Mark Lemmert of 6502 Workshop has been using microM8 to debug Nox Archaist, an Apple II RPG he’s developing, and we’re really happy when people use our stuff to do cool things. So we thought that the debugger could use a little love, for Mark’s benefit and the benefit of others.
microM8 has the ability to ‘record’ the state of the emulated Apple II, first so that you can ‘rewind’ and cheat at games, but second so you can debug software by analyzing how the error occurred. Mark has been using that ‘time travel’ ability to debug intermittent issues he has found in his game.
The previous version of the debugger let you do that, but it was itself pretty buggy, cantankerous and slow. As Mark says, it was better than nothing, but not by much. However, numerous bugs have now been fixed and the recorder has been optimised substantially, so it’s pretty quick and reliable now.
Also, you can record a session using ‘full CPU mode’ now via the microM8 menu, rather than needing to open the debugger to do it, which cuts out that overhead, and you can open recordings via the file catalog, after which you can then launch the debugger (while the recording is playing back) and continue from there. We’ve even added command-line flags so you can start recordings automatically.
So all of that should make Mark’s life much easier. And maybe yours, if you’re into writing Apple II software.
To further assist with debugging (and maybe for a bit of fun) we’ve also added a ‘heatmap’ under the memory tab that visually shows you reads and writes to memory, either as a full overview or for a specific bank of memory, and also a map that follows the CPU program counter, so you can see where code is executing. Speaking of the memory tab, we’ve also added a disassembly view that lets you disassemble from arbitrary addresses (which you can also save to a text file in the Tools menu at the top of the debugger window, along with hex dumps). You can also ‘lock’ memory addresses to specific values when you edit them, and you can ‘jump’ the memory view to the current program counter position.
The breakpoints dialogue is a bit more sophisticated now, featuring additional types of breakpoints including warning chimes, text messages inserted into traces, the ability to jump to an address and return, increment counters, change speed and start and stop recording. You can also set breakpoints to trigger after they’ve happened a certain number of times, and enable and disable breakpoints without having to delete them.
There’s a number of other minor improvements, but those are the highlights.
The Apple II doesn’t have sprites like other 8-bit computers such as the Commodore 64. This is annoying because it makes game programming more difficult. But that doesn’t mean we couldn’t have sprites in microBASIC. We’ve created a sprite engine and a number of BASIC commands to control it, prefixed with @sprite. There’s also a sprite editor in the Tools submenu of the microM8 menu you can use to generate the sprite code needed for the BASIC @sprite commands. You can get more information about sprites on this page.
Part of microM8’s mission is also to allow our users to ‘upcycle’ games. You can change the colour palette, offset voxels and so forth using microBASIC commands or microPAK configuration files. But what if you could change how specific regions are rendered? Well now you can, with zones. The examples above were created using them. They allow for many more on-screen colours than the Apple II is usually capable of. There’s more information about zones on this page.
Finally, although we love the Apple II, microM8 is meant to provide a diverse 8-bit experience, and to make a step in that direction, there’s now experimental Sinclair ZX Spectrum / Spectrum 128 support. It currently emulates the Kempston joystick interface, the AY sound chip in the 128, and can load .Z80 freeze files. And you can apply microM8 effects to Spectrum games. However, recording and such is not yet supported, and the emulation is still a bit buggy. So be warned!
Be the first to comment