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).