WDC 65C51 chips defective

[floobydust]

I have to agree, there's quite a bit of vacuum around this problem. The other thing I found out was they deleted the 1Meg internal resistor from the baud clock oscillator (it was present in earlier chips) so you need to add that also if you intend to use a crystal. This has also been added to the October datasheet errata on page 34. Do note that this is specifically for LOT code A6A749.1. The good news (there has to be something) is that the chip will easily run at 10MHz. I did get a few other older W65C51 chips from WDC some time ago... they all have their, uh, issues... but I have one of them working for full duplex interrupt-driven transmit/receive with a 10MHz CPU clock but need to drive the baud clock with a can oscillator (built-in baud clock won't run stable). I opted for a 3.6864MHz can and get 38.4K baud rate. I also had to add more power supply noise caps everywhere as the chip was generating a lot of noise on the supply which was also causing problems.

I posted an updated SyMon 5 version I've been working on here: viewtopic.php?f=2&t=3138

The BIOS at the end has a fully working interrupt-driven and buffered 6551 driver and also a 6522 driver that has dual timer interrupt support. You could modify (or bastardize) the timer and UART routines to get an interrupt driven transmit working with the bad chips... but there's no elegant solution based on the nature of the problem.

[cr1901]

Well, the VIA solution might be my best best. Honestly, I just need to get some code snippets working and try stuff out (even if that means breadboarding my design as a stopgap). I've ran a UART successfully off a breadboard before.

[BigDumbDinosaur]

Just my curmudgeonly viewpoint, but you guys are beating a dead horse with the 65C51. Why bother when there are much better UARTs available?

[floobydust]

Yea, I've been waiting for that. I do have some 26C91 NXP UARTs, just haven't had the time to get one wired up on a board yet, but it's on my list of things to do. I spent some time last year writing a reasonably small and flexible BIOS with the functioning boards I have... 6551/6522 based. It was based on code I had written for a 6551 added to my old Vic-20 that goes back to the 80's, so I used it as a base and extended it. With that done, the goal is to start adding some new I/O devices, among them the NXP UART. Timing is the issue, too many other projects plus regular work, so it's been on the back burner for quite a while now. Hopefully soon.... as I also started on a new single board system using mostly PLCC chips and a single CPLD as a glue chip. Too many (fun) projects, too little (free) time. But I appreciate the gentle nudge

[cr1901]

BigDumbDinosaur wrote:

Just my curmudgeonly viewpoint, but you guys are beating a dead horse with the 65C51. Why bother when there are much better UARTs available?

cr1901 wrote:

26C92 requires too much discrete logic to interface properly, and 6850 can't handle my intended clock speeds period (10 MHz).

Well really, b/c interfacing the 26C92 to the 65xx bus presumably requires a bit of glue logic to convert 65xx bus signals to whatever the 26C92 expects, that will inevitably add prop. delay. Since I want to use through-hole components and discrete glue logic, I really can't expect either of them to work in my design. Consider not using a CPLD or GAL for interface logic as a hard requirement for how I want to build this. Additionally, both of them appear to be EOL. 6551, for all its flaws, is still made and understands the 65xx bus.

[GARTHWILSON]

I scanned the previous pages of the topic and I didn't catch anything saying you intend to use the UART with an '816. IIRC, the 26C9x cannot handle being accessed in consecutive cycles, which would mean you can't use R/M/W instructions on a 6502 accessing the UART, right? You could still do LDA, ORA/AND, STA though, which is still faster than bit-banging the SPI MAX3100, although I definitely like that 14-pin Maxim UART.

[cr1901]

GARTHWILSON wrote:

I scanned the previous pages of the topic and I didn't catch anything saying you intend to use the UART with an '816.

If I didn't not say anything, that was an oversight. R1, which uses an '816 is intended to sit on an ISA card. The UART is the window into the computer's world.

GARTHWILSON wrote:

IIRC, the 26C9x cannot handle being accessed in consecutive cycles, which would mean you can't use R/M/W instructions on a 6502 accessing the UART, right? You could still do LDA, ORA/AND, STA though, which is still faster than bit-banging the SPI MAX3100, although I definitely like that 14-pin Maxim UART.

R/M/W isn't a dealbreaker. If I ever need to do an atomic access to a peripheral, I can live with using a mutex to denote a critical section. Or maybe I'll reverse my stance on SPI and use that. I'll take a look at the 26C9x timing diagram and see if it fits my needs. Additionally, the 26C9x also has GPIO, which is cool.

Since LDA/STA will only take one machine cycle to write data, the 26C9x would need to be able to respond to writes in a machine cycle as well. As another example, old MCS-85 chips require 4 clock cycles for a bus cycle, so without a frequency multiplier, one has no hope of interfacing, say an Intel DMA Controller to 65xx chips. This is my main concern- if writes/read require multiple clock cycles, then the chip can't be interfaced easily to the 65xx bus. Or am I misunderstanding something?

That said, alternative UARTs are still technically on topic, so maybe an example circuit/POC with an alternate UART might be a good addition to this topic.

[BigDumbDinosaur]

cr1901 wrote:

26C92 requires too much discrete logic to interface properly, and 6850 can't handle my intended clock speeds period (10 MHz).

Well really, b/c interfacing the 26C92 to the 65xx bus presumably requires a bit of glue logic to convert 65xx bus signals to whatever the 26C92 expects, that will inevitably add prop. delay.

The required glue logic is trivial. If you are using a 65C816 you will also have to qualify chip selects with VDA and VPA, which can be done with a single OR gate. Here is how I did it in POC V1.1:

Chip decoding

Read/write generation

Quote:

Since I want to use through-hole components and discrete glue logic...

Everything that you need in through-hole glue logic is available in 74AC, which is fast enough to do the job.

[Dr Jefyll]

cr1901 wrote:

This is my main concern- if writes/read require multiple clock cycles, then the chip can't be interfaced easily to the 65xx bus. Or am I misunderstanding something?

Hmm, could be. It's true that microprocessors such as Z80, 8080 etc use a fine-grained CPU clock running at a comparatively high frequency. Unlike 65xx, these chips require multiple CPU clock cycles to do a single bus cycle. However, the bus cycle is all that concerns you. The connection to an IO device (such as a UART) consists mainly of just a /RD and a /WR signal.

The second of BDD's attachments (above) shows how it only takes two gates to supply /RD and /WR on a 65xx system.

-- Jeff

[cr1901]

BDD... I stand corrected then. THANK YOU for that schematic.

Dr Jefyll wrote:

cr1901 wrote:

This is my main concern- if writes/read require multiple clock cycles, then the chip can't be interfaced easily to the 65xx bus. Or am I misunderstanding something?

Hmm, could be. It's true that microprocessors such as Z80, 8080 etc use a fine-grained CPU clock running at a comparatively high frequency. Unlike 65xx, these chips require multiple CPU clock cycles to do a single bus cycle. However, the bus cycle is all that concerns you. The connection to an IO device (such as a UART) consists mainly of just a /RD and a /WR signal.

The second of BDD's attachments (above) shows how it only takes two gates to supply /RD and /WR on a 65xx system.

-- Jeff

Some IO chips, like the 8237 DMA controller need a fine-grained clock cycle to perform an xfer (4 clock cycles). Since the 65xx surely won't keep a value on the bus for 4 clock cycles, the only solution I can think of is to force such I/O devices to wait until the correct number of clock cycles pass (de-assert RDY).

Incidentally, it turns out that while the ACIA requires a clock signal from the CPU, the 16550 does not.

[Dr Jefyll]

cr1901 wrote:

Since the 65xx surely won't keep a value on the bus for 4 clock cycles, the only solution I can think of is to force such I/O devices to wait until the correct number of clock cycles pass (de-assert RDY).

Interesting challenge. (And FWIW a DMA controller is more like a CPU than an I/O device, since its main job is to generate bus cycles -- not respond to them, as a simple I/O device like a UART does.) But as for adapting an 8237 for use with 65xx, the approach I'd consider first is to use an oscillator that's four times the desired 65xx bus frequency. Feed that high-frequency clock to the 8237 and to a divide-by-four circuit which in turn drives the 65xx CPU. I don't mean to make it sound trivial, because certainly there'd be complications -- but it's an alternative worth considering.

Quote:

Incidentally, it turns out that while the ACIA requires a clock signal from the CPU, the 16550 does not.

16550 and other non-65xx/68xx peripheral devices are usually obliged to dedicate a separate input pin for use as a time base. But 65xx/68xx peripherals save a pin by simply using Phase2 as the time base. Though part of the bus interface, Phase2 is a signal that's continuous & unvarying, regardless of the presence or absence of I/O activity. The same can't be said for /RD & /WR -- hence the extra input pin for a clock.

-- Jeff

[BigDumbDinosaur]

Dr Jefyll wrote:

16550 and other non-65xx/68xx peripheral devices are usually obliged to dedicate a separate input pin for use as a time base. But 65xx/68xx peripherals save a pin by simply using Phase2 as the time base. Though part of the bus interface, Phase2 is a signal that's continuous & unvarying, regardless of the presence or absence of I/O activity. The same can't be said for /RD & /WR -- hence the extra input pin for a clock.

There is an advantage to the peripheral device requiring a separate clock source, and that is it will run in a consistent fashion regardless of the Ø2 frequency. In the case of the NXP 26xx UARTs, the 3.6864 MHz X1 clock both drives the internal baud rate generator and produces a time base for the counter/timer (C/T). It is possible to use the C/T to generate a jiffy IRQ for general timekeeping purposes, or to run a preemptive scheduler of some sort.

Similarly, the 53CF94 SCSI controller I am using has a clock input that clocks the state machines in the device that sequence the SCSI bus. Unlike the 26xx, a range of clock frequencies may be used with the 53CF94, up to 40 MHz. The 'CF94 is told in software the clock range to expect.

In both cases, the devices operate asynchronously to the 65xx bus, which generally poses no hardware design problems as long as chip selects and read/write inputs are properly handled.

[Dr Jefyll]

BigDumbDinosaur wrote:

There is an advantage to the peripheral device requiring a separate clock source, and that is it will run in a consistent fashion regardless of the Ø2 frequency.

Yup -- also true; a classic tradeoff. Having a separate pin for the timebase is handy if you need a fixed CPU speed, say, but want to experiment with using a non-standard baud rate. Yet, in other cases it'd be preferable to devote that pin to another function, or eliminate it for reasons of cost and space.

AFAIK, chips intended for the market where /RD and /WR bus signals prevail always use a separate pin if a timebase is required. The bus signals can't be considered a timebase because they're not expected to be periodic. FWIW, the CPUs that don't generate periodic bus signals seem to be those using fine-grained input clocks -- that and the /RD and /WR signals seem to go together.

In the case of chips for the 65xx/68xx market (ie; with R/W and Phase2 bus signals), the Phase2 (aka E) bus signal is expected to be periodic, and the manufacturer has the freedom to include a separate timebase pin or not.

On 6522 you get to choose for yourself, at least in regard to timer T2. It can take its input signal from Phase2 or from the PB6 pin.

[GARTHWILSON]

Dr Jefyll wrote:

BigDumbDinosaur wrote:

There is an advantage to the peripheral device requiring a separate clock source, and that is it will run in a consistent fashion regardless of the Ø2 frequency.

Yup -- also true; a classic tradeoff. Having a separate pin for the timebase is handy if you need a fixed CPU speed

That's partly why I haven't varied the CPU clock input speed. A free-running T1 on the VIA would not keep a consistent speed. Otherwise you could have the length of each half cycle optimized for what's being addressed in that cycle, with the timing being continuously variable rather than go in increments of a given size.

Quote:

but want to experiment with using a non-standard baud rate.

On the '51, I've done that with the 16x baud clock input. I did the 31.25kbps for MIDI using a 500kHz VIA PB7 output from the free-running T1 toggling it. T1's speed was governed by phase 2 though.

Quote:

On 6522 you get to choose for yourself, at least in regard to timer T2. It can take its input signal from Phase2 or from the PB6 pin.

You can also connect PB7 (output, with a free-running T1 toggling it) to PB6 (input, to decrement T2) for longer periods.

[BigDumbDinosaur]

Dr Jefyll wrote:

On 6522 you get to choose for yourself, at least in regard to timer T2. It can take its input signal from Phase2 or from the PB6 pin.

The downside with that arrangement, of course, is that PB6 is no longer available for communicating with an external device. Compromises, compromises...