|Re: [hatari-devel] ICD clock / Hatari MFP GPIP at startup|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
Le 23/04/2017 à 17:57, Christian Zietz a écrit :
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.
thanks for pointing this, fdc internal signal was set to 0 on reset, but
it was not propagated to MFP GPIP5 at this point (it was only propagated
later when the signal changed during normal fdc operations)
This is fixed now, let me know if the problem remains with Emutos and
this ICD detection.
PS : I'm not subscribed to Emutos list, forward this email if necessary