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

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

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