Before I begin ripping into the card I suspect, it would be prudent to swap the card with an adjacent one, just to verify that the problem moves When I did that, the problem did NOT change, still occurred at addresses with Y high bit pattern of 011. Thus, the problem is elsewhere. Time to dig into the manuals to see what might cause this specific failure, either another card or a backplane trace failure.
This failure occurs in both halves of the 8K memory block, which is a consequence of it relating to Y addresses which run vertically through the planes covering both 4K sections. The address bit inputs that feed into the G3 card are used to decode one other line each as well as the 011 combination, so they must be good. Thus, my problem is isolated to the output of the G3 card down to the connectors onto the core plane diode boards.
The signal runs from the G3 card, over the backplane, to a connector and then to a set of diodes. The wire runs through the core planes, out to another set of diodes, through a connector and back through the backplane to another card connector. It will be in the first half of that run, up through the diode board wiring.
If I have a problem with backplane traces cracking, this is a long term worry but I can jumper around it for this failure. If it is a connector issue, more difficult but potentially can be bypassed. I also have to check that the other connections to the card socket are good:
- +8.3V
- +6V
- Ground
- Read current
- Read sink
- Write gate current
First up was continuity checking of all those signal connections. If any of those failed to make it to the board socket, I can jumper or wire around the failure. All six showed good continuity, leaving me to check the two signal run from the card socket up to the diode board on the core planes.
The card has a read driver output and a write sink input. Each goes over the backplane to a jumper-connector that carries the signal up through the core plane stack to the diode board on top. Each of the two signals is connected through sixteen diodes to sixteen separate lines that snake through all the core plans.
The diodes from the read driver line are oriented in one polarity while the diodes from the write sink line are in the other polarity. The far end of each pair of diodes is hooked to one of the sixteen lines wound through the 18 core planes. Each of the sixteen lines is hooked to its pair of isolating diodes on our end, but the other end of the sixteen lines connect to read gate/write driver cards
That means that I can't have a broken wire in the core arrays as that would effect only one of the sixteen words driven by our card, but all sixteen words are dead. Thus, the possible problems are:
- continuity break from G3 card to the connector-jumper
- corrosion or failure in the connector-jumper
- broken wire from connector jumper up through core plane to diode board
- some problem like a short in a diode impacting the entire line
I am a bit nervous about removing the connector-jumper blocks to test because of the age and possible brittleness of the small pins involved. If I can get to a pin on the connector block without removing it, I can resolve possible cause 1 above. I need to work out where on the diode board my signal lines connect, so that I can test the continuity all the way back to the G3 socket.
Another test will be to check each of the diodes to see if they are shorted or open. I think I have to pull all the driver/sink boards first, but then I can do pure continuity testing so it is worthwhile. I spent the evening studying the documents and laying out all the information I need for the testing.
The Y high order address card that handles 011 in bits 9-11, the failing symptoms, sits in slot G3. The Read Driver line runs from pin D06 over the backplane to the connector block at slot D5, pin B03. The Write Gate line runs from pin B13 over the backplane to a connector block at slot K5, pin D04.
In the D5 connector, pin B03 is jumpered to pin B12 which runs up through the core array to the diode card. For the K5 connector, pin D04 is jumpered to pin D12 which also runs up to the diode card. On the diode card, two diode packs are connected to these two signals, bottom right of the pack is the Read Driver and top left is the Write Gate connection. Each pack has four pairs of diodes to drive half the lines that go through the core arrays.
I can reach the diode packs on the board since it is on top of the core module, thus I should be able to check out all the diodes. Also, the diode pack has a line I can check all the way back to slot G3 to test connectivity. This will be my first test - since if I have a break in continuity I can track down that fault otherwise my problem is likely in the diode packs.
SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130
Restructuring the GUI
-- startup test for Xilinx toolchain USB link corruption --
I had built a quick check into the GUI which will allow me to verify the usability of a bit load before I attempt to power on the 1130. Unfortunately, the test passed but it should not have. When I tried core loads and device operation, it failed.
I will need to wait until I have a known bad bitstream in the fpga and then tweak the transactions until I have a way to detect the problem reliably.
-- virtual 1403 --
I had rolled in the correction to the flaw I saw yesterday and reran the test that loops printing a line followed by a space. Bad bitstream but finally made enough trivial changes to get a workable load. In one of the runs, I received a Java array out of bounds exception from Vivado! What a dependable toolchain! Restarted it all and generated the bitstream. The write plus space a line program works great, at real 1403 model 7 speed.
With that working correctly, it is time to test out the skip function, which will advance the virtual page down to the point on the virtual carriage tape where a hole exists in the chosen channel. My default carriage tape has a hole in every channel with varying strides, so that I can validate the operation by counting blank links in my virtual paper file.
I tried with a skip to channel 3, but the output was still lines with one space between them. I need to enable some diagnostic output from the GUI, which luckily does not expose me to corrupted bitstreams. I put in a log to tell me each time we entered the skipping and the spacing logic.
I found a couple of minor flaws in my GUI side logic, one of which allows a subsequent write to arrive before the skip has occurred because of how I go back to polling transactions. Restructuring the flow a bit should fix this.
Upon testing, it got better - I never lost a skip nor a print line command - but I wasn't saving the skip pattern at the time I saved the existence of a carriage movement function. That is, I see a response to a poll that has a space or skip, save that code then process the outcome. It will be a print line if the XIO IW code was also returned from the poll, otherwise it goes to deal with the saved skip or space.
If it does have a print line to handle, the loop resumes and sees that we had a saved space or skip. Rather than poll again for a new print line and/or movement, we go ahead and handle the carriage movement. Once that is done, the loop now does the next poll for a new print line and/or movement.
With that rolled into the GUI code, I think I am ready to vary skip channels to ensure the behavior is correct. I had to rebuild a spreadsheet for the default tape image, where I had each channel spaced by its number, other than channels 1 and 12 which have special meanings of top and bottom of form, respectively. That is, channel 2 is in lines 2, 4, 6, 8 etc of the tape, while channel 3 is in 3, 6, 9 etc. This forms a pattern where a channel number gives you its value minus one of blank lines of skipping.
I set the next test up with channel 4 selected, which should give me the right pattern.
Unfortunately, I got into a loop in the GUI with bad values which I quickly traced to a wrong character in one line of code .
Once fixed, I ran various tests and the output is erratic compared to what I expected. I need to instrument both sides to see what line each side believes it has reached. I will work on this overnight and test tomorrow.
PREPARATION FOR VCF WEST EXHIBITION
I was reminded that the exhibition occurs two years to the day from when I got on an airplane to fly out to Beloit, Kansas to pick up and drive a truck bringing the 1130 system home for restoration. Thanks for the alert, Jack! I will have to commemorate this somehow.
I gave the five covers for the 1130 replica another color coat, as the surface was not even enough in color for my tastes, even for a quick and dirty substitute for the eventual metal doors with powdercoated paint.
No comments:
Post a Comment