[hatari-devel] ICD clock / Hatari MFP GPIP at startup (was: RC2 for EmuTOS 0.9.8)

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Christian Zietz schrieb:

> That being said, the ICD clock detection code is quite fragile, imho. It
> solely relies on the clock asserting the shared FDC/ACSI interrupt line
> when accessed. However, detect_icdrtc() does not check if the interrupt
> line was already asserted even before the attempted access to the clock.
> Maybe on Hatari there is an unacknowledged FDC interrupt waiting when
> detect_icdrtc() is called?

I think the main problem here is that Hatari starts with the MFP's GPIP
(General Purpose Input Port) register set to 0x00, i.e. the FDC/HDC IRQ
line is asserted (=low). This is different from the real hardware where
the IRQ is deasserted (=high) after reset. On Hatari, it is only after
some interaction with the FDC that the interrupt line is set high.

Hence, I'm crossposting this on the Hatari list as well.

So, during startup on Hatari EmuTOS' detect_icdrtc() always sees a low
level on pin 5 of the MFP, even without trying to access the ICD
realtime clock, and thus erroneously assumes that such a clock is present.

I see three possible ways to solve this:
a) Move the detection of ICD clock to a later stage, after the first
attempted floppy disk access. This however would mean that the clock
cannot be detected in machine_detect().
b) Think of a more robust detection algorithm for the ICD clock that
does not only rely on the interrupt.
c) Let Hatari fix this.

Regards
Christian
-- 
Christian Zietz  -  CHZ-Soft  -  czietz@xxxxxxx
WWW: http://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/