Screen memory

We know from a previous log that the screen is 768bytes @  0x2400 and the character map is 1024bytes @ 0x2C00.

Hardware

The PIC will be acting as a bridge between the Raspberry PI (used to render the screen image to a HDMI viewing device) and the Z80 bus. The PI will command the PIC to read a portion of the Z80 memory space, and then provide it as a SPI byte-stream. Once the PI has collected the required data, it will render it its own framebuffer.

State machine

I love state-machines! Here is a draft of the PIC's:

Whilst the PIC is in IDLE state, it is prepared to receive commands from the PI over the SPI bus. One such command will be to fetch the "status" of the PIC, if one is signalled, and another is to request to read a block of memory.

In the READ_DATA state, PIC has requested control of the Z80 bus, and is currently reading the requested number of bytes from memory space.

Once all the data has been read from the Z80 bus, it goes into the XFER_DATA state. This is when the PI can read the collected bytes over the SPI.

Once the data has been transferred, the PIC goes back to the IDLE state.

The hardware

As an 8-bit PIC, there is no SPI FIFO, so the speed can not be very fast.

The PIC is perfectly happy with 3v3 as a "logic high". I plan to use a resistor-based voltage-divider for the PIC-to-PI signals....with the expected reduction speed of the SPI for the PIC to manage, I'm sure the voltage-divider will be fine. :)