It's probably also worth mentioning the Z50 bus, which was designed for compatibility with the RC2014 ecosystem, but has 50 pins in a 2x25 connector outline, so things are a little more mechanically stable. It looks like the designer did think through how to put a 65c02 on their bus, but synthesize 8080 style bus control lines. http://linc.no/products/z50bus/

I particularly like how well the bus standards are documented.


I've considered adding "ROM Inhibit" as a signal on my "unassigned signals" breakout, so it could theoretically be assigned to an EX pin and used along side VPB.


Updated the table for ML and BE. I need to train my brain that B stands for bar, and not "bit".
Re: tx/rx vs sda/scl, I do have the I2C pullups on my board design, but with easily cut traces to make the signals float normally again. I actually quite like how the z50 bus specifies that Tx/Rx be reconfigurable and easily split along sections of the backplane. That may be an appropriate thing to incorporate.

_________________
https://github.com/Individual-Solid/

Ok, that's great to know. So I'm not missing anything huge here about how VPB is used.


Ah, another pile of reading. I look forward to seeing those ideas.

But this reminds me, it might be a good idea to write up some design goals as well just to make it easy to review proposed changes against them. For example, the 39-pin single-row layout of RC6502 is a deliberate trade-off of reliability (in several different ways, including human insertion error) for cost (cheapest possible connectors and PCBs). So that means that while an optional pin 40 probably makes sense (it's on the connector anyway so instead of cutting it off we hand-wire it—I actually still have the pins on my backplane board because it was more work to cut them off than leave them) adding an optional second row on the connector probably does not (if we're going to go that far then it's probably worth redefining other things too to clean up some of the messier stuff).



Yeah, that sounds like it's getting tricky enough that it may not be the kind of thing we want to try to go adding to this bus. My inclination for anything specialized and complex like this would be just to direct-wire twisted pairs between separate headers on cards, since that provides ultimate flexability and avoids contortions in bus design. (Or there's nothing stopping someone from just re-assigning I/O signals or whatever to this for their own purposes, if they're willing not to share boards, or use breaks in the backplane, or whatever.)


Is that on the CPU board? (I'd imagine that there are no other boards that would be mastering the I2C lines, right?) Or do you still need the pullups on systems with I2C present but not used on peripheral boards that also have other means of access or other utility? (I'm imaginging the situation where I use a CPU board without I2C with a peripheral board that does have it.) But also, hmm, old backplanes won't have this so it would seem that boards would always need to deal with something like this themselves, anyway. (Maybe, "completely passive backplane except for power" is also a design goal, not just for backwards compatibility but because right now an RC6502 backplane is also a basic RC2014 backplane.)

Also, I'd use jumpers instead of traces or pads to cut or solder, but same idea anyway.


Yeah, I like this idea too and keep coming back to it, and then I keep thinking that any boards using multi-purpose lines are going to have to have jumpers on the board to disconnect them anyway, so what's the point? The only reason to have jumpers on the backplane then is so that you could have a split backplane with some cards using the line for one purpose and some for others, but I'm not sure I see much in the way of scenarios for that where a CPU board would be using the lines for one purpose, but a couple of peripheral boards could also have their own separate use of those lines for something else. (Video terminal board talking to a UART board, perhaps?)

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

BTW, tebl has posted an answer on issue 26. I think he may be mixed up about what the original Apple 1 did, but I need to do some research on how the Apple 1 actually generated clock (without the 6800 mods) before I can go further.

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

I've traced through the schematic from the back of the Apple 1 Operation Manual and it seems to me that Φ₂out from the CPU is never used in the Apple 1. I describe my reasoning in more detail in my comment on the issue. Maybe someone here can have a look over that and let me know if I've made a mistake there?

So it looks like one of the Φ₀/Φ₂ clock lines can go, and after further thought I'm inclined to say it should be pin 19, leaving pin 21 as clock on both RC2014 and RC6502, even though that probably means modifying more old boards if they're going to run on the new bus (assuming there are more peripheral than CPU or clock generation boards out there).

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

I've just scoped out the Φ₂ and Φ₀ bus lines on my SBC (details here) and it's looking to me as if it's just giving more reason not to use the 6502 clock output.

• The 6502 is a Rockwell NMOS version. It might be relabeled (the date code is 1349) but it's drawing >100 mA, so not CMOS.
• Channel 1/yellow is the Φ₂ bus pin (21) fed by the board's 1 MHz crystal oscillator to the bus pin and pin 37 of the 6502.
• Channel 2/blue is the Φ₀ bus pin (19) fed by pin 39 of the 6502.
• Channel 3/pink is the Φ₁ output of the CPU, pin 3 on the IC. (The bus pin has nothing on it, maybe a soldering problem on my part.)

I'm guessing that this is pretty clear evidence that one doesn't want to be using the 6502's clock output if you've got an external clock generator, but I'm welcoming corrections and thoughts from people more expert on this than me.

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

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

My biggest gripe with the various RC6502 designs is the lack of a signal thst qualified the address on the bus, like /sel line.

It would allow
a) having own memory on the CPU board without interfering with the devices on the bus
b) reuse all the RC6502 boards in other useful setups
c) even allow positional selects like in the apple 2 by using e.g. a 74ls138 on the backplane.

I'm thinking of using RC6502 as extension bus, but I actually have actively pull address bits to a fixed value when not selected to avoid any spurios access. (Eg with a faster CPU board that decouples CPU from bus when accessing local memory. Even if Ax connected through I'd still need to decouple Dx and still have spurious reads. It's just not really worth it that way.)

Without that.... not interested..

André

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

Can you explain exactly what the /SEL line does? I don't recall seeing this on any of the RC* buses. How might a system without this line "interfere with the devices on the bus"? On all 6800-style buses the peripherals should be ignoring the address and data buses unless selected, should they not?

I think your idea of a decoupled bus is very different from the goal of the RC6502 bus, which is basically just to extend the CPU's bus signals directly out to a backplane, allowing a computer's components (CPU, clock, memory, peripherals) to be broken out on to separate boards. Indeed, the idea of even positional selects is moving well away from that. It sounds to me as if you want a completely different bus, one designed to keep peripherals separated from the main system, rather than a bus designed spread the main system across multiple boards.

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

But how is a chip selected? It detects the right value on the address lines.
The /SEL line "outsources" part if the detection process to the main board. Just look at the select lines for the apple 2 slots. That's actually a great design in this respect.

The z80 sytems IIRC have separate /rd and /wr lines on the bus. Those incorporate the equivalentof the r/-w and phi2 lines of the 6502 - but they can also be qualified with address selection. Not sure it does on RC2014 though.



Yes it seems I have a conflict of goals here. But even in a 6502 system like RC6502 this /sel line could mask the bogus read (+writes on the NMOS part) of the 6502, that you'd otherwise have to deal with. A bogus read on eg a 6526 can clear interrupts for example. Stupid chip design but a /sel derived from eg the 65816s vpa and vda would protect from this (granted, the bogus reads of the 65816 are less dangerous but still)

Besides even if the RC6502 CPU board just pulls the /sel line low all the time, it would allow for the IO boards to be used in many more systems. Eg in an apple 2 or c64 using appropriate adapters. Think of the marketing potential for board makers. At least I would happily use it for my system. Right now I'm more leaning towards a RC2014 bus in my 6502 because I _can_ qualify /rd and /wr with address selection.

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

To clarify my goals: I intend to extend my MicroPET with a bus system.

See here for the MicroPET https://github.com/fachat/MicroPET

Currently I am leaning towards apple 2 bus and RC2014. The latter for the reasons given above, and the ability to use existing board designs by qualifying /rd and /wr with address selection on the backplane.
I'd rather use an RC6502 type bus, because I find that rd and wr signal stuff awkward. But if that selection doesn't work, then no...

Edit: yes my goal for the RC6502 would be like a stripped down version of this bus http://6502.org/users/andre/csa/bus-1.1.html that I used to extend the CPU bus to potentially many IO boards.

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

RC2014 does not have any mainboards on the market today that send a different /IOSEL to each slot, or qualify /rd /wr based on the slot you're in. A 74HC688 comparator chip is pretty standard on most RC2014 peripherals that don't have a fixed address. You set a mask for bits in the addr you care about.

However, I think there may be some compatibility in ideas here. We've discussed permanently assigning Pin 39 (currently EX2) to /IOSEL. This would be provided by whatever board (be it a SBC or a module) does the main memory decoding for RAM/ROM. It's expected to decode at least 1k worth of address space, but we're still discussing exactly how to spec that.

You could certainly design a backplane that qualified R/~W~ with IOSEL and an on-backplane '688 instead. Each slot could be assigned an exact address, and if peripherals continued to use the '688 on board, then they could just mask off no bits (and always be enabled by the qualified R/~W~).

_________________
https://github.com/Individual-Solid/

In my http://6502.org/users/andre/csa/bus-1.1.html I had an /IOSEL for 2k io space, and typically a '688 on every board to select its slot. Pls look at the various boards I had built as example, as linked from the bus page.

You cannot qualify r/-w on a 6502 with address selection, you can only convert a write to a read. That only works for intel/z80 type separate/rd and /wr lines. But maybe I misunderstood your comment.

In RC6502 what you basically need is a board that does the address map. That could probably be a "personality board" that would maybe contai RAM and ROM and create /IOSEL according to what type of computer should be'emulated'.
The lack of separate ram and rom select lines on the bus prevents separating these features. Maybe except for 32k RAM on the lower address range.

Using only the CPU bus lines (more or less) on RC6502 is jumping too short...

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

Oh and providing an /IOSEL would immediately allow to port idk 5-10 of my IO boards to such an RC6502 without any change I would assume.

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

Ah, I hadn't seen your edit with the link in your last post. I'll take a look at your bus, more samples are always better for this conversation.

You're write, of course you can't qualify r/~W~ on the 6502, that was a brain blip.

I quite like the idea of the "Personality" board. I was already thinking about RAM/ROM/Decode being a separate card from the 6502/Clock/Reset in a someday maybe build.

Naively, I'd say /IOSEL and an active high CHIPSEL, but we're really digging into what can be done on the 40 pin connector.

_________________
https://github.com/Individual-Solid/

If all you're looking for is to let some boards that do decoding put their decoded selects out on to the bus, read though the previous posts in this dicussion: that's exactly what we plan to do. In fact, some people are already doing this; we just intend to formalize it a bit more. So no fear there.

But you seem to keep bringing (perhaps unwittingly) timing into this discussion. Pardon me if I'm misintepreting you and you're not, but if you are, keep in mind that the address mapping selects will NOT be usable for any timing purposes, just as the address bus itself is not. You'll need to use Φ2 for anything related to timing, just as usual.


Right, but that's nothing to do with timing and cannot be used for any sort of timing. The 6502 has full control of the address bus at all times (unless you put a tri-state buffer in front of it to let you cut it off), and you must never assume that the timing of any signal change on the address bus means anything. The same goes for other non-clock lines, too, which is why all writes should always be qualified with Φ2.


Yes, as you point out, /RD and /WR are different because they include timing information, unlike RWB or the address bus from either CPU. (Perhaps this is why you sound to me like you're talking about timing.) And being separate signals they also incorporate "enable" communication (unlike RWB) and so could be manipulated by the CPU board not to assert on the bus while at the same time asserting for local peripherals on the CPU board (based on address or anything else). But I don't see anything like that appearing in RC6502 bus or variants of it, that's just too alien to how the Motorola-style buses work. If you wanted to do something like that, it would probably make more sense to put your 6502 on RC2014 bus.


Yeah, it could, but then you put a huge implementation burden on everybody making boards that drive that line to implement the timing for it correctly, and all old RC6502 CPU boards need non-trivial modifications to do this, if it can be done at all. If you're going to go that route, I'd say you're making a new bus.

I'm not saying that it's not a problem worth solving, I'm just saying that RC6502-style systems live with the problem (and from this gain certain other advantages, such as simplicity) and if you're wanting to solve it in the way you propose, you're no longer wanting an RC6502-style system.


Yeah, that really sounds like the better way to go for your purposes.

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