mp 10/87 S. 311 ff.

Für den Z9001 gibt es ein CP/M-ähnliches Verfahren für Gerätetreiber. Darüber gab es einen umfassenden Artikel, den ich hier (nebst reassemblierter Software) bereitstelle. Mir ist nur das hier vorgestellte Treiberpaket bekannt, welches den offiziellen Weg über das ASGN-Kommando (s.u.) zur Treibereinbindung nutzt. Andere Treiber, wie auch die Druckertreiber von Robotron, umgehen diesen Mechanismus und verankern sich direkt in den Systemzellen. (vp)

Dr. Frank Schwarzenberg, Mikroprozessortechnik, 10/1987, S. 311-315, Datei z9001_interfaces.zip, Originalartikel mp87-10.pdf

Für Geräte der Leistungsklasse des KC 85/1, die bereits in der DDR eine große Verbreitung erfahren haben, werden i. a. keine peripheren Geräte mitgeliefert. Häufig besteht deshalb der Wunsch, bereits vorhandene Geräte wie Drucker, Lochbandleser und -stanzer, Teletypes, Fernschreiber o. ä. an den Kleincomputer anzuschließen. Von Robotron wird bisher nur der Anschluß spezieller Drucker (K6311, K6303) unterstützt. In dem Beitrag werden Möglichkeiten dargestellt, wie ohne spezielle Zusatzmodule und mit geringstem Hardwareaufwand in vielen Fällen ein Anschluß der o. g. Geräte durch Nutzen des User-Ports des KC85/1 realisier- bar ist. Die Problematik des Einbindens eigener Gerätetreiber in das Betriebssystem des KC 85/ 1 wird ausführlich erläutert. Die in dem Beitrag angeführten Programmbeispiele sind erprobt und ermöglichen u. a. das Betreiben solcher Drucker wie EPSON LX86 (V24/DTR-Protokoll) oder K6303 (TD40) am KC85/1 ohne Druckermodul.

Bild 1 zeigt den für den Anwender frei verfügbaren User-Port des KC 85/1. Er ist über eine 15polige EFS-Buchse an der rechten Seite des Gerätes dem Nutzer zugänglich und besteht aus einem PIO-Port und einem CTC-Kanal. Diese Peripherieschaltkreise sind über folgende E/A-Adressen ansprechbar:

PIO-Daten: 89H
PIO-Control: 8BH
CTC1: 81H

Bei der Nutzung dieser Schnittstelle müssen unbedingt die zulässigen Pegel und Lastbedingungen von PIO und CTC beachtet werden, da diese Anschlüsse im KC 85/1 *nicht* gegen Überlastung bzw. Zerstörung geschützt sind.

Aus Bild 1 geht hervor, daß dem Anwender am User-Port 8 freiprogrammierbare Leitungen und jeweils zwei Ein- und Ausgabeleitungen mit speziellem Verhalten zur Verfügung stehen. Diese Belegung erlaubt bei konsequenter Ausnutzung die Realisierung so gängiger Standard-Interfaces wie SIF-1000, V24(RS 232C) und CENTRONICS derart, daß viele Geräte mit diesen Schnittstellen direkt an den User-Port angeschlossen werden können. Die notwendigen Hardware-Arbeiten beschränken sich - wie die folgenden Beispiele zeigen - auf das Anfertigen eines Kabels und evtl. erforderliche Pegelanpassungen (V24). Es sei darauf hingewiesen, daß die Beschreibung der Standard-Interfaces nur soweit erfolgt, wie das für den konkreten Geräteanschluß notwendig ist, und somit keinen allgemeingültigen Charakter besitzt.

SIF-1000 ist ein in der DDR noch weit verbreitetes Standard-Interface. Lochbandleser und -stanzer (z. B. daro 1215) sowie ältere Druckertypen (z.B. SD 1156) sind mit diesem Interface ausgestattet. Bevor man ein derartiges Gerät anschließt, sind folgende gerätespezifischen Parameter zu prüfen:

• Pegelverhältnisse (TTL, KME3 (12V), KME 20 etc.) und Lastbedingungen

Geräte mit TTL oder KME3-Pegel ermöglichen häufig, den direkten Anschluß an den User-Port. Bei KME3 genügt meist das „Klemmen“ der vom Gerät kommenden Signale über Dioden gegen +5 V. Die vom User-Port abgehenden TTL-Signale werden meist von den Geräten sicher erkannt. Dies sollte jedoch anhand der Gerätebeschreibungen im konkreten Fall überprüft werden.

• Paritätsprüfung

Bei SIF-1000-Geräten wird das 8. Datenbit oft als Paritätsbit verwendet. Das hier angegebene Beispiel einer reinen Software-Realisierung des SIF-1000- Signalspiels nutzt das 8. PIO-Bit für die Erzeugung des RUF-Signales. Ein Paritätsbit kann somit nicht gebildet werden. Die meisten Geräte gestatten aber das Abschalten der Paritätsprüfung.

• Nutzung der KOMmando- bzw. STATus-Signale

Die begrenzte Anzahl der Datenleitungen am User-Port gestattet nicht die Bildung der KOM- bzw. Auswertung der STAT-Signale des SIF-1000 ohne Zusatzhardware. In den meisten der hier interessierenden Anwendungsfälle kann auf die dynamische Nutzung dieser Leitungen verzichtet werden. Für die Datenübertragung müssen die Kommando-Signale normalerweise die folgende Belegung haben (sofern sie vom Gerät überhaupt ausgewertet werden):KOM-1: 1 KOM-2: 0 KOM-3: 0Diese Belegung kann - falls erforderlich - fest verdrahtet werden.

Über die max. 3 Statusleitungen werden u. U. bestimmte Gerätebedingungen wie Lochband- oder Papierende bzw. Gerätefehler gemeldet. Auf die Auswertung dieser Bedingungen kann unter Berücksichtigung der hier interessierenden Anwendung verzichtet werden. Bild 2 zeigt das für SIF-1000 typische Signalverhalten. Über die Begleitsignale *RUF* und *END* wird ein sog. vollständiges Hand-shake realisiert.

Bei Beachtung der genannten Einschränkungen kann der Anschluß eines SIF-1000- Gerätes an den User-Port mit folgender Signal-Zuordnung erfolgen:

Die PIO-Signale RDY und /STRB werden hier nicht verwendet, da sie das für RUF und END geforderte Signalverhalten ohne Zwischenschalten von Zusatzelektronik nicht realisieren.

Für die Auswertung des END-Signals wurde der Zähler-Eingang des CTC-Kanales benutzt. Damit sind die in Tafel 1 und 2 angeführten Routinen zur softwaremäßigen Realisierung des Geräteanschlusses ohne Interruptbetrieb ausführbar.

Die angegebenen Treiber bilden das in Bild 2 dargestellte Signalverhalten für die Signale /DAT-1 bis /DAT-7, /RUF und /END nach. Um ein „Klemmen“ des Systems bei nicht angeschlossenem Gerät oder anderen Fehlern zu verhindern, wurde eine Abfrage der STOP-Taste mit integriert, wodurch ein Zwangsaustritt aus den Routinen jederzeit möglich ist.

Die SIF-E-Routine wurde insofern verkürzt, als auf die Rückflanke des END-E- Signals nicht mehr gewartet wird. Das hat sich als vorteilhaft bei der Nutzung des Handlesers ZfK 4944-170/03 herausgestellt.

Es wird eine stark abgerüstete, aber weit verbreitete Form dieser weltweit wohl am meisten genutzten

Geräteschnittstelle betrachtet. Detailliertere Informationen zu dem Standard können u. a. /2/ entnommen werden. Computer- Peripheriegeräte mit dieser Schnittstelle arbeiten in der Regel mit einem asynchronen Übertragungsprotokoll nach Bild 3. Dieses Übertragungsprotokoll erlaubt eine große Flexibilität bzgl. bestimmter Parameter:

• Zahl der Datenbits pro Übertragungseinheit (meist 5..8) - Baudrate (Bit/s): übliche Werte sind 19200, *9600*, 4800, 2400, *1200*,… - keine, gerade oder ungerade Parität - 1, 1,5 oder 2 STOP-Bits

Peripherieschaltkreise wie der U880-SIO-Schaltkreis ermöglichen die Realisierung dieses Übertragungsprotokolls mit minimalem Aufwand. Sämtliche oben angeführten Parameter sind durch entsprechende Programmierung- des Schaltkreises einstellbar. Im allgemeinen sollte für den Aufbau einer seriellen Schnittstelle dieser Art ein solcher (oder ähnlicher) Schaltkreis Verwendung finden. Ein entsprechender Zusatzmodul für den KC 85/1 ist im ZfK Rossendorf entwickelt worden (IFFS und V24).

Wie nachfolgend gezeigt wird, ist in vielen Fällen aber auch ohne Zusatzmodul ein Anschluß solcher Geräte möglich, die mit der sog. DTR-Prozedur arbeiten können. Das bedeutet, daß die Daten zum Gerät seriell übertragen werden und zur Synchronisierung der Übertragungsgeschwindigkeit ein statisches Signal (DTR-Data Terminal Ready) vom Gerät geliefert wird. Der Hardware-Aufwand für den Geräteanschluß (Pegelanpassung) kann unter bestimmten Bedingungen minimal ausfallen (s. u.). Die in Tafel 4 gezeigte Routine übernimmt die serielle Ausgabe eines Bytes über den User-Port entspr. dem in Bild 3 dargestellten Protokoll bei folgenden möglichen Parametern:

• 5 bis 8 Datenbits, ein eventuelles Paritätsbit ist als Datenbit an die Routine zu übergeben.
• Folgende Baudraten sind einstellbar:

Für die Berechnung der Befehlslaufzeiten wurde dabei eine Systemtakt-Frequenz von 2,5 MHz veranschlagt. Niedrigere Baudraten sind leicht durch Einfügen von Dummy-Befehlen in die Warteschleife WT1 (s.Tafel 4) zu erreichen.

• Parität:

Das Paritätsbit wird der Routine als Datenbit übergeben. Die Anzahl der Datenbits (DN in Tafel 4) muß entsprechend definiert werden. Da nur max. 8 Datenbits von der Routine verarbeitet werden, können mit Parität max. sieben Datenbits gesendet werden.

Beispiel: 7 Datenbits und ungerade Parität

DN 	EQU 8 		;7+1
	.
	.
	LD A,C 		;ZEICHEN NACH A
	AND 7FH
	RES 7,C
	JP PO,UPAR 	;UNGERADE PARITAET
	SET 7,C
JPAR: 	CALL V24 	;AUFRUF DER ROUTINE NACH TAFEL 2
	.
	.

Ein Zwangsausgang über die STOP-Taste wurde wiederum vorgesehen.

Man beachte, daß die gezeigte Routine das unterste (d. h. physikalische) Übertragungsprotokoll realisiert. Druckerspezifische Anpassungen (Sonderzeichen, Steuerzeichen o. a.) sollten an dieser Stelle nicht erfolgen, sondern - sofern überhaupt erforderlich - von einem übergeordneten Treiberprogramm ausgeführt werden. Die dargestellte Routine ist allerdings direkt für den Betrieb eines TD40 (K6303) oder auch des EPSON LX86 (PC-1715-Variante) am KC 85/1 geeignet.

Den notwendigen Pegelanpassungen muß hier besondere Aufmerksamkeit gewidmet werden. Standardmäßig finden beim RS232C die Treiberschaltkreise 75150, 75188 o. ä. und die Empfängerschaltkreise 75154, 75189 o. ä. Verwendung. Damit ist eine normgerechte Pegelanpassung durchführbar, allerdings werden für die Treiberschaltkreise +/-12 V bzw. +/-9 V benötigt, die am User-Port leider nicht zur Verfügung stehen. Hier sollte im konkreten Fall geprüft werden, wie die Empfängerschaltkreise im Gerät beschaltet sind. Die angegebenen Typen gestatten

nämlich eine Verschiebung der Triggerschwelle. Bild 4 zeigt eine Beschaltung der Empfängerschaltkreise, die eine sichere Ansteuerung mit einem Signalpegel von 0 bzw. +5 V erlaubt (z. B. im LX86 und K6303 gegeben). Damit entfällt die Notwendigkeit einer negativen Spannung, und eine Pegelanpassung nach Bild 5 ist der gesamte Hardware-Aufwand für den Druckeranschluß. Die Kabellänge sollte dann allerdings 2 bis 3 m nicht überschreiten.

Das CENTRONICS-Interface ist eine bitparallele bidirektionale Datenschnittstelle, die insbesondere als Druckerinterface z. Z. weltweit starke Verbreitung findet. Alle modernen Drucker für Heim- und Personalcomputer bieten in der Regel auch eine Ausrüstungsvariante für diese Schnittstelle.

Bild 6 zeigt das Signalverhalten. Da die Pegel TTL-Pegel sind, eignet sich dieses Interface besonders gut für den Betrieb am User-Port des KC 85/1. Bestimmte Einschränkungen müssen allerdings wegen der begrenzten Zahl der Datenleitungen wieder getroffen werden. Will man gänzlich ohne Zusatzhardware auskommen, so bietet sich eine Zuordnung der Signale des User-Ports zu den CENTRONICS-Signalen in folgender Form an:

Es ist zu erkennen, daß bei dieser Zuordnung das PIO-Bit 7 für die Erzeugung des CENTRONICS-/STROBE-Signals verwendet wird und somit nur 7 Datenbit übertragen werden können. Die meisten modernen Matrix-Drucker ermöglichen auch bei 7 Datenbits alle verfügbaren Druckmodi (einschließlich Grafik). Bei geschickter Ausnutzung des Signalverhaltens der RDY-/STRB-Leitungen kann das RDY-Signal auch als CENTRONICS-/STROBE-Signal verwendet werden. Die damit erreichbare Länge des /STROBE-Signals liegt dabei aber immer unter dem normalerweise erforderlichen Wert von mindestens 1 µs. Bei einigen Druckern funktioniert das zuverlässig (Schneider NLQ 401, Seikosha GP100), andere Drucker haben damit Probleme (K6313). Die oben angeführte Zuordnung sichert das Standard-Signalverhalten und ist ohne jede Zusatzhardware einsetzbar.

Auf eine Auswertung der Papierendemeldung vom Drucker (PE) muß aus den genannten Gründen auch hier verzichtet werden.

Tafel 3 zeigt die entsprechende Treiberroutine für den Anschluß eines CENTRONICS-Druckers an den User-Port des KC 85/1.

Das OS des KC85/1 unterstützt leistungsfähig das Einbinden neuer Gerätetreiberroutinen für die sog. zeichenorientierten logischen Ein- /Ausgabekanäle. Vorbild für das im folgenden kurz erläuterte Konzept ist das Betriebssystem CP/M.

Das OS-KC85/1 verwaltet eine Tabelle mit 4 mal 4 Plätzen für Adressen von Gerätetreiberroutinen (Tafel 5). Jeweils eine Zeile dieser Tabelle wird dabei einem der 4 logischen E/A-Kanäle

CONST: (Console)
READER: (zusätzlicher Eingabekanal)
PUNCH: (zusätzlicher Ausgabekanal)
List: (log. Kanal für Drucker)

zugeordnet, d. h. für jeden log. E/A-Kanal können 4 Treiberroutinen gleichzeitig resident sein. Welche dabei im gegebenen Moment ausgewählt wird, bestimmt die Belegung des I/O-Bytes (HS-Adr. 0004, im CP/M üblicherweise Adr. 0003).

Das OS selbst beinhaltet zwei residente Treiberroutinen:

CRT Consoltreiber
BAT Batch-Treiber

CRT ist der Treiber für die Standard-Console, d. h. für das Fernsehgerät als Sichtgerät und die eingebaute Tastatur.

BAT ist ein Treiber, der das log. Gerät Console (CONST:) auf die Kanäle READER: (Eingabe) und LIST: (Ausgabe) aufteilt, also nur verwendbar ist, falls auch für READER: und LIST: entsprechende Treiber eingebunden wurden.

Alle anderen Plätze der Tabelle sind nach einem Kaltstart des OS (RESET oder POWER ON) mit dem Wert 0FFFFH belegt und zeigen dem OS damit einen nicht existenten Treiber an. Sollen eigene Treiberroutinen - wie z. B. die in Tafel 1 bis 4 - eingebracht werden, so kann das durch direktes Eintragen der Treiberadresse in den entsprechenden Tabellenplatz und zugehöriges Stellen des I/O-Bytes erfolgen. Aber auch hierfür bietet das OS ein leistungsfähiges Hilfsmittel - das ASGN (Assign)-Kommando - an. Diese Form des Einbindens von E/A-Treibern sollte i. a. bevorzugt werden, da die konkreten Anordnungen von Zuordnungstabelle (Tafel 5) und I/O-Byte im Speicher damit für den Nutzer transparent bleiben (d. h., evtl. Veränderungen wirken sich nicht auf das Anwenderprogramm aus).

ASGN ist ein residentes Kommando des OS (von insgesamt 3). Die Aufrufform ist

ASGN [log. Gerät = phys. Gerät]

ASGN ohne Parameter gibt die aktuelle Belegung auf dem Bildschirm aus, z. B.

CONST:=CRT 
READER:= 
PUNCH:=
LIST:=

sofern noch keine zusätzlichen Treiber eingebunden worden sind. Die möglichen logischen Geräte wurden bereits erläutert, als phys. Geräte sind *CRT*, *BAT* oder Namen eigener Treiberroutinen möglich (max. 8 Buchstaben oder Zahlen).

Beispiel: ASGN LIST:=LX86

Wird eine solche Anweisung gegeben, so vollzieht sich im OS ein umfangreicher Mechanismus:

Zuerst wird eine Treiberroutine namens „LX86“ im Speicher (von oben nach unten) entsprechend den Aufrufregeln für transiente Kommandos gesucht:

- Suche auf allen Adressen mit Low-Byte = 0 nach einer Bytefolge der Form: C3 ll hh (= JP hhllH) - Die folgenden 8 Bytes werden mit der angegebenen Zeichenkette (hier „LX86“) verglichen.

Diese Tabelle wird mit einem Nullbyte abgeschlossen und kann mit weiteren Strukturen dieser Form fortgesetzt werden. Zwei aufeinander folgende Nullbytes beenden diese Sprungtabelle (vgl. Beispiel Tafel 6).

Ist die Suche erfolgreich, so wird die Steuerung zur Adresse hhllH übergeben (Initialisierungsroutine des Treibers), andernfalls wird angenommen, daß eine Treiberroutine vom Band nachgeladen werden soll, und es erfolgt die Ausschrift

start tape.

Nach dem Einlesen wird die Routine an der im FCB (1. Block) spezifizierten Startadresse gestartet. Im allgemeinen sollte die Treiberroutine an das aktuelle Speicherende (RAM) plaziert werden (über Zelle 36H zu ermitteln). Dem OS müssen nun noch einige Informationen übermittelt werden:

- Welchem log. Gerät darf die Treiberroutine zugeordnet werden?
- Die Startadresse des Treiberteils
- Auf welchem Platz der Zuordnungstabelle (Tafel 5) soll der Eintrag erfolgen (physisches Gerät 0…3)?
- Die Adresse des symbolischen Gerätenamens (8-Byte-String).

Zu beachten ist, daß physische Geräte mit der Nr. 0 jedem log. E/A-Kanal zugeordnet werden können (also auch der Console) und entsprechend aufgebaut sein müssen.

Ein physisches Gerät mit der Nr. 1 kann auch immer dem LIST-Kanal zugeordnet werden (Beispiel: residenter CRT-Treiber).

Die Parameterübergabe erfolgt über die folgenden Register:

H: log. Gerätenr. kennzeichnet den log. Kanal, dem die Treiberroutine zugeordnet werden kann.
0 - CONST: 2 - READER: 4 - PUNCH: 6 - LIST:
L: phys. Gerät (0,…,3)
BC: Adresse der Treiberroutine
DE: Adresse der Zeichenkette (symbolischer Gerätename)

Tafel 6 gibt ein Beispiel an, wie die Treiberroutine nach Tafel 4 (V24/DTR) als Druckertreiber mit der Bezeichnung „LX86“ in das OS eingebunden werden kann. Mit der Anweisung

ASGN LIST:=LX86

wird die Routine V24 (Tafel 4) eingebunden und das I/O-Byte entsprechend gestellt. Es erfolgt die Ausschrift

CONST:=CRT 
READER:= 
PUNCH:= 
LIST:=LX86.

Der Drucker kann jetzt mit CTRL/P zum Bildschirm parallel geschaltet werden (auch im BASIC) oder über den LIST-Kanal (Ruf-Nr. 5) direkt angesprochen werden.

(VP: hier nicht als Text, enthalten s. Datei z9001_interfaces.zip). Ein Anschauen des reassemblierten Quellcodes lohnt sich! Dr. Schwarzenberg hat - wie auch im ZM - außerordentlich intensiv das Z9001-OS einbezogen!

/1/ Mikroprozessorsystem der 2. Leistungsklasse, Beschreibungen der Bausteine CPU 880, PIO, SIO, CTC und DMA. VEB Mikroelektronik „Karl Marx“ Erfurt
/2/ Wilhelm, C.: Datenübertragung. Berlin: Militärverlag der DDR, 1976
/3/ Schwarzenberg, F.; Wobst, R.: Anschluß der Schreibmaschine S6005 an KC85/1: Mikroprozessortechnik, Berlin 1 (1987)10, S. 315
/4/ Dokumentation des Betriebssystems OS- KC85/1, VEB Robotron Vertrieb Berlin

s.a. z9001_interfaces.zip

• Bild 1 User-Port des KC-85/1
• Bild 2 Signalverhalten beim SIF-1000-Interface
• Bild 3 V24 - asynchrones Übertragungsprotokoll
• Bild 4 V24 - Treiber und Empfängerschaltkreise im „failsafe“ Mode
• Bild 5 Pegelanpassung User-Port <→ V24 bei Beschaltung der Empfänger nach Bild 4
• Bild 6 CENTRONICS-Signalverhalten

• Tafel 1 Treiberroutine für SIF-1000-Ausgabe
• Tafel 2 Treiberroutine für SIF-1000-Eingabe
• Tafel 3 Treiberroutine für CENTRONICS-Drucker
• Tafel 4 Treiberroutine für V24/DTR Tafel 5 I/O-Byte und Zuordnungstabelle im OS-KC85/1
• Tafel 6 Einbinden eines Druckertreibers in das OS-KC85/1
• Tafel 7 HEX-Dump des Treiberpakets

Dr.-Ing. Frank Schwarzenberg studierte von 1970 bis 1974 an der TU Dresden in der Fachrichtung Informationstechnik. Von 1970 bis 1974 absolvierte er am VIK Dubne einen Arbeitsaufenthalt. 1980 erfolgte die Promotion zum Thema Rechnerkopplung zur Erfassung kernphysikalischer Experimentdaten. Seit 1982 ist unser Autor am ZfK Rossendorf tätig. Sein Arbeitsgebiet ist die Hard- und Softwareentwicklung für Klein- und Mikrorechentechnik (8-(18-Bit-Systeme).