An open hardware extensible 65C02 computer

[jfoucher]

TLDR: I'm designing a modular 65C02 based computer here : https://gitlab.com/planck-6502 and am requesting your enlightened feedback.

Hello all, I've been lurking on this forum for a few years, but I have finally decided to create my first post because I would like some feedback on a project I've been working on. Maybe you are aware of the RC2014, an extensible Z80 based computer ? Well maybe I didn't search properly, but I could not find something similar but based on our favorite CPU. So since I've been learning to design PCBs for unrelated projects, I decided to have a go at it.
The constraints I set myself were the following :
- a PCB footprint of 100x100mm (jlcpcb reduced price footprint)
- Serial port
- Parallel port
- SPI / SPI65B port
- PS/2 port for keyboard
- eventually VGA out
- target clock frequency of 10MHz

Since it became obvious after several attempts that it would be very difficult to fit all these features on a 100x100mm board (even if using an FPGA for VGA out : https://gitlab.com/jfoucher/6502-vga ), I decided to go the backplane route, even if that goes against the advice of some of our most distinguished members.

Inspired by the Apple II the expansion slots use geographic addressing from a GAL chip on the backplane. This means the expansion cards do not generally need to include their own decoding logic, which in my mind greatly simplifies the design and creation of extension cards by third parties.

The result is available at https://gitlab.com/planck-6502 which is a group of repository, one for each card. You should probably take a look at the backplane first ( https://gitlab.com/planck-6502/backplane ) as the readme explains some of the choices that I made.

I am specifically looking for feedback on the expansion bus design, and whether you can spot anything that is obviously wrong or suboptimal on the various boards I have so far.

I could keep going for a while, but I think this is already quite long enough.

Thanks for reading this far !

[BigEd]

Welcome! Thanks for sharing and permissively licensing your projects. Have you built the system out yet, or is this an early request for comments? It's a nice idea, for sure.

[jfoucher]

Hi and thanks for the welcome.

No nothing has been built yet. I was tempted to have the backplane and CPU boards fabricated but I thought it best to request some comments to catch any possible mistakes or omissions early on.

I'm also hoping some people would take interest in the project and participate in its creation. It seems that the prototype stage would be too late for other people to feel like they could have a significant impact on the project.

[GARTHWILSON]

Welcome. Be sure to go through the 6502 primer if you have not already. It was written years ago to address the questions and problems that kept coming up on the forum, and I keep updating it.

[jfoucher]

Oh you mean the bible Yes I've been coming back to it regularly in my hours of darkness. Thanks for putting such a thorough resource online.

[jfoucher]

And to clarify, I know I'm going against your advice not to bring the CPU's own bus outside the board, but I could not find another way to match all the other requirements without doing so, sorry! Maybe this will prevent the computer from achieving the target 10 -12 MHz, but I'm hopeful that any issue that arises can be solved.

[BigEd]

It might helpful if you could tabulate your proposed bus here, in one or two columns (or three or four) and summarise what the physical connection will be.

One idea which has come up recently, I think, is that with large capacity SRAMs readily available, a backplane will mostly be for peripherals - the RAM and ROM could be onboard with the CPU. However, even if possible, it's not necessarily desirable. It would be good to see your thoughts on that.

Another thing which commonly happens is that at least one peripheral needs to run at some slower clock than the CPU, so it would be good to hear what the plan is there: RDY, or clock stretching, or something else. (And if the clock isn't regular, is there any provision for fixed-frequency timer/counters?)

[Dr Jefyll]

BigEd wrote:

with large capacity SRAMs readily available, a backplane will mostly be for peripherals - the RAM and ROM could be onboard with the CPU.

I think Ed raises a good point, jfoucher. And it implies your proposed backplane needn't include all the address lines... which makes things easier in some ways.

For example, you'll have better signal integrity if you intersperse one ground line between every two signal lines -- or, better yet, make the ratio one-to-one. Obviously that drives up the conductor count, but maybe you can afford that if you have fewer address lines.

Also, have you considered using a flexible backplane, based on ribbon cable? There are advantages, which I describe here.

Regarding peripheral timing, perhaps cycle-stretching or use of RDY will be required. To review the relative merits of these you may wanna have a look at RDY vs CLOCK STRETCHING. Includes 2 very simple circuits.

-- Jeff

[plasmo]

Are there any talks here about "processor agnostic" bus? I thought of one based on RC2014 bus a couple years ago, but wasn't too happy with the results. I still have a couple ideas fermenting (festering?) in the back of my head. The idea is having common RAM, peripherals, mass storage, video supporting 8-bit and some 16-bit 5-Volt processors of 1970's and 1980's. In my mind CPLD looms large as the mechanism to accommodate different processors, but perhaps there is a better way.
Bill

[BigEd]

I wouldn't want to derail the thread... here is a previous discussion about 6502 on rc2014, which might have some useful points:
Newbie moving onto second build - RC2014 but using the 6502?
(The first response there links to another earlier discussion)

[plasmo]

I have read that thread and basically that was what I did with G8PP. OK, I'll mull it over more and possibly start a new thread about generic processor bus.

[jfoucher]

BigEd wrote:

the RAM and ROM could be onboard with the CPU.

Yes my idea was to have 64k of RAM+ROM on the CPU board, and expansion cards can expand the ram, maybe using banking or replacing the ROM address or whatever the expansion card wants to do.

BigEd wrote:

it's not necessarily desirable

What are the cons of doing it that way ?

BigEd wrote:

Another thing which commonly happens is that at least one peripheral needs to run at some slower clock than the CPU, so it would be good to hear what the plan is there: RDY, or clock stretching, or something else.

The clock would be regular, and provided by the backplane. RDY is on the expansion bus so that is the plan for slow peripherals.

Here is the expansion bus description that I have so far devised :

Code: Select all

Most pins correspond to the pins of the same name on the CPU.
Below are the pins that are specific to the expansion bus:

EX0-EX2
3 expansion pins that are reserved for future use or can be used for communication betwen two expansion cards.

INH
When low, this signal inhibits the RAM and ROM present on the CPU card and allows an expansion card to take over the whole bus (except expansion region).

SEL1-SEL5
The expansion card in the slot in which this signal is low should activate.

SSEL
Slot selected. The cpu card and any other card should disable all bus access when this signal is low and their own select signal (SEL1-SEL5) is high.

LED1-LED4
Debug leds 1 to 4.

IRQ0-IRQ3
Should be used by expansion cards when they want to signal an IRQ. All 4 lines are ANDed together on the processor board and pull the IRQ line low when at least one of them is low.

More readable version here : https://gitlab.com/planck-6502/backplan ... us-signals

[jfoucher]

Dr Jefyll wrote:

BigEd wrote:

with large capacity SRAMs readily available, a backplane will mostly be for peripherals - the RAM and ROM could be onboard with the CPU.

I think Ed raises a good point, jfoucher. And it implies your proposed backplane needn't include all the address lines... which makes things easier in some ways.

Yes but then if you want to add banking and so on then all the logic has to be on the CPU board hasn't it ? But I admit it is an intriguing possibility.

Dr Jefyll wrote:

Also, have you considered using a flexible backplane, based on ribbon cable? There are advantages, which I describe here.

Thanks for the link, I will read it, but I have to admit I find it fiddly to have to plug and unplug cables.

Dr Jefyll wrote:

Regarding peripheral timing, perhaps cycle-stretching or use of RDY will be required. To review the relative merits of these you may wanna have a look at RDY vs CLOCK STRETCHING. Includes 2 very simple circuits.

To be honest I am a bit afraid of clock stretching which seems fairly tricky to get right. I will take a look at the link, maybe it changes my mind !

[BigDumbDinosaur]

jfoucher wrote:

Dr Jefyll wrote:

Regarding peripheral timing, perhaps cycle-stretching or use of RDY will be required. To review the relative merits of these you may wanna have a look at RDY vs CLOCK STRETCHING. Includes 2 very simple circuits.

To be honest I am a bit afraid of clock stretching which seems fairly tricky to get right. I will take a look at the link, maybe it changes my mind !

There's nothing about which to be afraid. The clock-stretching to which Jeff refers has been proved to be viable on a 65C816 system running at 20 MHz. Jeff's method is a single-chip solution that was straightforward to implement.

[BigEd]

jfoucher wrote:

BigEd wrote:

the RAM and ROM could be onboard with the CPU... it's not necessarily desirable

What are the cons of doing it that way ?

It might mostly come down to a matter of taste. Some thoughts, if the CPU board is just a CPU board:
- looks a bit more historically authentic, with ROM board, RAM board, peripheral board
- allows for one or two small RAM boards or a large paged RAM board
- allows different model of CPU, reusing all other boards
- might allow dual CPUs
- allows boot ROM swap by swapping a board

However, flexibility might mean complexity, and complexity might mean drowning in details. Everyone has an opinion, so the more features you have, the more people you ask, the more you find you can't please everyone...

I would say follow your muse. You might find one or two people could be collaborators on your project - perhaps more likely, if you make the thing, someone might design a board for it. In my experience, two or three collaborators is a soft limit on how many people can communicate and agree!