Full Screen Editor for HP-IPL/OS

It took years but finally HP-IPL/OS has an editor capable of doing development work completely within the system without having to write the code using a PC editor.

This text editor requires a HP 21MX minicomputer with at least 64KW memory, connected to a terminal which supports HP26xx or VT100/ANSI screen codes. The base version is the one included in (or a candidate for) the main HP-IPL/OS archive, loading code was added to permit using it with any HP-IPL/OS build containing the standard extras, DMS, and screen-control words. The experimental version is for developing new features and does not include the loading features or as many comments, leaving more room for on-line editing.

Both versions presently use the same conversion utilities package to provide words for saving and loading text to and from a "MS" (mass storage) device, typically assigned to a papertape punch (PTP) and reader (PTR), and permit a PC-based terminal such as HyperTerminal or ProComm to send a text file to load into the editor, or capture edited text to save to a file. The utilities are not needed to edit disk files unless they need to be converted to the editor's "array" format.

The edit builds are stand-alone ABS binaries containing HP-IPL/OS and the editor with utilities.  Builds are provided for both the base and experimental versions. These should be adaptable to most HP 21MX machines, drivers are included for BACI, a printer, and for 7906 or IDE disk drives formatted with the SFS file system. When stored on disk they should auto-detect the appropriate disk driver. See buildinfo.txt for how to reconfigure slots, boot to BACI, etc. If using on a disk-less system the prompt for the disk driver can be removed by renaming the autostarting !DISK word and punching a new build.

Speculations are at the end of this page. Here's a screen shot...

This was using QCTerm version 3.1a (Sept.2007), which emulates a HP700/92 terminal. AEDIT stores graphical characters with bit 7 set, when updating the screen if bit 7 is set it sends control-N, then the lower 7 bits of the character, followed by control-O. When control-N is pressed a variable is set that causes the character to be stored with bit 7 set, pressing control-O clears the variable. HP terminals interpret these as field sets - characters on the line after the cursor will change, and due to the way AEDIT works cursoring tends to change the displayed characters to the selected mode. The data isn't changed, flip pages (control-V then control-C) to restore.

3/16/09 - updated the printer driver in the stdedit.abs and sfsedit.abs builds in the editbuilds.zip archive, no changes to the editor itself, should work on (at least some) real printer hardware now.

8/10/08 - updated stdedit.abs and sfsedit.abs builds in the editbuilds.zip archive, no changes to the editor itself. Mainly this update was to upgrade the SFS "experimental" build to HP-IPL/OS 1.52 to avoid data loss if SFS is used to write files without enough memory installed. Nothing in the editor would trigger that but these are more than just edit builds, they can be used to generate derivitive builds (by me) so the surrounding code matters. The "standard" build in stdedit.abs now includes the SVMT and LDMT words for saving and loading edit files to and from magtape. The "experimental" build in sfsedit.abs no longer includes the magtape words and instead includes various utilities for manipulating binaries in alternate memory and is similar to the SFS/EDIT build used in the 7906 simulation package. Both builds include the printer driver and APRINT word for printing edit data, and if needed the HP2645 terminal words. The docs now include information for setting up a simulated magtape and disk system and some operational details.

7/19/08 - SimH HP2100 version 3.8-0 now works properly with QCTerm without having to use autolf mode. The funny screen effects when using graphical characters appears to be just how HP terminals work, there probably isn't an easy code solution that won't impact the primary purpose of this editor - to edit HP-IPL/OS code and text. It's easy enough to work around the effects... edited the notes on this page [updated 7/24/08].

4/9/08 - updated the magtape load/save words in editbuilds.txt, initial SVMT saved twice the data it should (magtape files sized by words, not bytes). These seem to work with large files too.

4/7/08 - updated FED.IPL with a candidate for the HP-IPL/OS archive, fixing the LDFILE max-size bug (updated in the text file archive, not in the main zip yet). Minor cosmetic tweek to LDFILE in AEDIT.IPL to match the spacing of SVFILE (and the one in FED.IPL). Updated editbuilds.zip, STD/EDIT now 1.51J, SFS/EDIT now 1.51L. Added experimental magtape load/save words to the editbuilds.txt file.

4/6/08 - a tiny little fix that probably wouldn't have mattered except for seeing it. SFS/EDIT build now 1.51K. Working on the new "base" FED.IPL version, will include the bugfixes and smoother cursor, but not the control-F page-delete function. That one is still experimental and hasn't been properly integrated yet... not sure how to fit the key on the hint/status line, toying with the idea of a pop-up help screen instead of trying to cram all the available keystrokes on line 24.

4/5/08 - Just when I think it's getting there up pops a bug... this time when loading files that occupy all of the available pages. Was able to work around the problem by using "FILE" LDTXT (do -SFS afterwards if that causes an X stack overflow, LDTXT isn't intended for loading files already in the editor format). To fix the problem I modified LDFILE to remove the code that zeroes the space after the loaded file and simply cleared alt mem before doing the load. Also modified the truncate code when quitting to make faster, removed history comments for more editing room, and added back the previous control-F command to delete the current page. Although no longer needed as a workaround to prevent file growth, while editing docs I wanted to start a section over, on real hardware that would have been about 5 seconds each to update the screen after each line delete, not cool. Updated sfsedit.abs build in the editbuilds.zip file.

4/2/08 - Updated AEDIT.IPL with new code to reduce cursor wiggle, essentially rearranged the code to permit calling to perform a single-character update rather than having to update two characters at a time. This doesn't make it significantly faster (overhead is in the repositioning code and terminal sequences required to restore garbage that might have been left by pressing control keys), but certainly makes it look better when cursoring around. Updated editbuilds.zip with new sfsedit.abs build, now v1.51H.

3/29/08 - The experimental code has been merged into the "standard" FED.IPL version, it was only about 0.2KW larger and has gotten fairly extensive testing (more than the original has) so was time to merge. For the moment, both AEDIT.IPL and FED.IPL contain the exactly same word code, version 1.51G matching the present disk simulation build. FEDUTIL.IPL was updated to correct bugs in LDTXT ALOAD and CKARRAY, the latter bug was caused by format differences between the new and old array formats, another reason to do away with the original version and update to the new code.

3/15/08 - modified AEDIT.IPL's FED (FEDIT and SVFILE) to make it try harder to save the file. I was editing stuff in mixed case (not normal for me but was writing docs) and when it asked to save typed y instead of Y. As I was running it "run-and-forget" mode from a menu I almost lost the file (SVFILE no longer in memory to save again, to reload it would overwrite the file in memory). To get the data back I dropped to a prompt and did "# NOTES" 2000 AM2F (in retrospec should have specified 174000 to save all of alt mem), FED still wouldn't go for it so booted a SFS/EDIT build and ran LDTXT, gave me a X stack error when it hit the uncleanedup data at the end but nevertheless got my file back :-) After that I totally removed the save? prompt and modified the file exists part to prompt for a new name if the delete prompt not confirmed, the new name has to be entered empty to abandon. Loops until it gets a valid name with a confirmed delete, or nothing at all. Also noticed it refused to save a one-line file, fixed. The lost-file issue is only a problem when running from a menu such as DMENU or from the SFS library, so updated the raw IPL file. Not a problem if using the SFS/EDIT build, just SVFILE again, so will test this fix a bit before updating the editbuilds.zip file.

2/22/08 - modified AEDIT.IPL and sfsedit.abs to remove page-delete function, added code to zero empty lines and report true size upon exit to avoid growth. Fixed a potential bug in SVFILE, no longer depends on MPAG being correctly set (like when accidently forgetting the editor before saving the newly edited editor then reloading from alt mem - SVFILE only saved one block, had to AEDIT again then it worked). Also fixed a doc bug in the AEDIT word comments - MPAG is set to the last page with a CRLF in the first line, not the last line. Noticed another thing, this probably doesn't count as a bug but if there's trash in alt mem it might appear as pages are added, causing the delete function to act funny due to the out-of-place CRLF's (but it still works). Using ZAM before starting a new edit avoids this glitch.

2/18/08 - modified AEDIT.IPL and sfsedit.abs for faster screen updates by skipping spaces.

2/14/08 - slightly modified FED.IPL to be compatible with the SFS library, no code change. Updated the edit builds zip to the latest versions, the stdedit.abs build contains the stock FED.IPL and FEDUTIL.IPL, the sfsedit.abs build contains AEDIT.IPL and FEDUTIL.IPL (and LDTXT). Printer driver added to both, sfsedit.abs also contains HP2645 control words.

2/13/08 - modified the utilities package to add ALOAD and fix flaws in the MASAVE and CALIST utilities, which previously required the last page be viewed in AEDIT to fully format it.

2/9/08 - removed redundant fsaedit.ipl and aeditutl.ipl files. Use fedutil.ipl for the utilities if using the experimental aedit.ipl version.

2/1/08 - split up fsaedit.ipl into fed.ipl and fedutil.ipl for inclusion with HP-IPL/OS, need to save the relatively compact original version before it overbloats itself. No code changes but added immediate code to make sure ZAM gets defined, detect whether or not to load the disk words, and define a pad variable if necessary to avoid page errors (so it can load as-is into the stock DMS build).


AEDIT is not like PC editors. PC's have memory-mapped displays and can update a screen instantly, a HP mini editor is limited by the speed of its serial console interface often running at 2400 baud and might take several seconds to refresh the screen. PC's can access a simple array of memory bytes, a HP mini stores two characters per memory location which must be unpacked and packed for each read read and write. Inserting an odd number of bytes into a byte array on a HP mini compounds the problem as each byte in each word has to be shifted and merged with the destination word. PC's typically run at dozens or hundreds of MIPs, a HP 21xx mini is lucky to hit 1 MIP. Clearly a different approach is needed to implement a usable full-screen editor for HP-IPL/OS.

AEDIT greatly simplifies the programming by storing the file being edited as an array. Each line is always 78 characters long with a CRLF in positions 79 and 80, thus lines always begin on a word boundary and when inserting or deleting words on a line at most only 40 words have to be byte-shifted, line inserts and deletes always move data up and down by 40 words, and each line begins at a predictable location in memory without requiring extra data structures. To avoid slow screen refreshes the file is accessed 23 lines at a time, leaving the 24th line available for help hints and status. There's room for improvement here, presently I find myself inserting empty lines to push the code I'm editing into the next page so I can look at the code as one chunk, then removing the extra lines afterwards. The paged array format limits the file size to a maximum of 782 lines, or 34 pages (00 to 41 octal) of 23 lines each. File size is tracked by the number of pages, always a multiple of 3460 octal bytes with file space after the last text line zeroed.


The AEDIT word operates on alternate memory. There's no provision for clearing alternate memory for starting a new file, disk builds include the ZAM (zero alternate memory) word to use for clearing memory to start a new edit. If using on a disk-less system load altutil.ipl which includes a ZAM, or type it in directly... [only needed for AEDIT.IPL, FED.IPL includes it]


HP-IPL/OS must be set to OCTAL before running AEDIT or it crashes with a string error. HP-IPL/OS should not be operated in DECIMAL mode anyway (except when doing conversions) so this "bug" is intentionally not fixed. Make sure the screen words are set to the proper terminal type, enter TERMINAL to toggle between ANSI and HP mode.

After doing ZAM AEDIT the screen should be empty except for the last line which lists the control keys, insert and graphics status, the current page and the last page. Page counts are in octal and start at zero so initially it'll say page 00 of 00. If AEDIT is exited and rerun it resumes editing on the page it was on, which might happen as the control-Q exit key is right next to the control-W key for moving the cursor up. Under sim control-E halts so if that happens enter c to continue then control-P and enter the page you're on, or do control-V control-C to flip forward and back a page. The editor starts in overwrite mode, to move the characters after the cursor press control-T select insert mode (the status line indicates by printing T=ins or T=ovr), insert mode slows it down quite a bit so control-T again when done inserting or deleting. Backspace does the usual thing, Enter moves the cursor to the next line column one, or if at the end of a page flips to the next page. Control-I inserts an empty line at the cursor, control-D deletes the line under the cursor. Be careful, it's right next to the control-S key which moves the cursor left, there is no undo.

After editing the file press control-Q to return to the HP-IPL/OS prompt, if IPL code is being edited it can be loaded by doing 2 MSUSER <MS (or just ALOAD if the utility package is loaded) and immediately tested. There should be a CONSOLE on the last line to undirect the redirection but if forgotten it seems to tolerate it with an error message. The utilities package provides an ALOAD word which does the load after making sure there's edited text in alternate memory.

For disk-less systems or to import regular text, run CALOAD (in the utility package) and paste the text using HyperTerminal or something which supports setting character and line delay, set the delays large enough to avoid dropped characters. When done enter ~TERMINATE~ on a line by itself or add as the last line of the file being imported. To export the text run CALIST and capture the text using the terminal. Regular text can be loaded from papertape (emulator, or wherever MS in is set to) using MALOAD, the last line must be ~TERMINATE~ or it will hang at the end requiring a halt and run from 2. To punch the edited file to papertape (or MS out) enter MASAVE, it automatically adds the ~TERMINATE~ line.

For XDOS-based disk systems the edited file can be saved by entering "FILE" SVFILE and reloaded for editing by entering "FILE" LDFILE AEDIT, the file being loaded must be in array format. For convenience FED can be used to prompt for the filename(s) to load and save. FED is the first word of the editor package so it can be used to run-and-forget from the SFS library (import using MS2L and name "FED"), or from DMENU (name the editor IPL "$ FED"). SFS supports redirection of files enabling the LDTXT word (in the utility package) to load regular text files from disk by redirecting them into the MALOAD utility. A similar wrapper could be made for MASAVE but once in array format there's little advantage to compacting the trailing spaces, HP-IPL/OS files are always 32KW long regardless of content.

Using graphical HP characters

On a real HP terminal (or something compatible such as QCTerm) AEDIT supports entering and displaying alternate graphical characters. Here's what's available...

To select graphics press control-N, further keystrokes will be displayed using the alternate character set and stored in the file with bit 7 set (sent to the terminal with bit 7 clear). Press control-O to return to regular text. When graphics "mode" is selected a control-N is sent before each key prompt to force the character to be displayed using the graphics character set. This is an attempt at a mode switch, however HP terminals switch attributes based on position leading to odd bug-like behaviors. Cursoring while set to graphics mode will change characters cursored through to graphics, press control-O before cursoring through text or changing pages. Pressing control-N or control-O on text will flip the characters after the cursor up to the first graphical character. Cursoring in text mode preserves graphics and text characters if moving forward, so lines can be restored by cursoring back and forth over them. To fully restore the screen to the stored edit data press control-O (if not in text mode) then press control-V then control-C.

Speaking of cursoring, whether using an HP terminal (or emulation) or a PC VT100/ANSI terminal, avoid pressing the conventional cursor keys. Even if they move the cursor (the effect varies) AEDIT won't get the message and will store the next character where it thinks the current position is.

When writing graphical IPL code, do 16 PCHR to switch to graphics characters and 17 PCHR to switch back to text, otherwise HP-IPL/OS will just print the underlying character. While editing the graphical versions can be displayed for convenience. Here's a simple example...

When this IPL loaded it looks like this...

This technique can be combined with CLS and POS to create more artful apps, or just to doodle.

Observations and Speculations

Reality check (if there is such a thing in an old-comp hobby) - just how "good" is AEDIT? That depends on how it's used and what else is available. For major editing jobs (such as creating HP-IPL/OS), using a PC editor and building a HP21xx software system under simulation is the only practical way to go. Otherwise it'd just take too long to implement the kind of stuff I play around with, even if the editor was perfect. Once the system has been implemented and moved to a real HP-21MX minicomputer the situation is different, the time it takes to set up and transfer a PC-edited file for each test iteration has to be considered, and having even a crude built-in editor can save time. In my case I have only one serial port available making it quite inconvenient to load PC-edited IPL files and I lose my console when I do, having ANY editor that avoids having to do that is a huge plus and saves time when I'm programming on real hardware. Sure I'd like AEDIT to be better but right now even the base version is much more convenient than how I used to do it... essentially type in words one at a time with no editing ability at all. Even now that I have an IDE disk connected to my HP, to use PC-edited material I have import the edited file into my simulation, swap the IDE disk to a USB drive tray and overwrite the system with a new copy, then swap the cables back and reboot. If there's stuff on the real-IDE system I have to save it's even more complicated. Either that or I'd have to (slowly) load the edited file in via PTR, lose the console and any error messages that would have been displayed. Now that I have FED and AEDIT I can just make the changes and immediately test the results, much better! Even if it is slow and limited.

A better judgement of effectiveness would be to compare AEDIT to other editing solutions available in the late '70's. I'm not that familiar with all that was available, but I've tried to use the RTE-IVB EDIT/1000 under simulation and found that I'd need to become very familiar with it to get anything done. It has dozens of useful features but everything has to be specified as a command, kind of reminds me of a fancy version of the SFS line editor. AEDIT lets me cursor around the screen and change things as needed, and presently doesn't offer much beyond flipping pages and inserting and deleting lines but I don't really need fancy editing features - I'm still totally free to use my PC (and do) when I need that kind of stuff.

Nevertheless there are a few things that can be done to enrich the editing experience...

A function that moves the current line and everything after it to the next page then switch to it so code can be edited with the appropriate bits visible at once. A companion function would remove the empty lines to compact it back. This would permit using the editor like the 2400 baud console environment dictates - avoid screen refresh as much as possible.

Buffer deleted lines so they can be "pasted" back somewhere else, or simply undo an accidental deletion. This will need a lot of thought to implement correctly.

Some way to split and join lines? Perhaps control-I insert can move the remainder of the line to a new line and insert a blank line only if done with the cursor in the first column, and control-D could delete from the cursor to the end of the line and move however much text fits from the following line (word wrap). With the cursor in column 1 it would behave just as it does now.

[however... despite its quirks I'm not that inspired to change it so long as it keeps on working...]

HP-IPL/OS testing page