TRACE bit functionality

[JimDrew]

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!

[ijor]

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]

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.

[ijor]

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]

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.

[ThorstenOtto]

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.

[mfro]

... 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.

[npomarede]

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