Re: [hatari-users] Floppy in Falcon mode

[ Thread Index | Date Index | More Archives ]

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.


Mail converted by MHonArc 2.6.19+