Hi Pete,
 
I must admit I have been lurking in the background as your suggestion to
create an MPE machine has been debated on this list at some length.
 
All I can say is that it is possible to emulate a machine at the hardware
level that can do a pretty darn good job of looking like the orginal.  As
an example, I am writing this reply in the HP1000 editor on my laptop at
home.  The actual workspace is a Reflection screen which is connected via
a telnet session to my desktop PC at the office.  The telnet session is 
going
to a server program running on the desktop which presents it as a serial
port to the Kestrel CoProcessor running an RTE-A system.  Note that it is
going into the virtual HP1000 as a plain old serial port, not as a telnet
session.  This means that I could be doing the same thing on an RTE-2 system
if I wished, because I am not invoking NS1000 with its required LAN card.
To put it in MPE terms, that is equivalent to using the editor on a virtual
serial port on the MUX on an HP3000 Series-II.
 
As I type, EDIT/1000 is storing my characters in a temporary workspace file
in the RTE-A file system.  No supprise there, as the editor on the 3000 
would
have done a similar thing.  The virtual HP1000 has a few hundred megabytes
of disc space in several drives, some of which appear to be 7925s and
others more modern SCSI discs.  I sometimes use what appear to be 8" floppy
drives.  All of it is a sham, produced by really dense smoke and very shiny
mirrors.  The reality is that the "discs" are actually container files 
in the
 WIN-XP file system on my desktop machine.  The Windows file systems
(all four or five(?) of them) use stream files, just as LINUX does.
One of your correspondents seemed to think that would be a problem.  It is
not at all, because from the Windows file system point of view, each of my
disc container files is just another mysterious heap of bytes in a file that
it knows nothing about.  It doesn't need to know the meaning of any of the
bytes in the file, it just has to have three capabilities: it has to be able
to store bytes at an offset in the file, it has to be able to read back the
bytes from that offset in the file, and it has to be able to find the 
file again
when I reboot my virtual HP1000.  HPUX, LINUX, WIN-ucks, or any other
O.S. should be able to meet those rather simple requirements.
 
After I finish editing this message, which is growing much larger than I
had anticipated, I will use a utility developed here at Strobe to copy the
RTE file out of the container file encapsulation to a Windows text file.
Its kind of like using FTP to get a file from RTE to UNIX, only much faster.
At that point, I will stuff it into an email and post it to the OpenMPE 
list.
The same path is available to take test data from an IMAGE/1000 database and
pass it into a spreadsheet on the PC.
 
It has been my observation over the years that the MPE community has had
a incredible variety of system backup solutions, from HP and others.  It
seemed that each time a new disc drive or tape was introduced, things became
unsettled for a while.  RTE certainly had its share of backup solutions
also.  Honestly, I don't worry about backups very much on the Kestrel.  When
I feel it is time to do a backup, I simply drag and drop the container file
from its normal place to a USB flash drive, a DVDROM drive, a portable hard
drive, a file system on another computer on a network, or any other place
that WIN-XP can stuff bytes reliably.
 
The Kestrel is an instruction level work alike for the HP1000 line of
computers.  In fact, it executes most of the instructions in a microcoded
hardware engine that is, on the average, faster than the fastest legacy
HP1000 produced by HP.  The design allows us to drive a legacy HP1000
backplane or a virtual backplane with virtual devices or a combination of
the two.  In my case, I have a legacy backplane that contains a SCSI and a
LAN card, with the remainder of my peripherals virtualized.
 
The Kestrel was designed at Strobe Data from sources which were available to
customers when I was an HP employee or later on a consultant to HP.  The
primary sources of information were the ERS (External Reference 
Specification)
manuals for the various CPUs and the I/O cards, and the normal documentation
which was shipped with an HP1000 system.  Most of the really old stuff came
from the stash in my attic of the manuals that I just couldn't bear to throw
out over the years.  Who knew that a 2116 reference manual could be so much
fun to read 30 years after the machine was oboleted?
 
There were times that my experience in teaching the microprogramming classes
at HP were invaluable.  There were also times that we requested driver
sources and sometimes O.S. module sources from HP and were delighted when HP
provided them.  Sometimes we resorted to logic analyzers and dissassemblers,
occasionally finding that published documentation was incomplete or in some
cases inaccurate.  It takes people with specialized knowledge to bring 
up a new
CPU, but the most important attribute is sheer stubbornness.  No one can 
really
know everything about a machine, but they can know the techniques to 
find out.
 
How did we start?  We made a design that we thought would execute the base
set of instructions.  We wrote some small programs that we preloaded into
the memory on the infant Kestrel.  We set the P register and told it to RUN.
We watched it die.  We changed our design until the small program ran as
expected and then added more tests to it and ran again and watched it die.
We repeated this process a few hundred times until we had something that
we thought could talk to a disc.  We copied a running RTE system onto the
disc, told it to run, and watched it die.  See above for algorithm ;-)
 
If you do this long enough, eventually you get something that will work and
then you start adding the stuff around it to package it into a product.
In a way, unlike most software and hardware projects, it is very simple to
write the specification for the product...  It just has to run like the 
legacy
machine.
 
The Kestrel is a hardware solution, but it could have been done in software
instead.  The tools would have been different.  In some ways, it would have
been easier.
 
I guess that what I am trying to emphasize is that the job was done 
without full access
to HP's sources.  Over time, as the project progressed and HP saw
that we were capable of creating machines that were in fact true members of
the HP1000 family, our relations with HP improved.  We first had to prove
ourselves, because too many people had talked about it over the years and
then done nothing.  At the very end of the product life, we were able to
sign a contract with HP allowing us to distribute the RTE software and
derivative works to our customers.
 
I am proud of the results of our efforts.  The Kestrel can appear to be
any of the members of the HP1000 family, from the HP2116 up to the A990.
It can allow any O.S. that ran on those machines to talk to modern devices
which were not even imagined at the time.  Our customers
have been able to keep their legacy systems not only running, but viable
as full fledged members of modern heterogeneous computing solutions.
 
It is my opinion that the same thing could be done for the HP3000 family.

That is my 8 Kilobytes worth.
Alan Tibbetts
Strobe Data Inc.