Need a guideline for pin layout of CPU or I/O expansion bus.

[mkarcz]

Hello.
I am relatively new to this forum, please see my post in the Introduce Yourself section in General Discussions if you are not comfortable talking to a stranger .
Recently I started to build 6502 based general purpose microprocessor system or Homebrew Computer (I like this term more) just for the heck of it (and nostalgia is involved). More details about how am I going to assemble the system on the boards are here:
http://6502cpu.blogspot.com/2012/01/mkh ... -some.html
Can somebody please provide some expert advice about how I should lay out the pins on my CPU extension bus sockets and my I/O expansion ports sockets? Is there any recommended arrangement of pins? E.g.: if some pins should be neighbors, while some should be far apart and such kind of guidelines? I looked at the (in)famous S-100, but the pin out seems to be chosen at random on that bus.
Thank you in advance for your time.

[Nightmaretony]

Greets and welcome!

I personally like power at the far edges and keep the busses grouped together. For noise shielding, an entire row can be grounded, such as all the odd pins, making one side as ground. Might also want to put mroe grounds round a high speed clock to keep it from interfering with other lines, perhaps.

for my pinball mind, I am using the WDC RAM expander bus with some extra lines I need as a variation. (had pulled out more the R/W unqualified due to me wanting to use 65C22s beyond)

to look at the WDC one, look at their 65C02 development board and the schematic is on their website. westerndesigncenter.

Take a look, www.nightmarepark.com/6502.php the click on the pinball mind folder and get the schematic pdf in there.

[mkarcz]

Thank you for reply, I will certainly check these referenced materials. The tip with shielding clock pin is certainly a good one. I have 64 pins available on my bus, so I can spare quite many for ground shielding. I will need 16 address + 8 data + all control signals/clock plus my I/O decoder outputs (total of 8) plus IRQ input for CPU card slot ad output for other cards. Vectorized IRQ controller lines inputs will be going all to the I/O expansion bus, which has less pins (40) but I am not going to attach the whole address bus to it, just lower 8 bits. Each will have one input to vectorized IRQ controller and one from I/O decoder (chip select) plus CPU control signals. This leaves much less for shielding, but I think quite a few can be spared as well. I did not do the exact count yet.

[GARTHWILSON]

If you really must run the processor's own buses off the board, Tony's recommendation to make every other pin (ie, a whole row) a ground pin really is the best way to get signal integrity, and in fact is how it's done with ribbon cables that have to perform at high speeds too. One of the enemies of high-speed digital performance is inductance; and having the return right next to a signal line will minimize that. It also minimizes the antenna effect, for both transmitting and receiving unwanted noise.

To go a little less extreme, you can have every signal line be next to a ground or virtual ground (like Vcc that's bypassed to ground right at the connector), instead of having ground on both sides of each signal line. That way 2/3 of the lines can be signal lines, instead of only half. We have this on the select lines of our 65SIB (6502.org Serial Interface Bus) specification.

Next down would be to have no signal line more than say .2" from a ground or virtual ground. You'll find this on my small 32Mb 4Mx8 5V 10ns SRAM module (which I can provide). I could get away with it there because signals don't have to go very far.

When I last designed and built some automated test equipment (ATE) for our products, I used STD bus. It was a good solution at the time, but I don't think I would use it again at this stage. For one thing, STD bus would be impractical to try to interface to today's faster 6502/816. Also, there's less need for that type of bus today than there was back then. Take for example memory. At that time, if you wanted a megabyte of SRAM, battery-backed or not, it took a whole card. Now you can get more than that in a single IC socket on the CPU board, even in SRAM if you go with 3.3V. Back then, a disc-drive controller had to be on its own card also. Now, you can get far more storage in an SD card with the socket on the CPU board, or solder down a flash memory in a tiny SO-8 package. The same goes for so many other things. It is no longer necessary to go offboard for much of anything anymore, which is nice because taking the processor's own buses off the board brings a huge performance penalty unless you're happy limiting yourself to a couple of MHz.

What I advocate now after many more years of experience, as well as our now having a lot more SPI and I²C parts on the market, is not running the processor's own buses off the board at all (since that dramatically reduces the maximum speed), not even buffered, but instead have several interfaces on the CPU board including something like our 65SIB (linked above) that we devised here which extends SPI in several directions at once and makes it suitable for both internal and external equipment and peripherals, both intelligent and non-intelligent, and works for SPI, Microwire, and dumb shift register devices all simultaneously. Other interfaces on the CPU board might include LCD, printer, keyboard, I²C, Dallas' 1-Wire, etc..

I should add that in the ATE mentioned above (and pictured at the link), only four of the boards were actually on the STD bus, and the STD backplane was only about five inches long. The other cards were controlled through a synchronous serial interface from the 6522 serial port giving hundreds of bits of I/O.

You might be surprised how much I/O and other features you can do with few parts if you plan it all right. One of the 6522 VIAs on my workbench computer is used for:

• Timer 1 generating interrupts for a software RTC
• printer interface
• keypad
• LCD
• beeper
• synchronous serial interface for things like my analog oscilloscope raster graphics display
• I2C-6 I²C port
• A/D converter chip select
• and the ABORT input which is like Reset but less drastic.

That's all through a single 6522, simultaneously, and the only conflicts are that you can't press more than one key at a time while the LCD or printer are getting fed data our you'll mess it up, and you can't press a key during I²C operations. If you do use the I²C though, you can make tiny modules with only four pins: power, ground, clock, and data, or possibly add one or two more so you can have interrupts, although those won't often be needed for I²C devices. [Edit, later: See our I2C-6 hobbyist-friendly I²C connector standard at viewtopic.php?f=4&t=2155 . 7/28/22 I now offer a tiny I2C-6 EEPROM module on the front page of my site now, and there's a link to the data sheet there.] Making it as modular as possible makes the project more manageable, and makes it easier to recover when you change your mind. Anyway, there's a lot of I/O bit sharing you can do on the I/O ICs.

I haven't done things like SATA, but my workbench computer exists for workbench I/O, not human I/O, and everything goes through three 65c22 VIAs and it also has three 65c51 ACIAs which get very little use. These are all on the main board. The things mentioned above go through the first VIA. In addition there are the

• A/D and D/A converters
• with audio ports
• and sockets for amplifier and anti-alias filter modules
• 65SIB port
• PC keyboard port
• port for frequency/event counter + external-instrument control
• Dalas 1-Wire interface
• SS22 port
• serial port to large external RAM & ROM
• MIDI
• 440MHz wireless link
• tape modem (whose use has been replaced with modern serial EEPROMs)
• and RS-232

that all go through the other two VIAs and the three ACIAs that are on the main board measuring 4.5x6.5", and there are plenty of bits left over for general use in projects.

It does have a board-edge connector plus a mezzanine board, but the processor's own buses don't go to these. If I want to add USB or so many other things, they are available in SPI or other interfaces that can go through ports I already have.


Edit: This discussion was continued in the topic "Techniques for reliable high-speed digital circuits", about 40% of the way down the second page , at viewtopic.php?p=17906#17906 .

[mkarcz]

Thank you for your response, Garth.
I already made up my mind about the architecture of my system to be organized around 2 buses, CPU and I/O, hence my question was about how to lay out these pins rather than the philosophy of the system architecture.
Your advice is great, however it simply promotes a different philosophy than I chose. Perhaps my future systems will follow your model.
My project will have little practical and more educational use. It has desired modular architecture, so I will be able to add to the system as my project progresses. I will mount several circuits on the same board with CPU, including clock, I/O address decoding, start-up reset and EPROM address decoder and EPROM memory. However RAM memory and RAM address decoding circuit I want to build as a separate CPU bus card, since I may change my mind about memory capacity and memory banking circuitry or build a brand new different RAM card in the future.
I use slow clock (CPU at 1.8 Mhz), therefore there should be no penalty performance wise. I have the prototype now wired
on the bunch of bread boards with big mess of wires and it so far worked fine. I do not have whole lot of
peripherals connected at this point, just UART and LCD and just base RAM with no banked RAM part yet (ran out of bread board space), nevertheless I do not expect any problems when I connect advanced I/O card based on bunch of 6522-s on my buffered I/O bus and banked memory and graphic chip on local CPU bus. When I say local CPU bus, I mean the non-buffered close to CPU card part of bus. The whole bus will not have very long wires (up to 20 cm total I believe, including wires leading from CPU to the bus expansion sockets and wires under the mobo connecting 3 sockets on that bus that I will have in total, and to the chips on memory and other CPU bus expansion boards. They are not spaced wide apart, I will keep them close.
The I/O bus will be a little more extended on the other side of mobo, however it will be buffered. The buffer chips will be put just past the last CPU bus socket and will amplify and isolate CPU bus from I/O part. Wires on that bus may be a little longer than on local CPU bus, because they will span over several (4-5) expansion sockets. My UART and LCD now are both connected to that buffered I/O bus with long wires between bread boards and both seem to work flawlessly. That bus will not have all address wires on it, just lower 8-bit part (I dedicated 256 bytes for each I/O device). I do not have oscilloscope to see the signal quality though and there may be some ugly interference (expected on the bread board with heavy parasitic capacitance), which should be much reduced when I solder the thing point to point with much shorter and thinner magnet wire.
Thank you for your input though.

With best regards...

[cr1901]

Since your primer directly links to this forum thread:

To be honest Garth, I personally don't think it's very fair to say "don't run the buses off the board" and use serial interfacing and the VIA, and call it a day. Unless you're using wire wrap (time consuming, and high initial cost for sockets and tools, but easier to make changes) instead of making a PCB (defer the time cost for a monetary cost + sockets), the ability to add new high speed parallel I/O is very difficult without having an expansion bus.

I can only speak for myself, but one goal of me making a 65xx computer is to have something which I can interface parallel I/O with, just by adding a device to the 65xx bus. This is possible with near-zero prop-delay thanks to your creative incomplete address-decoding scheme that you placed on the primer. I'm not saying I2C, SPI, or interfacing using the VIA/PIA's output doesn't have it's place, but there's at least three things that come to mind:

1. If I wanted purely serial I/O besides a VIA, I would've gone with a microcontroller instead of learning how to interface to the 6502.
2. On a similar token, some devices are parallel by nature, and sometimes interfacing through serial I/O expander becomes difficult timing-wise, especially if the parallel device has control signals that must be asserted beforehand.

I'm not the analog designer by trade, you are . I think it would be nice if an example parallel bus that could work at high speeds be added to the primer, while still exercising caution. One doesn't even have to bring all the address lines out- just enough for I/O-device select, CLK, data, and power. I've never taken an RF course, but I'm certainly willing to take a chance on making my own 65xx/65816 parallel bus- or use an existing generic bus such as Wishbone and create a workable physical layout. PC-104's may also be a candidate. The 65SIB is giving me ideas on how to design such a bus as well.

I'm happy to discuss my reasoning further in DM (too far ahead in the future for me to make public promises now).

Of course, the alternative COULD be to just have the PCB remade, but... . I personally think it's better to add incrementally while still deferring the time cost of wire-wrap.

EDIT: Yes, I see Jeff Laughton's single cycle I/O trick, so there's no penalty for accessing data through the VIAs. It doesn't solve the problem of adding more fast parallel I/O. VIA also doesn't help interface 8-bit devices which require more than two control signals, or an 8-bit device with registers, such as a 6845 (example) .

[BigDumbDinosaur]

cr1901 wrote:

To be honest Garth, I personally don't think it's very fair to say "don't run the buses off the board"...

Quick reply before bedtime.

I would not take the MPU's buses off-board as well, although I sort of did this when I added the SCSI host adapter to my POC unit. What you might want to consider is a parallel expansion bus that is driven by a pair bus transceivers or similar and devise a protocol for selecting the particular I/O device that you want. It is conceivable that you could do this with a 65C21 or 65C22, either device which can support 16 bit parallel I/O. Please give it some thought. I think you'll end up with a more flexible and reliable arrangement.

[BigEd]

Marek, cr1901,

Bear in mind that some people are more cautious than others, and that some people will be quite OK with trying to debug and improve a not totally reliable first effort. Bear also in mind that very many of the early home computer designs, running at 1 or even 2 MHz, did take their busses off board, if only for a single point-to-point expansion.

So, when you see people saying "I wouldn't do that" you need to calibrate your own sense of what's worth trying with theirs: they might be more cautious than you, or they might know what is doomed to fail. If their background is industrial product design, you'll probably find that they want a lot of predictability, reliability and margin in whatever they make.

Cheers
Ed

[GARTHWILSON]

cr1901 wrote:

VIA also doesn't help interface 8-bit devices which require more than two control signals, or an 8-bit device with registers, such as a 6845 (example) .

If you're satisfied to run at a speed the 6845 could run at, then there's no problem running the buses off the board. The challenges come at the higher frequencies. If you can keep it all really small and the total length of the very longest connections (including the length across one board, through the connectors and the backplane, and across another board) still pretty short, you might do alright, if you do everything else correctly, like using an even distribution of power and ground connections through the connectors rather than bunching them up at the ends.

Perhaps 15 years ago, I was planning another workbench computer with a parallel expansion bus which would go through VIAs and let me for example control your 6845 (which came in 1 or 2MHz max, right?) and a nearly unlimited collection of other parallel things with a 20MHz computer, using VIA lines to emulate things like phase 2 and R/W\ in addition to address and data; but altogether, the complexity was reaching a point that I could see I'd never finish it. As I gained more experience with my current workbench computer, I was also seeing that the projects I was doing for both work and fun were not getting interfaced the way I had originally envisioned, and the edge connector was not very practical, even though it went to the VIAs, the A/D and D/A converters, MIDI, and so on, not the processor's own buses. (Instead, most things go through the many smaller connectors elsewhere on the SBC.) I also found ways to breathe new life into the original workbench computer, through things like 65SIB, so the plans for another one have kept getting put off, for years now.

The fact that I mostly use the smaller connectors and that I plug in various modules (shown further down) are partly why I've never gone through with a plan to use a half-rack-width portable card cage shown here with two 3U VME cards plugged into it. I was very enamoured by this cage's perceived possibilities for a while:

The slanted front cover was to hold a 40x4 text LCD and a keyboard which are protected when the cover plate hinges down and is secured with thumb screws to carry the unit, like so:

Here's the back hinged open to expose where the 96-pin DIN connectors' WW pins come out. (Again, the processor's own buses would not be brought out to the backplane, not even buffered.)

and closed:

More and more, I was seeing the idea just wasn't practical.

If/when I do build another workbench computer, it will be similar to the original shown below but have probably one or maybe two additional VIAs (for a total of four or five), and use an '816 with one of my 4Mx8 SRAM modules. I sure don't need three AICAs anymore, especially as one was intended for cheap data storage on audio cassettes, and today tiny serial EEPROMs and flash memories have become much cheaper, smaller, denser, and faster, and don't have the long rewind and fast-forward times. For UARTs though, I'll probably use the MAX3100 14-pin UART on SPI. I will try again though for a more rugged package that can be thrown in an attaché case without damaging WW pins. It would be somewhere around the size of 'scope meters.

In its original incarnation, my workbench computer had a third of its board still empty. That got filled up, and I added a mezzanine board later which is so far one-third full. Here's a comparison:

Original:

With later additions:

Here it is with the mezzanine plugged in which hides a lot of parts in this picture. The mezzanine does not have the processor's own buses going to it—not even buffered. There are a couple of modules plugged in, one being an anti-alias filter for the A/D converter and the other being for an amplifier to feed a speaker with the D/A converter's output or the A/D converter's input (and there are sockets for additional modules):

I wrote more and then realized I was just repeating material from earlier posts.