Re: [hatari-devel] ASV unix crash with TT emulation

[ Thread Index | Date Index | More Archives ]


Second MFP isn't only potential problem.

Did you verify with "--trace vme" that ASV
doesn't try to use TT VME/SCU registers?

E.g. Linux doesn't boot with Hatari TT
emulation unless VME/SCU access is disabled
(with "--vme none") as Linux will try to use
SCU regs if they appear to be present.

(I added support for tracing & disabling Hatari's
no-op VME/SCU reg access after v2.3.1 release, so
Hatari git version is needed for this.)

	- Eero

On 12.3.2021 11.29, Markus Fröschle wrote:
bringing up this old issue again.
I have had a look into it and it appears that the ASV Unix crash dump
is misleading here. Using the Hatari debugger,I tried to find out what
happens here.
Indeed it appears to indicate the MFP involved in the crash, but
actually, this seems to be a subsequent fault(as it shows the registers
from the crashdump writeout itself that is not only written to the
screen but to theserial port as well).
The root cause of the crash appears to be indeed this:
WARN : Write to unimplemented RTC/NVRAM interrupt enable bits 0x40

ASV seems to be using the TT RTC's timer interrupt as kind of watchdog
and crashes if this does not trigger as expected.
Not sure if this is the only issue that prevents ASV from booting, but
at least I would really like to give it a try.

Question is: what would it take to properly implement this interrupt?
Can somebody provide pointers on where to look
best for a sample implementation of an interrupt trigger in Hatari's
source code that could be used as a template?

I already peeked into the source tree but admitted, I'm a bit lost on
where to start. Hints appreciated.

Thank you!

Am Montag, den 06.05.2019, 18:18 +0200 schrieb Nicolas Pomarède:
Le 06/05/2019 à 18:02, Uwe Seimet a écrit :
Interesting news. I just checked the behavior of ASV, which appears
to get abit further in the boot process now. There is an exception,
though, pleasesee the attached screenshot.

hard to tell what went wrong with this screenshot (and I don't know
ASV that much) ; strange thing is that A0=FFFFFA13 in that dump,
which would mean it was an access to main MFP whose behaviour was not
modified (hopefully). But it's not sure the faulty access was made on
this address, one would need to see the corresponding asm code.

Mail converted by MHonArc 2.6.19+