5 ms·

Booting the IBM 1401: How a 1959 punch-card computer loads a program

107 points by CaliforniaKarl 6y ago

tyingq 6y ago
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-software.html http://codeincluded.blogspot.com/2012/07/punchcard-reader-so... Looks like he added a punch card generator as well.
- seryoiupfurds 6y ago
  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 https://man.openbsd.org/bcd.6
sedatk 6y ago
This article is worth to read just for the history of the term "bootstrapping". The rest is great too.
- mjgs 6y ago
  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.
  - kens 6y ago
    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 https://en.wikipedia.org/wiki/Geneva_drive
    - mjgs 6y ago
      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)
      - KineticLensman 6y ago
        > 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.
- 082349872349872 6y ago
  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/Muenchhausen_Herrfurth_7_500x789.jpg https://upload.wikimedia.org/wikipedia/commons/3/3b/Muenchha... Are there earlier instances of this trope?
Stratoscope 6y ago
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.
- accrual 6y ago
  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 https://en.wikipedia.org/wiki/Multiple_buffering
- prox 6y ago
  You must be absolutely overwhelmed by the power of just one PC these days :) Great story!
MaysonL 6y ago
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)
meepmorp 6y ago
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.
- tyingq 6y ago
  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_enterprise_linux/6/html/installation_guide/s1-s390-steps-boot#s1-s390-steps-boot-Installing_under_zVM-zVM_Reader 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.
  - 082349872349872 6y ago
    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".
    - skissane 6y ago
      > 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/char/src/tpc/db2z_codeptdiffebcdic.html 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.
masswerk 6y ago
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-spacewar2bsa5.html https://www.masswerk.at/spacewar/inside/insidespacewar-space...
xenadu02 6y ago
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.
- colejohnson66 6y ago
  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.
  - the_only_law 6y ago
    iirc, the first thing it execute any sort of code is the power management controller (PMC) somewhere on the chipset.
- the_only_law 6y ago
  > 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.
0x0 6y ago
Pretty crazy how the code had to "out-run" itself setting word marks on every instruction, "spending" word marks in the process.
coldcode 6y ago
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.
- Shivetya 6y ago
  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
andyjohnson0 6y ago
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.
bogomipz 6y ago
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?
- kens 6y ago
  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 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.
  - bogomipz 6y ago
    Ah neat. I somehow missed the clickable schematic cards. Good stuff. Cheers.
kpgraham 6y ago
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.
throwanem 6y ago
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 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-software.html http://codeincluded.blogspot.com/2012/07/punchcard-reader-so... Looks like he added a punch card generator as well.

seryoiupfurds 6y ago
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 https://man.openbsd.org/bcd.6

sedatk 6y ago

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

mjgs 6y ago
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.
- kens 6y ago
  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 https://en.wikipedia.org/wiki/Geneva_drive
  - mjgs 6y ago
    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)
    - KineticLensman 6y ago
      > 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.
082349872349872 6y ago
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/Muenchhausen_Herrfurth_7_500x789.jpg https://upload.wikimedia.org/wikipedia/commons/3/3b/Muenchha... Are there earlier instances of this trope?

Stratoscope 6y ago

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.

accrual 6y ago
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 https://en.wikipedia.org/wiki/Multiple_buffering
prox 6y ago
You must be absolutely overwhelmed by the power of just one PC these days :) Great story!

MaysonL 6y ago

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)

meepmorp 6y ago

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.

tyingq 6y ago
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_enterprise_linux/6/html/installation_guide/s1-s390-steps-boot#s1-s390-steps-boot-Installing_under_zVM-zVM_Reader 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.
- 082349872349872 6y ago
  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".
  - skissane 6y ago
    > 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/char/src/tpc/db2z_codeptdiffebcdic.html 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.

masswerk 6y ago

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-spacewar2bsa5.html https://www.masswerk.at/spacewar/inside/insidespacewar-space...

xenadu02 6y ago

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.

colejohnson66 6y ago
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.
- the_only_law 6y ago
  iirc, the first thing it execute any sort of code is the power management controller (PMC) somewhere on the chipset.
the_only_law 6y ago
> 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.

0x0 6y ago

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

coldcode 6y ago

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.

Shivetya 6y ago
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

andyjohnson0 6y ago

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.

bogomipz 6y ago

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?

kens 6y ago
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 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.
- bogomipz 6y ago
  Ah neat. I somehow missed the clickable schematic cards. Good stuff. Cheers.

kpgraham 6y ago

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.

throwanem 6y ago

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.