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

[ Thread Index | Date Index | More Archives ]

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.


Mail converted by MHonArc 2.6.19+