What UART should i use for my first computer?

[BigLadWhillis]

I'm working on a computer and am wondering what UART i should use for 57600 baud, preferably i would want it to be easy to use and be reliable. I was looking at the Zilog ZDU0110RJX, Which is used for 57600 baud communication via serial without requiring a external clock, which makes my life so much easier, What I'm wondering is if this chip is useful for my application, I've never done SMD before but it shouldn't be too hard.

Thanks for the help

[DerTrueForce]

That UART is unsuitable, unfortunately. That one uses an I2C interface, and I'm assuming you want one to go on the 6502's main bus, which is a parallel interface. For that purpose, the ones that get recommended a lot are the NXP SC28L91 and SC28L92. The datasheet for that one is not the best, though there are a few people here who have gotten it to work. Those do need an external oscillator or crystal, but that really isn't such a problem. Most UARTS(including the 65c51 and the 28L91 and 92) also have software-selectable baud rates, without needing to change the oscillator.

[BillO]

The 65c51 is probably the simplest way to go, but it will not do 57K baud (19K max.). The NXP chips are pretty much the best you can get, but the available packaging is all surface mount. Not an issue if you are really experienced a soldering such devices, but not very beginner friendly.

There are other options too, the like the 16550, but I have never used them. They are more complex and larger than the 65C51.

Just a point here. Would it not be better to restrict all your questions regarding this build to a single thread? You seem to be asking the same questions is various different threads. It gets a little difficult to keep track of what has been answered where.

[BigLadWhillis]

BillO wrote:

Just a point here. Would it not be better to restrict all your questions regarding this build to a single thread? You seem to be asking the same questions is various different threads. It gets a little difficult to keep track of what has been answered where.

ahem... uhm you do make a... good point, from now one i will just add to my original thread and continue from that.

[GARTHWILSON]

BigLadWhillis wrote:

BillO wrote:

Just a point here. Would it not be better to restrict all your questions regarding this build to a single thread? You seem to be asking the same questions is various different threads. It gets a little difficult to keep track of what has been answered where.

ahem... uhm you do make a... good point, from now one i will just add to my original thread and continue from that.

Yes, please do. Thankyou. Readers will be able to see the various parts of your project together and keep them related mentally, and it results in less forum clutter.

[cbmeeks]

BillO wrote:

The 65c51 is probably the simplest way to go, but it will not do 57K baud (19K max.).

I can verify that the 65C51 is easy to get going. Even with its infamous bug, it's still not a bad little chip for beginners like me. In fact, I actually found the old NMOS version from eBay (US seller) that worked really well that doesn't have the bug. It doesn't have the buffers or other bells and whistles, however.

Plus, I wonder, how important is 57K for a beginning 8-bit computer? Are we really in that much of a hurry? LOL

BillO wrote:

The NXP chips are pretty much the best you can get, but the available packaging is all surface mount. Not an issue if you are really experienced a soldering such devices, but not very beginner friendly.

One option that might help the beginner is look for a PLCC44 to DIP44 converter on eBay. These are dirt cheap and will allow you to plug it in like a normal DIP...although they are longer in that they have 4 extra pins. Just be careful and read closely. I bought some once and didn't realize it was a PLCC44 to DIP40 converter (it dropped four pins).

[GARTHWILSON]

BillO wrote:

The 65c51 is probably the simplest way to go, but it will not do 57K baud (19K max.).

I answered this somewhere but it must have been elsewhere (on a different forum?) since I don't see it now, so I'll repeat it. The '51 will do at least 125kbps if you use the 16x clock input rather than the onboard BRG. I've used it at 31.25kbps for MIDI, giving the 16x clock input 500kHz from a VIA's PB7 toggled from a free-running T1's timeout. [Edit: I'm also using it at 115.2kbps for programming our bluetooth devices for work.]

[BillO]

GARTHWILSON wrote:

BillO wrote:

The 65c51 is probably the simplest way to go, but it will not do 57K baud (19K max.).

I answered this somewhere but it must have been elsewhere since I don't see it now, so I'll repeat it. The '51 will do at least 125kbps if you use the 16x clock input rather than the onboard BRG. I've used it at 31.25kbps for MIDI, giving the 16x clock input 500kHz from a VIA's PB7 toggled from a free-running T1's timeout.

True, but it makes changing baud rates a bit of a pill.

[GARTHWILSON]

BillO wrote:

True, but it makes changing baud rates a bit of a pill.

As long as the phase-2 clock rate and the desired bit rates are compatible, ie, that the VIA is capable of putting out 16x the desired bit rates with the current phase-2 frequency, you would change the bit rate by writing to the VIA's T1's latch rather than the ACIA's control register. Not much different.

[BillO]

I meant if you don't have a VIA. Then you need to change crystals or build a BRG (using a VIA or otherwise). But the VIA idea is a pretty neat one.

[floobydust]

I've used the 6551 and 65C51 for decades. In short, it's dirt simple to make it work in either polled I/O mode or interrupt-driven mode, provided you have a properly working one. I actually bought over 20 of the new WDC chips (both DIP and PLCC) and eventually found the Xmit bug. You have several options to work around it, but for myself, I don't want to be writing code as a band-aid for defective components.

My last SBC project used a Philips/NXP UART, the SCC2691. Granted, this chip is no longer in manufacture and isn't the latest from NXP, but they are (still readily) available in 24-pin DIP, can easily run up to 115.2K reliably and I've written a rock-solid BIOS to support it. There are a few caveats however:

1- 6MHz CPU clock is the typical limit, which is per the datasheet (I do have one chip which is rock solid at 8MHz, out of a stock of 13).
2- Implementing Extended baud rates (higher than 38.4K) could be better implemented, but I've worked around that as well.
3- A test mode register can be toggled, which can appear to crash the UART, but there's no way to know this. The only fix is to toggle it again or physically "hardware reset" the chip.

In short, if you're looking for a solid UART that can handle high baud rates, available in DIP and looking to stay around 6MHz on the CPU clock, I would highly recommend it. I've currently run 3 SBCs with this chip totaling over 50K hours without a single hiccup. Using one of the newer NXP UARTs (SC2692, 28L91/2) would be better, but they are only available in PLCC or QFP.

[cbmeeks]

Someone should create a small PCB that accepts a PLCC44 or QFP NXP UART, crystal oscillator, caps, etc. and bring it out to DIP package. Something as small as possible that could just plug into a breadboard or socket. Could even have a place for RS-232 level converters.

May not be the smallest PCB in the world, but an easy "drop in serial" design would be pretty cool.

[drogon]

cbmeeks wrote:

Someone should create a small PCB that accepts a PLCC44 or QFP NXP UART, crystal oscillator, caps, etc. and bring it out to DIP package. Something as small as possible that could just plug into a breadboard or socket. Could even have a place for RS-232 level converters.

May not be the smallest PCB in the world, but an easy "drop in serial" design would be pretty cool.

Maybe just stick an FPGA/CPLD on the carrier and make it 6551 compatible without the bug? This has been done for much more complex stuff in the past - e.g. the TI99 graphics chip thingy... Anyone up for the challenge?

-Gordon

[cbmeeks]

drogon wrote:

Maybe just stick an FPGA/CPLD on the carrier and make it 6551 compatible without the bug? This has been done for much more complex stuff in the past - e.g. the TI99 graphics chip thingy... Anyone up for the challenge?

-Gordon

That's not a bad idea either. But it could be a hurdle for new 6502 designers or people intimidated with FPGA. I was thinking more along the lines of a drop-in board where the user only has to solder and go.

Of course, if someone sold the FPGA/CPLD solution then that would be cool.

I just see the NXP recommended a lot (I have one myself) and the big hurdle for it (for some people) is the package format.

BTW, I own the "TI99 graphics chip thingy". The F18A. I wished I had 100 of them. We're all waiting for the creator to open source the files. He's working on part two (MK2) but who knows when it will be finished. That's the problem with relying on one person for a product. You are at their mercy and time schedule.

[BigDumbDinosaur]

drogon wrote:

Maybe just stick an FPGA/CPLD on the carrier and make it 6551 compatible without the bug? This has been done for much more complex stuff in the past - e.g. the TI99 graphics chip thingy... Anyone up for the challenge?

Using a naval analogy, making an FPGA emulate a 6551 seems too much like dispatching a battleship to sink a rowboat. A PLCC44-to-DIP adapter is a whole lot less work.

In the case of the NXP 28L92, two pins are no-connects, so the adapter could be designed around a 42 pin DIP socket. The logical way to construct the unit would be to directly solder the UART to the board so as the eliminate the cost of a PLCC44 socket. PLCC uses 50 mil J-leads, which can be manually soldered.

cbmeeks wrote:

Could even have a place for RS-232 level converters.

That could be done. However, not all applications would need TIA-232 voltages, so you'd have two different designs to accommodate those who want TTL connections vs. those who want TIA-232. Better to have the TIA-232 transceivers on the mainboard instead of the UART adapter.

Getting back to the 6551 itself, it's a very obsolete design that reflects 1970s technology. About all it has going for it is it's easy to interface to a 65xx bus and it has a very simple, albeit brain-dead, programming model. Much better UARTs are available.