From: Spiro Trikaliotis (ml-cbmhackers_at_trikaliotis.net)
Date: 2005-04-22 14:27:33
Hello Ruud,
* On Fri, Apr 22, 2005 at 01:16:34PM +0200 Baltissen, GJPAA (Ruud) wrote:
> > (1) is the wait for the byte to go into the serializer (U3L), while
> > (2) waits for the byte to be written to disk,
>
> Nope. The byte placed on $1C01 is written to disk (when in write mode
> of course, which is the case here).
Yes, this is what I thought before, too. ;-)
> The only thing that happens is that the Overflow flag is set after the
> last bit has been written to the disk. So if the processor doesn't
> react, the byte will be written again and again and again until the
> CPU either changes the byte or changes the mode.
This is known to me.
> > Unfortunately, I do not understand this. Can anyone explain me why I
> > need two "BVC *" in the formatting case, but only one in the writing
> > case?
>
> Because, IMHO, you are comparing apples with pears. The equivalent of
> the routine at $F5BF for the formatting part can be found at $FCF7.
> The routine at $FD1E that you mention, is only used once at the end of
> a track. Certainly NOT for for formatting a sector/block.
Of course it is the end. I am comparing the switching from write to read
mode, which is different. Thus, I am not comparing apples with pears,
but apples with apples. ;-)
AFAIK, these two places are the only places where switching from write
to read mode is done, so, I do not have anything to compare this to.
> Regarding your error: I'm certain that a disked formatted with one BVC
> less is no problem for a real 1541.
Yes, from what I found out, it is no problem for a 1541 or 1571 trying
to read that block back.
Anyway, it is a problem if you do a (raw GCR) byte-by-byte compare after
writing the track.
I put the sources for my formatter online
(http://www.trikaliotis.net/download/cbmformat-20050421.zip).
The critical point is DtaByt4. If I leave this out (without verify), the
disk is readable for the 1541. Anyway, if I activate verify, the verify
fails. It does not fail if DtaByt4 bvc DtaByt4 is in place.
Now, test it and restate your above statement. ;-)
> As you already mentioned yourself,
> only a picky byte nibbler will see the difference.
The 1541 does not see a difference as it ignores the two extra bytes at
the end of each block.
> > The data block contains:
> >
> > - 1 byte $07 (data block marker)
> > - 256 byte DATA
> > - 1 byte CKS
> >
> > Thus, we have 258 byte, which sums up to 258 / 4 * 5 = 322,5 GCR byte.
>
> You forget to mention the two $00 bytes following the 1 byte checksum CKS.
Now, I wanted to tell that there *are* two additional bytes. ;-)
> The confusing part is that I now think that you think there is a link
> between these last two bytes and the routine at $FD1E. (I hadn't that
> impression when answering the original email)
No, I do not think that these two BVC are there for specifically writing
these two bytes. They are just there to make sure all 325 (GCR) byte are
written to the disk. Coincidentially, the last bytes of the 325 (GCR)
bytes are the coded equivalents of the Null-bytes.
What I want to say: The "write" routine inside the DC only writes 324
(GCR) byte (possibly, plus some bits), not all 325 byte. Thus, the last
(GCR) byte can be wrong, but this does not do any damage to the reading
of the sector.
From my oversations, IMHO, the 1541 write routine for writing a block is
wrong, but it does not do any harm.
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.