WDC 65C51 chips defective

[GaBuZoMeu]

WDC cannot use the masks without some modifications. They need a solution to clear the race condition, so something is to change.

But even if this could be achieved at moderate costs there is at least another serious flaw in the design: the CTS behaviour that truncates the transmission - thats a no go.

Assuming they could solve both issues - producing the smallest batch will probably take more than $50K at least. This may then produce 10K or so parts. Then testing and packaging and testing again. I assume they need to sell these parts for $15 or more for a barely profit.

And how many people are willing to pay that much?

[Alarm Siren]

A fair point, but there really is not point in them continuing to sell an obviously defective part. If they don't want to invest in a new batch then fine, its not like there aren't plenty of other options out there, but the current situation just makes them look bad.

[GaBuZoMeu]

Alarm Siren wrote:

A fair point, but there really is not point in them continuing to sell an obviously defective part. If they don't want to invest in a new batch then fine, its not like there aren't plenty of other options out there, but the current situation just makes them look bad.

That's 100% true. At least they updated the datasheet with a note on page 34:

W65C51N6TXG-14 Errata Sheet for Silicon Lot Code: A6A749.1
The information below describes the current known function discrepancy current
W65C51N6T (Lot Code A6A749.1) devices found by WDC. Please contact WDC with
any other errors found.

Transmitter Parity
The transmitter of this part functions differently than previous 6551/65C51 devices. For
all Parity Mode Control (PMC) settings (Bits 7, 6 of the Command Register), the
transmitter will transmit a MARK (1) for Parity (When enabled with Bit 5 of the
Command Register set to “1”). Previous versions would transmit Even, Odd, Mark or
Space parity depending on the PMC bits.

Baud Rate Generator Feedback Resistor
The W65C51N needs to have a 1Mohm resistor between XTLI and XTLO (see Figure
20A). This was not needed on the W65C51S and some older chips.

Transmitter Data Register Empty
The W65C51N will not properly set Bit 4 of the Status Register to indicate the
Transmitter Data Register is empty. Determining when to send the next byte would
need to be done by using the transmit interrupt or having a software delay loop based
on the baud rate used.


Most likely this helps them to stay clear from legal issues.

I was lucky to verify this forum before buying some CMOS ones, as I already possess two NMOS ones having this "feature" to truncate a character in transmission if CTS toggles - this is completely silly. Together with the DCD behaviour this renders the chip as useless. The "new" errors (TDRE and Parity) are like a cream topping on a pile of debris

[cb3rob]

the CTS behaviour that truncates the byte and causes a frame error at the receiver is the -normal- 6551 behavior of all 6551's the harris cpc65c51 has codes A E <speed in mhz> whereas the 'a' indicates 'alternate cts behaviour' (read: 'fixed' cts behavior where it continues to transmit the current byte, the ones without 'A' also CPC65C51E2 or 4 do the exact same thing ALL other 6551's do which is to cut off the current byte and thereby cause frame errors.

https://www.aliexpress.com/item/The-ori ... 609aMd5C86 <-- without 'A' CTS 'fix'
https://www.aliexpress.com/item/Freeshi ... 4c4dtrIFav <-- with 'A' cts fix both 2 mhz.
they were made up to 4mhz. can't find any suppliers with large stocks of that version.

also there won't be any 'legal' issues in copying a 40 year old chip. even lego lost those cases and they definately put some more work into that than any 'motorola' or 'harris' or whatever either of those are called now would invest in 'protecting' their 40+ year old design they no longer intend to sell anyway. they're not gonna risk -losing- a case over 'work of art' vs 'functional requirement' and with that put their entire current portfolio at risk over some chip they haven't actually sold in years. simple as that. lego took it to court against some chinese guys, and lost hard. 'chips are a functional part of computers that are required to be designed like so and so in order to replace another chip in the same slot and fulfill the same function and therefore are not a protectable 'work of art'. also all patents expired 20 years ago. bye now. bam. case closed.

[cb3rob]

also commodore made the 6551 as well. they can always just buy the rights for next to nothing from whomever currently owns the remaining assets (icomp seems to have licensed the name recently) they already -have- the design anyway lol. it's not like the sid or 6526 where one would have to 'guess' and reverse engineer. they already know what goes into them.

[Dr Jefyll]

Thanks for posting this, GaBuZoMeu.

Quote:

[...] Determining when to send the next byte would need to be done by using the transmit interrupt or having a software delay loop

The transmitter-empty interrupt works properly? Somehow I missed that detail until now. So, maybe a software delay loop isn't the only workaround. The ISR could infer transmitter-empty status even though the Status Register fails to reveal that info as it should. Inferring status would be a bit tricky, but it's good to have options, and in some situations it'd be worth considering.

-- Jeff

[floobydust]

Well, having been the one that figured out that problem, even WDC has not correctly documented it. In short, the transmit empty bit is stuck on, so if you enable transmit interrupt, it will endlessly generate interrupts... in which case, the ISR will continue to write to the transmit register. The end result is simple, unless the current byte in the transmit register has been shifted out, a write will cancel the existing character transmission and start with the new one. The result, garbage output. Also note that polled I/O mode is also useless, as the same transmit register bit is tested to see if the chip is ready to accept another byte... being stuck on, it always shows as being ready to accept another byte, so the end result is the same.

In short, this is not something they will fix, costs to fix the mask problem and make a new run of chips versus what they might be able to sell, is a no brainer... it's just a financial loss for a very small customer base that might want to buy them. The only logical recommendation to anyone wanting UART support for any 65XX project is to use something else, unless they prefer to use a software band-aid to work around the problem. It's a shame... as if the chips worked, our little community here would have a simple and easy to implement serial port for projects.

[BigDumbDinosaur]

Dr Jefyll wrote:

Thanks for posting this, GaBuZoMeu.

Quote:

[...] Determining when to send the next byte would need to be done by using the transmit interrupt or having a software delay loop

The transmitter-empty interrupt works properly?

That's a documentation error, which of course we are accustomed to seeing in WDC's data sheets.

[Alarm Siren]

I wonder how many of this batch are actually left in the warehouses... Mouser shows 247 of DIP and 359 of PLCC. Are there likely to be more in a warehouse somewhere? If there's 100k of them somewhere, probably not much one can do, but if its only that 600 someone with deep pockets, or a community effort, could just buy 'em all up (and most likely chuck 'em), at which point WDC would have recouped costs and need to make a new - fixed - batch.

[BigEd]

I wouldn't think WDC would spin the design, even if they sold all the bad ones. If I'm right, that wouldn't be a good use of money!

[GaBuZoMeu]

Thanks Jeff but I believe KM and the people are right treating this as another glitch in WDCs documentation.

Having none (only NMOS) I cannot verify the actual behavior.


Regards
Arne

[BigDumbDinosaur]

BigEd wrote:

I wouldn't think WDC would spin the design, even if they sold all the bad ones. If I'm right, that wouldn't be a good use of money!

I'm with Ed on this one. There's no economic incentive for WDC to invest in fixing whatever it is that ails the 65C51. Far better UARTs are available from other sources.

[hth313]

I am looking to add a 6551 to a Commodore 128 (or C64) to get a good speed serial port. I am hoping to get 38400, with the idea of making a monitor for remote debugging.

In my small electronics stash I found two 6551 chips (about 30 years old), one is a Synertek, the other I do not know. This problem seems to rule out WDC65C51. Will the old 6551 work better? The data sheets I have suggest they will go up to 19200, so I suppose I might have to settle for that then.

I found a board for the C64/C128, but it is out of stock. The Gerber files are available so I consider if I could take the plunge and have it manufactured. I am totally new to doing things like that, so it all adds up and feels a bit overwhelming to me...

Reference:
https://gglabs.us/node/691

[Chromatix]

Older 6551s should work as well as they ever did, and won't have the bug in the new WDC version.

[GARTHWILSON]

Welcome, hth313. I believe even the original ones would do at least 125kbps using the 16x external clock. I have used 65c51's at 31.25kbps for MIDI this way. You might be able to use an external 3.6864MHz oscillator connected to the XTAL1 pin to get 38kbps, but I have not tried it.