Make your own free website on Tripod.com
zurück : weiter  : inhalt =
 
 

 3.6 *** Übertragungsprotokolle

Für die Datenübertragung zwischen den verschiedenen Systemen Floppy oder Hard Disc gibt es eine Vorlage zur Standardisierung von Sinclair Research. Danach hat sich beim QL für Discetten in 5 1/4 " und 3 1/2 " ein Quasistandard etabliert. Nichts steht dem entgegen, diesen auch für andere geeignete Datenträger zu verwenden. Für die Microdrives gibt es ein besonderes Protokoll der Datenübertragung, für das Netzwerk ein Weiteres. Auch die Datenträger anderer Geräte, Draht und selbst Lochstreifen, wären geeignet. Die Standardisierung ist das ordnende System auf solchen Datenträgern. Unterschiede in den Verfahren sind begründet durch das unter den gegebenen physikalischen Bedingungen Erreichbare und hier völlig uninteressant. Bedingung ist nur, daß sie die angegebene Ordnung erlauben.
 

3.6.1 ** Floppy Disc

Die ursprüngliche physische Struktur ist dem IBM System 34 entlehnt (8" MFM):
Im Unterschied dazu fehlt beim QL die Index-Markierung, Flag für die Sectorlänge ist $02, der Datenanteil darin hat die Länge 512, und der Sicherheitsabstand zwischen den Sectoren wurde von 54 auf 84 Bytes vergrößert. Physische Sectorlänge ist damit 658 Bytes, die einer Spur mit 9 Sectoren 6250 Bytes, darin enthalten 328 Bytes als zusätzlichem Sicherheitsabstand. - Was bei präzisen Laufwerken und ordentlichem Datenträgermaterial z.B. ohne weiteres auch 10 Sectoren/Spur erlaubt.
 
Es erfolgt, zunächst nur begrifflich, die Einteilung einer Floppy Disc in Sectoren, Spuren und Seiten. Physisch können sie in völlig anderer Weise geordnet sein; dies wird vom Device Handler geeignet verwaltet.

Die Floppy Disc hat Sectoren zu gewöhnlich je 512 Bytes. Je nach Möglichkeiten der Geräte sind z.B. 80 Spuren eingerichtet. Auch geräteabhängig gibt es beispielsweise 2 Seiten. Und bei der Flopyy Disc wirklich nur als Begriff existiert der Cylinder mit je einer Spur pro Seite. Spuren und Seiten zählen ab 0, Sectoren je Spur ab 1. Bei einer 3 1/2 " Disc mit 80 Spuren zu je 9 Sectoren auf zwei Seiten ergibt sich die Kapazität von 720K Bytes.

Für alles Weitere werden hier nun die Gegebenheiten eines solchen Laufwerks vorausgesetzt.

Es folgt die Darstellung der Organisationsstruktur und der Möglichkeiten, mit Hilfe der aufgezeichnenten Daten die Discette vollständig zu lesen oder zu beschreiben. Damit ist der direkte Zugriff unter den beim QL üblichen Übertragungsmodalitäten uneingeschränkt möglich.

Sector Map - Verteilungsplan

Unabhängig von der Formatvariante steht in Spur 0, Sector 1 auf Seite 0 der Verteilungsplan. Dort wird neben Daten, die die besonderen Gegebenheiten kennzeichnen, notiert, wie die Aufzeichnungseinheiten der Discette verteilt worden sind. Neben der elementaren Sectorgröße, neben der nicht immer eindeutigen u.g. Formatidentifikation ("FMTID") im QDOS noch mit Hilfe der Daten-Relationen geprüft werden kann, die FS.MDINF und FS.XINF liefern, brauchen keinerlei Strukturdaten "gewußt"zu werden!
Ein Beispiel gibt das Programm "RecoverQ", bei dem sämtliche Daten aus dem jeweiligen Datenträger gelesen werden, und mit dessen Hilfe sich auch unkonventionell formatierte Discetten lesen, reparieren und copieren lassen.

Die ersten 96 Bytes beschreiben das benutzte Gerät und die Aufzeichnungsmethode:
 

Name Posn Fmt Verwendung z.B.
FMTID 00 Format-Identifikation QL5A
MDNAM 04 .b auf 10 Bytes aufgefüllter Name des Datenträgers name
mdrnd 14 .w beim Formatieren eingetragene Zufallszahl 12345
MDUPD 16  .w Anzahl erfolgter Datensendungen 1
  18 .w    
MFREE 20 .w Anzahl freier Sectoren 1434
MGOOD 22 .w Anzahl brauchbarer Sectoren 1440
MTOTL  24 .w Anzahl sämtlicher Sectoren 1440
MSTRK  26 .w Sectoren je Spur (einer Seite) 9
MSCYL 28 .w Sectoren je Cylinder (alle Seiten einer Spur) 18
MTRAK 30 .w Anzahl Spuren 80
MALLC 32 .w Sectoren je Zuweisungseinheit 3
MEODR 34 .w letzter ganzer Sector des Directory-File 0
  36 .w letztes Byte im folgenden Sector 64
MSOFF 38 .w Sectorsprung zur folgenden Spur 5
MLGPH 40 18.b Umsetzungstabelle logisch -> physisch s.u.
MPHLG 58 18.b Umsetzungstabelle physisch -> logisch s.u.
  76 20.b Reserve  
 
Diesen Daten folgt unmittelbar der Verteilungsplan für die Sectoren, gruppiert in oben definierten Zuweisungseinheiten, hier identisch mit den Datenblöcken aus je drei Sectoren. Bei drei Sectoren je Block und 1440 Sectoren je Discette kann über 480 Orte, zugleich Blöcke, buchgeführt werden. Das geschieht mit Hilfe der auf den Header folgenden 1440 Bytes.

Die Format-Identifikation ist ein vier Bytes langer Eintrag, der anzeigt, daß die Aufzeichnung in der hier beschriebenen Form erfolgte. Name, Zufallszahl und Zähler der Aufzeichnungsvorgänge sollen die Kontrolle über einen womöglich erfolgten Tausch der Datenträger erleichtern. Weiter läßt sich damit auch überprüfen, ob der Datenträger zwischendurch anderweitig bearbeitet wurde.

Die anderen Daten dienen der einfachen Durchführung von Operationen zum freien Zugriff auf beliebige Stellen der Discette. Sie sollen die Berechnungen, auch beim Umgang mit dem Directory, beschleunigen helfen. und, um für die Zukunft auch Erweiterungen zu erlauben, von "gewußten" Daten unabhängig machen.
 

Sectorenvergabe

Files erhalten Platz auf der Discette in Vielfachen des Zuweisungsformats, das hier aus den drei Sectoren eines Blocks besteht. Damit der Zugriff möglichst schnell erfolgen kann, sind diese mit gewissen Zwischräumen angeordnet, deren Ermittlung in den Umsetzungstabellen unterstützt wird. Für den Übergang auf eine anderen Spur ist Zeit erforderlich, die dem Laufwerk durch den Sectorensprung gegeben wird, einem weiteren Offset.

Der Verteilungsplan liefert die logische Sectornummer :

(Sector im Plan * Zuweisungsformat + Sector in der Zuweisungsgruppe) MOD Sectoren je Cylinder

In der ersten Umsetzungstabelle, logisch nach physisch, steht im höchstwertigen Bit die Seitennummer, der Sector in den verbleibenden Bits. Aus praktischen Gründen zählen beide ab Null. Die zweite Tabelle, physisch nach logisch, gibt die Zuordnung für die einzelnen Sectoren eines Cylinders an. Sie soll nur die Positionsberechnungen erleichtern, notwendig ist sie nicht, weshalb sie auch bei den Formaten höherer Dichte (QL5C, QLWA) fehlt.

Auch hier werden Seiten wie Sectoren ab Null gezählt. Mit Schachtelung der Sectoren in Blockgröße ergibt sich etwa:

MLGPH : 00 03 06 80 83 86 01 04 07 81 84 87 02 05 08 82 85 88
MPHLG : 00 06 0C 01 07 0D 02 08 0E 03 09 0F 04 0A 10 05 0B 11
Vorgabe für den Sectorensprung von Spur zu Spur ist Fünf. Alle diese Daten können innerhalb sinnvoller Grenzen frei verändert werden. So ist es etwa auch möglich, ganz ohne Verschachtelung zu formatieren, und nur einen geringen Sectorensprung, etwa drei, einzuführen. Dies kann die Übertragung langer Files ganz wesentlich beschleunigen. Mit den Befehlen des TK2 genügt dazu ein einfaches Basic-Programm, das nach dem standardmäßigen Formatieren nur diese beiden Tabellen und die Eintragung MSOFF justiert:
 
 
f=FOPEN('flp1_*d2d') Discette als File
GET#f\1,e$ Directory-Header
e$(39)=CHR$(0):e$(40)=CHR$(3) MSOFF Sectorensprung
FOR n=41 TO 49:e$(n)=CHR$(n-41) MLGPH Seite 0 
FOR n=50 TO 58:e$(n)=CHR$(78+n) MLGPH Seite 1 
FOR n=59 TO 76:e$(n)=CHR$(n-59)  MPHLG ganze Tabelle
PUT#f\1,e$ eintragen 
CLOSE#f fertig
 
TK2 und Basic verarbeiten diese neue Anordnung völlig problemlos, auch LV2 mit Gold-Card und MGG.

Der Physische Sector ist nun mittels der Umsetzungstabelle auszurechnen:

(umgesetzter Sector + Spur * Sectorensprung) MOD Sectoren je Spur
Im Verteilungsplan wird die Verwendung eines jeden Blocks mit 24 Bits angegeben:
Bits 0 bis 11 Die Nummer des Blocks im File.
Bits 12 bis 23 Die Filenummer
 
Manche Filenummern haben besondere Bedeutung:
 
$000   Reserviert für das übergeordnete Directoryfile
$0xx - $6xx Reguläre Files (bis max. Blockanzahl)
$F8x -8.. Sectorenplan
$FDx -3.. Freie Sectorengruppe (freier Block) 
$FEx -2.. Unbrauchbarer Block
$FFx -1.. Nicht vorhandener Block
 

Das übergeordnete Directory ist aus File-Headern in der üblichen Anordnung mit je 64 Bytes Länge zusammengefügt. Darin wiederum können andere Directory-Files verzeichnet sein, die "Subdirectories". Das File mit der Nummer Null ist das Directory selbst, das keinen Eintrag in seiner eigenen Datei hat. Das zugehörige Feld bleibt frei, ggf. darin vorhandene Daten werden nicht berücksichtigt.
 

Standard-Aufzeichnungsformate:
 
 

Format   DD HD ED
Kennung QL5A QL5B QL5C
Spuren 80 80 80
Sectorenlänge Bytes 512 512 2048
Sec/Spur 9 18 10
Sec/Cyl 18 36 20
Sec/Block 3 3 1
Umsetzungstabelle Bytes 18 36 20
Sector Map Bytes 1440 2880 4800
Eintragungen 480 960 1600
Map-Länge Sec. 3 6 3
Direktzugriff mit *D2D *D2H *D4E
Sectorensprung Sec. 5 5 2
 
"Bad Medium"-Fehler (-16) beim Direktzugriff mit ungeeignetem Namen.
Die zweite Umsetzungstabelle entfällt bei 'D4E', rsp. bleibt ungenutzt.

Die Basic-Aufrufe WSTAT etc. liefern Werte, die auf die Sectorenlänge von 512 Bytes bezogen sind, sodaß der Vergleich zwischen den verschiedenen Format-Typen möglich ist.

Die Datenanordnung im Media-Header erlaubt auch freie Formate, z.B. QL5B mit 20 Sec./Spur bei 4 Sec/Block für 3200 Sectoren entspr. 1,6MB Daten. Dieses Format wird jedoch bei FS.LOAD und FS.SAVE nur in MINERVA und (im allgemeinen) SQ fehlerfrei ausgewertet - da müssen dem Entwickler des QDOS doch glatt seine eigenen(?) Tabellen entgangen sein...
 

Direktzugriff

Die Erweiterungen des TK2 erlauben auch den Direktzugriff mit der Adressierung einzelner Sectoren, wobei als Fileposition den betreffenden Qdos-Traps das Ergebnis folgender Berechnung mitzugeben ist:

Spur * 65536 + Seite * 256 + Sector + 1
Dabei alle Angaben ab Null zählend. Die Längenangabe ist ggf.:
 
len zum Lesen eines Sectors
2 zur Ermittlung der Sectorlänge (z.B. len=512 bei d2d) - { Wert nur bedingt von Nutzen. }
len+2 holt Sectorlänge und Inhalt als String oder sendet den Sectoreninhalt

Die o.a. Längenermittlung ist allerdings gänzlich wertlos, wenn daraus etwa der wirkliche Discettentyp abgeleitet werden soll, denn sie gibt nur das wieder, was mit dem Namen dem vom Discettentypen unabhängigen OPEN übergeben wurde, also ohnehin schon bekannt ist. Typerkennung ist nur durch Ausprobieren möglich und kann wegen der möglicherweise vielen internen Fehlversuche u.U. sehr langwierig sein.

Es werden nur die Traps zum Lesen und Schreiben eines String bedient, sowie die relative und absolute Positionierung des Filepointers.
Weitere Kanäle auf ein direkt geöffnetes Laufwerk lassen sich nicht einrichten, jedoch kann das betr. Laufwerk jederzeit FORMATiert werden (nicht probiert)!
Die direkten Kanäle erlauben in allen OPEN-Varianten immer auch das Schreiben.

Beim Zugriff auf mit 40 Spuren formatierte Discetten ist die Nummer der Spur jeweils doppelt zu zählen. Dies ist offenbar aber nur mit dem QL selbst möglich, nicht bei den Atari-QL-Systemen oder mit SQ {15}.

Ein Beispiel:
Mit folgender kleinen Procedur kann im Direktzugriff sehr einfach das genaue Abbild einer beliebigen Discette erzeugt werden, sofern ihre Aufzeichnungstechnik der des IBM-Vorbildes entspricht (z.B. QDOS, *WeichDOS, Atari) und das Ziel in derselben Weise formatiert ist, wie die Quelle. Dabei ist es belanglos, ob einzelne Sectoren als "schlecht" oder "nicht vorhanden" etc. gelten. Etwa läßt sich zum Auffrischen überalterter Originale (allein das Magnetfeld der Erde schwächt die Aufzeichnungen so, daß sie schon nach ca. 10 Jahren unbrauchbar werden können) oder Anlegen von Sicherungscopien ein blödsinniger "Copierschutz" in Gestalt "schlecht" markierter Blöcke oder verkürzt formatierter Discetten hiermit unwirksam machen.

Das Verfahren ist zwar langwierig (ca. 10 Min. für eine DD-Discette), doch es ist sicher. Nur bei physischen Schäden am Datenträger scheitert die Übertragung der betroffenen Sectoren.

Bekannt, rsp. wie oben beschrieben ermittelt, seien Dichte-Typ, Anzahl Spuren ("tracks"), Seiten ("sides", 0 für "single") und Sectoren ("sectors") pro Seite:

tracks = 80
sectors = 9
sides = 2
 
i = FOPEN ("flp1_*d2d")
o = FOPEN("flp2_*d2d")
 
FOR t=0 to tracks-1
  s = 0
  REPeat r
   FOR c=1 to sectors : a = 65536*t+s+c : GET#i\a,sec$ : PUT#o\a,sec$
   IF sides = 0 : EXIT r : ELSE IF s : EXIT r : ELSE s=256
  END REPeat r
END FOR t
 
CLOSE#i,#o

 

3.6.2 ** Hard-Disc der QXL

Grundsätzlich gilt das zur Floppy beschriebene auch hier. Allerdings haben die Strukturdaten und die Sector-Map einen völlig anderen Aufbau, und die Verweise auf die Files sind anders organisiert.

Der Header zur Laufwerksbeschreibung ist 64 Bytes lang, daran schließt sich die Block-Map an. Dort sind die zunächst fortlaufend durchnumerierten Blöcke von der Größe je einer Zuweisungseinhait mit der Nummer des jeweils nächsten Blocks verzeichnet. Die eigene Blocknummer enstpricht der relativ zu ihrem Anfang gezählten Postennummer in der Block-Map. Werden die Blöcke später durch Files belegt, markiert eine Null anstelle der letzten Blocknummer das File-Ende.
Die Blocknummern sind zugleich Index in den Datenträger (s.u.).

Leere Blöcke sind mit besonderen Datensätzen gefüllt, die beim Formatieren erzeugt wurden. Sie weisen gewisse Ähnlichkeit zu *DOS-Bootsectoren auf; Details, oder ob diese Daten überhaupt von Belang sind, bleiben aber mangels Dokumentation im Dunkeln.
 
Die Zahlenbeispiele sind einer 10MB QXL.WIN entnommen

Name Posn Fmt Verwendung z.B.
FMTID 00   Format-Identifikation QLWA
MDNAM 04 .w+.b count.w + max. 20 Zeichen Datenträgername name
  26 .w nicht besetzt 0
qwrnd 28 .w beim Formatieren eingetragene Zufallszahl 52364
qwupd 30  .w Anzahl erfolgter Datensendungen 1159
qwoff 32 .w Schachtelung 0
qwallc 34 .w Azahl Sectoren je Zuweisungseinheit 4
qwsect 36 .w Anzahl Sectoren je Spur 0
qwtrkc 38 .w Anzahl Spuren je Cylinder (Anzahl "Köpfe") 0
qwcyld  40 .w Cylinder/Köpfe des Laufwerks 0
qwgrpn 42 .w Anzahl Zuweisungseinheiten 5120
qwgrpf 44 .w Anzahl freier Zuweisungseinheiten 1685
qwmsec 46 .w Sectoren je Map (Partition?) 0
qwmapn 48 .w Anzahl Maps (Partitionen?) 0
qwfree 50 .w Nummer der ersten freien Zuweisungseinheit 3426
qwroot 52 .w Blocknummer des Basisdirectory 6
qwrlen 54   Filelänge des Basisdirectory ("root-dir.") 6592
qwcyl1 
qwsec1
58 .w 
.l
Nummer des ersten Cylinders, oder 
erster Sector der Partition
0
qwpark 60 .w Park-Cylinder 0
Dank für die akribische Ermittlung dieser Strukturdaten gebührt Gerhard Plavec.

Man öffnet die QXL-WIN-Devices zum Direkzugriff wie eine DD-Floppy, und adressiert auch ihre Sectoren in derselben Weise. Da aber Seiten und Spuren hier nicht gezählt werden, erübrigt sich die Berechnung und es genügt die Angabe der Sectornummer.

Es soll beispielsweise ein File "WIN1_boot" aufgesucht werden.

Dazu öffnet man den Kanal "win1_*d2d" und sucht das "root-directory" auf. Dessen Anfangsblock steht in QWROOT. Die Adresse seines ersten Sectors ist

(qwroot)*(qwallc)
Die Fileposition eines jeden einzelnen Eintrages darin ist
eintragnummer*64
Mit den (einzigen) als bekannt voraussetzbaren Zahlen für Sectorgröße (512) und der Länge eines Directory-Eintrags (64) gilt dann allgemein für die Adressierung
sector = INT( eintragnummer*64 / 512 )
position_im_sector = eintragnummer*64 MOD 512
block = INT( sector / qwalc )
sector_im_block = sector MOD qwallc
woraus sich successive der jeweils nächste Directoryeintrag ermitteln läßt.

Hat nun den Eintrag mit dem Namen "boot" gefunden, und ist auch der Zähler für die Länge des Filenamen richtig angegeben, ist der gesuchte Fileheader gefunden. Dort an Position 58 steht die Nummer seines ersten Datenblocks. Dessen Sectoradresse ist

nummer * (qwallc)
Die Nummer des nächsten Blocks findet man in der Block-Map auf Position
nummer * 2 + 64
Sie ist als vorzeichenlose 16-Bit-Zahl zu bewerten.
Steht dort eine Null, ist der letzte Block des betr. File erreicht.

Die zweite Zahl, die bedingt "gewußt" werden muß, ist die (keineswegs in allen Systemen gleiche!) Größe des physischen Fileheaders, der bei MDV- und den ursprünglichen FLP-Aufzeichnungen der Devicehandler ohne "echte" Directories die Daten des Directoryeintrags aufnimmt, aber bei den späteren Typen nur noch der Compatibilität halber unbenutzt mitgenommen wird. Im Falle der QXL.WIN ist seine Größe 64 Bytes, es gibt aber auch Filesysteme, in denen er garnicht vorhanden ist. Nur außerhalb des Direktzugriffs, ein Manko der Installation, kann die betr. Zahl mittels der i/o-Trap MD.XINF (3/79) zuverlässig ermittelt werden.
 
Mit dieser Korrektur ist also der Anfang eines File an Byteposition 64 im ersten Sector des Blocks, auf den die im Directory-Header verzeichnete Nummer zeigt.
 
Als Beispielanwendung mag das Programm "RecoverX" dienen, mit dem sich Files sowohl aus den (pseudo-)Laufwerken der QXL als auch aus den QXL.WIN-Dateien selbst lesen und auch z.B. nach versehentlichem Löschen wiedergewinnen lassen. In einem gesonderten Archiv liegen die F6 Forth-Quellen dazu vor.
 
 

3.6.3 ** Microdrive

Die Microdrive-Vectoren erlauben den direkten Zugriff auf einzelne Sectoren. Dabei gibt es keine Sperren durch irgendwelche Fehlerkontrollen, die Fehlerbehandlung ist durch jeweils angepasste Rücksprungadressen im aufrufenden Programm möglich. Ansich sind die Vectoren völlig ausreichend, wenn die äußere Datenstruktur bekannt ist. Diese besteht aus den Directory-Eintragungen und dem eigentlichen Datenblock von 512 Bytes Länge. Zum Formatieren taugt bestens die entsprechende Qdos-Trap.

Doch da die Angaben nun einmal vorliegen {1} und die Microdrives markanter Bestandteil des QL sind, außerdem auch, weil die eine oder andere vielleicht weniger konventionelle Anwendung nicht ausgeschlossen werden soll, folgt hier noch ein Blick in die eigentlichen Interna der Aufzeichnungsstruktur.

Der Datenträger ist ein zweispurig bitweise abwechselnd bespieltes Endlosband aus Magnetfolie {14}. Es erlaubt somit nur den sequentiellen Zugriff, erspart aber immerhin das Zurückspulen des Bandes.

Datentypen

Sector-Präambel

10 Bytes 00 
2 Bytes $FF
Sector-Header
1 Byte $FF
1 Byte Sectornummer
10 Bytes Filename 
2 Bytes 16-Bit Zufallszahl
Block-Präambel
6 Bytes 00 
2 Bytes $FF 
Block-Header
1 Byte $00 bis $0F Filenummer 
$F8 Microdrive Map 
$FD leerer / schlechter Block 
1 Byte Blocknummer ab Null zählend 
Datenblock
512 Bytes Daten 
Prüfsumme
2 Bytes niederwertiges Byte zuerst gesendet.
Ausgehend vom Wert $0F0F werden die Datenbytes 
eines Blocks zusammengezählt. 
Sector Map Block,
der Verteilungsplan mit Filenummer $F8 im Block 0
512 .b paarweise mit 
1. 
Filenummer des betreffenden Blocks, oder 
$FF fehlerhafter Sector 
$FD freier Sector 
2. 
Lfd.Nr. des Blocks innerhalb des File
 Das letzte Byte der Sector Map enthält die Nummer 
des jüngst zugewiesenen Sectors. 
 

Aufzeichnung

File-Header

64 Bytes der schon beschriebenen Directory-Angaben 
 
Directory Block
Ein besonderes File mit der Nummer 0. 
Es enthält alle Fileheader einschließlich des eigenen in Reihenfolge 
ihrer Nummern im Abstand von 64 Bytes je Nummer. 
 
Löschen eines File
geschieht durch Überschreiben der Eintragungen im Directory-File für File-Länge und Länge des Namen. Wenn das eigentliche File noch nicht überschrieben wurde, kann es durch Restaurieren nur dieser beiden Zahlen z.B. aus dem Fileheader wieder greifbar gemacht werden.
 
Sicherheit
zwischen den einzelnen Blöcken gegen Überschreiben in den Randzonen wird durch einen Zwischenraum (gap) gewährleistet. 
Dessen Länge ist zeitlich bemessen mit
2660 
µs Einschwingdauer der Löschspannung
20 
µs Abklingzeit dto. 
160 
µs Unschärfe in der Steuerung 
dazu 10%
 Zuschlag für Drehzahlschwankungen 
 
Sectoren-Anordnung
Wegen der Trägheit des Antriebes werden die Sectoren fortlaufend verschachtelt aufgezeichnet. Zu Beginn ist dafür ein Abstand von 
20 Sectoren zum jüngst benutzten Sector angemessen, dann zwischen 
den folgenden Blöcken eines File 12 Sectoren. 
 
Ablauf

Die zeitliche Steuerung erlaubt die Nutzung von 225 Sectoren + 5% Toleranz.

 
 
Präambel 
12 Bytes
480 µs
 
 
Sector-Header
14 Bytes
560 µs
 
 
Prüfsumme
2 Bytes
80 µs
 
 
Sicherheitsabstand
 
3600 µs
zusammen
4720 µs
 
Präambel 
12 Bytes
480 µs
 
 
Block Header
2 Bytes
80 µs
 
 
Prüfsumme
2 Bytes
80 µs
 
 
Präambel
8 Bytes
320 µs
 
 
Aufzeichnung
512 Bytes
20480 µs
 
 
Prüfsumme
2 Bytes
80 µs
 
 
Sicherheitsabstand
5520 µs
zusammen
27040 µs
Übertragungszeit für einen Sector insgesamt
31760 µs
 
Die Steuerung erfolgt mittels der Hardwareregister, deren genaue Verwendung den Tabellen und den Angaben zu den Vectoren entnommen werden kann (s. beigefügtes Disassembly ).
 
 

3.6.3 ** Netzwerk

Das zunächst vorgestellte Original-Protokoll entspricht dem des Spectrum. Mit dem TK2 sind darin einige Änderungen für höhere Übertragungssicherheit eingeführt. Da sich auch andere Nutzung anbietet, etwa der Anschluss eines Magnetbandgerätes, vielleicht sogar die Übertragung akustischer Signale, wird sich die genauere Betrachtung der Register zur Hardwaresteuerung lohnen.
 
 
  Sender Empfänger
>> "scout" - Vorlauf  
GAP Abwarten 
3 ms Ruhe, sonst neu beginnen.
Vorlaufsignal abwarten
WAIT längstens 530 µs lang 
Senden eines Vorlaufsignals, 
neu beginnen, falls eine Antwort erfolgt
530 µs warten
>> "header" - Kopf der Sendung  
HACTIV Netz für 22µs aktiv machen Aktivität abwarten
HBYTES Signal inaktiv für jedes Bit, nur Stop-Bits aktiv 
1 * 11,2 µs für das Startbit 
8 * 11,2 µs für 8 Datenbits 
5 * 11,2 µs für 5 Stop-Bits
Startbit abwarten 
bei Fehler wiederholen
HACKW 2,5 ms auf aktives Signal warten, 
Sendung wiederholen, wenn keines kommt
22,5 µs aktives Signal senden
HACKBT Startbit abwarten, 
8 Datenbits 
empfangen
11,2 µs Startbit senden, 
dann 8 Datenbits 
%000000001 senden.
  bei Fehler neu beginnen.   
>> "data" - Daten  
DACTIV Netz für 22 µs aktivieren aktives Signal abwarten
DBYTES wie bei HBYTES wie bei HBYTES
DACKW dto.
dto.
DACKBT dto.
dto.
 

Das ganze Protokoll ist durch einen inaktiven Zeitraum von wenigstens 2,8 ms synchronisiert.

Der Kopf besteht aus 8 Bytes in folgender Anordnung:

Nummer der Zielstation
Nummer der sendenden Station
Höherwertiges Byte der Blocknummer
Niederwertiges Byte der Blocknummer
Block-Typ: 0 normaler,1 letzter Block
Anzahl Bytes im Block: 0 für 256, weiter 1 bis 255
Prüfsumme für die Daten
Prüfsumme für den Kopf
Fehlersituationen

Die Prüfsumme wird durch Addition gebildet. Zwei Bitfehler in den höchstwertigen Bits der Bytes eines Blocks werden nicht erkannt - was die häufigsten Fehler sind.

Stimmt die im Mitteilungskopf empfangene Blocknummer nicht mit der des fälligen Blocks überein, werden die Daten wohl quittiert, nicht aber ausgewertet.

Wenn der Empfänger den letzten Datenblock zwar empfangen, der Sender die Quittung aber aus irgendeinem Grunde verfehlt hat, wird er den Block immer wieder aussenden, solange, bis die Zeitbegrenzung von etwa 20 s abgelaufen ist.
 

Übertragungsprotokoll im Toolkit II

Das Protokoll wurde etwas geändert und für die Sicherheit erweitert.  Der Empfänger hat nun genügend Zeit, auf den Vorspann zu warten. Die Quittungen für richtig und fehlerhaft empfangene Sendung sind unterschiedlich.

Die Änderungen sind hervorgehoben:

  Sender Empfänger
>> 'scout' Vorlauf
GAP Abwarten 
3 ms Ruhe, sonst neu beginnen.
Vorlaufsignal abwarten 
alle 20ms <break>-Abfrage
WAIT längstens 530 µs lang 
Senden eines Vorlaufsignals, 
neu beginnen, falls eine Antwort erfolgt
530 µs warten
SCOUT 5ms aktives Signal senden  
>> "header" - Kopf der Sendung  
HACTIV - entfällt -
HBYTES Signal inaktiv für jedes Bit, nur Stop-Bits aktiv 
1 * 11,2 µs für das Startbit 
8 * 11,2 µs für 8 Datenbits 
5 * 11,2 µs für 5 Stop-Bits
Startbit abwarten 
bei Fehler wiederholen
DACK Positive Quittung:  
DACK Netz abschalten 
max.1 ms auf aktives Signal warten 
neu beginnen, wenn es nicht kommt
innerhalb 500µs Netz aktivieren, 
min. 5 ms warten, 
neue Daten erwarten. 
Hier ist Zeit zur Datenbearbeitung.
NACK Negative Quittung:  
NACK Auf Abschaltung warten 2,6 µs warten, 
bleibt das Netz inaktiv, neu beginnen.
NACKW 500 µs auf aktives Signal warten, 
Ablauf dieser Zeit bei inaktiven Netz bedeutet fehlerfreien Empfang.
200 µs aktives Signal erwarten, 
dann mit neuen Daten weiter, 
sonst 500 µs aktives Signal für NACK senden. 
HACKW - entfällt -
HACKBT - entfällt -
>> "data" - Daten  
DACTIV - entfällt -  
DBYTES wie bei HBYTES wie bei HBYTES
DACKW - entfällt -
DACKBT - entfällt -
Quittung für eine vollständige Sendung:
    5 ms aktives Signal
DACK nach positiver Quittung min. 400 µs inaktives Signal (Netz abgeschaltet)
NACK nach negativer Quittung 200 ... 300 µs Inaktivität, dann 
min. 200 µs aktives Signal
 
 
 


  oben : zurück : weiter : inhalt 

(count)