Keypunch mechanical issues addressed

New Year's Eve and kept pretty busy prepping the house for a party my daughter and son-in-law will hold for local gamers tonight. However, I was able to put in a couple of hours tuning up the keypunch. New Year's day, once all the overnight guests woke and left.  I was able to get back into the workarea and the 1130 for a while.

NEW KEYPUNCH INTERFACE DEVELOPMENT

I worked on the keypunch mechanism today, hoping to resolve several problems it has been evidencing. The first problem it had was inability to feed cards cleanly from the input hopper to the punch station. The second problem was failure to register at the read station when a card came out of the punch station. The third problem was failure to eject the card fully from the read station and move it up into the stacker. Finally, the read station card was not moving in sync with the columns of the card in the punch station.

I cleaned and adjusted the hopper feed mechanism. Several rubber rollers needed a bit of deglazing, to achieve approximately the same traction on both the left and right of the card. The original fault was skewing of the card as it was pushed down into the punch station.

Both registering at the read station and ejection to the stacker station are supported by metal rollers on arms that push down on the card to hold it against a rubber feed roller. The arms were not pushing down far/hard enough to cause the card to be moved across. I did some rough adjusting of the arm position and it fixed the eject issue easily.

However, the correct position appears to be very touchy, as each time I tried to adjust it, I either had the card registering well but unable to move through the read station on a release/clear, or it moved through the station but wouldn't reliably register. I will keep adjusting it until I get both registration and movement through the read station to work.

There is an official way to adjust this, which requires that the mechanism be partly rotated through a cycle until a cam reaches its high point, then a feeler gauge is used to measure the clearance to the roller. I don't (yet) know how to manually release and rotate the mechanism, thus I can't get the cam to the proper point to use the official adjustment method.

I believe the lack of synchronization between read and punch station columns is also caused by the same maladjustment of the arms, since the card has to stop in the proper place when registering, which depends on the pressure on that roller that is controlled by the cam. However, once the read station registration is working, I can check the card sync again to see if I have an independent problem.

I asked a fellow member of the 1401 restoration team at CHM about how to make the setting, as well as ways to follow the official adjustment process. Stan told me that he had to make the very same adjustment within the last few weeks on one of the keypunches at the museum. They did not use the official method, but did describe what worked for them.

It appears that I might have a wheel that is too small to work properly - the rubber wheel that the roller contacts, but if I can find a setting in between blocked release and failed registration, I can make do with this. If not, then there are a few spare wheels at the museum but a fair amount of disassembly is required to make the change, so I will avoid the change if it isn't necessary.

Based on the failure symptoms of the keypunch at CHM, fixing my adjustment problem will fix all the outstanding problems of my keypunch. I didn't quite get it sorted out today but I know this will be resolved soon.

Keypunch interface testing wrapped up, keypunch itself needs work

Our electrical utility, PGE, scheduled today to replace transformers serving my neighborhood, leaving us without power for a majority of the day. Got to work once I could, but progress limited as a result.

NEW KEYPUNCH INTERFACE DEVELOPMENT

I rewrote the parsing of the punch line and am now pleased with the code. The earlier implementation was clunky, easily misunderstood and complex to maintain. Testing resumed once power was on.
Routine worked very well, thus could blast through the tests and finish up the remaining steps.

Interface under final test

The remaining two issues I found may be mechanical issues in the keypunch, they both have to do with the card in the read station registering and staying in column sync with the card moving through the punch station. A few times when I tested the _R read command I found some erratic initial movement, often generating one or two false columns before reading the rest of the card.

Verify mode suffered from the same defects, thus the card in the read station was a couple of columns behind the punch station card (and thus behind the logic of the interface which times everything to the punch station card column.

At this point, I will close up the interface box with its current software, since it is probably working correctly, and turn my attention to rehabilitating the keypunch.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I opened the cable connector, but there were no wires disconnected inside. I tried to clamp the connector on the thick vinyl outer cover of the cable but it was very difficult to accomplish since the internal wiring inside the connector exerts tremendous back pressure when I try to compress all the twisted pairs. When they are in their rest state, the clamp is about one half inch past the end of the vinyl and could instead compress twisted pairs if tightened.

Cable not secured by clamp on connector

I need at least four hands, two to push the cable into the connector, another to twist the connector to make the clamp screws accessible, and the last to operate the screwdriver. I will try to get someone to help tomorrow.

I see a couple of female pins pushed in on the socket, not as many as the peak of problems I saw on prior removals but still not good enough to complete all circuits. Once I fix the clamp on the cable, and push the errant female pins into position more firmly, I will try to reconnect the cable again.

Keypunch interface testing almost done, but SAC Interface connection still dead

NEW KEYPUNCH INTERFACE DEVELOPMENT

I had one anomalous result in testing yesterday that I don't understand, so I instrumented the heck out of the interface program and will use the voluminous state output to show me where things are going wrong. I have the detailed test plan to finish up today.

I found and fixed several minor problems, as well as the one big issue which came down to a boneheaded programming move I made, reusing the same index in both an inner and an outer loop. Can't believe I didn't spot that in all the examining and refining.

The physical keypunch sticks in a clear cycle when I should reset once all cards are out of the card path. I suspect this is an oxidized contact on the cardlever relay, the one relay I didn't pull and clean up with the burnishing tool when I serviced all the others last week.

Really feeling good about condition of this interface. As soon as last step of test plan completed, this gets uploaded to a repository and shared, along with the interface design and wiring information. The python wrapper program to use this to punch decks or read decks from 1130 simulator files will be a good demonstration of flexible ways this can be used.

I decided to rewrite the parsing of the punch line to make the code a bit more straightforward, which pushes the completion of testing off until tomorrow.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I designed the logic to allow the PC to read and write blocks of core memory on the 1130, using the USB link to the SAC Interface box. Now I just need to finish fixing the problem with pins pushed out of the back of the 160 pin socket and get the USB link working again.

Well, I thought I had them all in but the interface remains inert, no sign of incoming signals and no recognition of my output signals. I did notice that the cable connector clamp had come off the cable, so perhaps some internal wires have come loose inside the connector. This is discouraging when I had gotten so far and was finally debugging and expanding the logic inside. 

Finding and fixing minor bugs in keypunch interface, problems crop up with SAC Interface

1053 CONSOLE PRINTER RESTORATION

I kept returning to the printer to search for the lost spring, but as of the end of the day I still haven't located it. As a backup, I crawled around on the floor extensively plus searched deep inside the 1130 just in case the spring took an odd hop outside of the typewriter mechanism.

The typewriter will sometimes fail to reset after a carrier return, attempting two or three before resetting the latch. I suspect that the lost spring is somewhere in the string of parts, levers and clutches that handle the CR, interfering with its proper operation, but even with that suspicion it is extremely hard to find.

NEW KEYPUNCH INTERFACE DEVELOPMENT

I completed the detailed test plan last night and set out to work through it step by step today. I discovered a parsing error which I corrected before resuming the testing early in the afternoon.
Progress was steady as I worked through my plan, identified and corrected problems, then restarted any steps where my changes could have an effect.

As the daylight faded, I closed up the garage, took a breather from live testing on the keypunch in order to correct a few anomalies I discovered and improve one area of the code that I don't like.
I will also put together a quickie Python program that will use the keypunch interface to read a deck of cards into a hollerith format or an ascii file.

I will use that to read in some small decks that I want to transfer to other enthusiasts. Once my stacker, release and autofeed are working more reliably I can attack some larger decks but currently I will be hand feeding and nursing the cards through the keypunch.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

Everything was ready for the next round of testing. When I removed the 160 pin connector to check the wiring to my interface boards, I discovered that a couple of female pins had been pushed into the socket openings, thus not making contact with the male pin on the cable. One of them was for B register bit 1, one of the signals that had been missing. I pushed them forward into place but given the high force used to seat the cable onto the socket, I have to hope that these are not pushed out of place again.

I found that even with a fresh day and load, I am unable to successfully read and write to the registers using the USB link. I don't know what is wrong yet. I rebooted my PC in case the drivers on the PC side or in the SDK had fouled up, but I suspect it is a more fundamental wedged state of the USB link. I have to understand the condition and build in a means of clearing it as part of the startup of my PC side program.

When I loaded the new logic configuration to the flash and brought up the 1130 with the SAC box, nothing worked. I didn't see any signals and my interrupt request wasn't detected. I leaned over to look at the back of the 160 pin socket and could immediately see several female pins pushed out of contact. Although every signal on the cable is a twisted pair, IBM didn't connect the ground wire on both sides of every signal. Instead, just one pin is used to link grounds.. If that pin is pushed back like several of the others, it would cause exactly this symptom.

My first task is to get all those pins back into position contacting the male pins of the cable. Given the thicket of wires emerging from the back of the 160 pin socket and limited maneuvering room as the box is assembled, this will take a bit of time. I didn't finish this by the end of the day today.

Steady progress on SAC interface box and new keypunch interface

NEW KEYPUNCH INTERFACE DEVELOPMENT

I had to partially disassemble the keypunch to clear a really bad jam, but once I did I could verify that the interface will correctly punch and read cards. The keypunch itself needs work so that it can register each card in the read station after it is released from the punch area, and to place the cards in the stacker at the end, and to autofeed blank cards from the hopper. That doesn't impact the interface testing and operation.

It is time to do a full and complete test of the code, validating its correct operation with all the features, functions, and conditions that will be encountered. I will spend some time tonight and tomorrow writing up a comprehensive test plan which I will execute.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I worked out the method for using the ISE toolchain Impact program to set up and load the flash on the FMC Carrier S6 board, allowing me to have the interface box come up automatically. I set it up this very cold morning in the bay area (cold for us, just a few degrees above freezing when I awoke).

My Python code is working well to display the incoming signals, looping every five seconds to display the B register, clock levels and status information. This was debugged using my spare Nexys2 board, but targeted for use with the board in the SAC interface.  I tested the ability of my code to open and access the registers of the FMC Carrier S6 board.

I was able to read for a couple of rounds then the python program began receiving address and data timeout errors, suggesting that my logic in the fpga was hung up somehow and not properly responding. Timeout recovery is missing from the fpga side logic, something I need to investigate and correct.

My initial testing showed me that I had improved the assignment of signals to lights but not totally correct. parts of the B register signals are offset or missing, and all the four interrupt level signals are the inverse of their expected state - when entering IL4, the light assigned to that state turns off, otherwise all four IL levels are lit when they should be extinguished. A simple matter to invert the IL signals, the rest takes some investigation and changes to the assignment spreadsheet.

I decided to pull the 1130 cables from my interface box and use a continuity checker to make sure I know what signals are handled by each circuit on each of the four interface boards. As well, I will check that the appropriate pin to the fpga stack is used for the circuits. With that done, I can create a fully accurate assignment spreadsheet, update the fpga logic and then be sure that I am looking at the appropriate LED when testing each signal.

Lack of a signal then indicates either a fault in my interface boards, in the cable, or in the 1131 itself. There should be very few such issues to manually trace, but I have to get the assignments correct before I have eliminated the most likely cause of any LED remaining dark.

I traced all the signals and came up with the definitive assignments of the cable signals to the interface board circuits. The sun had set so I went inside and began updating the spreadsheet and documentation. That took a couple of hours to carefully cross check everything. Once done with that, I turned to the VHDL and updated the logic to get the signals straight inside the fpga. It is now ready for the next round of testing tomorrow. 

Good progress on the SAC interface, clearing up assignments of incoming signals

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I spent some time in the morning working on two issues: getting the FMC Carrier S6 board flash programmed with the logic configuration, and figuring out how to access a string embedded in a structure using ctypes and Python.

Digilent just opened a forum for users to communicate with them and each other. I posted a query about the problem programming my FMC Carrier S6 board, hoping to hear back in a few days when the return from holiday shutdown.

I switched the system on and once again I had reliable behavior of the signals injected into the 1131. I began mapping the signals that correspond to the incoming state from the 1131, with a fair degree of success right away. The signals are all scrambled compared to what I think I am sensing but I could locate 14 of the 16 B register bits, all four of the T clock signals and the Phase A signal.

Two of the B bits didn't seem to change any of the LEDs, which must mean they are actually different signals into the FPGA than I think because of mismapping of connector, 1131 signal and fpga pin. If the pattern I detect from the 19 known signals is consistent, I can infer the remaining signals, correct all the assignments and test again.

I did find a pattern, although it has a few oddities. I will rearrange all the incoming signals to what makes sense based on the pattern, then do some testing. Updating the documentation is the really tedious task but has to be done if I am to have any chance of maintaining this interface in the future.

Changing all the documentation then updating the VHDL took all day, but it was finally done before I went to bed. Tomorrow I can validate the correctness of all the signals using the 1130. The basic method for validation is to:

• use Load mode to test the B register bits
• single step through the machine states and instructions to verify the T clocks and phase A
• execute an XIO instruction to validate XIOE1
• check interrupt level correspondence
• cause a parity error to validate parity stop
• verify clock out and meter out signals

Testing the cycle steal related incoming signals is more complex because the eight X clock steps can't be single stepped, they occur within a few hundred microseconds. I will change the use of a slide switch from triggering an interrupt level to commanding a cycle steal operation, which should show me the occurrence of the cycle steal L1 status signal as the machine loops continuously in cycle steal mode. 

On the flash programming front, I discovered that the Adept utility should recognize the FMC Carrier S6 board and present a Flash Programming tab. Since it doesn't know what board it is seeing, it doesn't give me the means to load the flash. I should be able to load the flash through Xilinx Impact in the toolchain, if I can figure out the proper settings and configurations for the tool. 

Limited time due to holidays but a bit of work on SAC Interface

Because of the holidays I didn't spend much time on the 1130, being busy with family. However, I did spend some time on the SAC interface and I bought myself an Intel Edison to play around with for some future aspect of the project.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I set up all the LED signal driving logic in the interface box, controlled by switch 0. When sw0 is off, the B register is displayed on the additional LED board. When sw0 is on, the additional LED board displays, from left to right:

• T0 cycle
• T2 cycle
• T4 cycle
• T6 cycle
• X0 cycle
• X2 cycle
• X4 cycle
• X6 cycle
• Clock Out (running)
• Phase A
• Parity Stop
• Reset
• XIO instruction E1 cycle
• Meter Out
• Cycle Steal Level 1
• Inhibit Cycle Steal Requests

The four user LEDs on the breakout board always display:

• Interrupt Level 2
• Interrupt Level 3
• Interrupt Level 4
• Interrupt Level 5

I worked with the spare fpga board (Nexys2) to ensure that the setup for reading and writing registers in the FPGA via the utility on the PC and a USB link were functioning properly. It worked fine, although the addresses and bits returned are reversed compared to the PC. I made a fix to swap the bits around end to end and got the results I expected. Based on that, I adjusted the SAC Interface board logic to ensure that I could access those registers via the SDK.

However, the erratic injection of interrupts was back, the on board LEDs didn't lite, and the LEDs emitted on the add-on LED board don't seem to correspond to anything useful. Something odd going on here, plus I don't yet know how to load the configuration into flash for automatic bootup.

I spent a bit of time working in Python to access the registers from a PC. This will be the heart of the virtual peripherals I will implement in the interface, but I have to get more familiar with the Adept SDK, the hardware system for USB communication, the ctypes mechanism in Python to call c libraries and other details in order to create solid code on the PC side.