There is no such a thing as a "PC-style interface." TIA-232 (assuming that is what you meant) existed long before the first microcomputers were developed. All that PC hardware did was introduce the DE-9 connector (on the PC-AT) as an alternate to the standard DB-25 connector. The use of the DE-9 alternate is defined by the TIA-574 standard.

In the TIA-232 standard, there are "data terminal equipment" (DTE) devices and "data communications equipment" (DCE) devices. A terminal, printer, magnetic strip reader or machine controller is a DTE. A computer is a DTE when acting as a workstation.

A DCE is almost always a modem, or a device that links up two DTEs, such as a "null modem" cable. A computer acting as a server is technically a DCE if its serial port is connected to a DTE.

Both DTEs and DCEs are required to have an RxD (receive data) input and a TxD (transmit data) output. RxD and TxD are all that is needed to establish two-way communications. All other circuits are optional and some, such as RI (ring indicator), are seldom used these days—modems are usually programmed to automatically answer and then tell the host via the DCD connection when carrier has been established.

The 6502 contraptions we build are technically DTEs, so a "full" set of TIA-232 connections would be RxD, TxD, CTS, RTS, DSR and DTR. Hardware flow control would be established with CTS and RTS. There would be no reason to implement DCD or RI unless the 6502 contraption was to be directly connected to a modem. Note that DCD and RI are inputs on a DTE, but are outputs on a DCE. It would be illogical to connect, for example, DCD on your 6502 machine to DCD on a PC's serial port, as both are inputs.

The TIA-232 side of the 28L91 has nothing to do with interfacing a UART of any kind to a 65C02 or 65C816, and I as much make that point in my paper. In fact, the 28L91 could be used to communicate on a TIA-485 link, which is a totally different animal than TIA-232. Yet the microprocessor interface would be exactly the same as if the UART were linked up to a TIA-232 circuit.

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

I took the question to be regarding the normal way to get the various handshake signals from the 28L91. My guess would be that the UART’s RTS output comes from OP0, pin 32, and that the UART’s CTS input is at IP0, pin 8, and that you have some choice about which of the others to put DSR and DTR on, or even DCD or RI if you use them.

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

The basic TIA-232 interface illustration on page 16 covers CTS and RTS.


DSR could go on any IP pin other than 0 and DTR could come from any OP pin other than 0. I would use OP7 for DTR and IP6 for DSR. Alternatively, DSR could be wired to a IP that has change-of-state, in which case the UART could be set up to interrupt if DSR changes.

DCD and RI would be inputs and unless the system with the 28L91 is to be connected to a modem, there is no reason to implement these circuits. If used, DCD should be wired to an IP pin (e.g., pin 1) that has change-of-state detection so a change to DCD can cause an IRQ. RI is hardly used these days, so I wouldn't bother with it.

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

Just because the signals no longer see much use and/or you do not use them, doesn't mean that they have no use, and since neither the NXP datasheet nor your instructional sheet gave clear guideance on how to connect up these signals if they were required, I enquired. As it transpires for the application I have in mind, no, I don't need DCD or RI and I have no intention of connecting them, nor can I think of any modern application where they would be needed (unless you were actually connecting to a modem!), though I included them in the question for completeness. I do, however, need DSR & DTR.


And that answers my question nicely, Thank you.

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

I don't recall saying that DCD, RI, etc., have no use. I pointed out that RI is seldom used anymore and DCD is only applicable in the context of a modem. You are reading something into my last post that isn't there.


That lack of "clear guidance" is intentional on both NXP's part and mine. Also, your question wasn't phrased in that fashion, which is why I answered as I did. I don't mean to put you off, but I also don't want to have to answer a lot of questions that can be resolved with careful reading and thought. That said, see attached.


Unlike the 65C51, 6850 and other UARTs of that class, NXP UARTs are extremely flexible and can be connected to a wide variety of external hardware in a wide variety of ways. Whereas the 65C51's primary design focus is in connecting to a modem, an NXP UART is intended to be used with virtually anything that communicates with a serial data stream, including Bluetooth receivers, GPS receivers, ECMs in automobiles, etc. Clearly, elucidating on all the ways in which the 28L9x can be linked up with other serial hardware could fill up another white paper, and consume a lot of time in writing that paper. NXP mentions the serial interface side of the UART only in the context of programming it. They can't possible cover all the ways the electrical connections can be made, and leave it up to the designer to use some aptness of thought to figure out how to rig up, say, DCD to do something. In other words, data sheets are not application notes.

I took the same approach in my write-up, except my focus is narrower than NXP's, since it is about adaptation to 65xx hardware. The process of getting a UART and a microprocessor to mutually converse has no relationship to the process of getting the UART to converse with a printer, terminal, etc. It's no different than with the 65C22, or any other I/O device. Everything that you need to know to make serial interface connections is in there. I'm trying to point the way, not hold your hand.

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

I have completed the "white paper" on interfacing the 28L92 DUART to a 65Cxxx system. See the first post of this topic for the download link. This paper covers the hardware aspects only.

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

This is a great thread. Thank you.

You are welcome. Thanks for the compliment.

The next paper in the series, Driving the NXP SC28L91 UART, is in process—in fact, I'm working on it as I speak, so to speak. It may be a couple of weeks before it is ready.

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

A minor comment and possible recommendation. Exar make some compatible chips here, specifically the XR88C92 and XR88C192. These are pin and program compatible with the SC26C92, provide operation from 2.97V to 5.5V, offer 8-byte (xC92) or 16-byte (xC192) FIFOs and consume a maximum of 1.5ma of current at 5V. With a quick scan, the datasheet seems a bit more user friendly (than NXP's) and has some simple programming examples for setting the chip up for a few modes of operation.

http://www.mouser.com/ProductDetail/Exar/XR88C92CJ-F/
http://www.mouser.com/ProductDetail/Exar/XR88C192CJ-F/

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

I decided to limit coverage to the 28L91 and the 28L92, and ignore the older 26...) UARTs. Neither of the above parts is exactly pin-compatible with the 28L92.

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

Fair enough... your article, your choice on what to cover or not. I would point out that NXP documentation state the SC28L92 is a pin and function replacement for the SC26C92. The only pin that differs is the I/M pin, which is a N.C on the 26C92 (pin 12 on 28L92 PLCC), so if you're planning to use Intel mode, then that pin floats and the parts are directly interchangeable. The EXAR parts are a pin and function replacement for the SC26C92 so the same would apply. My main point was/is the reduced operating current, as the 28L92 states from 7ma to 25ma, the Exar parts are max at 1.5ma, quite a difference.

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

The 28L92 plugs into a 26C92 socket and works because pin 12 would have been wired no-connect on the board using the 26C92. The reverse is not necessarily true, however. In most cases, an NC pin is not to be connected to anything and if by chance the Exar part is plugged into a board built around a 28L92 wired for Motorola bus mode the NC pin would end up being grounded. Operation of the device could be undefined in such a case—neither NXP or Exar indicates what might or might not happen if a no-connect pin is wired to the circuit.

As for the current consumption angle, that would most likely be of importance to someone powering their system from a battery. My articles don't get into the specifics of power sources or other hardware matters, other than adapting an NXP IMPACT UART to a 65C02 or 65C816 system. Presumably, anyone who is able to scratch-design such a system can work out the details as needed.

As I noted in the opening article, I want to keep topic dilution out as much as possible. My focus is on NXP parts subbing for a 65C51. Perhaps later on a post or two about subbing an Exar part for an NXP part can be made.

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

I see in your first post, you mentioned running at 1X clock rates.
Most UARTs can only run 1X with synchronous clocks.
Does the part have a built in clock multiplier to use for sampling?
I'm not able to read pdfs right now but will later.
Dwight

I did? Perhaps you were thinking of this:


The X1 clock is the time base used by the 28L91. The above could be better worded so one doesn't mistakenly think only 1X sampling occurs on the start bits.


Yes, and if using the built-in baud rate generator, you have your choice of using 16X or 1X—16X is the default.

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

I've always wondered why they even have the setting since for async operation
it is useless. They don't always mention it in the data books but they usually
include a diagram showing how the sampling is done.
I've seen design errors caused by it.
Dwight