9 Jan
2007
9 Jan
'07
4:05 p.m.
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