WDC 65C51 chips defective

[Alarm Siren]

This bug is extremely irritating as it effectively rules out the '51 from any new designs, and no-one (apart from the '51, anyway) seems to make UARTs in DIP packages anymore. The only one I've been able to find is the Intersil CP82C52Z - which looks like similar deal to the '51 overall, except for being incrediably expensive! £30 for a UART? no thanks.

EDIT: tell a lie, I found this 16x550 chip in PDIP for £6. Only one I've found though.

[GARTHWILSON]

If you have SPI, you can use the MAX3100 which is available in a 14-pin DIP which is easy to work with and takes very little board space. If you want line drivers and receivers integrated, you can use the MAX3110 which comes in a 20-pin narrow DIP IIRC.

[BigDumbDinosaur]

Alarm Siren wrote:

This bug is extremely irritating as it effectively rules out the '51 from any new designs...

The '51 isn't really good for new designs, bug or not.

Quote:

...and no-one (apart from the '51, anyway) seems to make UARTs in DIP packages anymore.

Unfortunately, that is the way the industry is headed. The cost to stuff a board with SMT devices is a fraction of what it is with through-hole parts, and of course, less board real estate is required for the same functionality, reducing the per piece bare board cost. These items, as well as others, dictate where the electronics industry is going, and such changes are as inevitable and unavoidable as death and taxes.

PLCC packages can be socketed, which sort of makes them through-hole parts—the NXP DUARTs I use are PLCC44. The sockets have a 100 × 100 mil pin grid, which means they can be mounted on standard perf board. If you are wire-wrapping you will pay a premium for compatible PLCC sockets.

Quote:

EDIT: tell a lie, I found this 16x550 chip in PDIP for £6. Only one I've found though.

The 16C550 is an okay UART but in my opinion, has a somewhat obstreperous programming model. It was for that reason, as well as the desire to have two TIA-232 channels, that I instead used an NXP DUART in POC V1.

[Tor]

I have a couple of DIP Z85C30 dual-channel UART (or 'SSC', Serial Communication Controller) in my drawer, which I will one day try to interface to a 65Cxx setup. They look fairly nice, feature-wise. Documentation is good. And it's not expensive. It looks like you can still buy them (Mouser link). That's a 10MHz part. I have a 16MHz version (DIP version, which Mouser doesn't currently stock). As Wikipedia says, the Z8530 version is ".. designed to allow use with any CPU or host platform" (unlike the Z8030 which is Z-specific). But I haven't looked carefully at the details of interfacing yet.

[Edited a bit]

[LIV2]

The SC28L92 is pretty good and what I'm going to use going forward.
If you want DIP you can do what I have done which is to use QFP44 to DIP breakout boards, the only annoying part is that the Adafruit breakouts are something like 700mil wide so you need to keep that in mind. Still good for breadboarding though.

[Alarm Siren]

BigDumbDinosaur wrote:

The '51 isn't really good for new designs, bug or not.

I know, but it does at least have the advantage of being easily breadboarded.

BigDumbDinosaur wrote:

Unfortunately, that is the way the industry is headed. The cost to stuff a board with SMT devices is a fraction of what it is with through-hole parts, and of course, less board real estate is required for the same functionality, reducing the per piece bare board cost. These items, as well as others, dictate where the electronics industry is going, and such changes are as inevitable and unavoidable as death and taxes.

PLCC packages can be socketed, which sort of makes them through-hole parts—the NXP DUARTs I use are PLCC44. The sockets have a 100 × 100 mil pin grid, which means they can be mounted on standard perf board. If you are wire-wrapping you will pay a premium for compatible PLCC sockets.

Yea, I know, I'm not phased in general by surface mount parts, except when they have almost microscopic pins - like the LQFP48 packages all the modern UARTs seem to come in.

BigDumbDinosaur wrote:

The 16C550 is an okay UART but in my opinion, has a somewhat obstreperous programming model. It was for that reason, as well as the desire to have two TIA-232 channels, that I instead used an NXP DUART in POC V1.

I have a look at the datasheet for the NXP and I found it very confusing....

[BigDumbDinosaur]

Alarm Siren wrote:

I have a look at the datasheet for the NXP and I found it very confusing....

You're not the only one. Whomever is in charge of writing data sheets at NXP probably isn't a native English speaker and may not even have a technical education.

The NXP UART that I usually suggest is the 28L92, which is dual channel with 16-deep FIFOs on both RxD and TxD. You can get it in PLCC or QFP packages—I use the PLCC package. A MAX238 can be used to interface both channels to the outside world.

Through a combination of reading the data sheet and experimenting I've got the 28L92 hardware figured out fairly well. I run the DUART in Intel mode, as that mode is more compatible with the 65C816 than Motorola mode. The hardware interface is uncomplicated, requiring a little bit of glue logic (a couple of NAND gates) to generate qualified /RD and /WD signals. There's the usual chip select and an open drain IRQ output.

The driver is actually fairly simple and as I have it, makes full use of the FIFOs to reduce the volume of IRQs during CBAT (Continuous, Bi-directional, Asynchronous Transmission). All NXP UARTs are highly configurable, so a fair amount of setup data is usually required to achieve desired operation. That's best done with a data table to keep things straight and to load the registers in the correct order.

In my POC units, I use the 28L92's counter/timer in counter mode as a jiffy IRQ source for system timekeeping, generating 100 IRQs per second. As the 'L92 uses a separate 3.6864 MHz clock source (called the X1 clock) for baud rate generation and internal sequencing, timekeeping is not influenced by Ø2 as it is with the 65C22, which is convenient. Timekeeping accuracy is as good as the stability of the oscillator driving X1—my POC V1.1 machine drifts less than a second per month, averaged over a three month period

[BigDumbDinosaur]

GARTHWILSON wrote:

If you have SPI, you can use the MAX3100 which is available in a 14-pin DIP which is easy to work with and takes very little board space. If you want line drivers and receivers integrated, you can use the MAX3110 which comes in a 20-pin narrow DIP IIRC.

I'm guessing many of the 6502 systems that are using the 65C51 don't have SPI, so they are limited to parallel interface UARTs (which in many cases, are much more feature-rich than the MAX3100). I also wonder what sort of throughput the SPI approach would produce. For example, to transmit a datum, it must be serialized to go down the SPI wire to the MAX3100. Then the 3100 must "re-serialize" the datum to the TIA-232 format. I suspect all that monkey motion will have some effect on performance.

[BigDumbDinosaur]

LIV2 wrote:

The SC28L92 is pretty good and what I'm going to use going forward.
If you want DIP you can do what I have done which is to use QFP44 to DIP breakout boards, the only annoying part is that the Adafruit breakouts are something like 700mil wide so you need to keep that in mind. Still good for breadboarding though.

I started a separate topic on replacing the 65C51 with the 28L9x.

[Chromatix]

BigDumbDinosaur wrote:

GARTHWILSON wrote:

If you have SPI, you can use the MAX3100 which is available in a 14-pin DIP which is easy to work with and takes very little board space. If you want line drivers and receivers integrated, you can use the MAX3110 which comes in a 20-pin narrow DIP IIRC.

I'm guessing many of the 6502 systems that are using the 65C51 don't have SPI, so they are limited to parallel interface UARTs (which in many cases, are much more feature-rich than the MAX3100). I also wonder what sort of throughput the SPI approach would produce. For example, to transmit a datum, it must be serialized to go down the SPI wire to the MAX3100. Then the 3100 must "re-serialize" the datum to the TIA-232 format. I suspect all that monkey motion will have some effect on performance.

With apologies for resurrecting this thread, I had a quick look at the MAX3100 datasheet to shed light on this question.

First off, the MAX3100 can interface to a 4MHz SPI bus, and requires a 16-bit transmission each way on that bus per byte on the serial line. Note however that an RX byte is returned during a TX transaction if one is available, so that's one byte each way per 32 bits on SPI. It's therefore easy to see that you can keep up with a 230Kbps link as long as your SPI bus is at least 1MHz. (Even a little less can be tolerated, due to serial line framing overhead.)

The MAX3100 has reasonably generous RX and TX FIFOs, 8 bytes each (including optional parity bits, which are not calculated by the chip but left for the controlling CPU to deal with). It generates an IRQ as soon as the first byte arrives, and as soon as there is any space in the TX buffer, if the corresponding masks are enabled. Thus data can continue to flow on the line, even if there's a slight delay in the ISR getting around to servicing it.

So the only performance detriment is the 8-32 microsecond latency of getting 32 bits over SPI. This is negligible in most applications.

I have ignored any consideration of the overhead of interfacing with SPI itself, assuming that you have a parallel interface to a full-speed driver. It's also possible to bit-bang SPI, but in that case the throughput may be lower (depending on how fast you can bit-bang).

[Dr Jefyll]

No need to apologize. Resurrecting a thread is perfectly alright.

I agree that a tiny increase in latency is the only unavoidable performance impact of choosing a UART featuring an SPI interface. Throughput can remain the same, whether the interface is SPI or parallel.

On the topic of bit-banging, this is a tradeoff that simplifies hardware at the cost of chewing up extra CPU cycles. But typical CPU clock rates far exceed typical asynch baud rates, and therefore it's often the case that even bitbanging doesn't compromise throughput. In this thread I share code that bitbangs at roughly 1/20 the CPU clock rate. IOW even a lowly 1 MHz 6502 can bitbang about 50,000 SPI bits per second. That's more than enough to accommodate one-way transmission at 19.2kbaud on the asynch connection -- or 38.4 kbaud if you use the UART's FIFO.

I did some playing around with an NXP SC16IS750, and here's the SPI timing for it. (Chromatix, you mentioned the MAX3100, which also looks like a nice chip -- and I suspect its SPI timing is similar. This suggests you may've underestimated its potential, although I'm happy to be corrected on that.)

This image from the 16IS750 datasheet shows a simple read and a simple write of any of the on-chip registers (which BTW are like those of the widely popular 16C450, thus facilitating re-use of existing code; just have SPI read/write subroutines replace parallel read/writes from/to the UART). Notice it takes 16 clocks to read or write a byte. That's because there's a one-byte prefix containing r/w, the register address, and 2 unused bits.

In this simple case 50% of your bandwidth is overhead (because it takes 16 clocks to transfer 8 bits). But a 1 MHz 6502 can, as noted, bitbang 50,000 SPI bits per second, and 25,000 of those bits will be useful data. Thus, 19.2 kbaud on the asynch connection won't be a problem.

Using the FIFOs increases program compexity somewhat, but (among other benefits) it all but eliminates the 50% overhead. That's because the entire FIFO contents (eg: 64 bytes) can be transfered using just a single prefix byte. SPI throughput basically doubles, and that's how I calculated 34.8 kbaud... for a 1 MHz 6502 using bitbanged SPI. Obviously a faster CPU can exceed this figure.

(BTW Sparkfun used to sell a 16IS750 breakout board; dunno if it's still available. And here is a much smaller breakout board of my own. )

[Chromatix]

I used the MAX3100 as an example because it was brought up in this thread. Its SPI format is always 16 bits write and 16 bits read, no matter what, and the first 8 bits of each are command/status overhead. I agree this isn't the most efficient method possible, but it looks straightforward enough to deal with in software.

The more precise calculation would be one 16-bit SPI transaction per 10-12 symbols required for an RS-232 byte, where a single transaction can handle TX and RX simultaneously. At 230Kbps, that requires 23K transactions per second with 10-symbol format (1 start, 8 data, no parity, 1 stop), which in turn requires 368KHz on the SPI bus. I would round up to 400 or 500 kHz just for the sake of round numbers, and you could also run your SPI bus faster to support more active peripherals at once. Obviously you can get away with lower SPI rates if you accept lower line throughput.

EDIT: of course *now* I realise that SPI, unlike I2C, has independent send and receive data wires (on a common clock). So it's only 16 SPI cycles per transaction, not 32. Fixed the above figures to match.

[unclouded]

If you don't mind the impurity of incorporating a modern CPU pretending to be a UART in your design then it ought to be possible to program an ATtiny2313 as a bus interfaced UART. It's quite a bit cheaper than the MAX3100, available in DIP and you could roll your own SPI format as required. The "USI" peripheral can provide hardware-assisted SPI and the USART is a hardware peripheral that oversamples each bit with majority voting. It works best with a baud-rate-friendly XTAL such as 18.432 MHz.

[cb3rob]

https://www.aliexpress.com/item/Freeshi ... 97408.html

still some 5000 harris chips left there (although only the 2mhz version, not the 4), also some other suppliers still have boxes full of those harris 65C51s with or without the 'alternate cts behaviour', pretty much all of them in the 2mhz edition. should suffice until WDC gets their act together. (why the hell they even make an 'n' version which besides the txre bug also has a broken/no parity generator/checker is beyond me how hard can it be to produce a 40 year old chip and do so without introducing any new bugs or cut things out.

some clear statements on when they will come up with some new production run that actually -fully works- would be practical

you can sit on failed production stock forever and wonder why nobody is buying it (other than maybe 1 or 2 to test and then go 'nah', never leading to the final order of 100s of thousands of units , or you can just do a recall and fix it. seems like all it takes is 1 single semi-good selling product to slurp up all of mousers stock in a second anyway but if it's broken it'll just stay in stock there for another 10 years. also there are plenty of applications where you DON'T want '16 byte fifo buffers'. such as midi. think we'll just buy up all that harris stock from china for now. and then when they run out get some fab to make new ones (not wdc, they can't even answer email within a week

[GARTHWILSON]

cb3rob wrote:

(why the hell they even make an 'n' version which besides the txre bug also has a broken/no parity generator/checker is beyond me

I've never heard of the parity problem until now. Even the data sheet has conflicting information—but that's normal for WDC. Who uses parity though. I certainly never have.

Quote:

how hard can it be to produce a 40-year-old chip and do so without introducing any new bugs or cut things out.

As for the transmit register empty status bug: It worked right in simulation before the chips were made in a newer, faster silicon process; but there was a problem in the simulation software (used also by other companies—it's not WDC proprietary software) that resulted in a race condition that caused the problem in actual hardware. According to Dunn & Bradstreet, it looks like WDC grosses about $2M a year; IOW, it's a very small company. It was a huge investment to get a run of chips made, and they lost big time on it. Their income is mostly from licensing IP, not selling parts, and apparently they don't feel it would pay to try again. I have no idea how much more it would cost than it would if they only needed to get another run made with existing masks. However, I imagine that as technology advances, it will get cheaper and cheaper, just as the cost of custom PC boards now is well within the reach of hobbyists, whereas 25 years ago it was prohibitive.