From: Spiro Trikaliotis (ml-cbmhackers_at_trikaliotis.net)
Date: 2005-04-27 08:24:36
Hello André,
* On Tue, Apr 26, 2005 at 12:31:38AM +0200 fachat wrote:
> First: the double "BVC *" occurs at the end of formatting a track.
> The bytes written before are #$55, so it just means that the gap
> has a length of one more byte than calculated.
[...]
Thank you for your explanation which tells me my own analyzes was
correct. :-)
> 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.
> [The byte timing is determined by the SYNC pulse.Shifting starts when
> the SYNC pulse stops - maybe. Just had a look at the schematics again,
> but didn't see how it should work, Don't have my TTL docs at hand....]
You're right. Looking at the 2031 schematic:
If a SYNC is detected by U2L, U5L pin 11 is low, thus, the bit counter
is loaded with 0, effectively stopping it as long as the sync pulse is
there.
OTOH, if READ DATA is 1, than U2M pin 10 goes load, setting U5M pin 11
to low, thus, performing a LOAD (and effectively stopping U5M from
counting).
> > GCR byte doesn't get written to the disk completely, I can imagine
> > that this can lead to problems! E.g. Joe introduced a GCR code
> > checking into SC some while ago, and I keep getting extra errors on
> > disks that are otherwise perfectly fine. While most disks read just
> > fine, and others that usually report checksum errors (code 23) in
> > reality have decoding errors (code 24), there are some that have
> > decoding errors in each block, but the data is just fine. So I think
> > that the decoding of the extra filler bytes fails,
>
> This may be because the timing difference between the write clock and
> read clock was too large.
Joe told us that SC does not check the unused bytes. Thus, it is
unlikely that this is the problem.
> > Still I'd like to know what formatters create such "broken" disks. I
> > can't really believe the ROM formatter does this, otherwise much
> > more disks would give these errors. Something that needs to be
> > checked I believe :/
>
> Indeed. This is an interesting problem.
The ROM formatter does it correctly - it is the ROM "write block" job
routine that does it wrong. :-(
Anyway, as I told, as these bytes are never tested on the 1541, this is
no problem with neither the original ROM, nor SC.
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.