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).
About AEDIT
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.
Using AEDIT
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]
OCTAL DEFINE ZAM
MS_SAVE #0 ZEROBLOCK #0 37 +DO @BLK GET INDEX 2000 MUL DUP
IFZ DROP 2 ENDIF 2000 C>ACOPY +LOOP MS_RESTORE END
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...]