First of all (if not obvious), HP-IPL/OS
is an antique-style
operating system for a series of vintage mini computers, written mainly
so a few of us who own such machines can have something to run on our
machines besides numerical BASIC and paper-tape demos. More often than
not these surplus machines have to be connected to homemade hardware to
do something resembling useful, thus we wanted a programming system
that would let us write arbitrary drivers and access every bit of the
machine with no artificial rules and without having to write every new
app from
scratch. Given enough memory and hardware, it can be used to load BASIC
and other paper-tape-style software from a homemade disk drive without
having to go through the boot sequence every time. There isn't a whole
lot of publically available software, but there is some, including
(very) old-style games that run under BASIC. It's nice to have an
operating system that lets me run BASIC, paste in a program, save it to
disk then run it or any other binary app any time I want from a menu
without going through the process again. But it takes at least 64KW of
memory to do that (at least with the present software), plus having to
build an interface for an IDE drive or USB thumbdrive, unless you're
lucky enough to own a real 7900 or 7906 drive with working media. To do
anything at all with one of these machines, at minimum you'll need a
papertape emulator or some other means to transfer binaries from a PC
to the machine. One possibility, especially for core-memory machines,
is the ABL
loader which permits octal machine code to be loaded via a serial
connection.
HP-IPL/OS works on HP21xx minicomputers ranging from a HP2114 with
8KW ram to a HP21MX-class machine with 192KW or more ram. Technically,
HP-IPL/OS is just a kernel that provides a limited stack-based
interpreted programming language (IPL), everything else that HP-IPL/OS
does depends on what IPL packages are loaded, and how much memory and
hardware is available to work with. Therefore the capabilities of
HP-IPL/OS range from a programming language that can be used to make
and run homemade apps (like MAZE) which
have to be punched and loaded from emulated papertape, to a disk-based
operating system that can run arbitrary binaries made using
[HP/MSU]BASIC, FORTRAN, ALGOL, ASMB, HP-IPL/OS, etc. With enough memory
and hardware (disk, papertape reader and papertape punch) it's possible
to edit old-style source, compile and link using vintage tools then run
the results. Myself, I usually develop using the SimH simulator where
hardware is free and the virtual machine is magnitudes faster then just
run the results on my HP2113 machine.
The "testing"
archive contains several pre-configured binaries and all the docs
and IPL files needed to adapt HP-IPL/OS to run a variety of HP21xx
machines to provide a range of abilities. Here are a few possible
configurations and what can
be done...
HP21xx with 8KW memory - mostly limited to IPL-only
programming. If machine code is needed it should be loaded directly
into high memory (i.e. created using a cross-assembler and loaded from
the papertape reader using the front-panel switches) then the proper
locations adjusted to tell HP-IPL/OS not to overwrite it, or configure
with Octapus, a vintage tool that includes a primitive assembler,
disassembler and papertape load and save functions. The hpos8k.abs
binary from the testing archive is a good starting build for 8KW
machines, comes with MAZE loaded as a demo, FORGET MAZE for about 2.6KW
free for custom applications. Can load IPL code from paper-tape
(front-panel switches have to be used to load machine code), if a
paper-tape punch emulator is available can punch changes made to the
system. When configured with Octapus there's about 0.7KW free for
high-level IPL code and memory from 16360 to 17677 can be used for
machine code. Download hpos8ko.abs.zip
for a pre-configured HP-IPL/OS 8KW binary with Octapus.
New (11/19/10) - I made a new USB disk adapter
that should provide an 8KW system with simple disk abilities, when used
with UDOS there
is no need to include the ABSOUT and SYSGEN IPL code since UDOS can do
that. This leaves about 0.5KW free for IPL with Octapus loaded, about
1.8KW free with the file access words, and about 2.4KW free after
removing non-essential utilities, leaving just HP-IPL/OS, essential
extras like FORGET EXPLAIN and RENAME, and UDOS.
HP21xx with 16KW memory - can support IPL and assembly
programming. The hpos16k.abs binary from the testing archive has a full
version of the kernel with two 1KW data blocks free and includes the
extras, a small version of the CREATE
assembler and Octapus. This system provides about 3.2KW free for
IPL/CREATE programming, high memory from 36360 to 37677 is free for
machine code. Memory is still a bit tight but for IPL that's quite a
bit. For more memory ditch Octapus - FORGET OE then adjust memory -
@END 36377 PUT 2 ALLOCATE - this leaves about 4.4KW free for
programming and high memory from 37000 to 37677 free for extra machine
code. To save the modified system to papertape you'll need to define a
new SYSGEN word that contains say PTZERO 2 EOD ABSOUT 37000 37677
ABSOUT PTZERO (or just run those commands, change the 37677 to the
highest memory to save). The code isn't provided but this is enough
memory for a simple VDRIVE/USB operating system. With a suitable
interface VDOS from
the testing archive should run as-is and provide the ability to boot a
system from the thumbdrive, load IPL files and save modified HP-IPL/OS
builds to the thumbdrive ("BUILD.ABS" VWRITE SYSALL VCLOSE).
Reloading would require copying the build to the fixed boot file then
rebooting - unless some of the high memory was used to make a
machine-coded loader that could load and run an arbitrary binary from
the thumbdrive. The USB disk adapter (with a bit of code to force
papertape mode) would allow using VDOS to open a binary for read then
using the HP's papertape loader to load it.
A HP21xx with 32KW memory - pretty much the same stuff listed for
16KW but with much more memory available, and can load full-size
binaries including stuff like BASIC with Trek on board and other large
programs. Most of the disk-related OS stuff has to be written but with
32KW it becomes possible to use the low-level IDE disk stuff (requires
the full version of CREATE) to save and
boot a
system and save and load arbitrary disk blocks. Probably much easier
to get a USB-type VDOS system going, the VDRIVE has a dos-like OS built
into its firmware greatly simplifying the HP-resident code. Some sort
of an SFS-compatible disk operating system can probably be devised that
works kind of like XDOS but with no alternate memory available for
buffering would have to work very differently - the operating system
couldn't simply and instantly be swapped to alternate memory to run
other systems, rather the "restore" code (normally placed at location
77000) would have to reboot the boot system. IPL packages or other
files couldn't be loaded as a unit into alternate memory then
redirected into the system a byte at a time, rather the LOAD code would
have to buffer the file a block at a time with a MS driver delivering
the bytes as requested. After returning to the operating system the
previous system wouldn't be available in alternate memory to
conveniently save, so tricks like entering a BASIC program and saving
to disk as a complete binary would take quite a bit of code, not
impossible but intense - in addition to the code a 1KW block of memory
is needed for parsing the disk directory and other data structures.
As far as the existing code is concerned, systems with 32KW or less
are restricted to (emulated) papertape, systems with 16KW or more can
support a simple VDOS system for storing files on a USB thumbdrive (but
not booting binaries except in the case of the existing IDE/USB
hardware/firmware, booting a fixed file), and a 32KW system can support
saving and booting a system from an IDE disk. Anything beyond that
would require writing custom code. The VDRIVE interface is
fairly simple to use so it probably wouldn't be that difficult to
devise some sort of a stand-alone dos for it that worked with even 8KW
machines (a few hundred words of code would do it - something like this), for a
system
without alternate memory I'd go that route if an on-line file system
was needed. Another (possibly better) approach would be an external
file system - make a papertape reader/punch emulator that provided some
way to specify what file is attached (but of course that means
designing new electronics and firmware).
A HP21MX-class machine like a HP2113 with 64KW memory - this
provides DMS and double-word
capabilities and enough
memory to use XDOS and its utilities for IDE/7900/7906 disks and/or the full
VDOS package
with extensions
for loading binaries while the
operating system is swapped to the other 32KW alternate memory bank.
When the swapper is called to return to HP-IPL/OS, the memory of the
system that was running remains in alternate memory, making it possible
to run a BASIC interpreter or other binary system, enter or paste code,
then save the entire system as a new disk file or punch it to PTP as a
stand-alone ABS binary. Binaries or other files can be loaded into
alternate memory to manipulate or redirect to and from other programs
using the MS (mass storage) infrastructure, XDOS loads IPL packages by
loading the file into alternate memory, redirecting alternate memory to
MS input then redirecting MS input into the console so that the file
gets loaded as if it were typed in. The altutil.ipl
sham.ipl and fcam.ipl
packages provide commands for examining and changing locations in
alternate memory, the results can be saved as a disk binary or punched
to an ABS binary attached to PTP or a file on a USB thumbdrive (same
mechanism - writes to MS which is PTP by default but can be pointed
elsewhere). XDOS systems can use a disk menu
which can load and run files by pressing a key, automates saving BASIC
programs and provides menu-driven functions for importing files to and
from the disk file system. A full screen editor
is available if you can stand it (full-screen editing over a slow
serial connection isn't exactly fast, usually it's more practical to
use a PC editor and load via PTR but an on-line editor is handy for
small stuff). It's possible to change the slot assignments of existing
binaries using the binpatch.ipl package
without having to have the program's matching configure program. A
specific patcher for the vintage SIO driver (used by the vintage
assembler and compilers) is in the sioutil.ipl
package. Having the extra 32KW bank of memory makes all sorts of stuff
possible that would be difficult to impossible to do on a plain 32KW
machine. The testing archive includes a hposdms.abs binary that can be
used as a base for building other systems, and a hpos6i.abs binary that
contains both IDE and 7906 disk drivers and the disk menu, which is
handy since the same binary system can be used under simulation with a
7906 disk or run on a real system with an IDE disk. In fact even the
disk image itself can be directly copied back an forth - my IDE system
I run on real hardware is exactly the same system I run under
simulation, when booting it looks at the bootrom code to determine
which disk drivers to enable. I can connect a serial terminal to my
IDE/USB controller to copy the IDE disk image to and from a file on a
thumbdrive.
A HP21MX-class machine with 192KW memory - this provides all of the
above plus four more 32KW file buffers using the SFS file access
system.
SFS stands for the Simple File System and has two distinct parts - a
physical disk format that specifies where things are located on disk,
and a software method for providing streaming access to files. XDOS and
its utilities implement the SFS disk format but it treats files as
single units that can only be copied to and from alternate memory. The SFS package goes a step further and permits up
to 4 files to be buffered and attached to the MS system at once, each
file has its own position pointer to permit opening, accessing and
closing multiple files without conflict. This is mainly something a
custom file-processing application would need to do, what that might be
depends on what you have in mind. I don't do a lot of that kind of
stuff but SFS provides the ability to do it whereas XDOS doesn't - XDOS
is designed for loading and saving stuff and doing disk tasks like
renaming and deleting files and formatting the disk to begin with.
There are a few provided things made possible by SFS - a library system that permits storing multiple
IPL files in a single disk file (the SFS format always uses 32KW per
file so is wasteful when storing many small IPL packages) and a simple line editor for editing text or IPL
files. SFS is used by LDTXT in the fedutil.ipl
package to permit converting a normal text file to the full-screen
editor's array format. SFS permits binaries to be saved in ABS format
and load them into alternate memory so that arbitrary memory ranges can
be loaded without disturbing other memory, the siobcs.ipl
package makes use of this ability to run the vintage FORTRAN compiler
which requires a 2nd-pass overlay. For what I do none of these things
are essential for me (for vintage compilers I usually use the mkbcs.ipl package to write out a SimH script
to compile apps under simulation outside of HP-IPL/OS and usually I use
a PC to store and edit IPL files and other source code - ok not exactly
authentic but makes development faster), but it's nice to have the
ability and it makes some things easier to program.
HP-IPL/OS can do a lot of stuff given enough code and hardware
resources, but what can be done highly depends on how much memory is
available and what sort of gadgets are connected to the machine. It's
really just a programming framework that in base form only knows about
the console and papertape, everything else is up to the user to make
and program, or see if some of the existing application code can be
used. For limited memory machines generally it's only useful as a
programming language as most of the existing disk operating system
stuff assumes 64KW or more.
Last modified 9/20/2010, 11/19/2010