| Z80 und |
| CP/M-Projekte |
| Ronald Daleske |
|
|
|
|
|
|
|
|
Nach dem Anfang der 1990er Jahre der erste CP/M Computer (CPD) nicht vollständig fertig gestellt wurde, sollte dies 2010 mit dem CPD2 vollendet werden. Das Ergebnis wird hier vorgestellt. Auf einer Universalleiterplatte wurde ein Z80 CP/M Computer aufgebaut, der alle Schnittstellen über USB/UART an eine PC leitet, auf dem ein Lazarus-Programm die Console und das Laufwerk vom PC aus bereitstellt. |
|
Inhaltsverzeichnis1. Etwa 20 Jahre nach CPD2. Das Konzept 3. Die Hardware 4. Die Software 5. Die CONSOLE - Anbindung des SBC an den PC 6. Probleme und Erfahrungen bei der Umsetzung |
Zitat von Ingo Kripahle
Quelle:
Ausgabe 12 des freien Magazins embedded projects Journal, Seite 20, Beitrag: Reif für den Hive? Download embedded-project Journal als PDF
Homepage des embedded projects Journals: Das embedded projects Journal
Homepage des HIVE-Projects: HIVE-Project
Auch hier war es ähnlich. Auf der Suche nach einem neuen Projekt kamen die alten Projekte ML und CPD im Bastelkeller zum Vorschein.
Die Idee, mit wenig Bauelementen ein relativ hardwareunabhängiges Betriebssystem (CP/M) zu implementieren war immer noch sehr verlockend. Inzwischen hatte sich die Technik weiterentwickelt. Es gab nun 128k SRAMs und 512k SRAMs für wenig Geld. Zusätzlich konnte auf einem gewissen Erfahrungsschatz in der Arbeit mit Mikrocontrollern zurück gegriffen werden.
Nach ein paar Gedanken zur möglichen Umsetzung und ein paar Recherchen im Internet, stand der Entschluss fest:
Übrigens ist das Angebot an Informationen rund um die Z80 und CP/M im Internet fantastisch. Man kann tagelang unendlich viele Informationen zu diesen Themen mit Begeisterung im Internet sammeln.
Hier einige Anregungen zum Thema CP/M und SBC (Single Board Computer oder auch Einplatinencomputer) aus dem Internet:
Für das neue Projekt sollte die Hardware möglichst einfach sein und auf eine größere Universalleiterplatte passen (SBC).
CP/M definiert drei grobe Softwareschnittstellen:
Ausgabe eines Zeichen auf den Bildschirm (CONOUT)
Eingabe eines Zeichens durch die Tastatur (CONIN)
Lesen und Schreiben von Blöcken auf Diskette oder Festplatte (READ, WRITE und die dazugehörigen Hilfsfunktionen)
Um den Hardwareaufwand gering zu halten, sollten diese 3 Softwareschnittstellen über eine einzige Schnittstelle an den PC leiten. Für diese Schnittstelle zum PC bot sich RS232 an. Hardwareseitig war noch zu überlegen, ob die RS232 über eine SIO direkt im Z80 System realisiert werden sollte, oder ob sie mit einem ATMEGA8 realisieren wollte. Der ATMEGA8 und PASCAL ist hier eindeutig die bessere Variante, auch was die Flexibilität und den Preis betreffen.
Für die Kommunikation zwischen dem Z80-System (genauer der PIO) und dem ATMEGA8 wurde ein eigenes asychrones Protokoll entwickelt. Es sollte den Namen "Interface Transmission Protokoll - ITP" erhalten. Die wichtigsten Anforderungen waren:
das ITP sollte ein sehr einfaches asynchrones Protokoll sein
es musste sowohl unter Z80 wie auch unter ATMEGA8 (Assembler und PASCAL) einfach zu implementieren sein
jedes System bedient die Anforderungen so schnell wie möglich und wartet so lange, bis die Gegenseite fertig ist (Polling)
asynchrone Arbeitsweise und Polling ermöglichen eine einfache Umsetzung ohne Interrupts
Festlegung der grundsätzlichen Datenrichtung der Übertragung durch den Server (CPD2).
Bestätigung der Datenrichtung durch den Client.
Auf der Serverseite heisst dieser Anschluss SDEN und auf der Clientseite CDEN. Der jeweilige Sender der Daten (je nach Übertragungsmodus) gibt mit diesem Signal die Freigabe zum Lesen der Daten.
Bestätigung der Datenübernahme durch den Empfänger. Nach dieser Bestätigung kann ein neuer Sendezyklus beginnen.
Eigentlich sollten für den CPD2 EPROMs als ROM genutzt werden. Vor 20 Jahren war das beim Projekt ML schliesslich eine gute Lösung. Außerdem lagen in der Bastelschachtel noch 3 Stück herum.
EPROMs müssen aber mit UV-A-Licht gelöscht werden. Ein Löschgerät war nicht mehr verfügbar und der Kauf eines EPROM-Löschgerätes wurde auf Grund des recht hohen Kaufpreises von über 50 EUR verworfen.. Löschen mit UV-Geräten zum Bräunen klappt nicht, da die neuen Geräte nur sehr wenig UV-A Strahlen enthalten. Auch das Löschen mit Halogenlampen hatte nicht geklappt (EPROMs werden sehr heiß, werden aber nicht gelöscht).
Somit fiel die Entscheidung - dem Trend der Zeit folgend - auf einen FLASH-Speicher. Genauer für den AM29F040 von AMD (4 Megabit (524,288 x 8-Bit) CMOS 5.0 Volt-only, Sector Erase Flash Memory). Im Nachhinein kann man sagen, dass dies ein sehr interessanter Schaltkreis ist. Es hat nur den einen kleinen Nachteil, dass es seine Hochzeit schon vor vielen Jahren hatte und nun nur noch recht schwer zu bekommen ist.
Aber auch dieser FLASH-Speicher muss programmiert werden. Für den Anfang wurde schnell aus einem POLLIN-Board und einem alten IC-Sockel ein Programmiergerät zusammengebastelt.
Nach den ersten sauberen Tests wurde dann eine C-Control-Board (C-Control Projectboard PRO 32 von www.conrad.de) um einen 32 pooligen Nullkraftsockel erweitert (siehe auch FLASH-Prommer).
3.1 Schaltpläne für CPD2
3.2 Leiterplatte und Verdrahtung
4. Die SoftwareDer CPD2 startet wie jeder CP/M und Z80 Computer von der Adresse 0000H. Dort muss zum Startzeitpunkt ein Programmspeicher vorhanden sein, damit die CPU den Programmcode von dort aus laden kann. Das übernimmt hier dr FLASH-EPROM. Nach dem Reset wird in den unteren Adressen bis 7FFFH der FLASH-EPROM eingeblendet. Über 8000H ist immer der RAM ansprechbar. Wie bei vielen CP/M BIOS-Versionen wird das BIOS nach der Initialisierung der Hardware in den oberen RAM (hier ab F000H) geladen und gestartet. So arbeiteten die ersten Versionen. Da aber nach jeder Änderung des BIOS der FLASH-EPROM neu gebrannt werden musste, wurde eine flexiblere Lösung gesucht. Bei den modernen PCs wird das BIOS auch nicht immer neu gebrannt, wenn es eine neue Betriebssystemversion gibt. Nach diesem Vorbild wurden die weiteren Versionen folgendermassen umgesetzt.
Das hört sich alles erst einmal unheimlich kompliziert an, macht das System aber sehr flexibel. Ist das Lade-BIOS erst einmal stabil lauffähig, so braucht man kein EPROM mehr zu brennen. Das Laden des Haupt-BIOS von der Console dauert nur etwa 3 Sekunden. Die ersten 32 K auf dem FLASH-EPROM werden wie folgt genutzt:
Das BIOS kann somit in der Warmstart-Routine das CCP und das BDOS sehr schnell neu laden. Auf der rechten Seite ist die Speicheraufteilung zu sehen. Die BIOS-Größe von 4K habe ich bei allen folgenden Projekten beibehalten. Dabei ist genug Platz für Experimente im BIOS und außerdem bleibt trotzdem genug TPA für die CP/M-Programme (über 48 KB wenn das CCP überschrieben wird). 4.1 EEPROM-FloppyDa auf dem FLASH-EEPROM noch sehr viel Platz ist, wird er zusätzlich noch als EEPROM-Floppy (ohne Schreibmöglichkeit) genutzt. Die EEPROM-Floppy beginnt nach dem ersten 32K-Block ab EEPROM-Adresse 8000H. Die Umschaltung der oberen Adressen (A15..A18) wird durch PIO-Ports vorgenommen. 4.2 Quelltexte für CPD2-BIOS
4.2 Quelltexte für ATMEGA8Das Programm für den ATMEGA8 wurde mit der kostenlosen Version des AVRco Pascal-Compilers der Firma E-LAB Computers (http://www.e-lab.de/) erstellt, die ich auch schon in anderen Projekten genutzt hatte.
|
 |
Ein wichtiger Bestandteil des Projektes CPD2 ist das Consolenprogramm in LAZARUS. Über die serielle Schnittstelle werden die CP/M-Schnittstellen CONIN, CONOUT und READ/WRITE an den PC weiter gereicht und umgesetzt.
Wie oben bereits beschrieben kann das aktuelle BIOS (als COM-Datei) eingelesen und an das CPD2-Board übertragen werden. Während des Starts des Programms werden alle CP/M Dateien aus dem Verzeichnis "CPM_DIR_IN" in ein Diskettenimage eingelesen und als CP/M-Laufwerk angeboten. Als Image-Formate können derzeit 3 verschiedene Formate aus CP/M-Emulatoren ausgewählt werden.
Nach dem Schliessen des Programms werden alle Dateien des Images in das Verzeichnis "CPM_DIR_OUT" exportiert. So können geänderte Dateien gesichert werden.
Das Programm mit Quelltext wird unter CONSOLE im Bereich "Programmier-Projekte Lazarus / Free Pascal" beschrieben.
Eigentlich ist die gewählte Universalleiterplatte etwas groß dimensioniert. Zu Beginn eines Projektes ist der endgültige Platzbedarf nicht immer genau absehbar. Außerdem ist es hilfreich, wenn man zukünfige Erweiterungen auf dem Board mit unterbringen kann.
 |
 |
 |
Sehr hilfreich ist die Erstellung kleiner Zettel mit der Pinbelegung der Schaltkreise, wie es auch bei CP/M on breadboard gezeigt wurde. Diese Zettel werden während der Verdrahtung auf die Fassungen geklebt. Das erleichtert die Verdrahtung wesentlich. Für die Erstellung kann man jedes beliebige Vektorzeichenprogramm nutzen, das in der Lage ist massstabsgerechte Zeichnungen zu erstellen (z.B. COREL-Draw™ Version 9).
Beispiel füe eine Beschriftung für ICs:
IC_Beschriftung.cdr
Bei der Verdrahtung mit farbiger Litze ist es für die Fehlersuche sehr hilfreich, wenn man für die unterschiedlichen Bussysteme definierte Farben verwendet. Daher wurde eine spezielle Farbtabelle für die Verdrahtung entwickelt, an die ich mich bei allen CP/M und Mikrocontroller-Projekten (soweit wie möglich) gehalten habe.
Bild |
Farbe |
Leitungen |
 |
Rot |
+5V |
 |
Schwarz |
Masse |
 |
Orange |
Adressen |
 |
Grün |
Daten |
 |
Braun |
M1, Reset |
 |
Blau |
MREQ, IORQ, BUSRQ |
 |
Weiss |
RD, OE, RXD, TXD, Halt, IEI, IEO |
 |
Grau |
WR, CE, RAMSEL, SPI (MOSI, MISCO, SCK) |
 |
Gelb |
Takt, STP-Daten |
 |
Lila |
INT, STP-Control, WAIT, NMI |
Es empfiehlt sich beim Aufbau der Schaltung schrittweise vorzugehen. Zuerst werden die Masseleitungen aller Schaltkreise angeschlossen. Danach folgt die Spannungsversorgung. Nun wird die CPU mit den wichtigsten Anschlüssen (Quarzgenerator) aufgebaut. Danach folgen der EEPROM-Flash und eine PIO mit LED. Sind diese drei Schaltkreise miteinander verbunden kann schon der erste Test mit einer LED durchgeführt werden. Erst wenn die LED ordentlich blinkt, sollte man an die Verdrahtung des RAMs gehen und diesen testen. Das ist auch für die Motivation der relativ langen Verdrahtungsphase wichtig.
Testprogramme zum schrittweisen Test der Hardware:
Testprogramme.zip
Welches ist die beste Schnittstelle vom ATMEGA8 zum PC?. Auch hier habe ich viel experimentiert. Noch vor ein paar Jahren hatten alle alten PCs eine serielle Schnittstelle. Mit einem MAX232 und ein paar Widerständen und Kondensatoren kann man schnell über die RS232 eine Verbindung zum PC herstellen. Das läuft auch sehr gut. Nachteilig ist der relativ grosse Stecker, die lästige Pegelwandlung (auf beiden Seiten) und das nicht mehr vorhanden sein von seriellen Schnittstellen bei neuen PCs und Notebooks.
Der zweiter Versuch war V-USB (Virtual USB port for AVR© microcontrollers). Eigentlich eine einfache und tolle Sache, mit einem ATMEGA8 einen virtuellen USB-Port zu schaffen. Das hat auch funktioniert, aber die maximale Baudrate von 38800 Baud ist für die Übertragung von Dateien auf den CPD2 viel zu langsam, so dass ich diese Lösung nicht lange genutzt habe.
Die dritte Lösung war die Conrad Adapterplatine USB zu RS232 (im Bild Links/Mitte). Vorteil dieser Lösung: die notwendigen USB-Anschlüsse sind an jedem PC verfügbar. Ein weiterer unschlagbarer Vorteil ist die Nutzung der 5V Spannung von USB-Adapter für die Stromversorgung der gesammte Schaltung. Man muss nun nur noch das USB-Kabel anschliessen und der komplette CP/M-Computer ist betriebsbereit (separate Spannungsversorgung ist nicht mehr notwendig). Wenn man sich erst einmal an diese Arbeitsweise gewöhnt hat, möchte man diesen Komfort nicht mehr missen (vor allem, wenn das Projekt ein paar Monate nicht genutzt wird). Ein weiterer Vorteil dieser Lösung ist, dass auf dem Adapter ein CP210x von Silicon Laboratories, Inc. verwendet wird. Die Treiber für diesen IC sind für alle üblichen Betriebssysteme verfügbar und laufen sehr stabil (ich hatte bisher damit noch keine Probleme). Das war beim V-USB leider nicht immer so (kompletter Absturz meines Servers beim Anschluss eines V-USB-Gerätes).
Nach mehreren Versuchen habe ich die Übertragungsrate mit 128000 Baud festgelegt. Ist sie geringer, dauert die Übertragung der Diskettensektoren sehr lange. Bei Übertragungsraten über 128000 Baud traten plötzlich sehr viele Fehler in der Übertragung auf.
Trotz aller Sorgfalt, kommt es auch bei erfahrenen Bastlern zu Fehlern. Wichtig ist nicht, ob man Fehler macht oder nicht, sondern wie man an die Fehler behebt. Bei diesem Projekt hatte sich eine kalte Lötstelle eingeschlichen, die bewirkte, dass es bei den Tests zu Unregelmäßigkeiten kam (die Tests laufen zeitweise sauber, dann wieder nicht). Notfalls muss man sich sehr viele Testprogramme schreiben und versuchen den Fehler logisch immer mehr einzukreisen. Das hat schon ein paar Tage gedauert. Wichtig: nicht entmutigen lassen.
Sehr wichtig ist auch, dass alle wichtigen Eingänge /NMI, /INT, /BUSRQ usw. einen definierten Pegel (10-100 KOhm gegen 5V) haben. Sonst arbeitet die CPU ständig Interrupts ab, oder stellt den BUS über /BUSRQ zur Verfügung oder andere nicht geplante Sachen.
| Startseite | Impressum | Warenzeichen |
