HP 21MX/F and OS choices (was Lookee what I just got!)

Jay West jwest at classiccmp.org
Tue Jan 9 10:05:39 CST 2007


Warren wrote...
>    So, I will no doubt give HP-IPL/OS a try.  I always thought Forth
> got a great deal of attention LESS than it deserved.
As Bob will no doubt point out quickly, HP-IPL/OS is not Forth. But it is 
very much in that vein as far as design & philosophy.

>    Okay, you talked me into it.  No harm done in any case, and I love
> to poke around and experiment with new computer environments.
Don't view IPL as a distraction from TSB. View it as a complement... 
sometimes you just want to boot something up quick and experiment with a new 
card or peripheral and don't want to wait 5 minutes and mount tapes to boot 
the machine. You just want to "get at" the card, or test some theory with 
regards to how DMS works to further your understanding of it, etc. Or maybe 
you want to poke around at how TSB lays things out on the disk. TSB doesn't 
offer you assembler, and no low level access to the machine. Boot up IPL and 
read a few sectors, toss together a WORD to dump the disk intelligently (ie. 
list programs in a user account for example), etc. IPL is awesome for just 
that quick "whatif/how" scenario.

>    Not my cup of tea.  I've used it, and find it, as you say,
> unintuitive.  There's also no BEAUTY to it, if you catch my drift.  I'm
> not sure I can define it, but I know it when I see it.  <Grin>
I agree... today. I must admit I haven't given it enough of a chance to sink 
into my head. I will give it a fair shake and dig into it deeply when I get 
back to my HP boxes. But I know what you mean... TSB is spartan and simple 
compared to most other environments. But there is definitely a particular 
elegance to it's simplicity....

> As a matter of fact, at the risk of offering offense, I was
> considering trying to produce new plug-compatible devices for the
> machine, if the necessaries are not available.
No offense at all. Bob Shannon took the first step by creating the IDE 
interface. I'd have to hack up TSB to get it to see that drive as a 
7900/05/06/20, but that is certainly doable (and not difficult really). You 
should take the second step... and that is building a modern replacement for 
the 12920/21/22 mux set. That is the last part that is fairly rare and is 
the single biggest thing keeping most HP folks from running TSB.

There's another approach... I have done some initial digging in to the 
source for TSB to see about making some changes that would both improve the 
OS and make it run on hardware that is easier to find. There are two key 
things that have to change.... 1) implement DMS support (memory over 32kw) 
and 2) make the number of ports configurable... then it may be possible that 
the code could be revamped to run in just one cpu. Gone would be the dual 
cpu requirement, gone would be the microcode requirement, gone would be the 
need for the rare mux set. The number of ports is already configurable (16 
or 32)... but it would need to be granular in units of 1. Then you could gen 
your machine for say... 4 user ports. One of the key requirements to make 
this possible would be switching to use BACI boards for serial ports. If you 
look at the programming api that BACI boards offer, it's pretty incredible. 
I've never seen a serial interface with quite so many programmatic features. 
It seems to be extremely adept at keeping the load off the cpu. I'd also 
want to enhance the system console code to allow use of a BACI instead of 
the harder to find 12531 boards (the api isn't compatible). I am not 
positive that all this is possible, wouldn't know till I tried. But from a 
brief glance at the code I think it might be doable. I did set up the 
2000/Access source code in a CVS repository... :) But then, I seem to never 
have any time to really dig in to projects like this :\

>    That sounds like a plan.  If any partially lobotomized CPU will work
> as the secondary, I probably will just wait around for one to present
> itself.
Best choice - and most common - get yourself a 2109 or 2113 (21MX/E). You'll 
need 32kw of ram... but heck, you could easily pull one of your 64k boards 
from your F and be all set. You'd also need floating point roms... was that 
standard on the E? I forget, and no books around at the moment. But I think 
it was standard on the E. Lastly, you'd want to make sure it had a FAB board 
(a daughterboard underneath the cpu - most E's have it). The 2000/Access IOP 
firmware (special microcode) comes in a chip size that can only go on a FAB, 
not a FEM. It would be possible to rip the data from those chips, 
re-organize it, and stuff it into the larger formfactor chips that will go 
on a FAB *OR* a FEM.... but those larger chip blanks seem to be unobtanium.

>    o    Can a TSB system be connected to an Ethernet and be useful?
>
>        o    If so, what cards are needed?
>
>    o    Is there any way to get TSB connected to an IP network?
TSB certainly has no IP support, and without DMS, the memory map is awfully 
cramped - little room for new code. However - just cheat: put a terminal 
server in front of it and away you go!

>    I'd love to offer TSB ports on a real machine.  The 2000B TSB system
> I used in high school had 64 phone lines and ports.  I'd like to do the
> same, but NOT by buying 64 phone lines...
32 lines was the max. Perhaps they had two machines :) I opened mine up for 
a few folks to telnet in to for a short time. I didn't use a terminal 
server. I had a FreeBSD pc with a wireless internet card to my home 
cablemodem network. The PC also had a digiboard PC8e  (8 port serial card). 
People could telnet to the PC and get a script which picked an open line 
from the 8 and cu'd them to the first available port on the HP. I never kept 
it up for more than a few hours, by arrangement only. I stopped doing it 
after the novelty wore off... I don't like leaving the dual 2100's running 
unattended.

Jay West 





More information about the cctalk mailing list