|[hatari-devel] problem with gemdos 0x20 Super|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
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 ?