41 MCODE - Debugger

[Mark Power]

If you're into MCODE development, my debugger from 1986 might come in handy. Recently resurrected from HP-IL cassette tape and saved to a Mac courtesy of Clonix NoV-64 and suitably tweaked to work with that module, the DEBUG function in this module allows you to:

• Directly execute MCODE (so it runs at native speed)
• View and modify the five main 56 bit accumulators A, B, C, M and N prior to, after or during breakpoint stops in the code
• Edit the CPU status, pointers P and Q, the active pointer, machine code flags 0-7, the G register and hex/dec mode
• Print the contents of the CPU registers to attached HP-IL printer/video interface
• Edit the state of the 56 FOCAL user flags
• Create up to 10 breakpoints to interrupt the code, view and modify the CPU
• Continue execution from breakpoints
• Store the CPU state in a buffer so that debugging can continue next time the calculator is turned off and then on. This also allows you to break into code, drop out of the debugger, go into your favourite hex editor or assembler, look at the code and then continue in the debugger
  

Lots of additional functions are provided in the module:

• Create, Clear, Delete, Locate and Test a buffer
• Increment or decrement the FOCAL M register
• Extended catalogue
• Test and set a ROM checksum
• Load and save a ROM to tape
• Roll a HP-IL video screen up or down by a number of lines
• Provides a power on message, as Douglas Adams would say "In large, friendly letters"
• Power down the HP-IL loop when the calculator is powered down
• List user MCODE lables created with the David Assembler
• Super fast random number generator, increment/decrement X, some constants,...
• Play about the tone generation (claxon, rasp, key sounds off/loud/soft)
• Convert alpha to uppercase
• XTOA (for people without Ext Functions or a CX)
  

The zip file contains the mod file, main manual and quick reference guide.

In the manual you will find a worked example of how to drive the debugger. I'd recommend you follow that through before you try anything adventurous.

Note that the module must be placed in a RAM/Q-ROM page which can be modified such as a within an RSU or Clonix module. I tested it in 1986 with an ERAMCO RSU (which sadly I sold) and this week with the Clonix NoV-64.

Note also that the module modifies itself in order to preserve as much of the CPU state as possible, so the ROM checksum is only valid when the module is first loaded and before any MCODE is executed or breakpoints set.

If you want to use the breakpoint function the code under test must also reside in a RAM/Q-ROM, otherwise it cannot be modified to break out back to the debugger. If you just want to set up the CPU, run a genuine ROM MCODE routine through to a RTN and then look at the CPU state you can do that.

There are a few more limitations which are explained in the manual. In addition bank switching is not specifically supported (there were't many modules in 1986 that did this and the RSU I had didn't support it so I never implemented anything specific for it).

I've had to modify the code to support NoV-64 and your mileage may vary with all of the other variants of HP-41, RSU devices, emulators, etc. that are available now. Back up your HP-41 before use if you are worried about keeping user RAM.

If you find a problem, let me know but without your hardware or emulator it will be difficult to fix the code. The module is pretty packed full - I struggled to find space to add a NOP after each WROM (WRIT S&X) instruction in order to make the debugger work with NoV-64.

This debugger was part of my final year project that I did for my Computer Science degree and being a poor student at the time I had no printer, so the only copy of the source code is an A4 folder of handwritten code. I've just scanned this, so if you'd really like to see how it all works, drop me a note and I'll make it available (minus the tweaks for Clonix support which would involve rewriting quite a few pages).