Die Technik von CP/M (2)
Weiter geht es in der mehrteiligen Artikelserie über die Technik die hinter CP/M steckt. Gestern erschien der erste Teil, an diesen schließt dieser zweite Teil direkt an. Komplett findet ihr das ganze auf der Website. Hier alle Tele:
Erschienen sind:
Teil 1 behandelt den Aufbau des Speichers und des Dateisystems
und sie lesen gerade:
Teil 2 behandelt den Aufbau einer Diskette und des Rechners, Bildschirm und Tastatur
und es kommen noch:
Teil 3 behandelt die BDOS-Funktionen, den Kommandointerpreeter, User Befehl und die Geräte.
Teil 4: Über CP/M 3, andere Versionen und warum es heute noch neue CP/M Rechner gibt.
Aufbau der Diskette
Eine CP/M Diskette hatte immer auf dem ersten Sektor und der ersten Spur den Bootloader. Das ROM-BIOS des Rechners musste beim Einschalten diesen Sektor in den Arbeitsspeicher laden und das dort gespeicherte Programm lud dann nacheinander BIOS, BDOS und CCP in den Speicher (s.u.). Dafür waren bestimmte Größen vorgesehen, notfalls folgten leere Sektoren. So war auf dem Amstrad CPC Sektor 3 bis 7 von Spur 0 ungenutzt, weil hier das BIOS im ROM steckte. Es folgte das Verzeichnis, das immer auf einem neuen Block anfing. So belegte bei den 180 KByte Laufwerken des Amstrad mit 1 KByte großen Blöcken das System 9 KByte, bei den Fremdfloppys von Vortex mit 4 KByte großen Blöcken dagegen 12 KByte.
Die Größe des Verzeichnisses konnte vom Hersteller gewählt werden. Typisch waren 64 Einträge bei einer Disk mit unter 250 KByte großen Blöcken, das Maximum, das ich gesehen habe waren 768 Einträge. Die Größe wurde so abgestimmt, das es nicht vorkam das bei normaler Nutzung das Verzeichnis voll war, auf der Disk aber noch Platz war. Dies musste mit der Blockgröße abgeglichen werden, denn eine zweite Einschränkung war, dass ein Eintrag maximal 16 Blöcke aufnahm. Benötigte er mehr Blöcke – bei 1 KByte Blöcken schon ab 16 KByte Dateigröße – so wurde ein zweiter Eintrag angelegt und in zwei Verwaltungsfeldern angegeben, dass dieser auf den ersten folgt (Extend). Jeder Eintrag belegte 32 Bytes, sodass bei meinen oben erwähnten Disketten die 64 bzw. 256 Einträge des Verzeichnisses 2 bzw. 8 KByte belegten. Der Eintrag, der sich von der internen Verwaltungsstruktur FCB ableitete hatte in den ersten 16 Bytes Informationen über den Dateinamen (11 Zeichen – 8 für den Dateinamen, drei für die Erweiterung), die Größe der Datei und den User-Bereich sowie ob sie in Bearbeitung war und in den 16 Bytes im zweiten Teil standen die belegten Blöcke, gab es weniger als 256 Blöcke so einen pro Byte, ansonsten zwei. Ob eine Datei versteckt war oder nicht beschreibbar wurde im siebten Bit der Erweiterung gespeichert – für Dateinamen waren nur ASCII-Zeichen zulässig, die 7 von 8 Bits eines Bytes belegten. Die Dateinamen wurden immer in Großbuchstaben abgelegt. Heute gewöhnungsbedürftig, aber auch MS-DOS folgte diesem Beispiel bis zur letzten Version und die erschien erst 1994.
Ein Nachteil dieses Konzepts war, das CP/M beim Einlegen einer Diskette, das ganze Verzeichnis gescannt werden musste. Dies wurde bei MS-DOS / PC-DOS besser gemacht, da wurde auf der Diskette ein Array mit den Nummern der belegten Blöcke abgelegt (FAT : File Allocation Table). Auch diese Tabelle musste gescannt werden, sie war aber kleiner als das Verzeichnis.
CP/M unterstützte bis zu 16 Laufwerke, welche die Bezeichnung A: bis P: hatten. Wem das bekannt vorkommt: MS-DOS übernahm es und so ist es bis heute so, dass zumindest das Systemlaufwerk unter C: eingebunden ist. CP/M 2.2 beschränkte die Größe einer Partition auf 8 MByte, weil die Sektornummern in 16 Bit Zahlen gespeichert wurden und da ist der höchste Wert 65536 was mit den 128 Byte pro Sektor 8 MByte ergab. CP/M 3.0 erhöhte dies auf 32 MByte pro Partition. CP/M 3.0 konnte bis zu 16 Partitionen pro Festplatte anlegen.
Es gab unter CP/M noch nicht das Konzept der Verbindung von Dateiendungen und Programmen. Zwar speicherten viele Programme ihre Dateien mit bestimmten Erweiterungen – Turbo Pascal z.B. als „.pas“, aber man konnte nicht einen Dateinamen wie „programm.pas“ eintippen und CP/M startete dann den Turbo Pascal Compiler. Die einzige feste Verknüpfung war, das eingegebene Dateinamen vom CCP um .com ergänzt wurden, und dann wenn eine Datei dieses Namens existiere sie gestartet wurde. Gab es sie nicht so gab CP/M den Namen einfach mit einem Fragezeichen ? zurück. Die Systemmeldungen von CP(M waren insgesamt sehr kurz und Wörter wurden meist auch noch abgekürzt wie bei die wohl häufigste Fehlermeldung „Bdos Err On C: R/O“ die man bekam wenn man eine diskette gewechselt hatte und das BDOS davon nichts mitbekam.
Architektur eines CP/M Rechners.
Die meisten CP/M Rechner hatten eine textbasierte Oberfläche. Das heißt der Monitor zeigte nur Text an. CP/M selbst kannte ja nur die Textdarstellung. Das musste aber nicht so sein. Ich arbeitete mit einem CPC 464, der einen Graphikbildschirm hatte, also Text mit Grafik mischen konnte. Die meisten Rechner hatten ein kleines ROM. Dieses ROM beinhaltete zum einen die Boot-Routine: Damit CP/M überhaupt lief, musste beim Einschalten des Rechners – bei 8080 Rechnern wird dabei das Programm ab Adresse 0 ausgeführt – ein Programm ausgeführt werden, dass mindestens den ersten Sektor von der Diskette in den Speicher einlaß und das Programm dort ausführte. Dieses lud dann den Rest von CP/M von der Platte.
Ein Rechner der nur Text ausgab, brauchte einen Bildschirmspeicher. Pro Zeichen das auf dem Bildschirm zu sehen war benötigte er ein Byte. Typisch waren 80 Zeichen in der Breite, da dies der normalen Breite einer A4 Seite bei Druckern entsprach. Letztendlich endete vieles was man erarbeitete ja auf Papier. In der Höhe waren 24 oder 25 Zeilen üblich, was zu einem Speicherverbrauch von 2 KByte führte. Manche Rechner hatten auch noch einen zweiten Speicherbereich den Attributspeicher. Ein Zeichen bei diesen rechnern konnte fett, kursiv, unterstrichen, durchgestrichen, invertiert oder blinkend dargestellt werden. Für jeden Zustand konnte man ein Bit im Attributspeicher setzen, da die Attribute auch kombiniert werden konnten (wie Fett-Kursiv). Wie die Matrix das Zeichens aussah, das dann jeweils ausgegeben wurde, stand in einem Font-Rom. Bei einer groben Auflösung von 8 x 8 Pixeln brauchte man für den ASCII-Zeichensatz ohne Steuerzeichen 768 Byte pro Font. Zumindest die Kombinationen kursiv, fett und fett-kursiv erforderten weitere Zeichensätze, die anderen Attribute konnte man auch programmtechnisch umsetzen. Manche Systeme wie der Osborne 1 verfügten über mehrere Fonts, die man wechseln konnte, aber nur jeweils einer konnte aktiv sein.
Im ROM war meist auch das komplette BIOS, nicht nur zum Ansprechen der Disketten, sondern auch die Ein-/Ausgabe von Tastatur, Bildschirm und Schnittstellen, gebräuchlich warne eine parallele (Centronics) Schnittstelle für einen Drucker und eine serielle für ein Modem oder serielle Drucker. Das BIOS auf der Diskette war dann relativ klein und beinhalte nur Routinen mit denen man das ROM in den Adressbereich einblendete und dann einen Sprungbefehl an die entsprechende Stelle des ROM-BIOS. Die typische Größe eines BIOS mit einem Font war so 8 KByte.
Bildschirm und Tastatur
CP/M war vor allem als Diskettenbetriebssystem ausgelegt. Etwas stiefmütterlich wurde die Eingabe über Tastatur und die Ausgabe auf den Bildschirm behandelt. Als die Version von CP/M 1974/75 entwickelt wurde, waren Terminals als Ein-/Ausgabegerät üblich. Ein (Video)Terminal enthielt einen Bildschirm und eine Tastatur, wurde aber über eine serielle Schnittstelle an einen Computer angeschlossen und gab nur das weiter, was man eintippte, es lief aber kein Betriebssystem oder ein Anwenderprogramm auf ihm. Die Daten tauschte es über eine serielle Schnittstelle aus. Später kamen separat anzuschließende Monitore und Tastaturen auf den Markt.
Heute findet man auf jeder Tastatur neben den direkt eintippbaren Buchstaben, Zahlen und Sonderzeichen, die auch eine Schreibmaschine hat, auch Funktionstasten, einen Cursorblock und den numerischen Block. Was diese beim Darauftippen an den Computer übergeben wird, war je nach Typ der Tastatur damals unterschiedlich, es gab keinen Standard. Genauso war es bei der Ansteuerung eines Bildschirms. Man musste den Bildschirm löschen, Cursor positionieren etc. Die Lösung für beide Probleme waren Steuercodes. Ein Byte im Speicher kann auch als ein druckbares Zeichen interpretiert werden, dafür gab es den ASCII (American Code for Information Interchange) Code. Er belegte die Werte von 32 bis 127 mit den Zeichen, die man auf einer Tastatur eingeben kann, das „A“ hat z.B. den Code 65. Die Werte über 128 waren nicht definiert und wurden manchmal für grafische Symbole genutzt. Die Codes unter 32 betrachtete man als Steuercodes, die nicht ausgegeben wurden, sondern eine Aktion auslösen. Einige sind bis heute in Benutzung: so wird eine Zeile von den beiden Codes 13 und 10 begrenzt, die früher beim Drucker einen Wagenrücklauf auf den Zeilenbeginn und einen Zeilenvorschub auslösten. Andere Codes, die der Drucker nutzte, waren 8 (Tabulator), 9 (Klingelton), 11 (Seitenvorschub).
Tastaturen haben bis heute ein Control-Taste, auf deutschen Tastaturen meist mit „STRG“ für „Steuerung“ beschriftet. Drückte man auf die und dann auf einen Buchstaben so übergab die Tastatur ein Steuerzeichen an den Computer und zwar den Code 1 bei dem Buchstaben A und den Code 27 bei dem Buchstaben Z. So konnte man die Tastatur auch für Cursorbewegungen nutzen. Bis heute hat sich in Spielen die Nutzung der Tasten ESDX für die Cursorbewegung gehalten. Die populäre Anwendung Wordstar, das erste brauchbare Textverarbeitungsprogramm, setzte einen Quasistandard, indem sie die Tasten auf der linken Hälfte der Tastatur für Cursorbewegungen / Scrollen nutzte und Tasten auf der rechten Seite für komplexere Befehle, indem diese als Prefix galten. So STRG+K für Blockoperationen. STRG-KW speicherte einen Block, STRG-KR laß einen Block ein.
CP/M nutzte praktisch keine dieser Codes. Mit STRG+P konnte man die Ausgabe auf den Drucker umleiten, mit STRG+S die Ausgabe temporär anhalten. Am meisten brauchte man STRG+C das brach eine Anwendung ab und lud das BDOS / CCP von der Diskette und man war wieder bei CP/M. Tastatureingaben konnte man zeichenweise oder die ganze Zeile löschen. Es gab keine Cursorbewegung in der Eingabezeile.
Beim Bildschim ging man ähnlich vor. Hier wurden Steuerzeichen in den Ausgabetext eingebaut und jedes System interpretierte diese anders. Bei meinem CPC 464 wurde der Text z.B. CTRL-X (24) invertiert. Es gab schon Standards so die populären Terminals von DEC VT-52 und VT-100. Aber im Prinzip konnte jeder Hersteller sein eigenes Süppchen kochen. So wechselte auch Amstrad zwischen dem CPC 464/664 und dem 6128 die Steuercodes aus.
Für den Anwender bedeutete das: er konnte eine Anwendung nicht einfach starten, er musste dieser erst mitteilen welche Steuercodes sein System verwendete. Populäre Systeme waren meist in einem Installationsprogramm hinterlegt, ansonsten musste man Fragen beantworten oder gar Speicherstellen modifizieren. Der folgende Ausdruck zeigt die Liste der Computer, die das Installationsprogramm von Turbo Pascal 3.02 kannte:
Choose one of the following terminals:
1) ADDS 20/25/30 13) Lear-Siegler ADM-31 25) Teleray series 10
2) ADDS 40/60 14) Liberty 26) Teletex 3000
3) ADDS Viewpoint-1A 15) Morrow MDT-20 27) Televideo 912/920/92
4) ADM 3A 16) Schneider 464/664 28) Texas Instruments
5) Ampex D80 17) Otrona Attache 29) Visual 200
6) Kaypro with hilite 18) Qume 30) Wyse WY-100/200/300
7) DEC Rainbow, 8 bit 19) RC-855 (ITT) 31) Zenith
8) Hazeltine Esprit 20) Osborne 1 32) Schneider 6128
9) ANSI 21) Soroc 120/Apple CP/M 33) None of the above
10) Hazeltine 1500 22) Soroc new models 34) Delete a definition
11) Kaypro, no hilite 23) SSM-UB3
12) Lear-Siegler ADM-20 24) Tandberg TDV 2215
Which terminal? (Enter no. or ^Q to exit):
Gary Kildall bzw. die Angestellten von Digital Equipment haben nie hier etwas festgelegt. Vielleicht weil sei möglichst wenige Vorgaben machen wollten. Das ist schade, denn es hätte die Vielfalt ja nicht unterbunden, wenn für jedes System gelten würde, das die Ausgabe des Steuerzeichens 11 den Bildschirm löscht. Ein BIOS, das ein VT-100 Terminal unterstützt, hätte durch eine einfache Ersetzungstabelle daraus ein „^[[2J“ gemacht (^steht für den Code 27, ESC). Den Anwender wären viele Stunden der Installation von Software erspart gewesen. Ebenso hätte man wichtige Funktionstasten für Cursorbewegung, Rollen, Scrollen etc. mit Controlcodes belegen können und auch hier hätte das BIOS den Scancode den eine Tastatur primär liefert, in den Code für CP/M umwandeln können.
Im Allgemeinen gab es bei Bildschirm und Tastatur kaum Vorgaben. Der Bildschirm musste nur 64 Zeilen Breite haben. Mehr nutzte CP/M nie, auch auf 80 Zeichen Bildschirmen wurden bei der Directoryausgabe maximal 64 Zeichen genutzt und die Tastatur musste nur die einer Schreibmaschine sein. Editieren konnte man in der Eingabezeile nur, indem man das letzte Zeichen oder die ganze Zeile löschte, was aber bei den kurzen Dateinamen und wenigen Parametern die damals üblich waren keine große Einschränkung war.