Pete, When the webpage is back up for OpenMpe take the time to read the minutes going back in time, you will see the bottle necks in this mess are Dave W, Mike P. These two guys are the slugs that HP has given the honor to "slow / stop" the process of  allowing MPE source to be placed in the hands of a company that will safely store it.


-------------- Original message from Pete <[log in to unmask]>: -------------- 


> Alan, it is refreshing to read some worthwhile comments. I have very 
> limited knowledge of RTE (Real Time Executive?) and the HP1000. What 
> I recall is that when programming on RTE, you are pretty close to the 
> metal. Software emulation is certainly easier than hardware 
> emulation, but there is a real performance hit. Maybe not enough to 
> make a difference in switching from PA-RISC to modern x86, but still a 
> hit. Maybe not a problem. 
> 
> HP was quite loose with their system code in the old days. I still 
> have a 9 track tape of MPE-V, but maybe not readable and I don't have 
> access to a drive to test it right now. Since HP switched to the 
> PA-RISC architecture, they got pretty tight with their MPE code. 
> Don't know what the situation is now, but if it were easy, OpenMPE 
> would already have a copy to start with. The HP3000 PA-RISC machines 
> are fairly complex with a fair amount of diversity, but then, I 
> suspect you only need to pick one. Then you need to get MPE/iX 
> working, which is a far larger and complex animal than RTE. 
> 
> Let's say you did get it working. You now need a fairly large and 
> technologically savvy team to maintain and enhance MPE going forward. 
> This is likely to be a problem. Having virtual devices does reduce 
> the problem, but does not remove it. 
> 
> Still successful emulation of a machine to do a simple editing session 
> and a file copy does not compare to doing that with several hundred 
> users logged on with a half a dozen or more large database jobs 
> running at the same time. Yes, modern CPUs put the older HP hardware 
> to shame, and many of the IBM mainframes also. But, when you are 
> talking about large database systems, it is the I/O bandwidth that 
> counts, and with several hundred users banging away, character I/O 
> becomes a heavy burden. Both HP3000 and IBM mainframes offload 
> terminal character processing to I/O processor boards so that the CPU 
> and operating system only sees record I/O and is never interrupted by 
> character I/O like terminals generate. 
> 
> I would be interested to know if you can show me an example of a large 
> multiuser machine running in software emulation mode. 
> 
> - Pete 
> 
> On 9/15/06, Alan Tibbetts 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.