Zolatron 64 6502 computer: the backplane dilemma

Having looked at a lot of homebrew computers online, including the popular RC2014, it seemed obvious that the best way of going about my own project is to opt for a backplane design. But maybe it’s too obvious.

Just as I was ready to get started with designing the Zolatron 64 I stumbled across this page (via the excellent 6502.org site). Garth Wilson makes an extremely cogent and insightful case for not using a backplane. Chief among these is that such designs impose severe limitations on speed. He points out that serial communications offer a much better way of throwing signals about these days. Backplanes, he says, are for newbies.

He’s entirely right. And here’s why I’m going to ignore him.

am a newbie. I haven’t even got as far as hooking up the 6502 processor to RAM yet, let alone implementing I2C interfaces. I need to walk before I can run and the backplane design is simple.

It’s also highly modular. I’m going to be making mistakes. My hope is that I can get one section of the computer designed and debugged at a time. And once I’ve got each section licked, I’ll make it into a custom PCB, plug it into the backplane and move on to the next section.

Speed isn’t important. If I want something faster, I’ll use a Raspberry Pi (I have a few) or my iMac – or even my BBC Master, if I want to program in 6502 assembler on a real machine (and can get it fixed).

The purpose of this project is to learn. As with software, my approach is – get the damn thing working, then optimise. I figure I’ll go through versions of the machine where boards get integrated together until there is finally only one and it can at last spring free from the backplane.

So, how to connect to the backplane?

The Euro way

I wasn’t sure how many signal lines I was going to need. Obviously, you need eight data lines and 16 for addressing. You’ll want at least one clock line, VCC and GND. The RC2014 mentioned above has 40 lines in total for the standard backplane, not all of which are used. But I like having room for expansion. So having cast around I settled on the classic Eurocard connector, the DIN 41612, as found in many rack systems and the VMEbus.

This comes in a number of flavours and configurations, one of the most common being 96 pins arranged in three rows labelled A, B and C. I doubt even I could find a use for 96 pins, so I went for the variant that has 64 pins by virtue of using only rows A and C. This leaves a nice gap between the rows, which might be useful for routing on the boards. On the backplane, all the pins in row B are sometimes connected to ground to reduce crosstalk between rows A and C. I don’t think my design is going to be advanced enough or running fast enough to worry about that, though.

The next decision to make was which signals to connect to which pins. I reckon the best layout will emerge only through designing actual boards, but I had to start somewhere.

I decided to put all the address and data lines in the same row (C), along with the main clock signal. This means I might be able to connect some stuff with only a single row. In the list shown, the entries in green are 6502 signals. The two in orange are 6502 signals that I probably won’t need. The ones in red are signals of my own invention and are best described as ‘tentative’.

Using pins 1 for VCC and 32 for GND is pretty much a Eurocard convention. I added extra GND and VCC lines on pins 2 and 31. And I’ve thrown in a few more GND connections for good luck. This leaves me with 12 spare pins (14 if you count the SOB and MLB pins that I probably won’t be using).

So the schematic, drawn in KiCad’s part editor, looks like this. (The pins labelled ‘nc’ are not connected – ie, currently spare.)

It’s unlikely this will remain unchanged. No plan, they say, withstands first contact with the enemy. But at least I now have something I can throw on to a schematic and start tussling with connections.

The first board will be the main processor board, carrying the 6502 itself, a 32k RAM chip, the crystal and reset circuitry and maybe the main 16k ROM.

The second board is likely to carry a 6522 Versatile Interface Adapter (VIA) or two. And I have in mind to create a couple of test boards – one with a four-digit, seven-segment to show the state of the address or data bus (switchable) and another using something like an AVR microcontroller to put signals on those buses.

Ultimately, I’ll want a control panel, too – for play value and blinkenlights. But that’s far in the future. First, I need to finish the kit I bought so that I at least have a fighting chance of knowing what the hell I’m doing.

2 thoughts on “Zolatron 64 6502 computer: the backplane dilemma

  1. GDS

    I’m so glad to have found your pages about the Zolatron project. I’ve been thinking about the same thing (a backplane-based 6502 system), but I have so little practical experience with these things I’ve been kind of floundering. After seeing your posts here, I tried to get an Apatco NCS 2056T for parts, documentation, and to get a little experience,, but they are currently sold out.
    I’ll be watching this blog for updates, and I hope to eventually follow along with hardware of my own.

    1. Machina Post author

      I’ve been a bit lazy with that project lately, but also feeling like I need to get back into it. Time to dust it off and get going again!


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.