Main HP-IPL/OS page is here.
(older)
IPL,
assembly
and
text
files
are
here.
Instructions for simulating a magtape/disk system are here.
Pre-built 7906 disk simulation loaded with games and stuff is here.
Plans for a PTR emulator and IDE disk interface and software links
are here.
Plans for a PTR/PTP emulator and USB disk adapter are here.
The editor page is here. The 31KW MSU
BASIC
page is here.
Updates and Testing Files...
Added/modified packages for 1.52 and above include...
sham.ipl - utility for
dumping alternate memory as octal and text
binpatch.ipl -
utility
for patching the I/O slots of existing binaries
msupatch.ipl -
utility
for patching the 31KW MSU BASIC binary
sfs.ipl - SFS file access
words, now checks to make sure buffer memory exists
bkfile.ipl - a way to
dump/restore files to/from the console (when PTP isn't available)
ideboot.hpa - went
back to
the original IDE bootrom code
sfslib.ipl (8/30/08) -
a
new library system, replaces lib2.ipl/a2l.ipl/ms2l.ipl
edit.ipl (9/7/08) - a
much
faster
replacement for edit.ipl SFS line editor
print.ipl (3/15/09)
- fixed printer driver with new/renamed words
screen.ipl and hpscreen.ipl
(5/22/10) -
fixed COLOR so dim FG on color BG works
Version 1.60 testing archive includes a new kernel with
dictionary
overflow prevention and infrastructure for a new ERASE word that
removes the last package loaded. The new archive includes new
html-style docs, a few new
builds and packages, and sources tools and docs available
elsewhere but
should be included for self-sufficiency.
Fixes/additions for the 1.6x testing archive include...
(most
of these also work with older versions)
hpiplos1.asm
(6/9/10) - a
new kernel with overflow protection and @LLP (address of last load
point)
extra.ipl (6/5/10) - a
new
extra package for v1.6 with an ERASE that removes all words from
the
last load
vdos.ipl
(11/17/10) - words for controlling a VDRIVE disk module and
streaming
firmware
vdosext.ipl
(6/14/11) - extra VDOS words for HP21MX machines (here's a patch for
existing VDOS builds)
vintage.ipl
(6/14/11) - VDOS words for compiling and linking software using
vintage tools
cross.ipl
(12/1/10) - words for running and passing data to and from an
HPBASIC
app
svbas.ipl
(12/4/10) - a word for saving HPBASIC apps to MS out in ABS format
dm2.ipl (6/13/11)
- disk menu for use
with MSU BASIC or HPBASIC
dmenu.ipl (6/13/11) -
simpler
disk menu for HPBASIC
dms.ipl (6/13/11) -
dynamic
mapping system - new swapper in ALTSAVE clears A/B
altutil.ipl (6/13/11)
-
alternate memory utilities
mkbcs.ipl (6/13/11) -
makes
a simh hp2100 script for compiling apps
sioutil.ipl (6/13/11)
-
slot-patches SIO driver, now compatible with other versions
xutils.ipl (1/1/12) -
modified ABS2F to use location 157 for temp (instead of 100)
Version 1.66 has a fixed 7906 driver (which had a bug that caused
it to fail with newer versions of the SimH hp2100 simulator) and
the build scripts have been changed to be more compatible. See the
changes.txt file.
The following source files were changed...
7906.ipl (and 7906ldr.hpa) (3/5/21)
- changed 102706/STC 6 to 103706/STC 6,C to properly start the DMA
transfer
mkbcs.ipl (3/6/21) -
changed the script output to use attach -e ptr file.abs followed
by boot ptr instead of load file.abs
The latest testing archive is in the hpiplos_main_testing.zip
file. This is really the real main package now.
Extra HPBASIC stuff including games binaries is in the hpbapps.zip
file.
Note... this is a log of recent development and related
web-related
activity. Text here gets written in bits then get consolidated,
moved
to other files, edited and/or deleted as needed.
3/6/21 - Recently I started switching to the new SimH hp2100
simulator and discovered the 7906 Disk Sim didn't work with it.
Well darn! It booted but XLOAD didn't load work unless I modified
it to load using F2AM 77000 RUN etc. DBOOT was also broken.
Tracked it down to the LDFB code in the 7906 driver, forgot the ,C
in the STC 6,C instruction to start the DMA transfer - surprised
it worked at all, was like that all this time and didn't know it
until I upgraded the simulator. Once I started comparing the boot
code to the very similar LDFB code the bug was obvious. The LDFB
version is also missing the CLC/CLF slot before running the binary
but that doesn't seem to matter, not fixing that makes it possible
to fix existing builds by changing a single memory location then
doing DGEN.
9/16/12 - Still here :-) Not a lot of old-comp activity lately,
but
Bob Shannon has been having some troubles with his system, we're
trying to track it down. Symtom is there seems to be a branch into
low
memory when the !DMS word is executed, where it hits a halt at
location 150 (octal, left-over cruft
from some utility used in the past, locations from 150-157 are
often
used by utilities for temporary storage). The wayward jump is to
between 101 and 147 octal (a halt at 100 isn't reached, one at 147
is),
and the problem seems to occur with all DMS versions of HP-IPL/OS.
Suspiciously the machine he's
trying to get going uses DMS microcode versions (13307-800)
'36-'38
whereas the
older machines we tested on uses microcode '33-'35. No idea what
the
difference is, not convinced that has anything to do with anything
but
we may be looking at an incompatibility, or could be a hardware
problem
or a mismatch between firmware and board versions... will update
when I
have more info.
This wasn't it, but this issue reminded me of a possible bug to
watch out for -
invalid IRQ vectors in locations 6 to 25.
DGEN, XSAVE, etc save an entire 31KW memory image, so if there is
a
vector down there, a build is saved, then slots get rearranged,
then
whammo... unpredictable crash. Any I/O activity with interrupts
enabled
can trigger a fault if the corresponding vector location is
invalid.
So... if rearranging
slot addresses, boot with autostart words disabled (put 177777 in
the
switch register before running from location 2) and enter/run the
following...
OCTAL DEFINE CLRINTS
6 25 +DO INDEX 0 PUT END
CLRINTS
FORGET CLRINTS (and confirm)
...now clear the switch register, run from location 2 and if all
is
well, resave the build. It is tempting to add something like this
to
the kernel to make sure the vectors always start cleared, but
besides
wasting memory such a thing could get in the way of someone
manually
installing a custom vector so I resist. But there probably should
be a
note about this in the readme. Another thing to keep in mind that
since
HP-IPL/OS allows the user to do just about anything (including
corrupting the build), be very careful when saving builds. If an
improper command is entered (having no apparent effect) and it
happens
to corrupt a system word and then the build is saved, that's a
problem.
My
own rule here is I avoid saving a build I've been hacking on to
anything important, once I know what I want to do I reload the
base
build, make the changes, then immediately resave. That way I don't
accidentally corrupt a build from misplaced fingers.
1/1/12 - Updated the testing archive to version 1.65, only
build-related code change is the XDOS utility word ABS2F now
doesn't
stomp on location 100 (locations 100-147 are supposed to be
reserved
for applications and user code). Could replace the 1's with #1 and
save
5 more memory locations but that'd change the size and risk having
to
do IPL rearrangements so left that alone. Details. Also updated
Asm21
to the new 1.07 version with FP and DMS support (should now
assemble
most absolute asm sources, even the vintage malformed stuff - at
least
the ones I noticed), dropped some of the outdated bash scripts,
added a
new doc that tries to briefly explain how the core threaded
interpreter
works (sometimes the simplicity of it gets lost in the details),
added
more info about how I recovered the SIO/BCS assembly source from
the
magtape images. Fixed some typos.. one of the urls pointed to my
corewar page (ugh again but I'm sure there are other typos in all
that
stuff but so long as I'm not aware of them then it's ok:-).
7/6/11 - Almost... forgot to change the 1.64 archive date to
2011..ugh. Fixed, along with some other minor tweaks including an
updated Asm21 assembler and my script for using the vintage
EXTASMB
assembler, now archive version 1.64A. The updated Asm21 just fixes
the
ORR and IFZ psuedo-instructions, a new version of Asm21 is in the
works
that includes DMS and FP instructions and can handle the malformed
OCT
and ", I" instructions (space before the I) present in the old
EXTASMB
and ALGOL assembly sources but it's still under development so for
now
use the vintage assembler if the old stuff needs to be
reassembled...
plus it might be awhile if ever before Asm21 can handle
relocatable
source code for linking using BCS. No real need for that since the
vintage tools have to be used anyway for linking and compiling
ALGOL/FORTRAN modules but it would be interesting to figure out
the
"rel" format and how they did away with page errors and handled
external references in the old days - software techniques that are
now
just a given. Also included my PT conversion of The Oregon Trail,
which
has its own Wikipedia
page including links to modern conversions and a page with
information about the original HP2000 versions.
6/14/11 - OK went for it... updated the "testing" package to
1.64.
While testing discovered a major issue with VDOS' UFSIZE word..
realized I had forgot to add the BCSLIB.REL file to my binary test
directory but had a copy in another directory. The USB disk
adapter
does not support streaming files between two different directories
(due
to the way the VDRIVE works), so wrote a "DDCP" word (on line
using the
funky full-screen editor, it's now in the ipl_notes.txt file) that
reads
a file from one directory into alt mem, changes to another
directory
and writes out the file. Needs UFSIZE to see how big the file is
to
know how much to read and write. Only it didn't work, always
returned 0
bytes (it used to work..). Problem was the VDRIVE takes more time
than
I anticipated to return the size so fixed it by using &WFVDR
(wait
for vdrive response) instead of <VDR. With that fixed, copied
the
file I needed and finished testing. It's a pretty drastic update,
just
about everything had to be rebuilt to incorporate the new DMS
package
but thankfully all that is scripted now. While tweaking the
archive and
to get it all on the same page, replaced the old vintage binaries
with
the recovered source and binaries, no unknown "binary blobs" now,
everything has source so if something doesn't work right can
figure out
why.
The other big change as far as the web site goes is I updated the
linked IPL/assembly/text files to reflect the latest 1.6 versions,
and
removed the main readme.txt and other readme's as they are too
archive-specific, instead linked the HTML docs I wrote covering
the base
system
and how to make a custom
build
from scratch on real hardware with not much more than a PTR
emulator
and a console. That last doc is already a bit out of date, some of
the
things it mentions for dealing with failed loads were addressed in
v1.6
- now if a load fails just enter ERASE and confirm. Of course that
matters only to someone who actually needs to make a build to do
something different... there are already many pre-configured
builds for
(probably too many) situations, can just use one of those should
the
need arise. As with many projects development here is driven
mostly by
what I want to do... as a language HP-IPL/OS has been pretty much
"done" for years (occasionally getting updated at the base level
to fix
old nags), almost all of the new stuff is related to fixing and
running
other stuff. What interests me is being able to take old code I
find on
the net and turn it into programs I can run and enjoy... so I make
dumpers, patchers, menus, loaders, words that make it easier to
use
vintage compilers, that kind of stuff so in the end I can sit back
and
play some old game like it would have been played in the '70's.
Well
mostly.. if I don't like the way the original worked (if even
possible
to run the original) I'll hack it to make it work the way I want
or
just use the old tools to make something new. Which is what users
did
back then so that's part of the "experience". And now I have to
get
back to real work... received the specs I was waiting on.
6/12/11 - Updated the 7906 sim package, now uses the "BASIC2"
adaptation with a functional backspace and doesn't spew the
terminal
with unprintable TTY characters like MSU BASIC did, and the BCS
apps no
longer require CRLF terminal settings. Little things like that
make a
big difference. The SIO/BCS source "recovery" option is pretty
much
done, the new sim package includes the tools on disk with words
for
operating them (they still require attaching ptr and ptp to source
code
and binaries, it's still paper-tape software). Source code for the
assembler, ALGOL, FORTRAN, BCS, library, SIO/BCS drivers, newly
assembled binaries, docs and tools are in the vintagetools.zip
archive. Very cool stuff, at least the vintage material - my
homemade tools for processing the raw magtape images and
assembling the
library source are crude and probably need work, but they got the
job
done. Of course nothing new there, most of my tools are crude
(including HP-IPL/OS:-). I dropped quite a bit of esoteric IPL
material
from the simulation... the focus seems to be shifting now from
testing
new IPL stuff to merely using HP-IPL/OS as an operating system for
running vintage stuff. Cramming a bunch of words or IPL packages
in an
SFS library file then running and forgetting them is cool and all,
but
when it comes down to it, mostly what I want to do is press keys
to run
games from a menu, type simple commands to compile stuff, be able
to
examine and patch binaries and other fairly simple things. For
what I
do, SFS earns its keep bigtime by letting me store ABS overlays on
disk, very handy for running FORTRAN pass 2. Getting back to the
basics... and exploring all the new vintage code that has become
available.
This is not to say there won't be any more HP-IPL/OS development,
far from it. In the process of working with the BASIC/SIO/BCS
material
I learned that 2027 is a much better BASIC re-entry vector, the
SIO TTY
driver I found is totally different than the old one I was using,
BCS
requires that the B register be 0 when running (or else location
106
needs to point to an exit sub), and now not all BCS apps require
CRLF
enters. Nice stuff to know but it affects a few IPL packages...
dm2.ipl - fix message regarding BCS apps, change BASIC re-enter
vector to 2027 (already patched in the 7906 sim version).
dmenu.ipl - same fix as for dm2.ipl (or just remove this package,
nothing really uses it)
altutil.ipl - change BASIC re-enter vector to 2027 in the ALTABS
word.
ipl_notes.txt - change BASIC re-enter vector to 2027 in the BSAVE
word.
sioutil.ipl - fix so the actual locations of I/O instructions
don't
matter, or at least only work on the old version.
mkbcs.ipl - fix it so it correctly does d 0-77677 0 when clearing,
eliminate halt workaround for BCS.
dms.ipl - fix the swapper in ALTSAVE so that it clears A/B before
jumping to the binary.
vintage.ipl - fix the message in the link word about halting BCS
when
done, with the swapper fix won't have to.
...and rebuild all affected builds and docs. The old versions
aren't
really broken, they just have cosmetic effects that have been
known for
awhile. The difference is now I know what causes the effects, so
now I
can fix them. Eventually anyway, might take awhile and before I do
maybe dig more through the newly posted material to see if any
other
compatibility fixes are needed to run some cool thing, and see
what
else might need doing.
6/4/11 - Just a "I'm still here" post... and some good news -
there
has been a very large code drop into the BitSavers bits/HP
section.
I've been slammed with work (I design ANR headsets and try to
keep
musicians happy by fixing their amps) so I haven't had much time
for
old-comp hacking, but every now and then I power up my old HP mini
with
my homemade USB disk controller and have some fun... and
contemplate
the state of HP-IPL/OS. Yes, it's just a crude homemade OS for a
vintage computer that means little in the real world, but that's
what
makes it fun. Yet despite being just a fun study in "what would it
take", there are still a few real-world benefits. These days I use
"blassic" a lot, but for some things it is faster for me to use
HP-IPL/OS and/or HPBASIC to write little one-off programs (and if
the
app requires parsing arbitrary file bytes it's usually lots easier
to
write a few lines of streaming IPL rather than messing with
anything
modern). Thanks to SimH and some scripting I can double-click HP
mini
apps and run them just as easily as an app written in any other
language. Thanks to BitSavers and the single-user BASIC source,
now I
can double-click my customized basic2.abs binary, type in some
code,
type BYE and save it to a new app. That covers most of my
low-precision
computational needs, which usually involving inputing some numbers
then
spitting out the answers I need. But perhaps one of the biggest
applications of old-comp tech for me comes from building hardware
to
attach to my machine. Making the USB disk controller taught me how
to
use the more the powerful PIC18 chips, and that directly impacts
real-world apps. Now I have an automated tester that can save
thousands
in labor costs and my own bootloader that lets me update embedded
app
code without having to remove the chip and stick it in a
programmer,
and unlike existing bootloaders, without having to dance around
the
bootloader or use a custom PC client. Now I can just send a
standard
hex file using a serial terminal. I can't really say this came
about
because of old-comp hacking, but in this case old-comp definitely
gave
me a venue in which to work out the tech before tackling a
real-world
app. And likewise, the need for more powerful (but still simple
and
rock-solid - not ARM) embedded processing for real-world apps
caused
the USB disk adapter to be made and now I have another toy, so the
two
worlds definitely intersect and feed off of each other.
The present "hpiplos_main_testing.zip" package is really the main
package to use, just subject to updates that might or might not
stick.
The old "hpiplos_main.zip" package works (other than a few
slightly
buggy IPL's like disk menus that can't count to Z) but it doesn't
have
kernel-level dictionary overflow protection and the ability to
remove
all words from the last loaded package in one step. At some point
I
probably should package up a new v1.6 "main" package with the
latest
code but without all the non-HP-IPL/OS bloat present in the
testing
package - but there are more important things to do (like
streamlining
the use of vintage compilers) and some of it might affect the
package... so it can wait.
The 7906 simulation package needs to be updated to use the new
basic2.abs base which has a real backspace function and works
better
with modern terminal emulators than the present MSU BASIC
solution.
Also can add a few new games such as Sea Battle and a new
conversion of
The Oregon Trail that I'm working on. [..]
need to finish up Trail, patch the BCS apps so they'll work
without
terminal changes (see below), add vintage compiler tools and write
docs
and stuff. [done]
My current project is going through a bunch of stuff that got
added
to BitSaver's HP bits section last month. Not everything is
directly
accessible due to an index file in one of the directories, but no
problem, copied new "what's new" entries to a file, sorted it, and
used
an IPL program to turn it into a huge HTML index file...
;MKINDEX - reads lines from PTR, prefixes url and writes to PTP in
;the form of a HTML index file. At EOF halts with overflow (or hang),
;to avoid add ~TERMINATE~ as the last line of the input file.
OCTAL DEFINE MKINDEX
"Enter URL prefix: " $PRINT $IN
"<PRE>" MS$OUT MSCRLF
DO
$DUP ;dup prefix line
MS$IN ;read line from input file
"~TERMINATE~" $EQUAL DUP IFZ
$DUP X>>Y ;save line to Y stack for label
$CAT ;combine with prefix
"<A HREF=" MS$OUT 42 MSBOUT MS$OUT 42 MSBOUT ">" MS$OUT
Y>>X MS$OUT "</A>" MS$OUT MSCRLF
ENDIF
UNTIL ;loop until ~TERMINATE~ is read or it hangs at EOF
$DROP
"</PRE>" MS$OUT MSCRLF
END
CONSOLE
(could have used almost any language for that, in this case
Blassic
or QBasic would have been easier but whatever)
Wow. Just the whatsnew.txt entries are about 340K, yielding a 1
meg
index. Most of the material in the form of raw magtape dumps, it's
going to take work to turn into reusable files. Many of the source
files appear corrupted but that's easy to fix, just set bit 7 to
0.
This IPL does that...
;clear bit 7 from PTR to PTP, terminate when result is 0
OCTAL DEFINE NB7
DO MSBIN 177 AND DUP IFNZ DUP MSBOUT ENDIF WHILE END
CONSOLE
(this is one of those binary processing apps that's easier to do
with HP-IPL/OS)
...I think this one needs to be wrapped in a script so I can
right-click raw files and turn into plain text.. done. So how to
do
that? This is how I did it in Ubuntu - starting with hposdms.abs
or
just about any non-disk HP-IPL/OS build, first create a HLT word
then
add the above IPL as an autostart word, ending with HLT...
HP 2100 (modified) simulator V3.8-1
HP-IPL/OS DMS 1.60
? CREATE HLT
033567 : HLT 1
033570 : END
? DEFINE !NB7
> DO MSBIN 177 AND DUP IFNZ DUP MSBOUT ENDIF WHILE HLT END
?
Simulation stopped, P: 02226 (JMP 2225)
sim>attach ptp hpnb7.abs
PTP: creating new file
sim>c
? SYSALL
Writing..............
?
...put the hpnb7.abs binary somewhere and make a bash script to
run
it...
#!/bin/bash
tmpdir=/tmp
hpnb7abs=/home/terry/hpnb7.abs
echo "set cpu 21MX" > $tmpdir/hpnb7.tmp
echo "set cpu 256K" >> $tmpdir/hpnb7.tmp
echo "set clk dev=10" >> $tmpdir/hpnb7.tmp
echo "set tty dev=11" >> $tmpdir/hpnb7.tmp
echo "set ptr dev=12" >> $tmpdir/hpnb7.tmp
echo "set ptp dev=13" >> $tmpdir/hpnb7.tmp
echo "attach ptr $1" >> $tmpdir/hpnb7.tmp
echo "attach ptp $1.txt" >> $tmpdir/hpnb7.tmp
echo "load $hpnb7abs" >> $tmpdir/hpnb7.tmp
echo "run 2" >> $tmpdir/hpnb7.tmp
echo "detach ptp" >> $tmpdir/hpnb7.tmp
echo "exit" >> $tmpdir/hpnb7.tmp
xterm -e hp2100 $tmpdir/hpnb7.tmp
rm $tmpdir/hpnb7.tmp
...I called it StripBit7 and put it in my nautilus-scripts
directory
so I can run it on any file. Not robust software, must not be any
spaces in the filename or it might wipe out the source file
instead,
but for me that's not an issue since I never save normal files
with
spaces in them. Theoretically this should be doable in Windows but
not
sure how that OS handles quotes these days, there cannot be any
quote
characters in the attach lines.
It's going to take awhile to go through all the files but it
appears
that a very large portion of the HP21xx software library is here.
[...]
[6/7/11 - ALGOL, FORTRAN, EXTASMB, BCSPREP and the drivers all
assemble cleanly, but the BCSLIB source consists of 76 ASMB chunks
and
as far as I can tell the papertape version of EXTASMB can only
assemble
one chunk at a time (the original was probably
assembled using a magtape or RTE system). To compensate made a
really
scary bash script that uses blassic and flip to break the source
file
into separate ASMB chunks which are assembled separately to the
same
output file while suppressing leaders and trailers. The simple TTY
term
poke patch didn't work out.. making BCS work with a regular
terminal
with CR enters required modifying the driver and reconfiguring.
Seems
to work under sim but need to test on real hardware... messing
with TTY
in an interrupt-driven environment can have side effects. At this
point
I've recreated the essential BCS toolchain from source code except
for
the SIO drivers, still using my old configured binary for that.
Definitely getting there!]
Thanks goes out the CHM, BitSavers, and to all who preserve code
from the past. And to the one who wrote the "saveit" program that
separates the magtape images into individual files! Crude but
extremely
cool.
12/21/10 - Found and converted an old BASIC game called "Sea Battle"...
Here's the source
code
and a log
of
it beating me (I thought that was a ship). Added to the
hpbapps
collection [and to the games page].
12/12/10 - I was working on some "history-related" stuff and ran
across a 4KW build of HP-IPL/OS (v0.34) from 2002. OK... but I
cheated
by using Octapus to save it, requiring 8KW. Not truly 4KW, so
grafted
the punch code from the "smovl" overlay into it to make a stand-alone
4KW
HP-IPL/OS capable of saving itself and anything added to it.
Only
391 words free (about 0.76K bytes) so won't be adding much but
that's
enough for a line automata display and a little splat game. Here's
the
WORDS display for the newly-configured 4KW kernel...
HP-IPL/OS 4K 0.34P
? WORDS
DO LOOP +DO INDEx +LOOx IFNZ IFZ IF<0 ENDIx ELSE UNTIx
WHILx EXECxxx AND OR XOR ADD SUB INC DEC NOT 2CPL DUP DROP
OVER ROT SWAP GET PUT PNUM CRLF DECIxxx OCTAx BINAxx SP>S SB>S
XP>S END DMPS S>SR SR>S PCHR PWRD PSTR S>X X>S S>Y Y>S S>Z
Z>S MUL DIV ASL ASR ROL ROR X>>Y X>>Z Y>>X Z>>X $CPY $SWAx
$DUP $DROx $LEN $ADR $XTExx $HEAx $APPxxx $TAIx $PUT $GET CHRIx
WORDx DEFIxx RUN RND $STR $IN $CAT $VAL <>COx >PTP <PTR #0 #1
PUNCx
EOD=007070
?
...now that's minimalistic! EOD can go to 7677 before it gets
into
the bootloader.
In other file news, while the testing archive now includes BASIC
RevA (plain 28KW and with the overlay patches applied), it does
not
include extra stuff like overlay binaries for reconfiguring,
assembly
listings and preloaded BASIC games binaries (except for at the
moment
an 8KW version of OTHOV). That stuff could be regenerated but
requires
installing perl for the assembler and also the SimH HP2100
simulator
unless a good PTR/PTP emulator is available. For the convenience
of
those who might want to actually run this stuff, I put the extra
files
in the hpbapps.zip
file [linked above in the initial section] with several
ready-to-boot
games for 32KW and 8KW machines. The
simulator might still be needed to make different configurations
but
for that included extra scripts to try to simplify the process.
Manually installing PC software can't exactly be described as
simple
but at least in this archive it's not required when all that's
available is a simple PTR emulator (for that matter putting the
stuff
together on a real HP mini with a full PTR/PTP emulator isn't
trivial
either - without perl on a PC for Asm21 it would require using the
vintage EXTASMB assembler, definitely not "easy"). For Windows
users
who do use the simulator, one issue with running terminal-enabled
software is the plain "dos" window can't handle ANSI codes, so
figured
out a possible scripting solution involving launching
HyperTerminal
configured for telnet (only tested with XP under VirtualBox -
YMMV).
Another minor PC nitpick is support for proper ascii-127 "rubout"
backspace that actually stops at the beginning of the field - for
some
terminal emulators (HyperTerminal, Gnome Terminal) have to settle
for a
ascii-8 backspace that can't know when to stop. Konsole and xterm
get
it right. Not only is this an issue for the BASIC backspace patch,
but
also for HP-IPL/OS itself and just about any oldcomp software
running
on anything with hard-wired echo - if the terminal sends 127 for
backspace but then reacts to the character when it echos back,
then it
can't work right on a HP mini. Sometimes I wonder what modern OS
makers
are thinking when they try to support old protocols like this...
it's
really very simple - incoming ascii-8 should always back up the
cursor,
ascii-127 should always be ignored, and permit setting the
terminal so
pressing backspace sends either 8 or 127 depending on the needs -
my
stuff supports either but only the ascii-127 backspace properly
stops,
ascii-8 backspaces back up to the line beginning since I can't
stop the
echo.
12/8/10 - HP-IPL/OS "testing" archive now includes the BASIC
overlay
stuff, now v1.63. Includes a new "basic2.abs" binary w/cross2,
Octapus
and the backspace patch, can be used from HP-IPL/OS, stand-alone
on a
32KW+ machine or under sim - especially handy since it has a
built-in
puncher, doesn't require an external save utility to create binary
apps, just PTR and PTP devices and some way to change the
"papertape"
files/roms/etc. Finished up a terminal-enabled
OTH,
uses
a
ANSI-colored
display...
Cool stuff (for old-comp), the program includes a set of
subroutines at the end which might be useful for playing around
with
the overlay, stuff like clear screen, home, position cursor, set
colors, etc.
12/5/10 - Here's a backspace
patch
for 28KW BASIC with the cross2 version of the overlay. With the
patch
applied the regular backspace key can be used to make corrections,
should work with most terminals that send ascii-8 or ascii-127.
I've
been wanting this one for years, using "_" for corrections might
be OK
for a TTY machine but these days we have terminals that can
actually
erase characters.
12/4/10 - Finally got around to real-hardware testing.. oops bit
7
of char gets is invalid with a 7-bit parity console.. fixed. There
are
now 3 versions of the BASIC overlay in testing, the original
version
(with fixes) in the bascross.txt
file
that uses 21MX hardware fix/float instructions, org'd to 72000
octal
and exits to HP-IPL/OS upon entering "BYE"; a general-purpose
stand-alone version in the cross2.asm
file
that doesn't require hardware FP and has a menu with options for
punching a stand-alone BASIC application, patching run and BYE
behavior, help for calls and options to run HP-IPL/OS and
Octapus-D if
present; and a version optimized for 8KW in the smovl.asm
file
that includes a simplified self-save option for punching
stand-alone
BASIC apps. All support the same added CALL commands except for
the 8KW
version which (obviously) doesn't have the DMS-specific
exit-to-HP-IPL/OS calls. Between these three versions it should be
possible to configure a version of the overlay that works with
most
configurations. At some point these will probably get added to the
HP-IPL/OS testing archive along with some terminal-enabled games
and
stuff, but first have to make some apps. The BEASTI game is a good
start but it's still a bit slow on real hardware, could use some
speedup tweaks if possible. Can't do anything about the slowness
of my
2400 baud console besides move jumpers on my interface card to
change
it to 9600 baud, but if I do that need to put it on a switch so I
can
still test using the slower speed.
12/1/10 - [...] The new console get/put calls are nice for games
-
here's a terminal-enabled
BEASTI. One issue though - if a key is pressed while BASIC
is
actually running it stops the program. To fix this (sort of) I
figured
out a CALL poke that disables that, causing the program to ignore
errant keystrokes. They still echo to the terminal output so the
screen
refresh prints need to account for that possibility. The program
should
undo the poke before exiting and before normal inputs to allow
normal
stop behavior (entering S). Peeks, pokes and data-passing can be
tricky
- BASIC (as well as the hardware FP instructions) treat 16-bit
integers
as signed, 77777 octal is 32767 but 100000 octal is -32768 (2's
compliment). Care must be taken when poking machine code
instructions,
but just have to remember to subtract 65536 from any value over
32767
for the negative equivalent. Doesn't bother me :-)
11/30/10 - From the Neat Hacks department... [figured out] how to
call a BASIC program from HP-IPL/OS then return, in
effect running an entire BASIC system as if it were a word. Two
components make this possible, an overlay that implements a call
that
exits the system by swapping but instead of running from location
2, it
does JSB 321B,I to continue running HP-IPL/OS from whereever it
was
when it ran the BASIC system. The overlay includes other useful
stuff
like peek, poke, execute and raw console I/O. The other
component is a IPL package that does the heavy lifting for passing
data
between HP-IPL/OS and BASIC's "common" area declared when
dimensioning
arrays using COM instead of DIM, also includes words like BASINIT
BASEDIT and BASRUN for clearing, editing and running BASIC,
patching
the run address appropriately.
11/28/10 - I recently found the complete source code for
papertape
BASIC on BitSavers (under pdf/hp/hp2116/BASIC_Jan70/) - this is a
huge
find for HP21xx hackers, many thanks to all who helped to preserve
this
classic program. The source was in 11 "tapes", with 3 more tapes
for
the prepare program. Using the magic cat I combined them and it
assembled cleanly and produced a perfectly working 20392 Rev A
BASIC.
Super-cool. The only (non) issue was the configure program only
supports 8KW, 16KW, 24KW and 32KW configurations, a few minutes
with an
editor gave me options for 12KW, 20KW and my favorite
configuration,
28KW. I spoke with Bob Shannon (the originator of HP-IPL/OS) and
he
highly encouraged me to add this to the HP-IPL/OS archive, along
with
the SIO/BCS tools so that practically everything needed to
experiment
with HP21xx computers is included and preconfigured for use, at
least
if using the standard HP-IPL/OS slot lineup. So I did that, now
archive
1.62. Hopefully it's all organized and documented sufficiently, no
changes were made to the existing archive material (MSU BASIC
remains)
but added a new "development" build with VDOS, vintage.ipl for use
with
the USB disk adapter and mkbcs.ipl for making build scripts for
simulation, and new docs explaining how to use the material. To
truly
experience what it's like to develop vintage software one really
needs
a sufficiently capable papertape emulator such as the USB disk
adaper
to handle all the read and write file attachments (each
corresponding
to physically changing a papertape). It is not necessary to run
HP-IPL/OS to use the software, rather HP-IPL/OS can be used as
"training wheels" to automate the file attachments using VDOS and
the
USB disk adapter, and print instructions to the console to tell
the
user what buttons to press to make it go, and in some cases edit
source
code to compile.
11/23/10 - I made a set of
words
for VDOS and the new USB disk adapter that operate the vintage
compiler
tools...
"source.asm" "output.ext" ASMB - assembles a program using
EXTASMB,
output can be REL or ABS depending on source
"source.alg" "output.rel" ALGOL - compiles a program to a REL file
using ALGOL
"source.ftn" "output.rel" FORTRAN - compiles a program to a REL
file
using FORTRAN1 and FORTRAN2
"input.rel" "output.abs" LINK - links a REL file using BCS and its
library to produce an ABS binary
The words prepare the files and print instructions, the vintage
software has to be operated by hand by selecting registers and
pressing
switches. Here's a session
log
showing the building of a Reversi
program written in FORTRAN and a chess game written in
ALGOL
and assembly. The vintage compiler binaries were obtained from The
HP2100
Archives, the sio.abs binary was slot-patched using sioutil.ipl and the
bcs.abs
binary was prepared using the instructions in bcs31k_log.txt. This
is a
pretty cool hack, I've been doing this for awhile under simulation
using mkbcs.ipl to
make a
"makefile" script but being able to operate the original programs
on
real hardware is a nice experience. The "Creating USB file"
messages
printed by VDOS give it away that all is not vintage, but that
doesn't
matter - that's just the operating system, the vintage compiler
tools
are stock except for configuring.
11/21/10 [edited 11/23] - [...] This afternoon, perhaps for
the very first time ever on real hardware, I used the USB disk
adapter
with the vintage EXTASMB assembler to assemble the HP-IPL/OS
kernel.
One of the more exciting 20 minutes in HP-IPL/OS history, waiting
for
the error to come but once I got it going the software and
hardware
performed perfectly and punched a working ABS file. [...]
11/19/10 - Updated the "testing" archive to include essential
details for the new PIC-based VDRIVE interface, and fixed a couple
of
bugs in VDOS (an operating system for VDRIVE/USB adapters) - the
original VDOS driver mistakenly tried to use a second command/flag
cycle when I needed was LIA. The 8052 firmware didn't notice the
command glitch but the PIC-based interface picked it up, requiring
extra delay to get past that, especially if interrupts were
enabled.
Also wasn't waiting long enough for a response in the VOWCHECK
work
(checks to see if a file exists)... the VDRIVE "dir" command can
pause
after it outputs the first CR if there are a lot of files in the
directory, changed all of the byte reads following the command to
the
wait form.
11/14/10 - The USB disk
adapter
is pretty much done. I still have a bit more testing to do but so
far
it's really nice - does papertape reader and (theoretically) punch
emulation, works
with VDOS and UDOS, has an LCD screen to show file attachments,
single-letter files can be manually attached using switches or the
serial port can be used to specify full filenames for use without
an
HP-side dos. This should be a workable solution for booting an HP
mini
and loading and saving files, even with a 8KW machine. Or even a
4KW
machine for that matter if you don't mind being limited to UDOS
and/or
Octapus.
10/2/10 - Updated the 7906sim package to v1.60 (finally! the menu not allowing entry Z was bugging me). Version 1.60 is probably beyond testing at this point, it seems to work fine and is what I'm using for other HP-IPL/OS projects... soon the v1.53 archive probably should be removed from the main page with v1.60 in the usual hpiplos_main.zip - only trouble with that plan is my infionline web site doesn't have enough free space to do that until I figure out how to shuffle some stuff around. Another "issue" is that would leave identical content in the testing and main zips.. so maybe I'll defer the whole thing until I got something more worthy of testing in the testing archive... ah the joys of maintaining a hobby programming site that's totally off the beaten path (I'd hate to have to figure stuff like this out for something that's actually important but I suppose attempting to maintain some resemblence of consistency is good practice should that task ever present itself). In short, consider the v1.60 testing link the current production version until I figure out how to make the transition (unless of course a bug is found). Might take awhile, around here hobby stuff can move slowly.
[standalone VDRIVE solution speculation moved to its own page]
9/19/10 - A disk operating system for the HP2114? Sure why not!
Here are the VDRIVE2-related
commands
supported
by
my
IDE/USB
8052
firmware...
120000 = 1010000000000000 read from VDRIVE, follow by read transfer (bit 15 set if busy/end)
121bbb = 10100010bbbbbbbb write to VDRIVE, byte in low 8 bits of command
122000 = 1010010000000000 sync VDRIVE (call before starting operations)
123000 = 1010011000000000 clear VDRIVE (call to discard response of last command)
130000 = 1011000000000000 open read file, follow by filename[cr]
131000 = 1011001000000000 read from file, follow by read transfer
132000 = 1011010000000000 read using paper-tape emulator mode (disables commands until eof)
134000 = 1011100000000000 open write file, follow by filename[cr]
135bbb = 10111010bbbbbbbb write to file, byte in low 8 bits of command
136000 = 1011110000000000 close write file (write remaining buffered bytes)
137000 = 1011111000000000 get usb_error value, follow by read transfer (0=no error)
Command 132000 is new, sends whatever bytes are remaining in an
open
read file. In the present "hack" implementation the only ways to
return
to command mode is to read all bytes of the file, or reset the
IDE/USB
interface... before placing the data on the bus and setting the
flag,
the firmware could check for another command (say 133000) to
cancel
papertape mode but for now I have to press the reset button the
8052-based interface.
I made a tiny
dos called UDOS that might be useful for small machines line
the
HP2114, it contains drivers for all of the functions and a simple
menu
to provide essential operations - save memory to a named ABS file,
attach a named file to PTR (if a binary then can be booted using a
stock loader), and a dos prompt for giving raw Vinculum commands
including DIR, CD, DLD (delete dir), MKD (make dir), DLF (delete
file)
and RD (read file). The core dos is less than 0.5KW and occupies
memory
from 17000 to 17677, easily fits into 8KW with other software.
This
isn't really a finished product (has some crude aspects), but
something
to get started with and further explore what is needed to make a
functional small-memory operating system. [UDOS is now included in
the
HP-IPL/OS testing archive, it's done enough.]
The present hardware doesn't support papertape-punch emulation,
file
writes have to be done using the dos... contemplating alternate
hardware and firmware that would permit punch emulation as well.
HP-IPL/OS has redirectable input/output subroutine vectors so it
can
read and write files through a single HP adapter card without
using
emulated punch, and it's easy enough to simply load binaries via
emulated papertape, but vintage software such as compilers that
needs
to read and write data won't work (not that it has to, apps can be
built under simulation where there is plenty of memory and full
command
line control over what files PTR and PTP attach to). To really be
useful a PTR/PTP emulator needs to have some kind of external way
to
select the files. In times past the operator physically changed
rolls
of papertape - having to specify filenames via HP software doesn't
work
for all cases, especially for a limited memory machine where a dos
or
an app can be loaded, but not both, and overlays are involved.
Hmm...
maybe better to not to try to run compilers and stuff from disk
and be
happy just to be able to save custom dos systems and load and run
arbitrary binaries, the existing stuff does that and it makes the
interface design lots simpler... can focus on more mundane aspects
like
being able to correct errors using backspace and how to kick the
interface back into control mode without pressing reset.
7/11/10 - I'm really starting to like ALGOL.. it has many of the
features found in modern structured languages like local
variables,
parameter passing by value or pointer (but they didn't call it
that
back then), and return values so a function can be used in an
expression. Programmers take these things for granted these days
but
advanced stuff for the early '70's, the FORTRAN (II) compiler is
extremely crude by comparison. The main limitations are upper-case
only
I/O and practically no input editing, but these things can be
overcome
using assembly modules which accept parameters and pass data back
via
pointers. I started a new programming project - a version 3
Z-machine
interpreter that when/if it works will let me play old Infocom
text
adventure games such as the Zorks
on
my HP minicomputer. Much of the infrastructure is in place, now
getting
deep with the interpretation process. At the moment working on
parsing
packed Z-strings.. the encoded strings (3 characters to 2 bytes)
have
abbreviations that point to more Z-strings, and it all expects the
interpreter to perform word-wrap. Fortunately it's illegal for
abbreviation strings to also contain abreviations so full
recursion
isn't necessary but it's still tricky. One of many problems to
solve! I
think I have the stack frame stuff figured out but still have to
tackle
object tables, input dictionary searching, opcode execution and
all
that stuff to go. It's designed to run either stand-alone,
prompting to
load the story file via papertape, or run from a HP-IPL/OS disk
system
using SFS to pre-load the story file into alternate memory banks.
Minimum target system is a HP21MX CPU (HP2113 etc) with 64KW
memory
(enough for "minizork"), with a serial terminal and (emulated)
papertape reader.
6/15/10 - I was out of town for a few days so loaded my little HP
110 "mini" with the HP-IPL/OS disk simulation I had made, further
loaded with siobcs.ipl and the vintage assembler, ALGOL and
FORTRAN
compilers and the BCS linker. First thing I discovered was the new
version 4 Konsole terminal shell is practically unusable - no way
to
disable software flow control thus breaking everything that uses
control-S or control-Q. Plus the command like defaults break all
scripts that use it. Version 3 is one of my favorite terminals but
seems "progress" has gotten to it, so ignore references to konsole
in
scripts or docs. Once I got over not being able to use my
preferred
terminal, I rigged the xterm command line options to make an
authentic-looking green on black display and got on with the goal
of
the exercise - figuring out the basics of ALGOL by writing a
simple
program that prompted for a string then printed it back...
HPAL,L,B,"HELLO"
BEGIN
INTEGER I;
INTEGER ARRAY NAME[1:10];
FORMAT A1(10A2);
WRITE(1,#("WHAT IS YOUR NAME: _"));
READ(1,A1,FOR I:=1 TO 10 DO NAME[I]);
WRITE(1,#("HELLO, _"));
WRITE(1,A1,FOR I:=1 TO 10 DO NAME[I]);
END OF HELLO$
The lines are space-padded because I wrote it in AEDIT (which
uses
control keys for cursoring, why the new Konsole wouldn't work).
Compiling it requires exporting the AEDIT-format source file to a
papertape
source file, compiling the source to produce a papertape
relocatable
file, feeding the relocatable into the BCS linker, followed by the
BCS
library with some switch register settings to produce a binary.
Normally more steps are needed but HP-IPL/OS is used to store
pre-combined compilers with the SIO drivers already in place, set
the
initial switch register bits, and print instructions telling me
what to
do. Here's a dump of a simulated
compile
session. With a suitable PTR/PTP emulator this can be done
using
real hardware - to be suitable the emulator needs to be able to
cycle
papertape punch output back to papertape reader input, and the
bcslib.rel file must already be available in papertape form to
load in
after the relocatable, so the emulator must have the ability to
swap in
additional media. I have no such hardware but that's ok, I can
still
run the compiled apps on real hardware using only a simple PTR
emulator, which I do have. The real discovery was figuring out
that
adding "_" to the end of a print string suppresses the CRLF which
is
normally added after every print, and discovering that this trick
works
for HP FORTRAN as well. Such a small thing, taken for granted
these
days, but a big deal - for years I thought FORTRAN could not print
a
string without also printing a newline without the help of machine
code, but all it took was an underscore. Old timers probably knew
this,
but I was amused to discover this is still a FAQ from modern
Fortran
coders, with varying solutions. Cool, so I imported the source for
my
Reversi-playing FORTRAN program and made most of the changes from
within the HP-IPL/OS environment, updated the FORTRAN Reversi page
with the
new code. The process for compiling a FORTRAN program is similar,
except the FORTRAN compiler is in two parts, the first binary
compiles
the source to a temp file and the second pass overlays the first
pass
(which must still be in memory) and reads the temp file to produce
a
relocatable file which can then be linked. This is where SFS comes
in
handy - alternate memory already contains the first pass so it
needs another buffer from which it can read the second pass ABS
from to
overlay it on top of the first pass, otherwise yet another
papertape
file would be needed.
I can only imagine what it must have been like in the late '60's
when all this stuff was done completely with papertape, I'm sure
they
went though a lot of it. In the '70's a HP21MX with at least 96KW
memory would probably have used the RTE disk operating system and
would
not have required papertape for temporary files, but here in the
21st
century MX-class CPU's are still fairly common and it's more
practical
and much cheaper to hobble together a modern disk solution and use
microchips and stuff to fake papertape. Nevertheless, even though
modern devices and HP-IPL/OS is used to make up for the lack of
vintage
hardware, it's still running vintage BCS software - the input
source
and the output binary is the same as it was back then.
6/10/10 - For testing, went through the process of setting up a
simulated disk menu system, my notes are in the simsetup.txt
file,
which
might
get
added
to
the
archive
but
needs
some
cleaning
up.
For
now,
wordiness
aside,
provides
step-by-step
instructions
for
using
the
scripts
in
the
testing
archive
to
create
an
IDE-compatible
bootable
7906
disk
image.
Everything
worked
perfectly,
except
for
Windows...
discovered
that
it's impossible to paste BASIC code into a command
window running SimH HP2100 running MSU BASIC. That works fine
under
Linux, used to work fine under Windows, not sure why it no longer
works
(but guessing SP3 which broke other "dos" window stuff). So I
documented how to get around that bug using HyperTerminal.
6/9/10 - Darn beer. I was making a 99-beers generator
in
IPL and discovered an issue I hadn't run into before - if a word
containing a backwards >STEP isn't done correctly and crashes,
requiring a restart, it leaves the step value set incorrectly,
effectively (as far as a user would think) hosing the system. Not
all
cases of GIGO can be fixed,
but this effect is pretty easy to accidentally bump into and the
cure
was easy - added an instruction to the kernel that sets +LOOP's
step to
1 on any cold/warm start - thus once it bugs it rights itself, and
no
issues interrupting running programs. Testing archive updated,
also
added some sample HP BASIC code (including a conversion
of
TTY TREK).
Here's my best beer-maker so far... (no backwards +DO or other
funky
stuff)
;99 bottles of beer for HP-IPL/OS, 99BB to run.
OCTAL DEFINE 99S1
OVER IFZ DUP IFZ 116 ELSE 156 ENDIF PCHR "o more"
ELSE OVER $STR ENDIF $PRINT " bottle" $PRINT OVER #1 SUB
IFNZ 163 PCHR ENDIF " of beer" $PRINT DROP END DEFINE 99BB
DECIMAL 143 DO DUP #0 99S1 " on the wall, " $PRINT #1 99S1
56 PCHR CRLF IFZ "Go to the store and buy some more, " ELSE
"Take one down and pass it around, " ENDIF $PRINT DEC DUP
IF<0 DROP 143 ENDIF #1 99S1 " on the wall." $PRINT
CRLF CRLF DUP 143 SUB WHILE DROP OCTAL END CONSOLE
Here's a zip containing a small HP-IPL/OS
build containing the program, just add simulator. This
version of
the program properly punctuates and restocks - unlike some other
examples. True, it could make better use of whitespace to indicate
structure... but then it wouldn't be shaped correctly. Besides,
there's
already a beer-maker
program written in whitespace.
6/6/10 - Close, but upon further thought, it's better to NOT
clear
@LLP on startup - that's too limiting, if a specific default is
desired
the user can make that decision with an autostart word. Now the
default
ERASE behavior for all builds is to remove whatever was typed in
since
booting the build, and if a IPL package is loaded, restarting the
binary won't clear the last load point. Since the kernel no longer
needs to access the variable except through IPL code, storage for
@LLP
has been moved from zero page to inside the word itself. Also, the
DMENU program in dm2.ipl and the hpos6i.abs build now supports
saving
HP BASIC programs in addition to MSU BASIC.
6/4/10 - Updated the testing archive and all of its builds with a
new kernel that goes beyond what a patch can do and validates the
machine-coded DEFINE writes too. Since fixing the issue properly
had to
be done at the kernel level, I took the opportunity to also fix
another
nagging usage issue - easily recovering from a failed load. Added
a new
@LLP variable and modified <PTR
and <MS (called by all other IPL loads) to set it to the
end-of-dictionary before doing an IPL load, making it possible to
automatically remove the last package loaded without having to
determine which word the package starts with. Now it knows. Made a
new
ERASE word (replacing an old now-useless word with the same name)
for
extra.ipl/extra2.ipl that checks @LLP and if pointing to a valid
word,
prompts to erase from that point on. Now after a page error or if
a
word is not found, just enter ERASE and confirm to remove the
partial
load. If nothing made it into memory or @LLP isn't valid ERASE has
no
effect. Also useful to load an IPL, use it, then remove
afterwards. A
little thing, but much better. [irrelevant info snipped] These
mods
caused no bloat (other than using up the hole
between the interpreter and the start of the dictionary), the new
builds actually have a few locations more free memory than
before...
but only because the memory-hogging usage messages were removed
from
CONSTANT and VARIABLE. Nice trade in my opinion.
6/2/10 - Huh. This is proving to be one tough patch! it works,
better than uncontrolled dictionary overflow, but still permits
strings
to overflow into block space (the string compiler in DEFINE is
machine-coded and isn't affected by the patch). Only use the
present
patch if blocks are allocated to buffer the overflow and protect
high
memory, looks like it's going to take a kernel revision to do this
right. But now it has become a challenge!
5/31/10 - HP-IPL/OS has always had a "feature" that bugged me a
bit
(especially when writing docs), there is no protection against
accidentally loading too much and overflowing the dictionary.
Checking
free memory first usually prevents that, and when it happens,
usually 0
ALLOCATE reveals the failed load so it can be removed, but still
it's
one of those things that would be nice to fix. This is a tricky
problem
to solve as every write to dictionary space has to be validated,
if
implemented in the obvious way (adding conditions everywhere a
write
takes place) it would inflate the kernel and slow down word
creation.
But there's another way to do it that doesn't increase the
apparent
kernel size at all - don't use PUT to write to the dictionary.
Instead
make a machine-coded "headerless" word that quickly validates the
write
and if out of bounds, displays an error message and warm-boots the
system. There's enough room between the end of the kernel code and
start of the dictionary to put the new code, then the DEFINE and
ADDCODE words can be modified to use the validated write code
instead
of PUT. This experimental dictionary
overflow prevention patch does that. Once applied it makes
it
impossible for DEFINE, CONSTANT, VARIABLE or CREATE to write
[much]
past the
end of dictionary memory [strings still overflow into block
memory],
instead it just displays OVFLOW and stops the
load. This is experimental code that does scary stuff, it seems to
work
fine [but has side effects, see comments]. To
apply the patch, attach it to PTR and load it (<PTR) like any
other
IPL, it needs a bit of free memory to function but doesn't leave
any
words in the dictionary. If needed the patch can be removed using
this unpatcher.
5/24/10 - Here's what my new SendToHP PC-to-HP PTR transfer
program
for Linux looks
like now...
...the overflow and extend LED's blink while loading, and at the
end
of the transfer it lights up bits 0-5 and other LED's just like a
real
HP mini. A bit overboard but I wanted to give the new code a good
workout and it does serve a purpose, they show EOF when loading
text
IPL's too so I don't have to guess when it's done - I have only
one
serial port so I have to disconnect the console when loading
things
into my mini thus can't see the normal console output.
The boxes were drawn using a few words that output
unicode strings for lines and corners...
; unicode "graphics" words
OCTAL 2017 377 PUT ;patch kernel for 8-bit output
DEFINE UCST ; unicode start (for most)
161224 PWRD END
DEFINE UCHL ; horizontal line
UCST 200 PCHR END
DEFINE UCVL ; vertical line
UCST 202 PCHR END
DEFINE UCUL ; upper left corner
UCST 214 PCHR END
DEFINE UCUR ; upper right corner
UCST 220 PCHR END
DEFINE UCLL ; lower left corner
UCST 224 PCHR END
DEFINE UCLR ; lower right corner
UCST 230 PCHR END
These aren't in their own package, just part of the sendtohp.ipl
package in the new archive's ptremu material. Each word just
writes a
unicode string, so doing say UCUL UCHL UCUR CRLF UCVL 40 PCHR UCVL
CRLF
UCLL UCHL UCLR CRLF draws a box on the screen. This technique is
for
Linux where console terminals support ANSI and unicode "graphics",
the
sender app itself depends on being able to access the serial port
as a
simple device file from which it can read from and write to just
like
any other file, leaving me free to write apps in anything I want
(including simulated IPL). To do anything like this under Windows
would
take a "real" PC language such as FreeBasic or Visual Basic - but
I
already made a sender called HpLoader for Windows long ago, no
depiction of a minicomputer with blinkenlights but it does blink.
As
far as terminal graphics though, the Windows Hyperterminal program
supports ANSI color - select the ANSI or ANSIW emulation - and
line
characters are available by unchecking "Force incoming data to 7
bit",
selecting the Terminal font, patching HP-IPL/OS to allow 8 bit
output
by doing 2017 377 PUT, then printing characters from this chart
(here's the low
chart to go with it).
5/22/10 - hehe shouldn't have said "quite" [5/21] - the
code-spite
principle
struck again and in the process of fixing up my new SENDTOHP
file-to-PTR transfer app with color and unicode "graphics" I found
a
bug in the COLOR word - won't do dim
forground on a color background. 17 4 COLOR CLS works and makes
bright
white on blue, but 7 4 COLOR CLS for dim white on blue sets the
background to the terminal default instead. After looking at the
code I
saw why, it's all screwed up (wrote it long ago,
worked for what I was doing at the time, didn't notice the bug).
Here's the original COLOR code...
ESC #0 SWAP 000050 ADD $DSTR "0;" $PRINT $PRINT 000155 PCHR
ESC DUP CASE > 000007 "1;" 000026 DEFAULT "0;" 000036
ENDCASE $PRINT ADD #0 SWAP $DSTR $PRINT 000155 PCHR
That's just wrong. Outputs parms in two escape sequences, and if
a
forground < 10 octal specified, the second esc seq outputs a 0
which
resets the background to default. 17 4 COLOR should output
<esc>[1;37;44m and 7 4 COLOR should output
<esc>[0;37;44m -
all in one escape sequence. Here's some corrected IPL...
ESC SWAP DUP CASE > 000007 000026 030473 DEFAULT 000036
030073 ENDCASE PWRD ADD #0 SWAP $DSTR $PRINT 000073 PCHR #0
SWAP 000050 ADD $DSTR $PRINT 000155 PCHR
The COLOR code is in screen.ipl
and hpscreen.ipl
(in
hpscreen it's in a condition branch to only use if not in HP
terminal
mode). It's fixed now in the linked text files, along with making
CLS
and -COLOR more efficient. But this changes everything! Many
builds
need to be rebuilt, plus all the other builds scattered about.
Because
many of these already carry a 1.54 version number and it'll take
awhile
to fix them all, the new builds and archive with the fixed COLOR
will
be called version 1.55. Oh well. Fairly minor thing but I like
things
to be right, especially now that more and more I'm writing simple
PC
apps in IPL running under simulation to avoid the complexities of
modern PC programming for trivial things. Updated the
hpiplos_main_testing archive, now 1.55.
Another archive addition I need to make [done] is include the
QBasic
source
for OCT_TOOL - I use this constantly to figure out
the packed octal equivalent for text strings. Another thing to
document
-
Unicode. To make nice-looking Linux apps using HP-IPL/OS I need
unicode
support to make boxes and other graphics, but the stock kernel
only
allows 7-bit output because 8-bit output can cause bad effects
with
some terminals. For the present kernel doing 2017 377 PUT switches
it
to 8-bit output to permit unicode strings. For safety check first
to
make sure the current value is 177 before patching. This could be
a
package with words that print corners and lines - UCHL UCVL UCUL
UCUR
UCLL UCLR to print horizontal and vertical lines and upper-left,
upper-right, lower-left and lower-right corners.
5/21/10 - OK, sometimes I take a long time for a seemingly simple
edit... however (other than the printer driver) the 1.53 package
is
quite solid as far as I can tell - if the new edit and print
IPL's,
summary.txt and demo build are added to the hpiplos tree, then it
mostly makes it 1.54 as far as the existing code is concerned. The
printer driver in existing systems can be fixed by entering the
commands from the 3/16/09 entry, so there was no hurry. The new
archive
has progressed far enough to share as a "testing" version, it's
at: http://newton.freehostia.com/hpiplos_main_testing.zip
The archive is subject to change depending on proof-reading,
testing
and feedback, and isn't the real 1.54 package until it gets posted
to
the main page. Changes won't necessarily be noted here but so far
the
new archive includes the following changes...
Includes the replacement edit.ipl and print.ipl packages
Builds containing print.ipl were rebuilt - hposdemo.abs,
hposide.abs
and hposidem.abs
Added a new 8KW build containing MAZE, and a new 64KW utility
build
with binary hacking tools
Added 8kextra2 package with a more complete set of words for 8KW
builds
Added extra2 package with fewer words for more compact builds for
larger setups
Added double2 package without EMUL EDIV to work on older machines
or
with small CREATE
Added bugs2 package that paints colored patterns on an
ANSI-compatible
terminal
Added a slightly modified version of Tim Riker's version of Eric
Smith's Asm21 cross-assembler
Added assembly source for MSU BASIC along with docs and notes
describing how it was patched
Added notes about HP BASIC including patching for HP-IPL/OS (and
finally figured out how to CALL! yay!)
Added notes about patching SIO and configuring a
HP-IPL/OS-compatible
version of the BCS linker
Added notes, VDOS packages, and 8052 code for the IDE/USB VDRIVE
mod -
stores files on a thumbdrive
Added Visual Basic source for the HpLoader app for transferring PC
files to a PTR emulator
Added a new HP file sender app for Linux - it's written in IPL :-)
(feeling the urge to tinker with it more)
Added an html file to the root linking to the documentation files,
includes more docs and examples
Root docs (besides readme) and new docs moved to a new docs
directory
to reduce root clutter.
It's a fairly extensive update but is mostly about tidying up
docs
and adding new tools and info, none of the existing code has
changed
since March '09. I'm sure there are bugs but so far haven't run
into
anything worthy of changing. Most existing odd behaviors (like
being
able to overflow the dictionary) fall under the category of
"feature"
and probaby won't change anytime soon - GIGO - I'm only concerned
with
actual bugs like stuff not working. Lots of new stuff was added
but
tried to keep the size increase minimal (the zip is roughly 300K
larger), most of the added stuff is available elsewhere but
putting it
in the main package makes it available without having to search.
More
importantly, it ensures that the sources and binaries match, and
makes
it less important that the pages currently hosting the info remain
up.
Even this infionline site might go (it's my old dialup account
from the
'90's and costs me magnitudes more than the equivalent amount of
webspace elsewhere), no plans to take it down but just in case my
entire infionline site is mirrored here, here's the mirrored
HP-IPL/OS entry page.
3/16/09 - The printer driver had a bug causing it to work under
simulation but not with a real printer. Fixed in the web files
archive,
the full-screen editor builds, and the 7906 disk simulation build.
Still working on docs and stuff for the main HP-IPL/OS archive
zip,
will update that when it's ready. If needed the old printer driver
can be made to work on real hardware with the following patch...
To fix an already loaded !PRN driver do...
"!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).
The things I do... write and support an OS that only a very few dedicated hard-core hackers actually use... sure why not [...] But there's more to it than just writing code for nothing (although that alone is very enjoyable) - HP-IPL/OS is an OS, and it runs the most primitive and oldest form of HP21xx software - the absolute memory image. These bits of antique code are the real stars, and there's a shortage of it. MSU BASIC helps fill the void, many of old-style BASIC programs that can get by with numeric-only input can be converted to run under it. Learning FORTRAN II was a pleasurable experience, of course the only thing I wrote for it broke many rules to implement recursive subroutines using only GOTO... although distro of the compilers and stuff is still unclear, at least the SIO/BCS stuff resulted in a few more things to run using HP-IPL/OS including a prized vintage Chess game. Slowly but surely more old bits are coming to life, lately I've been playing around with another old HP mini OS... RTE-6/VM. I put together a small collection of games in hpgtapes.zip that can be run as-is on a primary system. Reconfiguring the system proved to be quite involved but fortunately I had expert help, eventually was able to put together an "answer" file to set up a more useable configuration but I still have much to learn. Email if you want what I have so far.8/2/08 - I discovered an issue - if SFS is used to update a file
and
the specified buffer
memory does not exist, the result is the loss of all files in the
specified volume.. ouch! [...]
4/9/08 - ok going for it... main archive updated [1.51J].
4/8/08 - the 3/29/08 editor update still had a bug in the LDFILE
word, fails when loading files that take up the editor's maximum
capacity. Simplified this word so it is little more than
"FileName" ZAM
F2AM and doesn't attempt to clear alt mem after the file, and
added
extra code to the TRCAM word called when exiting AEDIT to ensure
junk
after the end of the file in alt mem is zeroed (at least what
matters).
The new fed.ipl also updates the screen one character at a time to
reduce cursor "wiggle". Incorporated the new version into the edit
builds and the 7906 disk sim, if it remains stable will update the
main
HP-IPL/OS zip with the new version to get the bug out. The other
new
IPL files (dm2, msu/binpatch etc) will probably remain in testing
for
awhile to see if anything else gets done to them.
I've been pounding the editor pretty hard both under sim and on
real
hardware - the present version works fairly well (for me)
considering
it emulates a typewriter that can insert and delete lines,
overwrite
text and (slowly) move text on the current line. It certainly has
its
quirks but due to the severe speed limitations of a 2400 baud
connection and a sub-mips processor not sure what can be done to
improve it besides possibly adding functions for splitting lines
and
jumping to the end of a line. Or just start over and rewrite the
whole
thing in machine code but that won't help a bit for the slow
terminal.
The alternative would be a command line editor in the style of
EDIT/1000 or the original SFS
file
editor but I'd rather have a slow
full-screen page at a time editor with no features beyond movement
than
try to edit text using a command line. Some people can use command
line
editors but I can't.
I still haven't found the "perfect" PC terminal emulator for real
hardware yet, ProComm for Dos works the best but has no
scroll-back
buffer so it's inconvenient (but still probably better than what
I'd
get using a real terminal, at least if I have to I can capture
text to
a file). I have hopes for dterm, at least it's simple and small
enough
to hack (and possibly make it emulate some HP terminal features)
but it
presently has a couple of severe problems - it locks up when
cursoring
around in the editor, and doesn't buffer keystrokes so drops
characters
if the editor is currently updating the screen making touch-typing
impossible. MiniCom is not useable either, it intercepts some
control-keys for its own use making it impossible to use not only
with
the editor but other HP programs like OCTAPUS. I gave up on
HyperTerminal, it used to work fine but now I can't get it to
operate
at the baud rate and bits I tell it to and (incorrectly) sets
itself
and fails when other old-comp software is run. For my HP mini
console I
need 2400/7E2, period.
3/29/08 - update done, now the sim, editor builds and main
archive
all contain the same editor version (for the moment anyway). The
"official" version is still called FED.IPL, same code as the
previous
"experimental" AEDIT.IPL version but with the extra IPL features
added
to adapt to different builds and avoid page errors when running
from
DMENU or the library. The new version isn't that much bigger than
the
original, has faster screen updates, and doesn't cause files to
grow
with successive edits, so not much point keeping the original
around.
3/28/08 - maybe I better keep it simple this time around and
update
just the editor and its utilities in the main zip file, and let
the new
code reside in the 7906 disk sim and scattered about this page for
now
where it can be easily fixed if a problem is discovered. I don't
want
to burn a version number on dumb bugs that affect only one build
(hposdemo.abs) so letters to the rescue... barring new discoveries
the
new version will be 1.51G to match the sim version containing the
same
code, and remain consistent with the other 1.51 builds which
aren't
affected. Makes sense... 0.1 clicks for kernel changes, 0.01
clicks for
changes to IPL's which affect most of the builds, and letters to
indicate other versions like the 1.51C utility build included in
msubasic.zip and the 1.51G version with editor updates.
3/27/08 - [found a few bugs in the editor's utility package,
fixed
in the text version of fedutil.ipl,
the
7906
disk
sim
and
in
edit
builds
on
the
editor
page.]
3/22/08 - updated the new disk menu [dm2.ipl] to
avoid
renaming files (to no name) if nothing is entered at the new name
prompt, changed other text to make it slightly smaller. Updated
the sim
package with the new menu and hopefully better docs. Download
details
now on the 7906
Disk
Simulation
page.
3/15/08 - the disk sim is back! The new disk menu looks like
this...
======= HP-IPL/OS Disk Menu =======
A) Binary 31KW MSU BASIC B) Binary TREK
C) Binary HAMURABI D) Binary OTH
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
