I realized that I could support a third kind of peripheral on the box - mirror devices - in addition to virtual devices on a PC or real devices that use this box for their adapter logic. A shadow device creates a PC file that should mirror the input or output of a real device whose adapter is inside the 1131. That means I could mirror the 1053 console typewriter, the keyboard, the console data entry switches, the 1442 card reader, the 1442 card punch and the 1132 line printer.
The idea behind the mirror device is that I would pick off key data from the IO operations while the SLT device adapter in the 1131 does the real handling of the peripheral. I worked out a way to mirror sufficiently to copy the stream as the peripheral would produce it - the character typed on a keyboard or the line printed by a printer or whatever makes sense for the peripheral.
For example, when software types a character on the console printer, it issues an XIO Write instruction. I will see the XIO instructions and the area codes (device addresses) and can follow along with what the real adapter is doing. At the time the processor gets to the E3, time T4, of the XIO Write, the character to be emitted is present on the B register which I can see.
The obviously easy tracking situations are writing a character with XIO Write, because the memory word sent to the device is avialable on the B register, XIO Control operations for similar reasons, and the XIO Init Read/Init Write commands which present the WCA data address in the E3 stage.
More challenging are XIO Read, cycle stealing by the device, and XIO Sense DSW, because the device adapter presents the bits on the incoming data register, which I can't sense, I can only drive them. For XIO Read, I will see the new value in the B register late in the E3 stage, after the inbound data is gated in. For cycle stealing, I can watch CS accesses and capture the B register late in the cycle after it has been updated by a read or as it was fetched for a write. For XIO Sense DSW, I can see the updated B register late in the E3 cycle.
Remaining is the problem of discovering what device is using the cycle steal - the device adapter requests a cycle, provides a memory address and then either snags the resultant core location or provides the replacement data word. Since I can't see the memory address just the replacement data word, this is a hard problem.
If only one peripheral using cycle steal were active at a time, I would know that any cycle steal could only be on behalf of the mirrored peripheral. Unfortunately, my system has two peripherals whose adapters in the 1131 use cycle steal - the internal disk drive and the 1132 printer.
The disk drive transfers data words to or from disk using cycle steal. I simply need to save the WCA from the XIO Init read/write command then capture the data coming in from the cycle steal operations. I could force cycle steal reads of the WCA to retrieve the data being read or written, after the device has done its cycle steals to move the data from disk.
The 1132 printer fetches data words beginning at address 0x0100 and uses them to fire hammers based on which bits are set to 1 in the words. This happens after the printer interrupts on IL0, the software issues an XIO Read to get the particular character which is ready for printing across the 120 print wheels, then the software sets up the words starting at 0x0100 with bits for each column where this particular character should be printed. I could capture the data words as they are retrieved by the printer in order to populate the print line columns with this character.
The challenge comes for the case where both the printer and the disk are currently active - the printer started with an XIO to start printing via the interrupts for each ready character, and the disk drive started with an XIO Initiate Read/Write operation. Depending up on mechanical movement factors, the two devices could request their cycle steals independently of the other and perhaps interleaved. The SAC Interface has no indication for which device is making the cycle steal request.
The disk uses CS level 0, my box uses CS level 1 and the printer uses CS level 2. I can see if we are in CS Level 1, the one I requested. I can see if we are in clock states X0 - X6, which indicates a cycle steal operation, thus if this happens when we are not in CS Level 1 then it is a steal for level 0 or 2. I have no available signal telling me if those other states are active.
However, I do have a hint - a signal called Inhibit CS Request - which tells me if any of the following are true:
Based on the hints from Inh CS Req and other signals, it is barely possible to figure out which cycle steal is underway. I know the following:
1131 PROCESSOR REPAIR
The system is current staying in reset mode and when it wasn't, had difficulties loading the IAR or memory from the console data switches and perhaps was having an issue with peripheral operation. This has to be diagnosed and repaired before I can continue with the 1053 or most SAC Interface Box work.
Everything looked good down under, but something is wrong. I decided to remove the plate in front of the resistor panel allowing me to enter from the front, a much easier task than the narrow tunnel I had to use before. The resistor panel wiring looked fine.
I moved on to checking the power on the terminals while the machine was on. What I found was that the common line to all the buttons and switches, which should be energized with +12V power, was floating near ground. That would definitely cause the symptoms I saw. It is still 86F at 7PM tonight, which means I am not going to do much powering of the system. The most I can do tonight is check wiring harnesses and connections, as well as circuit breakers, to see if there are obvious errors.
The +12V comes from the power supply to the lamps on the left side of the main console plate, then over to the common leads of the buttons and switches on the right, by way of the CE switch panel hidden under the top cover near the usage meter. I see continuity among all the devices and one of the lamps along the left side is lit, so we have +12V on the line.
However, I don't see the +12V coming in from any of the switches. Something is wrong in the wiring down by the resistor panel. The wires coming in from the switches where I have the vampire taps is the area I need to check. If a tap isn't working, then the switch can deliver the +12V signal but it never makes it up to my relays and back out to the 1131.
It is very difficult to get the screws loosened that hold the resistor panel in its inconvenient place, but if I can get them loose I can rotate the plate, see what I am doing and get good testing of all the connections. Tomorrow, I will get this done and figure out what is wrong.
More challenging are XIO Read, cycle stealing by the device, and XIO Sense DSW, because the device adapter presents the bits on the incoming data register, which I can't sense, I can only drive them. For XIO Read, I will see the new value in the B register late in the E3 stage, after the inbound data is gated in. For cycle stealing, I can watch CS accesses and capture the B register late in the cycle after it has been updated by a read or as it was fetched for a write. For XIO Sense DSW, I can see the updated B register late in the E3 cycle.
Remaining is the problem of discovering what device is using the cycle steal - the device adapter requests a cycle, provides a memory address and then either snags the resultant core location or provides the replacement data word. Since I can't see the memory address just the replacement data word, this is a hard problem.
If only one peripheral using cycle steal were active at a time, I would know that any cycle steal could only be on behalf of the mirrored peripheral. Unfortunately, my system has two peripherals whose adapters in the 1131 use cycle steal - the internal disk drive and the 1132 printer.
The disk drive transfers data words to or from disk using cycle steal. I simply need to save the WCA from the XIO Init read/write command then capture the data coming in from the cycle steal operations. I could force cycle steal reads of the WCA to retrieve the data being read or written, after the device has done its cycle steals to move the data from disk.
The 1132 printer fetches data words beginning at address 0x0100 and uses them to fire hammers based on which bits are set to 1 in the words. This happens after the printer interrupts on IL0, the software issues an XIO Read to get the particular character which is ready for printing across the 120 print wheels, then the software sets up the words starting at 0x0100 with bits for each column where this particular character should be printed. I could capture the data words as they are retrieved by the printer in order to populate the print line columns with this character.
The challenge comes for the case where both the printer and the disk are currently active - the printer started with an XIO to start printing via the interrupts for each ready character, and the disk drive started with an XIO Initiate Read/Write operation. Depending up on mechanical movement factors, the two devices could request their cycle steals independently of the other and perhaps interleaved. The SAC Interface has no indication for which device is making the cycle steal request.
The disk uses CS level 0, my box uses CS level 1 and the printer uses CS level 2. I can see if we are in CS Level 1, the one I requested. I can see if we are in clock states X0 - X6, which indicates a cycle steal operation, thus if this happens when we are not in CS Level 1 then it is a steal for level 0 or 2. I have no available signal telling me if those other states are active.
However, I do have a hint - a signal called Inhibit CS Request - which tells me if any of the following are true:
- the 1442 is presenting an interrupt request on Int Level 0
- the 1132 is presenting an interrupt request on Int Level 1
- we are currently running in Int Level 0
- we are currently running in Int Level 1
- a request exists for a cycle steal on CS level 2 (printer)
- a request exists for a cycle steal on CS level 3 (unused on my machine)
Based on the hints from Inh CS Req and other signals, it is barely possible to figure out which cycle steal is underway. I know the following:
- If the 1132 is presenting a request on IL1, it is to report the next character value ready for printing. Thus, when this is active, the printer would not be fetching words to fire hammers.
- If IL0 is requested for the 1442, which doesn't use cycle steal, then I should see IL0 go active at the end of the current instruction since it is the highest level other than cycle stealing
- If a CS request for levels 2 or 3 occurs, they will get a cs cycle at the end of the current instruction unless levels 0 or 1 are active.
- If we see the X clock at any step other than X7, we are currently in a cycle steal
- if we requested a CS on level 1 and separately, if it is active
- if we are in CS level 0 and the printer wants cycles, it will have Inh CS Req active
- if we enter a CS request cycle, but Inh CS Req is not active and we are not asking for level 1, then it is a CS level 0 activity
- if we are asking for or actively operating in interrupt levels 0 or 1, then CS Inh Req is active whether or not CS level 2 request is active
- If neither IL0 nor IL1 go active at the end of an instruction while CS Inh Req is active, then it was caused by CS Level 2 req (printer cycle steal).
This means I have ambiguity during the times that IL0 or IL1 are active - I could not track who commanded the current cycle steal operation in that case because my view of the CS level 2 request was hidden by the interrupt stuff. This becomes a problem when I have an XIO Init outstanding for the internal disk and also have the 1132 actively printing a line.
Unless I figure out something iron-clad, there is no way I can mirror the 1132 or the internal disk drive unless I add some lines from the machine that let me know definitively when a cycle steal operation is underway and what level is active. I have tight limits on fpga IO pins, so this I am not sure I will do this.
It isn't likely I would want to mirror the internal disk, but I can see the value in mirroring the line printer to keep a PC copy of what was printed. I can't do this reliably unless I can differentiate between CS Level 2 cycle steal operations and steals by the disk drive. Perhaps I can take one of the existing IO pins of the fpga and repurpose it to sense the CS Level 2 state.
A good candidate is the Meter Out signal, which is part of the standard SAC Interface, but is only important if you want usage meters to roll only while the system is active. Since I am not billing anyone by usage, that is unnecessary. I can take over the fpga pin and use it for the new level, but I still need to sort out how to add the wiring between the interface box and the 1131.
1131 PROCESSOR REPAIR
The system is current staying in reset mode and when it wasn't, had difficulties loading the IAR or memory from the console data switches and perhaps was having an issue with peripheral operation. This has to be diagnosed and repaired before I can continue with the 1053 or most SAC Interface Box work.
Everything looked good down under, but something is wrong. I decided to remove the plate in front of the resistor panel allowing me to enter from the front, a much easier task than the narrow tunnel I had to use before. The resistor panel wiring looked fine.
I moved on to checking the power on the terminals while the machine was on. What I found was that the common line to all the buttons and switches, which should be energized with +12V power, was floating near ground. That would definitely cause the symptoms I saw. It is still 86F at 7PM tonight, which means I am not going to do much powering of the system. The most I can do tonight is check wiring harnesses and connections, as well as circuit breakers, to see if there are obvious errors.
The +12V comes from the power supply to the lamps on the left side of the main console plate, then over to the common leads of the buttons and switches on the right, by way of the CE switch panel hidden under the top cover near the usage meter. I see continuity among all the devices and one of the lamps along the left side is lit, so we have +12V on the line.
However, I don't see the +12V coming in from any of the switches. Something is wrong in the wiring down by the resistor panel. The wires coming in from the switches where I have the vampire taps is the area I need to check. If a tap isn't working, then the switch can deliver the +12V signal but it never makes it up to my relays and back out to the 1131.
It is very difficult to get the screws loosened that hold the resistor panel in its inconvenient place, but if I can get them loose I can rotate the plate, see what I am doing and get good testing of all the connections. Tomorrow, I will get this done and figure out what is wrong.
No comments:
Post a Comment