From: Spiro Trikaliotis (ml-cbmhackers_at_trikaliotis.net)
Date: 2005-05-06 10:44:13
Hello,
* On Fri, May 06, 2005 at 12:35:55AM +0200 Patrycjusz R. ?ogiewa wrote:
> >OTOH, the 4040 used a gap between the data block header and the data
> >block itself of 10 bytes. The 2031 and 1540 (and 1541 up to $E000-ROM
> >version -02) used 8 bytes, while the 1541 (-03, -05 and later) and
> >157x use 9 byte. I believe 8 bytes are critical if a disk is to be
> >interchanged between a 154x and a 4040, as there might be "double
> >SYNC marks", making the data block unreadable. With 9 byte, it is
> >much more unlikely that this happens than with 8 byte.
>
> But... "... note that a header block is never rewritten after
> formatting is complete. The data block of a sector, including the sync
> character, is completely rewritten every time data is written to that
> sector. The [...] header gap is counted off by the DOS to determine
> where to start writing the data block."
Yes, this is wrong. But think about the following layout of a 4040 disk,
which shows the part between the data block header and the data block
itself:
byte: -2 -1 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
content: xx yy 55 55 55 55 55 55 55 55 55 55 FF FF FF FF FF aa bb cc ...
Here, xx yy are the last bytes of the data block header, aa bb cc are the
first bytes of the data block. As the 4040 has written this part, there
are 10 $55, followed by 5 $FF byte. This is immediately after formatting
the disk.
Now, think about what happens if the 2031, 1540 (or 1541-01, -02; I will
call this the the 1540 case) write to this disk:
byte: -2 -1 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
content: xx yy 55 55 55 55 55 55 55 55 FF FF FF FF FF aa bb cc ...
As these disks use only 8 bytes for the gap, the $55 part is just
getting smaller. Everything else is correct.
Now, what if a 4040 writes to this very same disk again? Have a look
here:
byte: -2 -1 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
content: xx yy 55 55 55 55 55 55 55 55 FF FF FF FF FF aa FF FF FF FF FF aa bb cc ...
gap count: 0 1 2 3 4 5 6 7 8 - - - - 9
I added the byte count, that is, how the write mechanism sees this disk
(I assume the byte count mechanics are the same as with the 2031).
The 4040 recognizes the $55 bytes 0-7. The 8th byte, a $FF, is
recognized as a regular byte (a SYNC mark has to be 10 bits of 1, but we
only have 9 up to the first $FF). Anyway, as we are now IN the SYNC
mark, no more S.O. (byte marks are generated until the SYNC mark is
over. Thus, the first data block byte (aa, byte 13) is recognized as 9th
(and last) GAP byte, thus, the 4040 does not start before byte 14, thus,
the 4040 writes its own SYNC mark, starting at byte 14. Of course, as
the byte 13 (aa) is not a $FF byte, we have a double SYNC mark which
makes this disk unreadable afterwards. Furthermore, this block is 6 byte
longer than before (1541 format), or 4 byte longer than before (4040
format), which could potentially overwrite parts of the SYNC mark of the
next sector.
Ok, why doesn't this happen with the 1541-03, -05 (which I will call
1541 in the following) and newer, which write a 9 byte gap?
Have a look again at the disk as it has been written with the 1541:
byte: -2 -1 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
content: xx yy 55 55 55 55 55 55 55 55 55 FF FF FF FF FF aa bb cc ...
You see, there is one more $55 than in the 1540 case.
Now, the 4040 wants to write to this disk:
byte: -2 -1 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
content: xx yy 55 55 55 55 55 55 55 55 55 FF FF FF FF FF FF aa bb cc ...
gap count: 0 1 2 3 4 5 6 7 8 9
Here, the 4040 correctly counts the bytes 0-8, and it still recognizes
byte 9 as a data byte (as no 10 "1"-bits are recognized until then).
Thus, it starts writing its SYNC mark at byte 10, which is exactly where
it would have started its SYNC mark if no 1541 would have been used
in-between. The only difference here is that the SYNC mark is 6 bytes
long now, as byte 9 is the rest of the 1541 SYNC mark.
Thus, this 9 byte gap of the 1541 is much more uncritical than the 8
byte gap of the 1540. Anyway, there is still a chance for problems. The
problem is that going into write mode takes some time. Thus, it could be
that the 4040 emits a 0 bit before it starts writing the SYNC mark. If
this does not occur with the first bit, but with the 2nd bit or later,
than the drive would again have a double SYNC mark:
1. case: first bit is 0. Then we have
55 FF 7F FF FF FF ...
This is not critical, as the last bit of $55 and the 8 bit of the
first $FF only give 9 "1" bits, thus, no SYNC mark is detected.
2. case: first bit is 1, but some subsequent one is "0". Then, we have
55 FF BF FF FF FF ...
or
55 FF DF FF FF FF ...
or
55 FF EF FF FF FF ...
or so on.
Here, the "1" from the last bit of the $55, the 8 "1" bits in $FF and
the first "1" of the next byte result in 10 "1" bits, thus, giving a
SYNC mark. The next "0" then *clears* this sync mark, but there is a
new SYNC mark immediately after (after 1 $FF byte!). Thus, we drive
reads a $FF as first data byte, which makes this disk unusable.
I do not think that this is very likely, but it can happen. Anyway,
chances for problems are MUCH smaller than with the 8 byte gap.
> >Thus, Commodore might have had some problem and tried to solve this
> >by reducing the number of written bytes.
>
> At the off-bytes then? Note also that there is enough buffer at the
> end of the track. The tail gap of the last sector is usually much
> longer than any other (up to 100+ bytes),
I have not checked any disk, but are you sure about 100+ bytes? This
sounds like VERY much for me. My own probing formatter just has a
variance of less than the number of sectors per this track (that is,
less than 21 bytes for tracks 1-17).
Furthermore, it is not only the tail gap of the last sector; it's the
other way around: If the last sector's tail gap is that high, then
the blocks are not written very balanced all over the track, thus,
increasing the probability about one drive writing over the beginning of
the next block if the formatting was done with a very slow drive, but
the new writing drive is very fast.
> OTOH as we all more or less speculate on this then who really knows?
Yes, this is true. Anyway, it IS remarkable that Commodore reduced this
gap by 2 between the 4040 and the 2031, and increased it again by 1
between the 1541-02 and 1541-03. I'm sure there was some reason for it.
BTW: You all know the "wrong" empty sectors of the 1541 disks, don't
you? That is, instead of being all $00, the sectors are $00, $01, $01,
... on track 1, and $4B, $01, $01, $01, ... on all subsequent tracks?
It is interesting that this "bug" was introduced between the 1540 and
the 1541. Thus, the 1540 had the "correct" empty pattern. Thus, to me,
it seems to be a kind of "version information" from Commodore to use
that blank pattern.
Ok, again, this is pure speculation.
Regards,
Spiro.
--
Spiro R. Trikaliotis
http://www.trikaliotis.net/
http://cbm4win.sf.net/
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.