RC80 ?

[Tadeusz Pycio]

Recently, Specer clearly defined what could be called RC2014 and made a valid point about the community abusing its registered trademark. I propose to solve this problem by renaming the new products "RC80". I think this name captures the idea of retro computers well, referring to the 80's, the 80 pin connector used and the Z80 compatible signals. Of course other suggestions will be welcome. However, it would be good to unanimously adopt a standard so that everyone clearly knows what they are dealing with, so that there is no need to refer to a proprietary name and promote it in this way. Another issue is the preservation of a uniform bus, here it is worth considering the extension proposed by Steve, i.e. additional interrupt lines, IEI/IEO cascade. As a suggestion, I also present the logo (I am a lousy graphic designer) on a sample module. Perhaps other suggestions?

[Steve Cousins]

I've been giving this whole issue quite a bit of thought since Spencer raised it. There are so many aspects to it I don't know where to start but here are a few random thoughts.

Spencer did point out that he is not really seeing a deliberate abuse of his trademark. It seems to be more about confusion of what is an RC2014 and what is a "designed for RC2014" product with no official standing or compatibility certification. Not that all official RC2014 modules work with all others - that is just the nature of the modular design of a range of related systems.

I like the name RC80, especially with the reference to 1980, but many RC2014 compatible systems use only the 40 pin bus. So I'm not convinced about the name - yet. I call my 40-pin Classic II style designs RC40 and my 80-pin backplanes BP80, but I don't make a big issue of this and don't mind changing if we can agree something else. I quite like Alan's suggestion of RCBus. One thing I like about the name RC2014 is that it is quite unique from the search engine point of view. The name RC80 gives all sorts of matches.

I'm happy to adopt a new branding if one can be agreed. One of my concerns is that not all of us who share our designs or sell them will adopt a new brand. This would be more confusing than the current situation. Also, it will take a long time to migrate exiting designs, documentation and product listings to a new brand. I have lots of designs, many pages of documentation, and a lot of stock of PCBs in a range of colours. That will not change overnight.

For some time now I have avoided any use of "RC2014" on my new PCB designs due to the very issue Spencer raised. I do however make a lot of use of "designed for RC2014" and "compatible with" in my documentation and product listings.

I'm not sure who a new branding scheme would really help. Sure it would differentiate official RC2014 products from others (if everyone adapts it) but I feel that may just make it confusing for new users. They may even view it that there are two competing systems that look very similar.

All my RC2014 style designs are now either:
* enhanced bus: standard PCB form factor with 2-row headers (full or partial second row), or
* standard bus: Classic II form factor with single row, 40-pin headers
Having some standard form factor modules with single row and some with double row is inconsistent and ugly. It is also responsible for all the problems people have with using the wrong header on the Pro memory modules.

These issues are some of the main reasons I have produced a range of Z50Bus products. Currently the Z50Bus is relatively "clean". The bigger cards provides a bit more scope without creating non-standard card sizes. The easier removal of cards from backplanes (due to the shorter bus header) is a big plus. 80-pin RC2014 style headers are difficult to handle. I also like the Classic II style as the 40-pin header profile makes the modules much easier to lever out of a backplane.

I agree, a new brand will give us an opportunity to specifiy some enhancements to the bus, such as the IEI/IEO issue. This, however, opens another can of worms. Last time this was discussed in detail a consensus was not reached.

I assume Spencer's comments are at least partially motivated by wanting to protect his business from the designs the rest of us produce. This could backfire if we agree an alternative brand and all third parties support it. The new brand could become stronger than the RC2014 brand.

Steve

[Tadeusz Pycio]

Hi Steve,

I am in a bit of a dilemma as to what to call my projects these days, as I have often used the abbreviation RC2014 in descriptions, comments, meaning the bus standard and not the product. Another thing is that I consistently use the extensions you suggested, because I think they are needed and some will not work on the RC2014 bus. And this is where it should say "Designed for RC2014 and compatible with BP80 or SC"?
The problem of consenus - have any of the requests to add more signals on the bus propnned in the previous discussion taken physical form? I haven't seen the off-the-shelf modules with I2C, SPI, 3V3 on the bus that were supposedly so needed.  Yes I still maintain that the DREQ and possibly DACK signals are missing, I don't think there is a need to add a BAI/BAO cascade due to the assumed simplicity.
I personally wasn't convinced by the Classic ][ standard, but I wasn't the target audience for this product either. More often than not, I struggle to find space on the standard PCB dimensions to go towards making them smaller (trying to lay out a Z80 KIO or the topic I'm currently working on, the V40, are not possible on this size).
I think the RC40 is still the RC80 which is used half. :)
We should uniformly name our projects, because I don't know if I can still write: "I built, ran, messed up an RC2014 module", because it is not an RC2014 module. If we start using different names, we certainly won't help people getting into retro computing, because they'll think we're talking about completely different platforms.

[Doug Jackson]

Hi Everybody.

I firmly believe that we need an open, consistent - Searchable - name for the bus structure as a superset.

We started with RC2014, and now we have RC40, RC80 etc.

A simple name such as "RCBUS" which could encompass the wide range of RC bus structures we have may be worthwhile.   It especially appropriately covers the problem of saying RC2014, instead people would say "I made a RCBUS module and it was busted".

A quick search suggests that there is not a heap of overlap in Google space.

Just my $0.02 - including inflation :-)

Kindest regards,

Doug Jackson

em: do...@doughq.com

ph: 0414 986878

Check out my awesome clocks at www.dougswordclocks.com

Follow my amateur radio adventures at vk1zdj.net

--
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/b05b45f6-7460-433a-8d5e-a8e9b3c54867n%40googlegroups.com.

[Tadeusz Pycio]

Yes, RCBUS might be a good idea, as it contains the entire collection of available bus.
I would like to stress that this is not an attempt on my part to build a new brand (I don't intend to make money from my projects, most of them are available for non-commercial use) but an attempt to find myself in the current situation.

[Sergey Kiselev]

Quite an interesting conversation to read (and also go back and read Spencer's post and previous posts).

I agree with the need for an alternative name for the RC* bus and for the modules and systems that use it.

As far as naming goes, RCBus sounds good. It is has a meaning as of "Retro Computing Bus", it is close enough to RC2014 and yet far enough from trademarking perspective. It also doesn't specifically mention the number of pins or the CPU type/name, so it leaves things flexible there.

Random thoughts (that could get me banned on the other group):

I do understand Spencer's worry about protecting the RC2014 trademark. At the same time, I am not sure how much is it justified, given that only a handful of folks produce popular RC2014 compatible modules, and likely none of them are as popular as the original Spencer's kits (did anyone sell a few thousands RC2014 compatible modules yet? Maybe Steve did :)). The rest of us seem to design modules mostly for fun, and perhaps a little profit.

At the same time it is awkward to describe the system built out of RC2014-like modules... For example my current system has Steve's SIO module and backplane, and mine CPU/memory and floppy controller modules (or sometimes Spencer's CF card module, which doesn't work that great... need to build Tadeusz's one instead). Apparently I cannot call it an RC2014 system... Maybe not even RC2014 compatible (who knows what compatible means here, and who validated this compatibility?!).  At the same time, it would be fine to call it an RCBus system.

I also agree that Spencer might be shooting in his leg here, if the whatever new name we come up with here will become more popular (kind of IBM PC vs clones situation in smaller scale).

Cheers,

Sergey

[Steve Cousins]

I really like the idea that RCBus could mean "Retro Computing Bus" 

Steve

[Steve Cousins]

Hi Tadeusz,

I think you are right about the additional bus features previously discussed. They all sound good but I haven't seen much sign of them being implemented via USER pins or extra pins on the 80-pin bus. Of course, that could be because there is no agreed standard for them. My feeling is they are not as important as they may sound. One of the attractions of the RC2014 bus is its simplicity. If we extend it to include 3.3 volt supplies and signals, I2C, SPI, etc. we may not actually be improving the system overall. I think it was Alan who said during previous discussions that I2C and SPI (in particular) are best implemented with the master on a module and the slave devices remote from the bus. This is what I have done with my I2C range and it seems very appropriate. I have also done the same with a yet to be released SPI interface.

As for the Classic II standard, I like it because it is simple and it does enforce the extreme modular system that the RC2014 started out being. You really can't put many functions on a single module. The low profile system looks very neat and the 40-pin bus means less soldering. The modules are easier to handle. I agree it is not realistic to implement some features on such small boards, but for systems up to and including the equivalent of an RC2014 Pro, it is quite suitable. I already have a range of modules in this form factor to implement a basic CP/M system.

Steve

[Steve Cousins]

Another thing to consider is how to implement systems designed to be put in a case. External connections from RC2014 style modules can be from any part of the PCB making it difficult to design a small case. I try to make external connections on the back edge of my modules. I think any published guide to designing for RCBus (or whatever we call it) should recommend a common approach to this problem. This will help a bit but I can't see a way to make a really nice cased modular system with the constraints of the RC2014 style modules.

Steve

On Wednesday, 8 February 2023 at 11:54:23 UTC Tadeusz Pycio wrote:

[Wayne Warthen]

On Wednesday, February 8, 2023 at 4:56:39 PM UTC-8 Steve Cousins wrote:

I really like the idea that RCBus could mean "Retro Computing Bus" 

I am also a fan of "RCBus".  I think we are talking about an enhanced bus definition derived from the RC2014 product line.  New folks would "get" that name almost intuitively.  And Spencer has already indicated he is OK with it.

I sure would like to see a formal definition of the RCBus signals, form factor, and external connector standards.  I am honestly not sure how to get there.  Steve seems to have done the most work (and documentation) -- perhaps he should be the RCBus czar?

-Wayne

[Greg Holdren]

Spencer is just ranting and raving again. I guess it happens every few years or so.

I have only done one board which was few years ago (Xilinx 84 pin 9572/95108 CPLD) and I put RC80 Bus on it. Actually I think it was on the connector symbol already. Didn't put Arrrrrrrr (say like a pirate) Siiiiiiiii (spanish accent) ( RTC fiasco year plus 14) on it. :)

However, I do like RCBus.

Greg

[Kande Laber]

As a newcomer to retro computing, I have no problem paying full price for the many good retro comp kits that are available today. But I also take note that this is essentially a non-profit hobby community. Many sources of our hobby are considered royalty free, such as documentations, software, etc. This also applies to the foundations of the RC2014. While RFC2795 Ltd's claim may be legally justified, I believe that morally the discussion is unjustified. In other words: "If it ain't broken, don't fix it".

[Bill Shen]

I designed mostly with 40-pin Classic connector and sometimes with 26-pin (no high order addresses, no spares).  In 68K and 6502 worlds, I use 40-pin with the same addresses, data, power, clock. and reset but different controls.  I do use CPLD extensively so the control signals can be redefined when the same board is moved from Z80 to 68K/6502.  In 6502 world there is an informal RC6502, 40-pin RC2014 with control signals redefined.  I'm a participant and have designed a few RC6502 boards.

RCBus sounds good with RC80 and RC40 as two variants of RCBus.  I suppose 26-pin RC40 can be called RC26, but I rather not.  I think the idea of RCBus is to encourage experimentation and not get too caught up in standardization.and branding.
  Bill

[Alan Cox]

I switched Fuzix, the emulator kits and the like to use rcbus when the
matter came up.

From a bus point of view I'd say my list of things is

- Defining how some of the pins are used on a per CPU type basis
(IEI/IEO for Z80/Z180, RW and E for 68xx 65xx, bitwide I/O bus on the
TMS99xx)
- Sorting out the fact we have 16 data pins defined by no byte enable pins
- Multiple interrupt lines
- Perhaps sorting out the BUSRQ/BUSACK stuff

It would also be nice to have a 3v3 version of the spec. I'm tempted
to just go with the existing connector but at say a 2mm spacing so it
looks the same, acts the same and can't be stuck in the wrong place.

Agreed on the awkwardness of the 80pin connector but I think we are
stuck with it personally, and if I was designing a new bus I'd make
sure i could use the cheap arduino headers and make it stackable
instead 8)

I did, btw, eventually find a 16bit bus CPU with 32 address lines. The
i960SA/SB have this arrangement. I'm not sure it matters for the bus
pin allocation because I can't see any one (except maybe Bill)
building a 4GB retro computer.

Alan

[Bill Shen]

> I can't see any one (except maybe Bill)
building a 4GB retro computer.

now you making me think (always dangerous)...With decent cache & DMA, it is probably reasonable to run programs from a 4GB CF disk.  I thought about putting 68030 on RC2014 as a joke, but now...hmmm.

[Tadeusz Pycio]

Hi Alan,

I think some of your demands are already implemented in the BP80/RC80. The IEI/IEO cascade on pins 38/39 is supported by modules/SBCs - Easy Z80, SC102, SC103, SC104, SC110, SC132, my DUART modules, Universal SIO, Z80+CTC and probably a few more I haven't mentioned at the moment. Similarly there are two additional interrupt lines on pin 37 in both rows are handled by SC102, SC111, Z180 MPU, Z280 MPU, and they are used by my Network Controller, 16C450/550 module among others. For 68xx processors, line 39 is for the R/W, 38 the E clock.

[Karl Albert Brokstad]

Hi All!

I have read the discussion about RC2014/alternative name with interest.

Spencer Owen makes a living selling his RC2014 kits so it's not entirely open and free hobbyist products and hence the products are trademarked. 

That is fine with me.

I never liked the "made for RC2014" label since many third-party modules were stand-alone products or work with other kits. 

For a short period, I labelled my kits "RC2014 compatible" but have since used RC40 and RC80 bus, for the 40 and 80 pins header respectively.

If I remember correctly Steve Cousins initiated the discussion about the data bus, wanting to standardize the pin layout beyond the standard RC2014 bus including pins for interrupt chain and more. Additionally, he was trying to sort out the I/O space, as some kits took up to much I/O space.

I think RC80 is a good alternative name.

Karl

[Mark T]

Using 2mm pitch headers for 3v3 systems would prevent reuse of 5v modules by replacing components with 3v3 compatible parts.

I think RC40 and RC80 could be used to define a subset or full set of the RCBus, though a full set of RCBus is going to be dificult to standardise as there are already a few variants for use of the user defined pins for different processors or just from different designers. Maybe we just adopt the standard RC2014 pinouts as RCBus-RC40 and the RC2014 Enhanced bus as defined by the RC2014 pageable ROM or 64K as RCBus, without the modifier. Then refer to RCBus-6502, RCBus-68k, RCBus-IM2, RCBus-4MB etc for the different variants, leaving the designer to define the additions.

[Sergey Kiselev]

Preferably 3.3V would be provided on an unused pin of a standard 80x2 (really 79x2), 2.54 mm pitch  RCBus connector. Some modules might benefit from both voltages. For example some CPLDs are 3.3V but have 5V tolerant, TTL-compatible I/O pins. In other cases adding current limiting resistors might work, e.g. Parallax Propeller based console/display controllers (ParPortProp http://www.malinov.com/Home/sergeys-projects/parportprop, and https://github.com/maccasoft/propeller-graphics-card)

Thanks,

Sergey

[Dylan Hall]

I’ve not seen this come up yet. I use 4 of the USER pins for RTS/CTS from the two serial ports. The main thing for me is that cards using these optional pins use jumpers so the function can be disabled to avoid clashes. 

Dylan 

--

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/199f1bd2-07a4-4537-b63b-f5f9d42ab5a4n%40googlegroups.com.

[Tadeusz Pycio]

I believe the bus should be unambiguously standardised, this is its foundation. I would also argue that adding utility pins on a modular bus is its biggest flaw, it leads to incompatibility and derails it as a standard. I realise that it is difficult to get consesus because everyone has their own vision of what it should look like. RC2014 is exactly why it became popular, because it had a fixed order on the bus and the author didn't care what users did on the USR pins, because his modules were never meant to interfere with them. The problem arises as there are many creators and everyone is free to use them, this is how the A, B, C, .... standard is created.  There should not be any USR pins on the RCBus!

[Chris Brunner]

I'm working on an SBC that co-opted the RC80 bus that carries both 12V and 3V3 on a couple of the unused pins. This eliminates the extra circuitry needed to shift the 5V down for 3V3 components (such as an ESP32 module for example) or the need for external power in the case of 12V.

--

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/5bef3eea-c43b-49c8-902a-38dc5f6daf11n%40googlegroups.com.

[Dylan Hall]

I think the opposite is true. I don't think it's practical to anticipate all the use cases, now and in the future, so having USR pins accommodates that and also encourages people to experiment.

Dylan

On Fri, 10 Feb 2023 at 09:04, Tadeusz Pycio <ta...@wp.pl> wrote:

I believe the bus should be unambiguously standardised, this is its foundation. I would also argue that adding utility pins on a modular bus is its biggest flaw, it leads to incompatibility and derails it as a standard. I realise that it is difficult to get consesus because everyone has their own vision of what it should look like. RC2014 is exactly why it became popular, because it had a fixed order on the bus and the author didn't care what users did on the USR pins, because his modules were never meant to interfere with them. The problem arises as there are many creators and everyone is free to use them, this is how the A, B, C, .... standard is created.  There should not be any USR pins on the RCBus!

--

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/eff014a4-f8e9-41d1-8961-e60bfbb18646n%40googlegroups.com.

[Tadeusz Pycio]

Experiments are not done on the bus, well, unless in the course of its creation. She should be the only sure thing. My design doesn't work because I made a mistake in the module or maybe I got the incompatible modules wrong? Have you seen the USR pins on the ISA, EISA, PCI buses?

[Mark T]

We can call the User pins Reserved if you prefer.

[Ronny Ribeiro]

I thought the same 😂

--

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/1eb9015c-fe49-4c6e-a8bb-c9bb58e5c5e3n%40googlegroups.com.

[Tadeusz Pycio]

Preliminarily summarising the discussion so far, I think we can adopt a solution that should satisfy everyone to some extent. In view of the hardware (kits, modules, backplane, SBC) and software, adopt the common name "RCBus", which operates on the electrical/logical bus RC26,RC40,RC2014,RC80,BP80. This division into a general/common part and a specific part related to the characteristics of the bus in question should not cause a revolution in our current descriptions and documentation. Of course, it will remain an open question to determine the meaning of the signals on the individual bus, but the general idea will be under a common denominator. I think this will be the best solution. What do you think?

[Steve Cousins]

Sounds good to me Tadeusz

I thought it would help to start by documenting where we are currently. To that end I have attached some notes about my pin numbering and pin assignments. I've attached the document as a DOC file and a PDF. Feel free to say what you feel needs to be said!

I think we should start by agreeing terminology, pin numbering, signal names, etc for where we are currently. We can at least start off being consistent about such things.

I think we need to keep all the official RC2014 signals for compatibility, so that includes the USER pins. 

All my modules jumper any connections to the USER pins so the user can decide if they are wanted. Some of my backplanes hardware an interrupt daisy-chain on pins 40 and 80. Most of my backplanes allow for relatively easy configuration of pins 38 and 39 as an interrupt daisy-chain. As far as I know no one has used the pin 40/80 daisy-chain, but some use the pin 38/39 daisy-chain. My Z80 CTC, PIO and SIO modules offer jumpered connections to pins 38 and 39 for IEI and IEO. They also have pins on the "back" edge of the modules to allow flying leads to be used to create a daisy-chain.

My Z180 CPU and Z180 memory modules use A16 to A19 (pins 53 to 56). I don't use pins 41 to 52. Also, I haven't used D8 to D15 (pins 67 to 74).

Steve

[Alan Cox]

> I think we need to keep all the official RC2014 signals for compatibility, so that includes the USER pins.

Yes, and things that provide a signal to the user pins should be
jumpered not directly connected.

Currently the only pin use I have is the use of E and RW on 38 and 39
for Motorola bus devices. This is used by the following cards
- 65C02
- 65C816
- 6803/6303
- 6808
- 6809/6309
- 68HC11
- 65C22
- 6840/65C21

The TMS9995 card puts the following signals on 37-39
- MEMEN
- CRUIN
- CRUCLK

The current one doesn't jumper them but that was an oversight.

Those to my eyes are all really CPU specific or bus type specific pins
not general ones.

From memory the last time things raised more generally included
- No low/high enables to make D15-D8 actually usable
- Multiple interrupt lines
- DMA - BUSRQ etc
- 3v3 power

None of the CPU cards I have currently go above A19 except for the
test flat mode 65C816 board which goes to A23

The 68008 is limited by pin count, the 80C188 is a 20pin address bus.

The other bit of the specification is
- clocks
- voltage (5v)
- signals (74HCT or equivalent)

Some of the NMOS CPU parts don't work if you've got more than the odd
74LS device on the bus.

Alan

[Tadeusz Pycio]

I think the meaning of pins 37-39 should be made clear as IRQ1, IEI, IEO for Zilog bus compatible modules and IRQ(FIR), R/W, E for Motorola. As the official backplane and Karl's do not have the ability to disconnect between slots lines 37-39 on the backplane, this should be provided on any module using these extensions to maintain backwards compatibility. In the second row, designate pin 77 as IRQ2. It remains to establish the meaning of pins 78-79, because, as I mentioned earlier, I am against leaving anything to chance on the bus, as this leads to incompatibility. Like you and Alan, I am in favour of not introducing signals not required for the bus (I2C, SPI), the only deviation is the use of TXD and RXD signals (35-36) which is due to the fact that a serial terminal has been adopted as the main way to communicate with the user. I also question whether the TXD2 and RXD2 signals (75-76) are not superfluous here. I also raise the issue of the need to add signals for the I/O device to request support via the DMA channel, (perhaps pins 78-79?). I find the addition of the BAI/BAO cascade superfluous for such simple systems.
PS. What is the SC128 Z80 CPU - I have not found such a module?

[Mark T]

Is SC128 a typo in Steve’s pin listing? I thought that was a Z50 bus modular backplane.

[Tadeusz Pycio]

I forgot to attach the file. :(

[Steve Cousins]

Sorry, yes, it is a typo. It should be SC149. This is designed as an upgrade to the Classic II CPU module. As this uses the 40-pin bus I provided jumpers to allow NMI etc. to be linked to USER pins.

Steve

[Steve Cousins]

I've updated the RCBus document to include feedback received to date.

[Tadeusz Pycio]

It seems that I don't know my projects because I skipped two modules. There is also the Easy-Z80 which uses the IEI/IEO cascade. I have added these missing items to the document. It's worth remembering that there are also great J.B. Langston products that use USER pins to create a different ecosystem. He has used them for their intended purpose which has resulted in incompatibility with a number of modules. It is a good argument that leaving pins on the bus for any use leads to such effects.

[Brad Hines]

Hi all, 

I've been monitoring this discussion with interest and have not had much to add - it seems to be converging nicely.  

I will say that I am relatively new to getting back in to retro computing (it wasn't retro last time I was doing it), and after studying the existing state of things, I settled on Z50Bus for my system, for the reasons Steve Cousins mentioned (and purchased a couple of his backplane modules).  I like the idea of an enhancement that includes those improvements and that also arises from community consensus.

The thing I did want to weigh in on is the Bus Acknowledge daisy chain.  I wanted to offer an example of how it can be important in even small systems (like mine).  I want to share an example of

• A relatively simple system
• That will require at least two DMA devices
• And might grow to four while still being relatively simple.

My summary argument amounts to "Some folks might have use for the BusAck daisy chain - if there's room for it, is there a way to include it without any undue harm?"  

Of course, this is also a case of where, as soon as one asserts that nobody will ever need a feature, of course someone wants the feature.  One does have to be careful, or you can end up with a system that tries to be all things to everyone and collapses under its own weight.  But if the BusAck daisy chain could be included without disruption to the overall evolution of the bus, I feel like that would be a nice thing.

Background -  Legacy Machine

In my case, I am trying to enhance this legacy 8080A machine while preserving as much legacy functionality as possible.   

The legacy machine actually had zero I/O devices, believe it or not.  I was a poor high school student at the time, and all I could afford were 

• 1K of Memory
• 7-segment (octal) displays hanging directly off the address and data buses, and 
• 24 "front panel" switches for input.

You operated the machine by 

• taking over the bus
• entering (hand-assembled!) programs with the switches
• resetting the machine

I wrote little programs that would operate on values in memory and put new values in memory.  The most sophisticated thing was a "high-low" guessing game, where one person entered a value into a memory location, and the other would try to guess it in a series of program executions that simply reported whether the guess was high or low.

Project Goals

I would like to eventually get CP/M running on the machine.  I plan to add a Z50Bus backplane and use an ribbon cable to jumper from the legacy board to the backplane.

In the process of bringing the system up, the first device I want to add is a KIM-1 style keypad.  This would be fully a hardware thing - no monitor software running on the 8080.  It can poke and peek memory directly.  But meanwhile I want to preserve the legacy front-panel switch function.  I feel like the keypad will be valuable (and a fun device as well) as I try to gin up an OS from scratch.

So this keypad is going to be a second DMA device.  The front-panel switches would be the highest priority device, and then the keypad will have second priority.

From there, I want to add disk and serial ports.  I would like both of those devices to eventually use DMA, as it could be especially helpful with such a slow processor.  (I'd like to start with the simplest possible system, then work on BIOS upgrades to improve performance over time - I'm an embedded programmer in my day job and am interested to develop a highly customized ROM over time.)  I'd like to see if I can get serial data flowing in and out at 115200 or higher.  

DMA Device Summary

So there's my simple system, with four DMA devices:

• Front-panel switches
• Keypad
• Disk controller
• Serial port

And would like to grow to one or two more over time (audio for example?).

Closing Summary

Of course I can use BusAck jumper wires.  But I would love it if this kind of system could be supported directly on the new RC bus.  Then I could migrate whatever I build to the new bus when it becomes available, and have easy access to that ecosystem, and could build (and offer to the community) high-performance DMA-capable cards.

I'm excited to have discovered such a vibrant community.  I look forward to continuing to follow all the developments here.

Thanks,
Brad

On Wednesday, February 8, 2023 at 3:51:51 PM UTC-8 Tadeusz Pycio wrote:

Hi Steve,

I am in a bit of a dilemma as to what to call my projects these days, as I have often used the abbreviation RC2014 in descriptions, comments, meaning the bus standard and not the product. Another thing is that I consistently use the extensions you suggested, because I think they are needed and some will not work on the RC2014 bus. And this is where it should say "Designed for RC2014 and compatible with BP80 or SC"?
The problem of consenus - have any of the requests to add more signals on the bus propnned in the previous discussion taken physical form? I haven't seen the off-the-shelf modules with I2C, SPI, 3V3 on the bus that were supposedly so needed.  Yes I still maintain that the DREQ and possibly DACK signals are missing, I don't think there is a need to add a BAI/BAO cascade due to the assumed simplicity.
I personally wasn't convinced by the Classic ][ standard, but I wasn't the target audience for this product either. More often than not, I struggle to find space on the standard PCB dimensions to go towards making them smaller (trying to lay out a Z80 KIO or the topic I'm currently working on, the V40, are not possible on this size).
I think the RC40 is still the RC80 which is used half. :)
We should uniformly name our projects, because I don't know if I can still write: "I built, ran, messed up an RC2014 module", because it is not an RC2014 module. If we start using different names, we certainly won't help people getting into retro computing, because they'll think we're talking about completely different platforms.

[Mark T]

What would be recommended for high/low byte selection? Z280 seems to use a word/byte selection, while 68k seems to use UDS and LDS. I haven’t looked at the details recently to remember how each of these works. Is it better to pick one of these two methods and have other processors adapt to that interface, or pick a simple system for memory modules that can be easily adapted from either? I think I would prefer the latter, possible just an additional MREQ for high byte, or is it better just to have a second Write enable for the high byte as a separate MREQ could increase address decoding delays.

What methods have already been implemented?

[Bill Shen]

Looking over my Z80/Z180/Z280 designs I believe they are RC2014-compatible without using the USRx signals.  Some of my more compact designs do not have addresses A8-A15 so they only have 26 pins.   By using more integrated I/O such as KIO, Z84C15, quad serial, and CPLD emulation I did not find it necessary to have interrupt daisy chain.  For non Zx80 processors (I've tried 8085, 6809,6502, 65816, 68008, 68020, 68030, P90CE201), I've altered the Z80 control signals extensively and chaotically without a consistent methodology ("evolving thought process" is the kind word I used for that madness), so I certainly won't burden my chaos on anyone.  RCBus looks good from my point of view.  

I'm writing to express three thoughts:

*  Fitting non Zx80 processors on RCBus is stretching it too far, in my humble opinion.
*  KIO is cheap, provide high integration of I/O and possibly eliminate the needs of EI/EO
*  How about 14.7MHz as the standard CPU clock?

  Bill

[Tadeusz Pycio]

I once tried to adapt a 16-bit Z-BUS bus to an RC80 bus and it failed. The signals are so different that trying to adapt them to the existing signals on the RC bus severely limited the Z280, Z8K processors with their peripherals. For this reason, my Z-Bus project has been lying in the waiting room for 3 years now, as I took care of the RC80 modules. Here when trying to add different 8-bit processors to the Z80 I have not encountered such limitations, I think my 6809E/6309E module works well on this bus and I have not encountered any problems so far.

The system clock issue, I think this problem does not exist if you use serial transmission modules with their own clocking. I have RCBus systems clocked at 6.144, 7.3728, 9.216, 12.288 and 18.432 MHz and there is no limitation with such different from 7.3738 MHz.

The subject of the BAI/BAO cascade has been raised with constructive argument, so I guess the topic should be revisited. In this situation, we also need to be clear about how many interrupt lines we want (I thought two were enough) and DMA service request lines (here again, my musings limited the number to 2).

[Wayne Warthen]

On Saturday, February 11, 2023 at 12:30:44 PM UTC-8 Bill Shen wrote:

*  How about 14.7MHz as the standard CPU clock?

Just be aware that a CPU clock of 14.746 MHz results in pretty funky baud rate options on the Z180 (for it's built-in ASCI ports).  See attached matrix.

-Wayne

[Bill Shen]

I'm thinking for RCBus to be different significantly from RC2014, it needs to be more than the addition of EI/EO or DMA request/ack signals.  I think it should graduate from RC2014 concept of one-function-per-module to faster, more integrated, more compact, and cheaper retro computers.  SC108, Sergey K's TinyZ80, and many of my designs already consolidate RAM/ROM on board, so with that approach RCBus is more like an I/O bus than a memory expansion bus.  RC2014 has served its purpose educating people about CPU/RAM/ROM/clock/CF resulting in CP/M which took 5 boards to implement.  We don't need to repeat that, consolidate these functions in a board, make it cheaper and faster and start looking at KIO, ethernet, video, sound and for the RC80 bus maybe multi-master,s multi processors capability.

I'm not suggesting banishing non-Zx80 CPU from RCBus; I'm suggesting NOT extending RCBus to accommodate the few potential non-Zx80 processors; put the onus on the non-Zx80 designers to fit RCBus.  Some may fit nicely, but other may not, but that's the designer's challenge.  My suggestion is putting all memory on board with the processor then it becomes easier to fit 68K, Z280-ZBUS and other non-Zx80 processors on RCBus.


Yes, Z180 wants to run at 18.4MHz or 36.8MHz whether it is RC2014 or RCBus thus it is non-standard frequency for both buses.  Speaking for myself, it is not all bad, it has spurred me to come up with varieties of I/O that can run much faster than the standard 7.37MHz bus.
  Bill

[Tadeusz Pycio]

Hi Bill,

It seems to me that you are talking about something completely new by rejecting existing solutions. I think it's too revolutionary a concept, because modules have already been made for over a hundred and users will probably be reluctant to put what they have in the box. Yes, I myself often have such feelings when designing modules, when I have to use circus tricks to route the power lines quite correctly, which, not knowing why, is in the middle of the bus, I get white fever when I have to make a memory module and have the address and data bus separated by control signals. This standard is what it is and I don't think anyone will want to switch to it. You are right that the appetite grows as you eat and atomic modules containing a single element are not very attractive, but this also requires a change in the size of the PCB that everyone is used to. Here we are trying to add functionality to an existing state that has not been implemented, or has not been officially standardised.

[Bill Shen]

I don't think consolidating CPU/ROM/RAM is unusual.  SC108 is well-known, Sergey introduced his TinyZ80 here.  Since I don't sell on Tindie, my stuffs are less known.  The one on my bench right now testing KIO and VGA/PS2 is the 14.7MHz ZRC which runs RomWBW.  ZZRCC is 14.7MHz Z280 SBC that also run RomWBW.  ZRC and ZZRCC are Classic RC2014 compatible in standard 50x100mm pc board.

Z280 in ZBUS mode is indeed like a different processor.  Make it work with RC2014 is more work, that's why Z280RC is 75mmX100mm but with Classic RC2014-compatible bus.  Similarly the 75mmX100mm T68KRC is 68000 with Classic RC2014-compatible bus.

Like SC126, I also have reversed passive backplane to active motherboard.  So CPLD trainer can accommodate Z80, 6502, and third processor on a motherboard and with a RC2014-compatible expansion.  CB030 is 24MHz 68030 motherboard with RC2014-compatible connector.

Consolidated SBC is faster, cheaper, easier to build and less bus loading so backplane is freed up to develop new boards.  I found them to be more reliable as well.

One KIO can replace SIO, CTC, and PIO; RomWBW already setup for KIO; don't have to worry about EI/EO between boards; and KIO chip is cheap.  I really don't know why people don't use KIO more often.
  Bill

[Tadeusz Pycio]

I think it's a case-by-case thing, some people think a computer should be made up of elementary modules, others think you should go for a 2, 3, 4 module system, and there are those who think SBCs are the right choice. What they have in common is a unified bus and I think that's where the beauty of this solution lies.

[Steve Cousins]

I've attached the latest update to the "current situation" document. 

While I'm sure there are other uses for the USER pins I think we now have a pretty good idea of the range currently out there. The good news is most designs have jumpers to make use of these pins optional.

Steve

[Tadeusz Pycio]

Hi Steve,

I have applied amendments for the J.B. Langston modules. It uses more connections.

It looks like most of the modules meet the requirements to be able to call pins 37-39 unambiguously with backward compatibility. Pins 77-79 remain open, although the former already has its use. What remains to be determined is where and how many pins should be allocated for the DREQ(RDY) signals and the postulated BAI/BAO cascade. A bus defined in this way will ensure compatibility with most retro 8-bit CPUs. It would be worthwhile for authors of 68k solutions to specify which signals are missing for their modular implementation, solutions for 8-bit x86 should already work in the current state, and in the case of Zilog's 16-bit ZBUS (Z8000, Z280) I personally don't see any chance for a modular solution - RCBus can be used as SBC.

[Alan Cox]

Accidentally sent these replies to Bill only

> * Fitting non Zx80 processors on RCBus is stretching it too far, in my humble opinion.
> * KIO is cheap, provide high integration of I/O and possibly eliminate the needs of EI/EO
> * How about 14.7MHz as the standard CPU clock?

Having fitted all kinds of processors to the bus I would disagree. In
fact if it could only do Z80/Z180 I'd have given up on RCbus by now as
junk. Mind you people said S100 was only fit for 8080 8). I don't btw
consider it can do Z280 because my experience of Z280 in 8bit mode was
that it was so buggy it was unusable. Yes the bus signals should be
Z80 timed and if a givn board fails to work with non Z80 then you get
to keep both pieces. In practice this only appears to affect the Zilog
peripherals (which have internal knowledge of Z80 state and don't work
with anything else period)| and some ACIA cards because of the way
they are wired to fake motorola bus to the chip.

The KIO does not eliminate the need for IEI/IEO because you cannot
operate in IM2 mode with any interrupting device that does not honour
the chain as you'll get bus contention, random bits and crashes. There
are S100 style schemes for pull ups but if you look carefully at how
they work most of them only work for NMOS parts. Now I admit that
personally because of the chain length rules and the like I consider
IM2 an amusing hack for single board machines anyway and rarely use
it. Actually using it in anger tends to involve having multiple IRQ
lines wired to a PIO or CTC used as an interrupt controller instead.

I don't think a standard clock is necessarily a good idea. It's also a
bad idea to make it different from the RC2014 one if so, and a really
bad idea to make it default to one that is too fast for most of the
parts, and worse yet, too fast for the scopes and logic problems most
hobby builders will have access to. In addition the way processors
relate to clock is a bit more complex.

The RC2014 clock fits the 68xx devices very well along with the later
8085 parts all of which have a usual max of 8MHz imput clock. It's a
bit hairy for 6502/65C816 because the CPU cycle really is one clock
cycle so a 7.3MHz 65C816 is actually at the point the 512/512K card
needs 74AHC so is better run at lower speed.

Also except for the Z80 SIO (which doesn't have a 14MHz part) and the
68B50 (which is only within spec to 8MHz) all the serial cards
generally have their own clock anyway.

Alan

[Alan Cox]

> I'm not suggesting banishing non-Zx80 CPU from RCBus; I'm suggesting NOT extending RCBus to accommodate the few potential non-Zx80 processors; put the onus on the non-Zx80 designers to fit RCBus. Some may fit nicely, but other may not, but that's the designer's challenge. My suggestion is putting all memory on board with the processor then it becomes easier to fit 68K, Z280-ZBUS and other non-Zx80 processors on RCBus.

I think the discussion there is more around things like the Z280RC and
MB020 where the memory speed is also a consideration. On the SC126 for
example you can omit the RAM or ROM and plug in an external card if
you want to experiment with different memory options, and something
akin to the Retrobrew 4M card would be interesting.

There are two things from that IMHO. One is easy, the other is
probably not the same bus.

The first is to define the I/O subset of the RCbus for that kind of
use - so D0-D7 A0-A7 IORQ M1 INT RD WR VCC GND, or something like
that. That way anyone building a card has a clear view of what pins
would be on a minimal system.

The second is harder because a smarter I/O slot just for I/O would
have the decode done by the motherboard by slot (say a \CS and A0-A3)
as well as probably qualifying RD/WR and things like IRQ priority
being up to the mainboard. I don't think that's something you can make
look like an RC2014 card.

Alan

[Alan Cox]

> Like SC126, I also have reversed passive backplane to active motherboard. So CPLD trainer can accommodate Z80, 6502, and third processor on a motherboard and with a RC2014-compatible expansion. CB030 is 24MHz 68030 motherboard with RC2014-compatible connector.

I think this is a great model. I was looking at the 16bit data bus on
the RC2014 whilst sketching out the i960 design and aside from the
lack of enables it's actually really hard to route 24bit data and
16bit address plus RAM/ROM etc on a single RC2014 size card. I'd not
seen you'd gone to 68030. I saw the 68020 design (in fact it's now in
the emulators).

> Consolidated SBC is faster, cheaper, easier to build and less bus loading so backplane is freed up to develop new boards. I found them to be more reliable as well.

Agreed - my SC126 just works. The big backplane machine gets cards
pulled in and out a lot. Now and then needs poking (and it's had once
cycle of resoldering all the connectors).

> One KIO can replace SIO, CTC, and PIO; RomWBW already setup for KIO; don't have to worry about EI/EO between boards; and KIO chip is cheap. I really don't know why people don't use KIO more often.

I've got one KIO based machine and Fuzix auto-detect
KIO/SIO/ACIA/Z84C15/EasyZ80 layouts. It's an OK chip but it lacks
FIFOs. It is nice in the fact it's got real PIO built in so you can
drive SD cards, SPI WizNet and printer ports off it if you need to.
Apart from the PIO side though I preferred the 64180/Z180 with all
that built in and generally better with the CSIO SPI.

Alan

[Steve Cousins]

I agree with the comments about greater integration. This can help resolve some of the problems with other processors. The bus does not have to account for all the features of other processors but instead becomes little more than an I/O bus (in most cases). It is this approach I have taken to RomWBW on a Z180 processor on the Z50Bus. The extra address lines are not needed on the bus, which is limited to 16-bit addressing. In addition, the SPI port for an SD card is also integrated onto the board, saving the debate about SPI signals on the bus and/or removing the need for extra wires between cards.

I also agree with the greater reliability of integrating more functions on a single board. SC126 is a good example of that. I'm tempted to make a version of SC126 with a couple more bus sockets as 2 doesn't seem quite enough even with SC126 handling most of the basic functions people need.

I find the 4"x3" (100x75mm) format of my Z50Bus designs to be a very good size. It allows much more functionality on a card or greater component spacing (which I think is a good thing especially for kits)

I've attached a picture with the following designs for comparison:
SC527 Z80 processor card for Z50Bus (roughly equivalent to SC114 SBC/motherboard)

SC503 Z180 processor card for Z50Bus (roughly equivalent to SC130 SBC/motherboard)

SC108 Z80 processor module for RC2014 bus (standard module size)
SC149 Z80 CPU module for RC2014 (Classic II low profile module size)

I feel the classic II size is best for a system of single function modules (it is small, easy to remove modules from backplanes, and very attractive IMHO), while the Z50bus card size is best for more highly integrated designs. The standard RC2014 module size fall between them.

While anyone can make an RCBus card of any size they fancy I think it would be worth adding a larger card size suggestion to the bus specification as an option.

Steve

[Bill Shen]

On my homepage I counted 15 active motherboard designs with one to four 40-pin RC2014 style connectors.  Beside being compact and reliable, they are very useful encapsulating a project idea that can be put away in a box with few notes and returned to it months/years later.  I have 3 official RC2014 backplane, but that's hardly enough so I've build up many motherboards that are only populated with RC2014 connectors and power jack and use that as small backplane; then I discovered the area of un-populated active circuits is great place to add monitor/diagnostic logic.  My recent motherboard designs have mounting hole pattern for PacTec CM5 boxes which I bought a whole surplus lot.  This gives me a compact way of storing all the boards I have.  I've gone from not giving a thought about enclosure to now designing specifically for enclosures.

KIO not only combine SIO, CTC, and PIO, it can also overclocked recklessly to 30MHz (it is rated 12.5MHz).  So it can interface to fast SC126 and many of my SBC.  Another serial device I used frequently is quad-serial OX16C954 with 128-byte FIFO.  It is designed for Intel as well as Motorola timing and very fast (60MHz), so one board is good for Zx80, 6502, and 68K.  I was pleasantly surprised when RomWBW autodetect it as 4 channels of 16C550.
  Bill

[Bill Shen]

If we do want to accommodate a varieties of processors, I felt we may need to have different bus than a close relative of RC2014.  In G8PP I tried to accommodate different processors with heavily modified RC2014, but that was unsatisfactory.  In a more recent attempt, I have designed GRC with the idea different CPU board but reusing RAM, ROM, CF, serial, PS2, VGA.  Picture shows GRC populated with Z80 that can run RomWBW.  One interesting feature is the mass storage (disk-on-module) is designed into the backplane.
https://www.retrobrewcomputers.org/forum/index.php?t=msg&th=703&start=0&

[Gary S]

I might be thinking a bit too far ahead but....

Maybe an extra extension shoud be considered now rather than have another reinvention later..  RCBus > RC120 ?.
Obviously RC80 is a subset of RC120 same as RC 40 is a subset of RC80.

Define out whats needed to keep going to 64bit stuff (& Beyond ?) and try and lay it all out now rather than doing similar in years to come.

May never be required, but its better than a top/side nonstandard connection.

[Mark T]

I think you would need to go further than rc120 for 64 bit unless you multiplex address and data.

[Doug Jackson]

I am all for improving specifications, but I do have to ask at what point of complexity (pin count / bus word length / address width?) should we look at using an established bus structure using quality connections, such as ECB?

There is a well established z80 / z180 world that uses the ECB backplane system using two or three-row versions of DIN 41612 connectors, and using Eurocard formats for the physical dimensions.  Some of my extant Z180 and even 80186 systems already use ECB, so there are a heap of boards available.

And using the DIN 41612 connectors means no crashes when the system is bumped after the backplane connectors get a bit soft (It has to be said that the RC2014 connector style is not designed for many insertions and becomes loose over time).

 

Doug

--
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/05e0422f-b45a-47f4-a289-a86b6bd4d0afn%40googlegroups.com.

[Steve Cousins]

I want to see the RCBus project move forward but fear it will fade away unless someone makes firm proposals. So here goes.

The term "RCBus" should be adopted as an alternative to using the trademark "RC2014" when referring to designs that have a degree of compatibility with official RC2014 products but are not products from RFC2795 Ltd, the owner of the RC2014 trademark. This should satisfy Spencer's concern over trademark and confusion issues.

The following is aimed at keeping designs simple and low cost, and building on the eco-system we already have. It is about extending the bus specification, not about starting from scratch with a new system. Maintaining backward compatibility is a limiting factor but a critical one.

The term "RCBus" can be used for any designs that meet the RCBus specification. So we need to write that specification.

The retro-comp google group will be preferred over the rc2014-z80 google group for discussion of designs and issues relating to RCBus products, especially for those designs that are not entirely compatible with the official RC2014 specification.

The term "RCBus" is an abbreviation for "Retro-Computer Bus". The bus itself is formed with male header pins on the bus cards and female bus sockets on the bus backplane. Readily available, low cost, 2.54mm (0.1") pitch connectors are used, either 1 row of up to 40 pins or 2 rows of up 40 pins each.

The RCBus specification will clearly define the function of each pin on the bus, except any pins left completely free for the end user to do as they please. No commercial modules should require the use of USER pins or make any assumptions about them. Thus, no commercial products will create compatibility issues due to uncertainty of USER pin functions. However, commercial products can use jumpers to provide optional features to the end user via USER pins.

Not all modules use all of the pins. Some modules may use as few as, say, 26 pins if they are simple 8-bit I/O modules. While the RCBus offers support for a variety of processor families with their different control signalling schemes, not all modules need to support all the schemes.

The official RC2014 specification is a subset of the RCBus specification. This subset is "RCBus-2014".

Extensions to the RC2014 specification are identified by different sub-sets of the RCBus specification. For example:
- The Z80 extensions (RCBus-Z80) include the IEI and IEO interrupt daisy-chain
- The Z180 extensions (RCBus-Z180) include the Z80 extensions plus extra address lines and interrupt lines
Perhaps this can be rolled into one subset?

The RCBus supports a range of processor signaling types, such as Intel (eg. 8080) and Motorola (eg. 6502). To avoid simple modules having to support all varieties of signalling types, or even just processor modules needing to provide non-native signalling types, the RCBus specification has subsets for each type. These types might include: RCBus-68xx and RCBus-Z80.

A product can claim to be compatible with multiple subsets. For example:
- A Z80 memory module might be compatible with RCBus-2014 and RCBus-Z80
- A 6502 CPU module that includes circuitry to generate Z80 style bus signals might be compatible with RCBus-2014 and RCBus-Z80
- A 6502 CPU module that does not include circuitry to generate Z80 style bus signals can not be RCBus-2014 or RCBus-Z80 compatible

Having distinct subsets should help when describing the compatibility of a design. Without such a mechanism it will be more confusing trying to describe how an 8-bit memory module is not suitable for use with a specific 16-bit CPU module. As new modules become available trying to describe compatibility by listing all the compatible or incompatible modules becomes a nightmare.

Well, that's what I have so far.

Now I'm now off to find my flame-proof clothing.

[Tadeusz Pycio]

I think RCBus-Z80 and RCBus-Z180 are the same thing. I have a Z80 module with an MMU that supports more address lines, just like the Z180. On the Z80 through a CTC chip, or if someone designs a PIO, it can support more interrupt lines in IM2 mode. Regarding other architectures - full agreement, a given processor should be able to communicate with existing memory, serial transmission (not Zilog) and storage modules, which does not exclude the existence of architecure-specific I/O modules (which did not have to be fully compatible with RCBus-2014, but with a given solution).
More complicated is the issue of USER pins, as these should have a defined meaning with the ability to disconnect them on the module for backward compatibility. Perhaps a compromise would be to name them e.g. IRQ1/USER1? I'll say it again, there should be no room for experiments on the shared bus, the outer edges of the PCB are for that purpose.

[Steve Cousins]

Hi Tadeusz,

Okay, so we seem to be on the same page with the Z80/Z180 issue and with the architecture-specific modules.

I agree the current USER pins need more defined functions, but disagree about the bus NOT supporting room for experiments.

The existing USER pins are problematic due to the desire for backward compatibility, where limitations in the RC2014 bus specification have led to a variety of solutions using USER pins. USER pins should never have needed to be used in this way. Not a good starting point for a tight specification.

I think it should be noted that this is primarily a hobby platform and not strictly a commercial one. Many members of this community will be unhappy if there is no flexibility in the bus for experimental and custom solutions. 

I think the compromise is a number of pins totally free for end users. Common requirements, such as IEI/IEO need to be specified with dedicated pins and not end up repurposing USER pins. The problem with the existing USER pins is we now want to incorporate their de-facto functions into the specification. If, for backwards compatibility, we assign the existing USER pins to their de-facto functions then we should allocate new pins as USER pins. This does not undermine the bus specification if they remain free for the end user and don't get repurposed to overcome shortcomings in the specification. I see these new USER pins as no different from a set of pins designers might fit to the top edge of their modules for custom functions, except they offer the convenience of the backplane for interconnection. The key requirement is any use of USER pins by commercial products is that they are optional and can be isolated with jumpers etc. They must remain under the control of the end user.

Steve

[Tadeusz Pycio]

Hi Steve,

Looking at the table with the use of the USER pins it is the vast majority that use these signals explicitly. Leaving them as freely usable by the user doesn't improve anything, it will still be the RC2014 bus just with a different name. That there are missing signals there is a known fact, there are no additional interrupt lines for devices that cannot handle IM2 mode, for devices that do, there is no IEI/IEO cascade. The use of DMA channels by I/O devices is currently impossible there without creative use of existing pins by designers. These shortcomings are not conducive to development, as my module may not work with yours and many other designs.  A standardised bus should give you the confidence that by using any modules you don't have to wonder if it will cause a conflict. USER pins are a great idea when there is a monopoly of module creation and it is predetermined what the whole thing should look like - this is what Spencer postulated, this is supposed to be a simple Z80 computer and only he has the right to call it that.

[Steve Cousins]

Lets consider what signals we want that are not part of the RC2014 spec. 

From above comments :

Z80 style: IEi/IEO daisy chain, BAI/BAO daisy chain

68xx style: FIRQ, E, RW

TMS9995 style:: MEMEN, CRUIN, CRUCLK

Interrupts:

We have NMI and INT which could presumably have different names for other architectures but essentially the same functions.

We could do with a couple more interrupts: INT1 and INT1

Power:

- 3v3

16-bit systems:

- Hi/lo select

Can we say the architecture specific signals are mutually exclusive so can share the same pins? 

I doubt there are enough pins available to support all possible architectures without doing this.

What have I missed in my list above?

[Bill Shen]

Someone is interested in a P90MB so I updated the homepage for rev1 P90MB (a 68000 clone) and adopted the name RCBus as a trial balloon (even though I've mentioned RCBus should not be stretched for other processors and I still believe that, but this is a trial balloon).  This board was designed 3 years ago and meant to accommodate selected RC2014 board.  See the attached schematic.

I can see few problems:
* P90CE201 has 7 interrupts, 3 of them are assigned to three of the RCBus slots; this means each slot has different interrupt level.
* Only mode 1 interrupt will work
* Clock is 12MHz thus incompatible with I/O boards expecting 7.37MHz clock
* USRx pins are not ganged together so each slot has its own 4 jumper pads.  This is because P90CE201 has many I/O pins that I thought different functions may be jumper-ed to different expansion slot.

I want to show potential compatibility issues with RCBus when non-Zx80 processors are involved.  I think when drilling down into details of RCBus (as a designer should always do), many subtle incompatibilities will be revealed and force the designer to adopt a "RCBus-Like" level of compatibility.  In fact, I called it "RC2014-like expansion bus" in my previous revision which Spencer had no problem with.  You'll also need a relaxed RCBus spec for non-Zx80 processors simply because strict conforming to Z80 protocols is unlikely.  

This is a trial balloon, please feel free to pop it.
  Bill

[Tadeusz Pycio]

Yes, to our current knowledge, other architectures can use the same pins without conflict - devices that use the IEI/IEO cascade will not work on the Motorola bus anyway. The issue of 3V3 was raised, I think the appropriate place would be for modules that use this voltage, especially as there will usually be 5V/3V3 converters to match the 5V rail. Adding it to the bus would require the abandonment of the existing backplane, as none of them provides this voltage and there are no sufficiently wide paths to route the additional power. Adding DREQ signals is not a big problem, it's just a matter of which pin will handle them. The big problem arises for the BAI/BAO cascade, because the bus already has a BUSREQ signal. Here I have absolutely no idea how to implement this elegantly (separate BAI/BAO signals and routing to BUSREQ on the module?).

[Mark T]

BUSRQ is separate to BAI and BAO, you need all three, BUSRQ is common across all modules and driven by open collector input/output drivers. BAI and BAO form a priority chain, at the highest priority BAI should be linked to z80 BUSAK output. Modules providing DMA should provide a link for this option with BUSAK common across all modules for this purpose.

[Tadeusz Pycio]

You are right, I was thinking of BUSAK and persistently misspelled BUSRQ....
The only pins that are next to BUSAK are HALT and CLK2 which will be hard to give up so that you can reasonably arrange the cascade on the backplane.

[Mark T]

Yes, leave BUSAK where it is, this is generated by the z80. Then a separate BAI/BAO with the option on the DMA modules to take BAI from BUSAK.

Another question raised by having both a BAI/BAO chain and IEI/IEO chain, should they run in the same direction? I think they should.

[Tadeusz Pycio]

It seems that they should run in the same direction, for the IEI/IEO signals I have realised on the backplane with the possibility that the signal should run one way or the other with the possibility of 'skipping' a slot that does not use it. The same should be done for BAI/BAO.
The BAI/BAO cascade can also be realised as it is in the N8VEM, with a wire connection.

[Mark T]

Probably three options for IEI/IEO and BAI/BAO.

1. Links between modules.

2. Chain between modules, needs custom backplane and a method of linking the chain across modules where chain is not used.

3. Select links between each of the inputs and outputs to a selection of the user pins bussed between modules on a standard backplane.  For example use 38 to link IEO from module 1 to 2 and 39 to link from module 2 to 3.

Possibly not mutually exclusive options.

There is always the final option to isolate a pin on any module from the bus by removing that pin from the module.

[Paul Williamson]

On Tue, Feb 14, 2023 at 3:14 AM Steve Cousins <steve...@gmail.com> wrote:

Not all modules use all of the pins. Some modules may use as few as, say, 26 pins if they are simple 8-bit I/O modules.

There are existing official RC2014 modules that use far fewer than 26 pins. For instance, the Pi Zero Serial Terminal uses just 4 (VCC, GND, RXD, TXD). Likewise with the Pi Pico VGA Terminal and the ESP8266 Wifi Module. For less trivial examples, the ZX Printer module uses just 14 pins, and the popular Dual Clock Module uses 8 (if you include both copies of VCC and GND).

I see no need to mention a minimum number of pins used, even as an example.

There are other things to say about unused pins that are more important than their number. I'm thinking along these lines:

  - As a minimum for mechanical strength, pins 1 through 34 on the primary bus shall be physically present.

  - If the module has multiple configurations, each configuration shall be documented as fully compatible or partially compatible with respect to each supported subset.

  - In all fully compatible configurations, each pin shall be used as specified or physically disconnected from any circuitry on the module.

  - The module shall support at least one useful configuration that is fully compatible with respect to each supported subset.

This is a sort of middle ground on the issue of experiments. Modules can use the defined bus pins for experimental purposes, but those uses must be jumper-selectable, and you can't claim compliance if your module isn't useful without abusing any defined pins.

[Kande Laber]

As a retro computer newbie I am really impressed about the enthusiasm here. But be careful: The "beauty" of the RC2014 and Grant Searle based designs is its relative simplicity. This made the retro technology reachable for the non-cracks. If you start to design for the cracks only, you will risk to loose the non-cracks. The community would risk to just disperse.

[Alan Cox]

> Z80 style: IEi/IEO daisy chain, BAI/BAO daisy chain
>
> 68xx style: FIRQ, E, RW

(the 680x and 650x bus mastering are basically the same if you squint
hard. They used to be made to interwork on Apple II, on S100 and I
believe that's how the Commodore 128 does it as well.

> We have NMI and INT which could presumably have different names for other architectures but essentially the same functions.
> We could do with a couple more interrupts: INT1 and INT1

Agreed - almost everyone has an NMI that I can think of by some name
or other. Extra interrupts vary a lot and then you have to field
things like "what is the priority order". Having at least one
"probably higher priority" interrupt extra line makes a big difference
because you can keep serial on its own faster interrupt without all
the fun NMI causes.

S100 never sorted out the IEI/IEO chain. It remained an 'over the top'
cable even on things like the big Cromemco boxes that used IM2
heavily. partly I imagine so you could get cards in the places they
needed to be for venting or external connectors and then spaghetti
wire the interrupt priorities. It did sort DMA priority but that's a
complicated implementation and I think inappropriate to the RCbus
mindset.

Must admit I really like Bill's answer to that one. Perhaps the right
way to deal with such things is to simply shrug and say "so put an
interrupt controller on the motherboard".

> Can we say the architecture specific signals are mutually exclusive so can share the same pins?
> I doubt there are enough pins available to support all possible architectures without doing this.

I think we kind of did. It's become a defacto standard for the IEI/IEO
Zilog and the 680x/650x cards.

> What have I missed in my list above?

Nothing I can think of that is needed. The 65C816 has an abort pin,
the 68000 has ways to indicate bus faults and asynchronous timings but
they probably fall outside of any normal RCbus usage as you'd have to
do wait stating instead to make existing cards work sanely and aborts
and faults are not really part of the current cards and architecture.

The Z8 and the 8051 have a distinction between code and data space but
it a) doesn't matter that much and b) could use A16 or something if
anyone actually cared.

Alan

[Mark T]

Would an address strobe be useful, maybe to allow use of 8155 on 8085 or 8748 type?

The low byte of address would probably be latched on the processor module to make it compatible with existing modules, but the address strobe would make it easier to add some specialist support chips.

[Steve Cousins]

I think this is beginning to come together.

I've looked over all recent comments on this topic and studied the current user pin functions. I think I've whittled it down to what we seem to need/want without breaking compatibility with existing designs and products, wherever possible. I've added some tables of proposed pin assignments to the RCBus document.

Steve

[Steve Cousins]

Ooops, just noticed I duplicated the USER pin table end edited for pins 41 to 48 but forgot to remove the RCBus-2014 pin functions. There shouldn't be any as these pins don't exist on the RC2014 bus.

[Steve Cousins]

Correction attached

[Tadeusz Pycio]

Would an address strobe be useful, maybe to allow use of 8155 on 8085 or 8748 type?

 I think we shouldn't get too used to Zilog-specific signals, since we can allocate IEI/IEO for other purposes, we also have an M1 signal that will only work with Zilog processors and peripherals. The Byte/Word issue - here we can easily use the PAGE signal. It is just a matter of our arrangements, as we will have unused signals in such cases.

[Tadeusz Pycio]

First attempt to adapt my backplane 4 to the BAI/BAO cascade.

I assume that the BUSAK->BAI connection will be implemented on the highest priority module.

[Steve Cousins]

Hi Tadeusz,

Very nice. You beat me to it. I was going to try one of my backplanes, but also modify it to use your rather neat jumper tracking scheme. I think that is the way to go and wish I'd thought to do it that way.

If we think of any other signal that might benefit from an isolation option there is still room to have a jumper on pin 44. Just a thought.

One thing troubling me about my existing backplanes (SC112 and SC113) and yours as well, if I remember correctly, is the use of pins 40 and 80. As they are not generally used I wired them as a daisy-chain but the feature has never been used as far as I know. 

Steve

[ladislau szilagyi]

Hi Steve,

I personally used the interrupt daisy chain on your SC112 , between SC110's SIO and SC103's PIO, in order to write (and run) the parallel printer driver on my RTM/Z80.

It runs to handle printing to EPSON LX 350.

It was you to teach me how to do-it...remember, back in 2021? 

regards,

Ladislau  

[Tadeusz Pycio]

Hi Steve,

I think you have something to work on - 6 slot backplanes and expanders won't do themselves ;-)
I don't see a problem with adding a jumper to pin 44.

In my previous backplane (v1.2) and in the current one, I abandoned the cascade and pins 40 and 80 are routed to pins 40 and 80 in the next slot. This was due to the fact that I became the owner of a Z80 trainer popular in my country in the 1980s with an RCBus port - the CA80 - in which these pins are used (curse of the USER pins).

[Tadeusz Pycio]

I have completed work on the backplane. I am concerned about the lack of undetermined DREQ signals on the bus. I think this is the last issue that should be fixed for RCBus with an 8 bit Zilog compatible bus. We already have partially fixed where the Motorola compliant signals will be. Perhaps those interested in the subject should comment here?

@Ladislau - It was because of your RTM/Z80 that I started looking for a solution to arrange the cascade of interrupt piorities on the backplane. :D

[Steve Cousins]

I agree we should allocate pins for any remaining common features. What do you suggest?

I'm adapting my backplane design at the moment. I see you have only labelled the standard RC2014 pins. I think an RCBus backplane should label all the standard RCBus pins. I think it is time to finish the pin allocations so we can decide how to label the backplanes.

[Steve Cousins]

I find myself thinking along these lines. 

The RC2014 style USER pins are only called USER pins when the backplane is used as an RCBus-2014 backplane. 

When used as an RCBus-Zx80 backplane they have functions defined by the RCBus-Zx80 part of the RCBus specification.

The physical backplane (the RCBus backplane) is the same for both, just the signal usage changes.

I am therefore playing around with labelling them n37, n38, n39, etc.

They could be left with no labels but then it is difficult to refer to them in documentation and instructions.

I'm still thinking about waht to label pins like NMI and M1 that only have these functions for Z80 style processors.

[Tadeusz Pycio]

Hi Steve,

You have raised a very important issue of naming. You are absolutely right that one should use neutral names for pins that are architecture specific. This approach will lead to RCBus becoming a universal platform for modular designs. The problem is that we don't have feedback from people who have knowledge of the requirements of an architecture other than the Z80. My knowledge of, for example, the 6809 is poor, if it wasn't for help I wouldn't have created my HD63C09E module and I certainly haven't exploited the capabilities of that processor for that reason. It would be worthwhile for people who have experience with other architectures to comment in this thread.

[Alan Cox]

On Fri, 17 Feb 2023 at 22:33, Steve Cousins <steve...@gmail.com> wrote:
>
> I find myself thinking along these lines.
> The RC2014 style USER pins are only called USER pins when the backplane is used as an RCBus-2014 backplane.
> When used as an RCBus-Zx80 backplane they have functions defined by the RCBus-Zx80 part of the RCBus specification.
> The physical backplane (the RCBus backplane) is the same for both, just the signal usage changes.
>
> I am therefore playing around with labelling them n37, n38, n39, etc.
> They could be left with no labels but then it is difficult to refer to them in documentation and instructions.
>
> I'm still thinking about waht to label pins like NMI and M1 that only have these functions for Z80 style processors.

NMI is generic I think. Might be called something else in some cases
but whether it's the top interrupt priority, XIRQ, NMI etc it's the
same thing. Some other processors do have an M1 equivalent but I'm
not sure it's useful in this context.


Alan

[Mark T]

Maybe M1 and RFSH should be pulled high by non z80 processors as this would have least impact on modules that might qualify M1 and RFSH. Probably not important for RFSH but quite a few input/output modules where the designer qualifies M1 high, even though not required in most cases.

[Alan Cox]

The bus sort of assumes you are mapping things onto a Z80 style context.

Going through the lines
5v, D0-Dn, A0-An are the same on just about every other CPU, but they
may be multiplexed and that is handled by the CPU card
GND/Vcc are the same obviously
/RESET is the same (some processors use RESET some /RESET and some
have particular requirements but that again is handled on the CPU
card)
/INT is fairly generic. Polarity and the like vary and the CPU card
might be doing some magic

/MREQ /IORQ /RD /WR are less so. Motorola bus devices have an E clock
and no separate I/O space. However in order to make the bus work
sanely and portably you generate these signals on the CPU card. It's
also something everyone is used to because you end up needing those
signals broken out anyway.

CLK is more complicated. I would be inclined to cover bases as best as
possible with

CLK : Optional. CLK is a CPU clock or a signal synchronous to the CPU
clock. The signal SHOULD have equal high and low times and range from
close to Vcc to close to 0V. For full RC2014 compatibility the signal
MUST be the Z80 processor clock and MUST be 7.3728MHz. If a Z80/Z180
or similar processor is used this signal SHOULD be the processor clock
in order to enable the use of Zilog peripherals such as the CTC, KIO,
PIO, and SIO.

Any device using the CLK line SHOULD provide an option to talk a clock
from another location or provide the option to populate it with a
clock of its own.

\M1: Required. On a Z80, Z180 or similar processor this signal MUST be
the \M1 input. On other processors it MUST either be pulled high or
provide equivalent bus semantics to the Z80. This is required as some
cards include M1 in their decoding (generally unnecessarily) to handle
Z80 interrupt cycles.

The reasons here being
- Some parts (including Z80 parts) require that the clock has those ratio and
- Some I/O devices get very weird if you have clocks that don't line
up with the CPU
- RC2014 depends upon the speed and the clock being the Z80 clock for
the Zilog peripherals

That leaves /M1 which is very Z80 and other cards mostly pull high,
and the user/serial pins on the 40 pin bus. There are /M1 equivalents
on many processors but it's not clear what use /M1 has generically.

On the 80 pin bus /RFSH has no real equivalent but nobody uses it
anyway. Historically 680x/650x systems had something else doing DRAM
refresh or just used SRAM. Usually it's the video (6845, SAM etc).
Doesn't really matter.

PAGE is a bus specific signal and kind of weird historic RC2014ism

A lot of the processors have a /HALT equivalent but nobody uses it anyway

/WAIT is interesting. Most of the processors have a wait mechanism
(68E09 is the obvious exception), but some of them have asynchronous
completion instead. So instead of a /WAIT the other end of the bus
generates a signal indicating completion. Very little uses /WAIT and
it's possible to make it work with a bit of CPU card glue.

/BUSRQ /BUSAK and friends have equivalents in some processors. and can
usually be mapped onto the Z80 scheme.


What happens to RFSH probably doesn't matter. If you plug a 40pin CPU
card into the bus then it's unconnected and that seems to be the norm,
plus nothing actually uses it anyway.

[Steve Cousins]

I've attached a first attempt at creating a table of the bus signals and names

[Steve Cousins]

Mark

That's a good point. I'll make a note that we should include recommendations for such things.

Steve

[Steve Cousins]

Alan

Some great points there for the spec. I'll copy and paste those for later reference.

The points about signal polarity have made me wonder if we should not label the pins on the backplane with polarity markers so as to keep it as generic as possible. Not sure. I suppose it depends if the processor creates Z80 style signals or if it is more native (and unable to use some Z80 style RCBus modules)

Steve

[Tadeusz Pycio]

Right, I was too hasty in my approach to the subject /M1. For the Zilog bus it is required, for the other architectures it must be pulled up, due to the existing decoders in the modules. Also I think that the /MREQ, /IORQ,/WR and /RD signals should remain common for all architectures, because they can be generated and are needed anyway. I think the same applies to the /RST, CLK, /BUSREQ, /BUSAK, /NMI, /INT signals. One might be tempted to use the RFSH signal in a different way, as I don't think it will ever be used. The problem is the incomplete knowledge of the needs of other architectures than the Z80 (we already know that for Motorola there must be added an E clock and an R/W signal), but it also appeared that an ALE signal would be useful for x51, 8085,.... to enable I/O modules using this.

[Steve Cousins]

Attached is a render of my first attempt at converting backplane SC113 to an RCBus flavoured backplane

[Alan Cox]

INT and IRQ are the same thing

FIR or FIRQ signals are not the same as NMI but are a 'fast'
interrupt. They really have no equivalent in Z80space.

The 680x processors push all the registers on an interrupt so the
interrupt is nice, easy to use and not as fast as it could be. FIR
doesn't and usually has higher priority - same thing on ARM roughly.
It's often used for stuff like faking floppy disk DMA.

[Alan Cox]

Not sure ALE has any uises. It's used by different processors for
different bits and numbers of bits, the signal has differing meanings
and it varies what lines are multiplexed. They can't agree if for
example you put out half the address on the address lines then the
other half, or you put half of it on the lines muxed with data. They
can't agree on timings. They also can't decide whether it's A8-A15 or
A16-A23 or some other combinations that are multiplexed. Some
processors even latch most address bits but then cycle low bits
without relatching the upper ones so they can burst transfer.

All the cards that use multiplexed bus peripherals already convert
from the Z80 style signalling (eg the DS12885 does it and the EF9345).
This is probably the best route for compatibility unless you are
building something very weird where you'd probably not be able to use
an RCbus cards anyway.

It's usually a single 74HCT573 to handle the demultiplexing on the CPU
card, so trivial enough.

[Steve Cousins]

Okay, I've updated the proposed pin-out:

Pin 22, RCBus backplane label INT, RCBus-Z80 = INT, RCBus-68xx = IRQ

Pin 66 , RCBus backplane label and usage remains NMI

Pin 37 , RCBus backplane label n37, RCBus-Z80 = INT1, RCBus-68xx = FIRQ

Is this the correct way to use the NMI pin?

[Tadeusz Pycio]

Hi Alan,

I think the proposal Mark to add an ALE signal was dictated by the possibility of using I/O chips like the 8155, 8256,... than the requirement for processor modules in which this signal can be used internally for appropriate latches.

[Steve Cousins]

I've got a release candidate of my SC113 like RCBus backplane. See attached render.

It uses Tadeusz's rather neat solution to creating direct or cascade (daisy-chained) signals using jumpers. All the common bus signals are labelled with their specified functions. All others are labelled nXX, where XX is the pin number. This looks rather cryptic but it avoids having them labelled for one processor or system type and thus being incorrect for a different type. This is particularly relevant to pins that can be configured as either direct or a daisy-chain. What do you guys think?

We could do with assigning pins for DMA etc. See previously posted document.

Steve

[Tadeusz Pycio]

The more I think about it, I come to the conclusion that cascade connections can probably be unambiguously named as they relate to a specific architecture, in other cases it will be a direct connection. Just how to label it on the backplane. Quite a puzzle. Maybe I'm worrying too much about it, I don't know.

My concern is that by the time we figure out where to put the missing signals, the physical hardware will have been created (fortunately the backplane will not be affected) :)

[Steve Cousins]

Perhaps we should make an announcement on the RC2014 group and see if we can get more input before it is too late

[Tadeusz Pycio]

Hi Steve,

I don't know if this makes sense, I tried to get feedback on the FB group, then instead of some ideas, I heard that we want to promote our crappy products under a common name because they don't meet RC2014 standards. Such a curiosity.
Maybe I should step away from supporting this standard and get on with something developmental...

[Steve Cousins]

It is hard to establish a consensus on things like this. A few years ago we tried and it didn't reach a conclusion.

I assume those who were negative on FB don't see the need for more advanced features or for other processors. Perhaps Spencer is right and this sort of system is for simple 8-bit computers without multi mode 2 devices, etc. Perhaps the vast majority of people out there are content with those limitations.

There only seems to be a small group of us contributing to this effort to move forward. I think we should just agree what we want and start using it.

It is tempting to say the RC2014 standard is too limited and move to something else. But it looks like there is more interest in simple systems and it is the people that make this an attractive hobby.

Lets see if we can reach a conclusion in the next few days.

Steve