August 25, 2026

Completing the RAM Module

So far, we've been using the RAM as simply as possible. We wired it to the address bus and the data bus and the ESP32 was just sending the read and write signals. But the actual CPC is more complex with a RAM module comprised of three part:

• In the middle, the RAM itself, it is made up of eight PD4164 DRAM chips. Each chip holds 64 kbits and only deals with one bit at a time. They are parallelized to get to 64 kbytes.
• Above, the four 74LS153 chips arbitrate the memory access between the CPU and CRT Controller and split the 16-bit addresses into two 8-bit words, row and column, to address the DRAM since that's what the DRAM chips expect.
• Below, two chips act as buffers for the data bus:
  • The 74LS244 is a data buffer and it allows the signal to flow in one direction only.
  • The 74LS373 is also a uni-directional data buffer but it can latch the data as well.
  • Enabling one or the other allows the gate array to dictate in which direction the data should be going.
  • Disabling both allows DMA transfers between the RAM and the gate array. Whatever data was present on the data bus for the CPU is latched while the gate array reads directly from the RAM at the address specified by the CRTC.

The design of the Frankenstrad is different though. Instead of eight DRAM chips, we are using one single SRAM chip KM681000C. This is going to change a few things:

• The SRAM takes all 16 address bits at once. No need to split the address into rows and columns anymore. This means we won't be needing the multiplexers. We still have to arbitrate the access to the RAM address and we are going to use 74HCT245 data buffers for this. Two for the CPU address bus and two for the CRTC. And we are going to enable them to grant access to one side or the other.
• The DRAM has different pins for data in and data out while the SRAM uses the same pins. This small detail is going to have its importance for the data buffer and the data latch.
  • The data buffer 74LS244 is going to be changed to a 74HCT245. Technically a 244 would do, but the 245 pinout is easier to work with as all the pins for a same port are on the same side of the chip. The 245 is bi-directionnal, but we'll enable only the one direction we need. Since it is now guarding the RAM's data pin, it needs to be enabled when we write to the RAM.
  • The data latch 74LS373 is going to be changed to a 74HCT373. For now only the CPU is connected to it, so we can just latch the data all the time. When the CRTC will come into play and for slow I/O operations we will stop latching until we're ready. Its output is only enabled during read operations.
• We are going to disconnect the ESP32 from the normal data bus, and give it its own special bus, directly connected to the RAM for DMA transfers.
• Since the SRAM does not need to be refreshed like the DRAM does, no need to worry about the CPU refresh signal and do some extra work to keep the RAM alive.

Cleaning Up the Monitoring

I made it sound like these modifications are simple, but that's a lie. Up until now, I've been following the circuit diagram. But a different RAM calls for different supporting chips. And, without fully understanding yet what the gate array does, I'm only guessing what these supporting chips are doing. And figuring out this new design takes a lot of trials, errors, and monitoring.

At first, I had both the data buffer and the data latch enabled at all time. Both chips were feeding off of eachother with a highly unstable result that ends up sitting on the bus when reading or writing. We start a read, bits are coming out from the RAM, they're latched right away and sent back to the data buffer, possibly conflicting with other bits still coming out of the RAM, on the same wires, latched again, and so on and so forth. Both chips are basically crossing the streams, which, as we know, should never be done!

I had to debug the system to understand that. Until now, the monitoring program was only looking at the write operations, but I needed to also look at the read operation to properly troubleshoot the memory module. The read operations include reading the instruction op codes though. That's a lot of "noise" when we just want to look at the memory operations.

Lucky for us, the CPU has a /M1 signal. The active low signal goes low during the machine cycle, which is when the opcode is fetched from memory and executed. The cycles that are not the machine cycles are the actual reads and writes from memory or I/O. And that's the ones we're interested in.

This is the new monitor loop that only display what we want, free of opcode reads:

void loop()
{
    const bool write = digitalRead(_write_pin) == LOW;
    const bool read = digitalRead(_read_pin) == LOW;
    const bool m1 = digitalRead(_m1) == LOW;
    if (!m1 && (read || write))
    {
        BusState state;
        state.read = read;
        state.write = write;
        state.address = read_address_bus();
        state.data = read_data_bus();

        if (state != last_state)
        {
            print_format("%c %04x: %02x '%c'", read ? 'r' : 'W', state.address, state.data, state.data);
            last_state = state;
        }
    }
}

Seeing exactly what is read, from where, and what is written is really helpful, because then I can see when the system stops working and where by moving the data probe along the bus. And the solution is obvious: only enable the data buffer when writing, only enable the data latch when reading, and, at least for now, always latch the data.

What's Next

We're getting there! Only 3 important chips to go: the CRTC, the PIO, and the sound chip. Once this is all wired, we can flash the ROM with the CPC BIOS, and execute it! Or at least try... At that point, our Z80 is going to run a whole bunch of instructions. It's going to do a lot of crazy stuff and I'm expecting a lot of hiccups.

Seeing what it's doing is going to be crucial. To that end, we are going to give our monitor an upgrade and have it look at the machine cycles and print out what instructions are being executed.