12-minute Mandelbrot: fractals on a 50 year old IBM 1401 mainframe
righto.com
righto.com
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.
Is this the origin of the word "patch" in CS usage? As in, literally patching paper? Or does it trace further back to patching clothing?
Originally you programmed by plugging "Patch Cords" into field of jacks.
So to edit a program, you would swap around a bunch of Patch cords.
The term "patch cord" comes from old Telephone switch boards.
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?
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...
Would love to see the mandelbrot printout scans :)
Generated with a Commodore 64, output on an Epson RX80 dot matrix printer, circa 1986. All coding credit to my genius brother!
Do you and your genius brother still write code?
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 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.
"(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!
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 wish I'd had similarly inclined peers at the time. We could have totally geeked out. But I was the only one I knew.
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.
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.
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..
[1] http://www.usinflationcalculator.com/
[2] The Interface: IBM and the Transformation of Corporate Design http://www.amazon.com/gp/product/0816670390/ref=as_li_tl?ie=...
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.
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.
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!
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.
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.
The 1403 was quite an engineering marvel. Lower case, Upper case, many odd characters.
There is in fact a book published that was masterd by 1403 by David Grau, I believe.
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.
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.