Rufus und Connect - Damit wir in Verbindung bleiben...

Auf dem ATARI-Sektor gibt es zwei Terminalprogramme, die einen besonders großen Anwenderkreis haben: Rufus und Connect jeweils Shareware-Produkte. Und noch etwas haben beide Programme gemeinsam: Vor nicht allzu langer Zeit gab es neue, im Funktionsumfang erweiterte Versionen. So liegt Connect inzwischen in der Version 2.2 vor, Rufus als Version 1.35.

Daß Terminalprogramme auf allen Computersystemen eine immer größere Bedeutung gewinnen, läßt sich daraus ableiten, daß die Zahl der Benutzer von Mailboxen stetig zunimmt. Sinkende Preise für Modems machen die DFÜ immer attraktiver. Für ATARI-Anwender stellt insbesondere das deutschlandweit vernetzte Mausnetz ein interessantes Forum auf Mailbox-Basis dar. Auf lokaler Ebene sind inzwischen überall Mailboxen auch für den ATARI vertreten. Zur Kommunikation auf dieser Ebene sind Terminalprogramme unerläßlich. Solche Software ist jedoch nicht ausschließlich für Anwender interessant, die ein Modem besitzen und mit dessen Hilfe den Kontakt zur Außenwelt suchen. Auch für die Rechnerkopplung über die serielle Schnittstelle oder auch den MIDI-Port leistet Terminalsoftware wichtige Dienste. Dabei spielt es keine Rolle, ob sich zwei ATARIs miteinander „unterhalten“ sollen, oder ob die Datenübertragung zwischen einem ATARI und irgend einem anderen Rechnersystem erfolgt. Stets wird auf beiden Seiten ein Programm benötigt, das die Datenübertragung von der Software-Seite her überwacht und die richtigen Schnittstellenparameter einstellt. Besonders an Hochschulen werden ATARIs häufig als Terminals eingesetzt, über die der Kontakt zu VMS- oder Unix-Systemen hergestellt wird.

Übertragungsraten

Die Geschwindigkeit bei der Datenübertragung mittels serieller Schnittstelle hängt zunächst einmal von der maximalen Baud-Rate ab, die die beteiligten Rechner erlauben. Dabei handelt es sich um eine Angabe für den Takt, der der Datenübertragung zugrundeliegt, in der Praxis aussagekräftiger ist die Angabe des Datenstroms in bps (Bits pro Sekunde). Daß dieser Wert nicht unbedingt mit der Baud-Rate identisch ist liegt daran, daß neben den eigentlichen Daten noch weitere Informationen über die Leitung geschickt werden müssen, die zur Steuerung der Datenübertragung dienen.

Verwendet man ein Terminalprogramm zur Kopplung zweier Computer (Nullmodemverbindung), wird man in der Regel die höchste Übertragungsrate verwenden, auf die sich beide Rechner verständigen können. Bei den ATARI-Computern ist dieser Wert abhängig von der jeweiligen Schnittstelle. Besitzen ST und Falcon030 lediglich eine serielle Schnittstelle, sind es beim MegaSTE bereits zwei und beim TT gleich vier. Dabei beträgt die maximale Übertragungsrate beim ST 19200 Baud, bei den anderen Geräten sind bis zu 115200 Baud möglich. Dieser Wert stellt für den MegaSTE eher ein theoretisches Maximum dar, da der STE in der Praxis nicht schnell genug ist, diese Geschwindigkeit zu realisieren. Falcon und TT spielen jedoch selbst hier noch mit. Inzwischen erlaubt es zusätzliche Hardware, auch einen ST mit bis zu 57600 Baud zu betreiben, was in erster Linie für die Besitzer von High-Speed-Modems wichtig ist.

Das Modem als Nadelöhr

Im Gegensatz zu einer Nullmodemverbindung ist beim Modembetrieb nicht mehr ausschließlich die Hardware der miteinander gekoppelten Rechner von Bedeutung. Als weiterer Faktor kommt hier das Modem ins Spiel. So beträgt die maximale Übertragungsrate handelsüblicher Modems 19200 Baud, in Ausnahmefällen auch mehr (Turbo PEP). Zwar lassen sich manche Modems mit einer Baud-Rate von bis zu 76800 Baud an den Computer koppeln, doch bei der eigentlichen Übertragung der Daten über die Telefonleitung ist bei 19200 Baud die Grenze erreicht. Somit drängt sich der Eindruck auf, daß die maximale Übertragungsrate bereits dann erreicht werden kann, wenn man ein Modem an einem ST betreibt, dessen Schnittstelle standardmäßig 19200 Baud unterstützt. Da sich die maximale Geschwindigkeit bei der Datenübertragung nach dem schwächsten Glied in der Kette, also der Telefonleitung, richtet, sollte sich so selbst das schnellste Modem zufriedenstellend am ST betreiben lassen.

In der Praxis sieht das jedoch ein wenig anders aus. Die heutigen Modems sind in der Lage, den zu versendenden Datenstrom automatisch nach ausgefeilten Methoden zu komprimieren. Dabei läßt sich insbesondere bei Texten mehr als die Hälfte der Daten einsparen. Und schon sieht unsere Rechnung ganz anders aus: Um bei einer durchschnittlichen Komprimierung von 50% eine Modem-Modemverbindung mit 19200 Baud voll auszulasten, muß die Kopplung zwischen Rechner und Modem mit mindestens 38400 Baud erfolgen. Andernfalls entstehen Wartezeiten, da das Modem die Daten schneller komprimieren könnte, als sie vom Computer geliefert werden.

Daten, die bereits vor der eigentlichen Übertragung mit Hilfe eines Archivierungsprogramms wie LHARC, ZOO oder ZIP komprimiert wurden, können vom Modem naturgemäß nicht weiter geschrumpft werden. Wer also ein Modem besitzt, das von sich aus keine Datenkompression beherrscht, sollte Daten vor der Übertragung unbedingt mit einem der genannten Programme komprimieren.

Von der Hardware zur Software

Wie wir gesehen haben, muß ein Terminalprogramm gleichermaßen für den Nullmodem- als auch für den Modembetrieb geeignet sein. Bei Nullmodemverbindungen ist es besonders wichtig, daß möglichst hohe Baud Raten unterstützt werden. Ärgerlicherweise bietet TOS hier nur sehr magere Möglichkeiten. So handelt es sich bei der maximalen, vom Betriebssystem unterstützten Baud-Rate um 19200 Baud. Höhere Geschwindigkeiten lassen sich nur dadurch realisieren, daß in ein Terminalprogramm neue, eigene Routinen zur Ansteuerung der seriellen Schnittstellen integriert werden. Dies bedeutet für den Programmierer einen erhöhten Programmieraufwand, und zwar für eine Aufgabe, die eigentlich dem Betriebssystem obliegt.

Sowohl Connect als auch Rufus bieten Baud-Raten in unterschiedlichen Abstufungen an, die je nach Rechner und Schnittstelle bis zum Maximalwert von 115200 Baud bei Rufus und 153600 Baud bei Connect reichen. Auch Übertragungen über die MIDI-Schnittstelle werden von beiden Programmen unterstützt. Mit Connect können bei MegaSTE und TT alle Schnittstellen gleichzeitig aus verschiedenen Fenstern heraus bedient werden, was einer Art Multitasking innerhalb des Programms entspricht. Es ist also kein Problem, mehrere Schnittstellen gleichzeitig zu betreiben. Klar, daß so etwas nur dann Sinn macht, wenn man über mehr als ein Modem verfügt oder wenn mehrere Nullmodemverbindungen aufgebaut sind.

Terminalemulationen

Heutzutage ist man gewohnt, bei der Arbeit am Computer die absolute Kontrolle über den Bildschirm zu besitzen. So mutet es als Steinzeit-EDV an, wenn man noch auf zeilenorientierte Software angewiesen ist, die es nicht erlaubt, den Cursor frei auf dem Bildschirm zu positionieren. Dabei war das ursprünglich einmal der Normalzustand, denn zu Zeiten, als die Ein-/Ausgabe von Daten noch über Lochkarten erfolgen mußte, war naturgemäß kein bildschirmorientiertes Arbeiten möglich.

Was die Bildschirmausgabe angeht, haben sich im Laufe der Jahre diverse Standards für die Terminalsteuerung etabliert. Selbst der ATARI hat eine einfache Terminalemulation (VT52) im ROM integriert, die allerdings kaum noch Verwendung findet. Weit verbreitet ist dagegen die sogenannte VT100-Emulation, nicht zuletzt deshalb, weil unter VT 100 auch farbige Darstellungen möglich sind und die ANSI-Steuercodes unterstützt werden, wie sie auf DOS-Systemen Verwendung finden. Rufus und Connect unterstützen neben VT52 und VT 100 auch VT220, Rufus sogar einige VT330-Codes.

Connect bietet neben den textorientierten VT-Modi auch eine TEK-Betriebsart (benannt nach den TEKTRONIX-Terminals) an. Hierbei handelt es sich um eine Emulation, die die Darstellung von Grafiken erlaubt. Voraussetzung für eine sinnvolle Nutzung dieser Option ist natürlich, daß die Gegenstelle in der Lage ist, solche Grafiken zu liefern. Die Ausgabe der Grafik im TEKTRONIX-Fenster kann als GEM-Metafile oder direkt auf dem Drucker erfolgen, sofern GDOS (z.B. NVDI oder Speedo) installiert ist.

Los geht’s

Es ist also soweit, die Schnittstellenparameter sowie die Terminalemulation sind eingestellt, der Verbindungsaufbau steht an. Eine einfache Anwahl ermöglichen die Wahldialoge von Rufus und Connect, die jeweils in einem eigenen Fenster untergebracht sind (Bild 1). Besonders für den Anwender von MultiTOS oder MagiX! bringt dies einen erhöhten Bedienungskomfort mit sich, da so jederzeit der Wechsel in eine andere Anwendung möglich ist.

Per Mausklick wird die Anwahl eingeleitet. Ist die Verbindung hergestellt, erscheinen die ankommenden Informationen im Terminalfenster, wobei sich, GDOS vorausgesetzt, Zeichensätze nach eigener Wahl verwenden lassen. Es empfiehlt sich, einen Font mit ANSI-Zeichenvorrat zu verwenden, wie er in der DFÜ-Szene weit verbreitet ist. Rufus und Connect liegt ein solcher Zeichensatz bei. In der Regel wird man zumindest auf einem SM 124 ohnehin nicht mit dem Standard-System-Font arbeiten, weil dieser bei der üblichen Terminalgröße von 80x25 Zeichen zu groß ist, um alle Informationen auf einem Blick darzustellen. Schließlich fordern auch die Fensterelemente ihren Tribut bezüglich des Platzes.

Übertragungsprotokolle

Ein wichtiger Anwendungsbereich von Terminalprogrammen ist neben der reinen Kommunikation die Übertragung von Dateien. Hier haben sich im Laufe der Zeit unterschiedliche Übertragungsprotokolle entwickelt. Häufig wird die Übertragung durch das Terminalprogramm initiiert und dann von einem externen Programm abgewickelt, das vom Terminalprogramm aus bei Bedarf gestartet wird und sich speziell auf das gewünschte Übertragungsprotokoll versteht. Ursprünglich war auch für das schnelle, weit verbreitete ZMODEM Protokoll ein zusätzliches Programm zwingend notwendig, das auf dem ATARI vom jeweiligen Terminalprogramm automatisch aufgerufen wurde. Diese Aufgabe erfüllt auch weiterhin besonders gut das GSZRZ-ZMODEM von Xenia-Software (Michael Ziegler). In den aktuellen Versionen von Rufus und Connect wurden die wichtigsten Funktionen von ZMODEM jedoch integriert, so daß man für Standardanwendungen auf ein externes ZMODEM-Programm verzichten kann (Bild 2). In speziellen Fällen kann der Einsatz eines externen Programms aber weiterhin sinnvoll sein. So erlaubt GSZRZ Blockgrößen von bis zu 8192 Bytes, was sich positiv auf die Übertragungsgeschwindigkeit auswirkt, und unterstützt eine Kompression von ASCII-Daten. Dieser Modus ist vor allen Dingen für diejenigen interessant, die kein Modem mit MNP5 oder V42bis besitzen, bei dem die Daten bereits von der Modem Hardware komprimiert werden.

Zwar ist das ZMODEM-Protokoll heute weit verbreitet, aber es ist nicht auszuschließen, daß eine Situation eintritt, die ein anderes Protokoll erfordert. So ist vor allen Dingen das Kermit-Übertragungsprotokoll noch hin und wieder anzutreffen. Sowohl Rufus als auch Connect bieten daher zusätzlich zu den internen Protokollen die Option, beliebige andere Protokolle anzusprechen. Voraussetzung ist allerdings, daß man über externe Programme verfügt, die sich vom Terminalprogramm aus aufrufen lassen und dann die Übertragung übernehmen können. Wer Kermit als Protokoll benötigt, wird davon profitieren, daß Rufus nicht nur ein externes Kermit-Modul beigelegt ist, sondern daß darüber hinaus auch ein internes Kermit-Protokoll verfügbar ist.

Automatismen

Hat man einmal die wichtigsten Anwendungsbereiche für sein Modem erschlossen, stellt man fest, daß bei der Kommunikation mit Mailboxen gewisse Prozeduren in schöner Regelmäßigkeit auszuführen sind. Sei es das Anmelden (Einloggen) in der Mailbox oder der anschließende Datenaustausch, der stets nach einem festen Schema abläuft. Um solche Vorgänge zu automatisieren und zu beschleunigen, besitzen Rufus und Connect eine spezielle Programmiersprache, mit der sich kleine Programme (Scripts) entwickeln lassen, die die „Unterhaltung“ mit der Mailbox unkompliziert gestalten.

Diese Script-Sprachen bestehen in erster Linie aus Kommandos zur Anwahl und Modemsteuerung, es lassen sich aber auch Abfragen formulieren und Texte einlesen bzw. ausgeben. Die von Connect zur Verfügung gestellte Sprache ist besonders umfangreich und wird vor allen Dingen Anwender mit Unix oder MiNT-Erfahrung erfreuen, ist sie doch eng an die Shell-Sprachen angelehnt, wie man sie von diesen Systemen her kennt. Die Script-Sprache von Rufus mag zwar etwas weniger mächtig sein als die von Connect, erfüllt aber alle Anforderungen des täglichen Gebrauchs. Sehr praktisch ist eine Option in Connect, mit der sich ein Shellscript automatisch erzeugen läßt. Dabei zeichnet Connect eine komplette Sitzung auf und kann diese dann später automatisch ablaufen lassen. Auf diese Weise lassen sich selbst umfangreiche Scripts leicht erzeugen. die anschließend kaum noch nachbearbeitet werden müssen.

Spezialitäten

Eines der herausragenden Merkmale von Connect läßt sich in Verbindung mit den Modems U-1496 der Firma ZyXEL ab ROM-Version 5.00 nutzen. (Inzwischen dürften diese Modems auch in einer postzugelassenen Variante auf dem Markt sein.) Das U-1496 läßt sich nämlich nicht nur für den reinen Modembetrieb einsetzen, sondern kann darüber hinaus auch die Funktionen eines Anrufbeantworters übernehmen. Ein Teil der Funktionalität muß dabei vom Computer und der Terminalsoftware übernommen bzw. gesteuert werden.

Die Aufnahme der eigenen Ansagen kann wahlweise über ein externes Mikrofon oder aber über den Telefonhörer erfolgen. Die Digitalisierung der Sprache wird dabei vom Modem durchgeführt, das die Daten sofort an den Rechner weiterleitet. Dort lassen sich eine oder mehrere Ansagen auf der Festplatte unterbringen, wo sie bei Bedarf, also im Falle eines Anrufs, von Connect abgerufen werden. Spricht der Anrufer anschließend etwas „aufs Band“, wird auf ähnliche Weise verfahren und der Text wird für einen späteren Abruf bereitgehalten. Das alles setzt natürlich voraus, daß der Computer die ganze Zeit über eingeschaltet ist, damit Anrufe entgegengenommen werden können. Über die in Connect integrierte Script-Sprache läßt sich übrigens auch eine Fernabfrage realisieren. Dabei ist die Flexibilität im Vergleich zu handelsüblichen Anfrufbeantwortern ungleich größer, denn über die Fernabfrage im Verbindung mit einem passenden Script läßt sich alles Erdenkliche in die Wege leiten.

Rufus bietet zwar keinen Anrufbeantwortermodus, dafür ist hier aber ein einfacher BTX-Decoder im Lieferumfang enthalten, der direkt aus Rufus heraus aufgerufen werden kann und so BTX auf dem ATARI ermöglichen soll. Im Test war der Einsatz des Decoders auf einem TT allerdings nicht von Erfolg gekrönt. Das Programm ist bereits etwas älteren Datums, und das mag der Grund dafür sein, daß es sich nicht zur Zusammenarbeit mit dem TT überreden ließ. Registrierte Connect-User können einen BTX-Decoder direkt beim Autor erhalten.

Handbuch inklusive

Sowohl für Rufus als auch für Connect gibt es für registrierte Benutzer Programmbeschreibungen in Formeines Handbuchs. Das ist insofern nicht selbstverständlich, als es sich bei beiden Programmen um Shareware-Produkte handelt. Die Programmbeschreibungen unterstreichen den professionellen Anspruch, den beide Programme zu Recht für sich erheben. Sowohl die eigentlichen Programmfunktionen als auch die Script-Sprachen sind beschrieben, zum Teil mit Beispielen. Auf den Programmdisketten finden sich darüber hinaus einige vorgefertigte Scripts, mit deren Hilfe sich die wichtigsten Mailbox-Systeme nutzen lassen, ohne daß man sich erst selber ein Script zusammenbasteln müßte.

Egal ob Rufus oder Connect, beide Programme sind Shareware und als solche frei erhältlich. Leider scheint es sich unter den ATARI-Anwendern immer noch nicht herumgesprochen zu haben, daß bei regelmäßiger Nutzung eines Shareware-Produkts der Shareware-Beitrag fällig wird. Um dem Benutzer diesen Umstand ins Gedächtnis zu rufen, besitzt die nicht registrierte Version von Connect einige Einschränkungen, die durch die Eingabe eines persönlichen Schlüssels aufgehoben werden.

Wer also an einem der Programme Gefallen findet, muß sich registrieren lassen. Die Gebühr beträgt bei Rufus 50,- DM ohne und 60,- DM inklusive Handbuch, bei Connect ist man mit Handbuch ebenfalls für 60,- DM dabei.

Jedem das Seine

Betrachtet man den Funktionsumfang der beiden Terminalprogramme, präsentiert sich Connect mit einem größeren Angebot. Dies bringt allerdings den Nachteil mit sich, daß die Programmbedienung aufgrund der zahlreichen Optionen unübersichtlicher wirkt, als es bei Rufus der Fall ist. Die integrierte Online-Hilfe bringt hier eine gewisse Entlastung. Wer Wert auf ein möglichst unkompliziert zu bedienendes Programm legt und sein Zyxel-Modem nicht als Anrufbeantworter einsetzen will, dürfte daher mit Rufus besser bedient sein. Für fortgeschrittene Anwender, die bereits Erfahrung mit Terminalprogrammen haben, wird eher Connect das Programm der Wahl darstellen, da es umfangreiche Einstellmöglichkeiten bietet, die jeder Anwendung gerecht werden dürften.

Egal, ob man zu Connect oder Rufus greift: Man kann sich sicher sein, für den alltäglichen Terminalbetrieb eine gute Wahl getroffen zu haben. Daher kann man sowohl Rufus als auch Connect durchaus empfehlen.

Bezugsquellen:

Rufus:

Creativ Concept
Michael Bernards
Am Waldeck 16
53797 Lohmar

Connect:

Wolfgang Wander
Rudolf -Breitscheid-Str. 63a
22880 Wedel

GSZRZ

XENIA Software
Michael Ziegler
Jagdfeldring 16 85540 Haar

Uwe Seimet

---

---