Kevin wrote.... 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. 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