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

[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.
It's possible the 2nd MFP in TT mode triggers some interrupts/exceptions 
that were not present before and that the processing of these interrupts 
use more stack than what it was before.

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.

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.

> > Even minute changes in timing, like switching to "cycle exact" mode or
> > renaming the file (which probably makes some code running a bit longer
> > while comparing file names) makes the MFP interrupt happen at a less
> > critical moment.
> >
> > Yet, this was a time bomb waiting to be triggered. I don't have a
> > solution at hand, though. Maybe switch to another stack during the
> > cartridge Pexec code?
> 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).
This might already be safe to do so, but TOS code should be checked to 
be sure.

Nicolas