Updates

After I write the first draft of an article, I go through it, mercilessly scratching out phrases, sentences, and even paragraphs that aren’t absolutely necessary. I do this so as not to take up too much space in the newsletter; others must also have the chance to speak their mind. While this occasionally obscures some minor point, l’ve never grossly changed the meaning of a statement… until last issue. Fortunately (for me) no one seems to have caught the error, as yet. Now, I’d like to quickly insert a correction to which I can point in my own defense, should someone send me a “nastygram”.

In “Running Those Unrunnable Spectrum Programs”, 1 may have inadvertently given the impression that any I/0 device that does not check M1 will interfere with interrupt mode 2. This is not true. It is true that the I/0 port must not put data on the bus unless M1 is high, but there’s no way to do this. For example, if the port checks that RD is low before becoming active, everything will be fine, because there are no cases when RD, M1, and IORQ are all low together. Unfortunately, not all peripherals do this. I know of two such “design flaws”; one is obvious, and the other is quite subtle.

The obvious flaw occurs in a low cost input-only type peripheral that doesn’t sample the RD line. (At least one Spectrum joystick interface does this.) This save on hardware, but carries with it the requirement that the port should only be read from; never written to. Since this scheme only samples IORQ and the address lines, it can be accidentally activated when an interrupt is serviced.

The second, not so obvious, flaw usually involves designs with programmable peripheral chips, like 8255 or the 6820. Those chips have a line called R/W, which is only used when the chip is enabled. In this case, it’s pulled high to read from the chip and pulled low to write to it. It’s often attached to the Z80 WR signal, under the assumption that if its enabled and not being written TO, it MUST be being read FROM. The problem occurs when the chip is enabled using IORQ and the address lines, but not M1. In this case, an interrupt service can enable the chip to put something on the data bus. Then it’s bye-bye program. As such, if R/W on the chip is attached to WR on the Z80, then the chip enabling must only be active when M1 is high.

Interestingly enough, the Z80-P10, a programmable peripheral chip designed by the same folks who gave us the Z80 microproceesor, is set up so it’s impossible to commit this error. I guess it pays to “stick with the same brand”.

Anyone who’s followed this line of reasoning to the end is likely to agree that attempts to simplify it just invite disaster. I’a glad for the opportunity to set things straight.