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
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.
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, at least with the level shifters,
TTL compatibility to be determined (should be close, might have to
reduce the 1K resistor in the flag output emitter follower to 470
ohms). Here are some notes about the
schematic.
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...
For now I'm using a USB tray for the drive's power supply, the
controller module itself is powered by a 12V adapter. Eventually it
needs a proper enclosure with a decent power supply, for now I'm just
testing and using the USB tray to load the disk image to the drive,
might as well borrow its supply.
Software
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.
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.
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. 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)
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 or some other support solution becomes available.
Created Nov 30 2007, last mod July 8 2008
Terry Newton (wtnewton@infionline.net)