CP/M 2.2x, BIOS 2.0 von Gerald Schröder Inhaltsverzeichnis: 1. Wer hat wann was gemacht? 2. Aufbau des CP/M Version 2.0 2.1 Struktur 2.2 Das Linken 2.3 Die BIOS-Module 2.4 Putsys und Boot-Sektor 1. Wer hat wann was gemacht? Die Grundstruktur dieses CP/M stammt von "Montezuma", und zwar von einer Version für ein TRS-80 Modell IV. Ich habe die Listings studiert und viele Anleihen gemacht. Nur die Hardware-Ebene mußte stark verändert werden, denn die Diskettenlaufwerke und der 80-Zeichen-Bildschirm werden bei meinem Genie IIs ganz anders angesteuert. Außerdem habe zuerst einige Features (IOBYTE, DCBs, serielle Schnittstelle) weggelassen, die mir zu aufwendig erschienen. Sie lassen sich aber leicht "nachrüsten", soweit dies noch nicht geschehen ist. Bei den Diskettenroutinen wäre noch TCS/Phoenix mit einem CP/M für den Speedmaster zu erwähnen, aber diese haben wiederum erstens schlampig gearbeitet und zweitens meist aus den Newdos-Routinen abgeschrieben. Übernommen habe ich einiges aus der Tastatur-Routine. Der größte Teil des BIOS ist von mir selbst erdacht und eingegeben, obwohl ich die Anregungen nicht leugne. Die erste Version entstand im August 1987 unter dem Editor/Assembler ZEUS auf einem Genie IIs (Betriebssystem GDOS). Die Version 2.0 entstand im Februar 1989, diesmal unter CP/M mit dem Assembler Macro-80. Besonders hervorzuheben ist hier der Port-Betrieb der Disk-Ein-/Ausgabe und die Nutzung etlicher Vorteile des Prozessors HD-64180. Im folgenden wird diese Version beschrieben. 2. Aufbau des CP/M Version 2.0 2.1 Struktur CP/M besteht bekanntlich aus den Teilen CCP, BDOS und BIOS. Das BDOS wird unverändert aus der Version 2.2 von Digital Research übernommen. Den CCP habe ich ausgelagert, d.h. er wurde zu einem eigenständigen COM-File, der auch wie so einer gestartet wird. Deshalb schrieb ich einfach einen Header davor, der ihn nach dem Start bei 100h unter das BDOS schiebt und dort weiterarbeitet. Es kann auch jede andere Shell genommen werden. Nennen Sie sie einfach nur CCP.COM und beim Booten wird sie statt des CCP geladen. Das BIOS ist der hauptsächlich von mir erstellte Teil. Es gliedert sich in mehrere Module, die einzeln geändert werden können. Zentrale Teile, namentlich FDC.MAC und DISK.MAC sind fast unverändert von Montezuma übernommen worden. Zwei andere Module sind noch wichtig: Der Bootsektor hat die Aufgabe, BDOS und BIOS von den Systemspuren zu lesen und dann zu starten. Bei mir enthält der Boot-Sektor auch noch einige Cold-Start-Routinen, die eigentlich dem BIOS zuzurechnen sind. Das zweite Modul ist Putsys, das einfach nur Aufgabe hat, den Bootsektor sowie BDOS und BIOS auf die Systemspuren zu schreiben. 2.2 Das Linken Unter CP/M erschien mir der Assembler Macro-80 am besten geeignet für die System-Erstellung, obwohl er immer noch viele Unzulänglichkeiten aufweist. Die Umwandlung in REL-Files sollte kein Problem auf. Benutzen Sie einfach folgenden Aufruf: "M80 =modul"; oder "M80 ,=modul" zum Testen; oder "M80 ,modul=modul", um noch ein Listing (Extension PRN) zu erhalten. Beim Linken habe ich immer gleich ein komplettes Sysgen erstellt, also einen COM-File, der nach seinem Start ein System auf die Spuren einer formatierten Diskette schreibt. Dazu wurden die Module Putsys und Bootsec bei D000h abgelegt, gefolgt von dem BDOS und dem BIOS ab E106h. Wenn das System länger ist, verschieben sich die Adressen entsprechend weiter nach unten. Da sich die ganze Prozedur sehr aufwendig gestaltet, habe ich alle REL-Files sowie L80 auf die Ramdisk (Laufwerk M:) gelegt und bin dann auf Laufwerk A: gegangen, auf dem SUBMIT.COM, XSUB.COM und ein Text LINK.SUB standen. Nach dem Aufruf "SUBMIT LINK" wird auf dem Laufwerk M: ein COM-File SYSGEN.COM erstellt. Diesen können Sie auf Disk sichern und dann zum Erzeugen einer CP/M-Diskette starten. Der SUBMIT-File LINK.SUB sieht folgendermaßen aus: XSUB ; auch BDOS-Aufrufe umleiten M: ; auf die Ram-Disk umschalten L80 ; Linker starten /P:D000 ; Putsys und Boot-Sektor hier ablegen PUTSYS, BOOTSEC ; die ersten beiden Module /P:E106 ; hier beginnt das BDOS GENDEF, BDOS, CONFIG, BOOT, CONIN, CONOUT, SERIELL, PRINTER DISK, FDC, RAMDISK, BUFFER SYSGEN/N/E ; COM-File erzeugen N ; den Inhalt nicht verschieben! Folgendes ist zu beachten: 1. Alle Parameter-Eingaben von "/P:D000" bis "BUFFER" können einzeln in einer Zeile oder hintereinander, mit Kommas getrennt, erfolgen. 2. Nach dem Aufruf "BUFFER" kann der Aufruf "/M" eingeschoben werden. Es erscheinen dann alle globalen Labels. Das letzte Label sollte "ZZBIOS" heißen und sollte einen Wert zwischen FE00h und FFFFh habe. Ansonsten ist Ihr BIOS entweder zu lang (setzen Sie die Anfangsadresse herunter) oder sehr kurz (Anfangsadresse raufsetzen). 3. Es darf kein globales Label mehr undefiniert sein, wenn "SYSGEN/N/E" aufgerufen wird. Sonst war irgendwas falsch. 4. Der entstandene COM-File SYSGEN.COM wird normal gestartet und schiebt sich selbst über das alte BDOS/BIOS. Deshalb dürfen im Modul PUTSYS keine BDOS/BIOS-Aufrufe erfolgen. 5. Nach dem /P:E106 muß auf jeden Fall zuerst BDOS und dann CONFIG aufgerufen werden. GENDEF darf nur deshalb davor stehen, weil es keinen Code erzeugt, sondern nur einige Label-Definitionen liefert. Rufen Sie es ansonsten nach CONFIG auf. Die Reihenfolge der Module ist dann egal, nur BUFFER muß das letzte Modul sein, denn hier wird ZZBIOS erzeugt, das am Ende des BIOS stehen muß! Außerdem wird der in BUFFER enthaltene Code (bzw. der freigehaltene Platz) beim Booten nicht geladen! Wenn hier also Programmcode steht, gibt es einen Absturz. 2.3 Die BIOS-Module: gendef: legt allgemeine Definitionen fest. Es wird kein Code erzeugt, weshalb das Modul auch irgendwo gelinkt werden darf. config: beinhaltet die Sprungleiste des BIOS und eine Auswertung des I/O-Byte. Mit seiner Hilfe können Ein-/Ausgabe umgeleitet werden. boot: beherbergt die Warm-Boot-Routine mit einem Unterprogramm, das CCP.COM von der Diskette lädt. Außerdem mußten einige BDOS-Aufrufe aus dem CCP aufgenommen werden, die dieser sonst erledigt (RESDSK usw). Eine Hilfsroutine zur Ausgabe von Strings auf dem Bildschirm befindet sich auch noch hier. conin: fragt die Tastatur ab. Diese Routine ist genau auf die Genie IIs- Tastatur und die Geschwindigkeit meines IIs abgestimmt. Zu ändern wären neben der rein anderen Tastatur-Interpretation vor allem die Warteschleifen-Werte: a) Entprellung (irgendwo LD BC,xxxx / CALL wait); b) erstes Wiederholen der gedrückten Taste (firdly); c) zweites und fortmaliges Wiederholen der Taste (secdly). Alle Werte sind für 9.2 Mhz und meine Tipp-Geschwindigkeit OK, dürften bei Ihnen aber anders zu dimensionieren sein. conout: gibt Zeichen auf dem Bildschirm aus. Bei mir dient dazu die c't-Terminal-Karte, die über eine serielle Schnittstelle des HD-64180 angesprochen wird. Dadurch wurde diese Routine extrem kurz. printer: bedient den Drucker. Bei mir über eine Centronics-Schnittstelle, die per Port ansprechbar ist. seriell: hier stehen Routinen zum Ansprechen der seriellen Schnittstelle, bei mir eine vom HD-64180 zur Verfügung gestellte. Sie dient mir als Punch und Reader. ramdisk: beinhaltet die Zugriffsroutinen auf die Ramdisk, Laufwerk M:. Sie ist bei mir 448 Kb groß und wird über die HD-64180-DMA angesprochen. disk: erledigt die Organisation der Disketten-Ein/Ausgabe. Der Blocking/ Deblocking-Algorithmus (von Montezuma) ist hier vor allem interessant. Es dürfte eigentlich nichts zu ändern sein, wenn sie nicht mehr als 2 Laufwerke benutzen wollen. Im Gegensatz zur Version 1.x sind die Disk-Tabellen in dieses Modul integriert. fdc: gibt und holt Daten von Diskette. Dies ist das zentrale Modul, denn CP/M ist nunmal ein Disketten-Betriebssystem. Dieses Modul läßt sich auch gut in andere Programme ("format", "sysgen") einbauen. Es dürfte stark von Ihrer Hardware und dem gewählten Komfort Ihres CP/M abhän- gen, wie dieses Modul aussieht. Mit Komfort meine ich, wieviele Dis- kettenformate Ihr CP/M später lesen können soll. Je nachdem müssen Sie dann auch das Hardware-Byte (DPB-Options-Byte) ändern und evtl. noch mehr Parameter dazunehmen. Die Sector-Translation-Table gilt übrigens für die physikalischen Sektoren, nicht die logischen. Mir wäre sie sonst zu lang gewesen. buffer: enthält nur noch Platzreservierungen. Sie liefern a) Labels für die anderen Module und b) eine Kontrolle über die Länge des gesamten Systems. Das letzte Label sollte immer "ZZBIOS EQU $" sein, damit die Länge nach dem Linken feststellbar ist. 2.4 Putsys und Boot-Sektor Putsys nimmt den Boot-Sektor und legt ihn auf einer Diskette in Laufwerk A: (Track 0, Sektor 0) ab. Dann werden das BDOS und das BIOS dahinter abgelegt, von Sektor 1 bis zum Ende des Tracks, dann auf der Rückseite weiter (Sektor 0 bis Trackende) und evtl. noch auf Track 1, wenn Track 0 nicht reicht. Bei mir ist das System 6 KByte, also 6 Sektoren lang. Es hat also bequem auf Track 0 Platz (4 Sektoren vorne und noch 2 auf der Rückseite), aber ich habe bei mir Track 1 freigelassen, für spätere Erweiterungen. Der Boot-Sektor hat ja nicht viel zu tun. Er muß nur das von Putsys abgelegte System (bei mir 6 Sektoren) laden und den Cold-Start anspringen. Weil in meinem Boot-Sektor noch viel Platz war, habe ich die Cold-Start-Routinen gleich hierher verlagert. Da sie nur einmal gebraucht werden, ist das kein Problem. Danach wird dann die Warm-Start-Routine des BIOS angesprungen, die einige Initialisierungen durchführt, u.a. auch das BDOS initialisiert, und dann eine Kommando-Shell lädt. Sollten sich noch Fragen oder Anregungen ergeben, stehe ich unter untenstehender Adresse zur Verfügung. Hittfeld, im Februar 1989 Gerald Schröder Am Schützenplatz 14 2105 Seevetal 1