Booting the IBM 1401: How a 1959 punch-card computer loads a program
righto.com
righto.com
My high school had a Teletype machine with an account on this timesharing service. At the end of the school year Transdata hired me as "night operator" working the graveyard shift for $2/hour.
The fun part was that Transdata didn't offer their timesharing service at night! So the Sigma 5 was mine to do whatever I wanted with it.
I guess they figured I would at least make sure the building was secure, and maybe do something interesting and useful with the machine.
To run a batch job, you made a deck of cards with a boot loader card at the front. This card loaded the actual program from the next group of cards, and then that program would read and process the rest of the deck. Each card was 80 bytes.
Naturally, we tried to see what we could do with just a single card!
The Sigma 5 had a speaker you could toggle with an instruction, so one popular single card program toggled the speaker in a way that sounded like bird chirps.
Another popular card was a simple print program. Put this card at the front of a deck, and it would read the rest of the cards in the deck and print them on the line printer one by one.
But it was slow. It read a card, then printed the card and waited for that print line to finish because it was printing directly from memory. Only then it read the next card, printed that card, and so on.
I looked at the code and found there were a few bytes left, just enough to make the print program double buffered. Now it would read the first card into the first buffer and print it, and while it printed read the next card into the second buffer, then print from that buffer while reading the next card after, and so forth. It was twice as fast!
Of all the programs I've worked on since then - many of them massively more complex - this one sticks in my mind as something I'm proud of.
I just wish I still had that card.
Say I write a deck of FORTRAN code. What do I do with it next? Do I stack the a deck of cards labelled "FORTRAN COMPILER" and append my stack of code and a card printer pops out cards punched out with machine code?
The cards you put up with has two // These are you control cards One of these will be program card The next card with dd * you will be your program ...
An example is on p.88 of this manual http://www.computinghistory.org.uk/downloads/9041 , in fact follow up you have many details.
The computer center had stacks of control cards for different functions like this - they were color coded - so you had to remember to get a pink card and put it before your program deck.
It was possible to punch a binary output deck of your compiied program or even store it on disk or tape - there were different control cards for that.
Things were faster if you had a tape drive. Your source code would normally be on cards, but the compiler would be on tape.
You can see a video of FORTRAN II compilation on the 1401 here: https://www.youtube.com/watch?v=uFQ3sajIdaM
Other comments described a later system such as the IBM System/360, where you had an operating system so you could use a card specifying Fortran compilation and you were set.
Description of the compiler: http://ibm-1401.info/1401-IBM-Systems-Journal-FORTRAN.html
Quite a lot goes on before even EFI or similar firmware starts, which itself does quite a bit of work before the OS boot loader starts.
Interesting is definitely correct I suppose...
I don’t think I’ll ever get a good understanding of the x86 boot process.
>The IBM 1401 could also boot from a magnetic tape using a similar process; pressing the "Tape Load" button on the console loaded a record from tape, just like booting from a card.
Were the tape consoles prohibitively more expensive at the time? Were there certain workloads that lent themselves to magnetic tape vs punch cards or was this purely an economical concern?
>"The photo below shows the card that implements this flip-flop. With the 1401, you can actually see the physical transistors that implement each function."
Would you consider diagraming out that card like you usually do for circuits? I think that would be great addition or maybe even a separate blog post(s) on discrete CPU components in these old mainframes?
Lastly where did you manage to find access to a working IBM 1401?
IBM's documentation explains how the cards work in detail. I've put the information for each card online. For instance, the CW card in the article is described here: http://righto.com/sms/CW (Click the arrows on the schematic to get to the text description.)
I used the IBM 1401 at the Computer History Museum in Mountain View, California. They have two working 1401s.
They're surprisingly handy, especially when you want to just slip the boots on without lacing them to run out and check the mail or whatever. Stick your toes in, pick your foot up, tug the strap, and done - you don't even need to sit down.
And especially I like that it has a hot pink Emergency Off pull-switch.
Core Memory by John Alderman and Mark Richards is full of great photos of early/classic computers.
Maybe interesting in context, this page contains a description of how the DEC PDP-1 (announced the same year as the 1401) did it, using bootstrap code and a loader format that can be traced back to the TX-0: https://www.masswerk.at/spacewar/inside/insidespacewar-space...
I'm pretty sure it was this one: http://codeincluded.blogspot.com/2012/07/punchcard-reader-so... Looks like he added a punch card generator as well.
$ bcd hello
________________________________________________
/HELLO |
|]] |
| ]]] |
| |
|111111111111111111111111111111111111111111111111|
|222222222222222222222222222222222222222222222222|
|33]]33333333333333333333333333333333333333333333|
|444444444444444444444444444444444444444444444444|
|5]5555555555555555555555555555555555555555555555|
|6666]6666666666666666666666666666666666666666666|
|777777777777777777777777777777777777777777777777|
|]88888888888888888888888888888888888888888888888|
|999999999999999999999999999999999999999999999999|
|________________________________________________|
$ bcd hello | bcd -d
HELLO
I remember hearing this once from a friend who'd had some zSeries training, but I was drunk at the time, so who knows.
https://access.redhat.com/documentation/en-us/red_hat_enterp...
The actual booting part is a REXX CMS script, and you can see the references to punchcards within:
/* CMS EXEC script to punch RHEL 64-bit install */
'CP SPOOL PUN *'
'CP CLOSE RDR'
'PUR RDR ALL'
'PUN KERNEL IMG * (NOH'
'PUN 'userid()' PARM * (NOH'
'PUN INITRD IMG * (NOH'
'CH RDR ALL KEEP'
'IPL 00C CLEAR'
IPL IIRC was "Initial Program Load", and I'm guessing PUN would be "Punch" but since it's converting file formats I'd like to read it as "pun".
dd's built-in EBCDIC/ASCII conversion is terrible. It doesn't use any proper IBM codepage (such as EBCDIC 37 or EBCDIC 1047). It is based on the character set of some random mainframe printer at Bell Labs in the 1970s. As a result, it tends to garble punctuation (especially square brackets).
iconv can do it correctly – provided your copy of iconv has the EBCDIC conversion support compiled-in. Ubuntu's does, macOS' doesn't.
Most 8-bit ASCII codes (e.g. ISO 8859-n, UTF-8) are based on US-ASCII, where the first 128 characters are always at the same locations, including the punctuation marks traditionally used in programming. By contrast, different EBCDIC code pages put those punctuation marks at different locations. Even for US English text, there are two different EBCDIC code pages in common use, with different codes for square brackets, exclamation mark and pipe symbol – IBM 37 is the main traditional US English EBCDIC code page, and IBM 1047 is a variant originally devised for use with POSIX. UK English, and other European languages, add even more.
https://www.ibm.com/support/knowledgecenter/SSEPEK_10.0.0/ch... covers some of these details, although it doesn't go into the history behind it.
There is also the broader family of compatible 7-bit codes of which US-ASCII is a member – ISO 646. ISO 646 codes take US-ASCII, and replace up to 12 punctuation symbols with symbols needed in non-US-English text. Some people will say that only US-ASCII is ASCII, and these other derived 7-bit codes are not. On the other hand, the very existence of the term "US-ASCII" (which is IANA's preferred term) suggests that these other variants are ASCIIs too, and the original is just the ASCII for the US. Indeed, the original developers of ASCII foresaw and expected the development of variants of it for non-US use. It was only the later development of 8-bit codes (and then even bigger codes, such as ISO 2022 and Unicode) which meant everyone could standardise on the US version. And the fact that popular programming languages ended up using (close to) the full complement of US-ASCII punctuation marks gave people the motivation to do so – others you had to rely on ugly hacks such as C and C++'s trigraphs and digraphs.
A bit of (probably) useless trivia that I noticed, because I used to work in feature film visual effects, is that the card reader read 13 punch cards per second, which is about the same speed as an arriscanner which scans reels of motion picture film. You get about 4-10 frames per second depending on the resolution.
In the card punch, this is used to advance the card one row and then hold it stationary while the holes are punched. The punch can punch 250 cards per minute (more than 4 per second), and each card has to be stopped 12 times to punch the rows, so it's quite a remarkable high-speed mechanism. In film projectors, the Geneva drive advances the film by one frame and then holds it steady without vibration while the frame is projected.
Mechanical machines that perform several actions per second are a real marvel.
Did you ever write programs that ran on the 1401?
I’m curious to know what the scene was like.
Were people as excited about programming for punch cards as they are today writing javascript for the web? (For example)
My school didn't have a computer (in 1979) but the insurance company down the road did. So in our programming class we punched our cards and the teacher took them to the company. Next week, we would get a list of our compile errors - or occasionally - output an actual run. I can't now remember the language (I suspect some sort of basic) or the programs that I wrote. But I do remember being excited. This was the future!
That said when I started a programming course at University I was massively pleased that we had actual terminals (or 'new fangled glass teletypes' as they were sometimes referred to. We had actual teletypes (keyboard and a roll of paper, no screen) for APL programming as they were the only keyboards with the APL character set.
That’s awesome! :)
I didn’t ever work with punch cards, but my very first summer job in the early 90s with a big engineering company they were using several main frames. They were huge! Sort of like the WOPR in the film War Games, but less colourful flashing LEDs.
It was very corporate atmosphere, everyone wearing suits and ties, there wasn’t much of a sense of it being the future, just the way big engineering companies operated.
I never got to program on them, I just got a tour of the server room, so perhaps the atmosphere was different for the programmers.
I looked up teletyoes on Wikipedia. They look like an electronic type writer.
I can’t imagine the workflow for writing programs on such a device. I guess there was no vim/emacs yet. How did you go about writing a script to parse and process some data on such a device?
What is difficult to appreciate today is the sparsity of the software environment and the lack of tooling beyond editors and compilers and OS utilities. Use of third party libraries was essentially unheard of, at least in the academic environment world I started out in.
I recognise the names of all the machines you mentioned from the Steven Levy Hackers book. I suppose it must have been much slower progress with no internet to read tutorials, no code to read and learn from, I guess only books.
I had some time on Mini-computers back in the 80s, I think it was an Olivetti, but there wasn’t much you could do. There was wordperfect and some game were you walked around from room to room, but it was all text based.
I didn’t get really into computers until around 2002. It was the web when I got interested in computing, but I was always interested to learn about the scene in previous decades.
Are there earlier instances of this trope?
I never had to work with punched cards so this is actually new to me too.
This did result in my learning Turbo Pascal and Turbo C to a limited degree. Sometime in 88 we got a program which allowed maintain card images in simple ASCII format on regular DOS diskettes. The Sperry provided program could take an hour provided no errors to read that diskette and upload it. Through Turbo Pascal I was able to get it down to less than ten minutes for the largest amount with error recovery.
I don't know when the USAF stopped using cards but they were there in the early nineties but mostly in diskette formats and not physical cards. The comm center was special to me as it still had a Burroughs system noteworthy for the fact it was the first system they built that did not use tubes. You could boot it from switches but I never saw that done, I did see it booted from paper tape though.
On a side note, my father worked for IBM until the nineties when he retired, pretty sure he worked on this beast in the article. I will have to find out what he remembers of those days