Hacker News new | past | comments | ask | show | jobs | submit login
Booting the IBM 1401: How a 1959 punch-card computer loads a program (righto.com)
107 points by CaliforniaKarl 13 days ago | hide | past | favorite | 44 comments





My first personal computer was a Scientific Data Systems (SDS, later Xerox) Sigma 5, owned by Transdata in Phoenix, Arizona, in the summer of 1969.

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.


Sorry for hijacking your response but I have a question that you might know the answer to: how did using compilers work back in the punch card days?

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?


On the IBM 1401, there wasn't an operating system so compiling a program was like you said: you put a stack of cards with the compiler and your program in the card reader. The compiler ran in literally 63 phases since there wasn't enough memory to do very much at one time. Compilation took about 3 minutes plus .76 seconds per statement. Your executable got punched onto a stack of cards that you could then run.

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


If no one reply you on that old machine I can answer for ibm machine which still use card reader concept in its jcl card deck.

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.


You could do just that, but the usual way was to put a single "control card" that invoked the FORTRAN compiler before you own code. This invoked a compiler that was already stored in the system, on tape or disk.

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.


That's a really wonderful anecdote, thanks for sharing! This was especially nice since I just read the Wikipedia article on double buffering so I immediately understood your work.

https://en.wikipedia.org/wiki/Multiple_buffering


You must be absolutely overwhelmed by the power of just one PC these days :) Great story!

Modern systems are even more interesting in how they boot. There is chipset initialization, DRAM configuration, etc that needs to be done. But how do you execute when there is no DRAM? It turns out modern CPUs have a decent amount of cache so they load the code from ROM or flash into the CPU's cache and both execute from there as well as using it as RAM.

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.


And then even before BIOS/EFI is Intel’s ME or AMD’s PSP. And when control is handed over to the BIOS/EFI, the processor is pretending to be an 8086-era processor running in “Real Mode” (16 bit). The BIOS/EFI have to tell the processor to stop pretending (switch to “Protected” (32 bit) or “Long Mode” (64 bit)), do their things - and in the case of the BIOS, switch back to Real Mode - and then hand control over to the OS. It’s layers and layers of complexity all the way down. It’s astounding how much technical debt there is in these machines, and yet they still work.

iirc, the first thing it execute any sort of code is the power management controller (PMC) somewhere on the chipset.

> Modern systems are even more interesting in how they boot.

Interesting is definitely correct I suppose...

I don’t think I’ll ever get a good understanding of the x86 boot process.


The first FORTRAN programs that I wrote were a version called FORTRAN WITH FORMAT that ran on an old 1401. This was 1969. The compiler booted from an old dogeared card deck and somewhere around the middle of the deck there was a bent card. You had to slap the side of the card reader to get it going. I remember carrying a tray full of a hundred or so carefully typed program and data cards to the computer room. There was a small control deck that loaded first and then the compiler and behind that the FORTRAN source and then the data deck. Upper classmen on passing a freshman in the hall carrying deck would knock the tray so that the cards would fall on the floor and needed to be sorted all over again.

Many years ago, I wrote a one-card program to duplicate a card deck – reading from the reader and punching a copy until there were no more cards in the input. I can almost remember it: ,008015,022029……1200 (don’t remember all the opcodes, or special memory locations)

Boot straps are still a thing! You'll find them on just about any pair of more than ankle-high workboots, including my 9-hole loggers.

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.


I love the visual design in the close-up of the console. Actual physical switches and light-up buttons, and the way that the lines and arrows document the control flow. I have a Rigol digital oscilloscope on my desk right now that has a slightly similar aesthetic.

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.


Wow what a fascinating post this was. I had a questions and a comment.

>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?


Tape drives rented for about $1000 a month ($9000 in current dollars). Tape drives were pretty common because they could hold much more data than cards. However, everyone used cards for data input because you couldn't enter data directly onto cards. Sorting was tricky on tape drives; you typically needed 4 drives. Cards were also more reliable since it's pretty hard to destroy a card unless you burn it. (Even if someone rips up a card, you just look at it and punch a new one.)

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.


Ah neat. I somehow missed the clickable schematic cards. Good stuff. Cheers.

As usual, a fascinating read!

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 remember using a python script that would decode pictures of punch cards using PIL, and trying it on some images from a google image search.

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.


Image input! Like a practical version of the old bcd -d command...

    $ bcd hello
     ________________________________________________
    /HELLO                                           |
    |]]                                              |
    |  ]]]                                           |
    |                                                |
    |111111111111111111111111111111111111111111111111|
    |222222222222222222222222222222222222222222222222|
    |33]]33333333333333333333333333333333333333333333|
    |444444444444444444444444444444444444444444444444|
    |5]5555555555555555555555555555555555555555555555|
    |6666]6666666666666666666666666666666666666666666|
    |777777777777777777777777777777777777777777777777|
    |]88888888888888888888888888888888888888888888888|
    |999999999999999999999999999999999999999999999999|
    |________________________________________________|
    $ bcd hello | bcd -d
    HELLO
https://man.openbsd.org/bcd.6

Pretty crazy how the code had to "out-run" itself setting word marks on every instruction, "spending" word marks in the process.

Can someone answer a question for me? Is or was it ever true that booting Linux on a zSeries mainframe involves converting (part of?) the bootloader into 80-column card sized chunks to feed into a virtual card reader?

I remember hearing this once from a friend who'd had some zSeries training, but I was drunk at the time, so who knows.


You can boot from a z/VM reader, which would be a virtual card reader, but it's not the only option.

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'
It's not as terrible as it sounds. It just turns kernel.img and initrd.img from stream files into record based files with records of 80 bytes.

From the linux side, dd(1) has blocking/unblocking and EBCDIC/ASCII conversions as well.

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".


> From the linux side, dd(1) has blocking/unblocking and EBCDIC/ASCII conversions as well.

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.


So EBCDIC is like “ASCII” in that there isn’t one true definition (people making 8 bit code pages and claiming it was ASCII)?

Even if we limit ourselves to 7-bit codes, ASCII still doesn't have one true definition. US-ASCII was first published in 1963. In 1967, a new revision was published which changed some of the characters – most significantly, left arrow was replaced by underscore and up arrow was replaced by caret, although also some control characters were renamed/replaced. The vast majority of systems nowadays use the 1967 revision, which is also the basis of subsequent standards such as ISO-8859 and UTF-8. However, the 1963 standard did see some historically significant use – Smalltalk adopted it, and even today some Smalltalk implementations display up and left arrow instead of caret and underscore. It also influenced the choice to use the caret for exponentiation in languages such as BASIC (the original Dartmouth BASIC used 1963 ASCII rather than 1967.) The ASCII extension used by 8-bit Commodore systems (PET, VIC-20, C64, etc), PETSCII, is also based on the 1963 edition of ASCII rather than the 1967.

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.


Kind of, but the incompatible versions all come from IBM.

Although IBM invented EBCDIC, other vendors adopted it, and some of those other vendors created their own slightly incompatible versions of it as well. For example, Unisys mainframes (running MCP) have their own EBCDIC variant called "ASERIESEBCDIC" (named for its A Series mainframes). They also support another EBCDIC variant called "STDEBCDIC" ("Standard EBCDIC"), which I am guessing by its name is more compatible with IBM's (although I'm not sure which IBM code page it corresponds to)

Thanks! It totally makes sense that you'd have a mechanism for booting an image like that, considering how heavily mainframes use virtualization and how insanely backward compatible they are.

Right, it's klunky, but doesn't seem much different from what you see around BIOS/UEFI/grub and so on.

I find something appealing about how the vestigial remnants of physically punched cards are retained to boot the OS, even though they don't really make sense any more. It's weirdly reminiscent of biological evolution, where systems get retained and repurposed even if they're not the most efficient way something could be implemented.

This article is worth to read just for the history of the term "bootstrapping". The rest is great too.

Without bootstraps, but by his ponytail, the fictional Baron Münchhausen pulls himself (and his horse) out of a swamp in the 18th century: https://upload.wikimedia.org/wikipedia/commons/3/3b/Muenchha...

Are there earlier instances of this trope?


Yeah I thought that bit was cool too.

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.


If you want another piece of trivia related to film, both film projectors and the 1401's card punch use a Geneva drive. The idea of a Geneva drive is that a drive wheel with a pin quickly rotates a second wheel and then locks it into place, before repeating the cycle. It rapidly alternates between quick motion and stopping and holding steady.

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.

https://en.wikipedia.org/wiki/Geneva_drive


Great bit to of trivia!

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)


> 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.


> This was the future!

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?


The workflow for programming in APL on a teletype was IIRC a bit like using a REPL-based system. APL is a concise language so the programmes we were writing as part of our assignments were only a few lines long. But the bulk of the programming (1980) was on Amdahl and DEC mainframes, in Pascal and sometimes FORTRAN on VT100-type green screen displays, with a bit of COBOL as well. Later C on Vax machines (1982), and in my case Prolog. These all allowed a basic workflow of think-edit-compile-run/debug. All at the command line, with vi for editing on the Vax. I don’t recall the names of the editors on the DEC and Amdahl.

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.


Of course! A REPL style interface hadn’t occurred to me. That totally makes sense.

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.


The difference between when I started in 1981 and 1959 is the same distance as today vs 1999, when the Dotcom era was going strong, and the web was still relatively new.

I never had to work with punched cards so this is actually new to me too.


My days in the US Air Force were in mid eighties, we had punch cards. Seriously numbers of them fed to a Sperry 1100/60, later Unisys. VK runs, personnel, would comprise four to six boxes of cards. Storage on the system was a small disk set but mostly comprised of autoloading tapes. It was the various groups we served on base that brought us cards which we loaded and returned.

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




Applications are open for YC Summer 2021

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: