From: Greg King (gngking_at_erols.com)
Date: 2005-05-05 08:45:02
From: Spiro Trikaliotis; on Date: April 27, 2005, at 02:14 AM -0400
>
> * On Tue, Apr 26, 2005 at 06:16:15PM +0200, Patrycjusz R. ?ogiewa wrote:
>
> > It has the same double BVCs in question but of course I can't really
> > explain why is this needed. Since I am now also up to similar matters
> > (I am trying to adapt some software to work with DD3), I can only add
> > my voice to the chorus, "can someone explain that?"
>
> From discussions here, on another ml, and via PM, I am sure that the
> first BVC is for being sure that the byte has been latched into the
> shift register, while the second BVC is for being sure that the byte has
> been shifted out of the shift register.
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.
>
> Thus, the write routine in the ROM is wrong, but it does not do any harm
> since the read routine does not check the last bytes, at all.
>
> > [snip]
>
> ... In fact, calculating
> the inter-block gap is the most interesting part for me now. If that gap
> is chosen wrong, there may be problems using a disk, formatted on one
> drive, on another drive.
From: Spiro Trikaliotis; on Date: April 27, 2005, at 02:24 AM -0400
>
> * On Tue, Apr 26, 2005 at 12:31:38AM +0200, fachat wrote:
>
> > Now, if always the same data is written to disk (at the end of the
> > block), it is not important when the write stops, because the data is
> > already on the disk, from the previous write.
>
> I tend to disagree here. Doing some tests, I found out that my own drive
> starts to spin faster the longer it runs. Furthermore, using a disk, from
> one drive, on another drive with a very different rotational speed will
> increase the problem much.
>
> > ... [snip] ...
>
> The ROM formatter does it correctly -- it is the ROM "write block" job
> routine that does it wrong. :-(
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."
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.