Re: Re: Re: cbm 1541 drive reading AppleIIe 5.25" disks?

[koch@sylt.informatik.uni-kl.de (Peter Koch - DA Gesmann)]

Hi folks!

Richard Hable writes:
>Thus, some modification of the 1541 to switch off the automatic
>synchronisation detection would be necessary, and of course some
>difficult to write machine language routines in the 1541.

I think there is a more serious problem: The 1541 writes more than
16 sectors (i think 18 and 20) on the outer tracks. This means, it
does a track-dependent recording speed.

But as i remember, it has a 2kbyte RAM for such purposes like patching!

John West writes:
>The tricky bit is sync (is it the same?) and the decoding software. We need
>information on the Apple format for this.

Read "Beneath Apple Dos" from Worth and Lechner for details. From my memory,
the scheme is as follows (errors possible, please flame to /dev/null):

Synchonizing is done by a 10 Bit pattern 0011111111, repeated several
(at least 5) times (the so called sync FF gaps).
The Apple recognizes only bytes with a leading 1 as valid disk bytes.
Therefore a repeated pattern of 0011111111 will allow to self-sync the
reading, wherever in the first sync byte the reading starts:

00111111110011111111001111111100111111110011111111 bit stream
     ^point of start reading (try other poins as well)
     11111001                                      = F9
             11111110                              = FE
                      11111111                     = FF
                                11111111           = FF
                                          11111111 = FF
Notice, how leading zeroes are ignored.
Then a sequence of $D5 AA 96 preceeds the sector header.
It contains Track, Sector, Volume and Checksum in 2:1 encoding.
A trailing $DE AA EB follows.
Then 5 (or more) sync bytes fill the gap to the data portion:
The Data is preceeded by $D5 AA AD and has 342 bytes 6:2 encoded data.
As before, $DE AA EB makes the tail.
After some sync bytes, the next track is found.

So here is a complete track (sync bytes are written as -FF):

-FF
-FF Sector 0 Header sync gap (usually 20 or more sync bytes)
 :
 :
-FF
D5
AA
96
AA track
AA track
AA sector
AA sector
FF volume
FE volume
FF checksum
FE checksum
DE
AA
EB
-FF
-FF Sector 0 Data sync gap (usually 8 bytes)
-FF
-FF
-FF
-FF
-FF
D5
AA
AD
XX \
XX  \
 :   > 342 bytes (6:2 encoded)
 :  /
XX /
DE
AA
EB
-FF
-FF Sector 1 Header sync gap (usually 8 bytes)
 :
 :
-FF
D5
AA
96
AA track
AA track
AA sector
AB sector
FF volume
FE volume
FF checksum
FF checksum
DE
AA
EB
-FF

 and so on...

2:1 encoding is very simple: a byte with bits b0b1b2b3b4b5b6b7 is
splitted in two bytes as follows:
	b0  1 b2  1 b4  1 b6  1		even bits
        b1  1 b3  1 b5  1 b7  1		odd bits
This is done with the following code:
	LDA bits
	ORA #$AA
	JSR writeabyte
	LDA bits
	LSR
	ORA #$AA
	JSR writeabyte

This is also very easy to decode:
	LDA odd bits
	ASL
	ORA even bits
	
6:2 encoding is not so easy:
the 256 bytes are splitted into 342 bytes as follows:
the first 256 bytes contain the first 6 bits of the data
the next 56 bytes contain the other 2 bits (three per byte).
So the 342 bytes contain 6 bits of data, giving 64 possible values.

The Apple Hardware is able to write Bytes meeting the following specification:
1. the fist bit is 1 (see above)
2. after two consecutive zeroes must follow a 1
3. there is at most one pair of consecutive zeroes in the byte

The values 128-255 meet condition 1. Condition 2 eleminates a handfull more.
After Condition 3, there are 67 values left. D5 AA and DE become reserved.
The other 64 are used to store the data. They are looked up via a
translation table.

Peter (koch@informatik.uni-kl.de)
-- 
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Peter Koch, Universitaet Kaiserslautern (AG Haerder, Raum 36/318)
Postfach 3049, D-6750 Kaiserslautern (Germany)
@@@@@@@@@@@@@@@@@@   koch@informatik.uni-kl.de   @@@@@@@@@@@@@@@@@@