Hello everyone. I have never used a UART in my computer designs. But Ben Eater has sparked my interest with his new "Serial Interface" videos (here https://www.youtube.com/watch?v=zsERDRM1oy8).

1) It is very well known that the W65C51N has a fairly serious bug in it, and WDC has had no indication of fixing it. Therefore, Kevin (floobydust) uses the SCC2691 and BDD uses the SCC2692. I went on to Mouser and cannot find them, and I figure their search engine is pretty good. Is it no longer in production? What are other modern (still in production) replacements for the W65C51N? I have also seen Garth recommended the MAX3110E (SPI interface) but I don't see that on Mouser anymore either, so I'm guessing it's no longer in production?

2) RS-232 is great, but most modern PCs or Macs don't have that built in. Also, if you are using plain ol' RS-232, you need a MAX232 or some such to meet voltage requirements. How else do you interface the UART? I have played with the FT245RL before, but not seriously enough to know the in's and out's. Is it possible to use an Arduino Nano? Are there other ways to connect your UART to a modern PC easily [ read: USB ]?

3) Why would I use a serial connection to a PC anyways? I know that you can possibly:

a) Send keystrokes to the 6502 and have it send characters back in a terminal like minicom (or telnet?).

b) Send whole binary programs to the 6502 though something like TerraTerm.

Am I correct about this? Is there anything else that it can do for you? How do you use your 6502+UART?

Thanks ahead of time for the learning I will receive.

Chad

1) Assuming you want something that can interface directly with the main parallel bus of your SBC (rather than going through something like SPI), essentially all UARTs currently available are clones or supersets of either the 16C450 (which was the UART used in early IBM PCs) or the SCC269x (the NXP one). They are also pretty much only available in SMT packages. If you want through-hole, and you don't want NOS, you'll need an I2C/SPI based UART, or to use the old-fashioned WDC W65C51N or Zilog Z0847006PSG.
Link: One of many examples of a 16C450-compatible UART available.

2) Actually, many desktop PC motherboards do in fact include an RS-232 serial port on the backplate. Business orientated boards often have 2x serial and a parallel port, even these days. Consumer and "Enthusiast" boards often have an internal serial header which can be accessed using an inexpensive bracket. My own computer falls into the latter camp, and I have just such a bracket in place. But failing that, FTDI make a range of cables and adapters to suit for converting RS-232 or other similar protocols to USB. I'm not sure about an Arduino Nano specifically, but you can definitely use the Arduino Uno as a 232-to-USB adapter: remove the Atmega328p processor chip from the Uno, and connect the TX/RX signals from your UART at TTL level (i.e. not via a MAX232) to the Uno's pins D1 and D0. You now have a somewhat physically fragile but nevertheless fully functional RS-232 to USB adapter - I have done this in the past.

3) In addition to (a) and (b) that you gave, RS-232 can also connect two SBCs together to create networks, or use it as a general peripheral interface bus (there are plenty of industrial widgets which can be controlled, or report data, via 232). For 6502 hobbyist use, it usually comes down to the fact that an RS-232 based interface is one of the easiest and quickest to implement and get you up and running quickly, then you can use that to help you launch off into (and debug) any more complex interfaces you may want. A UART using different logic buffers can also implement RS-422, RS-485, MIDI and DMX-512 protocols, and no doubt others too.

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

Whether you're building something with an LCD display and buttons, or a retro gaming-console with a keyboard and VGA output, a UART can be a great interface for debugging.

My interest is more in the latter, so let's say I'm writing a game with moving graphics and taking input from the keyboard or a joystick... and either (a) things don't look right, or aren't moving right, or (b) everything just stops... freezes... due to a bug. How can I debug that?

Well, one way might be to have an NMI button I can push to enter a monitor. But that's going to need to take over the VGA screen and keyboard so I can interact with it, so either I have to be fancy about it and find somewhere to save al that state, or I'm going to have to accept that some state will be lost.

Another way to go might be to have the debugger use the UART. Now my keyboard I/O state is preserved, as is my video controller state and memory. I can issue commands through the UART to read any state as it existed before I pressed the NMI button.

Even better, with my game running I can use the UART to extract runtime telemetry (taking UART interrupts), and even set breakpoints and debug, single-step, continue, etc.

I think UARTs are great.

I agree; I can't see me ever designing a processor board without a serial connection - UART->FTDI cable->terminal program->FTDI cable->UART is a tried and true method of talking between a development system and (system agnostically) a terminal.

Curiously, embedded processors like the STM32L07xxx series have at least four (well, depending on pin count) UART ports as well as their one-wire JTAG debugging function; someone thinks they're worth having.

Of course, there are chips from which one might reasonably easily build a JTAG-style interface on a generic digital circuit but frankly life's too short and serial ports are too cheap to bother.

Grant Searle's minimal design uses a no-longer-available (except as NOS or pulls) 68B50 UART which uses a very sneaky trick to automate flow control; he uses the interrupt pin to control CTS so until the processor reads the input port, clearing the interrupt, the sending end waits. The interrupt pin does not go to the processor at all, which instead polls the 68B50's status register. That works with the way the original MS basic was written.

Neil

I don't mind being corrected. What I meant was my home desktops or laptops. Indeed all of the computers here at work do have a serial port. Am I correct in understanding that even if there isn't a DSUB9 on the back of the PC, that it doesn't necessarily mean it's not on the motherboard? Connect to it with a ribbon cable, all is done? That sounds too easy!



Ah that is a good point. Yes, it can act as a secondary display device in a way, or could send coordinates, codes, or other things that you can't always easily display on the monitor, etc.



You are not alone in that school of thought, and that is why I am wanting to discover and learn.

Thanks for the responses so far!

Chad

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

Modern motherboards are slowly starting to lose them, but yes, many still have the header for a serial port. Look for a port labeled COM or COM1. Note that the voltages on these ports are not directly compatible with TTL/CMOS and so you will need an interface IC (often called a line driver or level shifter, although both of those terms apply to other ICs too) to go in between your ACIA and the PC serial port. The MAX232 and all of its clones are popular chips to use - I often use an ST3232 for this purpose when connecting to real serial ports, but that chip is surface mount only.
Ask the e-commerce site of your choice for "motherboard serial port" and you'll see the mating connector, a short ribbon cable, and a DB-9 external connector mounted on a slot plate for the back of a computer (they have half-height versions too if you need the shorter bracket for your computer). Once you know what to look for, you can just open the computer and look on the motherboard to see if you already have a serial port. They are usually near the bottom edge of the motherboard between the expansion slots and the edge of the board.

I run Forth on my single board computer, so using an ACIA allows me to use my computer's display and keyboard, as well as to write software on my PC in my favorite editor and using modern revision control, and then send it quickly over to my SBC to test it out - all without having to reprogram an EEPROM. This falls into categories 3a AND 3b from your head post, although Forth programs are sent to the SBC as text rather than binary. I also enjoy the ability to do debugging over the serial link. I can not only add extra print statements to the program, but Forth allows interactive inspection of variables, dumping memory, changing values, etc. with immediate results. I use a USB->TTL_Serial_Port cable with my board, so I only need a free USB port on my PC.

Chad,
Most people started out with a serial port as the console peeking into the inner working of microprocessors because it is easy and there are plenty of hardware/software examples. It is easy to load files, display memory, change memory and run program via a serial port. However, you’ve started out with video and keyboard and figured out how to debug your programs with emulator and eprom programmer. It is a more difficult path, but now you’ve done it, the serial port seems less useful to you. But even in your setup, serial port is still a good way to upload new programs from your workstation to the target hardware.

Given serial port is just a file transferring mechanism for you, I think you can implement an extremely cheap serial port by software manipulating hardware handshake and bit banging the transmitter and receiver. You can accomplish that with a couple D flipflops and a buffer.
Bill

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

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

A naive approach perhaps, but he was presumably designing something to work with the MS basic.

Don't forget, at some point in any input routine you're going to have to poll *something* to see whether there is any received data requiring your attention. Using a buffer driven by an interrupt is in many ways nicer - in particular because it can largely look after receiving new characters itself without bothering the main program flow, but sooner or later you're going to have to see if the head and tail pointers differ and do something about it.

I can't offhand think of many applications - games perhaps? - when you need an instant interrupt to say a character has arrived... if you're waiting for characters either you're spinning in a loop waiting for the buffer to be not empty, or you're spinning in a loop waiting for the RX register to be not empty. Grant's method moves the buffering off the board and onto the terminal (or more likely, a much more capable computer) but significantly doesn't require you to have a working interrupt routine before you can receive anything.

I can't agree with you that it's terribly inefficient - at least, any more inefficient than other approaches.

Of course, what we'd probably all like is a UART with a large internal buffer to take the strain!

Neil

For sure I've used a TTL-UART connection to a host machine for a console and for debug - but also for a filesystem, in at least a couple of different ways. Get the right kind of USB adapter and flow control will work properly.

About UART choices, I posted this nearby:

Everything SamCoVT said in his post (quoted below) is correct, but just to add sometimes the motherboard's serial port header will be disabled by default, and you'll need to turn it on in the BIOS settings.

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

And one point, of which I'm sure we're all aware but it's still worth pointing out, I think: remember that there is a difference between UART serial output and RS-232. The main thing to be aware of is that the RS-232 signal moves either side of zero volts by at least three volts and often as much as twelve - so from -12v to +12v potentially.

The UART input and output expect to see/provide either zero to 3.3v or zero to 5v depending on Vcc. The signal is also the other way up from RS-232 - it is logic high for a one, while RS-232 is at it's negative level.

As an added bonus, the signal idles at logic high. This means that if you're plugged into a logical UART signal (either direct or through an RS-232 converter) and your device isn't powered, you can find that it actually *is* powered through the substrate diodes because of that logic high... can be surprising.

Neil

EDITED at Dr Jeffyll's suggestion to clarify the voltage levels for UARTs.

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