SCC.PRG, ESCC.PRG, ST_ESCC.PRG
------------------------------

Dies sind Treiber fr die mit einem SCC oder ESCC (z.B. Z8530, Am85C30, 
Z85230) ausgestatteten seriellen Schnittstellen der Ataris und fr die 
Zusatzhardware ST_ESCC. Sie funktionieren zusammen mit DRVIN.PRG oder 
einem gleichwertigen Ersatz. Einfhrende Bemerkungen finden sich in 
1_README.TXT.



Allgemeines
-----------
Als "ESCC" betrachte _ich_ nur den Z85230 und den Am85C230A. Diese 
besitzen nebem dem auf 8 Byte vergrerten EmpfangsFIFO auch einen 
mindestens 4 Byte groen SendeFIFO. Ein ESCC beinhaltet alle Funktionen 
eines SCC.

Die Konfigurationsmglichkeiten der einzelnen *SCC*.PRG unterscheiden sich 
etwas.


Taktrate und Baudraten
----------------------
Ein SCC kann fr die Baudratenerzeugung verschiedene Taktquellen 
verwenden. Die meistbenutzte Taktquelle ist sein Systemtakt PCLK. Dieser 
Takt PCLK betrgt bei einem normalen (so wie von Atari geliefert) MegaSTE, 
TT und Falcon 8MHz (=8000000Hz). Das ist zwar eine schne Zahl, die aber 
zur Erzeugung der hohen Standardbaudraten wenig geeignet ist. Die hohen 
Baudraten im MegaSTE/TT/Falcon werden aus anderen Taktquellen erzeugt. 
Meine Hardware ST_ESCC wird immer mit 14745600Hz getaktet.

Man kann einen MegaSTE, TT oder Falcon mit einem Quarzoszillator und etwas 
Draht auf PCLK=14745600Hz umbauen (Vorschlag von Franz Sirl). Wenn man nur 
die 115200Bd und 57600Bd auf MODEM2 haben will, bietet sich ein 
einfacherer Umbau nur mit Draht an. (### Nein, ich kann das jetzt hier 
nicht beschreiben. Bei Interesse in spteren Versionen.###)

Da also zwei verschiedene Taktraten blich sind, ist der im Computer 
vorhandene PCLK in den Treibern einstellbar.


Bei einem PCLK von 8MHz sind folgende Rsconf-Baudraten mglich:
(neue - alte)
SERIAL2:
115200 - 150
 57600 - 134
 38400 - 110
MODEM2:
 38400 - 110
153600 -  75
 76800 -  50
Bei MegaSTE und Falcon (nicht beim TT) sind zustzlich auf MODEM2:
115200 - 150
 57600 - 134

Bei PCLK = 14745600Hz sind bei MODEM2 und SERIAL2 mglich:
neue Rate   alte Rate
 115200      150
  57600      134
  38400      110
 153600       75
  76800       50

Wenn man die GEMDOS-Fcntl TIOC?BAUD benutzt, hat man ohnehin kein Problem, 
dort erfhrt man, welche Baudraten mglich sind im Klartext als 
"Bit pro Sekunde".

ST_ESCC enthlt immer einen ESCC. MegaSTE/TT/Falcon enthalten nur einen 
ESCC, wenn den jemand extra gewechselt hat. Der Treiber fr den SCC luft 
auch mit dem ESCC-Schaltkreis, umgekehrt nicht.


SCC und ESCC
------------
Zur Erinnerung nochmal: Als "ESCC" betrachte _ich_ nur den Z85230 und den 
Am85C230A. Bei ST_ESCC wird immer ein ESCC eingesetzt. In 
MegaSTE/TT/Falcon befindet sich im Originalzustand nur ein SCC. Zur 
Entlastung der CPU und zur Verbesserung der Datensicherheit (geringere 
Wahrscheinlichkeit von Zeichenverlusten beim Empfang) kann man einen ESCC 
im PLCC-Gehuse einsetzen. SCC und ESCC sind pinkompatibel genug.


SCC.PRG
-------
Der Treiber fr MODEM2 und SERIAL2 des MegaSTE und TT sowie fr die 
einzige durch Atari herausgefhrte RS232-Schnittstelle des Falcon 
(beschriftet mit Modem), wegen ihrer Verwandschaften hier ebenfalls MODEM2 
genannt.

Beim MegaSTE und TT wird momentan NICHT zwischen den Alternativen SERIAL2 
und LAN umgeschaltet sondern einfach davon ausgegangen, da SERIAL2 
eingestellt ist (ist wohl nach Reset der Fall). Wenn man von Hand das 
Soundchipbit auf LAN umschaltet, sollte man fr SERIAL2 auf "kein 
Handshake" schalten, da ich fr die LAN-Schnittstelle noch nichts getan 
habe.

Beim Falcon ist die zweite serielle Schnittstelle nicht umschaltbar, 
sondern fest auf LAN gelegt (auf dem Gert als "LAN" beschriftet). Sie 
wird von diesem Treiber aber als SERIAL2 betrachtet und mte "ohne 
Handshake" nutzbar sein. Es gilt das Gleiche wie fr MegaSTE/TT: Ich habe 
mich mit dieser Schnittstelle und speziell deren Handshakeleitungen noch 
nicht nher befat.

Beim TT (und Falcon, falls man dem einen Beschleuniger mit FastRAM 
spendiert hat) darf SCC.PRG _keinesfalls_ ins FastRAM, da es sonst mit zu 
schnellen Zugriffen auf den SCC Probleme geben kann. Diese Probleme 
knnten sich in Zeichenverlusten, unsinnigem Verhalten oder Bomben uern.


ESCC.PRG
--------
Siehe SCC.PRG. Dieser Treiber ist nur fr die Nutzer, die sich einen 
Z85230 oder Am85C230A eingebaut haben. Der SCC-Treiber funktioniert 
ebenfalls mit dem ESCC, nutzt die ESCC-Vorteile aber nicht aus. Der 
ESCC-Treiber ist fr den SCC sehr ungeeignet!


ST_ESCC.PRG
-----------
Der Treiber nur fr (ich komm mir langsam wie in einer Dauerwerbesendung 
vor) die von mir entwickelte Hardware ST_ESCC, die zwei zustzliche 
schnelle serielle Schnittstellen in ST/STE/MegaST realisiert. 115200Bd 
problemlos mit einem 8MHz/68000 unter TOS, das ist doch was.


Die Konfiguration
-----------------
Die Konfiguration erfolgt durch das SETTER.TTP. Zur Bedienung siehe 
SETTER.TXT.

PCLK
Hier wird eingestellt, ob der SCC-Takt PCLK 8MHz ("Nein") oder 14745600Hz 
("Ja") ist. Bei nicht umgebauten Ataris mssen Sie mit "Nein" antworten. 
Bei ST_ESCC.PRG wird die Frage nicht gestellt.

M2TT
Wenn Sie einen nicht umgebauten (also originalen) TT benutzen, antworten 
Sie mit "Ja". Dann sind auf MODEM2 leider keine 57600Bd und 115200Bd 
verfgbar. Wenn man dan Draht-Umbau gemacht hat, sollte man mit "Nein" 
antworten, genau wie die MegaSTE- und Falcon-User. Bei ST_ESCC.PRG wird 
diese Frage nicht gestellt. Wenn Sie bei PCLK die 14745600Hz angegeben 
haben, ist die Antwort auf diese Frage bedeutungslos.

USE4C
Diese Frage erscheint nur bei ESCC.PRG und ST_ESCC.PRG. Soll ein 
Empfangsinterrupt erst nach 4 empfangenen Zeichen erfolgen? Ich nenne 
diesen Modus, der erst nach 4 Zeichen einen Interrupt auslst, 4ZI. 4ZI 
entlastet bei "RTS/CTS"- und "ohne"- Handshake die CPU wesentlich. Bei 
"XON/XOFF"-Handshake ist er automatisch ausgeschaltet, der Aufwand an 
Sonderbehandlungen htte den Nutzen berstiegen. Neben den Vorteilen 
verkrzt 4ZI aber die freie Lnge des EmpfangsFIFOs von 8 auf 4 Zeichen. 
Nach einer Interruptmeldung des ESCC an die CPU knnen vor einer Reaktion 
der CPU nur noch 4 statt 8 Zeichen verlustfrei empfangen werden. 
Normalerweise schaltet man 4ZI an, antwortet also mit "Ja", da 4 freie 
Zeichen ausreichen und der Gewinn an CPU-Zeit durch die auf 1/4 
reduzierten Empfangsinterrupts wesentlich ist. Wenn man unsaubere 
Programme hat, mu man 4ZI wahrscheinlich immer ausschalten, also hier mit 
"Nein" antworten. Diese unsauberen Programme uern sich durch 
verschiedene Verzgerungen: im Terminalmode kommen erst dann Zeichen auf 
den Bildschirm, wenn es 4 Zeichen sind. Unsaubere bertragungsprotokolle 
hngen einige Zeit (oder ewig) fest, besonders am Anfang oder Ende.

DTRM2:
Das DTR(Data Terminal Ready)-Signal der Schnittstelle MODEM2 wird beim 
Start dieses Treibers einmalig auf den hier angegebenen Wert gesetzt. Eine 
Aktivierung mit "Ja" entspricht der Arbeitsweise des TOS, eine 
Deaktivierung mit "Nein" verhindert das "ungefragte" Abheben eines 
entsprechend konfigurierten Modems.

DTRS2:
Wie DTRM2, aber fr Schnittstelle SERIAL2.

RBLM2:
Wenn man hiermit nichts anzufangen wei, einfach 256 einstellen. Hier wird 
die Empfangspufferlnge der MODEM2-Schnittstelle in Byte eingestellt. Sie 
darf maximal 65534 und minimal 16 betragen. Werte auerhalb dieses 
Bereiches werden auf den Standardwert von 256 gesetzt. Die Lnge wird auf 
eine gerade Zahl abgerundet. Die Wassermarken werden generell auf 1/4 (low 
water mark) und 3/4 (high water mark) gesetzt.

TBLM2:
Wie RBLM2, aber diesmal die Sendepufferlnge.

RBLS2:
Wie RBLM2, aber diesmal fr Schnittstelle SERIAL2.

TBLS2:
Wie RBLM2, aber diesmal die Senderpufferlnge fr Schnittstelle SERIAL2.


Fr Programmierer: Der IOREC
----------------------------
Finger weg von der Bestimmung der lesbaren Byteanzahl ber den IOREC! Das 
geht bei eingeschaltetem 4-Zeichen-Interrupt des ESCC und ST_ESCC voll 
daneben. Immerhin bringt dieser Interruptmodus eine wesentliche 
Systementlastung. Stattdessen FIONREAD oder gleich Fread benutzen, 
funktionieren bei diesen Treibern beide richtig. Bconstat funktioniert 
ebenfalls.

Wenn der Cookie RSVF und in der RSVF-Liste die benutzte Schnittstelle da 
ist, darf man sich darauf verlassen, da FIONREAD funktioniert. Das kann 
der MiNT-User zwar sabotieren, aber dann ist er selbst schuld.

Solange die Fcntl-Funktion zur Vernderung der Puffergre nicht 
implementiert ist, ist es auf jeden Fall legal, die Puffergre und die 
Wassermarken in der IOREC-Struktur zu ndern. Dabei, und nur dabei, sehe 
ich es als legal und erforderlich an, ebenfalls die Schreib- und 
Lesezeiger gemeinsam auf Null zu setzen. Schlielich erwartet man in 
diesem Umstellungsmoment keinen Datenbertragungen mehr.

Es ist denkbar, da irgendwann die IOREC-Benutzung entfllt und durch eine 
sinnvollere Datenstruktur ersetzt wird. Nur ein Beispiel: rckwrts 
laufende Zeiger wrden etwas Zeit einsparen. Aus Kompatibilittsgrnden 
wird wohl eine tote IOREC-Struktur zurckbleiben. Wer aber wirklich sauber 
programmieren will, sollte den Rckgabewert der XBIOS-Funktion IOREC 
testen (oder den Wert des Zeigers in der MAPTAB, wenn man so direkt 
reinfingert). Ist dieser Wert 0 oder ungerade, gibt es bestimmt keinen 
IOREC.


Fr Programmierer: Untersttzte Funktionen
------------------------------------------
Alle Treiber untersttzen inzwischen die TIOCCTL(MAP/GET/SET)-Funktionen 
aus dem SERSOFST.TXT, wenn auch noch nicht fr alle Leitungen und noch 
ohne Callbacks. Aber das lt sich problemlos per TIOCCTLMAP erfragen. 
Welche Fcntl sonst noch untersttzt werden, lt sich ebenfalls durch 
Aufruf feststellen.


Versionen
---------
Wenn nicht extra vermerkt, gelten die Daten fr alle *SCC*.PRG.
1993-11-25
jetzt auch 115200/57600 auf MODEM2 bei MegaSTE/Falcon
ST_ESCC hat nichts sinnvolles zum Konfigurieren, entsprechend dmlich die 
Meldung
1993-12-01
TIOCM_RNG auf MODEM2 bei TT/Falcon/ST_ESCC, TIOCM_RNG auf SERIAL2 fr 
ST_ESCC, kleine Verzgerung fr Siegfried Hartmanns TT an einer Stelle 
eingebaut
1993-12-27
Fcntl TIONOTSEND implementiert, bei ESCC und ST_ESCC ist 
4-Zeichen-Interrupt abschaltbar
1994-01-01
TIOCM_DSR in den TIOCCTL* vorhanden, Fcntl TIOCFLUSH implementiert, 
DTR-Signal durch Nutzer voreinstellbar, Puffergren durch Nutzer 
einstellbar


Harun Scheutzow
(Harun_Scheutzow@b.maus.de)
