Some Capabilities of HP-IPL/OS

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