IBM 1130 Restoration at TNMOC in 2014

2nd October 2014 Update from Peter Vaughan

• 1442 card reader: This was inspected and various areas cleaned, bearings re-greased and rubber wheels cleaned. An increasing number of cards were fed through and the reader appears to be working fine. However, a bearing in the punch mechanism was found to have degraded. While this is not used during the reading of cards it will need to be checked / fixed before further punching is possible, This involves removing the complete punch mechanism so will be left for a later time.
• 1131 processor: A few months ago I noticed the fan under rack A-A1 was not moving. The fan tray was removed from the system and the fan removed for inspection. Continuity was checked and this gave an open-circuit result so the fan is dead. I took the fan apart but the fault is in the winding so a repair is unlikely. A suitable replacement will need to be found before the 1131 can be safely left running for long periods.

5th October 2014 Update from Peter Vaughan

• Broken fan is beyond repair and as this fan is no longer available a more recent fan has been found to replace it - Thanks Olly.
• If the fan is OK then the system should be running again next weekend, assuming the console printer is still functional after not being used for months.
• Spent a few hours tidying up the area behind the system and sorting through several donations of punched cards. I'm on the lookout for a 2 draw cabinet or filing cabinet to replace the small black cabinet I have and to keep stuff out of view, so if anyone has such a thing let me know.
• I'm also on the lookout for a 10A variac to replace the 25A version that currently trips the circuit breaker when the system is powered on (still no idea why). I am currently using a 6A variac but this is not big enough to also have the 1132 printer on with the rest of the system.

11th October 2014 Update from Peter Vaughan

• Broken fan replaced with a more modern alternative so the system can be run fully again.
• System ran the CPU test most of the afternoon without error. Still need to test reading of punched cards and the disk drive to check they are still working properly.
• At some point the 1442 punch mechanism will need to be removed to see if the failed bearing can be fixed / re-lubricated or replaced. While this bearing plays no part in reading cards it could impact punching should that be needed in the future.

1st November 2014 Update from Peter Vaughan

• Someone pinched the 4 way mains extension used to power the system. Had to borrow another one to get the system running again (wasted 45 mins looking for it)
• The system normally runs the CPU test which is retained in core memory when the system is switched off. However, this time after setting it running as normal it stopped with an error condition. Just to make sure this was not a corrupted program (the program in core was last loaded in march 2013!), I attempted to reload the CPU test via punched cards as I had done before. Test programs on card need a loader program to be run first which then loads and runs the test program following it in the card reader. While the 5 card basic loader appeared to be read in OK, when it started and loaded the first card of the actual test program it stopped. I then tried another test program which uses the same basic loader and that failed at the same point. Attempts with another copy of the basic loader and programs that use a different relocating loader program also failed to load after it started.
• Investigated the loading issues for a couple of hours but no clues as to whether this is a fault with the 1442 card reader or with the CPU or transfer of data to core memory. What is strange is the location in the basic loader program that it stopped at is not one of the normal wait instructions used to indicate error conditions (a wait instruction 30XX causes the CPU to halt with the wait instruction value, XX, stored in the B register), it is actually an unconditional jump instruction (MDX). So either the basic loader has not read in correctly, the 1442 reader is faulty or there is an instruction fault. I will need to investigate further next weekend.

8th November 2014 Update from Peter Vaughan

• The missing 4 way mains extension was behind the 1130 when I came in with no clues as to why it was removed or by who.
• spent much of the day investigating the card load issue.
  • First did a basic core test writing all zeros, then all ones then F0F0 and 0F0F and all read back fine so the core appears to be fine.
  • Next tried loading the master copy of the basic loader and the same problem occurred, so it is not the card deck at fault.
  • Next check was to see if the basic loader had been read into core store correctly. This is likely as a checksum is performed on each card and no checksum error stops were seen. I started with just loading the first card, which checked out OK.
  • Next tried 1st & 2nd card - core checked OK
  • Next tried 3 cards - 1 & 2 OK, 3 did not match the program listing
  • Next tried 4 cards - 1 & 2 fine, 3 wrong, 4 fine... very strange.
  • Spent some time and with Kevin B's help we noticed that the 3rd card was actually loaded into core 1 byte offset to where it should have been read into, with the extra byte at the front being 0.
• So it looks like a program error, but as I know the program is correct there must either be an instruction fault or a store corruption causing the load code to copy the card to the wrong location. I need to understand the 1130 instructions better to see if I can identify where the program is going wrong, which may identify a faulty instruction.

13th November 2014 Update from Peter Vaughan

• Spent some time getting more familiar with the 1130 instruction set and working out how the basic loader program works.
• Did a bit more testing of core store writing different patterns to see if there were any issues but none were found.
• Tried reading in all 5 cards on the assumption that the 5th card would be read in incorrectly, and it was, but I then discovered the data was being written 24 bits (1.5 words) late in core. I rechecked the 4rd card in memory that had been written correctly and discovered it was in fact written 1 word late rather than in the correct place.
• So each read of a card after the 2nd card is written offset by an accumulating 8 bits per card.
• The basic loaded card format is called 8/8. This means the top 8 holes in each column represents 8 bits, with 2 columns needed to supply each 16 bit word. The columns are also written LS byte first, MS byte 2nd, with the first column read into a 16 bit word, shifted right 8 bits then the 2nd column read in to another location and the two XORed to produce the actual 16 bit word. There is also a memory location (RDIN) that is used as a toggle. As each column is read, the word is toggled between 0 and 1 with 0 indicating the LS byte column is being read, which is shifted right 8 bits and put into location 0, and 1 indicating the MS byte column is being read which is written into location 1. The two are then XOR and the 16 bit word written to its final destination in core using a long store instruction.
• The store instruction that copies each word is initially set to write to address 0x004F, the start of where the 2nd card is read into. This instruction has the store address incremented by 1 each time a word is written, so as card columns are read and combined, they are written into consecutive core locations. This continues with each subsequent card with each word written consecutively until all cards are read and the loader code branches to the 2nd stage loader responsible for reading in and checking the actual test program cards following the basic loader cards.
• It was clear that additional bytes were being read from somewhere at the beginning of each card causing the increasing offset as each card is read in. One culprit could be the RDIN toggle word so I tried reading just 2 cards, the initial loader card and the first card of the basic loader. Because each card is an even number of columns, after reading a whole card, the RDIN toggle should be 0, reading for the first LS byte column of the next card. After loading the 2 cards I found RDIN was actually 1 and not 0. So it looks like the code has seen an extra byte (or column) or the XOR toggle is failing in some way.
• As the 2nd card is the only one that is copied to a predefined starting location with all the others just following on in core, I tried just loading the first card which has exactly 80 columns filled, so it should load into the first 80 core locations only. Before I loaded it I cleared store to FFFF so I could see exactly what was read in and where. After loading the card I checked various locations which all checked out until I got to location 81 (0x0050) which contained 0 and the FFFF as I expected. The system had in fact read 81 columns of data into core so had not stopped reading after column 80. If each card produced 81 columns of data, that would explain why RDIN was 1 instead of 0 after reading a card, and explain the 8 bit incrementing offset writing each cards data.
• So this could be a 1442 fault with not detecting an end of card condition, or the device status word (DSW) was not setting the operation complete bit (bit 4) (which the loader program looks for) or was setting it late. Time to get the scope out!

15th November 2014 Update from Peter Vaughan

• Spent some time checking card alignment in card reader but even after further minor adjustments the problem still exists.
• Tried to check interrupt signals from 1442 on 1131 backplane to see if I was actually getting 81 int 0 (normally 80, one per column read) and at what point int 4 (operation complete at end of card) was generated (normally at or slightly after the 80'th int 0), but the analogue storage scope I had did not capture the spikes very well. As Delwyns digital storage scope was broken I could not progress this further. So still no clue why I am getting 81 columns of data.
• Will look at a donated logic analyser we have to see if that can capture the info I am looking for or borrow Johans digital scope if he has it with him.

22nd November 2014

• Had a visit from Carl Claunch from USA, who is currently restoring an 1130 he acquired a few months ago. He spent some time with me investigating the card reading problem.
  • Tried the logic analyser but sadly the 1130 was so slow, the analyser ran out of memory before seeing anything useful. As I had not brought my scope and the others around did not appear to work properly no additional information was gleaned.
  • Looked at the 1442 and found that it does in fact send 81 int 0 signals (i.e. and extra one after reading the 80th column). Looking at the logic diagrams it looks like this last int 0, combined with the CB2 signal sent at the end of the card read cycle is used to block further writing of memory and other operations. This then gets converted into an int 4 (operation complete).
  • Looked at the logic diagrams to see how these signals were handled and identified a number of cards where the signals were processed.
  • Swapped a number of card locations with other locations containing the same card type. Initially it did appear to change the fault and allow reading in of all the cards in the test deck, but I discovered a badly punched 2nd card which caused the system to think the basic loader card set consisted of 255 cards rather than 4. Repeating the load with a good basic loader set showed the problems still remain.
• Concluded that something in the logic that deals with CB2 & int 0 is allowing int 0 through, even though we do still see the int 4. Investigations continue.

20th December 2014

• Still investigating card reader problem but still no clues as to the cause. Now using Johans logic analyser to investigate various signals and following logic diagrams