chips icon indicating copy to clipboard operation
chips copied to clipboard

Disassemble invalid uses of the DD and FD prefixes as NOP

Open leiradel opened this issue 5 years ago • 3 comments

Same as https://github.com/floooh/chips/pull/44 , but from a different branch.

leiradel avatar Nov 29 '20 12:11 leiradel

Just a headsup, this will take longer to fix, because there's some tricky places in chips/ui_dbg.h where I'm assuming that the 'read-pointer' always advances one byte forward, see here:

https://github.com/floooh/chips/blob/093ca02eae3d7d36eb1a38d75b7fc9e913f2a9b3/ui/ui_dbg.h#L345-L353

More specifically here:

https://github.com/floooh/chips/blob/093ca02eae3d7d36eb1a38d75b7fc9e913f2a9b3/ui/ui_dbg.h#L349-L351

My initial "quick-fix" was to simply pass a 16-bit address into the read-callback, which is definitely the right thing to do for z80_dasm.h itself to allow "random access" in the read-callback, but this clashes with the code in ui_dbg.h which records the current instruction bytes into this bin_buf[] array. It'll probably be better to rework the whole z80/m6502_dasm.h API, make it a bit less "radical" in its "statelessness" but instead allow it to have state, and then provide additional convenience functions (for instance to read the bytes of the last disassembled instruction)...

floooh avatar Dec 02 '20 19:12 floooh

My first thought was that it could have something similar to ungetc to backtrack one byte, then you could just win->dasm.cur_addr--; win->dasm.bin_pos--; without the disassembler having to store any state.

leiradel avatar Dec 03 '20 08:12 leiradel

Ah, it's always possible to get the instruction bytes by using the PC passed to the disassembler and the next PC that it returns, so maybe ungetc is not even necessary.

leiradel avatar Dec 03 '20 08:12 leiradel