 
V.24-OEM
========

Schnittstellen-Treiberprogramm fr
IBM-kompatible MS-DOS-Computer

V.24-OEM ist Freeware. Sie finden Hotline-Tips zu diesem Programm
im mitgelieferten Expertensystem XPERT sowie im Internet unter
www.shamrock.de. Shamrock bietet fr Freeware-Produkte keine
kostenlose telefonische Hotline-Untersttzung an und garantiert
nicht die Eignung fr bestimmte Anwendungsflle.

Dieses Handbuch benutzt den IBM-OEM-Zeichensatz. Umlaute werden
in einem Windows-Editor deshalb nicht korrekt dargestellt.

V.24-OEM ist ein DOS-Treiber und eignet sich nicht fr Windows
95, 98 und NT, da diese Versionen ihre eigenen Schnittstellen-
Treiber mitbringen.

(c) Shamrock Software GmbH, 85238 Petershausen, www.shamrock.de


Eigenschaften von V.24-OEM

V.24-OEM ist ein RAM-resident ladbares Treiberprogramm fr IBM-
kompatible PCs und ATs, das bis zu zehn serielle Schnittstellen
bedienen kann. Empfangsseitig ist ein Puffer vorhanden
(voreingestellt 2048 Byte, maximal 60000), damit Zeichen auch im
Hintergrund empfangen werden knnen, wenn das aufrufende
Anwenderprogramm gerade beschftigt ist. Sendeseitig kann ein Puffer
von bis zu 255 Zeichen konfiguriert werden.

Das Treiberprogramm lt sich von allen Programmiersprachen mit den
logischen Gertenamen RS1, RS2, RS3 usw. ansprechen. Dabei lassen
sich auch die V.24-Steuerleitungen DTR und RTS setzen, andere
Leitungen wie CTS, DSR, CD und RI sowie Parity-Fehler oder Puffer-
berlauf lassen sich ohne direkte Hardware-Adressierung abfragen.
Baudrate und bertragungsparameter lassen sich fr alle
Schnittstellen getrennt jederzeit neu setzen.

Durch das Konzept, den Treiber als echten MS-DOS-Gertetreiber
auszufhren, wird die Ein- und Ausgabe von hheren
Programmiersprachen sehr einfach und erfordert keine Assembler-
Unterprogrammaufrufe. Vielmehr werden die normalen DOS-Funktionen
zur Ein- und Ausgabe genutzt.

Wenn der Treiber fr COM3 oder COM4 geladen wird, trgt er
automatisch die entsprechenden Adressen in die vom BIOS dafr
vorgesehenen Speicherzellen ab 0040:0004H ein, so da COM3 und COM4
auch vom DOS erkannt werden knnen.

Schnittstellen mit dem Chiptyp 16550, die einen Hardware-FIFO
enthalten, werden automatisch erkannt und untersttzt.

Das Archiv enthlt folgende Dateien:

README		Ergnzungen und Nachtrge zu diesem  Handbuch
		(verwenden Sie  COPY README PRN  zum Drucken)
CONFIG.SYS	Beispiel fr  die  Installation  von  V24.SYS
V24.SYS		Treiberprogramm, in CONFIG.SYS konfigurierbar
CMTERM.ASM	Assembler-Beispielprogramm (Terminalprogramm)
CMTERM.COM	Lauffhiger Assembler-Objektcode v.CMTERM.ASM
CMTERM.C	C-Beispiel-Software        (Terminalprogramm)
CMTERM.BAS	GW-Basic-Beispielprogramm  (Terminalprogramm)
CMTERM.PAS	Beispielprogramm fr Turbo-Pascal ab Vers.4.0
WINTERM.MAK	Make-Datei fr Visal Basic  (fr Windows 3.x)
WINTERM.FRM	Form-Datei fr Visual Basic  (zu WINTERM.MAK)
V24_GFA.LST	Beispielprogramm fr GFA-Basic (Terminalprg.)
COMTEST.EXE	Diagnoseprogramm fr  Schnittstellen-Hardware
XPERT.COM	Expertensystem-Programm   (Start  mit  XPERT)
XPERT.TXT	Hilfsdatei,  wird  von  XPERT.COM nachgeladen


Hardware-Voraussetzungen

Im IBM-PC bzw. AT sind nur die Ports COM1 (03F8, IRQ4) und COM2
(02F8, IRQ3) standardisiert, alle weiteren COM-Ports jedoch nicht.
Sowohl die Basisadressen als auch die Interrupts der verwendeten
Schnittstellen-Hardware lassen sich beim Laden des Treibers deshalb
beliebig konfigurieren. Dafr gelten allerdings einige
Einschrnkungen: Es ist nicht zulssig, zwei Schnittstellen mit
derselben Adresse zu betreiben. Wenn der Rechner bereits eine
serielle Schnittstelle besitzt, darf COM1 nicht gleichzeitig auf
einer Karte adressiert werden.


! Es ist durchaus mglich, da mehrere Ports einen gemeinsamen
Interrupt (z.B. IRQ3) verwenden. Allerdings funktioniert das nur
dann, wenn alle diese Schnittstellen auf der gleichen Karte sitzen
und die Karte vom Hersteller ausdrcklich als intern interrupt-
sharing-fhig deklariert ist. Der PC- bzw. AT-Bus gestattet aus
Hardware-Grnden ein Interrupt-Sharing mehrerer Karten nicht. Karten
fr COM3 und hher, die sich nur fr IRQ 4+3 konfigurieren lassen,
sind fr alle interrupt-gepufferten Programme (und damit auch fr
V.24-OEM) unbrauchbar, da IRQ4+3 bereits von COM1 und COM2 belegt
sind. Ferner ist die erreichbare Baudrate umso geringer, je mehr
Schnittstellen sich einen Interrupt teilen. Dies gilt insbesondere
fr Microsoft-Windows-Anwendungen, da hierbei die vom System pro
Sekunde verarbeitbare Zahl von Interrupts erheblich geringer als
unter MS-DOS ist.

Sollten Sie nicht sicher sein, ob Ihre Schnittstelle(n) korrekt
installiert sind, so starten Sie bitte das Programm COMTEST auf der
V.24-OEM-Diskette. Es sucht den I/O-Adressenbereich des PC nach
seriellen Schnittstellen ab und berprft einzeln die Zuordnung der
Interrupts 2 bis 7 (andere IRQs, z. B. 10 oder 11, werden von
COMTEST nicht untersttzt, ebenso wird ein Interrupt-Sharing nicht
geprft). Besonders ntzlich ist, da COMTEST auch in der Lage ist,
festzustellen, welche Schnittstellen bzw. Interrupts von welchem
residenten Programm benutzt werden, z.B. von einem Maustreiber.

Wenn Sie COMTEST ohne Option starten, sucht es nur an den Standard-
Adressen von COM1 bis COM4. Mit der Option /E wird der gesamte
Adreraum von 100 bis 3FF durchsucht, wobei auf manchen PCs Probleme
auftreten knnten, da zum Teil allein schon das Lesen von einer
Adresse zum Absturz fhren kann.

Eine groe Hilfe bei der Fehlersuche kann das mitgelieferte Programm
XPERT sein. Dabei handelt es sich um ein kleines Expertensystem, das
Ihnen Fragen stellt, die Sie durch Drcken bestimmter
Funktionstasten beantworten sollten. Sie erhalten dann eine Liste
mglicher Problem-Ursachen.

Sollten Sie das Problem nicht selbst beheben knnen, so kontaktieren
Sie bitte den Hardware-Hndler, von dem Sie die jeweilige
Schnittstellen-Karte bzw. den Computer bezogen haben. 


Laden mit CONFIG.SYS

Die V.24-OEM-Routinen knnen mit Hilfe der von MS-DOS beim
Einschalten des Rechners automatisch geladenen Datei CONFIG.SYS als
residente Betriebssystem-Erweiterung eingebunden werden. Es ist
zulssig, ein und dasselbe Treiberprogramm V24.SYS mehrmals
nacheinander zu laden, um mehrere Schnittstellen gleichzeitig
bedienen zu knnen. Wenn CONFIG.SYS die Zeile

			DEVICE=V24.SYS

(mit Return abgeschlossen) enthlt und die Datei V24.SYS sich im
Hauptverzeichnis des Boot-Laufwerks befindet, wird der Treiber mit
seinen Standard-Einstellungen geladen. Diese sind:

   Schnittstelle:	COM1
   Baudrate:		4800 Bd
   Datenformat:		8 Datenbits, keine Paritt, 1 Stopbit
   XON/XOFF-Handshake:	Ausgeschaltet
   RTS/CTS-Handshake:	Ausgeschaltet
   Timeout:		Ausgeschaltet

Selbstverstndlich kann man hinter DEVICE= auch einen Pfadnamen
angeben, z.B. DEVICE=C:\DOS\V24.SYS, wenn sich der Treiber in einem
Unterverzeichnis der Festplatte befindet. Gro- oder Kleinschreibung
spielt keine Rolle, weil MS-DOS die Zeilen in CONFIG.SYS automatisch
in Groschreibung umwandelt.

Hinter dem Dateinamen V24.SYS (gefolgt von mindestens einem
Leerzeichen) knnen zahlreiche Parameter angegeben werden, um das
Programm anwendungsspezifisch zu konfigurieren. Ein einfaches
Beispiel:

		DEVICE=V24.SYS C3 A02E8 I2 B2 PH

Diese Zeile konfiguriert das Treiberprogramm fr die dritte serielle
Schnittstelle bei der Adresse 02E8 (hex) und dem Interrupt 2
(Parameter I2) mit 300 Baud (B2) sowie acht Datenbits mit ungerader
Paritt und einem Stopbit (PH). Die Leerrume zwischen den
Parametern sind optional. Insgesamt untersttzt V.24-OEM folgende
Parameter (in alphabetischer Reihenfolge):

Axxxx	Schnittstellen-Adresse = xxxx (4stellig hex). Wenn diese
Angabe fehlt, wird bei COM1 03F8 und bei COM2 02F8 angenommen. Bei
COM3 und hher ist die Angabe von Axxxx stets erforderlich.

Bx	Es wird die Baudrate x voreingestellt, wobei x eine Ziffer oder
ein Zeichen mit folgender Bedeutung ist:

	0   75		4  1200		8  19200
	1  110		5  2400		9  38400
	2  300		6  4800		:  57600
	3  600		7  9600		; 115200

	Wenn der Parameter B fehlt, wird eine Geschwindigkeit von 4800 Baud
angenommen (entsprechend B6).

Cx	Der Treiber wird fr die x-te serielle Schnittstelle geladen,
wobei fr x eine Ziffer von 1 bis 9, 0 sowie A-Z eingesetzt werden
kann. Ohne C wird COM1 angenommen.

H	Es wird ein RTS-/CTS-Hardware-Handshake aktiviert: Der Treiber
wartet mit dem Senden, bis CTS=1 ist, und legt RTS auf 0, solange
der interne Puffer voll ist.

Ixx	Es wird der Interrupt xx verwendet, wobei xx eine ein- oder
zweistellige Dezimalzahl von 1 bis 15 sein kann. Diese Nummer mu
mit der auf der Schnittstellenkarte eingestellten Interrupt
bereinstimmen.

O	Mit dem Buchstaben O als Parameter wird dem Treiber mitgeteilt,
da beim ffnen der Schnittstelle aus dem Anwenderprogramm die
internen Sende- und Empfangspuffer nicht gelscht werden sollen.
Ohne den Parameter O werden bei jedem ffnen der Schnittstelle die
internen Puffer gelscht.

Px	Es wird das Datenformat x voreingestellt. Der Buchstabe x hat die
folgende Bedeutung:

	A  8N2		D  7N1		G  8E1
	B  8N1		E  7E1		H  8O1
	C  7N2		F  7O1

	Hierbei bedeutet zum Beispiel "8N1" acht Datenbits, keine Paritt
(N=no=keine, E=even=gerade, O=odd=ungerade) und ein Stopbit. Diese
Konfiguration (entsprechend dem Parameter PB) ist auch
voreingestellt, wenn der Parameter P nicht verwendet wird.

Rxxx	Eine nach R angegebene Dezimalzahl xxx (2 bis 60000) stellt die
gewnschte Gre des Empfangspuffers ein. Ohne R werden 2048 Byte
als Puffergre angenommen.

Sxxx	Eine nach S angegebene Dezimalzahl xxx (2 bis 255) stellt die
gewnschte Gre des Sendepuffers ein. Wenn der Parameter S fehlt,
werden 2 Byte als Puffergre angenommen. Bitte beachten Sie, da
ein groer Sendepuffer das Treiberprogramm bei eingeschaltetem
XON/XOFF- oder RTS/CTS-Handshake erst verzgert auf Handshake-
Signale reagieren lt.

Tx:yyy	Hiermit kann ein Timeout programmiert werden, das immer dann
wirksam wird, wenn Sie versuchen, Zeichen zu empfangen, ohne da
etwas empfangen wurde. Die Dezimalzahl x (1 bis 255) gibt die Anzahl
der Sekunden an, die der Treiber maximal wartet, whrend yyy fr
eine bis zu 15 Zeichen lange Zeichenfolge steht, die Ihrem Programm
bei einem Timeout im Empfangspuffer bergeben wird. Beachten Sie
bitte, da DOS in der Datei CONFIG.SYS Kleinbuchstaben in
Groschrift umwandelt und auch keine Steuerzeichen erlaubt. Um
trotzdem alle Zeichen programmieren zu knnen (auer 00 hex), knnen
Sie beliebige zweistellige Hex-Codes nach einem Backslash angeben,
zum Beispiel \1A fr ein CTRL-Z-Steuerzeichen. Der Parameter T
sollte stets als letzter in einer CONFIG.SYS-Zeile stehen, da
nachfolgende Parameter sonst als Bestandteil des Timeout-Strings
aufgefat wrden.

Uxx,yy	Bei Empfang des Zeichencodes hex xx wird der User-Interrupt
mit der Nummer hex yy ausgelst. xx und yy mssen stets zweistellig
angegeben werden.

V	Wenn nach der Baudraten-Einstellung der Buchstabe V folgt, wird
unabhngig von der mit B gewhlten Empfangs-Baudrate mit 75 Bd
gesendet. Beispiel:
			DEVICE=V24.SYS B4V
	initialisiert den Treiber so, da entsprechend der V.23-Norm mit
1200 Bd empfangen und mit 75 Bd gesendet wird, z.B. fr ein
Bildschirmtext-Modem DBT-03. (Die umgekehrte Kombination ist aus
Hardware-Grnden leider nicht mglich.)

X	Mit dem Parameter X wird sende- und empfangsseitig das XON/XOFF-
Software-Handshake aktiviert. Ohne diesen Parameter werden die
Zeichen XON und XOFF nicht ausgewertet, sondern transparent
bergeben.

Z	Dient bei RS485-Schnittstellen zur passenden Steuerung des RTS-
Ausgangs: Der RS-485-Sendeteil wird aktiviert, solange Zeichen
gesendet werden.

Wenn Sie beispielsweise die Schnittstelle COM3 bei Adresse 02E8 und
mit dem Interrupt IRQ2 so betreiben wollen, da nach zehn Sekunden
Wartezeit (wenn keine Zeichen empfangen werden) Ihrem
Anwenderprogramm das EOF-Steuerzeichen 1AH bergeben wird, ist
folgende Zeile in CONFIG.SYS notwendig:

		DEVICE=V24.SYS C3 A02E8 I2 T10:\1A

Alle genannten Parameter mit Ausnahme von C (Schnittstellen-Nummer),
A (Adresse) und I (Interrupt) lassen sich auch vom Anwenderprogramm
aus setzen und mssen deshalb nicht unbedingt in der Datei
CONFIG.SYS stehen (siehe "IOCTL-Funktionen").

Wirklich notwendig sind nur folgende Parameter:

	  C  (Schnittstellen-Nr.) auer bei COM1,
	  A  (Adresse)   auer bei COM1 und COM2,
	  I  (Interrupt) auer bei COM1 und COM2.

Falls in der Datei CONFIG.SYS hinter dem Dateinamen des Treibers
(V24.SYS) falsche Parameter stehen, gibt das Programm beim Laden
eine Fehlermeldung aus. Es wird dann zwar in den Speicher geladen,
sollte aber nicht verwendet werden, da nur ein Teil der angegebenen
Parameter ausgewertet werden konnte.

Nach dieser Installation ist die erste Schnittstelle unter den
"Datei"-Namen RS1 und RS1X ansprechbar, die zweite mit RS2 und RS2X
und so weiter. Da jeder Schnittstelle zwei gleichwertige Namen
zugeordnet sind, kann man einen Namen zum ffnen einer Datei zum
Lesen und den anderen zum ffnen einer zweiten Datei zum Schreiben
zuweisen, ohne da z.B. in Basic eine Fehlermeldung wie "File
Already Open" auftreten wrde.

Nach dem Laden sind die DTR- und RTS-Leitungen der Schnittstelle
aktiv (d. h. auf +12 V), falls eine DOS-Version vor 3.0 verwendet
wird. Bei spteren DOS-Versionen werden RTS und DTR erst bei einer
Open-Anweisung aktiviert (bei DOS 2.11 wird Open intern ignoriert!).


Ein- und Ausgabe via DOS

Da V.24-OEM ein echter, mit Namen ansprechbarer Gertetreiber ist,
kann man einfache DOS-Anweisungen verwenden, um Daten ber eine
serielle Schnittstelle ein- und auszugeben. Die wesentlichen
Unterschiede zur "normalen" DOS-Schnittstelle COM1 bzw. COM2 sind:

 Die Gertenamen lauten RS1 und RS2 statt COM1 und COM2.
  Die DOS-Namen COM1 und COM2 sind wie bisher benutzbar.
 Der Treiber bleibt bei nicht angeschlossenen Hardware-
  Steuerleitungen (CTS, DSR usw.) nicht hngen.
 Die Ein- und Ausgabe erfolgt gepuffert, so da auch bei
  hheren Baudraten keine Zeichen verloren gehen.
 Das XON/XOFF-Software-Protokoll wird untersttzt, wenn
  der Treiber entsprechend konfiguiert wird.
 Es sind auch hhere Baudraten als 9600 Bd (DOS) mglich.

Um z.B. eine Datei ABC.TXT ber die erste Schnittstelle mit Hilfe
des Treibers auszugeben, gibt man in DOS folgendes ein:

		C>COPY ABC.TXT RS1

Um diese Datei auf einem zweiten PC, der ber ein Nullmodem-Kabel
mit dem ersten verbunden ist, wiederum zu speichern, mte man
vorher (!) folgendes eingeben:

		C>COPY RS1 ABC.TXT

Dieses Beispiel setzt allerdings voraus, da die bertragene Datei
ABC.TXT am Ende ein CTRL-Z-Steuerzeichen (hex 1A, dezimal 26)
enthlt, damit der empfangende PC wei, wann sie aufhrt. Ohne
dieses CTRL-Z wrde MS-DOS ewig auf weitere Zeichen warten und ist
in diesem Zustand auch mit CTRL-C nicht unterbrechbar. Eine Lsung
ist das Programmieren von CTRL-Z als Timeout-Zeichen (z.B. DEVICE =
V24.SYS T5:\1A in der Datei CONFIG.SYS).

Selbstverstndlich sind auch andere DOS-Befehle auf den Treiber
anwendbar, zum Beispiel TYPE RS1, um empfangene Daten bis zum
Auftreten eines CTRL-Z-Steuerzeichens auf dem Bildschirm anzuzeigen.

Diese Art der Treiber-Verwendung ist allerdings alles andere als
komfortabel. Im nchsten Kapitel wird deshalb auf das Ansprechen der
Schnittstellen aus Anwenderprogrammen eingegangen. Damit ist es auch
mglich, zahlreiche Parameter wie Baudrate, Datenformat und so
weiter auch im laufenden Betrieb jederzeit zu ndern.


Programmieren mit V.24-OEM

V.24-OEM eignet sich fr alle gngigen Programmiersprachen. Obwohl
z.B. GW-Basic bereits eine gepufferte Schnittstellen-Behandlung
realisiert, bietet demgegenber V.24-OEM auch hier wesentliche
Vorteile:

+ Es sind mehr als nur zwei Schnittstellen mglich.
+ Bei Empfangsfehlern steigt das Programm nicht aus.
+ Die RTS- und DTR-Leitungen lassen sich definiert steuern.
+ Die CTS-, DSR-, CD- und RI-Leitungen sind einzeln prfbar.
+ Der Sonderstatus "Break" ist abfragbar und auch erzeugbar.
+ Die erreichbare Geschwindigkeit ist erheblich grer.
+ Alle bertragungsparameter lassen sich jederzeit ndern.
+ Jeder Treiber besitzt einen einstellbaren Empfangspuffer.

Das Ansprechen des V.24-OEM-Treibers ist in Basic ebenso einfach wie
die Verwendung der "eingebauten" COM1- und COM2-Schnittstellen-
Routinen, nmlich mit OPEN und CLOSE. Wie bei diesen ist auch eine
Abfrage der Zeichenzahl im Empfangspuffer mglich; dazu spter.

Grundstzlich ist es mglich, schon mit dem folgenden Primitiv-Basic-
Programm Daten auf dem Bildschirm anzuzeigen, die ber die erste
serielle Schnittstelle empfangen werden:

  10 OPEN "I", 1, "RS1"		'Schnittstelle ffnen
  20 PRINT INPUT$(1,1);		'Empfangene Zeichen anzeigen
  30 GOTO 20			'Wieder von vorn

In anderen Programmiersprachen wie Pascal, Modula oder C ist
grundstzlich jede Ein- und Ausgabe ber den Treiber ebenso einfach
wie das Lesen und Schreiben einer Datei.

Wenn Sie erste Versuche mit V.24-OEM unternehmen, dann ist es eine
praktische Sache, Ihr Programm zuerst so zu schreiben, da es
Zeichen nicht von einer Schnittstelle, sondern aus einer
sequentiellen Textdatei liest. Wenn das einmal funktioniert,
ersetzen Sie den Namen der Textdatei einfach durch RS1 (oder eine
andere Schnittstelle), und schon kommen die Zeichen vom seriellen
Port.


IOCTL-Funktionen

MS-DOS stellt mit IOCTL- (I/O-Control-) Funktionen ein brauchbares
Mittel zur Steuerung von Treiberprogrammen zur Verfgung.
Beispielsweise bergibt die Anweisung IOCTL#1,E$ von Basic aus den
Steuerungs-String E$ an das Treiberprogramm mit der Filenummer 1.
Einer IOCTL-Anweisung mu stets ein OPEN-Kommando vorausgegangen
sein. Wenn ein und dieselbe Schnittstelle gleichzeitig mit zwei
Filenummern (fr Ein- und Ausgabe) geffnet wird, ist es
gleichgltig, auf welchen der beiden Kanle die IOCTL-Anweisungen
angewendet werden; sie gelten stets fr beide.

Andere Programmiersprachen, z.B. das verbreitete Turbo-Pascal,
besitzen keine IOCTL-Anweisungen. Die mitgelieferte Diskette enthlt
jedoch zwei Prozeduren, die als Ersatz fr die Basic-Anweisungen
IOCTL# und IOCTL$ verwendet werden knnen. In Assembler oder C kann
der INT-21H-Aufruf AH=44H verwendet werden, um IOCTL-Strings zu
bergeben.

Alternativ kann unmittelbar nach dem ffnen des Treibers (und nur
dann!) auch ein IOCTL-String ber den normalen Datenkanal gesendet
werden, wenn er in die Sonderzeichen-Codes 174 und 175
eingeschlossen wird; in Basic z.B. so:

	OPEN"O",2,"RS1X"
	PRINT #2, CHR$(174); "I5C"; CHR$(175);

Der V.24-OEM-Treiber versteht eine Reihe von IOCTL-Kommandos. Sie
bestehen aus je einem Zeichen und drfen in beliebiger Reihenfolge
bergeben werden (Ausnahme "T"). Andere IOCTL-Zeichen als die im
folgenden genannten werden vom Treiberprogramm ignoriert.

Sie werden feststellen, da die meisten IOCTL-Anweisungen jenen
Parametern hneln, die man auch in CONFIG.SYS hinter dem
Treibernamen angeben kann.

Die Parameterfolge "6BR" (4800 Bd, 8N1) wird beim Start automatisch
ausgefhrt; bei DOS-Versionen vor 3.0 werden zustzlich die
Leitungen DTR und RTS aktiviert. Wenn diese Parameter nicht
verndert werden mssen, sind keine IOCTL-Anweisungen im Programm
erforderlich (auer "I" bei MS-DOS 2.11). Baudrate und
bertragungsparameter knnen nach einer OPEN-Anweisung beliebig oft
mit IOCTL-Kommandos verndert werden. Die OPEN-Anweisung selbst
verndert Baudrate und sonstige Parameter nicht.


Einstellen der Baudrate: 0...9, :, ;, V

0 =   75 Bd	4 = 1200 Bd	8 =  19200 Bd	V = senden
1 =  110 Bd	5 = 2400 Bd	9 =  38400 Bd	    mit 75 Bd
2 =  300 Bd	6 = 4800 Bd	: =  57600 Bd	    (z.B.4V=
3 =  600 Bd	7 = 9600 Bd	; = 115200 Bd	    1200/75)

Wenn der Parameter V zum Senden mit 75 Bd verwendet wird, mu er
stets nach der gewnschten Empfangs-Baudrate stehen. Die
voreingestellte Baudrate ist 4800 Bd.


Einstellen der bertragungsparameter

	A	8 Datenbits, keine Paritt,    2 Stopbits
	B	8 Datenbits, keine Paritt,    1 Stopbit
	C	7 Datenbits, keine Paritt,    2 Stopbits
	D	7 Datenbits, keine Paritt,    1 Stopbit
	E	7 Datenbits, gerade Paritt,   1 Stopbit
	F	7 Datenbits, ungerade Paritt, 1 Stopbit
	G	8 Datenbits, gerade Paritt,   1 Stopbit
	H	8 Datenbits, ungerade Paritt, 1 Stopbit
	*	Erzwingt zwei Stopbits nach A-H (z.B. "E*"
		fr 7 Datenbits, gerade Paritt, 2 Stopbits)

		(Beim Laden ist "B" voreingestellt.)


Sonstige IOCTL-Kommandos

	+	Leitungen DTR und RTS = 1 setzen (+12 V)
	-	Leitungen DTR und RTS = 0 setzen (-12 V)
	I	Treiber initial. (nur bei MS-DOS 2.xx ntig)
	M	DTR=0 und RTS=1 setzen
	N	DTR=1 und RTS=0 setzen (z.B. fr NET.24)
	P	Sorgt fr das Lschen des Puffers bei OPEN
	Q	Verhindert das Lschen des Puffers bei OPEN
	R	Empfangspuffer lschen
	T	Timeout-String setzen: "T"+CHR$(sec.)+TS$
	X	XON/XOFF-Protokoll einschalten (s.u.)
	Y	XON/XOFF-Protokoll ausschalten
	<	Break-Status ein (TxD-Leitung = 0 setzen)
	>	Break-Status aus (Normalzustand, TxD = 1)

Beim Laden sind normalerweise "P" und "Y" voreingestellt.

MS-DOS 2.11 ignoriert intern einen z.B. von Pascal, C oder Basic
veranlaten OPEN-Befehl. Deshalb ist "I" ntig, um sicherzustellen,
da vor einer Ein- und Ausgabe die Interrupt-Vektoren und Puffer-
Zeiger korrekt gesetzt werden. "I" lscht gleichzeitig den
Empfangspuffer. Bei MS-DOS-Versionen ab 3.0 wird die richtige
Initialisierung aber durch eine OPEN-Anweisung automatisch
gewhrleistet. Weder "I" noch OPEN verndern jedoch die eingestellte
Baudrate oder die brigen Parameter.

Ein OPEN-Kommando (z.B. in Basic) setzt die RTS- und DTR-Leitungen
automatisch auf 1, das entspricht einem elektrischen Pegel von +12
V. Der IOCTL-Befehl I hat dieselbe Wirkung. DTR und RTS sind jedoch
auch schon nach dem Laden des Treiberprogramms sofort auf 1 gesetzt,
damit der Treiber auch von der MS-DOS-Kommandoebene aus eingesetzt
werden kann. DTR und RTS knnen (stets gleichzeitig) entweder mit
dem IOCTL-Kommando "-" oder mit einer CLOSE-Anweisung zurckgesetzt
werden.

In GW-Basic ist zum Beispiel folgende Anweisungsfolge ntig, um die
Schnittstelle COM1 zur Eingabe der Filenummer 1 und zur Ausgabe der
Filenummer 2 zuzuweisen:

	OPEN"I",1,"RS1" : OPEN"O",2,"RS1X"

Dabei sind zunchst die Baudrate 4800 Bd und die Parameter 8N1 (acht
Datenbits, keine Paritt, ein Stopbit) voreingestellt. (Den Versuch,
fr Ein- und Ausgabe jedesmal den Namen "RS1" zu verwenden, wrde
Basic mit der Fehlermeldung "File Already open" quittieren, deshalb
wird zur Ausgabe der gleichwertige Name RS1X verwendet. Es sollte
brigens auch vermieden werden, da Disk-Files den gleichen Namen,
mit oder ohne Extension, z.B. RS1.TXT, verwenden.)

Die folgende Anweisung initialisiert den Treiber (I) und setzt die
bertragungsparameter auf 2400 Bd und 7N2:

			IOCTL#2,"I5C"

Zur Datenausgabe lassen sich dann in Basic die Anweisungen PRINT#2
und PRINT USING#2 einsetzen. Zum Empfang von Daten eignen sich die
Anweisungen INPUT$(n,1) mit n=zu lesende Zeichenzahl, INPUT#1 sowie
LINE INPUT#1 (siehe Basic-Handbuch).


Timeout-Programmierung

Der IOCTL-Befehl "T" veranlat das Treiber-Programm, einen von Ihnen
definierbaren Timeout-String ber den Empfangspuffer zu bergeben,
wenn eine bestimmte Zeitdauer vergebens auf den Empfang von Zeichen
gewartet wird. Das ist zum Beispiel dann sinnvoll, wenn die
verwendete Programmiersprache die Abfrage von IOCTL-Strings nicht
erlaubt und somit nicht feststellen kann, ob berhaupt Zeichen
empfangen wurden.

Im IOCTL-String gibt das erste Byte nach dem T binr die Wartezeit
in Sekunden an (maximal 255), die dann folgenden Bytes enthalten den
bei einem Timeout zu bergebenden String, der bis zu 15 Zeichen lang
sein darf, jedoch kein Null-Byte (00H) enthalten darf.

Angenommen, es soll nach fnf Sekunden die Zeichenfolge "Timeout"
und ein Return-Zeichen bergeben werden, ist folgender IOCTL-Befehl
in Basic erforderlich:

	IOCTL#2,"T"+CHR$(5)+"Timeout"+CHR$(13)

Durch das Auftreten eines Timeouts wird gleichzeitig ein eventueller
XOFF-Status auf XON rckgesetzt, damit das System nicht "hngt"
(siehe Abschnitt "XON/XOFF-Protokoll").

Mit der Anweisung IOCTL#2,"T"+CHR$(0) kann die Timeout-Funktion bei
Bedarf jederzeit wieder ausgeschaltet werden.

In Pascal kann die in CMTERM.PAS bzw. CMTERM4.PAS enthaltene
Prozedur IOCTLOUT zur Programmierung des Timeouts verwendet werden.
Beachten Sie bitte, da die Sekundenanzahl innerhalb des Strings als
CHR() bergeben wird, d.h. als binres Byte.


Handshake-Verfahren

XON/XOFF

Beim Start ist der Treiber fr alle Codes transparent, d.h. alle
Zeichencodes werden unverndert durchgelassen. Mit dem IOCTL-
Kommando "X" lt sich ein XON-XOFF-Protokoll einschalten, mit dem
man verhindern kann, da eine Seite die Zeichen schneller sendet,
als die andere sie verarbeiten kann.

Bei eingeschaltetem XON/XOFF-Protokoll sind die beiden Zeichen XON
(CTRL-Q, Code dezimal 17 bzw. hex 11) und XOFF (CTRL-S, dezimal 19
bzw. hex 13) natrlich nicht bertragbar. Eine vollstndig
transparente bertragung ist deshalb nur bei ausgeschaltetem
XON/XOFF-Protokoll mglich. Es wird auch empfohlen, das Senden von
CTRL-S und CTRL-Q aus dem Anwenderprogramm heraus zu vermeiden, wenn
das XON/XOFF-Protokoll eingeschaltet ist, damit keine Konflikte mit
der Protokollsteuerung auftreten.

Wird ein XOFF-Zeichen empfangen, so wird mit dem Fllen des
Sendepuffers solange gewartet, bis ein XON-Zeichen empfangen wird.
(Hierbei gibt es kein Timeout, d.h. der Rechner kann beliebig lange
warten.) Beachten Sie bitte, da der Treiber bei einem groen
Sendepuffer u.U. wesentlich langsamer auf ein empfangenes XOFF-
Zeichen reagieren kann als in der Standard-Einstellung
(Sendepuffergre 2 Zeichen).

Durch Abfrage von Bit 0 im dritten Byte des IOCTL$-Strings kann
festgestellt werden, ob der Treiber gerade im XOFF-Status ist, so
da im Moment kein Zeichen gesendet werden kann (siehe nchstes
Kapitel). Ein Anwenderprogramm kann dadurch verhindern, da es
"hngt", nachdem die Gegenstation ein XOFF-Zeichen gesendet hat.

Wenn der Empfangspuffer (normalerweise 2048 Zeichen) halb voll wird,
sendet der Treiber ein XOFF-Zeichen, um die Gegenstation anzuhalten.
Sobald das Anwenderprogramm den Empfangspuffer soweit geleert hat,
da er nur noch zu einem Viertel gefllt ist, sendet der Treiber ein
XON-Zeichen.

Das Senden eines XOFF-Zeichens (sobald der Empfangspuffer halb voll
wird) erfolgt im Hintergrund, d.h. innerhalb einer Interrupt-
Routine, und funktioniert daher auch, wenn das aufrufende
Anwenderprogramm gerade anderweitig beschftigt ist. Wenn es jedoch
gerade selbst Strings ohne Pause zwischen den einzelnen Zeichen
sendet, wird kein XOFF-Zeichen ausgegeben, um Konflikte mit dem
gesendeten String zu vermeiden.


Hardware-Handshake

Der Treiber kann ein RTS-/CTS-Hardware-Handshake automatisch
durchfhren, wenn er beim Laden mit der Option H passend
konfiguriert wurde. Das Puffer-Verhalten entspricht dem bei
XON/XOFF. Das Hardware-Handshake ist nicht per IOCTL-Anweisung ein-
oder ausschaltbar. Die Option H sollte nicht bei RS485-Karten
eingesetzt werden; fr diese ist die Option Z vorgesehen. Ebenso
sollte nie XON/XOFF (Option X) und RTS/CTS (Option H) gleichzeitig
Zeit aktiviert werden - das wre auch wenig sinnvoll.


Abfrage von Statusangaben

Die IOCTL-Parameter-bergabe funktioniert auch in der anderen
Richtung, also vom Treiberprogramm zum aufrufenden Anwenderprogramm,
in Basic z.B. so:

		E$=IOCTL$(1)

Diese Anweisung holt vom V.24-OEM-Treiber einen stets vier Byte
langen String, der folgendermaen aufgebaut ist:

1. und 2. Byte:	Zahl der Zeichen im Puffer (binr, low/high):
		L=ASC(E$)+256*ASC(MID$(E$,2,1)) oder, etwas
		schneller: L=CVI(LEFT$(E$,2))

3. Byte:	Status der Schnittstelle (binr):
		Bit 0 = Sender im XOFF-Status (wenn Bit=1)
		Bit 1 = Parity-Fehler aufgetreten
		Bit 2 = Framing-Fehler aufgetreten
		Bit 3 = Break empfangen (d.h. RxD = 0)
		Bit 4 = CTS (Clear To Send)
		Bit 5 = DSR (Data Set Ready)
		Bit 6 = RI  (Ring Indicator)
		Bit 7 = CD  (Carrier Detect)
		Das zur Abfrage (UND-Verknpfung) erforder-
		liche "Masken-Byte" ist je nach Bit:

		Bit-Nr.		0  1  2  3  4  5  6  7
		UND-Maske	1  2  4  8  16 32 64 128

		Zum Beispiel ist eine CTS-Abfrage so mglich:
		IF(ASC(MID$(E$,3,1)))AND 16 THEN PRINT"CTS=1"

		Wenn Bit 0 = 1 ist (XOFF-Status), knnen kei-
		ne Zeichen gesendet werden, bis die Gegensta-
		tion ein XON-Zeichen sendet oder das XON-/
		XOFF-Protokoll ausgeschaltet wird. Ein Test
		dieser Bedingung ist wie folgt mglich:
		IF(ASC(MID$(E$,3,1)))AND 1 THEN PRINT"XOFF!"

4. Byte:	Empfangs-Status des Treiberprogramms (ASCII):
		" " (Leerraum, dez. Code 32) = kein Fehler,
		"E" = Parity-/Framing-Fehler oder Break
		"B" = Empfangspuffer-berlauf

		Beispiel zum allgemeinen Fehlertest:
		IF RIGHT$(E$,1)<>" "THEN PRINT"Fehler!!!"

Das Lesen des Fehlercodes ist nur einmal mglich, da jede IOCTL-
Leseanweisung den Fehlerstatus automatisch wieder lscht. Das gilt
auch fr die Bits 1 bis 3 im IOCTL-Byte 3.

Nach einem Pufferberlauf (Fehlerstatus B) befinden sich jeweils die
letzten 2047 Bytes noch im Puffer (bei einer Pufferlnge von 2048
Zeichen). Der Fehlerstatus E gibt an, da seit dem letzten Lesen des
IOCTL-Strings ein Paritts- oder Framing-Error auftrat; es ist
jedoch nachtrglich nicht mglich, noch festzustellen, welches
empfangene Zeichen hierfr die Ursache war.


Beispielprogramme

Die mitgelieferte Diskette enthlt Beispielprogramme in GW-Basic,
Turbo-Pascal, Microsoft-C und Assembler. Alle drei Programme
(CMTERM.BAS, CMTERM.PAS, CMTERM.ASM) eignen sich als einfache
Terminal-Emulationen. Steuerzeichen wie z.B. Backspace werden
allerdings nicht untersttzt. Voreingestellt ist jeweils die erste
serielle Schnittstelle. Verbindet man an ihr die Pins 2 und 3
miteinander, so mssen die an der Tastatur eingegebenen Zeichen
sofort wieder auf dem Bildschirm sichtbar werden.


GW-Basic: CMTERM.BAS

Das folgende Listing zeigt die Basic-Version des Terminalprogramms.
(Sie kann auch mit Quickbasic compiliert werden.)

100 ' --- BEISPIELPROGRAMM FR V.24-OEM [SHAMROCK/FE/88-92] ---
105 '
110 ' --- Schnittstelle fr I/O ffnen (hier fr RS1=COM1) ---
115 ' Parameter zunchst: 2400 Bd, 8N1
120 OPEN"I",1,"RS1":OPEN"O",2,"RS1X":IOCTL#1,"I5B-" ' DTR noch=0
125 CLS:PRINT"TERMINALPROGRAMM (F10=Ende)":PRINT:KEY 10,""
130 '
135 ' --- Parameter evtl. ndern ---
140 INPUT"1=110,2=300,3=600,4=1200,5=2400,6=4800,7=9600 Bd";E$
145 IF E$>"0"AND E$<="7"THEN IOCTL#1,E$
150 INPUT"A=8N2,B=8N1,C=7N2,D=7N1,E=7E1,F=7O1,G=8E1,H=8O1";E$
155 IF E$>"A"AND E$<="h"THEN IOCTL#1,E$
160 IOCTL#1,"+":PRINT"Terminal bereit" ' DTR+RTS=1
165 '
170 ' --- Programm-Hauptschleife ---
175 E$=IOCTL$(1):L=ASC(E$)+256*ASC(MID$(E$,2,1))' Zeichenzahl
180 I$=RIGHT$(E$,1):IF I$="B"THEN PRINT:PRINT"Pufferberlauf!"
185 IF I$<>"E"THEN 210 ELSE E=ASC(MID$(E$,3,1)):BEEP:PRINT
190 IF E AND 2 THEN PRINT"Parity-Fehler!"
195 IF E AND 4 THEN PRINT"Framing-Fehler!"
200 IF E AND 8 THEN PRINT"Break empfangen!"
205 IF L>255 THEN L=255 'Max. Stringlnge = 255 Zeichen
210 IF L>0 THEN PRINT INPUT$(L,1); ' Pufferinhalt anzeigen
215 E$=INKEY$:IF E$=""THEN 175 ' Taste gedrckt?
220 IF ASC(E$)=0 THEN IF RIGHT$(E$,1)="D"THEN 230 ELSE 175 'F10?
225 PRINT#2,E$;:GOTO 175 ' Zeichen senden
230 CLOSE 1:CLOSE 2:PRINT:PRINT"Programm beendet":END


Hinweise zu QBasic, QuickBasic und Visual Basic

Der Quickbasic- und Visual-Basic-Compiler sowie der QBasic-
Interpreter von Microsoft knnen keine CTRL-Z-Steuerzeichen
ausgeben, wenn man den Ausgabekanal mit OPEN ... FOR OUTPUT ffnet.
Das Problem tritt nicht auf, wenn der Kanal mit OPEN ... FOR BINARY
geffnet wird; dann kann sogar der gleiche Kanal zum Schreiben und
Lesen verwendet werden. Allerdings eignen sich dafr nicht mehr
INPUT#, INPUT$ und PRINT, sondern GET# und PUT# (siehe Compiler-
Handbuch). - WINTERM ist ein einfaches Terminal-Programm fr Visual
Basic unter Windows. Laden Sie den Treiber dafr mit der Option
T0:\1A. Dadurch wird bei leerem Empfangspuffer ohne Wartezeit ein
CTRL-Z-Zeichen zurckgeliefert. Das ist ntig, weil Visual Basic
keine IOCTL-Anweisungen zur Statusabfrage kennt.


Turbo-Pascal: CMTERM.PAS

Das folgende Beispielprogramm ist in Turbo-Pascal 4.0 geschrieben.
Der "etwas" grere Umfang der Pascal-Version rhrt vor allem daher,
da die in GW-Basic vorhandenen IOCTL-Anweisungen erst als neue
Prozeduren definiert werden mssen. Auch dieses Programm ist
zunchst fr die erste serielle Schnittstelle ausgelegt, da es RS1
und RS1X als Namen fr die Treiberprogramme verwendet.

Eine Besonderheit ist der MS-DOS-Aufruf mit AX=$4401, der dazu
dient, das Betriebssystem in den "raw mode" zu versetzen.
Andernfalls wre MS-DOS 3.x nicht in der Lage, ber ein CTRL-Z-
Zeichen hinaus von einem logischen Gert zu lesen. (Dieses Problem
tritt in MS-DOS 2.11 nicht auf, ebenso nicht in GWBASIC unter MS-DOS
3.11, weil Basic diesen MS-DOS-Aufruf intern automatisch
durchfhrt.)

Wir empfehlen Ihnen, Programme, die zur Weitergabe an Kunden
bestimmt sind, grundstzlich so zu schreiben, da sie unabhngig von
der MS-DOS-Versionsnummer funktionieren. Verwenden Sie deshalb stets
die IOCTL-Anweisung "I" nach einer OPEN-Anweisung, und bernehmen
Sie den MS-DOS-Aufruf $4401 auch dann, wenn Ihr Kunde (noch) mit MS-
DOS 2.11 arbeitet.


{ TERMINAL PROGRAM FOR V.24-OEM WITH TURBO PASCAL 4/5/6 }
{ (C) SHAMROCK SOFTWARE/FE 1988-90 }

program CMTERM;
uses dos, crt;
type
 iotyp = string[4];                 {format of ioctl string}
var
 comnr, comxnr: text;               {file handles for RS232}
 i,l: integer; iostat: iotyp;
 var regs: registers;
 ch,buffer: char; leave: boolean;
{V-} {this switch allows different length of ioctl string}

function getbx(var handle:text):integer; {GET MS-DOS HANDLE }
var ad,sg:integer;
begin
 ad:=ofs(handle); sg:=seg(handle);       {address of block}
 getbx:=mem[sg:ad]+256*mem[sg:ad+1];     {handle=1st 2 bytes}
end;

procedure ioctlin(var handle:text; var io:iotyp);
begin                                    { GET IOCTL STRING }
 regs.bx:=getbx(handle);                 {get handle into bx}
 regs.ax:=$4402;                         {function 44H, read}
 regs.dx:=ofs(io)+1; regs.ds:=seg(io);
 msdos(regs);                            {call INT 21H}
end;                                     {status in iostat}

procedure ioctlout (var handle:text; var io:iotyp);
begin                                    { SEND IOCTL STRING }
 regs.bx:=getbx(handle);                 {get handle into bx }
 regs.ax:=$4403; regs.cx:=length(io);    {funct. 44H,03=write}
 regs.dx:=ofs(io)+1; regs.ds:=seg(io);   {address of string}
 msdos(regs);                            {call INT 21H}
end;

begin                                    { PROGRAM BODY }
 assign(comnr,'RS1');                    {sets turbo buffer..}
 settextbuf(comnr,buffer);               {..to only one byte }
 reset(comnr);                           {open RS1  for read }
 assign(comxnr,'RS1X'); rewrite(comxnr); {open RS1X for write}
 regs.bx:=getbx(comnr);
 regs.ax:=$4401; regs.dx:=$00e0;         {ignore CTRL-Z..}
 msdos(regs);                            {..when in DOS >2.X!}
 regs.bx:=getbx(comxnr);
 regs.ax:=$4401; regs.dx:=$00e0;
 msdos(regs);
 writeln('Terminal, ESC=End'); leave:=false;
 iostat:='I6B+'; ioctlout(comnr,iostat); {Init driver}

 while not leave do begin                {TERMINAL MAIN LOOP}
  ioctlin(comnr,iostat);                 {get driver status}
  l:=ord(iostat[1])+256*ord(iostat[2]);  {char.count i.buff.}
  if l>0 then begin
   read(comnr,ch);                       {read character}
   if ch<>chr(10) then write(ch);        {display if not LF}
   if ch=chr(13) then write(chr(10));    {add LF if CR}
  end {if};
  if KeyPressed then begin
   ch:=readkey;                          {get key if pressed}
   if ch=chr(27) then leave:=true;       {ESC = end program}
   write(comxnr,ch);                     {send character}
  end {if};
 end {while};
end {program}.


Microsoft-C, Turbo-C:  CMTERM.C

Das folgende Programmbeispiel zeigt, wie man IOCTL- und Daten-
Strings in C von und zum Treiber bergeben kann. Es realisiert ein
einfaches Terminal-Programm, das ber die Tastatur eingegebene
Zeichen sendet und umgekehrt empfangene Zeichen auf dem Bildschirm
darstellt. Die Struktur ioc dient zur Aufnahme des vom Treiber
bergebenen Status, der u.a. die Zahl der im Empfangspuffer
befindlichen Zeichen enthlt.

Der Microsoft-C-Compiler bietet keine IOCTL-Funktionen an. Sie
lassen sich aber leicht implementieren:
a) Abholen des Treiberstatus (4 Byte)
regs.h.ax=0x4402; regs.x.bx=fileno(f);regs.x.cx = 4;
regs.x.dx=Offset eines 4-Byte-Arrays; regs.x.ds=Seg.d.Arrays;
intdosx (&regs,&regs,&segregs);
b) Setzen von Parametern im Treiber
regs.h.ax=0x4403; regs.x.bx=fileno(f); regs.x.cx=Stringlnge;
regs.x.dx=Offset des Param.-Strings; regs.x.ds=Seg.Par.-Str.;
intdosx (&regs,&regs,&segregs);


/* Einfaches Terminal-Programm in Borland- bzw. Turbo-C */
#include <stdio.h>
#include <io.h>
#include <conio.h>
FILE *f;
int run = 1; char *ini; char ch;
struct ioc { unsigned int cnt; char port; char status; };
struct ioc iocin; 	   /* Struktur fr IOCTL-Status */
main()
{
 printf("\nTerminal-Programm fr V.24-OEM (ESC = Ende)\n\n");

 f=fopen("RS2","r+b");     /* Hier RS2 fr COM2 */
 if (f==NULL) { printf("Treiber nicht geladen!\n"); return 1; }
 setbuf(f,NULL); 	   /* Stream nicht puffern! */
 ini = "6B"; 		   /* Baudrate+Datenformat */
 ioctl (fileno(f),3,ini,strlen(ini));
 while (run) 		   /* Terminalschleife... */
 {
  ioctl(fileno(f),2,&iocin,4);
  if (iocin.status != 32)  /* Status=OK? */
   printf("\nStatus=%c\n",iocin.status);
  while (iocin.cnt)        /* Was empfangen? */
  {
   fread(&ch,1,1,f);       /* Ja, lesen+anzeigen */
   printf("%c",ch); iocin.cnt--;
  };
  if (kbhit())		   /* Taste? */
  {
   ch = getch();
   if (ch==27) run=0 ;     /* ESC=Programmende */
   else fwrite(&ch,1,1,f); /* Tastendruck senden */
  }
 }
 fclose (f);
 printf("\nProgramm beendet.\n");
 return 0;
}


Sonstige Hinweise zu hheren Programmiersprachen

	In C gibt es Compiler-abhngige Probleme bei der Behandlung von
Line-Feed- und Return-Steuerzeichen, da C teilweise Line Feed statt
Return als Zeilen-Ende annimmt. Dieses Problem hat aber berhaupt
nichts mit dem V.24-Treiber zu tun, sondern ausschlielich mit der
jeweiligen C-Implementation (beachten Sie dazu bitte die Hinweise im
Handbuch Ihres Compilers).

	Die EOF-Funktion in C, Basic oder Pascal gibt nicht an, ob sich
Zeichen im Empfangspuffer befinden, sondern nur, ob ein CTRL-Z-
Steuerzeichen (Dezimalcode 26) empfangen wurde. Die Zahl der Zeichen
im Empfangspuffer ist nur mit Hilfe einer IOCTL-Anweisung
ermittelbar.

	Viele C-, Pascal- und Cobol-Compiler sind so voreingestellt, da
sie nicht nur fr Dateien, sondern auch fr Gertetreiber
unsinnigerweise zustzlich einen internen Puffer ffnen. Wenn man
ihn nicht mit "setbuf" (in C), "SetTextBuf" (Pascal) oder "Rewind"
(Cobol) deaktivert, fhrt er zu erheblichen Problemen.

	Die Basic-Anweisung ON COM GOSUB ist mit V.24-OEM nicht
verwendbar, da sie keine echte Interrupt-Anweisung ist, sondern
lediglich im Polling-Modus einen internen Puffer abfragt, der von
den Basic-typischen OPEN"COM"-Routinen verwaltet wird.

	Unter Windows ist erfahrungsgem selbst auf schnellen Rechnern
eine Baudrate ab 9600 Bd ohne Zeichenverluste nicht sicher mglich;
hnliches gilt fr OS/2. Bei gleichzeitiger Verwendung mehrerer
Schnittstellen liegt die Grenze noch erheblich niedriger. Der Grund
ist die komplizierte Interrupt-Behandlung im Protected Mode der
80X86-Prozessoren. Fr geschwindigkeitskritische Anwendungen wird
deshalb dringend von Windows oder OS/2 abgeraten; diese Systeme
wurden von Anfang an nie fr Echtzeitanwendungen konzipiert.

  GFA-Basic-Versionen vor 4.43 "verschlucken" aufgrund eines
compiler-internen Fehlers manchmal Zeichen. Verwenden Sie bitte
ausschlielich sptere Compiler-Versionen. - Ein Beispiel mit GFA-
Basic finden Sie auf der Diskette; wegen des Fehlens von IOCTL-
Anweisungen wird die gesamte Ein-/Ausgabe dabei ber eigene
Prozeduren mit Hilfe des DOS-Interrupts INT 21H abgewickelt.

	Turbo-Basic (alias Power Basic) hat in allen uns bekannten
Versionen den Fehler, da es schon bei OPEN versucht, 128 Bytes
einzulesen, und ist deshalb mit Gertetreibern generell nicht
verwendbar - also auch nicht mit V.24-OEM.

	Vermeiden Sie bei hohen Baudraten mglichst eine zeichenweise
Verarbeitung. Die bergabe ganzer Strings funktioniert erheblich
schneller.


Assembler: CMTERM.ASM

Die Assembler-Version des einfachen Terminalprogramms verwendet
Unterprogramme zur IOCTL-Ein- und Ausgabe. Der Aufruf INT 21H mit
AX=4401H schaltet wie im Turbo-Pascal-Beispiel das Betriebssystem in
den "raw mode" (Transparent-Modus). Der Einfachkeit halber wird
angenommen, da IOCTL-Kommandos immer genau vier Zeichen lang sind.
Im Gegensatz zu Basic und Pascal ist es hier nicht ntig, getrennte
Open-Anweisungen zum Lesen und Schreiben zu verwenden.


;Einfaches Terminalprogramm
;fr COM1 (300 Baud, 8N1, Vollduplex)

code    segment
        assume cs:code,ds:code
        org 100h

start:  mov ax,3d02h    ;R/W-Open
        mov dx,offset rsname
        int 21h
        jc openerr      ;Fehler?!
        mov bx,ax       ;BX=Handle
        mov ax,4401h
        mov dx,00e0h    ;CTRL-Z
        int 21h         ;ignorieren
        call ioctlout   ;Baudrate usw.
        mov dx,offset hello
        mov ah,9        ;Text ausgeben
        int 21h
receive:call ioctlin    ;Zch.im Puffer?
        cmp word ptr ioctl,0
        jz send         ;nein
        call getch      ;ja,holen
        call display    ;und anzeigen
send:   mov ah,1        ;Taste gedr.?
        int 16h         ;(Z148 braucht
        sti             ;STI nach INT 16H)
        jz receive      ;nein
        mov ah,0
        int 16h         ;ja,lesen
        sti
        cmp al,0        ;Sondertaste?
        je receive      ;ja,ignorieren
        cmp al,27       ;ESC?
        je leave        ;ja,Ende!
        call sendch     ;nein,senden
        jmp short receive
openerr:mov dx,offset opentxt
        mov ah,9        ;Fehlermeldung
        int 21h
        int 20h         ;zu MS-DOS
leave:  mov ah,3eh      ;Close RS232
        int 21h         ;mit BX=Handle
        int 20h         ;zu MS-DOS

;----------------------------------
;Unterprogramm:1 Zeichen empfangen
getch:  mov cx,1        ;1 Zeichen
        mov dx,offset dta
        mov ah,3fh      ;Read
        int 21h
        mov al,dta      ;AL=Zeichen
        ret

;Unterprogramm: 1 Zeichen senden
sendch: mov cx,1        ;1 Zeichen
        mov dta,al
        mov dx,offset dta
        mov ah,40h      ;Write
        int 21h
        ret

;Unterprogramm: IOCTL lesen
ioctlin:mov ax,4402h
        jmp short ioctlf

;Unterprogramm: IOCTL schreiben
ioctlout:mov ax,4403h   ;BX=Handle!
ioctlf: mov cx,4        ;4 Byte
        mov dx,offset ioctl
        int 21h
        ret

;Unterprogramm: 1 Zeichen anzeigen
display:cmp al,10       ;LF?
        je disp2        ;ignorieren!
        cmp al,13       ;CR?
        jne disp1
        call disp1      ;ja,erst CR
        mov al,10       ;dann LF
disp1:  push bx
        mov bl,7        ;Farbe=7
        mov ah,0eh
        int 10h         ;ROM-BIOS
        pop bx
disp2:  ret

opentxt db 7,'Treiber geladen?$'
hello   db 'SHAMROCK SOFTWARE - V.24-OEM'
        db 13,10,'TERMINAL-PROGRAMM '
        db '(ESC=Ende)',13,10,'$'
rsname  db 'RS1',0      ;hier fr COM1
ioctl   db 'I2B+'       ;immer 4 Bytes!
dta     equ this byte   ;Transfer-Adresse
code    ends
        end start


User-Interrupt

Fr spezielle Anwendungen ist es mglich, immer dann, wenn ein
bestimmtes Zeichen empfangen wird, einen frei definierbaren
Interrupt auszulsen, um eine anwendungsspezifische Routine
auszufhren. Maximal kann dies allerdings 18,2mal je Sekunde
erfolgen, da dieser User-Interrupt aus der internen Systemzeit-
Interrupt-Routine aufgerufen wird (der serielle Empfangs-Interrupt
selbst wre allzu zeitkritisch).

Der gewnschte Zeichencode und die Interrupt-Nummer knnen jeweils
zweistellig hexadezimal beim Laden des Treibers in CONFIG.SYS
angegeben werden. Ein Beispiel:

		DEVICE = V24.SYS U1A,7B

Hier wird immer bei Empfang des Zeichens 1A (Ctrl-Z) der Interrupt
7B aufgerufen. Der Zeichencode FF ist reserviert und wird nicht
akzeptiert, ebenso sind Interrupts unterhalb hex 44 unzulssig, da
sie vom System belegt sind (wir empfehlen Interrupts von 7B bis 7E,
diese sind gewhnlich unbenutzt).

Der so konfigurierte Interrupt zeigt nach dem Laden zunchst auf
eine IRET-Anweisung innerhalb des Treibers. Ein Anwenderprogramm
kann den Interrupt-Vektor spter auf eine eigene Routine umlenken.
Am Ende des Anwenderprogramms sollte der vorherige Inhalt des
Interrupt-Vektors unbedingt wiederhergestellt werden (auch bei
unvorhergesehenen Programm-Abbrchen z.B. nach Laufzeit-Fehlern!).

Der Interrupt-Routine im Anwenderprogramm werden in vier Registern
folgende Informationen bergeben:

 AX    = aktueller Stand des Puffer-Schreibzeigers
 BX    = aktueller Stand des Puffer-Lesezeigers
 CX    = konfigurierte Lnge des Empfangspuffers
 DS:DX = absolute Anfangsadresse des Empfangspuffers

Die Interrupt-Routine mu den Lesezeiger BX entsprechend korrigiert
zurckgeben, wenn sie Zeichen aus dem Puffer gelesen hat.

Um festzustellen, wieviele Zeichen (n) sich gerade im Empfangspuffer
befinden, ist folgender Algorithmus ntig (hier programmiersprachen-
neutral formuliert):

  n := AX - BX;		IF n < 0 THEN n := n + CX

Um das jeweils nchste Zeichen c aus dem Empfangspuffer zu lesen,
eignet sich folgender Algorithmus:

  c := DS:[BX+DX];  BX := BX + 1;  IF BX = CX THEN BX := 0

Hierbei wird c aus der Speicherstelle [BX+DX] im Segment DS gelesen.
Die Interrupt-Routine darf nie lnger als 50 ms dauern. Sie darf die
Segment-Register sowie SI, DI und BP nicht verndern. Der Aufruf von
DOS- und BIOS-Funktionen aus der Interrupt-Routine ist nicht
zulssig. Wir empfehlen, die Routine in Assembler zu formulieren.
Sie mu mit einem IRET-Befehl enden (also nicht mit RET oder RETF).
Bei Miachtung dieser Punkte wird sich der Rechner unweigerlich
aufhngen.



Die V.24-Schnittstelle

Das V.24-OEM-Treiberprogramm lt prinzipiell eine 3-Draht-
Verbindung an der V.24-Schnittstelle zu (GND = Bezugspotential =
Masse, TXD = Sendedaten, RXD = Empfangsdaten). Alle brigen
Leitungen dienen ausschlielich Steuerzwecken und knnen bei Bedarf
abgefragt (DSR, CTS, CD, RI) oder gesetzt werden (DTR, RTS). Die
Pinbelegung der hier erwhnten Leitungen geht aus folgender
bersicht hervor (sie entspricht der Lage der Pins an einer V.24-
Buchse).


Pinbelegung

			o 1
		o 14
			o 2 TXD (Sendedaten)
		o
			o 3 RXD (Empfangsdaten)
		o
			o 4 RTS (Request To Send, zum Modem)
		o
			o 5 CTS (Clear To Send, vom Modem)
		o
			o 6 DSR (Data Set Ready, vom Modem)
		o
DTR (Data Terminal	o 7 GND (Ground=Masse, vom/zum Modem)
Ready,zum Modem)o 20
			o 8 CD  (Carrier Detect, vom Modem)
		o
			o
RI (Ring Indi-	o 22
cator,vom Modem)	o
		o
			o
		o
			o
		o 25
			o 13


Pin 1 ist im jeweiligen Gert meist mit dem Gehuse (Schutzkontakt!)
verbunden. Es ist normalerweise aber nicht erforderlich, auch ihn zu
verdrahten, da Pin 7 als Bezugspotential ausreicht.

Theoretisch erlaubt die CCITT-V.24-Norm eine noch grere Zahl von
Steuerleitungen, beispielsweise sieht sie auch Taktleitungen fr
synchrone bertragung (z.B. X.25-Protokoll) vor. Die in IBM-
kompatiblen PCs und ATs verwendeten V.24-Interfaces untersttzen
jedoch nur die oben genannten Leitungen und sind auch nicht fr
synchrone bertragung mit externem Takt geeignet.

Manche Schnittstellen-Karten, insbesondere solche fr COM2 und COM4
sowie Multifunktionskarten, besitzen keinen normgerechte DB25-
Stecker als Ausgang, sondern eine neunpolige DB9-Buchse. Das
entspricht zwar nicht der CCITT-Norm, reicht aber prinzipiell aus,
da auch eine neunpolige Buchse alle erforderlichen Leitungen zur
Verfgung stellt. Wenn man ein Adapter-Kabel herstellen mchte, das
am einen Ende einen neunpoligen Stecker (z.B. fr einen IBM-AT) und
am anderen Ende einen 25poligen besitzt (z.B. fr ein Modem), dann
sind folgende Verbindungen ntig:

	Pin		Name der	Pin
	9polig		Leitung		25polig

	1		CD		8
	2		RXD		3
	3		TXD		2
	4		DTR		20
	5		GND		7
	6		DSR		6
	7		RTS		4
	8		CTS		5
	9		RI		22


Bedeutung der Leitungen

GND	Gemeinsames Bezugspotential fr alle Signale (0 V).
TXD	Sendedaten; Ruhelage -12 V = log. 1. Jedem Zeichen ist ein
Startbit (log.0 = + 12 V) voran- und 1...2 Stopbits (log.1)
nachgestellt. Die sieben oder acht Datenbits werden mit dem
niederwertigsten Bit (Bit 0) zuerst gesendet.
TXD	Empfangsdaten (Datenformat natrlich wie TXD).

Bei den folgenden Leitungen entspricht "wahr" (log. 1) einem
elektrischen Pegel von + 12 V und "nicht wahr" (0) einem Pegel von -
12 V:

DTR	Computer sendebereit.
RTS	Computer empfangsbereit (Halbuplex-Modem: Senden).
CTS	Modem sendebereit.
DSR	Modem empfangsbereit bzw.an die Leitung geschaltet.
CD	Modem stellt Trger-Ton der Gegenstation fest.
RI	Das Telefon klingelt, ein Anruf liegt vor.

(Insbesondere bei Hayes-kompatiblen Modems werden die
Steuerleitungen nicht immer korrekt nach CCITT-Vorschrift
untersttzt, insbesondere CD, CTS und DTR.)

Mchte man zwei Computer miteinander verbinden, so ist ein
sogenanntes Nullmodem ntig - das ist schlicht ein Kabel, bei dem
einige Leitungen miteinander vertauscht sind:

	Computer A		Computer B
	Name	DB25		DB25	Name

	GND	7		7	GND
	TXD	2		3	RXD
	RXD	3		2	TXD
	RTS	4		5+8	CTS+CD
	CTS+CD	5+8		4	RTS
	DSR	6		20	DTR
	DTR	20		6	DSR

Zur Simulation des Zustands "Anruf liegt vor" (RI=1) kann RI (Pin
22) kurzzeitig, z.B. ber eine Taste, mit DTR des anderen Rechners
bzw. mit DSR desselben Rechners (Pin 6) verbunden werden.


Verwendung von Steuerzeichen

Die V.24-OEM-Treiberprogramme sind bei ausgeschaltetem XON/XOFF-
Protokoll vollstndig transparent, fangen also keine Steuerzeichen
ab. Das aufrufende Anwenderprogramm kann dadurch auf bestimmte
Steuerzeichen bei Bedarf individuell reagieren. Ist die bertragung
von Binrdateien vorgesehen, so sollte dies mit einer Wortlnge von
8 Datenbits und ohne das Abfangen von Steuerzeichen geschehen. (Das
Datex-P-Netz der deutschen Bundespost akzeptiert ber PADs nur 7-Bit-
Zeichen, ein Binr-Transfer ist deshalb nicht mglich.)

Bei Textdateien, die selbst keine Steuerzeichen (auer CR und LF)
enthalten, ist eine Steuerung der bertragung mit Hilfe des XON/XOFF-
Protokolls mglich, das beim Treiberprogramm mit dem IOCTL-Kommando
X ein- und mit Y ausgeschaltet werden kann:

	Zeichen	Dez.Code    Bedeutung

	XOFF	19 (CTRL-S) bertragung anhalten
	XON	17 (CTRL-Q) bertragung weiterlaufen lassen


IBM- und ISO-Zeichencode

Die International Standards Organisation (ISO) hat fr den
nationalen Datenverkehr in Deutschland einen Code genormt, der auch
mit 7 Bits die Darstellung deutscher Umlaute gestattet und identisch
mit dem entsprechenden DIN-Vorschlag ist. Gegebenenfalls mu das
Anwenderprogramm also eine Zeichensatz-Anpassung nach folgender
Tabelle durchfhren (dez.):

Zeichen	IBM-PC	ISO			Zeichen	IBM-PC	ISO
   	 142	91			   	 132	123
   	 153	92			   	 148	124
   	 154	93			   	 129	125
   	  21	64			   	 225	126

Folgende Zeichen stehen im ISO- bzw. DIN-Code wegen der berdeckung
mit Umlautcodes nicht zur Verfgung: @ [ \ ] { | } 7E  (und
natrlich auch alle IBM-Grafikzeichen!).

(c) Shamrock Software GmbH
