Toying with idea suggested by another restorer; plug in peripheral replacements for 1130 systems

THE 1130 REQUIRES PERIPHERALS FOR EFFECTIVE DEMONSTRATIONS

The entire design of the IBM 1130 system is centered on batch processing, thus a machine which primarily reads punched cards in, processes things and produces printed output on a line printer. Several of the museums which have 1130 systems do not have the reader and printer, or they are not working, nor do they have the keypunches and supplies on hand to use these systems as they were intended. 

In spite of its disk based monitor system (DMS2) the software is itself constructed around the concept of reading job control languages and other data from card readers, producing output on line printers, card punches, plotters and other devices. The console printer (typewriter) is a secondary kind of device that was generally not used very often compared to the continuous use of the readers and printers. 

CONCEPT OF A REPLACEMENT

The basic idea from this restorer is to inject card images from a PC based file but using the physical card reader on their system. This works when you have a mostly working peripheral but does not solve the issue for museums that lack working readers and printers.

To accomplish this without needing the IO boxes, my approach would be to connect to the 1130 at its cable connector for the missing peripherals. The replacement would appear to be the physical card reader or line printer as far as the 1130 system was concerned, but would instead use modern file systems and storage devices to hold the pretend punched cards and to record the pretend paper output. 

HOW IT WOULD WORK FOR A 1442 CARD READER REPLACEMENT

The 1442 card reader/punch is a complex beast but as far as the 1130 cable connection is concerned, it is much simpler. There are approximately 65 signals on the cable between the device and the 1130. These are in categories:

• 12 rows of card data from reading the current column
• 12 rows of card data to be punched in the current column
• 12 rows of confirmation signals of what was punched in the current column
• Four 'CB' pulses at points during one feed cycle
• Read emitter pulse that each of 80 columns is ready to be read
• Hopper empty, Stacker full and Cover open microswitches
• Card entering punch station signal
• Two Incremental Drive pulses indicating movement of card in punch station
• Two punch 'CB' pulses for each of 80 columns
• Trigger feed, read or punch
• Busy status
• Select alternate stacker
• Motor controls
• Pushbuttons (Start, Stop, Non-Process Runout) and lights (Power, Ready, Check and other errors)

The replacement device will generate the appropriate CB and emitter pulses at the proper timing when the device has been requested to do a feed, read or punch. It will present the state of the 12 rows (holes) then emit a pulse to have the 1130 pick up the data. On punching, it will grab the 12 rows of data for each column to save on the replacement device, then echo back the value to indicate that the punching worked properly. 

Feed CB pulses, microswitches and other pulses generated by the replacement device will show the card moving through the 1442. Any lamps to be illuminated on a physical 1442 will be shown on our replacement device. We can send a pushbutton signal for Start, Stop and NPRO from the replacement device.

This will cause the controller logic in the 1130 to believe that it is controlling a physical 1442 and that successful reading and punching of cards has taken place. All works normally for the 1130 system. 

The data that will be passed into the 1130 upon reading or captured from the 1130 upon punching is stored recording all 12 rows of data for each of 80 columns, thus ensuring it handles any kind of binary as well as Hollerith format. The data is stored compatibly to the format used by the DeckView program written by Brian Knittel as part of his IBM 1130 simulator, thus these files can be interchanged between simulators and the real 1130. Deckview will show the 029 keypunch glyph on the top of the card image when viewing a card, in addition to the actual holes punched. 

A USB memory stick with a card file having a specified name can be inserted into the replacement box, just as a stack of cards would be placed onto the input hopper of the physical 1442. Once must supply blank card images on the USB stick the same way that an operator must load blank cards before doing an output only job. Any punching will update the cards just as would occur with an actual 1442, since programmers can read certain columns of a card and then punch data in different columns immediately afterwards. The restriction is that punching must start in column 1 so the data being read has to be in higher column numbers. 

Physically I envision this as a small model of a 1442 with a USB slot on top for the input hopper. It would have the lights and pushbuttons that look like the physical reader. Perhaps the USB card would have a 3D printed cover that looked like a stack of cards. 

Image copyright The National Museum of Computing, UK

A companion application would look like an 029 keypunch and allow creating and editing cards in the files. The files on the USB stick might be named hopper, stacker1 and stacker2. 

HOW IT MIGHT WORK FOR AN 1132 PRINTER REPLACEMENT

The 1132 uses 120 spinning print wheels that have 48 character positions around their perimeter, all wheels moving together continuously. When a user starts a print operation, the 1132 raises a signal when each new character is about to move in front of the ribbon and paper. It also sends a bit pattern that represents the particular character which is arriving. 

The printer hardware waits a fixed period of time, allowing the software on the IBM 1130 to read that bit pattern then set up a hardware scan buffer in memory with a 1 bit for every print column that contains the character that is arriving. This buffer is fixed in locations 32 to 39, which covers the 120 columns plus the final bit is used to let the printer detect when the software had not finished setting up those bits in the buffer before physical printing began. 

When the software was interrupted due to a new character arriving on the wheel, once it grabs the character code it should turn off the final bit in the hardware buffer. Once the software has set all the bits in the buffer for columns containing that character, it turns on the final bit. The printer would fetch the eight words of the buffer one by one to select the columns it will print; if the final word's final bit is not a 1, the controller logic in the 1130 takes the printer out of ready and signals a 'scan check' error condition. 

Our replacement will model a wheel rotating at the 150 rpm so that each character takes a bit over 8.3 milliseconds to arrive. Thus when commanded to start a print by one of the signal wires begin activated, we will send the interrupt signal every 8.3 ms and encode the proper character bit pattern on eight wires. The 1130 delays for 1.78 ms to allow the preparation of the hardware scan buffer before it begins sending the buffer words to the printer. 

The printer is sent 16 bits representing one word of the buffer plus a eight print group lines that tell us which of the eight buffer words we are receiving from the 1130. We use this to insert the character into any column where a 1 bit has arrived from the buffer. When we have processed the final word of the eight from the buffer, we have completed adding this character to the print line we are building up. 

Thus when the print gate signal is activated, we clear our print line in the replacement device, begin sending the print wheel characters every 8.3 ms and receive the buffer words for each character to insert into the columns of the print line. When the print gate signal is dropped, because the print line has been completed, we capture that line and go back to waiting.

The paper movement is generated by one of two signal wires from the IBM 1130. clutch or interposer, which either cause a one line space of the paper or start the paper skipping up. Our replacement device will emulate the carriage control tape of the printer, which is a paper band with twelve columns along the length representing printer channels 1 through 12 although this printer only works with 1 to 6, 9 and 12. The band is taped into a loop and is mounted on the physical 1132. 

The printer can be set for either 6 lines per inch or 8 lines per inch spacing. The carriage control tape will move at 60 or 80 positions per second while skipping, thus our replacement device sends the carriage pulse once each 12.5 or 16.67 milliseconds representing the movement of one line. Spacing down one line takes the same time as during a skip. 

Our replacement device will have a carriage control tape stored in it, with holes in the columns and enough rows to emulate the longest paper length. Typically forms have 66 lines on them, but could have about 90 when in high density (6 lpi) mode. We track where we are on the continuous loop tape and send the proper hole bits for channels 1, 2, 3, 4, 5, 6, 9 and 12 for each row (line). 

In general, it is up to the software to determine when to stop skipping. When the interposer signal is dropped we stop at the next line (row) of the simulated tape. We capture a blank line for each row/line we pass as the printer spaces or skips. The carriage restore button, however, skips until it finds the next hole in channel 1 of the tape. This is done by the 1132 hardware thus we must pad blank print lines down to the point where we have a hole in channel 1, rather than waiting for the software to stop the skip. 

This replacement device will communicate over a USB serial link to software that runs on a personal computer. The software on the PC or Mac will be capture the output into an ASCII file. That software will also transmit a carriage control tape image down to the replacement device in order to control skipping and carriage restore operations. 

It is common for programs to overprint with an 1132, that is to send multiple lines of print without spacing or skipping the carrier to move the paper. This has to be addressed somehow in the captured file. Also, we need to show the fold lines of the paper which is traditionally a bit above the point where the carriage control tape has a hole in channel 1, as that is the top of the form. 

I envision generating the output of the printer in postscript. It would be output to a printer attached to the device. The device would need to have a button to flush a page to see the last lines since the postscript would still be building up the page image, but that would be labeled as Carriage Restore just as on the physical 1132. 

 If I had used a standard ASCII file it cannot show the results of overprinting, instead showing only the last line printed before a space or skip. A tradition with printing on the 1132 is to watch for a hole in channels 9 or 12, which indicates the last printable line of a form, then skip to another channel before the next print operation. Thus, we can detect this pattern and do something to indicate the first line of a page such as a line of a character that doesn't exist on the 1132 print wheel. 

The viewing program could graphically set pixels for each line printed, thus showing what overprinting would look like on physical paper. It also can show perforation lines at the fanfold. Optionally it could introduce tinting to represent greenbar paper, where alternating stripes of green and white are on the paper before it is loaded into the printer. 

OTHER OPTIONS AND THOUGHTS

1 - A physical card reader, e.g. a Documation reader, could be combined with the 1442 replacement device so that actual punched cards can be read by the 1130 system. That plus the postscript based modern printer attached as the 1132 replacement would give the closest recreation of operating a batch mainframe system. 

2 - Rather than implementing these at the connectors, which requires the 1130 to have controller logic installed for each peripheral you are emulating, a design could be attached which intercepts the XIO instructions and manages core memory, interrupts and device status words, bypassing any actual device controller logic in the system. 

This requires about 76 signals to be connected onto the SLT (mother)boards but allows emulation of any device that can be installed on an 1130, not just the devices which were installed on the specific 1130 machine. The bonus is that I have already created the FPGA logic to do this as part of my SAC Emulator box I developed years ago to use with my own IBM 1130. This therefore would have the least development work involved; mainly I have to clean up the Python based GUI and make it more rugged.