HP-IPL/OS Testing Page

hpiplos_main.zip - 836K v1.53 (9/1/08) contains abs, source, docs, and interfacing plans
mydemo.zip - 59K (8/26/07) older DMS demo build, contains abs file and text-encoded binary
Main HP-IPL/OS page is here. 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 are here.
The editor page is here. The 31KW MSU BASIC page is here.

Updates and Testing Files...

Previous new files are now in the 1.52 archive, including...
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
dm2.ipl - (updated 8/19/08) disk menu for use with MSU BASIC

Changed/added files for 1.52 include...
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

Changed/added files for 1.53 (besides above updated files) include...
sfslib.ipl (8/30/08) - a new library system, replaces lib2.ipl/a2l.ipl/ms2l.ipl
edit(old).ipl (9/5/08) - no code change, altered comments (again)
ipl_notes.txt (9/1/08) - new docs describing included IPL's and other IPL listings

Pending changes for version 1.54 include...
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
summary.txt (3/15/09) - updated summary docs to cover new printer driver
hposdemo.zip (3/16/09) - updated hposdemo.abs build with fixed printer driver

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.

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...
"!PRN" $DEFADR 21 ADD GET PNUM
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]
  CRLF CONSOLE

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

DEFINE CP2F
; 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
  UNTIL
  #0 CLOSE  ;close and save file
 ENDIF
 #0 RELEASE ;release buffer
ENDIF
MSPAPER     ;put MS back to default PTR/PTP
END
CONSOLE

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

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
E) Binary   WUMPUS              F) Binary   REVERSIX
G) Binary   CHESS               H) Binary   31-ODD
I) Run IPL  MAZE                J) Run IPL  1DCA
K) Run IPL  LIFE                L) Run IPL  ECAL
M) Run IPL  FED                 N) Text     SUMMARY
O) Binary   SFS/AEDIT           P) Text     NOTES
Q) Text     CHESS-FILES         R) Text     31-ODD-FILES
S) Text     REVERSIX-FILES
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
OCTAL DEFINE SAVE
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
 $LEN IFZ $DROP ELSE
  $DUP GetFile IFNZ ;if file exists
   DROP DROP ;drop disk location
   "File exists. " $PRINT
   $DUP XDEL CRLF ;prompt to delete file
  ENDIF
  $DUP GetFile IFNZ ;if file still exists
   DROP DROP $DROP ;clean up stack, don't save
  ELSE
   174000 AM2F
  ENDIF
 ENDIF
ENDIF
END
CONSOLE

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

CREATE DMATEST
 LDA CW1
 OTA 6
 CLC 2
 LDA CW2
 OTA 2
 STC 2
 LDA CW3
 OTA 2
 STC 6,C
WAIT SFS 6
 JMP WAIT
 JMP END
CW1 OCT 120011
CW2 DEF ODATA
CW3 OCT 177771
ODATA ASC 5, H E L L O
      OCT 15
      OCT 12
END
CONSOLE

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

? DEFINE MT2F
> MTSEEK IDREC 20 MTREAD MTWAIT IDREC GET 15400 SUB IFNZ
> "UNKNOWN FILE" $PRINT $DROP ELSE UDMA 2 IDREC INC INC GET
> MTREAD MTWAIT SDMA IDREC INC INC GET 2 MUL AM2F ENDIF END
? ;I want to copy ECAL.IPL from magtape to a disk file
? ;named "$ ECAL" so DMENU can run and forget it.. so..
? MTDIR
....
File 000031  ECAL.IPL              File    003535 words
....
? 31 "$ ECAL" MT2F
Saving alt to 000000 002347 **
? XDIR
....
$ ECAL            000000 000000 000000 007272 000000 002347 000000 000046
? ;did other tests, works, want to keep the MT2F word so...
? DGEN
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].

[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

HP CHESS VERSION A  10/26/73

DUMPS AVAILABLE:
     SW0 - MOVE LIST
     SW1 - BOTTOM NODE DUMP
     SW2 - FULL DUMP



TYPE 1 FOR A NEW GAME, 0 FOR OLD 1
CHOICE: (B=1, W=-1) -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
LOAD
?
Simulation stopped, P: 02217 (JMP 2216)
sim> attach ptr 31odd_enc.txt
sim> c
LDENC
...
Binary loaded into alt mem, 77000 RUN to execute
? 77000 RUN
 WELCOME TO A GAME OF 31-ODD.


 DO YOU NEED TO KNOW THE RULES?

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:

OCTAL DEFINE ALTSAVE
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...

OCTAL DEFINE CLRHALT
"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...

#!/bin/bash
# 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...

#!/bin/bash
# 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