| Re: [hatari-devel] Improved timings for the FDC emulation |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
On 24/11/2013 00:23, Roger Burrows wrote:
On 23 Nov 2013 at 23:53, Nicolas Pomarède wrote:
On 23/11/2013 23:29, David Savinkoff wrote:
I also noticed that Hatari/EmuTOS always shows Drive B:
when both drives are disabled now.
Isn't that the same on a real STF ? If I start mine with drive B turned
off, drive A and B icons are displayed nonetheless on the desktop.
What matters is the content of 0x4c2.l once GEM is up as it contains the
bitmask for the detected drives ; do you have 0 or 1 or 3 in this case ?
IIRC, EmuTOS only shows floppy drives that physically exist (it doesn't support
TOS's "virtual floppy" concept). So I expect that EmuTOS believes that both
drives are really there.
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)
But I don't know how emutos is checking if a drive is on or off, if I
recall correctly there were some discussions lately about this and it
used a slightly different sequence of FDC commands than a real TOS.
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.
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.
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.
There's one exception to this (not documented) if you send another type
I command during the spinup phase. Then the new command is run, but the
actual command is lost.
So, in either case, EmuTos code is wrong. You should send a restore on
drive A, wait for bit 5 of $fffa01 to be cleared (command is over), read
the status register, and then you can test drive B.
Note that in the case of the restore command, you don't need to handle a
timeout yourself in emutos if the drive is OFF. If the WD1772 can't
detect TR00 after 255 steps attempts, it will abort and you can detect
the failure because TR00 will be 0 instead of 1. This will take
approximatively 1 second to timeout.
Nicolas