Modular backplane specification

[Steve Cousins]

Hi all

Leading on from other recent topics, I've attached a discussion document about modular backplanes.

This is one of a number of things I've been talking with Tom Szolyga about and we feel it is time now to document the ideas and present them for discussion on this group. 

The backplanes are not entirely new. I have already presented the first generation to the group and have had some useful feedback which may be seen in the second generation prototypes.

I'm looking forward to your comments.

Steve

[Alan Cox]

Page 29 you have D13/D14/D16 but not D15.

Four comments I'd make
- Anything labelled 'user' and connected across the full bus length is
just asking for disaster. The odds of getting all cards compatible
with one definition of user declines dramatically as you add cards!
- Having D8-D15 is great if someone can explain how a memory card
handles 8bit v 16bit CPU. Do we just say 'you can't do that' ?
- 'Some signal functions change when used for processors other than
Z80', is IMHO not a good answer
- Clearly document what is pull up or pull down

The non Z80 boards need to generate the right bus signals (which is
what S100 does and isn't actually very hard), and if there are other
signals that are needed (eg function codes for Motorola stuff) they
ought to just get pins allocated.

The proper handling of IORQ & !M1 on all cards is needed for IM2 as well.

Actually an RC2014 way to solve it nicely might be to give pins to the
Motorola/Mostek style bus arbitration and have a standard bus
convertor card that generates the relevant Intel bus signals
accordingly ?

There's also a lack of recognition of the existing well established
retrocomputing standards

- ECB eurocard bus used by all the N8VEM and related (retrobrew)
hardware. There are more cards for that than RC2014 and it's long
established. See
https://retrobrewcomputers.org/doku.php?id=boards:ecb:ecbbusinfo

- S100 bus. Which plays in a different space but ought to get a
cursory mention (IEE 696) and also has a ton of retro activity with
everything from PDP-11 to Raspberry PI CPU cards !

More generally I think we need a line allocated for 3v3 even if a bus
isn't required to supply it (and for 3v3 someone can put a 3v3 shifter
on a card with a 'supply 3v3 to bus' jumper). Not so sure about 12v
and I guess -5 isn't really needed as nobody is going to be using
4116's.

If it's truely modular then the power supply can also be a plug in
card with voltages/currents sized to need (effectively that's what the
SIO2 is doing today)

[Mark T]

On SC107, for each module does IEI pin 38 connect to IEI pin 80 and IEO pin 39 connect to IEO pin 40, or are these two completely separate chains.

In a previous post you showed how links can be added to SC112 and SC113 to support the pin 38 and pin 39 IEI/IEO chain. If newer modules are designed using pin 40 and pin 80 how do these connect to the legacy modules using pin 38 and pin 39?

As I mentioned in the earlier thread, requirement for 80 pin modules to support IEI/IEO limits the pcb manufacture to single source JLCPCB due to cost increase above 100mm for other suppliers. Other suppliers are more cost effective if you want Blue pcbs instead Green provided you limit the module to 39 pins.

Any provision for other priority chains? (/BAI and /BAO) .

[Jon Langseth]

I see I have some background reading to do in threads in this group, so I'll hold off with comments (except those below) until I've done so. But as my Z50Bus spec is mentioned, I thought I'd just note that I'm here :)

Alan mentioned legacy bus types. I just wanted to mention that "the good thing about standards, is that there are so many to choose from". Like the STD80 and STD50 bus types. Yes, ECB and S-100 are widely used, but their connectors make them somewhat less than ideal for modern homebrew, in my opinion. That's why I designed the Z50Bus spec. A significant limitation of my design is that it's more-or-less hostile to 16- or 32-bit designs, and I thing Steve and Tom are on to something with their BP80. Unfortunately, it breaks the "magical 100mm barrier", one significant reason why I went for 50, not 80 pins.

[Alan Cox]

On Wed, 22 Aug 2018 at 18:33, Jon Langseth <jon.la...@gmail.com> wrote:
>
> I see I have some background reading to do in threads in this group, so I'll hold off with comments (except those below) until I've done so. But as my Z50Bus spec is mentioned, I thought I'd just note that I'm here :)
>
> Alan mentioned legacy bus types. I just wanted to mention that "the good thing about standards, is that there are so many to choose from". Like the STD80 and STD50 bus types. Yes, ECB and S-100 are widely used, but their connectors make them somewhat less than ideal for modern homebrew, in my opinion. That's why I designed the Z50Bus spec. A significant limitation of my design is that it's more-or-less hostile to 16- or 32-bit designs, and I thing Steve and Tom are on to something with their BP80. Unfortunately, it breaks the "magical 100mm barrier", one significant reason why I went for 50, not 80 pins.

There are lots of reasons for not using S-100 including its
complexity, the bus drivers and power supply logic.I've built ECB
stuff and the connectors are not hard to solder, and a good solid fit.

It's not really about what you want to use, but if you are going to do
a survey of existing retro backplanes missing out the two most used is
a bit misleading - and there is much to learn from them including what
not to do 8)

Alan

[Mark T]

https://xkcd.com/927/

[Steve Cousins]

I'll wait for more feedback before trying to address all the points raised.

However, I want to clarify that this document is not intended to be a survey of all retro backplanes or an evaluation of long established bus systems. 

The goal isn't to redesign the RC2014 or identify a bus system that is "better" so we can all move to it.

This is the RC2014 group and this project is about creating a more flexible backplane system. 

The designs described in the document are about building on existing RC2014 standards.

I've included the Z50Bus because it already has an adapter for RC2014 modules and I think can have adapters for the proposed backplane system.

I hope that helps clarify what I think this is all about. 

Of course if you want to start a broader discussion on backplanes, that's fine too.

Steve

[Eric Matecki]

I'm happy to see the spacing of slots across section is now a multiple of the intra-section spacing.

Even if there is still some todo :)

It will make the design of a case much easier.

And about the case....

Any intent to standardize how the connectors at the back (whichever side that is) of the modules should be fitted ?

Especially DB style connectors (serial, joysticks, centronics...)

I'm thinking at least the dimension from the back of the module to the 'back' 'plane' of the connector should be standardized,

this way they will be easy to attach to the backside of the case, all nicely aligned in the same plane.

Not sure what I say is clear :)

[Conrad Larsen]

Hi Steve

That clears up a lot. Good post!

Conrad

[lon...@engr.sc.edu]

Hi Steve,

Just a thought, but the ECB boards are 100mmx160mm, so similar in width to the RC2014 cards.  John Coffman designed an ECB backplane to fit in the Siemen's Simatic 505-6508 chassis that can be found surplus on eBay.  The 505-6516 is similar, but is longer and supports more slots.  They are also easier to find and less expensive, as they appear to be less popular.  It might be a suitable chassis for a version of the RC2014 backplane.  I'm including a link to John's ECB design, which includes pictures of the chassis and backplane.

https://www.retrobrewcomputers.org/doku.php?id=boards:ecb:backplane-505-6508:start

Dave London

[Jon Langseth]

I see two challenges with this. The first is that, because the ECB connector is not 100mm wide, there's clearance to use the support rails of the chassis. the BP80-like RC2014-compatible bus extensions/versions use the full with of the card for the connector, so the rails may well be getting "in the way". The second challenge is realted to ECB cards having their external interface connectors on the edge opposite the ECB connector, whereas RC2014-like cards have (with ongoing questions) landed on having their external connections on the "short" edge, away from the angle-cut side (as seen relative to the official template).

I'll take this opportunity to respond to Alan's reply to me regarding the ECB. I agree that it's not difficult to build an ECB based system, and it is a nice bus type. But compared to the straight-forwardness of the original RC2014 bus, it's harder to "grasp" for a novice. Combine that (relatively small) element, with the pricing of the required connectors, I found that I preferred the RC2014-style when I was evaluating options. I did whoever not like that the original bus lacked significant signals (I started before the extended bus was a thing), and when I started tweaking, I realized I preferred a shorter dual-row connector. Thus the Z50Bus was born. Regarding my statement of price: in Norway, where I am located, a pair of DIN 41612 connectors costs me as much as the entire 5-slot Z50Bus backplane with connectors does in my Tindie shop.

I think that to stay on topic, we should see this discussion in the light that Mark, Steve and Tom started their discussion: trying to establish an agreed-upon wide version of the RC2014 bus, compatible with the original.

--
You received this message because you are subscribed to a topic in the Google Groups "RC2014-Z80" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rc2014-z80/XvdyuOd62v8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rc2014-z80+...@googlegroups.com.
To post to this group, send email to rc201...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/5215bb11-7356-4213-bbb4-95190de857ac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

regards, Jon Langseth

[Steve Cousins]

Hi Alan

See below

On Wednesday, 22 August 2018 16:05:10 UTC+1, Alan Cox wrote:

Page 29 you have D13/D14/D16 but not D15.

Thanks, noted to be fixed.

 

Four comments I'd make
- Anything labelled 'user' and connected across the full bus length is
just asking for disaster. The odds of getting all cards compatible
with one definition of user declines dramatically as you add cards!

I agree, but this is part of the RC2014 spec which the modular backplane must support. However, section SC113 has solder pad links to allow some of the USER pins to be connected between sections only if required. Also SC112 and 113 have jumpers between sockets to link or isolate some of these signals. This however gets complex to manage if, as you say, you have incompatible modules. The allocation of USER pins in the RC2014 spec appears great at first, but there will be inevitable clashes.

 

- Having D8-D15 is great if someone can explain how a memory card
handles 8bit v 16bit CPU. Do we just say 'you can't do that' ?

I don't have an answer to that, but as it is part of the existing RC2014 spec, the modular backplanes must carry these signals.

 

- 'Some signal functions change when used for processors other than
Z80', is IMHO not a good answer

You are right. I was being lazy.

 

- Clearly document what is pull up or pull down

Good point. I've noted this for inclusion. I guess a proper spec for a backplane would also include signal levels, timing, etc.

 

The non Z80 boards need to generate the right bus signals (which is
what S100 does and isn't actually very hard), and if there are other
signals that are needed (eg function codes for Motorola stuff) they
ought to just get pins allocated.

Noted

 

The proper handling of IORQ & !M1 on all cards is needed for IM2 as well.

True. Same for existing RC2014 backplanes.

 

Actually an RC2014 way to solve it nicely might be to give pins to the
Motorola/Mostek style bus arbitration and have a standard bus
convertor card that generates the relevant Intel bus signals
accordingly ?

There's also a lack of recognition of the existing well established
retrocomputing standards

I don't think this is relevant to designing a modular version of the RC2014 backplane.

 

- ECB eurocard bus used by all the N8VEM and related (retrobrew)
hardware. There are more cards for that than RC2014 and it's long
established. See
https://retrobrewcomputers.org/doku.php?id=boards:ecb:ecbbusinfo

- S100 bus. Which plays in a different space but ought to get a
cursory mention (IEE 696) and also has a ton of retro activity with
everything from PDP-11 to Raspberry PI CPU cards !

Again, I don't think this is relevant to designing a modular version of the RC2014 backplane.

 

More generally I think we need a line allocated for 3v3 even if a bus
isn't required to supply it (and for 3v3 someone can put a 3v3 shifter
on a card with a 'supply 3v3 to bus' jumper). Not so sure about 12v
and I guess -5 isn't really needed as nobody is going to be using
4116's.

On modules with RC2014 card sockets, this would need to be compatible with the RC2014 spec. Spencer has recently suggested uses for the pin not allocated on the enhanced bus. That only leaves assigning a USER pin, which as you have already pointed out will lead to clashes. The debate about allocation of RC2014 pins is central to the whole RC2014 universe, not just modular backplanes. That debate needs to be had asap I think.

 

If it's truely modular then the power supply can also be a plug in
card with voltages/currents sized to need (effectively that's what the
SIO2 is doing today)

True. There is nothing in the spec on RC2014 or the proposed modular backplane system to prevent this. It is a perfectly valid option.

 

Steve

[Steve Cousins]

Hi Mark

See below.

On Wednesday, 22 August 2018 16:21:05 UTC+1, Mark T wrote:

On SC107, for each module does IEI pin 38 connect to IEI pin 80 and IEO pin 39 connect to IEO pin 40, or are these two completely separate chains.

SC107 has each socket 's pins 38 & 39 are individually connected to that socket's pins 40 & 80. This backplane section should therefore be able to support a mixture of 39/78 pin modules and any of the proposed 40/80 pin modules.

 

In a previous post you showed how links can be added to SC112 and SC113 to support the pin 38 and pin 39 IEI/IEO chain. If newer modules are designed using pin 40 and pin 80 how do these connect to the legacy modules using pin 38 and pin 39?

That's a good point, they don't. The current design of these two backplane sections do not support a mixture on existing modules and proposed 40/80 pin modules. Other designs, as SC107, could do.

 

As I mentioned in the earlier thread, requirement for 80 pin modules to support IEI/IEO limits the pcb manufacture to single source JLCPCB due to cost increase above 100mm for other suppliers. Other suppliers are more cost effective if you want Blue pcbs instead Green provided you limit the module to 39 pins.

Fair point.

 

Any provision for other priority chains? (/BAI and /BAO) .

Nothing planned.

 Steve

[Steve Cousins]

Hi Eric

I'm not planning to propose a standard for how the connectors at the back of the modules should be fitted.

Perhaps someone would like to have a go at that.

Steve

[Steve Cousins]

Thanks Dave, interesting link.

I haven't even thought about cases for my RC2014 systems. 

Steve

[Steve Cousins]

Thanks Jon

Yes, we need to focus on a manageable project. A modular backplane for RC2014, and other similar systems, is not a big step. It should be possible to agree a standard.

I too like shorter connectors. For one thing, they make it much easier to remove modules from the backplane. They allow you to get your finger tips under each end of the board and ease it out. Trying to extract event a 39 pin RC2014 module can be difficult, and with the full 80 pins it can be painful.

Steve

On Thursday, 23 August 2018 18:15:37 UTC+1, Jon Langseth wrote:

I see two challenges with this. The first is that, because the ECB connector is not 100mm wide, there's clearance to use the support rails of the chassis. the BP80-like RC2014-compatible bus extensions/versions use the full with of the card for the connector, so the rails may well be getting "in the way". The second challenge is realted to ECB cards having their external interface connectors on the edge opposite the ECB connector, whereas RC2014-like cards have (with ongoing questions) landed on having their external connections on the "short" edge, away from the angle-cut side (as seen relative to the official template).

I'll take this opportunity to respond to Alan's reply to me regarding the ECB. I agree that it's not difficult to build an ECB based system, and it is a nice bus type. But compared to the straight-forwardness of the original RC2014 bus, it's harder to "grasp" for a novice. Combine that (relatively small) element, with the pricing of the required connectors, I found that I preferred the RC2014-style when I was evaluating options. I did whoever not like that the original bus lacked significant signals (I started before the extended bus was a thing), and when I started tweaking, I realized I preferred a shorter dual-row connector. Thus the Z50Bus was born. Regarding my statement of price: in Norway, where I am located, a pair of DIN 41612 connectors costs me as much as the entire 5-slot Z50Bus backplane with connectors does in my Tindie shop.

I think that to stay on topic, we should see this discussion in the light that Mark, Steve and Tom started their discussion: trying to establish an agreed-upon wide version of the RC2014 bus, compatible with the original.

On Thu, Aug 23, 2018 at 5:24 PM <lon...@engr.sc.edu> wrote:

Hi Steve,

Just a thought, but the ECB boards are 100mmx160mm, so similar in width to the RC2014 cards.  John Coffman designed an ECB backplane to fit in the Siemen's Simatic 505-6508 chassis that can be found surplus on eBay.  The 505-6516 is similar, but is longer and supports more slots.  They are also easier to find and less expensive, as they appear to be less popular.  It might be a suitable chassis for a version of the RC2014 backplane.  I'm including a link to John's ECB design, which includes pictures of the chassis and backplane.

https://www.retrobrewcomputers.org/doku.php?id=boards:ecb:backplane-505-6508:start

Dave London

--
You received this message because you are subscribed to a topic in the Google Groups "RC2014-Z80" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rc2014-z80/XvdyuOd62v8/unsubscribe.

To unsubscribe from this group and all its topics, send an email to rc2014-z80+unsubscribe@googlegroups.com.

To post to this group, send email to rc201...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/5215bb11-7356-4213-bbb4-95190de857ac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

regards, Jon Langseth

[brwella...@gmail.com]

Hi Steve,

We have read your draft specification with interest and once again we must thank you for all your efforts in the generation of useful documentation on various aspects of the RC2014 system,

After being in the Project Management field for more years then I would care to remember I recall a little, now rather old cartoon about the design of a swing to be installed on the branch of a tree, but still relevant where the message was that we should remember what the actual objective of the discussed topic is.

Here we are proposing a means of providing a modular system which will enable the user to expand an existing RC2014 type backplane by means of the addition of additional modular slot sections but at the same time enable or retain the full functionary of all the existing modules which may or could at a later date be installed.

Various proposals have been put forward for comment and discussion and I take this opportunity to add my own input for consideration which I trust will prove helpful in your future development of a final acceptable specification which the majority of potential users will find useful.

The following comments are collated by reference to the existing draft specification pge numbering.

Title page: Since we are making a proposed specification relevant to the RC2014 system it might be prudent to include “RC2014” in the title.

This should help to eliminate some of the apparent confusion where we see references to potential use of alternate bus systems such as ECB, S100 and the like. Whilst most of these alternative bus systems have their individual merits their use here without the use of adapters or similar would cause the majority of the existing RC2014 modules to become incompatible.

Overview: It is noted that the term “card” is used with the term “module” a bit like an afterthought. Why not just call “cards” modules which is what they have been called since conception of the RC2014 system.

Card (Page 4); Same comment as above.

USER pins (Page 5: To eliminate any possible confusion concerning their use why not just delete this name and leave the silkscreen bare against these pins.

Sections (Page 8): The table contains many terms which imply that you already know what they mean etc.

Basically we have two types of backplane sections which we could IMHO define as MASTER and SLAVE.

The MASTER being a section which includes the power input circuitry and associated components like a reset and a set of module slots.

A SLAVE being a section capable of coupling to the MASTER or another SLAVE to add additional module slots.

The actual choice of how you join these sections together can be either use of straight or angled BP80 type connectors which you could then be shown as typical illustrations.

It is appreciated that you have used some actual examples to illustrate some typical applications and should be retained once the above base terminology has been defined. The reference to the LINC Z50Bus and the associated SC109 adapter should be omitted as not being strictly relevant here.

Bus: BP80 (Page 23-24): Pins 49 to 56 inclusive should ideally be defined as “Not assigned” thus making them available for future use. Pins 37 to 39 and pins 77 to 79 should similarly be defined as “Not assigned” as per my earlier comments above.

Page 25: TODO – Are these not already defined on page 24? The plug/socket illustration and associated text is a little confusing. Why not just make two views, one for a plug showing top and bottom pin references and another for the socket similarly showing top and bottom pin references.

Pages 26 to 29 inclusive: These are existing standards so why detail them here. A simple web link to the official RC2014 site is all that is required to clearly detail this information.

Page 30-31: Modify as per my previous comments

Page 32: Delete as not relevant here.

Cards (Pages 33 onwards): Similar comments as above concerning use of “card” as opposed to “module”.

Page 37: Delete as not relevant here.

Kindly note that all the above are only my own comments and suggestions and are not intended to imply any criticisms or to exclude the use of any other peoples suggestions or opinions.

The Cartoon

[Marten Feldtmann]

Am Freitag, 24. August 2018 23:05:26 UTC+2 schrieb Steve Cousins:

More generally I think we need a line allocated for 3v3 even if a bus
isn't required to supply it (and for 3v3 someone can put a 3v3 shifter
on a card with a 'supply 3v3 to bus' jumper). Not so sure about 12v
and I guess -5 isn't really needed as nobody is going to be using
4116's.

On modules with RC2014 card sockets, this would need to be compatible with the RC2014 spec. Spencer has recently suggested uses for the pin not allocated on the enhanced bus. That only leaves assigning a USER pin, which as you have already pointed out will lead to clashes. The debate about allocation of RC2014 pins is central to the whole RC2014 universe, not just modular backplanes. That debate needs to be had asap I think.

 

 

Two other signals candidate for  the expanded backplane: /INT1 and /INT2 (available at Z180, Z380 and ez80) and /CS0, /CS1, /CS2, /CS3 for an ez80 system :-)

[Alan Cox]

The reason I care about other busses is to learn from them.

 Eg ECB simply doesn't allow upper 8bits of a 16bit wide card to be accessed from an 8bit CPU. S100 does but this adds a layer of complex logic to RAM cards most of which omitted it anyway.

That tells me a lot about how RC2014 should handle D8-D15 !

Alan

[Steve Cousins]

Hi Alan

Thanks for the explanation.

You raise a fair point and I see where you are coming from.

However, I think that is an issue for the RC2014 bus specification.

This project is about providing a modular version of the RC2014 backplane, and must meet the specification of the RC2014 bus. Thus regardless of the validity of the RC2014 specification's of D8 to D15, I feel the modular backplane must do the same.

Perhaps what we need here is to split this discussion into two parts:

• Discuss with Spencer the current specification of the RC2014 bus and perhaps make changes where appropriate. This should be done before Spencer finalises the specification for the currently unassigned pins.
• Modular backplane specification, which must provide compatibility with the RC2014 bus. This document should focus on modularity rather than trying to influence the RC2014 bus itself.

Steve

[Steve Cousins]

Wow, thanks. Quite a bit to digest there.

Great cartoon.

Steve

[Marten Feldtmann]

On the other way - the RC2014 is very simple and this is an advantage ... I've never thought about creating a module before, now I am working on two modules - hoping to get it finished some day in the future. I've started easyeda and actually created PCBs and got them back from China to view the errors I made. Wonderful experience (though :-() I've viewed all the other projects (e.g. ECB oriented) but never thought about the idea to make my own card. I looked at the simple Z80 CPU card of the RC2014 system  and it seemed, that I understood this simple module etc. That was the initial "Ha"-event for me.

I do not want to care about how an 8 bit cpu is accessing 16 bit memory. I - for myself - am thinking in a Z80/Z180/ez80 oriented world and I live in an eight-bit world with the RC2014. Perhaps over the time my knowledge may increase and I will try out ICs with multiplexed pins, perhaps some day I try out SMD stuff for the ez80 system - but not now. Today I live in the through-hole technology, seeing the need for 3.3v on the bus to make it easier for me to access ICs with 3.3v only.

So for me: the experienced user should add 3.3v, solve the IEO/IEI problem, solve the SPI and/or I2C problem, put address lines up to A23 to the bus, more INT-lines and some more user lines - but please: keep the whole system simple for the beginners. Then the bus will be a good bus for a Z80 oriented system - but perhaps not that good one for other systems.

[Jon Langseth]

Den lør. 25. aug. 2018, 14.13 skrev Marten Feldtmann <m.fel...@dimap.de>:

Today I live in the through-hole technology, seeing the need for 3.3v on the bus to make it easier for me to access ICs with 3.3v only.

I really do not see anything good coming from adding a 3v3 supply line to the bus. On the other hand I see potential issues with novice builders failing to properly understand level conversion. If a module or expansion needs 3v3, it is my opinion that it should be handled by a voltage regulator on the module in question. An LDO regulator does not add much complexity nor cost to the project.

This is a spot where the S100 bus gives a good lesson: each card was required to have on-board voltage regulators. What we also can learn from S100 in this case, having too many different supplies (8,+12, -12) required on the bus is something we have moved away from.

With buck/boost and LDO converters, we can create any voltage we need on the modules, from a single-end ed 5v supply is my opinion :)

[Mark T]

I agree with Jon, I think additional voltages should be provided by regulators on the individual cards.

Maybe SPI/I2C should be via an interface card with the SPI/I2C expanded via a separate bus as I don't think those devices would need access to the Address/Data/Control signals of the RC2014 bus. There may also be some use for a bus section module that could connect to the end of one of the modular bus sections that would contain the SPI/I2C interface and regulators but with reduced pin count module connectors suitable for SPI/I2C devices.

I don't think it makes sense to handle 16 bit memory from the 8 bit processors. To support experiments with with 16 bit processors then perhaps have a bus section where memory cards could provide either high or low 8 bits without redesign of the memory card. Alternate method could be to connect to both low and high bytes of the bus connector, then depopulate the pins for the connector.

Mark

[Alan Cox]

On SPI and I2C I agree. They just need a simple backplane with a few lines and voltages. There are existing simple cheap ones. Also for slow use cases you'd wire it to an existing rc2014 pio adapter and bitbang it.

Alan

[Bill Shen]

Perhaps it would be instructive to examine a 16-bit processor design for RC2014.  I've not seen one being proposed, perhaps there are some design activities going on under the radar.

I myself have designed three 16-bit uP for RC2014 (Z280RC, T68KRC, ZZ280RC all are documented elsewhere in RC2014 forum) and I can describe some of my design decisions:  Z280RC is based on Z280 which configure to a 16-bit wide data bus.  It also has a 16-megabyte physical memory space managed by on-chip MMU and DMA.   There are no existing RC2014 RAM or ROM modules for the extended address space so instead of designing a new set of RAM & ROM modules, I chose to utilize the large memory space with a low-cost 2-megabyte dynamic RAM and put it on the CPU board.  The address multiplexing and DRAM controller logic are easily handled with a modest CPLD.  The big issue is interfacing with existing Z80 peripherals (SIO2, CTC, PIO) because these peripherals all watch the 8-bit data bus for RETI instruction sequence which is incompatible with 16-bit data bus of Z280.  So Z280 in 16-bit data bus mode can only access the Z80 peripherals in Mode 1

In the case of ZZ80RC, it is configured to the 8-bit Z80 compatible data bus mode.  It certainly can use the existing RC2014 RAM & ROM modules, but it has on chip MMU and DMA that can access 24-bit address space directly, so using the existing RC2014 RAM & ROM modules is a step back.  I choose to keep the 512K RAM on the CPU board and connect all 19 addresses directly from Z280 to RAM and let the on-chip MMU & DMA do their magic.  ZZ80RC can use the existing Z80 peripherals in Mode 2.

In the case of T68KRC, it is based on a Motorola 68000 processor with 16-bit wide data bus and 23-bit address bus.  Because there are no existing RC2014 memory modules, I also choose to put 2-meg of dynamic RAM on the CPU board.  The I/O interface for 68000 is more troublesome because not only does it need to translate 68000 bus signals to M1/IORQ/RD/WR, it also needs to change the memory map of existing I/O modules.  This is because  D7..D0 is accessible only on the odd address memory space of 68000 so instead of having a I/O address map of 0x0 to 0x7F, the I/O are accessible on addresses 0x1, 0x3, 0x5 so on to 0x1F.  In addition, the Z80 peripherals can only interrupt in Mode 1.

All three modules only use the I/O portion of RC2014 bus (8-bit addresses, 8-bit data, and controls), so the upper 8 address bits of RC2014 bus can be reused for something else.

A new module with 16-bit wide memory and 24-bit addressing can certainly be designed, but it needs to match up with the intended 16-bit processor.  It is also unclear to me whether there are enough room in the standard 50mmx100mm RC2014 form factor to handle the double amount of RAM/ROM and the additional decoding circuitry in through-hole technology.  In addition, compatibility with existing Z80 peripheral is in doubt.  So the designer of a 16-bit processor system may face the possibility of starting all over with new set of modules. 

  Bill

[Spencer Owen]

I've been keeping quiet in this thread so far, as I try to do with most threads discussing somebodys new module, design or whatever.  It seems somehow inappropriate for me to advise people what they should or shouldn't do with the thing they are designing, and unless I see something that could cause issues down the road, I try to keep out of things. At least publicly anyway :)

Just to give a bit of history of the RC2014 for those that don't know, it was originally created as a personal hobby project to build my own very simple Z80 based computer running BASIC.  Whilst the modular format of it has proved to be one of the key aspects to it's success, the original motivation was due to my own insecurities about PCB design, and the fact that a design error would only need a single module to be redesigned instead of spinning another whole single board computer.  I looked around at other modular computers and busses like the S100 or VME etc, but the complexity and cost of connectors almost stopped my project dead.  That is until I looked at what signals was really needed on the bus, and what other cheaper connectors were available.  I could get away with just 34 signals, and use single row 0.1" header pins, meaning that Veroboard (stripboard) could be used for the backplane, so the entire backplane and all connectors came in cheaper than a single DIN41612 connector!

The original RC2014 bus was very simple, and although it missed a few key signals needed for more complex machines, it worked just fine.  In fact, my "daily driver" RC2014 runs on a Backplane 8, as that has everything it needs.

When I was looking at making a CP/M variant of the RC2014, and also add things like dual speed clock and dual serial ports, the extra signals were added to support this, as well as some of the missing control lines and some expansion that would take it up to 16 bits.  So, the Enhanced Bus, as found on the Backplane Pro, was developed.  Again, this is a very simple bus, although it does lose the ability to get away with just using stripboard.  [Spoiler: This bus will happily run a 68000, using the standard Pageable ROM, standard 64k RAM for the lower byte and a new combined ROM/RAM board for the upper byte memory]

The key to all of my decisions, wherever possible, has been to keep things simple. I think this has been fundamental to the success of the RC2014, and for a lot of people it has been the reason that they decided to build one.  I have spoken to a lot of people at various Maker Faires and other such events, and pointed out that this is a computer that you can assemble yourself and really understand how it works - and the reaction is always one of "wow, even me?".  Yes, YOU!  I don't want to discourage use of things like the Raspberry Pi, or Arduino, as they are absolutely fantastic devices, and they are so powerful - but when it really comes down to it, a mere human cannot really know what is going on under the hood.  When is there a memory write going on? What data is being put on which I/O port?  For something like the RC2014, the simplicity means you can hook up a scope or logic analyser and see *exactly* what is going on.

I know that the Z80 is capable of so much more than just running BASIC, and there are all kinds of exciting peripherals that it can interface to, and with the right software, it can become the heart of a really powerful system.  And moving on from the Z80, there are much quicker, more powerful, more feature laden processors that can make things even better still.  And for those of you that want to go in that direction, I take my hat off to you.  But, the RC2014 is, and always should be, a simple computer that can be built and understood by anyone.  Some people like to build their RC2014, use it once, and put it in a draw, smug in the knowledge that they built their own computer.  Others get a kick out of the software, be it learning an ancient language like assembly code, or the challenge of getting modern languages to run on old hardware.  For a lot of you, it is about using the RC2014 as a building block for developing your own hardware, whether it's with traditional 80's components or integrating modern cutting edge tech.  The fact that there are over 100+ modules that have been "designed for RC2014" I think says a lot about the flexibility of the platform.

For me, the spirit of RC2014 is simplicity.  It isn't about sheer processing power (I've got a smart watch which is way more powerful), and it isn't about making the most complex thing possible.  I love the fact that some of you are pushing the boundaries of what's possible, and I love that some of you spot what's missing from the RC2014 modules available, and go ahead and fill that gap.  And, whilst I don't think that Steves modular backplane is something that I personally need, I love the fact that Steve is making it and sharing it with everyone.

Spencer

On 22 August 2018 at 14:58, Steve Cousins <steve...@gmail.com> wrote:

Hi all

Leading on from other recent topics, I've attached a discussion document about modular backplanes.

This is one of a number of things I've been talking with Tom Szolyga about and we feel it is time now to document the ideas and present them for discussion on this group. 

The backplanes are not entirely new. I have already presented the first generation to the group and have had some useful feedback which may be seen in the second generation prototypes.

I'm looking forward to your comments.

Steve

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

To post to this group, send email to rc201...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/85d6b86b-8236-47f0-be0a-c72ba6424b3d%40googlegroups.com.

[Steve Cousins]

Hi all

It appears all the feedback is in, so I've updated the specification.

I've tried to incorporate your comments where I feel they are appropriate. 

I don't want to dedicate huge amounts of time to this project, so I have compromised.

I can see I tried to write a very generic document instead of a tightly focused one. I hope I have corrected that now, with the revised document being specific to RC2014 Z80 systems. Use with other processors and other bus types has been left out as it is just causing complication and confusion.

If anyone makes any compatible backplane sections and want them included as example implementations, please let me know.

I would like to bring this project to some form of conclusion now, but I also want it to be useful to others and hopefully adopted as some form of standard by this group. Therefore if you have any comments I would appreciate receiving them sooner rather than later.

Steve

[Steve Cousins]

Attached is an illustration of the current modular backplane options kindly contributed by Karl (karlab).

Also below is Karl's description of motherboards and backplanes, which you might find useful.

I think you should make the distinction between motherboard and backplane.

In a typical computer, the hardware consists of a central electronic/logic board, also called motherboard which has control logic (I/O controller) and maybe a CPU and other necessary components of a computer. A motherboard may have several connections or slots for connecting additional electronic boards, adding extra functionality to the computer e.g. video, sound, network. The data signals to the slots are under control of the I/O controller and CPU, and the slots may carry an extensive or limited number of data lines depending on intended use. 

Examples of a Motherboards: Linc1, SBC1, RC2014 mini

In a typical retro computer like RC2104, the central electronic board is the backplane. The function of the backplane is to distribute signals passively to all data lines of the bus to all connectors/slots. The modules connect to the necessary data lines for its operation. Individual modules may be designed to take control of the data lines in a backplane system (using interrupt signals), e.g., the CPU module, z80ctrl. One exception may be the reset signal, which may be controlled by the backplane. You should in theory be able to put any compatible card in any slot of the backplane and it should work.

Examples of Backplanes: RC2014 backplanes, S. Cousins modular backplanes

You may find the main boards which can be defined as something in between, but that’s another discussion.

[Steve Cousins]

Probably would have been helpful if I'd actually attached the document. D'oh.

So here it is!

[Mark T]

Hi Steve,

Maybe include a link to your website for any updates to the document and also to make it easy to find the schematics for the various sections of backplane.

Comparison of the wiring of tx/rx and user pins between the various backplanes would be a nice reference.

Mark

[Steve Cousins]

Hi Mark

Thanks for the suggestions. I've started a feature table (see below) and will add website details.

Steve

[ZO...@gladucalled.com]

Would like to see pin 40 uncommitted.  I am using pin 40 for random purposes (i.e 3V3 or INTACK).  

Personally, I haven't had a need for dual connectors.  The Tx, Rx, U1-2-3-4, and pin #40 are pretty much up for grabs and I use them.  At least two pins are needed for inter-board coordination (in HW) which seemed to be the only thing lacking in the 39 pin configuration.  So I am using User3 / User4 for IEI / IEO.

I have seen alternate processor proposals and mega-memory expansions that require many more pins.  This seems out of scope for a Retro Challenge Z80 system, no?  

But I certainly undertstand wanting to take off to high altitudes. So, there is a need to expand.  My only request is to keep the original bus 30 pin bus adding the HW daisy pin wiring and leaving pin 40 uncommitted.  That way we can we can still plug in all the old faithful cards into the new buses. I do not know of any conflicts with any of the existing boards which have preceded where we are now..

Anyway, that's my two cents.

=SteveM

 

[ZORAk]

Here is what I have done with the Standard 39 pins. This is not as mangled as it first may look.

The Daisy wiring has been used on the first four connectors.

Pin 40, which is undefined in the spec, is used for two purposes (iACK and 3V3).

Pri#2 is otherwise complaint, and actually uses Tx and Rx (which haven't seen elsewhere).

Pri#3 leverages all seven free pins.  This is for a specialized card using DMA.  But it fits in 40 pins.  A case may be made for dual connectors here, but I do not expect many users to jump on-board the DMA bandwagon.

Opt #5 sneaks NMI in where IEO is not needed.  This was for S&G's.

The last two (right most) connectors leave the last 7 pins unassigned.

J8 is a pin header which can be wired at will.  Maybe all buses should use something like this.

Cards which do not use these seven pins can be used in any of these slots.

Comments are welcome.

[ZO...@gladucalled.com]

Hi Steve,

On SC107, 38 connects to pin 39 in the next slot with SC107, right?

And it looks like SC112 and SC113 can be strapped to daisy chained 38 to 39, yes?

I have been out-of-pocket for many weeks.  I think I am slowly coming onboard with this.

I would still like to see pin 40 uncommitted.  It gives flexibility to 40 pin card designs.  

Can you move IEI and IEO to the 41-80 pin connector for those cards?

Maybe you could include straps for pin 40 in the jumper headers. 

I am sorry to be a bother (a Johny-Come-Lately).

Great work, btw.

=SteveM

[Steve Cousins]

Hi SteveM

I think your application is rather unusual. You have a number of RC2014 sockets on your motherboard, but you don't use the USER pins the same on all sockets. In some cases you run the signals in parallel to the next socket, but in others you cross link two pins for an interrupt daisy chain. No general purpose backplane will cater for that. You have created a custom backplane in the form of your own motherboard to provide this unique functionality.

If you were to implement your system using the modular backplane, you would have to do the same as you have now. You would design a custom backplane section to provide the unique features you require. If it conforms to the modular backplane specification, you can pretty much do what you want with the module sockets and still be able to join other backplane sections.

In a way pin 40 is uncommitted in the sense that you can simply not connect that pin from the backplane section input and/or output connectors to the module sockets on a custom backplane section. That way it does not matter what other backplane sections do with the signal on pin 40. The only catch I can think of is if you have more than 2 sections and your custom module is in the middle it might break the interrupt daisy chain, depending on the wiring of your custom section. I doubt that is a significant issue.

I think it is worth noting that there are very few modules which are more than 39 pins long, which is why I used the 40/80 pair for the interrupt daisy chain.

It is also important to consider that the ultimate RC2014 bus is likely to use the full 80 pin connector format (2 rows of 40 pins). At some point I think Spencer will allocate the extra pins, so it would be dangerous for any of us to do much with them. We should only use the pins allocated to us (the USER pins).

As it is expected that all 80 pins will ultimately be allocated by Spencer, and the modular backplane will need to support them all, the backplane section input and output pin outs are essentially chosen for us. So again this is part of the logic of using USER pins for the daisy chain, with the 40/80 pair being the least used and thus the least disruptive.

As for the huge memory map issue. I too feel there is a sensible limit for such a simple bus. I think anyone wanting a huge memory should put the memory on the same module as the processor, as Bill Shen has done with his Z280RC.

SteveC

[Steve Cousins]

Hi again Steve

See below for answers

SteveC

On Tuesday, 11 September 2018 17:10:05 UTC+1, ZO...@gladucalled.com wrote:

Hi Steve,

On SC107, 38 connects to pin 39 in the next slot with SC107, right?

Yes indeed. Each module socket connects 38 and 39 to 80 and 40 respectively, so both current module style 38/39 chains and proposed new module style 80/40 chains can be mixed on the same backplane section.

 

And it looks like SC112 and SC113 can be strapped to daisy chained 38 to 39, yes?

Yes, a short dupont cable would do. Alternatively a link soldered under the board for a more permanent and tidier connection.

 

I have been out-of-pocket for many weeks.  I think I am slowly coming onboard with this.

I would still like to see pin 40 uncommitted.  It gives flexibility to 40 pin card designs.  

As you are only using single row module connectors, you could solder blob pin 40 to 80 on the backplane to convert it to a simple track between all module sockets.

 

Can you move IEI and IEO to the 41-80 pin connector for those cards?

Maybe you could include straps for pin 40 in the jumper headers. 

As earlier post, I don't want to mess with the unallocated pins, as that may break compatibility when they get officially assignments.

Also I'm reluctant to add more jumpers. Jumpers are useful but also more things to go wrong.

[Mark T]

It might be possible to treat the user pin area of the backplane as a prototype area. There is just enough space between bus connectors on 0.6 inch pitch for two double row headers, which could be linked to bus connections between modules or used for random wiring.

Mounting holes would be further from the pcb edge and wiring up to bus the connections would be a pain, but it would allow almost any use of user pins.

[Steve Cousins]

Hi Mark

Yes, that allows every option with USER and TX/RX pins. Nice.

I have just today been playing with the SC112 & 113 backplane sections. These sections have some jumper headers between the module sockets. I dug out an old module with a single row connector and was shocked to find the profile of the single row connector means the circuit board sits lower and hits the header pins, so the module does not sit quite as low as it should. No problem with the dual row connector profile.

With your suggested design, if you want to fit a dupont style cable to the header pins immediately next to the socket, the PCB will block it. The double row jumper header on my backplane sections are far enough away, so no problem with those. Well that's not quite true. Those pesky single row profiles strike again. The PCB is further over and blocks the header. 

So more reasons to use the double row header on all modules, even if all the pins in the second row have to be removed.

This business of USER pins is a right nuisance. There doesn't seem to be a tidy way to cover all applications. To provide enough flexibility the backplane ends up being complex, with more soldering and numerous jumpers. Simple backplanes will ultimately lead to clashes between modules.

Perhaps we should just have headers on the modules for all 'user' functions and link them with wires to where ever they are needed! Messy, but flexible. That approach would sort out the whole interrupt daisy chain problem and mean the modules would not need to in a specific order on the backplane. I think it was Alan who said recently that one of the big name CP/M system suppliers handled IEI/IEO that way.

I did allow for connecting IEI/IEO with flying leads on my SIO, PIO and CTC modules, but am still hoping we can adopt a common solution via the backplane.

Steve

[Mark T]

Hi Steve,

There are two styles of single row right angled header. I've always preferred the style where the right angle is between the plastic carrier and the pcb, similar to the double row right angled header. This keeps the height of the module the same as those using double row headers, also the pins into the female header seem to be more stable and less likely to bend out of alingment.

For example samtec TSW-140-08-T-S-RA

I hadn't considered the standard RC2014 single row right angled header blocking the adjacent connector.

Mark

[ZO...@gladucalled.com]

Good catch, SteveC!

Random notes follow.

o  On the ZMS  motherboard, I used 0.8" spacing for some interconnector gaps.  I remember someone saying that they wanted fo fit an eprom ZIF socket onto their card and they didn't have room between the cards.  

o  Maybe we could have a few wider gaps among some slots.  A larger gap could accommodate the sandbox Mark T suggested.

o  I do not know if it is too late, but could we number the 1-40 pins along the back row instead of the front?

o  One more radical idea.  We could populate our backplanes with 1x40 or 2x40 connectors as needed.

o  I Reconciled myself to the new bus specs.  My DMA board will be dual row.  That fixes a lot of nits.  I will post the ZORAk bus soon.

Cheers, =SteveM

[Mark T]

Hi SteveM,

One in every six slots has a 1.2 inch gap.

(Also one slot on every bus has infinite gap :) ).

Its also easier to swap eproms if the first slot contains the module with the eprom.

Mark

[ZO...@gladucalled.com]

Perfect.

[ZO...@gladucalled.com]

Yup.  The plastic is always on the business end.  It functions as a stop or limit.

Strictly speaking, the numbering of the connector pins themselves is opposite of our pin board numbering (per Right-Hand-Rule).  Eagle EDA is fussy about this. (or I don't know how to impose left-hand numbering yet).

Thanks for the tip.  =SteveM

[ZO...@gladucalled.com]

Hi SteveC,

Here is my solution to my DMA quandary.  I went to the extended bus for the extra pins I needed.  This helped to keep the bus for pins 36-40 sane.  

= SteveM

[Mark T]

Hi Steve,

I think you placed J13 on the wrong side of the main connector.

I'd also recommend using the full 2x40 connector. It can be a bit of a pain aligning the two separate connectors on 0.1 inch centres. If you use separate connectors then plug a two row pin header in before soldering the sockets to the motherboard.

Mark

[brwella...@gmail.com]

Hi Steve,

I found the same problem with my first build of SC112 and SC113. On my second set of boards (you by default usually get 10 of each anyway!) I simply did not fit the headers. My view was that they were only being used to form one of two current fixed configurations and once installed were unlikely to be altered so the fitting of some (easily removeable) solid links when required solves this access problem.

Brian

On Wednesday, August 22, 2018 at 3:58:26 PM UTC+2, Steve Cousins wrote:

[brwella...@gmail.com]

Hi Steve,

Following from my earlier comment regarding fitting solid links rather then headers I have been wondering what we could do to use the currently unused pins 41 to 56.

Pins 49 to 56 have already been unofficially allocated for A16 to A23 but to date I am not aware if these have been actually used on any RC2014 type modules (but stand to be corrected).

The RC2014 PRO backplane currently has no provision even for installing headers for these pins.

My suggestion is to add dual header pads adjacent to pins 41 to 56 inclusive which would then allow links to be installed (if desired) between two different pins where required. The technique of the provision of thin traces between adjacent pads suitable for easy cutting to isolate individual pins or sections (as provided on the PRO Backplane for example) would allow for this flexibility for the joining of non-adjacent pin pads. Obviously you would normally leave all the links intact and only trace cut those which require cross linking.

This suggested solution would still allow for the any eventual official future RC2014 allocation of these pins for other possible uses.

[Steve Cousins]

Hi Mark

Thanks for the part number. You make a good case for using that version of the connector.

Steve

[Steve Cousins]

Hi SteveM

You asked "could we number the 1-40 pins along the back row instead of the front?"

Assuming you mean the second row of the enhanced RC2014 bus, then I'd say best not. The first row is the RC2014 standard 40-pin bus and the use of pin numbers 1-40 is well established. The second row was added later and is also, confusingly I think, labelled 1 to 40 in the official RC2014 docs. As the second row is less well established it is this I feel should be renumbered when using a complete two row plug and socket.

If that was not what you meant then please clarify.

Mark gave a good account of the spacing issue. All I'd add is that others have asked for consistent spacing throughout, which is why I fiddled around with connector placing to get the gap at the section joint to be exactly twice the 0.6" spacing between sockets.

Yes indeed, you could well fit single row connectors to the backplane section, if you so wished.

SteveC

[ZO...@gladucalled.com]

THANK YOU for catching this.  I appreciate you attention to details.

Regarding alignment, I am planning on using two connectors.  I see that my KiCad PCB layout footprints show two connectors sitting comfortable side-by-side with a little room to spare.  Yet, I look at the 3D view, and the shells on the female connectors overlap just a bit.  Is this an issue? It might just be a rendering nit.  

Do we need to be very careful when selecting these parts?

On the card side, I am planning to use three parts, 2 x single row, and 1 x dual row, from the same manufacturer.  I will use a dual row female part to align all the connectors on the card when I solder them to the card. . .   as you suggested.

Thanks again or the J13 catch.   

[Steve Cousins]

Hi Brian

Your wire links sound like a good solution to me.

Your suggestion "dual header pads adjacent to pins 41 to 56" and associated ideas would indeed provide lots of flexibility, so a backplane section with that feature might be very useful. But it is also adding yet more complexity.

Uses for the pins not currently allocated in the RC2014 bus spec were discussed here: (and elsewhere)

https://groups.google.com/forum/#!topic/rc2014-z80/oGw1MAQXfn0

More specifically Spencer's post here:

https://groups.google.com/d/msg/rc2014-z80/oGw1MAQXfn0/umMlj_r_DAAJ

I think we should start a topic to discuss this issue and thus provide more feedback to Spencer as to what we all feel is the best use of the pins. 

Not trying to cause you problems Spencer, but I think there are more important uses than high order address lines (A24 to A31). Others in the group have already voiced ideas for the bus, but a fresh discussion might be worthwhile before it is too late.

I see some common issues being raised where an official bus allocation would be helpful. The use of USER pins to solve common problems is possibly the wrong solution and is leading to 'over use' of these pins. I think USER pins should be for unique/personal applications and not for common needs. 

This 'over use' is in turn leading to clashes and extra complication, which is why we are discussing the need for jumpers all over the backplane. 

Often when things feel complex, it is because you have the 'wrong' solution. Complex solutions aren't usually difficult to dream up, but simple solutions to the same problem often are. We should aim for simple solutions.

I thought backplanes were simple things, but working on these modular backplanes has raised all sorts of issues and has proved far more demanding than any of the modules I've designed. Very strange.

Steve

[Mark T]

Hi Steve,

I think its standard to mount 10 pin and 40 pin female headers next to each other for the enhanced bus. I've not had any problems with spacing being too close, just with accurate alignment due to movement of the headers in the pcb prior to soldering.

Normal practice on the modules is to use the dual row right angled pin header for the full length of the bus, but remove the pins that don't have mounting holes on the module. Spencer has some instructions at rc2014.co.uk, but I couldn't find the right page. The trick is to put the right angled header reversed into the holes of an rc2014 pcb with the second row of pins hanging over the edge of the pcb, then pull out the unwanted pins with long nosed pliers. Take care not to remove the wrong pins.

Mark

[Steve Cousins]

The official backplane pro builds the two rows from separate single row sockets. 

I'm not sure if all manufacturer's sockets have suitable dimensions for this, but the ones I use from eBay are fine. See attached photo. They actually fit snugly together, but I have them angled slightly apart in the photo.

Steve

[Mark T]

Hi Steve,

Its not just that we have complex solutions. We have a number of different simple solutions and it becomes complicated when you try and cater for all the different module solutions in one backplane, or the different backplane solutions in one module.

I blame you for creating the most backplane variations :)

Mark

[Steve Cousins]

Fair point about complexity, Mark.

I hold up my hands and admit I have the PCB design bug. Probably more backplane variations to come too.

Actually I think Karl has designed more backplanes than me. Have you seen all his stuff at EasyEDA? You should blame him. I'm innocent by comparison :)

[karlab]

I think you are still in the lead Steve regarding the number of backplanes.

I have stuck with one header layout for all my backplanes.

karl

[ZO...@gladucalled.com]

Hi karl,

I am would use this with one change, U2 and U3 should be jumpered to allow for diasy-chaining.  

This does not violate the original spec as these are user pins.

[ZORAk]

Hello Steve,

Thanks for the response.  I have read your notes (all of them, I think) and have come to the conclusion that, in the short term, I will continue to use the USER pins as necessary.  There will not be conformity on their use, because they are for, well, users.  This is why I like your boards with jumpers between the User pins.  That approach encouraging the swapping boards between systems and among user community.

The ZMS (my motherboard) is really a workstation for the Interoctor Front Panel and for new designs.  Some card slots will always have the same cards in them, notably the SCC and DMA cards.  I do not anticipate much interest in them.  This is because the SCC uses INTACK, and DMA needs real time OS.

I would like to see IntAck in the 80 pin spec as it is really a processor signal and not a user pin.  IntAck needs to be generated on the motherboard because it is used by multiple cards and must be the same signal to all cards.   But this may not be the same opinion of all.

Thank you for all your work.  It has been stimulating.

One more radical thought.  Cards with finger edge connectors would be cool for the 80 pin spec.

=SteveM

It was easy to see thy you used 40 - 80 for daisy chaining in the 80 pin spec.  When everything settles down

--
You received this message because you are subscribed to a topic in the Google Groups "RC2014-Z80" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rc2014-z80/XvdyuOd62v8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rc2014-z80+...@googlegroups.com.
To post to this group, send email to rc201...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/dbdb323e-a867-4a17-81cf-6391b8da950a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Peter Willard]

"Cards with finger edge connectors would be cool for the 80 pin spec."

Until you price the matching receptacle...  ;-P

[Mark T]

Hi SteveM,

I think INTACK is so rarely used that it wouldn't be worth redesigning the processor module, maybe worthwhile on a special purpose motherboard. It would probably be better to include in the modules that use it, maybe just the scc if that is a requirement, then it can be bussed to other modules that need the same signal via one of the user pins. If the other modules need INTACK but don't require scc, they could generate it themselves or have option links to take from the user pins, or also to provide it to the user pins.

Which pin do you plan to use for INTACK? If you design the first module to use it you get chance to influence a potential standard.

Mark

To unsubscribe from this group and all its topics, send an email to rc2014-z80+unsubscribe@googlegroups.com.

[ZO...@gladucalled.com]

Yup.

[ZO...@gladucalled.com]

Hi Mark,

True, except that IntAck cannot be generated on each card as needed.  It has to be the same signal for all cards.  In this sense, it is really a processor signal and is distributed to all cards.

I'm designing a real-time system, so it this important to me.  Right now, I use U1, on my ZORAk motherboard.  Using USER pins is fair game under the original RC2014 spec.  

BUT, it could be spelled out specifically on the new 80 pin bus.

[Mark T]

Hi Steve,

Is it not generated from IORQ and M1? Then it could be generated on any card and then distributed via U1 to any other card that needs it. It would then be the same INTACK signal used by all cards.

Other cards could also have the circuit to generate INTACK, but with option to either supply to U1 or to receive via U1.

If the SCC card is always required then this would be the ideal choice for the INTACK circuit.

Mark

[Jon Langseth]

On Friday, September 14, 2018 at 8:58:17 PM UTC+2, Mark T wrote:

Hi Steve,

Is it not generated from IORQ and M1? 

Yes, the Z80 Interrupt Acknowledge is indicated through the combined active signals /IORQ and /M1, and there is no separate/dedicated IntAck line. As the RC2014 is a Z80-oriented system, the statement that the "IntAck" cannot be generated on each individual module is incorrect.

Maybe SteveM is talking about some separate Interrupt-acknowledge system he has designed for some expanded interrupt scheme? If so, that would be magic to us unless he explained it. It would also be completely irrelevant for any other RC2014-based system except his.

[ZO...@gladucalled.com]

[ZO...@gladucalled.com]

Good idea, Mark T. 

IntAck will help promote the use of non-Zilog parts.

[ZO...@gladucalled.com]

Jon T,

The timing might be skewed from card to card, all circuits not being made with the same parts -- but usually made from spare gates at hand.  This is not magic, just some advice for neophytes.  Take it or leave it,  (_._)

[Mark T]

Also some of the more obscure zilog parts like the FIO, but that looks like more trouble than its worth.

It might be usefull to try and combine none zilog type device interupts with IM2, but likely that will only be on a single module.

[Jon Langseth]

SteveM,

You are not making a lot of sense to me here. With two signal lines, controlled by the CPU, on a passive bus operating av less than 20MHz, with timing being non-critical for 2 T-states, how can you be worried about timing differences on /INT and /M1. Even the slowest TTL gates will be single-digit nanosecond-scale transitions, while the CPU operates in the 50->500ns range per T state. If you have real skew issues on those signals across your cards, you have far bigger problems than a single IntAck signal can solve, as none of your IO or memory operations can be trusted anyway if that is the case. 

I meant no (_._), but your claims regarding IntAck still make no sense.

[Jon Langseth]

I'm sorry that you seem to have me come across as a less-than-friendly guy, and that I'm still "throwing fuel to the fire", but:

It's a single OR-gate! How can a signal generated by a single OR gate promote the use of non-Zilog parts just by getting a dedicated line on the bus?

[ZO...@gladucalled.com]

Hi Mark T,

Somewhat off topic here, but I have seen the FIO (I think). Is it the single channel part which fixed bugs in the E/SCC?  It introduced a FIFO.  I think Zilog has struggled with synchronous drivers (as did a lot of folks back then).

I am interested in non-zilog part IM2 cards.  Not there yet though.  Got to get the Zilog parts using IM2 and an RT OS.

[ZO...@gladucalled.com]

Hi Steve C,

This is a little off topic, but I am marking the end of circuits in my (custom) bus layout.  Just wanted to share it with you.  I hope to make the ZMS bus self-documenting.  X's mark the end of the line.

[Mark T]

It was the Z8038, it looks like its intended to interface between processors, but seems to need a lot of glue logic for a z80. I saw it in the eagle library for zilog so was curious and searched out the spec to take a look.

Mark

[Steve Cousins]

Hiya Steve(M)

The 'X' marks and bus pin labelling make it clear to me.

I think you are right to put a lot of effort into labelling to self-document the PCB. Who wants to dig out the manual when they can read direct off the board!

A couple of very minor suggestions:

Some sort of graphic (more dashed lines perhaps) to show the how the Ei/Eo pins are connected on the circuit board (as indicated in red on the attached)

Complete the dashed lines where indicated on yellow on the attached.

Steve C

[ZO...@gladucalled.com]

Hi Mark T,

I looked this up and I remember now.  I wanted use a Z8038 for SPI but saw some difficulties with the protocol, don't remember what.  The Z8038 was probably ahead of its time.

Actually it was the Z85233 literature (the EMSCC) where I saw they had made improvements to the SW IntAck servicing.  That made me think earlier parts might have had some bugs in this area.  [ The Z85233 is a PLCC package, and is only one channel - M for Mono. ]  

Best

[Alan Cox]

On Mon, 17 Sep 2018 at 00:02, <ZO...@gladucalled.com> wrote:
>
> Hi Mark T,
>

> I looked this up and I remember now. I wanted use a Z8038 for SPI but saw some difficulties with the protocol, don't remember what. The Z8038 was probably ahead of its time.

A lot of vendors were more on the ball with SPI. The 68HC11 had superb
SPI support, the 68302 had passable support.

> Actually it was the Z85233 literature (the EMSCC) where I saw they had made improvements to the SW IntAck servicing. That made me think earlier parts might have had some bugs in this area. [ The Z85233 is a PLCC package, and is only one channel - M for Mono. ]

I never had any big problems with the 85230, and they turned up on a
lot of X.25 cards, Apple localtalk and amateur packet radio boards
etc. The only real issue I had was that the docs had a suggest
register programming order. What they neglected to add was that in
other orders it doesn't necessarily work at all. Synchronous mode was
also a horror without DMA because the hardware kept interrupting the
CPU all the time.

For lower speeds the easiest SPI I know of is to use a CTC and a PIO.
The CTC is set up to clock the right number of times at the right
number of CPU clocks and the CPU does

in a,(port)
rra
rr b

(repeated 8 times)

As the CTC is set up to clock at the same rate the CPU does each of
those complete cycles a bit turns up with each 'in'.

Doing in and out together needs a slower clock, and write is similar to read.

There is a very nice motorola bus SPI interface (65SPI - actually a
CPLD) used in some of the 65xx systems and also Tormod's SPInx and MOO
cards for the 6809 COCO2/Dragon. I saw
https://www.ecstaticlyrics.com/electronics/SPI/fast_z80_interface.html
also seems to have some useful info on Z80 SPI interfacing although
not quite so neat. The SPInx has the 6809 reading from SPI at
basically CPU memory speed.

Alan

[ZO...@gladucalled.com]

Hello Allen,

My only experience with synchronous was on an SIO using VRTX, an event driven OS.  This was BiSync so the SIO wasn't really put through its paces.  The app captured rocket telemetry at the range at Vandenberg AFB for Orbital Sciences Pegasus rocket.  That was an interesting gig.

Thanks so much for the info.  Let me chew on all your comments for a few days.  

=Steve.

[Colin MacArthur]

Hello,

On the topic of ECB, does anyone out there have a ECB-6 (RetroBrew version)  to RC2014 80 pin adapter ?

I have some ECB cards that I would like to use with my RC2014...

THX

CM 

On Thursday, August 23, 2018 at 11:15:37 AM UTC-6, Jon Langseth wrote:

I see two challenges with this. The first is that, because the ECB connector is not 100mm wide, there's clearance to use the support rails of the chassis. the BP80-like RC2014-compatible bus extensions/versions use the full with of the card for the connector, so the rails may well be getting "in the way". The second challenge is realted to ECB cards having their external interface connectors on the edge opposite the ECB connector, whereas RC2014-like cards have (with ongoing questions) landed on having their external connections on the "short" edge, away from the angle-cut side (as seen relative to the official template).

I'll take this opportunity to respond to Alan's reply to me regarding the ECB. I agree that it's not difficult to build an ECB based system, and it is a nice bus type. But compared to the straight-forwardness of the original RC2014 bus, it's harder to "grasp" for a novice. Combine that (relatively small) element, with the pricing of the required connectors, I found that I preferred the RC2014-style when I was evaluating options. I did whoever not like that the original bus lacked significant signals (I started before the extended bus was a thing), and when I started tweaking, I realized I preferred a shorter dual-row connector. Thus the Z50Bus was born. Regarding my statement of price: in Norway, where I am located, a pair of DIN 41612 connectors costs me as much as the entire 5-slot Z50Bus backplane with connectors does in my Tindie shop.

I think that to stay on topic, we should see this discussion in the light that Mark, Steve and Tom started their discussion: trying to establish an agreed-upon wide version of the RC2014 bus, compatible with the original.

On Thu, Aug 23, 2018 at 5:24 PM <lon...@engr.sc.edu> wrote:

Hi Steve,

Just a thought, but the ECB boards are 100mmx160mm, so similar in width to the RC2014 cards.  John Coffman designed an ECB backplane to fit in the Siemen's Simatic 505-6508 chassis that can be found surplus on eBay.  The 505-6516 is similar, but is longer and supports more slots.  They are also easier to find and less expensive, as they appear to be less popular.  It might be a suitable chassis for a version of the RC2014 backplane.  I'm including a link to John's ECB design, which includes pictures of the chassis and backplane.

https://www.retrobrewcomputers.org/doku.php?id=boards:ecb:backplane-505-6508:start

Dave London

--
You received this message because you are subscribed to a topic in the Google Groups "RC2014-Z80" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rc2014-z80/XvdyuOd62v8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rc2014-z80+unsubscribe@googlegroups.com.
To post to this group, send email to rc201...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/5215bb11-7356-4213-bbb4-95190de857ac%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

regards, Jon Langseth