| Re: [hatari-devel] Re: Hatari floppy drive detection with EmuTOS |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Le 16/01/2014 22:41, Roger Burrows a écrit :
On 16 Jan 2014 at 18:50, Nicolas Pomarède wrote:
Le 16/01/2014 18:28, Roger Burrows a écrit :
On 16 Jan 2014 at 10:46, Nicolas Pomarède wrote:
Do you have the possibility to test this on a real ST :
- connect drive A and disconnect drive B as above
- but in the drive detection test, test drive B first, then drive A.
I'd like to know the delay you get in that case where spinup is made
first on the disconnected drive.
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 ?
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.
I successfully uses this in my program between each access :
FDC_Tempo
rts
Doing a "bsr FDC_Tempo" will take a total of 44 cycles.
I saw a lot of demos/games with different pauses between access, I have
the feeling the minimum delay indicated in the doc is not that strict.
Nicolas