Re: RFC - RCBus Extensions Needed for MC 68000-Family 32-Bit CPU's

[Harry Speer]

10:46 AM,  Friday,  July 3rd,  2026

Re:  RFC - RCBus Extensions Needed for MC 68000-Family 32-Bit CPU's

To: RCBus Users interested in Motorola MC 68000-Family CPU's on the RCBus, from the Byte-Wide 68008 to the 32-Bit 68020 & 68030

I am now working on my second draft of a Request For Comments Regarding RCBus Users interested in Motorola MC 68000-Family CPU's

Mark Durham has given us his 68000 16-bit CPU on RCBus and I am working on my own 68008 CPU design,  and we're looking forward to RCBus 68020 and 68030 CPU Cards in the future.

Obviously we'll need more address and data lines on the RCBus Backplane(s).   There is just  NOT  enough room to expand with the Single RCBus 80-pins Cards and Backplane that we have right now !! 

Mark's 68000 work is on GitHub: 

https://github.com/MarkD833/RCBUS-68xxx

And his recent Retro-Comp Posts are Here: 

https://groups.google.com/g/retro-comp/c/YKTyfbDTO6k/m/_8YbvDdeCAAJ

My Proposal is to add a Second Parallel RCBus Backplane, Like 2x of the 

SC 709 - Steve Cousins' 12-Slot RCBus Backplanes.  2 Of Them.  Side-By-Side. 

  

  This is an idea born of the VME Bus implementation by Motorola  themselves. They Created the 32-Bit VME Bus for their own 68000-Family CPU's and for their Backplanes they used a Pair called "J1" and "J2". 

 

 I am looking at doing the same thing here.   RCBus "J1" is the Exact Same Backplane now being used with absolutely NO Changes.  "J2"  will provide the additional Address Lines -  A24 through A31  -  and also Data Lines D16 through D31.  And then also carry  any additional Control and Status Lines needed to implement the additional functions needed for a 68020 or 68030 CPU to interact with the Cards on the New Dual RCBus Backplanes J1 & J2.  

The proposed 68020 card should be able to read from & write to the existing RCBus Cards that do NOT use Zilog Chips.  So an RCBus Serial Card using a 68B50 UART should work fine.  A CF Card or SD Card might be a little bit trickier as those are "fiddly" even with a Z80.   An IDE / PATA Card should be able to read / write a PATA drive (??).  The Flock-2 Card should allow the use of a Floppy Drive, and so on.  

 Zilog Peripheral Chips seem to Require Zilog CPU's so I don't want anyone to imagine a 68000 CPU working with a Z80 SIO chip.  NOT !! 

 

Since I am also working on my own MC 68008 CPU Card for the RCBus, I am including notes on what's needed in the RCBus for an 8-Bits Data Bus Motorola CPU.  I am keeping these as close as possible to what Mark's 68000 CPU Card he has created, following his lead as much as is possible.

 

As part of this effort, I will be using one or more of Steve Cousins' Double-Width RCBus Prototyping boards,  

SC736 – Double-Width RCBus Prototyping Module, 

https://smallcomputercentral.com/rcbus/sc700-series/sc736-rcbus-prototyping-module/ 

Some cards will  Require  spanning both J1 and J2  -  like the Power Supply and Reset Card - a +5V DC @ 5 Amps Voltage Regulator,  and a MAX70x Power Supervisor Chip followed by a Traditional 555 Timer with Open-Collector Outputs into the 68000's  /HALT  &  /RESET  lines simultaneously.  The 555  /RESET  is on most of the 68000 CPU cards I have looked at. 

Also,  a 68020 CPU Card would need a Double-Width Card,  and a 32-Bit RAM / ROM / Flash Card would also need a Double-Width card. 

 

So I am now working on the Second Draft of this RFC and I would welcome any thoughts and opinions about this either in the Retro-Comp Google Group or emailed directly to me.  

 

 So Please, if you have thoughts or opinions to share,  or  if you have your own ambitions of using a 32-Bit CPU on the RCBus, I would like to hear from you.  We all share in the use of the RCBus so it seems only right to put this out there for everyone to look at and comment on it.  

TIA,

Harry S. Speer

h dot s dot speer at google mail dot com 

[Alan Cox]

Mark Durham has given us his 68000 16-bit CPU on RCBus 

My Proposal is to add a Second Parallel RCBus Backplane, Like 2x of the 

SC 709 - Steve Cousins' 12-Slot RCBus Backplanes.  2 Of Them.  Side-By-Side. 

The connectors, the backplanes, the bus are IMHO simply not designed or suitable for the speeds you would ideally want for a 68030 or similar machine. I honestly think that rcbus works for 68008 (but do expose the E clock and a couple of other oddments to use the 680x compatibility) and marginally 68000/10 with 16bit memory - but you have to fix the complete lack of byte enables.

Above that you want a 3.3v backplane with far far better signal paths, proper RFI protection, and quite possibly also bus termination. At that point I'd question why you want to invent a new one when you could just use something like VME, or build an SBC and use an existing standard rcbus as a low speed I/O bus (like ISA on later PC systems).

 

The proposed 68020 card should be able to read from & write to the existing RCBus Cards that do NOT use Zilog Chips.  So an RCBus Serial Card using a 68B50 UART should work fine. 

It will I think break in most cases because of the way the card is done but a simple 68B50 card using the E clock and the 6800 compatible bus features will work but that's a strange detail of the RC2014 hack to stick a 68B50 on a Z80.

 

A CF Card or SD Card might be a little bit trickier as those are "fiddly" even with a Z80.   An IDE / PATA Card should be able to read / write a PATA drive (??).  The Flock-2 Card should allow the use of a Floppy Drive, and so on.  

ATA requires you get the signals right, you drive them at 5v through fast and strong enough buffers and you have good power signals. Getting the 68K signals lined up with correct ATA is different to Z80 but similar. On the other hand with a faster processor the impact of using a PPIDE card isn't too bad.

SD cards are easy. The only hard bits are power and grounding, especially if you allow hot plugging.

 Zilog Peripheral Chips seem to Require Zilog CPU's so I don't want anyone to imagine a 68000 CPU working with a Z80 SIO chip.  NOT !! 

16x50 is the easiest I found.

 

Also,  a 68020 CPU Card would need a Double-Width Card,  and a 32-Bit RAM / ROM / Flash Card would also need a Double-Width card. 

Trying to reliably put the 68020 and RAM on different cards on a backplane will be exciting and certainly a challenge at full speeds.

 

  

 So Please, if you have thoughts or opinions to share,  or  if you have your own ambitions of using a 32-Bit CPU on the RCBus, I would like to hear from you.  We all share in the use of the RCBus so it seems only right to put this out there for everyone to look at and comment on it.  

I'll be very interested to see how it works out but I think you are in danger of trying to make a race car run on a dirt track.

 

Alan

[Bill Shen]

I have a 68030 design (CB030), 68020 design (MB020), 68000 design (T68KRC), CPU32 design (SBC68340), 68K clone design (P90MB), and a couple exploratory designs for 68040 (IP940, Tiny040) all have the original 40-pin RC2014 bus for I/O expansion.  So regarding 68K on RC2014 bus, I think it is workable as long as the memory is on the same board as 68K.  RC2014 serves as an I/O expansion bus for 68 K.  In fact, I prefer the original 40-pin RC2014 bus because 80-pin RCBus takes away board space needed to place memory on the CPU board.

Bill

[Mark Durham]

Harry,

I don't have much to add that hasn't already been said. My 68000 design(s) seem to work - more by luck than judgement - on Steve Cousin's SC701 RCBus-80 backplane. I don't know if my designs would work with a bigger backplane than the 6 slot one I'm using without adding driver chips for the address and data lines - which would consume board space I don't have. I didn't have high speed in mind when I cobbled my designs together and I think 16MHz will be the fastest I will likely run at. I hope to tinker with an '020 design and an '030 design in the near future but they will only have a 16-bit data bus to remain compatible with my 16-bit wide memory boards.

I couldn't find any other 68K RCBus designs (other than Bill Shen's marvelous creations) so I put together my variation of RCBus-80 to suit my needs whilst trying to remain compatible with as many existing boards as I could (excluding Z80 peripheral chips).

Mark.

[Doug Jackson]

He he 

We could extend to something that I suggest could be called RCBus160.  The top 40 pin bus is for standard RCBus cards - I/O and such,

The next 3 rows could be extensions for larger CPU's

Kind of like QBUS, but without the signal integrity and quality connectors ;-) 

Kindest regards,

Doug Jackson

em: do...@doughq.com

ph: 0414 986878

--
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 visit https://groups.google.com/d/msgid/retro-comp/9d9b79ae-9271-4cd1-92c5-cee533b109a5n%40googlegroups.com.

[Andrew Lynch]

Hi

The Duodyne bus supports full 32-bit data and address paths plus 68K control signals.  https://github.com/lynchaj/duodyne

Very similar to what you're proposing without a complete restart.  Many current 8-bit boards exist, CPU, memory, and I/O peripherals.

Merovingian: Choice is an illusion created between those with power and those without.

--

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 visit https://groups.google.com/d/msgid/retro-comp/CAAdWMwgp%3De3%3D5saNGFfhBkwS0oWuyCLi6u%3D%2Br52%3DsVWUuf%3Dw_Q%40mail.gmail.com.

[7alken]

Hi Harry, I am not any hardware design experienced oldtimer here, but as mostly Alex, Bill and Mark sed, try to make rather integrated module with CPU and MEM as close as possible;
Complexity (and PCB price) moves to multilayer board, but using RCBus as peripheral only is nice in this scenario; I only deeply though about this all with my 7xsys things here, to maintain 50x50mm cheaap prototyping  space for even 8layer boards with via-in-pad for BGAs from JLCPCB, so AFAIK those large ceramic motorolas even dont fit with memory integrated, so I have 7xmod+7xmem, expected retro friendly CPLD in between, but its all still in desing or stalling due the other issues conducting here for half a year ... but I WILL continue on this hopefully soon, last thing which landed here was embedded 386ex for 3V3; ... but one most close thing to test all my ""technologies"" is DragonBallEZ+MCP NOR flash+PSRAM dual bga chip (flex-ZIF involved) combo; fingers Xed all the time...
You can probably fit the cpu+memory on RCBus 100x100 format; fact is even pro-PCI ended as 33/66MHz max paralel thing at 3V3, but you can push close enough memories up to 166, when carefully designed PCB ... world then moved to drastically fast serial links for everything, including PCIe/HDMI etc ... sad but true (of physics); 

Petr

[7alken]

hi, also, as I am now also reviewing my notes for multilayer PCBs, here I made public extended playlist which began with great Altium guy presentation about RF energy flows ...
at least this first video is very cool, but others appended later too
https://www.youtube.com/playlist?list=PLSqihAwc_6x3duXwYFBegpYHccg2n3ya2

P.

[Dennis Burke]

When you move up to 32 bits you're also moving up in speed. That will force the use of buffers between the chip and bus which then forces a large card or much more complicated PCB design.

To view this discussion visit https://groups.google.com/d/msgid/retro-comp/62bae87f-dda2-4259-9ce7-07d1b6bdf4b0n%40googlegroups.com.

[Andrew Lynch]

Hi

Yes, that's true which is why duodyne uses bus buffers in its design.  However, even with bus buffers, a bus-based design is going to be limited to maybe 10 to 12 MHz.  Maybe a really good build 16 MHz.  Reliably going faster than that will require an integrated, SBC type design.

A complex design might be able to decouple the CPU clock from the bus clock, but the bus speed will ultimately be limited in the speed it can reliably accomplish.

Merovingian: Choice is an illusion created between those with power and those without.

To view this discussion visit https://groups.google.com/d/msgid/retro-comp/CAN5PXRovv_s%2B4bdVES3sQu6sqZ_1BMthkuQLhpyK1hPKbiDpDQ%40mail.gmail.com.

[Mark T]

I would expect buffers to add delays and slow down the bus. 74LS would add 10-15 ns to address and another 10-15ns for data read. 74ACT/AHCT would reduce the delays to 5-10ns but add the problem of bus terminations to deal with overshoot ringing.

I think most RC2014 backplanes don’t have a complete groundplane, so don’t really have transmission lines to drive, or if they do they have quite a high impedance and can be driven without buffers.

When you aim for higher bus speeds you probably should add ground planes, which then reduces the impedance of the bus and might require buffers and terminations. Double sided pcb with ground on one side and 10 mil traces is probably not going to be too low.

I made a six layer bus with ground planes separating each trace, when I measured the impedance with a nano vna this verified the impedance at 43 ohm, I should have used thinner traces. It will need buffers and terminations, but I was already expecting that.

[Harry Speer]

18:27,  6:27 PM, Thursday,  July 9th,  2026

Re: Buffers and/or drivers requires larger cards

I agree that larger cards will likely be required but I have already decided to use bigger 

RCBus Cards and larger prototype cards. 

 My reason being that,  at age 67,  I am now having problems with both vision and dexterity.  

I have prototype cards that are larger,  from EuroCards  and VME bus.  Much Larger than the 

Standard RCBus Cards specs.  I have some of Mark Durham's cards and the spacing on 

those is  Mind-Blowing for me and my eyes.   I'm thinking digital microscope for soldering 

sooner rather than later. 

 

Eurocard  and  VME  Card  Sizes: 

3U Eurocards = 100mm × 160mm or 3.94 inches by 6.30 inches

6U Eurocards = 233.35mm × 160mm or 9.19 inches by 6.30 inches

As you can see,  these  cards are relatively  "Huge"  when compared to

the really tiny RCBus cards. 

  

And I also have a couple of Steve Cousins SC700 series Prototype cards. 

Especially the double-width SC736 RCBus Prototype card, which can span 

across 2 of the RCBus-80 Backplanes, Side-By-Side, which was my original

idea.  Someone dubbed this concept  "RCBus-160"  which I thought was an 

Excellent Name !!  I'm Sorry to not give the credit to whomever this was but 

my memory for names is Nearly Zero.  Please speak up if this was you.  

Naming rights deserve to be honored and respected. 

  

But there is also another idea that I have been pondering which also has more

board space - square centimeters or square inches.  Go to the SBC / Motherboard

with Both Vertical RCBus-80 Slots and Horizontal Backplane Connector(s).  

 

Steve's SC720 RCBus Z80 SBC / Motherboard  -  gives us an example of this 

other solution for more space than will fit onto one standard SCBus card. 

And it also gets the 32-bits of address and 32-bits of data OFF of the Backplane.

  

See Steve's SC720 Z80 SBC Here:   

https://smallcomputercentral.com/rcbus/sc700-series/sc781-rcbus-z80-sbc-motherboard/

  

But in this case,  the SBC could use an 8-bit Motorola 68008,  or use a 16-bit  

68000,  or use the proposed 32-bit 68020  and  later.  The SBC can host all 

or almost all of  the parts needed - CPU,  Flash or EEPROM or UV EPROM, 

SRAM,  Serial IO,   and  even a CF card  and/or an SD card - all on the one SBC.

 

And also on the SBC / Motherboard, we can have  Vertical RCBus-80 Slots 

and also a Horizontal  RCBus-80 Extension Port that would allow an RCBus-80 

Backplane to connect to the SBC Horizontally.  That Backplane can then 

provide a connection to cards that did not fit onto the Main SBC board.  

  

And also with this idea of an SBC "Host" Board,  that can be extended through

a Horizontal Backplane,  This would allow putting the 32-bit 68020 CPU,  

All of the 32-bits of Flash,  EEPROM, or UV EPROM,  32-Bit SRAM,  and then 

the DUART(s),   CF,   SD,  and etc  --  put it all on the One SBC Card and then 

it  Would NOT Need to expand into a Second Parallel RCBus-80 Backplane. 

Thus no need for the RCBus-160. 

  

 In this SBC configuration,  the "Main Board" would have all of the 32-bit stuff 

on the one SBC and then the RCBus-80 Backplane can be a way of expanding 

with more add-on cards - Video Card, USB card,  and Other IO,  and so on. 

  

 This "SBC With Expansion" idea has been on my mind for a while now,  just  

mulling it over and considering "What problems will this Solve ??"  as well 

as "What problems might this create ??".   Every design choice has to 

consider these very questions. 

  

 So I am wanting folks to now consider NOT using a Second Parallel 

RCBus-80 Backplane but rather putting "the guts",  including all of the 

32-bit memory,  onto the one "SBC Main Board" and then using the 

RCBus-80  Backplane and Cards Exactly As They Are Now - Without 

any changes to the RCBus,  and  Without needing TWO Parallel 

Backplanes. 

  

 Thoughts ??  Comments ??  Questions ??  Possible Problems ?? 

Please Speak up Now if you are looking forward to using Motorola

32-bit CPU's  -  68020, 68030, etc. 

Mark Durham  - Are you still working on a 68020 Card ?? 

  

 NOW  is the time to mull this over Before any of us has their own 

68020 or 68030 CPU using the RCBus.  I think that it is Much Better 

to think this out ahead of time, and discuss it among the Actual 

RCBus Users  -  Before Changes are made and even whether or 

not any changes are needed at all.  

 

I welcome your input !!  Please take the time to respond. 

Harry S. Speer

P.S.  I am working on a detailed paper that shows the 68000 

Family Bus Signals,  Side-By-Side,  and then also has another

chart that shows the existing RCBus-80 pins and their names  

and then shows the usage of those same pins for a 68k-family 

CPU  -  Columns:  RCBus-80,  68008,  68000, and 68020.   And 

this chart also has the 68000 pin assignments that  Mark 

Durham used with his 68000 CPU Card.  I hope to be sharing 

this document with you all very soon but it is a LOT of 

typing.  HSS

Mark - Sorry for getting your name wrong before. My bad eyes. HSS

[Dean Netherton]

Hi

I am no expert here - pure amateur with probably many wrong understandings... I saw this discussion touch briefly on signal integrity on an RCBus at higher clock speeds, and design choices for backplanes.  So I thought I could share my experience with my eZ80 module for the rcbus.

With the eZ80's 24-bit address and 8-bit data -- and with the CPU running from 18MHz up to around 30MHz - I was concerned about how things would operate on standard backplanes. (The eZ80 runs at 3.3V, so for compatibility I need to step it up to 5V)

I have 2 rcbus 80-lane backplanes I have tested on. A 6-slot and a 10-slot. Both backplanes have a solid ground plane -- all signals sent on the top layer - they are just 2-layer PCBs.

The CPU connects to the main bus via 74HCT245 buffers - I initially chose HCT because I thought this would have rise/fall times similar to most other stuff and so should work on any backplane - albeit with the caveat of introducing that extra latency on the CPU. That extra latency is solved by adding appropriate wait states - my understanding was 74HCT should not give me any signal integrity issues on the RCBus (at least no more than usual).

I recently have been trying to use faster SRAM (surface-mounted CY7C1049GN chips) - and had some success achieving 0 w/s RAM access.

Summary of my testing. Sorry, don't have any traces from my scope of the signals.

| eZ80 Speed | Bus drivers | Memory W/S | Memory module type       | PCB Type | Performance    |
|------------|-------------|------------|--------------------------|----------|----------------|
| 20MHz      | 74HCT245s   | 1          | 4xAS6C4008/74hct138      | 6 slot   | Works          |
| 20MHz      | 74HCT245s   | 1          | 4xAS6C4008/74hct138      | 10 slot  | Works          |
| 20MHz      | 74AHCT245s  | 1          | 4xCY7C1049GN/74AHCT138DR | 6 slot   | Works          |
| 20MHz      | 74AHCT245s  | 0          | 4xCY7C1049GN/74AHCT138DR | 6 slot   | Not reliable   |
| 18.432MHz  | 74AHCT245s  | 0          | 4xCY7C1049GN/74AHCT138DR | 6 slot   | Works reliably |
| 18.432MHz  | 74AHCT245s  | 0          | 4xCY7C1049GN/74AHCT138DR | 10 slot  | Not reliable*  |

* regardless of slots chosen.

From my reading online, I understand if I were to add some inline small resistors on the bus drivers - I could improve signal integrity without introducing much delay --- but very much doubt I could fit that many resistors on the CPU's PCB.

And as you and others have mentioned, I perhaps easier and simpler to create an SBC (CPU and RAM together) with some optional expansion slots.

I do have one question, if anybody could enlighten me - What exactly is bus termination?  Is it a cap & resistor in series to ground for each line - at the end of the backplane (eg after slot 10) ?  Would this have similar effect as having resistors at the source?  

Dean.

[Harry Speer]

22:12,   10:12  PM,  Thursday,  July 9th,  2026

Re:  a 68020 SBC or a 68030 SBC with Backplane Connector(s).

I finally found the examples of this SBC idea in my bookmarks 

for my web browser.

Mega-Micros in the UK

His Version # 1 of the 68030 SBC with Expansion connectors

It is sposed to be mountable in an ITX Motherboard mounts in 

a PC Case.

https://www.mega-micros.co.uk/68030_sbc.htm

And he also has a Version 2 of the same, but this one is 

maybe bigger ??  He says ATX Form Factor.  

https://www.mega-micros.co.uk/68030_sbc-2.htm

And he also now has a 3rd Version of the 68030 SBC.

He says it is a Micro-ATX form factor.

https://www.mega-micros.co.uk/68030_sbc-3.htm

So in these three examples,  you can see the 68030 SBC 

equivalent of Steve Cousins' SC720 Kit - Z80 SBC / Motherboard -

These UK Mega-Micros have been around for a few years

and I did think seriously about going with his bus.

 

If you look at a photo of Steve's SC720 Z80 SBC Motherboard

and then look at a photo of a Mega-Micros 68030 SBC, side-by-side

photos you can see roughly the same idea in each.  The Difference s

being the RCBus is the Expansion for the SC720,  and also that 

the 68030 SBC is probably a LOT Faster than a Z80.  smirk. 

So what I have in mind is a 68020 SBC / Motherboard with

an RCBus Expansion Connector to allow an RCBus Backplane 

to be attached.  Sort of an RCBus version of the Mega-Micros

68030 SBC. 

I welcome thoughts, opinions, and other ideas of how to make 

this work.  The target I'm shooting for is a 68000 CPU and Cards

that can address RCBus Cards over an RCBus Backplane. 

And I'm not just meaning just the one 16-bit CPU like Mark made 

but also an 8-bit 68008 RCBus Card and then move forward to 

either the 16-bit 68000 or the 32-bit 68020. 

 

 I just wanted to share the Mega-Micros stuff with you all.

Harry

[Harry Speer]

22:20, 10:20 PM,  Thursday, July 9th, 2026

Re: Driving the Bus with Buffers / drivers / whatever 

In the process of getting to RCBus, one of the "stops" 

along the way was the ancient S-100 Bus.  I also 

once owned my own Altair 8800b - So I do have a 

little bit of S-100 background. 

 

And coming from that kind of background, I was taken 

aback at the lack of Drivers between the CPU and the 

Backplane when it comes to RCBus working and also

RC2014 stuff working without these kind of chips. 

Here's all these guys and gals running without any drivers

and, over the short distances of the RCBus Backplanes,

RCBus somehow "happens to work" without drivers. 

 

I am more accustomed to seeing Buffered Inputs, Driver 

outputs, and the use of  Tri-State  aka  3-State chips 

that can basically remove themselves from the bus by

going into High-Impedance if I remember the lingo 

correctly. 

And yet the RCBus Compatible Cards and RC2014 Compatible 

cards  "Just Work"  which is, to me, a rather big surprise. 

I realize that there will be signal delays and timing issues

but that's the real world of trying to build this stuff from 

scratch.  One BIG help is being able to search the web

for the schematics of other people's work to see what 

they did. 

This just to express my level of surprise at NOT seeing 

the use of drivers and such.  I am used to seeing it in 

S-100  and I'm surprised the RCBus and RC2014 work

well without these same chips. 

Shaking my head left to right in bewilderment. 

Harry

On Wednesday, July 8, 2026 at 8:11:14 AM UTC-7 den...@burkescience.com wrote:

[Bill Shen]

A number of my 68K-for-RC2014 are SBC motherboards with 1, 2, or 3 RC2014 connectors.  They have sufficiently large DRAM in 72-pin SIMM modules so additional 32-bit memory expansion is not necessary.  This way RC2014 connectors served as 8-bit I/O expansion.  The problem is SMT CPLD is needed to interface to DRAM and translating 68K signals to RC2014.  Other than SBC68340, I don’t have 68K designs that does contain a CPLD.

Bill

[Bill Shen]

Typo, the last sentence should be “other than sbc68340, I don’t have 68k designs that do not contain a CPLD “

[Bill Shen]

An example of 68020 motherboard with 3 rc2014 connectors populated with RC2014 8k ROM board, 6850 serial board, and CF board.

[Mark Durham]

Harry,

I'm still working on the 68020 (and potentially 68030) cards for RCBus-80. I got distracted by trying to integrate vectored interrupts into my 68000 board. I've got a design just about ready to go to JLCPCB along with updated serial I/O (with integrated bit banged SPI and I2C interfaces) and updated digital I/O, both to support vectored interrupts.

I also have a prototype 68020 board with vectored interrupts ready to go to JLCPCB. This one uses an ATF1504 CPLD in order to cram in the required logic to support dynamic bus sizing as well as the existing logic.

There's also a serial & maths coprocessor board ready to go to JLCPCB as well as a 3Mb RAM / 1Mb ROM board (uses SMD RAM chips).

Unfortunately progress on all of them has been slow over the last few months as my better half has suffered compression fractures of L1 & L3 which has left little time to my hobby.

Mark.

[Mark T]

Hi Dean,

For a simple transmission line the bus termination could be an LCR network at the opposite end of the line from the driver. The purpose would be to match the transmission line impedance to prevent reflections.

The driver should also be matched to the impedance of the transmission line. Most logic families have output impedance similar to the transmission lines used, for 74ACT its best to provide a series resistor on the output of the driver.

On a bus with multiple stubs and drivers along the length of the bus its better to use an array of schottky diodes to each supply rail, to prevent overshoot and undershoot beyond the supply rails.

Mark

[Mark T]

An SBC with RCBUS expansion is probably the best choice for the 68k series, though it does remove the modularity of the RCBUS if you are planning to experiment with different memory configurations.

RC2014 bus originated as a simple breakout from the Z80 pinout to put each function on a separate module. You might consider a similar bus for the 68k, based on the 68k pinout, with an adapter at one end for RCBUS expension. The RCBUS expansion could also be a separe module for translation to Z80 signals. This format could allow you to experiment with the memory interface or try alternate 68k processors. I haven’t compared the 68000 and 68020 pinouts, maybe it makes sense to arrange the address and data bus to make it easier to adapt to either of these.

Mark

[Harry Speer]

===================================================================

  

13:10,  1:10 PM,  Friday,  July  10th,  2026

Re:  Two Different RCBus Backplanes

Mark T - You hit the nail right on the head when you said:

"You might consider a similar bus for the 68k, based on the  

68k pinout, with an adapter at one end for RCBUS extension.   

The RCBUS expansion could also be a separate module for  

translation to Z80 signals. This format could allow you to 

experiment with the memory interface or try alternate 68k 

processors. 

I haven’t compared the 68000 and 68020 pinouts, maybe it 

makes sense to arrange the address and data bus to make 

it easier to adapt to either of these." 

I have, in fact, been thinking of exactly that - The Existing RCBus 

would be called  "RCBus-80"  for the Z80,  8080,  8085,  Z180,  Z280,  eZ80, 

and so on.  And Then the Second RCBus, for 68k-family, could 

be called the  "RCBus-68k"  and this would mean using the 

Motorola Control and Status Lines as well as the Address 

and Data lines.

 

Not just because of different usage of all those status and control lines,

BUT ALSO for another reason that has, so far as I recall, Not 

Been talked about.  

"Little-Endian" -  Intel 8080 & 8085,  and also the Whole Zilog Family.

Thus the RCBus-80 as it stands today it is a Little-Endian Bus. 

Whereas the Whole Motorola Family of 68008, 68000, 68010, 

68020,  and  68030  -  They are all "Big-Endian". 

For more information, I suggest starting with this 

wikipedia article here: 

https://en.wikipedia.org/wiki/Endianness

This topic is worthy of discussion, IMHO, and the difference 

is a part  of why I am thinking of having two different 

RCBus Backplanes - RCBus-80  and  RCBus-68k.  

If we assume that we would create an SBC for the Motorola 

CPU, then  there would be an optional Expansion Connector 

used to link to an RCBus Backplane.  

Physically the Same RCBus Backplane, regardless of it being 

used with Intel / Zilog signals or if it was to be used for 68k 

CPU Status and Control signals. 

 

As for going from 68k SBC to  Intel / Zilog  RCBus-80, there would

need to be some chips to translate from 68k to Z80 outbound to 

the RCBus-80  and then also another set of chips to Receive the 

Returning Data back from the RCBus-80 and into the 68K SBC.  

And part of the interface between 68k and RCBus-80,  a Byte-Swap 

of the 16-bit words to / from  the Little Endian RCBus-80.  

Whereas for the connection between 68k SBC and RCBus-68k, 

No byte-swapping would be needed nor desired.  Just possibly 

using drivers to feed the RCBus backplane and possibly also 

some 8-bit and 16-bit Latches to help stabilize the outbound 

and inbound data.  That might help to get more stable timing 
so that the outgoing data and incoming data could be "held"

by said latches.  One of the biggest problems we have is 

timing and getting the timing "Off" and the foul results of

the "Bad" timing.

This idea changes away from using the second RCBus for 68020

signals for the extra Address and Data lines. 

As I said before, I am working on charts of the various address 

and  data lines and control/Status lines for the 68k Family 

68008, 68000, and 68020.  

And a second chart of where these 68k signals are presently

being put onto the RCBus-80.  There is, unfortunately, already

problems as to how the lines are routed on current 68k cards.

A close look at this second chart will show that things already

seem to be problematic.

I continue to work on this and I hope to have it ready soon. 

I am just not the worlds fastest  typist. 

Harry

=============================================================

[Alan Cox]

"Little-Endian" -  Intel 8080 & 8085,  and also the Whole Zilog Family.

Thus the RCBus-80 as it stands today it is a Little-Endian Bus. 

On a 16bit wide bus with 16bit devices or 8bit with 8 or 16bit devices really. If you want it to look the right way around by magic just wire the device bus with the bytes swapped from the CPU card. As the CPU has a single instruction to byte swap a word it's pretty irrelevant. We also btw already have 6800 series processors on rcbus and some other weird and wonderful things which are big endian and it all works out fine.

We have working 68K cards using RCbus for I/O. It's not complicated at all. What causes all the fun is having 32 address and data lines all of which tend to flip at the same time. It pushes you from being able to treat a bunch of connectors as a "bus" to actually needing correct analogue signal management - which is a much much harder problem. RCbus is kind of 1st year electronics "I made a computer". Doing higher speed buses with a lot of wires, especially across two backplanes is masters level stuff.

Doing a second part of a bus separately is possible with 32bit 68K - VME bus did exactly this to go to 32bit but there's a huge amount of analogue electronic design required to make it work.

Alan

[Dennis Burke]

I consider the RCBus (RC2014) a minimal/entry-level solution to attract and satisfy retro hardware lovers. It fits the pattern of late 1970, early 1980 systems.

There is nothing cohesive in the spec or implementations for 16-bit systems. As pointed out, the RCBus is rather Intel centric (little endian).

That said, there are ways out of that box but they consume real-eastate.

Considering 32-bit designs is such a leap in bus architecture and speed that it really warrants a different bus/form-factor.

Many years ago I built a 32-bit through and through system on single VME cards. I would consider that 96-pin solution for systems that exceed the RCBus spec.

On the subject of bus buffering, it's true they add a delay but they also help mitigate signal integrity issues.

Bus termination is only possible with these buffers.

--
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 visit https://groups.google.com/d/msgid/retro-comp/CAK9X0%2Btc%3DtqjomEg-5N4%3Dfwhmb%3DAzwBA2KB2s9zMX6bLrUMj_Q%40mail.gmail.com.

[Harry Speer]

=================================================================

 17:23,  5:23 PM,  Saturday,  July 11th,  2026 

 Re: How to deal with 32-bit CPU's - Specifically Motorola 68020 and 68030

   

 To: All

   

  I hear the  "Voice of wisdom"  and I accept it.  

  I will go with the SBC Plus RCBus-80 Optional Add-On Extension. 

  

  I see the consensus on keeping the RCBus-80 as it is and using it only

  only for 8-bit and 16-bit Add-On cards.  Excluding Cards with Zilog

  peripheral chips.  I expect some boards to work while I expect any

  with Zilog Chips to NOT Work with any Non-Zilog CPU's.  

   

  Suggested: 

  The SBC's would have, as a minimum, CPU,  Flash or EEPROM, or 

  UV EPROM,  SRAM  with possible DRAM with Controller like a CPLD,

  and Console IO - a UART or DUART or even USB IO for those who want 

  to use them.  Thus the SBC should be able to power-up and interface

   with the user via Serial or USB for Console: 

   

  RCBus-80 Cards:   Should  "Just Work" 

  EG:  CF,  SD , Floppy Controller,  PATA/EIDE for vintage hard drives, 

  also a video card or cards, and so forth.  

   

  Thus the SBC card would be able to bring up a monitor with all

  that is needed to run from Power-Up without using an Add-On 

  Bus Backplane.

    

   As was pointed out, we have Mark Durham's 68000 CPU Card,

   ROM+RAM Card, and Serial IO up and running already.  My

   great thanks to Mark for his work.  

   

   I will continue my own work and I will listen to suggestions, 

   but,  for me,  I think there is no need for me to address the 

   Retro-Comp Group as a whole.  I think that I have what I 

   needed. 

     

   My thanks to all of you  who have put forth your voices.

   Greatly Appreciated.

   Harry

   

 =================================================

[Mark T]

Its been an interesting discussion. Please let us know how your project turns out.