I set up the FPGA logic to emit a non-zero pattern on the Channel Data In lines of 0x5555 which should show up if I do an XIO Sense Device to a non-existent area code (peripheral address). The peripheral adapter logic for every device is watching for the XIO E1 signal. The adapter logic that as the same area code is the only one that is allowed to set up non-zero bits on the Channel Data In lines.
The Data in lines of all peripherals are wire ORed together and transferred to the B register. With a Sense Interrupt version of XIO, all device adapters that can interrupt on the selected interrupt level must raise the bit for any condition for which they requested an interrupt. Since more than one device could interrupt at the same time, they are assigned specific non conflicting bits from among the 16 possible positions and thus the wire-OR might produce an interrupt status answer in the B reg that has bits set by more than one device.
For all other XIO command types, only the device being addressed is supposed to raise any bits during the XIO E cycles (E1, E2 and sometimes E3), while the others have all bits set to zero. If I am raising every other bit (through the pattern b'0101010101010101 I set up) then that is wire-ORed for any XIO E cycle. If I picked an existing real peripheral, such as the printer, then its adapter logic would be raising bits also, but if I choose an address for which no adapter logic is configured, then only my bits will be transferred to the B reg.
This method will let me do a SMC mode stepping through an XIO instruction and watch the value of the B register as a way of testing how my Channel Data In lines are working. It would have been nice to have a similar stepping mode for cycle steal operations, allowing me to see the Channel Address In values I am sending and verify that I am reading or writing from that word in memory. However, the X clocks run at full bore through all eight states, they can't be manually stepped as we can with the T Clock cycles.
The way I can check out the cycle steal is to set up the sequencing logic and some target addresses and data patterns. Then I can verify that a certain value is indeed stored in memory at the chosen address after I trigger a cycle steal with the channel write gate involved. Without the write gate, it is simply a read of an address into the B reg, no update is done.
Cycle steal requires that the Channel Data In and Channel Address In lines only be raised at specific times during one cycle of X0 through X7 states. Further, The channel write gate line is only to be activated during certain of these states. I can't just turn all the lines on and hope it works properly. I have a finite state machine set up to process a cycle steal read or write, which I will trigger as part of my testing. Since the FSM depends on watching such signals a CS Level 1, X0, X2, X4, X6, Osc Phase A, CPU Parity Stop and the B Register, they must be correct before I can use them to control the cycle. I don't yet know for sure that CS Level 1 and the four X states are working properly and coming in on the intended pin, making that validation a mandatory pre-requisite to any cycle steal operational testing.
I already have all the signals validated that I need for handling XIO instructions - signals such as Osc Phase A, Clock Out, CPU Parity Stop, XIO E1, T0, T2, T4, T6 and the B reg - and know I can fire off the interrupt requests, so as long as I can send in device status or data values on the Channel Data In lines I could act as the adapter logic for any non-cycle-stealing peripheral. Then, when I get cycle stealing operational, I have the means to handle any device behavior.
One side of my SAC Interface box handles the duties of a device's adapter logic, handling XIOs, interrupts and cycle stealing. The other side either communicates with a PC program or drives a real peripheral of some type. I have a paper tape reader to look like a 1134, a paper tape punch that appears to be a 1055, a plotter that maps to a 1627 modle 1, and a IO Selectric that can appear to be a 2741 terminal.
In the middle between the sides is the ability to modify the behavior of the physical peripheral to make it appear to be a known 1130 device - emulating a device. For example, it may connect to a Documation card reader on one side and implement a device adapter using the area code and interrupt assignments of a 2501 card reader. In the middle we can map the behavior of the Documation to act the same way as a 2501 would.
Other real devices I can connect include three DEC RK05 disk drives and on CHI disk drive, all of which could emulate 2310 disk drives. I have an IBM 9 track tape drive from an RS6000 which can appear to be a 2420 drive. There is an HP line printer which could emulate a 1403 line printer.
Right after I woke, I took a few minutes to complete the testing of the remaining driver circuits, cutting the pullup resistors off for all that had working resistors in the 1131 side circuitry. Now the drivers are all set up to work properly, allowing me to resume testing. First up is verification that I can trigger a cycle steal by driving CS Request, giving me appropriate return signals of CS Level 1, X0, X2, X4 and X6. I should see the X7 lamp extinguish on the console when cycle steal is operational, as well as the return signals mentioned above.
Testing had to wait until I had some free time during a busy workday. I ran out and spotted a few anomalies to investigate:
I discovered the cause of the three problems above. I had a broken wire on the input to the interrupt request inverter - fixed. X2 flickers came from a wire wisp bridging X2 to Parity Stop which gave the intermittents - fixed. Circuit 40 was a bad inverter, moved over to the other circuit and it was fixed.
I still wasn't seeing any cycle steal activity when I forced any of those four signals on. I even swapped the lead I believed to be the mostly useless Meter In in case I had it wrong, but still no joy. Then, I had a dim memory from the earliest days of the restoration, when I was seeing data coming in spuriously and in my debugging, I remembered setting some jumpers to block certain signals.
I pulled out the ALDs and looked at the sheet with the configuration jumpers - a list of conditions, e.g. No 2501, and the jumper setting for that condition. I saw two entries labeled No SAC, with jumpers on gate B compartment B card B6 and card B7. Referring to the logic, I discovered these would block cycle steal 1 requests and block another related signal come from my box.
I swung open the gate and saw two red jumpers glaring out at me, causing my inability to request cycle stealing. I yanked them off and powered back up - now I could cycle steal!
I used the cycle stealing and my scope to identify the association of receiver circuits to the four X clock levels - X0, X2, X4 and X6 - which was an important validation of the reliability of the signals that will step my finite state machines handling cycle steal activity. When the 1131 was in Run mode, when I pushed my button I would see the X7 light extinguish and see the X clock pulses on the scope.
When the machine was in Single Step mode sitting at T7, I expected to see the X7 light extinguish in the same way, based on my believe that cycle steal operations ran at full speed rather than being stepped. It didn't happen. I left the cycle steal request on and pushed the Start button on the console, which normally would step from T7 to T0, but instead the machine stayed at T7 and turned off the X7 light. I realized that I was wrong. It is possible to step through the eight X clock states manually.
Stepping one push at a time let me double check that I had the right sequence for the X clock signals. I am not sure if I can see the channel address and data in/out with the console, but I do have other ways to check this out.
Next up was to issue an XIO Sense Device and see what pops up in the memory location. I had set up the fpga logic to emit a non-zero pattern on data in, which had the effect of forcing those bits onto the B register at all times, not just during the XIO. I need to be much more nuanced in when I emit bits on the data and address in registers.
I already have all the signals validated that I need for handling XIO instructions - signals such as Osc Phase A, Clock Out, CPU Parity Stop, XIO E1, T0, T2, T4, T6 and the B reg - and know I can fire off the interrupt requests, so as long as I can send in device status or data values on the Channel Data In lines I could act as the adapter logic for any non-cycle-stealing peripheral. Then, when I get cycle stealing operational, I have the means to handle any device behavior.
One side of my SAC Interface box handles the duties of a device's adapter logic, handling XIOs, interrupts and cycle stealing. The other side either communicates with a PC program or drives a real peripheral of some type. I have a paper tape reader to look like a 1134, a paper tape punch that appears to be a 1055, a plotter that maps to a 1627 modle 1, and a IO Selectric that can appear to be a 2741 terminal.
In the middle between the sides is the ability to modify the behavior of the physical peripheral to make it appear to be a known 1130 device - emulating a device. For example, it may connect to a Documation card reader on one side and implement a device adapter using the area code and interrupt assignments of a 2501 card reader. In the middle we can map the behavior of the Documation to act the same way as a 2501 would.
Other real devices I can connect include three DEC RK05 disk drives and on CHI disk drive, all of which could emulate 2310 disk drives. I have an IBM 9 track tape drive from an RS6000 which can appear to be a 2420 drive. There is an HP line printer which could emulate a 1403 line printer.
Right after I woke, I took a few minutes to complete the testing of the remaining driver circuits, cutting the pullup resistors off for all that had working resistors in the 1131 side circuitry. Now the drivers are all set up to work properly, allowing me to resume testing. First up is verification that I can trigger a cycle steal by driving CS Request, giving me appropriate return signals of CS Level 1, X0, X2, X4 and X6. I should see the X7 lamp extinguish on the console when cycle steal is operational, as well as the return signals mentioned above.
Testing had to wait until I had some free time during a busy workday. I ran out and spotted a few anomalies to investigate:
- Somehow I am triggering an interrupt on level 3 - have to check that the wire didn't come loose on the driver circuit or some other problem occur.
- X2 phantom detection on the PC screen, but should be seeing it.
- One of the final driver circuits, number 40 which is probably the CS Request, is not behaving properly. It is pulled up to 2.9V but when I give the inverter a logical 1 as input, it remains at 2.9V rather than dropping down to near zero.
I discovered the cause of the three problems above. I had a broken wire on the input to the interrupt request inverter - fixed. X2 flickers came from a wire wisp bridging X2 to Parity Stop which gave the intermittents - fixed. Circuit 40 was a bad inverter, moved over to the other circuit and it was fixed.
I still wasn't seeing any cycle steal activity when I forced any of those four signals on. I even swapped the lead I believed to be the mostly useless Meter In in case I had it wrong, but still no joy. Then, I had a dim memory from the earliest days of the restoration, when I was seeing data coming in spuriously and in my debugging, I remembered setting some jumpers to block certain signals.
I pulled out the ALDs and looked at the sheet with the configuration jumpers - a list of conditions, e.g. No 2501, and the jumper setting for that condition. I saw two entries labeled No SAC, with jumpers on gate B compartment B card B6 and card B7. Referring to the logic, I discovered these would block cycle steal 1 requests and block another related signal come from my box.
I swung open the gate and saw two red jumpers glaring out at me, causing my inability to request cycle stealing. I yanked them off and powered back up - now I could cycle steal!
I used the cycle stealing and my scope to identify the association of receiver circuits to the four X clock levels - X0, X2, X4 and X6 - which was an important validation of the reliability of the signals that will step my finite state machines handling cycle steal activity. When the 1131 was in Run mode, when I pushed my button I would see the X7 light extinguish and see the X clock pulses on the scope.
When the machine was in Single Step mode sitting at T7, I expected to see the X7 light extinguish in the same way, based on my believe that cycle steal operations ran at full speed rather than being stepped. It didn't happen. I left the cycle steal request on and pushed the Start button on the console, which normally would step from T7 to T0, but instead the machine stayed at T7 and turned off the X7 light. I realized that I was wrong. It is possible to step through the eight X clock states manually.
Stepping one push at a time let me double check that I had the right sequence for the X clock signals. I am not sure if I can see the channel address and data in/out with the console, but I do have other ways to check this out.
Next up was to issue an XIO Sense Device and see what pops up in the memory location. I had set up the fpga logic to emit a non-zero pattern on data in, which had the effect of forcing those bits onto the B register at all times, not just during the XIO. I need to be much more nuanced in when I emit bits on the data and address in registers.
No comments:
Post a Comment