MagicSLM - Der ATARI-Laserdrucker am Apple Macintosh

Für viele überzeugte ATARI Fans war es naheliegend, sich einen ATARI SLM 605/804- Laserdrucker zu kaufen. Schließlich handelt es sich dabei um einen kostengünstigen Drucker, der am ATARI per ACSI-Port eine hohe Druckgeschwindigkeit ermöglicht. Jetzt, da viele User auf den Apple Macintosh umsteigen wollen bzw. schon umgestiegen sind, stellt sich die Frage, was man mit dem guten Stück anfangen kann ...

Das wichtigste Zubehör für einen Computer ist und bleibt der Drucker, denn irgendwann möchte jeder seine Arbeit schwarz auf weiß vor sich sehen. Beim Umstieg vom ATARI auf den Mac bemerkt man schnell, daß Apple sich für eher eigenwillige Schnittstellen zur Anbindung von Druckern entschieden hat- mit all seinen Vor- und Nachteilen. Deswegen hat man Probleme, seinen alten Drucker weiterzuverwenden. Hat der Drucker eine serielle Schnittstelle, reicht ein selbstgelötetes Kabel zum Anschluß. Um einen Drucker mit Centronics-Schnittstelle anzuschließen, muß man etwas tiefer in die Tasche greifen und einschlägige Wandler und Druckertreiber kaufen (z.B. PowerPrint). Beim einem so exotischen Drucker wie dem ATARI- Laser mit einem ACSI-Port hat man ja wohl überhaupt keine Chance, oder?

Der direkte Anschluß des SLM an den Mac scheitert zunächst an der eigenwilligen Schnittstelle, die ihm ATARI mit auf den Weg gegeben hat. ACSI ist leider nicht gleich SCSI. Selbst wenn dieses Problem mit aufwendiger Hardware gelöst würde, fehlt immer noch der passende Treiber für den Mac.

Glücklicherweise hat aberjeder SLM-Besitzer ja noch seinen ATARI in der Ecke stehender mangels Rechenleistung evtl. nicht mehr benötigt wird. Dafür gibt es auch einen passenden Treiber, der beim SLM ja mitgeliefert wird, und außerdem hat der ATARI ST genügend standardisierte Schnittstellen, um mit der Außenwelt in Kontakt zu treten. Was liegt also näher, als den ATARI als intelligentes Druckerinterface zu benutzen, der die vom Mac ankommenden Daten für den SLM aufbereitet?

Der einfachste Weg zur Datenübertragung zwischen ATARI und Mac ist die serielle Schnittstelle (beim Mac auch Druckerport genannt).

Als Übertragungsformat wäre bei Apple eigentlich PostScript am naheliegendsten. Da aber ein PostScript-Interpreter recht komplex ist und die Übertragung von PostScript-Daten doch recht langwierig werden kann, verwenden wir die von einem HP-LaserJet/ Deskjet-Druckertreiber erzeugten PCL-Daten. Schließlich handelt es sich hierbei auch um einen weit verbreiteten Standard.

Das Gesamtpaket im Detail - Hardware

Natürlich braucht man zunächst einen ATARI ST/TT mit einem SLM-Laser-drucker. Andererseits ist ein Mac mit RS422-Modem- oder Druckerport nötig. Schließlich benötigt man ein Kabel, das die RS422-Schnittstelle des Mac mit dem RS232-Port des ATARIs verbindet. Wenn Sie das noch nicht besitzen, dann können Sie es entweder kaufen oder Sie bauen es anhand der folgenden Anleitung selbst (wobei wir keine Haftung für auftretende Schäden übernehmen).

Als Bauteile benötigen Sie eine SUB-D-Buchse mit 9 oder 25 Polen (je nach ST/STE/TT-Typ),ein8adriges geschirmtes Kabel und einen Spoligen Apple-Talk-Stecker (siehe Bild 1 und 2).

Software

Auf der ATARI-Seite ist als erstes der Diablo-Druckertreiberfürden SLM nötig (liegt auf Disk dem Drucker bei). Dann brauchen Sie natürlich unser Programm MAGICSLM.ACC, das mit Sourcen in der Redaktions-Mailbox liegt.

Auf der Mac-Seite ist ein HP-Laser-jet/Deskjet-Treiber erforderlich - egal ob unter System 6/7 oder unter MagiC-Mac. Für System 6/7 bieten sich die folgenden beiden PD- beziehungsweise Shareware-Druckertreiber an, die Sie für den Mac ebenfalls in der Redaktions-Mailbox finden können: Chucks Printer Driver von Charles Rent-meesters: Dieser unterstützt nebenbei auch verschiedene Nadeldrucker.

HPDJ 3.1 von Ari Mujunen: Ein etwas schnellerer Treiber.

Benutzt man beim ATARI eine serielle Schnittstelle mit 56KB, können eventuell auch die Druckertreiber von Power-Print (s.o.) verwendet werden.

Benutzt man MagiCMac, dann sollte es kein Problem geben, genügend LaserJet/DeskJet-Treiberzu finden. Auf alten MagiCMac-Versionen (<1.1) können Sie zum Beispiel SpeedoGDOS verwenden, auf neueren Versionen bietet sich NVDIMac an. Auch andere Programme mit eingebauten Druckertreibern sollten problemlos funktionieren.

Insgesamt stellt sich das komplette System dann wie in Bild 3 dar. Als Bonus erlaubt das Programm aber zusätzlich die Eingabe der Daten als PCL-Datei von Disk und das Ausgeben der Daten als PCX-Datei.

Das Grundkonzept

Das grundlegende Programmkonzept ist schematisch in Bild 4 dargestellt. Das Programm wird als Accessory ausgelegt, damit es jederzeit im Hintergrund warten kann, auch wenn ein anderes Programm läuft oder man nicht in MultiTOS arbeitet. Der Nachteil ist, daß etwa 100KB an Arbeitsspeicher verlorengehen.

Das Kernstück des Programms ist die Multi-Event-Hauptschleife. Wird der Accessory-Eintragim Menü angewählt, ruft sie den Hauptdialog auf. Hier hat der Benutzer die Möglichkeit die Ein-und Ausgabemedien festzulegen. Hat der User im Dialog ,File' als Input gewählt, ruft die Hauptschleife sofort die Konversion auf. Wurde ,Modem' angeklickt, überprüft die Hauptschleife im Hintergrund mit Hilfe eines Timer-Events alle 2,5 Sekunden, ob Daten über die serielle Schnittstelle angekommen sind. Erst dann wird auch hier die Konvertierung gestartet.

center
Bild 1: Verdrahtungsplan zur Verbindung von RS422 nach RS232
Bild 2: Pinbelegung der AppleTalk-Buchse

Macintosh mit System 7 oder MagicMac LaserJet/DeskJet Druckertreiber

Atari mit PCL-Emulator und Diablo-Treiber und beliebigem als 'intelligenter' Druckerspooler

Die Konvertierungsroutine legt zunächstfest, welche Funktionen für die Ein- und Ausgabe benutzt werden. Danach wird der Speicher (besonders für den Seitenpuffer) alloziert. Dann wird der Statusdialog aufgebaut, der einerseits zur Information über den augenblicklichen Zustand dient und andererseit dem Benutzer einige einfache Eingriffsmöglichkeiten gibt. Ab jetzt hat das Accessory die Kontrolle über den Rechner übernommen. Andere Programme werden angehalten. Nun werden die Daten Byte für Byte eingelesen und umgewandelt. Dabei kümmert sich die Input-Routine auch um eventuelle Benutzereingaben, die als .Daten' der Wandelroutine mitgeteilt werden.

Die eingelesenen Byte-Folgen werden als PCL-Befehle interpretiert und in den internen Seitenpuffer als Rasterdaten übertragen. Wird ein ,Form-Feed'empfangen, wird jeweils die Seite ausgegeben. Ist die Konversion beendet oder hat der Benutzer abgebrochen, werden die Speicher freigegeben und das Accessory verschwindet wieder im Hintergrund.

Insgesamt besteht das Programm aus folgenden Dateien:

Die GEM-Funktionen und die Routinen der Hauptschleife befinden sich in MAGICSLM.C, die Verwaltung der verschiedenen Eingabemöglichkeiten in SERIAL.C bzw. FILE.C. Die Ausgabe wird in SLM.C und PCX.C abgehandelt. Die eigentliche Konvertierung findet dann noch in CONTROL.C und PCL-UTILS.C statt. Zusätzlich gibt es ein globales Headerfile GLOBAL.H und eines speziell für die PCL-Konvertierung PCL.H. Die Resourcen für die beiden Dialoge werden in MAGIC-SLM.H/RSH/RH/RSC definiert. Ein Project-FilefürPure-C (LASER.PRJ) liegt ebenfalls vor.

Diese Dateien befinden sich in der Redaktions-Mailbox.

Das Programm im Detail

Die GEM-Oberfläche

Da es sich bei diesem Programm um ein Accessory handelt, ist zusätzlich zur normalen Applikationsanmeldung noch eine Registrierung im Menü nötig, mit:

MenuId = menu_register(AplId,AccName);

Sollte dieser Funktionsaufruf einen negativen Wert zurückliefern, beendet sich das Programm einfach.

Die Resourcen werden mit #include dazukompiliert, deshalb muß man nur noch die Umrechnung für jedes Objekt der beiden Dialoge auf Bildschirmkoordinaten durchführen:

Setup = (OBJECT *)rs_trindex [SETUP];
FixTree(Setup);

Das Kernstück der Haupschleife ist dann der Multi-Event, der auf Messages und-fallsnötig-aufTimer-Events zum Überprüfen der Schnittstelle reagiert:

EventRes=evnt_multi ( MU_MESAGI TimerMode,0,0,0,0,0,0,0,0,0,0,0,0,0, MsgBuf fer, WAIT, 0, &Dummy, &Duiratty,&Dummy, &Dummy,&Dummy,&Dummy);

Neben dem Timer-Event wird nur noch auf die /4C_OPE/V-Message reagiert, die durch Anklicken des Accessory-Menüeintrags erzeugt wird und dazu führt, daß der Hauptdialog geöffnet wird.

center
Bild 4: Das Programm-Grundkonzept

Dieser Dialog verwaltet je zwei Radiobuttons zur Auswahl von Ein- und Ausgabe sowie zwei Exitbuttons. Wird der Dialog mit ,Stop' verlassen, wird der Timerevent zur Überprüfung der seriellen Schnittstelle abgeschaltet. Bei .Start' wird der Status der Radiobuttons ausgewertet und danach alle nötigen Dateinamen vom Benutzer angefordert. Wurde als Input der serielle Port gewählt, schaltet die Funktion den Timer-Event ein und schließt den Dialog. Bei einem Input über eine PCL-Datei startet sie gleich die Konversion.

Im Anschluß daran folgen noch einige allgemeine Funktionen zur Verwaltung von Dialogen:

InitDlg übenimmt die Mauskontrolle, sperrt den Bildschirm und zeichnet den gewünschten Dialog. Dabei ist zu beachten, daß die Ausmaße des Dialogs in statischen Variablen gespeichert werden, damit weitere Funktionen darauf zugreifen können. Daher ist es mit diesen Funktionen nicht möglich, mehrere Dialoge gleichzeitig auf dem Bildschirm darzustellen.

CloseDlg schließt den derzeit angezeigten Dialog und gibt die Mauskontrolle wieder frei.

Da das Programm Benutzereingaben parallel zum Empfang von Daten ermöglichen muß, kann bei der Abfrage der Buttons im Statusdialog nicht auf die GEM-Funktionen zurückgegriffen werden. Die Funktionen CheckBut-ton und SelectButton übernehmen diese Aufgabe.

CheckButton überprüft zuerst, ob die linke Maustaste gerade gedrückt ist:

graf_mkstate(&Mx, &My, &MbState, &MkState); S if(MbState&l) (...)

In diesem Fall werden die Mauskoordinaten mit den Positionen der Buttons im Dialog verglichen. Im Trefferfall wird dann die ID des entsprechenden Buttons plus 255 zurückgegeben.

if (objc_tind(Print,ABBR,0,Mx,My)>=0) return ABER*255;

SelectButton selektiert oder deselektiert einen Button und zeichnet ihn neu.

PCL-Dateneingabe über die serielle Schnittstelle

Der Mac sendet die PCL-Druckerdaten normalerweise über den Drucker-oder Modemport zum ATARI. Je nach Hardware-Ausstattung des ATARI kann man dabei 19200 Baud oder 57600 Baud auf der Apple-Seite einstellen. Dabei benutzt der Apple üblicherweise XON/ XOFF zum Handshake.

Grundsätzlich sollte man im Kontrollfeld beim ATARI die selben Werte wie auf dem Mac einstellen; dann werden sie automatisch auch von unserem Programm benutzt. Es gibt nur einen Unterschied zu beachten: Im Kontrollfeld muß das Handshake ausgeschaltet werden. Der Grund ist, daß die vom Mac gesendeten PCL-Daten durchaus XON/XOFF-Werte enthalten können, die aber nur als Daten, nicht als Handshake-Befehle zu verstehen sind. Wäre Handshake angeschaltet, kämen diese Daten bei MagicSLM nicht an. Deswegen sendet MagicSLM die nötigen Befehle selbst, ignoriert aber ankommende Befehle.

Da die Hauptschleife nur alle 2,5 Sekunden nachfragt, ob Daten angekommen sind, ist der übliche Systembuffer von 256 für die serielle Schnittstelle doch sehr klein. Deswegen melden wireinen eigenen Buffervon 16KB an. Dazu dient die Routine S/n/t, die die systemeigene /orec-Struktur zunächst sichert und dann unsere eigenen Werte einträgt:

iorec->ibuf=buffer; /* Neuer Buffer /
iorec->ibufsiz=SBUFFSIZE;
/
dessen Größe / iorec->ibufhd=0; / Nächste Input-Adresse /
iorec->ibuftl=0; /
Nächste Leseadresse /
iorec->ibuf low=IBLOW;
/
Wasserstandsmarken*/
iorec->lbufhi=IBHI;

Die Wasserstandsmarken geben an, wie voll der Buffer werden darf, bevor die Übertragung mit XOFF angehalten wird, und wie leer er durch das Abarbeiten werden soll, bevor es mit XON wieder weitergeht.

Wenn die serielle Schnittstelle nicht mehr gebraucht wird, müssen die alten Werte wieder in iorec kopiert werden. Siehe SCIose.

SRec überprüft, ob Daten im Buffer der seriellen Schnittstelle vorliegen. Das ist der Fall, wenn die Leseadresse (also der Zeiger auf die Stelle von det das nächste Byte im Buffer gelesen werden kann) einen anderen Wert als die Input-Adresse (die Stelle an der das nächste ankommende Zeichen zwischengespeichert wird) hat.

Das eigentliche Lesen von Daten über die serielle Schnittstelle führt SGet durch. Liegt kein Zeichen im Buffer, wartet die Funktion so lange, bis eines ankommt. Sollte während j der Wartezeit ein Button gedrückt werden, wird gleich dessen ID+255 zurückgegeben.

Ansonsten wird das nächste Byte ausgelesen und der Lesezeiger zyklisch erhöht. Zusätzlich werden die Wasserstandsmarken überprüft, und wenn nötig XON/XOFF gesendet.

PCL-Dateneingabe über eine Datei

Eine andere Möglichkeit zur Eingabe der PCL-Daten ist das direkte Einlesen von einer Datei. Damit das byteweise Auslesen ausreichend schnell erfolgt, werden die Daten aus der Datei immer blockweise in einen Buffer gelesen.

GetNextByte liest die Werte byteweise aus dem Buffer aus und lädt ihn wenn nötig wieder mit neuen Daten. Zusätzlich werden auch hier die Buttons abgefragt.

Beim Öffnen einer neuen Datei, muß der Buffer initialisiert werden. Dies geschieht mit InitFile.

Das war's für dieses Mal, denn leider müssen wir aus Platzgründen den Artikel hier unterbrechen. In der nächsten ST-Computer geht es dann weiter mit der Ausgabe auf den SLM-Drucker, der Bedienung der Software und mögliche Fehlerquellen.

Bernd Spellenberg, Harald Schönfeld

Literatur:

HP LaserJet III Printer Technical Referees

Manual ATARI Profibuch, Sybex



Aus: ST-Computer 01 / 1996, Seite 46

Links

Copyright-Bestimmungen: siehe Über diese Seite