Kevin wrote....
> How does it compare to the emulator available at
>
> http://simh.trailing-edge.com/
>
> I don't know how complete the hp2100 is, but other simulators in this
> set are
> quite functional.
Well, mine is better of course *GRIN* Not that I'm biased or anything :)
But seriously... they are pretty different designs from what I have seen.
First, let me caveat - I have only looked at SIMH in a very cursory fashion,
so what I'm about to say are "first blush" reactions off the top of my head.
I may be wrong. Your mileage (opinions) may vary. Nuff said. Please folks,
I'm NOT disparaging SIMH or it's authors.
SIMH is designed to support many different cpu's. HPEMU is designed and
written from the ground up specifically to emulate one particular cpu (and
all associated peripherals). I'm sure that anyone on this list has the
technical ability to elucidate the obvious conclusions of that with regards
to differences, efficiency, etc. Think for a moment about the code a
programmer has to generate for the two cases, and then compare. That's it in
a nutshell.
If you want an emulator that supports many different cpus, go with SIMH! It
does that very well. You have one emulator to learn to run all your emulated
machines. That's a great advantage for SIMH. If you are an HP 2100 lover, I
think you'll find the HPEMU program much easier to use, and more
importantly, if you're so inclined, to modify. Anyone familiar with C and
the HP2100 systems will be immediately right at home reading and modifying
the source code to the emulator. SIMH however, because it has support for
different cpu's - brings in an "abstraction layer". Housekeeping stuff. So a
2100 programmer would look at modifying the code and have a harder time
"getting acclamated to the SIMH infrastructure (internals) and way of doing
things" if you will. Succinctly put, to modify SIMH you have to learn SIMH
nuances and paradigms. With HPEMU, you already know what you need to know
basically (assuming we're talking 2100 people).
Another ramification of this is - adding additional devices that aren't
supported initially. From what I can tell, adding additional peripherals is
much easier in HPEMU (for people who know 2100 stuff). Of course it is,
because only peripherals that adhere to the HP internal I/O structure would
EVER be added to this emulator. SIMH code has to account for lots of
different peripherals with totally different I/O architectures. Does this
make SIMH bad? Not at all! Just different. In fact, it makes it more general
purpose and robust. HPEMU on the other hand tries to do one specific thing
directly and well.
There's another critical difference. HPEMU runs on unix. Period. I doubt
that it could ever be ported to Winblows or DOS as HPEMU uses too many
facillities that I don't think exist on Windows/DOS, even with Cygwin. There
are some benefits to this though. With HPEMU, everything in your emulated
system is a separate process. Each cpu, and for that matter each I/O
interface card in the cpu, and each peripherial device is a separate unix
process. Thus, the experimental code you wrote to emulate a 7925 disc drive
for example, is incapable of crashing the running cpu code. If your
experimental 7925 disc drive code goes south, you can kill it, and start up
another one, and your main cpu keeps right on reading the paper tape from
the emulated 2748 reader. These processes are started up when the executive
starts, and it only starts processes for the devices you specify are in the
virtual computer system (so you don't get a huge executable capable of every
device the emulator supports). And yes, it already supports MULTIPLE
computer SYSTEMS. Right now today you could start one copy of HPEMU up and
instantly get a virtual computer room. Multiple complete computer systems,
some with multiple cpu's each. And you can specify connections between the
computer systems, not just between the devices in a single computer system.
Go right ahead and put a virtual synch modem card in one of your cpus, and
designate it's TCP socket (or com port on your pc) and have it run RJE with
another system across the net. And because each entity (circuit card) is a
separate process, HPEMU actually takes advantage of SMP systems. Create
yourself a virtual HP2000/Access (dual cpu) system on a real dual processor
computer and each emulated cpu can get a separate real cpu!
Future Plans: Some hints.... each peripheral (and the cpu) physically being
accessible via any web browser. By physically I mean, from anywhere on the
net, pull up a picture of your running paper tape reader. Click on the LOAD
button. Drag and drop a different paper tape to it. Click on the READ
button. Click on the appropriate S-register bits of the cpu, Preset, Run...
watch your tape load....just like the real thing. Hum... would it be too
cutesy if it simultaneously played a sound file in the browser of the sound
of a real paper tape reader loading? Then telnet to the system and run the
program (or OS) you just loaded.
With HPEMU, everything in the user interface has been very carefully
designed around the experience of using the REAL hardware. For example, it
would have been easy to provide a single command to load a tape into the
paper tape reader and that's the end of the story. But no... in HPEMU, you
actually have to press the capstan engage button too, just like the real
thing. This type of extreme attention to physical details isn't really
addressed by SIMH to my knowledge. To do so would be inappropriate and
cumbersome I would think, given that it supports many different computers.
My goal is to not only be able to run TSB on it, but RTE as well. I suspect
(not positive) there's a lot of additional work SIMH would have to do to get
support for an RTE load.
I really didn't write HPEMU to compete with SIMH. Years ago, I wanted to run
HP2000 on an emulator and at the time SIMH didn't support most of the stuff
needed to do this on a 2100. I looked at the code for SIMH and found I would
be learning a lot of overhead stuff to learn how to code something into SIMH
(I don't mean this in a bad way). So I started writing my own. HPEMU isn't
targeted at people who want to run different computer systems (DEC, DG,
etc.). For a 2100 purist who wants something that he'll immediately
understand the nitty gritty internals of, I hope they use it and like it.
Afterall, if no one ever uses HPEMU, that's fine too. It's become a labor of
love really, and I am happy with it. But it also gives people (2100 users
anyways) a choice, and I personally think choice is a good thing.
> Maybe these two could share information.
There has definitely been information exchanged, albeit indirectly, over
time. There may have been one or two direct exchanges in the past, I'm
honestly not sure.
Regards,
Jay West
Received on Fri May 16 2003 - 16:02:01 BST