Kai,

Back in the '70's and '80's, when the exciting and all-too-famous innovation in the electronics industry in the U.S. was on everyone's lips, the "real" innovation didn't happen, generally, in large companies willing to risk resources and build application-specific hardware. It was done by small operators who bought or produced highly flexible microprocessor-based hardware with maxmial flexibility, hence, maximal reuseability. The 8255 fits that model, in that it can do a number of things and operate in a number of modes. However, once placed in an application, it will probably only operate in the mode in which it was first applied. This made the 8255 an attractive option for those who built those microprocessor-based boards that people commonly used for small-scale development. Every major semiconductor house had an equivalent circuit, e.g. Motorola's 6820/21, Zilog and Mostek's Z80 PIO, etc. MOS Technology even developed a more general chip, the 6522, which had provision for a serial channel in addition to the typical two parallel ports. The technology of the time kept these devices from becoming powerful enough at the outputs to drive more than a darlington, i.e. no relays or LED's, and that was their weakness. While they did find their way into many applications because they had worked in prototypes, serious "productization" seldom left them in a design intended for a specific purpose.

Using the 8255 as it was designed was pretty easy. Using its inherent features was easy. Changing something, even in a small way, was not, unless it was accomodated by the features of the 8255. Because it had only 8 bits in its control register, it could only do what the Intel guys envisioned and, therefore, provisioned with the 8255's internal resources. There were combinations of the STB, ACK, and INTRQ signals that didn't always work out for certain types of interfaces, and there was really no way to make the 8255 do what was needed, so one had to add external hardware. Once one was doing that, the interface because sufficiently specialized that one was better off, economically, to put the hardware in place without the 8255.

If Lynn were to provide a path, perhaps through redefinition of the control register bits, he could provide extra logic and controls to enable the Port-C pins to function in pretty much any way. However, in the process, he'd lose the compatibility with original 8255 driver code that he requires. If he were to modify the external hardware, adding a pin, for example, he'd lose compatibility with both hardware and software, so he'd no longer have a valid replacement.

It's probably not worth the effort and investment for someone wishing to put something on the replacement market.

RE