The ENIAC, or Electronic Numerical Integrator and Computer, is essentially the Great Great Grandfather of whatever device you’re currently reading these words on. Developed during World War II for what would be about $7 million USD today, it was designed to calculate artillery firing tables. Once word got out about its capabilities, it was also put to work on such heady tasks as assisting with John von Neumann’s research into the hydrogen bomb. The success of ENIAC lead directly into the development of EDVAC, which adopted some of the now standard computing concepts such as binary arithmetic and the idea of stored programs. The rest, as they say, is history.
But ENIAC wasn’t just hugely expensive and successful, it was also just plain huge. While it’s somewhat difficult for the modern mind to comprehend, ENIAC was approximately 100 feet long and weighed in at a whopping 27 tons. In its final configuration in 1956, it contained about 18,000 vacuum tubes, 7,000 diodes, 70,000 resistors, 10,000 capacitors, and 6,000 switches. All that hardware comes with a mighty thirst for power: the ENIAC could easily suck down 150 kW of electricity. At the time this all seemed perfectly reasonable for a machine that could perform 5,000 instructions per second, but today an Arduino would run circles around it.
This vast discrepancy between the power and size of modern hardware versus such primordial computers was on full display at the Vintage Computer Festival East, where Brian Stuart demonstrated his very impressive ENIAC emulator. Like any good vintage hardware emulator, his project not only accurately recreates the capabilities of the original hardware, but attempts to give the modern operator a taste of the unique experience of operating a machine that had its heyday when “computers” were still people with slide rules.
How Low Can You Go?
Given the monstrous rift between the computational power of the ENIAC versus something as pedestrian as the Raspberry Pi, it’s natural to wonder just how much abstraction is required to emulate the hardware. We occasionally talk about “cycle accurate” emulation when dealing with older hardware: which essentially means that the emulator can run software from the original machine without the software needing to be modified. The emulator is accurate insofar as the software running on it cares to look, but it does’t mean the underlying methods are the same. This lets an emulator run the older software while using modern tricks to help improve overall performance.
But with a computer as slow as the ENIAC, speed isn’t really a concern. We’ve got plenty of power to burn, so how accurate can you get? Originally, Brian thought it would be interesting to simulate ENIAC on the circuitry level. But given that part count, and the fact that the documentation really only has a rough explanation of the internal circuitry, he thought that might be a tall order. In the end, he decided to simulate the ENIAC down to the actual pulses that would travel though the machine while in operation. This level of emulation makes his software exceptionally accurate, and indeed it can run any example program from the original ENIAC technical manuals, but does mean that even on modern computers the simulation can run slower than on the actual ENIAC. But the increased fidelity, especially for those who wish to truly understand how early computers like this operated, is worth waiting around for.
The ENIAC Experience
It would have been easier to create a command line emulator for the ENIAC that just dumped its results to the terminal (and indeed others have done just that), but that wouldn’t give you the feeling of actually running a computer that was large enough to take up a building. For that, Brian created a number of visuals that use actual images of the ENIAC panels. This gives the user the impression of actually standing in front of the computer, watching the banks merrily blink away as it works through the given program.
While it’s not required to use the emulator, Brian even went as far as recreating the handheld control unit the ENIAC operators would have used. He mentions this peripheral is often overlooked, and in his research was only able to find a single clear shot of what the device looked like for him to base his 3D printed model on.
ENIAC: The Home Game
Brian has made the source code and compiled binaries for his ENIAC simulator available for anyone who wishes to try their hand at commanding a virtual representation of the original “Big Iron”. He’s even provided binaries for machines as lowly as the C.H.I.P (if you can find one, that is) so it doesn’t take much gear to get your own mini ENIAC up and running. You’ll have to provide your own hydrogen bomb to research, though.
If you’d like a crash course on the rather alien methods of programming the beast, our very own Al Williams recently wrote up a fantastic piece about the ENIAC, including some information on operating it within a virtual environment.
23 thoughts on “VCF East: The Desktop ENIAC”
I spent a fair amount of time chatting with [Brian] about this project. I have an interest in the first generation computers and this was one of my favorite exhibits at VCF East.
An ENIAC cycle accurate simulator running slower than the actual machine? I’d say this is because: 1. Lack of optimisation.
2. Choosing go as programming language.
But mainly 1.
It’s beyond just cycle accurate, that’s the whole point. It is simulating the ENIAC on the electrical level. If it was just cycle accurate, it would be much faster.
It does not simulate the ENIAC at the circuit level. From this very HaD article:
“Originally, [Brian] thought it would be interesting to simulate ENIAC on the circuitry level. But given that part count, and the fact that the documentation really only has a rough explanation of the internal circuitry, he thought that might be a tall order. In the end, he decided to simulate the ENIAC down to the actual pulses that would travel though the machine while in operation.”
So, I guess is something intermediate between circuit level and cycle accuracy.
I think the previous comment is more or less correct in saying that it is an electrical simulation versus a circuit simulation. Though admittedly it’s a gray area.
The software simulates the electrical pulses as they would travel between components, but it doesn’t attempt to actually simulate the operation of individual transistors/tubes/etc. So it’s less abstracted than most emulators, but not as low as you could potentially go.
History of the IC and computing go hand in hand. Maybe in a Fallout universe it would be the history of tubes.
But it would never have led to the integration density of today’s ICs. It’s quite difficult to deposit metal layers on vacuum and structure them to metal traces.
I think HaD did an article a while back about vacuum circuits in silicon…
Why would metal need to be deposited on vacuum?
If you want an air-bridge deposit metal on something and then etch away that something while keeping the metal.
I think that, technically, that input device was really the first mouse. It looks to have all/most of the features of a modern day mouse. I had not considered how they manipulated that giant machine before seeing that controller. Interesting article.
It’s neat that they actually went to the pulse level for emulation. Many people don’t realize that almost all emulators only go down to a fairly high abstract level and none actually emulate the actual physics. Very few do transistor level emulation. It’s also not immediately clear just how much actual raw computation is even needed to emulate things as “simple” as an Atari or Eniac at the circuit level, let alone actually doing a full emulation of all of the actual molecules involved.
If interested, you can learn more about transistor level simulation of the slightly more advanced 6502 chip at http://www.visual6502.org/welcome.html
Brian has been working on this for several years. I’ve seen two iterations of it, most recently at VCFSE. He has put an incredible amount of research and work into it and spends lots of time with visitors explaining it. He is truly preserving the history of this fabulous device for future generations to understand.
Recently I read the autobiography of Jean Jennings Bartik, one of the six programmers of the ENIAC. In the book, she talks how women where relegated to the lowest task, and if they were used as programmers was precisely because it was considered a “simple task” (at the time, it was considered that the true complexity was in designing the machine, not in programming it; this didn’t change until the Apollo Guidance Computer).
I remember seeing a picture of the ENIAC when I was 10 (in the 80’s), and wondering why was there “that woman posing in front of the computer, like in a car advertisement”… Now I’m embarrassed of that, but funny enough, Jean explains in the book that it was a very common misconception, which was only fixed in the 90’s, during the 50 anniversary: until them, nearly all people that saw the pictures believed they were just “refrigerator women”, and not the real programmers. In fact, the men in the pictures were the ones “posing”.
To be fair, Margaret Hamilton didn’t write *all* of that code herself. But she was the lead software engineer of the Apollo Project Guidance Computer.
“In this picture, I am standing next to listings of the actual Apollo Guidance Computer (AGC) source code,” Hamilton says in an email. “To clarify, there are no other kinds of printouts, like debugging printouts, or logs, or what have you, in the picture.”
“PDF scans of the source code is located at http://www.ibiblio.org/apollo/ScansForConversion/ and there are about 11,000 pages, which is not inconsistent with what we see on in the picture: the paper is likely continuous stationery and 11,000 pages of that are 165cm tall, since a box of 2,000 is about 30cm (ref).”
The movie Top Secret Rosies is well worth the watch: https://youtu.be/PuFJE0tuz1c
I love that this is a guy from Drexel making a simulation of a machine that was created just a few blocks away, at Penn. Such a Philly jawn.
This was a cool exhibit, but the Sunday opening starred picking the front gate lock to let the visitors in. Nice application of “Why yes, I did bring my picks, why?”
” At the time this all seemed perfectly reasonable for a machine that could perform 5,000 instructions per second, but today an Arduino would run circles around it.”
I understand that you need less computing power to design hydrogen bomb than Arduino has. But you must understand that my door bell project really need ARM because Arduino is too lame! ;-)
To make this true you only need to want software decoding of MP3 doorbell chimes. The MAS3507 is probably not available anymore.
Moore School of Electrical Engineering
University of Pennsylvania
Tom? You were there? So was I. I”m surprised that the rest of the crew didn’t say anything…… And yes that was an interesting job that of emulating a computer system that basically started everything off.
Please be kind and respectful to help make the comments section excellent. (Comment Policy)