Hey all,

I came across this little chip on mouser.com today, just casually looking for an ACIA alternative, not that I'm terribly unhappy with it or anything, but I might've found something interesting - it's a dual UART in a "friendly" PDIP package.

Exar ST16C245 and Datasheet

Dual channel, 8-bit parallel data interface, 8 control registers. $9.16 for one (single quantity), not a mind-blowing price but, for two-in-one, it doesn't look bad. Has anyone tried it?

The 16450 was pretty much the standard UART in PCs for a long time. If this is simply a dual '450, then there is lots of resources like example code you can use.

But back then everyone knew that you should have a 16550 instead if you could, the 16450 only held one byte in its buffers and sometimes couldn't keep up if you were using a multitasking operating system.

If you broaden the search to, say, QFP packages (for which there are DIP adapters), I'm guessing you have a lot more options.

Ah, I see they also make a 16550 variant as well. QFP is no big deal. I didn't realize the 450 only had a single byte buffer - thanks a lot for the tip!

There is also the XR88C681, available in DIP40 and DIP28 (DIP28 is very hard to find). It has a 4 byte buffer. NXP/Philips made a nearly identical part, though I forget the number.

_________________
8 bit fun and games: https://www.aslak.net/

The XR88C681 is a slightly different version of the old Philips SCN68681. I don't recommend either part for use in new designs.

NXP makes a whole range of UARTs (see attached catalog), in single, dual, quad and octal channels. In dual UARTs (DUART), the choices that I recommend are the 26C92 and 28L92. The former has eight-deep FIFOs for both RxD and TxD, and the latter has 16-deep FIFOs for both RxD and TxD.

NXP's part numbers generally begin with 26, 28 or 68, which indicates the bus type that the device natively supports. 26 series parts are Intel x86 bus-compatible and 68 series parts are Motorola 68K bus compatible. 28 series parts can be configured (in hardware) to be compatible with either bus type. I have used both the 26C92 and 28L92 in POC V1.1, the latter being the one I'm currently running. Oddly enough, interfacing the 26 and 28 series to the 65C816 bus is easier than with the 68 series. The 68 series can be made to work with the 65C02 bus as long as the read/write signal is qualified by Ø2. Getting that series or the 28 series configured for the Motorola bus to work with the 65C816 is tricky.

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

The 68681 was originally a Motorola part, a peripheral in a big line of peripherals for the 68K. I assume the Philips clone of that part hasn't been made in a decade or more.

The XR88C681 appears to be a current part from Exar though. See this product page. I found only recently that they'd stopped making them in DIPs, but the PLCC44 is a current part, and the DIP version certainly worked well in my 8 bit.



Thanks for the catalogue; it makes very interesting reading. My latest (6809 based) micro uses a SC16C654. I chose to configure it in Motorola mode because it has single select and interrupt lines in that mode, vs external decoding in 16 mode. It adds a small complication to the R/W and CS signalling but it's no biggy. I must admit I chose that part mostly because it sat within my perhaps strange needs: 4 channels, easy to source through ebay, and not SMT. Yes the '654 in PLCC is no longer made, but I found 5 of them for US$ 20 so I'm happy. I'm sure your POC V2 choice, the SC28C94, would have worked equally well.

_________________
8 bit fun and games: https://www.aslak.net/

NXP lists the SCN68681 as a "first generation" part, which usually means out of production. They produce the SCC68692, which is essentially the SCN68681 with better features. However, it's still not the equal of the 26C92 or 28L92.


Motorola-style bus interfacing creates gnarly timing problems with the 65C816, due to the use of a single R/W control input. It's not a problem on a write, assuming writes are qualified with Ø2. Since there is no practical means to qualify reads with Ø2, the UART will drive the data bus as soon as it's selected, which in a well-designed system would occur as soon as the 65C816 asserts VDA and/or VPA. However, the bank address would be on the data bus while Ø2 is low, which sets up a bus contention issue. The only resolution would be to use a transceiver on the data bus, with it gated by Ø2 to block incoming from peripheral devices while Ø2 is low.

The 26xxx and 28xxx devices in Intel mode offer separate /RD and /WD inputs, which are easier to manage with the '816.

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