I seem to be running into obscure emulation problems with a current project using the latest Hatari. None are timing related, or even involve the DSP. This occurs in normal Falcon 030 emulation mode.
The first involved some GCC inline assembler fragments, performing endian swaps on words/longs. The actual problem is probably with one of the fragments, register clobbers etc. Strangely it always gets stuck in a loop in the new Hatari, but runs correctly in older versions of Hatari or real HW. Disabling the asm optimizations allowed this area of the code to execute properly. Hmmm!
I'll investigate later what was up with the asm fragments, but it's a bit worrying :)
The second problem I ran into immediately after fixing the first. Some plain C code is looking up a game object from a table, and performing a function pointer call. No assembly involved. This part of the code always worked on previous versions of Hatari, and on real HW.. It also compiles and works properly in VisualStudio 8.
On the latest Hatari, this code is jumping to address 0 for one of the game objects.
Again, it could be some sort of code bug that hasn't shown itself until now - maybe. However getting two of these in a row - for the first time - without any DSP stuff being involved is suspicious. Especially so that the same binary runs happily in Hatari 1.7.
I noticed in both cases some 030 addressing modes were involved. e.g. see below.
In the earlier case, FPU code was mixed with CPU code (but not used to affect conditions/branches - just to convert data).
If I find out more detail I'll update...
_Object_Init:
$00026ea8 : 2f02 move.l d2,-(sp)
$00026eaa : 202f 0008 move.l 8(sp),d0
$00026eae : 2400 move.l d0,d2
$00026eb0 : e58a lsl.l #2,d2
$00026eb2 : 2200 move.l d0,d1
$00026eb4 : ef89 lsl.l #7,d1
$00026eb6 : 9282 sub.l d2,d1
$00026eb8 : 2230 19b0 0034 2430 move.l $342430(d1.l),d1 <- d1 is garbage by this point. uncommon addressing mode.