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

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

In Spur 0, Sector 1 auf Seite 0 steht der Verteilungsplan.
Dort wird neben Daten, die die besonderen Gegebenheiten kennzeichnen, notiert, wie die Aufzeichnungseinheiten der Discette verteilt worden sind.

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, unbedingt 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-program, 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		Reguläre Files
$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 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)
len+2	holt Sectorlänge und Inhalt als String oder sendet den Sectoreninhalt

Die o.a. Längenermittlung ist allerdings weitgehend wertlos, denn sie gibt nur das wieder, was mit dem OPEN-Namen eingestellt wurde, also ohnehin schon bekannt ist. Weil das Öffnen zum Direktzugriff unabhängig von wirklichen Discettentypen ist, kann der zurückgegebene Wert nicht dazu benutzt werden, etwa den wirklichen Discettentyp herauszufinden - das ist ggf. nur durch Ausprobieren möglich und dann wegen der vielen internen Fehlversuche u.U. sehr langwierig.

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 emulierten Systemen oder 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 "schlecht" oder "nicht vorhanden" etc. markiert sind. Das Verfahren ist langwierig (ca. 10 Min. für eine DD-Discette), aber 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, Bytes/Sector, Anzahl Spuren ("tracks"), Seiten ("sides", 0 für "single") und Sectoren ("sectors") pro Seite:

CATCH_P "GET" : REMark : aus IO2
n$=FILL$(CHR$(0),512) : REMark : LEN=Bytes/Sector, für Lesefehler
 
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$
   IF Q_ERR : sec$=n$ : REMark : mit IO2 (s.o.)
   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 einzelnen 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 Direktzugriff 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 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 gravierendes Manko der Installation, kann die betr. Zahl mittels der i/o-Trap MD.XINF (3/79) zuverlässig ermittelt werden. - Man unternehme einmal einen Versuch an einer *WeichDOS-formatierten Discette aus dem SMSQ heraus...
 
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 program "RecoverX" dienen, mit dem sich Files aus den (pseudo-)Laufwerken der QXL rsp. 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 program 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 byteweise 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