Hello Dave, * On Mon, Apr 13, 2026 at 05:36:19PM -0400 Dave McMurtrie wrote: > I'm the person who uploaded the 15 second format disassembly to > GitHub, and was happy to see your reply. I have a few questions: > > > 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. > > I'm curious why shorter is better. It looks like in practice, > Commodore DOS 2.6 calculates a value around 7-8 bytes for the outer > tracks, then 12 or so bytes for the inner tracks. From "Inside > Commodore DOS" page 34: "The gap is designed to be long enough so that > if you write a data block on a day when your drive is turning slightly > faster than 300 rpm, you won't overwrite the start of the next > sector." This also indicates too long is preferred over too short. It > seems like it's more risky to have a too-short gap value than > too-long. Perhaps that statement was not completely thought out. ;) Fact is: The problems typically do not arise when you are writing on a disk that you formatted yourself. The turning speed of the drive does not "magically" change significantly. The main problem occurs if you change to another drive that has a different turning speed. If the new drive turns "much" faster than the drive with which you formatted the disk, the data block needs more space; thus, you have the risk to overwrite the next block header if the gap is too small. If the new drive is "much" slower than the drive with which you formatted the disk, things should not be problematic at all. Your data block is shorter than the one that was written on disk by the format routine. Thus, it will end sooner. However, as you are still in the "old" data block, you will not have any problems because the new drive cannot create a SYNC mark (with would be problematic), and it cannot overwrite the next block header because it is too far away. Note that the "much" is in parenthesis; we are speaking about a (very small) single-digit percentage value only. (We did some calculations back in the day, and I think it was around 3% or so, but I do not remember completely...) So: Yes, the problematic case is if the GAP is too small. My statement was wrong. > 15 second format uses a hard-coded GAP2 value of 8 bytes for all 35 > tracks. I feel as though this could be fraught with peril, but it > appears to work. > > I'd love to hear your thoughts on this. Again, I would have to look at the calculations from back then (or re-do them). I just had a look at the correction values that are used by cbmformat: - tracks 1-17: 0 - tracks 18-24: +9 - Tracks 25-30: -5 - Tracks 31-42: -3 Note that the values add to the GAP that was writen in the previous zone. Thus, if we start hypothetically with 8 on track 1, we would change to 8+9=17 on track 18, then to 17-5=12 on track 25, and then 12-3=9 on track 31. Our formatter starts with a GAP value of 5 on track 1, but it is marked as "most probably too small". So, looking at these values, the values of 15 seconds formatter might be problematic especially on tracks 18-24. But, as I said, I would have to look up the calculations. This is just from memory and from the source code. Additionally, WoMo was very correct in very small details. It might also be that we have overengineered this. > > 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. > > Commodore DOS 2.6 does this -- it writes a full track of $55 gap bytes > before it starts writing sectors. I was not clear in my statement. That's the problem when you write in a foreign language. I know that DOS writes a complete track (and some more) with $55. What I wanted to express is: We only "clear a memory *region* on the track". In fact, we write out 255 $55 values plus the time we need to convert the data blocks to GCR. IIRC, this should be much too long, so we could shorten that, but we never investigated on that. WoMo went over to cbmforng and really overengineered that. ;) We write these $55 in order to be able to reliably test for the length of the remaining gap, as we read that after writing and rely on that to find out if the gap value is usable. A spurious SYNC would be problematic here, as it would also be very problematic when reading or writing to that disk. Regards, Spiro -- https://spiro.trikaliotis.net/Received on 2026-04-14 21:00:01
Archive generated by hypermail 2.4.0.