Re: Question about writing to 1541

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.