I whipped up some test code and fired up the 1130 for the XIO Sense Device test on area code 21. No signs of response. Time to instrument some more diagnostic information into my fpga logic and python program.
I also thought of a more reliable way to be mirror the T and X clock state of the 1131, using a pair of FSMs I will create. This way I can time actions to any clock state and to either phase A or B within the state. A third clock will be defined to track XIO execution memory cycles, e.g. E1, E2 and E3.
The problem this solves is that all we are receiving are levels telling us when we are in states T0, T2, T4, T6, X0, X2, X4 or X6. We may wish to time activity by the missing states such as T3, T7, X7 etc.
Although the existing clock state signals are no all-inclusive, we can use these to ensure the FSM is tracking properly, using the CPU Clock Out as our primary stepping signal but kept in check by the clock state signals. CPU Clock Out moves the rings forward and also defines whether we are in phase A versus B, the front and back half of each machine cycle (clock value of 1 versus clock at 0.)
Once I see these working properly under single step mode, I can run the machine at full speed and see that these seem to be tracking properly. They will be the foundation for controlling the various types of XIO, for signalling interrupts and for handling cycle steal read or write.
On first test, my T clock mirror worked perfectly but I didn't seem to get the same good results on the X clock ring. I also found that the X6 and XIO E1 lines were touching, requiring a bit of cleanup on the receiver board.
With that fixed, it appears that I am triggering my DSW store process for the XIO, however since the value is all zeroes it is not definitive. I looked at my logic to see why I am not injecting the pattern I expected into the register. I then found another wire wisp bridge, this time to the T4 incoming state. With that fixed, my state machines where shadowing T clocks, X clocks and the E phases of the XIO instruction.
Also, my logic for Sense DSW worked properly, however the data returned was only the bottom half of the register - while I sent 1 bits, the top half of B register remained all zeroes. I began looking into continuity of the wires and other electrical issues in my link.
There is still an electrical/wiring problem with the lines for Channel Data and Channel Address in - they are not pulled up to 3V as they should. All the offending signals run to the same type of card, a 7196 SLT card, but with each card handling 8 signals the problem is common to all four cards. I see a reference in the ALD to the incoming lines showing them running to items labeled 'resistor', which should be the pullup devices yet I don't yet know there to look.
I could go through and install pullups on my side, but that is not how the machine is supposed to work. I need to figure out what is wrong and correct it. I will also pull one of the 7196 cards to see if the resistors are mounted there. It would definitely help if I could find the schematics of that card, but so far it is not in any of the material I can find online.
I opened the card compartment to take out one of the 7196 cards for a quick examination, when I got quite a surprise. There should be four of these cards, two in slots B6 and B7, the other two in slots E6 and E7. I found a gaping hole at B6 - the card responsible for the high half of the incoming data bits. This certainly explained the failure to set them to one. E6 and E7 were correct, plus I saw one more 7196 card sitting in D6.
Looking at the card map for the compartment, there should be nothing in slot D6. I tried to move the card over but couldn't insert it. Looking closely at the socket, I could see that a plastic guide piece broke off the original card and was blocking insertion. I pulled the nonessential guide piece and inserted the 7196 card.
I did a quick power up of the 1131, without any power on my SAC Interface board, and now see voltages on the channel data in lines where before there was no pullup. There must be a series circuit of some kind that requires all four cards inserted to power the lines. This of course means that I have to cut away my pull-up resistors on the driver board for all that are working properly then I can do a power-on test.
My first check is to look at the resistance of these lines now that the card is inserted - any that are less than 100 don't need a pullup on my end. I found that all of the lines to the newly discovered card could have their pullup resistor cut off my driver card.
I did a power up of the 1131 and tested voltages with no power to my SAC Interface box. All I could reach were correctly at 2.975. I then ran the XIO Sense DSW to area code 21 and found x7B70 in the B register. I was trying to emit an xFFFF. I checked the signals coming out of my box and all sixteen bits were pulled low. It should have registered as xFFFF.
I then did some continuity testing of the lines for bits 0, 5 and 8, the ones that didn't show up in the accumulator, using a VOM. My thinking was that I might have a cabling/continuity issue, it might be a termination problem, or there may be a flaw on the 7169 cards. It would require two bad circuits on one card and another bad circuit on a second, something I am not ready to accept without testing.
The continuity test was unfortunately successful - bits 0, 5 and 8 are connected from the input in of the 7169 receiver board right to the output pin of my driver board. Further, I see that my driver board is pulling the line down as it should. I will prepare to scope the lines at the 1131 backplane and make other tests to figure out what is causing this issue.
It still could be a circuit issue outside of the SLT, although I am prepared to deal with the issue however it turns out. Facts first, then plan the resolution. Focusing on the positives, I have pretty decent logic for responding to a XIO Sense Device, will only get more solid now that I have such reliable T clock, X clock and XIO phase mirroring.
I also had a very nice insight today. I had been assuming that any peripherals I attach or emulate using the SAC Interface box would have to be different from the physical devices on my system - assuming that the adapter logic in the 1131 would always be responding to XIOs for that area code.
However, I realized that all I need to do is block one signal going to the adapters - the XIO E1 signal - and they will never "see" the XIO with their area code. Instead, my SAC Interface box could respond to any area code as long as its adapter is blocked.
The big limitation to this is that not all interrupt and cycle steal levels are available via the SAC interface. Specifically, I can't trigger interrupts on IL0 or IL1 and I can only do cycle steal on level 1, not on CS0. The cycle steal level isn't really a problem as long as I prioritize CS among devices properly.
The show stopper is the limit on IL0 and IL1 triggering. The 1442 interrupts on IL0 for each column, which is how the software knows to issue an XIO Read or XIO Write for that next character. Similarly, the 1132 printer interrupts on IL0 to indicate that the next character on the rotating print wheel is ready to be read with an XIO Read and then the printer can cycle steal to fetch the hammer firing mask.
I can pretend to be the 1442 reader for a single boot card, because the hardware is blocking recognition of the interrupt and using the condition to force gate in each column to ascending words. I can just cycle steal to write all eighty characters, then push Imm Stop, Reset and Start (instead of Imm Stop, Reset and Prog Load). It won't help read a second card, since that needs IL0 for the software to work properly. Still, if I boot a card that then tries to read from a 2501, that is a device I can emulate.
As I looked at the 1130 and other gear in my two-car garage where I am restoring it, I realized that the space is about the same as the machine room where my first hands-on computer was installed - the room had an 1130 with 32K words (the full length model like mine), an 1133 Multiplexor box, a 1403 line printer, a 1442 reader/punch, and a 2310 model B with two additional disk drives to complement the single drive inside the 1131 cabinet.
It too was on a concrete floor with cables visible as they ran between the units. A different complement of peripherals, more memory, faster cycle time, and the machine from my past had the red "Garnet Rose" colored doors while mine is painted in "Sunshine Yellow", but satisfyingly, nostalgically similar.
I then did some continuity testing of the lines for bits 0, 5 and 8, the ones that didn't show up in the accumulator, using a VOM. My thinking was that I might have a cabling/continuity issue, it might be a termination problem, or there may be a flaw on the 7169 cards. It would require two bad circuits on one card and another bad circuit on a second, something I am not ready to accept without testing.
The continuity test was unfortunately successful - bits 0, 5 and 8 are connected from the input in of the 7169 receiver board right to the output pin of my driver board. Further, I see that my driver board is pulling the line down as it should. I will prepare to scope the lines at the 1131 backplane and make other tests to figure out what is causing this issue.
It still could be a circuit issue outside of the SLT, although I am prepared to deal with the issue however it turns out. Facts first, then plan the resolution. Focusing on the positives, I have pretty decent logic for responding to a XIO Sense Device, will only get more solid now that I have such reliable T clock, X clock and XIO phase mirroring.
I also had a very nice insight today. I had been assuming that any peripherals I attach or emulate using the SAC Interface box would have to be different from the physical devices on my system - assuming that the adapter logic in the 1131 would always be responding to XIOs for that area code.
However, I realized that all I need to do is block one signal going to the adapters - the XIO E1 signal - and they will never "see" the XIO with their area code. Instead, my SAC Interface box could respond to any area code as long as its adapter is blocked.
The big limitation to this is that not all interrupt and cycle steal levels are available via the SAC interface. Specifically, I can't trigger interrupts on IL0 or IL1 and I can only do cycle steal on level 1, not on CS0. The cycle steal level isn't really a problem as long as I prioritize CS among devices properly.
The show stopper is the limit on IL0 and IL1 triggering. The 1442 interrupts on IL0 for each column, which is how the software knows to issue an XIO Read or XIO Write for that next character. Similarly, the 1132 printer interrupts on IL0 to indicate that the next character on the rotating print wheel is ready to be read with an XIO Read and then the printer can cycle steal to fetch the hammer firing mask.
I can pretend to be the 1442 reader for a single boot card, because the hardware is blocking recognition of the interrupt and using the condition to force gate in each column to ascending words. I can just cycle steal to write all eighty characters, then push Imm Stop, Reset and Start (instead of Imm Stop, Reset and Prog Load). It won't help read a second card, since that needs IL0 for the software to work properly. Still, if I boot a card that then tries to read from a 2501, that is a device I can emulate.
As I looked at the 1130 and other gear in my two-car garage where I am restoring it, I realized that the space is about the same as the machine room where my first hands-on computer was installed - the room had an 1130 with 32K words (the full length model like mine), an 1133 Multiplexor box, a 1403 line printer, a 1442 reader/punch, and a 2310 model B with two additional disk drives to complement the single drive inside the 1131 cabinet.
It too was on a concrete floor with cables visible as they ran between the units. A different complement of peripherals, more memory, faster cycle time, and the machine from my past had the red "Garnet Rose" colored doors while mine is painted in "Sunshine Yellow", but satisfyingly, nostalgically similar.
No comments:
Post a Comment