From: Baltissen, GJPAA (Ruud) (ruud.baltissen_at_abp.nl)
Date: 2005-04-22 13:16:34
Hallo Spiro,
> .8:fd1e 50 FE BVC $FD1E ; (1) make sure the last
> byte is written
> .8:fd20 B8 CLV
> .8:fd21 50 FE BVC $FD21 ; (2) write another (!) byte to disk
> .8:fd23 B8 CLV
> .8:fd24 20 00 FE JSR $FE00 ; set read mode and data
> port as input
>
> .8:fe00 AD 0C 1C LDA $1C0C
> .8:fe03 09 E0 ORA #$E0
> .8:fe05 8D 0C 1C STA $1C0C
> .8:fe08 A9 00 LDA #$00
> .8:fe0a 8D 03 1C STA $1C03
> .8:fe0d 60 RTS
> (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). 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.
> 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.
Regarding your error: I'm certain that a disked formatted with one BVC less
is no problem for a real 1541. As you already mentioned yourself, only a
picky byte nibbler will see the difference.
> 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.
If you take these in account, you get your 325 GCR bytes. I couldn't find a
1541 routine that checks these two bytes on the end so IMHO you could write
there anything, as you say, but no guarantee the moment a nibbler is
involved.
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) The answer above applies to
these two bytes as well.
FYI: next week I'm out of town, so now you know in advance why I won't
answer future emails coming after 16:00.
--
___
/ __|__
/ / |_/ Groetjes, Ruud
\ \__|_\
\___| URL: Ruud.C64.org
=====DISCLAIMER=================================================================
De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd voor de geadresseerde. Wanneer u dit bericht per abuis ontvangt, verzoeken wij u contact op te nemen met de afzender per kerende e-mail. Verder verzoeken wij u in dat geval dit e-mailbericht te vernietigen en de inhoud ervan aan niemand openbaar te maken. Wij aanvaarden geen aansprakelijkheid voor onjuiste, onvolledige dan wel ontijdige overbrenging van de inhoud van een verzonden e-mailbericht, noch voor daarbij overgebrachte virussen.
The information contained in this e-mail is confidential and may be privileged. It may be read, copied and used only by the intended recipient. If you have received it in error, please contact the sender immediately by return e-mail; please delete in this case the e-mail and do not disclose its contents to any person. We don't accept liability for any errors, omissions, delays of receipt or viruses in the contents of this message which arise as a result of e-mail transmission.
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.