I worked as a paid programmer on card systems in 1970. I'm not saying things were better then. Give me C++ and Python any day over Assembler.
However, there was something magical about being able to step through your program one instruction at a time using a switch on the control panel, or being able to display and modify the memory with lights & toggle switches. It was like you were reaching right into the soul of the machine, in a mysterious world.
Compilations were so expensive (40 min. for a 4,000-card program) that we would often patch the binary card decks to squeeze one more test.
We had to segment our programs into "overlays" that would load consecutively, and re-use the same limited memory locations. What a pain :o)
Having dealt with index registers in Assembler, C pointers were a cinch.
I enjoyed that story; my father could have written it, although at a large railroad as the setting. As per the very end of the story, lets just say it was into the 00s before we ran out of what seemed to be an infinite supply of bookmarks and art project stock paper.
I distinctly remember as a kid watching the first star trek movie on TV on a VCR tape and making a shoebox sized model "Enterprise" out of many used punch cards and about a roll of scotch tape, although that was hardly the only art project or whatever using punch cards.
I would say by the 90s the very concept of a punch card had pretty much disappeared from the general public conscious and general public people were mystified what my bookmarks were, what is that peculiar artifact I'm using as a bookmark?
"However, there was something magical about being able to step through your program one instruction at a time using a switch on the control panel, or being able to display and modify the memory with lights & toggle switches."
Access to the hardware.
Would have killed for this as an undergrad, typing up 200 line FORTRAN programs via a IBM card punch type-writer. One mistake and you were back to the comp-centre to re-type of fix the card to resubmit the batch. ~ https://www.flickr.com/photos/bootload/tags/punchcard
(A K Dewdney's columns were always fantastic - a whole new world of wonder for early 'home computer' users!)
After careful study, my brother coded it in assembly on a C64. We both had the idea to double the display resolution (from 320x200 to 640x400) by 'extending' the screen into RAM. After leaving the computer running overnight (often longer), we eagerly came the next day to check progress, and dump the output to a dot matrix printer. We couldn't use color or even grayscale, so black and white stripes were the only option to reveal the glories of the Mandelbrot set.
Result: stunning, finely detailed, black and white images! I still have the printouts...
I learned about the set in '87 or '88 and wrote a BASIC program to calculate it on my Apple IIe using the "obvious" algorithm.
I left my computer on overnight (I had no idea if it would overheat). However, even after a day, it hadn't even got to the interesting parts of the set- it was still off in the big bands of constant color around the set.
When I got to college I had a PC (a 286 with no floating point hardware) so I ran FRACTINT. It was great, fast, and fun. Eventually PCs got hardware floating point but by that time, few people were really exploring fractals.
Yup: 36 hours on a BBC B+ micro for monochrome mandelbrot. I used to leave it running over the weekend, and tried zooming into various parts of the set over some weeks. I used to photograph the monitor, and I'm now searching for the negatives...
"(Up until 1971, British currency was expressed in pounds, shillings, and pence, with 12 pence in a shilling and 20 shillings in a pound. This makes even addition complicated, as tourists often discovered.)"
Just after I had learned to add and subtract pounds shillings and pence, they went decimal! Ha!
I wrote something similar in Apple ][+ Basic. It had a cool optimization: it would scan 16 points around the boundary of each 64x64 pixel block, and if they were all-black (in the set) or all-white, it would assume the rest of the block was the same and finish quickly. My dot-matrix printer had something like 2000 pixels of width and limited-only-by-patience height, so the printouts were amazingly detailed.
I wish I'd had similarly inclined peers at the time. We could have totally geeked out. But I was the only one I knew.
Edit: the wording "assumed" led me to interpret that you didn't know about this mathematical property, but perhaps you did!
You almost hit upon a real property of the set, namely that if you can find a closed contour of the interior, all the enclosed points are in the set...
A common variant of your approach, then, was to quad tree the area of interest and evaluate the boundary of each square, if it was consistent you just fill in the block, otherwise subdivide. This is a massive speed up for locations like the canonical initial view with large areas of the set shown...
... Of course the problem with this is you are sampling discretely, so inferring that the boundary is closed because a sampling of it is doesn't really work. Your filling in of the white blocks like this is particularly problematic, as that can easily cut off "children" in the set.
You can do this sort of approach properly, but it is a bit more complicated.
I haven't been active here, but have an account so I thought I'd chime in (being "the brother"!)...
That was great fun back then and I was (and still am) a total geek. I called the various programs "routines" back then, as they were commonly known.
There was a "plot routine" which would plot points in monochrome or colour, either on screen or on the virtual screen (i.e. the 32Kb of memory that included and went "past" the screen in RAM). The plot routine used fixed point math, which I coded in a separate portion, so was as precise as I wanted it to be. I forgot what that precision was now, but it was something like 4 or 8 bytes.
Then there was the "print routine" which took that memory and output it to the printer.
Finally, the main Mandelbrot/Julia routines were done using a direct translation of the A K Dewdney articles.
All the assembler code was written in a notebook and debugged by hand before even entering it, which was done in the Zeus Assembler. Would be cool if we could locate the notebooks. At least we have the 6510 source code.
Thanks for posting this fractallyte! We're separated by an ocean, so I'm glad I can see this digitised.
To answer you dang (first, I don't consider myself that), I work as a consultant currently writing C#/.NET code for a large corporation. But hopefully one of my side projects (using various other technology stacks) will pan out one day, and I'll be able to escape, like many of us here dream about (and many have already achieved) :)
I hope you do and also that you continue to participate on Hacker News. Between kens outdoing himself with the wonderful OP, and all the other historical contributions here, this has my vote for the best HN thread in quite a while.
Sorry, what I mean to say is: if you happen to have those printouts somewhere convenient, I would love to see what a 1980s assembly language generated, dot matrix printed Mandelbrot set looks like.
I recall writing a mandelbrot program on my Casio (in the awful Casio basic) in the late 90s, after reading Ivar Peterson's "The Mathematical Tourist" (actually started with Sierpinski Gasket variations, as that is much easier, not to mention faster). I was wondering how he managed to do it in 12 minutes on such an old machine -- until I realized he only checked 24 iterations. I believe I started at a 100... and it took ~6 hours to run (more than the time from lunch until I got home, anyway...).
I used the inflation calculator [1] to convert 1960s prices to today's dollars:
- Rental price: ~$20,000 / month
- Purchase price: ~$1,000,000 (yes, a million dollars).
So what you're looking at is what used to be a million dollar computer. You could buy a car for every month you pay to use this machine, so you better had really useful programming ideas or it's back to pen & paper :)
As the author points out, this was considered the model T of computers because of how affordable it was compared to what sold before.
The attention to detail is tremendous.
I never paid much attention to the design of old IBM mainframes, but now I can see how profoundly it influenced our perception of computing. I love the author's phrase "inherent drama of computing." and how it became a trope. The IBM industrial design book [2] he recommends is now going on my to-read list..
I'm glad someone reads my footnotes :-). About the rentals - most customers rented instead of buying. This had a huge effect on computer companies. Starting a competitor was extremely capital intensive since you had to build the computers up front and then you got revenue monthly, rather than from big sales. Rentals also made IBM conservative since they didn't want to introduce a new machine that would obsolete all the old ones they were still renting out.
As for the design book, I only recommend it about 50% - it has a lot of academic theory that HN readers may find uninteresting. It also goes into great detail of the architecture of IBM buildings. Not to discourage you but just set expectations.
We employ z, i, and p, series systems from IBM currently. The biggest costs these days have become licensing software and site costs; power, cooling, site to site comm, and space. The number of languages used across all platforms is varied and well represented. There will always be a lot of business use for large hardware and even languages I thought long past their prime have had enough enhancements they blend the best of the old coding with the newest.
There's always something to repair - the 1401 restoration team (consisting of retired IBM engineers) is at the museum every Monday doing maintenance. The computers work most of the time, but the card readers take a lot of adjustment and they are still trying to get all the tape drives operational.
One nice thing about the 1401 is the gates swing open for easy access to the circuitry for hardware debugging. This picture from Wikipedia shows what debugging looks like, with an oscilloscope hooked up to the 1401: https://en.wikipedia.org/wiki/IBM_1401#/media/File:IBM_1401_...
The museum has a cabinet full of SMS cards, so if they find a problem, in most cases they can swap out the bad card. The card can then be fixed, usually by replacing the bad transistor.
At the start, fixing all the bad transistors was a huge problem, which is why it took the restoration team 10 years to get the 1401 running. The German machine in particular was a problem because it had been stored in an unheated garage for a decade, so there was a lot of corrosion. Some of the transistors would literally fall apart if you touched them. (This is what I'm told - I wasn't part of the restoration.) The other complication with the German machine is it included the "overlap" feature, which allowed overlapping of reading, punching, and computation for increased performance. A nice feature, but it made it much, much harder to figure out what was wrong.
This is fascinating. While I have a soft spot for old computers, I don't think I would put that much time into such a project. I do admire the author's determination, though! I imagine it must have been a lot of fun and thoroughly enjoyed reading about it.
Just the other day, I was talking to one of our automation engineers on the phone, and while waiting for his computer to reboot, we talked about old hardware. He told me how, as a student, he sometimes had to write programs in FORTRAN, and how punched cards were kind of, eh, expensive[1], so the students were all kind of happy when somebody hooked up a paper tape reader to the university computer. Until, that is, they realized that paper tape - at least the paper they were using - was kind of prone to tear, and sometimes students would get their programs back in pieces.
I feel nostalgic about this era I did not see for myself, but I also appreciate today's computers being cheap and - for most intents and purposes - mind-bogglingly fast.
EDIT: Also, it is fascinating how the 1401 was simple enough that one could get to know each part of it so intimately, from the software running down to the individual pieces making up the processor. On today's computers, where even the keyboard controller is probably more complex than the entire 1401, this has become pretty much impossible.
[1] This engineer is from Eastern Germany, and I know that, for example, audio tape was fairly expensive over there. But punched cards, made out of paper? And keep in mind, this must have been at least around 1980!
This article and its footnotes constitute the best summary of an IBM mainframe computing environment I have ever encountered. Have occasionally tried to read the old reference materials but they were never remotely this cogent. He also makes good use of modern context, since we have now settled on fundamentals such as word length, binary encoding, and so on. A masterpiece in miniature.
However, I think the 029 keypunch didn't overlap the lifetime of the 1401, but I could be wrong.
The other marvel of the day was the 1403 printer, which had a lifetime that went long beyond the 1401. It was a bit noisy, and the cover you see in the photos there did serve as a pretty good damper.
However, when I did a co-op at IBM in Portland Oregon during my engineering studies, they had a 1403 printer hooked to a 360/30 printing library catalog cards. There was a roll of card stock feed by an automatic feeder that set perhaps 5 feet from the printer. It would feed more stock from the three-foot diameter roll when the printer pulled the paper out. The length of card stock between the printer and the feeder served as a very effective sound amplifying board causing quite a racket.
You are correct about the 029. However in the 1401 machine room at CHM there is an 026 which was the correct keypunch for the era. OP could have used that but would have had to punch it manually -- not fun! The 029 used is, as noted in the article, relay-driven from a USB port, so he could just dump the working executable from the simulator.
Of course for full authenticity he SHOULD have manually punched the source deck on the 026, fed it into the 1401 for assembly using the 1402 reader, and had Autocoder in the 1401 punch the executable deck on the 1402.
Obviously the 029 keypunch overlaps the lifetime of the 1401 since they are both still working :-)
But seriously, the 029 was introduced in 1964 along with the IBM 360 mainframe, while the 1401 wasn't withdrawn until 1971, and some were used long after that, so they had plenty of overlap.
You're right that the 1403 printer is pretty cool. One interesting thing is it has a hydraulic pump running the paper feed, so it can skip lines very rapidly.
And the disk drives on that 360 had hydraulic actuators to move the heads. Was that the 2301 or 2311 disk, or something else? Where I was in IBM Poughkeepsie we kept our programs on removable disks of somewhere around 16 in. in diameter. I don't remember the capacity but it was in MB. At the end of the line of disk drives sat our 029 card punch. I spent way too many hours at that punch because my fingers were so inept. There was no backspace 'cause you can't unpunch holes.
We used a card based program to modify the code that accumulated on our personal disk as ISAM data sets. I set that up for my department after dropping and bursting open a very long portable card carrier (of mostly unsequenced cards) that was used before my 1967 "innovation." :-)
What shocks me at the moment is the incredibly clear 50 year old mental map and images I have of that machine room and the computers in it. A 360 model 50 that I primarily used. Beside that a model 40, down the isle a model 67, behind that a 7094 and further on a big ol' model 85. Across the hall a honking model 91. No 1401's in that room, however, but lots of 1403 printers.
I entered the Navy in 1967 and went to IBM 029 school in San Jose sometime in 1968. And I also took a 1401 SPS/Autocoder course at UC Davis that year. A few years later I learned BAL on a 360 and they still had 026 keypunch machines. I assume they were leased machines, so the lease price came down fast towards EOL. Then they got spray painted and leased in Africa and So. America.
However, there was something magical about being able to step through your program one instruction at a time using a switch on the control panel, or being able to display and modify the memory with lights & toggle switches. It was like you were reaching right into the soul of the machine, in a mysterious world.
Compilations were so expensive (40 min. for a 4,000-card program) that we would often patch the binary card decks to squeeze one more test.
We had to segment our programs into "overlays" that would load consecutively, and re-use the same limited memory locations. What a pain :o)
Having dealt with index registers in Assembler, C pointers were a cinch.