Die Sache mit den 1200 Baud... --------------------------------
Diesmal wollen wir uns ein wenig um ein
Problem kümmern, vor dem manche von
Ihnen bestimmt schon einmal standen, als
sie Ihr neues 1200- Baud-Modem ausprobieren wollten, und stolz im Terminalprogramm die Baudrate "1200" einstellten, um anschließend entstäuscht zu werden, als Sie nämlich einen Haufen wirre
Zeichen auf dem Bildschirm sahen. Dabei
steht doch groß und breit im Handbuch, daß der C64 bis 2400 Baud serielle Daten
übertragen kann, und dann so etwas ! ! !
Jetzt einmal im Ernst : Tatsächlich ist
es so, daß wenn Sie versuchen, ein
1200- Baud-Modem mit Ihrem 64 er zu
betreiben, es zu Übertragungsfehlern
kommen kann. Anfangs sieht ein
übertragener Text zwar noch ganz normal
aus, doch bei genauerem Hinsehen, werden
Sie feststellen, daß hier und da, etwa alle 200 Zeichen, ein kleiner Schub von
wirren Buchstaben und Sonderzeichen im
Text erscheint. Und so soll es ja nun
wirklich nicht sein. Gerade beim
Übertragen von Programmen ( z. B. mit
Hilfe des XModem-Protokolls) kann man
auf eine gewisse Genauigkeit der Übertragung absolut nicht verzichen. Bei
XMODEM erhalten Sie so etwa alle 2 Blocks ( von XModemübertragungsblocks ist
hier die Rede) einen Prüfsummenfehler, und die ganze Übertragung dauert
vielleicht noch länger, als wenn Sie mit
300 Baud gearbeitet hätten. Ich habe
mich nun einmal auf den Weg ins Innerste
des Betriebssystems unseres 64 ers
gemacht, um herauszufinden, woran der
Fehler liegen könnte. Und tatsächlich
bin ich auch fündig geworden ! Ich habe
mir einmal die Routine, die einen Kanal
auf der RS232- Schnittstelle ( also der
seriellen Schnittstelle) öffnet genauer
angeschaut. Zur besseren Erläuterung des
Ganzen sollten Sie wissen, wie der C64
mit der RS232 umgeht und wie er die
Baudraten auf ihr simuliert. Wenn Sie
einen RS232- Kanal öffnen ( hierzu benutzt
man die Geräteadresse #2 im OPEN-Be- fehl), dann passiert folgendes:
Erstens richtet der 64 er zwei Puffer am
Ende des Basicspeichers ein, die jeweils
256 Bytes groß sind. Zweitens aktiviert
er einen Interrupt, den NMI ( steht für
Non Maskable Interrupt - nicht maskierbarer Interrupt) . Der NMI ist quasi ein
Programm, daß in regelmäßigen Zeitabständen vom Prozessor abgearbeitet wird.
Damit dies auch immer rechtzeitig und in
gleichmäßigen Abständen geschieht, hat
der C64 einen sogenannten " Timer" eingebaut, der alle soundsoviel Millisekunden
den Prozessor unterbricht, ihn dazu veranlaßt, seine aktuellen Registerwerte
zwischenzuspeichern und das NMI-Pro- gramm abzuarbeiten. Nach dieser Abarbeitung springt er dann wieder zurück zu
seiner ersten Arbeit und macht dort wei- ter, wo er vorher aufgehört hat. Wozu
jedoch das alles?
Nun, der NMI steuert die gesamte Datenübertragung über die RS232- Schnittstelle. Sollten Sie Daten auf diese
Schnittstelle senden, so schreibt die
Senderoutine des Betriebssystems ( es ist
die BSOUT-Routtine, bei $ FFD2) diese
Daten in einen der oben genannten
Puffer. Der eine ist der Ein-, der
andere der Ausgabepuffer. Die Daten
kommen also in den Ausgabepuffer, wo sie
- vorläufig einmal - stehenbleiben. Wird
jetzt der NMI ausgelöst, so prüft
dieser, ob Daten im Ausgabepuffer stehen. Ist das der Fall, so schickt er
diese auf die RS232- Schnittstelle.
Gleichzeitig sieht er nach, ob von der
RS232 nicht auch noch gerade Daten
eintreffen.
Sollte dies der Fall sein, so greift er
sich diese Daten ab und speichert sie im Eingabepuffer. Nun können diese von dort
aus mit der Einleseroutine des Betriebssystems abgeholt werden ( diesmal ist es
die BASIN-Routine bei $ FFCF) . Die Baudrate, die Sie bei OPEN angeben, bestimmt
nun den Zeitabstand, der zwischen zwei
NMI-Aufrufen besteht.
" Baud" oder " BPS" heißt ja nichts anderes als " Bits Per Second"- also wieviel
Bits in einer Sekunde übertragen werden.
Sind das 300 pro Sekunde (300 Baud), so
so wird der NMI 300 mal in einer Sekunde
aufgerufen. Jedesmal also, wenn ein Bit
übertragen wurde, oder abgesendet werden
muß.
Dieser Zeitabstand zwischen zwei NMIs
muß nun beim Öffnen des RS232- Kanals an
den NMI-Timer weitergegeben werden, damit dieser auch weiß, wann er den
Prozesser zu unterbrechen hat ( daher
auch der Name des NMIs - Interupt ist
englisch und heißt übersetzt " Unterbre- chung") . Diese Zeitwerte sind für die
gängigsten Baudraten im Betriebssystem-ROM des C64 gespeichert.
Das heißt also, daß wenn Sie einen
RS232- Kanal, mit zum Beispiel 300 Baud, öffnen, der 64 er sich aus seiner ROM-Tabelle den Zeitwert holt, der für
diese Übertragungsgeschwindigkeit nötig
ist, und ihn in den Timer übergibt.
So wird ebenfalls bei 1200 Baud verfahren, doch stoßen Sie dann auf den oben
beschriebenen Fehler. Sie ahnen vermutlich schon, woran es liegt:
Der gespeicherte Timerwert für 1200 Baud ist ganz einfach FALSCH. Ich habe
einmal nachgerechnet und herausgefunden, daß mit dem gespeicherten Wert
etwa eine Übertragungsgeschwindigkeit
von 1198 Bits pro Sekunde simuliert
wird. Und genau diese 2 fehlenden Bits
führen zu den uns bekannten Fehlübertragungen, da der Computer auf der an- deren Seite des Kabels von uns ja erwartet, daß wir mit vollen 1200 Baud senden. Wie können wir nun diesen Fehler
beseitigen, so daß es für uns keine
Probleme mehr in dieser Hinsicht gibt?
Nun, da gibt es drei Möglichkeiten, die
ich im Folgenden durchgehen werde und
die alle ihre Vorund Nachteile haben.
Fangen wir also an:
Da wäre zuerst einmal die einfache, softwaremäßge Methode. Wie Sie vielleicht wissen, kann man einen RS232- Kanal in BASIC folgendermaßen öffnen:
OPEN 1,2,0,CHR$(6)+chr$(0)
Mit diesem Befehl habe ich nun einen
RS232- Kanal, mit der logischen
Filenummer 1 und mit folgenden Parametern geöffnet:300 Baud,8 Datenbits,1 Stopbit,3- Draht Handshake, Vollduplex, Keine Parität. Kurz geschrieben auch:
300 bd,8 n1 . Sollten Sie sich hierbei noch nicht so gut auskennen, so möchte
ich dies nun erläutern: Beim Öffnen
eines RS232- Kanals ist es zunächst
einmal wichtig, daß Sie im OPEN-Befehl
die Sekundäradresse 2 angeben, damit
OPEN auch weiß, das hier die RS232 gemeint ist, und nicht etwa die Floppy
oder der Drucker. Dann müssen Sie
sozusagen als " Filenamen" zwei Steuerbytes an die OPEN-Routine übergeben.
Diese heißen Kontrollund Befehlsregister, und werden in der hier beschriebenen Reihenfolge angegeben. Da hier
zwei Strings zusammen den Namen bilden, werden die einzelnen Registerbytes mit
mit einem "+"- Zeichen zusammengefügt.
Mit der CHR$- Funktion lassen sich solche
Bytewerte DIREKT übergeben und müssen
nicht noch extra in Buchstaben gewandelt
werden. Die beiden Register werden folgendermaßen berechnet: Zuerst einmal das
Kontollregister. Es gibt die Baudrate, die Anzahl der Datenbits und die Anzahl der Stopbits an. Diese sind folgendermaßen aufgeteilt:
Bit 0-3 : Baudrate Bit 5-6 : Datenbits Bit 7 : Stopbits
Die einzelnen Werte lassen sich nach
folgenden Tabellen berechnen:
a) Baud-Rate :
==============
Bit 3 2 1 0 dez. Wert Baudrate
0 0 0 0 0 User-Baud-Rate
0 0 0 1 1 50
0 0 1 0 2 75
0 0 1 1 3 110
0 1 0 0 4 134.5
0 1 0 1 5 150
0 1 1 0 6 300
0 1 1 1 7 600
1 0 0 0 8 1200
1 0 0 1 9 1800
1 0 1 0 10 2400
b) Anzahl der Datenbits :
=========================
Bit 6 5 dez. Wert Anzahl Datenbits
0 0 0 8 Bits
0 1 32 7 Bits
1 0 64 6 Bits
1 1 96 5 Bits
c) Anzahl der Stopbits :
========================
Bit 7 dez. Wert Anzahl Stopbits
========================================
0 0 1 Stopbit
1 128 2 Stopbits
Möchten Sie nun den Wert Ihres Kontroll- bytes ermitteln, so wählen Sie einfach
Ihre Parameter aus den obigen 3 Tabellen
und addieren Sie jeweils die angegebenen
Dezimalwerte. Das Ergebnis ist der Wert
Ihres Kontrollbytes.
Nun noch die Angaben für das Befehlsregister. Dieses ist ebenfalls in Bits unterteilt, die verschiedene Funktionen
haben, nämlich:
Bit 0 : Handshake Bit 4 : Duplex-Modus Bit 5-7 : Parität
Und hier die 3 Tabellen mit den entsprechenden Werten:
a) Handshake :
==============
Bit 0 dezimal Handshake
0 0 3-Draht-Handshake
1 1 X-Draht-Handshake
Hier wird meistens der 3- Draht-Handshake
verlangt, sollten Sie ein " normales" Modem, oder Akustikkoppler besitzen.
X-Draht wird für eine andere Art der
RS232- Schnittstelle benutzt.
b) Duplex :
===========
Bit 4 dezimal Duplex
0 0 Vollduplex
1 16 Halbduplex
c) Parität :
============
Bit 7 6 5 dez. Parität
0 0 0 0 keine Parität, kein 8.
Datenbit
0 0 1 32 ungerade Parität
0 1 1 96 gerade Parität
1 0 1 160 keine Parität, 8.
Datenbit immer 1
1 1 1 224 keine Parität, 8.
Datenbit immer 0
Verfahren Sie zur Ermittlung des Bytewertes bitte ebenso wie beim Kontrollregister.
Nachdem Sie nun wissen sollten, wie man
einen Kanal auf der RS232 öffnet, möchte
ich nun zu unserem eigentlichen Thema
kommen, nämlich, wie wir den Fehler mit
den 1200 Baud umgehen können. Hier bie
tet sich die Möglichkeit der sogenannten
" User-Baud- Rate" an. Es handelt sich
dabei um die Möglichkeit, eine eigene, beliebige Baudrate an das Betriebssystem
zu übergeben. Sie haben diesen Modus
bestimmt schon in der obigen Tabelle für Baudraten entdeckt. Geben Sie also nun
für die Baudrate ganz einfach den Wert 0 an, so können Sie Ihre eigene Baudrate
definieren, indem Sie dem OPEN-Befehl
noch zwei weitere Bytes anhängen. Diese
enthalten die Werte, die dem Timer übergeben werden sollen, damit dieser die
angegebene Baudrate simulieren kann.
Zunächst einmal benötigen wir den Grundwert für den Timer. Dieser berechnet
sich nach folgender Formel:
Timerwert = 492662 / Baudrate - 101
Anschließend müssen Sie den erhaltenen
Wert noch in LOWund HIGH-Byte umrechnen, was folgendermaßen geschieht:
HIByte = INT( Timerwert /256) LOByte = INT( Timerwert)-256* HIByte
In unserem Fall, für 1200 Baud, sieht
das also folgendermaßen aus:
Timerwert = 492662/1200-101 = 309.55 HI = INT(309.55/256) = 1 LO = 309-256*1 = 53
Öffnen wir doch nun einmal einen RS232- Kanal mit folgenden Parametern, wobei
wir die Baudrate als " User-Baud- Rate" übergeben:
Parameter:
1200 Baud 8 Datenbits 1 Stopbit 3-Draht-Handshake Vollduplex Keine Parität
OPEN 1,2,0, CHR$(0)+ CHR$(0)+ CHR$(53)+ CHR$(1)
Sie sehen, diesmal ist der " Filename"4 Zeichen lang, wobei die letzten 2 Bytes LOund HI-Byte der User-Baud- Rate angeben. Sollten Sie jetzt einmal versuchen mit Ihrem 1200- Baud-Modem zu arbeiten, so werden Sie keine Schwierigkeiten
haben, zu kommunizieren, da wir ja jetzt
die richtige Baudrate eingestellt haben.
Soweit die erste Möglichkeit, den Betriebssystemfehler zu umgehen. In der
nächsten Ausgabe erfahren Sie dann, wie
Sie auch mit Ihren schon vorhandenen
Terminalprogrammen die 1200 Baud realisieren können.
