xxx
SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130
I got out before breakfast and did a bit more work on the connections. There were three of the seven pairs still to solder in when I left the workshop. Later, after the morning meal, I did another pair, taking the usual 30 minutes, until my back spasmed up again from hunching over the box. At this point, I would need to steal another hour to finish up the final two pairs, before I could do any testing.
Before lunch I managed to wrest 30 minutes from my party preparations and as a result there is only one pair of connectors left to build. For each pair, there are 12 twisted pairs that run to the main SAC cable connector and six single wires from the fpga. These must be cut off the old board, stripped, have heat shrink tubing placed over one end, and be carefully soldered to the ribbon cable on the new connectors. The heat gun shrinking the tubing is the last step in the process.
Final pair soldered on just before lunch and the old board removed. Next up was soldering in the power and ground lines to the new boards, then plugging in all the connectors in their proper locations. With that it was ready to power up.
I had updated the fpga logic in the SAC box, which now inverts the interrupt level 0 and 1 request lines, so I had to install the inverter board inside the 1131 before I powered the system on. I was able to add it to the bracket that held the original driver daughter card then wire it in place.
As a power on test, I loaded core memory from a PC file to verify that things still worked properly - that checks out quite a few of the driver signals. Three driven signals are of no importance at this time - block channel advance, advance IO entry, and meter in - and there are interrupt requests for levels 2, 3, 4, and 5. I modified the Python program to cycle through the interrupt levels so that I could verify them.
I found that somehow I reversed the wiring of a few lines, or have bad connections. Bit 15 is always hot as a 1. Interrupt level 2 is always triggered. When I trigger what i think is IL2, it triggers level 3 instead. Level 4 trigger does nothing.
These symptoms mean that not much is wrong - I got 15 of the 16 data lines correct, cycle steal and channel write works, and the address lines are good for address of the form 0x01?? because I only looked at location 0x0100 and a couple dozen words afterwards but those locations were correct.
I could have up to seven channel address lines swapped, up to three interrupt request lines swapped, and of course my low order bit 15 for data is hot. Since chip 5 on one side has the low order bit (15), int req for L2 and int req for L3, I am almost certain to have a wiring issue in this connector that is causing some problems, but what is wrong isn't immediately obvious.
The lack of int req L4 hints at the connector for chip 4, which also has address bit 0 and IL5. Since IL5 works, I may have swapped the positions of IL4 and Address bit 0. This is not certain, because I can't see the result of A0 - it isn't really implemented as this machine is a 32K configuration.
This will require tracing fpga pins back to my chip inputs on the driver board, as well as verifying the color codes and sequencing from my working notes while I was moving wires around.
I ran out of time due to the party, so that ends my work for today.
Final pair soldered on just before lunch and the old board removed. Next up was soldering in the power and ground lines to the new boards, then plugging in all the connectors in their proper locations. With that it was ready to power up.
I had updated the fpga logic in the SAC box, which now inverts the interrupt level 0 and 1 request lines, so I had to install the inverter board inside the 1131 before I powered the system on. I was able to add it to the bracket that held the original driver daughter card then wire it in place.
As a power on test, I loaded core memory from a PC file to verify that things still worked properly - that checks out quite a few of the driver signals. Three driven signals are of no importance at this time - block channel advance, advance IO entry, and meter in - and there are interrupt requests for levels 2, 3, 4, and 5. I modified the Python program to cycle through the interrupt levels so that I could verify them.
I found that somehow I reversed the wiring of a few lines, or have bad connections. Bit 15 is always hot as a 1. Interrupt level 2 is always triggered. When I trigger what i think is IL2, it triggers level 3 instead. Level 4 trigger does nothing.
These symptoms mean that not much is wrong - I got 15 of the 16 data lines correct, cycle steal and channel write works, and the address lines are good for address of the form 0x01?? because I only looked at location 0x0100 and a couple dozen words afterwards but those locations were correct.
I could have up to seven channel address lines swapped, up to three interrupt request lines swapped, and of course my low order bit 15 for data is hot. Since chip 5 on one side has the low order bit (15), int req for L2 and int req for L3, I am almost certain to have a wiring issue in this connector that is causing some problems, but what is wrong isn't immediately obvious.
The lack of int req L4 hints at the connector for chip 4, which also has address bit 0 and IL5. Since IL5 works, I may have swapped the positions of IL4 and Address bit 0. This is not certain, because I can't see the result of A0 - it isn't really implemented as this machine is a 32K configuration.
This will require tracing fpga pins back to my chip inputs on the driver board, as well as verifying the color codes and sequencing from my working notes while I was moving wires around.
I ran out of time due to the party, so that ends my work for today.
No comments:
Post a Comment