I recently ran across a new visual debugger for C64 emulators called ICU64, written by Mathfigure. It will be released later this year and provides some amazing visualizations of both memory access and memory-mapped devices like the video and sound chip. See the video below for how it works.
There is also another video showing how the classic game Boulder Dash can be expanded to span multiple screens. He implemented this by grabbing graphics from the same RAM areas the game uses and displaying them on a custom screen. On this forum thread, the author discusses his goal of allowing more graphical expandability for classic games.
Learning to program on a small machine with a full view of every memory location is something I’ve always seen as a great way to start. I got a lot of insight into how my computer worked by running a background task that continually copied pages of RAM to screen, so you could “scroll through” memory. For example, the tick counter showed up as a blur.
I’ve always said that my kids would have to learn to program a C64 before they got a more modern system. Wouldn’t this be a great tool for teaching anyone new to low-level computing how assembly language and memory-mapped devices work? What about adapting some of these techniques to fuzzing or modern debuggers?
[Edit: added a link to the project now that it has been released]
11 thoughts on “Awesome C64 visual debugger”
Very nice looking demo.
I think one big factor that makes this so effective/possible now is that the hosting machines is several orders of magnitude bigger. Meaning you have enough cycles and storage to model and measure the emulated machine at full speed.
I have seen similar concepts for vuln finding now, like Pai Mei. The problem is that the program being instrumented can run thousands of times slower.
I went to a talk recently by someone who programmed computers in the 1960s — I spent a lot of time hacking demos with a monitor cartridge for the C=64, but his talk covered programming when you could map out the entire memory of the system on a single sheet of paper.
that’s a great visualisation btw…
I was actually thinking something like this would be a more effective debugger/hacking/cracking tool about 3 weeks ago and was considering trying to implement it. It looks like you beat me too it. :-)
I didn’t implement this, “Mathfigure” did.
An experimental version of this software is now available for download
Thanks, I’ve added a link to this. Hope you keep maintaining and improving it.
Honestly, I don’t find the 6502 programming very educational.
Don’t misunderstand: just this year I purchased the C64 machine language programming book, thinking it would have been very interesting and useful.
I think it is been definitively interesting, but not so useful: the problems of that kind of architecture sets are too far from today’s ones, and they are far from today’s low level programming perspective too.
A very restricted instruction set, specifically, creates a set of problems that nowadays are obsolete. They say that learning a very reduced instruction set is easy. It definitively is, but learning it is a thing, using it is totally another.
I wonder now which could be an educational low-level architecture/field.
Paradoxically, I find that a very educational field could be 80×86 anti/virus programming, though the virus programming is obviuosly full of bad implications.
Of course, I don’t endorse virus programming in any way.
Saverio, any low-level system is probably a good choice. What I would not recommend is choosing one with artificial restrictions like x86 16-bit mode segmentation.
I don’t recommend even modern 32-bit x86 as a programmer’s first system-level assembly environment due to its terrible artifacts. Anyone who has ever parsed the IDT will know what I’m talking about here.
The C64 has a lot going for it. Other than the limited number of registers and no MMU, the 6502 has most assembly features of modern CISC architectures. It comes with a flat 64k RAM if you disable the memory-mapped devices. You can poll or interrupt on raster lines, making it a great way to get a feel for realtime programming.
The best way to learn assembly is probably in an emulator. I think the C64 is a good option, but any basic game system emulator (not Playstation 2 or newer) is probably a good choice.
I agree that emulator programming is interesting and a good way to start out.
Another good processor to look into is the Z80. The Sega Master System was based on this, and if you check out SMS Power.org there are good tech notes, and the SMS emulator Meka has a nice memory debugger built into, too.
The NES emulator FCEUX (http://fceux.com/) has the best disassembly/debugging tools I’ve ever seen. Assembly viewer, breakpoints, real-time memory display, real-time memory editing (including both working RAM and the game itself), RAM address freezing, graphical memory viewer (including palettes, tilesets and backgrounds), trace logger, code/data logger (which tracks whether bytes are run as code or read as data), and more. One of the only drawbacks is that the NES used a lot of bank-switching because it could only load 32K of the program into memory at a time, so you have to keep track of which part of the ROM file an address is referring to, but they have some ways of making that easier.
Nice. I was pleased to find that gdb has built-in overlay support also. It automatically switches symbols when the overlay is reloaded.
Comments are closed.