It's interesting how a cultural artifact belonging to a museum is better preserved in software. It is unlikely anyone will put the hardware in a museum, let alone getting it operational and allowing someone to play with the exhibit.
Many of the better museum exhibits tend to tie in things to people's daily life in the present. I searched an anachronistic term, "game of thrones."
For everyone else reading this, if you live in the bay area, you should seriously visit the Computer History Museum. It's absolutely fascinating to see how far we've come in such a short time. I had assumed I wouldn't get much value from the trip, but I was blown away.
I saw that presentation last week. What I found even more awesome than the presentation itself was that the presenters were Peter Samson and Steve Russell, the two MIT hackers who had written the software originally.
Yes, that would be the guy, although in the context of the PDP-1, he was only talking about Spacewar.
Samson was demonstrating four part audio synthesis of Bach organ pieces. It turns out that during the restoration project, they came across some of his original data tapes encoding the music, but the software was long lost, so he recreated his hack 50 years later, with the additional constraint that he had to reconstruct his data format and remain compatible with it!
Speaking of Steve Russell: Meanwhile I've received a quite flattering mail from S.R. on the authenticity of the feel of the version of "Spacewar!" associated to the page.
How nostalgic for me, reminds me of my days as a junior Data General field engineer - Nova 3, Eclipse S/130, S/140, S/200'S + Phoenix and Gemini 10+10 and 5+5 toploaders.
Admittedly this was their Dasher D200 (current loop) and LP2 era, but we did sometimes bootstrap DTOS (Diagnostic Tape Operating System) from paper tape if all else failed. We even had a couple of ancient punched card readers in stock for certain oddball customers, just in case.
I used to have a rig that looked like this in my parents dining room:
Regarding 2, remember that you're looking at a turnaround time of hours to try running your program, unless you were in a special situation. Anytime punch cards are involved, response time goes from seconds to minutes or hours.
"Development" would be sitting down, writing your program on sheets of paper (marked out to 80 columns so you know how many characters you get). Then either you'd key it yourself, or you'd send it off to be keyed onto cards. I'm not really familiar with the 390, but that's typically how things would work on a punched-card (i.e. batch) system.
We had the fugly IBM terminals by the time I went to the university. Long lines waiting to key in your assignments, then even longer time awaiting the printouts.
Found a nice loophole that I could exploit. Modem users got higher priority on jobs. Plus the TRS-80 Model4P I owned was capable of terminal emulation and other nice tricks to speed up Fortran and JCL assignments. So I sat in the comfort of the dorm room and used the time I saved on EE assignments.
Ah, yes. I'm aware of that. I actually read this rather famous book on the subject, "Hackers: Heroes of the Computer Revolution" by Steven Levy. I thoroughly enjoyed it. All the stories, machines, code and people. If anyone wants to get the feel of those times I highly recommend it.
Makes you realize in 1000 years there will be museums where people will go to see the early ipad and android devices and wonder how anyone got anything done with them, and stare at 3.5" and 2.5" hard drives with their ridiculously tiny 1TB capacities. Hmm, maybe even in just 100 years.
Just having the most fun playing a round of "thermonuclear war" (well, actually, it's mostly playing itself), better than any (AAA) title I have been playing lately.
This one is going to take forever. And I am glad that we moved from printed output to graphical displays, the amount of forests we would have had to cut down...
I once had demigod access to Southampton University Computer Centre. The ops staff used to rip erroneous job cards in half and put them back in the deck for repunching. Clueless or lazy students sometimes repaired them with sellotape and resubmitted. The resulting bang as the card hit a high speed reader could be heard across the whole room and would take out the card reader for about 15 minutes while glue was cleaned off the innards.
This time that user's whole job would be returned, guillotined in half and tipped into a manilla envelope, with a suggestion that next time they repunch error cards. Savvy users realised that you could repunch the correct code and use chad to fill in unwanted holes. Stacked in a deck these could last a surprisingly long time. (Yes, I'm that old.)
CHANNEL ERROR (VERBOUS)
RECEIVED MESSAGE "Quota Exceeded. Please see http://code.google.com/apis/websearch.
HUMAN READABLE: "Mountain View, we have a problem."
ADVICE: A quota error indicates a temporary overload due to high demand. Please retry later.
Great experience though, props to those who made it!
Watching the tape animation makes me think that these guys have never actually seen a magnetic tape unit before. At several points, their animation shows the reels spinning in opposite directions. An actual tape would snap if you could somehow get the reels to do that.
Having only a limited amount of RAM accessible, you simply had to rewind the tape drive in order to process data. (E.g., for the UNIVAC I, the first computer to rely on tape drives, there were the commands 1nm, 3nm to read/write forward and 2nm and 4nm to read/write backward. That's also what the seek-command in any file-API is for.) The vacuum columns provided the extra amount of tape to control the tension and keep the tape from snapping.
In the animation, the exaggerated action of the tension rollers stands for this functionality of the vacuum columns, which can't be shown in the limited screen estate.
(In the ambient audio there's a "floop" like sound, probably produced by the vacuum columns on occasion of a reversal of the direction.)