except that when I do it in WW, I solder the crystal and discretes directly to the socket pins under the board so they don't take any board space! But yes, I would generally recommend the half-can oscillators too.

_________________
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?

Well, more progress:

First, using a Crystal, cap (and now resistor) still uses less current than adding a can oscillator, but yes... a can is always a better choice.

Next, I might have found an anomaly in the WDC chip. As I couldn't find anything wrong with the HW design or the SW side of it, I started thinking that the chip transmit function might be having issues, so I inserted a delay routine into the main character output routine, so after writing to the Data register, no access to the 6551 would occur while the character was being transmitted.... and it worked!

So, additional diagnostics seem to indicate that if you have Receive IRQ enabled and Transmit in polled mode, looping on reading the Status register results in the character transmission getting interrupted. I've been swapping a bit of email with WDC today on this, they sent me code they used for polled transmit which works for them, but no IRQ is enabled for Rcv or Xmt. Using their code also did not work for sending a character (Rcv still IRQ enabled). I'm further along, but not with an elegant much less proper workaround. Guess the next step is to implement full duplex interrupt driven (and buffered) receive/transmit and see if that flies on the chip. Very strange operation.... all of my older 6551 chips are fine with the code.

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

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

Completely agree on IRQ driven full duplex operation. I have a full function 6551 BIOS I wrote back in the late 80's. It's full-duplex with a pair of 128-byte circular buffers and both Rcv and Xmit are IRQ-driven. It supports a 6551 port implemented on an expansion board for a Vic-20. I'm going to drag the Vic out, get it working again, then swap to the WDC chip (adding the resistor and cap) for testing. Should be quicker to verify/debug chip operation this way. Once completed, I can rewrite the I/O routines and interrupt handler for the two-board setup.

It is an odd quirk between older NMOS 6551 chips and the latest WDC CMOS version. On the plus side, running the two board set at 8MHz, current draw is ~50ma for everything which includes a MAX238 driver/receiver, a 65C22, and a pair of power indicator LEDs @ 2ma. each.

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

My Tip of the Day #14 is about that, making sure you find all the interrupt causes in the '51 before you exit the ISR.

_________________
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?

ARM7 LPC21xx UARTs were broken as well (as of 3 years ago anyway), losing characters under heavy load even when there was room in the buffers.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

First, Garth, thanks for the link... good info on running the 6551 under IRQ control. Enso, hmmm, problems elsewhere, who knew.

So, I found my old code and got it working on the Vic-20 last night. It's simple enough... follows the standard checking of bits in the status register during IRQ servicing. Having the code running on the Vic with a monitor is nice, can see stuff better. I've found that the WDC 65C51 receives data perfectly fine in all cases, IRQ servicing works without issue. Transmit is the problem... just not sure what the cause is.

Scenario: I send a string of data to the OutCharacter routine, which simply puts one at a time into the Xmit buffer and checks to see if the 6551 has Xmit IRQ enabled (flag check). If not, it enables Xmit IRQ (updates the flag) and exits. I can see the character string get placed into the circular buffer. I also see the buffer pointers get updated to reflect all bytes being sent. The only way this can occur is the 6551 chip generates an IRQ, the IRQ handler checks for the cause, finds the Xmit buffer empty bit on and sends another byte and updates the buffer pointers. Bottom line, all of the data is being sent to the 6551 via IRQ. With a standard 6551, the code works fine... all buffered characters are sent and displayed in a terminal program.

With the current WDC chip, everything happens as above, but no valid data appears on the TxD pin... either no characters or random garbage appears via the terminal program. Seems that accessing the chip while it is actively outputting a character resets the output and you lose the data on output. Adding a delay routine which prevents the chip from being accessed until the character is sent allows the transmit to complete. I've shared this with the WDC folks and they are working on their end as well. I also used their polled mode code sample and made a bootable ROM for my board. A simple modification to simply send an ASCII string, all via polled mode. No IRQ service routine exists and no IRQs enabled on the 6551 chip. Again, standard old 6551 chip send the string of data without issue and the WDC chip gets sent everything, but no outputted data.

My last test (as I can't come up with any more) is to put a logic analyzer on the chip and watch the chip access line vs the TxD line with a few test routines running. Does anyone else have any suggestions?

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

After much testing, and multiple captures with a logic analyzer, I've concluded that the Xmit bit in the status register is stuck on. This explains why both polled and IRQ handlers are endlessly pushing data to it, and why transmitter output is corrupted (as it's being over-written). I've also confirmed it using a Vic-20 and an expansion board... simple code that does chip setup and multiple writes capturing and saving the status register each time. With a standard 6551 chip, the Xmit flag clears after writing the second byte. With the WDC chip, the Xmit flag never clears, even after 4 successive writes. I've also sent all of the details to the WDC folks to see if they can confirm the same.

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

I'm glad you're looking into this in such detail. I would sure like to see the matter cleared up.

_________________
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?

Sounds like a definite case of chip errata. Good work.

Yet another reason to use something other than the 6551. It just seems that virtually every piece of 65xx I/O silicon ever produced has problems. One of several reasons why I went with the 26C92 in my POC unit.

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

I never had any trouble with Rockwell or CMD (formerly GTE) 65c51's, but I never tried a WDC one or the old NMOS ones either although I have an ap. note about the NMOS '51 bugs.

_________________
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?

I like the 26C92 (Dual UART) as well, one of my favorite features are the 8 byte TX and RX buffers.

Yea... and it's confirmed.... Xmit bit, ugh. So, will hopefully get some older samples to test. My best old chip is a Synertek SY6551A which runs rock solid at 6MHz. The WDC version was cruising fine at 8MHz but with a band-aid on the Xmit routine. So I'm hoping it gets resolved sooner than later. I still like the 6551... have good code to drive it which works well and low CPU overhead. I guess I'll have to take a look at the other one....

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

Do you have an idea if this is a single bad chip, a bad batch, or a general problem?

Do you know if this affects the PLCC chips as well, or has your testing still been limited to the DIPs?