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.
pentium IV's can you emulate on a PowerPC?
emulating old servers may be a better way to keep them running that servicing the physical machines.
I disagree. It's not the same thing.
-- Signed: your friendly PDP-11 system operator downstairs, 3 years from retirement.
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
.. but you forget the reason people dont upgrade is that it costs money to do so.
Steal This Sig
Before I even R'd TFA, I thought about one big problem:
How are you going to emulate a 5.25 inch drive to read old disks?
I gave up sigs almost a year ago.
Although this is a very good idea I question the stability of a new emulator vs an old proven system.
By using the original the kinks have already been worked out, quirks are known and understood, and everything just works.
By creating an emulator you have bugs to smash, that's just the way software is. Also keep in mind this seems to apply to big businesses (financial, medical) and large organizations (NASA) with legacy hardware. Since the stability of these systems is absolutely crucial why would they want to switch to a new, unproven, buggy system that stick with the old?
by Bob Supnik, Sun Microsystems
Gee, I wonder why he would be recommending buying new servers?
---
Those who can, do
Those who can't, teach
Those who don't know how, supervise
TOP TEN SIGNS THAT YOU'RE A VAX GEEK
Key traits identifying individuals tendencies towards abnormal preoccupation with VAX computer systems
9. When talking about building software you make reference to
compilation times in weeks and days instead of minutes and seconds.
8. You stopped purchasing new furniture when you realized that
your computers work just as well.
7. Your electricity bill is more than your monthly rent payment.
6. You've been hospitalized with muscle strain injuries after
performing some routine hardware maintenance on your computer.
5. You don't have an SO, but it's okay because your computer keeps
you warm at night.
4. While doing laundry, you occassionaly have a mental lapse and try to
wash your socks and underwear in your 11/750.
3. Friends who visit you want to know why there are old-time movie reels
stuck on your refridgerator(s).
2. Your house is pleasantly warm in the dead of winter, even with the air
conditioning turned all the way up.
1. The lights in your home dim or flicker when you reboot.
0. It doesn't matter to you if someone else's computer is faster because
you know your system could smash theirs flat if it fell over on it.
-------
Support Indy Music. Buy
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?
All of them?
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