Re: [hatari-devel] TT emulation crashes when there is no ACSI drive

[ Thread Index | Date Index | More Archives ]

Am Sun, 11 Aug 2019 22:35:37 +0200
schrieb Nicolas Pomarède <npomarede@xxxxxxxxxxxx>:

> Le 11/08/2019 à 17:19, Roger Burrows a écrit :
> > On 11 Aug 2019 at 14:12, Christian Zietz wrote:  
> >>
> >> It is stack corruption after all -- like I speculated before. While
> >> running AUTO programs, TOS is operating with a dangerously low
> >> stack, very close to the GEMDOS register save area. The Hatari
> >> cartridge Pexec code also needs some stack space. Thus, if a MFP
> >> interrupt occurs at precisely the wrong moment (i.e. within a
> >> GEMDOS call from load_n_reloc), the stack overflows into the save
> >> area and upon return from GEMDOS the A6 register is wrong,
> >> ultimately causing the crash Uwe is experiencing.
> >>  
> > Great analysis, Christian!  
> yes, thanks a lot for the report.

Right, thanks a lot for that analysis!

> Not much we can do about these interrupts, maybe the stack was close
> to be too short on real TT too, but the extra stack use due to the HD 
> emulation in cartridge space is certainly taking too much stack at
> one point.

I don't think we can still shorten the stack here very much ... at
least not without a major rewrite of the assembler code.

> One possible solution would be to allocate a dedicated RAM space when 
> cartridge code starts at boot and use it as stack space when entering 
> cartridge later.

Hmm, maybe. But I guess that will cause other problems instead (e.g.
I'm currently not sure whether this code needs to be reentrant or not)

> > Maybe turning off interrupts during the cartridge Pexec() code?
> This could be a solution ; I'm not familiar with the corresponding
> TOS part, but assuming SR is set to $2700 during the Pexec/cartridge
> part we need to be sure that no TOS code in-between will be waiting
> for an exception (for example FDC or HDC IRQ).

We can at least try this solution. If it does not work, I think we
should rather get rid of that assembler kludge and rather rewrite at
least most parts of it in the C side of the host. GemDOS_LoadAndReloc()
is already a good first step into that direction.


Mail converted by MHonArc 2.6.19+