Unknown FPU instruction F201 0003B656
2. CPU breakpoint condition(s) matched 19 times.
pc = ( $8 )
3. CPU breakpoint condition(s) matched 3 times.
pc = ( $c )
4. CPU breakpoint condition(s) matched 10 times.
pc = ( $10 )
CPU=$e00fb6, VBL=4228, FrameCycles=3558, HBL=6, LineCycles=486, DSP=$583
$00e00fb6 : 48f8 ffff 0384 movem.l d0-d7/a0-a7,$0384.w
Last of all, the second crash relates to an emulator complaint about an unsupported FPU operation. As usual, the disassembler has trouble disassembling most FPU instructions so I'll need to decode this by hand to find out what it is. BTW this is true of both disassemblers, although the gaps in each are different.
$00e00fb6 : 48f8 ffff 0384 movem.l d0-d7/a0-a7,$038
> d $3b656
$0003b656 : f29d DC.W $f29d
$0003b658 : ffca DC.W $ffca
$0003b65a : f200 1528 fsub.x fp5,fp2
$0003b65e : f201 DC.W $f201
$0003b660 : 6500 f201 bcs $3a863
$0003b664 : 4500 chk.l d0,d2
$0003b666 : 2081 move.l d1,(a0)
$0003b668 : f23c 4538 3fe0 0000 fcmp.s #$3fe00000,fp2
So while I'm still not exactly sure what's going on, I'm becoming more sure that there is something wrong with the new Hatari's floating point emulation (aside from the disasm gaps - the emulator is broken somehow). Perhaps specific to 881/882 operations which are no longer common in software built for 68060 devices? Or maybe some functionality that the float library calls depend on - e.g. float exceptions - and which the compiled code does not.
(Once again: real HW does not show this issue. Versions of Hatari prior to the 'new core' upgrade do not show this issue either..).
I'm short of time today but will try to look deeper next week.
(Eero - I'll try to get you a test build sometime next week which shows these issues, at least for the debugger breakpoint problem which seems to be a separate thing).