Spuler v4.5 ½by Martin Rogge M”llenholt 24 24107 Kiel 27. Juli 1995 Inhaltsverzeichnis ================== 1) Lieferumfang 2) Copyright 3) Beschreibung 3.1) Wozu das Ganze 3.2) Funktionsweise des Spoolers 3.3) Installation 3.4) Konfiguration 3.5) Der Normalbetrieb 3.6) Zusammenarbeit mit GEMINI 3.7) Zusammenarbeit mit MagiC und MultiTOS 3.8) Technisches 4) Bugs oder Features 5) Was ist neu 5.1) in Version 4.0 5.2) in Version 4.1 5.3) in Version 4.2 5.4) in Version 4.3 5.5) in Version 4.4 5.6) in Version 4.5 6) Literatur 1) Lieferumfang =============== Das System Spuler v4.5 besteht aus folgenden Dateien: SPULER45.APP Oberfl„che mit integriertem Filespuler SP45_TSR.PRG Hintergrundprogramm SP45_CFG.PRG Konfigurationsprogramm SP45_CFG.RSC zugeh”rige Resource-Datei SPULER45.IMG Zustandsdiagramm im GEM-Imageformat SPULER45.DVI Dokumentation als TeX-Datei SPULER45.TXT Dokumentation im ASCII-Format Die Weitergabe des unvollst„ndigen Systems ist untersagt. 2) Copyright ============ Spuler v4.5 ist nicht PD, d.h. ich, Martin Rogge, behalte alle Rechte an dem Programm. Es ist aber erlaubt und erwnscht, Spuler v4.5 zu benutzen und komplett mit allen Dateien weiterzugeben, auch in komprimierter Form. Dabei darf jedoch nur der zur Deckung aller Unkosten ben”tigte Geldbetrag gefordert werden. Falls jemand irgendwo mehr bezahlen mužte, so m”ge er oder sie mir bitte schreiben. Auch Fehlerberichte und Fragen sind mir willkommen. Postanschrift: Martin Rogge M”llenholt 24 24107 Kiel MausNet: Martin Rogge @ KI Internet: martin_rogge @ ki.maus.de Selbstverst„ndlich geschieht die Benutzung auf eigene Gefahr, ich ber- nehme keinerlei Haftung fr irgendwelche Datenverluste oder sonstwas. Nach diesen strengen Worten kann ich Dich, lieber Leser, aber beruhigen: Ich pers”nlich benutze das Programm seit Jahren (in der jeweils aktuel- len Version) und habe bestimmt schon Gigabytes hindurchgepumpt, ohne jedes Problem. 3) Beschreibung =============== 3.1) Wozu das Ganze ------------------- Eine der unangenehmsten Eigenschaften des Atari-Betriebssystems ist die Tatsache, daž I/O-Operationen (mit Ausnahme serieller Kan„le) nicht im Hintergrund durchgefhrt werden, obwohl die Hardware dafr ausgelegt ist. Wer hat nicht schon minutenlang in die R”hre gesehen, w„hrend der Rechner einen Ordner mit 100 Dateien von Laufwerk A: nach Laufwerk B: kopiert hat, obwohl dabei nur eine effektive Prozessorleistung von ge- rundet 0% ben”tigt wird? Indes ist bei Floppy-Operationen auch kaum Abhilfe m”glich, da die einzige Instanz des Betriebssystems, die (etwa beim Dateizugriff) begrenzt in die Zukunft blicken k”nnte, n„mlich das DOS, eine abgeschlossene Einheit bildet. (Seit dem Erscheinen von MagiC 3 hat sich dieser Sachverhalt allerdings ge„ndert.) Aužerdem br„uchte man zus„tzliche Kommunikationsmittel, damit die Direktprogrammierung der Hardware, wie sie von fast allen Kopier- und Formatierprogrammen ange- wandt wird, nicht zum Absturz fhrt. Dagegen kann der Datentransfer ber die Parallelschnittstelle relativ einfach in den Hintergrund gedr„ngt werden. Das genau ist die Aufgabe von Spuler v4.5. Eine weitere Aufgabe von Spuler v4.5 ist es, auf ein- fache Art und Weise aus GEM-Anwendungen heraus die Spulfunktion ber- wachen und kontrollieren zu k”nnen. Ferner ist seit Version 4.4 ein Filespuler integriert. Das Hauptaugenmerk dabei liegt darauf, daž all dieses auf m”glichst saubere Art und Weise geschieht, also m”glichst betriebssystemkonform und mit geringstm”glichen Einbužen bei der allge- meine Performance. šbrigens ist Spuler v4.5 kein v”llig neues Programm, sondern seit 1988 mehr oder weniger kontinuierlich gewachsen. Die Version 3.0 ist in der c't 6/90 abgedruckt worden. 3.2) Funktionsweise des Spoolers -------------------------------- Bei der Darstellung des Spulprozesses muž man seit Version 4.4 termino- logisch aufpassen, da es jetzt zwei verschiedene Mechanismen gibt, die in der Umgangssprache beide "Spooler" genannt werden. Nennen wir den einen "Interruptspuler" und den anderen "Filespuler". Dabei ist der Interruptspuler der wichtigere der beiden. Er ist auch historisch der Kern von Spuler v4.5. Der Interruptspuler legt einen ausreichend grožen Datenpuffer an und biegt alle relevanten BIOS-Ausgabevektoren um. Soll nun frderhin ein Zeichen ausgegeben werden, so wandert es in den Puffer. Danach steht der Pozessor sofort fr weitere Aufgaben zur Verfgung. Der Spulprozež l„uft selbstt„tig im Interrupt: Immer dann, wenn der Drucker die Busyleitung zurcksetzt, wird ein Interrupt der Priorit„t 6 ausgel”st. Dieser Inter- rupt gibt dann das n„chste Zeichen aus. Die Ausgabefrequenz kann man b- rigens nicht vorhersehen, sie wird vollst„ndig vom Drucker gesteuert und ist daher maximal. Sie interessiert aber auch nicht, da der Prozež ja im Hintergrund abl„uft (einen hinreichend grožen Puffer vorausgesetzt). Obige Darstellung ist natrlich etwas vereinfacht, so mssen etwa die F„lle eines vollen oder leeren Puffers sowie Eingriffe des Steuerpro- gramms bercksichtigt werden. Was macht nun der Filespuler? Er ist im Steuerprogramm angesiedelt (das auch als Accessory benutzt werden kann) und muž explizit angestožen wer- den. Man gibt ihm einen Dateinamen und er versucht dann, diese Datei in gleichm„žigen Abst„nden h„ppchenweise auf den Drucker auszugeben. Dazu sieht er regelm„žig nach, ob genug Platz im Puffer fr ein weiteres H„ppchen ist. Dank des Interruptspulers kommen beim Drucker trotzdem keine Datenh„ppchen an, sonder ein kontinuierlicher Datenstrom, der da- rberhinaus auch noch maximale Datenrate hat. 3.3) Installation ----------------- Um normale Druckerausgaben im Hintergrund durchzufhren, reicht es vollst„ndig, das TSR zu installieren. Am einfachsten kopiert man zu die- sem Behufe die Datei SP45_TSR.PRG in den Auto-Ordner. Fr den Inter- ruptspulbetrieb selbst wird das Steuerprogramm nicht ben”tigt. Das Steuerprogramm SPULER45.APP erlaubt es einem, den Fllstand des Druck- puffers zu kontrollieren, den Puffer zu l”schen, und Dateien im Hinter- grund zu drucken. Wenn man das Steuerprogramm SPULER45.APP in SPULER45.ACC umbenennt, kann man es als gew”hnliches Accessory betrei- ben. Das ist letztlich nur bei einem Singletasking-TOS sinnvoll. Unter MagiC und MultiTOS funktioniert es aber auch. Der Hauptunterschied besteht darin, daž das Accessory auch bei geschlossenem Fenster weiter- arbeitet, w„hrend die Applikation sich beim Schliežen des Fensters been- det. (Sollte der Filespuler noch am Werken sein, bleibt die Applikation allerdings so lange resident, bis die Datei ausgedruckt ist.) 3.4) Konfiguration ------------------ Um das TSR zu konfigurieren, startet man die Datei SP45_CFG.PRG. Zu- n„chst erfragt das Programm den Namen des TSR mit Hilfe der Fileselec- torbox und testet die angegebene Datei. Als n„chstes erscheint eine Dia- logbox, in die man die gewnschte Puffergr”že eintragen kann. Man kann ferner zwei Verz”gerungswerte angeben, deren Funktion ich im folgenden Absatz kurz erkl„ren m”chte. Wer mit so technischem Zeugs nix am Hut hat, kann beim bern„chsten Absatz weiterlesen. Es hat sich n„mlich gezeigt, daž der Interruptspuler, der von mir auf h”chste Effizienz getrimmt wurde, bei schnellen Beschleunigerkarten Probleme hat. Befindet sich die ganze Routine zum Beispiel im prozessor- internen Cache eines mit 48 MHz getakteten 68030, erscheinen auf dem Bus nur noch die Buszugriffe auf die I/O-Bausteine, und zwar unmittelbar hintereinander. Da der Soundchip eine nur schwache Treiberleistung hat, folgen die Spannungspegel in den Leitungen nicht schnell genug - vor allem bei l„ngeren Kabeln. Deswegen sind jetzt zwei Verz”gerungsschlei- fen eingebaut: die erste verz”gert die Aktivierung des Strobe, nachdem die Daten schon angelegt wurden, und die zweite verz”gert die Deaktivie- rung des Strobe. Im Inneren jeder Verz”gerungsschleife findet ein Lese- zugriff auf den I/O-Bereich statt, der von keiner Beschleunigungshard- ware verkrzt wird. Wenn im Ausdruck falsche Zeichen ankommen, sollte der erste Wert erh”ht werden. Werden Zeichen verschluckt, muž der zweite Wert erh”ht werden. Vermutlich ist es auch sinnvoll, den zweiten Wert nicht kleiner als den ersten zu w„hlen. In den meisten F„llen wird man die Werte aber einfach auf 0 stehen lassen k”nnen, das funktioniert bei mir (68030 mit 48 MHz) problemlos. 3.5) Der Normalbetrieb ---------------------- Aktiviert man das Steuerprogramm, so ”ffnet sich ein Fenster, aus dem sich der aktuelle Fllstand des Puffers und seine Gr”že ergeben. Zu die- sem Zweck wird ein Balken gezeichnet, der bei sich „nderndem Fllstand aktualisiert wird. Hatte man beim Start zus„tzlich die linke Shifttaste gedrckt, so erscheint stattdessen eine Alertbox, die fragt, ob der Puffer gel”scht werden soll. Zeitgleich mit dem Erscheinen bewužter Alertbox ist auch die Zeichenausgabe im Interrupt gestoppt worden. Man kann dann in Ruhe entscheiden, ob man l”scht oder weiterdruckt. Beim L”schen wird nicht nur der Puffer des Interruptspulers gel”scht, sondern auch der Filspuler abgebrochen. Eine andere M”glichkeit, den L”schdialog zu starten, besteht darin, bei gedrckter linker Shifttaste in das offene Fenster zu klicken. H„lt man beim Aktivieren des Steuerprogramms oder Klicken ins Fenster die Controltaste gedrckt, erscheint statt alledem der Fileselektor. Jetzt kann man eine Datei ausw„hlen, die vom Filespuler ausgedruckt wer- den soll. Die Bedienung l„žt sich also auf den Merksatz bringen: "Keine Taste - Fenster, Linke Shifttaste - L”schdialog, Controltaste - Filespuler". 3.6) Zusammenarbeit mit GEMINI ------------------------------ GEMINI benutzt seit Version 1.2 das sogenannte AV-Protokoll zur Kommuni- kation mit Accessories und Applikationen. Dieses ist auch in Spuler v4.5 implementiert. Fr den Anwender heižt das, daž nicht nur SPULER45.APP durch Doppelklick auf das Dateiicon gestartet werden kann, sondern auch SPULER45.ACC - falls das Accessory installiert ist. Bezglich der Shift- und der Con- troltaste gilt das oben Gesagte. Zieht man ein Dateiicon auf das Spuler- icon oder das Spulerfenster, wird der Filespuler in Gang gesetzt, um die Datei auszudrucken. S„mtliche Tastendrcke werden an GEMINI weitergereicht. Die Fensterfunk- tionen von GEMINI beziehen sich auch auf das Spulerfenster. Zwischen einem GEMINI-Fenster und dem Spulerfenster sollte kein Unterschied feststellbar sein. In frheren Versionen des Spulers wurde stets der Zustand des Fensters in GEMINI.INF abgespeichert, und auch nach der Rckehr aus einer Appli- kation wurde der alte Zustand wiederhergestellt. Dies wird seit Version 4.5 nicht mehr gemacht. 3.7) Zusammenarbeit mit MagiC und MultiTOS ------------------------------------------ SPULER45.APP prft stets anhand der Funktion appl_getinfo, welche M”g- lichkeiten das aktuelle Betriebssystem bietet und sollte daher mit MultiTOS und MagiC zurecht kommen. Zur Zeit besteht die spezielle Anpassung darin, daž - es als Accessory auf den act_pd-Hack verzichtet - der Filespuler bei gesperrtem Bildschirm weiterl„uft - es sich bei Empfang von AP_TERM beendet. Fr sp„tere Versionen ist evtl. die Implementierung der Protokolle DRAG&DROP und ICONIFY geplant. Als Druckprogramm unter MAGXDESK ist SPULER45.APP brigens jetzt schon hervorragend geeignet, da MAGXDESK das AV-Protokoll verwendet. 3.8) Technisches ---------------- Auf einer gewissen Abstraktionsebene ist Spuler v4.5 (wie eigentlich alle eventorientierten Programme) einfach beschreibbar (ohne das jetzt n„her zu definieren) durch einen endlichen Automaten. So etwas „hnliches (nennen wir es Zustandsdiagramm) stellt Abbildung SPULER45.IMG dar. Ein Bild sagt halt doch mehr als tausend Worte. Wie aus der Abbildung ersichtlich ist, besteht Spuler v4.5 im wesentlichen aus zwei zentralen Zust„nden, die im Programmcode tats„chlich durch Eventschleifen repr„sentiert sind. Die kleinere von beiden wartet ei- gentlich nur auf die Aktivierung des Fensters. Daher frižt Spuler v4.5 praktisch keine AES-Zeit, wenn das Fenster zu ist. Die gr”žere Schleife schaut alle 0.2s nach, ob der Fllstand des Puffers sich ver„ndert hat. Dank eines effizienten Bindings fr evnt_multi() wird aber auch dort keine Rechenzeit verdorben. Etwas anders sieht das Bild aus, wenn der Filespuler aktiv ist. Dieser liest im Timerevent gegebenenfalls 4KB von Platte ein und schiebt sie gleich in den Puffer des Interruptspulers. Ursprnglich wollte ich die Daten ber das BIOS ausgeben, um so eventuelle Systemerweiterungen des Users (Filter usw.) nicht zu umgehen. Bei einem schnellen 68030 geht das durchaus noch, aber ein 68000 mit 8 MHz wird durch einige tausend BIOS- Calls pro Sekunde fast bis zum Stillstand gebremst. Damit der Filespuler nicht direkt in den Puffer des Interruptspulers schreiben muž, habe ich die Softwareschnittstelle des TSR um eine weitere Funktion bereichert (s.u.). Insgesamt ist der Filespuler dadurch so schnell geworden, daž auch auf einem ST mit 8 MHz keine st”rende Verlangsamung beim Arbeiten feststellbar ist. Trotzdem wird die Datei verzugslos und mit maximaler Druckergeschwindigkeit ausgedruckt. 4) Bugs oder Features ===================== - Der Interruptspuler bedient sich der xcon-Vektoren des BIOS. Diese gibt es jedoch erst seit TOS 1.02, dem Blitter-TOS. Die Alternative, den Trap umzubiegen, halte ich fr eine Zumutung. Wer heute noch TOS 1.0 benutzt, wird vermutlich fr ein Betriebssystemkonzept wie I/ O-Transfer im Hintergrund ohnehin nichts brig haben. - Ist der Drucker ausgeschaltet oder offline, so k”nnen beim normalen Ausdrucken folgende zwei F„lle auftreten. Falls die Druckdaten weni- ger als die Pufferl„nge sind, so wandern sie vollst„ndig in den Puf- fer. Sobald man den Drucker online schaltet, wird alles ausgedruckt. Sind es dagegen mehr Daten, als in den Puffer passen, so wird erst einmal der Puffer gefllt. Bei den folgenden Zeichen verh„lt sich die Ausgaberoutine dann wie die originale BIOS-Routine. Erst wird 10s ge- wartet, danach ein Fehlerflag gesetzt und alle nachfolgenden Zeichen- ausgaben mit Fehler abgebrochen. (Erst eine fnfsekndige Druckpause macht das Flag wieder unwirksam). Der Puffer wird aber nicht ge- l”scht, das bleibt dem Anwender berlassen. - Da mir keine M”glichkeit bekannt ist, an die Druckerkonfiguration des XBIOS heranzukommen (ein Trap bei jeder Zeichenausgabe ist indiskuta- bel), wird ein serieller Drucker nicht mehr untersttzt. Das ist bei meinem TeX-Druckertreiber allerdings ein Feature: Durch Ausgabe auf einen seriellen Drucker zwinge ich ihn, das BIOS berhaupt zu be- nutzen. Sonst gibt er alles direkt auf den Port, wohl in der Einbil- dung, beim Warten auf den Drucker weniger Zeit zu verschwenden. (Ein „hnlich kl„glicher Versuch war auch 'mal in c't 10/91, natrlich ohne jeden Benchmark.) - Aus naheliegenden Grnden sollte der Puffer leer sein, bevor man ein Programm startet, das den Port direkt programmiert. - Es werden auch die Vektoren von Bconstat() und Bconin() fr den Druk- ker umgebogen: Sie geben stets "Kein Zeichen verfgbar" bzw. CTRL-Z zurck. Damit ist jetzt auch bei TOS 1.02 die GEMDOS-I/O-Umlenkung auf den Drucker m”glich. - Wnschenswert w„re natrlich eine dynamische Speicheranforderung zur Laufzeit, d.h. daž Pufferspeicher in kleinen Stcken genau dann vom Betriebssystem angefordert wird, wenn er gebraucht wird und auch stckweise zurckgegeben wird. Das ist jedoch mit den Mitteln des GEMDOS fr speicherresidente Programme nicht machbar. An eine L”sung mit Hilfe der AES (durch Auswertung von AC_CLOSE) will ich nicht ein- mal denken, da der Spulprozež selbst _unabh„ngig_ vom GEM sein soll, TOS-Programme dann Schwierigkeiten bereiten und es aužerdem mangels Handshake Timingprobleme mit den AES-Messages gibt. Ein sicherer Be- trieb w„re Zufall. - Noch lieber h„tte ich einen Mechanismus, der Teile des Puffers auf die Platte auslagert und bei Bedarf wieder l„dt. Wollte man dazu das normale Filesystem benutzen, mžten GEMDOS-Aufrufe aus dem Interrupt heraus gemacht werden, was Atari sei Dank unm”glich ist. Auch einen pollenden AES-Prozež zu benutzen, ist keine gute Idee: ein TOS- -Programm oder ein schlecht programmiertes GEM-Programm k”nnte einen Deadlock erzeugen. Fazit: mit den Mitteln des Betriebssystems ist das ganze nicht sauber machbar. Mir ist zwar bekannt, daž es Spooler gibt, die BIOS-Traps abfangen und die Druckdaten mit einem Trick in eine Datei schreiben, aber so etwas ist in meinen Augen ein Hack und entspricht nicht meiner Vorstellung von sauberem Programmieren. - Was ich noch machen wollte, ist ein CPX zur Spulersteuerung. Aller- dings w„re damit vermutlich kein Filespuler m”glich. Falls sich aber jemand daran macht (die Softwareschnittstelle des TSR ist ja dokumen- tiert), bitte ich um Nachricht. - Wo wir gerade bei der Softwareschnittstelle sind: Das Konzept, ber einen Cookiepointer aus dem Speicher eines anderen Prozesses zu lesen bzw. dessen Code auszufhren, l„uft natrlich der Memory Protection von MiNT zuwider. Hier hilft nur, den Speicher des TSR als global zu kennzeichnen, oder aber das Steuerprogramm nicht zu benutzen. - W„hrend der Filespuler l„uft, wird die Bconout-Schnittstelle _ nicht_ gesperrt. Ich erlaube es einfach einem AES-Prozež nicht, in das BIOS einzugreifen, denn das BIOS soll nach wie vor transparent und autonom funktionieren. Das Konzept des Lockings von Systemressourcen gibt es halt beim TOS nicht. Es liegt in der Verantwortung des Benutzers, nur einen Prozež zur Zeit drucken zu lassen. Das Schlimmste, was andernfalls passiert, ist die Vermischung der verschiedenen Druckdaten. - Auch zum ewigen Thema GEMDOS ist etwas zu sagen: Es scheint so zu sein, daž die Filehandles des GEMDOS fr den Rechner global sind, es also keine Benutzerfiledeskriptorentabelle (fr jeden Prozež) gibt. Jeder Prozež kann auf jedes Handle zugreifen, wenn er es nur kennt. Trotzdem wird der Prozež vermerkt, der die Datei ge”ffnet hat, damit bei dessen Ende die Datei automatisch geschlossen wird. Da nun ein Accessory im SingleTOS stets unter dem aktuellen GEMDOS-Prozež l„uft, gibt es Probleme, wenn eine Datei ber einen AES-Aufruf hinweg offen bleiben soll -- der beim ™ffnen aktive GEMDOS-Prozež k”nnte ja zwischenzeitlich zuende sein und das Filehandle weg oder gar neu ver- geben. Zur L”sung dieses Problems k”nnte man jeden Dateizugriff in Fopen/Fclose schachteln, was aber ineffizient ist. Ich habe mich daher schweren Herzens entschlossen, (im Falle von Accessory & SingleTOS) den bekannten aber unsch”nen Hack zu benutzen, dem GEMDOS beim ™ffnen des zu spulenden Files einen anderen Prozež (eben den Spuler) vorzuspiegeln. Lesen und Schliežen geschieht dann wieder unter dem gerade aktuellen Prozež. - Ich sollte noch ein paar Worte zur Konzeption des Filespulers verlie- ren. Es war _nicht_ geplant, den Filespuler als zentralen Druck- manager oder als Druckerd„mon zu entwerfen. Ein solches Konzept w„re zum einen dem TOS etwas fremd, zum anderen w„re es ein extrem aufwen- diges Projekt, das die Kontrolle ber den gesamten Druckbetrieb ber- nehmen mžte und vielf„ltige Konfigurationsm”glichkeiten br„uchte -- man denke an Druckerinitialisiserung, Formfeed, Fehlerbehandlung, usw. sollte dagegen schon immer ein kleines und effizientes System sein. In Version 4.5 belegen TSR und APP im Speicher (!) 17 KB zuzglich Puffer. Unter MagiC reichen 8 KB Puffer v”llig aus. Auch die Be- lastung fr das Restsystem ist minimal: Es werden keine Traps abge- fangen, das TSR ist optimal in Assembler codiert und ber die geringe AES-Belastung ist weiter oben schon geschrieben worden. Trotzdem k”nnte Spuler v4.5 von, sagen wir, einem D„mon benutzt werden, der dem Steuerprogramm VA_START-Messages schickt. Kleinere Druckjobs sollten nach M”glichkeit wie gew”hnlich abge- wickelt werden. Der Interruptspuler sorgt schon fr das Verschwinden eventueller Denkpausen. Erst bei gr”žeren Jobs wird die Benutzung des Filespulers sinnvoll, wenn man gleichzeitig auf dem Rechner noch etwas anderes zu tun hat. Unter SingleTOS muž es sich dabei aber um GEM-Applikationen handeln, da sonst der Filespuler nicht parallel dazu arbeiten kann. W„hrend ich zum Beispiel diesen Text hier in einem GEM-Editor tippe, druckt die Nadels„ge neben mir ein ber 200- seitiges Postscriptdokument aus. Um den Filespuler berhaupt benutzen zu k”nnen, mssen die Druckdaten als Datei vorliegen. Dazu muž man das druckende Programm so einstel- len, daž es in eine Datei druckt. Geht das nicht, so kann man es mit der Ausgabeumlenkung des GEMDOS versuchen. Programme, die stets ber BIOS oder - schlimmer - durch Direktprogrammierung der Hardware druk- ken, k”nnen den Filespuler nicht nutzen. Glcklicherweise geh”ren Ghostscript und die meisten DVI-Treiber nicht in diese Kategorie. Eine A4-Seite verschlingt bei 360*360 dpi brigens bis zu einem Mega- byte auf der Platte. Man braucht fr das Filespulen von Vollgrafik also geh”rige Reserven. - Unter MagiC wird bei der BIOS-Ausgabe und vollem Puffer immer noch eine Warteschleife (bis zum Timeout) durchlaufen. Bis ich die Pro- grammierdoku verstehe, bleibt das auch erst mal so. 5) Was ist neu ============== 5.1) in Version 4.0 ------------------- - Fast der gesamter Code ist neu. Lediglich die Interrupt- und BIOS- Routinen sind (leicht berarbeitet) von Version 3 erhalten geblieben. Die gesamte Accessoryverwaltung ist nun in C geschrieben. - Der Timeout wurde von 30s auf 10s verkrzt. - Die BIOS-Vektoren 0x506 und 0x50A fr die Zeichenausgabe der internen Hardcopyroutine werden nun umgebogen. - Die Vektorverbiegung entspricht jetzt dem XBRA-Standard. Die XBRA- Kennung von Spuler v4.0 ist "spMR". - Der Fllstand wird jetzt intuitiv erfažbar als Balkengrafik dar- gestellt. Aužerdem l„uft die Anzeige auch w„hrend der Ausgabe. - Das AV-Protokoll wurde implementiert. - Bei Start als Hauptapplikation konfiguriert sich Spuler v4.0 selbst. 5.2) in Version 4.1 ------------------- - Leider mužte ich nach der Freigabe von Spuler v4.0 noch einen „rger- lichen Fehler feststellen: In der Schleife zur Bearbeitung der Recht- ecklisten wurden die falschen Variablen getestet, so daž zuviele wind_get(WF_NEXTXYWH, ...) get„tigt wurden. Der Fehler f„llt nicht auf, weil nach endlich vielen Schritten die AES immer so frei sind, als x-Koordinate eine 0 zu liefern, zumindest bei meinem Rechner. Da jedoch TOS das erste nichtdeterministische Betriebssystem ist, kann man sich wohl kaum darauf verlassen. - Die Fensterkoordinaten werden nun als Relativgr”žen gespeichert. 5.3) in Version 4.2 ------------------- - Der Spuler ist jetzt zweigeteilt in ein TSR und ein Accessory. Die Kommunikation geschieht ber den cookie jar. Dazu legt das TSR ein cookie mit Namen "spMR" an. Der zugeh”rige Parameter ist ein Pointer auf folgende Struktur (in C-Syntax): struct { long length; /* Pufferl„nge */ long lobuf; /* Startadresse des Puffers */ long hibuf; /* Endadresse des Puffers */ long inmark; /* Eingabepointer */ long outmark; /* Ausgabepointer */ void (*stop)(); /* Stoppt Hintergrundprozež */ void (*restart)(); /* Neustart desselben */ } Diese (hiermit dokumentierte) Struktur ist nur gltig, wenn length!=0 ist. Dadurch bleibt die Definition offen fr zuknftige Entwicklun- gen. Der Puffer ist genau dann leer, wenn inmark==outmark ist. Allge- mein liefert das Programmstck l=inmark-outmark; if (l<0) l+=length; den aktuellen Fllstand des Puffers in der Variablen l. Die brigen Eintr„ge der Struktur tun genau das, was man anhand der Kommentar- zeile von ihnen erwarten wrde. Jede andere Eigenschaft des TSR gelte als undokumentiert. - Der Non-Autovektor-Interrupt-Pointer des MFP fr das Busy-Signal an 0x100 wird nun einfach berschrieben und nicht mehr in einer XBRA- Struktur vor der neuen Interruptroutine gerettet. Das war n”tig, weil das TOS diesen Pointer bei einem Reset nicht zurcksetzt und dann ein Zykel in der XBRA-Kette entsteht (bei gleicher Systemkonfiguration). Das hinwiederum s„gt einige der vektorberwachenden Programme ab. - Der Busy-Interrupt wird nun stets initialisiert, wenn ein Byte in den leeren Puffer bertragen wird. Das war n”tig, da z.B. einige TeX- Druckertreiber einen eigenen Spuler einrichten. Das ist an sich nicht schlimm, nur ist nach dem Ende dieser Programme der Busy-Interrupt disabled und der Interruptvektor berschrieben. - Die Messages des AV-Protokolls werden nun nicht mehr einfach an ap_id 0 geschickt. Stattdessen wird bei jeder Einstellung des Minimalproto- kolls versucht, die Applikationen AVSERVER oder GEMINI zu finden. Nur wenn das fehlschl„gt, wird weiterhin ap_id 0 verwendet. 5.4) in Version 4.3 ------------------- - Im wesentlichen wurde nur das TSR berarbeitet. Ich wollte eigentlich nur testen, ob ein Burst-Fill in der Interruptroutine sinnvoll ist. Zumindest fr meinen NEC P6 ist es das aber nicht. Stattdessen gelang es mir, die Interruptbehandlung um ber 10 Mikrosekunden (bei einem Standard-ST) zu verkrzen. - Es wird jetzt bei jedem Bconout geprft, ob der MFP-Interrupt noch korrekt initialisiert ist. Falls nicht, wird kurzerhand alles neu initialisiert. In Version 4.2 geschah das nur bei leerem Puffer. - Das TSR gibt jetzt eine Einschaltmeldung aus. - Das ACC kann jetzt im Zeitalter des Multitasking auch als PRG gestar- tet werden. - Dafr ist jetzt ein eigenst„ndiges Konfigurationsprogramm beigelegt. 5.5) in Version 4.4 ------------------- Es hat eine mehr oder weniger drastische šberarbeitung aller Programm- teile gegeben. - Beim TSR von Version 4.3 hatte ich schlauerweise ein bset mit einem bclr verwechselt. Das fhrte dazu, daž die stop-Routine ihrem Namen nicht gerecht wurde. - In die Ausgaberoutine wurden zwei Verz”gerungsschleifen eingebaut, die mit dem Konfigurationsprogramm konfiguriert werden k”nnen. Die Funktion dieser Schleifen wurde oben schon beschrieben. Damit sollten jetzt alle Probleme mit schnellen Beschleunigerkarten der Vergangen- heit angeh”ren. - Es ist eine weitere aufrufbare Funktion implementiert worden. Sie hat (in C-Notation) den Prototypen long write(long count, char *buffer) und funktioniert „hnlich wie Fwrite: Es wird versucht count viele Zeichen von buffer an in den Puffer des Interruptspulers zu bertra- gen. Zurckgegeben wird die Anzahl der tats„chlich bertragenen Zeichen. Das k”nnen durchaus weniger als count sein, wenn nicht genug Platz im Puffer ist. Auf keinen Fall wartet write auf das Freiwerden von Platz. Wie bei Bconout wird geprft, ob der Spulerinterrupt noch korrekt initialisiert ist, und der Spulprozež wird n”tigenfalls an- gestožen. Die Parameterbergabe erfolgt gem„ž der Pure-C-Konvention: count in D0, buffer in A0, Rckgabewert in D0. - Um auf die neuen Elemente zugreifen zu k”nnen, wurde die Software- schnittstelle erweitert. Der Parameter im Cookie "spMR" zeigt nun auf folgende Struktur (int habe 16 bit): struct { long length; /* Pufferl„nge */ long lobuf; /* Startadresse des Puffers */ long hibuf; /* Endadresse des Puffers */ long inmark; /* Eingabepointer */ long outmark; /* Ausgabepointer */ void (*stop)(void); /* Stoppt Hintergrundprozež */ void (*restart)(void); /* Neustart desselben */ long (*write)(long, char*); /* Schreibt in den Puffer */ int delay1; /* Verz”gerung vor Strobe */ int delay2; /* Verz”gerung nach Strobe */ } Offenbar ist diese Struktur aufw„rtskompatibel zu der alten. Fr die ersten sieben Eintr„ge gilt das unter Version 4.2 Gesagte. - Das Konfigurationsprogramm hat nun eine externe RSC-Datei, was die Wartung wesentlich vereinfacht. Das ist von der Handhabung her kein Nachteil, denn schliežlich wird das Konfigurationsprogramm nur selten benutzt. - Bevor das Konfigurationsprogramm seinen Dialog ”ffnet, fragt es be- reits nach dem TSR, um die aktuellen Werte in die Dialogbox zu ber- nehmen. - Die herausragende Neuerung im ACC bzw. PRG ist der Filespuler. Die gesamte Dokumentation wurde entsprechend umgearbeitet, so daž an die- ser Stelle nichts mehr zu sagen bleibt. 5.6) in Version 4.5 ------------------- Spuler v4.5 wurde im wesentlichen nur an MagiC (und damit an MultiTOS) angepažt: - Die Distribution enth„lt jetzt das APP anstelle des ACC, was unter MagiC sinnvoller ist. Das ist halt die neue Konfiguration des Autors. Am besten tr„gt man das Steuerprogramm bei Magxdesk unter Optionen- Programme ein. - Unter MagiC (oder MultiTOS) wird der Filespuler nicht mehr von wind_update blockiert. Das hat den sehr angenehmen Seiteneffekt, daž man fr das Filespulen den Puffer des TSRs nun sehr klein w„hlen kann. Bereits 8 KB reichen v”llig aus, den Drucker immer mit Stoff zu versorgen. Fr die BIOS-Schnittstelle braucht man allerdings wie bis- her einen grožen Puffer. - Auch als Accessory verzichtet der Filespuler auf den oben erw„hnten act_pd-Hack, wenn MagiC (oder MultiTOS) aktiv ist. - Das Steuerprogramm wurde um diejenigen Funktionen des AV-Protokolls erleichtert, die Gemini stets ber die Lage des Fensters auf dem Lau- fenden halten. Das ist letztlich eine Spielerei, die 1.3 Kilobytes kostet. Das sei nicht viel? Nun, es drckt die Dateil„nge unter 8192 und spart unter Umst„nden einen grožen Plattensektor. ;-) Durch ein einfaches Compilerflag kann der Support aber jederzeit wieder eincom- piliert werden. - Das Steuerprogramm prft jetzt zyklisch nach, ob der MFP-Interrupt noch korrekt initialisiert ist. In einer Multitasking-Umgebung ist es einfach zu wahrscheinlich, einmal auf ein Programm zu stožen, das selber spulen m”chte. (Im L”schdialog (Button "zurck") konnte man den Interrupt schon immer manuell neu Installieren.) Dazu wurde die Softwareschnittstelle des TSRs um einen neuen Eintrag erweitert: struct { long length; /* Pufferl„nge */ long lobuf; /* Startadresse des Puffers */ long hibuf; /* Endadresse des Puffers */ long inmark; /* Eingabepointer */ long outmark; /* Ausgabepointer */ void (*stop)(void); /* Stoppt Hintergrundprozež */ void (*restart)(void); /* Neustart desselben */ long (*write)(long, char*); /* Schreibt in den Puffer */ int delay1; /* Verz”gerung vor Strobe */ int delay2; /* Verz”gerung nach Strobe */ void (*check)(void); /* Test und evtl. Neustart */ } - Die Blockl„nge des Filespulers wurde auf 4096 erh”ht, was beim Autor gerade einem Plattensektor entspricht und dadurch unter Umst„nden die Performance erh”ht. Zum Ausgleich wurden die Zeitintervalle fr evnt_timer auf 200 ms verl„ngert. Man kann als Programmierer :-) mit diesen Parametern in weiten Gren- zen spielen. Es sollten nur die Daten mit einer h”heren Rate in den Puffer hineinkommen als der Drucker sie herausholt. Auf langsamen Rechnern sollten die evnt_timer-Intervalle nicht zu kurz sein, damit die Gesamtperformance nicht leidet. Umgekehrt sind zu grože Blockl„n- gen unter Singletaskingsystemen zu vermeiden, da der Rechner w„hrend der Plattenzugriffe blockiert ist. Das gilt brigens auch fr Multi- TOS. Unter MagiC mit Hintergrund-DMA ist es dagegen v”llig egal. Hier sind grože Bl”cke sogar vorzuziehen, da DMA immer billiger ist als Taskswitching. 6) Literatur ============ [1] Jankowski, Rabich, Reschke: ATARI ST Profibuch, Sybex, 1988 [2] Amler, Zobel: Einer fr alles, c't 9/88, Seite 144 [3] Rogge: Von der Spule, c't 6/90, Seite 212