💾 Archived View for mirrors.apple2.org.za › archive › apple.cabi.net › FAQs.and.INFO › DiskDrives › … captured on 2024-12-17 at 12:55:28.
⬅️ Previous capture (2023-01-29)
-=-=-=-=-=-=-
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: <koch.739483176@sylt>
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 @@@@@@@@@@@@@@@@@@