Organized the diagnostic card decks that come with the IBM 1130 and archived them online

DIAGNOSTIC PROGRAMS SUPPLIED WITH THE IBM 1130

IBM produced a range of diagnostic programs used to test the 1130 system and its attached peripherals. They are intended for use by the Customer Engineer (CE) who services the hardware but can be run by the owner/user as well. These are documented in four large binders, with the assembly listings and user instructions supplied for each of the decks. In addition, a set of the object modules are delivered on punched card (or paper tape for a readerless system). 

MINIMALIST PROGRAMS

There are a set of seven 'one card' programs. Each is loaded using the Program Load button (boot procedure) and accomplishes some very tiny checkout of the system. Assuming that the machine is healthy enough to access memory and to read a card and begin execution, these can be used to progressively verify the state of the machine prior to running the full function diagnostic programs.

As an example of how little is accomplished per card, here are the capabilities tested by each card:

1. Tests MDX branch instruction and ability to load accumulator register ACC from IAR
2. Tests a one word addition and ability to increment index registers
3. Verifies BSC Z, SRA 1, EOR, LD, STO and data movement between registers
4. Verifies long format LD, STO, EOR, LDX and A, plus adding pos and neg numbers
5. Accesses memory locations x0050 to x0FFE
6. Verifies that CPU interprets simulated Device Status Words (DSW)
7. Verifies load and add doubleword instructions, then loops on XIO for scope testing

The system also provides a set of single bootable card scope loop program that repeat actions allowing the use of a scope rather than a logic analyzer to see system operation.

PERIPHERAL AND FUNCTION TESTING ROUTINES

Each device or major function has one or more test programs used to validate their proper behavior or in some cases to adjust them to operate well. 

• Console keyboard and printer functional tests
• Low range core memory functional tests
• High range core memory functional tests
• Billing meter functional test
• CPU instruction functional test
• 1132 printer functional test
• 1442 card reader/punch functional test
• Internal and 2310 disk drive functional test
• Interrupt functional test
• Core storage adjustment program
• Disk drive adjustment program
• 1442 reader timing adjustment program

LOADERS AND MONITORS

There are four types of loadable card decks. Single card, basic loader, relocatable loader, and those that load under a monitor. 

The 'one card' diagnostic deck has each card in the format used for loading via the Program Load button. This boot process uses an oddball method of loading the first 80 words of memory with the data on the cards. 

Since a word in the 1130 is 16 bits but a card column is only 12 rows of holes, some bits of the word are either set to zero (three of the bits) or in one case, two bits are loaded from a single row. A part of each such card involves modifying the data in memory to produce the intended final instruction before it is executed - restoring the 3-4 bits that are not loaded properly by the boot process. 

Some fundamental tests are loaded by using the basic loader first, which in turn reads either the CPU functional test or the Interrupt functional test and executes the test. 

A relocatable loader will load a few tests that may be run on a system that isn't fully healthy, thus they minimize the footprint of capability required to get the diagnostic running. 

• Core storage function tests, low and high range
• Core storage adjustment program
• Billing meter function test

The relocatable loader also loads some SCA monitoring programs. Its final and important use is to load either the diagnostic monitor or the DIMAL program. 

DIMAL lets you set up a diagnostic disk cartridge with the routines such that you can run from the disk and operate various functional and adjustment tests. After initializing a blank cartridge, DIMAL is booted using the relocatable loader and followed by all the decks of the function and adjustment tests you want included on the pack. 

The DIMAL process produces call cards and methods of booting specific routines from the diagnostic disk cartridge. One can then run a sequential set of tests, randomly selected tests, or specify individual tests to run. 

The diagnostic monitor is loaded into core using the relocatable loader and then the chosen functional or adjustment programs are loaded by the monitor. It runs and allows the CE or user to select the tests to run, loop them and controls which test to execute. These are all loaded ad-hoc from the card reader, as contrasted to DIMAL which loads tests from a disk cartridge. 

PROGRAMS NOT SHIPPED IF PERIPHERAL NOT INSTALLED ON THE SYSTEM

Since my system did not have these attached, I did not receive card decks for the 1403 printer, 2501 card reader, 1134 paper tape reader, 1054 paper tape punch, Synchronous Communications Adapter (SCA), 1627 plotter or 1231 optical mark reader. The binders include the documentation thus one could resurrect the decks if necessary.

Restoration of 1053 Console Printer of the IBM 1130 system is nearly complete

 DISPLACING GUMMED UP OLD LUBRICANTS

The major challenge for any IBM Selectric based machine is the lubricants that were used in the 1960s and 1970s. They turn to sludge, absorb dust and harden in place. The standard way to deal with this is to dunk a mechanism in a solvent bath, then reapply oil or grease at the relevant points. 

The I/O Selectrics, those with microswitches and solenoids to allow them to be controlled by computer, pose an added challenge. those electrical parts need to be removed before a solvent bath, which is a labor intensive process that must be followed by a total reset of all the adjustments. 

However, I make use of my secret weapon. Nye #80 clock oil is so light that it seeps between the gunky materials and the metal parts, floating them away and restoring movement. It doesn't take long - drop on some of the oil and move the parts for a few minutes until they are turning freely. 

EXERCISING FUNCTIONS ON BENCH

I have the typewriter mechanism out on a workbench where I can run it under motor power as well as with hand cycling. The functions can all be triggered without connection to a computer. The 1053 was built with three buttons on the front to activate the Tab, Space and Carrier Return functions. 

The solenoids for computer commanded motions such as space, backspace, tab, line feed and return have links to the mechanism that can easily be tripped. Finally, the seven solenoids that trigger printing a character can be pushed to activate the mechanism. 

Those seven solenoids select the chosen tilt and rotate position, plus when one or more are triggered it fires off a cycle of the print mechanism. Two signals allow selection of the four horizontal bands which are chosen by tilting the ball mechanism. Four signals allow selection of direction of rotation and which of the 10 vertical columns of letters are selected on that hemisphere of the typeball. 

An additional Auxiliary trigger is provided because there is one character position on the typeball that is reached with all the other solenoids left unselected. That is, the tilt tier encoded by 00 and the rotation column encoded by 0000 is a valid character that could be printed. In order to fire off a print cycle, since none of the other solenoids are activated, the Aux solenoid was implemented to handle this special case.

Testing rotation and tilt to chosen characters on typeball

 PLANNING TO SET UP MECHANISM TO DRIVE THIS ON THE BENCH

The solenoids that shift to upper or lower case, select the character to print, command returns, line feeds, spaces, backspaces and tabs, as well as choosing between the black and red section of the ribbon, are all fed with common +48V DC and the other side is pulled to ground by a transistor to activate the electromagnet. 

I can create a quick and dirty method of triggering these functions by jumpering the solenoid(s) I want to trip to a common ground and then blipping the 48V on for a short interval. The only reason I haven't done it already is that I don't have a handy 48V supply with enough oomph to handle the current of up to six simultaneous solenoids. 

While I can fire off the movement functions with the motor spinning, it is too hard to push a combination of seven solenoids simultaneously and for a brief moment to fire off selection of one character. I can use the hand cycle wheel to select the solenoids by hand and then crank the machine to see that the proper tilt and rotate is achieved, but I would want to see this work at full speed before I was certain it was good enough to go back onto the 1130. 

STATE OF THE 1053 AS OF THIS EVENING

The functions that are working well now, both manually and under motor power, are:

• Space
• Backspace
• Carrier Return
• Line Feed

I have yet to fully test these functions, but expect that they work properly:

• Shift to upper case
• Shift to lower case
• Shift to black ribbon half
• Shift to red ribbon half

The case shifts will be easy to validate, but the ribbon halves depend on firing characters at motor speed which I can't do with my fully manual testing methods. If I get the test mechanism working that I described above, I can stick on the platen, ribbon and some paper to test the color being typed and shift between them. 

The one function that I know is not working properly is Tab. It appears that there is a missing spring or other issue in that one function. It fires erratically from the button and won't fire at all when pulling on the solenoid link. When it does fire it resets as soon as the activation cycle is over, whereas it should stick on while the carrier moves to the right, only dropping a pawl into the escapement when a set tab position is reached. 

Fixed hot interrupt issue with FPGA box unplugged, testing 1130 instructions by hand, anomaly spotted, plus typewriter work

 LOOKED OVER MY MODIFICATION TO ADD IL0 AND IL1 SUPPORT TO SAC

I had designed and installed a modification to the Storage Access Channel feature to add in the ability to trigger requests and see the state of interrupt levels 0 and 1. The SAC as it was shipped by IBM provides access to levels 2, 3, 4 and 5 but didn't include the two highest levels. 

Some peripherals, for example the 1442 card reader/punch, make use of those levels. Since I want the SAC as a means of emulated all peripherals, for completeness I needed those levels included. After I located the appropriate pins on the SLT gates in the 1130 to trigger and view the levels, I added driver circuits in small boards I fasted under the covers. 

The 1130, like most older IBM mainframes, makes extensive use of wired-OR circuits to reduce the parts count. That method will connect several open-collector gates together in a wired junction with one pullup resistor. Any gate going active will activate the output by taking it low, thus it is a wired-OR with inverter. That makes it simple to add in my wires to the gates that drive IL0 and IL1. 

I set up a small connector on the 1130 to tie to the four added signals (IL0 in, IL0 out, IL1 in and IL1 out). When it is disconnected, as it is right now, the new circuit boards I built will pull the wired-OR low (make it on). Normally the FPGA expansion box will keep the signal low when an interrupt is not wanted, but that doesn't work with the connector disconnected.

FIX TO STOP INTERRUPT REQUESTS WHEN EXPANSION BOX UNPLUGGED

I added some high value resistors to the circuit to drive it in the desired direction, 100K in value, so that the disconnected behavior is that no interrupt request is triggered. I powered up and everything was perfect. That allowed me to turn off the Interrupt Delay switch and operate in more normal mode.

TESTING INSTRUCTIONS BY FOLLOWING TESTS FROM CPU FUNCTIONAL DIAGNOSTIC

I have binders with listings of all the diagnostic programs that are delivered with the 1130 system. Among them is the CPU Functional Test which would be a great way to check out the processor functionality. When I have the expansion unit cabled up I can boot up the diagnostic loader and run these directly from a virtual card reader, but right now I can toggle in small numbers of instructions and data from the console as a first set of tests.

The console has a rotary mode switch which has Load and Display settings as well as Run mode and others to step through execution. When in Load mode, the 16 console entry switches are used to set up the bit pattern for a word that is stored in core memory. If you push the Load IAR button it puts the number in the CES into the Instruction Address Register. Effectively, if you push Load IAR you are selecting the core location from which you display contents or load new data from the CES. 

I set the IAR to x0100 and loaded some branch instructions - Modify Index (MDX) and Branch and Skip (BSC) - to check that they worked as they should. I watched them perform properly, which also proved out lots of the processor execution control and the arithmetic logical unit. During the single stepping of branch instructions some addition is done to calculate the effective address for the next instruction to execute. 

I could confirm that these worked right and the machine was adding properly as it did the address arithmetic. However, soon the CES switches and the Load IAR button stopped working. I think that the contacts are spotty in the rotary mode switch, but it could be a circuitry failure. Something to work on next time I come to the workshop.

WORKING ON THE SELECTRIC MECHANISM IN THE 1053 CONSOLE PRINTER

I applied the clock oil and exercised various moving parts to make the typewriter work more smoothly. I This is a iterative process but over time the improvement was very clear. At this point, the Carrier Return and Space functions are working quite well, but Tab still has problems. 

If I push the rocker arm that directly triggers tab movement, the carrier zooms along just fine, but when I trip the mechanism with the Tab button or the solenoids, it doesn't latch up. That means the carrier only moves a bit during the cycle time of the Tab button but does not stay engaged to continue moving to the next stop position. 

There was a spring detached in the mechanism behind the carrier that does space, backspace and tab, so I fixed that before continuing. I owned quite a few springhooks of different sizes and shapes, but can't find them now. All I have is one with a somewhat large curved hook end. 

I need to read more about the selectric mechanism in order to understand what parts should latch the tab, as that is where I need to oil, free up or perhaps where a spring is detached. Another task to get to when I return to the shop.

COBOL issue resolved, able to load the compiler on DMS

NO PHASE BREAK CARDS NEEDED, DECKS ARE OKAY AS IS

After experimenting with added phase break cards listing the official phase numbers like 51 but receiving a sequence number error, I went back to the decks as they were delivered. I was still receiving the checksum error message that way, but it had me look over the deck very very closely to see if there were duplicate or missing cards. 

ISSUE WAS CARDS OUT OF ORDER IN SEVERAL PHASE DECKS

What I spotted were a couple of places where a few cards were out of order. The sequence numbers might run 20, 22, 21, 23, 24 . . . and I guess the checksum calculations depend on the sequence of the cards not just the contents of the cards. The deck had two different places where cards were out of order. Once I corrected that, I moved on to get the checksum error on the second deck instead. 

Out of the twelve decks, four of them had cards mixed up. Some careful examination to find them and then resequencing of the images gave me a load deck that ran through to completion with no errors. I then ran the cobol library routine loads through the system and had a DMS disk with just the COBOL compiler installed. 

LOAD COMPLETED AND SAMPLE PROGRAM COMPILATION RUN BUT LOOPED

I fired up the deck to compile and execute the sample program they provided, however the IBM 1130 simulator went into a loop partway through compiling the deck. I don't know if this is a simulator defect, something wrong with the subroutines or phases I loaded, or there may be a configuration requirement for a 32K system while I generated only a 16K computer. 

In any case, I feel pretty good about the state of the compiler cards I archived. Once I have my 1130 up and running, able to use my FPGA extender to mount the virtual COBOL DMS disk, I can try the sample program deck on a real machine to highlight where the problem lies with this run I did.

Verified cause of interrupts on IBM 1130, more indications it is in great shape, plus removed console typewriter for restoration

VERIFIED THE CAUSE OF THE SPURIOUS INTERRUPT LEVEL 0 EXECUTION

I had suspected that this was caused by my modification to the Storage Access Channel (SAC) feature to also control interrupt levels 0 and 1, allowing my FPGA box attached to the SAC to emulate every peripheral type that runs on an 1130. I added some circuitry to the 1130 SLT logic, a few small boards of my own, and a new connector for a cable to run to my FPGA box. That isn't connected at this time.

The way I designed the interface boards, absence of a signal results in triggering interrupt requests, certainly not what I want the behavior to be. I will do a quick reimplementation ensuring that absence of a cable allows the machine to work as originally designed.

My verification was to switch one of the Customer Engineer (CE) switches to Interrupt Delay. This blocks the interrupt recognition while the switch is on. In that state, I could reset the machine and step it through fetching and executing instructions cleanly. 

MORE INDICATIONS THAT EVERYTHING IS GOOD WITH THE MACHINE

I used another of the CE switches that does a continual loop through memory fetching and displaying the contents of memory. That checked all 16K words and found that all worked properly, none with a parity error. 

I did use the Lamp Test CE switch again and see that only one light is not working. It is one of eight lights reserved for CE use, meaning that you might hook a signal inside the machine to one of them in order to see its state while you are debugging. Normally, these are unconnected. Seven of the eight work fine, but the bulb for CE5 is not lighting. At this point I will not do anything as this is truly a superfluous indicator for my machine. 

REMOVED CONSOLE TYPEWRITER FOR REFURBISHMENT

The console typewriter is an IBM Input-Output Selectric, model 1053, which is a printer only typewriter mechanism that is controlled by computer. These are the console printers for many of the IBM S/360 mainframes as well as the 1130 system. Mainframe users often installed multiple 1053 consoles, such that they could print logs and provide specialized console access to the operating system. 

The mechanism is inside an enclosure that features a few pushbuttons for Space, Tab and Carrier Return, setting or clearing tabs, and 16 toggles switches called the Console Entry Switches (CES). The programmer can read the state of the CES so they are often used to indicate choices by the operator to the program. As an example, when loading the DMS software onto a blank disk cartridge, the CES indicate which drive number is the target, which is useful on systems with multiple drives attached. 

The CES are cabled directly into the SLT card cages and don't easily disconnect. I removed the faceplate and left it on the computer, thus I can still enter values into the CES. They allow the operator to load addresses and data into memory for manual operation. 

I disconnected the SMS style paddle cards that connect the solenoids, microswitches and power to the 1053. The machine was carried over to my workbench where I wired up just the 115V AC for the typewriter motor. 

I will install the paddle cards from the 1053 Emulator box which I had designed and built, so that I can run the 1130 and communicate exactly as if the console printer was installed, although the actual output data is streamed over a USB serial link to a terminal program on a PC. 

INITIAL WORK ON TYPEWRITER DEALING WITH BAD LUBRICANT

I began to add my extremely fine Nye #80 Clock Oil to the parts of the mechanism which were sluggish. Adding the oil to seep under the dry lube and moving the parts frees everything up and restores operation. It will take some time as there are many many moving parts that need this treatment, but I can start with the parts involved in each symptom I encounter.

My first work was on the Carrier Return, Tab and Spacing functions, since I can trigger them with the mechanical pushbuttons that sit behind the faceplate. I worked a while and began to see satisfactory operation. It will take some time but I hope to have this working to spec and returned to the IBM 1130 in a week or two.

LOOSE SPRINGS FOUND IN AT LEAST TWO SPOTS

I noticed a spring dangling off the return for the Tab mechanical button on the front. Later I noticed a spring that is detached on the space/backspace mechanism behind the carrier. These need to be reattached.

For some reason, I can't locate the plastic tub with all my spring hook tools. Fortunately I had one sitting in another box of tools so that I could re-attach the end of the Tab spring but I really need to find my full set. I won't attempt the spring in the space mechanism without the proper size and shape spring hook. 

TRYING TO SOLVE THE MYSTERY OF HOW IBM COBOL IS LOADED ON DMS

IBM sold COBOL as a added price program product to 1130 users, rather than including the compiler for free as they did with Fortran, Assembler and tRPG. I have the deck marked COBOL, with the twelve phases of code that make up the compiler, but I am not sure how they are installed. 

All the other parts of DMS have a phase card in front of each phase of code which includes the phase number in hex. For example, the Fortran compiler's first phase if 1F and that is what is marked on the card in front of the deck. COBOL, on the other hand, has no visible phase cards. 

However, the loader program is clearly designed to load it. The Load Mode card has a column where you specify if each compiler is loaded or skipped and the last such column gets a C if COBOl is to be loaded. The DMS system has reserved the range of 51 to 5C for the twelve phases of the compiler. 

This is why I was confused by the presence of decks without any phase cards. I tried to load it without the cards, putting the phases in the correct place in the deck right after Fortran. The first phase was read but the loader reported a Checksum Error thus something isn't right. 

I will try creating my own phase cards and placing them in front, to see what happens. I may have to try various things blindly but hopefully at some point I will get it to load and have the compiler run. 

Organizing my various DMS load decks, ready to do restoration work on 1053 console of 1130 while using my 1053 emulator box

 ORGANIZING MY VARIOUS DMS LOAD DECKS

I have several sections of the card trays that contained cards for loading or reloading the Disk Monitor System, the software that controls the IBM 1130 system. I want to get the digital versions organized so they can be run on the IBM 1130 Simulator and work properly. 

There are also three other compilers besides the Fortran and Assembler code that is installed with almost every system. These are RPG and COBOL from IBM and the DNA Systems RPG II product. I want these organized and prepared for those who want to produce a DMS disk including those compilers.

I need to separate all the decks into each individual phase, 123 in total just for a system with Fortran and Assembler. This allows me to easily spot decks at different modification levels, for when the user is creating a V2 M11 versus a V2 M12 system. This is a tedious process to accomplish manually, opening large files and repetitively saving and trimming files to store each individual phase. 

IBM 1130 CONSOLE TYPEWRITER NEEDS SOME TLC AND RESTORATION

When I power up the IBM 1130 system, the console typewriter begins to take continual operational cycles on its own. This is either due to some spring coming loose or, more likely, the old lubrication having gummed back up over the time that the machine sat idle. 

I now have all the proper tools to completely adjust the selectric mechanism, items such as spring scales, Hooverometers, hand cycle tools, dynamic half cycle tools, spring hooks and all the special wrenches. Coupling that with my miracle Nye clock oil that will seep between surfaces and the old IBM lube, I should be able to get this typewriter humming.

INSTALLING MY 1053 EMULATOR BOX IN PLACE OF THE SELECTRIC CONSOLE

Since my typewriter will be out of the system, I could use a substitute to receive typed output from diagnostics and deal with interactive requests from applications. Fortunately, I had built a 1053 substitute years ago, centered on an Arduino with appropriate level shifting interface circuitry, that will communicate over USB serial to a PC to display the output. 

It has the three buttons that sit on the front of the 1053, plus the set and reset buttons for setting tabs. A set of 7 segment displays show the current column. Thus, this allows any action that could be performed with the actual Selectric printer. It connects via the SMS paddle cards into the connectors inside the 1130, just as the actual 1053 would connect.

1053 Emulator Box

IBM 1130 light panel wired up, powered up and okay at first cut; my DMS load deck isn't complete (yet)

WIRING MY MODIFIED LIGHT PCB INTO THE 1130 DISPLAY PEDESTAL

Because of the clunky design of the lighting components inside the 1130's display pedestal, replacing incandescent bulbs is very labor intensive, tedious and causes much frustration. To do away with the frustration, I designed a new approach to host the bulbs and circuitry that would allow for relatively quick and easy replacements.

The entire back of the honeycomb which houses more than 150 bulbs is covered by a single large PCB. it has sockets at each lamp location where I can plug in, and therefore replace, lights. The back of the PCB has the SCRs and wiring, plus the pins where each system signal is connected to drive its lamp on the display. 

I did extensive testing of this back in California, but not on the 1130 itself. I used a high current 7.5VAC transformer and wired up circuits to appear to be the Lamp Test and signal inputs. I was satisfied that all bulbs would light with Lamp Test switched on, as well as having the lamps individually controlled by SLT logic levels on the input pins. These levels swing between 0 for off and +3V for on but have a threshold for valid off and on values that I also had to honor. 

I had this temporarily mounted to the back of the honeycomb, then cut and connected power leads to bring the lamp test signal and the AC power from the terminal strip in the pedestal to my PCB. Once that was done, I thought it wise to test without having all the precious logic signals wired in, lest something blow up dozens and dozens of SLT cards.

POWER UP AND LAMP TEST TO CHECK FIRST FUNCTIONALITY

I brought up the machine and hit the Lamp Test switch. Everything was off with no logic signals connected and lit up when I did the test. I did see two bulbs that either are bent over or otherwise not lighting, but those can be handled later since almost everything else lit satisfactorily.

APPROPRIATENESS OF SIGNALS AND CIRCUITS DRIVING LAMPS

At that point, I plugged all the signals into the pins on my PCB. IBM's wonderful manufacturing practices were a tremendous help here. IBM carefully cuts all wires in a harness to their intended length and laces everything together, so that a bundle providing signals for 16 bits of a register have the pins arranged perfectly to plug in with no confusion. If this wasn't true, I might have had to beep out connections for more than 150 signals to get them on the proper pin. 

Laced harnesses make wiring easy

When I powered up, I could see reasonable and appropriate status lighting up. The machine responded to the buttons like Reset, Start and the rotary mode switch. The lamps light just as they did with the original IBM components, a key objective of my project to replace the lamp components. 

Running under Interrupt Level 0

MUCH IS WORKING PERFECTLY

I can see that most of the machine is working properly, a fairly large fraction, since it will single step through instruction execution and fetch memory contents without parity errors or other issues. When I hit the Reset button, the machine quickly jumps to a high address which I believe is the resident driver code for one of the peripherals. 

INITIAL ISSUE IS DUE TO HOT INTERRUPT REQUEST FOR LEVEL 0

I can see that something has a permanent request for interrupt on IL0, which forces the machine to branch to a location and execute code. Once I quell that request for interrupts, I can hand load some instructions and begin to more fully check out the system. It does appear to have survived its trip pretty well. 

LIKELY CAUSES, NO RED FLAG AT THIS TIME

There are two possible outside elements that can be causing this IL0 request. The 1442 Card Reader, while not cabled into the machine currently, does use IL0 to read each column as the card moves it over the photocells. I also added circuits for my FPGA based extender to drive IL0, so that it could provide a virtual 1442 to read and punch card images to PC. My bet is on the FPGA connection, since I didn't hook up the cable. 

HAD NAGGING FEELING MY CARD DECK FOR LOADING DMS V2M12 WAS TOO SHORT

As I thought about having three small boxes to load the entire DMS system on a freshly initialized cartridge, I felt the size was too small. I went to the digitized file for that tray and indeed the deck is not complete. Well, more later since it is complete just not for an initial load on a clean pack. 

There were quite a few phases missing in the deck. The first phase should be DUP phase 1 followed by 2 through 17. then all the phases for Fortran, Supervisor, Core Load Builder, I/O devices, Core Image Loader, DUP II, and the Assembler. Right away, phase 1 was missing, we had 2, 3, 5, 8, 9, and 10 so quite patchy.  

THIS IS ACTUALLY AN UPGRADE DECK, TO CONVERT A M11 PACK TO M12

This deck has a Mode card with R, which is reload, which means you apply it against an already loaded cartridge to reapply the selected phases in the deck. To understand why the particular phases were there and others were missing, I opened all the phases and looked at the header card which indicates the level when it was last modified. 

I found that the phases in the deck were all the phases that were changed going from V2 M11 to V2 M12, the latest version of DMS. I then realized that this was an upgrade deck. It would take a pack that had DMS V2 M11 loaded on it and, through the reload, bring it up to full V2 M12 level. 

WHAT I PLAN TO DO IN ORDER TO SELL A COMPLETE LOAD DECK

Potential buyers of the deck may include collectors and museums who have an IBM 1130 and want to have the full deck to run on a physical system. The chance that they have a M11 pack already and just need to upgrade is slim. Therefore, I want to build this up to be a complete initial load deck.

Since the missing phases are all from earlier levels of DMS, I can grab them from any of my decks, whether for V2 M11 or V2 M12. I have several such decks and should therefore be able to find all the older phase versions in them and assemble everything to a complete, current system deck. 

IBM 1130 powers up on new 240 service, first group of cards prepared for sale, IBM 1130 Simulator issue is not a flaw in DMS

QUICK CHECK OF POWER SUPPLY HEALTH AND VOLTAGES ON 1130

Once the L6-20 outlet for 240V was available, I ran a set of checks on the various power supplies in the 1130 to be sure that it was ready for powering on. This consists of unhooking the output of the supplies from the cables that carry those voltages to the logic gates, bringing up the supplies and testing voltages.

The 1130 does its own testing of power correctness as part of the power sequencing, done with relays and testing circuits. The machine was happy with the health of the +3, +6, -6 and other outputs, thus it brought them online serially until it was complete. I too found the outputs to be right on the money. 

POWERING UP ALL APPEARS HEALTHY

After connecting all the cables back to the supplies, I plugged in the 1130 and flipped the Power On/Off switch on the console. The machine came up happy, at least to a stopped and reset state. Until I wire up the light panel I can't see the important status to be sure it is working well, but no red flags arose.

BOXED UP COMPLETE DMS V2 M12 LOAD/RELOAD CARD DECK FOR SALE

The complete set of cards to load a fresh disk cartridge with DMS V2 M12 including both Fortran compiler and Assembler takes approximately 3,000 cards. I put them in three mailing boxes, around 1,000 cards each, and got the vital statistics to calculate postage. Each box is 8 1/4" wide, 7 1/2" deep and 3 1/2" high. The weight for all three together is 15.4 pounds.

DMS V2 M12 Load Deck

This deck consists of a sequence of card files:

• one card 1130 boot loader card that will read the next card into core and execute it
• one card 1800 loader card which is executed to read the binary format of the next file
• multi card loader deck that will begin reading in the actual system loader program
• first phase of the system loader program
• a load mode card that specifies whether this is Initial or Reload and the compilers to include
• the resident monitor that manages the hardware
• the second phase of the system loader
• configuration cards that specify I/O devices and core size
• phase ID cards that tell the range of phase numbers for each component
• phases for the Disk Utility Program (DUP)
• phases for the Fortran compiler
• phases for the supervisor
• phases for the core load builder
• phases for the I/O devices
• phases for the core image loader
• phases for part II of DUP
• phases for the macro assembler
• type 61 card to end system loading
• all the key system library routines set up as DUP commands to store from card to UA

A fresh cartridge is placed in some disk drive, the console switches are set to indicate which drive number contains the target cartridge, the card deck is placed in the reader hopper, the reader is readied and then the operator hits the Program Load button. 

The deck is read and its contents are placed on the cartridge to prepare it as a DMS V2 M12 pack. When the type 61 card is reached, the system loader completes its work and it loads the resident monitor and invokes DUP. DUP then reads the remaining deck which is a series of *STORE commands and object deck pairs to build up the required system library routines in the new User Area of this system pack.

The process completes and you can then use this cartridge to operate an IBM 1130. The operator puts a one card Cold Start loader in the card reader, readies the card reader and the disk drive, then hits Program Load. The result is the booting of the monitor, an implicit JOB card is processed and some output appears on the line printer. The system waits for card decks to be placed in the reader and the Start button to be pushed to begin batch processing. 

I tested this deck on the IBM 1130 simulator. I used the standalone Disk Configuration and Initialization Program (DCIP) to format a disk cartridge image as a fresh pack. I loaded the deck into the card reader, did a boot from the card reader and watched the process run to completion. On a PC this runs much much faster than it would with a real 1130 and its peripherals. I then booted the disk and ran some work.

NARROWING DOWN THE SEARCH FOR THE DEFECT IN IBM 1130 SIMULATOR

The IBM 1130 Simulator built by Brian Knittel in part upon the simh platform is a great tool to run 1130 workloads and try out software. However, it has two well known issues that impair its full usability. One is a loop when trying to store a core image file and the other is a loop punching blank cards. 

If a job issues a DUP command to store a file as a core image format (*STORECI), the 1130 system goes into a perpetual loop, never completed nor storing the file. The FORMS CHECK light is illuminated, which is an error because that lamp means that the console typewriter has run out of paper. There is no reason that this should occur at this point.

Jobs that punch cards will punch some correctly and then settle into a loop punching completely blank cards until you reset the simulated 1130. This one is a bit more understandable because the simh handling of card reader and card punch as independent peripherals does not reflect the physical reality in most 1130 shops. Most use the 1442 card reader/punch, which has a single input hopper and single path that handles both reading and punching.

In the physical world, if you have a program that will punch some cards, you have to put the correct number of blank cards (or more) in the hopper at the appropriate point in the deck being read. Failure to get this right can result in lacing cards by punching new content atop existing holes for cards you intended to read. The 1442 simulation does not address this in accordance with the real machine, nor does it model the way the machine works even for pure reading.

When you put cards into an empty 1442, you push the start button and one feed cycle is taken to move the card into the machine at the station just before the read photocells. The next feed cycle, taken when the processor does a read, will move the card through the photocells and simultaneously feed the next card from the hopper to the preread station.

When the hopper is empty, the machine switches off ready state. The processor sees this as a not-ready reader. The final card that was in the hopper has NOT yet been read, it is simply sitting in the pre-read station. If there are more cards involved in this batch, you add them to the hopper and push Start on the reader. That makes it ready to the processor and reading continues.

If this is indeed the end of a deck and no additional cards will be added, then the operator pushes the Start button while the hopper remains empty. This allows the final card to be read but also provides a 'last card' or 'end of file' flag to the processor.

The 1130 simulator does not model this behavior. Instead, the final card is read without any action pushing a simulated Start button on the reader. That means that when a card file finished on the reader it always sends the last card flag. This makes it hard to add more cards without that status. There is a 'deck' construct in the simulator where it takes a file which in turn lists file names to put in the read, each of which is added without 'last card' flags until the final file of the deck is read. 

If you couple this behavior with the reality that after the read station there is a pre-punch stop, then a feed is needed for the card to move to the final stacker, the mismatch with the physical world gets worse. After reading the final card of a deck, accepting the 'last card' state, the operator would have to push the NPRO (non-process runout) button to move the last card from pre-punch to the stacker. 

For punching, after you read a final card such as // XEQ to run a program which is going to punch, something has to move that last card, the XEQ, past the pre-punch station before you begin writing (punching) card images. Then there must be sufficient blank cards following so that each write to the punch has a blank card in the pre-punch station ready for it. None of this is modelled by the simulator. 

I needed to be sure that the errors, particularly the loop running the *STORECI, was not due to mangled contents of the DMS image that came with the simulator. Brian did a herculean job creating that by entering all the source cards for all of the monitor, assembling every module, then preparing them in the proper format to create the load deck described above. However, it is possible that some error crept in that is the root of this loop. 

To test that, I took the load deck which I had read from my cards and used that to build DMS on a fresh cartridge. This disk was booted on the 1130 simulator but I still saw the two issues, *STORECI looping and a blank card punching loop. This tells me the issue is in the simulator itself and not the DMS. 

I now have to figure out a means to debug this and fix it, in order to have a completely usable simulator. More in the future on this. 

Tape drive talks to my P390, preparing cards for sale, and getting 240V outlet to run my IBM 1130 and Telex tape drives

CONNECTING DEC TAPE DRIVE TO P390 AND TESTING FROM A RUNNING 390 IMAGE

I intend to use the Digital TSZ-07 tape drive as a mainframe 3420 tape drive which can be accessed by mainframe software on my P390. One of the capabilities of the P390 system was the ability to map a SCSI tape drive to a 3420 inside the mainframe. 

I connected the SCSI cable from the TSZ-07 to my Adaptec SCSI card on the P390 (the xServer hosting it), booted and verified that Adaptec saw the drive. I then fired up OS/2 which hosts the P390 system, started a mainframe instance and from the configuration file discovered that drive 181 on the mainframe image was hooked to the SCSI tape drive.

I inserted by blank tape into the drive, loaded it, and made the tape drive go online. I then did an IPL of unit x181 which resulted in the tape spinning looking for data to transfer to mainframe memory. Since there was nothing written on this particular tape, it spun for a while and timed out. Still I take this as evidence that I now have a physical 9 track drive to use with MVS, VM and DOS.

SETTING UP BATCHES OF CARDS FOR SALE OR DONATION

I bought some mailer boxes that hold batches up about 1000 punched cards securely. I begin the process of loading up interesting collections of cards that I can offer for sale on eBay. For instance, I will have a DMS2 (the 1130 operating software) load deck, the various compiler load files, and several major applications ready for purchase. 

GETTING 240V OUTLET READY IN WORKSHOP

The workshop came with plenty of 120V 20A circuits but no 240V outlet. Both my IBM 1130 system and the Telex tape drives require 240V to operate. Both of them can operate using an L6-20 plug because their current demands are not very high. I am getting the L6-20 outlet hooked up and will soon be able to works on any machine in my shop.

9 Track Tape Drive passes self tests and loads tape; Continuing post processing of 1130 card decks; awaiting cards to read for someone else

 DIGITAL TSZ-07 DRIVE POWER UP AND INITIAL TESTING

I gave up on hunting down schematics or reverse engineering the power supply. I went with the simpler option of energizing it with AC while the outputs were disconnected from the tape logic boards. After that I reinstalled everything and brought up the tape drive.

I did take some time prior to power-up to use IPA to clean the heads, rollers and the inside of the transport area. Everything looked clean, free of excessive wear, thus ready to use. It runs self-diagnostics and reports what portions of the machine might have failed. In my case it came up with a clean pass of the tests. 

Drive passed self tests and is loading a tape

I then grabbed a blank 9 track tape, stuck it in the drive, and hit Load. The tape loaded, it sensed the density of the tape (6250 BPI) and correctly reported that I had a write ring in the tape. Unload also worked properly. Next up, I need to cable this to the SCSI bus on my P390 system and see whether the SCSI board can talk to the drive. 

Tape at load point and apparently ready to acces

POST PROCESSING OF A FEW MORE FILES

I spent hours organizing, splitting up and documenting all the files for the Keyword in Context (KWIC) application. This set of programs creates an index by keyword of a list of books or documents allowing someone to read the listing to find all documents that contain a given keyword. Kind of a 1960s version of Google. 

I used my program to test the sequence number fields, which proved to me that we had clean decks without missing cards or duplicates. I was able to compile all the programs, create the empty disk files, and prepared to run the sample input. I don't have any documentation on the format of data cards nor about how to operate the program, thus I had to feel my way through this.

The complete deck from IBM PID apparently had dependencies on some other package, since I couldn't execute the resulting application due to missing subroutines. This is something you don't learn until execution time for most 1130 programs, because of the way that the system works.

Compiling a program, say with FORTRAN, produces an object module that contains within it a list of external references such as subroutines it needs to call. The relocatable object module is what is stored on the disk in the User Area (UA) most times. 

When you issue // XEQ for the main program name, the Core Load Builder (CLB) component starts up and does what the 360 operating systems would call a link-edit. It links together the program with all its referenced external objects, adjusts addresses to the absolute location in core where the software will be placed, and then passes that core image (CI) format module to the loader for execution. 

It is possible to have the CLB convert an object module into CI format in advance, using the Disk Utility Program to force that link-edit action, but the resulting stored program is much larger and locked to specific core locations. If ten object modules each reference the same subroutines, only one copy of the subroutine exists on disk if they object modules are relocatable, but if they are converted to CI then there are ten copies of the subroutine taking up disk space. 

It was when the CLB got involved that I first discovered that I needed missing subroutines NCOMP and PACK. Later phases of the application also needed the subroutine UNPAC. These were not supplied with KWIC but I dug through all my archived card decks and found these in the Complex Subroutines set of cards. 

Once I loaded these subroutines onto the disk, the CLB completed and the KWIC application started up. I found that it asks a series of questions on the console typewriter/keyboard to guide execution, such as whether to preserve existing content in the keyword or book files. Once I figured out this referred to groups of data cards in the sample execution deck. I guided the application to read the keywords and the book data. There is a format card which describes which columns on the data cards refer to titles, authors, etc so that has to be loaded. 

I did get it to read all the cards and process the index, then it asked me if I wanted to print listings of the index and a report. I collected both the console typewriter and line printer output files and saved them along with the other files from PID. To wrap this up, I wrote a document describing the files and the basics of this application. 

There was another PID filed called KWIC Generator, which looked similar but smaller than the KWIC application. I began the process of verifying this on the IBM 1130 Simulator as well, getting the program to compile successfully, but this program needed to be stored in CI mode because it had to refer to a temporary disk file that was bound to the program.

Alas, there is a flaw somewhere in the simulator. Anytime you ask DUP to run CLB, it looks forever on the *STORECI command. CLB works fine as part of an XEQ but not under DUP. As a result I couldn't finish my testing of the KWIC Generator application. I do need to attack this problem with the simulator as there will be many other cases where I will need STORECI to work properly.

CONTACTED TO READ OLD SOFTWARE DECKS FOR SOMEONE ELSE

I received an email through some friends seeking some way to read a deck of punched cards for someone. While a grad student, he had written some software in Fortran that he wanted to port to modern systems today. Perfect timing, as soon as he ships them down to me here I will archive the contents and send everything back to him. As a bonus he may have some mainframe simulation software package on cards that I can also archive. Not sure if it is GPSS or CSMP, but both are modeling/simulation packages which were distributed by IBM PID (Program Information and Distribution) department. 

Example of the post-processing work for the archived card decks

SCANNED CHUNKS DO NOT EQUAL PROGRAM BOUNDARIES

When I am reading cards they are often large blocks of cards without obvious delineation. Sometimes I can tell that a we switched to a major new program, but for applications that consist of many, many smaller programs, the break between each program isn't obvious. Often the cards don't have text interpreted across the top, but even if they did it would add hours of time to the archiving effort to scan and separate a box of cards into many small decks. 

OUT OF ORDER GROUPS FOR LARGE PROGRAMS

Some large programs spanned multiple boxes of punched cards or multiple trays from the card filing cabinet. It may be that the box I begin with is actually somewhere in the middle of the program because the markings on the boxes don't make it obvious. Even within a box, I have found situations where portions of an application are grouped out of order. This is only obvious when I am assembling them after the face. 

LIMITATIONS OF THE DECKVIEW PROGRAM

The deckview.exe application can only hold a max of 2000 card images otherwise it won't display or allow editing. When I combine all the cards from a large application, they may be two to three boxes long, far past the capacity of the deckview program. 

VERIFICATION BY EXECUTION ON 1130 EMULATOR IF POSSIBLE

In order to ensure that I have all the portions of some software program, to test that it compiles clean and appears to work correctly, I need to move it over to the IBM 1130 simulator and install the software to do testing. Some errors, such as depending upon a subroutine that was not capture with the application, will only become apparent when you try to execute the load module. 

ECAP PROGRAM PROCESSING TOOK SIX HOURS OF TIME

The Electrical Circuit Analysis Program (ECAP) software represents these challenges and more, giving a picture of how much work will be involved to organize, test and document all the software I captured through this process. 

I had to deal with very large captured files, read out of order. Fortunately the programs have sequence fields in columns 73 to 80 of most cards. This gives a good picture of where each portion of a file belongs compared to the others. To do this, however, I had to deal with individual programs broken over file boundaries and overly large files. 

I whipped up some Python programs to help with all this. One program would take a large deck file, too large for deckview to work with, and spit it every 1500 cards into a new subfile. I could then open each of the subfiles and extract the contents. The resulted in 71 distinct files, each of which needed a // JOB card at the start in order to make them standalone for compilation. 

When I fired up the IBM 1130 simulator and began compiling all these individual programs, many of them subroutines, I encountered a few that failed due to compiler errors. In each case, it was due to a duplicate card in the deck. Most duplicates were on a numbered statement card, which is how the compiler saw an error, but one was a duplicate COMMON statement that caused a duplicate variable name declaration. 

I then worried that some duplicates might exist in the deck which would not cause a compile error but would cause the software to malfunction. To check for this I wrote a Python program to read each of the files and show any any places where the sequence numbers didn't advance strictly by ten every card.

I had a reasonable number of such errors flagged. One was a clear case where three cards were out of order but that was correct since they defined COMMON exactly the same as other programs sharing that space. Others were identically missing cards at the start of a comment, found across about half the decks. No duplicates were found and all the anomalies were investigated and proved innocuous. 

The deck came with a sample run, which I executed and collected the output. I am searching for the ECAP manuals since that would let me verify the correctness. If not, I have to figure out what simple circuit was input to the program and then calculate the magnitude and phase angles to check the computer calculated results. For now I will move onwards to other software but will come back if I find evidence that the results are not correct. 

Starting on Diablo disk and DEC tape drive restorations

DIABLO DISK DRIVE RESTORATION BEGINNING

I opened the Diablo drive to inspect and begin the restoration. It has no heads installed, but I have a set to put in later. I cut a zip tie that secured the rotary actuator in position for transit. Overall everything looks undamaged and ready to be tested.

I have lots of experience with the Diablo since it is used in the Xerox Alto, which I restored along with Marc Verdiell and Ken Shirriff. As part of that effort, I engineered an FPGA controller and tested it on a Diablo of my own. I also worked with drives from several other Alto systems.

IBM created the single platter disk drive in the early 1960s, announcing it as the internal drive of the IBM 1130 and then as a 2310 peripheral for 1130 and S/360 systems. The disk has a single 14" platter of aluminum coated with an iron oxide surface. The platter is contained in a plastic cartridge that is slid into the front of a disk drive. 

There is a head for both surfaces of the platter, upper and lower, that moves radially from near the outer edge towards the center hub, stopping in 100 defined positions that represent one of 200 concentric circular tracks. Thus there are 400 tracks of information, 200 per head.

The disk rotates at 1500 rpm under the heads and has eight notches cut evenly around the periphery of the central hub, delineating eight physical sectors of the track. There is also a second notch at one of the positions, called the index mark, that defines the beginning of the track. The electronics in the drive ignores the odd numbered sector marks, thus the track is broken into four logical sectors.

Each sector is a fixed length, 321 words. Since the 1130 word size is 16 bits, the capacity of a sector is 642 bytes, 2,568 per track and just over 1MB per disk cartridge. For most purposes, the first word of a sector is used to hold the sector number, thus there are only 320 words the user can use. 

The data is recorded serially on the track with an alternating pattern of clock and data bits. Each bit is created by reversing the magnetic field. There is always a reversal for the clock bit since there will always be one received, but if the data bit value is to be written as zero then no reversal is made at that time. Thus we either have a reversal to read a data bit of 1 or nothing which signifies a zero.

After the 16 data bits of a word are written, four more bits that are error correction values, a form of parity, are written. These check each group of four bits in the word for validity. The beginning of a sector consists of a string of 0s (clock bit but no data bit) then a special format word to indicate that the next 20 bits is the first word of the sector. After the 321st word there are more zeroes written. 

The disk hardware will get into sync with the train of 0 words at the start of the sector so that it knows which magnetic reversal is a clock bit and which are data bits. The drive splits these out and sends clock pulses on one signal wire and data bits on another signal wire when the data value is 1. 

The disk hardware also sends the index marker pulse once per rotation and the four sector markers at the time of each of the four logical sectors on the track. It will switch to write mode if the control signal into the drive is set. It has another control signal that will activate the erase coil in the disk head, removing the previous magnetic reversals to allow for reliable clean writing to occur.

Writing uses a single line that has pulses for both clock and 1-valued data bits combined, unlike reading where the drive has separated clock and data. Thus, the drive is given the correct string of pulses to reverse the magnetic field of the write coil. 

There is a signal from the drive when the actuator is retracted to the position for the first track, called the home position. Moving the actuator is requested by control signals to the drive. The direction of movement is specified (inward towards track 200 or outward toward 1), the size of the movement which is one track or two, and an activation pulse to command one movement. 

The drive electronics spin the motor, load or unload the heads from the disk surface, report status from the drive, and implement the actions requested by control signals such as write or move. 

The drive is supplied with +15V, -15V, and 5V power from external supplies. 

Heads need to be aligned to a standard position such that a disk written on one drive can be moved to another drive and correctly read. This is done by sliding the heads on the actuator while reading a specially formatted disk alignment cartridge. 

A pattern is recorded on the pack at a given track position and nothing else is recorded nearby. Hooking the output of the read heads to an oscilloscope, the technician moves the heads until the signal is picked up. It becomes even and maximized at the correct position. The head is locked down with a setscrew and retested to verify its position. The two heads are done one after another. 

I don't have the special cartridge. If I can locate one I would buy it but they are pretty rare. Barring that, my restoration will require some clever workarounds to get the drive aligned so it can retrieve the data correctly from all the packs I own. 

Early tasks in the restoration are:

• Build FPGA based controller and connect to the drive
• Install new heads in approximate position
• Install terminator on drive
• Verify that drive spins up and loads heads properly
• Perform alignment somehow

WANT TO DO A QUICK CHECK OF THE DEC TSZ-07 9 TRACK MAG TAPE DRIVE

I kept a rack size 9 track tape drive, a DEC unit which is a rebadged Cipher Data drive, because it has a SCSI interface. That connects easily to my P390 server and appears to be a 3420 tape drive to the mainframe software. Since the P390 is already operational, this could be a quick project.

Unfortunately, I didn't find any schematics for this under either the DEC or Cipher Data names. There is a technical manual but it doesn't go down to the electrical connection level. This posed my first challenge because my normal practice would be to start with the power supply and verify it was producing clean, correct power before I connect it to the rest of the logic. 

The supply is a switcher made by GFC Power, a model GFXC 250-50, but again I can't find any schematics. That matters because there is a connector with some logic signals in addition to the power output connectors. I would prefer to bench test the supply but would need to make appropriate connections to the power supply logic connector. 

I have a few possible approaches:

• try to reverse engineer the logic connections
• just power up the entire drive without any prior testing
• disconnect the power output connectors and hook up load resistors to try to start the supply
• remove and test the capacitors, hope the rest of the power supply is good

Dug into the erratic contact in Documation reader, tested need for column 81 modification, stowed away

 REMOVING AND FIXING UP THE POWER SUPPLY AND DAUGHTER CARD

I found contacts that were bent and likely not making solid contact. I  did some straightening and adjusting to improve it, then remounted the power supply in the machine. I ran it a bit and it worked well, although with intermittent errors only the passage of time and many cards will remove any lingering doubts.

TESTING WHETHER MOD NEEDED TO HANDLE RIGHT SIDE DIAGONAL NOTCHED CARDS

I disconnected the connection from the MOSFET that is hooked to a wired-OR and at the time of the column 81 (CR81) signal, will force row 12 to appear to be dark. I had made this mod because I thought that light from a diagonal notch on the right side was reaching the row 12 phototransistor. 

I then ran a large batch of cards, about half of which had the notch on the right side, with no Read Checks being generated. This tells me that the reason the reader wouldn't tolerate right side notches was the modification made by previous owners that forced a dark check at column 82 in addition to the intended time at column 81. 

BACKING OUT THE MODIFICATIONS ON BOTH M1000 AND M600 READERS

I carefully removed the circuitry I engineered to 'solve' the right side column 81 issue, since it actually does not occur in a machine as it was designed by Documation. Thus I want to strip out the modifications that came with the machine as well as the mods I installed. 

Taking the MOSFET from the M1000 was pretty easy. The M600 had a small daughter PCB with a NAND gate that was wired to several points on the PCB. I had lifted pin 6 of a chip, broke a trace, put in a jumper to bring the pullup resistor to the correct side, and put my NAND gate between the pad under pin 6 and the lifted pin. I installed a new 7405 chip and jumpered over the cut trace, putting the card back in original condition. 

The other modification I had to back out was the cut trace and pullup resistor on the card that that creates the CR81 signal (and was producing the second pulse at column 82 time because of the mod). I had removed it on the M1000 by pulling the resistor and jumpering over the cut trace. I did the same fix to the card on the M600. 

I then grabbed a small batch of cards from a box that I had previously read and read them to be sure that all my tweaks didn't impair the successful operation of the reader. It performed perfectly. I stowed away the reader for future projects. 

RESTORATION UNDERWAY FOR M600 READER

I turned my attention to the M600 whose picker mechanism was in desperate need of renovation. I found that the shaft, which rotates between two roller bearings (at the top and underside of the picker casting), has a huge amount of vertical play. 

I inspected the upper bearing, which is the one riding up out of its socket. The notch on the shaft for a circlip is well above the top of the washer on the bearing. There may be another washer which is missing, or this may have been bad from when I bought it. I do have to measure the space between bearing and circlip notch, then buy washers of the proper diameter and thickness.

Wrapped up last of the cards and an interesting small challenge

FINISHED NURSING THE FINAL 1000 BADLY WARPED CARDS THROUGH ARCHIVING

With patience and skill, the remaining cards made it through the read, twice, to be archived to disk files and verified for correct capture. Over the coming week or two I will dig through all the files I captured, arrange them into logical files, combine sections that were spread across different boxes, test then where possible and document them. 

EXAMINING VARIOUS CARD FILES ON PC WHEN I DISCOVERED AN ODD SECTION

As I looked through the files I captured of the Commercial Subroutines for the 1130, I spotted a section of cards whose interpreted text was gibberish. As I looked at them, though, I could see areas that were likely to be the card sequencing (columns 73 to 80) but not representing real characters in Hollerith. Then, noticing a clustering of multipunched columns where one of the bottom three rows (7 to 9) were combined with higher row punches, I concluded that these cards were upside down!.

The cards were inserted in the deck with row 12 at the bottom and row 9 at the top, the reverse of a normal card. Some were also flipped side to side, so that column 80 was on the left and column 1 on the right. I had a few choices - ignore this and throw away the card images, dig through the boxes to find and reread those cards, or manipulate the files to flip and reverse the cards.

I chose the latter, whipped up some python code, and processed the cards. What I discovered were various // JOB cards, some disk utility program (DUP) commands such as store and list cards, and other odd cards that were NOT any program source or object code. I put these at the end of the Commercial Subroutines deck file for the time being, but they aren't very important. 

Future projects now that card archiving is almost complete

 SELLING, DONATING OR DUMPING THE PHYSICAL CARDS

I have the approximately 150,000 cards, almost none of which I will want to keep once the archiving is complete. I will hold on to a few cold start and diagnostic decks so that I can keep the various peripherals working properly. Everything else has to go.

I have mailing boxes that fit blocks of about 1000 cards, so that I can ship these either as snail-like media mail or via faster but costlier means. I will group together interesting decks, for example a complete DMS2 system load deck or the ECAP program decks, offering them on eBay so that someone who treasures them can grab them. Secondarily, there is always a market for people buying cards as memorabilia, so I can sell smaller lots to those interested. Donations or gifts are possible as well. If all else fails, there is the trash bin, so that one way or another I will reclaim the space in my workshop. 

ADDING 240V OUTLET TO POWER IBM 1130 AND 9 TRACK TAPE HARDWARE

My lease for the workspace includes permission to install a 240V outlet so that I can bring up and restore the two machines that need it - the Telex tape subsystem and the IBM 1130 with its peripherals. I just need to schedule a local electrician to make this happen.

BRING IBM 1130 UP AND VERIFY THE NEW LIGHT PANEL WORKS PROPERLY

Once I have power, I can bring up the IBM 1130 to be sure it is working properly. I will start with a power supply bringup before hooking up the logic to the power, then bring up the processor. At the same time, I have to connect the new light panel I built so that I can see the state of the machine and verify its operation. 

Further down the line I have to hook up my external box, with an FPGA that extends the 1130 with a range of virtual peripherals and a fast means of loading and dumping core memory contents. When this is working, I can boot up all manner of software to test the system fully.

DEVELOPING DISK ARCHIVE PLATFORM AND ARCHIVING OF MANY, MANY 2315 PACKS

I have a large number of 2315 disk cartridges with software for the IBM 1130. These may contain some precious files that weren't in the card decks, thus archiving them all is important. Too, these archived files can be used with my FPGA extender as virtual cartridges in virtual disk drives.

I have a Diablo disk drive, the standard density version that matches the density of the internal 'ramkit' drive inside the IBM 1130. It had suffered a head crash but I have replacement heads available. I expect I will create an FPGA to drive the disk drive and extract the images, much as I had done to read and archive all the Xerox Alto disk images from the Xerox PARC cartridges they let us access. 

First I will get the drive put back together, second I will inspect and clean some of the cartridges, then I will work out a method to align the Diablo drive so that it matches the internal 1130 drive and the data already on the cartridges. Once I figure this out and execute it, I can begin testing the FPGA code I will write. 

Continued archiving decks, only 1000 cards remain to read

 ARCHIVING DECKS CONTINUES

Having completed all 15 trays of cards, I turned my attention to the remaining boxes of cards waiting for reading. There were 13 boxes of roughly 2000 cards each left to go. I made great progress, reading 12 and a half of the boxes in just a few hours. The reader performed superbly, with one a few random issues (see below). 

Remaining cards to read are the top half

I didn't finish the last 1000 because they were badly warped, so that they must be fed in tiny batches after some bending and manipulation of the hopper weight pressure. It was very tedious to process another 1000 with the same warping and I ran out of energy and motivation to finish them up today. 

Bowed cards that won't feed properly

When I am next at the shop I will hand feed and baby them to get the remaining cards through the archiving process. The remaining deck is the Keyword In Context (KWIC) program that IBM offered to index files containing specific keywords, the program to generate the index is already saved but the IBM supplied data cards and examples constitute the remaining 1000 cards. 

VERY FEW MISBEHAVIORS WITH THE M1000 CARD READER

I was very pleased with the performance of the reader. Over the course of reading 25,500 cards and several hours time, I got one spurious Stacker Check/Read Check stop. The intermittent gremlin was quiet today, thus I postponed the disassembly and examination of the daughtercard until a later time.

I did see two occurences of another anomaly, the blower motor shutting down while the reader is in the process of reading cards. Without the blower to separate cards and grab the card being picked, the reading speed quickly declines and then stops. All I had to do was stop the read and restart to get the blower active again. 

This may be a flaky connection or logic issue, but I have only experienced this twice in the entire time I worked with the reader. It is easy to hear, correct for it and resume operations thus I won't be hunting this one down. 

Very good day in spite of the remaining gremlin

 INVESTIGATING THE ONEDARK SIGNAL FAULT

I used my voltmeter and quickly realized this was not the same root cause as my earlier hairline fracture, even though the symptoms were identical. I was seeing valid logic levels that would switch to true when the fault was present. In order to debug this further, I would need to trace the individual signals that generate OneDark, thus the machine had to be partially disassembled and the extender board used.

Once I had the extender board in place, the fault was gone! Typical of this possessed bit of machinery. Still, that meant I could do some archiving until it returned. 

ARCHIVING OVER 16,000 CARDS IN A FEW HOURS

I was able to process all the remaining trays of cards with a tolerable, low rate of errors. Sporadically I would get Read Checks or other failures but could rerun to get past the issue. I have lots of system software, utility programs, contributed programs shipped by IBM, games, and other goodies that I have captured.

THE HANGING CHAD PROBLEM - CAME THAT WAY FROM IBM PROGRAM DISTRIBUTION

One program deck repeatedly threw verification errors, across many different cards in the deck. Interestingly, all were at column 6. I inspected the cards where the errors arose and found small hanging chads on the rear of the card, where the machine that punched the hole in the card left it attached along the bottom edge of the hole. It would flop around, so that sometimes it read as a hole and sometimes it blocked the light and read like a 0. 

I had to tear off the chad, rerun, and find the next case until I was able to read and verify the entire deck after a very tedious session of many many runs. This is the only deck where I have run into this problem (and the only time in my entire career working with punched cards). 

I realized this failure could not have been produced on the 1442 card punch that came with the IBM 1130 system, nor from a keypunch. The 1442, like the keypunch and like the Documation readers, reads cards so that the columns move serially through the machine, capturing the 12 rows at a time before advancing to the next column. 

The only way this could recur so many times on exactly the same column was that there was a defect in the card punch only for that column. Few card punching machines from IBM operate with 80 separate punch dies operating simultaneously, moving the card serially from row to row. The IBM 1402 from the 1400 series computer, the 2540 which was its descendant installed on 360 systems, and a few tabulating machines are all that comes to mind. 

That is, a card enters with the top or bottom edge going into the reader throat on a 2540 and it moves past 80 read brushes or 80 punch dies, row by row. The 1442 and the keypunch has the card enter with the left edge into the throat and moves it past 12 photocells or punch dies, column by column. 

This deck was created on a defective machine at IBM and shipped to the owner of the 1130 system from their Program Information and Distribution (PID) department. 

PROBLEM RECURRED AND I NARROWED DOWN TO THE AREA OF THE ROOT CAUSE

The problem came back, the machine moved three cards while transmitting no data and giving a pick check. The OneDark signal was a valid logic true level. I began checking the voltages at the inputs to the Control board, one from each of the twelve phototransistors, and soon found that the row 9 phototransistor was the one reporting a dark situation, all others seeing light. 

Since this entered the circuitry already in error, the cause was elsewhere in the machine rather than on the PCBs. I began to manipulate the various cables and devices that link the read station to the PCBs. It was not sensitive to tugging or moving the cable, which meant I could rule out an intermittent wire in the cable. 

The 'other side' of the phototransistors are a set of 12 LEDs that produce the light which either passes through holes or is blocked by unpunched sections of cards. A set of adjustable resistors inside the base of the reader sets the brightness of these so that the dark and light signals are very reliable - not so bright that it shines through the card stock but not so dim that the light through a hole doesn't cause the phototransistor to conduct. 

These resistors and the wire cable up to the LEDs sit on a daughterboard which plugs into the larger power supply board. I moved the cable up to the LED with no impact, but when I tapped the daughterboard, my OneDark issue went away!

At times while reading all the thousands of cards, the intermittent issue would trigger a difference between the 'read' and the 'verify' passes of the card decks, or trigger a Read Check, but those could be solved by a rerun. A couple of other times the reader settled into the steady OneDark and its symptoms, but all I had to do was gently rock that daughterboard to resolve the issue.

I now know that the problem is in connectivity either on the daughterboard, in the variable resistor (less likely) or in the connection to the main power supply board. I have had sporadic errors where I saw Stacker Check raised along with Read Check, yet there was never a jam or issue in the stacker (where cards are stored after reading). The Stacker resistor is adjacent to the resistor to adjust row 9, increasing the chance that this is a failure on the daughtercard near those variable resistors on the end. 

Once I am through archiving, or if the rate of this failure increases to force me to switch over to repair early, I will pull the power supply and daughterboard, find the cause definitively and eliminate it.  

Daughtercard whose manipulation cures OneDark problem

Location of the daughtercard inside the base of the reader

HUGE BACKLOG OF FILE PROCESSING, VERIFICATION AND ORGANIZATION AHEAD

Because I have read so many trays of cards and so many separate programs, some in multiple segments due to length, I have to concatenate files, organize and document them, study them, and fix some cases where I found a section of a program out of order in the trays. This will take many hours of work while I am away from the shop. 

Ultimately I want all the card decks properly organized, documented and shared so that others have access to all this software. That is the end game for this archiving activity. I also have a few hand written notes on index cards or the backs of punched cards that reflect instructions for use of various utility programs, all of which need to be captured.

This card was stored with DISKDUMP and DISKREAD decks

THINKING ABOUT THE MYSTERY MODIFICATION FOR DOUBLING THE CR81 SIGNAL

The odd modification I discovered in my two Documation readers, that ignored the state of the lower order bit of the column number, resulted in checking for all dark rows twice, at the time of column 81 and again at the time of column 82. This made the machines very intolerant of cards with a diagonal notch on the right side. 

It is a well shared weakness of the machines, yet an odd one since right side notches are a legitimate version of punched cards that were prevalent enough that Documation must have run into them while selling these machines. The documentation does NOT list this as a restriction or warn the user about right side notches. 

One of my machines has a plate on the side listing its ownership as Jefferson County, Colorado, which is consistent with the widespread use of these machines for tallying votes a few decades ago. That led me to think that this modification was made for machines used in vote counting. 

The check that all rows are dark at the time of column 81, the originally designed test, is done to catch times where the card did not move through the read station the amount that was expected. If there is a light at column 81, or any dark rows at column 84, this indicates a movement error and the data is suspect. It generates a Read Check to warn of this problem. 

Installing this modification would add a check for all dark rows at column 82 time, thus making the error checking a bit more stringent. It may be that these were introduced to catch more issues because data integrity is important for vote counting. In the voting role, the reader would only be processing cards specifically created for the election, thus they could ensure that the card did NOT have a right side notch. 

Making great headway archiving card decks, but at least one more demon resides in the card reader

VERIFICATION THAT MY MODIFIED READER CORRECTLY READS COLUMN 80

Since my modifications to the reader affected the change that was giving double CR81 pulses, it was possible that my new circuit was being activated at column 80 time rather than the intended column 81 time when all rows should be dark.

My circuit forces the top row (12) to be seen as dark when at CR81 time. This compensates for errors reading cards with a right hand side diagonal notch, since the light may leak around the notch into row 12 causing a Read Check stop. If this circuit was active at column 80 time, then it would also ignore any hole in row 12 on that column. 

I took a card that had row 12 punched in column 1, flipped the card so that the column 80 side entered the reader first (to be read as column 1) and then checked what was read. You can see the backwards text because I flipped the card and indeed the last column does read the hollerith character C (row 12 plus row 3) properly.

Rightmost column (80) has holes in 12 + 3 for a letter C

 FAST AND ACCURATE ARCHIVING OF COBOL AND RPG COMPILERS

This reader is not only faster because it is 1000 cards per minute versus the 600 cpm rating of the M600, but also because its picking mechanism is in good condition and rarely fails to pick. 

First video above is loading the deck into the M1000 reader. Below is the process of reading via the cardread.exe application on my laptop, through USB to the controller I built into the reader.

I ran about 1500 cards of the COBOL compiler and another 1500 of the RPG compiler through the reader in batches of a few hundred cards each. Extremely few pick checks or reading errors. 

ARCHIVING OF IBM 1130 DIAGNOSTIC DECKS 

I then moved through a few thousand cards of diagnostics. In this case, each deck is quite short so the time to name and process each individually is much longer than the actual reading plus verification passes on the reader. 

In the video above, you can see a verification pass where the card deck is read a second time and compared hole for hole with the file that was created during the 'read' pass. At one point it has a pick check, thus a pause until I hit reset on the reader to continue the reading.

SYMPTOM RETURNS AS ONE INTERMITTENT AND THEN SOLID FAILURE

I had a pick check while reading a deck, but when I reset the reader to retry I saw that it was back to the same failure where it didn't see that the card was actually going through the read station. That was the symptom when the OneDark signal was prematurely active due to the hairline crack in the trace. 

I tapped the card cage, hit reset and we resumed reading successfully. However, after a few more decks being processed, the symptom returned and was solid this time. Very frustrating. Might not be the same issue exactly but certainly the same symptoms. Will have to call the Ghostbusters for this one. 

Flakiness multiplies but I hunted the cause down; reader working excellently now; debugging of my cardread.exe commences

 CAREFULLY PREPPED FOR MY DEBUGGING SESSION

I had printed the schematics, written out a solid plan and set up the logic analyzer to help me capture the flaw in the Good Pick Reset (GPR) signal generation. The extender had to be moved to the Clock board which is where this circuitry resides, then I powered up to take some readings.

PROBLEM SHIFTED DRAMATICALLY, BACK TO AN EARLIER ISSUE

When I fired up the reader to read some cards, it was failing in an new but old way. The logic analyzer showed me that GPR was issued, but it came BEFORE the start of the card read and well before OneDark should be generated. Yet, that signal was showing as true.

I had the VOM out and probed some signals to get an idea where to begin troubleshooting this problem. I uncovered an invalid voltage of 1.6V on the motherboard line for OneDark. This is right in the forbidden zone for logic values. 

This is enormously frustrating. A set of symptoms crop up, I set up to debug them but the reader shifts to a very different behavior that requires entirely different debugging actions (and test points). 

SWAPPED SOME BOARDS, PROBED SOME CHIP OUTPUTS AND THOUGHT DEEPLY

I pulled the Control board that generates OneDark, powered it independently and probed a chain of chips and signals to try to understand the improper voltage. The card, however, was working exactly as it should and driving completely valid levels for OneDark, OneLight and all twelve rows of data. 

That led me to look at all the destinations for this signal on other boards, to see if one of them was dragging the levels down. The Error and Clock boards are the other two involved, both of which I swapped with the same cards from the M600 reader, but nothing changed. 

I popped the VOM on the backplane pin 6 for OneDark and saw it was indeed registering 1.6V while the card itself had 3.7V present on the finger plugged into the backplane. That was when I realized I might have a continuity fault or short between traces somewhere.

After quite a bit of testing across the boards and backplane, I narrowed the issue down to the backplane itself. I disassembled the reader to tilt the card cage up for close inspection. I tested adjacent pins for shorts, but that wasn't an issue. I then tested for continuity between the six rows of pins for each signal and voila!

The signal for pin 6 ran properly between cards 1, 2, and 3 but not down to card 6, the Control card that generates OneDark. All other pins had full continuity, but not this one. Further, upon close visual inspection I found a hairline break such that I would have periods of good connectivity, periods of lost connectivity, and periods of erratic connections.

Very tiny break in trace discovered

A jumper wire across the backplane bypassed this problem and everything went back together rapidly. Filled with anticipation, I first tried the manual feed switch on the back and watched it process an entire deck just as it should. I next hooked up the laptop to the controller and did a proper read of the cards.

SUCCESSFUL READING INCLUDING MY RIGHT HAND DIAGONAL NOTCH FIX

The cards I read were correctly captured with no false Read Checks from the cards with a right hand notch. The deck had sequence numbering in columns 72 to 80, so it appears I could properly capture data out to the end. I will conduct one more test tomorrow to prove to myself that row 12 in column 80 is being read correctly, but this seems quite promising.

I whipped through a half box of cards with right hand notches, containing part of the IBM 1130 COBOL compiler. The reader was faster and more accurate than the M600 I had previously been using. I look forward to completing my archiving task with this reader.

FIRST DEBUGGING OF MY VERSION OF CARDREAD.EXE - MIXED RESULTS

The version of the program that I had modified and compiled was driving the card reader while I was reading cards. It appeared to be working properly however I noticed one flaw immediately. The original version displays the characters across the top of the card image along with the hole pattern when reading in binary mode. My version displays nothing but ? characters. 

I finally had a verify failure occur where I could test out my new Truncate button that is intended to truncate the file at the last properly read and verified card image. I pushed the button but it did not gray out, nor did it work properly. When I opened the card file it was empty. Truncated, but not to the intended card image.