Saturday, November 22, 2014

Visits with 1130 and 360 restoration/replica building peers in the UK, plus development of fpga logic for the SAC interface


I threw in a few hours of coding on the FPGA, during the train ride from London up to Bletcheley and back plus a bit of time in my hotel room. I hope to have enough to begin testing when I get back and hook up the interface boards to the Xilinx breakout card and new fpga board.

At each step as I code it, I realize ways I can generalize the design a bit more. The goal is for this to be a flexible framework that can be used to

  • allow quick loading and dumping of core memory from a PC file
  • hold diagnostic programs that can be popped into memory
  • emulate card readers, punches, printers and disk drives using PC files
  • hook real peripherals to the 1130 implementing a missing IBM adapter (e,g, paper tape)
  • hook real peripherals to the 1130 emulating IBM device (e.g. DEC RK05 as 2310)
  • extend functionality of the 1130 via device interface (e.g. floating point math)

My 1130 system, the system at the museum in the UK, an 1130 system owned by Brian Knittel and Norm Aleks, and an as-yet unrestored 1130 owned by the MARCH retro computing society in New Jersey all have the SAC interface installed. Other 1130s that are restored or might be restored in the future might have the feature installed, but I don't know enough about those machines to know.

Each 1130 system with the SAC installed could make use of the SAC interface I am building either temporarily to aid in restoration/repairs, temporarily to load or capture software to exchange with other systems, or permanently for its real and emulated peripherals. I will make the designs and VHDL code freely available such that owners who have an SAC equipped 1130 can make their own copy of the interface.


I visited the museum on Saturday, enjoying a look at changes since my last visit including the excellent progress on building the EDSAC replica machine. A malfunction has cropped up recently with the 1130 system, where each time a card is read using the 1442 it transfers 81 words into memory - the actual card image plus a final blank column.

Debugging this has been slowed because of a few coincidental issues. The storage oscilloscope normally available to capture images of nonperiod signal sequences has developed its own faults and can't be used. A logic analyzer was acquired but there are still learning curves figuring out how to recognize SLT voltage thresholds and to sample at a slow enough rate to capture the timing states during the reading of a card.

The way that the 1442 determines it has finished reading cards is not the most direct. It does not count up columns and trigger on reaching 80. As the mechanism rotates through a card feeding cycle, moving the card through the reader station, a permanent magnet on a rotating disc passes a coil and generates a pulse at the point where the card's 80th column will have just passed by the photocell detectors.

This 'CB2 pulse' will shut off the flipflop that enables the generation of level 0 interrupts that tell the software it is time to read the state of a card column; as well, it generates a level 4 interrupt informing the software that the reading of the entire card has completed.

While a card is moving through the reader station, a rotating disc allows light through a set of holes cut in the disc - the light pulse indicates that a card column is present, latching in the pattern of holes and also triggering the generation of the level 0 interrupt as long as the enabling flip flop is set. The disc does not have exactly 80 holes around its circumference as you might innocently expect. Instead, there is an 81st hole, which is how our extra column interrupt is induced.

The spurious extra column is either caused by a failure of the logic to reset the flipflop, or by a timing misadjustment such that the CB2 pulse is too late to have blocked the column interrupt, or by a different timing issue if the disc with the holes is exposing holes too early compared to the position of the card in its movement through the reader. Or, perhaps by another mechanism that hasn't occurred to either of us yet.

If the storage scope or the logic analyzer where working, Peter could see the relative timing of the various signals - CB2, the enabling flip flop, the emitter pulse from the disc with the holes, etc. That would have let the problem be narrowed down rapidly. Without those tools, the means to debug this are more limited. Logic cards implementing the enabling latch could be swapped with a different card of the same type, to see if the problem abates or moves, for example.

Interestingly, the type of card which is used for the flipflop circuitry that enables the generation of level 0 interrupts is the same type which had to be replaced in another location of the machine, back when the 1130 was first restored. That card failed, not resetting and therefore allowing a signal to be generated to move the punch mechanism forward one column when the flip flop should have been reset to block it. It sounds similar to the problem occurring with the reader at present, in that it may be failing to reset fast enough to block the generation of a card column interrupt.

It wouldn't be surprising to have a similar failure occurring in more than one card of the type, if a component or manufacturing step used on those cards is susceptible to age related failures. Once Peter can swap the card with a peer, it might confirm the problem is a faulty card. If not, however, Peter will need to wait until the tools are operational.

I had to leave before any swapping could occur, as I was due in London to meet with Lawrence Wilkinson, who has in the past owned and restored an IBM 360/30 system and more recently built an FPGA replica of a model 30. It was a chance to catch up in person, talk about where we were in our respective projects and share ideas on some upcoming work of mutual interest. That meeting went well, as had the visit to TNMoC and Peter. 


  1. Hi Carl,

    It was nice to see you again and thanks for spending some time with me trying to understand and investigate the problem I have on the 1130. My understanding of how the 1442 gets its data into core and the various logic areas involved is narrowing down where the problem might be.

    Sadly, swapping the SLT card identified with the same card used in 2 other locations did not change the problem so investigations continue.

    Peter @ TNMOC

  2. Sorry to hear that the easy fix didn't work - not the card we thought. I hope the tools you have access to are working again soon, allowing you to track down exactly what is happening or not happening.
    Once I am home and have the 1442 clutches reassembled, I can run some tests to see how mine behaves for various signals and timings, if that would help flag those that are different on your machine.