Re: [hatari-devel] Cartridge code Pexec7 / AUTO issue

[Thomas Huth <th.huth@xxxxxx>]

Am Sun, 26 Apr 2015 01:59:37 +0300
schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:

> Hi,
> 
> 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:

> r
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!

 Thomas