-1- 1. Zielsetzungen der Diplomarbeit: __________________________________ 1.1. Die schriftliche Aufgabenstellung: --------------------------------------- DT-Diplomarbeit Nr.89/406 Realisation und Programmierung eines 68008-Einplatinenrechners: Teil 2: Design und Programmieruung des Betriebssystems (Monitors) und der Peripherie. Einleitung: In den c't-Zeitschriften [1] wurde der Vorschlag eines Kleinsystems mit dem 68008-Prozessor publiziert. Dieser Prozessor ist softwarekompatibel mit dem 32/16-bit Motorola 68000-Prozessor, benutzt aber nur einen 8-bit Datenbus. Ziel dieser Arbeit ist, das als Bausatz erh„ltliche System aufzubauen, zu "beleben" und zu programmieren. Zus„tzlich soll noch einfache Peripherie (Display und Tastatur) gebaut und angeschlossen werden. Aufgabenstellung: 1) Man entwerfe das Monitor-Programm und realisiere es in Zusammenarbeit mit dem Projekt 89/405. Der Monitor muss u.a. einen transparenten Modus untersttzen, in welchem der Rechner eine "durchsichtige" Kommunikation zwischen dem einerseits angeschlossenen Terminal und dem anderseits angeschlossenen Host-Rechener (z.B. Vax) erm”glicht (2 serielle Schnittstellen sind vorhanden). Das System wird vom Terminal aus gesteuert, muss aber auch vom Host-Rechner mit den dort entwickelten Programmen geladen werden k”nnen. Fr die Programmentwicklung wird vorerst der ATARI-Rechner als Host verwendet. Neben diesen zwei Funktionen muss der Monitor auch das Debugging der Programme untersttzen (wie z.B. der MDT auf dem ISIS-System!) 2) Falls noch Zeit vorhanden ist, sollte eine Peripherie-Platine mit 5x4 Tastatur und 9-Ziffer 7-Segment-Display (evtl. einem LCD-Zeilendisplay) aufgebaut und getestet werden. Mit einem Demo-Programm soll die Funktionalit„t des Systems und der Peripherie demonstriert werden. Es steht der Gruppe frei, die Aufgaben bei der Programmierung des Monitors auch anders zu verteilen (mit dem Einverst„ndnis des Betreuers), falls damit die Programmentwicklung beschleunigt werden kann. 1.2. Pers”nliche Anweisungen von Herrn Zeman: --------------------------------------------- Es sollen ein kleines Betriebssystem geschrieben werden, das die Erstellung von EPAC-Programmen in C auf dem Atari ST erm”glicht, dazu ein Monitor der das Debugging auf dem EPAC vereinfachet sowie die notwendigen Wandlerprogramme um die Programme EPROM-brennbar zu machen. Der Debugger soll v.a. ber einen Tracer verfgen, der schrittweises Ausfhren von Programmen erlaubt. Weiterhin wird die M”glichkeit der Verwendung eines Hostrechners (oder eines intelligenten Terminals) als Fileserver fr die Programmentwicklung erwnscht. Da die Arbeit zu Unterrichtszwecken bentzt werden soll soll sie derart organisiert werden, dass im Falle von Zeitschwierigkeiten am Ende eine m”glichst grosse brauchbare Teilmenge von Funktionen verfgbar ist. Weiterhin soll zur Zeitersparnis vorhandene Software so weit wie m”glich genutzt werden. Falls die Zeit noch dazu reicht sollten eine kleine Tastatur und Anzeige fr den EPAC erstellt werden. -2- 1.3. Vorschl„ge zur Gestaltung der Arbeit: ------------------------------------------ Als Vorschl„ge zur Gestaltung dieser Programme wurden ein in mc ver”ffentlichter Artikel[2] ber die Programmierung von Einplatinenrechnern in Hochsprachen, eine ETH-Arbeit[3] ber die Cross-Software Entwicklung fr 680XX-Einplatinencomputer sowie die c't Artikelserie[4] ber ein MiniDOS fr den DPAC-88 abgegeben. 2. šberlegungen zum Design des Betriebssystems: _______________________________________________ Beurteilung der 3 Gestaltungsvorgeschl„gen: In [2] wird eine Methode gezeigt, eigene in C geschriebene Programme auf einem Einplatinenrechner laufenzulassen. Hierzu mssen sie mit einem speziellen, im Assembler geschriebenen Startup-Modul gelinkt werden. Weiter wird noch ein Locator vorgestellt, mit dem man PRG-Files im ROM-f„hige Files umwandeln kann. Dieser Artikel zeigt nur eine Methode Atari-C-Programme auf Einplatinenrechenr zu bertragen. Leider k”nnen keine C-Funktionen, die auf das Betriebssystem zugreifen, verwendet werden. Auch in anderen Sprachen (C ist nicht jedermans Sache) geschriebene Programme oder fertige kommerzielle Software kann nicht verwendet werden, da diese Runtime-Module ben”tigen, welche auf des Betriebssystem zugreifen, bzw. bereits gelinkt sind. Es mssten daher sowohl ein Betriebssystem wie auch ein Monitor geschrieben werden, was der Forderung nach Nutzung bestehender Software nicht nachkommt. Zudem ist der Locator fast unlesbar (keine Kommentare) und daher nicht fr unseren Fall modifizierbar. Dieser Artikel ist daher nur als Vorgehensweise interessant. In [3] wird ein Vorschlag gezeigt, die die Wahl zwischen eigenen Ein-/Ausgabefunktionen ([3] Seite 12, eine Library epacm.c wird auf der Seite 19 vorgestellt) oder der Verwendung einer in einem Monitorprogramm eingebauten mini-Betriebssystemnachbildung (Funktionen siehe [3] Seite 11 unten) erlaubt. Leider enth„lt dieser Monitor keine Trace-Funktion. Zudem werden die wichtigen Funktionen der Speicherverwaltung (Malloc, Mshrink, Mfree) berhaupt nicht nachgebildet und die Funktionen zur Ein-/Ausgabe umfassen nur Handle-Funktionen fr die Consolen-Ein-/Ausgabe sowie fr ein Diskfile. Wir mssten also Monitor und Betriebssystem erweitern. Trotzdem k”nnte diese Software eine Basis fr diese Arbeit bilden, sie wurde uns aber nur in einem von uns nicht lesbaren Format (TEX - Textformater) zugesandt und konnte daher nicht verwendet werden. In [4] wird eine miniMSDOS-Emulation fr den 8088-Einplatinencomputer DPAC-88 gezeigt, welche den Einsatz von beliebigen disklosen MSDOS Programmen erm”glicht. Zu diesem Zwecke werden die wichtigsten MSDOS- und IBM-BIOS-Interrupts nachgebildet. Eine Implementation dieser Methode in der Form eines TOS-Emulators auf dem EPAC68008 wrde die Verwendung eines bestehenden Atari Debuggers z.b. des BUG68, welches mit TurboC mitgeliefert wird, erm”glichen. Bei dieser Methode mssten etwas mehr an I/O-Routien und dazu noch TOS-kompatible Funktionsdiapatcher geschrieben werden, dafr wrden bereits ein fertiger Monitor mit Tracefunktion bereitstehen, sowie die Verwendung beliebiger PRG-Programme (auch in Pascal oder Basic geschriebener) m”glich werden. Ein l„ngerer Blick in die Beschreibung der BIOS-, XBIOS- und GEMDOS-Funktionen im ATARI ST Profibuch[5] berzeugte mich, dass dieser Weg gangbar ist. Ich habe mich daher nach Absprache mit Herrn Zeman dazu Methode entschlossen. -3- 3. Der Verlauf der Diplomarbeit: ________________________________ Diese Arbeit ist der 2. Teil einer zweiteiligen Diplomarbeit, deren erster Teil, die Hardware (Nr. 89/405), von Louis Scheidegger erledigt wird. Neben der eigentlichen Erstellung und dem Test der Hardware hat er auch die Aufgabe die grunds„tzliche Ein-/Ausgabe (Zugriff auf die Portchips) zu schreiben. Die von ihm geschriebenen Teile des Betriebssystems (Portchips initialisieren, Daten aus Chips lesen/ in Chips schreiben sowie die Inputbuffer) werden beim EPROM-brennen dazugebunden und sind im Listing gekennzeichnet. Da mir der Atari ST und die 68000er bisher v”llig fremd waren (meine bisherigen Erfahrungen sind Microprofessor/Z80, Commodore 64/6502, IBM AT/80286, Digitaltechnik/8080 sowie Semesterarbeit TK51/8051) verbrachte ich die Zeit, die in der Austeilungswoche und der darauf folgenden zur Verfgung standen, damit, diese beiden kennenzulernen. Als erste 68000 Assemblerbung schrieb ich den Startupcode fr C-Programme, die direkt (ohne Betriessystem) auf der EPAC-Hardware laufen. Dieser war fr des miniTOS vorgesehen, wird jedoch infolge der gew„hlten Programmierung in Assembler statt C (dazu sp„ter mehr) nicht mehr bentzt. In der ersten eigentlichen Diplomwoche nahm ich den Locator, der PRG-Files in ein EPROM-brennbares Format wandelt, in Angriff, da dieser bereits w„hrend der Erstellung des TOS-Emulators zum šbersetzen von PRG-Files bentzt werden muss. Dies verschlang mehr eine ganze Woche, da ich Schwierigkeiten mit dem Debugging hatte. Unbequeme Werkzeuge (Editor ohne Cursor-Zeilennummerangabe, separater Debugger, nur Assembler-Level Debugging) erschwerten die Suche nach den Fehlern und verbrauchten so die viele Zeit. Ich hatte zwei schwer zu findende Fehler im C Programm, welche drei Tage in Anspruch nahmen. Diese waren die Definition von Buffer ohne 'unsigned' was zu negativen Offsets bei Offsets gr”sser als 126 fhrte (Folge: nur erste Adresse wurde richtig reloziert), sowie ein Pointerfehler (long)(*reloc)++ statt (long)(*reloc++) der dazu fhrte, dass statt einem Pointer, der von einem Byte zum n„chsten geht, ein sich in Einerschritten erh”hendes Byte entstand, welches zu Adressfehlern fhrte (Folge: Absturz des Programms). Es waren diese Probleme, die mich erwogen den TOS-Emulator direkt in Assembler zu schreiben. Zus„tzlich musste ich in der vierten Woche feststellten, dass die ROM-Files nur in Vielfachen von 1024 Bytes gespeichert werden, obwohl die testeshalber im C-Programm eingebaute fwrite-Funktion fest behauptet, es werden alle Bytes gespeichert. Nachdem ich mit diesem Fehler einen ganzen Tag vertan habe (ich habe den Grund nicht gefunden) habe ich kurzerhand die Anzahl zu speichernder Bytes um 1024 erh”ht, dadurch werden alle gewollten Bytes gespeichert (die šberschussbytes bis ans n„chste Vielfache von 1024 st”ren nicht). Ebenfalls wird der Locator zufallsabh„ngig mit 4 Bomben (undefinierter Opcode) beendet oder strzt nach Erledigung der Arbeit ab. Ich habe weder den Grund nach das Unterscheicungsmerkmal fr die beiden Fehler entdecken k”nnen und muss daher Fehler im Turbo C (Version 1.0) vermuten. -4- In der zweiten Woche kam der TOS-Emulator (miniTOS) selber an die Reihe. Zuerst Diplomwoche bestimmte ich welche BIOS-, XBIOS- und GEMDOS- Funktionen emuliert werden sollen. Dazu suchte ich mit Hilfe des BUG68 einige typische Programme (darunter auch den BUG selber) nach TRAP- Befehlen ab. Da zu diesem Zeitpunkt des am Freitag zuvor bestellte TOS-Listing[5] noch nicht eingetroffen war (es traf dann am Mittwoch der dritten (!) Diplomwoche ein) fing ich danach mit dem Erstellen des Diplomberichtes an, damit mir nach den Eintreffen des Buches noch m”glichst viel Zeit zum Programmieren brig bleibt. Der Freitag der zweiten Woche sowie die Dritte Woche verbrachte ich mit dem Entwerfen und eintippen des Emulators, den ich allerdings nach Eintreffen des Buches an einigen Stellen umgeschreiben musste, sowie mit der Fehlersuche im Emulator, was sich als schwierig erwies, da man ein Programm, das nur aus einzelnen Subroutinen ohne Hauptprogramm besteht nicht einfach ablaufen lassen kann. Die einzige L”sung zu diesem Problem besteht darin, ein Testhauptprogramm zu erstellen, das alle Funktionen aufruft. Insbesondere erschwert wurde das Ganze dadurch, das einige Routinen Privilegierte Befehle enthalten und das Programm daher nach jedem Assemblieren in ein EPROM zu gebrannt und auf dem EPAC abgelaufen lassen werden musste. Dies war jedoch erst in der vierten Diplomoche m”glich (aus Hardwaregrnden) und ist sehr langsam (nur Logicanalyser als "Hex-Code-Debugger"). Aus diesem Grunde habe ich Ende der dritten Woche am Diplombericht weitergearbeitet um in der vierten Woche noch m”glichst viel Zeit zum Testen zur Verfgung zu haben. Am Freitag der letzten Woche musste ich feststellen, dass der Bug ohne von Disk geladenes Programm entgegen meinen Annahmen nicht einfach ein direkt nach Bug folgendes Programm ausfhrt, welches vom Bentzer als Hexcode eingegeben werden k”nnte sondern vielmehr abstrzt, daher wird Bug erst nach der Implementation einer Diskschnittstelle auf dem EPAC eingesetzt werden k”nnen. Bis dahin heisst es weiterhin Logicanalyser bentzen oder einen anderen Debugger suchen, dieser muss kleiner als 60 Kilobyte sein und darf nicht auf die GEM Graphikroutinen zugreifen. 4. Das Locator-Programm: ________________________ 4.1. Die Aufgaben des Locators: ------------------------------- Die PRG-Files des Atari sind in einem relozierbaren Format gespeichert. Dies ist notwendig, da es zur Compilezeit nicht bekannt sein kann, in welchen Speicheradressen ein Programm letztlich ablaufen wird. Hierzu wird dem Programm auf der Diskette eine Relokationstabelle mitgegeben. Es ist die eine Aufgabe des Locators, den ich PRGTOROM (er wandelt PRG-Files in Files mit der Extension ROM um) genannt habe, die in dieser Tabelle aufgelisteten Speicherstellen zu korrigieren. Zus„tzlich muss fr des ablauff„hige Programm eine Basepage erstellt werden, diese ist eine 256 Bytes lange Datenstruktur, welche direkt vor dem Programmcode im Speicher stehen muss und daher ebenfalls ins EPROM gebrannt werden muss. Beim Locaten muss schliesslich noch darauf geachtet werden, dass in einem Atari die Daten direkt auf des Programm folgem, sie auf dem EPAC jedoch im RAM stehen, dass vor dem ROM steht. -5- 4.2. Der Sourcecode des Locators: --------------------------------- Grunds„tzlicher Aufbau des Locators: Da der Locator in [2] unleserlich ist musste ich einen eigenen schreiben. Dieser fragt zuerst nach dem Filename des PRG-Files (ohne Extension), danach liest er dieses ein. Die ersten 28 Bytes (der Header, der ber die Gr”ssen der einzelnen Programmfileteile informiert) in den 'struct' namens header, den Rest in ein 'unsigned char array' namens buffer. Hiernach wird die Basepage (in der gleichnamigen struct) erstellt. Nach der darauf folgenden eigentlichen Relokation werden die Basepage sowie der Code- und Konstantenteil des Programms ins ROM-File gespeichert. Eine eventuell vorhandene Symboltabelle wird nicht ins ROM bernommen. Dies w„re, falls erwnscht, ohne Probleme m”glich, hierzu msste lediglich die L„ngenangabe im zweiten 'fwrite' um '+header.ph_slen' erweitert werden. Wird erwnscht, dass keine Basepage erstellt werden soll (z.B. fr des miniTOS selbst) so kann dies durch setzen von BASEPAGELENGTH auf 0 erreicht werden. Systemabh„ngige Gr”ssen, wie z.B. Anfangsadresse von ROM und RAM, Ende des RAMs, sowie ob eine Basepage erstellt werden muss k”nnen mit den #defines am Anfang des Files PRGTOROM.C vor dem compilieren von PRGTOROM eingestellt werden. Die Erstellung der Basepage: Gem„ss dem Atari Profibuch[6] besteht die Basepage aus Zeigern auf den einzelen Programmteilen, deren L„ngen (eigentlich redundante Information) sowie Information ber das Enviroment, den Standardger„ten und den Disklaufwerken. Am Schluss folgt noch die Komandozeile. Fr die Meisten der Felder k”nnen einfach die Daten aus dem Header bernommen werden, bzw. die festen, bekanten Daten des EPAC eingesetzt werden. Die Ausnahme stellt die L„nge des Data-Segmentes (Konstanten) dar. Dieses muss derart angegeben werden, dass Programme, die den Anfang des Stackes aus der Summe der L„ngen der Segmente bilden (wie z.B. alle Turbo-C Compilate, siehe Turbo-C Startup-Code[7]), den Stack richtig ins RAM und nicht ins ROM plazieren. Diese Programme gehen von der im Atari richtigen Annahme aus, dass das BSS-Segment (nicht initialisierte Daten, Variablen) direkt auf dem Data-Segment (initialisierte Daten, Konstanten) folgt. Im EPAC sind sie dagegen im RAM, welches vor dem ROM liegt. Der Offset vom erwarteten zum tats„chlichen Ort (Ende DATA - Anfang UserRAM) muss von der Datal„nge abgez„hlt werden. Das Locaten des Code-Segmentes: Das Code-Segment wird derart Compiliert, dass alle darin vorhandenen absoluten Adressen stimmen wrden, wenn der Code an der Adresse 0 laufen wrde. Daher muss zu s„mtlichen absoluten Adressen die tats„chliche Startadresse dazugez„hlt werden. Hierzu wird eine Liste der der Orte im Code-Segment aller dieser Adressen dem Programm beigefgt (die Relokationstabelle). Die Routine 'locate' geht durch die Tabelle und erledigt dies. Dazu muss sie s„mtliche dieser Adressen darauf testen ob sie auf im ROM stehende Adressen zeigen (Vergleich des Offsets mit Code+Data-L„nge). ROM-Adressen wird der Anfang des Userprogramms im ROM dazugez„hlt, RAM-Adressen mssen zuerst um die L„nge von Code und Data nach unten verschoben werden (sie stehen direkt am Anfang des UserRAM ohne Programm und Data vor ihnen), bevor man ihnen die Anfangsadresse des UserRAMs hinzuaddiert. Das Locaten wird unn”tigerweise dadurch kompliziert, dass der Offset der ersten Adresse vom Anfang des Code-Segmentes als 32-Bit Wert gespeichert ist, die Abst„nde der restlichen Adressen von ihrem jeweiligen Vorg„nger jedoch als 8-Bit Werte. -6- 5. Der miniTOS-Emulator: ________________________ 5.1. Aufbau des Atari-TOSes: ---------------------------- Das Betriebssystem des Atari besteht aus zwei grunds„tzlichen Teilen, diese sind das TOS (teilweise auch GEMDOS genannt) sowie das GEM. W„hrend das TOS ein MSDOS-„hnliches Diskettenbetriebssystem ist (leicht erweiterte Teilmenge der Funktionen von MSDOS Version 2.11) ist GEM die Macintosh-„hnliche graphische Bentzeroberfl„che. Da der EPAC nicht ber Graphikhardware verfgt mssen nur Funktionen des TOS emuliert werden. Dieses besteht aus drei Teilen, dem GEMDOS (dem eigentlichen Verwalter) sowie zwei von diesem aufgerufenen Ein-/Ausgabe- Paketen, dem BIOS und dem XBIOS. Das BIOS ist fr Aufgaben zust„ndig, welche auf jeder Maschine existieren (Charakter-I/O), das XBIOS fr Atari-Hardware spezifische Funktionen (Maus, Bildschirmspeicher, MIDI, Sound, Timer Portchips). Das TOS stellt seine Dienste in Form von drei mit 68000 TRAP-Befehlen aufgerufenen Subroutinenlibrarys, die sich im eingebauten ROM des Atari befinden, zur Verfgung. Die Parameter fr die Funktionen werden auf dem Stack bergeben, die Ergebnisse kommen im Register D0 zurck. 5.2. Der miniTOS-Emulator: -------------------------- Auf dem EPAC soll v.a. der Debugger BUG68 laufen k”nnen, mit dem Bentzerprogramme entwickelt und getestet werden k”nnen, aber auch mit von Compilern bersetzten Programmen. Daher habe ich BUG und einige C- und Pascal-Programme nach TRAP-Befehlen durchsucht. Dabei stellte es sich heraus, dass bereits Bug auf alle drei Teile des TOS zugreift, es mssen daher drei Dispatcher mit den zugeh”rigen Routinen fr die emulierten Funktionen geschrieben werden. Alle nicht emulierten Funktionen werden abgefangen und fhren zur Ausgabe einer Fehlermeldung (siehe NOTEMU weiter unten). Da fr dieses grosse Projekt die Zeit knapp werden k”nnte habe ich mich entschieden zuerst einmal nur die Terminal-Funktionen zu schreiben, mit denen eine Programmentwicklung wie auf dem TK80 von einem beliebigen VT220 aus m”glich ist. Als zweite Stufe k„men dann die Disk-Funktionen an die Reihe. Leider scheiterte das Ziel Bug laufen zu lassen aus dem im 'Verlauf der Diplomarbeit' erw„hntem Grunde, trotzdem das die erste Stufe zum laufen gebracht werden konnte. 5.3. Der Sourcecode des miniTOS: -------------------------------- Aufbau des Sourcecodes: Der Sourcecode besteht aus 6 Modulen (START, BIOS, XBIOS, GEMDOS, NOTEMU und USER), welche in einem File MINITOS.S enthalten sind. Jedes dieser Module hat den selben Aufbau, beginnend mit dem Label nINIT, wobei n der erste Buchstaben des Modulnamens ist. Alle Labels werden derart mit dem ersten Buchstaben gebildet, um Kollisionen zwischen den Modulen zu begegnen. Auf diesen Label folgt die Initialisierung der von diesem Modul ben”tigten Variablen gefolgt von BRA xINIT (x Buchstabe des n„chsten Moduls). Nach dem BRA folgen die jeweiligen Interrupthandler. Bei START ist dies der Defaulthandler fr nicht bentzte Interrupts (ein RTE ohne weitere Befehle), fr BIOS, XBIOS und GEMDOS die jeweiligen Funktionsdispatcher, fr NOTEMU der Fehlermeldungsgeber. USER hat keine Interruptroutine und geht daher direkt in den Aufruf des Userprogramms ber. -7- START: START hat die Aufgabe den EPAC in einen definierten Zustand zu bef”rdern. Hierzu werden der Supervisorstack gesetzt, die Interrupts gesperrt, die Portbausteine geresetet und die Interruptvektoren auf ein Default gesetzt. Dieser Default ist eine Art Sicherheitsnetz damit nicht definierte Interrupts nicht zum Systemabsturz fhren, welches nichts tut und fr benutzte Interrupts durch durch den entsprechenden Handler ersetzt werden muss. START f„ngt direkt mit der Startupvektoren fr die Adressen 0-7 an, daher muss MINITOS.S ohne Basepage locatet werden. BIOS: Das BIOS des Atari enth„lt lediglich 12 Funktionen, daher habe ich alle Funktionen, die auf dem EPAC einen Sinn machen nachgebildet, diese sind: - Bconstat: gibt zurck, ob an einem Eingang ein Zeichen zum Abholen bereit ist (-1) oder nicht (0) - Bconin: wartet bis BCONSTAT bereit meldet und gibt dann das Zeichen ans Userprogramm - Bcostat: gibt zurck, ob ein Ausgang Zeichen annehmen kann - Bconout: wartet bis BCOSTAT bereit meldet und gibt dann das auf dem Stack befindliche Zeichen aus Dem Atari-CON enspricht bei diesen Funktionen der Port A (an VT220 angeschlossen), der AUX ist mit dem Port B verbunden und der PRT mit dem Parallelport des PI/T (noch nicht in dieser Implementation). - Setexc: Setzt bzw. liest einen Interruptvektor; diese Funktion ist im Atari n”tig, da auf die Vektoren nur im Supervisormodus zugegriffen werden kann, existiert hier nur aus Kompatibilit„t, da BUG diese Funktion ben”tigt - Tickcal, Drvmap, Kbshift: geben je nur eine Konstante zurck, nur implementiert um unn”tige Inkompatibilit„ten zu vermeiden (zusammen nur 4 Zeilen Assembler) - Nicht emulierte Funktionen: Nicht emuliert werden die Funktion Getmbp (Speicherverwaltung), da diese Funktion aufwendig ist, „usserst selten verwendet wird (dient laut [8, Seite 250 oben] nur der Systeminitialisierung) und der Speicher hier anders verwaltet wird als im Atari. Ebenso nicht emuliert werden die 3 Funktionen zur Diskettensteuerung (Rwabs, Getbpb und Mediach), da letztere auf dem EPAC, ohne eigene Laufwerke sinnlos sind. - Drucker: Weiterhin werden fr B..... nur die Console CON (Port A, Terminal) und der AUX (Port B) untersttzt. Untersttzung fr einen Printer PRT (Parallelschnittstelle des PI/T) war vorgesehen (ist in den Sprungtabellen vorhanden), endet aber im Aufruf von Unterprogrammen, welche nur aus RTS bestehen, da uns (Louis und mir) die Zeit ausging. Diese Funktion einzubauen drfte die Sache von ein bis zwei Tagen sein. XBIOS: Das XBIOS enth„lt Atari-Hardware spezifische Funktionen und ist daher fr normale Programme auf dem EPAC nicht von Bedeutung. Im Modul XBIOS werden daher nur die von Bug ben”tigten Funktionen Supexec (um in dem Supervisormodus zu gelangen) und Cursorconf (teilweise) nachgebildet. H„tte ich am Anfang der Arbeit von den Zeitschwierigkeiten gewusst, die am Ende der Arbeit habe, h„tte ich vom XBIOS nur Supexec, ohne den Dispatcher und Cursorconf implementiert. -8- GEMDOS: Das GEMDOS ist das eigentliche Betriebssystem des Atari. Von dessen Funktionen sind im Modul GEMDOS s„mtliche Charakter-I/O-, Speicher- und Programmverwaltungsfunktionen nachgebildet. Die Diskettenfunktionen sind in der vorliegenden Ausgabe nicht emuliert. Weiterhin wird im Gegensatz zum Atari die Redirektion der Ein/Ausgabe auf andere Ger„te nicht untersttzt (Redirektion ist auf einem Einplatinenrechner ohne Kommandozeileninterpreter sinnlos). Zu den einzelnen Funktionen: - C...in, C...out,C...is und C...os: dies sind die von CP/M stammenden Charakter-I/O-Funktionen. Mit diesen Funktionen kann mit oder ohne Echo sowie mit oder ohne Warten auf Daten mit Terminal, Serielle Schnittstelle und Printer verkehrt werden. Diese Funktinen rufen einfach die BIOS-Funktionen Bconstat bis Bconout auf (z.T. mehrere pro Funktion). Im Gegensatz zum Atari werden im miniTOS keine Tests auf ctrl-C gemacht, da ein Programm auf einem Einplatinenrechner normalerweise nicht beendet wird (h”chstens durch einen Reset neu angefangen). - Cconws und Fwrite: Diese Funktionen dienen der blockweisen Ausgabe von Daten, auf das Terminal (Cconws) oder auf beliebige Ger„te (Fwrite). Beide geben nach den eigentlichen Daten ein Return/Linefeed-Paar von sich (der Bin„rmodus bei Fwrite, in dem dies unterbleibt ist nicht nachgebildet worden, da dieser nur im Zusammenhang mit Diskettens interessant ist). - Cconrs und Fread: Analog Cconws und Fwrite dienen diese Funktionen der blockweisen Eingabe. Sie holen eine vorgegebene maximale Anzahl von Zeichen von einen Eingabeger„t. Wird in Eingabestrom ein Return oder ein Linefeed entdeckt brechen sie ab. Wird durch ein Return abgebrochen so wird zus„tzlich zum Return noch ein Linefeed geechot (Annahme, dass das Terminal ein VT... ist), erscheint dagegen ein Linefeed so wird nur dies geechot (Atari als Terminal, analog wie bei Unix). Zudem bieten diese Funktionen die M”glichkeit Tastendrcke durch Delete (VT...) oder Backspace (Atari) rckg„ngig zu machen, solange nicht Return gedrckt wurde. - Sversion: gibt auf dem Atari die Betriebssystemversion zurck (stets 0.19); bedeutungslos, wird wie BIOS-Tickcal etc. nur emuliert, weil sie nur zwei Zeilen lang ist. -Malloc, Mfree und Mshrink: diese Funktionen sind fr die RAM-Speicherverwaltung des EPAC zust„ndig. Der Speicher wird hierzu als eine Liste von Bl”cken (beim Programmstart ein Block) angesehen. Die Startadressen und L„ngen dieser Bl”cke werden in einer Tabelle im Systemspeicherbereich der EPAC festgehalten. Jedes davon kann als belegt oder als leer bezeichnet werden (Bit 31 des Startadressfeldes). Die Bl”cke k”nnen zweigeteilt (Malloc mit verlangter Gr”sse kleiner als Gr”sse des ersten gengend grossen Blockes oder Mshrink) oder mit ihren Nachbarn zusammengelegt werden (Rest von Malloc oder Mshrink oder ganzer Block bei Mfree) sofern diese(r) leer ist. Das Aufteilen der Bl”cke, sowie erkennen der M”glichkeit, zwei Bl”cke zusammenzulegen, sowie das Zusammenlegen mssen von den Speicherverwaltungsfunktionen automatisch erledigt werden. Zudem muss auf den Listenanfang und -ende Rcksicht genommen werden, aus diesen Grnden sind diese Funktionen so umfangreich. -9- - Pexec, Pterm0 und Pterm: dienen dazu, Programme zu starten und zu beenden. Von Pexec wird hier nur die Subfunktion 4 (Programm starten) nachgebildet, da die restlichen Subfunktionen Diskettenzugriffe ben”tigen. Pexec merkt sich den bisherigen Userstack, sowie den Anfang des Userprogramms auf des Systemstack, schaltet dann in des User-Modus und springt zum Userprogramm. Pexec hat selber keinen Rcksprung ins aufrufende Programm, da dafr Pterm0 und Pterm zust„ndig sind. Vom Aufrufer aus bilden Pexec+gerufenes Programm+Pterm(0) daher eine einzige GEMDOS-Funktion. Pterm0 und Pterm sind fr den Rcksprung in den Aufrufer n”tig, da das aufgerufene Programm, welches im User-Modus l„uft, wieder in den Supervisor-Modus gelangen muss um seinen Speicher freizugeben und den Userstack fr den Aufrufer wiederherzustellen. Es ist m”glich mir Pexec von einem ersten Userprogramm aus ein zweites aufzurufen, hierzu muss als Startadresse die Basepage des zweiten Programms angegeben werden (Adresse nach Ende des Ersten). NOTEMU: NOTEMU dient dazu einen automatischen Ausstieg aus einem Programm, welches nicht emulierte Funktionen aufruft, bereitzustellen, welcher ber den Grund des Ausstiegs informiert. NOTEMU wird mit der Nummer der nicht emulierten Funktion sowie einer Kennziffer fr den Ort der Funktion (BIOS = 0, XBIOS = 1, GEMDOS = 2) aufgerufen. Es schreibt eine Fehlermeldung, mit Ort und Funktionsnummeranabe auf den Schirm, damit der Bentzer weiss, welche Funktion er unerlaubterweise genutzt hat, bzw. er im miniTOS nachprogrammieren muss. Als Hilfe fr Žnderungen am eigenen Programm wird die Aufrufadresse der falschen Funktion im Userprogramm ebenfalls ausgegeben. Nach einer Pause von ungef„hr 5 Sekunden wird automatisch ein Reset ausgel”st (die Pause erm”glicht das Lesen der Meldung, auch wenn das Userprogramm beim Einschalten sofort den Schirm l”scht. USER: USER h„ngt des Userprogramm an das miniTOS an. Es simuliert des laden des Programmes von der Diskette (erstellen des Eintrags fr den Speicherblock des Userprogrammes in der Speichertabelle fr die Speicherverwaltung), und schaltet, da die Initialisierung jetzt fertig ist, die Interrupts ein. Beim Setzen der Tabelle wird bercksichtigt, das das Datenende vor dem Programmanfang steht (fhrt zu negativer L„nge, was von Mshrink verkraftet wird). Danach startet es das Userprogramm mit Pexec. Falls das Userprogramm zurckkehrt (sollte es nicht) wird es einfach wieder von vorn gestartet. Im MINITOS.S auf der Diskette befindet sich hier zus„tzlich ein Hauptprogramm, welches testeshalber die wichtigsten Betriebssystemsfunktionen aufruft. Dieses wird beim Verbinden mit dem erwnschen Anwenderprogramm einfach berschrieben. -10- 6. Test des miniTOSes: ______________________ Um die Funktion des miniTOSes zu testen wurde das erw„hnte Testprogramm mit hineinassembliert. Es schreibt das obligate 'Hello World!' auf den Schirm und wartet dann auf ein Bentzereingabe, die es dann echot; damit wird die Ein-/Ausgabe getestet. Zudem belegt es einen Speicherblock, den es sofort wieder abgibt, damit die Speicherverwaltung getestet wird. Das Testprogramm l„uft, wie auf EInplatinenrechnern blich als Endlosschleife. Die Aufgerufenen Funktionen sind der Reihe nach: Mshrink (geh”rt als erstes an den Anfang jedes anst„ndigen Atari Programmes), Fwrite (ruft Bcostat und Bconout auf), Fread (Bconstat und Bconin), Malloc (zuerst gr”sster Block suchen, dann ein Block belegen), Mfree und schliesslich Pterm0 (ruft Pterm und Mfree auf). Beim Aufrufen des eigentlichen Userprogramms wird bereits Pexec benutzt. Damit sind alle wichtigen Betriebsystemsfunktionen getestet, der Rest konnte aus Zeitmangel nicht getestet werden, besteht aber fast ausschliesslich aus kleinen oder einfach aufgebauten Routinen, die wahrscheinlich fehlerfrei sind. Der XBIOS-Dispatcher ist eine Kopie des Bios Gegenstckes und somit Fehlerfrei (es sei denn Tippfehler). Der einzige gr”ssere Teil, der berhaupt nicht getestet worden ist ist Notemu. 7. Verwendung des minTOSes: ___________________________ Um ein Programm unter miniTOS laufen zu lassen muss dieses auf normaler Weise auf dem Atari entwickelt, comipliert bzw. assembliert sowie gelinkt werden. Die Funktionsaufrufe der untersttzten Funktionen sind absichtlich zu denen des Atari voll kompatibel gehalten worden (Aufrufparameter, Reihenfolge, Typen), es kann daher fr die Programmierung die umfangreiche Literatur zum Atari benutzt werden. Auf diesem Grunde verzichte ich hier auf eine Zusammenstellung aller Funktionen mit ihren Parametern, was einige Seiten beanspruchen wrde. Als definitive Referenz sollte ohnehin das miniTOS-Listing zu Rate gezogen werden. Das daraus resultierende PRG-File muss danach mit PRGTOROM (mit Basepage) locatet werden, die geschieht automatisch an die richtige Adresse, da ich diese passend zu miniTOS eingestellt habe. Danach mssen MINITOS.ROM, RS232DEF.B und .ROM ab den jeweiligen Anfangsadressen in das EPROM gebrannt werden. Im Junior Programmer wird dierzu zuerst der EPROM-Typ (27512) eingestellt, dann MINITOS.ROM geladen, dann Offset auf $36 gestellt und RS232DEF.B geladen. Zum Schluss wird auf Offset $CDC gestellt, .ROM geladen, Offset auf 0 gestellt und Programm gedrckt. Danach wird das EPROM in den EPAC eingesteckt und dieser eingeschaltet. 8. Schlussbetrachtung: ______________________ 8.1. Istzustand: ---------------- In der vorliegenden Form ist des miniTOS als Betriebssystem fr mit beliebigen auf dem Atari verfgbaren Compilern und Assemblern erstellten Programmen verwendbar, welche nicht auf Disketten oder den Printer zugreifen. Es wird dazu neben dem EPAC ein beleibiges Terminal ben”tigt, welches VT52-(ANSI-)Steuerzeichen versteht. -11- 8.2. Vorschl„ge fr zuknftige Erweiterung: ------------------------------------------- Das gr”sste Defizit dieser Implementation ist das Fehlen von Routinen zum Diskettenzugriff. Dadurch wird haupts„chlich die Programmentwicklung behindert, da Bug nicht genutzt werden kann. Fr die Implementation dieser Funktionen empfehle ich, die BIOS- und XBIOS-Diskroutinen undefiniert zu lassen (sie werden nur selten genutzt, brauchen aber einen grossen eigenen Verwaltungsaufwand, da sie blockorientiert sind und die ganze Direktorystruktur "entwirren" mssen). Stattdessen sollten die GEMDOS-Funktionen mit ihren Parametern zusammen in einer codierten Form (z.B. Funktionsnummer + Parameter + ev. Speicherbl”che, auf die Pointer zeigen) an den Host bertragen und von diesem ausgefhrt werden (Atari oder VAX an Port B oder ein intelligentes Terminalprogramm mit Fileserverfunktion auf dem Atari an Port A analog zu [4]). Um mit m”glichst geringem Aufwand diskf„hig zu werden mssen fr Bug lediglich die Funktionen Dsetdrv, Dsetpath, Fcreate, Fopen, Fclose und Fseek nachgebildet werden, zus„tzlich muss noch Pexec vervollst„ndigt werden. Der Rest kann bei Gebrauch sp„ter erfolgen. Zudem mssen fr die Vollst„ndigkeit die Druckerfunktionen des BIOS erg„nzt werden. 9. Vermerke und Literaturhinweise: __________________________________ [1] Zwergenaufstand EPAC-68008 - klein, aber oho! c't 87/2/88, 87/3/140, 87/5/148, 87/6/164 [2] Entwicklungshilfe Programmierung von Einplatinenrechnern in TurboC mc 89/4/110 [3] Cross-Software fr 680XX-Einplatinencomputer Interner Bericht No. 8701 ETH-Institut fr Fernmeldetechnik Max Dnki [4] Mini-DOS Ein DOS ohne Disk-Verwaltung c't 89/8/166 Brennbares Pascal Turbo-Pascal Programme im EPROM c't 89/9/228 [5] Das TOS-Listing, Band 1, BIOS-DEMDOS-VDI Heise Verlag, Hannover [6] ATARI ST Profibuch SYBEX-Verlag GmbH, Dsseldorf [7] TCSTART.S Turbo C Startup Code Borland International 1988, mit Turbo C mitgeliefert [8] c't Kartei TOS-Funktionen c't 89/7/245-253