Hello, * On Sat, Apr 11, 2026 at 10:50:07AM +0200 André Fachat wrote: > > Am 11. April 2026 10:41:54 schrieb Francesco Messineo > > I think all the routines do away with the verify. What my routine - IIRC - also > removed was the measurement of the drive speed and thus track length in bytes > that the original does (every track?). That's probably why it failed on other > drives. > > My guess is, without having looked at the code yet, that the working routine > measures it on the first track and then just calculates the gaps for all the > other tracks. as I have worked on a fast formatter years later, I can also add to it. First: The routines I disassembled never tried to measure the track length. They just wrote was worked for them. This approach can work if your gaps are conservative enough, that is, rather shorter than longer. For cbmformat https://github.com/OpenCBM/OpenCBM/tree/master/opencbm/cbmformat (and, later, https://github.com/OpenCBM/OpenCBM/tree/master/opencbm/cbmforng), WoMo and I used something that we *believe* no other used (but we may be wrong). From memory: 1. First, write track 1 with a pre-defined gap. For reasons given below, this GAP is very conservative, that is, it should be shorter than needed, but not longer under any circumstances! 2. To write the track, first clear a memory on the track (overwritten with $55) that can be used to later measure the last GAP. 3. Then, start writing all sectors with the known GAP 4. After we switched back to read, measure the number of GCR byte we read before the next SYNC comes. If the number of byte is "in the range of" the the GAP we have used, the GAP seems to be correct. Calculate how much to increate the GAP from the number of byte, and re-start with step 2 5. Now, check if the next SYNC introduces the block header of sector 0 of the track. If not, the write failed. That is, the GAP was too long! As we do not know how much too long, we shorten the GAP very aggressively (IIRC, we half it) and retry formatting this track (step 2) 6. If it succedded (and no verify was demanded by the user on the command-line), we change to the next track. If we change the speed zone with this, we adjust the GAP with given differences we have pre-calculated. If the last track was done, we are done. Otherwise, repeat with step 2 for the new track What came out of it: 1. The first track almost always needs 2 round in order to format it. That's because the GAP is very conservative. 2. If the GAP is too large, we have to take 3 rounds: First, we write the track which is too long. As we do not know how much too long, we halve the GAP and try again. As this try is almost always too short, we need the 3rd try with the right GAP. That's why the first assumed GAP in step 1 is so conservative. 3. This scheme works very reliably in general with 1541-II and 1571 drives (which are direct driven). The 1541-I is a little bit more problematic and needs the one or the other extra round in some cases. That's why the test for the remaining bytes in step 4 has to be "in the range of" the GAP. The 1541 needs a much more relaxed check, or chances are it will never succeed. 4. We found a strange mystery: Using our approach, step 5 failed every now and then. Debugging it, we found that it was written correctly. However, the test "thought" it was wrong. Inverstigating into it, we found that this problem occurs if we generate an empty data block of $00/$00/$00 (like the 2031, 4040 and early 154x drives used. If we change this pattern to $00/$01/$01/... (first track) and $4B/$01/$01/... (all other tracks) like the 1541 and later do it, this problem did not appear that often anymore! We even took this here to cbm-hackers: https://www.softwolves.com/arkiv/cbm-hackers/10/10471.html We assumed (but could never proove) that the drive has a problem when reading data immediately after switching from writing to reading, that it needs some time to settle. 5. The 1571 and 1541-II had other mysteries I do not remember completely. ;) 6. For direct driven drives, this schemes resulted in almost always needing 1 extra rotation for the first track only, but not more. The belt-driven 1541 is special, it takes an extra rotation every now and then, but we could reduce this considerably. 7. Of course, we need a little bit more than 1 rotation for writing because we wait for the next SYNC block and read it to find out if the GAP was right. 8. To be really reliable, we need the verification step, thus, we need 2 rotations per track. Note that while analyzing it, we found out that the original 1541 format routine also has a bug in which it will not recognize a specific type of error. I would have to look it up to find out what the problem was, I do not remember the details. Regards, Spiro -- https://spiro.trikaliotis.net/Received on 2026-04-12 09:33:32
Archive generated by hypermail 2.4.0.