From: daz@hal.gnu.ai.mit.edu (David A. Z.)
Newsgroups: alt.folklore.computers
Subject: Re: Spectrum hardware (was Re: VCS processor)
Date: 11 Jan 93 18:02:52 GMT
Organization: /etc/organization
NNTP-Posting-Host: hal.gnu.ai.mit.edu

In article <1491@eouk19.eoe.co.uk> dhembrow@eoe.co.uk (David Hembrow) writes:
>
>It's a little known fact that when a Z80 IO instruction such as IN A,(n)
>is executed, the previous contents of the accumulator appear on the address
>lines A8-A15, the IO address n appears on A0-A7. Because of this, depending
>on the contents of the accumulator before this instruction is executed,
> [...]

 
     A few years ago, I programmed the ROM based software for a 
Z-80 based device ("Starbus Busdriver") to  multiplex up to 35 RS-232 
signals to together over a single twisted pair wire in any configuration;
the idea being that you could stick a serial device in every room of a
building and connect them using only a single pair of wires which may have
been prewired for an extra telephone line.  (This was the only product of
the now defunct ACI in Westboro, MA.)

     At a certain point in developement, we were having problems with the
output being corrected by noise in the data stream.  Eventually, it became
obvious that it was only uppercase C's and lowercase d's that appeared
erroniously in the data stream.  The typical "debate " of me saying it was
a hardware problem and the hardware engineer saying it was a software
problem unsued.

     One day while working on this problem with the engineer, I happened to
use a test pattern other than my standard one of "Winnie the Pooh lived in
the 100 acre woods under the name of Sanders" and it transmitted correctly. 
He then noticed that the pattern sent correctly didn't contain any
uppercase C's and lower case d's in either the output, or the corresponding
input, and insisted that they must be related.  I thought he was crazy, but
tested the theory.  It turned out he was right about it.  

     We then went back into the "Software vs. Hardware" arguement, with him
being much much more sure of himself, now that the problem was much too
interesting to be a hardware problem.  Oh course, it turns out he was
wrong.

     He had messed up the chip select on the memory chip, and the I/O
instructions (as mentioned in the quoted text above) would throw the data
on the bus and end up somewhere in a corresponding place in memory.  (Since
the instruction before the Out command would load A with the byte to be
output.)  Thing was, the device didn't have much memory, and most
instructions threw the data somewhere harmless, but the C's and d's
corresponding to high order bits of my transmit buffer and would be
inserted into it as such.

     At that point, he ran to add the chip select and it fixed the problem. 
Since we were looking for cute tricks to slow other people from reverse-
engineering the product and putting out clones, I suggested that we leave
the chip select off, be careful about where in memory these bytes ended up,
and used the effect to our advantange, but he didn't go for it.  :)

     - daz@gnu.ai.mit.edu

Ps. If anyone out there ever heard of Starbus/ACI in Westboro, drop me some
email.  :)
Newsgroups: alt.folklore.computers,alt.folklore.urban,alt.religion.kibology