1970
The IBM System/3 has a special place in my heart.
Itwas the first computer I ever saw up close. It was at Evanston Township HighSchool, Evanston, Illinois, in 1970, replacing theold "unitrecord" machines that had occupied that same room just a few monthsearlier. It was a bare-bones model 10, 8k RAM,no disk drives, slowestprinter (100 lpm, I believe) andMFCU(120cpmread, 60 punch & print), and a5475 data entrykeyboardso the computer could be used as a data entry unit (IBM calledthem “Data Recorders”); they were new for the 96-column cardand held acard’s worth of data that could be edited before the card was punched.
IBMalso introduced a new card machine for the new, smaller card, called the MFCU(Multi-Function Card Unit). Machines for the 80-column card werededicatedto specific functions: reading, punching, interpreting, and sorting, but theMFCU was able to do it all.I have a lot of respect for the MFCU. It’stechnology that Honeywell tried to duplicate but did a poor job of. IBM’salways workeda lot better. For its day, it was really a cool machine, andwas very reliable. I still recall a lot about the System/3.
Iused to carry the hex nut driver in my wallet, the same size that the CE fromIBM would use to defeat the don’t-run-when-the-cover-is-upswitch insideof the MFCU. Now I could watch the MFCU run with the cover up. It was veryimpressive with its aircraft landinglight over the read station. I wasimpressed with the fact that this machine was the first to use optical cardreading instead of the wire brushes. I had selected Computer Programming for my sophom*ore year in high school out oflack of finding anything that sounded more interesting,and wasn't thatenthusiastic about the class. Things were off to an acceptable start, and I waslearning to code in RPGII. I had no ideahow computers worked and stillthought that there was some magic involved. Then one day, I had an enormousAHA! experience.I realized that computers don't do anything magical atall. They only perform one operation at a time, in sequence, one step afteranother.Only they do these operations really fast! Now it all made sense!I quickly excelled in my studies, raced through all the assignments,andbegan writing things that were more interesting. Still coding in RPGII, I wrotea clever little program that performed With only 8k RAM, RPG II became too limiting, and with no disk drive, there wasno assembler available, so once I had the instruction setmanual, I beganteaching myself machine language. I found the instruction set a gold mine ofprogramming adventures that I got totally involved in.Writing in machinelanguage requires the Components Reference Manual which describes the completeinstruction set in detail, and has a tablein the back for creating thepunch codes necessary to manually create an IPL-format card. It is a bittedious, but without an assembler,there wasn’t much alternative. Smallprograms of only a few bytes can be entered through the dials on the frontpanel with the right settingsin the I also wrote some utilities that weren't supplied by IBM, like a one-card"gang punch" program that read a card containing punchdata,then 4 more cards containing print data (one card per print line),and then punched and printed all the accumulated data onto as manycardsas followed, until the hopper was empty. With all my ambitions forfuture programming projects, writing everything in machine languageandconverting the values into the card characters got tedious, and I wanted a toolto help.
One day, he showed me a one-card program that turned the column indicators onthe 5475 keyboard into a digital clock, countingfrom 00 to 59, over andover, at 1-second intervals. He showed me the program, and before I could seewhat it was doing, he had thecard back in his pocket. When I asked himfor a copy of it, he said no. Instead, he handed me a copy of the"Components Reference Manual"and encouraged me to figure outhow to write my own.
I'd been made a lab aid by that time, which meant that I could be in thecomputer room without a teacher present, but if another studenthadquestions related to their assignment in the computer programmingclass, they took priority over what I was doing.Otherwise, the computerwas at my disposal! I was in heaven, and I spent endless hours working on petproject after pet project.
So I wrote a hex-to-IPL conversion program that read 2 cards with hex valuesand punched 1 card with the converted IPL characters.I wrote it inmachine language, by then my preferred coding "language". A friend ofmine wrote the same thing in RPGII.
It was very interesting to notice the contrast. His program was in a card deckover an inch thick, and mine was about a quarter of an inch thick.Hisread 2 cards, and turned on the processor lights (which showed addresses andsuch, showing how busy the computer was) for a secondor so beforepunching the card. Mine just read the cards in and punched the card out as fastas the MFCU could work, not even getting the
processor lights to glow at all. At first I thought it was a bug, but when Iexamined and tested the output card, I realized that there was no bug.Ihad just written code that ran very fast, without any of the overhead of theRPGII model! Once I had that program working, I used it tocreate severalmore programs that I wanted to write; I had a long list of tools I wanted tocreate and fun things to experiment with.
It wasn’t long after that that I created my IPL-to-Text converter that reads acard in IPL format and punches it out as a text card so the6-cardAbsolute Card Loader can read it in. I wrote a few larger programs,all in machine language, that required multiple cards.
Most of these I wrote in IPL format (with instructions on each card to loadpart of the program into memory and then branch to it) and intext cardformat so the Absolute Card Loader could load it. A few years later, working ata company with a larger System/3, I wrote themost ambitious RPGII programI'd ever written, to parse RPG II source code and produce a series ofstatistical reports on it.
I lost the cards for it, probably because I moved all the cards to disk anddidn't bother with maintaining the cards after that. It was easier toworkon it as a disk-resident program, but I never made arrangements fortransferring it off to another form of media, so all I have is aphotocopyof the printout.
That was back in the late 70's. Now, fast-forward to the present, 2010. I neglectedto transfer all my cards to disk and then to tape, so that Imighteventually be able to move them to my own computer. I delayed too long, and theSystem/3 shops and any others that might have beenable to read96-column cardsweredisappearing fast. I made several unsuccessful attempts to get these cardstransferred to PC-readable format,until I found the Wikipedia article"IBM System/3". I read it and was impressed with how detailed andaccurate it was.
At the bottom was a link to a website describing a System/3 installation in NewYork. I emailed the site's owner, asking if he could read my cards.Hecould not, but referred me to Henk Stegeman at this website, who was able tocomplete a project he'd been planning for a while, and then he could.Mysearch was over! Once he gave me the green light, I sent him 2 boxes of cardswith all my hard work in them. A couple of weeks later,I had all my cardsread into .txt files that my computer could read! It was interesting to noticethe contrast: 10 days to ship the cards, just a couple of
minutes to email them back to me; 2 boxes of cards (4000 cards) shipped, andall the cards fit into a .zip file not even 100k! While waiting forthecards to be read, I began work on a suite of tools that would be ableto process the "cards" once read to a flat file.
The tools included code to read cards to binary from both IPL format andtext-card format, a hexadecimal dump tool with literals in bothASCII andEBCDIC, a powerful disassembler, and a script-parser to drive them all.
As of this writing (July 2010), this is still a work in process and isn't readyfor public consumption yet. Once I had the disassembler working quitewell(much better than the Mnemonic Dump program that IBM supplied to the FieldEngineers), I decided to make the leap and build on the disassemblertocreate an IBM System/3 simulator. I began work on it, and after just a coupleof weeks of evening and weekend time, I had it working. I’ve named it “Symulator/3”.
I first got it to run some of my one-card programs, then the Absolute CardLoader, and finally I tried it on the compiled RPGII programs I had, PowerOfTwo andTrigTables.After fixing a few fairly minor issues with the simulator, I had both programsrunning! This was the realization of adream of mine from high school ofhaving my own System/3! Of course, my System/3 was a lot smaller, a LOT faster,and took only a tiny fractionof the power that the real machine took. Italso runs a lot cooler and is very portable.
One of the most amazing things that I noticed was the speed of the simulator,written entirely in C# with Microsoft's .Net framework. I thought thattheoverhead of .Net would slow things down as much as the new hardware (3GHzPentium) would speed it up. The C#source code for Symulator/3 is available on GitHub.
I decided to test the speed with the one-card clock program that my teacherfinally gave to me after I'd written my own version of the same thing.Itran so fast that I thought there might be a bug in my simulator, so I carefullycounted the repetitions of the instructions that the clock programused totake up a full second, and discovered that the simulator was working just fine.Instead of taking 1 second to get through the loop in theprogram, it wastaking around 20 or 30 milliseconds! Even with the overhead of Windows and the.Net framework, and of the simulator,this thing was moving incrediblyfast. I'd really lost sight of how far things had progressed since the early70's.
TheComponents Reference manual states 1.52 microseconds per memory fetch, whichworks out to a clock speed of just under 658 kHz. Very impressive considering that the previous generation ofcomputers, the IBM 1401 had a clock speed of around 87 kHz, and the ENIAC ranat 5 kHz. The ENIAC was an amazingmachine in its day as it did in 30 seconds calculations that took 20 hours todo manually. In theory, the System/3could do them in less than a second. 1970 I was getting ready to write my own assembler, but other things got myattention and I never got started on that project. The last card with the “E”also containeda short routine for displaying data in memory somehow. Inever used it so I don't know anything about it. There was also a 9-cardrelocatable loader that wouldload and then halt to prompt the operator todial in the address at which to begin loading the program. Once the user hadentered an address,the loader would then load the rest of the program.The 6-card loader always loaded each card's data at the address specified inthe card. Memory was not reset by pressing either “Program Load” on the front panel or“System Reset” in the CE panel. Either button would abort anyprogramrunning at the time, but “Program Load” would also initiate another boot. Sincememory wasn’t disturbed by either button, core dumpprograms could be runto do a post-mortem exam of a failed program. Each compiled RPGII program wasself-contained in a deck of cards, and had all the instruction code necessaryfor handling I/O and assisting the user in recovering from any errors thatmight occur, essential for a card-only system. I reviewed the System Control Programs Logic Manual and determined that theSystem Initialization Program performs these tasks:
I'm quite amazed with how much I still remember about the IBM System/3. I'vealmost completely forgotten everything I learned about other computersIworked on between the System/3 and Windows. I worked on the Honeywell Level/62and the Hewlett Packard HP3000, both of which I wrotesome interestingtools for. I did some machine language programming on the HP3000 and wrote acouple of technical articles for it, yet that stuff hasfaded from mymemory while the subtle details of the System/3 remain surprisingly clear. Whatfollows is a summary of some the things that I still recall with greatclarity.
When a program is first loaded, the machine reads cards in IPL (Initial ProgramLoad) format, beginning at memory address 0x0000.In this format, eachcolumn of the top tier is combined with 2 punch rows from the bottom tier toform an 8-bit byte, and the middle tier iscombined with 2 more punchrows, so that each card contains 64 bytes of 8-bit-per-byte binary data.
The first six cards contain the loader in IPL format, which is as much of an OSas the card machine had. The loader loaded itself into the bottom 256bytesof RAM, and after it had been loaded, control was passed off to itand the loader then read the cards that follow in “Text” format, in which 4punch columnsare compressed into 3 binary bytes by means of a verywell-engineered data management algorithm. It transformed 4 x 6 bits BCD into 3x 8 bits binary.
The text cards began with the character “T”, and the last card beganwith an “E”. This last card has a different format that instructs theloader to branch to theentry point of the program it just loaded. I stillremember this because I bought the manual on the loader and reverse-engineeredit to so I could write amachine-language program that would read anIPL-format card and punch out a text format card. I was really proud of thatprogram.
The relocatable loader would add the address value entered by the user to thataddress, and then load each card's data to the calculated address.
It was supplied with some of the IBM programs for the Field Engineers to use,like the Mnemonic Dump program (disassembler) andTrace (sort of likeMicrosoft's early non-GUI debugger for C and assembler debugging). Trace wouldsingle-step through a program,displaying the register values affected byeach instruction. Once a program ended, the next program was run by placing thecards into theprimary hopper, and pressing “Program Load” on the frontpanel, which initiated a boot all over again, reading the first card in IPLformat intomemory address 0x0000. Each card program had the same first 6cards, which were the loader. In essence, each program was its own OS,andeach program was run by booting the system. Without a disk drive, there wasn’tany place for the OS to reside.
The card system OS was a very interesting thing. Since there was nocontinuously available online storage on a card system from which theOScan be refreshed, the OS was only in the compiled programs, but theyrequired some initial values to be present in memory.
When the machine is first powered up, its memory is blank. The first thing thatneeded to be done was to run the SIP, System Initialization Program.TheSIP is not a program loader or an operating system, just a program that runs tocompletion and halts like any other.
1.Initializes the system date, storage size, and chain image fromcards
2.Initializes the copyright area to blanks
3.Initializes RAM to blanks from the first byte after the programimage to the highest address as indicated in the card input
4.Gathers & records error data captured by the IOCS (for anyprograms run after power up and before SIP was run).
Iwrote a little one-card SIP sets the memory size and printer chain image inmemory. I used the smaller 48-character chain with all capitalletters,which is the image that was used at the high school. The Greg.
The other chain image was a 120- character image, which is more characters thanin the card character set. On a system without a disk, eachprogram runsto completion, then finishes with a Halt instruction that illuminates the 27-segment displays on the front panel with a code thatindicates the statewith which the program ended. “EJ” was thehalt displaythatindicated that a program ran successfully.
It stood for “End of Job”.
The compiler existed not as a huge single program, but as a series of smallprograms, each tailored to perform a specific step in the compilationprocess.
One stage read in the source code header card. Another read the filespecifications and others read in the other sections of the source code.
Other sections performed various diagnostics and were responsible for printingout specific warnings and errors.
The cards in the second box worked the same way, and each section wasresponsible for punching out various parts of the object deck,like the6-card loader, the card and printer I/O routines, and various parts of thecompiled code.
Except for the last sections in each box which ended in one halt or another,each section ended by initiating the load of the next section.
It was a very cleverly implemented system that worked very well within thelimitations of a card-only system with only 8k of RAM.
