I removed any contributing signals that might affect the Channel Data or Channel Address In lines, as well as those controlling Channel Write Gate, just to be sure that I don't have a flaw in some other part of my interface logic injecting bits improperly.
Testing had to wait due to family obligations, but late in the afternoon I was able to sneak in for a brief test or two. I was still seeing the behavior but had a bit more feedback from the state machines to examine.
The machines are working correctly, but something caused me to check the correctness of the cabling of various Channel Data In and Channel Address In bits to the driver circuits. I found both registers to be a bit scrambled in their assignments, which needs rectification if my tests are to make any sense.
It took about an hour to continuity test all the bits between the 1131 entry cards and the driver card in my box. I then verified that my fpga to driver card signals were in the order I expected. There are 18 signals that are mis-connected, requiring changes to the fpga logic to reconcile them. I now have a definitive record of the connections and will update all my documentation.
With the documentation updated and the FPGA logic corrected, it was time to head out and test again. Having scrambled address bits certainly creates an Easter egg hunt through 16,384 addresses to find the one memory word I wrote to with my test. In hindsight, had I simply picked location zero, I could have at least checked that cycle steal fetch and store are working before I had to debug the errant wiring.
With the changes made, I fired up the system, set to both store and fetch into location 0x0020. I had set it up to store the pattern 0x1130, did a store cycle and then a fetch. The machine had been zeroed out using the Storage Load switch on the CE panel, but after the store and fetch were done I had retrieved 0x1130. The data was not at 0x0020, so it was time to figure out what was wrong with the address bits.
Using a voltmeter when the machine was in the midst of the X clock cycle, I found that bits 9, 10 and 15 were on - when I expected solely 10 to be on. That corresponds to location 0x0061 which I quickly checked with the console display mode. It had the 0x1130 pattern!
I then manually loaded two other patterns in the word at 0x0061 - first 0x5555 and then 0xAAAA. Both were correctly fetched when I commanded a cycle steal read operation. Once I figure out why bits 9 and 15 are on when they should be off, and correct whatever is the cause, I will have full cycle steal functionality.
Further, this makes me optimistic that the remaining XIO logic will work with minimal debugging. I used part of the logic to inject bits in when executing an XIO Sense Device for a device at area code 21, this used quite a bit of the 1131 side of the adapter functionality. I already know that I can force interrupts on the four levels, just to complete the set of all 1131 interactions I need to act as an IO adapter.
The machines are working correctly, but something caused me to check the correctness of the cabling of various Channel Data In and Channel Address In bits to the driver circuits. I found both registers to be a bit scrambled in their assignments, which needs rectification if my tests are to make any sense.
It took about an hour to continuity test all the bits between the 1131 entry cards and the driver card in my box. I then verified that my fpga to driver card signals were in the order I expected. There are 18 signals that are mis-connected, requiring changes to the fpga logic to reconcile them. I now have a definitive record of the connections and will update all my documentation.
With the documentation updated and the FPGA logic corrected, it was time to head out and test again. Having scrambled address bits certainly creates an Easter egg hunt through 16,384 addresses to find the one memory word I wrote to with my test. In hindsight, had I simply picked location zero, I could have at least checked that cycle steal fetch and store are working before I had to debug the errant wiring.
With the changes made, I fired up the system, set to both store and fetch into location 0x0020. I had set it up to store the pattern 0x1130, did a store cycle and then a fetch. The machine had been zeroed out using the Storage Load switch on the CE panel, but after the store and fetch were done I had retrieved 0x1130. The data was not at 0x0020, so it was time to figure out what was wrong with the address bits.
Using a voltmeter when the machine was in the midst of the X clock cycle, I found that bits 9, 10 and 15 were on - when I expected solely 10 to be on. That corresponds to location 0x0061 which I quickly checked with the console display mode. It had the 0x1130 pattern!
I then manually loaded two other patterns in the word at 0x0061 - first 0x5555 and then 0xAAAA. Both were correctly fetched when I commanded a cycle steal read operation. Once I figure out why bits 9 and 15 are on when they should be off, and correct whatever is the cause, I will have full cycle steal functionality.
Further, this makes me optimistic that the remaining XIO logic will work with minimal debugging. I used part of the logic to inject bits in when executing an XIO Sense Device for a device at area code 21, this used quite a bit of the 1131 side of the adapter functionality. I already know that I can force interrupts on the four levels, just to complete the set of all 1131 interactions I need to act as an IO adapter.
No comments:
Post a Comment