Sunday, September 21, 2014

Disk drive seems to be working well now, plus working further on card reader


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.


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.

Lamps that need replacement behind status panel in reader
Cornering station, not polished and shined enough yet
Clear plastic lid on cornering station, also not slick enough

Saturday, September 20, 2014

Time with the card reader, running one card diagnostics and adjusting its operation


I received my grease gun accessory kit with a plethora of adapters and fittings, however not a one is useful to get grease into one grease nipple on the card reader which is placed to allow virtually no clearance around it for the grease gun fitting.

My reader will very reliably pull the cards into the pre-read station and go ready. It seems to read them well - I have booted five of the one-card diagnostics and they appear to read into memory properly. I stepped through memory after loading the cards and it all looked good - words 0000 to 0050 matched the card columns as read in boot mode.

When in program load mode (boot mode), the card reader will create a 16 bit word from the 12 rows of each card column: Rows 12, 11, 0, 1 and 2 become bits 0-4, bits 5-7 of the word are forced to zero, row 3 is copied to both bits 8 and 9, and the remaining rows 4-9 become bits 10-15. As each column has been read, it is placed into the next word of memory, beginning at 0000, until the end of the card is reached. At that time, the processor begins executing the instruction at 0000.

What is not working is the cornering station, specifically the injection of a card to the rollers for the stacker station. I have polished and shined the metal plate and the plastic top lid fanatically, but there is still too much drag for the card to slide into the rollers. Peter Vaughan at TNMoC found the cornering station to be the most challenging part of the card reader, which itself was the most challenging portion of the 1130 to restore. I concur.


After installing my reader cable, I duplicated and punched some cards which validated that my changes had no impact on correct operation of the keypunch in standalone mode. The connectors I bought were not the correct size, keeping me from moving forward with the punch cable installation.


My testing resulted in a few error stops, but those would work properly if I reset and reran the same code in memory or reloaded the card. However I also experienced the machine failing with parity checks at a few locations. This seemed to be related to a problem as the reader loaded memory during the program load.
A page from the documentation for the one card diagnostics
For example, test card 3 loads and appears to be fine, except that one of the words that should be 0x4820 (a conditional skip instruction) is displayed at 0x5820 with a parity error due to the extra bit being on. If I manually alter that word back to its intended value, the test program completes satisfactorily. Each time I loaded the card, it got the error in the same place.

I then used the keypunch to DUP the card, thinking that some teeny variation was causing the problem, It might have been, because the duplicated card failed at a different location, not the original one. Curious. Each write from the reader into core memory should have had parity correctly set by the 1131 circuitry, regardless of what comes in from the reader.

Test  cards 1, 2, 4 and 5 loaded and ran well most of the time. Any time I experienced an anomalous result, I would rerun the code sitting in memory, going to single instruction or even single step to check its operation. The code always worked properly in those stepped modes.

Five of the one card diagnostic programs
As an example of a problem that did not occur in stepped mode, one of the programs will run through 1K of memory storing a specific value in each word, then check that the proper value was there. The card boots and stops at the address 0x1000, as it should. The instructions are to hit RESET and then PROGRAM START buttons.

When I hit the two in sequence, it stopped with an error asserting that a word did not have the proper value stored. When I single stepped, it looked good so after checking a few passes, I put it into RUN mode and let it complete - with no errors.

It is possible that the RESET function is not totally reliable, or that some part of it is so slow that it isn't in the proper state when instructions are fetched at normal speed. Speculative and I haven't really done a lot of troubleshooting to figure out what is happening, so probably not close to the real situation at all.

Once I have the card reader's cornering station working well, I can read more than one card at a time. That will allow me to load a diagnostic monitor and some substantial diagnostics to really shake down the system.

Friday, September 19, 2014

Booted diagnostic card from card reader, diagnosing failure of disk drive to load heads, wiring work on new keypunch interface


I polished up and cleaned the metal plates and plastic covers for the various stations where cards will sit. This was enough to get the reader to reliably load a card into pre-read and turn on the ready status. I stuck in a one-card diagnostic which I had laboriously punched out on the manual punch before I received my 029, readied the reader and hit the well known three key sequence on the 1131 - imm stop, reset, and prog load.

The machine booted in the card and ran the program. The program was sitting at its first wait condition where the operator confirms that the step worked properly, then allowed me to push start and continue through subsequent steps. This validates a considerable fraction of all the card reader circuitry both in the 1442 and in the 1131.

The cornering station, where the cards will stop before being accelerated forward into the stacker assembly, is still a problem. I had polished the plate and plastic, adjusted the height of the plastic lid, but there is still way too much drag on the card. I will repeat my polishing and cleaning until the card slides with similar resistance to that experienced in the pre-read station.

I implemented the extra switch to override the hopper empty switch, based on an excellent modification developed at The National Museum of Computing in the UK when they were restoring their 1130 system. I hid the switch behind a blank button, but when I pull the button cover out, I can easily flip the switch. This allows me to inject streams of cards using the NPRO function, a good way to validate the quality of the card movement inside the reader.

Panel, with my added switch hidden behind white blank button

Button revealed, allowing override of hopper empty condition for NPRO

The internal disk drive will spin the cartridge up but never loads the heads down onto the disk surface. If I manually move the solenoid to load heads, it will latch in and the heads seem to be flying well, but I had to figure out what conditions were not being satisfied to do the loading. I began with the oscilloscope where I quickly saw that the 90 second timer was not going off.

Logic card cage in disk drive, where I traced signals with scope
Testing the time delay relay and learning it never energizes
The timer is a relay that is powered at the same time as the motor is started. The relay continues a transistor and an RC circuit to cause it to wait 90 seconds before it energizes. However, it is not energizing at all. I removed the relay and did further testing to see what was wrong and whether I can correct it.

Time delay relay that is not working
After looking it over, particularly considering that all this relay does is break a signal connection to ground, to allow it to be pulled up to logical 1, I decided to find a replacement time delay relay. It need not be a direct substitute as long as it works with 48VDC power, can be set to 90 seconds and will open a circuit once the time has expired. I found a unit online and have it arriving Monday.

taking relay apart
timer circuit

K2 is the time delay relay, will replace with different type

I began assembling the cable with the appropriate pins and connectors to install it onto my keypunch. I don't yet have all the connectors I need but they are coming later today, after which I can resume this task.

The reader cable, which senses the absence or presence of holes in the 12 rows of the current card column for the card going through the dup station, was connected solely to the relay panel and I had enough push-in pins to finish the wiring. After soldering the connectors to the appropriate wires from the DB-25 cable, I installed it onto the logic gate.

connectors on to the wire on the cable
Reader cable installed

Wednesday, September 17, 2014

Relatively quiet until Friday 9/19 but a bit of progress on several fronts


The National Museum of Computing in Milton Keynes, UK has a restored 1130 system and I have been the beneficiary of all the experience they amassed during the effort. Peter Vaughan has been sending me detailed descriptions of what they discovered, how they repaired or adjusted it, and other tips for a successful restoration. Yesterday, Peter send me a long email with advice about the 1442 after reading my posts.

His reader also had most of the rotating steel wheels semi-frozen due to congealed grease and used the same persistent gentle working of new lubricants that I did to get the turning. He pointed me at two that I may not have seen, underneath the punch unit out of sight.

My reader pressure roller, a metal roller that is attached to a rotating lever assembly under strong spring pressure holding the roller against a rough rimmed large wheel underneath the card path. The two wheels pinch the card between them, while the rough rim provides the leverage to keep the card moving forward. I discovered that this wheel, even when the old lubricant is replaced, grinds and rolls unevenly. I believe a bearing inside is broken.

Metal roller wheel on this lever arm, riding on rough wheel surface below, but bearings are shot
I can see some signs of wear on the roller wheel surface that shows this failure started while the reader was still in service back in the 1980s, as the wheel bearings progressively got worse. The wheel is not designed to be removed from the lever assembly, unlike most of the metal rollers which have a circlip holding them on an axle.

I expect I may have to grind the end of the axle to release this damaged wheel, find a compatible substitute from a source like Graingers, and invent a way to secure the wheel on the axle when I replace it.

The other area where I was seeing problems was the cornering station, a spot where the card enters while moving from right to left through the punch station, stops, and then is propelled from back to front in a ninety degree change of motion. The card sitting in the cornering station would not start moving forward into the stacker area, but when I partially opened the top cover to release some drag, it worked fine.

Cornering station where card arrives (from top in this picture), stops, then accelerates to stacker (right in pic)
Metal surface needs to be well polished and under surface of plastic must be clean and slick
Peter noted that these areas with a clear plastic top cover over a polished metal bottom plate are highly dependent on good polishing and cleanliness otherwise drag increases until the card motion is impaired. I have to use a metal polish to get the bottom plates very shiny and slick, as well as use my IPA or similar cleaner on the clear plastic top covers so their under-surfaces are also slick.

They came up with a very clever modification that helps with testing. Normally, the NPRO function will only operate when the card hopper is empty, but the other functions that move cards will stop on many check conditions that we are trying to debug and fix. By putting a switch in the hopper empty circuit, we can do an NPRO while cards are sitting in the hopper.

This is helpful because the NPRO will pick a new card on each cycle as it moves the existing cards in the mechanism one station forward in the same cycle. If it works right, I can empty a large pile of cards one by one through the machine at a decent speed by pushing NPRO while the 'TNMoC' switch is activated.

The very detailed and helpful email from Peter also detailed all the grease fittings, which I will double check to be sure I forced new grease into all of them. Without new grease, those will not operate correctly.


I met with one of the other designers and discussed some alternatives related to the new interface, Stan Paddock at CHM. Stan found that a standard push on lug he had in his supply bin was a perfect fit on the SMS socket pins for the keypunch. This complemented my discovery two days ago that the Molex male pin for the .062" series connectors was an excellent fit for the relay panel holes. Now we have sources for the hardware to make up the cables and connect to the keypunch logic gate.

Push on connector that works on SMS socket pin connections
Backside of the standard connector

My latest eBay purchase, a CE cartridge for use with the 1130 internal disk drive, arrived tonight and I did an initial inspection. I see some marks on the surface on the path traced at specific cylinders - one dark track on the top and two on the bottom of the platter, separated by about 3/8" of radius from the center of the platter. They appear only at those three locations and to a first quick look they seem constant all around the platter.

My CE Cartridge arrived
Platter surface, hard to see due to reflections
Another view, some dust that is easily cleaned off surface
Trying to capture the darker tracks
The other surface, same constraints but twin lines are visible near upper third of the lower white area
Top picture attempt with different conditions
When I get good surface picture, it isn't far enough back to show marks
Reflections and blurry too
Final view
Until I can look much more closely at the dark traces and see whether they are raised, grooved and importantly if there is a hard particle embedded somewhere around the track, I can't assess whether the pack will be okay to use for its alignment purpose. If these are further out than cylinder 105, I need never put the heads over them. For alignment purposes, cylinders 95, 100 and 105 are used, while all the rest are superfluous but available for temporary use and testing

I will use my 99% isopropyl alcohol and lint free Kim-wipes to clean the disk platter, then inspect as well as I can. I may have to open the cartridge and check it while apart, it depends on what I can observe and clean using just the opened flap.

Tuesday, September 16, 2014

Progress on card reader, internal disk, keyboard, display panel lamps and keypunch interface design


I reassembled the button/light control panel on the card reader and began to examine the mechanical state of the device. I discovered that two steel rollers under the rubber drive wheels that pull cards forward into the stackers were frozen with sludge inside the bearings. I added oil and loosened them up.

Still more to go before this reliably pulls cards to the stacker but it is almost working right. If I loosen or lift the plastic cover over the station where cards turn into the stacker, the cards are taken. That means that I have a bit of resistance to movement or a too little pull to make the cards move.

I turned to the check condition as the cards enter the read station and found that another of the metal rollers was frozen. This one is the read pressure arm roller which holds the card against a rough edged wheel that drags the card through the read station. The roller is very rough when it turns, sounding like a bearing is damaged inside the little wheel. The wheel is not designed to remove from the arm, instead the entire arm is the replacement part.

I won't find the spare part and will have to repair this arm myself. I will check with the TNMoC museum in the UK, who have a working 1442, to have them verify the read pressure roller should be smoothly rotating. A replacement roller with bearing will have to be located using a supplier like Grainger, the bad one removed and the new roller fasted on. This may require drilling off the end and implementing a new fastener on the end of the axle.


Today I dropped the heads onto the rotating disk surface. They flew well, no scratches or interference at all. With the interface cable disconnected, I was able to move the arm in and out using the CE switches on the back of the drive. However, the drive won't load the heads automatically nor does it switch to file ready status when the cable is reconnected.

The solenoid has hold current continuously while the spindle motor is under power, but the pick current is needed to pull the solenoid slug in, after which the hold current is enough to retain it inside the coil against the pull of a return spring. When hold current drops,the arms leap up away from the disk platter surface due to the return spring.

The pick current is driven from a logic card when a set of conditions are all true:

  • Expiration of a timer that waits 90 seconds from initial motor start to let the disk stabilize
  • The carriage is at the home position (cylinder 0)
  • The spindle is rotating no slower than 70% of target speed of 1500 RPM
  • Heads are not already loaded onto the disk surface
To move forward, I will have to hook up the oscilloscope and determine why we aren't driving the pick current. I suspect it will be a simple single failure, much like the failed Start switch on the card reader. This pick logic is contained with the disk drive, operating whether the interface to the CPU is connected or not, thus my debugging will be focused on the small card cage on the side of the disk drive.


I received my relay boards and Arduino, as well as the DB25 cable. Looking at the relay boards and the logic gate of the keypunch, I immediately saw that the boards could be mounted on the gate, with short and appropriately thick wires. The wires inside most DB-25 cables is intended for low current signals and is marginal for driving punch solenoids.

Relay module, one of two used in the keypunch interface
Almost perfect fit for relay over these openings, with standoffs through holes
The team is working with an objective of backwards compatibility to the 026 and 029 that are already wired up at CHM, thus planning to hook up DB25 cables to the keypunch circuits and plug into a DB25 receptacle on the new interface box. However, at least for my own keypunch, I am going to set up the relay boards on the logic gate and connect only signal/control lines to the Arduino. Perhaps I can convince the team to switch to this approach.


The keyboard on the 1131 processor is an 029 keypunch keyboard with a very simple interface. An IO instruction is issued to select the keyboard, which turns on the Select lamp to the left of the keyboard and waits for the user to enter keystrokes. The keyboard responded to the command, select turned on, it turns off when you do a read command, however the area where I requested the data was always zeroes. Further, pressing the interrupt request key should raise an interrupt condition, but it did not.

I have some debugging ahead for the keyboard and control logic circuits. Another case where I will use the scope to see what is occurring including any missing signals.


I opened up the display panel, with new bulbs in hand, and went through the slow tedious work of replacing bad bulbs and securing the lamps firmly in the separator grid behind the front panel. The new bulbs are very cheaply made, but at least they work properly when installed.

Latest batch of lamps are low quality manufacturing
I found that one bulb that had broken off last time was still inside the separator grid, blocking the new bulb and its entire row from seating properly.It took a bit of careful slow manipulation to get the old bulb out, but once that was done the strip of lamps for the D (Arithmetic Factor) register was set in place.

I then worked on the last two rows, the A (Accumulator) and X (extention) registers. Alas, when I turned it on, there were a few dark spots and they were spread across multiple of the registers.

I took the front panel off the plastic grid, although that didn't really help in particular way. I worked for two solid hours trying to get the left side (six major register) all lit up and have them wedge in solidly into the plastic grid. It didn't work. For two of the bulb sites, I couldn't get the bulb to work. One of them appears to have a dead SCR driving the lamp, probably shorted out sometime in the past. The other was less conclusive but likely that is the problem,

Front panel removed
Back of the front panel, where it is secured to the plastic grid
Plastic grid into which the panel installs - lamps barely visible
For a break, it was time to pull out the strips that illuminate the clock cycles, machine state, op codes and other status information on the right half of the display panel faceplate. I was able to get them all working correctly and all reseated firmly, unlike the bane of my existence, the left side registers.

I threw in the towel for the night at 10PM, with five bits still dark. While three of them could simply be loose connections or dead bulbs, they could also be bad SCRs. The lower three register strips are very loose, so that touching one of them tends to dislodge the other two strips so they slide back away from their assigned openings.

Monday, September 15, 2014

Core memory stuck bits fixed, work on card reader and miscellaneous other work


I only had a few hours tonight to work on the system, but made the memory issue my top priority. I set up the scope and dove into the memory operation again. For some testing, I had to connect twisted pair cable with proper termination at the scope, where I displayed the differential by inverting and adding one channel to the other.

More scope testing
The inhibit bits going into the sense/inhibit card for bits 1&5 were working perfectly, responding to the state of the console bit switches. The sense output of those bits were always coming out as 1, even though the card was told to inhibit (i.e. keep it zero). Since the card was swapped without changing the symptoms, any problem has to be off the card.

I pulled the card and verified continuity on the sense/inhibit wire through the core stack. I checked that all the control pulses arrived at the right time. Everything looked right but the bit was flipping on regardless of the state of the inhibit line.

I shut things down and went through some continuity checks to verify voltages and signal quality. One of the inputs to the card is called 6V inhibit 1 & 5 but it isn't timed, it is a steady connection from the 6V line to all sense/inhibit cards at all time. I checked that the two cards handling bits 1 & 5 for the low and high 4K of this compartment were connected. Then I checked to see if the pin was also connected to the 6V inhibit voltage on the sense/inhibit cards for other bit pairs. It was an open circuit!

The card was not getting the 6V supply to drive the inhibit current, thus allowing the bits to flip on. I checked thoroughly to verify that all the other sense/inhibit cards were mutually connected. They would all have access to the 6V supply, but the cards for bits 1&5 were isolated.

I then moved over to the A1 compartment holding the second 8K core stack. The exact same fault existed on that board - the two cards for bits 1&5 were isolated from the 6V supply. I then thoroughly checked the other cards to ensure they had 6V supply, but found another pair that were isolated. The cards for bits 11 & 17 for the low and high 4K of the core were also isolated. I had noticed that bit 11 was stuck on in the high 8K but didn't see bit 17 because that is one of parity bits.

Now I had the cause and could correct it by bridging those isolated card pairs over to the 6V supply from adjacent cards. Now the light bulb went off. These were the locations where my machine had three red jumpers. The jumpers I removed while troubleshooting the one bad addressing card. The jumpers I removed right about when the problem of the stuck bits began to manifest.

One of the jumpers was connected to only one pin, the other end dangling. The other two were connected to the same pin of the two cards in a pair, which showed as connected on the backplane. This was the reason I believed them to be nonfunctional and just stowed there for convenience. As well, they didn't look like they were a permanent fixture for the machine, which I would have expected to be done with wire wrap and annotated in the ALDs.

I didn't put the jumpers back where I saw them, but I put one for each of the three isolated card pairs to bring it 6V from a working adjacent sense/inhibit card. When I powered up, the memory was working flawlessly (other than the 1K missing due to the bad addressing card I still have to repair or replace).

It wouldn't have worked properly even if I had left the jumpers as I found them, since one of the three was hanging loose on one end. However, in hindsight I could have zeroed in on the problem quicker than I did.

My two core storage backplanes have a fault in the internal traces, one that interrupted a steady voltage used only for inhibit. If the main voltage lines had been interrupted, none of the logic on the card would have worked, but this particular failure was with a special feed.

Since the jumpers work, I will make a more permanent fix using a hand operated wirewrap gun and a special color of wire. I have annotated the ALD page for the voltage distribution inside the core memory compartments.


I found that Molex .062" connector male pins work well in the serpentine connectors on the relay sockets. I will solder these to the DB-25 cable wires and push them in place to install. I still need to find a good friction fit connector to use on the SMS card panel, then I can install the connections into my 029.

We are discussing the details of the protocol in order to get it finalized, after which I can begin coding the Arduino.


I spun up a disk with the interface cable removed, looking over the operation of the drive without putting the heads down at flying height. Everything looked good, but I wasn't ready to risk the heads just yet.
Heads in position over rotating disk, but not lowered to flying height

Closer view of the heads straddling the rotating disk platter


Now that the processor is working, I can get back to the peripheral restoration. I hooked up the card reader cables and brought up power. The reader will clear cards (NPRO function - Non-process run-out) but wouldn't pull in a card or go ready. I brought out the scope and the ALD to start the debugging. First up, verify that the start button is operating and that the hopper empty switch recognizes that cards are sitting ready to be fed.

Terminal blocks connecting the button/light panel to the logic cards below

Hopper empty works, but the start button is dead. I opened up the unit, tested directly at the switch, but still nothing. Contact cleaner spray and worked the switch many times, but it wasn't going to work. Fortunately, there is a spare switch that was used for the local modification to add a Program Start button on the reader.

Back side of light/button panel, the failing switch is in the middle of the picture, near the bottom
I moved the good switch over, hooked it up, and the reader now feeds the card and drops into a check condition. The various warning lamps in the reader are the same bulb type that is used in the processor display panel, so they also crack off at the slightest touch. I can't tell what type of check is occuring, but I see that the card was sitting in pre-read with the lamp illuminating the edge of the card.

These readers have a variety of error checks that look for when all rows are blocked, when light is visible (e.g. holes in a column or the card is not in place) and relates that to the rotation of the mechanism. If the machine reaches a certain point but light is or is not detected, depending on the error, the machine stops with a check condition.

I can figure out what check we are getting by using the scope, plus I can watch and observe the exact conditions being experienced. It will just be a matter of time to step through, find any issues and get them fixed.

One mechanical problem I can see is that the stacker rollers that move cards from back to front along the left side of the machine are not turning. When I activate the NPRO function, the card gets to the left rear but then doesn't move forward. This may be a clutch, belt or something else mechanical. I ran out of time tonight but can continue this debugging until I get the reader operational.

Sunday, September 14, 2014

Extensive diagnostic work on core memory stuck bit problem, work on console printer and keypunch interface designing


Time to switch over from the Tektronix 7000, versatile as it is, since it does not have a storage function. Up until now, the signals I was debugging were steady or happened periodically and frequently allowing them to be seen on a continuously tracing scope.

Now, I will be looking at events which happen only at certain points and triggering on the signals which are shared across several hardware units will give me too many false images. I need to trigger only on the desired events and I need to store it and display it in human timescales. Out comes the Tektronix 466, a more limited machine but one with storage capabilities.

Tektronix scope with storage to watch one-time events
I will leverage the CE card installed in the machine to combine together signals as necessary to trigger the storage scope. For example, to scope one of the four sections of memory, I need to combine the Write Cycle signal with the two addressing bits that match my targeted memory, to ensure the scope stores a signal for the relevant hardware I am checking.

The CE card is installed in the A gate, not over by the D gate where core exists, but the signals I need exist over near A, actually in B, or can be recreated from accessible signals there. Some jumpers to bring signals to the inputs of gates on the CE card will give me an output that goes high or low at the appropriate times. That gets hooked to the external sync of the scope, to trigger a storage event.

Gates open to left rear, scope and ALDs at hand
After about an hour of checking the core storage logic with the scope - watching the Short Time and Long Time signals, the strobe pulses, inhibit timing and the rest, it seemed very healthy. I then turned to the stuck bits, focusing on bit 5 as one of the problems and bit 3 as a control since it performed normally.

Bit 5 definitely misbehaves, having a short inhibit effect even when the B register value should be zero. This is why it is flipped on, because that short interval drops the inhibition current enough that the magnetic flux flips the core to the on position. No such phenomenon occurs on the control bit, bit 3.

I took the signal all the way back to the first pin where it enters logic gates and the anomalous dip is still present! I then moved the probes over to the B register itself. That dip occurs because something is setting the B reg bit 5 on for a short portion of the cycle! B reg bit 3 doesn't experience this. I then watched both sides of the flip flop, normal and inverted output, to get a sense of whether this is a flip flop problem or logic issue with the inputs. The bit 5 and inverted bit 5 signals are perfect mirror images.

Exciting news - the stuck bit issue is caused in the processor or peripheral adapters, not in core memory. I am not saying that this rules out any core memory issues, but the major problem of the stuck bits is driven from outside the memory gate and that will mask any more subtle issues.

Back to the wired common pin issue, undoubtedly, as some input bit or control signal to B register is awry and many of those are the 'dot or' circuits which take a while to spot the culprit. I took a break and prepared a plan for scoping the various signals inside and into B register bit 5. I will find the trail of the miscreant circuitry, although it may take more tracing back through other 'dot or' junctions to get to the root cause logic.

I did  the first tests based on the forced bit logic used for interrupt handler entry, since that logic sets on bits 1 and 5. However, I didn't rule out anything at this stage as it is time to relentlessly down hunt the errant signals without shortcuts.

Forced branch - no. Card reader - no. Printer - no. SAC - no. Console printer - no. Keyboard - no. Disk drive - no. It appears that we are getting a blip from the sense line which is triggering the B register bit on. Still don't know why, but it does turn my focus back to the core memory.

Some nuances of the situation I noticed might be a clue to the problem. First, when I power on the machine, there is a delay of about 2-3 seconds before the bit goes high. Second, when I start the CE Storage Load operation with all the data switches off, I can see bit 5 flickering on and off. Flip that switch up and it goes solid, turn it off and we are back to the flicker. While bit 1 is off steadily, if I turn the switch on and then turn it off, bit 1 begins to flicker as well from that point forward.

Since these are the same sense/inhibit card, but four of them, each for a 4K block of memory, I swapped the card for bit 1/5, one block at a time. None of them made any difference to the behavior. I am going to stop the power-on diagnosis tonight, picking that up tomorrow or when I can next get to spend time on the project.

It's time for more continuity testing, checking voltage, and noodling about what common circuits could account for all this. Whatever happened began back when I was working on the first problem, which was only a memory addressing problem - might be a physical issue I caused when moving cards around for that diagnosis. I can look at everything with this in mind as well - what I might have impacted without noticing.


Last night I ordered the Arduino Mega 2560 and twin 8 relay boards for the new keypunch interface, as well as a DB-25 extender cable. Once I get the push in plug ends and friction fit clips I need to properly connect the cable wiring into the keypunch logic gate, I will begin installing the cables.

I made a few more design decisions and worked on a draft of the installation instructions for the interface. The protocol has to be finalized, thus I should build up a comprehensive draft and circulate it to the other designers in order to reach an approved specification. Coding of the Arduino can't be completed until we have the protocol and functionality agreed.

To help in the conversions and also to help sort out a mis-wiring that exists in the 029 at Computer History Museum, blocking the duplicate function, I have created a set of charts which show all the wires connecting to each relay contact point and where they go. Using a continuity tester and the chart, we can figure out what has to be changed to repair the CHM 029. This took me about four hours all told, between building it up and cross checking it.


I have ordered the correct (this time) ribbon shift tape, since the part I first requested was for a narrower platen model and therefore too short. It needs to be roughly double the width of the typewriter frame plus 10" for the vertical run. Different platen widths require double the tape to add double the additional width, The tape for the 15" platen is therefore 8" longer than the one for 11" platen machines.

The tape runs from the carrier of the typewriter to a pulley on the right side of the typewriter frame, reverses direction and runs back to one of a pair of pulleys on the left side of the frame, proceeds directly down to a solenoid at the bottom left which has a pulley on the end of the armature, reverses direction upward to the second of the pair of pulleys at top left, then heads to the right back to the carrier, where it bends around a pulley on the carrier to run towards the rear of the carrier to hook to the ribbon lift mechanism.

Still haven't reattached the spring that connects between the cycle control latch and a fixed upright deeper under the mechanism. In some ways, this is akin to arthroscopic surgery - can't fit my hands or even fingers in where the spring attaches - and I have to be clever enough to invent a method out of the tools and facilities at hand where I get hold a spring, bend the end and insert it through a small hole in the fixed plate. Two or three tiny hand-analogs will be required, all of which have to fit down a small tunnel and are restricted to movements that can be made within that tunnel.

I leave the reattachment task on the back burner, waiting for the muses to inspire me with a solution (or, if you prefer, waiting for the right hemisphere and subconscious to work on the problem until they are ready to announce a possible solution).

My first hand cycle tool snapped off due to excessive resistance as I was rotating the mechanism; this is a safety feature but a nuisance as I have to extract the threaded end from inside the hub before I can install my replacement hand cycle tool and get back to coaxing the old grease to give up. If it weren't a nuisance to detach the printer cables, I would have already picked up the mechanism and given it a good bath of solvent to wash away all the solidified old lubricants.

I finally invested the time to detach and extract the cabling, allowing me to move the 1053 away from the 1130 and therefore can give it a solvent bath. The best solution would be mineral spirits, but they are outlawed in the bay area. The eco-friendly alternatives are of unknown chararacter as far as damaging motor winding enamel, plastic parts, contacts, or other parts, nor is it clear if the solution is going to evaporate with almost zero residue.

1053 out on table ready for more thorough cleaning
Cable and connector ends that are now detached from 1131
While I look for the right immersive or spray solvent, I did some more oiling and gentle working of the moving parts, trying to get everything freed up.