This is a bit difficult to see but still clearly shows the relationship between the SYSTEM CLOCK and the WRITE line on CPU pin 22. By studying this, it is possible to work out just how many clock cycles the I/O write instruction uses. NOTE that in this program we NEVER write to RAM (which would make the investigation null and void as the write instruction to MEMORY is much shorter. (The processor adds an automatic WAIT state to all I/O instructions.)
And now onto a double trace! Back to our familiar I/O screen, we see CPU pin 20 IORQ on the lower trace (with it’s 5x negative transitions) with the one on the top being the keypad read pulse. It is very useful to have to opportunity to see the time relationships between signals, as no end of conflicts / erratically operating devices can be picked up this way. Obviously the better the scope the easier they will be to see. This is an old ‘scope, but it is still capable of reliable results with projects such as this one.
This is of course, the ‘remains’ of the I/O signal going to the displays
Perhaps a bit more difficult to understand? You remember that we looked at the jumble on an address line a few screens ago? Well the TOP trace this time is a DATA line- D0 to be exact, and it’s locked to the happenings on the 74xx374 keypad latch when it is actually READ onto the bus. Note that as the LOWER trace goes LOW on the left hand side, the ‘mess’ on the data line suddenly goes to a perfectly clear high level? In this instance we are seeing that keypad switch ‘0’ (Minutes adjust) is at a high (inactive) level - which it will be until it is pressed.
As mentioned before, a logic probe would show the latch ENABLE (clock), but not the data bus activity of course. Don’t forget that it would also be useful for checking that any other associated signals are being clocked as well, such as OUTPUT ENABLES, CHIP SELECTS etc.