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

["Roger Burrows" <rfburrows@xxxxxxxxx>]

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.

> >
> > On a related topic, I looked at your disassembly of TOS code.  It seems
> that
> > TOS delays for approximately 60 microseconds before and after accessing
> the
> > command/status register (I'm assuming a clock speed of 8MHz).  I have two
> > questions:
> > 1. What is the minimum delay necessary?
> > 2. Is this delay the same for any FDC register access (e.g. track
> register)?
> >
> > I ask because EmuTOS currently delays just 3 microseconds.
>
> The WD1772 docs mentions a register can't be read before 16 microsec
> after you write to it, but it's not very precise on the time needed
> between consecutive writes.
> But I think it's the same delay for each register.
>
> 3 microseconds means 24 cycles at 8 MHz, I can't really say if that's
> enough. It should be OK at 8 MHz, but maybe it could cause problems when
> emutos runs on 16 or 32 MHz cpu.
>
EmuTOS adjusts internal delays automatically according to the clock speed, so a
3 microsecond delay is 3 microseconds (approximately) on all systems.  I should
probably increase the time.

Does Hatari implement the 16 microsecond minimum time between read/write
accesses?

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.

Roger