[hatari-devel] problem with gemdos 0x20 Super

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Hello

I'm looking for a crash in several Stax menu compilation.
For example in Stax 53, press "1" and you get 2 bombs (with tos 1.62). 
This doesn't crash under Steem with the same tos.

The code that crashes is when we go back to User mode at $aa9c.

$00aa88 : 42a7                                 clr.l     -(sp)
$00aa8a : 3f3c 0020                            move.w    #$20,-(sp)
$00aa8e : 4e41                                 trap      #1
$00aa90 : 5c8f                                 addq.l    #6,sp
$00aa92 : 23c0 0001 7524                       move.l    d0,$17524

$00aa98 : 6100 03fc                            bsr       $ae96 
-> run the demo

$00aa9c : 2e79 0001 7524                       movea.l   $17524,sp
$00aaa2 : 3f3c 0020                            move.w    #$20,-(sp)
$00aaa6 : 4e41                                 trap      #1
$00aaa8 : 5c8f                                 addq.l    #6,sp

The problem is that instead of doing clr.l #$20,-(sp) at $aaa2, the code 
is just restoring the saved value of A7 in User mode, but in that case 
8(sp) (as used in the TOS handler for 0x20) is pointing for example to a 
random memory location

content of A7 when entering $fc9350 (0x20 handler in tos) :

003782: 23 00 00 00 aa a8 00 20 bf 08 00 00 00 00 00 00   #...ª¨. ¿........

the value of 8(sp) (stack to restore) is then bf080000.

This looks like a bug in the demo to me, but still its works under Steem 
(certainly because the ram contains different data)

Also, if I run Hatari with "--patch-tos no" and without hd emulation (to 
remove the handlers installed by hd emulation), then the menu is working 
and pressing "1" is correctly starting the demo.

Thomas, do you know what causes this ? It seems HD emulation is not the 
only cause (it crashes if I removed HD emul but leave patch tos). Some 
memory handling in Hatari ?


Nicolas