|Re: [hatari-devel] Cartridge code Pexec7 / AUTO issue|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
Am Sun, 26 Apr 2015 01:59:37 +0300
schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:
> On lauantai 25 huhtikuu 2015, Thomas Huth wrote:
> > schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:
> > > On tiistai 21 huhtikuu 2015, Eero Tamminen wrote:
> > > ...
> > > Only reason I could think of, why Pexec7 doesn't work during
> > > bootup is lack of parent basepage. Until bootup has finished,
> > > there's no valid basepage.
> > That can hardly be the reason. Pexec5 is failing too
> Just to verify...
> Did you test removing Pexec7 call from your code,
> and did it still fails when run from AUTO?
Yes, it crashed in that case, too.
> The code executed during Pexec7 when registers get messed and
> when they don't get messed is exactly the same, so I guess
> the issue is some data used by the code being different during
> TOS bootup.
Almost right - it was a stack overflow. The stack seems to be very,
very small when TOS boots, and GEMDOS uses a space for saving the
registers right below the stack area, so when the stack overflows,
the saved register values get clobbered.
This is from TOS 1.04 for example: The registers bevore the pexec call
looked like this:
D0: 0000001c D1: 00000000 D2: 00000000 D3: 00000000
D4: 00000000 D5: 00000000 D6: 00000040 D7: 00000008
A0: 0000098c A1: 000009c7 A2: 00fc0be6 A3: 0000a8fe
A4: 0000378a A5: 0000a852 A6: 0000a93e A7: 0000a8f0
USP=000f7ff2 ISP=0000a8f0 MSP=00000000 VBR=00000000
(note the values of A4 to A6)
Then the GEMDOS trap handler is starting like this:
$00fc9332 : 0817 0005 btst #5,(sp)
$00fc9336 : 660c bne.s $fc9344
$00fc9344 : 0c6f 0020 0006 cmpi.w #$20,6(sp)
$00fc934a : 6700 00b2 beq $fc93fe
$00fc934e : 2f0e move.l a6,-(sp)
$00fc9350 : 2c79 0000 5622 movea.l $5622,a6
$00fc9356 : 48ee 3801 0068 movem.l d0/a3-a5,$68(a6)
$00fc935c : 2d5f 0078 move.l (sp)+,$78(a6)
The value from $5622 is $0000a852, so a6 gets saved to memory location
$a852 + $78 = $a8ca. This is already pretty close to the stack
a7 = $a8f0 and since the following pexec code is pushing quite a bit of
further items on the stack, the save area finally got clobbered. At the
end of the trap handler, the values from the save area get restored
into the registers:
$00fc93ac : 2a79 0000 5622 movea.l $5622,a5
$00fc93b2 : 2b40 0068 move.l d0,$68(a5)
$00fc93b6 : 2c6d 007c movea.l $7c(a5),a6
$00fc93ba : 285e movea.l (a6)+,a4
$00fc93bc : 301e move.w (a6)+,d0
$00fc93be : 265e movea.l (a6)+,a3
$00fc93c0 : 4cde 07fe movem.l (a6)+,d1-d7/a0-a2
$00fc93c4 : 0800 000d btst #$d,d0
$00fc93c8 : 6610 bne.s $fc93da
$00fc93da : 2e4e movea.l a6,sp
$00fc93dc : 4e64 move a4,usp
$00fc93de : 60ee bra.s $fc93ce
$00fc93ce : 2f0b move.l a3,-(sp)
$00fc93d0 : 3f00 move.w d0,-(sp)
$00fc93d2 : 4ced 7801 0068 movem.l $68(a5),d0/a3-a6
$00fc93d8 : 4e73 rte
So finally a6 contains the clobbered value.
I now rewrote the cartridge code so that it uses less space on the
stack (the program header does not get fully loaded on the stack
anymore). The code is now really, really ugly, but it seems to work, at
least with the TOS version that I've tested. I hope that it is
sufficient for other TOS versions, too, so if you could do some more
testing (especially also with TT RAM), that would be great!