Not directly related, but this:

https://projects.drogon.net/ruby-6502-on-stripboard/

runs at 16Mhz on stripboard, so... go for it!

(But as BillO says above, PCBs are so cheap these days, it's hardly worth while not using one now - I also use JLCPBC)

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Thanks! Based on the many successful projects that were linked, i'm now sure it's doable. So as long as i keep the traces short and the clock frequency low, there should be no problems. For the connectors, the standard pins and the very similar DIN41612 looks good for the raster boards that i can source locally. I looked at the bus used for the RC6502 Apple II replica and it looks very similar to what i have in mind. While i don't plan to use the exact boards, i would like to make something along those lines.

For the bus, i have the following signals in my mind:
-power: 5V-gnd
-clock: phi2, generated by the clock circuit, input for everything else including the cpu
-/reset: generated by the reset circuit, input for everything else
-address: a0-a15
-data: d7-d0
-r/w: read/write, normally generated by the cpu
-/ready: device ready, active low, pulled up internally in the wdc65c02
-/irq: interrupt, active low, pulled up with 3.3k on the cpu card
-/nmi: non maskable interrupt, active low, pulled up with 3.3k on the cpu card

With all other outputs (/ml, sync, /vp) on the cpu unconnected and all inputs (be, /so) pulled with 3.3k resistors to their default state. Do i miss anything? Is it a good idea to generate clock synchronous read and write singnals from the r/w! output on the cpu card or it's better to do it on the card that might need them?

For address decoding, i plan to use 2, 3 or 4 bits decoder chips where direct wiring the right address lines is not enough. I don't plan to make any other bus master devices beside the cpu and maybe use some dual ported ram for a video output later to avoid tying the system clock to any video clock and to avoid tristating the bus (so the cpu's be input isn't needed). My main concern with this very basic design is getting the write and output enable inputs into the right states at the right time on the ram and eeprom chips and i hope the via, pia and acia chips could be used directly with the cpu signals.

I know backplanes get a bad rap. My SBC has four "slots" that are encoded by a couple IC's in a similar style as the Apple II. I've ran it for a very long time and found no issues up to 8 MHz. I also bring out the entire data/address bus on the slots too.

If you look at the Apple II, that board is gigantic and it has 8 slots with just about everything brought out. It only runs at about 1 MHz so it can get away with this. So a big thing to consider is how fast you want to run.

_________________
Cat; the other white meat.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I do a similar thing with mine. As it's essentially for I/O this works out well.

_________________
Bill

If you've got extra pins on the backplane, putting some decoding outputs on them seems like a pretty good idea to me, especially since the signals are often already lying around anyway if you're using a '138 or similar. Use decoding that's not being used on the main board, of course (or at least for peripherals that can be disabled with a jumper) and then you can try out additional I/O chips without trouble.

I find it mildly annoying that on the SBC I'm mainly using these days (RC6502 Apple I Replica SBC), where $8000-$CFFF is entirely unused, every 4K block in the upper half of RAM is decoded but most of those signals go nowhere. I want to map some of the alternate banks of the EPROM into that, but I'll need to add another '138 to the board that will do this, unless I want to start soldering jumper wires between the two boards, as well as using the bus connector. (I need a few anyway, though, so hmmm....)

This an idea used even in off-the-shelf, non-backplane systems. The Commodore 64, for example, had four different decodes going out on its expansion/cartridge port: /ROML ($8000-$9FFF), /ROMH ($A000-$BFFF or $E000-$FFFF, depending on the current memory map), /IO1 ($DE00-$DEFF) and /IO2 ($DF00-$DFFF).

_________________
Curt J. Sampson - github.com/0cjs

Thanks! So i'm adding a 3.3k pullup to the /notready line. Also considering using the unused lines as chip selects for some of the 16 available 1KB i/o blocks or maybe just to bring out some of the rest of the useful control lines. I'll have to draw up the decoding circuits for the ram, rom, pia*2, via and acia chips and see what decoder would be the best for them and which signals would remain unused and candidates to be shared on the bus. The available board width allows 39 signals, so one pin has to be removed from the 40 pin connectors. I don't plan to use any enable/disable jumpers, just to pull out any cards that i don't want enabled for a certain configuration. This would enable me to try different and conflicting hardwares. For the first try an external eeprom writer and no debug and single step support would be the goal with a single pia chip, a 9 pin joystick port and a few leds as i/o, so i can see that it works.

Remember that it's not just unused signals that can be useful, but even the ones that are already being used, if they can be re-used.

I spent this evening breadboarding up a second MC6821 PIA for the Apple I replica I mentioned above. The first PIA is in the $D000-$DFFF I/O area, but further decoded by A4, so its registers are in $D010-$D01F, $D030-$D03F, and mirrored up to the top of the page that way. I just stuck this one in the other half ($D000-$D00F, $D020-$D02F, etc.), with a duplicate 74LS138 set up in the exact same way, and using that exact same select signal that comes out of the original. All I needed to do was invert the A4 line on used on an additional chip select on the PIA on both the original PIA and mine. Ironically enough, there are even several unused inverters on the SBC, so I ended up duplicating two chips unnecessarily.

_________________
Curt J. Sampson - github.com/0cjs

Again, it's RDY, not /RDY. The true state which means "ready" and lets the processor continue, is high, not low.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Yes, but he said "/notready," which is "not not ready," which is "ready." :-)

_________________
Curt J. Sampson - github.com/0cjs

Right you are. Double negative caught me off guard . Maybe it should've been called something like HOLD\, to avoid confusion.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?