... I think I know what's going on for some reason.

I was hacking on some hardware (ATmega16 to be specific; a project for work), and trying to get it to talk to the PC via its SPI port (bit-banged unfortunately, due to the ATmega absolutely *requiring* _SS to be asserted, which is not practical for my application). The problem I found was that the Vih parameter for the ATmega16 is 0.7Vcc. Since it's a 5V part, it is only 3.5V. But, the highest voltage put out by the PC parallel port on my motherboard is only 3.3V!

Now, I always thought that the PC parallel port was a 5V port. So, why is my port only putting out 3.3V?

Anyway, I'm thinking of implementing a pull-up resistor on each of the inputs to the ATmega16, hoping that will take care of the situation. I figure that with a same-value resistor, the voltage swing will be between 2.5V (when the input is low) and 4.3V (when the input is high). I don't know what Vil is just yet, but I've run some tests, and it looks like any voltage below 3.5V looks like a binary 0 to the ATmega16. Further tests will confirm this.

Here's hoping.

The problem with the Kestrel was just the opposite -- the 6522 VIA wasn't properly registering logic high with the PC parallel port, though I think it's because it wasn't being buffered with a resistor (like the SPI port interface on the ATmega16 is). But, we'll see.

It wouldn't surprise me at all if the newer PCs have a 3.3V part there, put in with the assumption that it would be ok since TTL only needs 2.4V to be solidly in the "1" region. You might damage it if you pull it up more than 3.3V plus the small drop of its Schottky protection diode. You might need to put in a comparator, TTL buffer, or other level translator, which won't be too big a deal since you're only dealing with around 3 lines and not five times that many. What could be a problem is if you have to change the data direction on one or more of them.

Not necessary; the PC still only sees 3.3V. Here's a quick-n-dirty schematic:



When PC is low, ATmega16 sees 2.5V. When PC is high, it sees 4.3V (more or less). The PC pin is fully isolated from the voltage that the ATmega16 sees.

2.5V is in no-man's land in 5V CMOS logic. Usually if Vih is .7Vdd, Vil is .3Vdd.

If the PC pin could be an input before getting intialized, it could get pulled up to 5V through 1K, or at least through 2K if the ATmega16's pin is also an input. If the PC is truly 5V-tolerant, that won't hurt it; but otherwise many parts' static-protection diodes can be damaged if continuously made to handle even very small amounts of current. I just read about that in one of the electronics industry magazines, but I don't think I kept the article.

If the PC port has 5V tolerance, the other problem of the low logic level could be solved by replacing your left-most 1K resistor with a 1N4148 silicon diode, with the cathode toward the PC. This will make the voltage at the ATmega16 input pin go from .6V or .7V to at least 3.9V, giving you valid logic states for both 0 and 1.

Well, it turned out the chip was behaving exactly as it should after all -- unlike the 6522, PORTB is the output port, and PINB is the input port. This allows the software the ability to control internal pull-ups on a pin-by-pin basis, apparently (which is meaningless for my specific application, but still, it's something I wasn't aware of).

I was assuming it behaved similar to a 6522 VIA chip, where the input and output ports overlapped.

Anyway, this is good to know for future reference.

I actually got the MCU to synchronize with the PC, which is good. Now it's apparently locking up hard after receiving a byte, and for reasons that are wholesale unknown to me. *sigh* But at least it looks like a software issue.

Because it's probably TTL logic levels. See ...

http://www.twysted-pair.com/74lsxx.htm

.. for what to expect.

To bring the PC port outputs up to near 5v for a logic 1 just use 4K7 pullups. You won't hurt the PC port and logic 0 levels won't be changed.

Lee.