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

(Note for the English reading people: The English version is appended on 
the German, look for it!)

!!! Wichtiges neues selbst bersetzt, Rest mit "<NEWBEGIN>" und "<NEWEND>" 
geklammert. !!!

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<BEGINNEW>, siehe "MODEM2 des TT mit 
57600 und 115200Bd".<ENDNEW>

Die Treiber unterscheiden automatisch zwischen den beiden PCLK-Taktraten 
8MHz und 14745600Hz und zeigen die ermittelte Rate in ihrer 
Installationsmeldung an.

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

Bei PCLK = 14745600Hz sind bei MODEM2 und SERIAL2 mglich:
neue Rate   alte Rate
 230400      200
 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/LAN 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 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. 
Die Treiber mssen in physisch vorhandenes RAM geladen werden, drfen also 
_nicht_ im virtuellen Speicher liegen.


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.

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.

M2TT
Die Standardeinstellung "u" sollte keine Probleme bereiten, da der TT 
anhand des _MCH-Cookies erkannt wird und dann auf MODEM2 keine 57600Bd und 
115200Bd mglich sind. "0" legt fest, da 57600/115200 bereitgestellt 
werden, was auf TTs aber nur sinnvoll ist, wenn man den Draht-Umbau 
gemacht hat. "1" legt fest, da 57600/115200Bd nicht mglich sind. Bei 
ST_ESCC.PRG wird diese Frage nicht gestellt. Wenn ein PCLK-Takt von 
14745600Hz erkannt wurde, ist die Antwort auf diese Frage bedeutungslos.

M1EMU
Die Standardeinstellung ist "u". Dies drfte durch die automatischen 
Computertyperkennung anhand des _MCH-Cookies keine Probleme bereiten. 
Diese Funktion wurde extra auf Wunsch der Falcon-Besitzer und der Nutzer 
alter Programme eingebaut. Der reine Nutzer kann den Rest zu diesem 
Konfigurationspunkt berspringen.

Wenn man M1EMU einschaltet, sollte man kein MFP*.PRG fr MODEM1 laden, da 
sich M1EMU damit beit! Der am Computer vorhandene MODEM1-Anschlu wird 
bei eingeschaltetem M1EMU unbrauchbar.

"u" aktiviert M1EMU nur auf dem Falcon. "0" verbietet M1EMU generell. "1" 
schaltet M1EMU immer an.

M1EMU, der MODEM1-Emulator, ersetzt die BIOS-Routinen des Kanals 6 
(MODEM1) durch die BIOS-Routinen des Kanals 7 (MODEM2). Auerdem wird das 
aktuelle BIOS-Gert (AUX) auf 7 eingestellt (fr die etwas sauberere 
Software).

Beim Falcon
... kann man so auch die Programme nutzen, die nur auf AUX (Kanal0) oder 
Kanal6 arbeiten wollen. Da die RING-Leitung (von MODEM2) ohnehin dort 
angeschlossen ist, wo beim ST die von MODEM1 lag, knnen solche Programme 
auch RING direkt in der Hardware (MFP, Bit6) abfragen. Anstelle der 
DCD-Leitung (Carrier Detect) von MODEM1 (wie beim ST) liegt auf Bit1 des 
MFP leider der /ACK-Eingang vom Druckerport (Pin10), dmlicherweise ohne 
Widerstand, so da er bei ausgeschaltetem oder nicht angeschlossenen 
Drucker wild schwingen kann. Bei eingeschaltetem Drucker drfte er meist H 
sein, was diese alten Programme als "NO CARRIER" interpretieren. Abhilfe: 
Verbindung (von Pin10) zum Drucker auftrennen und Pin10 am Druckerport mit 
Pin25 verbinden, signalisiert diesen alten Programmen immer "CARRIER".

Bei MegaSTE/TT und ST_ESCC
... kann man so auch alte Programme ber MODEM2 laufen lassen, die die 
Statusleitungen RING und DCD direkt abfragen und sonst das BIOS benutzen. 
Sie drfen nur nicht direkt auf das Empfangs/Senderegister zugreifen. Man 
mu dazu die Statusleitungen RING und DCD von MODEM2 mit denen von MODEM1 
verbinden. Fr eine vollsteckbare Lsung reichen drei SUB-D-Verbinder. 
RING ist Pin9 an einem 9poligen SUB-D und Pin22 an einem 25poligen SUB-D. 
DCD ist Pin1 an einem 9poligen SUB-D und Pin8 an einem 25poligen SUB-D.

LANBIT
Hiermit wird mit "Ja" das Schalten des Soundchipportbits PA7 zur 
Umschaltung der Pegelwandler zwischen SERIAL2 und LAN erlaubt. Dies sollte 
man nur auf MegaSTE und TT erlauben, deshalb ist die Grundstellung "Nein", 
also keine Soundchipbeeinflussung. Auf MegaSTE und TT ist PA7 nach Reset 
normalerweise auf SERIAL2 gestellt.

LANEXT
"Ja" erzeugt zwei Eintrge, SERIAL2 und LAN, in der Maptab (BIOS-Kanle), 
im RSVF-Cookie und im GEMDOS. Damit hat ein MegaSTE 4 Maptab-Eintrge 
statt normalerweise 3 und der TT 5 statt 4. Das knnte einige nicht so 
gute Programme doch verwirren. Deshalb ist die Standardeinstellung "Nein", 
bei der es nur einen Eintrag gibt, entweder SERIAL2 oder LAN. Vermutlich 
wird man ohnehin immer nur einen der beiden Kanle benutzen, so da "Nein" 
wohl die meistgebrauchte Einstellung sein drfte.

LAN_S2
Hier wird die Voreinstellung von Kanal A des ESCC festgelegt, also ob er 
fr LAN ("0") oder wie normalerweise der Fall fr SERIAL2 ("1") benutzt 
wird. Falls bei LANEXT festgelegt wurde, da nur ein Eintrag existiert, so 
ist die hier gemachte Einstellung nicht nur die Voreinstellung, die direkt 
nach dem Laden der Treiber aktiv ist, sondern auch die endgltige 
Festlegung, ob ein SERIAL2- oder LAN-Treiber bereitgestellt. "u" ist die 
Standardeinstellung, bei der normalerweise SERIAL2, aber auf dem Falcon 
LAN, als Voreinstellung benutzt wird.

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. Einige Programme, die von diesen 
Treibern nichts wissen und entsprechend Ataris Entwicklerdokumentationen 
(die katastrophal falsch sind) erstellt wurden, kommen mit "Nein" nicht 
klar (unmotiviertes Auflegen whrend der Datenbertragung).

DTRS2:
Wie DTRM2, aber fr Schnittstelle SERIAL2.

<NEWBEGIN>
M2DRI:
Diese Frage erscheint beim ST_ESCC.PRG nicht. Sie ist nur beim MegaSTE 
sinnvoll, der keinen RING-Eingang auf der MODEM2-Schnittstelle hat. Es ist 
aber ein (fast?) nie benutzter DSR-Eingang vorhanden. Die Einstellung "Ja" 
tut so, als ob der DSR-Eingang ein RING-Eingang wre und meldet den 
fragenden Programmen das Vorhandensein und den Zustand eines RING-Eingangs 
auf MODEM2. "Nein" ist die bliche Einstellung, die Schnittstelle hat also 
DSR, aber kein RING. Um "Ja" sinnvoll zu nutzen, mu man RING vom Modem 
auf DSR des Computers legen. Modifikation am 9poligen SUB-D-Stecker (des 
Modemkabels), den man (zum Betrieb, nicht zum Lten) in die MODEM2-Buchse 
steckt: Draht von Pin6 (DSR) abtrennen und Drahtende isolieren. Draht von 
Pin9 (RING) ablten und an Pin6 anlten.
<NEWEND>

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.


<NEWBEGIN>
MODEM2 des TT mit 57600Bd und 115200Bd
--------------------------------------
(Nur fr Experten)
Der Leiterzug von pin17 des TT-MFP (MC68901) zu pin32 des SCC (Z85C30) 
wird aufgetrennt (oder pin17 des TT-MFP wird mit Plaststreifen gegen 
Fassung isoliert). Pin32 des SCC wird mit pin13 des SCC verbunden. Bei der 
entsprechenden Frage (M2TT) in der Konfiguration des ?SCC.PRG mu man dann 
vorgeben, einen MegaSTE/Falcon zu benutzen.


MegaSTE mit MODEM2/SERIAL2-Fehlern
----------------------------------
Es gibt einige MegaSTE, die bei der Datenbertragung ber MODEM2 oder 
SERIAL2 und gleichzeitigen DMA-Zugriffen auf Festplatte oder Diskette 
Dateien zerstren. Meist uert sich dies darin, da (z.B. per ZMODEM) 
empfangene (oder gesendete) Archive (z.B. LZH, ZOO, ZIP) sich nicht mehr 
auspacken lassen (Fehlermeldung des Packers). Dieser Fehler wird durch ein 
fehlerhaftes PAL in der Steuerlogik fr den SCC verursacht. Franz Sirl hat 
ein GAL entwickelt, das das PAL ersetzt und die Fehler erfahrungsgem 
beseitigt. Das Listing fr das GAL ist in Mailboxen im Archiv FSER096B.LZH 
zu finden.
<NEWEND>


LAN-Untersttzung
-----------------
Das hat jetzt wieder eine ganze Menge Arbeit gemacht und ist noch nicht so 
ganz wie ich es mir vorstelle. Wre nett, wenn die (potentiellen) Anwender 
sich dazu mal uern.

Die LAN-Schnittstelle und die SERIAL2-Schnittstelle benutzen den gleichen 
Kanal im SCC, Kanal A. Dieser Kanal A wird nur jeweils mit einem anderen 
Pegelwandler verbunden. SERIAL2 und LAN knnen also _nicht_ gleichzeitig 
betrieben werden. Im MegaSTE und TT erfolgt die Umschaltung zwischen den 
Pegelwandlern ber das Soundchip-Portbit PA7 und die Ausgangsleitungen des 
nicht aktiven Pegelwandlers werden auf einen inaktiven Pegel gelegt (??). 
Im Falcon gibt es keine Umschaltung, da nur der LAN-Pegelwandler vorhanden 
ist. Beim 1*RS232+1*LAN-Pegelwandler zum ST_ESCC gibt es ebenfalls keine 
Umschaltung. Die Mega-ST_ESCC-Version bietet bei entsprechender Bestckung 
die Umschaltmglichkeit mit einem mechanischen DIP-Schalter, der aber auch 
durch eine Leitung zum Soundchip (also wie beim TT) ersetzt werden kann. 
Mega-ST_ESCC schaltet jedoch im Gegensatz zum TT die Ausgangsleitungen des 
nicht aktiven nicht inaktiv.

Dieses PA7-Bit wird in STs (und manchmal auch im MegaSTE und TT) durch 
eine Drahtbrcke auf den Druckerport gefhrt zur Ansteuerung von Scannern. 
Davon sollte der Besitzer des Rechners aber wissen und sich entsprechend 
verhalten.

Ich bin der Meinung, da man normalerweise nur entweder LAN (ein Mix aus 
RS422 und RS423) oder SERIAL2 (RS232) benutzt. Der Treiber ist aber 
flexibel genug, auch die abwechselnde Nutzung beider Schnittstellen zu 
erlauben, ohne neu zu booten. Die Umschaltung erfolgt dabei ausschlielich 
durch das Fopen (GEMDOS) auf U:\DEV\LAN oder U:\DEV\SERIAL2 und bleibt 
auch nach Fclose bestehen. Die BIOS/XBIOS-Funktionen schalten nicht um 
sondern nutzen die durch das GEMDOS gemachte Einstellung.

Die LAN-Schnittstelle hat keine RTS-Leitung, so da dort normalerweise 
kein RTS&CTS-Hardwarehandshake (Hwhs) mglich wre. Auf dem MAC habe ich 
in einem Terminalprogramm einen bidirektionalen Hwhs gefunden: DTR&CTS. 
Anstelle der RTS-Leitung wird also die DTR-Leitung benutzt. Dies habe ich 
hier implementiert, Hwhs (meist RTS&CTS genannt) auf LAN bedeutet also 
DTR&CTS.

RTS wird intern benutzt, um den Sender hochohmig zu schalten. Im 
SERSOFST.TXT ist eine entsprechende Mglichkeit vorgesehen, mglicherweise 
baue ich das auch mal ein (ber I/O-Lines). ##########

Momentan ist immer bei Umschaltung auf LAN kein DTR verfgbar in den 
I/O-Lines, das wird sich eventuell noch ndern, so da nur bei Hwhs kein 
DTR verfgbar ist. ###############

Ich glaube, noch einen Unterschied zwischen den MAC-Schnittstellen und dem 
kompatiblen(??) Atari-LAN gefunden zu haben: Beim Atari sind RXD+ und RXD- 
ber einen 100Ohm-Widerstand (Abschlu) verbunden und der GPI liegt ber 
100Ohm an GND. Beim MAC sind diese Widerstnde wohl nicht vorhanden und 
werden nur an den Enden eines Appletalk-Netzwerkes ber die kleinen Ksten 
irgendwie realisiert. Sieht also so aus, als sollte man nur 2 Ataris 
koppeln, knnte aber beliebig viele MACs aneinanderhngen??? Bitte mal 
jemand was dazu sagen, der vom MAC diesbezglich wirklich Ahnung hat.

Anschlubelegung der 8poligen Mini-DIN-Buchse:
  --***--
/ 8  7  6 \
|5    4  3|
\  2   1  /
  -------
Pin Name  Beschreibung
 1  HSKo  Output Handshake, DTR-Signal vom SCC
 2  HSKi  Input Handshake or External Clock, CTS-Signal zum SCC
 3  TXD-  Transmit Data -, Sendedaten negiert
 4  GND   Signal Ground
 5  RXD-  Receive Data -, Empfangsdaten negiert
 6  TxD+  Transmit Data +, Sendedaten nicht negiert
 7  GPi   General Purpose Input, DCD-Signal zum SCC
 8  RxD+  Receive Data +, Empfangsdaten nicht negiert

Wenn man die LAN(RS422/423)-Schnittstelle mit einer RS232 verbinden will 
(als Nullmodem mit Benutzung von Hwhs), sollte man verbinden:
LAN            RS232
HSKo           CTS
HSKi           RTS
TXD-           RXD
TXD+   offen
RXD-           TXD
RXD+   GND
GND            GND

Interessanterweise negieren alle Pegelwandler, nur der fr HSHi/CTS nicht. 
Dies wurde natrlich im Treiber bercksichtigt.


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.


<BEGINNEW>
Fr Programmierer: Behandlung von Empfangsfehlern
-------------------------------------------------
Der ESCC macht eine Fehlerbehandlung recht schwer (bzw langwierig, was die 
Datenrate senken wrde), wenn man seinen EmpfangsFIFO sinnvoll nutzt. 
Deshalb ist die Empfangsfehlerabfrage mit TIOCCTLGET noch _nicht_ 
implementiert. Fehlerhaft empfangene Zeichen (auer receiver overrun, also 
nur parity und frame error) werden der Einfachheit halber mit in den 
Empfangspuffer bernommen. Im Gegensatz dazu beseitigt z.B. der 
MFP-Treiber alle Zeichen mit Empfangsfehlern.
<ENDNEW>


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
1994-03-27
Fcntl TIOCFLUSH Nr.1,2,3 gehen jetzt endlich
1994-04-07
Empfangspuffer High-Water-Mark richtig initialisiert
1994-06-12
M1EMU (MODEM1-Emulation durch MODEM2) ist mglich, alle ?TB?? 
Konfigurationen in einer Tabelle
1994-06-17  ACHTUNG! Installationsblock an MagiC3 angepat. Nur noch 
Treiber und DRVIN von 1994-06-17 oder jnger zusammen verwenden. Versionen 
vor dem 1994-06-17 laufen nicht mit denen ab 1994-06-17 zusammen.
1994-07-11  Konfigurationspunkt LANBIT neu
1994-08-20  M2TT mit Autodetect ausgestattet, 1994-08-13  LANBIT, LANEXT, 
LAN_S2 neu/gendert, Byte4.Bit0 im RSVF
1994-08-27  Konfigurationspunkt PCLK ersetzt durch automatische Ermittlung
<NEWBEGIN>
1994-10-09  DTR mit TIOCCTLGET rcklesbar (RTS auch, aber noch versteckt), 
CTS lesbar
1994-10-29  TIOCFLUSH korrigiert, etwas rumgebastelt, 230400Bd
1994-12-25  Konfigurationspunkt M2DRI, etwas rumgebastelt, u.a. fr 68040 
mit WriteBack-Cache-Einstellung
<NEWEND>
1995-01-04  schnelle Bconout-Parameterbergabe gendert 
(und MAPT_APP/MAPT_OVE Funktiosnummer), ...
1995-01-15  XON/XOFF-Empfangsfehler bei Empfangs != Sendepufferlnge raus

Harun Scheutzow
(Harun_Scheutzow@b.maus.de)




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

(The most important parts translated from German to English on 1994-01-09 
by Harun Scheutzow. I have no time for translating all. If anybody 
translates the remaining parts, I'm very interested in getting the result 
for including it in the next version of this package. My native language 
is German, I think a person whos native language is English would do a 
much better translation. Thanks! (Send only mails smaller than 16kbyte to 
my email address.))

These are drivers for the serial interfaces realized by a SCC or ESCC (eg 
IC Z8530, Am85C30, Z85230). They work together with DRVIN.PRG or an 
equivalent replacement. 1_README.TXT contains an introduction.


The general
-----------
I call only the Z85230 and the Am85C230A an "ESCC". These ICs have an 8 
byte receiver FIFO and a transmitter FIFO not smaller than 4 byte. An ESCC 
contains all functions of the SCC.

The configuration possibilities of the *SCC*.PRG differ a little bit.


Clock rate and baud rate
------------------------
A SCC can use different clock sources for the generation of baud rates. 
The mostly used clock source is its system clock PCLK. This PCLK is 8MHz 
(8000000Hz) in a normal (as delivered by Atari) MegaSTE, TT and Falcon. 
That is a nice number, but unsiutable for generation of the high standard 
baud rates. The high baud rates in MegaSTE/TT/Falcon are generated from 
other sources. My hardware ST_ESCC is clocked by 14745600Hz.

It is possible to modify the MegaSTE/TT/Falcon with a quarz oscillator and 
a bit wire to PCLK=14745600Hz (proposal of Franz Sirl). If only 115200Bd 
and 57600Bd on MODEM2 is needed, a more simple modification with one wire 
is possible. (## No time for description. If there is much interest, in a 
next version. ##)

The drivers detect automatically whether there is a PCLK clock frequency 
of 8MHz or 14745600Hz and display it rate in their installation message.

With a PCLK of 8Mhz are the following Rsconf-baud rates possible:
(old - new)
SERIAL2:
115200 - 150
 57600 - 134
 38400 - 110
MODEM2:
 38400 - 110
153600 -  75
 76800 -  50
On MegaSTE and Falcon (not on TT) additionally on MODEM2:
115200 - 150
 57600 - 134

With PCLK = 14745600Hz are possible on MODEM2 and SERIAL2:
old rate   new rate
 115200      150
  57600      134
  38400      110
 153600       75
  76800       50

If the GEMDOS-Fcntl TIOC?BAUD is used there is no problem at all because 
it provides the possible baud rates as "bit per second".

ST_ESCC contains ever an ESCC. MegaSTE/TT/Falcon contain only an ESCC if 
somebody changed this IC. The driver for SCC runs on the ESCC too, but the 
ESCC driver will not correctly run on a SCC.


SCC and ESCC
------------
Remember: I call only the Z85230 and the Am85C230A an "ESCC". ST_ESCC 
contains ever an ESCC. In the MegaSTE/TT/Falcon there is a SCC in the 
original state. To decrease the CPU load and to improve the data safety it 
is possible to insert an ESCC with PLCC-package. SCC and ESCC are 
pin-compatible enough.


SCC.PRG
-------
This is the driver for MODEM2 and SERIAL2 of MegaSTE and TT and for the 
only RS232 interface of the Falcon (signed with MODEM) drawn out by Atari. 
This "MODEM" of the Falcon is called MODEM2 in this text because of its 
similarity.

On the TT (and Falcon, if equipped with a speeder with FastRAM) *SCC*.PRG 
must not be loaded in the FastRAM. Otherwise problems (bombs, lost of 
characters, spurios behavior) could occur caused by a too fast access to 
the SCC. The drivers must be loaded into physical RAM, they must _not_ be 
loaded into virtual RAM.


ESCC.PRG
--------
See SCC.PRG. This driver is only for computers with a Z85230 or Am85C230. 
The SCC-drivers works with an ESCC too, but don't use the advantages of 
the ESCC. The ESCC-driver is very unsuitable for a SCC!


ST_ESCC.PRG
-----------
This driver is dedicated to my self developed hardware ST_ESCC which 
provides two additional fast serial interfaces on ST/STE/MegaST. 115200Bd 
run without problems on an 8MHz/68000 machine under TOS.


LAN-Support
-----------
(-- something untranslated --) (... manything)


Configuration
-------------
The configuration is done by using SETTER.TTP.

Because the explainations in the drivers are German I added an 
abbreviation to each point.

USE4C
This question appears only in the ESCC.PRG and ST_ESCC.PRG. Shall the 
receiver interrupt take place after four received characters? I call this 
mode which signals an interrupt after 4 characters 4ZI. 4ZI decreases the 
CPU load in the "RTS/CTS"- and "without"- handshake modes radically. 
"XON/XOFF"-handshake switches 4ZI automatically off because the number of 
necessary special actions would be greater than the use.
(-- something untranslated --)
Normally you should switch 4ZI on, answer with "Yes", because 4 free 
characters are sufficient and the profit by the reduced CPU load (the 
number of receiver interrupts is reduced to 1/4) is important. If you use 
unclean programs you should switch off 4ZI by answering "No". The programs 
show their uncleannes by delays: if you type in the terminal mode an the 
characters appear only if you typed 4 characters or more, unclean transfer 
protocols will hang some time (or for ever) mostly at the beginning or the 
end of transfer.

M2TT
The standard setting "u" should cause no problems because the TT is 
detected by the _MCH-cookie and then are on MODEM2 57600Bd and 115200Bd 
unavailable. "0" forces 57600/115200 to be provided. This is on TTs only 
senceful if you did the wire-modification. "1" forces 57600/115200 not to 
be provided. If your SCC is clocked by a PLCK of 14745600Hz this answer 
has no effect.

M1EMU:
The normal setting is "u". This should not cause any problems because of 
the automatic computer type detection using the _MCH-cookie. This function 
was added for the Falcon owners and users of old programms. The normal 
user can jump over the remaining text of this configuration point.

If M1EMU is switched on, no MFP*.PRG for MODEM1 shall be loaded because of 
collisions! The MODEM1-connector of the computer becomes unusable if M1EMU 
is active.

"u" activates M1EMU only on Falcons. "0" disables M1EMU on all computers. 
"1" activates M1EMU on all computers.

M1EMU, the MODEM1-emulator, replaces the BIOS-routines of channel 6 
(MODEM1) by the BIOS-routines of channel 7 (MODEM2). Additionally the 
actual BIOS-device (AUX) is set to 7 (for a bit more clean software).

On the Falcon
... programs become usable, which like to work only on AUX (channel0) or 
channel6. Because the RING-signal (of MODEM2) is attached there, were the 
RING of MODEM1 is on STs, such programs may detect RING direct in the 
hardware (MFP, Bit6). Instead of the DCD-signal (carrier detect) of MODEM1 
(as on ST) on Bit1 of the MFP lays the /ACK-input from the printer port 
(pin10), without any resistor, so that this signal may swing if there is 
no printer connected or the printer is off. If the printer is on, /ACK 
should be H most of the time, and these old programs interpret this as 
"NO CARRIER". Patch: Cut of the connection (wire from pin10) to the 
printer and connect pin10 with pin25 on the printer port. This signals 
these old programs always "CARRIER".

On MegaSTE/TT and ST_ESCC
... it becomes possible to run old programs, which access the signals RING 
and DCD direct and go over the BIOS for the other functions, on MODEM2 
too. These programs must not access the receiver/transmitter register 
directly. You have to connect the RING line and DCD line of MODEM1 
with the same of MODEM2. A full plugable solution may consist of 3 
SUB-D-connectors. RING is pin9 on a 9pin-SUB-D and pin22 on a 25pin-SUB-D. 
CDC is pin1 on a 9pin-SUB-D and pin8 on a 25pin-SUB-D.

LANBIT
(-- something untranslated --)
Use other values than No only on MegaSTE and TT!

LANEXT
(-- something untranslated --)

LAN_S2
(-- something untranslated --)

DTRM2
The DTR(data terminal ready)-signal of the MODEM2 interface is set at the 
start of this driver on time to the value given here. Yes corresponds to 
on and is equivalent to the behavior of TOS, No corresponds to off and 
prevents most modems from going off hook before a communication program 
has been started. Some programms which know nothing about these drivers 
and are made according to ataris developer documentation (which is 
catastrophic false), don't work with "No" (hang up during data 
transmission).

DTRS2:
The same as DTRM2 but for interface SERIAL2.

RBLM2:
Use 256 as a default. Here the receiver buffer length in byte of the 
MODEM2 interface can be set. It may be in the range of 65534 (maximum) to 
16 (minimum). Values out of this range are set to the default of 256. The 
water marks are set to 1/4 (low water mark) and 3/4 (high water mark).

TBLM2:
As RBLM2, but for the transmitter buffer length.

RBLS2:
As RBLM2, but for the interface SERIAL2.

TBLS2:
As RBLM2, but for the transmitter buffer length of interface SERIAL2.


For programmers: The IOREC
--------------------------
Hands off from computing the readable number of bytes by the IOREC! This 
method will fail if 4ZI is switched on in ESCC and ST_ESCC. Use the 
function Fcntl FIONREAD or Fread, both work correctly in these drivers. 
Bconstat works correctly too.

If the cookie RSVF exist and the RSVF-list contains the interface you can 
rely on the correctness of FIONREAD. The MiNT-user may destroy this, but 
he is responsible for that.

If the functions for modification of buffer length are not implemented, it 
is legal to change the buffer address, largeness and water marks in the 
IOREC. In this case, and only in this case, I see it as legal and 
necessary to reset the read and write pointer in the IOREC to zero.

It is possible, that in the future the IOREC is no longer used. Because of 
compatibility reasons a dead IOREC may remain. Who wants to program really 
clean should examine the return value of the XBIOS-function IOREC (or the 
pointer in the MAPTAB if you grab so direct in the memory). Is this value 
zero or odd there is no IOREC.


For programmers: Supported functions
------------------------------------
All drivers support the TIOCCTL(MAP/GET/SET)-functions as described in 
SERSOFST.TXT. May bee they don't support all signals and lines but that 
can be requested by TIOCCTLMAP. Which Fcntls are supported a program 
should determine by calling this functions.


Versions
--------
See German part.
1994-06-17  ATTENTION! Installation block adapted to MagiC3. Use together 
only drivers and DRVIN from 1994-06-17 or younger. Older versions will not 
run together with newer ones.
1994-07-11  added configuration facility LANBIT
1994-08-20  M2TT provides machine autodetect, LANBIT, LANEXT, LAN_S2 
new/changed, Byte4.Bit0 in RSVF
1994-08-27  configuration point PCLK replaced by automatic detection
1995-01-04  fast Bconmap parameter passing changed, ...
1995-01-15  XON/XOFF-receive error if rec.buffer length != tra.b.l removed
