home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Vectronix 2
/
VECTRONIX2.iso
/
FILES_01
/
STARC20.LZH
/
STARCALL
/
DFUETOOL
/
HSMODEM1
/
HSMODEM1.TXT
< prev
Wrap
Text File
|
1993-03-16
|
11KB
|
233 lines
HSMODEM1.PRG
============
HSMODEM1 ist ein Software-Beschleuniger und Patch für 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. Wer diesen Text nicht komplett durchliest, dem ist nicht zu
helfen. Es ist keine Schande, etwas nicht zu verstehen, denn ich lasse
mich über einiges aus, was für den nur-Anwender unwichtig ist, habe aber
heute keine Lust, alles zu sortieren (erledige ich später mal).
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 für die Übersetzung.
HSMODEM1 darf, aber immer nur zusammen mit diesem Text, zu nicht
kommerziellen Zwecken frei kopiert werden. Die Verbreitung auf PD-Disketten
ist ebenfalls zulässig, solange eine Disk mit HSMODEM1 nicht mehr als
andere PD-Disketten des Anbieters kostet. Ein Beipack zu Programmen ist nur
zulässig, wenn diese PD oder Shareware mit einer maximalen
Registrierungsgebühr von 50DM sind. Jede Verbreitung zusammen mit
kommerziellen Programmen oder sonstige kommerzielle Verwertung,
ausgeschlossen jedoch die übliche Anwendung (Programm starten), ist nur mit
meiner ausdrücklichen Genehmigung (möglicherweise gegen Gebühr) gestattet.
Interessenten können möglicherweise den Quelltext von mir erhalten. Das ist
nicht ganz kostenlos, aber auch für Hobbyisten bezahlbar.
Ich mag es nicht, an dieser Stelle zu schreiben: "Sollten Sie das Programm
länger als 3 Wochen (Testzeit) benutzen, so wird eine Registrierungsgebühr
in Höhe von xxxx fällig." Allerdings freue ich mich über kleine Spenden
(5DM und aufwärts) entweder an meine Postadresse oder auf mein Konto (bitte
Absender mit angeben). Ein kleiner Denkansto₧: Es ist nicht so, da₧ ich
wild drauflos auf immer und ewig für die Allgemeinheit billig arbeite.
Ich bin Student und mu₧ nicht nur mein Hobby selbst finanzieren. Je mehr
ich an kommerziellen Auftragsarbeiten oder sonstigen finanziell
einträglichen Dingen arbeite(n mu₧), desto weniger Zeit bleibt für Projekte
dieser Art.
Ich und die Betatester haben dieses Programm sorgfältig überprüft. Ich
hafte in keiner Weise für eventuelle Fehler und/oder (daraus resultierende)
Beschädigungen irgendwelcher Objekte, Subjekte oder Werte.
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 (in letzer Zeit sogar wieder gute) alte Post.
Ich bin im Mausnetz unter
Harun Scheutzow @B
zu erreichen. Meine Postanschrift lautet:
Harun Scheutzow
Dresdener Stra₧e 83
O-1020 Berlin
Meine Bankverbindung:
Kontoinhaber: Harun Scheutzow
Kontonummer: 581854107
Bankleitzahl: 10010010
Bank: Postgiroamt Berlin
Einsatzmöglichkeiten und Voraussetzungen, u.v.m.
------------------------------------------------
HSMODEM1 soll unter allen TOS-Versionen auf ATARI ST, STE, MegaST, MegaSTE
und TT laufen. Es läuft NICHT auf dem Falcon. Deshalb ist alles Folgende
nur für die Computer gültig, auf denen HSMODEM1 lauffähig ist. Je nach
TOS-Version integriert es sich unterschiedlich in das System. Dabei werden
nur dokumentierte Eigenschaften des TOS genutzt, auch wenn das manchmal
nicht einfach war.
Modem1 kann ohne Zusatzhardware maximal 19200Bd erreichen. Mit
Zusatzhardware, wie (dem von mir entwickelten) RSVE, RSSpeed oder anderen
können auch höhere Datenraten realisiert werden. Z.B. erlaubt RSVE auch die
Einstellung von 38400, 57600 und 115200Bd. Ohne Zusatzhardware können
höhere Datenraten im Synchonbetrieb des MFP erreicht werden, dabei ist eine
fehlerfreie Funktion aber ausschlie₧lich beim Senden möglich, und es wird
kaum einer auf den Empfang verzichten wollen.
Ich arbeite (immer noch) 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. Meine persönliche Meinung über die TOS-Programmierer (Eric
Smith ausgenommen) hat die (Selbst)Zensur an dieser Stelle gelöscht.
Wie schnell geht es?
--------------------
Das Problem bei einer seriellen Übertragung mit einer bestimmten
Geschwindigkeit (hier immer in Baud angegeben) besteht nicht im Senden der
Zeichen, sondern in deren Empfang. Der MFP puffert immer nur ein
empfangenes Zeichen und meldet ein empfangenes Zeichen der CPU per
Interrupt. Die CPU mu₧ dieses Zeichen für eine fehlerfreie Übertragung aus
dem MFP abholen, bevor dieser das nächste Zeichen komplett empfangen hat.
Wenn ich sage, der Betrieb bei ... ist zuverlässig, so bedeutet dies, da₧
die CPU es schafft, jedes Zeichen rechtzeitig abzuholen, und zwar bei der
maximal möglichen Zeichendichte auf der seriellen Empfangsleitung (keine
Pause zwischen Stoppbit des vorigen und Startbit des nachfolgenden
Zeichens).
Ein 8MHz ST (RSVE eingebaut) kann mit TOS und HSMODEM1 eine fehlerfreie
Datenübertragung mit 38400Bd realisieren. Eine fehlerfreie Datenübertragung
mit 57600Bd ist ebenfalls möglich, aber nicht mit dem originalen TOS.
Andere Interruptroutinen des TOS sind so unintelligent ausgelegt, da₧ sie
den zuverlässigen Betrieb mit 57600Bd verhindern. Siehe auch nächsten
Abschnitt.
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-Senden
bei 57600Bd erreicht mehr als 5000cps.
Zukünftiges
-----------
Die TOS-Interruptroutinen sind für fehlerfreien 57600Bd-Betrieb auf
8MHz-STs zu doof und langsam. Dies bezieht sich auf das ganze
Interruptroutinensystem. Ich arbeite an neuen Interruptroutinen, die dieses
Problem beseitigen werden. Dies sind NICHT neue serielle Routinen (die hier
enthaltenen sind schnell genug), sondern z.B. neue Tastaturroutinen.
Es geht auch noch ein bi₧chen schneller, aber ich will die Interessenten
nicht noch länger auf die erste Version warten lassen.
Eventuell wird es ein Programm geben, da₧ alle Schnittstellen des
MegaSTE/TT unterstützt, möglicherweise in Zusammenarbeit mit anderen
Programmierern.
Es wird wahrscheinlich einen TOS2.06-EPROM-Patch geben, der HSMODEM1 direkt
in das TOS2.06 integriert.
Eine blockorientierte Datenübergabe, kompatibel zu Mint/Multitos, befindet
sich ebenfalls in der Entwicklung. Damit mü₧ten mit einem neuen GSZRZ
5400cps beim Senden UND Empfangen (57000Bd seriell) möglich sein.
Au₧erdem kommen intelligente und schnelle Interruptroutinen bei einer
Multitaskumgebung der ganzen Systemleistung zugute, so da₧ nicht
auszuschlie₧en ist, da₧ auch mal Tastendrücken, Mausbewegen und 38400Bd
ZMODEM-Übertragung gleichzeitig fehlerfrei möglich sind.
Probleme oder auch nicht
------------------------
Lange DMA-Zugriffe können beim Empfang zu Datenverlusten führen. Ebenfalls
kritisch sind lange Verweilzeiten der CPU in einem Interruptprioritätslevel
grö₧er als 5.
Auf 8MHz STs: Finger weg von Maus und Tastatur, während GSZRZ empfängt.
Sonst gibt es ein paar Übertragungsfehler.
Abspeichern empfangener Daten unter GSZRZ während des Empfangs soll laut
Berichten eines Testers nicht zu Fehlern führen.
Man kann den Blitter auf jeden Fall so programmieren, da₧ er die CPU zu
lange blockiert. Das TOS und NVDI tun dies anscheinend nicht.
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.
Ein Problemprogramm ist leider DCF_TIME von Ralf Zimmermann @WI2. Der Autor
kennt das Problem und die Lösung dazu. Ab Version 1.2 (wird bald kommen)
sollte es behoben sein. Pünktlich zu jeder Minutenkennung ist es zu lange
in der Interruptroutine (IPL6) und es gibt bei 38400Bd einen Empfangsfehler.
Funktion des HSMODEM1
---------------------
Seine Geschwindigkeit erreicht es durch optimierte Interruptroutinen und
durch das zusätzliche direkte Einklinken in den BIOS-Trap. Deshalb sollte
es möglichst spät im AUTO-Ordner gestartet werden, aber noch vor allen
Programmen, die Modem1 benutzen. Es mu₧ hinter Programmen stehen, die die
XBIOS-Funktion Bconmap umlenken oder die Anzahl der per Bconmap verfügbaren
Kanäle ändern (gibt es sowas schon?).
HSMODEM1 kann alle drei Handshakearten, die auch das TOS können sollte:
KEIN Handshake, XON/XOFF-Softwarehandshake, RTS/CTS-Hardwarehandshake.
Achtung: Die Angabe "BEIDES" als Handshakeparameter bei Rsconf wird vom TOS
in XON/XOFF umgewandelt. Da mir keine sinnvolle Anwendung für "BEIDES"
bekannt ist, arbeitet er ebenso.
Das direkte Einhängen in den BIOS-Trap ist bei TOS1.00 die einzige
Möglichkeit, die Routinen Bconin, Bconstat, Bconout und Bcostat zu
ersetzen. Ab TOS1.02 dient dieses Verfahren nur noch der
Geschwindigkeitssteigerung, denn HSMODEM1 setzt sich auch in die
entsprechenden xco...-Vektoren ein. Wenn das TOS Bconmap unterstützt (ab
Version 2.00), so erfolgt das Einsetzen auch in die entsprechende MAPTAB.
Dabei werden die Originalroutinen für Modem1 vollständig ersetzt. Der
BIOS-Kanal 6 ist mit HSMODEM1 unter allen TOS-Versionen als Modem1
verfügbar. Bei Nutzung von Kanal1 (AUX) wird die Einstellung über Bconmap
beachtet.
Im XBIOS-Trap wird eine neue Iorec-Routine eingehängt. Wenn das TOS
Bconmap unterstützt, wird noch Bconmap überwacht. Ebenfalls ersetzt wird
Rsconf. Das neue Rsconf wechselt bei einem Wechsel der Handshakeart auch
die seriellen Interruptvektoren des MFP aus.
Das Einhängen in den (X)BIOS-Trap erfolgt per XBRA-Verfahren mit der
Kennung RSVE.
Die vier für die serielle Kommunikation wichtigen Interrupts des MFP werden
durch neue Routinen ersetzt. Dabei wird für jede Handshakeart eine
spezielle Routine benutzt, ein wesentlicher Grund für die erreichte
Geschwindigkeit.
Praktischer Einsatz
-------------------
HSMODEM1 wird in den AUTO-Ordner kopiert. Dabei sollte es möglichst weit
hinten stehen, aber vor allen Programmen, die Modem1 nutzen. Bei jedem
neuen Booten wird es automatisch geladen. Es belegt dann etwa 2KByte im
RAM. HSMODEM1 kann ebenfalls durch Anklicken gestartet werden.
Versionen
---------
Ich vergebe keine Versionsnummern, sondern überlasse die
Versionsunterscheidung dem in der Installationsmeldung ausgegebenen Datum.
Ich notiere das Datum in der deutschen Schreibweise, also Tag.Monat.Jahr.
Harun Scheutzow (SWB), 16.03.1993