From: Spiro Trikaliotis (ml-cbmhackers_at_trikaliotis.net)
Date: 2005-04-22 10:54:35
Hello Ruud,
* On Fri, Apr 22, 2005 at 09:43:01AM +0200 Baltissen, GJPAA (Ruud) wrote:
> Only after ALL sectors have been written, your part shows up by
> writing two extra $55's after the last $55's written by the loop. This
> bit of code isn't used anywhere else, certainly it is not used for
> writing a block to disk as you say.
Yes, I know this. I did not formulate this well.
> I hope this helped :)
Not really. ;-)
Ok, I reformulate:
I am not interested in the inter-sector gaps.
Here is the code from the ROM:
Looking at the "write to disk" DC routine ($F56E), you see the following
code:
.8:f5bf B1 30 LDA ($30),Y ; write the last bytes
.8:f5c1 50 FE BVC $F5C1
.8:f5c3 B8 CLV
.8:f5c4 8D 01 1C STA $1C01
.8:f5c7 C8 INY
.8:f5c8 D0 F5 BNE $F5BF
.8:f5ca 50 FE BVC $F5CA ; (1) make sure the last byte is written
.8:f5cc AD 0C 1C LDA $1C0C ; set read mode again
.8:f5cf 09 E0 ORA #$E0
.8:f5d1 8D 0C 1C STA $1C0C
.8:f5d4 A9 00 LDA #$00 ; data port as input
.8:f5d6 8D 03 1C STA $1C03
Now, the format routine handles the same (writing the last block to disk
and switching to read mode) a little bit differently:
.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
Now, thinking about how the serializer works in a 1541 (for example,
looking at
http://ftp.funet.fi/pub/cbm/schematics/drives/old/2031/page-11r.gif for
the 2031), I think it is the following way:
(1) is the wait for the byte to go into the serializer (U3L), while (2)
waits for the byte to be written to disk, actually, before settingd MODE
to read mode again (and stopping the WRT DATA via U6M). Thus, it seems
in the write routine, this wait is missing. Because of this, the last
byte is only partially written.
Now, why don't we see a problem with that write routine if I am right? I
state that the last (GCR) byte of the block is not necessary at all!
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.
OTOH, we have
$01BB-$01FF (69 byte)
data block (256 byte)
thus, 325 GCR byte are written to the disk per block (which is 260 byte
data).
So, we see that the last two GCR bytes are not needed at all, they are
just some dummy. Because of this, we do not get any read error when the
bytes are wrong.
Anyway, when my formatter tests the track for being correctly written,
it perform a comparison byte-by-byte, stumbling on the last byte not
written correctly to disk.
Any comments? ;-)
Regards,
Spiro.
--
Spiro R. Trikaliotis
http://www.trikaliotis.net/
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.