THE CPU STOP SIGNAL DID NOT DO WHAT I EXPECTED
I was watching the +Cpu Stop signal in order to block my loader if the processor was active running instructions or doing input output with peripherals. However, when I looked at the signal, it did not really do what I expected.
When the machine initially powers up, it is not running, but the stop latch is not set! The latch is set by two conditions - when a parity check occurs and when the user pushes the Imm Stop button. However, the button press only activates the stop latch if the CPU was actually running, otherwise it does NOT turn on the stop latch.
I then moved on to a signal generated by the Run logic of the machine, which at first blush seemed good until I noticed small pulses on every clock cycle, not really turning on the Run signal but the pulse was big enough to trigger my loader logic.
The reason for those is a known quirky behavior of the flip flop circuit from IBM SLT technology. Essentially it has a set and a reset input and offers two outputs. One is logic high when the flip flop is set (called Q in modern flipflops) and the other output is logic high when the flip flop is not set (not Q).
The flip flop is generally turned on or turned off by a pulse on the set or reset input. However, if the flipflop is in the off state and a reset pulse arrives, the flipflop emits a small pulse on the Q output. The flipflop was at logic low, since it was in the off condition, and it doesn't change its Q or notQ outputs, but there is this glitch pulse that looks like a very brief logic high.
The same quirk exists when the flipflop is on (Q is logic high and not Q is logic low). If a set pulse arrives, the flip flop will emit a brief logic high pulse on the not Q output but long term not Q remains low.
IBM protects against this by placing AND gates in front of the set and reset inputs, with one signal to the AND gate coming from the Q or not Q output. Thus, if already set, no additional set pulse gets through. If not set, no additional reset pulse gets through.
However, sometimes they don't put the protective gates in front. The Run flipflop is a case in point, where the reset input is not protected by an AND gate. A number of conditions can stop the processor, such as the end of an instruction if in single instruction mode, or the end of a memory cycle in single memory cycle mode. If the processor has executed a wait instruction or was stopped by the Imm Stop button, it will also reset the Run flipflop.
All of these conditions are tied together (a wired OR gate) to reset the flipflop. In addition, other outputs are wired together to the Q output. One of them produces very short pulses - glitches. This is why that signal is unsuitable for my loader to monitor.
I did find another related signal that does track logically with the running or stopped state of the 1130. I changed the wire wrap to my B1 header block to bring that to the core loader.
SCOPE SIGNALS FOLLOWED THE STATE MACHINE AND 1130 CYCLE STEAL
The data values I typed into the loader were displayed on the Storage Buffer Register and when I displayed those locations, the data I had loaded was there. However, I noticed that the RUN lamp lights and does not go out.
The scope showed me that I was continuing to hold up the Cycle Steal request line, so that the processor was repeatedly providing cycle steal memory accesses. I expected to see the request dropped once we were sure we had been granted a cycle steal access, but that didn't occur. I suspect a flaw in my logic board (shield) and will dig into the design at home tonight.
 |
| Yellow - request, green - granted, purple - X6 cycle |
No comments:
Post a Comment