PrivatSuperMicro80
Translate from German into English (some links may be mistranslated, then turn back to the original site): 
Nachdem dieses Selbstbauprojekt jahrzehntelang im Keller gelagert war, habe ich es vor Kurzem wiederentdeckt. Es machte mich schon neugierig, ob dieser Z80-Rechner noch lauffähig ist. Anfang der 80-er Jahre habe ich so manche Stunde damit verbracht, dieses Projekt zu realisieren. Damals habe ich durch "learning by doing" so richtig verstanden, wie ein Computer mit seiner Hard- und Software funktioniert. Wenn man es nicht selber gemacht hat, hat man es auch nicht wirklich verstanden...
Eingeschaltet und: geht !!! Nach über fünfundzwanzig Jahren zeigt sich die Hardware sehr willig; selbst die alten Disketten sind ohne Ausnahme lesbar. Auf Anhieb. Dann im Gedächtnis gekramt, wie das Ding zu bedienen ist. Nach einigen Stunden ist erstaunlich Vieles wieder präsent. Wie war noch dieser oder jener Befehl? Zum Glück habe ich in meinen alten Schätzen auch noch das passende Buch gefunden: "Jürgen Plate - Betriebssystem CP/M". Und: "Klaus Kämpf - CP/M 2.2 Assembler Listing". Da steht alles drin, was zu "CP/M 2.2" zu sagen ist.
1983 hatte ich begonnen, diesen Rechner zu konstruieren und zu bauen. Das war die Zeit der "Apple II"-Computer, der ersten "CP/M"-Systeme wie "Osborne", oder die Computer von Tandy, z.B. "TRS-80". Solch einen Tandy-Nachbau habe ich mir seinerzeit besorgt ("Komtek 1") und damit meine ersten Erfahrungen in Sachen Microcomputer - so hießen die Dinger damals - gemacht. Nein, stimmt nicht: davor hatte ich einen "Sinclair ZX81", aber der zählt nicht...
Der "Komtek 1" erwies sich relativ schnell als zu klein und nicht erweiterungsfähig. Andere Systeme waren mir zu teuer; also war Selbermachen angesagt. Die Basis sollte TRS-80-kompatibel sein. Der Grund dafür war, dass ich einige Software dafür ergaunert hatte. Die lief unter dem Diskettenbetriebssystem "NEWDOS80" (Festplatten waren unerschwinglich, meine erste Festplatte habe ich erst Jahre später (1990) gekauft: 42 MByte Kapatität, Preis: 800 DM !!).
Den "Komtek 1" hatte ich extern um 2x 5¼-Zoll-Disketten erweitert (einseitig, 40 Spuren, einfache Dichte, Brutto-Kapazität 100 KByte, Preis: 400 DM pro Stück !!)
Im Netz habe ich einige Unterlagen zum Komtek 1 gefunden.
Das ganze sollte modular und möglichst einfach erweiterbar werden. Da lag die Bauweise in 19-Zoll-Einschubtechnik nahe. Schaltbilder vom "TRS-80", bzw. vom "Video-Genie" - ein anderer Nachbau des "TRS-80" - lagen mir vor. Ich habe alles an Hardware-Beschreibungen studiert, derer ich habhaft werden konnte. Dann habe ich mich an diese Hardware-Beschreibungen angelehnt - nachdem ich verstanden hatte, wie das alles zusammenspielt - und verändert nachgebaut: auf Europaplatinen und in "Fädeltechnik" verkabelt. Die reinsten TTL-Gräber. Aber hochintegrierte Chips waren noch Mangelware.
Leider habe ich von den ersten Aufbauten keine Fotos mehr, ebensowenig von der ersten Diskettenstation. Ca. 1988 habe ich einen günstig erworbenen Monitorteilesatz (Bildröhre + Platine, ohne Netzteil) samt zweier neuer Diskettenlaufwerke (doppelseitig, 80 Spuren, doppelte Dichte, Brutto-Kapazität 800 KByte) zusammen in ein Gehäuse verbaut.
Fig. 1: Gesamtansicht
Fig. 2: Das 19-Zollgehäuse
Fig. 3: Die Rück- und Unterseite
Fig. 4: Auf der Rückseite sind die VG-Buchsenleisten untergebracht ...
Fig. 5: ... und das Bussystem ist von Hand mittels dünner lackisolierter Kupferdrähte erstellt
Fig. 6: Monitor mit 2 Floppies
Fig. 7: Auf der Rückseite: die Anschlüsse und zwei Steckdosen, über die von zentraler Stelle (Schalter vorne) alle Peripherie gleichzeitig versorgt und gemeinsam ein- und ausgeschaltet werden kann
Fig. 8: Das Innere. Blick auf die Monitor-Elektronik
Fig. 9: Blick auf die Diskettenlaufwerke. Die ALU-Folie schirmt die Laufwerke vor den Hochspannungsfeldern des Zeilentrafos ab
Fig. 10: Unten ist die CPU-Baugruppe mittels Adapterkarte im Betrieb zu sehen
Fig. 11: Bei 5,5 MHz Taktfrequenz der Z80B-CPU ist solch ein Adapter gerade noch funktionsfähig. Ohne ihn - und somit ohne die Messmöglichkeiten im Betrieb - hätte ich den Rechner wohl nie zum Laufen gebracht...
Fig. 12: Der Apapter von der Vorderseite...
Fig. 13: ...und der Rückseite. Wahnsinns-Induktivitäten - geht trotzdem!
Fig. 14: Die CPU-Baugruppe: Takterzeugung, 64 KByte Arbeitsspeicher (!!!), RESET-Logik, Bustreiber. Die CPU läuft in 2 Geschwindigkeiten: langsam (kompatibel zum "TRS-80") und schnell (5,5 MHz)
Fig. 15: Rückseite in Fädeltechnik
Bei der Fädeltechnik werden dünne lackisolierte Kupferdrähte über Plastikkämme geführt. Beim Anlöten verbrennt die Isolationsschicht. Die Kupferbahnen habe ich in der Regel lediglich zum Heranführen der Stromversorgung an die ICs verwendet. Die Fädeltechnik ist für Null-Serien ideal - bei genügend geringer Taktfrequenz versteht sich. Da ist jederzeit eine Änderung / Erweiterung möglich. Das war auch gut so: später habe ich da noch einiges verändert. Platz für Reserve-ICs habe ich berücksichtigt
Fig. 16: Video-Logik-Baugruppe
Die Video-Baugruppe erzeugt ein BAS-Signal (Bild, Austastung, Synchronsignale). Es wird ein Videocontroller-Chip (GPU: HD6845) verwendet, der sich um das Auslesen des Bildschirmspeichers und das Timing kümmert. Es sind 2 Charaktergeneratoren (EPROMS) vorhanden: einmal für den ASCII-Satz und ein weiterer für den deutschen Zeichensatz plus Pseudo-Grafik-Symbole. Zusätzlich gibt es 2 Bildschirmspeicher (jeweils 2 KByte für 16 Zeilen à 64 Zeichen im "TRS-80"-Modus bzw. 25 Zeilen à 80 Zeichen im "CP/M"-Modus, der später dazu kam)
Ich habe damals immer behauptet, das sei die schnellste Grafikkarte, die ich kenne. Üblicherweise durfte die CPU nur bei Bild- oder Zeilenwechseln schreibend auf den Bildschirmspeicher zugreifen. Das sollte Fehler (Flackern) verhindern, sorgte aber bei den ziemlich schmalen Zeitfenstern dafür, dass die CPU fast immer mit Warten auf diese Wechsel beschäftigt und die Ausgabe somit lähmend langsam war.
Ich habe dadurch Abhilfe geschaffen, dass ich zwei hintereinander liegende Bildschirmspeicher vorgesehen habe. Damit kann die CPU immer - ohne Warteschleifen - schreibend auf den ersten und die GPU immer lesend auf den zweiten Speicher zugreifen. Im Normalfall (ohne CPU-Zugriff) wird mit dem Auslesezyklus der GPU der erste (CPU-) Speicher gelesen und der zweite (GPU-) Speicher damit beschrieben. Greift die CPU schreibend auf den ersten Speicher zu, wird sofort die Verbindung der beiden Speicher unterbrochen und die GPU liest nun aus dem 2. Speicher, während die CPU mit voller Geschwindigkeit den ersten Speicher beschreiben kann. Ist der Schreibzugriff beendet, so kehrt das System zum Normalzustand zurück und der nun aktualisierte Inhalt des ersten Speichers wird in den zweiten kopiert und damit sichtbar. Das Timing ist ziemlich kritisch und hat so manche Stunde Probieren gekostet. Hat sich aber gelohnt!
Fig. 17: Rückseite der Video-Karte
Fig. 18: EPROM-Bank
Die EPROM-Bank mit 12,5 KByte BASIC-Interpreter, Bootloader, Adresslogik. Im "TRS-80"-Modus liegen in den unteren 16 KByte die EPROMS mit dem Betriebssystem incl. BASIC. Dort sind auch die Hardware-Adressen und der Adressraum des Bildschirmspeichers hineingemappt. Die darüber liegenden 48 KByte RAM stehen für das Anwendungsprogramm und seinen Daten zur freien Verfügung. Die Lesezugriffe auf die EPROMS können nur relativ langsam erfolgen. Deshalb wird dieser Bereich in das (schnellere) RAM kopiert, die EPROM-Bänke danach abgeschaltet, der untere RAM-Bereich hineingemappt, schreibgeschützt und dann der hohe Systemtakt angelegt.
Den "CP/M 2.2"-Modus habe ich später nachgerüstet. In diesem Modus ist das Speicherlayout ganz anders: Bis auf die eingemappten Hardwareadressen hier ganz am oberen Ende des Adressraumes steht der volle RAM-Bereich ab 0000H zur Verfügung. Die Umschaltung zwischen den Modi wird durch Register gesteuert. Gebootet wird immer im "TRS-80"-Modus. Je nach geladenem Bootsektor wird dann das nötige Speicherlayout eingestellt und "NEWDOS80" oder "CP/M" nachgeladen.
Fig. 19: Rückseite der EPROM-Bank
Fig. 20: Der Diskettencontroller mit SAB2793A. Das HD-Diskettenformat war noch nicht erfunden
Fig. 21: Rückseite des Diskettencontrollers
Fig. 22: Tastatur-Interface. Man sieht deutlich, dass ich da die Reserve-IC-Plätze vergessen habe. Ansonsten: nix mit serieller Tastatur mit eigenem Controller. Hier scannt die CPU die Tastenmatrix
Fig. 23: Rückseite
Fig. 24: Centronics-Drucker-Port mit Beeper
Fig. 25: Rückseite
Fig. 26: RAM-Disk
Jahre später gab es von der Computer-Zeitschrift "mc" - die gibt es inzwischen längst nicht mehr - eine RAM-Disk als Bausatz. Kapazität: unglaubliche 1 MByte. War ziemlich teuer - deshalb habe ich zunächst nur den halben Speicher bestückt. Aber enorm schnell. Das BIOS bindet sie als Laufwerk "F" ein.
Eine PC-Sitzung sah dann so aus: Floppy einlegen, booten, die Programme, mit denen man arbeiten wollte - ggf. von einer 2. Diskette - auf die RAM-Disk kopieren und dann dort temporär arbeiten. Am Ende durfte das Zurückkopieren auf Floppy nicht vergessen werden... Programme wie "WordStar" - eine Textverarbeitung, die diesen Namen eigentlich nicht verdient hat - legten temporäre Dateien an und luden sog. Overlays nach (weil nicht alles an einem Stück in den Arbeitsspeicher passte). Auf Floppy ziemlich langsam, mit der RAM-Disk enorm schnell. Super!
Fig. 27: Rückseite. Tja, ohne Anpassungen lief nix
Fig. 28: Hochleistungsnetzteil, Ultra Low Noise
Fig. 29: Die Tastatur. War ziemlich teuer. Aber unkaputtbar
Fig. 30: Qualitativ hochwertige Tastensätze. Die Matrix ist von Hand verdrahtet
Fig. 31: Detailansicht Fädeltechnik, Teil der CPU-Platine
Fig. 32: CPU-Fassung von unten
Fig. 33: 5¼-Zoll-Diskettenlaufwerk der ersten Generation (100 KByte); die Ära der 8-Zoll-Laufwerke habe ich nicht mehr bewusst erlebt
Fig. 34: Gebaut für die Ewigkeit
Es folgen diverse Schaltungsunterlagen; alle von Hand mit Bleistift erstellt - teilweise auf Umweltpapier und nach über 25 Jahren nur noch schlecht lesbar. Unzählige Male verändert... Alle Schaltpläne gibt es für die jung gebliebenen Nostalgiker hier als Download (.pdf) verfügbar.
Fig. 35: Bus-Belegung
Fig. 36: Tastatur-"Controller"
Fig. 37: Schaltung der Platine in der Tastatur. Mit Tricks die Funktionstasten eingebunden
Fig. 38: Drucker-Port (Centronics) und Beeper ("Ctrl-G")
Fig. 39: CPU-Karte mit Arbeitsspeicher
Fig. 40: Adressdekodierung mit EPROM-Bänken
Fig. 41: Bildschirm-Karte
Fig. 42: Disketten-Controller
Fig. 42: RAM-Disk
Es folgen einige Impressionen in Form von Bildschirmfotos.
Fig. 43: So sieht es aus, wenn der Rechner ohne Diskette bootet, aus dem ROM in den BASIC-Interpreter. Beim Original gab es ein Kassetten-Interface, um Daten zu speichern. Das habe ich mir gespart. Richtig, 12 mal 12 ist 144
Fig. 44: Booten im TRS-Modus von Diskette
Fig. 45: Booten im "CP/M 2.2"-Modus
"CP/M" (Control Program for Microcomputer) wurde Anfang der Achtziger Jahre ziemlich populär. Quasi der Vorläufer von MS-DOS. Tatsächlich hat BillyBoy wieder ordentlich kopiert und als Seines ausgegeben. Viele DOS-Systemaufrufe erinnern verdammt stark an "CP/M".
Ein Freund hatte seinerzeit einen "MSX"-Computer (mit MSX wurde seinerzeit von einer Reihe von Firmen versucht, einen Standard für Heimcomputer zu etablieren), der mit "CP/M" lief. Von dem bekam ich damals das Betriebssystem. Dann gab es einen Fachartikel in der "mc", wo ein BIOS für einen "CP/M"-Rechner beschrieben wurde. Mit dem Autor des Artikels habe ich seinerzeit Kontakt aufgenommen und von ihm bekam ich das vollständige BIOS-Listing - in Papierform! und sehr rudimentär. Meine Aufgabe bestand dann darin, die bestehende Hardware so umzubauen, dass sie "CP/M" fähig wurde. Siehe dazu meine Anmerkungen weiter oben. Und dann musste das BIOS auf meine Hardware angepasst werden, und vor Allem: verbessert werden; das war nämlich ziemlich erbärmlich: z.B. wurde die Tastatur nicht im Interrupt abgefragt. Es gab nur ein Diskettenformat, dass zu nichts kompatibel war. Das wurde geändert. Mit "WordStar", "M80"-Macroassembler und "Link" hat sich der Rechner mit der Zeit selbst am Schopfe aus dem Sumpf gezogen. Heißt: ich habe das BIOS auf dem Zielrechner weiterentwickelt.
Da bei "CP/M" bis auf die Programmier-Schnittstelle nichts standardisiert war, kochte so ziemlich jeder Hersteller sein eigenes Süppchen: es gab unzählige Diskettenformate (verschiedene Anzahl der Sektoren pro Spur und Sektorlängen) und Bildschirmformate. Ich hatte seinerzeit einige Programme ergattert, die für einen Alphatronic P3 (Triumpf-Adler) gedacht waren. Damit ich diese Programme verwenden konnte, musste mein Rechner dieses Diskettenformat lesen können und den Bildschirm korrekt emulieren. Also: eine spezielle BIOS-Version musste her!
Fig. 46: "DIR"-Befehl: nix mit Datum und Größenangabe. Unterverzeichnisse gibt es auch nicht. Will man Genaueres wissen: "STAT"
Fig. 47: Kopiert wird mit "PIP"
Fig. 48: Da mein Rechner ein Unikat ist, gab es natürlich keinerlei Dienstprogramme. Hier das Formatierprogramm im SM80-Format (so etwas geht natürlich nur in Assembler)
Fig. 49: Damit wird die Systemspur kopiert und die Diskette bootfähig gemacht
Fig. 50: Patch-Programm zum gezielten Manipulieren des Betriebssystems. Das Programm ist das Ergebnis längerer Analysen des "CP/M"-Assembler-Listings (250 Seiten im Taschenbuchformat)
Fig. 51: Autostart à la CP/M
Fig. 52: Kann sich noch jemand an "Turbo-Pascal" erinnern? Hier ist die Version 3.0 für "CP/M" - der Vorläufer aller modernen IDEs
Fig. 53
Fig. 54
Fig. 55: Der Beginn des Formatierprogrammes in Assembler (ich habe den TP-Editor auch später in DOS-Zeiten noch jahrelang verwendet)
Fig. 56: Die Textverarbeitung "WordStar" - in der Alphatronic P3-Video-Emulation
Fig. 57: Selbstgebaute Systemprogramme
Fig. 58: Mit diesem Editor, einem Macroassembler und dem Linker habe ich das BIOS (weiter)entwickelt
Fig. 59
Fig. 60
Fig. 61: Der Versuch einer Benutzeroberfläche
Fig. 62: Alte Schätze, u.a. Turbo-Pascal 1.0, PLI, Multiplan, DBase II, Forth
Hoppla, da habe ich doch noch ein altes Dia gefunden. Meine erste Diskettenstation (Bildmitte) und mein erster Monitor - bernsteinfarben, das war damals topmodern:
Fig. 63: Der Monitor rechts ist ein "Zenith Data System ZVM-122". Ich habe ihn 1983 oder 1984 auf der HobbyTronic in Dortmund erstanden. Leider besitze ich ihn nicht mehr. Im Netz findet sich das Service-Manual.
[Update:]
Eigentlich hatte ich nicht vorgehabt, diesen Artikel irgendwann einmal zu ergänzen. Aber es hat sich ergeben, dass ich (in Corona-Zeiten) etwas Zeit hatte. Und mein alter Selbstbau-Rechner in der Ecke meines Bastelkellers guckte mich so komisch an.
Also aus dem Regal gewuchtet, entstaubt und angeschlossen. Und dann AEG: auspacken, einschalten, geht nicht. Schade! Fast alle LEDs leuchten, die LED für den hohen Takt bleibt aus. Normalerweise schaltet die sich nach 1 Sekunde ein, wenn gewisse Vorbereitungsarbeiten erledigt sind. Das kann doch nichts Schlimmes sein. Die üblichen Verdächtigen: Kondensatoren. Und tatsächlich hat ein Elko in der RESET-Logik das Zeitliche gesegnet. Austauschen. Geht!!
Inzwischen ist der Rechner 13 Jahre älter (ich leider auch...). Und er läuft immer noch - erstaunlich!
Also habe ich meine alten NewDos/80 und CP/M 2.2 Disketten gesichtet und gestaunt...
Im Netz habe ich ein Manual über das Betriebssystem NewDos/80 gefunden und sofort ausprobiert:
Fig. 64: Erst einmal eine Kopie der alten Diskette anfertigen. Die magnetischen Eigenschaften der alten Scheiben dürften inzwischen grenzwertig sein!
Fig. 65: Das Betriebssystem kennt ebenso wie CP/M keine Dateiattribute wie Datum und Zeit. Ordner werden nicht unterstützt.
Fig. 66: Damals war BASIC als Programmiersprache immer dabei!
Fig. 67: Überraschung: Charakter-Editor für den Zeichensatz des Grafikadapters. Seinerzeit von mir selbst geschrieben!
Fig. 68: Ich weiß noch, wie ich mühsam die Buchstaben gebastelt habe - in verschiedenen Größen (10 / 15 Zeilen hoch) und mit / ohne Umlaute, und Klötzchen für die Pseudo-Grafik...
Fig. 69: "Komfort"-Funktionen.
Fig. 70: Ha !
Ab hier einige meiner CP/M 2.2 - Programme (Turbo-Pascal 3.0):
Fig. 71: Hier eine äußerst rudimentäre Budget-Verwaltung mit Auswertungen.
Fig. 72: Mit Hilfstexten für den Anwender.
Die Eingabe der Daten erfolgt strukturiert mit dem eingebundenen Text-Editor "WordStar", mein Programm extrahiert und verdichtet. Für die weitere Bearbeitung lässt sich eine Vorlage (Maske) erstellen. Dann müssen nur noch die neuen Werte dazu geschrieben werden.
Fig. 73: Eine (selbst geschriebene) Zeitschaltuhr.
Für 8 Schaltausgänge. Es werden 8 analoge und 8 digitale Eingangskanäle abgefragt.
Fig. 74: Die Schaltprogramme können einfache oder ...
Fig. 75: ... mehrfache Bedingungen - über UND u. ODER verknüpft - enthalten.
Fig. 76: Direktes Schalten der Ausgänge.
Fig. 77: Editieren bestehender Schalt-Programme.
Hmm... da fällt mir spontan ein: wie habe ich seinerzeit sichergestellt, dass die Uhr auch korrekt läuft? Da gab es ja wohl Anforderungen an die Laufgenauigkeit. Das hat mich dann doch interessiert!
Also habe ich in den PASCAL-Quelltext des Uhrenprogrammes geschaut und dort Folgendes gefunden - und dann angefangen noch viel weiter zu recherchieren:
Dort gibt es eine Routine "interrupt". Diese wird nach 40 Aufrufen eine Variable "sekunde" um 1 erhöhen. Und so weiter für Minute, Stunde, Wochentag. Das muss es sein! Weiter unten wird vom Uhrenprogramm die Adresse dieser Routine "interrupt" eingetragen (ab mem [ $E600 + 51 ]).
Das sind genau die Speicherstellen, die ich in der BIOS-Sprungtabelle dazu passend für solche Fälle erweitert habe, mit Offset 51 ab Tabellenbeginn: "USER-INTERRUPT".
Es folgt ein Ausschnitt vom BIOS und die zugehörige Erweiterung (in rot):
Diese Speicherzellen gibt es offiziell nicht und nur bei mir. Vorbelegt sind sie mit "C9". Das ist der Opcode "RET" (springe zurück).
Hier hat das Programm also die Routine "interrupt" eingetragen mit dem Opcode "C3". Das ist der (unbedingte) Sprungbefehl zur Adresse, die unmittelbar folgt. Und bei Programmende auch wieder ausgetragen (dann steht da wieder "C9").
In der Interrupt-Routine des BIOS findet sich dazu:
Der rote Teil ist speziell für meinen USER-INTERRUPT und ruft die Uhrenroutine "interrupt" auf - wenn sie denn dort eingetragen ist.
Die BIOS-Routine "INTRPT" wird alle 25 ms per System-Interrupt "INT" aufgerufen (= 40 mal in der Sekunde). Dazu wird die INT-Leitung des Prozessors von der Logik im Floppy-Controller (!!) auf Masse gezogen (invertierende Logik). Die Zeitbasis dort besteht aus einem 16 MHz-Quarz und einer entsprechenden Teilerkette.
Es ist schon spannend, alles dieses nach Jahrzehnten wieder zu entdecken!
Fig. 78: Zum Schluss noch mein EPROM-Programmer. Die Hardware dazu kann ich leider nicht mehr finden.
Fig. 79: Mit eingebauten HEX-Editor.
Damit habe ich seinerzeit die EPROMS für das Betriebssystem und die Zeichensätze gebrannt.
Dann habe ich noch ein paar Schaltbilder gefunden (hier besser lesbar als PDF-Dokument):
Fig. 80: Das Schaltbild vom EPROM-Programmiergerät. Ich habe mich da an den Vorschlag aus der Zeitschrift "mc" angelehnt - mit Anpassungen (Datenbus-Treiber, Portadress-Dekoder). Rechts die Eigenschaften der damals gebräuchlichen EPROMS.
Fig. 81: Und vom Netzteil. Wie man sieht hat das etliche Entwicklungszyklen hinter sich...
(Wird diesmal bestimmt nicht fortgesetzt)
