Alioth's Journal: [Z80] Duh

Well, I just Daily WTF'd myself.

In head scratching why a high interrupt rate caused (a) corruption on the LCD and (b) something that looked like stack corruption, I decided to look at the timing diagram for interrupt acknowledge. I had come up with many bizarre (and wrong) theories about the LCD corruption (random characters, things appearing in the wrong place etc). It also all feeds back to my problems with the PIO a while ago.

The little catch is that I had forgotten how maskable interrupts are acknowledged. A special M1 cycle, where M1 goes active with IORQ (rather than MREQ, which is the normal M1 cycle). But my device select logic only looks at IORQ...so guess what, every time an interrupt was acknowledged, bus decoders were looking to see whether this was an IORQ for one of our devices.

The LCD is on port 0. So while the address and data bus float during IORQ with no actual address/data on the bus, usually when IORQ+M1 were asserted as an interrupt acknowledge, the LCD was getting selected. So occasionally the LCD would see the right bit of data whizz by as the interrupting device placed an interrupt vector on the data bus, and the random garbage appearing on the LCD was simply whatever character the interrupt vector happened to map to (usually not an ASCII character). Since the address bus is in high impedance state, sometimes a bit of random electrical noise would mean the LCD would see something meaningful as a control sequence, treat it as the CPU trying to read, and try and dump a value on the address bus at the same time the interrupting device was writing a vector! So the CPU would get something pretty random depending on whose outputs had the lowest impedance, and get an interrupt vector which pointed to any random part of the 256 byte interrupt vector table (most of which is unallocated, and just contained whatever random value happened to be in that part of RAM) and usually crash the machine in what looked like a return address stack corruption.

The solution is of course to gate IORQ before it reaches the address decoder, so it only reaches if IORQ is low and M1 is high. For devices hanging off a 74HC138 this is easy - it has three enables, just invert M1 and put it on one of the three enables (I'm already using the high enable for A7). For the LCD interface which sits on its own PCB, this uses a 74HC688 comparator to look for its address - it just needs to be gated via an OR gate - inverted M1 to one input, and IORQ to the other, the output going to the LCD interface.

The reason I feel really really stupid is I saw a schematic for an LCD interface for a Z80 which included this logic, thought "why the fsck do you need all that buggery with the M1 line?" without investigating why. Argh! Important lessons have been learned.