Re: Question about writing to 1541

From: Nicolas Welte (
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 :/


PS: I CC: this mail to Joe for obvious reasons.

PPS: Spiro, can you change my cbm4win subscription to 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 <-

       Message was sent through the cbm-hackers mailing list

Archive generated by hypermail pre-2.1.8.