Re: [hatari-devel] Re: Hatari floppy drive detection with EmuTOS

[ Thread Index | Date 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
0.

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

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
accesses?


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

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.


Nicolas




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/