Slashdot Mirror
Don't Nurse Old Hardware - Emulate It
gManZboy writes "Bob Supnik, former team lead for DEC's VAX microprossesor, has an article up on Queue about his Computer History Simulation Project and how emulating old servers may be a better way to keep them running that servicing the physical machines. So how many PDP-11's can you run on a Pentium 4 anyhow?"
I was even considering emulating existing hardware on beowulf clusters, I know it sounds like a troll or deja-vu joke but I mean it : if I have 1000 machines emulated on a beowulf of 1000 machines, then it'll be harder to get downtime if one machine physically crash.
Trolling using another account since 2005.
Bob's emulation software SimH is a *fantastic* bit of kit. Runs vanilla OpenVMS without modification - VMS doesn't even know it's in a sim until you tell it so when you licence it.
I know of a PDP-11/73 which to this day is still cutting sheet metal for a duct factory. The damn thing just won't die. And they're not likely to emulate since the I/O board interface between the computer and their machine tools would be more expensive to implement on a custom PCI card, along with emulation drivers, than simply buying excess used PDP-11 parts. Someday they'll have to face the music and actually buy a commercial solution, but for the moment they continue maximizing their return on investment for a computer system originally purchased well over thirty years ago. And why the hell not? --M
There are emulators for old IBM mainframes (S360 S370). Hercules is one of these.
Unfortunatly, the massive cost of liscencing the MVS (OS/390, zOS) operating systems means there is no way that a normal user can run a PC based mainframe. IBM employees can do it, of course.
I guess thats also true for the PDP-11 and many old Vaxen, its just cheaper to migrate to new hardware/OS.
**TODO** Steal someone elses sig.
The article does well by pointing out a great list of problems that can be encountered when emulating a machine.
/* nothing */ }
Some of the projects on which I work are for nuclear power plants, many of which here in Canada use computers from 1972 -- I was born in 1976 -- to control the plant. While spare parts are dwindling, the prospect of having to retest all of the code is daunting, not to mention the costs of making a program as complex as an emulator in the first place.
I've seen (the assembler equivalent to) the following code used in embeded processors to perform a sleep():
counter = 500; while (counter--) {
Imaginine executing that on an emulator that didn't pay any attention to timing?
I have such warm, fuzzy memories of hacking a PDP 11 and rabidly tearing away the wrapping from each DEC Professional magazine that graced my mailbox...
Yeah, emulation sounds more reasonable than what some nut did, he got the schools old PDP 11/50, with 1 TU16 and 2 RP04 drives and had his house (I sh!t you not) raised 12 inches so he could set it up in the basement. No idea what's happened since.
A feeling of having made the same mistake before: Deja Foobar
I've written emulators for devices. It depends on what you want to achieve. Emulating the interface may be relatively easy. If you used an old server to provide specific data or perhaps some kind of interface to another service, well you don't need to duplicate the entire server, you just have to implement a "jumper" system to provide a different path for the information flow.
Emulating an device comprehensively just to simplify servicing it could be futile or infeasible when you need to know the fine details of the device's characteristics. The manufacturer of a device might supply an emulator but I wonder just how many PDP-11's or machines lacking backwards compatibility still provide a vital nonupgradable function.
One may point to certain programs that used to run in DOS or in my case Win95 that don't run in XP. I want to speed up these programs on new hardware without having to buy the latest version. This is the downside of using Windows - if backwards compatibility is broken, a faster processor may force an expensive upgrade. Then again, all this backwards compatibility could be slowing Windows down.
Know your pads. One time pad: good for cryptography. Two timing pad: where to take your mistress.
A PC 5.25" drive won't read hard-sectored RX50 (DEC VAX) floppies.
You use your old VAX to make disk images for you before you give it to a collector.
Feel that power? That's mah MOUSING FINGER
About fifteen years ago, I was involved in the retirement of a number of older computing systems (specifically IBM "Series/1", "System/7" and "1130"s) used in manufacturing. At the time, these systems were critical in supporting older products (most notably FAA radar displays) but had been withdrawn from regular IBM support and parts were only available from returned equipment.
I could appreciate the article's comments about engineering detective work; we had some source code on paper, some source and binary code archived on disc and some binary code saved on cassette tape (seriously). Product, tester and controller documentation was spotty to say the least. For the most part, we had enough understanding of what was happening to be able to recreate the test specifications for all the products.
The big problem was understanding actual timings and electrical parameters; few of the part numbers were built from standard TTL ("VTL" in IBM parlance) and most were built using IBM "SLT" technology implementing RTL and DTL logic.
After collating all the data we had, we decided we could: we could simulate the controller operations in a PC. In many cases, we could emulate the operation of the controller/tester hardware with basic digital I/O cards connected to a PC. Finally, in quite a few cases we were completely on our own due to unusual (for today) electrical requirements.
Due to the large number of part numbers (1500), we wanted to come up with a single solution that made the most sense and, ideally, worked for all the different part numbers. We looked at simulating the controllers with PCs and passing the I/O to the old tester hardware, emulating the tester using a PC with I/O cards or converting the tests to run on a standard InCircuit Tester (ICT).
In virtually all the cases, it made the most sense to convert the tests to run on a standard ICT tester (GenRad (new Teredyne) 228x was chosen) rather than simulate or emulate the hardware. The conversion applications generally converted the binary code into digital I/O operations (or GPIB instrument I/O) rather than come up with compilers for the original source code (although we did do this in one case). This was still a rather large job, but it was completed before parts sources for the old controlling computers completely dried up.
I suspect that from the lack of hardware interfacing information in the article, the author has run into similar problems. Despite that, having a simulator could be very useful in understanding how an old computer system operated and what is required to properly emulate/convert it into more modern hardware.
myke
Mimetics Inc. Twitter
how about a Serial RS-232 link... Kermit, that hoary standard, still is one of the best cross-platform transfer methods for machines of pre-Ethernet vintage.
At 9600bps you can transfer even the highest density 8" floppy in under half an hour!
(Ah, shades of my college job where our 'network' was oddball generic-MSDOS machines all with serial links to the VAX 11/750 in the back room with *Three* 30MB 14" Winchester drives, almost 100MB online, rah! Don't try and power all three up at once, though, or you'd blow the 100Amp breaker.)
Actually, it would be fun to see how many pentium-4's you could fit inside a PDP-11 case.
I miss those 8 inch 100K? floppy drives though - those were the days when floppy lived up to its nam, and the drives made interesting squeaking noises while they were being read. I still have a couple of them downstairs, I was part of the last class that used PDPs before the university retired the old 11/70.
The PDP OS had a weird (and annoying habit) of automatically making numbered backups every time you saved - in theory sounds like a good idea, except with an entire class editing and saving assignments, the main drive ran out of space and the whole system froze every 15 minutes, and we had to hunt down the TA to reboot it. "Delete your files, delete your files" was a cry heard every 5-10 minutes in the lab, lest the whole system hang and die yet again.
Back in the 1970's, that astronomically expensive PDP 11/03 in the Heathkit catalog was my dream machine, as it was the only true 16 bit PC on the market. I even bought the paper tape software and manuals for it!
My rights don't need management.
I'm sure its being done as we speak. In 1998, I helped implement a Honeywell 316 emulator to replace a real H316 computer in two F15/F16 diagnostics test stations. The test executive and user programs were all written in H316 assembly language. Seeing that the H316 is no longer in production, the only choice was to emulate the machine given that porting the existing code would have taken an inordinately long time and porting code we don't know about is obviously impossible. The test stations themselves contain new hardware from the late 1990s and the emulator contains device handlers to communicate to them via GPIB and other busses. The test executive uses standard H316 IN and OUT instructions to access the hardware. I also implemented a TEK400 display emulator and interfaced with a VB app that replaced a big custom console table with dedicated operator buttons that would be used during the tests. The customer must have liked it because they followed up on the contract with a request for more. In that sense, I'd say emulation is definitely a reasonable option. Its not always the right option. The downside is that there is still have old code to maintain. The system is a little more understood now, but you still have old archaic code. The upside is that writing an emulator often takes significantly less time than the alternative of rewriting.