|Re: [hatari-devel] TT emulation crashes when there is no ACSI drive|
[ Thread 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: Uwe Seimet <Uwe.Seimet@xxxxxxxxx>
- Date: Sun, 11 Aug 2019 14:52:48 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1565527968; s=strato-dkim-0002; d=seimet.de; h=In-Reply-To:References:Message-ID:Subject:To:From:Date: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=J/I8KuozuI+pgvc49c6TqTj24zbg2PxhK7S2JMsk+v4=; b=ELw/l06TfIEm1ipNQTevLnRa/DTTM35ZliFn2eOMzNJNVMMdZBhXTmdR+4PrPYAfwd p1+6XOdw3iTapkTHycIP5T/dWp7Dv8mYk7BJNpoL1Sl+K/OoZnGS3r2ZYoQVGctWgzpa FipYaS/KOlHXC/q3FkCr3mtft9kuBKub67dwqC7iwXfjuiiUrPAxZhUDrJog5qb9/7bc WN7X+YBXGPiBcy+q7/0LVk/bewlAVaF5/7MkhLd2Sk0Gd2pXgPbh88vh7kLXl3Zacp/0 78y5GT0Z+x27UX8f9irYC9uPExj6blQFEQhGJBR2em3RJMfX7mszVwvTtQ3Nxs52jvFW 2nwQ==
Sounds quite tricky. Why doesn't this also happen on real Atari hardware?
I'd assume that there could also be an MFP interrupt at a critical
> Christian Zietz schrieb:
> > Ah, that was the key missing piece of information! Now I can see the
> > bug, too. And I guess Eero and Nicolas could find the reason behind it.
> My initial analysis for the Hatari developers to continue on:
> 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.
> 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?
> Christian Zietz - CHZ-Soft - czietz@xxxxxxx
> WWW: http://www.chzsoft.de/
> PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA