HP Minicomputer Projects

The following sections detail construction projects for a '70's-era HP 21MX-series minicomputer as a suppliment to the HP-IPL/OS pages. Originally these computers used paper-tape for software input and output, supplimented by big clunky disk drives with packs of platters. These days HP 21xx software is generally in the form of "ABS" (absolute binary system) files on a PC, and likely the first thing someone who has aquired one of these machines needs is a paper-tape emulator to transfer PC files to the HP. To run original HP operating systems one would need a working period drive, not to mention the original software, but more often than not the HP hacker only has the CPU cabinet and little else. HP-IPL/OS was written to permit these old computers to be operated and programmed in configurations ranging from a 8KW 2114 with only papertape to a 192KW MX system with disk, HPIB, BACI (serial) and other devices, including an XY display generator which can write words and graphics to a standard oscilloscope. HP-IPL/OS supports actual 7900 and 7906 disk drives but also supports a homebrew "IDE" command set which can be used to make a functional disk drive using modern components. Although no vintage operating system can recognize such a drive (at least without writing a custom driver), to HP-IPL/OS a binary is just a memory image and it has no trouble loading most stand-alone vintage software from disk that otherwise would have to be loaded from papertape.

Paper-Tape Emulator

If you find yourself in the possession of just a HP21xx CPU you might want to be able to do something with it besides turning it on and listening to the fans, toggling in programs using the front panel switches might get old pretty quick... so the first thing to do is make a paper tape emulator so that software can be loaded from a PC. The following design is a "pass-through" paper-tape reader emulator, it permits transmitting a paper-tape file to the HP mini over a serial port. It takes several minutes to boot HP-IPL/OS but that's far better than nothing, and should be easy to duplicate.

The PIC is programmed with code that transmits a "!" character to the PC, then waits to get one byte which it passes to the HP. The code was written by Bob Shannon (probably in PicBasic), source has been lost but here's a hex dump and a disassembly. I use a program I wrote in QBasic called HPSEND to send the file to load. This is a "dos" program and will not work under Windows because that OS prevents the user from using the serial port. It can be run using a dos boot disk, I run it using FreeDos under DosEmu under Linux, which permits good old fashioned serial port access after editing config files. For loading HP files from Windows I found an older version of HpLoader which appears to work under XP, requires the VB6 run-time files.

Operating procedure is fire up the HP21-MX mini, start the HPSEND program and tell it what ABS file to send, select the S register and set bits 6-11 to the PTR slot (others clear), press Store, Preset, IBL, Preset, Run - HPSEND should respond by printing a "*" (I had to fool with mode commands to get it to work, details in the hpsend.zip file). Let the file load, when done the LED's for bits 0-5 will light up. Unless a terminal is already connected, close HPSEND, swap the serial cable to the HP's console port and run ProComm or similar set for 2400 baud even parity 7 bits 1 stop bit (on mine anyway, YMMV) Select the P register, press Clear, light up bit 1 (run address = 2, adjust if run address is not 2), press Store, Preset, Run.

The PTR emulator can also be used to load data files but things get a bit tricky if only one serial port, under HP-IPL/OS to load IPL files I have to use a HLT "word" (a program in the "dictionary" of words in memory) containing a halt instruction and include it on the LOAD line to give me a chance to swap cables. Other things like HP BASIC provide no chance to swap so if possible it's best to use separate ports for the PTR emulator and console so everything can remain wired.

11/15/10 - I discovered that my microcircuit board is jumpered so that while the data lines are ground-true, the command and flag lines are ground-false. The PIC code assumes this. In other words, to work with this particular board, the PIC code has to invert the data bytes, but responds to positive-going command signals, and asserts a positive-going flag signal once it sets the data lines.

IDE Disk Interface

The HP-IPL/OS "Simple File System" (SFS) permits storing up to 64 files in each of up to 64 volumes on each disk drive. Each file can be up to just shy of 64 Kbytes, and files are allocated 64 KB regardless of size (makes allocation a matter of simply finding the first unused file slot). The files can be  specific to HP-IPL/OS or not, binary files are simply loaded into memory and run without regard to content so can be almost anything that'll fit in 31KW and run from a cold start. The top 1KW is reserved for software to swap HP-IPL/OS back into memory, the current system is copied to alternate memory before running binaries. To run overlays requires storing the actual ABS file as a disk file then using SFS file access functions to load it into alternate memory on top of whatever is already there.

The SFS spec is independent of the actual drive, which is treated simply as an array of 1KW blocks. A really nice aspect of this design is a disk image for one drive can be used on another drive provided the disk driver is swapped. HP-IPL/OS comes with drivers for "real" 7900 and 7906 drives (but to my knowledge have only been tested under simulation), and Bob Shannon's IDE disk interface which permits connecting a common IDE hard drive using an 8052-based "Paul" board and some glue logic and code. Bob's system had been running fine for years with old code but after updating HP-IPL/OS and finding the IDE builds didn't work anymore (ended up being something stupid) I decided I had to make my own IDE controller so I could actually test the stuff. Besides it's fun, and beats waiting several minutes for my machine to boot from my pass-through PTR emulator.

HP interface boards come in many flavors, I'm certainly no expert on the subject but from what I've been able to determine the ones suitable for making a disk controller like this are either TTL-compatible "microcircuit" interfaces (such as the one being used for the pass-through PTR emulator which can be hooked directly to the PIC pins), or based on 12V logic such as the "+16 BIT DUP REG" board I'm using to test the IDE controller. This board is current-based, a "1" is current flowing but not in the usual sense, the inputs have a fairly stiff pullup (800 ohms or so) to +8 volts, the outputs can sink current but have a weak pullup (10K) to 12 volts. Voltage on the lines is high for logic "0" and low for logic "1" with the current flowing from the input's pullup through the output's transistor. Essentially to interface to these boards the logic levels have to be reversed and the voltages dealt with. For connecting HP outputs to device inputs, a series safety resistor, a diode to +5V, a resistor to ground and an inverter will convert the signal to a normal 0-5V logic level. For device outputs a resistor to the base of a transistor with the emitter grounded and the collector connected to the HP input will provide the necessary current sinking provided the signal is fairly strong (say from a TTL or CMOS chip), for weaker signals like those coming from an 8052 port an extra emitter follower or a very high HFE single transistor is needed, in addition to an external pullup resistor (8052 P1 pins can source hardly no current, in the low uA range). To be useful for a disk controller the interface needs to have 16 output lines, 16 input lines, plus the command and flag lines used for handshaking, and be set to "transparent" mode for no input register.

For the "+16 BIT DUP REG" board the jumpers should be set as follows...
W1 to +12, W2 to -12, W3 to -2
W4 to B, W5 to B, W6 to B, W7 to A
W13 to A, W14 to A, W9, W10, W11, W12 out.

Here's a schematic of my version of the IDE interface...

The entire circuit has been tested and seems to work [with a 12V interface board]. Here are some notes about the schematic.

Update 11/15/10 - The circuit is NOT compatible with a 5V "microcircuit" interface, do not connect directly to the HP without level shifter circuits or other interface elements - the microcircuit outputs have 1K pullups and the inputs have 316 ohm (!) pullups, which means the adapter circuit has to sink lots of current, and minimum there must be resistors in series with chip inputs to avoid large amounts of backcurrent through the protect diodes if the HP is on when the adapter is off. The circuit "should" also work with a ground-true microcircuit interface with the level shifters shown on the schematic - jumper the interface so that the command and flag signals are also ground-true (not tested). Also note that the microcircuit connector pinout is different. This circuit and the supplied code is only known to work with my particular "+16B DUP REG" ground-true board with ground-true control signals - but there is no guarantee it'll all work perfectly as-is as different boards often have different characteristics (as I discovered!), part of the HP minicomputer hobby is figuring out what the characteristics are and if necessary hacking the hardware and code into submission.

Note - when using the level shifters shown, a 150 ohm 1/2W resistor should be connected between +5V and ground to bleed off supply leakage from the HP. This is especially necessary if connecting other devices that don't reset properly on power-up if there's too much supply voltage when the interface is supposed to be off. Might need lower, perhaps even 82 ohms.

Here's the modified "Paul" board with the IDE interface and TTL-compatible HP interface...

A detail of the wiring between the 374's and 245's before other wiring applied...

The level-shifter board... (the top connector goes to the HP "+16 BIT DUP REG" board)


Point-to-point wiring was used to connect the level shifter outs and ins to the HP connector, the board was positioned on another piece of perfboard with hot-glue, set to raise the board up enough to keep from compressing the wiring. Salvaged ribbon cables connect the level shift board to the controller board...


Update 10/4/08 - I connected a VDRIVE2 USB "thumbdrive" interface to my IDE controller to enable saving and restoring up to a 7906-platter's worth of data in SimH HP2100 format, details on the IDE/USB page which includes updated source code. Connection is simple, just hook up the wires. A piece of empty perfboard on the left side of the level-shifter board (above) was cut away to permit mounting the module underneath the serial ports. Previously I was using a USB drive tray to load/extract disk data, the thumbdrive method is much slower but is more convenient, avoids wear and tear on the cables, and maybe now I can put this thing into a box with its own power supply instead of being spread out on my desk.

Update 6/5/10 - previous HP-IPL/OS version 1.53 is getting a bit outdated, for the most part it's ok but a few semi-obscure packages (print, edit, [hp]screen) have been updated with better/fixed versions, and the docs aren't exactly great. Working on a new archive that includes the latest packages and better docs and fixes some usage issues (like potentially crashing if too much stuff is loaded instead of saying it can't do that). Still waiting for the testing archive to stabilize before calling it official, but if trying out this stuff it's probably better to use than the old version.

The new VDOS stuff presents the possibility of a making a simpler VDRIVE2 interface that doesn't require the IDE stuff but can still load and save files on a thumbdrive, probably enough for poking around with an old minicomputer without the complexity of a full-blown disk system. Provided the interface firmware presents the same API (documented in the testing archive), the existing VDOS packages should work as-is. Probably should also double as a PTR emulator, without having to cram an IDE interface through the same lines, could arrange so simple reads (without high bits set) return the next byte of a open read file, and if a boot file is present on powerup, transfer it using the standard "IBL" boot procedure. Sounds like a "Microchannel" board and a PIC with enough ram to provide reasonably-sized read and write buffers, 1KB each should be fine. Perhaps a PIC18F2525-I/SP programmed using Great Cow Basic?

Update 9/20/10 - working on a new standalone VDRIVE2 dos suitable for small HP machines like the HP2114, menu-driven with options for saving a binary file, attaching a file that can be read from PTR (or booted), and a dos prompt. The current version is less than 0.5KW. Not much time to refine at the moment, what I have is in the udos.zip package. Includes updated firmware that adds a new command (132000) that engages papertape reader mode for the currently open stream read file, all bytes have to be read or the interface reset to return to command mode.

Update 11/11/10 - The PIC-based HP USB disk adapter is reasonably done, seems to work fine. Theoretically it should work with both 12V and 5V HP I/O interface cards but so far I've only tested it with the 12V "+16B DUP REG" I use for my 8052 IDE/USB adapter and haven't tried the papertape punch emulator feature yet. Works with both VDOS and UDOS, and also functions as a stand-alone papertape emulator with switches and a LCD for selecting single-letter read and write files, or a serial terminal to specify full filenames. Some aspects are still a bit experimental, the papertape command is implemented a bit differently than the modified 8052 code - instead of switching to papertape reader mode until reset or end of file, it disengages papertape mode if another disk command is received, avoiding having to reset the adapter and lose file attachments. Seems to work.

HP21xx Minicomputer Software

IDE disk notes... the 8052 code is configured to not autorun, in a production system the marked values need to be changed so the code starts automatically. If the drive is separately powered the 8052 needs to be powered up first, then the drive. The code will lock until the drive becomes ready. The stock Paul Rev5 board waits for a CR from the terminal to set the baud rate, to solve this problem the "fix_baud.asm" code from www.pjrc.com can be used to set the baud rate to a standard rate, updated examples are the "autostart.asm" code. I set baud_const to 244 for 9600 baud, and changed locat to 0xF000.

VDOS/USB disk notes... this project is (probably) easier to replicate and is especially handy for running HP21xx software with or without HP-IPL/OS as it has papertape reader and punch emulation. When using with HP-IPL/OS, VDOS can be used to specify filenames and even run the old EXTASMB assembler, ALGOL and FORTRAN compilers, and the BCS linker to produce ABS files. A bit funny with the enter key as the drivers require CRLF line ends, but after awhile I just got used to hitting control-M control-J instead of enter - another future hack. All that stuff is now in the HP-IPL/OS testing archive.

Files notes... there is some overlap in the various packages around here, the HP-IPL/OS main testing archive now includes a sampling of most of the software but slanted towards running from HP-IPL/OS and minus extra stuff that can be recreated or is too special-interest. Other various zips expand on specific types of applications with prebuilt binaries and other stuff that would be too much to add to the main archive, sometimes created by starting with the core files from the main archive then adding the rest of the related material. Or the other way around. The older 1.53 main archive is pretty much legacy material that can be ignored.. the primary page for it is almost full so new stuff mostly spills over to here now.

Initial Results

As of 11/29/07 the gadget essentially works, I can boot a copy of my simulated HP-IPL/OS disk system and can load and save files. My "+16 BIT DUP REG" board doesn't have W9 to W14 and can't be configured to operate in transparent input mode, resulting in a failure of the disk status being returned from the drive. To work around this problem I had to force the <IDE function (status read) to always return zero, details for doing this are in the hpiplos_ide.zip docs. This can probably be fixed in the 8052 code just not quite sure how yet, and likely would be fixing something that's not broken if used with the "proper" interface so any mods need to be done very carefully (my first attempt resulted in it not working at all, and the code does work as-is, at least on a 11mhz 8052 connected to the right interface board). Nevertheless even partially broken I can now boot my HP2113 far faster than from papertape, and have access to my favorite HP programs. Here are a few screenshots of the system in operation...

Going Further

The lack of jumpers W9 to W12 on the DUP REG interface board I have prevents it from being able to run the "stock" 8052 disk controller and HP-IPL/OS IDE code. Nevertheless a one-line command was enough to get the system up and going so even if the status read part is somewhat broken, the system as a whole certainly is not - I can now boot my system far faster than it previously took and it now takes only a couple seconds to load and run a program from disk, instead of many minutes. Forcing the disk status read to always return OK isn't as dangerous to the data as it might seem, since if an actual error occurs the 8052 disk controller code lights the error LED (or unlights it in the case of my hardware) and becomes unresponsive to any command except to reset the controller. The main difference is instead of getting an error message then not being able to do anything, the system will likely just hang, which is not necessarily a bad response to a disk error.

The HP/IDE interface hardware as documented seems to work well but there is still more that can be done to make it better...

Right now with the level shifters for 12V logic, if the HP mini is off or the cable is unplugged, every bit is set which sends the controller into an error state. The HP mini needs to be powered up first to force all the outputs of it to logical 0, then the 8052/IDE controller can be powered. Adding pullup resistors to the output-to-input level shifters would theoretically prevent dependencies like that by forcing the default state to 0... each output from the DUP REG board has a 10K resistor to 12V, 2.7K pullups on the level shifter inputs to a +8V source sounds about right, when the machine is off the input triggers will still see roughly 4V, enough to register as high and output a 0 bit. [note... debug mode still works fine with the HP turned off.]

Something should probably be devised for DUP REG boards that can't be configured for transparent inputs (besides patching HP-IPL/OS to be oblivious), preferably make the 8052 code so it will work with either registered or non-registered inputs. The <IDE status read has been a pain for awhile so one solution is to add a real status read command to the IDE instruction set and modify the HP-IPL/OS IDE driver accordingly [working on this but in practice it has not been an issue - simply disabling status is messy but works fine]. Another solution is figure out why status reporting works correctly on a registered board after a disk read but not after a write, telling me something is different between the two paths and it probably can be made to work without major code changes, and without changing the existing HP-IPL/OS builds.

RTE Games

These are sources and magtape binaries for a few RTE games...

Includes WOODY (chess), DAME (checkers), OTHEL, MMM, STAR and TREK (the source for TREK is in hpgtapes.zip, hpgames.zip contains the programs documented on my HP Games page). Running these on real hardware would be difficult without an existing HP1000 RTE system but now that SimH HP2100 supports RTE-6/VM the magtape files in hpgtapes.zip can be loaded and run under simulation. Some use HP terminal codes, the QCterm program (v3.1a) permits running all of these except for DAME, that one will have to wait until I apply HP->VT100 translations to the SimH v3.8 HP2100 simulator program [available in source form for 3.8-1] or some other support solution becomes available.

Created Nov 30 2007, last mod Jan 1 2012
Terry Newton (wtnewton@infionline.net)