Newsgroups: comp.sys.apple2 Path: news.weeg.uiowa.edu!news.uiowa.edu!hobbes.physics.uiowa.edu!moe.ksu.ksu.edu!ux1.cso.uiuc.edu!howland.reston.ans.net!xlink.net!rz.uni-karlsruhe.de!stepsun.uni-kl.de!uklirb!sylt!koch From: koch@sylt.informatik.uni-kl.de (Peter Koch - DA Gesmann) Subject: Re: Re: Re: cbm 1541 drive reading AppleIIe 5.25" disks? Message-ID: Sender: news@uklirb.informatik.uni-kl.de (Unix-News-System) Nntp-Posting-Host: sylt.informatik.uni-kl.de Organization: University of Kaiserslautern, Germany Date: Mon, 7 Jun 1993 19:59:36 GMT Lines: 144 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 @@@@@@@@@@@@@@@@@@