Threaded Mode | Linear Mode

Mark Power · 06-07-2016, 08:47 PM

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

Ángel Martin · (This post was last modified: 06-08-2016 06:03 AM by Ángel Martin.)

What a remarkable addition to the 41 legacy! So glad to see a real powerhouse MCODER back into the limelight. Many thanks for sharing your work, I'm sure it's going to be a pleasure to delve into it and put it to work. Ah, and nice opening splash too ;-)

charger73 · 06-08-2016, 06:18 AM

Hi Mark

Thank you for this great "hacker" tools!! I will "play" with it.

Best Regards
Tobie

richardjnelson · 06-08-2016, 03:08 PM

Hey 41 Mcoders,

When we were doing the HP-41 PPC ROM an HP employee Mcoder was interested. He didn't want to join PPC and pay for a ROM so i struck an (unofficial) agreement for him to write a few short Mcode routines. When he did and we loaded them they didn't work.

I wonder if they could be written today. The routine was a tone generator with an input of frequency and duration.

X < > Y,

Richard

Ángel Martin · 06-08-2016, 07:35 PM

(06-08-2016 03:08 PM)richardjnelson Wrote: I wonder if they could be written today. The routine was a tone generator with an input of frequency and duration.

There are at least three versions that I'm aware of tone generator functions. The first one was included in the SV-ROM but it's a little unstable. The second is TONEZ, in Doug Wilder's BLDROM. The third is TONEXY, written by Nelson F. Crowle if I'm not wrong. All use the same inputs for frequency and duration in X,Y registers - or the other way round, but the same concept nonetheless.

Just for fun I used TONEXY on the 41Z module to provide an audible signal on the complex results, using the real part for frequency and the imaginary for duration.

Mark Power · 06-08-2016, 09:01 PM

Thank you for all the comments. As the source code might be interesting to a few people I've loaded it onto hpcc.org in all its handwritten glory:

Please note that this is the original code, prior to tweaking it to work with Clonix. The Clonix meant adding a NOP after every WROM instruction in order to allow the device to have time to write to ROM/RAM and because I hadn't left spare bytes lying about I've had to use 3 byte port independent GOSUBs out to little blocks of code containing a few instructions. Consequently the code is now a lot messier than it was when I wrote the notes 30 years ago (I can't believe it was that long ago). The subroutine WRC1 (Write Class 1 Instruction to ROM) is now different as I realised I only ever write NC GO xxxx or NC XQ xxxx, never the Carry variants, so I deleted the code for this and put the extra NOP in.

I was interested in the comments about TONEXY. I have another ROM which has that contains all sorts of things I was playing with way back in the 1980s and 1990s. It includes a MCODE metronome, which was published in Datafile V9N4P19, and a MCODE routine which plays a tune from a ROM. It sounds terribly out of tune now. Whether it always was or this is some effect of now running it in a CX and Clonix+HEPAX module I'm not quite sure. I'll drag the ROM off tape but in the meantime you can inspect the PLAY source code.

I've a few more ancient artefacts lying around which I should now be able to get off tape now that I've mastered the process.

Keep calm and carry on debugging.

**rprosperi** · 06-08-2016, 10:22 PM

(06-08-2016 09:01 PM)Mark Power Wrote: Keep calm and carry on debugging.

Great sign-off!!

I've seen source code distributed in many non-text formats (e.g. Angel's Excel-based code sounds odd, until you examine it closely, then it's beauty and functionality is revealed) but don't think I've seen PDF source files before. I initially thought it may be a simple way to protect the code from casual copying, but then I looked at it, and it's history was instantly revealed. Thanks for saving it for so long and sharing it here.