Wer behauptet, Programme des 8085 würden auch auf der Z80-CPU laufen, der hat das entweder noch nicht probiert oder einfach Glück gehabt.
Ganz kompatibel sind die beiden jedenfalls nicht.
Nachdem mein Rechner mit seiner 8085-CPU mehrere Jahre ohne große Störungen treu gedient hatte, kam ich auf die Idee, eine Z80-Platine zu entwickeln.
Die Z80-CPU hat ja bekanntlich den Vorteil eines erheblich größeren Befehlsvorrates, sie ist schneller, viele Programme werden mit Z80-Befehlsvorrat angeboten, und die Programmierung ist eleganter.
Die Hardware-Probleme beim Umstellen waren gering, und das Monitorprogramm lief, wie erwartet, mit allen Funktionen einwandfrei.
Beim Starten des Basic-Interpreters kam der Frust:
Unsinnige Fehlermeldungen und fehlerhafte Variablenverwaltung waren die Folge der Umstellung.
Ein Hardwarefehler?
Nein!
Bei der Software-Fehlersuche zeigte sich, daß aus einem vorerst unerklärlichen Grund das Parity-Flag zuweilen anders gesetzt war als beim 8085.
Alle Computer-Freaks beteuerten mir jedoch, daß 8085 und Z80 kompatibel sind.
Die Literatur gibt auch kaum Hinweise.
Im Buch „Programmierung des Z80" von Dr. Rodnay Zaks findet man jedoch einen Abschnitt, der die Verhältnisse klärt.
Dr. Zaks schreibt hierzu sinngemäß:
Das Parity-Flag wird bei bestimmten Befehlen in Abhängigkeit der Parität des Akkuinhaltes gesetzt.
Beim 8080 und 8085 wird das Parity-Flag nur als ein solches verwendet.
Beim Z80 ist die zweite Funktion die eines Überlauf-Flags, das gesetzt wird, wenn bei einer Subtraktion oder Addition das Vorzeichen verändert wurde.
Weiterhin wird das Parity-Flag bei Blocktransfer-Befehlen (
LDD, LDDR, LDI, LDIR) und den Suchbefehlen (
CPD, CPDR, CPI, CPIR) verwendet, um das B-Register zu kontrollieren.
Letztlich wird das Parity-Flag bei den Befehlen
LD A,I und
LD A,R vom Interrupt-Enable-Flipflop beeinflußt.
Nicht alles, was hier geschrieben steht, ist für die Kompatibilität zwischen 8085 und Z80 von Bedeutung, aber man sieht, daß es Unterschiede gibt, die für ein 8080- oder 8085-Programm „tödlich" sein könnten.
Immer dann, wenn Parity-Abfragen durchgeführt werden, können durch die aufgeführten Unterschiede Fehler im Programmablauf entstehen.
Es kommen hier die Befehle
CPO, CPE, RPE, RPO, JPE, JPO (8085) in Frage, und zwar dann, wenn ein Befehl vorausgeht, der beim Z80 das Parity-Flag als Überlauf-Flag benutzt.
Bei meinem Basic-Interpreter führte dieser Unterschied an zwei Stellen zu Programmfehlern.
Zur Verdeutlichung seien diese Programmteile einmal dargestellt:
RAL
SBB A
Je nach der Carry-Bedingung durch den Rotate-Befehl
RAL wird der Akkuinhalt nach
SBB A 00H oder FFH.
Die Parity-Bedingung ist in beiden Fällen gleich.
Das Parity-Flag wird jedoch beim Z80 bei 00H auf Null gesetzt und bei FFH auf 1, da hier eine Vorzeichenänderung aufgetreten ist.
Im weiteren Verlauf folgt ein bedingter Sprung
JPO, der jetzt beim Z80 eine andere Bedingung vorfindet als beim 8080 oder 8085.
Das Programm stürzt ab.
Der zweite Teil lautet:
LDA M
ADC A
RPE
Bei der dargestellten Befehlsfolge tritt nach
ADC A im Parity-Flag ebenfalls eine Bedingung auf, die nicht von der Parität des Akkuinhaltes beeinflußt wird, sondern von einem eventuellen Vorzeichenwechsel bei der Addition.
Das paritätsbedingte Return wird u.U. falsch ausgeführt und führt zu Programmfehlern.
Am einfachsten begegnet man diesem Fehler, indem man den Akkuinhalt mit
ANI FF verknüpft.
Dieser Befehl ändert den Akkuinhalt nicht, setzt aber das Parity-Flag entsprechend der Parität des Akkuinhaltes.
Leider wird aber bei einer Verknüpfung mit
ANI das Carry-Flag zurückgesetzt.
Kommt es nun im weiteren Programmverlauf zu einer Carry-Abfrage, können immer noch Fehler auftreten.
Folgendes Unterprogramm schafft hier Abhilfe:
JC CARRY
ANI FF
RET
CARRY ANI FF
STC
RET
Hierbei wird durch
STC der aktuelle Wert der Carry-Flags wiederhergestellt, und alle Flags entsprechen den Bedingungen des 8080.