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.
I will have to guess, 7. Just because its a great number.
But seriously. Emulators are the way to go. I know that w/ Microsofts new initiative to let linux apps run in Windows, emulators are going mainstream. Yes, for all you anti-MS people, Windows is mainstream.
I was looking for the article about Windows Linux thing, but I cannot seem to find it at the moment.
--sig fault--
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 recently done this with a small webserver to keep it running. Some sort of deposit had appeared on top of the electrolytic capacitors on the motherboard, and the machine became unbearably unstable.
I took out one of it's mirrored drives and connected it in a different (larger) machine and then booted it using Usermode Linux.
I found it was best to be running 2.6.7 on both the host and the uml and it is bridged onto the host's network, so it appears exactly as before.
- Brian.
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
Ohh we have parts! for the Prime. We are swimming in parts. And we don't see running out any time soon. We still have customers using the Prime and we still maintain them. But we would love to get our hands on some Prime emulators to help with the migration to a new platforms as well.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
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
> Try emulating a paper tape reader....
The article (which I actually read on paper) talks about taking the tape, scanning it in segments, splicing, and using custom image recoginition to convert little circles into sequences of bits and bytes.
8-inch floppy disks is a diferent story.
I think their big thing is supporting legacy programs. Say your company spent millions of dollars back in the late 80's for some big iron, and some awesome server database stuff for that. Lets say these programs still meet your companies needs. But the hfardware itself is ailing, but you still need the software to run. Buy new machines to emulate the old machines. The actual data transfer can be done in many ways other than 1541 drives and I'm sure you can emulate the need to input data in old ways.
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.)
Probably not far from right. Considering, in 1984, we had a PDP-11/44 that ran on 4 Mb RAM (1 Mb per double wide board), with a 25-MB removable "platter". (a disk slightly bigger than a LP record. Remember them?) I don't remember what the DEC RM102 h/d had or even if I have the nomenclature right. The 11/44 was cool cuz there were no more switches on the front of it for inputting troubleshooting instructions (in octal). We actually got to use a keyboard for that! The good old days -- not.
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.
Quite a lot, and viably too. However, the REAL question is: how many Pentium 4's does it take to emulate a PowerPC at a usable speed, with and without Altivec (G4 and G3 emulation)? PearPC appears to get about a 75MHz G3 equivalent speed on an A64 3200+. NOT good at all.
But would a software-based emulator accurately reproduce the behavior of the infamous "More Magic" switch?
That's a serious question, by the way. How can it be proven that an emulated system will perform exactly the same way that the original system would?
Consider that even among the most popular emulators, those for videogame consoles and handhelds, you won't find many claimed by their authors to have more than 99% compatbility.
Yes, gaming hardware may possibly be more difficult to emulate than well-documented business hardware due to the number of custom chips that effectively have to be reverse-engineered, but do you want to migrate your mission-critical systems from physical hardware to emulated hardware only to find that they depend on the 1% of functionality that's not accurately emulated?
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.
Being asked to train your outsource replacement is bad enough. Being asked to write your replacement is even worse.
But since you're the only one who really knows how it works, would you mind terribly?Please?
You were 80% angel, 10% demon. The rest was hard to explain. - Over The Rhine
"Math in a song is good."-Linford