Firstly the LCD has to work without any support from the ZX81. This means, the interface must only be plugged in and has to display the ZX81 screen. Only this way it will be compatible with all programs and does not influence the ZX81 anyway. It's not easy to get access to the ZX81 screen (DFILE) out from the ZX81. All experiments using the /BUSRQ failed. So I decided to mirror the whole Basic-RAM and access this "Dual-RAM". It worked!

The LCD interface is an external, separate Z80 computer working at the ZX81. Any access at the Dual-RAM is synchronized: write access from the ZX81 to his Basic-RAM has first priority. Read access from the ZX81 at the Dual-RAM is not needed and so not enabled. When both CPUs -the ZX81 and the LCDIF- accessing the Dual-RAM, the LCDIF receives WAIT states until the ZX81 CPU comes in a refresh cycle. As the interface is running with 8 MHz CPU clock there is enough time, to access the Dual-RAM when the ZX81 CPU is in the Refresh cycle.

Now you have a copy of the whole Basic-RAM space which you may access from out the ZX81 and without any influence to the ZX81! The interface now has to convert the characters of the ZX screen into the LCD generic format.

Driving the display:

The interface has another RAM chip and holds a complete pixel image of the LCD screen. The output of each line to the LCD panel is similar to the video routine of the ZX81: a NMI routine which ends with a JP (HL), where HL is above 8000hex, A15 is high and M1 is low. This sets a logic, the CPU now only reads NOP instructions and counts up the addresses. In this state the pixel data from the RAM will be separated and taken to the LCD screen in half bytes. As we have 640 pixels at the panel and we only need 320 pixels or less for the ZX screen, we can half the resolution simply by shorting two data signals and thus driving the panel with a 4 Bit data. Separation from 8 to 4 Bit is managed by the refresh clock of the CPU which is in the NOP cycles exactly symmetric at half of the CPU clock. By writing each line two times to the panel the vertical resolution is reduced to 240 lines. At the end of each line an INT is generated to set the end-of-line clock for the LCD and to reset the NMI counter. This counter gives the next NMI after a selectable time, i.e. after 256 CPU clocks.

Firmware:

Additional features and the mysterious "task":

As we know the LCD has 240 lines and the ZX screen has only 192 lines. So there is a space for 6 character lines below the regular screen. In this space will be displayed whether the ZX runs in SLOW or FAST, free memory space and a "task" address. The first goodie: the LCD shows the screen even the ZX runs in FAST mode! And the second: what's about this "task" now? We know the ZX has some unused bytes within the system variables. Now the LCD IF continously reads one of them, and this cell is called the "task" address. And is always displayed at the panel because this address can be edited. What tasks do we have? Well, there could be thousand tasks we may want the LCD IF to do secret behind the ZX81. For the first time we can tell the LCD IF not to show the (text) screen but some HiRes screen. We can set another task address. And we can move programs stored anywhere within the Basic RAM space of the ZX81 to the LCD IF and include them with the system loop. Imagine: you can show any of the system cells of the ZX81 at the LCD, always and even if the ZX is FAST mode. Really nice hacking tool, isn't it?