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 no_spam@x1541.de? 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.