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: Christian Zietz <czietz@xxxxxxx>
- Date: Sun, 11 Aug 2019 14:12:08 +0200
- Autocrypt: addr=czietz@xxxxxxx; prefer-encrypt=mutual; keydata= mQGiBDdn2AURBADksdHVyN55nv0lx4qGx+GQMrbo7zs7lSkAfhkgmgqp84xUeUiWI/kj1on/ wxkmJ96Yzt0ktDbZYM0C9Z66M3rLfXE1vXALHhegeMuOy/tVWybcohRrhfB7tmANTESJOZke 0lZZ59DcIfFoqLYErb6qX8nLPYnOv6sFubxnhuF9QQCg/3GaIR1sVK9Xq+b4B9BtVxd7cHMD /i2hAEOX3WY3K7PNZJziYF54uBbGiVS88W41l1RARcaeogIZcAKpFH3on+Tf60fAC85MCp17 QIeP44hj4Cf46B+UTVhf3EFG4IOsLRxUonpt7dKO8txsKFN/OFsjlPOuDyg7XMpEWkTWZetm HC9/0pcApIXSDnggde4T8AX6nn/+A/4hBOhPxuvkV7Uw/ebLYwXrLo2vt9OvvC1VfeywNseq PIkFX/+n/+niBS+Cb2ess2SVQNKJ9vP5+vBxg5AMfQXqk1ONldGQ/ARHmL6+Iuo47mO51e7R i691hq13wHUvyKh1AN7fpKI2m3YW55XEQ+3iTMIZcqfjr6xYgG8GJTppdbQgQ2hyaXN0aWFu IFppZXR6IDxjemlldHpAZ214Lm5ldD6IYwQQEQIAIwIZAQIeAQIXgAUCVGD5IgcLCQgHAwIB BhUIAgkKCwQWAgMBAAoJEFLLl/ZtoCXKubQAoIHNaurSMQB8MHDoTk3B7WHk2ApoAJ0egA8q aNoVj0kU4+OjeGzFiSHMOrkCDQQ3Z9gFEAgA9kJXtwh/CBdyorrWqULzBej5UxE5T7bxbrlL OCDaAadWoxTpj0BV89AHxstDqZSt90xkhkn4DIO9ZekX1KHTUPj1WV/cdlJPPT2N286Z4VeS Wc39uK50T8X8dryDxUcwYc58yWb/Ffm7/ZFexwGq01uejaClcjrUGvC/RgBYK+X0iP1YTknb zSC0neSRBzZrM2w4DUUdD3yIsxx8Wy2O9vPJI8BD8KVbGI2Ou1WMuF040zT9fBdXQ6MdGGze MyEstSr/POGxKUAYEY18hKcKctaGxAMZyAcpesqVDNmWn6vQClCbAkbTCD1mpF1Bn5x8vYlL IhkmuquiXsNV6TILOwACAgf+JhucyZDzOWGht9e0U71kC2bxIOr4iz+ADd3sxS62okrocHXp B9zYDhmJ74BFfC7xMd9bwWNj7YR0yiUdOzY27OcXcEkVmhVBW6AqxuRAKfmYMvvnyR5z5OP6 vg2YSzgOmooc5vequa5YIjLmFkuRlglLiEgdW9gPBFtirNqxOtAqSxEcRrblSn8JBEU51Ii6 SVVuo1nXOP11g8rVO4YvEED89pHT4jgLZu4th1N+mDumNZlqyUIxZ4tQyw3X2OWvEbKWGn2j h0ZywaomUTpVA+wiwxndawP40oowFYT8LNeLtfZyq6xPpQmT2DaNhP4gdy3qkDfnmXkc2zFM YukXo4g/AwUYN2fYBVLLl/ZtoCXKEQKA3QCfTJstYzXurbt9ZnoTU3SFQQmG0/wAoNX91nWM nsS7JOepPAzOUoke4AIi
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1565525530; bh=yZq8tTMYbwKcUPPuOI7006+5ChHNfFF3XhmEr7aVo/0=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=X4INCLK1vFLoRwcdN+VTNbq5YfY/LWPbTwqwahlW7iXA5SDAbpNatVIeeTLgVMjXW J3Lqa/BxCLDXZAskxCIc5hL4AqTAO1sxxYn2k57WgJsG+JNfP6dciy5zml8hxd+yWT Cv4xnXufFpSKwWDlOBlV9sLT6zaLn7pNTDWEc/l4=
- Openpgp: preference=signencrypt
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?
Regards
Christian
--
Christian Zietz - CHZ-Soft - czietz@xxxxxxx
WWW: http://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA