RCBus specification

[Steve Cousins]

I've started to put together the various suggestions and contributions for the RCBus specification. See attached.

There is a long way to go but feedback would be appreciated.

One fundamental issue I'm having trouble with is this: If you want to design a 6502 CPU module you have a choice to make about interfacing to the backplane. Do you try to generate Z80 compatible signals so it is compatible with existing RC2014 modules, do you just support 68xx bus signals so it will only work with other modules implimeting 68xx signals, or do you provide both sets of signals to the backplane for greatest compatibility.

If you support Z80 style signals the 6502 CPU module will still not be compatible with all existing RC2014 modules. For example, the 6502 memory map requires ROM at the top of memory not the bottom, and also a space for I/O needs to be mapped into memory. That sounds like a big issue, but actually not all RC2014 modules can be used at the same time. Compatibility will always have its limitations. So perhaps this is a red herring.

In any event, the problem I'm having is how to specify what is and isn't required for compatibility. Should the RCBus-68xx specification only include 68xx bus signals or should it include the standard Z80 signals as well? In my mind, if the CPU module only supports 68xx signals then it is only compatible with the 68xx sub-set of RCBus. If it supports only Z80 signals then it is only compatible with the RCBus-Z80 sub-set. If it supports both sets then it is compatible with bith sub-sets of the RCBus spec. This suggests the RCBus-68xx spec should only include signals relevant to the 68xx. But given that there will likely still be significant compatibility issues, is the the right approach?

The alternative thinking I have is the core bus specification should include as many signals as possible even though some will not be relevant to a specific modules (rather like it is now with some RC2014 modules) or to a class of modules such as those using 68xx style signals. Using this approach only the few special signals that share pins with other signals need to be highlighted in specific sub-sets of the spec.

I'd appreciate thoughts on this issue.

Steve

[Alan Cox]

On Tue, 21 Feb 2023 at 16:21, Steve Cousins <steve...@gmail.com> wrote:
> One fundamental issue I'm having trouble with is this: If you want to design a 6502 CPU module you have a choice to make about interfacing to the backplane. Do you try to generate Z80 compatible signals so it is compatible with existing RC2014 modules, do you just support 68xx bus signals so it will only work with other modules implimeting 68xx signals, or do you provide both sets of signals to the backplane for greatest compatibility.

You generate the Z80 style signals. If you didn't want to generate the
Z80 signals you'd use one of the other bus designs for a Motorola bus.
All the current "other" CPU cards from 1802 to Z8 take this approach.
I think of it as analogous to S100 / IEE696 in this respect, except
it's a lot simpler and doesn't require a PSU of similar size and power
consumption to a small microwave oven.

> If you support Z80 style signals the 6502 CPU module will still not be compatible with all existing RC2014 modules. For example, the 6502 memory map requires ROM at the top of memory not the bottom, and also a space for I/O needs to be mapped into memory. That sounds like a big issue, but actually not all RC2014 modules can be used at the same time. Compatibility will always have its limitations. So perhaps this is a red herring.

In practice I think this is not a problem. The 512K memory card starts
with ROM mapped over the full 64K so just works. The 32K/32K card has
a jumper. The flat cards almost all have a jumper. Only the old paged
ROM board and RAM combo (that nobody uses) doesn't.

For the I/O with a 256 byte map at $FExx you've got the classic 8bit
256 I/O ports so the only things that don't work are cards that use
full 16bit I/O port decoding (very very few: QUART, ZXKey, dual port
RAM interconnect, and Bill's VGA ?). It's also possible to deal with
this by putting an extra latch on the CPU card so you can set the high
byte of IO cycles. I've just never bothered because it's really not
that important.

> In any event, the problem I'm having is how to specify what is and isn't required for compatibility. Should the RCBus-68xx specification only include 68xx bus signals or should it include the standard Z80 signals as well? In my mind, if the CPU module only supports 68xx signals then it is only compatible with the 68xx sub-set of RCBus. If it supports only Z80 signals then it is only compatible with the RCBus-Z80 sub-set. If it supports both sets then it is compatible with bith sub-sets of the RCBus spec. This suggests the RCBus-68xx spec should only include signals relevant to the 68xx. But given that there will likely still be significant compatibility issues, is the the right approach?

I see it as an appendix. You take RCbus and you choose to add some
extra lines for convenience if you want. If you are running just
Motorola bus devices and don't care about RCbus you'd use a different
bus to begin with.

I see it this way
- RCbus is a bus specification that happens to use Z80 like signals at
TTL logic levels with CMOS logic.
- The point of RCBus is to be able to use RCBus devices

So on that basis the starting point has to be compatibility. The extra
lines are a convenience for a few things, not the norm. In fact I/O
cards intended for 65xx/68xx should try not to use them unless needed
so they are still compatible with Z80, 1802, 68000 whatever.

> The alternative thinking I have is the core bus specification should include as many signals as possible even though some will not be relevant to a specific modules (rather like it is now with some RC2014 modules) or to a class of modules such as those using 68xx style signals. Using this approach only the few special signals that share pins with other signals need to be highlighted in specific sub-sets of the spec.

I would like to see a base set (I/O cards attached to a mainboard with
all the other stuff on it), the classic 40pin and bigger variants
documented as such. I'd prefer the "and this is useful if you run CPU
x" bits to be an addition not a core part of the bus. I'm not sure
they are even properly "RCbus" so much as "and here's a useful
convention on assignment of the user pins"

The base set is probably very small and that may be useful - it's what
VCC/GND/D7-D0/A7-A0/IRQ/IORQ/RD/WR/RESET (and maybe M1) ?

Alan

[Jordi Autocet]

Steve,

This has no solution. It is necessary to think of an RC Bus sectorized by micros, then, from this go to a serial bus, or like the IEEE488, parallel with its own protocol. Ultimately we will have to go to die in an MPI or OpenMP. It would be wiser to separately names like RC-6502 or RC-Z80 or RC-68XX and make conversion modules that adapt from one backplane to another.

Sorry for the intrusion. I say this because I have studied it a lot. The 80 pin limit is very small. S100 didn't get away either.

Good luck with the adventure, it's really cool.

Jordi Breu

Missatge de Steve Cousins <steve...@gmail.com> del dia dt., 21 de febr. 2023 a les 17:21:

--
You received this message because you are subscribed to the Google Groups "retro-comp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to retro-comp+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/retro-comp/62e3c208-6d6d-41ac-802d-7727b9d97cf6n%40googlegroups.com.

[Alan Cox]

RC-6502 is an existing thing and has been for some time. It's an "if I
did RC2014 with 6502 it would look like this" bus but it's not
compatible with RCBus so solves a different problem.

In fact Bill already has RC6502 bus cards...

[Tadeusz Pycio]

I think compatibility of all modules for different architectures is impossible without introducing another layer as Jordi mentioned. Signals, e.g. in 6502 have to be adapted to universal I/O chips, memory anyway, so making them compatible with Z80 standard is a good direction for RCBus. Architecture-specific I/O circuits should work with that architecture on RCBus, with others not necessarily. For example, I don't know if anyone has managed to get a Z80 SIO to work with the 6809. As Alan mentioned, the basic kit is small.

I mentioned earlier that I have a Z80 training kit and there is one MEM_EN signal that is worth putting in RCBus space. Obviously it won't be compatible with existing memory module solutions, but as a prospective solution because it does the trick of injecting code onto the bus. A similar solution has been used in the Z80-MBC2, V20-MBC from J4F. This could be useful, but I assume it will require dedicated modules.

[Alan Cox]

I don't believe anyone has ever gotten the classic Zilog peripheral
chips to work with anything but a Z80 or Z180 (and maybe Z280 in 8bit
mode ?). They have magic knowledge of the internal behaviour of the
processor. The later stuff you can (but the later stuff like the Z8530
is instead a pig to nail onto a Z80)

The only cards that don't work with the other processors that I know
of are some of the ACIA boards (because of the way their motorola bus
interfaces are glued to the Z80 bus), the Zilog peripherals and the
cards using 16bit I/O.

The 16bit I/O is doable if wanted, and I think Phillip got his 8085
generating the signals correctly for the 68B50 to work ?

The other oddments are electrical issues - unbuffered CF with NMOS
devices (affects NMOS Z80 as well) and cards that are naughty with
voltage levels (not shifting 3v3 because they know the CPU is a Z80 so
TTL level high/low)

Alan

[Mark T]

I was thinking PAGE could be renamed RAMEN, as this is its function with the pageable ROM and 64K ram modules. This can also be used in systems without Pageable ROM to provide code injection with RAM disabled.

I was a little confused on first reading of Steve’s document when I saw RCBus-Zx80, until I realised this was for both Z80 and Z180 rather than the old Science of Cambridge machine. Would Z*80 cause more or less confusion?

I think supply voltage should be defined as 5v, but if someone feels the need to build a 3.3v system they should make that very clear in their documents. Regulating down to 3.3v is very easy local on modules for supply to sdcards etc.

Signal levels on the bus should meet TTL input levels for compatibility with nmos on some older devices, with 5v tolerant inputs. I think cmos input loading should be recommended, not proscribed. Output levels should be recommended as 5v HCT outputs, again not mandated. 

[Mark T]

Sorry, that should be 5v tolerant inputs and outputs, for cases where a 3.3v device is driving ttl compliant outputs onto the bus.

[Ed Porter]

On 21/02/2023 18:56, Alan Cox wrote:
> I don't believe anyone has ever gotten the classic Zilog peripheral
> chips to work with anything but a Z80 or Z180 (and maybe Z280 in 8bit
> mode ?). They have magic knowledge of the internal behaviour of the
> processor. The later stuff you can (but the later stuff like the Z8530
> is instead a pig to nail onto a Z80)

Pages 198-205 of "THE Z8000 MICROPROCESSOR A Design Handbook" by Bradly
K Fawcett shows some TTL glue to attach Z80 peripherals to the Z8000
bus, including an I/O port to generate the ED4D RETI sequence at the end
of an interrupt service routine. It does look like more trouble than
it's worth.

https://archive.org/details/bitsavers_zilogz8000andbook1982_15357800/page/n207/mode/2up

-ed

[Tadeusz Pycio]

I would like to clarify the meaning of pin 60 - PAGE (although a better name would be RAM_EN). The High state enables RAM (all or part of it), the Low state disables its activity. This will allow existing modules using the PAGE signal to continue to operate (to disable ROM and enable RAM instead), and newly created modules will be able to temporarily disable all RAM in order to inject code onto the data bus by modules running on the Z80-MBC2 concept.

We still do not have assigned pins for the DMA service request signals. My suggestion was to use pins 78 (DREQ1) and 79 (DREQ2), but if others see the need to add DACK/EOP in addition to these signals it is worth considering another location (pins 45-48 ?).

[Steve Cousins]

I've updated the RCBus Specification to reflect the views above. This is mainly seen in the table of pin assignments where most of the traditional RC2014 pins are clearly shown as common to all processor types.

I've also padded it out a bit more with pin descriptions and connector details.

If there is anything you feel is wrong, not well presented, or missing please point it out. There are unanswered questions in the "Unresolved issues and notes" section.

Steve

[Alan Cox]

You have an appended where I think you mean appendix.

On the high address lines wiring them to 0v or 5v is bad if a wrong
card combination is used. It's also a problem because cards may not
even have those pins present. Perhaps

Current RC2014 systems use either 16bit or 20bit addressing and do not
support using a memory card that has more address lines than the
processor card. If a memory card is intended to be usable with
processor cards that have less address pins it should have pull up or
pull down resistors on the upper address lines.

ie
- it's optional
- nobody does it right now
- use resistors so it doesn't go boom if an error is made

[Steve Cousins]

I've made further progress on the RCBus specification. Most of what I think is necessary is now in place although use with more processor types need to be added - anyone???

It would be helpful if more members of the community could share their thoughts on the RCBus specification. It will only succeed if it is acceptable to most people here.

I'm sure there are lots of improvements that need to be made so feedback your thoughts please.

Steve

[Mark T]

I think I would prefer BAI/BAO at the same end of the bus as IEI and IEO. Partly because then Z80 is allocated existing user pins and leave n41 to n48 for functions not used by z80 processors, and maybe not for any of the 8 bit micros. I think that also works better with the option of IEI/IEO and BAI/BAO to be via  link wires between modules and only having those at one end of the modules rather than opposite ends. Its likely that a module using BAI/BAO would also need IEI/IEO.

I have considered using RCBus for INS8060 or INS8073 to reuse modules with these two processors. I think these have a close enough match to z80 interface to not need their own bus variant. I expect SIn and Sout to rx and tx. Sense A to Int. Sense B and flags to user pins. Possibly using refresh for NADS, though I think this could be limited to the processor module. BAI/BAO would be reused for NENIN and NENOUT. 

[Alan Cox]

> I have considered using RCBus for INS8060 or INS8073 to reuse modules with these two processors. I think these have a close enough match to z80 interface to not need their own bus variant. I expect SIn and Sout to rx and tx. Sense A to Int. Sense B and flags to user pins. Possibly using refresh for NADS, though I think this could be limited to the processor module. BAI/BAO would be reused for NENIN and NENOUT.

That was my conclusion some time ago - I've just never found a source
of INS807x parts at a sane price to bother turning the PCB design into
a board. Passing NENIN/NENOUT would make sense. I just had those as
flying leads so you could run multi-processor if you could afford to
spend $150 a shot on possibly dodgy remarked parts.

Alan

[Brad Hines]

Hi All,

I've been enjoying the RCBus discussion.  Something just occurred to me last night that I thought I should mention, which is that I'm worried about the name "RCBus".  I'll leave it to all of you to decide what to do with it or about it.

The issue is the possibility of brand confusion between RC2014 and RCBus.  As someone who has just recently discovered RC2014 and Z50Bus and all of the above, I can say that it took me a couple of days to sift through everything that was out there and figure out what the situation was.  

One of the questions that one has to resolve as you peel all this back is "which came first, which is derived from which", and so on.  

I think if I had been coming into it and had seen both RCBus and RC2014, I would have been a bit confused.  To a newbie, the assumption would be that they are related, probably branches off the same tree.  And to a degree they are, but at the same time, our new RCBus is intended to be a fresh start, with different parentage.  And it definitely would have been confusing figuring out which is more recent.

To some degree, maybe we want the similarity of names for what that communicates.  But that's where one can run into trouble with trademarks.  Having dealt with this in my businesses a bit over the years, I suspect that we will have an issue with RCBus infringing on the RC2014 trademark.

Why?  The reason is that the way the trademark office looks at these things (at least in the U.S. - I am admittedly slightly out on a limb with extrapolating this to the UK) is, "What are the chances that a consumer will confuse the protected brand with the competing brand?"  If a realistic chance for confusion is present, the new mark is infringing.

If the owner of the RC2014 trademark seeks to enjoin us from calling our bus RCBus, I would give high odds that he would succeed.

So that was the thought I thought I'd share.  Feels like it might be good to pick a different name.

Brad

 

--

You received this message because you are subscribed to the Google Groups "retro-comp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to retro-comp+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/retro-comp/66b4c474-b868-4027-baac-cc046531900dn%40googlegroups.com.

--

Brad Hines
Brade...@gmail.com

[Tadeusz Pycio]

Hi Brad,
I think you have misread our intentions, RCBus is meant to unite not divide. If someone confuses RC2014 with RCBus it will not be a mistake, any RC2014 module will work on RCBus. This is not an attempt to build a new standard (a very tempting proposition) or to build a new brand. We want to standardise the naming and standardise the missing signals on the bus. If we don't do this, everyone will call it according to their own vision, use the free pins in the way most convenient for themselves. This state of affairs will create more confusion for new users. One final point, Spencer did not object to using a different name.
If the idea of RCBus were to be about something new, the bus would certainly change. I've only designed 15 modules, so I already know the disadvantages of this arrangement of signals on the bus. I have old-fashioned PCB design principles, I believe that power lines should be a minimum of 18 mils wide and I do not tolerate vias for these lines, and placing them on the bus in the middle leads to circus tricks to keep these principles for a double-sided PCB. This would certainly be the first thing I would change. Here no one wants to change it to be consistent with existing solutions.

@All
I have a suggestion that further ideas should already be concretised - name/meaning/no. pin.
We should have already released the first version of the RCBus specification, Steve has done a lot of work and we are still moving on general outlines of what should be in there. Maybe try to finish the bus for Z*80, 6800 and 6502 and then focus on developing for other architectures. For example, I don't know what signals we want to have for 68000 support, not counting byte select signals. Is that all this processor needs to run on the RCBus?

[TonyD]

Hi All

I've been following this discussion with great interest.

A couple of discussion points I would like to add is that of:

- Board dimensions
- External Connector positions

 

Thank you all for such a good and open discussion.

best regards

Tony

[Karl Albert Brokstad]

Good discussion. At last, we may agree on a standard.

My suggestion is that the name RCbus covers the general standard, and provision for different sub-standards like 40 and 80 pins connectors, giving RC40bus and RC80bus respectively. This a naming convention I have used on my designs.

Karl

[Steve Cousins]

I think the RCBus specification should suggest board dimensions and connector positions but not try to limit designers to them.

There are two common RC2014 module sizes in Spencer's range: standard and low profile. I think both of these should be suggested in the spec.

The low profile modules are the full 40 pins long, whilst the standard modules are 39 pins long. I'd like to start making my standard modules 40 pins long. Spencer's module template for standard size modules also places the bus connector slightly off centre which seems odd. I would like to suggest anyone making modules 40 pins long should centre the bus connector, as Spencer has done with his low profile modules.

In addition I'd like to add a larger module size to allow more highly integrated designs and to allow nicely spaced components and useful screenprint. I very much like Spencer's single function modules as it has a valid educational aspect to it and, well, it is just nice. However, once you are over that part of the learning curve it is desirable to have the option of fewer modules. Less soldering, greater reliability. Some people building kits have never done any soldering before so it is important to me to be able to space components out etc. to make the assembly process less intimidating for inexperienced makers. I don't really like the look of modules greater than about 3 inches (75mm) tall but I think I would still like to suggest a module size nearer 4 inches (100mm) tall.

Steve

[Alan Cox]

> To some degree, maybe we want the similarity of names for what that communicates. But that's where one can run into trouble with trademarks. Having dealt with this in my businesses a bit over the years, I suspect that we will have an issue with RCBus infringing on the RC2014 trademark.

To quote Spencer from the RC2014 list

"RCBus or RC80 Bus sound good to me. It takes the essence of what the
bus is without limiting it by what the RC2014 natively supports."

So we should be good on that front. It's not really about lawyers
anyway it was a polite request. Either way Spencer's quote I think
probably counts for estoppel ;)
Alan

[Alan Cox]

Some more chunks of text as suggested reworks and additions

[Brad Hines]

Hi Tadeusz,

To be clear, my point wasn't about intent, it was about legal jeopardy.  I think the goals you suggest are good ones.

I do still think confusion is a concern.  The use case is a newbie trying to decide on the backplane for his or her system.  Does the term inform which kind of backplane is recommended for a new system, or does it muddy the water?

In my case, when I got started with RCxx, I had to decide what kind of backplane modules to buy.  RC2014, RC40, RC80, Z50Bus?  There was a bit of alphabet soup, and no clear indication of which was the latest.  Once RCBus is complete and available, then a newbie would likely want to buy a RCBus backplane.  It would be a sadness for someone to buy a RC2014 backplane and then realize that the slick new card that they want is only available for the newer bus.  If our new bus were called "RC2023", for example, then it would clearly inform the user.  But that would likley run afoul of trademarks even more than RCBus.

As far as legal, it may be okay given what you said.  I'm not sure who Spencer is - if he's the owner of the RC2014 trademark and has blessed the use of the term RCBus, then I'm sure it's fine.  If not, we could end up in a situation where we are forced to change the name in a year or two or three.

It may be that RCBus is the best term.  To me the ideal term would capture the heritage but also let you know which came first.  Something like "RCNext"?  I'll be happy with whatever is chosen; it doesn't really affect me, just thinking about new folks entering the domain.  

Brad

--

You received this message because you are subscribed to the Google Groups "retro-comp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to retro-comp+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/retro-comp/29a9dea7-9b2c-4de4-9554-062133ebacf7n%40googlegroups.com.

--

Brad Hines
Brade...@gmail.com

[Brad Hines]

Just saw this.

I guess Spencer must be the trademark holder.  Yes, I agree that that puts us in the clear.

--

Brad Hines
Brade...@gmail.com

[Tadeusz Pycio]

Hi Brad,

You are quite right about the choice of backplane, but that is the only risk of error that can be made. I think the name RCBus will make it unnecessary to do an analysis of what RC2014, RC80, RC40 are, because for this environment they will become a homogeneous name. Of course, the modules that will be created on the new specification will not be able to make the most of their capabilities on the RC2014 backplane, but it will be possible to run them, without interrupt priority cascade, additional interrupt lines or be handled by DMA. The vast majority of kits can cope without these enhancements. I think we'll also be waiting a long time on the new standard for practical implementation of DMA usage - I only started needing interrupt priority cascade when I wanted to use RTM-Z80, and additional interrupt lines when building CP/Net, so these are not common used applications.

[brade...@gmail.com]

Those sound like well-reasoned arguments to me.  Thanks for the dialog.

--

You received this message because you are subscribed to the Google Groups "retro-comp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to retro-comp+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/retro-comp/c169c764-d9c5-4cf6-9fa0-49d41a6c19bdn%40googlegroups.com.

[Wayne Warthen]

On Tue, Feb 28, 2023 at 2:39 AM Steve Cousins <steve...@gmail.com> wrote:

The low profile modules are the full 40 pins long, whilst the standard modules are 39 pins long. I'd like to start making my standard modules 40 pins long. Spencer's module template for standard size modules also places the bus connector slightly off centre which seems odd. I would like to suggest anyone making modules 40 pins long should centre the bus connector, as Spencer has done with his low profile modules.

I don't have a lot of input on the RCBus specifications, but I strongly agree with a couple things Steve suggests here.

Yes, please deprecate 39 pin connectors.  Far too easy to misplug them.  Yes, please center the bus connector.  It simply makes no sense for it to be offset.  Since Spencer has already made those adjustments in his latest form factor, it does not seem like a problem to standardize that way.

Thanks,

Wayne

 

[Mark T]

Maybe keep the pin1 end of the module the same profile relative to pin 1, but extend the pin40 end of the module to centre the module on the 40/80 pin connector. I think this would avoid a random staggered apearance to the system, at least at one end of the bus.

I think Jlcpcb allows 102mm with before the price starts to increase, unless they changed that recently. Last I checked you could used 102.4mm as they round to nearest mm for pricing. This does have the disadvantage of locking in to a single supplier, unless any other manufacturers have started to support this.

[Sergey Kiselev]

Not sure if it is documented anywhere or was mentioned before. I'd recommend having connectors that normally go to external devices on the right side of the board, connectors that go to the internal devices (e.g. floppy) on the top, and indicators (and perhaps buttons/switches or configuration jumpers) on the left, more narrow side.

[Tadeusz Pycio]

A frequently raised issue is the difficulty of removing modules from the slots. It might be worth thinking about suitable holes in the PCB and trying to design ejectors to make this task easier. It would have to be a simple design that allows such a component to be made on a 3d printer. I don't know if there are any ready-made solutions widely available.

[TonyD]

On Wednesday, 1 March 2023 at 07:44:57 UTC Tadeusz Pycio wrote:

A frequently raised issue is the difficulty of removing modules from the slots. It might be worth thinking about suitable holes in the PCB and trying to design ejectors to make this task easier. It would have to be a simple design that allows such a component to be made on a 3d printer. I don't know if there are any ready-made solutions widely available.

Yes, I agree 40-pin connector cards can be difficult to pull out a backplane.

I've used these types of PCB card ejectors / pulls of other board designs.

https://uk.rs-online.com/web/p/pcb-card-inserters-extractors-ejectors/5073687
https://www.toby.co.uk/pcb-hardware/card-guides-and-pulls/
https://www.essentracomponents.com/en-gb/s/card-ejector

I'm sure there will be 3D printed equivalents

Tony

[Tadeusz Pycio]

I don't know if this is a good idea with the ejector though. The PCBs are small, the edges are often used so there is no room for such facilities. The only idea I have is a rectangular PCB with holes on the top corners and handles in the form of a whistle.

[Mark T]

Maybe someone could design something to fit around 40 or 80 pin female headers on the backplane with levers to push up on the edge of the pcb at each end. No modification to the modules needed, but possibly mounting holes on the backplane if its not a firm fit on the headers. Would a 3d printed part be strong enough?

[PauldB]

Here's a (very) low-tech method for lifting modules from an RC2014 / RCBus40 / RCBus80 backplane which doesn't require any
modification to current hardware. A KISS solution that works well, most of the time *

The 'tool' is a toothbrush handle with the brush end cut off. Note that the plastic on this handle is of a softer type that doesn't scratch the backplane.

I've made a number of these over time and they work quite well as a lever (among other uses; I usually trim the end of the handle to a flat blade with a knife for poking around electrical things 8) )

* It can be a bit tricky to use if the module to be removed is mounted in the socket on the side of the backplane that has an LED, switch, etc. right next to it.

Paul

[Bill Shen]

I found an angled forceps very effective in prying a board loose. 

For board I need to remove frequently, I would place it at the end of the backplane where I can get index and middle fingers of both hands under the 90-degree connector and push board out against my thumbs.  It is quick and easy.
  Bill

[Gary S]

The toothbrush handle is actually allow the way to an idea I am have been thinking of.

In the S100 arena as many others it the lifters being on the removable board, which also entails a frame to work against.
This a bit in reverse, a good motherboard design could have "optional" designed in to act againt the base of the boards inserted. Yes this is actually a development along the idea of the toothbrush handle.

Sorry Steve, maybe we can throw this back onto you to design a suitable compatible motherboard ??  (hehe).

[Tadeusz Pycio]

Proposal for dimensioning the standard PCB size of the RCBus module. I have raised the connector so that the plastic part rests on the PCB and increased the size of the whole PCB propionally for the 40 pin connector. In the slot such a module will be 2.54mm taller and 1.6mm longer. The position of the hole has been retained. I don't know if we shouldn't also decrease the bevel to 0.5", not much, but it increases the PCB area. For 40-pin connectors, it would be necessary to use angled asymmetrical connectors in order to maintain an equal distance between modules in the backplane.