HP-IPL/OS Testing Page

Main HP-IPL/OS page is here. (older) IPL, assembly and text files are here.
Instructions for simulating a magtape/disk system are here.
Pre-built 7906 disk simulation loaded with games and stuff is here.
Plans for a PTR emulator and IDE disk interface and software links are here.
Plans for a PTR/PTP emulator and USB disk adapter are here.
The editor page is here. The 31KW MSU BASIC page is here.

Updates and Testing Files...

Added/modified packages for 1.52 and above include...

sham.ipl - utility for dumping alternate memory as octal and text
binpatch.ipl - utility for patching the I/O slots of existing binaries
msupatch.ipl - utility for patching the 31KW MSU BASIC binary
sfs.ipl - SFS file access words, now checks to make sure buffer memory exists
bkfile.ipl - a way to dump/restore files to/from the console (when PTP isn't available)
ideboot.hpa - went back to the original IDE bootrom code
sfslib.ipl (8/30/08) - a new library system, replaces lib2.ipl/a2l.ipl/ms2l.ipl
edit.ipl (9/7/08) - a much faster replacement for edit.ipl SFS line editor
print.ipl (3/15/09) - fixed printer driver with new/renamed words
screen.ipl and hpscreen.ipl (5/22/10) - fixed COLOR so dim FG on color BG works

Version 1.60 testing archive includes a new kernel with dictionary overflow prevention and infrastructure for a new ERASE word that removes the last package loaded. The new archive includes new html-style docs, a few new builds and packages, and sources tools and docs available elsewhere but should be included for self-sufficiency.

Fixes/additions for the 1.6x testing archive include...  (most of these also work with older versions)
hpiplos1.asm (6/9/10) - a new kernel with overflow protection and @LLP (address of last load point)
extra.ipl (6/5/10) - a new extra package for v1.6 with an ERASE that removes all words from the last load
vdos.ipl (11/17/10) - words for controlling a VDRIVE disk module and streaming firmware
vdosext.ipl (6/14/11) - extra VDOS words for HP21MX machines (here's a patch for existing VDOS builds)
vintage.ipl (6/14/11) - VDOS words for compiling and linking software using vintage tools
cross.ipl (12/1/10) - words for running and passing data to and from an HPBASIC app
svbas.ipl (12/4/10) - a word for saving HPBASIC apps to MS out in ABS format
dm2.ipl (6/13/11) - disk menu for use with MSU BASIC or HPBASIC
dmenu.ipl (6/13/11) - simpler disk menu for HPBASIC
dms.ipl (6/13/11) - dynamic mapping system - new swapper in ALTSAVE clears A/B
altutil.ipl (6/13/11) - alternate memory utilities
mkbcs.ipl (6/13/11) - makes a simh hp2100 script for compiling apps
sioutil.ipl (6/13/11) - slot-patches SIO driver, now compatible with other versions
xutils.ipl (1/1/12) - modified ABS2F to use location 157 for temp (instead of 100)

The latest testing archive is in the hpiplos_main_testing.zip file. This is really the real main package now.
Extra HPBASIC stuff including games binaries is in the hpbapps.zip file.

Note... this is a log of recent development and related web-related activity. Text here gets written in bits then get consolidated, moved to other files, edited and/or deleted as needed.

9/16/12 - Still here :-) Not a lot of old-comp activity lately, but Bob Shannon has been having some troubles with his system, we're trying to track it down. Symtom is there seems to be a branch into low memory when the !DMS word is executed, where it hits a halt at location 150 (octal, left-over cruft from some utility used in the past, locations from 150-157 are often used by utilities for temporary storage). The wayward jump is to between 101 and 147 octal (a halt at 100 isn't reached, one at 147 is), and the problem seems to occur with all DMS versions of HP-IPL/OS. Suspiciously the machine he's trying to get going uses DMS microcode versions (13307-800) '36-'38 whereas the older machines we tested on uses microcode '33-'35. No idea what the difference is, not convinced that has anything to do with anything but we may be looking at an incompatibility, or could be a hardware problem or a mismatch between firmware and board versions... will update when I have more info.

This wasn't it, but this issue reminded me of a possible bug to watch out for - invalid IRQ vectors in locations 6 to 25.

DGEN, XSAVE, etc save an entire 31KW memory image, so if there is a vector down there, a build is saved, then slots get rearranged, then whammo... unpredictable crash. Any I/O activity with interrupts enabled can trigger a fault if the corresponding vector location is invalid. So... if rearranging slot addresses, boot with autostart words disabled (put 177777 in the switch register before running from location 2) and enter/run the following...

FORGET CLRINTS (and confirm)

...now clear the switch register, run from location 2 and if all is well, resave the build. It is tempting to add something like this to the kernel to make sure the vectors always start cleared, but besides wasting memory such a thing could get in the way of someone manually installing a custom vector so I resist. But there probably should be a note about this in the readme. Another thing to keep in mind that since HP-IPL/OS allows the user to do just about anything (including corrupting the build), be very careful when saving builds. If an improper command is entered (having no apparent effect) and it happens to corrupt a system word and then the build is saved, that's a problem. My own rule here is I avoid saving a build I've been hacking on to anything important, once I know what I want to do I reload the base build, make the changes, then immediately resave. That way I don't accidentally corrupt a build from misplaced fingers.

1/1/12 - Updated the testing archive to version 1.65, only build-related code change is the XDOS utility word ABS2F now doesn't stomp on location 100 (locations 100-147 are supposed to be reserved for applications and user code). Could replace the 1's with #1 and save 5 more memory locations but that'd change the size and risk having to do IPL rearrangements so left that alone. Details. Also updated Asm21 to the new 1.07 version with FP and DMS support (should now assemble most absolute asm sources, even the vintage malformed stuff - at least the ones I noticed), dropped some of the outdated bash scripts, added a new doc that tries to briefly explain how the core threaded interpreter works (sometimes the simplicity of it gets lost in the details), added more info about how I recovered the SIO/BCS assembly source from the magtape images. Fixed some typos.. one of the urls pointed to my corewar page (ugh again but I'm sure there are other typos in all that stuff but so long as I'm not aware of them then it's ok:-).

7/6/11 - Almost... forgot to change the 1.64 archive date to 2011..ugh. Fixed, along with some other minor tweaks including an updated Asm21 assembler and my script for using the vintage EXTASMB assembler, now archive version 1.64A. The updated Asm21 just fixes the ORR and IFZ psuedo-instructions, a new version of Asm21 is in the works that includes DMS and FP instructions and can handle the malformed OCT and ", I" instructions (space before the I) present in the old EXTASMB and ALGOL assembly sources but it's still under development so for now use the vintage assembler if the old stuff needs to be reassembled... plus it might be awhile if ever before Asm21 can handle relocatable source code for linking using BCS. No real need for that since the vintage tools have to be used anyway for linking and compiling ALGOL/FORTRAN modules but it would be interesting to figure out the "rel" format and how they did away with page errors and handled external references in the old days - software techniques that are now just a given. Also included my PT conversion of The Oregon Trail, which has its own Wikipedia page including links to modern conversions and a page with information about the original HP2000 versions.

6/14/11 - OK went for it... updated the "testing" package to 1.64. While testing discovered a major issue with VDOS' UFSIZE word.. realized I had forgot to add the BCSLIB.REL file to my binary test directory but had a copy in another directory. The USB disk adapter does not support streaming files between two different directories (due to the way the VDRIVE works), so wrote a "DDCP" word (on line using the funky full-screen editor, it's now in the ipl_notes.txt file) that reads a file from one directory into alt mem, changes to another directory and writes out the file. Needs UFSIZE to see how big the file is to know how much to read and write. Only it didn't work, always returned 0 bytes (it used to work..). Problem was the VDRIVE takes more time than I anticipated to return the size so fixed it by using &WFVDR (wait for vdrive response) instead of <VDR. With that fixed, copied the file I needed and finished testing. It's a pretty drastic update, just about everything had to be rebuilt to incorporate the new DMS package but thankfully all that is scripted now. While tweaking the archive and to get it all on the same page, replaced the old vintage binaries with the recovered source and binaries, no unknown "binary blobs" now, everything has source so if something doesn't work right can figure out why.

The other big change as far as the web site goes is I updated the linked IPL/assembly/text files to reflect the latest 1.6 versions, and removed the main readme.txt and other readme's as they are too archive-specific, instead linked the HTML docs I wrote covering the base system and how to make a custom build from scratch on real hardware with not much more than a PTR emulator and a console. That last doc is already a bit out of date, some of the things it mentions for dealing with failed loads were addressed in v1.6 - now if a load fails just enter ERASE and confirm. Of course that matters only to someone who actually needs to make a build to do something different... there are already many pre-configured builds for (probably too many) situations, can just use one of those should the need arise. As with many projects development here is driven mostly by what I want to do... as a language HP-IPL/OS has been pretty much "done" for years (occasionally getting updated at the base level to fix old nags), almost all of the new stuff is related to fixing and running other stuff. What interests me is being able to take old code I find on the net and turn it into programs I can run and enjoy... so I make dumpers, patchers, menus, loaders, words that make it easier to use vintage compilers, that kind of stuff so in the end I can sit back and play some old game like it would have been played in the '70's. Well mostly.. if I don't like the way the original worked (if even possible to run the original) I'll hack it to make it work the way I want or just use the old tools to make something new. Which is what users did back then so that's part of the "experience". And now I have to get back to real work... received the specs I was waiting on.

6/12/11 - Updated the 7906 sim package, now uses the "BASIC2" adaptation with a functional backspace and doesn't spew the terminal with unprintable TTY characters like MSU BASIC did, and the BCS apps no longer require CRLF terminal settings. Little things like that make a big difference. The SIO/BCS source "recovery" option is pretty much done, the new sim package includes the tools on disk with words for operating them (they still require attaching ptr and ptp to source code and binaries, it's still paper-tape software). Source code for the assembler, ALGOL, FORTRAN, BCS, library, SIO/BCS drivers, newly assembled binaries, docs and tools are in the vintagetools.zip archive. Very cool stuff, at least the vintage material - my homemade tools for processing the raw magtape images and assembling the library source are crude and probably need work, but they got the job done. Of course nothing new there, most of my tools are crude (including HP-IPL/OS:-). I dropped quite a bit of esoteric IPL material from the simulation... the focus seems to be shifting now from testing new IPL stuff to merely using HP-IPL/OS as an operating system for running vintage stuff. Cramming a bunch of words or IPL packages in an SFS library file then running and forgetting them is cool and all, but when it comes down to it, mostly what I want to do is press keys to run games from a menu, type simple commands to compile stuff, be able to examine and patch binaries and other fairly simple things. For what I do, SFS earns its keep bigtime by letting me store ABS overlays on disk, very handy for running FORTRAN pass 2. Getting back to the basics... and exploring all the new vintage code that has become available.

This is not to say there won't be any more HP-IPL/OS development, far from it. In the process of working with the BASIC/SIO/BCS material I learned that 2027 is a much better BASIC re-entry vector, the SIO TTY driver I found is totally different than the old one I was using, BCS requires that the B register be 0 when running (or else location 106 needs to point to an exit sub), and now not all BCS apps require CRLF enters. Nice stuff to know but it affects a few IPL packages...

dm2.ipl - fix message regarding BCS apps, change BASIC re-enter vector to 2027 (already patched in the 7906 sim version).
dmenu.ipl - same fix as for dm2.ipl (or just remove this package, nothing really uses it)
altutil.ipl - change BASIC re-enter vector to 2027 in the ALTABS word.
ipl_notes.txt - change BASIC re-enter vector to 2027 in the BSAVE word.
sioutil.ipl - fix so the actual locations of I/O instructions don't matter, or at least only work on the old version.
mkbcs.ipl - fix it so it correctly does d 0-77677 0 when clearing, eliminate halt workaround for BCS.
dms.ipl - fix the swapper in ALTSAVE so that it clears A/B before jumping to the binary.
vintage.ipl - fix the message in the link word about halting BCS when done, with the swapper fix won't have to.

...and rebuild all affected builds and docs. The old versions aren't really broken, they just have cosmetic effects that have been known for awhile. The difference is now I know what causes the effects, so now I can fix them. Eventually anyway, might take awhile and before I do maybe dig more through the newly posted material to see if any other compatibility fixes are needed to run some cool thing, and see what else might need doing.

6/4/11 - Just a "I'm still here" post... and some good news - there has been a very large code drop into the BitSavers bits/HP section.

I've been slammed with work (I design ANR headsets and try to keep musicians happy by fixing their amps) so I haven't had much time for old-comp hacking, but every now and then I power up my old HP mini with my homemade USB disk controller and have some fun... and contemplate the state of HP-IPL/OS. Yes, it's just a crude homemade OS for a vintage computer that means little in the real world, but that's what makes it fun. Yet despite being just a fun study in "what would it take", there are still a few real-world benefits. These days I use "blassic" a lot, but for some things it is faster for me to use HP-IPL/OS and/or HPBASIC to write little one-off programs (and if the app requires parsing arbitrary file bytes it's usually lots easier to write a few lines of streaming IPL rather than messing with anything modern). Thanks to SimH and some scripting I can double-click HP mini apps and run them just as easily as an app written in any other language. Thanks to BitSavers and the single-user BASIC source, now I can double-click my customized basic2.abs binary, type in some code, type BYE and save it to a new app. That covers most of my low-precision computational needs, which usually involving inputing some numbers then spitting out the answers I need. But perhaps one of the biggest applications of old-comp tech for me comes from building hardware to attach to my machine. Making the USB disk controller taught me how to use the more the powerful PIC18 chips, and that directly impacts real-world apps. Now I have an automated tester that can save thousands in labor costs and my own bootloader that lets me update embedded app code without having to remove the chip and stick it in a programmer, and unlike existing bootloaders, without having to dance around the bootloader or use a custom PC client. Now I can just send a standard hex file using a serial terminal. I can't really say this came about because of old-comp hacking, but in this case old-comp definitely gave me a venue in which to work out the tech before tackling a real-world app. And likewise, the need for more powerful (but still simple and rock-solid - not ARM) embedded processing for real-world apps caused the USB disk adapter to be made and now I have another toy, so the two worlds definitely intersect and feed off of each other.

The present "hpiplos_main_testing.zip" package is really the main package to use, just subject to updates that might or might not stick. The old "hpiplos_main.zip" package works (other than a few slightly buggy IPL's like disk menus that can't count to Z) but it doesn't have kernel-level dictionary overflow protection and the ability to remove all words from the last loaded package in one step. At some point I probably should package up a new v1.6 "main" package with the latest code but without all the non-HP-IPL/OS bloat present in the testing package - but there are more important things to do (like streamlining the use of vintage compilers) and some of it might affect the package... so it can wait. 

The 7906 simulation package needs to be updated to use the new basic2.abs base which has a real backspace function and works better with modern terminal emulators than the present MSU BASIC solution. Also can add a few new games such as Sea Battle and a new conversion of The Oregon Trail that I'm working on. [..] need to finish up Trail, patch the BCS apps so they'll work without terminal changes (see below), add vintage compiler tools and write docs and stuff. [done]

My current project is going through a bunch of stuff that got added to BitSaver's HP bits section last month. Not everything is directly accessible due to an index file in one of the directories, but no problem, copied new "what's new" entries to a file, sorted it, and used an IPL program to turn it into a huge HTML index file...

;MKINDEX - reads lines from PTR, prefixes url and writes to PTP in
;the form of a HTML index file. At EOF halts with overflow (or hang),
;to avoid add ~TERMINATE~ as the last line of the input file.
"Enter URL prefix: " $PRINT $IN
$DUP ;dup prefix line
MS$IN ;read line from input file
$DUP X>>Y ;save line to Y stack for label
$CAT ;combine with prefix
UNTIL ;loop until ~TERMINATE~ is read or it hangs at EOF

(could have used almost any language for that, in this case Blassic or QBasic would have been easier but whatever)

Wow. Just the whatsnew.txt entries are about 340K, yielding a 1 meg index. Most of the material in the form of raw magtape dumps, it's going to take work to turn into reusable files. Many of the source files appear corrupted but that's easy to fix, just set bit 7 to 0. This IPL does that...

;clear bit 7 from PTR to PTP, terminate when result is 0

(this is one of those binary processing apps that's easier to do with HP-IPL/OS)

...I think this one needs to be wrapped in a script so I can right-click raw files and turn into plain text.. done. So how to do that? This is how I did it in Ubuntu - starting with hposdms.abs or just about any non-disk HP-IPL/OS build, first create a HLT word then add the above IPL as an autostart word, ending with HLT...

HP 2100 (modified) simulator V3.8-1

033567 : HLT 1
033570 : END

Simulation stopped, P: 02226 (JMP 2225)
sim>attach ptp hpnb7.abs
PTP: creating new file


...put the hpnb7.abs binary somewhere and make a bash script to run it...

echo "set cpu 21MX" > $tmpdir/hpnb7.tmp
echo "set cpu 256K" >> $tmpdir/hpnb7.tmp
echo "set clk dev=10" >> $tmpdir/hpnb7.tmp
echo "set tty dev=11" >> $tmpdir/hpnb7.tmp
echo "set ptr dev=12" >> $tmpdir/hpnb7.tmp
echo "set ptp dev=13" >> $tmpdir/hpnb7.tmp
echo "attach ptr $1" >> $tmpdir/hpnb7.tmp
echo "attach ptp $1.txt" >> $tmpdir/hpnb7.tmp
echo "load $hpnb7abs" >> $tmpdir/hpnb7.tmp
echo "run 2" >> $tmpdir/hpnb7.tmp
echo "detach ptp" >> $tmpdir/hpnb7.tmp
echo "exit" >> $tmpdir/hpnb7.tmp
xterm -e hp2100 $tmpdir/hpnb7.tmp
rm $tmpdir/hpnb7.tmp

...I called it StripBit7 and put it in my nautilus-scripts directory so I can run it on any file. Not robust software, must not be any spaces in the filename or it might wipe out the source file instead, but for me that's not an issue since I never save normal files with spaces in them. Theoretically this should be doable in Windows but not sure how that OS handles quotes these days, there cannot be any quote characters in the attach lines.

It's going to take awhile to go through all the files but it appears that a very large portion of the HP21xx software library is here. [...]

[6/7/11 - ALGOL, FORTRAN, EXTASMB, BCSPREP and the drivers all assemble cleanly, but the BCSLIB source consists of 76 ASMB chunks and as far as I can tell the papertape version of EXTASMB can only assemble one chunk at a time (the original was probably assembled using a magtape or RTE system). To compensate made a really scary bash script that uses blassic and flip to break the source file into separate ASMB chunks which are assembled separately to the same output file while suppressing leaders and trailers. The simple TTY term poke patch didn't work out.. making BCS work with a regular terminal with CR enters required modifying the driver and reconfiguring. Seems to work under sim but need to test on real hardware... messing with TTY in an interrupt-driven environment can have side effects. At this point I've recreated the essential BCS toolchain from source code except for the SIO drivers, still using my old configured binary for that. Definitely getting there!]

Thanks goes out the CHM, BitSavers, and to all who preserve code from the past. And to the one who wrote the "saveit" program that separates the magtape images into individual files! Crude but extremely cool.

12/21/10 - Found and converted an old BASIC game called "Sea Battle"...

Here's the source code and a log of it beating me (I thought that was a ship). Added to the hpbapps collection [and to the games page].

12/12/10 - I was working on some "history-related" stuff and ran across a 4KW build of HP-IPL/OS (v0.34) from 2002. OK... but I cheated by using Octapus to save it, requiring 8KW. Not truly 4KW, so grafted the punch code from the "smovl" overlay into it to make a stand-alone 4KW HP-IPL/OS capable of saving itself and anything added to it. Only 391 words free (about 0.76K bytes) so won't be adding much but that's enough for a line automata display and a little splat game. Here's the WORDS display for the newly-configured 4KW kernel...

HP-IPL/OS 4K 0.34P

...now that's minimalistic! EOD can go to 7677 before it gets into the bootloader.

In other file news, while the testing archive now includes BASIC RevA (plain 28KW and with the overlay patches applied), it does not include extra stuff like overlay binaries for reconfiguring, assembly listings and preloaded BASIC games binaries (except for at the moment an 8KW version of OTHOV). That stuff could be regenerated but requires installing perl for the assembler and also the SimH HP2100 simulator unless a good PTR/PTP emulator is available. For the convenience of those who might want to actually run this stuff, I put the extra files in the hpbapps.zip file [linked above in the initial section] with several ready-to-boot games for 32KW and 8KW machines. The simulator might still be needed to make different configurations but for that included extra scripts to try to simplify the process. Manually installing PC software can't exactly be described as simple but at least in this archive it's not required when all that's available is a simple PTR emulator (for that matter putting the stuff together on a real HP mini with a full PTR/PTP emulator isn't trivial either - without perl on a PC for Asm21 it would require using the vintage EXTASMB assembler, definitely not "easy"). For Windows users who do use the simulator, one issue with running terminal-enabled software is the plain "dos" window can't handle ANSI codes, so figured out a possible scripting solution involving launching HyperTerminal configured for telnet (only tested with XP under VirtualBox - YMMV).

Another minor PC nitpick is support for proper ascii-127 "rubout" backspace that actually stops at the beginning of the field - for some terminal emulators (HyperTerminal, Gnome Terminal) have to settle for a ascii-8 backspace that can't know when to stop. Konsole and xterm get it right. Not only is this an issue for the BASIC backspace patch, but also for HP-IPL/OS itself and just about any oldcomp software running on anything with hard-wired echo - if the terminal sends 127 for backspace but then reacts to the character when it echos back, then it can't work right on a HP mini. Sometimes I wonder what modern OS makers are thinking when they try to support old protocols like this... it's really very simple - incoming ascii-8 should always back up the cursor, ascii-127 should always be ignored, and permit setting the terminal so pressing backspace sends either 8 or 127 depending on the needs - my stuff supports either but only the ascii-127 backspace properly stops, ascii-8 backspaces back up to the line beginning since I can't stop the echo.

12/8/10 - HP-IPL/OS "testing" archive now includes the BASIC overlay stuff, now v1.63. Includes a new "basic2.abs" binary w/cross2, Octapus and the backspace patch, can be used from HP-IPL/OS, stand-alone on a 32KW+ machine or under sim - especially handy since it has a built-in puncher, doesn't require an external save utility to create binary apps, just PTR and PTP devices and some way to change the "papertape" files/roms/etc. Finished up a terminal-enabled OTH, uses a ANSI-colored display...

Cool stuff (for old-comp), the program includes a set of subroutines at the end which might be useful for playing around with the overlay, stuff like clear screen, home, position cursor, set colors, etc.

12/5/10 - Here's a backspace patch for 28KW BASIC with the cross2 version of the overlay. With the patch applied the regular backspace key can be used to make corrections, should work with most terminals that send ascii-8 or ascii-127. I've been wanting this one for years, using "_" for corrections might be OK for a TTY machine but these days we have terminals that can actually erase characters.

12/4/10 - Finally got around to real-hardware testing.. oops bit 7 of char gets is invalid with a 7-bit parity console.. fixed. There are now 3 versions of the BASIC overlay in testing, the original version (with fixes) in the bascross.txt file that uses 21MX hardware fix/float instructions, org'd to 72000 octal and exits to HP-IPL/OS upon entering "BYE"; a general-purpose stand-alone version in the cross2.asm file that doesn't require hardware FP and has a menu with options for punching a stand-alone BASIC application, patching run and BYE behavior, help for calls and options to run HP-IPL/OS and Octapus-D if present; and a version optimized for 8KW in the smovl.asm file that includes a simplified self-save option for punching stand-alone BASIC apps. All support the same added CALL commands except for the 8KW version which (obviously) doesn't have the DMS-specific exit-to-HP-IPL/OS calls. Between these three versions it should be possible to configure a version of the overlay that works with most configurations. At some point these will probably get added to the HP-IPL/OS testing archive along with some terminal-enabled games and stuff, but first have to make some apps. The BEASTI game is a good start but it's still a bit slow on real hardware, could use some speedup tweaks if possible. Can't do anything about the slowness of my 2400 baud console besides move jumpers on my interface card to change it to 9600 baud, but if I do that need to put it on a switch so I can still test using the slower speed.

12/1/10 - [...] The new console get/put calls are nice for games - here's a terminal-enabled BEASTI. One issue though - if a key is pressed while BASIC is actually running it stops the program. To fix this (sort of) I figured out a CALL poke that disables that, causing the program to ignore errant keystrokes. They still echo to the terminal output so the screen refresh prints need to account for that possibility. The program should undo the poke before exiting and before normal inputs to allow normal stop behavior (entering S). Peeks, pokes and data-passing can be tricky - BASIC (as well as the hardware FP instructions) treat 16-bit integers as signed, 77777 octal is 32767 but 100000 octal is -32768 (2's compliment). Care must be taken when poking machine code instructions, but just have to remember to subtract 65536 from any value over 32767 for the negative equivalent. Doesn't bother me :-)

11/30/10 - From the Neat Hacks department... [figured out] how to call a BASIC program from HP-IPL/OS then return, in effect running an entire BASIC system as if it were a word. Two components make this possible, an overlay that implements a call that exits the system by swapping but instead of running from location 2, it does JSB 321B,I to continue running HP-IPL/OS from whereever it was when it ran the BASIC system. The overlay includes other useful stuff like peek, poke, execute and raw console I/O. The other component is a IPL package that does the heavy lifting for passing data between HP-IPL/OS and BASIC's "common" area declared when dimensioning arrays using COM instead of DIM, also includes words like BASINIT BASEDIT and BASRUN for clearing, editing and running BASIC, patching the run address appropriately.

11/28/10 - I recently found the complete source code for papertape BASIC on BitSavers (under pdf/hp/hp2116/BASIC_Jan70/) - this is a huge find for HP21xx hackers, many thanks to all who helped to preserve this classic program. The source was in 11 "tapes", with 3 more tapes for the prepare program. Using the magic cat I combined them and it assembled cleanly and produced a perfectly working 20392 Rev A BASIC. Super-cool. The only (non) issue was the configure program only supports 8KW, 16KW, 24KW and 32KW configurations, a few minutes with an editor gave me options for 12KW, 20KW and my favorite configuration, 28KW. I spoke with Bob Shannon (the originator of HP-IPL/OS) and he highly encouraged me to add this to the HP-IPL/OS archive, along with the SIO/BCS tools so that practically everything needed to experiment with HP21xx computers is included and preconfigured for use, at least if using the standard HP-IPL/OS slot lineup. So I did that, now archive 1.62. Hopefully it's all organized and documented sufficiently, no changes were made to the existing archive material (MSU BASIC remains) but added a new "development" build with VDOS, vintage.ipl for use with the USB disk adapter and mkbcs.ipl for making build scripts for simulation, and new docs explaining how to use the material. To truly experience what it's like to develop vintage software one really needs a sufficiently capable papertape emulator such as the USB disk adaper to handle all the read and write file attachments (each corresponding to physically changing a papertape). It is not necessary to run HP-IPL/OS to use the software, rather HP-IPL/OS can be used as "training wheels" to automate the file attachments using VDOS and the USB disk adapter, and print instructions to the console to tell the user what buttons to press to make it go, and in some cases edit source code to compile.

11/23/10 - I made a set of words for VDOS and the new USB disk adapter that operate the vintage compiler tools...

"source.asm" "output.ext" ASMB - assembles a program using EXTASMB, output can be REL or ABS depending on source
"source.alg" "output.rel" ALGOL - compiles a program to a REL file using ALGOL
"source.ftn" "output.rel" FORTRAN - compiles a program to a REL file using FORTRAN1 and FORTRAN2
"input.rel" "output.abs" LINK - links a REL file using BCS and its library to produce an ABS binary

The words prepare the files and print instructions, the vintage software has to be operated by hand by selecting registers and pressing switches. Here's a session log showing the building of a Reversi program written in FORTRAN and a chess game written in ALGOL and assembly. The vintage compiler binaries were obtained from The HP2100 Archives, the sio.abs binary was slot-patched using sioutil.ipl and the bcs.abs binary was prepared using the instructions in bcs31k_log.txt. This is a pretty cool hack, I've been doing this for awhile under simulation using mkbcs.ipl to make a "makefile" script but being able to operate the original programs on real hardware is a nice experience. The "Creating USB file" messages printed by VDOS give it away that all is not vintage, but that doesn't matter - that's just the operating system, the vintage compiler tools are stock except for configuring.

11/21/10 [edited 11/23] - [...] This afternoon, perhaps for the very first time ever on real hardware, I used the USB disk adapter with the vintage EXTASMB assembler to assemble the HP-IPL/OS kernel. One of the more exciting 20 minutes in HP-IPL/OS history, waiting for the error to come but once I got it going the software and hardware performed perfectly and punched a working ABS file. [...]

11/19/10 - Updated the "testing" archive to include essential details for the new PIC-based VDRIVE interface, and fixed a couple of bugs in VDOS (an operating system for VDRIVE/USB adapters) - the original VDOS driver mistakenly tried to use a second command/flag cycle when I needed was LIA. The 8052 firmware didn't notice the command glitch but the PIC-based interface picked it up, requiring extra delay to get past that, especially if interrupts were enabled. Also wasn't waiting long enough for a response in the VOWCHECK work (checks to see if a file exists)... the VDRIVE "dir" command can pause after it outputs the first CR if there are a lot of files in the directory, changed all of the byte reads following the command to the wait form.

11/14/10 - The USB disk adapter is pretty much done. I still have a bit more testing to do but so far it's really nice - does papertape reader and (theoretically) punch emulation, works with VDOS and UDOS, has an LCD screen to show file attachments, single-letter files can be manually attached using switches or the serial port can be used to specify full filenames for use without an HP-side dos. This should be a workable solution for booting an HP mini and loading and saving files, even with a 8KW machine. Or even a 4KW machine for that matter if you don't mind being limited to UDOS and/or Octapus.

10/2/10 - Updated the 7906sim package to v1.60 (finally! the menu not allowing entry Z was bugging me). Version 1.60 is probably beyond testing at this point, it seems to work fine and is what I'm using for other HP-IPL/OS projects... soon the v1.53 archive probably should be removed from the main page with v1.60 in the usual hpiplos_main.zip - only trouble with that plan is my infionline web site doesn't have enough free space to do that until I figure out how to shuffle some stuff around. Another "issue" is that would leave identical content in the testing and main zips.. so maybe I'll defer the whole thing until I got something more worthy of testing in the testing archive... ah the joys of maintaining a hobby programming site that's totally off the beaten path (I'd hate to have to figure stuff like this out for something that's actually important but I suppose attempting to maintain some resemblence of consistency is good practice should that task ever present itself). In short, consider the v1.60 testing link the current production version until I figure out how to make the transition (unless of course a bug is found). Might take awhile, around here hobby stuff can move slowly.

[standalone VDRIVE solution speculation moved to its own page]

9/19/10 - A disk operating system for the HP2114? Sure why not!

Here are the VDRIVE2-related commands supported by my IDE/USB 8052 firmware...

120000 = 1010000000000000   read from VDRIVE, follow by read transfer (bit 15 set if busy/end)
121bbb = 10100010bbbbbbbb write to VDRIVE, byte in low 8 bits of command
122000 = 1010010000000000 sync VDRIVE (call before starting operations)
123000 = 1010011000000000 clear VDRIVE (call to discard response of last command)
130000 = 1011000000000000 open read file, follow by filename[cr]
131000 = 1011001000000000 read from file, follow by read transfer
132000 = 1011010000000000 read using paper-tape emulator mode (disables commands until eof)
134000 = 1011100000000000 open write file, follow by filename[cr]
135bbb = 10111010bbbbbbbb write to file, byte in low 8 bits of command
136000 = 1011110000000000 close write file (write remaining buffered bytes)
137000 = 1011111000000000 get usb_error value, follow by read transfer (0=no error)

Command 132000 is new, sends whatever bytes are remaining in an open read file. In the present "hack" implementation the only ways to return to command mode is to read all bytes of the file, or reset the IDE/USB interface... before placing the data on the bus and setting the flag, the firmware could check for another command (say 133000) to cancel papertape mode but for now I have to press the reset button the 8052-based interface.

I made a tiny dos called UDOS that might be useful for small machines line the HP2114, it contains drivers for all of the functions and a simple menu to provide essential operations - save memory to a named ABS file, attach a named file to PTR (if a binary then can be booted using a stock loader), and a dos prompt for giving raw Vinculum commands including DIR, CD, DLD (delete dir), MKD (make dir), DLF (delete file) and RD (read file). The core dos is less than 0.5KW and occupies memory from 17000 to 17677, easily fits into 8KW with other software. This isn't really a finished product (has some crude aspects), but something to get started with and further explore what is needed to make a functional small-memory operating system. [UDOS is now included in the HP-IPL/OS testing archive, it's done enough.]

The present hardware doesn't support papertape-punch emulation, file writes have to be done using the dos... contemplating alternate hardware and firmware that would permit punch emulation as well. HP-IPL/OS has redirectable input/output subroutine vectors so it can read and write files through a single HP adapter card without using emulated punch, and it's easy enough to simply load binaries via emulated papertape, but vintage software such as compilers that needs to read and write data won't work (not that it has to, apps can be built under simulation where there is plenty of memory and full command line control over what files PTR and PTP attach to). To really be useful a PTR/PTP emulator needs to have some kind of external way to select the files. In times past the operator physically changed rolls of papertape - having to specify filenames via HP software doesn't work for all cases, especially for a limited memory machine where a dos or an app can be loaded, but not both, and overlays are involved. Hmm... maybe better to not to try to run compilers and stuff from disk and be happy just to be able to save custom dos systems and load and run arbitrary binaries, the existing stuff does that and it makes the interface design lots simpler... can focus on more mundane aspects like being able to correct errors using backspace and how to kick the interface back into control mode without pressing reset.

7/11/10 - I'm really starting to like ALGOL.. it has many of the features found in modern structured languages like local variables, parameter passing by value or pointer (but they didn't call it that back then), and return values so a function can be used in an expression. Programmers take these things for granted these days but advanced stuff for the early '70's, the FORTRAN (II) compiler is extremely crude by comparison. The main limitations are upper-case only I/O and practically no input editing, but these things can be overcome using assembly modules which accept parameters and pass data back via pointers. I started a new programming project - a version 3 Z-machine interpreter that when/if it works will let me play old Infocom text adventure games such as the Zorks on my HP minicomputer. Much of the infrastructure is in place, now getting deep with the interpretation process. At the moment working on parsing packed Z-strings.. the encoded strings (3 characters to 2 bytes) have abbreviations that point to more Z-strings, and it all expects the interpreter to perform word-wrap. Fortunately it's illegal for abbreviation strings to also contain abreviations so full recursion isn't necessary but it's still tricky. One of many problems to solve! I think I have the stack frame stuff figured out but still have to tackle object tables, input dictionary searching, opcode execution and all that stuff to go. It's designed to run either stand-alone, prompting to load the story file via papertape, or run from a HP-IPL/OS disk system using SFS to pre-load the story file into alternate memory banks. Minimum target system is a HP21MX CPU (HP2113 etc) with 64KW memory (enough for "minizork"), with a serial terminal and (emulated) papertape reader.

6/15/10 - I was out of town for a few days so loaded my little HP 110 "mini" with the HP-IPL/OS disk simulation I had made, further loaded with siobcs.ipl and the vintage assembler, ALGOL and FORTRAN compilers and the BCS linker. First thing I discovered was the new version 4 Konsole terminal shell is practically unusable - no way to disable software flow control thus breaking everything that uses control-S or control-Q. Plus the command like defaults break all scripts that use it. Version 3 is one of my favorite terminals but seems "progress" has gotten to it, so ignore references to konsole in scripts or docs. Once I got over not being able to use my preferred terminal, I rigged the xterm command line options to make an authentic-looking green on black display and got on with the goal of the exercise - figuring out the basics of ALGOL by writing a simple program that prompted for a string then printed it back...

FORMAT A1(10A2);
READ(1,A1,FOR I:=1 TO 10 DO NAME[I]);
WRITE(1,#("HELLO, _"));
WRITE(1,A1,FOR I:=1 TO 10 DO NAME[I]);

The lines are space-padded because I wrote it in AEDIT (which uses control keys for cursoring, why the new Konsole wouldn't work). Compiling it requires exporting the AEDIT-format source file to a papertape source file, compiling the source to produce a papertape relocatable file, feeding the relocatable into the BCS linker, followed by the BCS library with some switch register settings to produce a binary. Normally more steps are needed but HP-IPL/OS is used to store pre-combined compilers with the SIO drivers already in place, set the initial switch register bits, and print instructions telling me what to do. Here's a dump of a simulated compile session. With a suitable PTR/PTP emulator this can be done using real hardware - to be suitable the emulator needs to be able to cycle papertape punch output back to papertape reader input, and the bcslib.rel file must already be available in papertape form to load in after the relocatable, so the emulator must have the ability to swap in additional media. I have no such hardware but that's ok, I can still run the compiled apps on real hardware using only a simple PTR emulator, which I do have. The real discovery was figuring out that adding "_" to the end of a print string suppresses the CRLF which is normally added after every print, and discovering that this trick works for HP FORTRAN as well. Such a small thing, taken for granted these days, but a big deal - for years I thought FORTRAN could not print a string without also printing a newline without the help of machine code, but all it took was an underscore. Old timers probably knew this, but I was amused to discover this is still a FAQ from modern Fortran coders, with varying solutions. Cool, so I imported the source for my Reversi-playing FORTRAN program and made most of the changes from within the HP-IPL/OS environment, updated the FORTRAN Reversi page with the new code. The process for compiling a FORTRAN program is similar, except the FORTRAN compiler is in two parts, the first binary compiles the source to a temp file and the second pass overlays the first pass (which must still be in memory) and reads the temp file to produce a relocatable file which can then be linked. This is where SFS comes in handy - alternate memory already contains the first pass so it needs another buffer from which it can read the second pass ABS from to overlay it on top of the first pass, otherwise yet another papertape file would be needed.

I can only imagine what it must have been like in the late '60's when all this stuff was done completely with papertape, I'm sure they went though a lot of it. In the '70's a HP21MX with at least 96KW memory would probably have used the RTE disk operating system and would not have required papertape for temporary files, but here in the 21st century MX-class CPU's are still fairly common and it's more practical and much cheaper to hobble together a modern disk solution and use microchips and stuff to fake papertape. Nevertheless, even though modern devices and HP-IPL/OS is used to make up for the lack of vintage hardware, it's still running vintage BCS software - the input source and the output binary is the same as it was back then.

6/10/10 - For testing, went through the process of setting up a simulated disk menu system, my notes are in the simsetup.txt file, which might get added to the archive but needs some cleaning up. For now, wordiness aside, provides step-by-step instructions for using the scripts in the testing archive to create an IDE-compatible bootable 7906 disk image. Everything worked perfectly, except for Windows... discovered that it's impossible to paste BASIC code into a command window running SimH HP2100 running MSU BASIC. That works fine under Linux, used to work fine under Windows, not sure why it no longer works (but guessing SP3 which broke other "dos" window stuff). So I documented how to get around that bug using HyperTerminal.

6/9/10 - Darn beer. I was making a 99-beers generator in IPL and discovered an issue I hadn't run into before - if a word containing a backwards >STEP isn't done correctly and crashes, requiring a restart, it leaves the step value set incorrectly, effectively (as far as a user would think) hosing the system. Not all cases of GIGO can be fixed, but this effect is pretty easy to accidentally bump into and the cure was easy - added an instruction to the kernel that sets +LOOP's step to 1 on any cold/warm start - thus once it bugs it rights itself, and no issues interrupting running programs. Testing archive updated, also added some sample HP BASIC code (including a conversion of TTY TREK).

Here's my best beer-maker so far... (no backwards +DO or other funky stuff)

;99 bottles of beer for HP-IPL/OS, 99BB to run.
DECIMAL 143 DO DUP #0 99S1 " on the wall, " $PRINT #1 99S1
56 PCHR CRLF IFZ "Go to the store and buy some more, " ELSE
"Take one down and pass it around, " ENDIF $PRINT DEC DUP
IF<0 DROP 143 ENDIF #1 99S1 " on the wall." $PRINT

Here's a zip containing a small HP-IPL/OS build containing the program, just add simulator. This version of the program properly punctuates and restocks - unlike some other examples. True, it could make better use of whitespace to indicate structure... but then it wouldn't be shaped correctly. Besides, there's already a beer-maker program written in whitespace.

6/6/10 - Close, but upon further thought, it's better to NOT clear @LLP on startup - that's too limiting, if a specific default is desired the user can make that decision with an autostart word. Now the default ERASE behavior for all builds is to remove whatever was typed in since booting the build, and if a IPL package is loaded, restarting the binary won't clear the last load point. Since the kernel no longer needs to access the variable except through IPL code, storage for @LLP has been moved from zero page to inside the word itself. Also, the DMENU program in dm2.ipl and the hpos6i.abs build now supports saving HP BASIC programs in addition to MSU BASIC.

6/4/10 - Updated the testing archive and all of its builds with a new kernel that goes beyond what a patch can do and validates the machine-coded DEFINE writes too. Since fixing the issue properly had to be done at the kernel level, I took the opportunity to also fix another nagging usage issue - easily recovering from a failed load. Added a new @LLP variable and modified <PTR and <MS (called by all other IPL loads) to set it to the end-of-dictionary before doing an IPL load, making it possible to automatically remove the last package loaded without having to determine which word the package starts with. Now it knows. Made a new ERASE word (replacing an old now-useless word with the same name) for extra.ipl/extra2.ipl that checks @LLP and if pointing to a valid word, prompts to erase from that point on. Now after a page error or if a word is not found, just enter ERASE and confirm to remove the partial load. If nothing made it into memory or @LLP isn't valid ERASE has no effect. Also useful to load an IPL, use it, then remove afterwards. A little thing, but much better. [irrelevant info snipped] These mods caused no bloat (other than using up the hole between the interpreter and the start of the dictionary), the new builds actually have a few locations more free memory than before... but only because the memory-hogging usage messages were removed from CONSTANT and VARIABLE. Nice trade in my opinion.

6/2/10 - Huh. This is proving to be one tough patch! it works, better than uncontrolled dictionary overflow, but still permits strings to overflow into block space (the string compiler in DEFINE is machine-coded and isn't affected by the patch). Only use the present patch if blocks are allocated to buffer the overflow and protect high memory, looks like it's going to take a kernel revision to do this right. But now it has become a challenge!

5/31/10 - HP-IPL/OS has always had a "feature" that bugged me a bit (especially when writing docs), there is no protection against accidentally loading too much and overflowing the dictionary. Checking free memory first usually prevents that, and when it happens, usually 0 ALLOCATE reveals the failed load so it can be removed, but still it's one of those things that would be nice to fix. This is a tricky problem to solve as every write to dictionary space has to be validated, if implemented in the obvious way (adding conditions everywhere a write takes place) it would inflate the kernel and slow down word creation. But there's another way to do it that doesn't increase the apparent kernel size at all - don't use PUT to write to the dictionary. Instead make a machine-coded "headerless" word that quickly validates the write and if out of bounds, displays an error message and warm-boots the system. There's enough room between the end of the kernel code and start of the dictionary to put the new code, then the DEFINE and ADDCODE words can be modified to use the validated write code instead of PUT. This experimental dictionary overflow prevention patch does that. Once applied it makes it impossible for DEFINE, CONSTANT, VARIABLE or CREATE to write [much] past the end of dictionary memory [strings still overflow into block memory], instead it just displays OVFLOW and stops the load. This is experimental code that does scary stuff, it seems to work fine [but has side effects, see comments]. To apply the patch, attach it to PTR and load it (<PTR) like any other IPL, it needs a bit of free memory to function but doesn't leave any words in the dictionary. If needed the patch can be removed using this unpatcher.

5/24/10 - Here's what my new SendToHP PC-to-HP PTR transfer program for Linux looks like now...

...the overflow and extend LED's blink while loading, and at the end of the transfer it lights up bits 0-5 and other LED's just like a real HP mini. A bit overboard but I wanted to give the new code a good workout and it does serve a purpose, they show EOF when loading text IPL's too so I don't have to guess when it's done - I have only one serial port so I have to disconnect the console when loading things into my mini thus can't see the normal console output.

The boxes were drawn using a few words that output unicode strings for lines and corners...

; unicode "graphics" words
OCTAL 2017 377 PUT ;patch kernel for 8-bit output
DEFINE UCST ; unicode start (for most)
161224 PWRD END
DEFINE UCHL ; horizontal line
DEFINE UCVL ; vertical line
DEFINE UCUL ; upper left corner
DEFINE UCUR ; upper right corner
DEFINE UCLL ; lower left corner
DEFINE UCLR ; lower right corner

These aren't in their own package, just part of the sendtohp.ipl package in the new archive's ptremu material. Each word just writes a unicode string, so doing say UCUL UCHL UCUR CRLF UCVL 40 PCHR UCVL CRLF UCLL UCHL UCLR CRLF draws a box on the screen. This technique is for Linux where console terminals support ANSI and unicode "graphics", the sender app itself depends on being able to access the serial port as a simple device file from which it can read from and write to just like any other file, leaving me free to write apps in anything I want (including simulated IPL). To do anything like this under Windows would take a "real" PC language such as FreeBasic or Visual Basic - but I already made a sender called HpLoader for Windows long ago, no depiction of a minicomputer with blinkenlights but it does blink. As far as terminal graphics though, the Windows Hyperterminal program supports ANSI color - select the ANSI or ANSIW emulation - and line characters are available by unchecking "Force incoming data to 7 bit", selecting the Terminal font, patching HP-IPL/OS to allow 8 bit output by doing 2017 377 PUT, then printing characters from this chart (here's the low chart to go with it).

5/22/10 - hehe shouldn't have said "quite" [5/21] - the code-spite principle struck again and in the process of fixing up my new SENDTOHP file-to-PTR transfer app with color and unicode "graphics" I found a bug in the COLOR word - won't do dim forground on a color background. 17 4 COLOR CLS works and makes bright white on blue, but 7 4 COLOR CLS for dim white on blue sets the background to the terminal default instead. After looking at the code I saw why, it's all screwed up (wrote it long ago, worked for what I was doing at the time, didn't notice the bug).

Here's the original COLOR code...

 ESC #0 SWAP 000050 ADD $DSTR "0;" $PRINT $PRINT 000155 PCHR 
ESC DUP CASE > 000007 "1;" 000026 DEFAULT "0;" 000036

That's just wrong. Outputs parms in two escape sequences, and if a forground < 10 octal specified, the second esc seq outputs a 0 which resets the background to default. 17 4 COLOR should output <esc>[1;37;44m and 7 4 COLOR should output <esc>[0;37;44m - all in one escape sequence. Here's some corrected IPL...

 ESC SWAP DUP CASE > 000007 000026 030473 DEFAULT 000036
SWAP 000050 ADD $DSTR $PRINT 000155 PCHR

The COLOR code is in screen.ipl and hpscreen.ipl (in hpscreen it's in a condition branch to only use if not in HP terminal mode). It's fixed now in the linked text files, along with making CLS and -COLOR more efficient. But this changes everything! Many builds need to be rebuilt, plus all the other builds scattered about. Because many of these already carry a 1.54 version number and it'll take awhile to fix them all, the new builds and archive with the fixed COLOR will be called version 1.55. Oh well. Fairly minor thing but I like things to be right, especially now that more and more I'm writing simple PC apps in IPL running under simulation to avoid the complexities of modern PC programming for trivial things. Updated the hpiplos_main_testing archive, now 1.55.

Another archive addition I need to make [done] is include the QBasic source for OCT_TOOL - I use this constantly to figure out the packed octal equivalent for text strings. Another thing to document - Unicode. To make nice-looking Linux apps using HP-IPL/OS I need unicode support to make boxes and other graphics, but the stock kernel only allows 7-bit output because 8-bit output can cause bad effects with some terminals. For the present kernel doing 2017 377 PUT switches it to 8-bit output to permit unicode strings. For safety check first to make sure the current value is 177 before patching. This could be a package with words that print corners and lines - UCHL UCVL UCUL UCUR UCLL UCLR to print horizontal and vertical lines and upper-left, upper-right, lower-left and lower-right corners.

5/21/10 - OK, sometimes I take a long time for a seemingly simple edit... however (other than the printer driver) the 1.53 package is quite solid as far as I can tell - if the new edit and print IPL's, summary.txt and demo build are added to the hpiplos tree, then it mostly makes it 1.54 as far as the existing code is concerned. The printer driver in existing systems can be fixed by entering the commands from the 3/16/09 entry, so there was no hurry. The new archive has progressed far enough to share as a "testing" version, it's at: http://newton.freehostia.com/hpiplos_main_testing.zip

The archive is subject to change depending on proof-reading, testing and feedback, and isn't the real 1.54 package until it gets posted to the main page. Changes won't necessarily be noted here but so far the new archive includes the following changes...

Includes the replacement edit.ipl and print.ipl packages
Builds containing print.ipl were rebuilt - hposdemo.abs, hposide.abs and hposidem.abs
Added a new 8KW build containing MAZE, and a new 64KW utility build with binary hacking tools
Added 8kextra2 package with a more complete set of words for 8KW builds
Added extra2 package with fewer words for more compact builds for larger setups
Added double2 package without EMUL EDIV to work on older machines or with small CREATE
Added bugs2 package that paints colored patterns on an ANSI-compatible terminal
Added a slightly modified version of Tim Riker's version of Eric Smith's Asm21 cross-assembler
Added assembly source for MSU BASIC along with docs and notes describing how it was patched
Added notes about HP BASIC including patching for HP-IPL/OS (and finally figured out how to CALL! yay!)
Added notes about patching SIO and configuring a HP-IPL/OS-compatible version of the BCS linker
Added notes, VDOS packages, and 8052 code for the IDE/USB VDRIVE mod - stores files on a thumbdrive
Added Visual Basic source for the HpLoader app for transferring PC files to a PTR emulator
Added a new HP file sender app for Linux - it's written in IPL :-) (feeling the urge to tinker with it more)
Added an html file to the root linking to the documentation files, includes more docs and examples
Root docs (besides readme) and new docs moved to a new docs directory to reduce root clutter.

It's a fairly extensive update but is mostly about tidying up docs and adding new tools and info, none of the existing code has changed since March '09. I'm sure there are bugs but so far haven't run into anything worthy of changing. Most existing odd behaviors (like being able to overflow the dictionary) fall under the category of "feature" and probaby won't change anytime soon - GIGO - I'm only concerned with actual bugs like stuff not working. Lots of new stuff was added but tried to keep the size increase minimal (the zip is roughly 300K larger), most of the added stuff is available elsewhere but putting it in the main package makes it available without having to search. More importantly, it ensures that the sources and binaries match, and makes it less important that the pages currently hosting the info remain up. Even this infionline site might go (it's my old dialup account from the '90's and costs me magnitudes more than the equivalent amount of webspace elsewhere), no plans to take it down but just in case my entire infionline site is mirrored here, here's the mirrored HP-IPL/OS entry page.

3/16/09 - The printer driver had a bug causing it to work under simulation but not with a real printer. Fixed in the web files archive, the full-screen editor builds, and the 7906 disk simulation build. Still working on docs and stuff for the main HP-IPL/OS archive zip, will update that when it's ready. If needed the old printer driver can be made to work on real hardware with the following patch...

To fix an already loaded !PRN driver do...
which should say 102720, if it does then enter...
"!PRN" $DEFADR 21 ADD 103720 PUT

...assuming the printer interface is in slot 20, otherwise adjust accordingly. Note that the new printer driver is named !LPT and the *PRN words have been changed to *LPT. Also has new words for printing without having to use MS redirection.

10/18/08 - I made a simple mod to my HP/IDE disk interface - added a VDRIVE2 USB module and new code for saving and restoring disk image files to a "thumbdrive". With the help of a fairly compact set of words I can also read and write files on the USB drive from HP-IPL/OS via the MS stream system, it isn't truly papertape compatible but as far as HP-IPL/OS is concerned it might as well be, can use standard commands like SYSALL LOAD ABSLOAD etc. This is nice as I can directly save work I do on the mini, and I have all my IDE files on the thumbdrive for quick access. Project details on the ideusb page.

9/7/08 - didn't go too crazy but now that the line editor is marginally usable, fixed it up a bit by adding a ?EDIT help/status word, declaring a ~PAD variable if it needs to cross a page boundary to avoid page errors, renamed MCL to MLP because it moves the line pointer (not the line itself), and added code to FOPEN to avoid raw error messages if a file is already open and print a warning message if not a CRLF-terminated file. And (finally) used the fancy search/replace function of my PC editor to get rid of the raw word names but didn't attempt to structure or comment the old code, as long as it works I don't care. Until the need arose to edit a library file on real hardware this crude little editor was pretty much ignored other than occasionally using under sim where its slowness wasn't a problem. One advantage of editing using line edit words rather than an app is the prompt remains available... other files can be displayed for reference or to copy code from, calculations made, even the output of other commands can be appended to the file being edited...

  EF 0 >FILE >MS
  [any command that outputs text, goes to the open file instead]

9/6/08 - ok that's better! even though not optimized the new edit2.ipl version of the edit words only takes a few seconds to insert or delete a line. Was many dozens of seconds. The new version prints [WORKING] when moving memory, and the previous DCL command to delete a line is now DLINE to avoid accidents. The BMOV machine code might be useful for other projects... usage is: byteaddress offset #bytes BMOV - moves the specified block of bytes forward or backwards in the currently selected alternate memory page (n USPACE selects, n=1 for SFS buffer 0).

[There may be a FFP instruction that does something like this, but haven't found a reference yet - to be useful it'd have to copy large blocks of bytes forward/backwards by any positive/negative even/odd byte offset, BMOV adjusts the loop direction according to the offset direction to avoid overwriting what it's copying.]

9/5/08 - in "fixing" edit.ipl's comments I added a note that the edit words don't save the MS vectors, actually they do. Corrected in text archive copy, not bothering with main zip - if all goes well then it'll get replaced by a new version with machine-coded byte moves.

9/1/08 - new 1.53 archive posted with updated dm2 disk menu, new sfslib library system and updated IDE builds containing the library words. Docs could probably use more work, but that'll probably always be the case. I found a new use for an old app - the old edit.ipl SFS-based line edit words. Right now it's the only thing that'll edit a variable line length text file such as a library, I actually used it on real hardware to edit a library segment from my sim to compensate for not having certain words in the hposide.abs build... slow isn't the word... [got the job done but need to machine-code the byte-shifting memory moves and provide feedback when it's doing that... even as fast as it can inserting or deleting a line in a large file is going to take a fair amount of time, I'd be happy with a few seconds.]

8/30/08 - worked on the SFS library system... the biggest change is getting rid of the legacy binary byte marking the end of the library file - I put up with it until it broke LFORGET when I overflowed the library (on purpose to see what happens). With the new sfslib.ipl package the library is just a plain text file that can be edited on a PC or even using the old SFS edit.ipl line editor. The previous A2L/L2A/MS2L functions are now built into the package and will be removed the next time the main archive is updated. Another major change is the library utilities are now named to be consistent with other object copies (as opposed to file transfers, library segments are not files but things in a single file), D2L, A2L, L2A and MS2L become D>L, A>L, L>A and MS>L (which now no longer requires specifying the number of bytes). Fixed a few bugs while at it.

8/19/08 - new dm2.ipl posted to the text archive... the only real bug was forgetting to drop an empty string after pressing just enter at a filename prompt to cancel a save.. things like that are rarely noticed unless every function is tested, then exited and the stacks checked. Of course that's one effect of putting something into the main zip archive... kind of backwards but happens frequently with this little hobby project - I'll use something for months, not do anything to it then think "well, seems stable", put it in the zip then the extra scrutiny of it being "official" causes all sorts of things to be noticed. I like to think I found and fixed everything but that's just not reality with any non-trivial piece of code, free or otherwise. There's always another issue, the goal is merely to make them so insignificant they don't matter.

The dm2.ipl menu now doesn't require msupatch.ipl, it still uses it as before to patch the info text etc of MSU BASIC binaries before saving them but only if it is loaded. I considered adding direct support for the vintage HP-BASIC interpreter but my diminishing free dictionary space convinced me otherwise. To patch an HP-BASIC program to make it autorun using the dm2.ipl menu requires one keypress for the prompt, entering 3 5137 APUT then DMENU to run the prompt, pressing another key and entering a name, that's easy enough. Define a word to not have to remember the numbers. Besides, the older and simpler and much smaller dmenu.ipl already supports patching/saving HP-BASIC programs. Other changes include printing the build's version string as the title, and rewriting the input prompt so that it reprints the prompt if an invalid key is pressed (the invalid key remains under the cursor, that's useful to see what was pressed). Escape sequences from PC keyboards like the cursor keys still cause inadvertent running (they contain A B etc), no code wasted on that.

Still working on docs.. particulary involving the SFS library. The library code is working well but some of the word and package names might change... since D2L and A2L append to the library they might make more sense if called D>L and A>L instead.. also the present A2L is much easier to use than the old MS2L utility for importing multi-word IPL code into the library, wrappers to make MS>L or F>L (file to library) would be easy to make so MS2L will likely get dropped from the zip archive.

8/17/08 - found another dm2.ipl menu glitch.. the text import function had bad code for skipping the leader zeroes (I don't use PTR text files with leaders, used a hex editor to make one to test). Updated in text files archive. Wouldn't have bothered with this little detail except that some interfaces require a leader, and real papertapes always have them. The new docs are coming along except the SFS/library docs ended up far too large and confusing, starting over. One of the sidetracks was to effectively use the library certain IPL's need to be imported to the system, and the old MS2F utility for doing that 1) doesn't skip leaders (it's a straight binary-capable copy, must position the PTR input file so the first byte read is really the first byte of the file) and 2) requires specifying the exact byte size. These properties don't bother me (and permit the exact transfer of any content), but make the utility somewhat inconvenient to use. So wrote a couple of new SFS-based importers for text-only files. The PTR importer skips leader 0's (leading to eyeballing the dm2.ipl leader-skip problem), another importer permits direct pasting of text into a file (typically IPL's containing CREATE code can't be directly pasted to the console due to the long "fixing..." delays). When I get it together the new archive will include an IPL "notes" file containing short descriptions of all the included IPL's, trivial IPL's like the text importers, SAVE etc will go into this file rather than bloating the archive with extra files.

Here's the SFS-based text/IPL file importer (for now)...

; copy/paste into a file, req's SFS 8/17/08
; usage: "FILE" CP2F
; ...then paste text into the terminal.
; when done enter ~TERMINATE~ on its own line.
$VOL #0 DRV GET DIRECTORY ;get directory of current vol/drive
FSS GET IFNZ $DROP ELSE ;if no error
 $DUP #0 CNF FSS GET IFNZ $DROP ELSE ;create new file, if no error
  #0 OPEN #0 >FILE DO ;open file, redirect MS to it, begin loop
  MS$IN "~TERMINATE~" $EQUAL ;get line, push a 1 if at end else push 0
  DUP IFZ MS$OUT MSCRLF ELSE $DROP ENDIF ;if not end, write line to file
  #0 CLOSE ;close and save file
 #0 RELEASE ;release buffer
MSPAPER ;put MS back to default PTR/PTP

This needs to be used with a terminal emulator (such as HyperTerminal) that permits setting character and line delays, adjust for error-free transfer. Enter ~TERMINATE~ on a separate line (or add to the text stream being sent) to stop the transfer and save the file.

8/12/08 - well of course I discover a glitch after updating (has become a useful debugging technique), this time a misplaced CRLF in the dm2.ipl disk menu when it's used to save an imported binary to disk.. filename prompt didn't drop to the next line. [...] Working on new docs to include and removing a couple outdated IPL's from the zip such as the original (slow) library from the zip archive, the new one is dramatically better and works well on real hardware... near-instant seek time [...but still being worked on]

8/10/08 - The editor and sim builds are now updated with the latest SFS code. While at it made a few changes... the SFS/EDIT build in the editbuilds.zip archive (on the editor page) is now based on the version included with the 7906 sim package (the one I use on my HP2113E), the only difference is the addition of the printer stuff and HP2645 words at the end so they can be easily removed if not needed. This is a much more versatile build (no magtape words) for making new builds with ranging from SFS/library systems, XDOS systems or even compact disk-less systems. The "standard" editor build still includes magtape but added the SVMT and LDMT words to the build (previously only listed in the docs) to permit saving and loading edit files to and from the (simulated) magtape drive, the stuff is there so might as well use it. Updated the editbuilds.txt docs with magtape/disk simulation instructions and yet another attempt at explaining how to rebuild HP-IPL/OS for different applications. In a related experiment, I confirmed that it is possible to use HP-IPL/OS to write a magtape file that can be read by RTE-6/VM - while testing another curious bug wrote a utility that converts a tar file into a magtape file that can be read using RTE's TF utility. The bug ended up being that TF requires that files in the tar be in unix-format with LF-only line ends.. otherwise the CR's end up in the records causing all sorts of problems.

For the simulator, in addition to updating the SFS parts, added the new A2L.IPL package that permits copying edit data to and from a library, this makes crafting multi-word run and forget library apps much easier. The NOTES covers setting up a library (specific to the sim) and using SFS to redirect the output of multiple EXPLAINs into a file then using the editor to fix it up into a library application, dependencies and all. Existing run-and-forget apps such as the editor can be easily edited (essentially change the ending CONSOLE to LIBEND) and copied to the library, can even load library "files" into the editor (but has to be the last file to replace, works like a magtape - unless I can figure out how to delete a chunk from the middle...).

8/9/08 - Updated the main archive to v1.52, or more precisely 1.51/1.52 as the non-SFS builds did not change. The 8/2/08 "discovery" (that SFS could destroy a disk directory if the buffer memory didn't exist) sent me into an editing frenzy... although nobody expects a computer to work with bad or nonexistent memory the ease of operator error with drastic consequences demanded a fix, which was to do a brief memory check in SFS' DIRECTORY word to ensure that the memory actually works before buffering a directory, otherwise just say "Bad memory!". The unforseen "problem" came about in two ways... no fault is generated (that HP-IPL/OS sees) if non-existing memory is written to or read from, and an all-zero directory block (returned if the buffer memory isn't present) is perfectly valid if there are no files. Leave it to me to shove mis-configured memory into my machine and wipe out all my files with one SETLIB command... boy was I surprised! but in my case no harm done since my IDE disk is generally just a copy of the 7906 simulation disk. I since found the docs on BitSavers to set the switches on the extra memory cards, SFS and the library now work.

Since an update was needed anyway, moved the "testing" code (which hasn't changed in awhile) to the new archive, mostly related to using MSU BASIC from HP-IPL/OS. So that the new code has a target the archive now includes a 31KW MSU BASIC binary that can be added to HP-IPL/OS disk systems. The "real" HP BASIC is still supported but I've found that for just about any pure P.T.BASIC program the patched MSU BASIC is just as good, and requires no further patching after entering a BASIC program to save to a binary file making it easier to use from HP-IPL/OS, just enter code, BYE and "FILENAME" 174000 AM2F to save to disk (the same command used to save any other 31KW absolute binary from alternate memory to a disk file).

Also added brand-new IPL's bkfile.ipl (BKFILE and REFILE) and a2l.ipl (A2L and L2A) to the main archive, these probably should be in testing but they're not in any builds, if I have to fix them later then so be it but the extra functionality should be present - BKFILE permits dumping any file to the console as encoded text so now if I create something great on my machine I'll have a way to actually save it before doing crazy stuff that might result in data loss, without PTP on my machine I can't use F2MS or other papertape export options. REFILE permits pasting the encoded text back through the console... I'd hate to have to use it to restore a bunch of files over serial (would be painfully slow) but most of my stuff is already in raw form or on the 7906 sim disk, and I can use the faster simulation to decode the few new things back into raw or simulated disk files. The A2L utility permits using the AEDIT editor to compose or fix up multi-word SFS library "files", adding a lot of functionality to the library system. Previously multiword apps had to be imported from PTR or a redirected file using MS2L, a rather large and picky utility requiring among things having to specify the number of bytes to import. Now I can just load or compose a library app using the editor then do "NAME" A2L to copy it to an open library file, much better. In case fixes are needed and to permit copying library file chunks to another library or a disk file, a matching "NAME" L2A copies the named chunk to alternate memory, space-padded and ready to edit or do something else with.

The docs in ide_buildinfo.txt have been changed, in particular instructions regarding using the Linux dd command to copy a disk image file to a real IDE disk. Previously Linux labled internal IDE disks hda hdb etc and external or SCSI disks as sda sdb etc. An external USB disk tray used to appear as sda, but now after updating my OS to Ubuntu 8.04 I found that sda is now my main hard drive - good thing I checked before using dd to update my HP's IDE disk! dd is a powerful command for copying files to disks but with power comes extreme data danger - can totally trash a PC if the wrong destination is typed. The previous docs fully warned about that, but now includes a somewhat safer script that ensures the specified device does not exist until it prompts to attach it. Also, put Bob's original IDE bootrom back into the archive, the CLC 0 I added probably isn't a good idea, and HP-IPL/OS now does this anyway so there's no need for the bootrom to do it too (wasn't that important anyway).

The things I do... write and support an OS that only a very few dedicated hard-core hackers actually use... sure why not [...] But there's more to it than just writing code for nothing (although that alone is very enjoyable) - HP-IPL/OS is an OS, and it runs the most primitive and oldest form of HP21xx software - the absolute memory image. These bits of antique code are the real stars, and there's a shortage of it. MSU BASIC helps fill the void, many of old-style BASIC programs that can get by with numeric-only input can be converted to run under it. Learning FORTRAN II was a pleasurable experience, of course the only thing I wrote for it broke many rules to implement recursive subroutines using only GOTO... although distro of the compilers and stuff is still unclear, at least the SIO/BCS stuff resulted in a few more things to run using HP-IPL/OS including a prized vintage Chess game. Slowly but surely more old bits are coming to life, lately I've been playing around with another old HP mini OS... RTE-6/VM. I put together a small collection of games in hpgtapes.zip that can be run as-is on a primary system. Reconfiguring the system proved to be quite involved but fortunately I had expert help, eventually was able to put together an "answer" file to set up a more useable configuration but I still have much to learn. Email if you want what I have so far.

8/2/08 - I discovered an issue - if SFS is used to update a file and the specified buffer memory does not exist, the result is the loss of all files in the specified volume.. ouch! [...]

4/9/08 - ok going for it... main archive updated [1.51J].

4/8/08 - the 3/29/08 editor update still had a bug in the LDFILE word, fails when loading files that take up the editor's maximum capacity. Simplified this word so it is little more than "FileName" ZAM F2AM and doesn't attempt to clear alt mem after the file, and added extra code to the TRCAM word called when exiting AEDIT to ensure junk after the end of the file in alt mem is zeroed (at least what matters). The new fed.ipl also updates the screen one character at a time to reduce cursor "wiggle". Incorporated the new version into the edit builds and the 7906 disk sim, if it remains stable will update the main HP-IPL/OS zip with the new version to get the bug out. The other new IPL files (dm2, msu/binpatch etc) will probably remain in testing for awhile to see if anything else gets done to them.

I've been pounding the editor pretty hard both under sim and on real hardware - the present version works fairly well (for me) considering it emulates a typewriter that can insert and delete lines, overwrite text and (slowly) move text on the current line. It certainly has its quirks but due to the severe speed limitations of a 2400 baud connection and a sub-mips processor not sure what can be done to improve it besides possibly adding functions for splitting lines and jumping to the end of a line. Or just start over and rewrite the whole thing in machine code but that won't help a bit for the slow terminal. The alternative would be a command line editor in the style of EDIT/1000 or the original SFS file editor but I'd rather have a slow full-screen page at a time editor with no features beyond movement than try to edit text using a command line. Some people can use command line editors but I can't.

I still haven't found the "perfect" PC terminal emulator for real hardware yet, ProComm for Dos works the best but has no scroll-back buffer so it's inconvenient (but still probably better than what I'd get using a real terminal, at least if I have to I can capture text to a file). I have hopes for dterm, at least it's simple and small enough to hack (and possibly make it emulate some HP terminal features) but it presently has a couple of severe problems - it locks up when cursoring around in the editor, and doesn't buffer keystrokes so drops characters if the editor is currently updating the screen making touch-typing impossible. MiniCom is not useable either, it intercepts some control-keys for its own use making it impossible to use not only with the editor but other HP programs like OCTAPUS. I gave up on HyperTerminal, it used to work fine but now I can't get it to operate at the baud rate and bits I tell it to and (incorrectly) sets itself and fails when other old-comp software is run. For my HP mini console I need 2400/7E2, period.

3/29/08 - update done, now the sim, editor builds and main archive all contain the same editor version (for the moment anyway). The "official" version is still called FED.IPL, same code as the previous "experimental" AEDIT.IPL version but with the extra IPL features added to adapt to different builds and avoid page errors when running from DMENU or the library. The new version isn't that much bigger than the original, has faster screen updates, and doesn't cause files to grow with successive edits, so not much point keeping the original around.

3/28/08 - maybe I better keep it simple this time around and update just the editor and its utilities in the main zip file, and let the new code reside in the 7906 disk sim and scattered about this page for now where it can be easily fixed if a problem is discovered. I don't want to burn a version number on dumb bugs that affect only one build (hposdemo.abs) so letters to the rescue... barring new discoveries the new version will be 1.51G to match the sim version containing the same code, and remain consistent with the other 1.51 builds which aren't affected. Makes sense... 0.1 clicks for kernel changes, 0.01 clicks for changes to IPL's which affect most of the builds, and letters to indicate other versions like the 1.51C utility build included in msubasic.zip and the 1.51G version with editor updates.

3/27/08 - [found a few bugs in the editor's utility package, fixed in the text version of fedutil.ipl, the 7906 disk sim and in edit builds on the editor page.]

3/22/08 - updated the new disk menu [dm2.ipl] to avoid renaming files (to no name) if nothing is entered at the new name prompt, changed other text to make it slightly smaller. Updated the sim package with the new menu and hopefully better docs. Download details now on the 7906 Disk Simulation page.

3/15/08 - the disk sim is back! The new disk menu looks like this...

======= HP-IPL/OS Disk Menu =======
A) Binary 31KW MSU BASIC B) Binary TREK
C) Binary HAMURABI D) Binary OTH
G) Binary CHESS H) Binary 31-ODD
1) Exit to prompt 2) Clear alt and halt 3) Load ABS from PTR
4) Delete file 5) Rename bin/txt file 6) Import/Export file
7) Save binary 8) Display binary data 9) Punch ABS to PTP
Press a key:

This version was written especially for the sim with MSU BASIC, requires altutil.ipl, fcam.ipl, sham.ipl and msupatch.ipl so for g.p. use it's a bit bloated. But if using MSU BASIC and especially for the sim, sure makes a useful boot system. All the import and export functions are a few keystrokes away, and best of all the import text feature on the import/export file submenu does not require having to specify byte size. Since it's strictly for text, it can simply stop when the trailer zeroes are detected. MS2F is for anything so it can't change, the only way to load an arbitrary block of data that might contain a bunch of zeroes is specify the size, but it'd be trivial to extract the new import code and make a TX2F word for doing text. Makes a huge difference, importing text and IPL files used to be a fairly involved ordeal but with the new menu features pretty much built the whole sim using just the menu, at least until I got to the menu-free SFS/AEDIT build.

While editing the sim docs I discovered a risk of "run and forget" - when running FED from the menu when I was done said y instead of Y in response to the save prompt (was in lowercase mode), I didn't get a second chance and the software to recover had already been forgotten. Got my file back using manual XDOS commands (eventually) then immediately edited the editor to drop the save prompt and make it try much harder to actually save something. Only a problem when running from a menu like in the sim, so it has the fixed version, and the raw AEDIT.IPL file has been updated. I'll get to the edit builds eventually but when running from an actual edit build just SVFILE if that happens. I'm pretty much only using the experimental version now, didn't grow by all that much and it does work better, so considering making it the main version with the next main archive update. Whenever that might be.

3/9/08 - Here's a binary alt-mem to file SAVE word... (until I figure out where to put it)

; SAVE - saves a binary in alt mem to disk  3/9/08
; Uses loc 150 for temp
2 150 #1 A>CCOPY ;copy loc 2 in alt to loc 150
150 GET 124003 SUB IFZ ;make sure it's a binary!
"File to save: " $PRINT $IN $TRIM
$DUP GetFile IFNZ ;if file exists
DROP DROP ;drop disk location
"File exists. " $PRINT
$DUP XDEL CRLF ;prompt to delete file
$DUP GetFile IFNZ ;if file still exists
DROP DROP $DROP ;clean up stack, don't save
174000 AM2F

Nice for saving MSU BASIC programs... or any other system binary in alt-mem. While taking a "break" I fired up the machine to goof around a bit and tried to paste in a BASIC program and it wouldn't work, not surprising since ProComm under DosEmu under Ubuntu has always had screwy upload timing. No problem I thought, booted into XP and ran HyperTerminal. I haven't used it in a while, discovered its behavior had changed and my 7E1 setting I normally use was something else (7S something) and no matter what I did it wanted to "autodetect", would not honor my setting wishes, and would not connect to MSU BASIC [...apparently HyperTerminal incorrectly readjusted itself to what it thought HP-IPL/OS used]. Tried minicom but too much stuff and only offered line delay (need character delay too), but after a bit of searching I think I found something I can make work... dterm. It's just a small "C" file, adding delay code should be easy enough. It doesn't try to be a terminal emulator, rather simply connects the serial port to an existing Linux console terminal, which already has term-emu selections. With dterm (and minicom) the ascii-127 TTY "rubout" characters show up as garbage, will have to do something about that. [update... dterm works perfectly with MSU BASIC on real hardware if it's run under konsole, just needs paste delay.]

3/7/08 - 31KW MSU BASIC files notes and stuff moved to the 31KW MSU BASIC page. Whew! nice week for hacking! [snip] MSU BASIC's TAPE command appears to be for something that isn't simulated by SimH HP2100 so had to figure out how to slow down pasting speed. At first was having to use a telnet connection to HyperTerminal under Wine or VMware but figured out the trick... d tty ktime 40000. The hint was the d tty ttime 400 setting that was needed to get MSU BASIC to run reliably (ended up increasing to 1000, otherwise LIST would intermittantly fail), read the docs and found the ktime setting.

2/17/08 - Updated readme_bats.txt to correct slightly incorrect info and add instructions for setting up telnet or HyperTerminal to use screen codes (CLS, POS etc) with an XP simulation.

2/14/08 - Updated to 1.51.. managed to cram in the CREATE patch with no overall change in size by editing a few messages. Also fixed a few things in the editor's utilities and made the MS2L utility compatible with the new lib2.ipl library system. Removed the XY stuff from the "demo" build, instead it now contains the editor and the printer driver. Added the print driver to the "ide" and "idem" builds, added the MT2F utility to the "mt6i" build.

2/12/08 - [CREATE fix details removed, in 1.51] Here's the (corrected) DMATEST program that let me know what happens if ASC is incorrectly coded...

 OTA 6
 CLC 2
 OTA 2
 STC 2
 OTA 2
 STC 6,C
CW1 OCT 120011
CW3 OCT 177771
  OCT 15
  OCT 12

...but even after hosing my simulated system (by forgetting the 5, after ASC) I was able to recover my AEDITed source from alt mem by manually loading and running the editutil.abs binary and doing AEDIT, this time saving my work. With a properly working DCPC board this code should print "HELLO" to slot 11 (TTY). On my HP2113E I get no output (but no crash) - I suspect that's why the XY stuff no longer works but before making conclusions I need to verify that the above test actually works on real hardware.

2/10/08 - [shock horror CREATE crashes HP-IPL/OS if it encounters a bad ASC line...]

2/9/08 - My HP2113E's XY board (or something) isn't working so I can't test the XY graphics stuff (no longer works with old code either), otherwise everything looks fine [looks can be deceiving :-] so going ahead with the HP-IPL/OS 1.5 update. The new archive now includes a version of the original FED/AEDIT words, not perfect but far more useful than the old line-at-a-time edit words, seems to work, and can serve as a base for branching off enhanced versions. None of the included builds contain the editor, if you want it make a custom build containing it, or get one of the builds from the editor page, where enhancements to the base editor will be posted to keep them from impacting the main archive (unless I find a bug in the base code). The simscr directory has been renamed to scripts and now includes Windows versions of batch files for assembling HP asm sources with Asm21 or HPASM, and for "running" ABS files by double-clicking them. Not really needed just for spinning builds (just associate .sim files to a text editor and the hp2100.exe simulator), but they avoid having to drop to a dos prompt to do those things. I tried to document how to use the build scripts... I don't mind making custom builds if requested (not like it happens often) but I do think better results can be obtained if the person needing them decides for themselves which modules to include and which to leave out, otherwise (as with the provided builds) I'm pretty much just guessing. But of course feel free to email me if you need help or have any comments.

1/29/08 - Working on a new HP-IPL/OS 1.5 version.. it's time to do away with the dummy interrupt vectors and replace them with NOPs (with corresponding changes to CONFIG and other things that mess around down there), and add a CLC 0 instruction somewhere in the startup code to clear all device control bits and resolve an issue with "stuck" interrupts causing slower than normal speed after booting from the old IDE boot rom. So no need to burn new roms, the old ones will work just fine. I made a few changes the kernel and Octapus-D source to be compatible with Eric Smith's Asm21 assembler, with the help of a wrapper script I can now right-click an assembly source and get an abs file, leader and all. The source changes are trivial, just have to make sure ASC statements with an odd number of characters are space-paded to avoid the line end's CR becoming the extra character [Asm21.pl also works under Windows using ActivePerl].

Summary of recent web stuff... the TSB-E page has been removed, the programs from it are now on the HP Games page and should be importable into any TSB-E image. Removed non-working links from the BCS and BASIC how-to files, the tools and much more should all be available in due time - the Computer History Museum has been authorized to distribute vintage HP materials, just has to be gathered up and organized. Details of the deal are posted on BitSavers under bits/HP.

1/10/08 - Fun stuff... many (most?) HP terminals can display graphical characters. Character code 16 octal (from HP-IPL/OS, 16 PCHR) switches in the alternate characters, 17 octal restores normal characters. QCTerm is a free Windows-based HP700/92 terminal emulator which can connect to SimH HP2100 via telnet, here's the output of a test program...

I'd like to find is something that simulates a HP264x graphics terminal, 8080 and all, for running terminal games like Invaders, Life, Mastermind, a driving game and others I ran across digging through archives. Real HP700 terminals have a 264x mode but not sure how far it goes.

I threw together an array-based full-screen editor which supports HP graphics characters, on a HP-compatible terminal it can do stuff like this... (these dumps made running on QCTerm)

After loading from alt mem by doing 2 MSUSER <MS it looks like this in the dictionary and when run...

In the edit file graphics characters have bit 7 set so the editor knows to send the control sequence to switch in and out the alternate character set. Most terminals ignore bit 7 but not always, a dos-based terminal will likely display garbage but in that case graphic characters would be inappropriate anyway. I haven't tested this with a real HP terminal, hopefully they ignore bit 7. If not a console out driver that clears bit 7 will have to be written to make use of this facility (not difficult). In past testing QCTerm sometimes changed the graphics status of characters when cursoring around but not always, seems to be related to sim speed might be just a environment effect. If it happens use control-V control-C to refresh the page.. or avoid cursoring through graphical doodles.

To get QCTerm to work right I [had] to select "autolf" mode to make it send CRLF enters, otherwise after entering lines the next character typed is ignored. Probably a sim thing [was], I suspect nuls are being echoed back to the terminal and it doesn't like that [not quite, was an intentional "feature" of QCTerm for HP3000 compatibility, this has been compensated for in the new SimH v3.8-0 HP2100 simulator]. Note... the nolf.ipl file should be loaded any time HP-IPL/OS is used with a terminal that outputs CRLF when enter is pressed, otherwise the LF becomes a part of input strings. This was an early design decision that I kind of regret now... don't be surprised if one day the kernel $IN word gets reprogrammed [but likely not].

[see the editor page for more info]

Here's a handy little word I wrote for transfering a magtape file to a disk file...

? ;I want to copy ECAL.IPL from magtape to a disk file
? ;named "$ ECAL" so DMENU can run and forget it.. so..
File 000031 ECAL.IPL File 003535 words
? 31 "$ ECAL" MT2F
Saving alt to 000000 002347 **
$ ECAL 000000 000000 000000 007272 000000 002347 000000 000046
? ;did other tests, works, want to keep the MT2F word so...
Saving boot system to disk...
Done, status = 000000

MT2F is especially handy for transfering simulated magtape files to a real IDE disk and have the files available when I boot my HP2113E (with no magtape). The alternative is to copy each file from papertape to disk which requires specifying the size of each transfer (ABS and IPL loads get around this by structuring the data but that's not helpful when copying a stream irrespective of content, so the user has to tell it how much to transfer). The make_mt dos utility and a batch file can turn an entire directory of files into a SimH HP2100 magtape file in one step, once in magtape form it's a lot easier to make custom builds and copy the files elsewhere.

[now in MT2F.IPL with comments]

12/18/07 - HP-IPL/OS version 1.4 posted with many [or a few compared to PC software] fixes and tweaks, see changes.txt for the nitty gritty details. The most significant fixes were to DMENU to fix the IPL load and forget feature, and to eliminate a lockup condition when certain kernel words were EXPLAINed with certain code in certain locations. More CLC fixes have been applied to the kernel, IDE and BACI drivers to avoid blocking lower-priority interrupts. The readme.txt file has been expanded with more detail about what HP-IPL/OS does, and now that I can test IDE builds they've returned to the main archive along with plans for my version of the IDE interface. Added a printer driver.

12/2/07 - Pictures and a schematic of my IDE interface are on a new HP Minicomputer Projects page [url changed]. It's still kind of under construction but close enough. Not to imply the software is stable :-) I'd like to figure out how to make the 8052 code not care as much about what kind of interface board is used, which might require changing the IDE driver to use a different method of obtaining drive status.

11/30/07 - The IDE interface works. Only took 2 tries... first try the jumpers on the "DUP REG" board were wrong and all I got was garbage (and it erased every block I tried to read, had to rewrite the image). The jumpers should be set W1 to +12, W2 to -12, W3 to -2, W4 to B, W5 to B (these two were to A, changed), W6 to B, W7 to A, W9-W12 out, W13 to A and W14 to A. There are still problems, possibly related to my board not having jumpers W9 to W14, it appears to be operating in registered input mode. Specifically, the 8052 code does not appear to "flag" the status word after doing block writes, reads are OK but after a write <IDE hangs (still reads the disk command that was previously flagged into the input register so it thinks the drive is busy). To fix this I hacked <IDE so it always returned 0.. "<IDE" $DEFADR PNUM, then change the next location from 114241 (call to the status sub) to 2400 (a CLA instruction). After doing that it worked, could load and save things to the disk. Because <IDE after block reads is OK but not after block writes I think this is something that can be fixed in the 8052 code, looking into it. For now the code requires a non-registered interface board to function as-is with the unmodified IDE driver.

Another relatively minor issue I need to figure out... the stock PaulMon on the Rev5 board waits for a CR from the terminal to determine baud, even if the disk controller is configured to be autostarting. Need to figure out how to eliminate this check [aha! found and modified fix_baud.asm, cool].

11/24/07 - Got the IDE interface portion of the circuit wired (the LED in my ascii schematic was backwards, fixed), it works with the drive I DD-copied my sim system to, can see the 7906 boot extension in sector 0, can see the HP-IPL/OS boot system in sector 20 hex and up (corresponding to 1KW block 8 and up) and it all looks identical to a hex-edit view of the disk image I copied to it. Whew! Still a ways to go but at least now I know I have a drive that both this IDE controller and my USB tray recognize, and block addresses correspond. I see that the LSB of words are recorded as the 1st byte of byte pairs.. the 124003 (A803 hex) is shown as 03 A8 (this is how SimH records 7906 disk images). Looking at the hpdisk code I see that it puts the MSB into the 1st byte... oops. Oh cool, DD has a byte-swap option, now it looks right, just had to add conv=swab to the command line.

11/23/07 - Updated the IDE zip (again, the 11/22/07 update had doc bugs). Added comments to the 8052 IDE controller code describing the HP interface - not tested, may still have bugs. Getting clearer though, nothing beats a powered HP, resistors and a meter to improve understanding... you've got to pull at least 10ma or more low to turn a 12V board's input to a "1". On the other hand the outs are only weakly pulled up to 12V (via 10K), designed to sink those current-heavy inputs. The zip includes the "combo" build I'll be using to test this stuff, it's XDOS-only (presently I have only 64KW of memory, not enough to run SFS builds but they're waiting and ready for when I do) and intended mainly for loading other binaries via a menu, which can be made auto-starting. Both IDE and 7906 drivers are on board with some selection logic so I can run the same disk images under both simulation and real hardware.

The component values mentioned in the 8052 controller code are preliminary and changing as I plan to make the thing. After reading the D71055L (82C55-ish) data sheet I see the LED's on the stock Paul Rev5 board definitely need to be removed (they can be reused for status LED's), and raised the values of the contention-absorbing resistors between the data bus and the 82C55 pins to at least 470 ohms. Paranoid perhaps but I want it to be immune to damage from incorrect software. I'm trying to get the TTL portion entirely on the prototype area and 32+ extra resistors in series with all the lines to toughen it up just won't fit, theoretically they aren't needed (provided it's not connected incorrectly), and totally not necessary if using level shifters so leaving these out. Another gotchya... the 87C52 P1 port pins can sink a little but cannot drive (measured "high" current is roughly 18uA, yea), they're essentially open-collector. P1 data lines (d_data, clk, flag) need to be pulled high using 4.7K to 10K resistors, the flag output probably needs [edit 11/24] an emitter-follower before being applied to the level-shift transistor to assure adequate current drive.

11/19/07 - IDE fixes done, seems to work now. LDEL in the "fast" library renamed to LFORGET with a confirmation, added 1.31 and 1.31MT (magtape) builds to the ide zip, in addition to the 1.3H version which was confirmed to actually function. Broken test code removed from the archives.

11/18/07 - Aha! It seems that fixing other bugs to make HP-IPL/OS go faster is what broke the IDE build due to broken status read code that was being masked by interrupt-induced delays (I think but figures). The IDE controller code puts the disk command on the HP input bus, then replaces it by zero. If status is read too soon it gets the command, not the disk status. Fix will be if status bit 15 set then it ain't status, loop until clear then read again to make sure. This affects only IDE builds, so except for a bum ide.ipl driver the main archive and the builds it contains should be OK other than a bit of non-build cleanup.

Working on a new SFS "fast" library - compared to the old one it blisters! Instead of a minute to find a sub-file it takes maybe a second thanks to writing a ";;" marker search in machine code. The file format is the same as the old IPL-only version, LIB L R D2L LDEL and LDIR work the same. Added are a SETLIB word so that any library file can be set (and saved), and a LCLOSE word for closing and saving changes to the library. XDOS writes are blocked if an unsaved file is being buffered but so long as LCLOSE LIB done to save the library file I had no problems putting XDOS-based utilities in the library to save dictionary space.

11/17/07 - The previous DMENU had an undesireable bug/feature - only permitted 25 files to exist in the default directory because it used XDIR to get the listing, any more would overflow the 1KW block used to hold the output. The new version includes a directory lister which outputs only the filenames. [snip...]

11/6/07 - Update to the main archives to make the CLS word compatible with HP2645 terminals (I hope! don't have one so can't test the theory but the previous version most certainly did not work). This is probably an interum fix - the new hp2645.ipl file with graphics/text control words needs commenting and testing, and there seems to be something wrong with XSAVE in the IDE build - so fixed only the hpscreen stuff and didn't want to burn a version click with another update likely pending.

10/24/07 - Making better progress on the new Simulating HP-IPL/OS document, not quite done yet but it's getting pretty darn close. Setting up a useful and interesting sim is a lot of work but it's not that much work, for those who are interested, follow the steps and it should work, and perhaps just maybe might provide a deeper understanding of what's going on under the hood than just running a pre-configured disk image - by building it from scratch knowledge is gained in how to build it differently.

10/15/07 - Made fixes to siobcs.ipl for running vintage compilers, got Fortran (II) working, yay. Other useful files around here for configuring and operating vintage languages are...

sioutil.ipl - repatches the slots in the sio16k11.abs binary
bcs31k_log.txt - procedure used for making a 31KW BCS linker
chess_log.txt - procedure used for compiling the Algol Chess program
ptbasic.txt - a bit about papertape BASIC and making a 28KW version
dmenu.ipl - a menu for running binaries, reading docs and saving BASIC programs

10/14/07 - HP-IPL/OS v1.3 posted, fixing TTY code I broke trying to fix the freezing clock, recent v1.1/1.2 kernels did not work on real hardware. Should be OK now but it'll be a bit before I can fully test it (the build I'm testing is hposdemo.abs in the main archive). The complexities of HP I/O operations are starting to sink in... today's lesson is simulation is a useful tool, but isn't real. FWIW under sim I can move TBG to slot 20 and it still keeps running, when I get a chance I want to swap boards around in my 2113E to check for blockages by the BACI and XY display code.

[obsolete removed]

9/25/07 - Yesterday while trying to use Octapus to see if P.T.BASIC could be patched to use regular (ascii-8) backspace I found a bug in the search function in my versions of Octapus D and E. These had been originally typed in from a partial listing and a LDB had been entered as LDA. For version "D" location 70443 needs to be changed from 63521 to 67521. I mistakenly suggested the patch for "E" but that doesn't work (just in case, 70443 53451 PUT undoes the wayward patch). The correct patch for "E" is 70423 GET PNUM, verify that it's 63473 and if so, 70423 67473 PUT. Before DGEN'ing test the patch.. OE then control-S, should prompt for the search value, if so control-R then enter 2 to restart HP-IPL/OS then DGEN or whatever. If it even matters... this was the first time I used that function in the 5 or so years since using Octapus, had no idea the search function gave a spectacular garbage show... typically I use the Punch Dump Assemble and Run functions and occasionally the Bounds function to examine ABS file ranges. [obsolete removed]

As far as patching basic's backspace, for the 28KW build found the 137 ("_") at address 67663, changing it to 10 (octal for ascii-8) permitted using the regular backspace key if Konsole's keyboard was set to "VT420PC". A side-effect under Linux simulation is DEL has to be used to abort Octapus entry and backspace at the sim prompt. Should be no side effects under Windows or real-hardware terminal usage, there ascii-8 is the backspace and DEL is the key for cancelling Octapus entries.

9/23/07 - Worked on TREK a bit, the previous conversion was functional but lack of formatted number prints and the resulting oddball spacing got to me, added a number print sub and restored text where it had been changed in an attempt to hide the spacing effects. The output is closer to original, now that it can be properly displayed. While at it added WARP UNITS to the calculator's distance measurement to help with navigation. [obsolete removed]

9/15/07 - I discovered that the chess program in ABS form would not run unless low memory was clear before running, even the ABS created by the BCS tools had this "problem" (only a problem when loading on top of something else, not a problem when importing to HP-IPL/OS or running from a cold boot) to 2000 octal for FCAM so that up to 1KW of embedded zeros is treated as code, and just in case added variables to AM2ABS (called by F2ABS) for the fiddle constants and increased the pad/boundary amount to 100 octal. The new algorithm is to see where non-zero memory is using FCAM (now ignoring larger holes) then all FROM addresses above 100 octal are lowered to the nearest 100 octal boundary, TO addresses below 67000 are raised by 100 octal, above that TO addresses rounded up to the last word in a 100 octal chunk. Memory over 76000 is ignored. Updated the ABS file in chessbcs.zip, updated the simulation and files page with new fcam.ipl code. This makes slightly bigger ABS files but ensures at least that all of page zero is saved and hopefully any embedded arrays that need to start out clear. Maybe, feel free to play with the _MCZ value and other variables if needed for whatever comes up or do it manually (ALTDUMP ALTABS etc), I'll only worry about making it work with the binaries included with the sim. Simplifications like F2ABS can only go so far, just beats the heck out of deducing and manually specifying ranges for every ABS file saved.

9/10/07 - I thought about possibly changing some of the words in altutil.ipl to make it easier to save binary disk files to stand-alone ABS files... but decided against that for now... those words work fine for the purposes they were designed for. Fact is, when an ABS is imported into a HP-IPL/OS disk system, information regarding load extents is lost. The data isn't lost of course, but information about which zeros in memory are important and should be saved as part of the ABS, or just space between code segments which can be omitted. This isn't a "real" problem, never stopped me from making an ABS, but it helps to have a little bit of knowledge about the program (like HP-IPL/OS needs a zero at the end of the dictionary) and architecture (like normally runable programs start at 2 and it's logical for something to end at 67777 or 67767 [minus 100 octal for the bootstrap] or 75777 [top of a 31K image] ) . Trying to generalize this process to document "how to save a disk file to an ABS file" is difficult, always seems to end up taking 3 paragraphs or more to poorly explain a very simple concept - dump alt and save the areas that appear important. Instead I really need something that takes a sentence to explain - something like attach PTP to a file and do "FILE" F2ABS and it just does it. The exising ALTABS takes the safe way out, it simply saves everything to a huge file unless the extents are manually specified. Rather than modifying what isn't broken, I'm starting a new "testing" package, named fcam.ipl for [a] word it contains.. FCAM - find code in alternate memory. "FILE" F2AM copies a file to alt, run FCAM to show where it sees code, then use ALTABS, AAOUT or other tools from the altutil.ipl package to save the output ABS. I'll add other tools to the fcam.ipl package and to the sim, hopefully something with a usage that can be simply explained.

Being able to extract binaries from the sim is a handy thing, not only for importing them into HP-IPL/OS or other installations running on real hardware, but also to run them by themselves (with the help of scripts) as if they were any other PC program. Double-click, there's TREK or CHESS or whatever. Or a program that actually does something important.

9/9/07 - Star Trek! Here's a paper-tape conversion of the STTR1 program. During the conversion process it ended up with X,Y coordinates rather than the original Y,X method, gotta make sure there's no more notation glitches and maybe work on the computer move calculator function - it shows the true distance between two points but that's not how the movement code measures it [added WARP UNITS display to the calculator to remedy that].

[trial documentation of binary save methods removed... too darn complicated...]

[obsolete removed, continuing 9/3/07...]

A Really Weird Problem I ran into while updating the sim - SFS didn't work (!). Could read but not write to the buffers. Thinking maybe it had something to do with the kernel fixes, tried last week's sim, same problem. Took the IDE build I just made with the new kernel, renamed !IDE and added !7900, it worked fine. And here's the kicker.. after running that build suddenly the bugged build worked. Turned out that interrupts had to be enabled, even temporarily, or SFS failed. Interrupts don't have to be on in the SFS build itself, just previously enabled at some point by the build that called it. This reminds me of the bug I was having loading BCS binaries without doing -TBG first. No time to track down why in the midst of major rebuilding, just renamed +INT to !INT and all seems well. The BCS lockup most certainly happens on real hardware... (HLT is a created halt instruction for swapping cables) did ALTSAVE HLT ABSLOAD HLT, loaded CHESS into alt mem, then -IRQ 77000 RUN - no output. Adding -TBG before the -IRQ makes it work, so does pressing the preset button while halted to swap cables. Hmm.. maybe need to make a PRESET word but for now TBG is the only thing that generates continuous interrupts, guaranteeing one will be deferred. If a unserviced timer tick can block TTY, makes me wonder if some interrupt left over from loading can block certain DMS-related functions (it was alt mem buffer writes that failed, nothing to do with disk), that would explain why enabling interrupts even for a moment permitted SFS to work. Or not. But the lessons are clear, enable interrupts even if not needed, and disable anything that generates interrupts (in addition to disabling interrupts) before loading stuff.

8/29/07 - I converted my OTH program to run under paper tape basic, didn't take much. To load, halt from the disk sim's main menu, attach ptr othel.txt and run 77000, run basic, enter PTA. To save to disk BYE then use the basic save option patching to auto-run. A stand-alone ABS file can be made by running the utility build from the other side (1 CHPL "MT7900 U" XLOAD), copying the saved file to alt.mem ("@ OTH" F2AM), attaching ptp OTH.abs, and using ALTABS, no change to run address, save the ranges 2-21567 and 67100-67677. These numbers determined by using ALTDUMP to see (about) where the program ends and where the drivers were. Nice. The save 28KW basic option can also be used but the file size comes out much larger.. now I want to hack ALTABS so it figures out optimum save ranges on its own [ended up being a new package...fcam.ipl for Find Code in Alt Mem].

8/26/07 - Had to work on altutil.ipl to fix things but they were mostly happy bugs, discovered after figuring out how to configure HP BASIC for more memory (which changed the contents of some locations). Updated "mydemo", removed the original hposdemo.zip (out of date, similar/better builds can be made from the current demo). Most of the fixes were in the RUNABS (load) and ALTABS (save) words to (hopefully) work with all configured versions of HP BASIC. The option to save the BASIC program now prompts to patch BYE (if loc 76 not patched) and if to autorun the program, and figures out how much to save based on the configured build size (but not the size of the entered program, just does a single-range core dump of everything). Fortunately the re-enter (2050) and autorun (5137) addresses didn't change so all that's good. The option to manually save alt mem now supports multiple ranges in the ABS file.

[obsolete removed, 28KW BASIC config instructions now in ptbasic.txt]

8/25/07 - Fixed LIFE again, updated ECAL to include LC resonance calculations, "mydemo" updated.

8/23/07 - Found and fixed the XDEL bug, while at it modified XLOAD so that it shuts down TBG (if present) before loading binary systems to avoid crashing BCS and other "alien" binaries. Updated xdos.ipl is here, I'll update the main distro zip and binaries when I finish the sim version. While working on the sim I altered the Life program so that it uses TTYSCAN if it exists for keyboard exit, otherwise uses the switch register (inconvenient to halt and set a SR bit under sim.. messes up the display), renamed to life.ipl to avoid the filename chase, same thing for ecal.ipl which is now the new one. Re: version numbering... the primary version will remain "1.0" since the kernel, DMS and MagTape builds are unchanged. For packaging changes and updates which only affect some builds I'll add a third "distro" number, starting at 1.0.2 since 1.0.1 would have been the tweeks to the original 1.0 test build. The new sim version is coming along, it's based on the MT build with a 7900 version of XDOS and an autostarting disk menu which displays text files and loads IPL and binary files... CHESS and BASIC too. Has an option for saving BASIC programs to disk files so the operator can enter a program, BYE and press a key to save to a new file containing the program, and optionally autostart it.

8/22/07 - well looks like I will have to re-do some of the main distro - I just found a serious bug in XDEL... if N is selected it leaves a value on the stack - no huge deal if using as a manual command but makes using from another IPL impossible. Ouch, never noticed this before but sure did when I was programming the new disk simulation's DMENU, which now has an option for saving an HP BASIC program to disk (if the file exists prompts to delete using XDEL). It'll be cool when done but now I have to backtrack.

8/19/07 - Interrupt Hell, but hopefully better now... the 8/18/07 version of "mydemo" was broken, removed incorrect notes about it, updated mydemo.zip and the altutil.ipl, conalt.ipl and ldenc.ipl files. This build also contains the new !NOLF autostart word so that, even if the formatting isn't quite right, at least IPL input code works correctly when the terminal is set to emit CRLF line ends, which are needed when running BCS stuff.

To make a long story shorter, turns out merely disabling interrupts before loading another system binary isn't always enough - just because interrupts are disabled doesn't mean they don't still happen, as soon as interrupts are reenabled the highest-priority interrupt that occured will be called and there had better be something there to service it. Normally all HP-IPL/OS binaries include dummy vectors for every slot unless it's been pointed to something else, so this never was a problem except in the early days before I learned to do that. But old ancient stuff like BCS was designed to be powered up cold, not loaded from something else, and if something like the TBG board is emitting interrupts then there will be problems. I thought I had fixed it by removing the -IRQ from RUNABS but all I really did was reduce the chances of an interrupt occuring before say Chess defined at least something in the interrupt table - wasn't right but permitted the program to run. Sure enough when I throttled back the cpu in simh hp2100 the interrupt would crash the program before it could print the screen and set up a terminal-entry interrupt (I guess). The real fix was to run -TBG (after checking to make sure it existed), to stop the interrupt from occuring in the first place. For disk systems, do a -TBG command before XLOADing an imported BCS binary, or for that matter anything which does not include dummy vectors in low memory.

8/18/07 - Found this in the Contributed Software Library archive X167...

Simulator startup and beginning text:

HP 2100 (mod) simulator V3.7-2
sim> set cpu 21mx
sim> set tty autolf
sim> load chess.abs
sim> run 2



CHOICE: (B=1, W=-1) -1

The program was written in Algol for DOS-M, which the SIO algol.abs compiler compiled perfectly after adding ",B" to the initial control line. The assembly file needed more extensive work, besides adding B's to output binary, unsupported RRR RRL and SWP instructions had to be replaced with octal equivalents and each section put into a separate file to make compatible with the SIO extasmb.abs assembler. Then I used my customized 31KW BCS linker to put all the pieces together to make a standalone chess.abs file configured for TTY slot 11. Modified source and ABS file is in the chessbcs.zip file, requires a CPU that supports extended instructions such as the 21MX. I don't know what the deal is with the extra 1 and 0 characters that appear in the output. As with all BCS binaries, input lines need CRLF to enter, if the terminal only supplies CR then press control-J after pressing enter. I'd love to hack that requirement away.

8/16/07 - Seems there's no [clear] documentation of the ABS papertape format on the net that I can find, so here's a draft based on my experience... [still a bit fuzzy]

  ABS Paper Tape Format

Leader - any number of 0 bytes (depends on interface)
For each record...
Byte - number of words in the record
Byte - 0
Byte - high byte of address
Byte - low byte of address
For each word in record...
Byte - high byte of word
Byte - low byte of word
Byte - high byte of 16-bit checksum of all words in record
Byte - low byte of checksum
0 to 4 (?) zero bytes to separate records
Trailer - at least 16 (?) zero bytes to terminate load

That should be close but unclear about the exact numbers of permissible inter-record and trailing 0's. HP-IPL/OS (usually) saves files with an 8-byte leader, no inter-record gaps, and 20 bytes to terminate.

Another LIFE fix... with all the hardware excitement (not to mention RL jobs) didn't notice the unerased text when returning to edit mode... files life3.ipl.txt and mydemo.zip updated.

8/13/07 - wrote a "dos" HPSEND program in QBasic, wasn't so bad, [was] on the PTemu page [now on the HP Mini Projects page]. Also zipped up mydemo.abs from which the encoded mydemo was made from. Now the encoded version lives in the zip.

8/12/07 - forgot to update the display when returning to LIFE's editor, fixed. Updated mydemo_enc.txt, now includes LDENC, removed 3BUGS and TTYSCAN stuff, added build notes. I really like being able to scribble notes to the build file, makes maintaining oddball builds easier, permits loading on systems which don't have a file-to-PTR connection. Modified CONALT so that it no longer needs ZAM, should be able to paste just the CONALT word (or the whole IPL to be able to save encoded builds too) into any fairly recent DMS build to enable pasting in binaries via a HyperTerminal console (see build notes for loading into a BACI console). Hopefully this will help solve the problem of being able to load stuff without having to have a PTR emulator which can transfer files from a PC. An HP21xx mini user still needs a PTR emulator of some sorts to make use of any of this stuff... I really need to document something that'll do the job... so I reverse-engineered my pass-through PTR emulator that Bob Shannon sent to me. At some point I'd like to come up with something better that can punch too and has a boot image on-board, and somehow make the serial PC interface not require custom software... getting even this simple emulator running requires writing/hacking serial port software.

8/11/07 - updated the LIFE program, now includes a full-screen cell editor in addition to random mode. Consolidating info [obsolete entries deleted]: the words I use for loading, saving and otherwise experimenting with stand-alone ABS programs are now consolidated into the altutil.ipl file. Also present in "mydemo", conalt.ipl for saving and repasting encoded binaries, and log2abs.ipl for converting encoded binaries to real ABS files. The TTYSCAN words are hanging out in the file archives but at least for real-hardware use it's probably better to use the switch register to terminate programs that don't pause for input, trying to detect keypresses by the slot flag is tricky [prints affect it].

The encoded binary format is a handy way to encapsulate code and additional text in one file, to make it easier to use I made a LDENC word that loads an encoded binary attached to PTR. For example...

Simulation stopped, P: 02217 (JMP 2216)
sim> attach ptr ldenc.ipl
sim> c
Simulation stopped, P: 02217 (JMP 2216)
sim> attach ptr 31odd_enc.txt
sim> c
Binary loaded into alt mem, 77000 RUN to execute
? 77000 RUN


8/5/07 - added newer IPL's to files.htm (but not into main zip archive), readusted links on this page to point to new locations. Wrote up some comments for the fixfst.ipl file relating to how I integrated a build containing it into my Linux GUI, so I can simply right-click an .fst file (from the now gone Interex archives) to untar it, then right-click the individual encoded files to decode as text or binary. Often it's quicker to code something like this in IPL than use a "real" programming language, particularly things that only require parsing an input stream and writing to the screen and/or an output file. Parsing single bytes or words in say QBasic is not exactly trivial but quite easy in IPL, even considering the watchdog timer has to be used to detect the end of the input file.

7/21/07 - updated mydemo_enc.txt to include a new version of ECAL that also does inductive reactance and noise voltage. Electronics designers often forget (or never knew) that all resistance implies a certain amount of noise, and there is no such thing as a "low-noise" resistor (just minimal extra noise). I often see high-gain guitar amps with a 68K resistor between the input and 1st tube grid, that produces about 3 microvolts of noise. For a "clean" amp no big deal (about -80db under a typical 30mV sensitivity) but for a high-gain "overdrive" amp that means pssssssss.. change that 68K to say 2.2K and much of the noise usually goes away with practically no change in tone. Anyway... the encoded binary format as a distribution medium is growing on me, provides an ability to put docs (just don't say BEGIN) and binary into a single text file that can be copy/pasted to a terminal or processed via PTR/PTP using L2ABS to convert to ABS. Other loading possibilities can be devised, perhaps a small machine-coded stand-alone program that directly loads from PTR or even TTY or BACI.

MAZE has been spotted running at VCF MidWest 3.0 here here (from here) and here... thanks guys!

7/16/07 - Here's another solution to the code-loading delima... CONALT. CONALT permits pasting a binary that was encoded to text using either CONGEN or ALTGEN (included in the IPL) into alternate memory, after loading the binary can be run by entering 77000 RUN. If it doesn't have a run address or running not desired then ALTHALT will swap it into main memory and halt. Either way running from 77000 will return to HP-IPL/OS. [encoded sample binary removed] Windows HyperTerminal with paste delay set to 10ms/300ms for char/line seems to work under sim with set throttle 800k [lately I've had to use 1800k - sim thing?] given at the sim prompt to approximate the speed of a real 21MX machine... but testing this was a chore, under Linux I have found no way to slow down paste speed, using flow control chars (XON/XOFF) doesn't seem to do anything useful but still investigating. This has always been a problem under both Windows and Linux... the only old-comp OS I've been able to copy/paste to under sim is TSB-E, and that's apparently only due to its very high response speed. So far the only (common) program I've found that permits control of paste speed is Windows HyperTerminal. I didn't feel like moving all my work files over to XP so in Linux ran my demo build with set telnet 4000 in effect, then ran XP under VMware and used HyperTerminal set to telnet to my eth0 address port 4000 to access HP-IPL/OS and test the stuff, works. Having to use two major OS's running simultaniously seems a bit excessive just to make paste work, but in practice it's not so bad, VMware server rocks!

Here's an encoded version of my demo build [now a zip w/ encoded and ABS], set up with BACI enabled (simh doesn't care but has no baci). To bootstrap an existing HP-IPL/OS system to this build, first make sure ALTSAVE is present. If not, it goes like this:

000002 000002 076000 C>ACOPY 000400 076400 076002 000002
027004 073035 127031 053032 043034 063035 105707 067035
063033 077034 105745 105706 067035 063035 077034 105745
105705 067033 063035 077034 105745 073035 063031 077002
105734 077000 077034 +DO INDEX SWAP PUT +LOOP END

This word copies the system to alternate memory then puts a machine code program in memory at 77000 that swaps main and alt then runs from 2. Often I use it just to get the swapper program and follow with ZAM to do something else in alternate memory. Anyway, continuing the bootstrap, paste in the ZAM code from zam.ipl from the hposdemo.zip file. Next paste the code from the conalt.ipl file (or just the CONALT word unless you want to save a copy of the present system using CONGEN). Hopefully it finds all the words it needs, if not hunt down IPL for whatever's missing. Once it goes without error enter CONALT then paste the encoded code into Hyperterminal, which should be set to a character delay of 10ms and a line delay of 300ms (thereabouts). If there are errors you'll probably have to wait for all the text to be pasted to the console, no apparent way to stop a paste without using the power switch. For each block a checksum is used, watch for checksum errors (like happens under sim when the TTY is set for uppercase.. duh). If no errors then the new system should be in alternate memory, execute by entering 77000 RUN. If everything looks good and you have a PTP emulator then SYSALL the new system, or not - same functionality can be achived with a recent build by just loading the new IPL code as desired, could be just loading the demo build to play the games. To go back to the previous system halt and run from 77000.

7/15/07 - Operating the old SIO/BCS software under simulation is giving me a deeper appreciation of what it must have been like to be a programmer in the late '60's. On one hand they had it kind of rough, but on the other hand there wasn't the excessive software complexity like there is today, if something can be made to work once generally it works every time. One thing they did have even early on was the concept of modular programming using separately assembled and compiled relocated "object" files, permitting the distribution of subroutines which could be reused for a variety of applications. While searching for fun stuff I ran across numerous routines covering everything from ascii decimal business math to floating point matrix operations and FFT's. They were doing some pretty high-powered computations using these machines which often had only 16KW memory or less.

A handy word I added to my copy of the demo build...

"RUN 77000 TO RETURN" $PRINT ALTSAVE ZAM 000150 102000 PUT
000150 000002 000001 C>ACOPY 077000 RUN END

CLRHALT presents a cleared halted machine except for a program at 77000 to return to HP-IPL/OS, ensuring that all traces of previous operations are removed. This will probably be added to the demo build at some point. [ZAM comments removed... the one in XDOS does Not affect MS] While clearing mem is not absolutely needed, it sure does make it easier to determine where code gets loaded. Once an ABS file has been created a "bounds" report can be printed using the built-in Octapus utility, attach the ABS to PTR and in HP-IPL/OS enter OE (or OE? for menu) and press control-B.

I rigged up my Ubuntu Linux system so that I can right-click .sim files and "run" them, or double-click .abs files to run them using my default configuration. This saves having to create a .sim file and a shell script to run every .abs I'd like to run, and goes a long way towards making the HP 21xx mini simulation work like any other program, just double-click it and it goes. More convenient to run than even QBasic for quick and dirty apps, I expect HP-IPL/OS builds with custom auto-starting apps to multiply, and for making fancier apps using the BCS tools is not that bad, certainly faster than trying to program in just about any modern language if all you need is keyboard/screen and basic stream I/O.

I have "hp2100sim" associated with .sim files to change to the directory and run in a terminal...

# open a .sim file using hp2100
cd `dirname "$1"`
konsole -e hp2100 `basename "$1"` &

I have "hp2100abs" associated with .abs files for running them in a default configuration...

# load a .abs file using simh hp2100 configured to
# whatever is in the ~/hp2100abs.sim file. Creates and
# removes a ~/hp2100abs.tmp file used to indicate
# the file to load. Runs file from loc 2.
cd `dirname "$1"`
cat ~/hp2100abs.sim > ~/hp2100abs.tmp
echo load `basename "$1"` >> ~/hp2100abs.tmp
echo run 2 >> ~/hp2100abs.tmp
konsole -e hp2100 ~/hp2100abs.tmp
# xterm -e hp2100 ~/hp2100abs.tmp
# gnome-terminal -e "hp2100 /home/newton/hp2100abs.tmp"
rm ~/hp2100abs.tmp

This requires that a simh script hp2100abs.sim exist in the user "home" directory, for this I used the .sim file from the demo build with the final load and run removed (this is added by the bash script for the specific file being loaded), and set tty autolf added so I don't have to hit control-J to enter when running BCS stuff. As written these use "Konsole" for the terminal, which seems for compatible with more old-comp stuff.. other possibilities are listed in the second script. When using Gnome Terminal backspace has to be reconfigured to output ascii-8, which has the effect of making backspace fail when at the sim prompt. With Konsole the backspace works in both HP-IPL/OS and at the sim prompt. Often it takes multiple tools to deal with multiple situations, when I examined an old Algol source my default text editor wouldn't load it, but I have a script that loads a file into good old qbasic /edit using DosEmu/FreeDos, upon saving whatever my editor was complaining about was fixed. Another thing that's a must for the oldcomp Linux user - unix2dos (and sometimes the converse dos2unix) which changes the line ends from LF to CRLF (in the tofrodos package on my system), these should be added to every right-click dealing with text. HP software will not accept files in "unix" format, unfortunately every time I edit a file with the default editor it adds LF-only line ends to whatever was modified which can cause really strange effects like parts of an IPL file (the part I just "fixed") to not be loaded at all. As soon as I edit something I run unix2dos on it. Except for bash scripts... these need to be in unix format or my system won't run them. Finally, when it comes to associations I found that the stock Gnome system tended to treat all text more or less equally so adding an action for say .sim files added to all text types - fine I suppose for the casual user but my right-click action menu got as tall as the screen. I used the Rox MIME Editor to create new file types that I could populate separately without affecting other text types.

Although the above integration examples were done using Linux, roughly the same things can be achived in Windows using batch scripts. Windows generally sets the working directory to the file being operated on so the tricky cd / dirname stuff isn't needed (at least didn't used to be), and by default all console programs like hp2100 operate in a "dos" window avoiding having to sort through multiple terminals. Just hope that the software works in the terminal provided, anything involving screen codes (HP or ANSI) has to be run in a telnet terminal under XP or other Windows OS's using cmd.exe. Discounting that, a possible Windows-specific version of the "hp2100sim" script would go something like...

:: hp2100sim.bat - run .sim script using hp2100
@echo off
hp2100.exe %1

...and "hp2100abs" would go something like...

:: hp2100abs.bat - run an abs binary using hp2100
@echo off
:: edit below for location of hp2100abs.sim script and temp file...
set scripts=C:\SCRIPTS
type %scripts%\hp2100abs.sim > %scripts%\hp2100abs.tmp
echo load %1 >> %scripts%\hp2100abs.tmp
echo run 2 >> %scripts%\hp2100abs.tmp
hp2100.exe %scripts%\hp2100abs.tmp

This doesn't bother to delete the temp file, always the same name so doesn't really matter and makes it easier to convert to a version which launches a telnet terminal to get "graphics"...

:: hp2100abs.bat - run an abs binary using hp2100
@echo off
:: edit below for location of hp2100abs.sim script and temp file...
set scripts=C:\SCRIPTS
type %scripts%\hp2100abs.sim > %scripts%\hp2100abs.tmp
echo set telnet 23 >> %scripts%\hp2100abs.tmp
echo load %1 >> %scripts%\hp2100abs.tmp
echo run 2 >> %scripts%\hp2100abs.tmp
start hp2100.exe %scripts%\hp2100abs.tmp
start telnet.exe localhost 23

It might be possible to remove the start from telnet but if telnet starts too fast it'll fail. I haven't tested these batches, they should be close but as usual every system is different, adapt. Some of the things I'm doing under Linux just wouldn't be possible under Windows, such as decoding the FST archives containing old HP software.. Windows won't accept filenames like "X17001:::4:12:3 [unnatural number of spaces] 7". Under Linux I have it rigged to right-click an FST file, decodes to an "untarred" directory, then I go to the strangely named files right click and select hp_fix.sh or hp_fixbin.sh to run a custom HP-IPL/OS utility that turns them into plain text or binaries. My FST decoder is linked at the bottom of this page but only useful if you managed to scarf the HP CSL FST archives before they vanished from the web... if anyone needs any of that stuff let me know.

Browsing through the archives I noticed that apparently there was a FTN4 for BCS, I haven't used it yet but pretty sure the fortran1.abs and fortran2.abs files I have are "basic" Fortran. Also saw hints (in the source for a DOS/RTE FTN4 compiler) that FTN4 running on RTE could be used to generate relocatable object files for BCS, there may be hope for the old games after all... change EXEC to .IOC. calls.

One more thought for today's notes then I've got to get on other (real world:-) stuff... all this action using the simulator is also for enjoying the results on real hardware, but in today's environment it'd be pretty tough to actually build the stuff using real hardware unless fortunate enough to have a complete working system with a papertape reader and punch and all software on papertape. On a practical level, being able to transfer files downloaded from the internet etc is vital for enjoying say an HP mini purchased from E-bay, and to do that you need a papertape emulator. Mine is a little box made by Bob Shannon containing a PIC processor, with a serial port for the PC and a connector that fits on the stock PTR board. It doesn't do punch, all it does is transfer files (quite slowly, takes about 4 minutes to boot a large papertape file). I need to get the code to this gizmo and document it, simple as it is it lets me run ABS files right from a PC file, and without the ability to do that there's not a lot that can be done with the old machine. Other PT-emulator options include using eprom or I2C chips, these generally can boot the machine much faster, able to operate at interface speed instead of being limited by a serial connection, but again you have to have a way to be able to program the chips to really enjoy it. My PTR-emulator requires use of custom serial software to perform the handshaking, would be better if a standard serial terminal program could be used in a way that did not require handshaking, I'm thinking something that used say 3 memory banks, a "boot" bank, a PTR bank and a PTP bank, with the ability to copy either the boot bank or PTP bank to the PTR bank, and a serial port interface that presented a menu that can be used from any OS with no special software to upload code to either the boot or PTR bank, or download code from the PTP bank. Sounds a bit complicated but fits the way I'm using this stuff under sim, and how HP-IPL/OS and BCS expect to be operated. Just a thought-drop... but any PTR emu with the ability to transfer or program files is much better than nothing.

7/14/07 - HP papertape Fortran (according to the standard software docs I have) supports "American Standard Basic FORTRAN", which is described in the "ANSI Fortran66" document found at Historic Documents in Computer Science. There is also Algol documentation there, not sure how close it is to the available papertape Algol. Most of the stuff I wanted to run is written in ASMB and FTN4, assembly probably isn't a problem (extasmb.abs worked perfectly the first time I tried to use it) but it's probably not practical to convert significant FTN4 programs to "basic" FTN. At least the docs give me something to go by and I have HP BCS "Fortran II" and "Algol" code to examine. There's not a whole lot in the HP Contributed archives that works with BCS (except for math stuff, lots of that), but found a deceptively simple game called 31odd (added the ABS and a simh hp2100 log of how I made it), haven't beat it yet.

7/13/07 - The SIO patch utility appears to work. Here's a log of BCS/SIO procedures for creating a 31KW BCS binary and a 16KW SIO binary for running the Algol compiler (and hopefully the assembler and Fortran compiler), which were used to compile and link a trivial Algol example. Getting there! One thing I discovered though is when I tried the same thing using a 16KW BCS system (as in the simh hp2100 Algol instructions adapted to my configuration) the drivers were not included in the resulting ABS, requiring that BCS be loaded first. In a way that made sense as the binaries were smaller and more portable, just not as convenient as self-contained binaries.

7/11/07 - I'd like to run the code too, so modified the screen words to work with HP and VT/ANSI terminals with a TERMINAL word to change back and forth. Added an ALTDUMP word for examining alternate memory. Fixed the ZAM word when I rediscovered that the old ZEROBLOCK word redirects MS output and leaves it redirected to block mem (not its job to worry about that). Added a PTHEADER word to make it easier to write 8-byte ABS headers, fixed ALTABS to do this instead of writing 20 byte headers. Most of these tweaks are to make it easier to use in conjuction with SIO/BCS, particularly exploring, patching and saving ABS files. I made a "SIOPATCH" utility that (theoretically) changes the slot assignments in a configured 16KW SIO papertape (not tested yet), soon will work through the Algol instructions for making a BCS tape and see if I can actually compile something.

7/8/07 - Added hposdemo.zip containing "demonstration" versions of the HP-IPL/OS "DMS" build with the screen commands (ESC CLS POS) replaced with code that should work with the 2621 and other HP terminals. Has drivers for TBG, BACI and HPIB, a "TTY" version is included that disables the TBG and BACI inits to require only TTY and PTR. Includes experimental TTYSCAN and TTYGET words for implementing keystroke scan, the technique has limits but useful for exiting demo's by pressing a key (eventually). On-board "programs" include MAZE CYLONS 1DCA and a new (slow) LIFE program. Also includes new experimental RUNABS and ALTABS commands for executing ABS papertape binaries with a "swap back" routine at 77000 for exiting, automatically patches HPBASIC so that BYE returns to HP-IPL/OS. ALTABS permits saving alternate memory to an ABS papertape binary with options for preserving or auto-running basic code. Theoretically this could be used to make a snapshot of a SIO/BCS system to create standalone ABS applications. There are a few HP games written in Fortran I'd love to convert and recompile to not require a disk OS... that sounds like a project.

[obsolete removed]

9/7/06 - [obsolete removed] Regarding SimH's relatively recent behavior of automatically adding 0's if a papertape is read past EOF, I read the docs <g> and found the TRLLIM variable, at the sim prompt or in the startup script d trllim 0 should restore the "normal" behavior of hanging at end-of-papertape. I'll only have to do this to get my FST archive file decoder working again as it used the watchdog to detect the hang, but no plans to modify the HP-IPL/OS config scripts since the new way better matches the way papertapes were really used in the old days (with a trailer after the data, I'm pretty sure they didn't let the tape run out). Just guessing, but it was probably normal programming procedure to skip any leading nulls to find the beginning of an ascii file and consider the first zero after the data the end of the file.

Other stuff hanging around here...

absutils.zip - various abs file tools
fstdecoder.zip - a HP-IPL/OS-made utility for decoding FST archives and files