[hatari-devel] Re: Hatari floppy drive detection with EmuTOS (was: Re: Improved timings for the FDC emulation)

["Roger Burrows" <rfburrows@xxxxxxxxx>]

On 29 Nov 2013 at 15:59, Nicolas Pomarède wrote:
>
> There was a small bug in Hatari when drive was not correctly disabled
> from the command line -but it was OK from the UI).
>
> With this fixed, I see that both drives' icons are shown with emutos
> when drives are off, but if you click on them, nothing happens, so
> emutos seems aware that the drive is indeed off and commands should not
> be sent in that case (which is different from normal TOS, whether this
> is a better behaviour or not is a matter of personnal preferences I guess)
>
I just did some testing on this issue, and found the following:

1. Hatari hacks the drivebits to show both A & B present if you have a GEMDOS
drive defined.  This may be what you are seeing here.  So all of the remaining
applies when the GEMDOS drive is NOT defined.

2. With the current Hatari snapshot, if drives A & B are configured, EmuTOS
only detects drive B.  If only drive A is configured, EmuTOS detects no drives;
if only drive B is configured, EmuTOS detects it.

> > I can post a summary here of how EmuTOS does drive detection, if that would
> be
> > helpful.  If there's an error in the logic, I'll certainly fix it.
> >
>
> Yes, that's would be interesting to post the summary; from the traces of
> emutos 0.91, the detection seems not correct to me.
>
Detection mechanism in EmuTOS:
For each of drive 0, 1:
 a) select drive via PSG
 b) send 0x03 to 1772 command/status reg
 c) wait up to 3 seconds for gpip bit 5 to clear
 d) if it doesn't clear, timeout, no device [this is what happens for drive A]
 e) if it does clear, read 1772 command/status register
 f) if the TR00 bit is set, the device exists.

NOTE: If I change the code to test drive 1 before drive 0, then drive 1 is not
detected, drive 0 is.  So somehow, it's the first timeout that is not working
correctly.

> One can test for a enabled drive by doing a restore with verify=off and
> then check in the status register if the TR00 bit is set. This bit will
> be set even if drive is empty, but it will remain clear if the
> corresponding drive is OFF, even when head is on track 0.
>
That's what EmuTOS does (see above).

> This is what EmuTos does, by sending a restore command on each drive :
>
> fdc change drive/side io_porta_old=0x7 io_porta_new=0x5 side 0->0 drive
> 0->0 VBL=69 HBL=52
> fdc write 8606 ctrl=0x80 VBL=69 video_cyc=26724 308@52 pc=e06e4e
> fdc write 8604 data=0x3 VBL=69 video_cyc=26800 384@52 pc=e06e5e
> fdc write 8604 command=0x3 VBL=69 video_cyc=26800 384@52 pc=e06e5e
> fdc type I restore spinup=on verify=off steprate=3 drive=0 tr=0x0
> head_track=0x0 VBL=69 video_cyc=26800 384@52 pc=e06e5e
> fdc start motor with spinup VBL=69 video_cyc=27520 88@54 pc=e5e758
> fdc start motor : no disk/drive VBL=69 video_cyc=27520 88@54 pc=e5e758
>
> fdc change drive/side io_porta_old=0x5 io_porta_new=0x3 side 0->0 drive
> 0->1 VBL=249 HBL=24
> fdc write 8606 ctrl=0x80 VBL=249 video_cyc=12780 80@25 pc=e06e4e
> fdc write 8604 data=0x3 VBL=249 video_cyc=12856 156@25 pc=e06e5e
> fdc write 8604 command=0x3 VBL=249 video_cyc=12856 156@25 pc=e06e5e
> fdc write 8604 while fdc busy in prepare+spinup, current command=0x3
> replaced by command=0x3 VBL=249 video_cyc=12856 156@25 pc=e06e5e
> fdc clear irq VBL=249 HBL=25
> fdc type I restore spinup=on verify=off steprate=3 drive=1 tr=0x0
> head_track=0x0 VBL=249 video_cyc=12856 156@25 pc=e06e5e
> fdc start motor without spinup VBL=249 video_cyc=13576 368@26 pc=e5e758
> fdc start motor : no disk/drive VBL=249 video_cyc=13576 368@26 pc=e5e758
> fdc complete command VBL=249 video_cyc=13588 380@26 pc=e5e75a
>
> But as you can see from the warning in the traces, the restore on drive
> B is sent *before* the restore command completed on drive A. This is not
> correct, as the WD1772 doc says a new command will be ignored as long as
> the busy bit is set for the current one.

The restore is sent to B before the restore completes on A because the restore
on A times out (after 3 seconds).  For testing, I increased the timeout to 9
seconds.  You can clearly see that the delay is really happening during EmuTOS
bootup, but it still times out looking for drive A.  So it seems that the GPIP
bit is not being cleared.

The current EmuTOS code works on real hardware (just tested on my ST with two
drives).

Roger