Add machine code monitor

[chrisgleissner]

Add C64 Machine Code Monitor

Addresses #151

This PR adds a machine code monitor for Ultimate 64–based devices. It includes a dedicated UI, a U64-aware memory backend, and 6510 disassembly support.

This PR has been tested on:

• Ultimate 64 Elite I
• C128 in 128 mode with UII+ (Thanks @bvl1999)

Video Walkthrough

• General: https://youtu.be/swDOzfrO0xI
• Bookmarks / Polling: https://www.youtube.com/watch?v=8Js9uDSfLco

Entry Points

• Ultimate 64 UI: Developer -> Machine Code Monitor (overlay and freeze modes)
• Telnet access

Features

• Views: Hex, Binary, ASCII, Screen Code, Assembly (incl. optional illegal opcodes)
• Edit and copy/paste in all views
• Memory operations: goto, fill, transfer, compare, hunt

Banking

• CPU bank–aware memory access
• VIC bank shown in status line
• Memory source annotations: RAM, BASIC, CHAR, IO, KERNAL

Session Handling

• Session state restored on reopen
• Concurrent use via multiple Telnet sessions and directly on the device

Backend

• Supports overlay and freeze modes
• Handles RAM-under-ROM writes
• Uses CPU-mapped reads in freeze mode

Testing

• Unit tests
• Many manual tests (see video walk-through above)
• E2E tests interacting with machine code monitor on Ultimate 64 Elite:

chris@mickey:~/dev/c64/1541ultimate/tools/developer/machine-code-monitor$ ./monitor_test.py
[01] initial CPU7/KERNAL monitor status ... OK
[02] KERNAL $E000 hex view and REST match ... OK
[03] paging away and back keeps memory view stable ... OK
[04] KERNAL disassembly formatting ... OK
[05] KERNAL $E010 REST match ... OK
[06] CPU6 RAM under BASIC write/read ... OK
[07] CPU5 RAM under KERNAL status ... OK
[08] ASCII view width and scrolling ... OK
[09] HEX edit writes both nibbles ... OK
[10] CPU bank cycling reaches CHAR and RAM mappings ... OK
[11] COMPARE reports differing address ... OK
[12] G executes finite loop and returns to monitor ... OK
[13] G repeated execution updates RAM sentinel ... OK
[14] G handoff preserves stable VIC state ... OK
monitor_test: OK (14 checks)

---

Keyboard Shortcuts

General

• CBM+O: Open monitor
• X or CBM+O: Exit monitor
• F3 or ?: Toggle help
• Cursor keys: Navigate by row/column
• Page Up or F1: Navigate one page up
• Page Down or F7: Navigate one page down

Please note that interacting with the machine code monitor often requires switching the two user interface modes (freeze and overlay):

• Overlay allows monitoring the C64 behaviour whilst changing RAM with the monitor
• Freeze mode allows for streaming the monitor's UI over the network, e.g. using C64 Stream. In Overlay mode, only the C64 video is streamed, hiding the C64 app menu, and thus the monitor.

To simplify this UI switch, I added a new keyboard shortcut accessible from the menu:

• CBM+I: Toggles the User Interface Mode and exits the menu (akin to Joystick toggle)

Views

• M: Memory
• A: Assembly
• B: Binary
• I: ASCII
• V: Screen Code view
• O: CPU bank options
• Shift-O: VIC bank options
• P: Toggle polling; great for observing live changes in UI Overlay mode

Edit Mode

• E: Edit
• CBM+E: Exit edit
• RUN/STOP or ESC: Exit edit mode or monitor

Copy / Paste

• R: Mark region start/end
• CBM-C: Copy
• CBM-V: Paste

Bookmarks

Bookmarks allow for storing up to 10 different regions (and user-preferred view settings for them).
This allows for very quick jumping to high value memory regions.

• 0 ... 9: Recall bookmark
• CBM-0 ... CBM-9: Set bookmark
• CBM-B: Open bookmarks list

Delete

The DEL key behaviour depends on the view and is always enabled, even if not in Edit mode:

• Assembly: Overwrites with NOP, moves cursor forward
• Memory: Overwrites with 00, moves cursor forward
• Binary: Overwrites with 0 (shown as .), moves cursor forward (NOT YET IMPLEMENTED)
• ASCII/Screen: Overwrites with space, moves cursor left (to operate more like a text editor)

View-Specific

Assembly

• Up/Down: Step one instruction
• Left/Right: Step one byte
• U: Toggle undocumented opcodes

Binary

• W: Set width, 1-4 bytes. Use 1 byte for charset editing and 3 bytes for sprites.

---

Freeze

• Z: Freeze in overlay mode
• Always frozen in freeze mode

---

Memory Commands

ASCII and Screen Code edit modes must be exited before using memory commands, to avoid ambiguity.

• J: Jump to address
• F: Fill memory range
• T: Transfer memory range
• C: Compare memory ranges
• H: Hunt for byte sequence
• N: Evaluate number
  • Shows hex, decimal, binary, ASCII, and Screen Code representations of an 8-bit or 16-bit value.
  • RETURN writes the selected value to the current address in the active memory view.
  • ESC closes without writing.

---

Execution Commands

• G: Go, executing the program at the specified address.

---

Disk Commands

• L: Load file to RAM. Choose PRG header address or absolute target address; optional file offset and length supported.
• S: Save RAM to file:
  1. Overwrite existing file: use "Select File" in file menu
  2. Create new file: press Enter on synthetic "" entry only shown if file system is used as file picker

Files can be loaded from / saved to either U64 filesystem files, or alternatively files within C64 disk files such as .d64 files.

---

Screenshots

Developer Menu

The machine code monitor can be opened in one of two ways:

1. Open menu, press CBM+O. (O as in mOnitor; the m shortcut is already taken)
2. Open menu, press F5 - D - M - Enter. In other words, via the Action Menu's "Developer" sub-menu, as seen in the screenshot below.

Freeze Mode

The "Freeze Mode" is used if the user selects Interface Type = Freeze in the User Interface Settings of the menu.

The freeze mode is largely identical to the overlay mode discussed below, but it does not have access to the BASIC nor KERNAL regions. Instead, it views the memory beneath them.

Help Menu

Hex Mode

Assembly Mode

The following steps take us to this screenshot

1. Copy Kernal to $1000 with the T E000-FFFF,1000 command (only works in Overlay UI Mode since Kernal not visible in Freeze UI mode)
2. Enter E(dit) mode
3. Type ST

From here, the user would normally continue as follows:

1. As the user types, a popup appears with all opcodes that match the characters typed so far.
2. The user can either select one of the opcodes and populate its arguments or alternatively type out the entire line.
3. The cursor automatically advances to the next line.

Binary Mode

Useful for viewing/editing the character set (as shown here) or sprites. Configurable width of 1 to 4 bytes per row.

ASCII Mode

Please note that the character set used by the UI does not include all characters of the standard C64 character set, so this is a best effort rendering.

Screen Code Mode

As mentioned under "ASCII mode", this is best effort rendering.

Evaluate Number

See the Hexadecimal / Decimal / Binary / ASCII / ScreenCode representation of the value at the current cursor position.

Save and Load

This section demonstrates how a byte range is saved, then loaded again. This relies on the standard Ultimate 64 file picker.

From U64...

...To C64U...

... And Back Again.

Overlay Mode

The overlay mode allows for full visibility of the C64's RAM, including BASIC and Kernal.

By default, the C64 is not frozen. However, if desired, its freeze status can be toggled via the Z shortcut. Great for examining memory without the C64 changing it.

Please excuse the image quality; the overlay is not visible in U64's video stream, thus I had to take photos. These are somewhat outdated as the code has moved on. For the latest code state, see the Freeze mode screenshots.

Disassembly Mode

Jump to Address

Fill Region

Limitations

• C64 monitor only. No 1541 drive monitor is included here.
• No stepping, breakpoints, or execution control.
• In freeze mode, ROM/RAM visibility follows the monitor's selected CPU bank. The live 6510 $0001 latch is not directly observable there, so the selected bank is treated as authoritative.
• No extra cartridge-specific banking UI beyond the existing platform behavior.

[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.

[GideonZ]

Hi Chris,

In the last months I have been primarily busy with the Ultimate64 Elite-II, so I had very little time to address activities from other users. I understand that this is discouraging, sorry about that. The good news is that I have put a bit of effort in CI/CD through github, which means that changes in a PR will be automatically built and result in an update package. Until now that's only available in the u64ii branch, but I'll merge all my changes there towards master shortly.

[chrisgleissner]

Hi @GideonZ ,

that's excellent news. Thanks a lot for investing time into this. It will drastically simplify raising PRs.

Some time ago, I wrote a hex viewer for viewing non-textual files in hexadecimal - an extension of the already existing text viewer in the context sensitive menu - see https://github.com/GideonZ/1541ultimate/tree/chrisgleissner-feature/320-hex. It works great on my U64. You didn't merge it back when I wrote it cause it only built for the U64 and I could not try it on any other devices as I only own a U64. If I get this to build with your new CI/CD pipeline, would you consider merging it?

Also, I emailed you two months ago about extending this hex viewer into a hex editor so one could also edit the file. This in turn could then be extended towards the machine code monitor described in this ticket.

Thanks

[Copilot]

Pull request overview

This draft PR expands Ultimate 64 developer tooling (peek/poke + a RAM “monitor” hex view) and introduces a new “managed Temp” mechanism that routes temporary artifacts into configurable Temp subfolders and optionally enforces an auto-cleanup limit, with supporting tests and validation scripts.

Changes:

• Add managed Temp file APIs in FileManager (category-based paths, optional /Temp/cache/<category> routing, and auto-cleanup enforcement).
• Add Ultimate 64 developer actions for Peek/Poke/Monitor and U64 memory access helpers (including freeze-menu handling).
• Add test coverage + on-device scripts to validate temp auto-cleanup behavior and PRG boot-cart display-name trimming.

Reviewed changes

Copilot reviewed 12 out of 13 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
tools/io/temp-auto-cleanup/temp-auto-cleanup-test.sh	End-to-end device validator for temp auto-cleanup behavior (FTP/REST driven).
tools/io/temp-auto-cleanup/temp-auto-cleanup-perf-test.py	Latency/throughput probe for managed temp uploads under different settings.
tools/io/prg-load-path-trim-test.sh	Device validator for boot-cart display-name trimming via PRG runner endpoints.
software/wifi/raw_c3/main/dump_hex.c	Formatting-only normalization of an ESP32-side hex dump utility.
software/userinterface/userinterface.h	Adds UI config IDs for Temp Auto Cleanup/Subfolders; defines store ID constant.
software/userinterface/userinterface.cc	Applies Temp settings to FileManager during UI configuration effectuation.
software/userinterface/hex_editor.cc	Uses shared dump-hex helpers for rendering hex rows.
software/userinterface/editor.h	Introduces AssEditor class declaration (assembly/disassembly editor placeholder).
software/userinterface/editor.cc	Adjusts text line-break behavior; minor draw() signature change.
software/userinterface/ass_editor.cc	Adds initial AssEditor implementation (currently erroneous draw binding).
software/u64/u64_machine.h	Adds U64-specific peek()/poke() and helpers around memory access.
software/u64/u64_machine.cc	Implements peek/poke and refactors memory access sequencing with freeze support.
software/u64/u64_config.h	Adds action slots for peek/monitor.
software/u64/u64_config.cc	Adds Developer menu actions: Peek, Poke, Monitor (RAM hex viewer).
software/test/filesys/test_mounts.cc	Removes redundant TempfileWriter::temp_count test definition.
software/system/dump_hex.h	Exposes new buffer-format helpers dump_hex_byte/word.
software/system/dump_hex.c	Implements dump_hex_byte/word; tightens const-correctness.
software/network/socket_dma.cc	Routes socket-uploaded disk images through managed temp storage.
software/network/assembly.cc	Removes redundant TempfileWriter::temp_count test definition.
software/io/c64/c64_subsys.cc	Trims boot-cart display name to last 13 chars with leading “...”.
software/io/c64/c64.h	Adds virtual peek()/poke() to the machine abstraction.
software/filesystem/filesystem_a64.cc	Uses managed temp paths/dirs for A64 cached downloads.
software/filemanager/tests/temp_auto_cleanup_test.cpp	New unit test suite for managed temp routing + auto-cleanup semantics.
software/filemanager/tests/Makefile	Adds a standalone build/run target for the new temp-auto-cleanup tests.
software/filemanager/filemanager.h	Adds managed temp tracking structures, settings, and new temp APIs.
software/filemanager/filemanager.cc	Implements managed temp pathing, tracking, cleanup enforcement, and hooks into open/close/rename/delete.
software/api/routes.cc	Removes redundant TempfileWriter::temp_count definition.
software/api/attachment_writer.h	Uses FileManager::create_temp_file() for multipart uploads (managed temp).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[bvl1999]

Would you be willing to try it out on an Ultimate II+ and see which features work and which ones don't?

From what I can tell currently none (monitor isn't in the developer menu, but didn't try if I can start it with c=+o).

[chrisgleissner]

Thanks @bvl1999 . Yeah, that is the problem with not owning a certain device; it makes development for it difficult. I will see if there is an easy way to at least activate the monitor so you can select it in the menu, but as it is already feature complete for Ultimate 64 devices, I think full support for U2 could then be a next step after merge.

[GideonZ]

Thanks @bvl1999 . Yeah, that is the problem with not owning a certain device; it makes development for it difficult. I will see if there is an easy way to at least activate the monitor so you can select it in the menu, but as it is already feature complete for Ultimate 64 devices, I think full support for U2 could then be a next step after merge.

@chrisgleissner Or before merge with a bit of help from the mighty guru... ;-)
And I think it's about time that I at least send you a cart as well.

[bvl1999]

Thanks @bvl1999 . Yeah, that is the problem with not owning a certain device; it makes development for it difficult. I will see if there is an easy way to at least activate the monitor so you can select it in the menu, but as it is already feature complete for Ultimate 64 devices, I think full support for U2 could then be a next step after merge.

I did a brief review of the code (tho before your last changes).

Currently there are a number of U64 specific things in there.

• using the character rom file from /flash/rom, this will not work on a UII/UII+ because that file won't be there (of course people can put the file there if they want to, but.. the UII/UII+ do not use it). I suspect this may also be an issue for a C64U implementation, but that needs a separate discussion anyway. This could be solved by including that rom in the firmware itself, but I suspect that has some licensing issues.
• you cannot access addresses 0 and 1 as the CPU sees them on a 'real' C64, so, the selection of rom/ram banks won't work. I don't see how that could be fixed without running code on the cpu.

Beyond that I didn't see things which wouldn't work on the UII/UII+.

So, with a few changes, and with some restriction on functionality, this could totally work on a UII+

As to integration, no idea if you already did any of this, but I have 2 suggestions:

• move the monitor from being a subdirectory of userinterface to a subdirectory of 'software'. I think it is substantial enough to be its own thing.
• move the code which sets up the 'tasks' for the developer menu into its own monitor_init.cc as part of that directory. While I get why you stuck it into u64_config.cc, this seems to not be the best place.

Last but not least, somehow u64_config.cc and u64_config.h ended up with dos line endings, the rest of your code has unix line endings like everything else in the repo.

Bart.

[GideonZ]

• using the character rom file from /flash/rom, this will not work on a UII/UII+ because that file won't be there (of course people can put the file there if they want to, but.. the UII/UII+ do not use it). I suspect this may also be an issue for a C64U implementation, but that needs a separate discussion anyway. This could be solved by including that rom in the firmware itself, but I suspect that has some licensing issues.

Correct. This ROM is not available in the /flash/roms directly on the cartridges. Including it in the ROM is OK for the C64U (is in fact already there), but not for the U64 / U64E2. What you could do instead is a DMA read of the cartridge ROM ;-) This will work on all machines / carts.

• you cannot access addresses 0 and 1 as the CPU sees them on a 'real' C64, so, the selection of rom/ram banks won't work. I don't see how that could be fixed without running code on the cpu.

You can't fix this through DMA unfortunately. This will neither work on the U64/U64E2/C64U. DMA access to locations 0 and 1 will always go to RAM, never to the CPU's PIO.

• move the monitor from being a subdirectory of userinterface to a subdirectory of 'software'. I think it is substantial enough to be its own thing.

Agreed.

• move the code which sets up the 'tasks' for the developer menu into its own monitor_init.cc as part of that directory. While I get why you stuck it into u64_config.cc, this seems to not be the best place.

Agreed. We must even consider renaming u64_config to u64_hw_config. This module shall only contain code that is U64 specific and is related to the configuration of the hardware (-registers) that configure the operation of the C64/U64 specific hardware.

Last but not least, somehow u64_config.cc and u64_config.h ended up with dos line endings, the rest of your code has unix line endings like everything else in the repo.

@bvl1999 The repo has different line endings, unfortunately, because some code is legacy from when I was still developing under Windows (before 2016). Git can be configured to store text files always with unix line endings, regardless of what your editor does. Would this be a solution for the future?

[bvl1999]

What you could do instead is a DMA read of the cartridge ROM ;-) This will work on all machines / carts.

I'm not sure I understand what you wrote here. Character rom on a C64/128 is not typically visible, and without changing either $01 on a C64, or both the mmu and $01 on a C128, you can't 'DMA' from there. And $01 as well as the MMU for the C128 can't be read/written using DMA.

Unless you run some software on the machine itself which sets up a memory map in which chargen rom is visible for DMA.

But maybe I am missing something here?

You can't fix this through DMA unfortunately

I think this is unfixable for the cartridges without running code on the cpu. And that code would be either C64 or C128 specific, or have to detect the machine type, as this also works differently on the 64 and 128 (where the memory map is mostly determined by the mmu, and only somewhat by $01, and neither mmu or $01 are visible for DMA).

So, for a UII(+) version, I rather consider this a limitation which cannot be addressed in a good way.

Git can be configured to store text files always with unix line endings, regardless of what your editor does. Would this be a solution for the future?

Sure. I just noticed the named files have unix line endings in the main repo, but not in this branch. It is a bit annoying to read, but no big deal really.

Bart.

[chrisgleissner]

Hi @bvl1999 and @GideonZ ,

Thanks for your very insightful comments.

Here some follow-up remarks:

• As @GideonZ already mentioned, the current repo has inconsistent line endings. I am keeping all my PRs minimal-invasive (though it may sometimes not seem that way - but things should always be as simple as possible, not simpler :-) ), thus I aligned the line endings to whatever is currently in place in a certain file. If that is not needed, I would very happily use Linux file endings (LF), but I discussed with Gideon before that line ending adjustments will be done in a separate, single PR, and from that point onwards, we can all just use Linux endings consistently.
• I will relocate the source code from software/userinterface/monitor to software/monitor. I doubt there will be a need for another kind of monitor soon, and if so, we can at that point rename software/monitor to software/machine_monitor or similar. I am a big proponent in keeping things simple and avoiding over-engineering, so I hope you like this name.
• My main ambition is to get this PR over the line for the Ultimate 64 (the device I own), unless fixing it for the U2+ is simple and does not massively expand scope. That way, it could potentially find its way into the C64U firmware, and there is now a large user base for these. In general, I strongly believe in small and frequent incremental releases to production.
• I did have a lot of trouble getting all the bank switching working. And as you pointed out @bvl1999 , writing to address $0001 from the monitor indeed does not change the banks that the CPU sees. As far as I can tell in my tests, the bank switching works now. To clarify, the CPU bank switching as implemented allows the monitor to have the world view of the CPU "as though" address $0001 had been modified to the value set via the O key. Thus, you can see RAM, Kernal, Basic, I/O, or Charsets. It does not change the banks as seen by the real CPU.

Today I did some final fixes to the Load / Save functionality to ensure it neatly integrates with the rest of the file picker (not yet pushed) and I am fixing the G (Go) command. Once that is done, it's ready for promoting the PR from Draft status.

Best wishes
Christian

[bvl1999]

* As @GideonZ already mentioned, the current repo has inconsistent line endings. I am keeping all my PRs minimal-invasive (though it may sometimes not seem that way - but things should always be as simple as possible, not simpler :-) ), thus I aligned the line endings to whatever is currently in place in a certain file. If that is not needed, I would very happily use Linux file endings (LF), but I discussed with Gideon before that line ending adjustments will be done in a separate, single PR, and from that point onwards, we can all just use Linux endings consistently.

Thing is, when I look in Gideon's version of the repository, those files have 'unix' line endings.
But anyway, this isn't a big issue to me, I just would like things to be consistent.

Gideon's suggestion to 'auto enforce' 'unix line endings' might work, until for some reason someone includes a dos/windows specific file of course.

Regardless, I agree, it would be better to go through the entire repo at some point and fix all the cases where dos/windows line endings are used.

* I will relocate the source code from `software/userinterface/monitor` to `software/monitor`. I doubt there will be a need for another kind of monitor soon, and if so, we can at that point rename `software/monitor` to `software/machine_monitor` or similar. I am a big proponent in keeping things simple and avoiding over-engineering, so I hope you like this name.

I'm totally fine with that name, simple and clear... but eventually, it is Gideon's call!

* My main ambition is to get this PR over the line for the Ultimate 64 (the device I own), unless fixing it for the U2+ is simple and does not massively expand scope. That way, it could potentially find its way into the C64U firmware, and there is now a large user base for these. In general, I strongly believe in small and frequent incremental releases to production.

I understand your take on this. My primary concern here is to not introduce avoidable things which would make it impossible to also implement this for the cartridges without that being a conscious decision.

As to the C64 Ultimate firmware, keep this in mind: the C64U firmware is currently not open source, and that means your code can't just move there, without your explicit permission or signing over the copyright.

From what you write, I assume you'd be willing to permit this, but I think it is good to not completely ignore the formalities of the GPL in this.

* I did have a lot of trouble getting all the bank switching working. And as you pointed out @bvl1999 , writing to address `$0001` from the monitor indeed does not change the banks that the CPU sees. As far as I can tell in my tests, the bank switching works now. To clarify, the CPU bank switching as implemented allows the monitor to have the world view of the CPU "as though" address `$0001` had been modified to the value set via the `O` key. Thus, you can see RAM, Kernal, Basic, I/O, or Charsets. It does not change the banks as seen by the real CPU.

From what I saw, you are using machine->get_cpu_port() to get around this, which works on the U64, but won't work on the UII/UII+.

Today I did some final fixes to the Load / Save functionality to ensure it neatly integrates with the rest of the file picker (not yet pushed) and I am fixing the G (Go) command. Once that is done, it's ready for promoting the PR from Draft status.

Thank you very much for all your work on this, I am sure this contribution will be valued by many a developer.

Bart.

[chrisgleissner]

Thanks @bvl1999 ,

Yeah, I am totally fine for all the code that I submit to this repo to be used for the Commodore 64 U firmware. To be perfectly honest, the prospect of making it to that repo is the sole reason why I started contributing a lot recently. There is currently no direct way to contribute to the C64U firmware, so this is my next best route.

Also, and this is totally unrelated, but have you seen Spiffy's take on the C64U firmware being also GPL v3 since it is unlikely all of its many authors signed a dual license agreement. I am not sure this can be discussed as part of this PR, but it is an open question I've had ever since reading this.

In terms of adding U2+ support, I would be very happy for this PR to be merged to master first for the U64 side of things. It can always be changed later - none of it is set in stone. Having a monitor is better than no monitor, and every road has a beginning. This is always my take on software - as long as it's written in a clear way, with tests, it is also easy to change and extend.

Many thanks for all your constructive feedback, it is much appreciated. I hope to promote the PR from Draft status either later today or tomorrow. Just final clean-up, and addressing the comment you left earlier about relocation.

Best wishes
Christian

[bvl1999]

Also, and this is totally unrelated, but have you seen Spiffy's take on the C64U firmware being also GPL v3 since it is unlikely all of its many authors signed a dual license agreement.

I am aware of that, but I think that discussion is a bit too big for this PR. I just wanted to make sure you are aware of this aspect, and permit such use.

[chrisgleissner]

Hi @GideonZ and @bvl1999 ,

I have pushed all my changes (including the relocation to a new folder, introduction of monitor_init.cc, and further reduction of formatting churn) and opened the PR up for review.

This has undergone my usual testing and I also added a video walk-through. There are also extensive unit tests as well as an E2E Python-based test that interacts with the deployed machine monitor via Telnet.

Many thanks for considering a merge.

Best wishes
Christian

[bvl1999]

Yay!

This is a C128 in 128 mode with UII+

Nice work @chrisgleissner !

[chrisgleissner]

Hi @bvl1999 ,

That is excellent, thanks for the good news!

You may like two new features I added: bookmarks and polling. I think especially the latter could become very handy when watching the I/O area.

I also added a short video link at the top of this PR to demonstrate them.

Best wishes
Christian

[bvl1999]

I also added a short video link at the top of this PR to demonstrate them.

Nice. but... do you ever sleep??? (hides)

[bvl1999]

So, found one curious behavior with the UII+ on a C64 or C128 in 64 mode. It makes sense when you realize how the freezer works, and might be hard to avoid.

Anyway, because the cartridge puts the system in ultimax mode, the system roms at a000 and e000 are not accessible, and nor is the ram below it, what you get looks like disconnected address space.

When using telnet instead of the local interface, you do get to see whatever is currently there based on the CPU's banking configuration.

This doesn't happen on a C128 in 128 mode because it ignores the cartridge trying to use ultimax mode, and you always get the view of memory configured in the mmu. It has its own peculiarity tho, because dma is used for reading/writing memory, the monitor will see the ram bank configured in $d506 and not the one in $d500. Also, the mmu and vdc registers are invisible to dma, so those can't be viewed or polled.

I imagine it might be possible to switch out of ultimax mode for the dma read/write, but don't know, @GideonZ would that work?