Sinclair ZX80 / ZX81 / Z88 Forums

Given an address in memory, it's trivial to disassemble the instruction at that address, know it's length in bytes, then move onto the next instruction.

However, how would one know what the immediately previous instruction was before that address? It would be easy if all instructions were the same length, but considering z80 has 1, 2, 3, 4... byte instructions, how can you "work backwards" disassembling from an address?

I guess you could start with a 1 byte instruction, then attempt to disassemble a two byte, then a three byte etc until you get an instruction that doesn't make sense - essentially just getting the largest chunk that is a valid z80 instruction, but it won't be right all the time...

Mike (Who does occasionally do some work on OE - honest )

Can't be done. You could get many instructions that make sense.

F'r instance is that a5 immediately behind PC an AND L, the end of an AND IXL, or the operand of ADD A,NN?

Are you thinking history? Reverse execution?

Whatever you need the past for I think there would have to be - like Andy suggested - a rolling journal of addresses that the z80 has visited.

Hi Mike,

I've been Thinking about this since you posted it, and i think your gonna need a super Ai Comp to do this, Whilst it's possible sometimes for a human to work out what's what we would be looking at the bigger picture structure of the overall code ect and trying to choose the best fit instructions but for a computer program to be able to do this is like asking the impossible unless of course your russian and a whizz at programming Ai Nets.

Regards Andy

Hi guys,

I half tried this when hacking through the ASZMIC ROM and the extra beeper code on the 8300. However, it's _very_ difficult (on occasion impossible).

I suspect that a ZX81 could not do it itself (not enough RAM!) but a PC may give you a fairly good guess.

The biggest problem is that it is near impossible to understand a system from just a binary dump. Some examples of "extreme pain" are things like the RST handlers in the ZX81 ROM. Those for HSYNC don't actually return, they clear up the return address left on the stack and then jump elsewhere (start of line) therefore any "AI" disassembler used to disassemble that code would either have to know that ahead of time (a priori) and deduce this from the code (a posteriori). This is made further evil cos' the 81 conditionally jumps or returns from it's interrupt handler.

Other evils are things like IY offsets. How do you _know_ that LD A,(IY+$06) is the same as LD A,($4006)? You only know that if you can guarantee the value in IY at a given point in the program... Then there are stack operations - these are WELL evil (esp if your app does evil things like move the SP into ROM - there are reasons to do this). I think the trick is to find all entry points to a function (jump or call destination) and try to infer register contents from that.

REALLY evil instructions are things like "RST cc, $38" the conditional reset instruction. I decoded that one separately (it jumps to its own relative offset if the condition is true - the offset is -1 which happens to be RST $38 - thus you get a conditional reset operation).

However, given enough compute time/space I reckon it's entirely possible. Something like a Z80 emulator with (maybe) a HW description (interrupt driven coding can, probably, not be inferred from the code) and a DB/Prolog style interrogation system may work (probably some fuzzy logic involved too in that you can't "know" all routes until all are traced which would result is disparate rules in the analysis time DB.

Incidentally Mike I've got code for a disassembler that I think accurately disassembles any given Z80 op code (including undocs, multiple prefix instructions etc). If it's any use I'll try and dig it out (SOOoooo much has changed since Bill's 81 forums you wouldn't believe it).

*Too many may be's and probably's in here!!

It seems archive.org has squirreled away the last version I uploaded... What a useful website!

http://web.archive.org/web/200503130158 ... 0.cpp.html