|Re: [hatari-devel] Re: Hatari floppy drive detection with EmuTOS|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
Le 17/01/2014 03:07, Roger Burrows a écrit :
On 16 Jan 2014 at 23:14, Nicolas Pomarède wrote:
OK, the following runs were made with floppy 1 tested first, then floppy
1. Drive 0 connected, drive 1 disconnected:
Drive 1: timeout (3 seconds)
Drive 0: 255 ticks
2. Both drives connected
Drive 1: 361 ticks
Drive 0: 26 ticks
For some reason, the timeout is working as expected here ...
Thanks for the test ; however, I don't see where those 3 sec are coming
from. The FDC has a 6 revolutions spinup, which makes 1.2 sec, and a 9
revolutions for motor stop, which makes 1.8 sec. So nothing in the
WD1772's doc that comes close to a 3 sec delay.
In test 1, we see spinup never complete, which make detection of drive 0
slower, because the spinup must be made on drive 0.
So, I don't understand what makes the restore+spinup stops after 3 sec
on drive 1, I don't see how Emutos can see bit 5 of $fffa01 going to '0'.
Are you sure it's not your timeout that stops the command ?
Sorry if it wasn't clear, it is indeed the EmuTOS 3 second timeout that occurs.
All the specific times listed are when bit 5 of fffa01 goes to 0; that didn't
happen for drive 1 in case 1, I got a timeout instead.
Ah ok, yes, I think there was a misunderstanding ; this is closer to
what I experienced on my STF.
For me, test 1 (timeout on drive 1 disconnected) is the correct
behaviour : no drive -> no spinup -> timeout
But test 2 doesn't match my test on STF. General knowledge (measure on
my STF, code in the IPF library, mail by David S. after opening his
drive) show that a connected drive _without_ a floppy in it should not
be able to report index pulse. But here, drive 1 succeeds after 361
ticks, I don't understand why.
As David suggested, maybe your external drive 1 is different from the
internal drives shipped by hatari and send IP even when there's no disk
? (the "long" time that an STF takes to boot to GEM without any disk
inserted is because spinup timeout, so Atari drive are doing timeout
Emulators don't have a setting to tell if the drive can send IP or not
without a floppy (it would be too technical for the user), they assume
the behaviour of a standard Atari floppy drive.
In that's the case, the only solution I see for Emutos to support real
HW and emulator is to do the test without the spin up bit.
Does Hatari implement the 16 microsecond minimum time between read/write
No, this minimum delay is not taken into account, immediate writes are
always processed (I don't think other emulator emulate the delay either)
I am still puzzled why EmuTOS gets a timeout on drive 1 under Hatari, when
drive 1 exists. As noted before, EmuTOS detects the drive correctly on real
As above, maybe your drive 1 has a "non standard" hardware, it would be
interesting to know the model ?
I will post a small program later that simply check a restore+spinup
that you can test on your drive 0 and 1, to see if they give different
result when they are drived by the same WD1772. If that's the case, then
it's a difference in the drive model.