Building a passive backplane based expandable system

[drogon]

kvp wrote:

My question is if i use a WDC65C02 cpu and try to stick to 5V CMOS components only and plan to run only at around 1 or 2 MHz, then can i get this system to reliably work if i use a hand soldered raster stripboard backplane
Thanks: Viktor

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

[kvp]

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.

[cbmeeks]

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.

[GARTHWILSON]

Quote:

-/ready: device ready, active low, pulled up internally in the wdc65c02

From the 6502 primer:

• The "ready" input is used for single-stepping, wait states for slow memory, and DMA. Some makes of 65c02 have had internal weak pull-ups on RDY and other inputs, so you could get away without connecting it to anything. WDC has apparently removed this. Better not let it float. Note that WDC's RDY is bidirectional, and it will be pulled low if it gets the WAI (wait-for-interrupt) instruction in your program. (WAI puts the processor in a better position to make a fast-as-possible response to an imminent interrupt.) On the other hand, although you may not have any plans to use WAI, a crash could make the processor misinterpret a $CB operand or data byte as the WAI op code and possibly damage the chip through heating problems if the output is shorted to +5V. If you don't want to further investigate or use the features this pin is made for, and you want the circuit to be able to handle any manufacturer's 6502 or 65c02, pull it up to +5V through a 3.3K pull-up resistor.
  
  Jeff Laughton has a wait-state circuit on the 6502.org forum using RDY for slow ROM. He also has a very simple clock-stretching circuit to replace a RDY circuit, here. A big advantage it has over other clock-stretching methods is that it does not affect VIA timing.
  
  Sometimes it gets called /RDY or RDY\ (ready-not), but this is incorrect! RDY\ would imply that you ground it when you're ready to have the processor move on. It's not that way though. You ground it when you're not ready yet and need for it to wait. As long as the memory being accessed is always ready at the bus's clock speed, you keep RDY pulled up to mean "I'm ready and I don't need any more time to get the data out." High means, "Yes! Ready! Go!" Low means, "No, I'm not ready! Don't go yet!" It is active-high.

[BillO]

cbmeeks wrote:

My SBC has four "slots" that are encoded by a couple IC's in a similar style as the Apple II.

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

[cjs]

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

[kvp]

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.

[cjs]

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.

[GARTHWILSON]

kvp wrote:

Thanks! So i'm adding a 3.3k pullup to the /notready line.

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

[cjs]

GARTHWILSON wrote:

kvp wrote:

Thanks! So i'm adding a 3.3k pullup to the /notready line.

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

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

[GARTHWILSON]

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