Has anyone from the UK found a good source of WDC W65C51A chips? They seem to be quite rare (especially going by some of the other forum posts I've found).
I need one to set up RS232 comms.

Many thanks

Depending the price and quantity you want to purchase. At the moment on ebay a british guy is selling DIP and PLCC versions.

Mouser have them: http://uk.mouser.com/new/westerndesignc ... e-adapter/

Don't forget our sticky topic "65xx parts sources" under "General Discussions." The Mouser UK link is there but I just added a line to make it easier to find. There's also Coltek, and our own BitWise (Andrew) who stocks a few WDC parts for UK users.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Awesome - thanks guys!

According to some other posts around here, the 65C51 has a hardware problem involving the TxD status register bit. There are other UART choices available that require only trivial adaptation to the 65xx buses.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Being the one that found that bug and verified with WDC, I can clearly state that all current sources of recent chips are known bad including Mouser, Jameco and the UK source listed. I bought 5 DIP chips and 1 PLCC from Mouser, 2 DIP chips from Jameco and 5 PLCC chips from the UK source. All are the same LOT number and all are bad chips. I can also safely say that no known 6551 driver code will work without a rewrite. This is based on the simple fact that any programmer would use the xmit bit in the status register to determine when the chip is ready for another byte.

I also sent WDC an email in the past couple weeks asking for an update (as they are planning to release their new SXB boards using a 65C51) and have not received any reply to date. It also became clear during my debugging of the problem that not only did WDC not know about this defect, they were never once looked at data coming out of the chip, so their internal testing was of no value. They also sent me their sample code which was polled mode only.

Unless WDC fixes the problem and has new chips made (in which case I expect a full set of replacements gratis), I can only recommend to source some NOS parts from other manufacturers. As much as I like the 65XX line of chips, the W65C51 debacle and lack of knowledge and concern from WDC has sorta cooled my jets on the matter. Good luck.

_________________
Regards, KM
https://github.com/floobydust

That sorta sucks for whoever...

Once again I walk away saying to myself: "If you want it done right, you have to do it yourself"....
Seems like, in the end, competition brings prices down on a certain product. Which: Lower prices mean lower quality talent hired. Nasty little circle

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Over the years, the 65xx I/O chip family has left a sour taste in my mouth. It seems that most of it has errata of once sort or another and the programmer ends up jumping through hoops trying to get working software . When I embarked on the design of POC I made the decision to use nothing from the 65xx I/O stable, especially the 65C51, which has a brain-dead programming model (plus a previously unknown bug, thanks to floobydust's diligence). This hardware has been around for some 35 years and still doesn't work right. Why bother when so many other choices are available?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

The problem with using NOS parts is the target system will constrained to a relatively slow clock rate. I don't understand why anyone would narrowly focus on such an ancient UART with documented bugs and limited performance.


I suspect your discovering this problem has probably caused a bit of an uproar in Mesa AZ, and that someone is reevaluating the chip design to figure out how to fix it. It could be that no news means they haven't yet figured it out.

Since the discrete part has the stuck TxD bit, it's a certainty that the problem is also present in the 65C134 and 65C256 microcontrollers. Needless to say, this is not good, since WDC has struggled for years to gain market share with these products.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Hi BDD,

I took your advice and used the SCC2691 on my SBBC. However now as this project has reached a stable state (I can boot PRODOS 2.0.3 yessss!! which supports dates up to the year 2039 hooray!) I can tell you one reason for me to still use an old-fashioned ancient UART. Throughout many projects I always used the 6551 and so I know this circuit and it's limits very well. But because I know it this good, it's also always the first IO device that works. So I often use the albeit slow serial link to debug the rest of the computers. Even during the setup of my SBBC I connected a 6551-2 (a NMOS device yes) with dupont wires to the socket prepared for the SCC2691 so I could quickly run my test monitor and check the hardware, especially during the setup and debugging of my new PS/2 interface and the VGA controller.

It is sort of a hen and egg problem if you use the SCC2691 for the first time on a new project. Now I can resolve it as I have a OS and an assembler running on my SBBC and can now start to program a driver and test it.

But I must say the documentation of the SCC2691 is very cryptic on some points and the programming model is as queer as the Z80 SIO. Especially the documentation of the support for baud-rates above 38400 is very hard to understand. And as it seems even the SCC2691 has a condition when it stops transmitting data (at least I found one errata mentioning this). So nothing is perfect.

Isn't that pretty much the case for any chip with which you have no hands-on experience? I jumped through similar hoops when I built my SCSI host adapter and started writing code for the 53C94 controller.


I agree that the documentation is somewhat cryptic—hardly uncommon, though. You should try reading the 53C94 docs if you want to see some truly cryptic prose. Think of filtering through the noise and gleaning the useful information as a mental challenge to be overcome.

As for the high baud rates, I tried to convince you to go with the 26C92, which supports 230.4Kbps in the standard baud rate tables...


I have only skimmed the 2691's data sheet, as I haven't used it in a project. Is this errata mentioned in the data sheet or elsewhere?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I wish I'd popped back and read the subsequent posts!
I've purchased 5 W65C51N6TPG-14 units (they'll be posted to me tomorrow). These are the NMOS compatible versions I think. Are these also having the issue described?
And I'm a bit surprised that WDC haven't commented yet. When were they advised? If it wasn't that long ago then they might still be testing.

BTW floobydust, can you advise what the work around to use these is programmatically?

The W65C51N is the version sold as a pluggable chip, with the PG suffix indicating that it is in a PDIP package and is RoHS compliant. The W65C51S is sold as dice only. In both cases, the devices are CMOS and expect CMOS input levels. I suspect the ones that are in transit to you will have the "stuck" TxD ready bit problem.

You are probably thinking of the W65C22N, which has current-limited outputs and an open-drain IRQ that makes it "NMOS compatible." The W65C22S has outputs that are not current-limited and features a totem-pole IRQ. The S variant is the recommended choice for new designs.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

BDD,

As always some good feedback/comments. However, WDC did send me some other chips to test.... none had the xmit bit stuck on, but all had other quirks which were mostly related to high noise levels and had limits on what I could manage with them. As a result, none of these could be used as direct replacements for existing NMOS chips as noted.

As for causing some grief in Mesa... well, not really my fault. I found a problem they didn't realize existed based on their (lack of) testing. However, based on the other chips they sent me, I wouldn't think that the 134 and 256 chips have the xmit bit problem... as it seems to be specific to the latest lot number. Also, WDC has not updated the datasheet with errata showing the xmit bit problem, nor have they (to my knowledge) alerted the current distributors of their chips of the problem. I can vouch that Mouser doesn't know based on earlier emails with them. This is a bit disappointing.... I can only hope that they are trying to resolve the problem as their new SXBs which are using the 65C51 will basically not work with any standard coding practice.

NOS chips will limit the CPU clock of course, but I guess it depends on how fast you're looking to run the CPU. I have a Synertek 6551 chip which runs flawlessly at 6MHz... and the SCC2691 per the datasheet will have an upper limit of 6MHz, but I'm hoping 8MHz or more will be possible.

Banedon,

As for a workaround, you are stuck with either providing a delay loop (which I posted in an earlier post) that's specific to the baud rate you're using to send the next byte to the chip, which wastes CPU cycles, or use an IRQ timed routine to throttle data writes to the chip.

I also am working on getting a SCC2691 chip setup, but due to real work and a ton of travel, I've just not had the time to finish up the initial hardware yet. And yes, the datasheet is a bit cryptic and vague, so it will likely take me some time to get it working once I have the initial hardware done.

Sorry for the delay in responding as I've been traveling for the past 2 weeks. Hope this information helps.

_________________
Regards, KM
https://github.com/floobydust