From: Christer Palm (palm_at_nogui.se)
Date: 2006-01-02 01:51:00
Hi all!
"Inside Commodore DOS" describes the 1541 sector gap calculation
algorithm as simply measuring the actual track length, subtracting the
number of raw bytes needed to store the sectors, and then divide the
available space evenly among the sectors.
However, they go on to say that this is not true for the gap between the
last sector and sector 0, which is much larger. This obviously
contradicts the first (and later) statements about the algoritm.
Calculating the "optimal" sector gap assuming 300 rpm gives roughly:
Zone 1 Zone 2 Zone 3 Zone 4
Track length: 7692 7142 6666 6250
No of sectors: 21 19 18 17
Data bytes: 7413 6707 6354 6001
Spare bytes: 279 435 312 249
Sector gap: 13 22 17 14
This is obviously much larger than the actual values observed by "Inside
Commodore DOS" authors:
Zone 1: 4 - 7 bytes
Zone 2: 9 - 12 bytes
Zone 3: 5 - 8 bytes
Zone 4: 4 - 8 bytes
Which, of course, supports the statement that the final gap is actually
much larger.
OTOH, the documentation for the G64 file format
[http://ist.uwaterloo.ca/~schepers/formats/G64.TXT] also contains a
discussion about the sector gap, arriving at the following table:
Track Range Size Tail Gap MNIB
(bytes) (even/odd sectors) Size
----------- ------- ------------------ ----
1-17 7692 9/9 7692
18-24 7139 9/19 7142
25-30 6666 9/13 6666
31- 6247 9/10 6250
Now, first of all, what the hell does even/odd sectors mean? Does it
suggest that the gap is actually different for odd/even-numbered
sectors, and if so, is that actually so or is it a mistake by the author
or a bug in MNIB?
Assuming the second value is correct, this suggests that the gap is
actually almost twice that of the values given by "Inside Commodore
DOS", and more in line with the "optimal" values. This would also mean
that the "final" gap would, in fact, not be substantially larger than
the others.
In other words - total confusion...
I tried to "decipher" the 1541 format routine to see what's really going
on, but the code is not so easy to follow and its outcome is timing
dependant as well making it even harder to understand exactly how it
works. Now before I try to dig deeper into that, perhaps someone has
already done this already and has information to share?
Cheers,
--
Christer
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.