From what I've seen, most of the whining about the limitations on the 8255 comes from people with limited experience with the thing. The 8255 is a good port for general purpose applications like development boards or general purpose boards for which the application is TBD. If one already knows what's going to be done with the I/O, it's hard to justify the size or expense of the DIP-40 or even the PLCC-44.

Given a plcc-44/DIP-40 footprint, it might make sense to move closer to the model of the Motorola 68HC24, which is their port expander. Then, of course, you might want better performance, since the fastest standard-pinout MCU's, and those are the ones that would need the expansion, operate at as much as 40 MHz and not all of them can modify their external bus cycle length/timing. Building in the address latch, which is what Motorola did, would be a boon, as would modifying the operation such it could do full handshaking under all conditions when one so uses the "port-C" capabilities. Even if it did that, howver, it should have output buffers at least capable of matching typical HC logic, i.e. 6 mA and 24 mA would be better. Even the old 74C-series buffers from NSC were rated capable of that. After all, an output should be able to drive a full-sized LED by driving the anode with one pin and sinking the cathode with another. If it can't do that at full brightness, or drive a small relay, it's not really worth the effort. There are enough old 8255's available even today.

You could, of course, cover both bases by providing a device that's a hybrid between the 68HC24 and the 8255, and I doubt it matters much which sort of I/O port you put in it. That would give you more market.

The old 2.5 mA output types never appealed to me, since they had to be buffered with parts that could, in effect, replace them.

If I were going to expend the time and effort, I'd have to be headed for a part compatible with the fastest external-bus-capable MCU's, capable of driving on the order of 24 mA from either rail, and having an internal address latch, maybe with relocatable internal address decoding as well. I'm not, of course.

RE