Is disassembly via simulated execution or just memory reads? #18
Comments
|
A single-stepping disassebly is indeed a true view of what the processor is doing. Do check out another of my projects that might be of use. It's called the Z80 Decoder: You need a cheap USB logic analyzer (16 bits) and a 40-pin DIP clip. You connect the logic analyzer up to DATA, IORQ, MREQ, M1, RD, WR and CLK pins. You set it to take a sample on the rising edge of the CLK. Capture a dump from the logic analyzer. This can be millions of instructions. Feed that dump through the Z80 decoder and you get an output like this: |
|
That's a really interesting project, I will definitely take a look as I have all the hardware required. I like the BusMon project for a more direct approach after a passive investigation. If I add an AVR8 routine to the project I can single step, display the disassembly, and list the registers to make the same output as above. I am thinking of making the output dump and run a single step and log to a file. I can then load it in Ghidra and do some high-level analysis. Most of my projects are old test equipment from the 80's and as such are very over engineered, no documentation and fun to make do things it was never designed for! |
Is the Z80Decoder file just the capture file pulled from the sigrok project save file? |
|
I don't know anyything about the project save file. Originally I used sigrok-cli to generate a binary capture file: But for most logic analyzers, sigrok only supports asyncronous capture, and it's generally much better to use synchronous capture (on the rising edge of the Z80 Clock). What Logic Analyzer do you have? What Operating Systems do you have access to? |
|
I have the same cypress dev kit logic analizer as you show in the post pictures. I use Linux primarily so it should work like a treat. I will move future conversations onto that projects issues tracker. |
|
FYI, If using Linux, I recommend using the fx2pipe capture tool to do synchronous captures (one sample taken on the specified clock edge). Use the version of fx2pipe from the dev branch here (as it includes some recent fixes): To capture on the synchronously rising edge, use the following options: You connect the CLK signal to the RDY1 input, and PA4 needs to be connected to GND. Dave |
|
These two other projects combined have been an AMAZING benefit to my hobby work over here. I modified fx2pipe to not output the streaming stats so I can pipe it directly into z80decoder. I then pipe that output to a grep or two and I can live stream
I mapped out an entire custom keypad in a few minutes. |
|
Glad to hear you are finding this useful. The original version of fx2pipe supports piping, because the streaming stats are written to standard error. So this should work as well: I've used this method myself on occasion: |
I have a piece of test equipment running a z80 I want to repurpose. To figure out how to interface with its hardware I need to disassemble and map IO.
I tried traditional methods like IDA but the manufacture specifically chunked up the asm with random jumps and then filled the inter-spaces with valid opcodes to obfuscate things. To make it even harder there is a PAL that logs IO writes and does a CRC or something to give a jump offset as well.
Does the disassembly instruction run the memory through the processor core or is it just opcode conversion from raw memory? Would single-stepping disassembly be a true view of what the processor is doing?
The text was updated successfully, but these errors were encountered: