Moon - hex monitor

[aeb]

Moon is a minimalistic hex monitor for hacking/debugging/experimenting/fun: There's functions to view and edit memory in hex, save a memory block to disk, and that's all!

Moon was inspired by Steve Wozniak's Woz Monitor, the 256-byte program in Apple 1 ROM, but is made for Commodore 8-bit computers from the ground up: You can use the KERNAL screen editor to edit memory dumped on screen, and there's an option for KERNAL save.

Jim Butterfield's TinyMon kind of serves similar purpose, but is much more feature-rich and also much bigger.

Moon is just over 200 bytes in size and loads to either tape buffer (SYS885) or bottom of stack memory (SYS321). Memory starting at $0200 is used by save filename, and zeropage $FB-FE for a pointer and two variables.

When viewing memory, every second byte is displayed in reverse mode to show the byte boundaries while fitting 8 bytes on a single VIC 20 line. You don't need to use reverse mode when editing.

Moon (VIC 20).png (1.58 KiB) Viewed 6427 times

Commands:
- SYS321 or SYS885 (Start Moon)
- 2000 (Just type address to view 8 bytes of memory. Press Return to continue. Use screen editor to edit, but remember to press Return on every line you have changed)
- 2000:112233445566778899aa (Enter hex to memory, up to 40 bytes at once)
- 2000S2100FILENAME (Save memory at $2000-$20FF to FILENAME)
- Pressing Return on an empty line dumps the next 8 bytes of memory starting from previous location

- 900F:08 (Black screen)
- 028A:80 (Key repeat on, now it's easier to dump larger regions of memory)
- There's no exit command, hit Run/Stop & Restore instead
- There's no jump command, use SYS instead
- There's no load command, use LOAD instead

Grab here:

Moon.zip

(9.34 KiB) Downloaded 69 times

[MrSterlingBS]

Cool it works !!!

THX a lot
Sven

[Mike]

Some remarks:

Moon is just over 200 bytes in size and loads to either tape buffer (SYS885) or bottom of stack memory (SYS321). Memory starting at $0200 is used by save filename, and zeropage $FB-FE for a pointer and two variables.

The "bottom of stack" version loads to $0100, and this lowest portion of the stack area is not particularly save for use: conversions of float or integer values to ASCII use the bytes beginning at $0100 as buffer, also tape operations use that part of the stack for error correction; so the first instructions of Moon are overwritten on those occasions.

The use of $FB..$FE for internal variables of Moon might easily clash with any use of those in the user's program. However, IMO it is rather unlikely people will use Moon for debugging, given the lack of register and breakpoint support, so that point is somewhat moot.

Jim Butterfield's TinyMon kind of serves similar purpose, but is much more feature-rich and also much bigger.

Even JB's TinyMon - and that one offers a proper runtime environment with CPU register dump and breakpoints - already is a straitjacket for anyone on real h/w to advance beyond BASIC and start out with machine code. Once one gets accustomed to the minimal standard of having a disassembly and direct assembler in a monitor, it is just painful to have to miss out on these two features. One can argue, whether block copy/compare, block fills and byte pattern searches are necessary - for me I once included those too into a true minimal set of features of a monitor for it to be really useful.

Typing in a disassembly listing at least has some educational merits, see my VICMON primer. However, I think that people nowadays don't type in long hex dumps anymore, especially not if they don't have checksums.

[Wilson]

I think aeb was quite clear about the limitations of his program

While one can do serious work with a monitor, frankly, even the most powerful one is sort of a toy compared to, say, VICE's debugging tools. But I love them just the same! Always fun to see new ideas.

Mike's points about where to locate a 200 byte monitor are good food for thought. In the most general sense, nowhere is really "safe" without knowing what the user wishes to save. It might be interesting to make a relocatable version the user can install wherever they wish. The zeropage values could also be saved/restored if you wanted to leave the entire ZP untouched.