I've spent some time writing up a new pinout for an RC2014 (40-pin, but sometimes 39-pin) bus. There is an existing "RC6502" bus standard well documented here. Perhaps in a fit of not invented here, I proposed a new pinout. Primarily, it updates the clock pinout to use the single PHI2 signal for modern WDC 65c02s. I also removed the SYNC line in favor of BE, and added MLB, for possible DMA experiments down the line.

I can't seem to format a table on here, so I put it into a markdown document.

This is for a design that I don't ever intend to run above 8MHz, so I'm happy to live with the electrical properties of existing RC2014 backplanes.

Let me know your thoughts!

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

There are certain issues with that "standard." :-) I'm the one that wrote most of that file, and I did it based on reading through and interpreting schematics, so it's not always a coherent design, and some pins may never even have been used in the way they're interpreted in that document. Not to mention that I probably made some sub-optimal choices here and there when deciding between different schematics' naming and interpretation of some of the pins. I think you may be addressing some of these with your design tweaks, which is very welcome!


Well, I think it's clear that PHI1 can go: nothing takes that as input as far as I know, and I see no reason anything would need it. So that's ripe for reassignment in the "standard," actually. The only modifications that might require on old boards in new systems is to cut the trace to that bus pin on old CPU boards.

As far as PHI2 goes, I'm not actually clear on why all the RC6502 peripherals use PHI2out from the CPU (bus pin 19) for clock inputs and write qualification rather than just using the system clock on bus pin 21. If there's no good reason for this it might make sense to drop PHI2out and have just one PHI2 clock pin. Whether it's 19 or 21 depends on whether you want to have to cut traces and solder jumpers on your existing CPU or peripheral boards. :-) (I'm inclined towards the former, though I've not put much thought into it.) Anyway, this also seems something that one might work towards in the standard, deprecating older versions for the sake of making the standard more broadly useful. (And I do prefer CLK as a name, as it happens.)

By the way, you've pin 21 mislabeled as PHI1I in the RC6502 column of your document.


Yeah, BE and MLB on the bus sound like a great idea to me. But it might be worth carefully considering the assignments with an eye to maximizing potential compatibility. I'm not saying that things can't change, but that we should work through what needs to do with old boards to update them for the new bus, and the effect of new boards in old systems, and pick the assignments that give the best strategy for this.

Here's an example off the top of my head. (I'm not saying that this example is well thought through, but just that it's the kind of direction I'd like to see people thinking in.) SYNC is currently used only by the debug board, so if it's really not that useful on the bus (which I tend to agree with), we could remove it from the standard. Then:

• The only board that takes SYNC input is the debug board, so for that you cut the SYNC trace on the debug board and instead run a pair of jumper wires for SYNC and its GND return from the debug board to the CPU board.
• Only CPU boards generate SYNC, and only CPU boards would generate MLB, so if we're dropping SYNC it would make sense to put MLB on that pin. With new peripheral boards and an old CPU, you may need to cut the trace to that pin on the CPU board. With a new CPU board and old peripheral boards you need do nothing except for the debug board above.

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

This is my version of RC2014 bus for 6502 as implemented on CRC65. https://www.retrobrewcomputers.org/doku ... rc2014_bus

The pin assignments are quite similar except RC2014 pin 19 is unassigned and pin 23 is NMI. Pin 35 to pin 40 are unassigned.

Currently there are 4 boards that work with the modified RC2014 bus: CRC65, VGA6448 with PS2 keyboard, Quad Serial board, and CPLDTIL discrete LED display. The 6502 clock is nominally 14.7MHz, but the goal is overclocking W65C02 to 25.175MHz and run everything at that speed on a 5-slot RC2014 backplane.

Bill

I'll update my document with the RC6502 pinout actually in front of me to get things right. thanks for pointing that out.

As far as I understand, though would love any experts to chime in, the 65xx peripherals are all designed to use the Phi2 signal. On older 6502s where you were using the onboard oscillator, you'd need to use the Phi2O signal from the board (since there's not one single CLK in).


I absolutely agree. I think my current pin assignments may be biased toward compatibility with the RC2014 bus more than with RC6502 (i.e., IOREQ becomes an EX line that can be easily assigned to the output of address decoding for IO select). I will have to take a closer look at the existing RC6502 board designs to think through some of these reassignments.

Your point about how SYNC/MLB both would be coming from the CPU board is well taken, I will definitely take that under consideration.

Plasmo, I'll add your pinouts to the table as well, with a link to your boards!

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

Right, which is fair enough: if you're using the onboard oscillator you need to get φ2 out somehow so that other things in the system can use it. In that case, you'd just send that to the one φ2 or CLK line in your single-clock-line design.

The use of CPU φ2out when also using φ2in is looking more and more wrong to me; none of the Apple 1, Apple II, Apple IIc or Acorn Electron do that and it can't even be done on the 6501 or the Commodore 64's 6510 because they have no φ2out (neither have an internal oscillator). I've started an issue in the RC6502 project asking about this; if you find any examples of systems other than this one that use this φ2in/out split, posting them there might be helpful. (Or feel free to comment there if you have any knowledge about this.) It might be worth starting a separate thread here, too, about this.


I have long wanted some partially-decoded I/O selects on the bus to reduce the amount of decoding I need to do on individual boards, and was planning to jumper some of the '138 decoder outputs from the SBC to pins on the bus. I'm obviously not the only one with this idea; have a look at the Third Party Modifications section for some extensions that an anonymous Japanese hacker did. (I think that this is the same guy from whom I bought my A1 SBC kit.) To my mind the most obvious selects to semi-standardize would be:

1. $C000-$CFFF (4K): a very common (almost standard?) I/O area left free on the SBC (and most Apple 1 replicas, I would think). Can easily be decoded into 512 byte blocks with a '138 on the peripheral board. JP guy puts this on pin 39, which suits me just fine.
2. $D000-$DFFF (4K): another perhaps sightly less common I/O area in the general case. Entirely used on the SBC, but it can be fully freed by disabling the PIA or partially freed by adding more decoding logic to the SBC. (I have yet to work out the simplest way of doing that.) JP guy does not use this.
3. $8000-$BFFF (16K): This is my idea: a larger space for additional RAM, ROM, video memory, whatever. A '138 on the peripheral board can decode this into 2K blocks. JP guy does not use this.
4. $A000-$AFFF, $B000-$BFFF. Smaller chunks from my "large area" above that the JP guy uses on pins 35 (repurposing TX) and 36 (repurposing RX). I don't particuarly feel that these are so useful when we already have $C000-$CFFF that easily gives us eight peripherals, and $D000-$DFFF for another eight with not much work, but those two pins are also kind of out of the way, so leaving them for his thing or semi-standardizing this seems reasonable to me.

One last thing I'd like to mention: as well as the obvious 6800 and 6809 CPUs, I'd like one day to be able to stick a Z80 (or similar Intel-ish) CPU board on this bus with minimum (ideally no) modifications to the 6502/6800/6809 periperheral boards and the bus itself. (I don't mind having a fair whack of glue logic on the Z80 board to make this happen; better one expensive CPU board than an entire second system.) I don't know off-hand if that has any effects on the bus design, but I'd welcome input into that. (There's a topic for this that I posted a year or so ago, but that produced nothing definitive. The 6809-based Fujitsu FM-7 does this with a special slot for a Z80 card; I should try to document that for insight in this area.)

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

In CRC65, the expansion I/O memory space is 0xE800-0xEFFF.



The link you provided didn't work. I'm interested in reading about your idea.

I have also have remapped the RC2014 bus to create a generic processor bus to explore processors of 1970's and 1980's with 8-bit data bus. I called it G8PP. It currently accommodates Z80, 6502, 8085, 6809, and 68008. In G8PP bus the address, power, data pins are fixed, but control signals are assigned to CPLD so they can be changed by reprogramming the CPLD.
Bill

Whoops! Somehow the scheme got changed from `http` to https` when I was editing. I've fixed that, and I've also linked the FM-7 mention to my notes page for that machine; there you can find links to technical manuals and suchlike, in case you want to investigate that. (Most of the detailed information has text only in Japanese, of course, but the diagrams and schematics usually use English names for signals and are fairly clear even without Japanese knowledge.)


That looks pretty cool, and I'm going to take some time to study it. It looks as if it basically changes the bus pin assignments as necessary to suit the processor, though, right?

Just to be clear, what I'm aiming at with the "Z80 board on RC6502" thing is re-use of existing peripherals, even if that ends up with the Z80 system being less good or flexible in other ways, such as being unable to use 8080 IO space "ports" to access devices across the bus or mapping those to memory address space on the bus. A typical use case for me would be to test prototype Z80 code to use a new peripheral I've built: I'd have the peripheral board, an EEPROM board and a 6800 board plugged into the backplane, use the 6800 to program the EEPROM with the Z80 code I want to test, and then swap the 6800 board for a Z80 board and boot. (I'd either rejumper the EEPROM board or perhaps just invert A15 on the Z80 CPU board or something like that.) That would let me provide Z80 sample code to drive the device without building a second version of the peripheral for RC2014 bus or whatever.


Ah, right. And we should expect plenty of designers will want to maximize their contiguous RAM even at the cost of more decoding logic (not much more cost if you're already using a PLA, I suppose :-)). I had thought about this and forgotten about it (I really should have written this stuff down last year when I was first thinking about this design), so thanks for the reminder.

What I think we actually want to do is label a set of pins "/IO0," "/IO1" and so forth. /IO0 would be roughly defined to be the most common "expansion" or "external to CPU board" I/O space for each CPU board, so in the case of the A1 replica this would select for $C000-$CFFF and in the case of your board it would select for $E800-$EFFF.

Dealing with the sizes of the range is an interesting problem. Here's one thought off the top of my head. If we define the "standard range" of /IO0 and /IO1 to be $1000 the peripheral board will be responsible for decoding A0-A9. After the lowest bits for individual registers in the device the remaining bits would determine the base address of the peripheral, and I would typically use some jumpers to allow changing that. If we also suggest that we allow similar configuration for ignoring the most significant bits then the registers become mirrored in the length $1000 space: ignore A9 and you get mirrors at $0 and $800, ignore A9 and A8 and it mirrors at $0, $400, $800, $C00, etc. This allows those with CPU boards with larger I/O spaces to make full use of them, and those with CPU boards with smaller I/O spaces starting at offsets, such as $E800-$EFFF or $FC00-$FDFF, to enable the mirroring so they can still address those devices. Does that make sense?

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

The available IO block on a Garthy/BE is $4000-$7FFF. This is generally decoded linearly (a device chip select connected directly to A13...A4) into ten IO devices of 32 bytes, so only one "standard" /IOx would suffice for my designs purposes. I'd propose putting it in pin 26 with my current layout, but could be moved around. On my SBC at least, I'd like to keep the Ex lines jumperable to a slew of more interesting signals.

I'd certainly be interested in anyone figuring out the circuit to run a 6522 off of a Z80 bus, that properly enables the chip for read and also keeps the timer counting... I should probably post this in that other thread.

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

I quite like how Stephen Cousins puts jumpers between the Tx/Rx/Usr1-4 lines of his RC2014 backplanes, to allow separate functions for different sections of the backplane.

It makes me think, and it's getting late for me and I should spend more time on this, but there's something tangentially interesting we could do. Next to the "controversial" signals on the RC6502 bus (19,23,26). There should be enough room to put a three-pin header next to each of them on newer CPU/SBCs. Then it's a matter of assigning one of two possible signals to each of those pins. Easier to move around Sync/MLB/BE/IOEN? This may be an overengineered solution, and instead picking something and going with will help everyone move forward (and leave the old clock signals behind us).

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

You're talking about this design, right? So basically you have one line generated by the CPU card indicating access in the 16K $4000-$7FFF block, and all further decoding within that block is done on the peripheral cards.

The "decode based on one address line" thing is cute and clever, though I don't think I'd use it myself because mirroring multiple devices into much of the address space makes me nervous. (I'm pretty sure that, no matter how often I remind myself never to touch those addresses, I'm likely to go and access them someday and cause contention.) This is why I like to decode more bits on the CPU board; decoding 4 bits giving 4K blocks lets me use a single '138 on a peripheral board to select out one of eight never-contending 512 byte blocks.

Anyway, the first thing I'd suggest is that pin 39 be nominally established as a 4K I/O select unless you have a really strong reason to make it something else, since it's already used for that in the JP guy's systems (and it was my plan to use it for that on my systems, too). Then you've got a couple of different options for approaching this with some compatibility in mind.

One is just to use pin 39 to select your entire 16K space, causing cards designed for full decoding of a 4K space there to mirror their addresses in each 4k segment. (Presumably you wouldn't be using too many of these cards so it wouldn't be too big a deal. But that does make avoiding conflicts between the "'138 select" and "A13-A4 select" cards kind of tricky, I think; I'd need to draw up a diagram to wrap my head around this.

Another is just to use slightly more decoding and generate three I/O signals along the lines I was thinking for my boards: two 4K and one 8K space. This is actually a pretty simple variant of Graham's scheme: the 8K is the AND of the 16K I/O select and A13, and the two 4K spaces are just under that selected with the 16K IO, A13 and A12 in a similar way. You then lose A13 and A12 as device selects, but gain either a lot more devices or free up a bunch of address space for other stuff. (I personally would be using the 8K select to select an EEPROM for programming and similar things.) You can still use one I/O line plus A11...A4 as selects as per Graham's scheme.

I think that for maximum compatibility it would make sense to use pins 38, 39 and 23 for this, so that older systems need only disconnect pin 23 on CPU boards that were driving it with PHI1 to avoid driving the select on newer peripheral cards. (And if they're generating the appropriate signal for it, they can jumper that to the now-disconnected pin.) Then I'd put /ML on pin 26, replacing SYNC, assuming we agree that SYNC is so rarely useful that it never deserves a bus line on systems that need /ML. (It can safely remain SYNC on older systems using the debug board.) BE can then replace whichever the PHI2 clock signal we decide to remove. (I think that it's 21 that gets dropped, but I haven't mapped out all the implications of this yet.)

Some notes on the latest version of your markdown document:

• /MLB should be /ML; the B stands for "bar" and is an alternative convention to an overbar or a slash prefix to indicate negative logic. What you have there is double negative logic. :-)
• I am wondering if /BE (negative logic) should be BE (positive logic) since the W65C02 BE and 6510 AEC pins are positive logic. I am suspecting that people will more often be using a W65C02 than a 6502 with external 3-state transceivers that have only negative enable.
• I like the idea of using Tx/Rx as SDA/SCL for I2C, which I'd not noticed earlier. But I'd say let's make that an option, rather than abandoning Tx/Rx entirely. I think that any boards driving or reading those should actually have a jumper or two to disable those lines given the multiple uses they seem to be acquiring. (The JP dude uses them for more I/O selects, remember.)

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

Yeah, I really liked that too when I saw it, and I think I had some plans relating to that, but I now can't remember what they were. :-(


See my message above just now re assignments for BE etc.: I think it makes more sense to put /ML on 26. That fits in really nicely with a jumper because both SYNC and /ML are outputs from the CPU board, so you can just select one or the other depending on which peripheral cards you have in. So yeah, I like that.

Something similar might be done for BE vs. the clock lines; we need to work out the details of the in/out PHI2 signals and which one goes by working through the various scenarios of CPU boards supplying clock, CPU boards not because a clock board is supplying it, and the peripheral boards. That's assuming that we find no good reason to keep both phi2; I'm watching issue 26.

Putting an I/O select on 23 (replacing phi1) seems to make sense to me because it seems pretty clear that we can snip the pin on everything generating phi1 because it's never needed, and those boards will never need a I/O select as an input, but might bodge-wire it for output if the CPU board has the decoding for it.

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

The BBC Micro uses phi1 to synchronize a lot of things, externally inverting it for many of them. The Electron is a more weird case though because really the ULA is running the show there, not the 6502.

I believe in early datasheets the 6502's clock input was called phi0, and there was a significant delay between phi0 and phi2. So I guess there could be some cases where it was important to use phi1 or phi2 rather than phi0. phi1 and phi2 are also guaranteed to be non-overlapping.

WDC's modern recommendation is very clear on this point though, you should just use phi2in with their processors.

Sure, but the question here is not whether φ1 is needed or not, but whether it's needed on the bus. φ1 can always be generated by inverting φ2, but that of course introduces a slight delay which might cause trouble in some applications. I don't know for what kinds of applications this might be an issue and whether these applications are the sort of things one would expect to be able to build on to peripheral boards separate from the CPU and/or clock board.

I do note that most of the lower-pin-count 6502 variants (6503, 6504, 6505, 6507) dropped the φ1 output, and the 6501 and 6510 required a φ1 input as well as a φ1 input.


That was also MOS's position, not just recommended but enforced, for the 6801 and 6810 processors. (Neither had a φ2 output, and both required an external clock generator.)

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

I was having a look at the 6502 CPU board for plasmo's RC2014 bus G8PP board and I noticed that it brings VPB (vector pull) out to the bus. According to the W65C02 data sheet:


I'm not seeing any easy way to use this a modular system, though, since for something to supply a vector it would have to be able to disable anything else wanting to supply the vector, in particular the ROM that's usually in the system and decoded at the vector addresses. But if anybody does have any thoughts on this, I'd be interested in hearing them.

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

I was exploring 6502 at the time (late 2018) so I didn't know about VPB's usage. Since CPLD has plenty of I/O, I just hook it up to CPLD. I don't think I ever used the VPB signal.

With the G8PP concept, the control section of RC2014 bus (pins 19-26) goes to CPLD so it is fully reprogrammable to accommodate different timings of various processors. The CPLD standardize the processor-specific timing to work with the RAM, serial port, I2C, compact flash timing needs. CPLD is really the heart of G8PP--RC2014 bus is the pipeline to bring processor-specific signals to the CPLD; CPLD is in the center stage translating processor's control signals to various standard device interfaces; and processor can be changed by reprogramming CPLD and loading new software, no other hardware changes are needed.

I have followed your link to other discussions. There are lots of ideas being talked about. I also thought about a modular system like RC2014 with one device per board except the modular system can handle diverse set of processors (with 8-bit databus) where a processor can be changed out without changing the rest of the system. I called that PRCC but I have not done any works other than the concept.
Bill