Sorry about the length; I kinda let this thread go a while before starting to read it and now there's lots to reply to.
jfoucher wrote:
Looks great, but If the female headers on the right hand side are your expansion connectors, they seem very close together....
jfoucher wrote:
And here's mine, about 19mm on centers. Most things fit, but sometimes a bit tighter than I'd like. I've actually shorted the back of one board a few times.
For what it's worth, the "standard" RC6502 backplane board is 24 mm centre-to-centre. (This is the maximum spacing you can get for five slots on the JLCPCB 10 cm × 10 cm minimum-price board around which the entire RC6502 system was designed.) The attached photo shows my Apple I clone SBC inserted into the backplane; you'll note it leaves enough room for the Arduino Nano which is not socketed but is a small board on 0.1" headers.
Attachment:
PXL_20210816_090600331.jpg [ 302.05 KiB | Viewed 1147 times ]
For spacing the bus headers further apart, have you thought about moving some of your devices
between the headers? I would think that RAM and ROM, in particular, might fit in there fairly well since most of their signals are coming off the bus anyway. I'm not so sure about the PIA.
I'd also consider adding pads for a right-angle header right at the edge of the board so it could plug into a stand-alone backplane, like the SBC does.
Quote:
Because of these choices, an 74HC00 can be used for address decoding instead of the '132 (chip included in BE kit)
Well, my feeling on that is that I'd consider carefully using the Wilson design or even a NAND or two over more decoding (like the '138 on the SBC) if you're focusing on making this fairly expandable. (Which, with three slots on your board, it looks like you are.) Garth's approach is pretty darn clever and gives massive savings on logic, but has the usual trade-off of eating a fair amount of address space for a relatively limited number of devices. It also has a lot of aliasing of multiple devices together, which is fine if you know what you're doing but not so great if beginners might be using your boards, I'm thinking. The '138 does have the disadvantage of being slower, but particularly high speeds might also be bad for beginners if they're glomming their own stuff on the bus, too.
The advantage of the '138 method is that it does a "medium" amount of non-overlapping decoding and, if you bring some of these I/O lines out to the bus as is discussed in the other thread (and as I plan to do for my SBC, and as others have done for theirs) it means you can use another '138 on a peripheral board to do another "medium" amount of decoding, giving you "medium²," which is a fair amount. (Typically, first '138 decoding top 32K into 8×4K blocks and second '138 decoding one of those into 8×512 byte blocks. It's easy to change this to be 2K/256 byte or 1K/128 byte chunks if you are building a high-memory system with 48K or 56K always mapped as RAM.) More on all this in the bus thread, of course.
BTW, this is not to say that the Wilson method is bad in any way; it's just (to my mind) best for something like a single system where one experienced guy is in designing and building everything on it, and speed and reducing logic is more important than being more modular. (Which happens exactly to describe Garth's bench computer.)
All that said, I must admit that for personal reasons I prefer you do the Wilson decoding system since bringing in such a different decoding design at an early stage will help make the bus design better. :-)
For what follows, I'm not sure if it's all worked out or not but I'll just post it without doing too much analysis of the previous posts because it's getting near the end of a long day. :-/
Quote:
[The SST 39SFxxx series is] not pin compatible with the EEPROM, which makes it not a great solution for this kit where I want to encourage folks to use the hardware they already purchased for a breadboard build.
Is it not? At first glance it looks as if it is to me. Remember, when more pins are added, the pins on the right side "slide" so that the "bottom" pins (furthest from pin 0 and the highest pin) continue to match. This means that e.g. /OE should be pin 20 on a 24-pin device, pin 22 on a 28-pin device, and pin 24 on a 32-pin device. I drew up
this diagram to help with matching the JEDEC pinouts for various device sizes (this is RAM/EEPROM, not EPROM):
Code:
┌─────────∪─────────┐
────────│1 32│──────── (Vcc)
(A16) ────────│2 31│──────── (A15)
(A14, Vpp) ────────│3 1 28 30│──────── (Vcc, CS2)
(A12) ────────│4 2 27 29│──────── (P̅G̅M̅, W̅E̅, A14)
A7 ━━│5 3 1 24 26 28│──────── (Vcc, A13)
A6 ━━│6 4 2 23 25 27│━━ A8
A5 ━━│7 5 3 22 24 26│━━ A9
A4 ━━│8 6 4 21 23 25│──────── (W̅E̅, A11, Vpp, A12)
A3 ━━│9 7 5 20 22 24│━━ O̅E̅¶ ─ (C̅S̅)
A2 ━━│10 8 6 19 21 23│━━ A10
A1 ━━│11 9 7 18 20 22│━━ C̅E̅ ── (A11)
A0 ━━│12 10 8 17 19 21│━━ D7
D0 ━━│13 11 9 16 18 20│━━ D6
D1 ━━│14 12 10 15 17 19│━━ D5
D2 ━━│15 13 11 14 16 18│━━ D4
GND ━━│16 14 12 13 15 17│━━ D3
└───────────────────┘
(In case that's not rendering well in your browser, I've attached below a screenshot taken in urxvt.)
There are definitely some pins that need jumpers based on device size (Vcc being the most obvious one), but if you need not support the old really small devices, I think this is relatively few.
Individual_Solid wrote:
Here is a part I used in several designs that may help driving down your BOM cost. W27C512 EEPROM is an obsoleted part but can be easily acquired on eBay for about $1 each.
Yeah, that's using JEDEC ROM pinout instead of RAM/EEPROM pinout, IIRC, but even there there are not a lot of pins to change with jumpers or solder/cut pads.