| Re: [hatari-devel] TT emulation crashes when there is no ACSI drive |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
- To: hatari-devel@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [hatari-devel] TT emulation crashes when there is no ACSI drive
- From: Thomas Huth <th.huth@xxxxxxxxx>
- Date: Fri, 16 Aug 2019 06:20:41 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1565929243; bh=ocMxjaaaX57vo0Dv4jV5xuA1P4rErsKeXgMXTJ1CCl8=; h=Date:From:To:Subject:From; b=PXaAfO/+BF0Os5WuaJn8IyPJLyFWbLOr/cIdqOUUW/Fl9WTeCIbjxaQik8Q5D300S 7ROQkfIlWqpGEIW+nL+B/6Wz14XcnvniKCXvwpPY1cQ8k2LbjZETUAKWa83T9ckZKP Cy08EQq+tda3eNcwnppEeXZJNomfz8RKaFsNIW0z6lHYAVxJ/XpUtdAZc4a9kbvjT8 MXLJYEI9X+YITcqDr6EaMIQKbSBRM40Fm7NtYbP3Dh+hEM8NrGowDVQWrSdOT0gqXQ BJwyOiTeMHCNZa6/+eSq/MWRQJ526c3N6HTH/KZ95dCpXNriDb8TQBuVzsF1ZoDqxm iNXOiHXjIgIgQ==
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.
Thomas