I've read many time that the 65C51 has a hardware flaw and that a replacement was sought out. What are you guys using in your SBC's?

I'm looking for something "simple" that could interface with the 65C02 easily, have 1-2 ports (don't need more than 2), and not super complicated to program.

Honestly, I don't know that I would need more than 1 UART port.

Suggestions appreciated!

_________________
Cat; the other white meat.

I'm using an NXP 28L92, which is a dual-channel UART.
It is something of a pain to program if you go off just the datasheet. There's also an irritating little behaviour of the 65c02 regarding indexed writes that the 816 can get around with its VDA output. That initially stopped me using BDDs initialisation routine. I know how I can get around it now (set the base address right before a page crossing and index over it), but it still exists.

One reason one might need/want more than one UART port if you're intending to use a display and keyboard that each talk to half a UART channel, and still want to have an uncommitted serial port, say for data transfer with a PC.
If you're happy tying yourself to a modern pc as a terminal emulator, then yeah, I can see why you might not be interested in a second channel, but to me, making an sbc that requires a modern PC to be usable defeats most of the point to the sbc existing in the first place.

There is always the 28L91 if you want a single-channel UART. Mind you, they are both PLCC44s, so there's not a huge benefit to it, in my opinion.

I use the NXP 28L92 in my POC units. It's a dual channel UART (DUART), with 16-deep FIFOs, full hardware flow control and a precision timer with sub-microsecond resolution.


Any non-65xx peripheral device is going to need some "help" in being attached to the 65xx bus. The good news is that it is not at all complicated.

As for programming, you will need to get comfortable with using IRQs if you want to get best performance. Again, it's not complicated, but does require some effort.


Well, the good news is if you use the 28L92 you get a second channel without using any more PCB space than for one channel.

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

Thanks for the suggestions!

Yeah, I will probably use 2 channels just because it's there. But my SBC would be targeted to be standalone. The UART would be for transferring data.

_________________
Cat; the other white meat.

@BDD,

I've reading through your user interface guide. It is very well written! It really makes me want to order NXP 28L92 and get busy using the thing!

_________________
Cat; the other white meat.

Glad it helped!

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

I'm using the 28L92 as well, 16 deep FIFOs and hardware flow control are welcome additions!

It does look like an attractive option, if you can get past the massive, scary-looking datasheet and the surprisingly high pin count. The fact that it can sit directly on the 6502 bus and might not even need any wait-states at relatively high clock speeds is particularly nice from the software standpoint.

Another reasonable option is the MAX3100 series, as long as you don't mind having to drive it through an SPI interface. It doesn't have automatic hardware flow control, but it does have a couple of GPIO pins that the datasheet suggests to be used for RTS/CTS.

The "surprisingly high pin count" is due in part to it being a dual channel UART with full flow control on both channels. Plus there are plenty of GP I/O pins to facilitate all sorts of applications, such as an RS-422/RS-485 synchronous interface (the AppleTalk network uses RS-422). The 28L92 is in a PLCC44 package, so it's not a problem to do an efficient PCB layout with it.

As for the DUART's performance, my POC V1.1 unit, which uses a 28L92 to drive the console and an external interface, has no wait-stating and will run in a stable fashion at 15 MHz without the SCSI host adapter installed. I'm not even close to crowding the 28L92's timing.


If you're going to go to the trouble required to interface an SPI device to a 65C02 just to implement TIA-232, you might as well get your money's worth and use a UART with much more capability. High performance I/O is like money: you can always use more.

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

With a bazillion SPI chips on the market today, it makes sense to have at least one SPI port available (and each one can address lots of devices). Daryl still has some of his 65SPI chips to sell, and when he's out, I have a half-dozen too, if someone wants them before I get a chance to use them. It's kind of power hungry, being in a 5V CPLD that got discontinued (which is why I said "still," as they'll run out) but I'm hoping he (or someone) will re-implement his design in another CPLD, even it it's at 3.3V. SD card has an SPI mode, which should be motivation enough to add SPI. Then there's also our 65SIB (6502.org Serial Interface Bus) which further extends the usefulness of SPI, and our SPI-10 hobbyist-friendly connection scheme for small SPI modules.

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

In particular, many of the small, simple displays that don't need a UART (and don't behave like one) use SPI instead. Want to experiment with eInk or Sharp's MemoryLCD? SPI.

Well, as I found the bug in the recently released W65C51, I went with a different UART on my last project, which I finally completed end of last year. I opted for the older NXP SCC2691, a single channel UART. I've posted full source code for the SCC2691 which features a BIOS/Monitor that supports full duplex interrupt driven receive/transmit plus timer for a jiffy clock (10ms) and received break as well. The code can be easily expanded to support one of the dual NXP UARTs as mentioned above.

So far, I've had two of my C02 Pocket SBCs running for over 200 days without a glitch. The monitor also supports Xmodem download via the console port with automagic S19 record support (based on the S19 format from WDC tools linker). If you plan on writing your own support code, you may want to scan the comments in my BIOS code at a minimum as there are some caveats to initializing the chip with the 65C02 instructions. My next board will use one of the NXP dual UARTS and mostly PLCC chips.

Hope this is useful to you: viewtopic.php?f=4&t=5005

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

Actually, it's been some five years since you ran into that bug. Wasn't it also you who discovered a problem with <addr>,X addressing with the 65C02 that would cause the MPU to accidentally "touch" MR in the 2691, requiring an offset-by-one approach to force a page crossing on each access?

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

Geez... you're right, 5 years have passed since that little discovery... who knew? While I did stumble into the addressing bug with the 65C02, I think it was Dr. Jefyll that figured out that crossing a page boundary gets around it. Ultimately, I opted to code the MR separately in my init routines, but noted the issue in my comments for the BIOS.

It was you that recommended switching to the NXP UARTs, which has been a good move.

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