mk79 wrote:I haven't though about this stuff for 10 years, so I'm a bit rusty. But as far as I can see that is simply a bug because the TRAP shares code with other exceptions where the T bit must be cleared. Amazing that nobody including myself has ever noticed it
Just tested it with a very old version (v3.12, it is dated March 2004) and tracing TRAPs worked. On v4.05 and higher it doesn't. So it must have been introduced somewhere in between
At first I thought this was a security feature of the 68020 (like the privileged MOVE from SR), but as I said I don't have the real hardware around to test this...
XorA wrote:It seems I could use your testsuite, as the following code from uqlx I guess means its nbcd instruction does not work.
I finally uploaded one version to https://www.kilgus.net/soft/m68k_tester_gz.zip. You probably only need to adapt the dev$ variable in the boot file. It can run very long on slower machines, days even, so it makes a screenshot after every instruction tested. Not so much a problem for an emulator like yours I guess.
Cheers, Marcel
Thanks Marcel, its currently crunching its way through on my Apple M1 (fastest CPU I have).
If you are very ambitious you can use the "all_flags_exe", it will also check the flags marked as "undefined"
IIRC I used this SBCD code from the UAE emulator as a reference in later QPCs as it also preserved the 68k behaviour when the operands are not BCD values: