65XX SBC general help and color display help needed

[GARTHWILSON]

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.

[backspace119]

DerTrueForce wrote:

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.

Serial is probably the way to go, since it's just data it has to load (having 52k flat ram early in the map and 4M flat ram in the 24 bit extension will allow me to load just about anything I want)

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

[GARTHWILSON]

DerTrueForce wrote:

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.

SPI-10 is intended for one plug to handle one device, although several plugs can have all the pins in common except the select line. VDD, ground, Clock, MISO, MOSI, IRQ\, RST\, and Aux can all be bused from one SPI-10 plug to another. The only thing that cannot be bused among connectors is the SS\ (slave-select-not) line. The AUX pin's function can be individual to each module. If you wanted to use the AUX pin to select which of two devices on one module gets selected when the SS\ goes low, you can do that.

SPI-10 is really for small modules though, similar to SD cards, but can be for lots of things besides memory. We also have the 65SIB (6502.org Serial Interface Bus) which allows lots of devices out on one bus, daisychained off of one connector (using ribbon cable), with automatic assignment of addresses. It is SPI compatible but more flexible. Typical uses would be larger external things. I have a graphics LCD on one for example, something which, because of its size and weight, you wouldn't expect a small connector to support mechanically.

[backspace119]

GARTHWILSON wrote:

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.

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.

Of course, these people were working with Arduinos, where the libraries are expected to take care of problems, but they don't for I2C (if a bit is lost in transmission the interface will completely cease operation until you bit bang the bit out of it and restart the transmission)

[cbmeeks]

backspace119 wrote:

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.

[backspace119]

cbmeeks wrote:

backspace119 wrote:

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.

There are dozens of us. DOZENS!

In all seriousness though, that's sort of my idea about the ACIA, it's well documented and has been used forever, but if the 28l92 has good offerings, I may end up just using it. From googling, I've found the 28L202, but not the 28L92 (other than on ebay and a few datasheets). I see the 202 is duart, and I'm wondering if this is something I should bother with looking to implement.

[GARTHWILSON]

backspace119 wrote:

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.

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

Quote:

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.

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.

[Arlet]

I2C is very susceptible to noise because of the high impedance '1'. I've had problems in several applications, even with careful layout of I2C traces. I'll take SPI any time.

[backspace119]

GARTHWILSON wrote:

backspace119 wrote:

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.

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

Quote:

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.

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.

Right, because original I2C spec was something like 400Khz, and....well let me not quote your primer here about capacitance due to open drain design keeping it from being fast.

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.

On an unrelated note I'm working on drawing the case before I put it in SolidWorks, and a thought has struck me.

I'm thinking about making it look a bit like the atari 2600, and having a thin display that's built in on the back "lip". Then I can have a port to connect a bigger display (for running basic terminal and all that) and eventually composite out for connection to a color display (which may be a module that connects to the machine. This seems like a lot of displays though, and I'm a bit worried about interfacing all of them.

Also, I've not thought about audio in a while, and I think I need to re-evaluate that situation now that I have some designs going.

Another thing, I'm thinking about using a normal C-15 AC power connector, and making my own PSU circuit (don't want to use ATX because of space constraints) Would a wall wart be a better approach? or should I try and make my own to ensure a clean supply.

Last thing, my printer can do 300x300x400mm prints (400 is vertical Z) so I'm trying to keep this at or below 200x200 (printing to the very edge causes warping usaully, it's better with my build surface, but still present). Do you think it's possible to fit all this in a board as small as 150x150?

[Arlet]

Quote:

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.

[backspace119]

Arlet wrote:

Quote:

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.

Noted, I think if I use I2C at all it will be for things on board that I can isolate as much as possible. Most devices these days tend to have counterparts in SPI though, the only issue being you need SS line for each slave (or you can do some cheeky bastard stuff like I did on my monsterous IO expander board, which used 7 lines from an arduino and turned them into 1,024 GPIO pins, but then again, it relied on the particular chips I used, which had an addressing mode with SPI, since the original chips were I2C and I guess they didn't want to remove it, so you could have 8 of them on the same SS line and the first transfer would be the address of the device you wanted to talk to, like I2C)

[GARTHWILSON]

backspace119 wrote:

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

The time constant in the rising edge is the capacitance times the pull-up resistance. Situations with totem-pole outputs like SPI has will have a very low resistance, making the time constant very short, hence the higher speed. There's a way to improve on I²C's resistance though. You can pull it up faster without increasing the current in the logic-low state, by replacing the pull-up resistor with a current source like NXP's BCM62B PNP/PNP matched double transistor being used as a current mirror. Others are the BCM856, BCM857, PMP5201, and PMP5501. (Thanks to Dr Jefyll for finding these.) If the I²C clock line (not just the data line) also has a passive pull-up (rather than a totem-pole type), the master can watch for when the line is a valid high before pulling it back down again, so that a high bus capacitance won't cause it to pull down again when it's still effectively low. If you implement the full I²C spec, that's part of it anyway, so a slow device can hold the clock line low as a method of asking for more time.

As for SMPSs, that is another reason to pay attention to good board layout practices like we discuss in the sticky topic "Techniques for reliable high-speed digital circuits." In my work, I have to be careful of this for a couple of reasons. One is that the digital is only there to control audio circuits including for high-quality music, and of course we can't afford to have digital noise or SMPS noise getting into it. The audio circuits are a lot more critical for that than I²C is. Another reason is that we can't be radiating noise from these that would interfere with the operation of the aircraft radios. I also have analog circuitry on my workbench computer and have done audio sampling many times; and I don't have any trouble with digital noise getting into that.

[backspace119]

BigDumbDinosaur wrote:

backspace119 wrote:

After studying the circuit in the docs, I've been looking at these two parts here and here

One's an AHCT 245 and the other is a ACT 573 (non inverting).

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.

Quote:

I'm working out the logic on it right now, I think I need the non inverting 573, but there's an inverting one too, so I'm working on figuring that part out since it doesn't mention it in the docs.

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

Quote:

Is there another part to this equation to make sure there's not bus contention?

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.

read_write_qualify_alt.gif

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

Quote:

I definitely want some io, planning on an acia...

DerTrueForce wrote:

On the ACIA you mentioned, I really wouldn't use that part...More info here: WDC 65C51 chips defective and here: UARTs: REPLACING THE 65C51.

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.

28l92_interfacing.pdf

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.

After reading through your thread on ACIA replacements, I'm considering going with the 16550 since it's available in DIP, although if I do end up just having this board made professionally it wouldn't really matter between the 28L92 or 16550, how hard is the 16550 to integrate? I intend on using it for RS-232 and possibly PS/2 (although I may go back to look at Grant's circuit on PS/2 again).

[Chromatix]

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.

[backspace119]

Chromatix wrote:

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.

If I can get the 28L92 in pdip it would be perfect. BigDumbDinosaurs thread seemed to suggest it's not available in pdip