Possible READ ERROR when switching to physical drive

[ki-bo]

Test Environment (required)
Tested with V920418

Describe the bug
The ROM tracks the current position of the read/write head, which can only move via relative stepping. On first use, the head’s position is unknown, so it is stepped outward until the track 0 sensor is activated. However, the remembered head position is not reset when Hyppo switches between virtual and physical drives. While the controller’s auto-tune feature can partially compensate for this issue, disabling it makes the problem more noticeable.

To Reproduce
Steps to reproduce the behavior:

1. Mount the physical disk via MOUNT and do DIR. This will make sure the physical head position is at track 40
2. Clear $D696.7 which is related to the track auto-tuning feature
3. Mount a D81 image with the MOUNT"IMAGE.D81" command
4. Load a program, eg. via LOAD"*". This will make sure the virtual head position is not at track 40 anymore.
5. MOUNT again the physical disk
6. Do DIR. The head will move (but shouldn't as it already is on track 40, see above). It will try to find sector 40:0, but will only find sectors from a different track, eventually resulting in 27,READ ERROR,40,00

Expected behavior
The directory should be shown.

Additional context
I was looking into the ROM src how the current track position is handled for the internal drive. Indeed, there is a curtrack array keeping that information per drive. On reset, this is initialized with 128, and on each access, we check whether the NEG flag is set for that drive. If it is, we assume the head's track position is unknown and execute a seek-to-track-0 routine, and then keep track of the head position whenever we step in or out.

On the other hand, it seems the controller's auto-tune feature is still enabled, which also will trigger stepping of the motor. I am wondering whether it is better to turn that off as the DOS is doing its own positioning.

In any case, we should reset the drive's curtrack value to 128 if the drive's state changed from virtual to physical, as then the head position is unknown again. Maybe we can add a check of the related register whenever a new drive access is triggered. That check could be added to InitCtlr.

[ki-bo]

Btw. the documentation also seems to be wrong. In section "Track Auto-Tune Function" it states The 45IO27 also includes a track “auto-tune” function, which is enabled by clearing bit 7 of $D696.

In sdcardio.vhdl, it is implemented the other way round:

when x"96" =>
              autotune_enable <= fastio_wdata(7);

This is also in line with the $d696 register behaviour described above in the original bug description.

[gurcei]

I'll share a reference to some of the discord chatter I had on this topic here:

• https://discord.com/channels/719326990221574164/719326990221574168/1439819958740582440

In it, I noticed that if I mounted "INTRO1.D81", and loaded various items within it, then did a power-cycle, and then did a MOUNT + DIR, sometimes the issue would trigger, sometimes it wouldn't. It seemed to depend on the track the loaded file was on prior to the power-cycle. E.g.:

WORKS on T24, S02 - "TETRIS"
WORKS on T31, S29 - "LEMONADE 65"
WORKS on T39, S0 - "AUTOBOOT.C65"
WORKS on T41, S0 - "2 BITPLANE CUBE"
WORKS on T41, S07 - "ARTHURS DAY OUT"
WORKS on T42, S05 - "BLASTER"
WORKS on T43, S27 - "CHARWARS 65"
WORKS on T44, S33 - "CHEEK2CHEEK"
FAILS on T45, S21 - "COMBAT"
FAILS on T47, S13 - "GUIDE AKMAFIN"
FAILS on T54, S3 - "REVOLUTION 65"
FAILS on T67, S11 - "REVOLUTION"

So from the above, the problem seemed to surface for files loaded from track 45 and higher, then power cycle, MOUNT + DIR (gets read error).

For additional reference, on discord I also shared a few vids of steps to replicate the issue, the workarounds I found so far, along with capturing the drive head movements:

• https://discord.com/channels/719326990221574164/719326990221574168/1440029257576485048

Video#1: showed how I can work around the issue by jumping into the freezer and mounting the floppy drive from there

Video#2: showed how I can work around the issue by doing a powerup + RUN-STOP to get into monitor and then exit with 'X'

Video#3: shows how I can work around the issue by doing a POKE $100E3, $80 ($100E3 = rom's curtrack variable) to force the rom to seek out track 0 again upon the next DIR.

Conclusion: I'm feeling upon doing a MOUNT, the rom should set this curtrack var to $80, to force the "seek-out-track-0" behaviour on the disk's next use (i.e., what I had accomplished manually with the POKE $100E3, $80

[ki-bo]

Conclusion: I'm feeling upon doing a MOUNT, the rom should set this curtrack var to $80, to force the "seek-out-track-0" behaviour on the disk's next use (i.e., what I had accomplished manually with the POKE $100E3, $80

Thanks for all the detective work!

I would not solve this as you proposed, though. I would prefer to have the curtrack >= $80 check getting amended with a check whether the drive changed from virtual to physical since our last access. That would be the most robust approach.

[dansanderson]

Was able to repro this, including the workaround. MOUNT then DIR caused the motor to spin but suspiciously no head noises, followed by Read Error. POKE $100E3,$80 then DIR got me head noises and a successful disk read.

[ki-bo]

The auto-tuning feature typically detects the current track position by reading the track ID embedded in the sector headers as they pass under the head. It then steps the head automatically until the desired track is reached.

However, if the head is positioned on a track without valid headers (such as those beyond the standard formatted area) auto-tuning may fail. Many floppy disks are pre-formatted up to track 82, but the MEGA65 floppy utility allows erasing flux data across a wider range, up to track 82 or even further (not 100% sure how far beyond track 80).
If you erase all tracks and then format only up to track 80, the head could become stranded in the beyond-80 area. In this case, the auto-tuning mechanism would no longer function, since there are no valid headers to reference.