Yes, but the 100mm board size requirements limits the computer to 6 boards, and that's with little space to spare for taller components. So CPU, RAM and ROM would already be three boards, reducing the expansion capacity. But maybe having the RAM and CPU on one board and the ROM on another would be a good comprise and still allow boot ROM swap by swapping a board (I really like that idea) and maybe clock stretching when the ROM is selected to allow for higher CPU speeds when doing RAM operations.



Yes that would be great! That's why I want to make sure that the base design is sound.

_________________
Jonathan Foucher

Take a look at the Planck 6502 computer.

BTW, I like the INH signal!

It's inspired by the Apple II expansion bus pinout, although in the Apple II's case the INH/ signal only inhibits the ROM. My reasoning for having it disable both the RAM and the ROM was that the expansion board can have logic that would toggle the INH/ signal on or off depending on whether the RAM or ROM is being accessed.

_________________
Jonathan Foucher

Take a look at the Planck 6502 computer.

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.


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.


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

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

First of all cjs, thanks for the detailed reply.



Yes definitely never saw that one, very interesting! I will have to take a look at their github repo in more detail.



Would reprogramming the PAL to map a specific address range to another port count as autoconfiguration ? But at least it is possible to move cards around without modifying the drivers, although you do have to pull the PAL and reprogram it. Having ROM on the cards is good move I think to allow third parties to integrate drivers in the system. However I feel it's overkill for this project.



Hmm, that gives me an idea. By having a transceiver between the select lines coming out of the PAL and the bus itself, an extension card could take control of the activation and deactivation of the expansion slots in a way similar to what you suggest. Maybe there are other, better ways though, but it is an intriguing possibility for sure.


That's actually a great idea! I think I could get something close by adding a serial chip and a connector for a USB to serial adapter to the CPU board (which already has RAM and ROM) Or maybe make them two separate card so that you could choose which one you want to build.


It was on my mind as well, will do it ASAP.


Yes, do let me know if you manage to find a way to do that! Automatic 3D view generation for the boards would be great as well!



Will do, thanks for the info.

_________________
Jonathan Foucher

Take a look at the Planck 6502 computer.

Instead of a transceiver, consider using an octal FET switch instead. Example: 74CBT3245 (PDF below) even has the same pinout as a normal '245.

These FET Switch devices add virtually no propagation delay as a signal passes through -- except for a few ohms of resistance, it's as if the signal were passing through the contacts of an electromechanical relay. And as with a relay the signal can be bidirectional (!). The only minor caveat: as with a relay, there *is* some real delay in turning the thing on and off. Nothing extreme, just a gate delay.

There's some introductory material at the start of the Selection Guide (PDF below). On page 10 they discuss 5-volt devices.

The products are also offered in bus exchange and mux / demux configurations. Example of the latter: a 74_257 equivalent that's virtually-zero delay (also bidirectional). Such a part (or a pair of 'CBT3245's) would be ideal for letting an extension card take control of the activation and deactivation of the expansion slots.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Oh, one more issue with slot-based addressing that I forgot to mention: it also then limits the number of (decoded) expansion slots you have to the number you have on-board decoding for.


Well, so long as you're reprogramming the PAL on the fly while the system is operating! :-)

Come to think of it, something like that might not be so difficult. Using a parallel ROM for decoding is a tried and true technique, as seen in systems like the Fujitsu FM-7. You could use an EEPROM for decoding, wire it to be in-system programmable, and then reprogram it on the fly as the system is running. (I'll leave it to you to decide how serious I am about that proposal. :-))


Also, having ROM on the cards also seems to undermine the point of having a dedicated select line per slot, which is to reduce the number of components one needs to put on a card, no? Or am I misunderstanding what you like about the bus-based select system?

I'm kind of feeling now that bus-based select can be good when you have a nailed-down system design, but when your system design is in flux the constraints of a particular decoding scheme would probably hurt more than they would help. But:


Ah ha! This idea could be used to allow for arbitrary experimentation again. How about removing all the address decoding from the backplane and putting it on a separate card that plugs into a special slot on the bus? This card would have access to all the control signals and all but perhaps the very lowest address lines, as well as a pin for the enable for each other slot. Then you can go wild consing up different ideas for the decoding circuitry without having to replace your backplane every time, and if it's not working out you can still use your backplane in the traditional way with all decoding on the card or partial decoding with a very simple separate decoding card asserting a line for the "I/O block."


Yes, that's more or less how the RC6502 system works: you can build the separate CPU, RAM, ROM, etc. boards or just use the SBC board to replace the core set of boards (or of course use the SBC board stand-alone).

To run the SBC board stand-alone, you'll need clock, reset and a bit of address decoding on it too of course. I think that the RC6502 SBC is a very good model of this. The only things I'm intending to change from that when I do my own 6800 board are to add a disable jumper for the CPU as well (so the board can be used for any individual function or combination of functions: RAM, ROM, I/O and clock already all have disable jumpers) and add some configuration ability to choose what I/O select signals come out on to what bus pins.

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

That does not matter much since there are a fixed number of expansion slots on the board. I am not really planning of daisy chaining backplanes, although I understand it has been done.



Yes I like that it simplifies the card hardware and that it makes it easier to build cards, but I think having drivers on the card was a good move for the Apple II in that it simplifies driver integration in the overall system. I'm wondering how the card drivers can be included otherwise without having the user reprogram the main ROM. Any suggestions are more than welcome.



Yep, a separate address decoding card could be used, all you have to do is remove the GAL22V10 from it's socket


.
The CPU card is already full as is, and I rather like the aesthetics of having all the expansion boards the same height, but maybe I can make all of them higher!



My humble suggestion regarding this would be to look at the feasibility of enabling / disabling specific features from software. Maybe a "master" CPU on the bus could disable the SBC's clock and CPU? Not sure if that's possible in your setup though. (I'm not the biggest fan of jumpers as you can see )

_________________
Jonathan Foucher

Take a look at the Planck 6502 computer.

Just to enlarge on this a little: Acorn's BBC Micro provides a usually-2MHz CPU clock, which can be switched to a free-running 1MHz clock, used for the VIA timers. That switching to slow clock takes one or two phases depending on which phase of the 2MHz clock triggered the switch. See here for a diagram. On the other hand, their later machine, the Master, uses RDY to stall the CPU, making slower accesses as required. In both cases, the decision that the current cycle needs to be a slow cycle has to made pretty quickly, driven of course by decoding the address bus.

_________________
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?

Funny, I just posted a question on this subject here.
Of course VIA timers go out the window with this method, but it could be useful if possible. My long term plan anyway is to copy the ROM to RAM on boot and run from RAM.

For the BBC Micro I'm not sure I understand how VIA timers are handled when switching clock speeds... Would you mind clarifying BigEd?

_________________
Jonathan Foucher

Take a look at the Planck 6502 computer.

I've put through hole parts on both sides before, but only for simple boards. For complex boards, wouldn't the limiting factor be the number of traces that have to be run all over ? I'd rather limit the boards to 2 layers if at all possible.


Yes I saw incredible examples on your website, but Kicad complains even I put a surface mount cap under a socket :/ I should probably tweak the design rules so it stops bothering me about that...

_________________
Jonathan Foucher

Take a look at the Planck 6502 computer.

Well, first thing is that VIA timers remain reliable: the VIAs both get a steady 1MHz clock tick, all the time.

The VIAs, and anything else which needs to see 1MHz accesses, will only ever see 1MHz accesses, because in the cycles that they are selected, the CPU is held up to wait for the end of the next 1MHz cycle, before continuing at its usual 2MHz.

So, the VIAs operate in a 1MHz world, and the CPU operates 99% of the time in a 2MHz world. Dave (@hoglet) has extended this to a CPU running at 100MHz (in FPGA) slowing down to 2MHz or 1MHz as it needs to access resources on the motherboard. Revaldinho has extended it to an '816 CPU daughterboard running at 14MHz and up to 20MHz on a similar basis. (In both cases, fast local RAM is needed to get any work done at high speed.) So, these two tactics, of RDY or clock-stretching, have proved to be quite general and robust.

(RDY is more applicable with CMOS parts, as NMOS CPUs don't recognise RDY during a write cycle, making it harder to use it for this purpose. That's probably the reason why Acorn's earlier machine used the clock-stretching approach.)

_________________
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?

Ok, I think I get it. The VIAs get a single clock at 1MHz all the time. The CPU gets another clock at (say) 2MHz all the time except when the VIAs are selected so that it can communicate with them.

In my case, (and please tell me if I get something wrong) it would be possible to have a slow clock and a fast clock on the bus. The expansion slots would listen to the slow clock all the time. The CPU board would listen to the fast clock all the time except when an expansion slot (or it's onboard ROM) is selected. The only drawback I see with this scheme is that fast devices (say RAM expansion) on the bus would be forced to use the slow clock. Unless I can think of a way to let the CPU know which expansion board uses which clock... Or have some "fast slots" and some "slow slots"...

Anyway, thanks for the clarification BigEd



I have to admit I haven't dared go to the limit of what the board house can do. I'm currently setup for 10mil/10mil trace/space. It appears JLCPCB at least can do 5mil/5mil ( https://jlcpcb.com/capabilities/Capabilities ). I'll have to get a test board fabricated at those specifications to see if the reliability is there before I'm confident though Getting 4 traces between pads sound reeeally appealing

_________________
Jonathan Foucher

Take a look at the Planck 6502 computer.