6502.org Forum Projects Code Documents Tools Forum
It is currently Sat Apr 27, 2024 4:44 pm

View unanswered posts | View active topics


Board index » 6502.org Users Forum » Hardware

All times are UTC




Post new topic Reply to topic  Page 5 of 7
  [ 102 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7  Next
  Previous topic | Next topic 
Author Message
schidester
PostPosted: Sun Apr 15, 2012 9:14 pm 
Offline

Joined: Wed Sep 04, 2002 4:08 pm
Posts: 57
Location: Iowa
I don't know if you're still on this project, but I've got an SBC that uses a 6850 to talk to a PC at 9600 baud described here:

http://chidesters.org/scott/meadow/Mead ... r_Doc.html
Top
 Profile  
Reply with quote  
Dajgoro
PostPosted: Mon Apr 16, 2012 12:43 am 
Offline
User avatar

Joined: Mon Aug 08, 2011 2:48 pm
Posts: 808
Location: Croatia
I successfully integrated the mc6850 into my sbc, and it works, i recently quired 3 ceramic gold MC68B50, so now i have a total of 5 mc6850. If somebody needs one, contact me.
Top
 Profile  
Reply with quote  
GARTHWILSON
PostPosted: Tue Apr 17, 2012 8:02 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8428
Location: Southern California
From page 3:
Quote:
I know that rs232 is usually associated with uart, anyway what is the difference between acia and uart?

I just stumbled on this on page 65 of the book "Advanced 6502 Interfacing" by John M. Holland, ©1982, that UARTs can be used without a computer, unlike the ACIA.  That might explain the UAT (universal asynchronous transmitter) of a Telex machine I remember seeing a secretary using with paper tape in 1983 and a UAR (universal asynchronous receiver) I think the news feed at the radio station where I was working in 1981 had, where there was no computer in the room AFAIK.  The UAR fed the typing machine directly.

_________________
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?
Top
 Profile  
Reply with quote  
fachat
PostPosted: Tue Apr 17, 2012 8:40 pm 
Offline

Joined: Tue Jul 05, 2005 7:08 pm
Posts: 990
Location: near Heidelberg, Germany
GARTHWILSON wrote:
From page 3:
Quote:
I know that rs232 is usually associated with uart, anyway what is the difference between acia and uart?

I just stumbled on this on page 65 of the book "Advanced 6502 Interfacing" by John M. Holland, ©1982, that UARTs can be used without a computer, unlike the ACIA.


That may have been the case before. However, I doubt the 8250/165x0 UARTs can be used without a computer. It's just a name now

André

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/
Top
 Profile  
Reply with quote  
MichaelA
PostPosted: Tue Apr 17, 2012 9:36 pm 
Offline

Joined: Thu Mar 15, 2012 4:00 am
Posts: 5
I'm not sure there's a significant distinction between UART and ACIA.

Companies like MOS Technology, Motorola, Intel, etc. generally moved toward a business model of providing bus-compatible I/O components in order to simplify the design of systems based on their microprocessor offerings. In the process, the UARTs which preceded the 6551, 6850, 8251, etc. were supplanted. One such device, the General Instrument AY-3-1015, could easily be used without a computer because it provided separate receive and transmit data busses, and it also provided a separate status register output. Because they could be adapted to any bus structure, if my recollections are correct, the multi-channel Serial I/O board (and the console UART) in my mid-80's DEC PDP11/24 minicomputer used these UARTs.

The problem of using the 6551 and 6851 in a processor-free configuration is primarily a result of their synchronous bus interface. A Finite State Machine (FSM) in a simple CPLD can be be used to control the bus signals and bus timing in order to use the device in a processor-free application. Polling of the status register will add complexity to the FSM, but should not be particularly difficult to implement.

However, an asynchronous receiver (with a limited number of baud rates) can easily be implemented in a fashion similar to the AY-3-1015 UART in an inexpensive CPLD such as the XC95xxx-series from Xilinx. The block diagram and datasheet for the AY-3-1015 UART can be found in the GI subdirectory of bitsavers.org PDF archives.
Top
 Profile  
Reply with quote  
scotws
PostPosted: Fri Feb 15, 2013 7:41 pm 
Offline

Joined: Mon Jan 07, 2013 2:42 pm
Posts: 576
Location: Just outside Berlin, Germany
If I may revive this thread -- the ACIA 6551 seems to be becoming hard to find (at least in Germany): It's not in the German Mouser catalogue anymore, and on Jameco not in the WDC variant, let alone any other stores here. Add to that a certain memorable statement by BDD in a different thread ("I wouldn't use it as a paper weight, let alone a UART"), I'm sort of looking around for an alternative to connect a host computer (MacBook with USB-to-serial adapter) to my SBC without special hardware (except of course for the adapter). All the two computers need to be able to do is get a terminal running (I figure I'll get fancy on the second computer) -- typing speed will be good enough for now.

Given that, the chips discussed here such as NXP-2692A seem viable, but also complete overkill (the NXP has 40 pins and two UARTS). I'd consider bit-banging something through a 65c22, but Garth tells me not to do that (http://wilsonminesco.com/RS-232/RS-232primer.html). Is there anything out of the box I'm missing, or should I just go with, say, the NXP and ignore the stuff I don't need? Seems like a waste of good silicon ...
Top
 Profile  
Reply with quote  
GARTHWILSON
PostPosted: Fri Feb 15, 2013 8:44 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8428
Location: Southern California
See our sticky topic 65xx parts sources.  That should help.  We want to keep this up to date, so if you find anything that's not, please notify us.

Just re-hashing, the NMOS 6551 had bugs that have been fixed in the CMOS one.  The only thing I don't like about it is that a couple of controls which should have been separate were merged into one bit.  Aside from that though, I've been using the 65c51 for 20+ years and never had a problem with it (except when I neglected to put the capacitors on the crystal connections).  Everything I've ever tried to do with it worked the first time.  It's nice that it has the baud-rate generator onboard, but also that you're not obligated to use it, as for example I've use the 65c51 for MIDI which runs at 31.25kbps.

You mentioned bit-banging, and no, I don't recommend bit-banging RS-232, but SPI is very easy to bit-bang and useful for a lot of things besides a small (14-pin DIP) MAX3100 UART which has SPI.  Daryl offers his 65SPI chip too, which will be faster and reduce the software load.

_________________
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?
Top
 Profile  
Reply with quote  
BigDumbDinosaur
PostPosted: Sat Feb 16, 2013 2:47 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8144
Location: Midwestern USA
scotws wrote:
If I may revive this thread -- the ACIA 6551 seems to be becoming hard to find (at least in Germany)...

The USA Mouser catalog doesn't list the W65C51S (the WDC version) as well, so that seems to be a dead end. Digi-Key at one time carried the WDC product line but apparently has dropped it. This availability issue has been ongoing with this part.

Quote:
Given that, the chips discussed here such as NXP-2692A seem viable, but also complete overkill (the NXP has 40 pins and two UARTS). I'd consider bit-banging something through a 65c22, but Garth tells me not to do that (http://wilsonminesco.com/RS-232/RS-232primer.html).

One of several problems associated with bit-banging TIA-232 on a 65C22 is the flood of interrupts that the MPU will have to process. You'll get an interrupt for each bit sent and each bit received, which will mean a surprisingly large amount of MPU cycles will be consumed in doing what a real UART does in the background. Timing will be another issue. You'd have to use the timer-counter in the 'C22 to act as a baud rate clock generator, which means you have to have a table of timer-counter setup values to correspond with the baud rates you intend to implement. The timer-counter is driven by the Ø2 clock, which means if you change the Ø2 frequency, your setup values likewise have to change. Your driver code would have to know about start and stop bits, framing errors, parity errors (if parity is required), etc. What about implementing hardware handshaking? It goes on and on. Writing something that can do all that is tedious and error-prone (vidi the C-64 and C-128 fake RS-232 routines, which have problems galore). It's for those reasons that UARTs were developed.

Quote:
Is there anything out of the box I'm missing, or should I just go with, say, the NXP and ignore the stuff I don't need? Seems like a waste of good silicon ...

Your main problem, aside from availability, is finding something that will run with the 65C02 at the elevated Ø2 clock rates the MPU supports. You could try the MC6850, which is old silicon (1970s vintage) and not capable of running at higher Ø2 rates without wait-stating (which you don't want to get involved with in a first design). There's the 16550, widely used in PC hardware, but as André Fachat would point out, that part is somewhat cantankerous to work with.

Despite its dual channels, the 2692 (or the 26C92) is inexpensive, is in current production and is relatively easy to interface to the 65C02 bus. The 2692 is fast enough to obviate the need for wait-stating up to 12.5 MHz and supports all standard baud rates up to 38.4 KBPS, plus extended rates to 115.2 KBPS. A proven 65xx driver algorithm already exists for it. You may discover after considering everything that the dual channels are useful and worth incorporating into your design, one to drive some sort of console and the other to act as a data channel for interfacing to another system.

Incidentally, the 2692 is available in PLCC44, which consumes about 60 percent of the board real estate taken up by the PDIP40 version.

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


Last edited by BigDumbDinosaur on Sat Feb 16, 2013 9:18 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
GARTHWILSON
PostPosted: Sat Feb 16, 2013 3:22 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8428
Location: Southern California
BigDumbDinosaur wrote:
scotws wrote:
Given that, the chips discussed here such as NXP-2692A seem viable, but also complete overkill (the NXP has 40 pins and two UARTS). I'd consider bit-banging something through a 65c22, but Garth tells me not to do that (http://wilsonminesco.com/RS-232/RS-232primer.html).

One of several problems associated with bit-banging TIA-232 on a 65C22 is the flood of interrupts that the MPU will have to process.  You'll get an interrupt for each bit sent and each bit received, which will mean a surprisingly large amount of MPU cycles will be consumed in doing what a real UART does in the background.  Timing will be another issue.  You'd have to use the timer-counter in the 'C22 to act as a baud rate clock generator, which means you have to have a table of timer-counter setup values to correspond with the baud rates you intend to implement.  The timer-counter is driven by the Ø2 clock, which means if you change the Ø2 frequency, your setup values likewise have to change.  Your driver code would have to know about start and stop bits, framing errors, parity errors (if parity is required), etc.  What about implementing hardware handshaking?  It goes on and on.  Writing something that can do all that is tedious and error-prone (vidi the C-64 and C-128 fake RS-232 routines, which have problems galore).  It's for those reasons that UARTs were developed.

I find it surprising that Commodore didn't put a UART in those machines.  There was a topic a year ago about a 57kbps bit-bang on a 1MHz 6502 (without interrupts—only carefully counting cycles in a loop) at viewtopic.php?f=2&t=2063.  The fact that it could be done at all is impressive; but it still keeps the processor from being able to handle interrupts or do anything else at all.  It takes its full, undivided attention.  OTOH, even if you do bit-bang SPI to talk to a hardware UART, the timing of the 6502 software becomes a non-issue, and you can even interrupt the sending or receiving of random individual SPI bits without causing problems, letting the UART continue doing its job while the processor is away doing something else here and there.

_________________
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?
Top
 Profile  
Reply with quote  
scotws
PostPosted: Sat Feb 16, 2013 9:21 pm 
Offline

Joined: Mon Jan 07, 2013 2:42 pm
Posts: 576
Location: Just outside Berlin, Germany
BigDumbDinosaur wrote:
You may discover after considering everything that the dual channels are useful and worth incorporating into your design, one to drive some sort of console and the other to act as a data channel for interfacing to another system.


This sounds suspiciously like the electronic version of mission creep :-). Thanks, I'll put the NXP data sheet under my pillow for a while and think about it. Bit banging would definitely seem to be out of the question.

BigDumbDinosaur wrote:
Incidentally, the 2692 is available in PLCC44, which consumes about 60 percent of the board real estate taken up by the PDIP40 version.


But will it wire wrap? Haven't seen the sockets in that form yet with those long pins.
Top
 Profile  
Reply with quote  
GARTHWILSON
PostPosted: Sat Feb 16, 2013 9:40 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8428
Location: Southern California
Quote:
BigDumbDinosaur wrote:
Incidentally, the 2692 is available in PLCC44, which consumes about 60 percent of the board real estate taken up by the PDIP40 version.

But will it wire wrap? Haven't seen the sockets in that form yet with those long pins.

Yes.
Attachment:
WW_PLCC_44.jpg
WW_PLCC_44.jpg [ 13.3 KiB | Viewed 1303 times ]

WW PLCC sockets have been hard to find (and always very expensive!) but Ed recently posted links to RS and Allied:
http://uk.rs-online.com/web/c/?searchTe ... ra=oss&r=t
http://www.alliedelec.com/search/search ... archType=0
(and yes, they're still super expensive, but still sometimes worth it.)

_________________
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?
Top
 Profile  
Reply with quote  
BigDumbDinosaur
PostPosted: Sat Feb 16, 2013 9:48 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8144
Location: Midwestern USA
GARTHWILSON wrote:
I find it surprising that Commodore didn't put a UART in those machines.

The generally accepted rationale was that a 6551, along with the requisite line drivers (1488 and 1489) added cost to a cost-sensitive design, not to mention the cost of adding a suitable receptacle (DB25 in those days). Evidently the cost of having someone write 6551 emulation into the kernel was lower than the hardware cost of a real 6551 plus the cost of kernel drivers, the latter of course, being much less complicated than the error-prone 6551 emulation.

Quote:
There was a topic a year ago about a 57kbps bit-bang on a 1MHz 6502 (without interrupts-- only carefully counting cycles in a loop) at viewtopic.php?f=2&t=2063. The fact that it could be done at all is impressive; but it still keeps the processor from being able to handle interrupts or do anything else at all. It takes its full, undivided attention.

In one of the last issues of Transactor magazine, George Hug wrote an interesting article on addressing the shortcomings of the 6551 emulation in the C-64 and C-128, and in the process, focused on what was at the time a relatively obscure errata in the 6526 complex interface adapter (CIA). Hug brought up the fact that the C-64 and C-128 6551 emulations were copied almost verbatim from the VIC-20, which used the 6522 versatile interface adapter (VIA) instead of the more technically advanced CIA. As the emulation was not modified to take advantage of the more enhanced timer features of the CIA, code was being executed to do in software what the CIA could be made to do in hardware.

The errata had to do with interrogating the CIA's interrupt status register (ISR) one or two Ø2 cycles before a timer-B interrupt was scheduled to hit. If that were to happen, the CIA might not interrupt the MPU when timer-B underflowed. As timer-B was the controlling time source for received data, incoming bits could be dropped, causing framing errors. It was conceivable during CBAT that a timer-A interrupt could occur immediately before one from timer-B did, which meant that the interrupt service routine would read the ISR at the critical moment when the loss of the timer-B interrupt could occur. Not helping matters was that the CIA doing the 6551 emulation I/O was tied to NMI. As NMIs cannot be stacked, even if the timer-B ISR bug didn't occur, a second NMI while servicing of the first one was pending would be missed.

Hug's solution to the errata was to query the value of timer-B before and after servicing a timer-A interrupt. If the (16 bit) value in timer-B's registers was higher after servicing timer-A than before, then a time-B interrupt had been missed and special-case code executed the time-B interrupt handler before returning. That along with refinements to the code that took advantage of the CIA capabilities, allowed to Hug to run his C-64 at an error-free 2400 BPS, previously impossible even on a C-128 running in FAST mode (2 MHz).

The point to this story is that even at a relatively sedate pace of 2400 BPS, bit-banging serial I/O is very costly in clock cycles, and difficult to do without error.

Quote:
OTOH, even if you do bit-bang SPI to talk to a hardware UART, the timing of the 6502 software becomes a non-issue, and you can even interrupt the sending or receiving of random individual SPI bits without causing problems, letting the UART continue doing its job while the processor is away doing something else here and there.

That said, incorporating a UART into one's design is the best way to get TIA-232. Despite its age, TIA-232 is the closest thing we have to a "universal" communications protocol. It can be supported on a PC (even one that doesn't have an embedded serial port), is widely supported on many different types of hardware and can be made to operate over long distances without error. I've said this before, but those who keep pushing USB really need to look at the technical reasons why TIA-232 is still around. I suspect that it will be around well after I've departed this life and have been set adrift amongst the asteroids. :D

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
BigDumbDinosaur
PostPosted: Sat Feb 16, 2013 10:08 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8144
Location: Midwestern USA
scotws wrote:
BigDumbDinosaur wrote:
You may discover after considering everything that the dual channels are useful and worth incorporating into your design, one to drive some sort of console and the other to act as a data channel for interfacing to another system.

This sounds suspiciously like the electronic version of mission creep :-).

Not at all. You always want a little extra capability even in a first design. I designed my POC V1 unit so the RTC socket could double as an "expansion port." At the time (2009) when I was detailing the design, I had no immediate use for such a feature. However, after I got the unit satisfactorily working, I decided to try adding a SCSI port. The solution was to build a host adapter that would plug into the RTC socket, with the RTC relocated to the host adapter. The decision to engage in a little bit of "mission creep" proved to be prescient.

Quote:
Thanks, I'll put the NXP data sheet under my pillow for a while and think about it. Bit banging would definitely seem to be out of the question.

As i early said, a proven algorithm for driving the 2692 exists—it's running both serial ports on my POC unit and can simultaneously do so at 115.2 Kbps. If you do decided to use the 2692 purchase the more advanced 26C92. The cost difference between the two is negligible and basic programming techniques are identical.

Quote:
BigDumbDinosaur wrote:
Incidentally, the 2692 is available in PLCC44, which consumes about 60 percent of the board real estate taken up by the PDIP40 version.

But will it wire wrap? Haven't seen the sockets in that form yet with those long pins.

See Garth's above reply. Also found:

    CGN 2001-44

    44 pin PLCC socket.

    Physical Dimensions:1.350" x 1.350" x .950"
    Price: $9.40

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
GARTHWILSON
PostPosted: Sat Feb 16, 2013 10:16 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8428
Location: Southern California
TIA-232 (RS-232, EIA-232, etc. over the years) has been around about 50 years and is still being used in industrial settings (and in my office!).  Consumer computing things don't last nearly so long.

I mentioned the multiple-interrupt-cause scenario in my tips at viewtopic.php?f=7&t=342
Quote:
Tip of the day, #14

When servicing 6551 ACIA interrupts for simultaneous transmission and reception, remember that reading the status register clears the interrupt, but the interrupt could have been caused by both TX register empty and RX register full at the same time.  If your ISR ends before finding all the interrupt causes, it may, for example, find the receive register full, service that, and then exit thinking it's done, when in actuality the transmit register emptied before you read the status register and it's waiting for the next byte.  Now the IRQ line is false and the issue will never be addressed, and transmission will come to a halt.  If more than one thing in the same IC could need service, make sure the ISR doesn't stop before the whole job is done.


Quote:
This sounds suspiciously like the electronic version of mission creep  :) .

There's a difference between:
  1. feature creep that advances faster than you can build and keeps you from completing a project, and
  2. designing a system that can be expanded later if necessary, not painting you into a corner so you can't expand it without starting over or at least re-doing a lot of work.

It takes a lot of experience to identify the line that divides the two.  It's not easy.

_________________
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?
Top
 Profile  
Reply with quote  
clockpulse
PostPosted: Sat Feb 16, 2013 10:58 pm 
Offline

Joined: Sat Oct 20, 2012 8:41 pm
Posts: 87
Location: San Diego
Here is a 40 pin 26C92 version if desired -->here

You can still buy in single quan. 'special at this time', but keep in mind they change the minimums at any time.
Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  Page 5 of 7
  [ 102 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7  Next

Board index » 6502.org Users Forum » Hardware

All times are UTC


Who is online

Users browsing this forum: Google [Bot] and 35 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
6502.org is an ongoing project by Mike Naberezny and contributors.