Alan -

Any chance you have some time to add a target PA-RISC cpu support to QEMU to
run PA-RISC binaries in user mode on Linux?

There was a guy named Stuart Brady that took a stab at it recently, but
doesn't seem to have gotten anywhere.  You could be the lead for adding the
PA-RISC support to QEMU with very little effort.  You won't be getting your
name in lights (unless you are at a meeting of MPE users ;-) ), but it would
probably look good on a resume, and you might even have fun doing it!

- Pete

On 9/15/06, Alan Tibbetts <[log in to unmask]> wrote:
>
> 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.
>
>
>
>