12 Jan
2007
12 Jan
'07
12:46 a.m.
You wrote...
What they have in common is what matters.
No,
what they have different is what matters... like TSB having it's own
fancy modified loader in the BBL area that IPL best not mess with ;) As I
said, I've had my head out of the HP stuff for quite a while now, but I do
THINK I recall that it has a special loader left in the system processor
(and the I/O processor for that matter). TSB on the 2100's at least also
relies on the autorestart feature so that the IO processor comes up to a
sane state.
Why would any program that runs in 32K, less the BBL
area (64 words) not
run correctly under the SYSTEM map with 21MX memory protection disabled?
Oh, many
things would run just fine I imagine. I would suspect that
interrupt handling could get sticky.
A single function can remap the SYSTEM and USER maps,
and make that
virtual
address space the SYSTEM map and transfer control to any address in that
page.
I'm aware of how DMS works. I'm not familiar with how IPL implemented
this
vm stuff you mention. Is that in the older versions of IPL like the one I
have?
The program that ~had~ been loaded into VM is now
running on its very own
32K word machine, IRQ vectors, DCPC transfers, everything.
DCPC is of course valid
and handled in a DMS environment. I'm still curious
just how you handled interrupts in the scenario you describe.
When that program (HP BASIC in this case) jumps to the
special BBL loader
a tiny DMS program unswaps the DMS maps and jumps to a special entry
point in IPL, the threaded interpreter keeps chugging along as if it also
is being run on a totally different CPU.
Ahhh so it seems (to answer the probing
question I asked earlier) that
you/terry seeded HP BASIC with strategic calls to the "release quantum" code
in the BBL area that does the task switch (or just patched it to exit
there). Co-operative tasking. That means each map better be awfully
co-operative in giving up it's use of the cpu. Or even if you're only
switching tasks on a special keypress (or using the TBG), each application
better be very well behaved. If it goes south (or just doesn't give up the
quantum), so does the whole machine.
... any program that does
not take control of the DMS mapping registers must, by definition, run
normally
under these conditions.
I may well buy that statement, but I sure don't buy it
yet. I'd like to see
just what IPL is doing for this.
The system map is the system map, no matter where in
physical memory it is
mapped to. At power on, its the first 32K words of physical address
space.
So what if it happens to be mapped to some other physical address space?
There
is no way for a non-DMS program to ever know this is the case.
Why would it not run perfectly?
If it were strictly a matter of code & data in
memory, of course your right.
But there's more to it as there's more parts to a running machine/OS than
the code in memory. Like disk drives, tape drives, interrupts, etc.
Jay