From: Spiro Trikaliotis (ml-cbmhackers_at_trikaliotis.net)
Date: 2005-05-05 19:59:44
Hello Greg,
* On Thu, May 05, 2005 at 02:45:02AM -0400 Greg King wrote:
> Another way to describe it is: There are two registers (VIA, shifter)
> in the pipeline between the code and the disk. So, two "bvc *"
> spinlocks are needed, to wait for the last byte to go all the way
> through that pipe.
Ok, this is another way to explain the same.
> Those comments suggest a possible answer to the original question:
>
> Maybe, the original "sector write" routine ended with the same code that
> the formatter routine still has. But then, maybe, CBM's engineers noticed
> that the end of a sector sometimes would overlap the beginning of the next
> sector far enough to confuse the drive's attempt to syncronize to that next
> sector. So, maybe they fixed that problem by changing the "sector write"
> routine:
> 1) It no longer writes the last GCR code; and,
> 2) it disables the write-circuit as soon as possible.
>
> If my speculation is true, then the routine isn't wrong; it simply has been
> "curtailed."
Well, this could be. Perhaps, we could deduce that if we compared with
the write routines of the older drives.
Anyway, the following might be some arguments in this area.
The formatter tries to put the sectors very balanced around the track.
For the worst speed zones, we have an inter-sector-gap of at least 6
bytes (from experience). I have been told (I did not check myself) that
approx. 5 bytes per round is the normal jitter of belt-driven 1541
drives.
Thus, per sector, the jitter is lower than 1 byte. Thus, we have 4 extra
security bytes between each sector. Thus, I doubt your argument.
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.
Thus, Commodore might have had some problem and tried to solve this by
reducing the number of written bytes.
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.