WDC 65C51 chips defective

[floobydust]

Older 6551 chips should be fine. I have an old Synertek that runs flawlessly at 6MHz. Also some Rockwell 6551 which really don't work beyond their rated speed... at least the ones I have don't. You can also find some newer CMOS 65C51 chips available in speeds up to 4MHz, but not necessary for the C64.

As for running at 38.4K baud, you might be able to push the 6551 with a double-speed clock (3.6864MHz), but would recommend a can oscillator instead of a crystal. I've pushed some newer CMOS versions and they work fine. Also, per the datasheet, you can run the 6551 at 115.2K baud, but if you're planning on using interrupt driven I/O (preferred) that be more difficult with a slower running 6502 (C64 runs a bit less than 1MHz).

You can also easily interface a NXP UART for more flexibility and such with one extra chip (74HC00 to generate qualified read and write signals plus an inverted reset signal). For a remote console, you might want to consider a FTDI UART-USB interface module, which can connect directly to the 6551 without any level conversion. This makes interfacing to any modern PC or Mac trivial and can use just about any decent terminal program via a USB port.

Just as long as you can find a prototype board for the C64 port, you can easily wire-wrap a working board in an evening.

edit: Garth replied while I was typing... but my post just shares my experience with some of the chips and such...

[hth313]

Thanks!

I checked the design again of the 6551 cartridge board mentioned and it uses a 3.6864MHz crystal for 38400. It seems that speed has been in use for several previous similar designs, which should indicate that many older 6551 will work at that speed.

I will open another thread later for additional advice on getting that board manufactured, if I decide to go that route. It is probably better to use something other C64/C128 users may have access to (as this seems like a somewhat common hardware for C64/C128). That way any monitor software I produce can be used by others too.

[floobydust]

Another thread makes good sense of course. As far as making up the PCBs, you might want to rethink exactly what to put on the board. Perhaps add an 8KB EEPROM which can hold your monitor code and be switchable between a couple ROM locations. Also add some additional I/O decoding for the 6551 so you can add some other hardware bits if desired.

Also, there are numerous machine language style monitors that exist for the C64.... depending on what your needs/requirements are, one of the existing ones might fit the bill for that, worth checking into. Have fun with the 6551... there's already lots of code implementations to run these... just pick your I/O address, buffer locations, etc. and you can easily integrate this into the C64 IRQ structure and Kernel routines.

[Alarm Siren]

The W65C21N datasheet has recently been updated to incorporate this bug as a "feature".

There is no longer any errata section; instead it simply says that Bit 4 of the Status Register is always 1. It does note in a footnote that this is different behaviour from previous 6551 chips. Additionally, the mode bits to enable transmitter empty interrupts and to enable parity are listed as "Do Not Use".

I don't think this is going to go away. Whilst definitely not ideal, I suppose at least the datasheet is no longer misleading as to the capabilities of the chip.

[BigDumbDinosaur]

Alarm Siren wrote:

I don't think this is going to go away.

That's likely the case. There would be no economic incentive for WDC to fix the part and produce new ones, given how old the design is.

Quote:

Whilst definitely not ideal, I suppose at least the datasheet is no longer misleading as to the capabilities of the chip.

There are many more UARTs that are much better than the 65C51 and are relatively easy to adapt to a 6502 machine. I see this as a non-issue.

[Alarm Siren]

Quote:

I see this as a non-issue.

Unless you're looking to use this chip as a replacement for a 6551 in an existing machine.

[Chromatix]

Actually, it's a pretty important feature for a UART, to be able to indicate when its transmit buffer can accept more data without corrupting previously accepted data. Without it, the only way to transmit successfully is to manually insert a calculated time delay between byte submissions. Even that doesn't account for any flow control imposed by the receiver. Hence I consider the WDC 6551 effectively unusable.

[GARTHWILSON]

Chromatix wrote:

Actually, it's a pretty important feature for a UART, to be able to indicate when its transmit buffer can accept more data without corrupting previously accepted data. Without it, the only way to transmit successfully is to manually insert a calculated time delay between byte submissions. Even that doesn't account for any flow control imposed by the receiver. Hence I consider the WDC 6551 effectively unusable.

Again— Use a free timer in a VIA, and start it when you store a byte to the transmit data register, either to check for completed time by polling, or use it to generate an interrupt, so the processor can do something else useful while waiting for the byte to go out. No need for a time-wasting delay loop.

You can short CTS\ to DSR\ to check (in the 51's status register) for CTS\ getting negated immediately after storing a byte in the transmit data register to know if it's going to go out or not. If it won't, keep polling periodically until it's no longer negated, then start your VIA timer. Many UARTs don't even have a DSR\ input anymore, so you might not be giving up anything to change its function. If you really do need DSR\ for an actual modem, you can use a spare VIA input bit for CTS\.

None of this is ideal of course; but these are ways to keep the W65C51 usable.

Edit, 2/8/19: I think GaBuZoMeu has the best solution yet: Use the 51's pin 5 (if in DIP), the x16 clock, as an output to drive a VIA's PB6 for its T2 to count pulses and generate an interrupt. The T2 latch value does not need to change with Φ2 rate nor with baud rate. viewtopic.php?f=1&t=5482&p=66433#p66433

[Chromatix]

GARTHWILSON wrote:

Chromatix wrote:

Actually, it's a pretty important feature for a UART, to be able to indicate when its transmit buffer can accept more data without corrupting previously accepted data. Without it, the only way to transmit successfully is to manually insert a calculated time delay between byte submissions. Even that doesn't account for any flow control imposed by the receiver. Hence I consider the WDC 6551 effectively unusable.

Again— Use a free timer in a VIA, and start it when you store a byte to the transmit data register, either to check for completed time by polling, or use it to generate an interrupt, so the processor can do something else useful while waiting for the byte to go out. No need for a time-wasting delay loop.

I included that (implicitly) in the range of possibilities. But it's still quite a significant increase in software complexity, compared to what a directly attached UART *should* require.

[floobydust]

It is most unfortunate that their (WDC's) latest run of W65C51 chips are defective... and it should be fairly obvious that there are no plans to rectify the situation. WDC has updated their datasheet a few times since this discovery. In the datasheet from 24th October 2014, they noted the problem in the errata section and also had this on page 7 via the "*" to the TDRE bit:

Note:
The W65C51N has an operation issue concerning TDRE. This bit is not being reset after loading the Transmitter Data Register. Polling the TDRE bit of the status register will never show the TDR as Empty. Due to this issue, the W65C51N is not suggested as a direct replacement for older 6551 devices if the firmware uses this bit. It is recommended to using IRQ handling or software timeout for transmission as a workaround for this issue.

They also documented it wrong... as the the bit always shows the transmit register as empty. So.... after 4+ years, they opted to declare the defect as a feature.... so be it. I agree with BDD on this one... just move on to something else. Adding complexity and more hardware to work around it just doesn't make any sense.

[BillO]

WDC have not handled this well. Back in 2013 - 2014 (not 100% sure)* I got some of their 65C51s and had trouble using them. I called them, but they were of no help at all. It was like they didn't know what was wrong.

*(Edit - actually it was in 2012 and the chips have a 2010 date code on them.)

If you need or would just like to use a 65C51 there are no shortage of them available. I have had great success at running them well beyond their rated speed. As fast as 20MHz in the case of the Intersil CDP65C51. Just keep the select propagation delay to an absolute minimum. 7ns in the case of the 20MHz use and 24ns in the case of 16MHz use.

[floobydust]

BillO wrote:

WDC have not handled this well. Back in 2013 - 2014 (not 100% sure)* I got some of their 65C51s and had trouble using them. I called them, but they were of no help at all. It was like they didn't know what was wrong.

*(Edit - actually it was in 2012 and the chips have a 2010 date code on them.)

If you need or would just like to use a 65C51 there are no shortage of them available. I have had great success at running them well beyond their rated speed. As fast as 20MHz in the case of the Intersil CDP65C51. Just keep the select propagation delay to an absolute minimum. 7ns in the case of the 20MHz use and 24ns in the case of 16MHz use.

Well, I picked up one Intersil 65C51 about 4 years ago... 4MHz rated speed. I found it to be somewhat buggy, i.e., some corrupted transmit problems and wouldn't run beyond 4MHz in any case. I do have one WDC W65C51 that does work properly... but needs a can oscillator to function... I've had it running at 12MHz without issues so far.... but that's the only one. I received the chip directly from the folks at WDC before the latest versions were released.

I'm somewhat amazed that you them running at such high speeds... impressive.

[BillO]

floobydust wrote:

I'm somewhat amazed that you them running at such high speeds... impressive.

No more so than I. I can assure it's nothing I did to make this happen. I expected I might be able to push the odd 2MHz device to 4MHz, but I kept pumping up the speed and they kept working. I am using them completely asynchronously too. No hardware or software flow control, no interrupts. Just polling the status registers for empty transmit or full receive buffers.

Not that it probably matters, but these are the CDP65C51A series with the corrected CTS response.