<<Buch, wo die GCR-Kodierung und der genaue Aufbau einer Spur beschrieben
ist? Gerüchteweise hat es irgendwas mit einer 4:5-Umsetzung zu tun, und SYNC
ist $FF>>

Ja, so ungefähr.  5 bits kodieren 4 bits, das Schema ist (in hex):

5 -> 4
--------
09    8
0a    0
0b    1
0d    c
0e    4
0f    5
12    2
13    3
15    f
16    6
17    7
19    9
1a    a
1b    b
1d    d
1e    e

Der Aufbau der Spur war nicht ganz einfach (Header-Markierungen, SYNCs
etc.); ich wußte das alles mal ganz genau, kann aber meine Notizen gerade
nicht finden. (Die GCR-Dekodierung weiß ich nur so genau, weil ich im
letzten Jahr einen Dekodierer für ZipCode "SixPack" Diskimages schreiben
mußte, und diese SixPack-Images sind in GCR...)

Ich glaube, daß die Dokumentation zum Diskeditor "Disk-Demon" einiges zum
Spuraufbau enthält (war auch mal in der 64er, 1987 glaube ich).  Bei Bedarf
kann ich sie vorbeischicken.

-- David


Ach ja, die Floppy-Specs.  Komischerweise steht das in meinem "großen
VC1541-Buch" (S. 190-215) alles mehr oder weniger drin (Du hast vielleicht
eine neuere Ausgabe).  Das wesentliche:

Spur = Sektor + Sektor...

Sektor = Block Header + GAP1 + Data Block + GAP2
 
Block Header:  5 SYNCs ($ff = %1111.1111) + 10 bytes Header-Info (GCR!)

GAP1: 8 GAP-Bytes ($55 = %0101.0101)

Data Block:  5 SYNCs (s.o.) + 325 bytes Data (GCR!)

GAP2:  4-12 GAP-Bytes (s.o.)

Die GAP-Zahlen muß ich noch verifizieren (GAP1 war in einer 64er mit 9 bytes
angegeben, und für GAP2 habe ich auch schon einmal etwas von 8-16 gehört.
In jedem Fall richtet sich GAP2 nach der gemessenen Länge der Spur.)

Die einzigen Informationen, die im GCR-Code vorliegen und (5 -> 4 bits)
dekodiert werden müssen, sind Header-Info und die eigentlichen Daten.  Im
einzelnen:

Header Info (10 byte -> 8 byte):
Header-Block-Kennung ($08) + AND-Checksum "über alle Bytes" (d.h. vermutlich
über bytes 3-8) + Sektor-Nummer + Spur-Nummer + ID2 + ID1 (ID1&2 sind die
beim Formatieren angegebenen Werte) + 2 Füllbytes ($0f)

Data (325 -> 260 byte):
Data-Block-Kennung ($07) + 256 Daten-Bytes + XOR-Checksum "über alle Bytes"
(d.h. vermutlich über alle Daten-Bytes) + 2 Füllbytes ($00)

Das wärs.  Interessant ist vielleicht noch, daß ein 100%ig komplettes
GCR-Disk-Image (mit dem alle Kopierschutztricks machbar sind) ziemlich groß
werden dürfte (ca. 2 MB):  Man braucht den Inhalt aller Spuren (und das sind
über 80, da der Steppermotor sich ja in Halbspurschritten bewegt), man müßte
jede dieser >80 Spuren in den 4 möglichen Geschwindigkeiten auslesen (80 * 4
= 320), und außerdem müßte auch die exakte Lage der Spuren zueinander
vermessen werden...  Viel Spaß <g>! 

-- David
