The Z80 is "binary compatible" with the 8080. It adds a bunch of new instructions, but places them all in unused (well, undocumented) opcodes.
yes .. err, no, they placed them on redundant opcodes.
For example the whole 00-xxx-000 group were
NOP instructions for the 8080, while Zilog only left
NOP, while the others became jumps (and
EX). Likewise the 'alternate' opcodes
FDh that all produced
CALL on the 8080 became prefix bytes (*1).
Does this mean that if I disassemble an 8080 program (which doesn't use any undocumented opcodes, naturally) using a Z80 disassembler, will the result be correct 8080 assembly code? Or are there any hidden gotchas?
No hidden gotchas, but then again, it will come out as Z80 assembly, not 8080, as the Zilog changed the words of the assembly language. For example:
Opcodes 8080 Z80 (8008 )
79 MOV A,C LD A,C (C2 LAC )
02 STAX B LD (BC),A (-- )
16 MVI D,12h LD D,12h (1E LDI 12h)
3A 34 12 LDA 1234h LD A,(1234h) (-- )
ED 4B 34 12 -- LD BC,(1234h) (-- )
So essentially it will produce an all Z80 Assembly source code (Z80 column), but certain operations are not used in 8080 sections.
The reason I'm asking is because Supersoft Associates' CPU Diagnostics II program from 1981 contains both 8080 and Z80 code; it checks which CPU it's running on in the beginning, jumping to CPU-specific testing code. Therefore I obviously need to disassemble it using a Z80 disassembler. Will the 8080 tests be valid 8080 assembly code?
It must. After all, on binary level all 8080 is as well valid Z80. Only on Assembler the above mentioned different 'spelling' is visible - think of it like Mancunian English vs. Texan English.
*1 - I understand that the A zeroing opcodes (
XRA A) haven't been touched, because some used them. Likewise, to a lesser extend, the 'flaging' NOPs
ORA A and
CMP A (*2). But I always found it strange why they didn't touch the MOV-NOPs (*2) which would have brought 7 additional opcodes.
They would relief plenty room from the 8080 code set. Especially since the prefixes take away much of the advantage of many of the 16 bit opcodes.
The only reason I can think of is that Mr.Faggin somehow knew (*4) that the 8085 would as well not touch any of these opcodes, so the level of incompatibility between Z80 and 8080 would be about the same as Intel introduced with the 8085
*2 - All of them do trigger flags, so while the result is forseable, it may be used on purpose to prepare some flag.
*3 - 49h/49h/52h/etc. are
MOV C,C ... they move data between the same register, thus making it effectively as well NOPs since MOVs don't trigger any flags.
*4 - Since both (Z80, 8085) were launched in March 1976, it's not very likely that this was without early knowledge of the changes Intel did.