Home

Computer

Software

Site Map

Die Technik hinter CP/M

Es gib zusätzlich zu diesem langen Artikel noch zwei kurze: Dieser alte Artikel behandelt CP/M-Technik und Geschichte erheblich kürzer und mit weniger Details. Dieser Artikel beschäftigt sich nicht mit der Technik, aber der Geschichte.

CP/M – Control Program for Microcomputers – besteht aus drei Teilen, man könnte auch sagen drei Schichten. Während dies heute normal ist (Internetdatenverkehr besteht zum Beispiel aus bis zu sieben Schichten), war dies damals eine revolutionäre Neuerung. Vorher waren Betriebssysteme mehr oder weniger monolithisch. Die drei Schichten bauen aufeinander auf und sind:

• CCP: Console Command Processor: die Eingabeschnittstelle mit der der Benutzer Befehle eintippen kann.

• BDOS: Das BASIC Disk Operation System enthält eine Sammlung von 41 Routinen, mit denen man Dateien verwalten kann, aber auch Dinge auf dem Bildschirm oder Drucker ausgeben kann und Zeichen von der Tastatur einlesen kann.

• BIOS: Das BASIC Input / Outputsystem kümmert sich vor allem um den physikalischen Zugriff auf Diskettenlaufwerken.

Speicheraufbau

Beim Start werden die drei Teile an das Ende des Speichers geladen. Das „Ende“ muss nicht der Maximalspeicherausbau sein. Zum einen läuft CP/M auch mit weniger Speicher – die letzte Version von CP/M, 2.2 die ohne Bankswitching arbeitete, mit minimal 20 KByte – zum anderen können sich oben noch Speicherbereiche befinden, die zur Hardware gehören, bei den Amstrad PC belegte z.B. der Bildschirmspeicher die letzten 16 KByte, darunter kamen Betriebssystemdaten (die des ROM-Betriebssystems), sodass nur etwa 44 KByte übrig blieben. Die Reihenfolge ist aber fix: ganz oben ist das BIOS, dann folgt das BDOS und zuletzt der CCP. Diese Reihenfolge ist so gewählt, weil ein Programm, nachdem es geladen wurde den CCP überschreiben kann. Er wird bei einem Rücksprung ins BDOS automatisch neu von der Diskette geladen.

CP/M lieferte das Programm Movcpm mit. Dieses konnte den Start von CP/M in Vielfachen einer Page (256 Bytes) verschieben, wenn man zum Beispiel einen Speicherbereich für ein Programm brauchte, der persistent war, also auch nach Programmende die Daten behielt. Das waren meist Treiber für zusätzlich erworbene Hardware.

Ganz am Anfang des Speichers findet man zum einen die Restarts: Das sind beim 8080/Z80 Prozessor Routinen, die mit einem Befehl ohne Adressangabe angesprungen werden können. Sie werden für häufige Softwareroutinen genutzt, z.B. um das Betriebssystem-ROM einzublenden oder fürs Bankswitching. Einige Restarts nutzte CP/M selbst. Danach folgten einige Verwaltungsinformationen, so z.B. ab Adresse 80H (128 dezimal, im Folgenden arbeite ich meist mit Hexadezimalziffern, weil diese meist gerade sind) die Eingabezeile aus der ein Programm die Startparameter wie übergebene Dateien herausfischen konnte.

Den Bereich zwischen 100H und dem Anfang des CCP bezeichnete man als TPA – Transistent Programm Area, weil wenn ein Programm beendet war dieser Bereich wieder frei war. Die Größe der TPA legte fest wie viel Arbeitsspeicher Anwendungsprogramme zur Verfügung hatten. In ihr wurden sie ausgeführt.

Ein Programm für CP/M wurde immer an die Adresse 100H geladen. CP/M erkannte ein ausführbares Programm an der Endung „.com“. Es konnte dann den ganzen Speicher bis zum Anfang des BDOS nutzen. Viele Implementierungen gaben diesen Speicher auch beim Start aus:

MinZ_C #47 - Z8S180 @ 33.333MHz 1MB RAM (0ws) 512KB Flash "ROM" (1ws)

A: RAMdisk 948 KB

C: SD Card 8192 KB

P: ROMdisk 496 KB

CP/M 2.2 64K (57K [+2K CCP] TPA) - BIOS V1.3 SUN JAN 1/01 5:28:34

A>

In diesem Falle nutzt CP/M die vollen 64 KByte, für Programme stehen 57 KByte zur Verfügung bzw. wenn der CCP überschrieben wird sind es sogar 59 KByte. Das ist viel, bedenkt man, dass der Intel 8080 maximal 64 KByte adressieren kann.

Das war einer der wichtigsten Vorteile von CP/M. Das Betriebssystem brauchte sehr wenig Speicher. Das BIOS belegte typisch 4 KByte, das BDOS unter CP/M 2.2 zwischen 2,8 und 3,5 KByte, das hing davon ab, welche Hardware tatsächlich verbaut und unterstützt werden musste. Fehlte z.B. eine serielle Schnittstelle so fielen Routinen weg. Der CCP war immer 2 KByte groß. Dazu kamen dann noch hardwarespezifische Dinge. Die meisten Systeme hatten den Bildschirmspeicher im Adressraum, der weitere 2 bis 4 KByte belegte. Real konnte ein CP/M Rechner mit reinem Textbildschirm zwischen 52 und 54 KByte von 64 KByte adressierbarem Speicher freihaben.

Das waren über drei Virtel des gesamten Speichers und damals enorm viel. Neben Rechnern die CP/M von der Diskette booteten, gab es auch Rechner mit einem BASIC Interpreter, bei denen war dieser zugleich das Betriebssystem und diese hatten viel weniger Speicher frei. Beim populären C-64 waren es 38 KByte, beim Amstrad CPC 42,6 KByte. Der Unterschied von 10 bis 20 KByte erscheint heute gering, machte in der Praxis aber viel aus, denn viele Anwendungen konnten Daten (Texte, Datenbanken, Spreadsheets) bearbeiten, die größer als der Arbeitsspeicher waren, konnten im Speicher aber nur einen kleinen Teil unterbringen und wenn der verfügbare Speicher voll wurde, dann wurde dieser Teil auf die Diskette ausgelagert und das dauerte. Zudem waren diese Programme so compiliert, das sie auch auf kleineren Systemen liefen also Rechnern mit weniger als 64 KByte Speicher. Nutzen mehr Arbeitsspeicher aber dann für die Daten.

Als mit der Version 3.0 noch Bankswitching eingeführt wurde, konnten BIOS und BDOS in eine andere Bank verschoben werden und dann konnte man 61 bis 63 KByte der 64 KByte nutzen. Das waren über 90 Prozent des physikalisch ansprechbaren Speichers!

Aufbau des Dateisystems

Die wichtigste Eigenschaft von CP/M war die Verwaltung von Disketten. Es war der zentrale Punkt eines Betriebssystems und steckte so auch bei anderen Betriebssystemen im Namen wie PC-DOS oder QDOS. Das „D“ steht dabei für „Disk“.

Im Dateisystem findet man die meisten Altlasten von CP/M. Es entstand zur Ansteuerung von 8 Zoll Floppydisklaufwerken, genauer gesagt dem Typ IBM 3740. Diese 8 Zoll (20,32 cm) Diskette hatte 73 Spuren, jede Spur bestand aus 26 Sektoren die jeweils 128 Bytes groß waren. Sie fasste also genau 242.944 Bytes oder 237,25 KByte. Mit der Version 2.0 unterstützte CP/M auch 5,25 und spätere Floppylaufwerke mit andern Formfaktoren. Die große Änderung war, das hier das Format nicht standardisiert war. Es gab zwei Schreibdichten, „einfache“ oder „doppelte“. Es gab zuerst Laufwerke mit 35 oder 40 Spuren, dann folgten welche mit 70 oder 80 Spuren. Dann gab es noch einen Unterschied in den Laufwerken: Ein Laufwerk konnte nur einen Schreib-/Lesekopf haben, dann musste man, um die Rückseite einer Diskette zu bespielen, diese manuell umdrehen oder es konnten beide Seiten simultan beschrieben werden, dann war diese eine Disk mit der doppelten Kapazität einer Seite.

Bis hierher liegen die Unterschiede in der Physik, also ein Laufwerk für 40 Spuren wird nie eine Diskette mit 80 Spuren lesen können. Dann hatte die Computerfirma aber die Freiheit zu bestimmen, wie eine Spur formatiert werden soll. Unformatiert fasste eine Spur immer 3.125 Bytes bei einfacher und 6.250 Bytes bei doppelter Schreibdichte. Es gab Sektoren mit 256 Bytes, am verbreitetsten waren 512 Bytes und einige Systeme hatten 1.024 Byte große Sektoren. Die Größe war abzuwägen. Zu jedem Sektor gab es auf der Disk Verwaltungsinformationen und nach jedem Sektor folgte eine unbeschriebene Zone um der Anwendung Zeit zu geben die Daten zu verarbeiten. Je mehr Sektoren man hatte, desto mehr Platz nahmen diese Bestandteile von der unformatierten Kapazität weg. Systeme mit 256 Byte Sektoren hatten typisch 13-16 Sektoren pro Spur (3,25-4 KByte), bei 512 Byte Spuren waren es acht oder neun Sektoren (4-4,5 KByte) und bei 1 KByte gingen 5 Sektoren auf eine Spur, also 5 Kbyte/Spur.

Der Nachteil war das man jeweils für das Schreiben und Lesen eines Sektors Speicher reservieren musste, bei 1 KByte großen Sektoren sind das 2 KByte, die vom nutzbaren Speicher abgingen, man erkaufte sich also mehr Kapazität auf der Diskette mit einem höheren Arbeitsspeicherverbrauch, der meiner Erfahrung nach immer knapper war als Platz auf der Floppy. Es gab daher nur wenige Systeme die 1 KByte große Sektoren nutzten. CP/M selbst machte diese Änderung nicht mit, das BDOS als Anwendungsschnittstelle arbeitete immer mit 128 Byte Sektoren wie sie beim ersten Laufwerk üblich waren. Das BIOS musste diese dann an passender Stelle in einen der größeren Sektoren umkopieren. Beim linearen Lesen machte dies wenig aus, doch wenn eine Anwendung auf die Sektoren nicht linear zugriff, musste jeweils ein größerer Sektor gelesen oder geschrieben werden, auch wenn sich nur ein Teil des Inhaltes änderte.

Auf diesen 128 Byte als logische Sektorgröße basierte auf der Verzeichniseintrag. In einem Feld wurde eingetragen wie viele 128 Byte Sektoren die Datei umfasste. Dabei war Schluss bei 128 Sektoren (80h). Das entsprach 16 KByte. Jede Datei die größer als 16 KByte war belegte so mehrere Verzeichniseinträge. Das war insofern ungeschickt, weil CP/M außer dem logischen Sektor, Record genannt, auch größere Verwaltungsinformationen auf BDOS Ebene kannte. Die wichtigste war der Block. Eine Datei belegte immer einen Block, selbst wenn sie nur 1 Byte lang war. Der Grund eine größere Einheit einzuführen war, dass CP/M intern eine Tabelle hatte, in der sie vermerkte, welcher Block auf der Diskette frei war. Sonst hätte bei jeder Schreiboperation das ganze Verzeichnis durchsucht werden müssen um zu sehen, wo auf der Diskette noch Platz frei war. Hätte diese Tabelle auf Records basiert so wäre sie unverhältnismäßig groß geworden. Die folgende Ausgabe gibt die logischen Verzeichnisparameter eines CP/M-Systems wieder:

C>stat dsk:

A: Drive Characteristics

7584: 128 Byte Record Capacity

948: Kilobyte Drive Capacity

256: 32 Byte Directory Entries

0: Checked Directory Entries

512: Records/ Extent

32: Records/ Block

32: Sectors/ Track

0: Reserved Tracks

C: Drive Characteristics

65536: 128 Byte Record Capacity

8192: Kilobyte Drive Capacity

768: 32 Byte Directory Entries

0: Checked Directory Entries

512: Records/ Extent

64: Records/ Block

4: Sectors/ Track

0: Reserved Tracks

Relevant für die Tabelle ist die Zeile mit „Record Capacvity“. Man sieht das (bei 128 Byte Sektoren) man bei einer typischen Diskette mit einer formatierten Kapazität von 160 bis 800 KByte mehrere Tausend Einträge hätte, bei einer Festplatte (hier: 8 MByte) erreicht diese Tabelle das Maximum mit 65536 Records, mehr kann CP/M nicht verwalten. Indem aber 32 bzw. 64 Records pro Block zusammengefasst wurden, wurde die Tabelle viel kleiner. Typische Blockgrößen waren:

Im BIOS gab es noch weitere Parameter, der physikalischen Formatierung, mit denen der Programmierer der das BDOS als Schnittstelle nutzte nichts zu tun hatte. Sie steckten in einem Definitionsblock, sodass sie austauschbar waren. Bei meinem Amstrad CPC gab es z.B. drei Diskettenformate – das IBM Format für den Datenaustausch, das CP/M-Format und das Datenformat. Bei letzterem entfielen die Spuren auf denen CP/M untergebracht war. Als ich dann noch eine Floppy eines Fremdherstellers kaufte, kannte CP/M nach einer Anpassung auch dessen Format, obwohl dieses Laufwerk 720 anstatt maximal 180 KByte pro Diskette nutzte,

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.

Die BDOS Funktionen

Die Kommunikation mit dem BDOS erfolgte mit dem Aufruf einer bestimmten Adresse (5). Als Übergabeparameter gab es immer die Funktionsnummer im C-Register. Daten, die an BDOS übergeben werden – im unteren Beispiel die Adresse eines auszugebenden Strings – werden im DE-Registerpaar als Adresse übergeben, Rückgabewerte nach Verlassen der Funktion stehen im HL-Registerpaar. Das folgende Beispiel ist das Hello-World Programm das nur diesen Text ausgibt. Es ist nur 25 Bytes lang, wobei es noch wenn ich aus Didaktischen Gründen nicht das Programmende durch einen Warmstart ausgelöst hätte, sondern nur einen Restart 0 nochmals 4 Bytes kürzer sein könnte. Der Quelltext (auf dem PC geschrieben) ist dieser:

tpastart equ 100h ; Definition TPA Start

bdos equ 5 ; Definition BDOS Einsprungpunkt

conout equ 9 ; Funktion 9 zum Ausgeben eines Strings auf dem Bildschirm

wstart equ 0 ; Laedt BDOS vom der Platte und beendet Programm

org tpastart

mvi c,conout ; Funktion muss im C Register sein

lxi d,helloworld ; Ausgabestring im DE Register

call bdos ; Ausgabe

mvi c,wstart

call bdos ; Programmende (ein RST 0 hätte es auch getan)

helloworld: db 'Hallo Welt!$' ; Zeichenkette terminiert mit Dollarzeichen

end

Der Prozess der Erzeugung eines ausführbaren Programms ist etwas lang. Zuerst habe ich den Quelltext vom PC auf das CP/M System übertragen, dann mit ASM übersetzt wobei eine .HEX Datei entsteht. Der Befehl LOAD lädt dieses an die Startadresse und konvertiert es in eine .com Datei die man dann ausführen kann:

A>pcget bdos.asm

Get a File from a host using XMODEM or XMODEM-1K on ASCI 1

+++Note - Old file has been deleted+++

Waiting for block # 07

Transfer complete

A>asm bdos

CP/M ASSEMBLER - VER 2.0

0119

000H USE FACTOR

END OF ASSEMBLY

A>load bdos

FIRST ADDRESS 0100

LAST ADDRESS 0118

BYTES READ 0019

RECORDS WRITTEN 01

A>bdos

Hallo Welt!

A>

Schon damals fragte ich mich, warum Gary Kildall das Dollarzeichen ($) als String-ende nahm. Eine Theorie die es gibt, ist das dies von seinen Erfahrungen mit DEC Großrechnern herrührte. Vieles von CP/M hat er vom Betriebssystem DECSystem-10 einer PDP-30 übernommen, so wie Laufwerksbuchstaben. Ich fand die Wahl für ein Betriebssystem, das zuerst einmal für US-Kunden gedacht war, nicht optimal. Drot kommt das Dollarzeichen dann doch oft in Texten vor. Idealerweise hätte man wohl ein nichtdruckbares Zeichen wie Nul (Code 0) oder End of File (Code 27) genommen. Für den Fall das es ein eintippbares Zeichen sein musste, wären mir andere selten genutzte eingefallen wie „@“, „^“ oder „`“ (Email wurde erst 10 Jahre nach CP/M eingeführt, sodass der Klammeraffe @ damals kaum genutzt wurde). Alle diese Zeichen kommen sowohl in Programmiersprachen, wie auch US-Texten kaum vor.

CP/M bekam mit jeder Version neues BDOS Funktionen, beim populären CP/M 2.2 waren es 41, wobei zwei aber gekennzeichnet waren mit „Nicht mehr verwenden“. Die meisten Funktionen hatten mit der Verwaltung von Dateien, Disketten und Verzeichnissen zu tun. Dazu gab es Funktionen für die logischen Geräte Bildschirm, Tastatur, Drucker, Leser und Stanzer.

Der Kommandointerpreter

Der CCP (Console Command Processor) war die Benutzerschnittstelle von CP/M. Er war immer 2048 Bytes lang (alle CP/M Programme hatten eine Länge von Vielfachem einer Page also 256 Bytes). Er verfügte über nur wenige eingebaute Befehle:

• Dir zeigt das Verzeichnis oder einzelne Dateien an

• Type Gibt den Inhalt einer Textdatei auf dem Bildschirm aus

• ERA löscht Dateien

• Ren benennt Dateien um

• User: wechselt den User-Bereich (siehe unten)

• Load Lädt eine Hex Datei in de Speicher und speichert sie als ausführbare com-Datei

• Save speichert einen Speicherauszug ab 100h in einer Datei

Man konnte nur das letzte Zeichen oder die ganze Zeile bei der Eingabe löschen, Cursorbewegungen in der Eingabezeile waren nicht möglich. Gab man einen Dateinamen ein, der nicht den obigen Befehlen entsprach, so suchte der CCP nach einer Datei mit der Endung .com und lud sie in den Speicher und startete sie. Danach konnte der CCP, der unter dem BDOS lag, überschrieben werden. Er wurde bei einem Warmstart (Laden des BDOS von der Diskette) automatisch wieder geladen. Das ergab 2 KByte mehr Speicher.

Der User Befehl

Eine Besonderheit von CP/M ist das User-Kommando. Es gab 16 User mit den Nummern 0 bis 15. Bei jeder Datei wurde gespeichert, welcher User sie anlegte. Warum dieses Konstrukt eingeführt wurde, ist mir ein Rätsel. Vielleicht ist es eines der Dinge die Gar Kildall übernahm – vieles an CP/M wurde von den Betriebssystemen von DEC für Großrechner abgeschaut. Ich dachte auch eine Zeitlang, der Befehl stammte aus MP/M – eine CP/M Version für mehrere Nutzer, aber die kam erst heraus, als es das User Kommando schon gab.

Bei einer großen Diskette können schon mal mehrere Hundert Dateien im Verzeichnis stehen. CP/M speichert zudem alles in Großbuchstaben, was das Lesen nicht erleichtert. Dann den Überblick zu behalten ist schwer. Das mag eine Erklärung für die User Bereiche gewesen sein. Aber man hatte das Konzept nicht richtig durchdacht, denn wenn man den User Bereich wechselte, sah man nicht nur die Dateien des aktuellen User Bereichs, nein, man konnte auch auf keine anderen Dateien in anderen User-Bereichen zugreifen. Wie aber kopiert man Dateien und Programme zwischen den Usern? Die Lösung war folgende:

a>PIP

*^C

A>User 1

A>Save 28 pip.com

Man startete das Programm PIP zum Kopieren von Dateien, das mit dem Parameter [Gnn] auch die Dateien von anderen Usern kopieren konnte, brach es ab, wechselte den User und speichere es – es war immer noch im Speicher - erneut ab. PIP existierte so zweimal einmal im User Bereich 0 und einmal in 1. Ich denke mit wenig mehr Aufwand hätte man es so machen können, das Dateien im Userbereich 0 immer von allen Usern ausgeführt werden können und ein Directory Befehl der auch Dateien eines anderen User-Bereichs anzeigt, wäre auch nicht schlecht gewesen

Geräte

Diskettenlaufwerke und Festplatten sprach man mit Buchstabe+Doppelpunkt an, also z.B. A:. Neben diesen 15 Laufwerken kannte CP/M aber auch noch andere Geräte (Devices) wobei es unterschied zwischen logischen und physikalischen Geräten. Ein logisches Gerät hatte eine feste Bezeichnung, aber der Benutzer konnte entscheiden, welches physikalische Gerät sich dahinter verbarg, das Geschah mit dem Programm STAT. Es gab vier logische Geräte: con: für die Konsole (Tastatur und Bildschirm), lst: für den Drucker und RDR: und PUN: für einen Papierstreifenleser/stanzer (Lesen/Schreiben getrennt) . Der Papierstreifenleser war nur in den Anfangszeiten von CP/M als Gerät vorhanden und wurden z.B. mit einer seriellen Schnittstelle verbunden.

Der Benutzer konnte dieses Systems der Ports, so hießen sie technisch, auf bis zu 16 ausweiten, so trennte CP/M 3.0 den Con: Port in zwei separate Ports für Eingabe und Ausgabe. Dazu war aber eine BIOS Anpassung nötig. Die meisten CP/M-Programme verwendeten daher nur die Standardports. Der Vorteil war, dass man so die physikalischen Ports den logischen Ports zuordnen konnte. Die Bildschirmausgabe eines Programms konnte auf den Drucker umgeleitet werden oder die Kommandoeingabe auf eine Batchdatei. Folgende physikalischen Geräte kannte CP/M:

In der Praxis war natürlich wichtig, welche Hardware verbaut war. PTR und PTP wurden, als Bezeichnung von der UR-CP/M Version übernommen, aber wenige Jahre später, als kein Papierstreifenleser/-stanzer mehr im Einsatz war, z.B. der seriellen Schnittstelle zugeordnet. Die User Definied Geräte erforderten eine BIOS-Anpassung. TTY war trotz des Namens immer die Tastatur des Computers. Mittels Stat dev: konnte man die Belegung anzeigen:

A>stat dev:

CON: is TTY:

RDR: is PTR:

PUN: is PTP:

LST: is LPT:

und so konnte man eine Belegung ändern:

A>stat con:=crt:

Vielfalt und riesige Programmauswahl

CP/M ermöglichte zwei Dinge. Es war zum einen ein Standard und zum anderen lies es dem Hersteller Freiheiten. Es war ein Standard, weil jedes Programm das auf eine Anfangsadresse von 100H compiliert oder assembliert ist und nur die BDOS oder BIOS Funktionen nutzt auf jedem Rechner bei dem CP/M läuft nutzbar ist.

Ein Newcomer im Computerbereich hat üblicherweise das Problem, das wenn er ein eigenes Betriebssystem einsetzt es dafür keine Software gibt, was sowohl für Käufer wie Softwareentwickler ein großes Manko ist. CP/M machte Programme austauschbar. Ein Redakteur der Zeitschrift ct’ schrieb, das Wordstar die Killerapplikation für CP/M war. Damit konnte man Texte schreiben, ähnlich wie später unter Word für DOS - es war schwerer zu bedienen, aber die meisten Funktionen hatte es schon.

Auf der anderen Seite machte CP/M kaum Hardwarevorschriften – eigentlich nur den Prozessor. Es lief auf jedem 8080, 8085 oder Z80 Prozessor (später würde man dies durch den HD64180, Z180 und EZ80 ergänzen). Als Extreme gab es Laptops mit CMOS-Stromspar CPUs und Rechner mit Z80B/C mit 6 bis 8 MHZ Takt. Es gab Rechner mit einfachem Textbildschirm, andere hatten auch die Fähigkeiten Schriftstile wie Fett oder Kursiv darzustellen. Mein Rechner setzte sogar einen Grafikbildschirm ein. Wie viele Zeilen der Bildschirm hatte, war egal, ebenso die Breite, nur 64 Zeichen mussten es mindestens sein. Ebenso konnte man ein 8 Zoll, 5,25, 3,5 oder 3 Zoll Laufwerk oder sogar eine Festplatte einsetzen. Anzahl der Sektoren, deren Größe, Spurzahl und Dichte waren variabel. Formatierte Kapazitäten von Disketten lagen den auch zwischen 90 und 800 KByte und es gab über 100 Diskettenformate.

Das war zu dieser Zeit einmalig. Wer einen Heimcomputer kaufte, konnte keine Software austauschen. Die Ataris, Apple II und Commodore VC20 / C64 hatten alle einen 65092 Prozessor, aber die Software des einen lief nicht auf dem anderen. Ja selbst innerhalb eines Herstellers waren Rechner inkompatibel, so lief auf einem C64 nicht BASIC-Programme seines Vorgängers VC20 ohne Anpassung, geschweige denn das man nicht den Quelltext, sondern wie bei CP/M das ausführbare Binärfile startet.

Nicht einmal UNIX das es damals gab und das entwickelt wurde damit es auf vielen Rechnerarchitekturen lief war soweit. Man konnte auf einem neuen Rechner Unix aus den Quellen übersetzen, musste es aber in der Regel anpassen.

CP/M 3.0 und nachfolgenden Versionen

Ein Betriebssystem muss der Hardware vorausgehen, das heißt im Idealfall existiert die neue Version des Betriebssystems, bevor die Hardware auf dem Markt ist. Das ist möglich, weil die Hersteller von Prozessoren und anderer Hardware an ihre Software-Lieferanten schon vorher technische Datenblätter und Handbücher abgeben, auch wenn die Hardware dann noch nicht physikalisch existiert, kann man Programme für sie erstellen und gegebenenfalls emulieren.

Was bei allen Programmen von Digital Research auffällig ist, ist die Versionen, nach der ersten Ausgabe meistens dem technischen Fortschritt hinterherhinkten. Von Firmengründer Gary Kildall ist bekannt das er sich mehr für neue Aufgaben und Herausforderungen interessierte, als für eine Weiterentwicklung eines bestehenden Produktes und für ihn auch nicht wichtig war, das man möglichst viel Geld mit der Cash-Cow – hier CP/M – verdiente. Das scheint sich auf die Mitarbeiter von Digital Research, die nach der Version 1 CP/M weiterentwickelten, sich durchgeschlagen zu haben.

CP/M 2.2 erschient 1979, zu einem Zeitpunkt als 64 Kbit RAMs auf dem Markt erschienen – CP/M erschien in der ersten Version, als 4 Kbit RAM üblich waren, man hätte also schon vorhersehen können, das es sehr bald Rechner mit mehr Speicher geben würde, als die 64 KByte die ein Prozessor direkt adressieren konnte. Trotzdem erscheint die Nachfolgeversion CP/M 3.0 welche diese Fähigkeit hat, erst Anfang 1983. Damals gab es dann schon Heimcomputer mit 64 KByte Speicher. Ebenso war die große Änderung bei CP/M 2.2 das es nicht nur 8 Zoll Diskettenlaufwerke im IBM Format, sondern auch die 5,25 Zoll Formate unterstützte. Diese waren aber schon seit drei Jahren auf dem Markt.

Genauso macht man sich bei Digital Research keine Gedanken ein neues Dateisystem einzuführen. Für Festplatten ist CP/M 2.2 nicht gut geeignet, da die Festplattengröße auf 8 MB begrenzt ist und es keine Unterverzeichnisse hatte, die schon bei großen Disketten wo man leicht 100 Dateien unterbringen konnte gut gewesen wären.

CP/M 3.0 hatte mehrere Verbesserungen. Der offensichtlichste war, dass es in einer gebankten und ungebankten Version verfügbar war. Beim Bank-Switching wird ein Teil des 64 KByte großen Adressraums ausgetauscht, bei CP/M 3.0 waren dies der letzte Teil wo CP/M residierte. Dort wurden nur einige Buffer für den Datenaustausch, Routinen um die Bank zu wechseln und Sprünge in die eigentlichen Routinen, eingefügt. Von 64 Kbyte Arbeitsspeicher blieben so zwischen 61 und 63 KByte übrig. Das war für viele Anwender schon Grund genug es einzusetzen, denn so vergrößerte sich der Bereich für die eigentlichen Anwendungsprogramme. Bei meinem Rechner von 38 auf 61 KByte. CP/M konnte nun auch einen Speicherbereich nutzen, um das Verzeichnis zwischenzuspeichern, das reduzierte die Zugriffe auf die Diskette deutlich.

Dem Grundproblem von CP/M – es gab eine Vielzahl von Hardwarekonfigurationen – wurde damit begegnet, dass es eine Schnittstelle für herstellereigene Erweiterungen gab, genannt RSX und GSX – Resident System eXtension und Graphical System Extension. RSX waren Erweiterungen des Systems, um spezielle Hardware zu unterstützen, die weiter als die BIOS Routinen ging. Druckertreiber konnten so erstellt werden. GSX war eine analoge Erweiterung, die es Anwendungsprogrammen ermöglichen sollte, eine Grafik auf einer Vielzahl von Plottern und Druckern auszugeben, ohne das das Anwendungsprogramm mit den Befehlen dieser Geräte hantieren musste. Beides sinnvolle Erweiterungen, doch sie kamen zu spät.

Die Kargheit des Systems wurde leicht verbessert. So wurden nun viele Befehle des CCP in ausführbare Dateien ausgelagert. Sie wurden nun auch leicht verbessert, so konnte man den Rename Befehl ohne Dateinamen aufrufen und er fragte diese ab. Erstmals konnte man den Programmen auch Parameter angeben, so bekam man mit Dir [Full] endlich auch mal alle Attribute und Dateilängen zu sehen.

Device, Set und Show ersetzen die umständliche Bedienung von Stat. Andere Programme erlaubten es erstmals eine Ersatztabelle für Bildschirmsteuerzeichen oder Tastaturcodes zu definieren.

Intern hatte man viel renoviert, so griffen nun alle Routinen auf die physikalischen Sektoren zurück und nicht in 128 Byte Schritten wie bei den früheren Versionen. Leider konnte man an den grundsätzlichen Strukturen nichts machen. So gab es nun die Möglichkeit das Datum und die Uhrzeit in eine Datei einzutragen, aber dies geschah intransparent und war nicht mit CP/M 2.2 kompatibel. Ebenso wurden Dateigrößen immer noch in 128 Byte Records und nicht bytegenau gemessen und Unterverzeichnisse gab es auch nicht. Dazu hätte man die Verzeichnisstruktur ändern müssen, aber damit auch die BDOS-Funktionen und damit müssten Programme umgeschrieben werden. Das wollte man nicht riskieren.

Seltsamerweise war die Suite aus Entwicklungsprogrammen - CP/M kam immer schon mit dem 8080 Assembler ASM, dem Debugger DDT und dem HEX-Dumper Dump ausgeliefert worden, was zu der Zeit schon bei MS-DOS nicht mehr der Fall war - noch erweitert worden. Es gab nun auch noch einen verbesserten Assembler RMAC, einen symbolischen Debugger SID und einen Linker den man brauchte wenn man Assembler mit höheren Programmiersprachen wie C mischte. Aber nach wie vor sprachen alle die Syntax den 8080 Prozessors der 1983 keine Marktbedeutung mehr hatte. Stattdessen steckte in fast allen CP/M Rechner der Z80 Prozessor der gegenüber dem Nachfolger von Intel 8085 leistungsfähiger und schneller war.

Hatte man mehr als etwa 96 KByte RAM, 32 KByte brauchte CP/M mit Buffern in der zweiten Bank, so bot CP/M 3.0 aber keine Möglichkeit mehr Speicher zu nutzen. Die meisten Rechner legten im zusätzlichen Speicher eine RAM-Disk an. In diese kopierte man beim Start alle Programme, arbeitete dann nur in der RAM Disk und bevor man den Rechner abschaltete, kopierte man die Daten auf eine Diskette zurück. Das erscheint ineffizient, aber da die meisten Programme sowieso mit Overlays arbeiteten, also ihr ganzer Programmcode nicht in den Speicher passte, war es egal ob dieser nun von einer RAM-Floppy geladen wurde oder direkt in einer direkt ansprechbaren Speicherbank saß, die Verzögerung war vernachlässigbar.

CP/M 3.0 war nun so groß, das es nicht mehr in Systemspuren passte und eine eigene Datei meistens „Cpm3.sys“ erzeugt wurde. Das Problem von CP/M 3.0 war, dass man zum einen zu spät kam – Softwarefirmen entwickeln für neue Hardware und als es Anfang 1983 erschien, war der IBM-PC schon über zwei Jahre auf dem Markt und es gab zahlreiche Nachbauten. Die Firmen modernisierten ihre Software nicht auf CP/M 3 und neue Software erschien kaum, noch weniger Software, welche die neuen Möglichkeiten von RSX und GSX nutze. Die Idee die karge UI zu verbessern, indem man nun Kommandos als .com Datei aus dem CCP auslagerte, führte dazu das diese zusätzlich Platz wegnahmen – anders als im CCP belegten sie ja immer ganze Blöcke auf der Diskette und es durch die bekannten Mängel schon zahlreiche Alternativen wie Xdir gab.

Die Hochzeit von CP/M war Anfang der Achtziger Jahre, es lief auf Millionen von PC, 1980 machten Einnahmen aus CP/M den Großteil der Einnahmen von Digital Research aus, mit einer Gewinnspanne von 57 Prozent! Praktisch jeder PC mit einem 8080 / 8085 oder Z80 Prozessor konnte es einsetzen, selbst Rechner bei denen die Hersteller ein eigenes DOS hatten, wie die TRS-80 Serie von Tandy. Microsoft machte den größten Teil seines Umsatzes vor PC-DOS mit dem verkauf einer Softcard, einer Erweiterungskarte für den Apple II, damit auch auf diesem CP/M lief.

Das ging auch nach Einführung des IBM PC noch einige Jahre so weiter. Der Grund war das diese 8086 Rechner mindestens doppelt so teuer wie ein CP/M Rechner hatten und weil das Betriebssystem und Code umfangreicher waren, musste man einen IBM-PC kompatiblen mit mindestens 128, besser 192 KByte Speicher ausstatten damit gleichwertige Programme liefen.

Aber „Kompatible“ PC kamen vermehrt auf den Markt, es begann ein Preiskampf der IBM-PC und kompatible Rechner rasch verbilligte. Speicher wurde immer billiger und ermöglichte unter MS-DOS/PC-DOS Anwendungen die komfortabler als CP/M-Programme waren. Trotzdem erschienen noch neue CP/M Rechner. Nun wurden viele Heimcomputer CP/M Fähig. Es wurde der CPC-Serie beigelegt, Commodores C128 hatte einen zusätzlichen Z80 Prozessor um CP/M laufen zu lassen. Die MSX-Serie hatte ein CP/M kompatibles Betriebssystem. Ein reines neues CP/M System war die PCW-Serie, in Deutschland als „Joyce“ verkauft. Alle diese Rechner wurden in Millionen Exemplaren verkauft.

CP/M-86 ist eng mit der Geschichte verknüpft wie IBM zu seinem PC-DOS kam. Die erste Version von MS-DOS war ein Plagiat von CP/M 2.2. IBM unterstützte Microsoft, indem es die Verkaufspreise sehr unterschiedlich setzte: PC-DOS kostete je nach Quelle 40 oder 60 Dolle, CP/M-86 dagegen 240. So war der Ausgang des Wettbewerbs klar. Ab Version 2 von MS-DOS kamen dann auch neue Funktionen hinzu. CP/M-86 wurde nicht weiter entwickelt, stattdessen konzentrierte sich Digital-Research auf MP/M eine Multi-User Umgebung und Betriebssysteme die MS-DOS kompatibel waren: DRI-DOS als Konkurrenzprodukt und Concurrent-DOS als Multiuser-System, aber MS-DOS kompatibel.

CP/M-68K für Prozessoren der MC68000 Serie fristete zuerst ein Stiefmütterchendasein. Diese Prozessoren waren so potent, das sie auch Unix als Betriebssystem nutzen konnten. Sie steckten so in den ersten Workstations von Sun und SGI. Firmen, die Personalcomputer mit diesen Prozessoren entwickelten, setzten auf eine grafische Oberfläche, wie beim Macintosh oder Amiga. CP/M-68K war aber noch textbasiert.

Die einzige Ausnahme war der Atari ST. Die Amiga Corporation, damals eine eigenständige Firma, hatte das Konzept des Amiga entwickelt und brauchte Geld das sie sich von Jack Tramiel, Atari-Besitzer liehen. Der hatte vor, das Konzept und die Firma zu übernehmen für den Atari ST. Commodore bekam davon Wind, kaufte die Firma auf und sie konnten so den Kredit zurückzahlen. Jack Tramiel war so ohne Betriebssystem und wandte sich an Digital Research. Die hatten neben CP//M auch eine Benutzeroberfläche namens GEM für den x86 Prozessor entwickelt und portieren diese auf den Atari ST, wo sie zusammen mit CP/M-68K das Betriebssystem bildete.

Heute gibt es – 40 Jahre nach CP/M 3.0 – wieder neue Rechner mit dem Betriebssystem. Der Grund ist die Retro/Vintage-Welle. Es gibt Bastler, die veröffentlichen Bausätze oder ganze Computer, die wie ein PC aus den frühen Achtzigern arbeiten. Dafür braucht man nicht viel. Nimmt man eine Z180 CPU, so hat man wichtige Peripheriebausteine an Bord. Benötigt wird mindestens eine SIO für die Serielle Schnittstelle, denn die Boards werden mit einem PC über USB verbunden, der zweckentfremdet als serielle Schnittstelle genutzt wird und auch den Strom liefert. Daneben braucht man meist nur drei weitere Bausteine: ein ROM in dem CP/M und meistens weitere Programme stecken und ein RAM sowie einen Duplexer, der abhängig von der Adresse zwischen RAM/ROM umschaltet.

CP/M ist als Quelltext veröffentlicht und freie Software. Ein Entwickler muss also nicht das ganze System neu programmieren, er muss nur das BIOS an die Nutzung des ROM (meist als Festplattenersatz) anpassen. Alle Bildschirmausgaben und Tastatureingaben werden vom PC verarbeitet und über eine serielle Schnittstelle geschickt, wofür man einen Treiber auf dem PC installieren muss und man benötigt ein Terminalprogramm.

Ich selbst habe als Mensch mit zwei Linken Händen zwei fertige Kits im Einsatz mit einem 33 MHz Z180 und einem 50 MHz eZ80. Wer sich dafür interessiert sollte nach „RC2014“ suchen. Bei Tindie gibt es etliche dieser Kits. Die gehen recht weit, man kann nicht nur einen einfachen Computer bauen, sondern einen der auch vollständig autonom ist und Farbgrafik wie frühere Heimcomputer hat. Der hier abgebildete AgonLight bietet zum Beispiel einen VGA-Anschluss, USB und man könnte auch noch eine Floppy Disk anbinden – wenn man eine mit den alten 40 poligen Pfostensteckern noch findet.

Wer nur mal CP/M Retrofeeling spüren will ohne zu löten, für den sind die Kits von Circle M. Systems etwas, wo auch meine beiden herkommen.

Sie werden sich aber teilweise umstellen müssen. Nach 48 Jahren kündigte Zilog das Produktionsende des Z80 Prozessors an. Meiner Ansicht nach hätte man noch das 40-jährige Jubiläum abwarten können, immerhin, er wurde 34 Jahre länger als der 8080 Prozessor, aus dem er hervorging, produziert.

Viele Kits basieren auf dem Z80, aber codekompatibel, wenn auch etwas teurer da leistungsfähiger ist sein bis heute produzierter Nachfolger Z180.

Links:

Kürzerer Artikel über die Geschichte und Technik von CP/M

Ausführlicher Artikel über die Entwicklungsgeschichte von CP/M.

Die wahre Geschichte wie IBM zu PC-DOS kam.

Inoffizielle CP/M Site mit Manuals und Software.

Artikel über CP/M bei Heise.de 

Artikel erstellt am 6.2.2025

Zum Thema Computer ist auch von mir ein Buch erschienen. "Computergeschichte(n)" beinhaltet, das was der Titel aussagt: einzelne Episoden aus der Frühzeit des PC. Es sind Episoden aus den Lebensläufen von Ed Roberts, Bill Gates, Steve Jobs, Stephen Wozniak, Gary Kildall, Adam Osborne, Jack Tramiel und Chuck Peddle und wie sie den PC schufen.

Das Buch wird abgerundet durch eine kurze Erklärung der Computertechnik vor dem PC, sowie einer Zusammenfassung was danach geschah, als die Claims abgesteckt waren. Ich habe versucht ein Buch zu schreiben, dass sie dahingehend von anderen Büchern abhebt, dass es nicht nur Geschichte erzählt sondern auch erklärt warum bestimmte Produkte erfolgreich waren, also auf die Technik eingeht.

Die 2014 erschienene zweite Auflage wurde aktualisiert und leicht erweitert. Die umfangreichste Änderung ist ein 60 Seiten starkes Kapitel über Seymour Cray und die von ihm entworfenen Supercomputer. Bedingt durch Preissenkungen bei Neuauflagen ist es mit 19,90 Euro trotz gestiegenem Umfang um 5 Euro billiger als die erste Auflage. Es ist auch als e-Book für 10,99 Euro erschienen.

Mehr über das Buch auf dieser eigenen Seite.

Hier geht's zur Gesamtübersicht meiner Bücher mit direkten Links zum BOD-Buchshop. Die Bücher sind aber auch direkt im Buchhandel bestellbar (da ich über sehr spezielle Themen schreibe, wird man sie wohl kaum in der Auslage finden) und sie sind natürlich in den gängigen Online-Plattformen wie Amazon, Libri, Buecher.de erhältlich.

Sitemap

Kontakt

Impressum / Datenschutz

Neues

Hier werben / advertisment here

Buchshop

Bücher vom Autor