REPLACING THE 65C51

—————
Please read this before posting in this topic.

The goal of this topic is to present the technical information needed to replace a 65C51 UART with a non-65xx part, specifically, the NXP 28L91 single-channel UART and the 28L92 DUART (dual-channel UART). I want this topic to be a useful resource for anyone who is building a 65C02 or 65C816 homebrew machine and wishes to include reliable, high-performance TIA-232 serial communication in the design. Off-topic posts will make it harder for a reader to find out what he or she wants to know and may discourage him or her from continuing. So, PLEASE, avoid off-topic discussion.
—————

———————————————————————————————————————————————————————————————
2019/12/02

"Driving the NXP SC28L91 UART" is available for download. This article discusses programming the 28L91. The paper is not finished and likely has errors—both technical and spelling—in it, but has most of what you need to know to drive the 28L91 in your 65C02 or 65C816 system. Presumably, you have already perused the "Interfacing..." series of articles (below).

———————————————————————————————————————————————————————————————
2017/07/10

"Interfacing the NXP SC28L92 DUART" is available for download. This article discusses the adaptation of the NXP 28L92 dual channel UART to a 65C02 or 65C816 system, and includes circuit examples.

——————————————————————————————————————————————————————————————
2017/06/30

"Interfacing the NXP SC28L91 UART" is available for download. This article discusses the adaptation of the NXP 28L91 single-channel UART to a 65C02 or 65C816 system, and includes circuit examples.

——————————————————————————————————————————————————————————————

In this forum post, it is mentioned that Western Design Center (WDC) recently issued a revised W65C51N UART data sheet, in which there is a caveat about the "stuck TXD empty bit" hardware errata. This bug was first described by floobydust in June 2013, and once the nature of the bug was fully understood, it was reported to WDC. WDC cooperated in determining what was going on and it was thought at the time that a fix would soon be devised and new parts would soon be available. Nothing of the sort has happened. Given the time that has elapsed since floobydust's report, it can be concluded WDC has decided to not do anything about the bug, viz.:


The above is on page 10 of the latest data sheet.

Succinctly stated, this bug makes it impossible for the 65C51 to indicate when the transmitter can accept a new datum and hence prevents the use of interrupt-driven code to run the transmit side of the UART. Only polled I/O can be used and it too has been compromised by this bug. The programmer must introduce a delay after writing to the transmitter so as to avoid writing another datum before the present one has been fully shifted out onto the wire. Writing too soon will likely result in corruption of the datum being shifted out. Obviously, delaying the MPU after each write results in system throughput degradation during data transmission.

Aside from the hardware errata, the 65C51 represents the state of UART design of the mid-1970s. The 65C51 has a poorly-designed programming model, e.g., one cannot decouple the state of the CTS input from the transmitter operation, even when XON/XOFF flow control is being exclusively used, and lacks the programming flexibility and performance features available with modern UARTs. About all the 65C51 offers to the modern designer is ease of attachment to a 65xx system.

Given that the WDC 65C51 is the only 65xx family UART currently available that can be operated at the elevated clock rates supported by the current WDC microprocessors, the 65xx hardware designer who needs a UART has a real problem on his hands. There is only one solution, and that is to design out the 65C51 and design in a modern UART.

A number of modern UARTs are adaptable to the 65xx buses without too much effort. The two that I would consider most adaptable are the 16C550, which is produced by a number of vendors, and the SC28L9x series, which is produced by NXP. Both have 16-deep FIFOs, support for a wide range of data rates and flexible programming models. In the past, I have worked with both the 16C550 and various NXP (then Phillips) UARTs and over time, have concluded that the NXP parts are less onerous to work with than the 16C550.

Since we are discussing a single channel UART, the NXP 28L91 would be the equivalent to the 16C550. In many respects, the two devices are equivalent in performance. However, the 28L91 was designed to work with both Intel and Motorola buses, which gives it more hardware flexibility. Also, the 28L91 has a precision counter/timer that can be used for a wide variety of functions, such as generating a "jiffy" interrupt for timekeeping and/or task switching purposes, as well as generating non-standard data rates.


The 16C550 is, it would seem, the only modern UART readily available in a DIP package, which is, of course, very hobby-friendly. The 28L91 is available in QFP44, which is not hobby-friendly, and has also been produced in PLCC44, for which sockets with 100×100 mil pin layouts are readily available (including wire-wrap versions), making PLCC44 practical on perf board. The NXP part number for this device is SC28L91A1A, which as noted above, is not available through regular parts sources. Since, as of this writing, it is available through wholesale parts liquidators, I am proposing that the PLCC44 version of the 29L91 be the "new 65C51."

NOTE: As the NXP 28L92 dual-channel UART (DUART) has the same interface and physical footprint as the PLCC44 form of the 28L91, the former is recommended for new builds.

Obviously, the 28L91 is not a "bolt in" 65C51 replacement. However, the required glue logic is easy to implement with discrete gates or a PLD, and timing is not a problem—the 28L91 will easily handle a system running at 10+ MHz without wait-states (my POC V1.2 unit is running at 20 MHz with a 28L92 and one wait-state on I/O accesses). When configured in Intel mode, separate /RD (read data) and /WD (write data) signals must be derived from the MPU's RWB output. As many 65xx designs use SRAM with similar control inputs, these signals may already be present. The 28L91's time base, referred to as the "X1 clock," is normally 3.6864 MHz, and may be generated with a crystal circuit or a can oscillator, the latter strongly recommended. I am working on generalized schematics that illustrate how to adapt the 28L91 to a 65C02 or 65C816 system with a minimum of logic.

Driving the 28L91 is somewhat more involved than driving the 65C51, as there is more to configure during initial setup, as well as more in the way of status and control functions. Plus the presence of the receiver and transmitter FIFOs tends to demand a different programming approach than that used with the 65C51. However, it's not complicated. I am in the process of preparing a paper on programming theory, complete with code examples that will be adaptable to the 65C02 and 65C816 (use of the 28L91 with an NMOS MPU is not recommended).

Let me know your thoughts. I'm hoping everyone who needs serial communication in their project finds this topic useful.

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

I looked over some of your builds a while back and came away thinking the way to go was to use a DUART. My thinking was that one operating at RS-232 levels and one left at TTL levels would give me a fair amount of flexibility.

So if you subscribe to the theory that "everyone" needs more than one serial port, looking at a DUART as the norm might make sense.

I definitely agree that having something that several people have used and where known working code is available would be nice for anyone looking at doing their own build.

I'm new to the world of FPGAs, but have to admit the ability to tweak the hardware itself is kind of cool. My SBC build has kind of been put on the back burner for now.

Jim

Agreed... time to move beyond the 65C51. I've also looked at the SC28L91 and was looking to use it as a replacement. However, as already noted, this is end of life from NXP so you need to find alternate sources as BDD already has. As the 28L92 is still readily available in PLCC, I would lean towards moving to this part instead. Same package size, same UART, just two of them. I also support the idea of using one port for the console via a FTDI USB-Serial interface and the second port for RS232 levels and a DB-9 connector for anything else one might need.

I do have a SC28L92 here... just no free time to get it on a board and wired up... ugh. There's also the 26C92 which, while similar, is still readily available. While it only has 8-byte FIFOs, it also consumes less than half the supply current (10ma vs 25ma per the datasheets) so it may be more favorable for anyone planning to go with battery operation. And of course, thanks to BDD for starting a new post on this with options.

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

Truly a very good idea BDD!

Back in the 80's I was heavily disappointed by the 6551 (NMOS) when I realized what was going on with /CTS. From that time I never used it again. Later then I read about the "new features" the 65C51 possesses... WHAT A SHAME.

EDIT: --- I decided to wipe that part of this post that was off topic. ---

The technical aspects of interfacing the 28L92 DUART to the 65C02 and 65C816 are virtually identical to those of the 28L91 and will be addressed later on, assuming there is sufficient interest.

That said, I don't want to muddy the waters at this time by bringing the DUART into the discussion too much. That will come later. My goal is to get everyone to recognize there is a viable alternative to the 65C51, publish the technical information needed to adapt that alternative to a 65xx system, and provide a source to forum members for the alternative part. If after reading all this, someone decides their needs would be better served by the DUART they can purchase one from stocking distributors (order NXP part number SC28L92A1A to get the PLCC44 version).


Thanks!


I've been saying that here since the beginning, even before it became known the WDC part was defective. I understand the desire to stick with 6502 peripheral silicon for that authentic retro computing experience—in the case of the 65C22, it makes sense, since it has a lot of functionality and only one known hardware bug (scroll down to read about it). That said, sticking with the defective and inadequate 65C51 just because it has a 65xx pedigree makes little sense to me. As you say, it's time to move on.

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

And it was not my intention to discuss the choice of the chips. I simply choose a different one, primary due to the small package available. I have not yet look what packages are available for the 28L91 and whether a similar module could be possible - freeing me to elaborate a driver

EDIT: Did look at the DS, found nothing smaller than QFP. This would cause a modul size of at least 600mils width (or height).

(The best way to make this a good reference thread, BDD, is to keep editing the head post to update it with the latest and best advice, and to add links within the head post to any particularly good reply posts. When the thread has gone cold, if you happen to need to make a further update to the head post, you can of course bump the thread with a new post pointing out that you've made an update.)

Yep! I did that in my POC V2 topic, especially since it now runs to 28 pages. I will do that here as things progress.

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

This is for those who use ExpressPCB's software to draw their schematics.

Attached are two ZIP archives, one containing schematic components for the NXP 28L91 UART and the 28L92 DUART, both for PLCC44 packages. The other archive contains schematic components for the Maxim MAX232 and MAX238 TIA-232 transceivers that are often used with UARTs. The MAX232 component is laid out for DIP, whereas the MAX238 is laid out for DIP and SOIC.

Unpack the archives and copy the files to wherever your custom EPCB schematic components are stored on your system. Look in the options menu of ExpressSCH if you aren't sure where your custom components and symbols are being stored.

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

I have almost completed the first article that I will be publishing on replacing the 65C51 with the NXP 28L91. I need to create a few illustrations and then the article will be ready for publication (in PDF form).

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

Oh, brilliant. That will be useful.

Also, after I get home, I'll post up the KiCAD schematic symbol I put together for the 28L92.

I did say that I'd put up a symbol for the 28L92(the dual-channel version), but BDD asked me to hold off on that via PM.
I have, at his request, put together a 28L91 KiCAD symbol, which I have attached. It will need to be unzipped before use.

I have completed the first "white paper" on interfacing the 28L91 to a 65Cxxx system. See the first post of this topic for the download link. This paper covers the hardware aspects only. The next paper will get into software engineering.

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

If you wanted to use or provide the full PC-style interface, to what pins would you need to connect DSR, DTR, RI and DCD?

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.