From: Patrycjusz R. Łogiewa (silverdr_at_inet.com.pl)
Date: 2005-05-08 13:16:34
On 2005-05-07, at 10:36, Spiro Trikaliotis wrote:
[...]
>>> 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.
>
> Well, "bigger" gap does not mean that one has to be 100+ bytes long.
It was said to be "much bigger, so much as to even exceed 100 bytes
from time to time".
>
>
>> 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.
>
> Well, the arguments I showed in another mail where for ONE drive. These
> arguments were not meant for different drives.
After I posted the message, I knew you were going to catch me here ;-)
>
> Let's calculate the length of a track in bytes. As I am lazy, I'm just
> quoting from a mail of WoMo here. I came to the same formula
> independently from him, so it is just for the sake of not writing too
> much that I quote him, not that I did not follow the formula: ;-)
[...]
>
> With this, you see why a probing formatting routine is very important
> if
> you want to share disks between different drives.
And I knew I should have done the calculations myself but I was too
lazy... and hoping that somebody did it already ;-)
>>> 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... ;-)
>
> Yes. Interesting, the 1540 and 2031 ROM have a NOP ($EA) there, while
> even the 1541-01 ROM has the INX. Interesting: INX ($E8) and the NOP
> differ in only one bit.
>
>> At least the 1541 leaves its clearly distinguishable mark on the disk
>> ;-)
>
> Yes, I believe this was the intention of this change.
Huh, that would (more or less) mean that they intentionally kept the
NOP placeholder there "just in case" when the ultimate drive (they
decide to) should stamp its mark. I think I would rather tend to
believe it was a kind of debug output, which normally was changed in
the final stages but got forgotten and went to production, or a kind of
"merge-in" artefact from different development versions. But... who
knows? BTW. The guys who coded those should still be somewhere among
us. Isn't there any chance finding them so that we could just ask? They
should still be able to remember some things.
--
What's the difference between a bad golfer and a bad skydiver?
A bad golfer goes: Whack, "Damn!"
A bad skydiver goes: "Damn!" Whack!
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.