TRACE bit functionality

All 680x0 related coding posts in this section please.

Moderators: exxos, simonsunnyboy, Mug UK, Zorro 2, Moderator Team

JimDrew
Atari Super Hero
Atari Super Hero
Posts: 644
Joined: Mon Nov 04, 2013 5:23 pm

TRACE bit functionality

Postby JimDrew » Thu Aug 18, 2016 12:53 am

Can someone explain exactly what gets pushed onto the stack when either T0 or T1 bits are set? I know it's a type 2 exception, and thus a 6 word exception frame, but I am not sure of the order of what is placed on the stack. Thanks!
I am the flux ninja

ijor
Hardware Guru
Hardware Guru
Posts: 3160
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: TRACE bit functionality

Postby ijor » Fri Aug 19, 2016 1:38 am

Jim, are you asking about a 68020 or (030), right? Because the plain 68000 has a single T bit.

I'm not expert on the 68020, but you can easily check the stack frame under emulation.

JimDrew
Atari Super Hero
Atari Super Hero
Posts: 644
Joined: Mon Nov 04, 2013 5:23 pm

Re: TRACE bit functionality

Postby JimDrew » Fri Aug 19, 2016 3:16 pm

Yes, 020/030/040 are all the same, which is what I am after.

Does the debugger in one of the ST emulations have a trace function? What I am trying to figure out is if the Motorola manual is correct about the 6 word stack frame contents. I am working on a FPGA CPU core, and although the data looks to be correct based on the datasheet, the return address for the exception is wrong.
I am the flux ninja

ijor
Hardware Guru
Hardware Guru
Posts: 3160
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: TRACE bit functionality

Postby ijor » Fri Aug 19, 2016 5:06 pm

JimDrew wrote:Yes, 020/030/040 are all the same, which is what I am after.

Does the debugger in one of the ST emulations have a trace function? What I am trying to figure out is if the Motorola manual is correct about the 6 word stack frame contents. I am working on a FPGA CPU core, and although the data looks to be correct based on the datasheet, the return address for the exception is wrong.


For accurate 020 and higher emulation you need to use Hatari. The debugger, of course, has a trace function, but that not what's you want. The debugger trace is internal to the emulation engine, it doesn't provoke a trace exception on the emulated CPU. But you can easily provoke that in several ways (you can manipulate the T bits), and then use the debugger trace.

If you are more familiar with the Amiga, then you might prefer to use Winuae.

JimDrew
Atari Super Hero
Atari Super Hero
Posts: 644
Joined: Mon Nov 04, 2013 5:23 pm

Re: TRACE bit functionality

Postby JimDrew » Sat Aug 20, 2016 1:13 am

I am using WinUAE as a comparison already. There are numerous issues with WinUAE (lots of CPU errors we are finding while working on the Vampire board), so I don't want to rely on it. I will try Hatari.
I am the flux ninja

ThorstenOtto
Captain Atari
Captain Atari
Posts: 178
Joined: Sun Aug 03, 2014 5:54 pm

Re: TRACE bit functionality

Postby ThorstenOtto » Sun Dec 04, 2016 9:02 am

JimDrew wrote:I am using WinUAE as a comparison already. There are numerous issues with WinUAE (lots of CPU errors we are finding while working on the Vampire board), so I don't want to rely on it. I will try Hatari.


Hatari uses the CPU core emulation from WinUAE, so if there are errors in it, they will most likely be present in Hatari, too.

User avatar
mfro
Atari Super Hero
Atari Super Hero
Posts: 687
Joined: Thu Aug 02, 2012 10:33 am
Location: SW Germany

Re: TRACE bit functionality

Postby mfro » Sun Dec 04, 2016 9:33 am

JimDrew wrote:... I am working on a FPGA CPU core, and although the data looks to be correct based on the datasheet, the return address for the exception is wrong.


Exactly 'how wrong' is the return address - completely bogus or just an offset to what you expect?

You need to realize that a trace exception is triggered *after* the instruction causing it has executed, right before the next instruction, thus the instruction address of the exception stack frame doesn't point to the current, but to the following instruction (at least that's my understanding as I currently don't have anything suitable around to test this on).

This might be especially disturbing if you are tracing in change of flow mode.

User avatar
npomarede
Atari God
Atari God
Posts: 1178
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: TRACE bit functionality

Postby npomarede » Sun Dec 04, 2016 11:10 am

JimDrew wrote:I am using WinUAE as a comparison already. There are numerous issues with WinUAE (lots of CPU errors we are finding while working on the Vampire board), so I don't want to rely on it. I will try Hatari.

I'm really suprised you found "numerous" errors in WinUAE cpu core. 68000 emulation is very accurate for Amiga / Atari STF/STE emulation and I didn't find any games/demos lately that fails due to Cpu emulation under Hatari.
Could you elaborate on those errors ? Which CPU, 68000 or 68030 or others ? Do you have some reproducible test cases ?

Nicolas


Social Media

     

Return to “680x0”

Who is online

Users browsing this forum: No registered users and 1 guest