Programmier-Projekte
Lazarus / Free Pascal
von Ronald Daleske

Homepage Übersicht vorherige Seite nächste Seite Kontakt Impressum Warenzeichen

EMUZ80 - Z80 / CP/M - Emulator

EMUZ80 ist ein CP/M-Emulator für den Z80 Prozessor. Das Programm liest den Ordner "CPM_LW_A" als CP/M-Laufwerk A: ein und startet CP/M in der Version 2.2. So können ohne weitere Installation schnell CP/M Programme genutzt oder getestet werden. Für Entwickler bietet der Emulator einen Einzelschrittbetrieb, einen Unterbrechungspunkt (Breakpoint), Anzeige der CPU-Register, Anzeige des Z80 Arbeitsspeichers (64 K RAM), Anzeige des jeweiligen Befehls im Quelltext (TRACE) soweit vorhanden. Der Monitor unterstützt die wichtigsten VT100 Steuerzeichen um Turbo Pascal 3.01 von Borland anzeigen und editieren zu können.

Inhaltsverzeichnis

1. Motivation und Zielsetzung
2. Bedienung des Z80-Emulators
3. Zusatzfunktionen des Z80-Emulators
4. Beispiel für Einzelschrittbetrieb mit Unterbrechungspunkten (TRACE)
5. Downloads
6. Lizenz
7. Hinweis zu den Compilereinstellungen

1. Motivation und Zielsetzung

Ein Emulator bildet die Hardware einen anderen Prozessor auf einem Computer (meist einem PC) programmtechnisch nach (der Prozessor wird softwaremäßig emuliert). So kann man theoretisch jeden Prozessor und jedes Betriebssystem nachbilden. Ein wichtiger Nachteil dabei ist, dass dies sehr zeitaufwendig ist.

In den 1970er und 1980er Jahren arbeiteten die damaligen CP/M Computer mit Taktfrequenzen von etwa 1 bis 4 MHz. Heutige PCs (nach rund 35 Jahren) arbeiten üblicherweise mit 2 bis 3 GHz. Das bedeutet, dass ein Emulator etwa 1000 Takte Zeit hat um einen "ein Byte Befehl" abzuarbeiten. Das ist sehr viel Zeit und so kann man den Emulator auch in einer Hochsprache schreiben und das Ergebnis ist in der Regel immer noch scheller, als der originale CP/M Computer.

Warum einen weiteren Z80-Emulator?

Im Internet kann man erstaunlich viele Z80- und CP/M-Emulatoren finden. Aber leider erfüllten viele Emulatoren meine persönlichen Vorgaben nicht. Wie schon gesagt, es sind an vielen Stellen

1. stabiler Betrieb

Hier fallen alle Testversionen, fehlerhafte Versionen und Alpha-Phasen heraus, auch wenn der Emulator sonst einen interssanten Eindruck gemacht hat.

2. kein DOS-Programm

Als sich in den 1980er Jahren das DOS-Betriebssystem gegenüber dem CP/M durchgesetzt hatte und auch die PCs immer schneller wurden, wurden viele Z80- und CP/M-Emulatoren für das Betriebssystem DOS entwickelt. Diese DOS-Programme konnten bis Windows XP recht zuverlässig genutzt werden. Aber ab Windows 7 gibt es mehr und mehr Probleme, so dass zukünftig DOS-Programme verstärkt nur noch in virtuellen Maschinen oder Emulatoren genutzt werden können. Aus diesem Grund ist es dann sinvoller den CP/M-Emulator nicht in einem DOS-Emulator laufen zu lassen, sondern gleich unter dem genutzten Betriebssystem Windows.

3. nur Freeware oder Open-Source

Erstaunlich viele DOS-Programme sind nicht Freeware oder Open-Source (oft Shareware) und können somit nicht uneingeschränkt rechtlich genutzt und verbreitet werden. Auch dies war ein wichtiges Kriterium.

4. möglichst kein reines Linux-Programm

Wiederum auffallend viele freie Programme (Freeware und Open-Source) werden für das Betriebssystem Linux entworfen. Der Vorteil liegt auf der Hand, wenn Du Deine Programme frei nutzen möchtest, dann verwende doch auch gleich ein freies Betriebssystem. Diese Denkweise ist sehr sympatisch, vor Allem wenn man die vielen Gängeleien berücksichtigt, die Microsoft seinen Kunden und Usern zumutet.

Auf der anderen Seite muss man akzeptieren, dass die meisten Programme unter Windows laufen. Nach meiner Erfahrung kennt sich so gut wie niemand in beiden Systemwelten (Windows und Linux) zu 100% aus. Daher vertrete ich die Meinung, dass auch die Programmierer eines Emulators ihr Programm immer nur primär für ein Betriebssystem entwickeln. Später werden manchmal einige Programme auch für andere Betriebssysteme bereitgestellt. Das ist dann aber immer das Zweitsystem und fast immer mit einigen Einschränkungen verbunden.


Anforderungen an den Emulator:


Unterstützung undokumentierter Befehle

Ein oft diskutiertes Thema in den Z80-Foren ist die Frage, ob ein Z80-Emulator auch die undokumentierten Befehlen unterstützen soll. Zum Hintergrund: der originale Z80-Prozessor der Firma ZILOG besteht (wie alle anderen digitale Schaltkreise) aus vielen logischen Gattern. Diese Gatter sorgen für die Umsetzung der geforderten und offiziellen Befehlstabelle (Instruction Set) des Z80-Prozessors.

Z80 CPU User Manual - Zilog

Nun haben in den 1980er Jahren einige Leute (durch einfaches Probieren) herausgefunden, dass - bedingt durch die Z80 Gatterstrukturen - auch andere Befehls-Hexacode ausgeführt werden und dann irgendwelche Aktionen durchführen. Die ganze Sache hat aber einige Nachteile:

Einige Tests haben bei mir ergeben, dass die "undokumentierten Befehle" in der Software, die ich derzeit nutze, nicht benötigt werden.


Wichtiger Hinweis:

Kann der Emulator einen Befehl nicht auflösen, so wird im Protokollfenster (links unten) sofort eine Fehlermeldung (mit der Adresse des Befehls) angezeigt.


Mein Fazit: Undokumentierte Befehle werden derzeit in diesem Z80-Emulator nicht unterstützt.


2. Bedienung des Z80-Emulators

Das Programm benötigt keine Installation. Nach dem Entpacken der ZIP-Datei muss lediglich die Datei

EMUZ80.EXE

gestartet werden.



Die Bedienung des Programms ist genau so einfach, wie seine Installation. Alle Dateien, die sich im Unterordner "CPM_LW_A" befinden, werden beim Start des Emulators als CP/M-Laufwerk A: eingelesen. Mit dem Emulator wird auch das CP/M automatisch gestartet (und zwar im Modus "Start Auto o. Protokoll", das heißt im Dauerbetrieb).

Ab der Version 1.05 ist zusätzlich das Laufwerk B: verfügbar. Ausserdem wurde die Laufwerkskapazität von etwa 1,4 MB auf etwa 4 MB erhöht.

Wird der Emulator mit "Schliessen" beendet, werden alle Dateien in den CP/M-Laufwerken A: und B: mit den Dateien im Ordner "CPM_LW_A" und "CPM_LW_B" verglichen. Sollte sich etwas verändert haben (neue Datei, Datei verändert, Datei gelöscht), so werden die geänderten Dateien in diesen Ordnern aktualisiert.

Innerhalb des schwarzen Rahmens ("CP/M Monitor by Ronald Daleske") wird ein CP/M Monitor mit VT100 ESC-Sequenzen nachgebildet. Die Monitoremulation wurde für "Turbo Pascal" mit VT100 Terminal optimiert.

Unterhalb des Monitorfensters werden die Laufwerke A: und B: mit ihrer Sektor-Belegung grafisch dargestellt. Dabei sind die roten Sektoren die CP/M Boot-Sektoren (hier aber nicht genutzt). Die blauen Sektoren stellen das Direktory dar und die grünen Sektoren sind die mit Daten und Programmen belegten Sektoren auf diesem Laufwerk. Die nicht genutzten Sektoren werden weiß dargestellt.


3. Zusatzfunktionen des Z80-Emulators


Die Zusatzfunktionen können in einem neuen Fenster durch Drücken des Button "Einstellungen anzeigen" genutzt werden.

Wie schon im Teil "Bedienung" beschrieben, startet der Emulator im Dauerbetrieb ( Modus "Start Auto o. Protokoll"). Um den Dauerbetieb zu beenden muss der Button "Stop Auto" gedrückt werden. Nun befindet sich der Emulator im Einzelschrittbetrieb. Durch Drücken auf den Button "einen Befehl abarbeiten" wird nun genau ein Befehl abgearbeitet (danach wird wieder gewartet). Der abgearbeitete Befehl wird im Protokollfenster angezeigt.

Wird im laufenden CP/M-Betrieb einfach auf den Einzelschrittbetrieb umgeschaltet, so befindet sich das BIOS meist in der Warteschleife für die Tastatureingabe (gut zu sehen mit "Trace anzeigen").


Anzeige zusätzlicher Emulator-Informationen

Anzeige der CPU-Register

Anzeige des RAM-Speichers

Anzeige des PRN-Quelltextes (TRACE)

Die drei in der Tabelle aufgeführte Button aktivieren Fenster, die zusätzliche Statusmeldungen und Informationen des Emulators im Einzelschrittbetrieb anzeigen.


4. Beispiel für Einzelschrittbetrieb mit Unterbrechungspunkten (TRACE)

Im Folgenden soll an einem Beispiel der Einzelschrittbetrieb und die Arbeit mit Unterbrechungspunkten erläutert werden.

Nach dem Drücken des Buttons "TRACE" wird das Trace-Fenster geöffnet. Im Beispiel soll die schrittweise Abarbeitung des Assemblerprogramms "HW.MAC" gezeigt werden.

Dazu wird das CP/M-Programm "HW.MAC" gestartet und dessen Abarbeitung bei 100H (Startadesse aller CP/M-Programme) gestoppt.

Zum Setzen des Unterbrechungspunktes wird mit der Maus eine Adresse in der linken Leiste des TRACE-Fensters angeklickt (die erkannten Adressen werden mit einem kleinen spitzen Dreieck gekennzeichnet).

Der gesetzte Unterbrechungspunkt wird mit einem kleinen roten Kreis gekennzeichnet.

Gleichzeitig zur Registrierung des Unterbrechungspunktes im TRACE-Fenster wird der Haken "Unterbrechungspunkt aktiv" im Fenster "Einstellungen anzeigen" (links unten) gesetzt. Ausserdem wird die gesetzte Adresse im Fenster "Einstellungen anzeigen" aktiviert (im Beispiel 100H).

Anschließend wird das Test-Programm im Monitorfenster des CP/M-Emulators (links oben) durch Eingabe von HW <Enter> gestartet (das Fenster muss vorher durch kurzes Anklicken mit der linken Maustaste den Fokus erhalten).

Wenn alles nach Plan läuft, stoppt der Emulator an der Stelle 100H. Das Stoppen wird angezeigt, indem im TRACE-Fenster die aktuelle Zeile blau hinterlegt wird. Im Fenster "Einstellungen anzeigen" wird im Protokollfenster die Anzeige "Abarbeitung bei Adresse: 100H gestoppt" ausgegeben und der Button "Stop Auto" aktiviert (das heißt, dass der Emulator gestoppt wurde).

Durch Drücken des Buttons "ein Befehl abarbeiten" wird das Programm schrittweise durchlaufen. Jede Adresse, die in der PRN-Datei erkannt wurde wird dann auch (blau hinterlegt) angezeigt.

Wird nun immer weiter "ein Befehl abarbeiten" angeklickt, wird in diesem Beispiel ab Adresse 105H in das BDOS verzweigt. Da der BDOS-Quelltext hinterlegt ist, kann mann wirklich jeden Programmpunkt verfolgen und Buchstabe für Buchstabe die Ausgabe von "Hallo Welt!!" verfolgen.

Wem das zu aufwendig ist, der setzt einfach einen neuen Haltepunkt auf die Adresse 108H. Um den Emulator vom Einzelschrittbetrieb wieder zu starten wird der Button "Start Auto o. Protokoll" gedrückt. Ist die Adresse 108H erreicht stoppt der Emulator wieder.

Im Monitorfenster wurde der Text "Hallo Welt!!" ausgegeben. Das Programm wird normalerweise mit einem Warmstart (Sprung auf Adresse 0000H) beendet.

Durch Drücken des Buttons "Start Auto o. Protokoll" ist der CP/M-Prompt wieder aktiv.

Damit ist der Test beendet. Um bem Start des nächsten Programms nicht wieder in den Einzelschrittmodus zu gehen, sollte der Haken aus dem Eingabefeld "Unterbrechungspunkt aktiv" entfernt werden.


Einlesen der PRN-Dateien

Nach dem Drücken des Buttons "TRACE" werden die PRN-Quelltexte aus dem Ordner "Trace" in alphabetischer Reihenfolge eingelesen. Dann wir aus den hexadezimalen Zeileninformationen eine Adress-Tabelle generiert. Bei jedem Einzelschritt wird die entsprechende Adresse gesucht und - wenn möglich - wird diese dann im TRACE-Fenster angezeigt.

Beispielhaft sind bei der Version 1.05 im "Trace" Ordner folgende PRN-Dateien hinterlegt:

Es können aber auch eigene PRN-Dateien hier abgelegt werden, die dann im Einzelschrittbetrieb genutzt werden können (z.B. eigene CP/M Programme ab 0100H).

Hinweis: Die PRN-Dateien werden in alphabetischer reihenfolge eingelesen. Um die Einlesereihenfolge zu steuern, empfiehlt es sich, eine Zahl vor den Namen zu setzen (siehe Namen der PRN-Dateien).


5. Downloads (Version 1.05 vom 12.12.2015)

Emulator mit CP/M Beispielprogrammen: EMUZ80_V1.05.ZIP

Emulator mit allen Quelltexten: EMUZ80_Quelltexte_V1.05.zip

Link zur Version 1.0 : EMUZ80_V1.0


6. Lizenz

Creative Commons Lizenzvertrag
Diese(s) Werk bzw. Inhalt von Ronald Daleske steht unter einer Creative Commons Namensnennung-Nicht-kommerziell 3.0 Deutschland Lizenz.


keine Mängelgewähr

DIESE SOFTWARE WIRD VOM URHEBERRECHTSINHABER "OHNE MÄNGELGEWÄHR" BEREITGESTELLT. ALLE AUSDRÜCKLICHEN ODER STILLSCHWEIGENDEN GEWÄHRLEISTUNGEN, EINSCHLIESSLICH DER STILLSCHWEIGENDEN GEWÄHRLEISTUNG DER MARKTGÄNGIGKEIT UND EIGNUNG FÜR EINEN BESTIMMTEN ZWECK (JEDOCH NICHT DARAUF BESCHRÄNKT), WERDEN AUSGESCHLOSSEN. DER URHEBERRECHTSINHABER IST IN KEINEM FALL UND NACH KEINER HAFTUNGSTHEORIE (SEI ES AUF VERTRAGSBASIS, AUF DER BASIS STRENGER HAFTUNG ODER UNERLAUBTER HANDLUNGEN, EINSCHLIESSLICH FAHRLÄSSIGKEIT) FÜR BELIEBIGE VERURSACHTE DIREKTE, INDIREKTE, ZUFÄLLIGE, BESONDERE, EXEMPLARISCHE SCHÄDEN ODER FOLGESCHÄDEN (EINSCHLIESSLICH, JEDOCH NICHT BESCHRÄNKT AUF BESCHAFFUNG VON ERSATZPRODUKTEN ODER -LEISTUNGEN, NUTZUNGSAUSFALL, DATEN- UND GEWINNVERLUST ODER GESCHÄFTSAUSFALL) HAFTBAR, DIE AUFGRUND DER VERWENDUNG DIESER SOFTWARE ENTSTEHEN KÖNNEN. DIES GILT AUCH, WENN AUF DIE MÖGLICHKEIT SOLCHER SCHÄDEN HINGEWIESEN WURDE.


THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.


7. Hinweis zu den Compilereinstellungen

Lazarus / Free Pascal erzeugt mit den Grundeinstellungen des Compilers recht grosse EXE-Dateien. Das liegt an den vielen Debug-Informationen, die in das Programm eingebettet werden. Damit die Zieldatei recht klein wird, habe ich unter:

Projekt Projekteinstellungen Compilereinstellungen Linken

die "Debugger-Informationen für GDB erzeugen (Verlangsamt das Kompilieren)" abgeschaltet.

Compilereinstellungen ohne Debugger (kleine EXE-Datei)

Compilereinstellungen mit Debugger (grosse EXE-Datei)

Für das Debuggen des Programms muss diese Schalter wieder aktiviert werden (auch "Zeilennummern in Laufzeitfehler-Backtraces anzeigen (-gl)").



Homepage Übersicht vorherige Seite nächste Seite Kontakt Impressum Warenzeichen