I am considering making a SBC (who hasn’t!) but getting disturbed by the lack of uarts. While WDC seems to have a nice supply of 65c22s, the serial interface they offer is nothing better than a shift register.
While the 16c550 offers fast speed, I havn't seen any simple designs for it. Everyone seems to have designs for the 65c51, but I can't find a good resource for the chip.
Has someone made a uart with logic? That seemed mentioned.
If all I have to work with is the 65c22s, has anyone made a serial interface using it? It looks like it can take an external clock, so if I just want a single baud rate could it work?
PS - I am talking a real, RS232, type in hyper terminal, interface. Not though the printer port.
Good uarts to use?
-
GARTHWILSON
- Forum Moderator
- Posts: 8773
- Joined: 30 Aug 2002
- Location: Southern California
- Contact:
The 6522's shift register has a lot of great uses. RS-232 is hardly one of them, although I have used it to output RS-232 (through a line driver of course). My tips, starting at page http://www.6502.org/forum/viewtopic.php ... sc&start=0 , have several on the 6522 shift register as well as the 6551 ACIA.
If 1 & 2MHz is ok, you can get 6551's (& 65c51's) at GI Electronics at http://store.gielectronics.com/gielectr ... 0-cpu.html and at Jameco at http://www.jameco.com/webapp/wcs/stores ... tId=117795 .
There are plenty of UARTs available that will work with the 6502, so I don't think it would be worth it to make your own. You could use a couple of 6522 pins and do it in software, but it's kind of a pain and not suitable for the higher baud rates especially if your processor is not running that fast.
One UART I've played with a little is the Maxim MAX3100, an SPI-interfaced 14-pin DIP whose capabilities are generally beyond those of the 6551. You can buy them directly from Maxim's website, http://www.maxim-ic.com
If 1 & 2MHz is ok, you can get 6551's (& 65c51's) at GI Electronics at http://store.gielectronics.com/gielectr ... 0-cpu.html and at Jameco at http://www.jameco.com/webapp/wcs/stores ... tId=117795 .
There are plenty of UARTs available that will work with the 6502, so I don't think it would be worth it to make your own. You could use a couple of 6522 pins and do it in software, but it's kind of a pain and not suitable for the higher baud rates especially if your processor is not running that fast.
One UART I've played with a little is the Maxim MAX3100, an SPI-interfaced 14-pin DIP whose capabilities are generally beyond those of the 6551. You can buy them directly from Maxim's website, http://www.maxim-ic.com
-
Brian_Lyons
- Posts: 14
- Joined: 28 Nov 2004
- Location: Toronto, Canada
RS232 with 6522 is generally a bad idea.
Just talk to a Commdore Vic-20 owner.
For 16550 design, check out :
http://www.6502.org/users/andre/csa/csaduart.png
Found on page: http://www.6502.org/users/andre/csa/
I haven't tried this out. But it looks like a pretty straight forward interface between 6502 and 16550
If you want to play with really old hardware, you could always use a 6402 (Ay-5-1013). I have a pile of these and have used a couple in projects. It's limited to 19.2Kb/s, but is super simple to design around.
Just talk to a Commdore Vic-20 owner.
For 16550 design, check out :
http://www.6502.org/users/andre/csa/csaduart.png
Found on page: http://www.6502.org/users/andre/csa/
I haven't tried this out. But it looks like a pretty straight forward interface between 6502 and 16550
If you want to play with really old hardware, you could always use a 6402 (Ay-5-1013). I have a pile of these and have used a couple in projects. It's limited to 19.2Kb/s, but is super simple to design around.
I'm using a PIC microcontroller's UART (PIC18F452). The CPU writes to the PIC's parallel port, and my software in there buffers it and sends it out. And for receiving, it buffers those and interrupts the 6502 to let it read a byte out when it's ready.
Of course I'm using the PIC for more than the UART, as you can imagine.
So it could be overkill, or not what you're after, but it's an idea. Plus it could be slower than a pure hardware solution in some cases.
Of course I'm using the PIC for more than the UART, as you can imagine.
So it could be overkill, or not what you're after, but it's an idea. Plus it could be slower than a pure hardware solution in some cases.
It's not super fast, but it's definitely much faster than the bit-banging method I used before.
With a 1.789Mhz 6502, and 20Mhz PIC, I've found I need maybe a 12 to 20 6502 cycle delay between consecutive writes/reads (but that timing really depends on the PIC's code).
If you write a FIFO buffer in the PIC's software then it can be getting the next byte from the 6502 while it's still sending the previous byte(s). Have it interrupt the 6502 when the buffer is empty, rather than when all bytes are sent, you know.
Then the tricky part is determining the IRQ source. I do this with a seperate read of the PIC's port (but this does slow things down a bit overall).
With a 1.789Mhz 6502, and 20Mhz PIC, I've found I need maybe a 12 to 20 6502 cycle delay between consecutive writes/reads (but that timing really depends on the PIC's code).
If you write a FIFO buffer in the PIC's software then it can be getting the next byte from the 6502 while it's still sending the previous byte(s). Have it interrupt the 6502 when the buffer is empty, rather than when all bytes are sent, you know.
Then the tricky part is determining the IRQ source. I do this with a seperate read of the PIC's port (but this does slow things down a bit overall).
Here's something that I've been wondering lately.....
So I made the leap to getting a AVR starter kit, because a lot of things I want to do can be done that way with a lower parts count.
It's already established that the 6522 can't quite do SPI.
But what about using the 6522's shift register to do synchronous serial transfers to an AVR? Most of the MegaAVRs have a USART that is able to do clocked IO, and both the AVR and the 6522 can fire interupts when a byte comes in.
So I made the leap to getting a AVR starter kit, because a lot of things I want to do can be done that way with a lower parts count.
It's already established that the 6522 can't quite do SPI.
But what about using the 6522's shift register to do synchronous serial transfers to an AVR? Most of the MegaAVRs have a USART that is able to do clocked IO, and both the AVR and the 6522 can fire interupts when a byte comes in.
-
Wally Daniels
- Posts: 53
- Joined: 30 Aug 2002
- Location: Windsor Forks, N.S. Canada
Re: Good uarts to use?
Ignoring the idea of bit banging with the VIA and considering the idea of
a UART or UARTs coupled to a 65xx CPU, maybe you might want to
consider one of WDC's single-chip controllers.
Although I have not used the 'C134' I have built a few SBC's around the
65C265. It can be either a C02 based cpu or a C816 its up to you. It
comes with 4 built-in UARTS, address decoding built-in and an onboard
ROM monitor that will let you download test programs into RAM/ROM
space in Motorola S record format.
The datasheet makes it look alittle daunting, but you can actually get the
Chip running with just : power, a 32kHz oscillator for the Slow clock,
a variet of common frequencies for the Fast clock ( sse the datasheet )
RS232 level translation and a Terminal program.
There is also at least one eight bit port that can be used for general purpose I/O, vectored-interrupts ( which are really handy ) and 8 timers.
If you are at least familiar with 65xx coding have a look, it may be just
what you need.
Good Luck in your searching, Wally
a UART or UARTs coupled to a 65xx CPU, maybe you might want to
consider one of WDC's single-chip controllers.
Although I have not used the 'C134' I have built a few SBC's around the
65C265. It can be either a C02 based cpu or a C816 its up to you. It
comes with 4 built-in UARTS, address decoding built-in and an onboard
ROM monitor that will let you download test programs into RAM/ROM
space in Motorola S record format.
The datasheet makes it look alittle daunting, but you can actually get the
Chip running with just : power, a 32kHz oscillator for the Slow clock,
a variet of common frequencies for the Fast clock ( sse the datasheet )
RS232 level translation and a Terminal program.
There is also at least one eight bit port that can be used for general purpose I/O, vectored-interrupts ( which are really handy ) and 8 timers.
If you are at least familiar with 65xx coding have a look, it may be just
what you need.
Good Luck in your searching, Wally
-
GARTHWILSON
- Forum Moderator
- Posts: 8773
- Joined: 30 Aug 2002
- Location: Southern California
- Contact:
> It's already established that the 6522 can't quite do SPI.
It is the 6522's shift register that is not quite SPI-compatible. Doing SPI by bit-banging on the 6522 is very easy though. I've done it many times. Granted, you won't be able to do 10Mb/s, but bit-banging SPI is not a pain like bit-banging RS-232 is. The latter has very stringent timing requirements, whereas SPI does not.
> But what about using the 6522's shift register to do
> synchronous serial transfers to an AVR?
The one possible problem I can think of is the 6522's bug if the shift clock is not generated by the 6522 itself. If the 6522 supplies the shift clock, there's no problem. If both ends of the communications line are intelligent though (meaning there's a computer at each end, instead of one end just being a 74HCxxx shift register for example), then it's usually better to have the sending party generate the clock. To avoid the occasional dropped bits at the 6522 receiving end, you need a flip-flop clocked by phase 2. Beyond the inconvenience of adding an IC (or half of one, since the flip-flops come two to a package), the problem is that you need a way to bypass the flip-flop when you want the data to go the other direction. It's not hard, but takes more parts. It's ideal if you can spare the shift registers of two 6522's, so one can be output-only and the other one input-only, at least as far as communicating with intelligent peripherals goes. (You can still multiplex many devices on one port by using addressing.) I've used the VIA's CA2 for strobing, as a handshake line to tell the transmitting end that it's ok to send the next byte.
With the two-VIA approach, you can have a long loop of intelligent peripherals connected with just the two ports. The software sends the info out on the loop as to which loop device a particular message is intended for. As it arrives at each device, the device acts on it if appropriate, otherwise just passes it on to the next device on the loop. Even the device a message was intended for can continue passing the message along so the sender receives it again to check it against the original to make sure it did not get corrupted. (Actually I'm getting carried away here, starting to describe HP-IL operation. HP-IL, short for Hewlett-Packard Interface Loop, was basically a serial implementation of IEEE-488, except that the serial aspect enabled some significant advantages, like auto-addressing, galvanic isolation, the elimination of fan-out problems, etc.. A port had two thin, two-conductor cords, one out and one in, and could be used in a loop of over 900 devices, at least one of which was capable of acting as loop controller. Devices on the loop could include various instrumentation, printers, mass-storage devices, interface converters to other interfaces, etc..) To do this kind of thing with VIAs, you'd need at least four conductors in the cord: clock, data, strobe, and ground.
It is the 6522's shift register that is not quite SPI-compatible. Doing SPI by bit-banging on the 6522 is very easy though. I've done it many times. Granted, you won't be able to do 10Mb/s, but bit-banging SPI is not a pain like bit-banging RS-232 is. The latter has very stringent timing requirements, whereas SPI does not.
> But what about using the 6522's shift register to do
> synchronous serial transfers to an AVR?
The one possible problem I can think of is the 6522's bug if the shift clock is not generated by the 6522 itself. If the 6522 supplies the shift clock, there's no problem. If both ends of the communications line are intelligent though (meaning there's a computer at each end, instead of one end just being a 74HCxxx shift register for example), then it's usually better to have the sending party generate the clock. To avoid the occasional dropped bits at the 6522 receiving end, you need a flip-flop clocked by phase 2. Beyond the inconvenience of adding an IC (or half of one, since the flip-flops come two to a package), the problem is that you need a way to bypass the flip-flop when you want the data to go the other direction. It's not hard, but takes more parts. It's ideal if you can spare the shift registers of two 6522's, so one can be output-only and the other one input-only, at least as far as communicating with intelligent peripherals goes. (You can still multiplex many devices on one port by using addressing.) I've used the VIA's CA2 for strobing, as a handshake line to tell the transmitting end that it's ok to send the next byte.
With the two-VIA approach, you can have a long loop of intelligent peripherals connected with just the two ports. The software sends the info out on the loop as to which loop device a particular message is intended for. As it arrives at each device, the device acts on it if appropriate, otherwise just passes it on to the next device on the loop. Even the device a message was intended for can continue passing the message along so the sender receives it again to check it against the original to make sure it did not get corrupted. (Actually I'm getting carried away here, starting to describe HP-IL operation. HP-IL, short for Hewlett-Packard Interface Loop, was basically a serial implementation of IEEE-488, except that the serial aspect enabled some significant advantages, like auto-addressing, galvanic isolation, the elimination of fan-out problems, etc.. A port had two thin, two-conductor cords, one out and one in, and could be used in a loop of over 900 devices, at least one of which was capable of acting as loop controller. Devices on the loop could include various instrumentation, printers, mass-storage devices, interface converters to other interfaces, etc..) To do this kind of thing with VIAs, you'd need at least four conductors in the cord: clock, data, strobe, and ground.
-
GARTHWILSON
- Forum Moderator
- Posts: 8773
- Joined: 30 Aug 2002
- Location: Southern California
- Contact:
All 6522's have this bug-- even WDC's. Regardless of how simple or complex your scheme is, the problem will show up if (and only if) the serial clock edges can occur within certain windows with relation to the 6522's phase-2 edges. IOW, if the serial clock is asynchronous WRT phase 2 (as it would be if another system is generating it), you'll have problems. If the 6522 is generating (outputting) the serial clock, that 6522 will never have a problem, regardless of data direction, speed, etc..
I was doing some sketchwork for a 65816 machine and had a thought...
Apple used the Z8530 serial chip for the Mac. It looks like it might have some good usages in a 6502 context, or maybe the Z85230... It's available at high speeds, can be used as a memory mapped peripheral, and seems to be able to be attatched with relatively small amounts of glue logic.
Just as an alternative to the 16550.
Apple used the Z8530 serial chip for the Mac. It looks like it might have some good usages in a 6502 context, or maybe the Z85230... It's available at high speeds, can be used as a memory mapped peripheral, and seems to be able to be attatched with relatively small amounts of glue logic.
Just as an alternative to the 16550.