Sunday, December 5, 2021

Archived cards, M600 reader now out of adjustment and misfeeding, but M1000 reader nearly ready to take over


I have completed five of the 15 trays of system cards and archived about a quarter of tray 6. Further, I continue to read and save the COMMON submitted decks and soon will start on some IBM distribution boxes and programs used by the prior owner to operate his business.


I will hear some clanks and metallic sounds on certain feed attempts. The reader is also failing to pick cards much more than before. The troubleshooting guide suggests that this sound is either misadjustment or wear in the parts that accomplish the pick/feed. 

There is a series of adjustments that I will have to put the mechanism through in order to have it properly set up. If there is wear, for example in a bearing, I will learn that as well during the process ahead. Until this is done, the main reader I was using and its external interface are unusable.


The magnetic pickup is again reading as fully connected and functional. The oscilloscope shows good clean pulses being detected and the reader logic is working properly. I finished installing the internal interface and connected it to my laptop to test reading some cards.

The problem I am encountering now is random Read Check errors. The data that is showing often has dozens of columns apparently laced with holes, although the actual cards are not punched like that. If light is detected and times when the card should not be over one of the 80 columns, or dark is seen when the card should be past the read station, the Read Check error is triggered.

This could be caused by sporadic circuit continuity problems with the magnetic pickup, if that causes the logic to miscount and believe the card is already past column 80 when it is physically still in mid stride. It could also be a different error that I have not yet found and debugged. 

Still, the pick mechanism and feeding seem really healthy. If I can resolve the erroneous read errors and its root cause, I will be ready to archive more cards with the new reader. 

Monday, November 29, 2021

M1000 reader magnetic pickup fails again, verifying more of my chips, continuing archiving of decks


I hooked the scope up to the Index Marker (IM) signal line and saw zip. I then noticed that the behavior of the reader indicates that the original problem I had with the magnetic pickup is back. That is, the pickup is not delivering pulses at all. Those are important in order for the reader logic to recognize that a card is feeding through the photocells and to time the points to read the eighty columns.

I was working on finding the open circuit in the pickup when I found it working again, so I simply installed a new cable and put it back into the reader. It seemed to work properly for a while but just as randomly the connection has failed again.

I am going to attempt more significant surgery on the pickup - cutting into the sealed block and inspecting until I can clearly spot the broken wire. I am assuming that it is broken from where it exits the wound coil up to the point where the external cable is attached; in that case, if I can see the break I can repair it. If it has failed deep in the windings, I am out of luck.

The alternative is to get another pickup that can detect the teeth of the wheel and generate pulses to feed into the logic circuitry. That may involve machining a different holder since I would have to be extraordinarily lucky to find a substitute with an identical size and shape. 


Over the years I have acquired plenty of integrated circuits, with some of them coming from auctions, surplus shops or other sources where I can't be certain that the chips are new and working well. The range of chip types is very wide, including many rare or obsolete versions that are not supported by most chip testers. 

The Retro Chip Tester Pro that I built covers a more comprehensive set of devices - far more than the other testers I have used. As a result, it has tests built in for the majority of the devices I attempt to test. 

I spend time on every visit dumping out bags of chips, sorting them into lots of the same part number and then testing them. I have found a few bad chips. Just as importantly, I have satisfied myself that the bulk of these devices work correctly and can be used in future projects. 


I used the 600cpm reader to archive another one and a half boxes of COMMON programs. These have read fairly reliably, although the heavier work is studying, testing and documenting them afterwards. I also tried to read more of the DMS R2 M12 deck but these cards are very touchy to scan. The rate of misreads, either on the first pass or on the verification run, forces me to take them 20-30 at a time and feed them perhaps five or ten times before I get a good captured file. 

Friday, November 26, 2021

Spent hours organizing DMS files and testing all the COMMON programs I have archived


I took the batches of cards that I had read, clumped them into larger groups and then split them into the individual phases that are loaded during and initial or reload of DMS onto a disk cartridge. You end up with many, many dozens of phase files plus other files that are assembled into a huge virtual card deck. On the real machine, that deck is loaded in the card reader, a blank disk cartridge is inserted in a drive, and then the deck is loaded by pushing the boot button (Program Load) on the 1130.

A deck consists of the following:

Three loader files in sequence. First, a single 1130 loader card that is the subject of the boot operation. That card's program then reads in a single card that is the 1800 loader; the 1800 is the big brother of the 1130 which was used for real time process control tasks. Finally, the 1800 loader program reads in a multi card deck which is responsible for reading in the system loader. 

The system loader is split into two phases. The first begins to format the disk cartridge and reads the next set of cards which are the data and permanently resident system code areas that are put in the special boot areas of the disk cartridge. After this 'EMN' permanent code and data file comes the system loader phase 2, which is the logic that reads most of the deck of cards and stores each phase on the disk.

A few control cards are inserted by the user that define the peripheral configuration, storage size and defines the ranges of phase numbers for each of the major sections of the monitor system. These are functional areas such as the job control, disk update program, fortran compiler, assembler and core image loader. 

The last phase of the monitor is followed by a 'type 81' card which tells the loader that it through with loading phases onto the disk libraries. The machine then fires up the monitor and runs the DUP program to start loading the system library components such as functions and subroutines. These are small object decks with a *STORE directive in front of each one. After the long string of library components is loaded, the process ends and the disk is now ready to be cold started by hitting Program Load with a cold start card in the reader. 

I have archived one complete deck to load the older V2 M11 version of DMS, a second complete deck to load the newest V2 M12 version, and have started on a third deck which is also a DMS V2 M12 load. Since I have multiples of the deck and have versions of the card decks from other sources, I can do a compare to make sure that I didn't garble any code during the archiving. 

I ran a few comparisons already with no differences detected. As a test I compared the System Loader Phase 1 decks between the two version, M11 and M12, which did flag a reasonable number of differences. I will continue to work with the files until I have compared and verified everything. Preservation of the 1130 system files is the most important aspect of this archiving for me.


I have reviewed all the files I have archived, written a short description of what they accomplish, and tested them on the IBM 1130 Simulator as much as feasible. In many cases I include part of the virtual listing from the line printer, particularly for printer art. 

Wednesday, November 24, 2021

Read almost four boxes more, plus started testing of the internal controller on the M1000 reader


Two of the boxes were the system load plus sample programs in Fortran, RPG, Cobol Assembler plus a few utilities. The sections where the edges near column 1 were torn up gave me the most difficulty, but I was finally able to coax them through and verify the results. 

When a box is particularly troublesome I have to move to small batches, 20 to 35 cards apiece, which means I end up with very many of these small deck files to consolidate. I whipped up a python script to pull them together on my PC.

A box of programs from the COMMON user group was also among the work I accomplished today. The work is just begun when I finish reading, as I have to figure out what each deck accomplishes, document it and test it as much as possible. With as many boxes as I read today, I wasn't able to finish all that back end work by the end of the evening. 

I did find the program that produces music on a nearby radio held near the processor, the complement to the decks of music data I had previously archived. Similarly, I had found a nude woman on stool printer art program which called a mystery program wxyz to print the stool itself. Today I found and archived that program, which completes the printer art work. 

I then began on another reload deck for DMS V2 M12, archiving about 1/3 of a box before I left the workshop. These have intact edges but don't slide smoothly apart so that I have a medium rate of misreads and verification errors. 


I powered up and connected to the controller from my laptop. The connection was successful and it appears to reflect the machine status accurately, although I didn't force very combination of states. The pushbutton toggles the EOF lamp on. Finally, the controller code issues a pick command and drives the reader to move cards through the machine. 

However, no data is transmitted to the PC. Tomorrow I need to monitor the IM line to see if the index marker pulses are arriving which is what triggers the Arduino to capture the hole patterns for each column. This could be wiring, bent pins on the shield, or another defect in the card reader electronics, to be resolved as I test the IM line. 

Monday, November 22, 2021

Fixed retro chip tester and archived more card decks


I flashed the test firmware that would allow me to cycle the voltage rails to the pin.s on the testing socket where they could be routed, as well as cycling signals to all the pins. I quickly discovered that pin 1 of the tester had a constant application of -5V applied to it. 

Tracing the pin back I found the circuitry that could deliver voltages to it - one was a transistor routing +5V but the other was a relay that switches in the -5. That in turn was ARbeing activated improperly because, shame on me, I had inserted the UL2003 backwards! The UL2003 is seven darlington transistor pairs but with pin 8 installed where pin 1 belongs, it fed power to the relay.

Putting the chip into the socket in the proper orientation resolved everything. Fortunately the mistake didn't damage any other components. After I flashed the production firmware I used the tester to validate chips like 7423 that weren't covered by my other chip testers. I validated several dozen ICs, fulfilling my hopes when I took on this project build.


I worked my way through a box (2000 cards) of programs contributed by members of COMMON. These read pretty well - some of them flew through with almost zero errors, other sections were a bit funkier, but I was pleased with the progress. I then turned to a reload deck for DMS V2 M11 which had been in a card tray in a cabinet back in Kansas, where the humidity the basement caused the cards to swell so much they were locked in place. 

The team helping me extract the 1130 could not release the latch to remove the cards in those trays; they were forced to pry sections out to relieve enough pressure to remove the rest. Sadly, this DMS deck had considerable damage on the two sides of the cards, near columns 1 and 80. 

Leading edge of card deck quite damaged

Amazingly the Documation could still get the cards through, albeit with time sucking manipulation that sometimes meant fighting individual cards to read. This will take many many hours to finish reading. 

Sunday, November 21, 2021

Continuing the card archiving, finished retro chip tester pro, wiring internal Documation controller


The number of reading errors varies dramatically from box to box of card and I don't yet see a pattern to warn me of troublesome decks. A two box set of cards that load DMS V2 M11 (the disk monitor system, compilers and utilities that are the equivalent of the operating system for the IBM 1130) read so smoothly that I only had three cards fail to verify, two of them were errors in the verify pass and one was an error when reading a card on the first pass. A box of contributed programs from COMMON, the IBM users group, on the other hand, was a nightmare where a hundred card deck might require ten or twenty passes to get the data read and verified. 

With the card contents captured, I could move on to phase 2 of the archiving. That is an examination of the decks to understand what they are, which guides me to further work. Sometimes I realize I have two more more logical items in one marked deck and split them up.

I want to end up with a folder for each deck with a descriptive name. In it there will be a text file where I describe what this deck represents and highlights any errors or missing elements. In many cases I run the code on the IBM 1130 simulator to make sure I understand it properly. Where it makes particular sense, I include a text file that is the printer listing output. 

The files I captured include printer art, games, utility programs and the disk monitor. As an example of a very useful utility, I came across programs that write various pause and error conditions to the console printer. In normal practice, a program issuing a PAUSE command will display four hexadecimal digits in the accumulator, visible only on the lights. There is no hard copy evidence of this, so that once you push Start and move past the pause, all record is gone. 

Other conditions produce monitor errors as four hex digits in the accumulator. This utility will type ERROR xxxx on the console, drawing more attention to the issue and making a hard copy. This was handy when I was trying to run a printer art program, because it had a defect that lead to the monitor detecting error F001 and pausing execution. It was helpful to see ERROR F001 printed because you might miss the error otherwise. 

When the card reader runs out of cards, the system waits with a particular address displayed in the console lights - one is accustomed to the monitor waiting and may not carefully examine the lights to distinguish an error from a normal end of job stop. 

I wrote up the order of the decks for someone who wanted to run a fresh install of DMS V2 M11 on a blank disk cartridge - along with the decks themselves. This makes the archived decks more useful than an assemblage of randomly named deck images. 


The last step in building the chip tester designed by Stephan at is to load the code onto the Atmel 2560 chip. The PCB he provides comes with the Atmel soldered on, but not programmed. I picked up a suitable programmer, hooked up and flashed the chip.

I brought it up. All lights were good and the menu system works on the LCD display. I started in testing some chips that weren't covered by the other testers I own, such as the 7475 and CD4050. However, some other chips that are supported came up with errors upon test. More worrisome, either the 12V or the -5V power supply LEDs blinked off during these failed tests. 

I suspect that something is not working properly, applying the wrong rail voltages or hooking more than one supply voltage to the same pin. A construction error undoubtedly. There is a diagnostic firmware load that will selectively apply the rails and signals to each pin, letting me track down the issue.


I removed the old socket from my previous controller and moved the wires over one by one to the Arduino shield that will connect a Mega2560 with my controller sketch. I finished all the signals that were used by Brian Knittel's controller but two additional lines from the reader are used by my controller - Motion Check (MOCK) and Busy. I have to identify the wires for these two and hook them up, along with the LED and pushbutton. 

Friday, November 19, 2021

Card reader interface fully working, beginning the archiving of all my decks


After I adjusted the code to send the two bytes for each column in the order expected by the CARDREAD.EXE application, I flashed that sketch, without a bootloader, to the Arduino Mega2560 inside the external interface box. It was ready to test. That was the last fix, as the unit now reliably read the card images into the file as displayed by the companion DECKVIEW.EXE application.

Cards faithfully captured


I can now begin the highest priority task I have, the reading and archiving of all the boxes of punched card programs and data that I hauled with me from California. I begin with around two full boxes worth of cards, consisting of various programs and test data. 

It takes a while for a deck of cards to read correctly - they are a bit sticky from the years of storage, thus from time to time there is a bit of drag as one card slides off the deck. This can cause the data in certain columns to be read as the adjacent column. 

To catch these issues, I read the file and then pass the deck through again in verify mode, where it reads them and compares the data to the stored file. When I get a verify error, it can be an error made during the second pass or it can be an error in the pass that was captured to the file. It takes several tries to figure out which is correct and to get a stored file which verifies properly. Different decks, varying in condition, read with more or less issues and take different numbers of passes to complete. 

The time it takes to make all these passes and yield a verified fail slows down the rate of reading dramatically from the nominal rate of the hardware. The Documation model 600 can read 600 cards per minute at full speed but my net rate of finished reading is only 1200 cards per hour. That is about 30 times slower than the theoretical. This means that it will take about 100 minutes, one and two-thirds hour, per box to archive.


I now have a reliable Arduino based controller for the reader which I will install inside the other card reader I own, removing the need for an external box and cabling to drive the machine. A USB port on the rear of the reader will let me link it to the card reading application on a PC. 

I have a shield that consists of a set of holes I can attach to wires, linked to each of the Arduino pins. It forms a compact sandwich with the Arduino that will easily fit in the gap inside the Documation card cage between PCBs 3 and 6. The two unimplemented card positions 4 and 5 are a comfortable space. 

I began soldering the wires from the Documation cards that had run down to the external cable connector, but are now available to hook to my shield. When these are done, the only remaining task will be to build a card sized base that slides into slot 5 and supports the Arduino/shield sandwich. 

I had previously installed a pushbutton and LED for the End of File function that is part of the card reading application process. These hook to assigned pins on the shield just as they do in the external box  I finished debugging this morning.