On the ACIA you mentioned, I really wouldn't use that part.
It's somewhat infamous around here for having a bug in it that makes it (in my opinion) very onerous to use. More info here: WDC 65C51 chips defective and here: UARTs: REPLACING THE 65C51.

I settled on the 28L92 for my design. It's easy enough to adapt to the 6502 bus. Mind you, there is nothing stopping you using the 6551 ACIA if you so desire.

On the subject of cartridges, I would use some kind of serial interface. The cartridges are made smaller, and multiple devices can still be packed into the one cartridge. SPI-10 might be a good starting point for the connector, although you may wish to add some extra select lines for extra devices, if that is something you think you might do.

On the subject of cartridges, I would use some kind of serial interface. The cartridges are made smaller, and multiple devices can still be packed into the one cartridge. SPI-10 might be a good starting point for the connector, although you may wish to add some extra select lines for extra devices, if that is something you think you might do.

The 65c22 can also count pulses on PB6, or automatically output a square wave of programmable period on PB7, which I've used for example to provide the 500kHz x16 clock input for the '51 to do MIDI at 31.25kbps. I've used the 65c22's synchronous-serial port in different ways for many different projects. The CA and CB pins can be used as interrupt-on-change and for automatic handshaking, as well as just general output bits. When bit-banging I²C, I have the '22 emulate the required open-drain ports (which is totally impractical on the '20/'21 PIA). The '22 has several capabilities there that I think keep getting overlooked.

As far as the ACIA goes, Garth told me about the bug, that the transmit register appears to always be empty, and he showed me a way around it. I'm open to other chips though, I just figured sticking with 65 series chips would keep it simple. I'll definitely look into the 28L92 though

I use the ACIA in my own SBC (The Potpourri6502). I *WILL* eventually switch to the 28L92. But at the moment, the ACIA is easier to get going....for me.

I will say this...for the longest time I could not get the ACIA to work. At all. Nothing I did. I followed (what I thought) was every example I could find and they all seemed to use a crystal and some resistors/caps for the clock. And I'm sure people got that to work. But for whatever reason, it never worked for me. And I still don't know why.

I even tried using my frequency generator and typing the 1.8432 MHz (IIRC). Nothing. Even hooked up my scope and confirmed the clock (although, I did see it fluctuate sometimes...probably the issue).

So one day, I decided to do something different. I bought a 1.8432 MHz half-can oscillator and connected it directly to the ACIA and guess what? It worked first time. Using the same code.

I obviously did something wrong with the crystal setup. But heck if I know what it was. Maybe it was my crappy breadboard. After I got the oscillator setup working, I haven't been motivated to switch to the 28L92 (at least, not yet). Keep in mind, my needs are very simple.

Anyway...just my $0.02 on the ACIA.

BTW, I see you're from Knoxville. I'm from Hixson (Chattanooga). Nice to know another 6502 user is not that far away.

Ultimately, I know that I'm giong to need some parralell interface busses for things like the display, so I'm going to need a ViA or similar to drive those since I don't want them on the CPU busses.

As far as I2C goes, it was actually the first serial communication I worked with in a project, and I do like the setup for it, my problem is that after working with SPI and similar, many people have told me that I2C should no longer be used, because of its susceptibility to noise and complexity in debugging if it does end up having a problem.

A lot of them aren't fast enough to put directly on the bus anyway.


I've never had any problem with noise on I²C, nor have I ever heard of such a problem. I have never had a bit error either. I²C and SPI have different uses though. I²C is good for where the number of connections really needs to be minimized (without going to the extreme of 1-Wire); the larger memories use SPI though because of the big difference in speed. It would not be practical to transfer a large file by I²C. It would just take too long.

I'll see if I can find the thread about I2C I read a while back about weird errors on Arduino with it, it's something to keep in mind, but I don't think it occurs much with small wires or if it's on the same PCB as what it's talking to, only if there's long wires involved or weird designs that introduce too much capacitance, or cannot drive the lines high fast enough.

Even short wires can cause grief with I2C if there's some strong interference nearby, such as PWM controlled fans, or a switch mode power supply.

and....well let me not quote your primer here about capacitance due to open drain design keeping it from being fast.

A minor correction on what DerTrueForce said. If you use Garth's SIMM you will be working with SRAM that generates TTL-level outputs. Therefore, your bus driver should be a 74ACT245 or 74AHCT245 (note that the 74ACT245 is slightly faster than the AHCT equivalent, which isn't necessarily a good thing). The bank bits latch should be a 74AC573, as TTL-compatible inputs are neither necessary or desirable.


You're thinking of the 74AC563, whose Qs are the complements of the matching Ds.


If you correctly generate your /OE and /WE signals you should not see bus contention. Here's an example of a circuit for generating said signals.


The above circuit is what I use in my POC units. /OE and /WD cannot go low until after the rise of Ø2 (PHI2), at which time the '816 will cease driving bank bits onto D0-D7 and will switch to data mode. The prop delay in the above logic, added to the time required for the addressed device to respond to /OE or /WE will give the '816 some turn-around headroom. Understand that the state of RWB will have been set by the MPU before Ø2 goes high, so the time from the rise of Ø2 to when /OE or /WE will be driven low will be the prop time of the 74AC00, typically around 4-5 nanoseconds on 5 volts. If you want to increase that lag you could use the 74HC00, whose tPD averages around 8-9 ns on 5 volts. Incidentally, it may come as a surprise to learn that the timing of /OE and /WE is not critical. As long as these signals are generated soon enough to meet the requirements of the slowest device at the highest Ø2 rate you plan to use it will all work.

Incidentally, if you use any 65xx I/O silicon, such as the 65C22, be aware that all control inputs must be set up before the rise of Ø2. These devices "understand" the 6502 bus cycle and will not attempt to get on the data bus while Ø2 is low. If you don't observe this requirement the device will not work.

Lastly, be aware of the 65C816's VDA and VPA outputs. At certain times during an instruction cycle the address bus could be in an indeterminate state. In some cases, that can result in improper selection and addressing of devices, which may cause some devices to malfunction. The NXP 26, 26C and 28L (mentioned below) series of UARTs is are such examples, the NCR/AMD/Buslogic 53CF94 SCSI controller is another one...

The general rule is if the expression VDA || VPA is false (|| meaning logical OR) the address bus may be in an indeterminate state and no chip selects should be generated. This can happen during Ø2 high and may result in the '816 "touching" something it shouldn't.

<Cue a comment from Ed about VDA and VPA not being necessary. >


I also recommend you stay away from the 65C51. Aside from it basically being a primitive 1970s vintage UART, it has a pernicious (in the archaic sense) hardware bug that prevents the use of PIO or IRQ-driven transmission. It's quite clear from recent revisions to the 65C51 data sheet that WDC has no plans to fix this part. If you use something like an NXP 28L92, as DerTrueForce suggested, you will get two high speed TIA-232 channels in one package, plus some programmable input and output pins, and as a bonus, a precision counter/timer (C/T) that has sub-microsecond resolution. My POC V1.1 unit uses the 28L92's C/T to generate a 100 Hz jiffy IRQ that ultimately is the time base for a software uptime counter, software time-of-day "register" and a software delay timer function. See the below attached on how to interface the 28L92 to your 65C816 system.


The problem with using a VIA timer for system timekeeping is said timer is usually slaved to the Ø2 clock and therefore will change speed if the Ø2 rate is also changed. That would mean you'd have to make changes to your timekeeping code in order to maintain accuracy should you decide to change the Ø2 rate. That won't be the case with using the 28L92's C/T, as it can be driven by the 3.6864 MHz X1 clock used by the 'L92 to generate bit rates.

I've heard that the 16550 is painful from a software perspective; that's something you gradually come to expect in PC-standard hardware. It's remained popular chiefly because it's "industry standard", ie. was used in PCs.

I think the 28L92 is also available in PDIP, and it's definitely well documented for interfacing with the 6502 family. It takes slightly more work to set up than the 6551, but it's straightforward overall.