Rescue 1130: 2014 Pickup of an IBM 1130 System and More: Disk drive seems to be working well now, plus working further on card reader

INTERNAL DISK DRIVE RESTORATION

I wired up a manual switch temporarily in place of the 90 second timer relay, in order to attempt loading the heads and seeing if the drive would go to File Ready status. The heads loaded well when I used the switch (waiting out the 90 seconds each time), but no ready status. I loaded some XIO instructions into the 1131 and executed them.

Temporary switch to act in place of 90 second delay relay

First, I did a sense of the disk drive status, receiving a DSW that showed file not ready, data error, home cylinder and a sector of 2 currently under the heads. When I reran that several times, the DSW never changed including the sector number, which should be randomly distributed over the four sector values 0, 1, 2 and 3 since the disk is continually rotating.

Drive open and ready for testing

Out came the oscilloscope as I methodically worked my way through the gates and signals that are needed to put the disk in file ready status. I watched the pulses coming in from the rotating spindle, plus the index and sector pulses were being detected cleanly. The head load switch should activate when the heads are dropped down to flying height and it was registering that event cleanly.

Inserting disc cartridge into drive

Cartridge loaded, ready to switch on

To move to ready status, the drive has to think it is rotating at least 1050 RPM out of the target speed of 1500, that there was no latched up write error, and that the heads are loaded - all of which I confirmed as true by scoping the various signals.

Heads in place over spinning cartridge

Then I looked at the file ready status, which was in fact showing that the drive was good with file ready status on. However, I saw that this was not getting through by a glance at the 1130 keyboard where the File Ready light was dark and the DSW still reported a not ready condition,

another view of platter inside

I looked at the bit on the disk drive backplane where it entered the signal cable running down to the 1131 file adapter logic - it was in correct status. That told me the problem was not inside the drive, but in the cabling or logic in the 1131. I moved the oscilloscope over, swapped logic manuals and set into some methodical checking at this end - in gate A, compartment C1, where the file adapter cards reside.

Heads flying on surface of platter, at cylinder zero

The File Ready lamp is off because the signal tells it so, no problem with the bulb itself. The gate in the file adapter that tracks ready status is conditioned on some error conditions they adapter can set, so I checked those out. No error conditions on, but file not ready status. Backing up, I went to the entry pin where the cable from the disk drive is hooked into A gate compartment C1. The signal remains off, even though I see it going on in the disk drive. This is a cable issue of some kind, so out came the continuity checker.

There was no connection between the pin in C1 and the pin in the disk drive for the file ready status wire of the cable. Opening the card cage, I looked at the back of the signal cable - the one which had been repaired since the plastic grid separated from the contact fingers when I first removed it.

To my chagrin, I found that the cable was plugged into socket B2 of the backplane but the correct socket for the signal cable was just above, in A2. Aha, that explains why the sector number didn't change, as well as the other symptoms. I pulled the cable from B2 and carefully inserted it into the A2 position. Once it was clamped down, my continuity tester verified that the signal was now reaching A gate compartment C1.

Powering up, spinning the disk cartridge, waiting 90 seconds and flipping the 90 second timer bypass switch resulted in an immediate File Ready lamp on the 1130 keyboard. Excellent, now time to try out a few operations.

File Ready is on! Disk can be accessed now

I went back to my XIO commands I had entered in memory and first executed the sense operation. The DSW returned exactly what it should and when executed multiple times, returned randomly changing sector numbers.

I then ran the XIO to command a seek of a few cylinders - it was accepted and the processor attempted to branch to the interrupt handling routine for level 2 interrupts. This is exactly as it should be, which a sense DSW confirmed by a operation complete status bit. I put in a larger seek count and did the movement command, hearing a satisfying buzz of the long seek emanating from the disk drive.

I did some reverse seeks, which also worked fine, then powered down the drive. It first retracted the heads to the home cylinder, as it should, before dropping the motor. Once the spindle stopped rotating, the Disk Unlock light went on.

At this point, I went from careful step by step mode to a big leap. I put in a cartridge that held the DMS (disk monitor system V2), found a cold start card to put in the reader, and did a program load of the card reader. Alas, the reader got a check condition each time and worse, the cold start code didn't work properly.

I stepped through the code in locations x0000 - x004F and found several places where wrong bits were read, just like the problems I encountered yesterday with the one card diagnostic card three. I tried quite a few times but the 1442 is not working well enough to reliably boot load clean contents of a card.

I dug out my files with the layout of the cold start card and fixed up memory to match what should have been there after the program load. Once done and verified, I ran that code with my DMS2 disk ready. It never got to the point where it moved the disk arm or read the boot sector. I stopped with a parity error as it was reading the console bit switches. This is suspiciously like the errors I get with some diagnostic cards when I boot load them from the 1442.

I decided to go back a few hundred steps, coding in an XIO to read the a sector from the disk as a much more basic check of functionality. It is probably a good time to move to a general checkout of the read and write interfaces to peripherals as I seem to be experiencing problems in this area with multiple devices.

My simpler hand coded routine to read the disk cartridge worked very well. The drive starts at cylinder zero, where when I read sectors 0 and 3, the first word of each was reliably the sector number. The data words in the first sector were 0658 0658 0658 0658 . . . which is what should be at the start of the disk. The first four words are the addresses of bad sectors on the disk, but if there were no bad sectors detected then the address is 0658 (the spare sectors).

I tried the other head as well, which also picked up good data from the drive. I did some seeks - first to cylinder 1 where I read a sector, then another 63 cylinder out

with a satisfying buzz. I then did a sense to verify that the home cylinder bit was off.

Lastly, I moved back 64 cylinders then did a sense which did show we were now back at cylinder 0, the home cylinder. I shut down the disk and turned my attention to the console data switches. XIO commands to read picked up the proper value each time I tried it.

As a final test for the night, I coded up some card reading instructions. When I put in a normal data card and started the reader, I saw a check on the reader and a parity error on the processor itself. It took a bit of time to set up the interrupt handler routine that has to read each card column as the interrupt comes in on IL0, sticking the column into memory and bumping up an index. I think the code was working right but didn't have time to diagnose the parity error and check situation any further.

1442 CARD READER RESTORATION

I spent a bit more time working on the reader, polishing the cornering station and working out old grease in the mechanism. One of the deficits I face right now is that the indicator panel that shows the type of check condition uses the same bulbs with the fragile wires, most of which are not working. Once I replace the lamps in this panel I will know more about the type of check condition we are encountering.