Treiber ******* Wer diesmal zu faul zum Lesen ist, wird sich wahrscheinlich m„chtig wundern. HSMODEM1 -------- Diese Treiber ersetzen HSMODEM1. Bei der Nutzung nur ber die BIOS-Funktionen von MODEM1 durch alte Programme sind sie nicht ganz so schnell wie HSMODEM1, dafr untersttzen sie jetzt wesentlich mehr Schnittstellen und ein flexibles Konzept. Wer ausschliežlich ein altes Programm zur DFš benutzt, ist mit der letzten Version von HSMODEM1 (HSMOD105.LZH) wahrscheinlich einigermažen bedient. BETAs ----- Ich bin von der Funktionsf„higkeit der Treiber berzeugt, da sie aber noch nicht berall optimiert sind, sie nicht fr jede Fehlerbedingung dem User eine passende Meldung liefern und ihnen noch ein paar Funktionen fehlen, die ich einbauen will, nenne ich sie erstmal BETA-Versionen. Die Beschreibungen lassen auch noch zu wnschen brig. Grundlagen ---------- Der Nutzer packt das DRVIN.PRG in den AUTO-Ordner und die zu seinem Rechner passenden Treiber hinterher. Es ist wirklich so gemeint, daž man zuerst DRVIN kopiert, da die Treiber nach DRVIN geladen werden mssen. Einige Treiber lassen sich mit SETTER konfigurieren, was man vor dem Einsatz tun sollte. Es sollte mit allen TOS-Versionen und mit Mag!X >=2.0 laufen. Mit Mag!X<2.0 mžte es auch gehen. Wenn man es komplett vor MiNT installiert, sollte es eingeschr„ngt funktioniert. Bitte NICHT nach (unter) MiNT starten, das kann ble Effekte produzieren. Extreme Kurzunterweisung ------------------------ Kopieren folgender Programme in dieser Reihenfolge in den AUTO-Ordner: fr alle: DRVIN.PRG fr ST, MegaST, STE, MegaSTE, TT: MFP.PRG fr Falcon: (optional MFP_FALC.PRG), SCC.PRG fr MegaSTE, TT: SCC.PRG fr TT: MFP_TT.PRG fr ST_ESCC in ST, STE, MegaST: ST_ESCC.PRG Damit kann man aber reinfallen, wenn man nicht vorher alle Programme mit dem SETTER.TTP behandelt, um deren Einstellungen zu prfen. Also sollte man doch noch mehr lesen. Einzelne Treiber ================ (##diese Texte werden noch mal passend vereinzelt.) 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 l„žt sich problemlos per TIOCCTLMAP erfragen. *SCC*.PRG allgemein ------------------- Als "ESCC" betrachte _ich_ nur den Z85230 und den Am85C230A. Die im System vorhandene SCC-Taktrate PCLK kann bei allen *SCC*.PRG durch SETTER auf zwei Werte eingestellt werden. Ein normaler MegaSTE/TT/Falcon hat einen Takt von 8MHz. ST_ESCC hat einen Takt von 14745600Hz, ein MegaSTE/TT/Falcon hat diesen Takt nur, wenn das jemand extra umgebaut hat. Bei einem PCLK von 8MHz sind folgende Rsconf-Baudraten m”glich: (neue - alte) SERIAL2: 115200 - 150 57600 - 134 38400 - 110 MODEM2: 38400 - 110 153600 - 75 76800 - 50 Bei PCLK = 14745600Hz sind bei MODEM2 und SERIAL2 m”glich: neue Rate alte Rate 115200 150 57600 134 38400 110 153600 75 76800 50 Wenn man die GEMDOS-Fcntl benutzt, hat man ohnehin kein Problem, dort erf„hrt man, welche Baudraten m”glich sind im Klartext als "Bit/Sekunde". ST_ESCC enth„lt immer einen ESCC. MegaSTE/TT/Falcon enthalten nur einen ESCC, wenn den jemand extra gewechselt hat. Der Treiber fr den SCC l„uft auch mit dem ESCC-Schaltkreis, umgekehrt nicht. Hinweis fr Programmierer: Finger weg von der Bestimmung der lesbaren Byteanzahl ber den IOREC. Das geht bei eingeschaltetem 4-Zeichen-Interrupt des ST_ESCC voll daneben. Immerhin bringt dieser Interruptmodus eine wesentliche Systementlastung. Stattdessen FIONREAD oder gleich Fread benutzen, funktionieren bei HSMODEM beide richtig (wenn Cookie RSVF mit der benutzten Schnittstelle da ist, darf man sich darauf verlassen, daž FIONREAD funktioniert. ## Aber momentan nur _nicht_ unter MiNT.) SCC.PRG ------- Treiber fr MODEM2 und SERIAL2 bei MegaSTE, TT und Falcon. Beim Falcon ist die auf dem Ger„t als "Modem" beschriftete Schnittstelle die MODEM2 und die als "LAN" beschriftete die SERIAL2. SERIAL2 hat eventuell noch Probleme mit den Handshakeleitungen, ich habe mich mit deren Herausfhrung auf den LAN-Port noch nicht n„her befažt. 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). 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 k”nnte. ESCC.PRG -------- Siehe SCC.PRG, aber _nur_ fr die Leute, die sich einen Z85230 oder Am85C230A eingebaut haben. ST_ESCC.PRG ----------- Treiber _NUR_ fr meine Hardware ST_ESCC! Realisiert MODEM2 und SERIAL2 und die entsprechenden BIOS-Ger„te 7 und 8. MFP*.PRG allgemein ------------------ Alle besitzen (momentan?) die gleichen Einstellm”glichkeiten durch SETTER. Diese M”glichkeiten werden weiter hinten erl„utert, in dem auf die Schnelle modifizierten Teil der letzten HSMODEM1-Doku. MFP.PRG ------- Siehe weiter hinten, fr ST, STE, MegaST, MegaSTE, TT als MODEM1. MFP_TT.PRG ---------- Fr SERIAL1 des TT, die Schnittstelle ohne Handshakeleitungen, nur mit TXD und RXD. TIOC?FLAGS fr SERIAL1 verbietet RTS/CTS noch nicht durch eine Fehlermdeldung, sondern konvertiert es ##momentan noch in "kein Handshake". MFP_FALC.PRG ------------ Fr den MFP des Falcon, als MODEM1. Ohne Handshakeleitungen, nur TXD und RXD. Aber nur nutzbar, wenn man seinen Falcon mit Hilfe von Draht, einem Stecker und evtl. einem Pegelwandler diese Schnittstelle spendiert hat. Andernfalls braucht und sollte man diesen Treiber nicht laden. Ich weiž nicht so genau, ob, aber eigentlich sollte auch dieser Treiber funktionieren. TIOC?FLAGS verbietet RTS/CTS noch nicht durch eine Fehlermdeldung, sondern konvertiert es ##momentan noch in "kein Handshake". MFP_BAST.PRG ------------ Fr die Leutchen, die sich einen TT-MFP in den ST gebastelt haben. Treiber liegt nicht bei, habe heute keine Zeit mehr, ist aber kein Problem, also einfach mal bei mir melden. Der auf die Schnelle ge„nderte Text des alten HSMODEM1 ====================================================== HSMODEM1 ist ein Software-Beschleuniger und Patch fr die serielle Schnittstelle Modem1 der Atari-Computer. Es beseitigt nicht nur den auch im TOS2.06/3.06 noch vorhandenen RTS/CTS-Handshakefehler, sondern erh”ht durch seine optimierten Routinen die m”gliche šbertragungsrate wesentlich. Aužerdem ein Fehler des TOS2.05 beseitigt. Sp„testens wenn Fragen auftreten sollte man diesen Text komplett lesen und erst danach seiner Umwelt oder mir die verbliebenen Fragen stellen. Bei Updates und Zeitmangel zuerst einen Blick nach ganz hinten, Abschnitt "Versionen"! Copyright --------- Ich gestatte die šbersetzung dieser Dokumentation in andere Sprachen. Der šbersetzer hat seine T„tigkeit entsprechend zu vermerken. Das deutsche Original muž weiterhin beigelegt sein. Die im Folgenden genannten Bedingungen gelten auch fr die šbersetzung. ##Dieses Zeug darf, aber immer nur zusammen mit diesem Text, zu nicht kommerziellen Zwecken frei kopiert werden. Die Verbreitung auf PD-Disketten zu blichen Preisen ist zul„ssig. Ein Beipack zu Programmen ist ohne meine Zustimmung nur zul„ssig, wenn diese PD oder Shareware mit einer maximalen Registrierungsgebhr von 100DM sind. Jede Verbreitung zusammen mit kommerziellen Programmen oder sonstige kommerzielle Verwertung, ausgeschlossen jedoch die Anwendung (Programm starten), ist nur mit meiner ausdrcklichen Genehmigung gestattet. Die Betatester und ich haben dieses Programm sorgf„ltig berprft. Ich hafte in keiner Weise fr: - Fehler und/oder (daraus resultierende) Besch„digungen irgendwelcher Objekte, Subjekte oder Werte. - irgendwelche Auswirkungen des Einsatzes oder Nichteinsatzes dieses Programmes und dieser Dokumentation Fehlermeldungen oder Verbesserungsvorschl„ge nehme ich gern an. Ich hasse allerdings unangemeldetes Auftauchen mir nicht pers”nlich bekannter Personen sowie Telefonanrufe zu MICH st”renden Zeiten. Es gibt schliežlich Email und die (gute) alte Post. Meine Adressen: Mausnetz: Harun Scheutzow @B Internet: Harun_Scheutzow@B.maus.de Post: Harun Scheutzow Dresdener Straže 83 D-10179 Berlin, Deutschland An dieser Stelle m”chte ich allen danken, die mich bei der Entwicklung dieses Programms untersttzt haben. Diese Untersttzung geht manchmal ganz sch”n auf die Telefonrechnung! Einsatzm”glichkeiten, Voraussetzungen, u.v.m. ------------------------------------------------ ### siehe ganz vorne Mag!X Versionen ab 2.00 dieses multitaskf„higen Betriebssystems (es ist im Gegensatz zum aktuellen MultiTOS nicht nur ein Aufsatz und wesentlich schneller) haben korrekte Routinen zur Schnittstellen-Bedienung. Die entsprechenden GEMDOS-Funktionen fehlen aber noch. Interessant ist das Mag!X-Multitasking auf 8MHz-STs bei 38400Bd-Empfang: (auf jeden Fall mit einer neuen NVDI-Version) Man kann im Vordergrund mit der Maus wirtschaften und einen Text schreiben (getestet mit Everest), w„hrend im Hintergrund GSZRZ 3.5 fehlerfrei empf„ngt. Mit Mag!X ab Version 2.00 sollte man die Interruptroutinenmodifikation im MFP.PRG abschalten, da Mag!X bereits modifizierte Timerroutinen hat. Wenn MFP.PRG da noch etwas einh„ngt, wird es ein bižchen langsamer. ## Dieses Zeug ist ein Ersatz fr andere Patches (nicht nur fr Modem1), wie z.B. RS232ENC oder TURBOCTS. Die Schnittstelle Modem1 kann ohne Zusatzhardware maximal 19200Bd erreichen. Daran „ndert auch MFP.PRG nichts. Es ersetzt aber die langsamen und zum Teil fehlerhaften Routinen des TOS durch schnelle und hoffentlich fehlerfreie. Mit Zusatzhardware, wie (dem von mir entwickelten) RSVE, RSSpeed (Stephan Skrodzki) oder anderen k”nnen h”here Datenraten realisiert werden. Z.B. erlaubt RSVE auch die Einstellung von 38400, 57600 und 115200Bd. MFP.PRG sorgt dann im Rahmen der Hardware-M”glichkeiten fr einen wesentlich h”heren Datendurchsatz (cps-Rate). Der komplette Bauplan fr RSVE liegt als RSVE.LZH in Mailboxen, auf jeden Fall in der Maus Berlin (@B). Die Fertigversion von RSVE gibt es direkt bei mir. Wenn jemand meint, allein mit Software Modem1 mit mehr als 19200Bd betreiben zu k”nnen: Das geht im Synchronbetrieb des MFP (Abschalten der Taktteilung /16). Dabei ist eine fehlerfreie Funktion aber ausschliežlich beim Senden m”glich, NICHT beim Empfang. Ich arbeite mit einem 8MHz ST, ohne CPU-Beschleuniger. Ich halte wenig davon, immer neue und schnellere Computer zu kaufen und diese durch lahme Software bis zum Stillstand zu bremsen. Das TOS ist eine lahme Software, kein Wunder, es ist inklusive der Interruptroutinen in C programmiert (es sieht so aus). MultiTOS ist eine noch gr”žere Systembremse. Mag!X ist genau das Gegenteil. TOS2.05-Fehler -------------- Die XBIOS-Funktion 14, Iorec ist nur im TOS2.05 fehlerhaft. Sie liefert unabh„ngig von der Einstellung ber Bconmap bei der Abfrage der IOREC-Strukturadresse fr AUX (Nummer 0) immer die Adresse des Modem1-IOREC. DRVIN beseitigt auch dieses Problem, da es das gesamte MAPTAB-Zeug selbst bernimmt. Rufus-Fehler ------------ Mit Rufus 1.11rel9 steht der Rechner nach dem Auflegen einiger HighSpeed-Modems (RXD und TXD leuchten beide, nichts geht mehr). RUFUS schreibt $00 ins UCR, das fhrt zu obigen Effekten und ist Bl”dsinn. Abhilfe: Rufus 1.20 oder neuer benutzen. Wie schnell geht es? -------------------- Das Problem bei einer seriellen šbertragung mit einer bestimmten Geschwindigkeit (hier in Baud angegeben) ist nicht das Senden der Zeichen, sondern deren Empfang. Der MFP puffert nur ein empfangenes Zeichen und meldet es der CPU per Interrupt. Die CPU muž dieses Zeichen fr eine fehlerfreie šbertragung aus dem MFP abholen, bevor er das n„chste Zeichen komplett empfangen hat. Wenn ich sage, der Betrieb bei ... ist zuverl„ssig, so bedeutet dies, daž die CPU bei der maximal m”glichen Empfangs-Zeichendichte (keine Pause zwischen Stoppbit des vorigen und Startbit des folgenden Zeichens) jedes Zeichen rechtzeitig abholt. Ein 8MHz ST (RSVE eingebaut) kann mit TOS und HSMODEM1 eine fehlerfreie Datenbertragung mit 38400Bd realisieren. Mit einem HSMODEM1 ab dem 21.05.1993 funktioniert auch der Empfang (Senden sowieso) mit 57600Bd auf 8MHz STs, solange nicht "NO FASTINT" angegeben ist. Derzeit erreicht ein 8MHz ST mit GSZRZ Version 3.3 von Michael Ziegler bei einer ZMODEM-šbertragung und 38400Bd mehr als 3600cps, wenn NVDI installiert und der Blitter ausgeschaltet ist. Ohne NVDI sind es etwa 300cps weniger, da GSZRZ lange an seiner Dialogbox zeichnen l„žt. Den Blitter kann man in den meisten F„llen auch zugeschaltet lassen. Sollten aber Empfangsfehler auftreten, dann den Blitter abschalten. ZMODEM-šbertragung ber die Filefunktionen bringt mit einem GSZRZ ab 3.5 mehr als 5400cps bei 57600Bd. Die angegebenen Datenraten gelten fr direkte Rechnerkopplung. Fr langsame Modems und schlechte Telefonleitungen ist HSMODEM1 nicht verantwortlich! Zyxels k”nnen bei 16800zyx/v42bis und ASCII-Texten 3800cps erreichen, Zyxel+ bei 19200zyx noch mehr. Andere 14400/v42bis-Modems liegen bei etwa 3300cps. Die von mir entwickelte Hardware ST_ESCC hat auch bei 115200Bd noch keinerlei Probleme, selbst bei Tastaturtippen unter normalem TOS, da sie ber einen 8 Byte grožen Empfangs-FIFO verfgt. Sie beschleunigt aber nicht MODEM1, sondern realisiert zwei zus„tzliche schnelle Serielle. 57600Bd auf 8MHz und 16MHz 68000er ber _MODEM1_ ------------------------------------------------ 57600Bd ist fr Modem1 auf (Mega)ST(E) die magische Grenze, die auch nur mit leichten Modifikationen im TOS erreicht wird. 115200Bd werden wohl auch in Zukunft nur im Polling und nicht im Interruptbetrieb m”glich sein. Bei mir funktionieren 57600Bd auf einem 8MHz-ST mit TOS2.06. Ich bin mir aber nicht sicher, ob es auch mit anderen („lteren) TOS-Versionen funktioniert. Da ich immer wieder gefragt werde, wie man 57600 fehlerfrei erreicht: Blitter aus, keine DMA-Zugriffe w„hrend Dateibertragung (in den Filepuffer des ZMODEMs muž bei Empfang das ganze File passen), keine Joysticks mit Autofire oder DCF-Uhren am Joyport. Dann testweise alle residenten Programme und ACCs entfernen und nur die wieder benutzen, die nicht st”ren. Die Konfiguration ----------------- Das alte HSMODEM1.INF-File kann man verschrotten. Die Konfiguration erfolgt jetzt durch das SETTER.TTP, zur Bedienung siehe dort. MFP.PRG kann den Timerinterrupt des TOS modifizieren, um so 57600Bd mit 8MHz-68000 ber MODEM1 zu erm”glichen. Sollte man auf TTs/Falcons und unter Mag!X >=2.0 abschalten, ebenso bei Experimenten mit anderen Betriebssystemen. Funktionsweise (fr Interessenten): Es hat sich aber gezeigt, daž es ausreichend ist, wenn die Routine (GEMDOS-Uhr) in NEXT_TIM (negative LineA-Variable) mit einem IPL < 6 aufgerufen wird, um auf 68000/8MHz den 57600Bd-Empfang zu erm”glichen. Also h„nge ich ein Programmstck ein, daž den IPL auf 5 heruntersetzt. MFP.PRG kann den Cookie RSVE anlegen, damit kann man sich das RSVE_SET.PRG im AUTO-Ordner sparen. Ganz neue Programme (Connect, aber ich kann nicht genau sagen welche Version, irgendetwas ber 2.4) interessiert dieser Cookie ohnehin nicht mehr, da sie die Baudraten ber TIOC?BAUD ermitteln. Wie eben schon undeutlich gesagt, werden die hohen Baudraten auch den TIOC?BAUD Funktionen mitgeteilt. Es gibt noch einen Konfigurationspunkt, der ohne Anlegen des RSVE-Cookies die hohen Baudraten wie bei RSVE anstelle der niedrigen den TIOC?BAUD-Funktionen mitteilt. MFP.PRG kann Baudraten umlegen. Dies ist nur zusammen mit RSVE oder RS-Speed ntzlich. So kann man die Einschaltung von 38400Bd, die frher durch Einstellen von 110Bd erfolgte, auf das Einstellen von 19200Bd zu legen. Damit erm”glicht man einigen alten Programmen die Arbeit mit mehr als 19200Bd. Dieser Konfigurationspunkt ist der Letzte, und man gibt dort (wie es SETTER beschreibt) zuerst die zu ersetzenden alte Baudrate und dann (auf den n„chsten Platz) die dort hinzulegende hohe Rate an, und zwar ganz exakt. Der erste als "ungltig" gekennzeichnete Platz beendet die Suche nach Umbelegungen. Will man nichts umlegen, gibt man berall "u" an. Die Baudraten 115200/57600/38400 liegen bei Einbau der Hardware RSVE sowie so schon immer auf 150/134/110, diese dorthin umzulegen ist sinnlos. Die Umlegungen sind fr Programme unsichtbar, erscheinen auch nicht in den Fcntl TIOC?BAUD. M”gliche Probleme (vor allem bei MODEM1, fast nicht bei ST_ESCC) ----------------- Lange DMA-Zugriffe k”nnen beim Empfang zu Datenverlusten fhren. Ebenfalls kritisch sind lange Verweilzeiten der CPU in einem Interruptpriorit„tslevel gr”žer als 5. Auf 8MHz STs ohne Mag!X >2.00 und neues NVDI: Bei mehr als 9600Bd Finger weg von Maus und Tastatur, w„hrend GSZRZ empf„ngt. Sonst gibt es ein paar šbertragungsfehler (bei MODEM1). Genauso k”nnen ein paar Zeichen verloren gehen, wenn im Terminalprogramm gerade ein Text ankommt und der User die Tastatur oder Maus bearbeitet. Abspeichern empfangener Daten unter GSZRZ w„hrend des Empfangs fhrt bis 38400Bd meist nicht zu Fehlern. Man kann den Blitter so programmieren, daž er die CPU zu lange blockiert. Das TOS und NVDI tun dies anscheinend nicht. Wenn Fehler beim Empfang mit >= 38400Bd auftreten, erst mal mit abgeschaltetem Blitter probieren. Es gibt einige ACCs und residente (AUTO-Ordner-)Programme, die irgendwelche Interrupts umlegen und das System zu lange blockieren. Im Zweifelsfalle einzeln rauswerfen und testen. MiNT und besonders MultiTOS sind allgemeine Systembremsen, die sich besonders auf 8MHz-Rechnern bemerkbar machen. Mag!X finde ich pers”nlich wesentlich besser, da es wesentlich schneller ist. DCF_TIME von Ralf Zimmermann @WI2 sollte in der Version 1.2 oder h”her verwendet werden. Aber nur die Abfrage ber den RingIndicator macht keine Probleme bei 57600Bd, ber den Joyport gibt es sekndlich Žrger. QFAX frižt sehr viel Rechenzeit und sollte bei Problemen zuerst entfernt (nicht nur abgeschaltet) werden. Funktion des ... ---------------- Siehe erstmal vor allem DRVIN.TXT. Versionen --------- Ich vergebe keine Versionsnummern, sondern berlasse die Unterscheidung dem in der Installationsmeldung ausgegebenen Datum. Ich notiere das Datum ab sofort als Jahr-Monat-Tag, ist eindeutig unterscheidbar von der deutschen Schreibweise Tag.Monat.Jahr, da die Jahreszahl vierstellig ist. Neue Versionen sind zuerst in der Maus Berlin, Telefonnummer 030-6246510 (meistens besetzt), zu finden und verbreiten sich schnell ber die M„use. Man sollte nach dem Filenamen "HSMOD*.*" suchen lassen. Das Archiv wird HSMODAxx.LZH heižen, wobei xx fr die fortlaufende Ver”ffentlichungsnummer und das A fr alle Schnittstellen (kann sich auch mal „ndern!) steht. (Historie des HSMODEM1 beseitigt) 1993-11-21 erste Ver”ffentlichung 1993-11-23 bleibt auch bei Installationsfehler resident allerdings passen dann ser. Interruptroutinen und Bco* nicht zusammen. (aber besser als Totalabsturz) Harun Scheutzow, 21.11.1993 und sp„ter