Re: [hatari-users] Floppy in Falcon mode

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

On 24/12/2011 17:10, Vincent Rivière wrote:
> Nicolas Pomarède wrote:
> If I'm not wrong reading the bits, I think I use:
> - Restore command
> - Enable Spin-up sequence
> - No Verify
> - Stepping rate 6 ms

This looks fine, I added some traces to devel sources, can you update 
your hg version and run your tests again ? It should display 
"current_track", which is the head's position at the time the restore 
command is run. It would be interesting to see if they differ for A: and B:

> > Even with a 12 ms stepping rate, restoring from track 79 should take a
> > little less than 1 sec, so it all depends on the optional bits you use
> > in the restore command.
>
>  From Hatari's log, looking at the VBL count I deduce that:
> - Restore on first drive takes 1.4 seconds in ST mode
> - Restore on second drive takes 2.4 seconds in Falcon mode
>
> I admit that EmuTOS 1.5 second timeout is too short.
> Anyway, is there a rational explanation for the Hatari behavior I
> describe here?

From the log, I don't see anything special. Do you get the same 
differences if you use falcon mode but with a 8 MHz CPU ?

Anyway, those commands seem unnecessary to me :

fdc write 8606 ctrl=0x82 VBL=3 video_cyc=12831 131@25 pc=e0624e
fdc write 8604 data=0xffff VBL=3 video_cyc=12997 297@25 pc=e06258
fdc write 8604 track=0xff VBL=3 video_cyc=12997 297@25 pc=e06258

Why do you set track register to 0xffff ? Track register is only 8 bits 
anyway, so this becomes 0xff, but anyway, I don't see the point of doing 
this before the restore command. In fact, this could even create trouble 
if you used the 'verify' bit, because track register should be set to 
the physical head position before doing a type I command with verify bit 
set.

This should not be related to your problem, but it looks wrong to me, 
changing track register should not be required.

Nicolas