DarkStar wrote:
Thank you for this fantastic piece of software.
Thank you for using it!
Quote:
1. I disassembled an old commercial file where I stripped the range $0000-$2000 because it is RAM Mapped and gave WFDis the start address of $2000. There are many points where the programm accesses the range of $0000-$2000 but WFDis does not fill up this range with labels automatically.
The current workflow is to put the cursor on a reference, and press Shift-C to create a new byte in the address space to hold that referenced value. For instance, if there's a "lda $1003" in the code, putting the cursor on the "$1003" and pressing Shift-C will manifest a byte of value "??" at location $1003. You can then press enter to follow the link and re-label that location.
This is a stopgap, as I'm currently in a major rewrite of how the displayed lines are internally represented, to allow much more flexibility. This is also why updates have been slow. Once I get away from single keystroke commands (because there are simply too many), labeling a
referred-to location from an absolute/zeropage reference will be a direct operation. I don't think it's currently the best solution to automatically spam up the disassembly with every byte that's directly referenced, especially since some of those references are intended to cross banking/overlay boundaries, and some are pre-baked offsets against tables.
Quote:
3. it would be fantastic if an ascii repesentation was show as column at least after data sections.
I absolutely agree. However, the main issue is which character set to use. In the C64, which is kind of the initial testbed for WFDis reverse engineering, there's 2 fonts (uppercase/graphics vs lowercase/uppercase), as well as 2 character code mappings (PETSCII vs direct screen codes), so I'm still figuring out where & how to switch character sets to explore all this.
Plus, there are things like having the high bit set for end-of- or beginning-of-word markers, and games/demos that use even different character code mappings. That's probably not applicable to the "unknown byte" parallel display, which would mimic CLI memory monitor output, just showing standard text decodings on the side. The main idea I'm going to try is having a different color for 0-31, so escape codes show up as their respective letters, and render it in reverse if the high bit is set. Then most of the bytes should be displayed using standard 32-127 ascii characters. But even then, I'd rather have options, especially per platform, for varying that display.
Quote:
4. the IRQ-, Reset- and NMI Vectors at the end could be named and labeled ... only the target addresses are labeled right now.
Yes, that's a remaining oversight. The initial destinations of those vectors are labeled as entry points, but that was done before I had an "address" type for data, so I couldn't yet represent the $fffx vectors themselves. I will get that in soon.