Hello, just to add a little bit to Andrés statements: * On Sun, Sep 28, 2025 at 02:44:10PM +0200 André Fachat wrote: > The dual CPU drives write 8 byte of real gap data bytes, which get translated > into 10 GCR bytes. Correct. > When they converted to the single CPU drives, they forgot that the old drives > converted between real and GCR in hardware. So they only wrote 8 bytes too, but > which was then GCR bytes. I believe the early 1540/1541 DOS images should have > that value. They then later moved to 10 and back to 9 IIRC. That's correct, too. The 2031 writes 8 bytes, as does the 1540 and the 1541 with 901229-01 and -02 ROM. With the 901229-03 ROM, Commodore changed the GAP to 9 byte. I even wrote about it somewhere, I believe even on this ML, but I cannot find it anymore. The problem with the old behaviour of 8 bytes is the compatibility: If the 2031/1540/early 1541 (I will summarize them to "2031" in the remaining text) write on a disk that is 4040 formatted, there is no problem. They will just wait the 8 byte after the header and write the block afterwards. No harm will occur. However, if a 4040 writes on a disk that was formatted by a 2031, there is a difference: The SYNC of the 2031 data block has already begun when the 4040 switches from reading to writing. If we assume the RPM is the same between the drives, there are already 16 "1" bits written. Any one, it will be more than 10 "1" bits. Now, if by changing from reading to writing, there is a flow written that will be written as a "0" (because of the timing), then the SYNC stops and a new SYNC begins. Thus, no drive will be able to read that block anymore with standard routines, because it expects GCR data after a SYNC and not another SYNC! "Inside Commodore DOS" even documents this problem. It might look best for Commodore to change the GAP of the 1541 (later models, starting with 901229-03) to 10 byte. However, in this case, early 1541 and later 1541 would have had this compatibility problem between themselves! Thus, Commodore used the 9 byte GAP. This value has the big advantage that it is compatibile with the 4040 format, as well as with the 2031 format! In retrospective, this was a clever decision by Commodore. > As for the gap between end of sector data and beginning of new header sync, > IIRC this was calculated at format time where the drive would basically measure > the length of the sector in bytes (which depends on the speed of the drive as > the bit frequency is fixed) and try to distribute the sectors evenly. That's correct for all (original) formatting routines. In fact, this calculation (and its complicated implementation, using the VIA timers) is the main reason why the original format routines are so slow! Most fast formatters do not even try to calculate the GAP, but just write a hard-coded GAP after each sector. This can be problematic of the disks of these fast formatters are shared between drives that have very different RPM. > To move that out was one of the optimizations I did in my (long forgotten) fast > format routine... With cbmformat and cbmforng (part of OpenCBM), we used a compromise: The first track is measured. Afterwards, every track is written with the GAP that was determined on that first track. There is a verify step afterwards, where we check that the GAP after the last sector is long enough (and, that the next sector we get is indeed the first sector of the track; if not, the GAP was too big and we did overwrite it!) If the expectations do not fit, we measure the GAP enough, using extra rounds. In most cases, however, there is no need for it, and we can just proceed to the next track. At first, we measured the GAP length for every speed zone. Them, WoMo did some calculations and we derived the GAP length from the previous GAP length. So, in most cases, we have to format the first track two times, and every other track only needs one formatting round (plus the next block). However, the result is not completely like the original formatting routine, as the first sector of each track starts after the first sector of the previous track (because we verify the first block of each track). This does not occur if the formatting is done with a verify of each track. In this case, the tracks align more nicely. While we worked on this, we found an interesting artefact that we could not make any sense from. On some drives (not many!), when we formatted the blocks with "00" as contents (like the 4040, 2031 and 1540 does), then the verify of the track failed in some cases! It looked as if the drive has problems with the timing (?) after switching from writing to reading the track. In all cases, if we write the usual 1541-pattern ($4B/$01 for every track but the first one), then this verify problem did not occur. We asked ourselves if Commodore had a similar effect, and if this is the reason why the 1541 changed the empty contents of a block, of if this was just coincidence. Regards, Spiro -- Spiro Trikaliotis https://spiro.trikaliotis.net/Received on 2025-09-28 18:00:12
Archive generated by hypermail 2.4.0.