Draft: Feature/151 machine code monitor

[chrisgleissner]

This is work in progress and not yet ready to be merged. This PR was raised to simplify discussion and tracking of outstanding work. It relies on changes introduced in #357 and assumes that PR has been merged.

Changes

Ultimate 64

• Enabled poke; already existed in the code base but was tied to DEVELOPER feature flag
• Added peek
• Added monitor with hex view

TODO

• Support peek in "UI / Freeze" mode.
• Support poke in "UI / Freeze" mode
• Support peek, poke and monitor for non-U64 devices.

Extend monitor (Shortcuts are inspired by the machine code monitors in Action Replay MK6 and Final Cartridge III):

• Fill (Shortcut F): Opens popup that expects a string of syntax AAAA,DD.
• Switch to Memory Dump view aka Hex view (Shortcut M).
• Goto address (Shortcut @): Opens popup that expects a string of syntax AAAA. View then refreshes with this address being shown in the first line.
• Disassembly (Shortcut D): Switches to assembly view which shows one 6510 instruction per line. Syntax: <Address> ' ' <Byte(s)> [' ' <Instruction>]. Switch back to hex view with H. Relative branches show the absolute target address, see address $E009 in the following example for a C64 with a first revision Kernal:

E000   85 56      STA $56
E002   20 0F BC   JSR $BC0F
E005   A5 61      LDA $61
E007   C9 88      CMP #$88
E009   90 03      BCC E00E
E00B   20 D4 BA   JSR $BAD4
E00E   20 CC BC   JSR $BCCC
E011   A5 07      LDA $07
E013   18         CLC 

• Adjust disassembly offset by pressing D: To ensure consistency with the file hex view, the first address shown in the assembly view is always a multiple of 8 bytes, e.g. 0xE000 in the example above. However, depending on where exactly the CPU starts decoding instructions, this may not allow us to find a valid opcode. In order to cater for this, repeatedly pressing A shifts the disassembly start address by 0 through 2 bytes relative to the first address shown in the editor's view. In the previous example, this would mean we try to disassemble from address 0xE000, then 0xE001, then 0xE002, before we revert to E000.
• Toggle illegal opcode support by pressing * (since popular monitors already use "I" to mean "Inspect"). Disabled when first entering the monitor view.

Open Questions

• How can we get this to work on non-U64 devices? It currently relies on U64Machine :: get_all_memory which is only implemented for U64.
• How can we get poke to work in "Freeze mode" on U64? Currently only works in HDMI overlay mode.

[GideonZ]

Looks quite good. I was able to build the U64 target. As soon as I have set up my U64 again (still in a box from a Commodore party), I will test it out. I can see you are on the right track also with separating the editor by type. Have you been able to figure out what happens with files larger than 26K?

[chrisgleissner]

Thanks Gideon! Please also have a look at the other PR I raised which, unlike the one here, is ready to be merged as it had a much smaller focus, namely to introduce a hex viewer for files rather than the C64's RAM.

The issue I had on that other PR with not being able to open files larger than 26KiB is already resolved. It was probably due to memory exhaustion caused by duplicating the required buffer space. The new approach simply uses the single source of truth buffer into which the file is read, then on the fly creates its hex representation as the hex viewer traverses the buffer. Thus, only a small additional buffer for the current view window is needed. I also did some low level byte to hex conversion (rather than relying on sprintf and its need to parse a format string) to keep it as fast as possible. May have been eager optimization, but I hope the resulting code remained legible.

I am facing a few issues with this PR here and I described them in the PR overview at the bottom. Maybe you have an idea how to resolve them. Many thanks!

[Zibri]

A full machine code monitor like the one in VICE would be great to have.

[chrisgleissner]

Thanks @Zibri , I agree.

I am currently hoping for my first PR (#357) to be merged by @GideonZ and will continue working on this PR once that has happened and I find time again.

[xahmol]

Would quite like this feature actually, missed a monitor sorely on developing my own recent project targettiing the U64.
As my porject is build in the form of a FinalCartridge 3 subtype 1 cartridge image, I could not use a cartridge to get a monitor. And could not use VICE either, as my project is heavily using the Ultimate Command Interface which VICE cannot emulate (yet?)

So ended up by debugging using full memory dumps (and doing PC based comparisons and analysis using a PC based hex editor)

A VICE like monitor via the Ultimate UI would be awesome.
And if you can only get it to work on the U64, well, IMHO that would be a great first step already ;-) (also being selfish a little bit here, use my UII+ carts on my C128s, and the C128 already has an inbuild monitor you can use in most cases)

[bvl1999]

Would quite like this feature actually, missed a monitor sorely on developing my own recent project targettiing the U64. As my porject is build in the form of a FinalCartridge 3 subtype 1 cartridge image, I could not use a cartridge to get a monitor. And could not use VICE either, as my project is heavily using the Ultimate Command Interface which VICE cannot emulate (yet?)

So ended up by debugging using full memory dumps (and doing PC based comparisons and analysis using a PC based hex editor)

A VICE like monitor via the Ultimate UI would be awesome. And if you can only get it to work on the U64, well, IMHO that would be a great first step already ;-) (also being selfish a little bit here, use my UII+ carts on my C128s, and the C128 already has an inbuild monitor you can use in most cases)

Not to mention, supporting the C128's MMU from an app running on the UII+(L) is probably not possible, because the MMU is invisible for DMA.. So such a monitor would be of limited use for the C128... but for a C64 with UII+ it would still be quite usefull. The biggest challenge I see is supporting changing the contents of $01, as it is also hidden from DMA, tho I think this is far less of a limitation for the c64.