jfoucher wrote:
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.
I guess you missed the
RC6502 system, which also is designed to fit within the JLCPCB 10×10 footprint. (That's not my design, but I use it, and I wrote the
bus documentation.)
That said, your project seems to be going in a somewhat different direction, so while I'd encourage you to have a look at the RC6502 stuff, there's no reason not to continue with your own.
Quote:
...I decided to go the backplane route, even if that goes against the advice of some of our most distinguished members.
Yeah, I wouldn't get too uptight about following such advice, so long as you're willing to to take care and deal with any extra debugging that may be involved. Members of this forum are
running 20 MHz systems on breadboards, so clearly what you're trying to do is far from impossible.
Quote:
...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.
That's certainly one way to go, though I wouldn't say it solves problems as much as replaces them with different problems. :-P For example, without decoding on the cards I/O ports now move around as you move cards between slots, and drivers need to take this into account, either auto-configuring or providing a way to manually configure them. You may want at least to think about providing some bus support to help with auto-configuration, though unless you've got a particularly clever way of doing this it adds either extra complexity or ends up putting more circuitry back on expansion boards. (The Apple II dealt with this by having ROM on boards with the drivers, so that they could be essentially self-identifying.)
It is possible to do a combination of bus-based and slot-based deocding, which has already been happening with RC6502 in a similar way to the way it's often done with the USER pins on RC2014. RC6502 has four essentially unused pins (35/TX, 36/RX, 38/EX1 and 39/EX2). The SBC/CPU card (more on this below) is already decoding every 4K block from $8000 to $F000 as a byproduct of the decoding for its onboard RAM, ROM and PIA, and one of the RC6502 users has already soldered a couple of jumper wires on to his board to bring the $A000, $B000 and $C000 signals out to the TX, RX and EXT1 pins.
I'm planning to do almost the same, except probably with two 8 KB and two 4 KB ranges, $8000/$9000, $A000/$B000, $C000 and $D000. (Though I've got to say, using one of those for an inhibit line like yours is tempting.) Then my boards themselves will be able to further decode those into smaller ranges: with a single 74'138 you can easily have an expansion card select for itself a 512 byte subsegment of one of the 4K blocks above and then generate separate selects for each 64-byte range within that subsegment. Add jumpers to configure which bus select signal is used and how the high address lines within that range are routed to the '138 (which has two negative and one positive select) and other chips and you've got quite a bit of flexibility for configuring your I/O space at minimal extra decoding cost.
I mentioned an "SBC" above: this is my favourite board of the whole system. The first RC6502 system had separate boards for CPU, clock/reset, RAM, ROM, and so on, but the SBC combines all of those and serial I/O (via a PIA talking to a microcontroller emulating the Apple 1 video and keyboard circuitry, in this particular case) so that the board can run standalone, which is great for carrying around to demos and whatnot. But plug it in to the bus and you've got access to whatever expansion cards you want. (The current RC6502 system has a wide range, including video and so on.) There are jumpers on the SBC to disable the RAM, ROM and serial I/O so that you can replace those with off-board devices if you like. You might want to consider doing your system this way so that you could run the simplest version as an SBC, and put your video and whatnot on additional boards.
I also have a few comments on your repo organization and so on:
1. I
strongly suggest you put all of your work in one repo, with a subdirectory for each project. This provides some very tangible development benefits, such as ensuring that changes are co-ordinated between boards and reducing duplication (for example by having one library for things like bus symbols and footprints used by all projects). It also makes it easer to get and update copies of your work, since there's only one repo to clone or fetch.
2. Once you're at the point where you're inviting folks to look at your work, it helps if you commit a PDF of the schematic, as well as the `.sch` file. This lets people view it on-line, rather than having to download the files or clone the repo. (And install KiCAD, if they've not done so already.) You do need to remember to regenerate and commit the PDF in every commit that changes the `.sch` file, but I'm hoping to look soon at some way of automating that a bit.
3. You seem to have committed your backup files as well (*-bak); it's probably best to remove these and then add that pattern to the .gitignore. (You do want to keep committing the *-cache* files, though, since they ensure someone without the same libraries as you can still read the schematics and PCB design.)