Rockwell R6551A vs CDP65C51AE4

[BigEd]

Hee hee. There's a lot to be said for datasheets - they do pack a lot of information in, sometimes also sketches of applications or sketches of the internal operation.

[jgroth]

So true and sometimes you miss that little detail that makes the IC you want to you use ticking.

[floobydust]

I'm a bit late on this thread, but opted to post with some additional background info. I do have a fairly large collection of 6551/65C51 chips. Brands I have include Rockwell (6551/65C51), Syntertek (6551), AMI (6551), Harris/Intersil (65C51) and an assortment of various lot numbered WDC (65C51). In short, datasheets for these parts are different for the XTAL, some, like early Rockwell, Synertek and AMI showing NO capacitors or resistor, to Harris/Intersil showing two caps and WDC showing one cap and then later showing one cap and a resistor. So much for alternate sourcing and compatibility, as you found out.

As far as which chips seem to be the best all around, I would suggest using the Rockwell R65C51. While all of my older NMOS versions function fine, CPU clock speeds typically are limited to 1- or 2-MHz, albeit my Synertek chip runs perfectly fine with a 6-MHz CPU clock. Being older NMOS they also draw more supply current. You can likely get 4-MHz Rockwell parts which will run fine. but I've not had any luck running faster than 4-MHz. The Harris/Intersil 65C51 (4-MHz version) has some odd issues resulting in some corrupted data output despite being a confirmed NOS chip. I tested using a CAN oscillator and still get some random corrupted data output. The WDC chips all seem to have their anomalies, including the current production version which is basically broken on transmit. Still, I have one earlier LOT number that has been running fine with a 3.6864-MHz CAN with a 10-MHz CPU clock configured for 38.4K baud rate.

One last thing I've found in testing over a dozen chips (all brands of 6551 and 65C51) is a highly intermittant bug on transmit when using interrupt-driven I/O. The transmit interrupt will turn itself off, which will result in stalled operation. I changed my BIOS to always turn the transmit interrupt on when checking for more characters left in the transmit buffer. This cured the problem and all chips transmit reliably, sans the odd problems mentioned above with specific chips.

[BigEd]

> highly intermittant bug on transmit when using interrupt-driven I/O. The transmit interrupt will turn itself off

That's terrible!

[GARTHWILSON]

floobydust wrote:

One last thing I've found in testing over a dozen chips (all brands of 6551 and 65C51) is a highly intermittant bug on transmit when using interrupt-driven I/O. The transmit interrupt will turn itself off, which will result in stalled operation. I changed my BIOS to always turn the transmit interrupt on when checking for more characters left in the transmit buffer. This cured the problem and all chips transmit reliably, sans the odd problems mentioned above with specific chips.

It sounds like there's a chance that tip #14 in my "Tip of the Day" column addresses the problem: viewtopic.php?p=2317#p2317

[BigDumbDinosaur]

GARTHWILSON wrote:

floobydust wrote:

One last thing I've found in testing over a dozen chips (all brands of 6551 and 65C51) is a highly intermittant bug on transmit when using interrupt-driven I/O. The transmit interrupt will turn itself off, which will result in stalled operation. I changed my BIOS to always turn the transmit interrupt on when checking for more characters left in the transmit buffer. This cured the problem and all chips transmit reliably, sans the odd problems mentioned above with specific chips.

It sounds like there's a chance that tip #14 in my "Tip of the Day" column addresses the problem: viewtopic.php?p=2317#p2317

Another arcane possibility is that reading the status register immediately before the transmitter is about to interrupt may cause that interrupt to not happen. This sort of errata has been noted in the past in a few other 65xx I/O devices, especially the 6526 complex interface adapter (CIA). My memory is a bit hazy on this, but I believe that what was happening with the CIA was if the interrupt status register was read one or two Ø2 cycles before timer-A was scheduled to interrupt due to underflow, the timer interrupt would never occur. What was aggravating about it was the failure was sporadic in nature, suggesting there was a timing issue within the CIA's circuitry. This errata was identified as a primary cause of random RxD overrun errors in the Commodore 64 and 128 software 6551 emulation.

Given the long history of buggy 65xx I/O silicon, it wouldn't surprise me to learn that the 6551 has yet another "undocumented feature." All the more reason to not use it.

[GARTHWILSON]

Even if you cleared the master interrupt bit (bit 7) by reading the status register, the individual interrupt bits will still be testable. You just have to make sure you test for all the potential causes of interrupts in the IC before leaving the ISR, instead of just handling one and figuring you're done.

[floobydust]

Hi Garth,
It's not related to tip #14 which is known to me. My ISR checks for Receive first, then Transmit second. Also, the ISR will check the Transmit bit after handling a Receive interrupt. The routine that exposed this problem was based on continuous transmit only, i.e., no characters ever received as the board was running an instruction loop that only generated output. The workaround for this was to enable the transmit interrupt every time I put another character into the transmit buffer (a 128-byte FIFO), which is a routine outside of the ISR. The ISR will turn the transmit interrupt off upon exit if there are no more characters in the buffer.

Hi BDD,
Now that's an interesting arcane possibility. I also use timer1 of a 6522 for a RTC which is set for 4ms, so the processor gets an interrupt from that 250 times per second. The ISR does check the VIA timers first (timer2 is used for delays and set at 1ms), then exits to the service routine for the 6551. So in this scenario, the 6551 status register is also read 250 times per second at a minimum whether it's generating any interrupts or not.

I never used the 6551 emulation in the C64, so never ran into that problem, but your knowledge around the 6526 is more extensive than mine. I only did some basic programming for one using the TOD clock and setting up an interrupt-driven and buffered printer port (on the C64). Until I get around to finishing another board design I'm stuck with the 6551. I have some of the NXP UARTs around, just need to build up an adapter and do the development for it... spare time, it's not free

[GARTHWILSON]

floobydust wrote:

Hi Garth,
It's not related to tip #14 which is known to me. My ISR checks for Receive first, then Transmit second. Also, the ISR will check the Transmit bit after handling a Receive interrupt. The routine that exposed this problem was based on continuous transmit only, i.e., no characters ever received as the board was running an instruction loop that only generated output. The workaround for this was to enable the transmit interrupt every time I put another character into the transmit buffer (a 128-byte FIFO), which is a routine outside of the ISR. The ISR will turn the transmit interrupt off upon exit if there are no more characters in the buffer.

So are you saying the transmitter interrupt actually got turned off in the command register, or just that the "transmit data register empty" bit in the status register isn't set anymore?

[floobydust]

The transmit interrupt is going off by itself, as it will only be turned off in the ISR if the transmit buffer is empty. Changing the character out routine to turn on the transmit interrupt every time a character is put into the buffer fixed the problem. Go figure, but then again how many folks actually use interrupt driven transmit with the 6551?

[BigDumbDinosaur]

floobydust wrote:

Go figure, but then again how many folks actually use interrupt driven transmit with the 6551?

In the only instance in which I used a 6551, in a serial link between a Commodore 128D and 65C02-based terminal server, I used interrupt-driven I/O in both directions. That was with an NMOS 6551. I ran it at 19.2Kbps without error, using CTS/RTS handshaking.

[floobydust]

BigDumbDinosaur wrote:

floobydust wrote:

Go figure, but then again how many folks actually use interrupt driven transmit with the 6551?

In the only instance in which I used a 6551, in a serial link between a Commodore 128D and 65C02-based terminal server, I used interrupt-driven I/O in both directions. That was with an NMOS 6551. I ran it at 19.2Kbps without error, using CTS/RTS handshaking.

I've always used the 6551 with interrupt-driven/buffered I/O as well, but I haven't seen too many bits of code that do. My current BIOS does this along with RTS/CTS handshaking.