From: Nicolas Welte (no_spam_at_x1541.de)
Date: 2005-04-23 10:41:18
Hi Spiro, after your "hint" in the last mail, I started to have a look at these mails. I can't really help with the problem, but maybe add some insight on the extra bytes riddle. Spiro Trikaliotis wrote: > Now, why don't we see a problem with that write routine if I am right? I > state that the last (GCR) byte of the block is not necessary at all! > > > The data block contains: > > - 1 byte $07 (data block marker) > - 256 byte DATA > - 1 byte CKS > > Thus, we have 258 byte, which sums up to 258 / 4 * 5 = 322,5 GCR byte. > > OTOH, we have > $01BB-$01FF (69 byte) > data block (256 byte) > > thus, 325 GCR byte are written to the disk per block (which is 260 byte > data). > > So, we see that the last two GCR bytes are not needed at all, they are > just some dummy. Because of this, we do not get any read error when the > bytes are wrong. The extra bytes aren't just dummies, they actually serve an important purpose. As you know, GCR conversion always takes place in groups of four bytes data, and it yields five bytes GCR code. It's a restriction of how the conversion routines are written if you like, but you have to write data in multiples of four. 258 isn't a multiple, but 260 is. Also, 325 is a multiple of five :) It's right that it doesn't matter at all what is contained in the two extra data bytes, because the data is unused. The same is true for the block header, BTW. It also has two extra data bytes, that usually read $0f I think. One of them actually gets used by Dolphin DOS to mark 40 track disks. So DD knows the disk type as soon as it reads in a block header. I have to dig deeper into the problem, but if you're right that the last GCR byte doesn't get written to the disk completely, I can imagine that this can lead to problems! E.g. Joe introduced a GCR code checking into SC some while ago, and I keep getting extra errors on disks that are otherwise perfectly fine. While most disks read just fine, and others that usually report checksum errors (code 23) in reality have decoding errors (code 24), there are some that have decoding errors in each block, but the data is just fine. So I think that the decoding of the extra filler bytes fails, which isn't a problem at all for the normal DOS, because it simply ignores decoding errors (unlike the older dual drives, BTW!). The idea of the decode checking was to have some extra error detection for weak disks where sometimes, after many retries, the checksum matches just by chance. But even if the checksum matches, you probably still have a decode error. If all this is true, then SC should probably be changed to only check the decoding of the actually used bytes, and forget checking the extra two data or two-and-half GCR bytes. Still I'd like to know what formatters create such "broken" disks. I can't really believe the ROM formatter does this, otherwise much more disks would give these errors. Something that needs to be checked I believe :/ Nicolas PS: I CC: this mail to Joe for obvious reasons. PPS: Spiro, can you change my cbm4win subscription to firstname.lastname@example.org? It's what I use for mailing lists usually. Thanks :) I guess this is why my mails didn't end up on the list lately. -- -> My Commodore hardware projects and the X1541 Shop at http://x1541.de <- Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.