 Greetings, Retro Friends! In the last video, I put together the four-digit hex displays so that I could see what the CPU was doing with the address and data lines, especially when the CPU is held. Now, according to the datasheet, when the hold line is activated and the CPU acknowledges hold, all of the CPU's outputs go high impedance. And since we have no pull-ups for the display's inputs, the display will show whatever it wants to display. This means that I have to capture the address lines at some point, and that means using a transparent latch. A transparent latch, like the 74373, allows the data through transparently until disabled, at which point the data is latched. So, we need a CPU signal we can use to indicate that the address lines should be latched. This memory-enable line looks useful. When it's low, the CPU is accessing memory, so the address lines have to contain something meaningful. So, all we need to do is invert this signal and use that as the latch-enable signal. That lets us display effectively the last address the CPU accessed. When the CPU is held, this is the last address the CPU accessed before being held. Okay, I've hooked up the CPU address lines to the display. This button is the reset signal, and here's the clock generator chip from before. Interestingly, even though I have no latches here, it looks like the display is showing something when I assert reset on the CPU. Alright, so here I've added the latches and a switch for the hold signal. Turning on the power with the processor held seems to put the address lines at 7FFF. Actually, it's FFFE, since I forgot to shift the address lines one. Addresses in the TMS-9900 CPU are always even, which is a bit silly, considering that the CPU accesses memory always 16 bits at a time. It's as if they couldn't get past the thought of memory being 8 bits wide. Anyway, I can now hold and un-hold the processor, and it seems to be doing something. Great. Now, this isn't perfect. If we look at the timing diagram in the datasheet, we see that the Phase 2 clock causes most outputs to change, and that includes the address, data, and the memory enable lines. This means that the memory enable line unasserting may or may not be synchronized with the address and data lines. However, Phase 2 is a good synchronization point, so we need to gate all our signals with Phase 2 low. That's what I've done here. I have a 7408 AND gate here. The memory enable line goes through an inverter and to the AND gate. The timing chip generates an inverted Phase 2 signal, and that goes to the AND gate as well. The output of the AND gate latches the 373s, which feed the display. That seems to work. Again, this last digit should always be 0 because I forgot to shift the address lines by 1. Now, it's a little hard to see here, but I noticed that touching one of the wires would cause one of the digits to change. I found that one of the pins on a latch had bent, so I straightened it out and everything worked fine after that. Okay, the final test is to use the single step state machine. I wrote a program very similar to the hex display one. I used a bigger chip, an AT-Tiny 2313, which can act as a 256 by 7 ROM, since it has 8 available lines on one port and 7 on another. The code for the ROM is written in assembly. Here I'm using port B as the address lines and port D as the data lines. We shut off the watchdog timer first as before and then just loop. First, we check the output enable line and change the direction of port D accordingly. To disable the output, this means setting port D as inputs, which puts it in high impedance mode. Then we just read the address lines at port B, pull the data from that address plus hex 100, and put the data on the data lines at port D. It's pretty slow. It's about 13 cycles per loop, which is about 1.6 microseconds, but that's okay. In this case, I don't need anything faster. The code, by the way, is available on GitHub, linked down below. The state machine only needs a 64 by 4 ROM. I wrote a Python program to generate the ROM, compiled the whole thing, programmed the chip, and put it on the breadboard. As before, it uses a 74-175 quad flip-flop to store the current state. And I'm using these 3 LEDs to show the current state. It seems to work okay. I can let the processor run, and stop it, and then single-step it a few times, and then let it run again. Great. So, right now, what is being latched is the last address in memory that the CPU accessed. If I latched the data lines in the same way, it would be the last data that the CPU read or wrote. With just a little modification, I can change this to latching the address of the last instruction retrieved by the CPU by including the IAQ, or Instruction Acquire signal. Similarly, latching the data lines on this signal would show the last opcode executed by the CPU. I could add even more displays, showing any location and data the CPU read or wrote during an instruction by keeping track of the number of memory accesses during that instruction. However, according to this table, including the opcode fetch, there is a maximum of 8 memory accesses per instruction, so I'd need 16 of these 4-digit hex displays. I'm crazy, but this would be a really crazy front panel. Or I could just use 2 displays, one for address and one for data, and store the 8 accesses in a RAM, and have lights to indicate which arguments were captured. Then a push-button interface could navigate through the arguments. Since we're speaking about front panels, I need a way to manually write and examine memory. Since that requires putting the CPU on hold, the address and data displays as I've built them aren't of any use. I could have a few more displays and buttons that let me do this while the processor is on hold. Also, I still need a system RAM, because right now the processor isn't hooked up to anything and is essentially executing random instructions. There's lots of stuff still to do, and that means lots more work and more videos to make. So thanks for watching and subscribe so you don't miss out on the rest of this project. Thank you.