[U64 v1.41-3.10] Formatting a D64 produces read errors (DolphinDOS, SpeedDOS)

[Jumpman64]

When using SpeedDOS or DolphinDOS: Formatting a mounted D64 image often results in a 21,READ ERROR,00,00. Sometimes it happens somewhere e.g. 21,READ ERROR,31,00, sometimes formatting gets finished. @ N:TEST,01 or OPEN1,8,15,"N:TEST,01":CLOSE1

format.d64.zip

[marty41]

This also had happened sporadically with the previous firmware, so it hasn't been introduced with 1.41/3.10. Just for info.

[GideonZ]

Interesting issue. A few things have changed in the 3.10 drive emulation. With the addition of 1571, it became evident that the write timing needed to change. The standard format routines on 1571 would not work in 2 MHz mode, or the resulting disks were unwritable on the higher tracks. While in the previous drive emulation code, the first write byte was actually skipped on purpose, this caused errors on the 1571. It is very well possible that the physical R/W heads of these drives differ; e.g. in distance between the erase and write heads.

Another change is that a BLANK disk is not pre-filled with $55 anymore, but with $00; real blanks. But that would probably not matter, as the weak bit generator will then cause some random flux changes to be read, which is closer to reality than reading gap bytes on a blank disk. Do these read errors appear DURING format, or while trying to read the disk after formatting?

I would suggest saving the disk as G64 and analyzing it.

[Jumpman64]

These read errors occur randomly during the format process of a D64/G64 image.

[Jumpman64]

This also had happened sporadically with the previous firmware, so it hasn't been introduced with 1.41/3.10. Just for info.

Of course you are right @marty41 , the issue https://github.com/GideonZ/1541ultimate/issues/63 is still open 🙈

[Jumpman64]

Here are two G64 images created on U64 as an example. One is the created G64 original and the other was tried to format but quit out with read error. speeddos-format-test.zip .

[GideonZ]

I looked at the image-format-abort-using-speeddos.g64 with a Hex editor, and what I immediately noticed is the very large sector gap. For track 1 I would expect 21 sectors to be written, which brings the maximum sector size including the gap to 0x1E00 / 0x15 = 0x16D.B6, so let's round that down to 0x16D = 365 bytes. I see, however, a total sector length of 1c4 (452) bytes.

Could it be possible that SpeedDos tries to write the track with the wrong speed setting? In write mode, the speed setting is observed, but the track length is not adjusted for it. In other words, a track that is defined by the Ultimate is set to 0x1E00 in length for speed zone 3. So that means that if SpeedDos would attempt to write track 1 with the slowest speed setting (250 kbps), the track would appear to be 61440 bits / 250,000 = ~246 ms. If then, speeddos assumes that the length of the track is 246 ms times 307692 bps... this would result in an observed track length of 24EC (9452) bytes! And guess what number of bytes you get when you divide this by 21 (number of sectors)? Right.. 450 bytes. (~ 452)

[image: image.png]

So yea... too much of a coincidence! I think I know just from the data what SpeedDos does... it 'measures' the track length with the wrong speed setting (the slowest), but the Ultimate presents a track length of 1E00 (7680) bytes, because that's how the internal G64 representation for that track is... SpeedDos reads 9452 bytes (more or less), and decides to put a lot of gap in between the sectors.... Then switches to the correct speed setting, tries to write out all the sectors with the large gap, but then finds that it doesn't fit, and fails.

[Jumpman64]

(image.png isn't shown.) And here follows an actual DolphinDOS attempt to proof it out maybe. Format came to track 18 this time, it randomly makes it to a track (01,18,31) on both Speed- and DolphinDOS. As reported in issue https://github.com/GideonZ/1541ultimate/issues/63 dolphin_format_test.zip

[GideonZ]

The image.png was an inset, a screenshot of an Excel worksheet that I used. Apparently GitHub doesn't pick that up from e-mail replies.