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.
If you find yourself in the possession of just a HP21xx CPU you
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.
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
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
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
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
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
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
Update 10/4/08 - I connected a VDRIVE2 USB "thumbdrive" interface to
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
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
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
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.
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...
The lack of jumpers W9 to W12 on the DUP REG interface board I have
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
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.
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)
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 (firstname.lastname@example.org)