From: Patrycjusz R. Łogiewa (silverdr_at_inet.com.pl)
Date: 2005-05-06 19:59:46
I intentionally left the quoted text uncut...
On 2005-05-06, at 10:44, Spiro Trikaliotis wrote:
> 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.
I read through this explanations and they seem really cogent. The
question remains if you have really verified this? I believe that we
would have to take down the bit images of the 4040 and 1541 (according
to your terminology) tracks freshly formatted and then cross-rewritten
and compare it this way. This would be something that I am tending to
believe the "incomdos" authors did and they have somewhat similar, yet
different explanations, starting from p. 208. Yet it seems to me
unlikely (speculation) that people at CBM have cut off last BVC from
the sector write routine (the thing we started with ;-) to improve
compatibility with 4040.
>
>>> 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?
Again - to be sure I would have to take the bit image, which I didn't
but I quoted the same source, which I thought to be reliable.
> 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).
Yes, with the fast formatters we don't really use the same, universal
and slow algorithms ;-)
>
> 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,
Yes. There is supposedly a bigger gap at the end of 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.
Well, such situations _will_ happen if the drive(s) are misadjusted but
I think they have put enough buffer (as you calculated yourself) to
cover the regular, acceptable deviations in drives' speed anyway. If
that doesn't prove to be enough (since the drive exceeds the acceptable
limits) then the drive needs servicing anyway.
>
>> 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.
AFAIR it was 9 GCR bytes vs. 8 non-GCR, with the actual bit patterns
taking even more for some reason - interesting for what reason though.
It would have to be verified if that was indeed changed _twice_ as you
suggested. Don't have resources at hand to verify 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?
Yes. There is one INX too much at $FC86, which both increments the
value passed to A by one (hence $01) and skips the first byte when
writing to the buffer later on (hence the first byte different). Some
ages ago, I recall wondering what did they have in mind to make it this
way... ;-)
> 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.
At least the 1541 leaves its clearly distinguishable mark on the disk
;-)
--
"*Note SIGINT* is not supported for any Win32 application including
Windows NT and Windows 95. When a CTRL+C interrupt occurs, Win32
operating systems generate a new thread to specifically handle that
interrupt. This can cause a single-thread application such as UNIX, to
become multithreaded, resulting in unexpected behavior." -- MSDN
Library Visual Studio 6.0; signal()
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.