New bus specification. Out with the old...

[Richard Lewis]

Would like to continue our discussions from rc2014-z80 when it was blocked by the proverbial excrement hitting the spinning blades.... 

I'm going to preface this by saying I'll defer to the real experts. My 2 cents would be 8/16 bit data bus and maybe a 24 bit address bus which will address 16MB (which should be plenty...), interrupt daisy chaining, SPI and I2C (and JTAG if there is room) pins with power and ground setup with a mirror symmetry so the board doesn't go up in smoke if plugged in backwards. Also don't care if it's easy to solder or not. After dealing with 0402 and 0.5mm pitch SMD I can pretty much solder anything now (except BGA but will try this weekend with a hot plate). 

While we are at it, maybe agree on a card standard that has more room on it. 

-Richard

[Sergey Kiselev]

Is the intention to keep the bus RC2014 compatible or not?

There are some obvious advantages of keeping it RC2014 compatible, but also there are some limitations.

Pros:

- One can keep using his/her existing RC2014 boards. This makes it easier to move to the new/enhanced bus.

- The hardware implementation is simple as long as the ICs used are compatible with Zilog Z80 / Intel 808x timing.

Cons:

- The bus is not generic or flexible enough to support other CPUs and higher bus frequencies.

- No bus buffering or termination. Although nothing really prevents from adding buffers/transceivers. Without termination and buffering the bus will be flaky even at relatively low frequencies (10 MHz).

- Obviously lack of the serial signals that Richard had mentioned above.

- Personally, I am not a big fan of using pin headers for bus connectors, they seem to be unreliable and also easy to plug the wrong way (backwards, or at an offset). DIN 41612 connectors, for example, were specifically designed for such applications, and the 32 column connectors conveniently fit 10 cm wide boards. 

A few things to add to the list of requirements:

- 3.3 V power supply. Most newer ICs would require that.

- Form factor specifications. RC2014 uses 5 x 10 cm. I would prefer 10 x 10 cm, or at least 8 x 10 cm (it is or used to be the Eagle CAD free version limit, if anyone cares). Both formats can be cheaply produced by Chinese PCB manufacturers. Other things in the form factor specifications might include the board spacing on the bus and the location of mounting holes.

While we are on it, what are the thoughts on re-using or modifying existing industry standard buses such as STEbus or ECB? I know that they don't provide the serial signals either, but both have some pins available that can be used for extensions. ECB is also somewhat Z80-centric - basically a buffered version of Z80 bus. It has a considerable number of boards already available at www.retrobrewcomputers.org. STEbus is much more universal, but I haven't noticed any hobby activity around it.

- Sergey

On Thursday, June 20, 2019 at 1:01:49 PM UTC-7, Richard Lewis wrote:

Would like to continue our discussions from rc2014-z80 when it was blocked by the proverbial excrement hitting the spinning blades.... 

I'm going to preface this by saying I'll defer to the real experts. My 2 cents would be 8/16 bit data bus and maybe a 24 bit address bus which will address 16MB (which should be plenty...), interrupt daisy chaining, SPI and I2C (and JTAG if there is room) pins with power and ground setup with a mirror symmetry so the board doesn't go up in smoke if plugged in backwards. Also don't care if it's easy to solder or not. After dealing with 0402 and 0.5mm pitch SMD I can pretty much solder anything now (except BGA but will try this weekend with a hot plate). 

While we are at it, maybe agree on a card standard that had more room on it. 

-Richard

[Steve Cousins]

Most of us have significant investment in RC2014, so I think it would be sensible to formalise an RC80 (or whatever we call it) specification. Namely, to decide what to use the "Not used" pins for (as they are called on Spencer's site) and firm up any vague descriptions like the PAGE/RESET2 pin.  This project has been waiting in the wings for a long while, but Spencer has now made it clear the bus will not change. Therefore, the "Not used" pins can now be safely allocated without fear of future conflicts.

I would welcome another bus to play with. Don't forget there is the Z50Bus. I also have my own I/O only bus, which has a few advantages: a shorter connector for easy card removal, less soldering, less real estate wasted on connector pins that are rarely used, more pins available for interrupts etc. Now we have free use of the RC2014 bus "Not used" pins I guess we can allocate similar functions on the RC80 bus.

I would like to stick with cheap header pins for the physical connections. It can get very expensive using high-quality connectors.

I would also like the specified physical parts of the bus to be 0.1" pitch for easy soldering. I struggle to see even these :(  What additional technology goes on the individual boards can be down to individual designers to decide.

I very much like the 100mm x 75mm format. See here for a visual. Actually, I like to work on a 0.1" grid so the boards are actually 3.90" x 2.95". The 50% increase in area is very nice.

Steve

[Tadeusz Pycio]

While we are at it, maybe agree on a card standard that has more room on it. 

The RC2014 problem is the address decoder on every tiny PCB using THT elements. I used to think that it should be on a mounting plate with rigidly assigned socket addresses, but it requires placing certain cards in the right places or EEPROM similar EISA/PCI processor notifications about the function of the given card in the slot. This is a big change.

[Steve Cousins]

You could have a number of pins on the backplane that carry decoded address enable signals to all the sockets. That would avoid have dedicated sockets for specific cards, but at the cost of more bus pins. The best implementation would probably to have one card which is the address decoder, rather than have the decoder on the backplane itself. Such a card could also house interrupt management circuitry, if appropriate, and perhaps other system-wide functions, like reset.

Steve

[Bill Shen]

I do like DIN41612. I thought about a "short Euro" format with 100mmX100mm pc board. To be compatible with RC2014, I thought the center row is defined to interface to the IO bus portion of RC2014 (address 0-7, ground, power, clock, reset, Z80 controls, data 0-7), so a RC2014 IO board can plug into the center row. Backplane can accommodate both DIN connectors as well as RC2014 connectors. This way we can mix and match RC2014 boards and "short Euro" boards
Bill

[Richard Lewis]

I bought three DIN 41612 on eBay, 96 pin was around $4.00 each so not that cheap but not ridiculous either. 

As far as RC2014 bus is concerned my view is we adopt a better standard and just build an adapter. Also with regard to address decoding, if we adopt SPI there will need to be a bus master defined somewhere. Maybe a "bus master card" that uses a CPLD/FPGA to do the decoding and acting as a SPI master. 

[Marten Feldtmann]

Am Donnerstag, 20. Juni 2019 23:19:19 UTC+2 schrieb Steve Cousins:

Most of us have significant investment in RC2014, so I think it would be sensible to formalise an RC80 (or whatever we call it) specification.

+1

I would like to stick with cheap header pins for the physical connections. It can get very expensive using high-quality connectors

+1

I would also like the specified physical parts of the bus to be 0.1" pitch for easy soldering. I struggle to see even these :(  What additional technology goes on the individual boards can be down to individual designers to decide.

+1

 

I also try to NOT use SMD, whenever possible... but have to admit, that I had to work with these types with the 376 board or the I2C board or the FPGA connector - but they also show me my possibilities.

I will never use boards using CLPD or stuff like this (because of additional tools needed).

For me the 80 pin bus was more than ok.

Marten

[Steve Cousins]

So what to do to get the best out of our existing RC2014 investments?

My feeling is the first 'standard' we generate should be the ultimate derivative of the RC2014 bus. Now Spencer has stated the RC2014 bus will not change, it is safe to allocate the "not used" pins without fear of future conflicts.

I see the ultimate extension of the RC2014 bus as a superset of the current specification, maintaining as much compatibility as possible. It should use the existing bus connector, but extended to 2 rows of 40 pins. It should not be called RC2014, but have a new name. It could, perhaps, be described as an extension of the RC2014 bus. 

I have attached a spreadsheet showing the official RC2014 bus, my current extension of this (as used on my backplanes and Z180 products), and an idea for the ultimate extension of the RC2014 bus. Please add ideas and repost.

The spreadsheet also has a TAB showing my uses of the USER and TX/RX pins. The uses in red are those hardwired, while those in black are optional, via jumpers. Again, please add uses by other products and repost.

Perhaps this spreadsheet should be a google doc.

Steve

[Richard Lewis]

I like the provision for SPI and TWI (i2c). Also some common voltages like: 1.8, 3.3 maybe 2.5. Some GPIO pins (aka User pins) but lock them down. 

What about something like this? One disadvantage is that the spacing between the cards would increase. But can add more things like QSPI maybe even an analog port or two? Arduino compatible pins?

[jopil]

Steve, I would suggest  pin 48 to be A24 (for a total of 16MB directly addressable space) and all IEI/IEO to go up to 39-40/79-80.

John

[jopil]

And on the top of that, we can also reserve user1/user2/user5/user6 for the minimal JTAG (IEEE 1149.1) bus. See attached image.

John.

[Steve Cousins]

Does anyone use D8 to D15?

Could do good stuff with those pins.

Steve

[Alan Cox]

Steve:

I would like to keep the 16MB address space as it's the full space for
just about every 16bit (and one or two 8bit processors) up to 65C816,
386SX and 68010. It's also sometimes useful to have 'spare' address
space (eg S100 supported slave CPU boards where you could halt their
CPU via an I/O port and then access their RAM in high address space)

I'm not convinced SPI along the main bus makes sense. I2C just maybe
as it's multimaster but SPI you need a CS and often other bits per
device, plus in all honesty why waste 80pin slots on SPI stuff. That's
a lot of excess soldering 8) I would much rather have a connector of
some kind so that I can use a separate bus and *small* connectors for
pure I2C or SPI devices, along with 3v3 shifters and chip selects.

INT1/INT2 are definitely welcome for 8085 and 68K.

I like the existing IE0/IE1 chaining you did.

Don't see the point in wasting pins on jtag when you usually want to
jtag one device at a time - if ever. Jtag isn't that retro and no

board supports it right now.

Alan

[Alan Cox]

Also for your spreadsheet 6522 VIA and 6502 card have jumpers to put R/W on pin 39

Optional for the 6502 required for the 6522 VIA

[Mark T]

My preference is to allow all the common functions to be allocated within a 2x39 bus rather than 2x40, as this fits within the 100mm width limit of most pcb manufacturers. I think only jlcpcb allows 102mm at low cost and we have recently seen they have changed there pricing for panelization. This impacts your use of pin 40 and 80 for IEI and IEO, I would prefer 39 and 79.

I’d like to see /BAI and /BAO daisy chain also, possibly using 38 and 78. /BAI on a module should include link option from /BUSACK.

I’m using 41 to 44 as MA15 to MA12, so the memory board can be either through a memory mapper or with links for a linear address space. Then using 45 and 46 as alternate read or write to support read protect or write protect or possibly high or low byte.

Maybe pins 41 to 48 could have different definition for ranges of slots on the backplane. One set of slots for memory control and another for input/output or interrupts.

I’d prefer SPI or I2C using pins 35 to 37 or 75 to 37, although this does clash with tx/rx of the standard bus. This is mostly due to my modular backplane only connecting adjacent modules on these pins. Then a SPI or I2C module could be used with a proto board in an adjacent slot. Also SPI or I2C might be better via PMOD connector to external boards.

There have been proposals to include 3.3v but I prefer this to be provided from 5 v on the boards where its used.

Mark

[Mark T]

John, i think A23 is enough for 16MB addressing.

Mark

[IOANNIS PILIOUNIS]

Correct. Thank you Mark.

[jopil]

Some thoughts:

Guys, I think that it is obvious to anyone that the current bus pattern [2x40 holes female socket] that we use as a design paradigm, has a very limited horizon. We can keep using this kind of back-planes and boards design, but for how long? As one can verify by just looking at Steve's makers boards list, almost everything that was to be said on such designs, has been already successfully said. Makers can keep producing kits for this SBC model for educational and experimental purposes, but maybe the time has come to move onto the next generation of  designs that I think need to be based on a very well tested and proven bus like the ISA 8/16-bit bus  https://upload.wikimedia.org/wikipedia/commons/9/9f/ISA_Bus_pins.svg

Backplane sockets can be sourced easily, though just a bit more expensive, but also some thousandths of successful designs are already available to the makers of our community to revitalize and present them under a new and more leveraged manner. Some quick and easy to comprehend links on ISA bus are following in case some of us here want to take a first look, or refresh their background on this technology. 

http://wearcam.org/ece385/lecture6/isa.htm

https://abhishekdutta.org/interfacing-with-the-isa-bus/

We are not in a hurry to decide. Let's think about it for some time and maybe a new forum category could be opened by the administrators under the title ISA-Revisited and start exchanging some ideas in that place.

Happy solstice period to all,

John    

[Mark T]

ISA seems to require pcb longer than 100mm to support 16 bits, so would be an expensive way to experiment with 16 bit processors.

Also the overview of ISA mentions there was never a common standard and Looks like quite a high overhead in glue logic to interface to the bus.

Mostly I just really dislike card edge connectors. I’ve experienced attempts to use these with tin/lead card connections and don’t want to do it again. The cost of gold plating is higher than using the much better din41612 connectors.

I think the ECB bus is a better choice, possibly as Bill suggested in 100mm x 100mm instead of 100mm x 160mm to keep the pcb cost down, although it rises quite quickly again if you want to build it in a nice Card rack.

I still prefer the pin header type bus, for experimenting with different interfaces, probably not good for building a more complex system, but combined with low pcb cost allows testing new ideas without high cost of connectors that are difficult to re-use.

Mark

[Tom Szolyga]

I would like to jump in the discussion with my latest project.  I am designing/building a 68000 16 Bit modular system.  The idea is to have a processor board, memory  board, serial board, IDE disc interface board, etc.  I have used the 80 bin version of the Z80 backplane.  However, some pins MUST be renamed/repurposed to support a 16 bit processor with 16 bit data bus and byte addressing.  Attached is my processor board schematic.  You can see the bus signal assignments.

I am not advocating this as a standard.  I just want to point out the bus needs for the functionality of a simple 16 bit system.

Tom 

[Darren Allen]

+1 for din41612 connectors

ECB  is the way to go

[Mark T]

I still like the idea of using 78 or 80 pin header backplane for development work and backward compatibility with existing modules.

Maybe a backplane/motherboard, 100mm x 160mm, with ECB bus connector to a backplane that would carry maybe 5 or 6 rc2014 type modules, with the 80 pin headers mounted lengthways on the eurocard.

Mark

[Alan Cox]

On Sunday, 23 June 2019 02:45:27 UTC+1, Tom Szolyga wrote:

I would like to jump in the discussion with my latest project.  I am designing/building a 68000 16 Bit modular system.  The idea is to have a processor board, memory  board, serial board, IDE disc interface board, etc.  I have used the 80 bin version of the Z80 backplane.  However, some pins MUST be renamed/repurposed to support a 16 bit processor with 16 bit data bus and byte addressing.  Attached is my processor board schematic.  You can see the bus signal assignments.

I am not advocating this as a standard.  I just want to point out the bus needs for the functionality of a simple 16 bit system.

I'm not sure you _need_ all the 68000 int vectors but intack is a good point. I think even 8080 needs that ?

There is also RC6502 which is a rework of RC2014 for 6502 based systems and used for the Apple on a pile of cards build. It's not quite RC2014 - it puts sync, rw and the like on the bus instead of the classic Z80 lines so isn't quite compatible and is designed for 65xx/68xx parts rather than Intel style bus.

Alan

[Steve Crompton]

Hello Tom,

How far along are you with your 68K project?

I am also designing a 68HC000 modular computer system

So far I have a simple 4 slot backplane, processor board, ram + rom board, dual acia, board and a couple of plug in proto-boards done

The proto-board's have address decoding only on them with a perf-board area to test new hardware idea's

It runs TSBUG or TUTOR Monitor and EHBASIC

Backplane is DIN41612AC 64W

I am currently finishing a PCB giving 32 Digital out lines with option of populating it with 8 TIL311 (costly but super cool) or 32 simple LEDS

I am debating what to do next - CP/M-68K or some sort of file system is needed + I want to do some sort of VGA graphics card for it

Regards

Steve

On Sunday, 23 June 2019 02:45:27 UTC+1, Tom Szolyga wrote:

[Steve Crompton]

My vote is to develop a completely new bus / backplane with DIN41612 connectors for new faster non compatible 8/16 bit processors - as much as I love RC2014 the connectors are just the pits - cheap yes so I understand why they were used but I for one don't necessarily want cheap - DIN41612 allows safe removal and re-insertion of boards. you have 64 or 96 pins to play with too

On Thursday, 20 June 2019 21:01:49 UTC+1, Richard Lewis wrote:

Would like to continue our discussions from rc2014-z80 when it was blocked by the proverbial excrement hitting the spinning blades.... 

I'm going to preface this by saying I'll defer to the real experts. My 2 cents would be 8/16 bit data bus and maybe a 24 bit address bus which will address 16MB (which should be plenty...), interrupt daisy chaining, SPI and I2C (and JTAG if there is room) pins with power and ground setup with a mirror symmetry so the board doesn't go up in smoke if plugged in backwards. Also don't care if it's easy to solder or not. After dealing with 0402 and 0.5mm pitch SMD I can pretty much solder anything now (except BGA but will try this weekend with a hot plate). 

While we are at it, maybe agree on a card standard that has more room on it. 

-Richard

[Tom Storey]

On Sunday, June 23, 2019 at 2:08:36 PM UTC+1, Steve Crompton wrote:

My vote is to develop a completely new bus / backplane with DIN41612 connectors for new faster non compatible 8/16 bit processors - as much as I love RC2014 the connectors are just the pits - cheap yes so I understand why they were used but I for one don't necessarily want cheap - DIN41612 allows safe removal and re-insertion of boards. you have 64 or 96 pins to play with too

I would probably suggest 96 pins, because 64 pins is only the same number of pins in a full size m68k for example, and if you need to gang up some pins for power/ground, youre going to lose out on some signals. 96 pins would enable you to support all pins on the backplane, plus some ganged up for higher power distribution, and also enable larger address spaces/multiple arch's/wider data busses etc etc.

Or, perhaps "extended" signals can be placed on B pins within the connector, with A/C pins used for 8 bit+ micros, and B providing those extended signals needed for 16 bit+ micros (things like A16+, D8+, etc)?

[Marten Feldtmann]

I use them as interrupt lines ...

Marten

[Alan Cox]

I am debating what to do next - CP/M-68K or some sort of file system is needed + I want to do some sort of VGA graphics card for it

CP/M 68K is useful if only for shuffling test stuff back and forth and debugging. Not much else.

EmuTOS might be a nicer fit especially if you want graphics eventually. The current one is  bit untidy on the porting side but the BIOS and BDOS are cleanly separated so would stand just writing a new BIOS from scratch instead of using the current one. EmuTOS is a clone of the Atari ST TOS so gets you FAT file system support and a rather saner environment. It can also support the full graphics stack if you write the low level drawing routines for your board.

And if it's a fairly plain I can probably knock out a Fuzix 68K port fairly trivially.

Alan

[Alan Cox]

There's already a DIN based standard arrangement used by the ex N8VEM now Retrobrew boards

https://www.retrobrewcomputers.org/doku.php?id=boards:ecb:ecbbusinfo

along with a load of boards so maybe wheel reinventing shouldn't happen ?

Alan

[Richard Lewis]

I agree with adopting a "standard" if one already exists. I don't have this to try but will an existing RC2014 card plug into a (I only have a few male ones I got on ebay a while back) female DIN41612? It has standard spacing 100 mil spacing. The only down side is they are not as cheap but compared to how much I've spent on Mouser in the last 6 months they are essentially 'free". 

[Tom Szolyga]

My experience with DIN connectors is they are hard to insert and extract.  A card cage and card extractors seem a must.

Tom

[Tom Storey]

On Sun, 23 Jun 2019, 18:45 Richard Lewis, <richa...@gmail.com> wrote:

will an existing RC2014 card plug into a (I only have a few male ones I got on ebay a while back) female DIN41612?

No, they are physically very different, not least due to n rows of 32 pins.

[Richard Lewis]

Ah of course, my Sunday morning and not enough coffee yet. So would need an adaptor card/board which should not be too hard since we are not changing voltage levels and/or logic standards. 

[Tom Storey]

On Sun, 23 Jun 2019, 18:55 Richard Lewis, <richa...@gmail.com> wrote:

Ah of course, my Sunday morning and not enough coffee yet. 

Happens to me all the time. 😄

[Bill Shen]

RC2014 will plugs into 'c' row of DIN connector just fine. 4 pins will hang out on each side, but that are the 4 spares and A15..A12 of RC2014 which are not needed for IO module.
Bill

[Mark T]

Looking at the ECB bus it seems it has support for 68008 on 8 bit bus, but doesn't seem to have a 68000 on 16 bit bus. Maybe there is a module I missed.

From the ECB definition there don't seem to be control signals for byte access to the 16 bit bus.

As Tom posted schematic earlier for his 68000 project I thought I'd also share schematic for unfinished projects, as I thought it should be possible to interface the 68000 type processor to a less modified RC2014 bus. In these examples I decided not to use VPA type access for legacy 6800 peripherals. I think the only addition required would be separate /UWR and /LWR for writing data from the processor.

I started looking at the 68332 as it has the ability to interface to both 8 or 16 bit bus, so could use 8 bit bus for all IO and 16 bit for memory. I was planning to use the FT245 again as a bootstrap option, unfortunately when reset the DTACK is not used and could not force the 68332 to wait for the next instruction byte from the FT245, but the bus retry could be used to keep retrying the instruction fetch until data is available.

/UWR would be used by the 68332 for 8 bit bus writes and so I swapped /UWR with /LWR and also D0-D7 with D8-D15 compared to the 68000 version.

Although these are both untested I think the ECB bus or 2x80 extended bus would need the addittion of only /LWR or /UWR to support byte access to the 16 bit bus. Possibly also re-using existing IO modules and perhaps memory modules with some wire mods.

Mark

[Marten Feldtmann (Büro Hamburg)]

There is the middle row of the ECB you have to look at ...

Am 23.06.19 um 21:25 schrieb Mark T:

>
> Looking at the ECB bus it seems it has support for 68008 on 8 bit bus,
> but doesn't seem to have a 68000 on 16 bit bus. Maybe there is a module
> I missed.
>

--
__________________________________________________________
| |
| dimap.de |
----------
dimap - das institut für markt- und politikforschung gmbh
büro bonn: konstantinstraße 42, 53179 bonn, +49 228 32969-3
büro hamburg: waterloohain 6-8, 22769 hamburg, +49-40-897182-0
geschäftsführer: reinhard schlinkert, knut holzscheck
amtsgericht bonn, hrb 7335

[Mark T]

Is that what /DS0 and /DS1 are for? Which one is high and which one is low?

[Bill Shen]

The complex 68000 backplane seems an overkill.  You can pack a lot of capabilities in a 100mm x 100mm 2-layer pc board instead of scatter them across multiple boards.  The design is faster and save space without big backplane connectors.  The photo shows a T68KRC ready for CP/M-68K.  It is in 100mm x 76mm 2-layer board with 2 meg of DRAM, 16-bit wide CF interface, dual serial port, and even a 7-seg display.  The backplane is the classic RC2014, but without the A8-A15, so only 28 pins in use.  My Z280 design is also 100mm x 76mm with 2meg DRAM, 16-bit wide CF interface interface to the classic RC2014.  My point is 100mm X 100mm is a lot of space for SBC, but putting big connector plus buffers on it take away the valuable space.  I rather put more features on each board than spread them out across multiple boards with big connectors & buffers.
  Bill

[Bill Shen]

Few more examples of 680x0 from the 'Tiny' (100mmX100mm) series:
* 68302 on a 100mm X 100mm pc board, all through hole components, no expansion bus, however.
* 68020 with 68881 on a 100mm X 100mm.  At one time this was my EPROM programmer.  The EPROM programmer connector IS the expansion bus
* 68030 with 16 or 32meg of DRAM on a 100mm X 100mm pc board.  The expansion bus is the 40-pin header around the 7-seg display.
  Bill

[Steve Markowski]

On Saturday, June 22, 2019 at 1:27:45 PM UTC-4, Steve Cousins wrote:

So what to do to get the best out of our existing RC2014 investments?

Hello Steve,

I would like to leave pin 40 as USER4.  This is an optional 3V3 signal on my designs and is seems to be good choice as pin 40 is sort of an odd duck already.  Too, some older boards have pin 40, some don't.  This means that pin 40 already requires special attention.

More importantly, I think the IEI/IEO should be moved off of pin 40.  Many existing backplanes have pin 40 wired together on all sockets.  That means that the proposed new IEI/IEO boards will not work with older backplane boards.  This is obvious at the outset, but already I am thinking about what pin 40 means, and I don't want think about what it means.  I just want to use virgin IEI and IEO pins that are only used for IEI and IEO and don't have a history and need explaining.

Of course, there is no daisy chaining of bus pins on any pins of Spencer's RC2014 spec.  Yet, I think we should leave his 40 pin spec *exactly* as is and not change pin 40 or overload it with multiple uses.  I want to be able to plug an older board into the newer spec'd backplanes and not have to fiddle with or get clever about what I can and cannot do with pin 40.  If I need IEI/IEO, then will use the a new spec backplane, period.  AND, if I want to jam an original 39 pin or 40 pin board into the new spec backplane, I will know I can.  Pin 40 is an ugly step child and shouldn't be burdened with additional potential uses.  In software, this is called overloading of variables.  I recommend we leave pin 40 as is and use new pins for new functionality.

Pins 78 and 79 looks like a good place for IEI and IEO.  We need and INTACT pin, too.  This signal should be generated in *one place* and distributed to consumer boards.  How about pin 80?  We don't seem to use USER pins much, and the new bus has lots or room on the high ordered pin numbers.

=Steve.

PS thanks for your work on this.

 

[TonyD]

>Does anyone use D8 to D15?

I've got a 8 / 16-bit RAM/ROM card for a 8086 project I've been planning

Tony

[Mark T]

Looking at modules and backplanes already designed and likely being used by a few people already I think pin 38 and 39 should continue to be used for IEI and IEO. This is based on Steve’s designs SC107, SC112 and SC113 backplanes and the SC102 CTC, SC103 PIO, SC104 SIO and SC110 SIO+CTC.

This would also allow up to three IM2 modules on an RC2014 pro backplane. First would have IEO pulled high, IEO to pin 39. Second by cross wiring jumpers for IEI from pin 39, IEO to pin 38. Third by IEI from pin 38.

Going forward to more IM2 modules would then need to move from the backplane pro to a backplane with daisy chain of pins 38 and 39. SC107, SC112 and SC113 already support this.

To fit in with the above I would suggest /BAI on pin 78 and /BAO on pin 79. May be unlikely to have multiple DMA devices but I’d like to experiment with DMA for SPI. If the backplane has daisychain of 38 and 39 then its easier to route daisychain on 78 and 79 than to simply bus them across.

To support byte access to 16 bit memory, we only need one more write control signal. I expect the processors to ignore unnecessary byte of a word during read, and the existing /WR would be used for D0 to D7. I’m still undecided if I prefer 37, 77 or 45-48.

I’m still planning to ignore pin 40 and 80 to stay within a 100mm pcb width, but with a connector mounting face based on 102.4 mm pcb width so I can still consider 102mm width modules in future.

Mark

[Richard Lewis]

JLCPCB upper limit for the $2 board is 102mm x 102mm which is 4.02 inches. The extra 2mm is enough to fit the 40th pin.  Choosing a non-green solder mask adds 2-3 days. 

FYI, a 4 layer board of 102mm x 102mm is $28.00 and takes about 5 bd turnaround. Choosing a solder mask other than green does not add to the delivery time. 

[Marten Feldtmann]

Actually I am using only SC113 and there the IEO,IEI is defined on pin 40/80 - and all my designs are based on that - the reason is very simple. Nobody used 40/80 those days, nobody had suppprt for IEI/IEO.

Marten

[Mark T]

Hi Richard
Actually upper limit for jlcpcb is 102.4mm as they round it to the nearest mm to calculate the charge. However using this limit means the boards are only a good price from jlcpcb making them single source. They also made some changes recently to their pricing so its now $2 for 5 of the first design and $4 for 5 or $5 for 10 of additional designs in the same order. Recently they started adding cost for panelizing two of single design using vscore, but this is hidden cost that they ask for after you place the order and they review the design.

Elecrow and Seeed are currently cheaper than jlcpcb for 10 off 100 x 100, and still seem to allow panelizing same design boards.

Elecrow Minimum distance of trace from board edge is 0.7 mm though which is a bit high compared to jlcpcb at 0.4mm to vscore or 0.2 mm routed edge.

Seeed distance of trace from board edge is 0.3mm, but doesnt specify if this is routed or vscore.

Mark

[Mark T]

Hi Marten,
I think I mentioned to Steve at the time he said he was going to change to 40 and 80 that it was odd that he wanted a standard and yet he was the one now not sticking with that standard.

Mark

[Steve Cousins]

Hi Mark,

I hedged my bets :)

As Marten said, basically nobody uses 40/80 so they were pretty much free for a dedicated daisy chain.

As you said, SC112 & SC113 backplanes allow links to use 38 and 39 for the daisy chain. The problem with hardwiring 38 and 39 as a daisy chain on the backplane is that they are sometimes used for other things.

I think when we have settled on our superset of the RC2014 bus, it is likely I'll add some new modular backplanes to my range which are optimised to match the new spec.

Good idea about the mods to Backplane Pro.

Steve

[Richard Lewis]

Thanks good to know. I usually take the minimums for trace width etc and double them. jlpcb state 3 mils so I use 6. Also like to make sure there is plenty of margin around the edge cuts. Anyway, still $100 cheaper than the local PCB fab shop. 

[Nigel Kendrick]

Would you make room for an optional 3 terminal regulator (I'd use a switcher variety) + caps. There's too many 12/15V bricks within my reach and despite having made up a DC jack socket to plug extension with a 7805 in the middle (all tastefully heatshrunk), I am sure one day I'll act in haste and fry everything on my SC112 with the wrong voltage. Of course, things get more complicated if multiple voltages come in to play - maybe then there will be a PSU board for the bus.

-- Nigel

[Tom Storey]

What about using more modern PCI-e sockets?

At least they will be around for some time to come.

Downsides:

Not very retro

Fine pin pitch

Maybe needs 2+ layer boards

Edge connector and it's issues if not done with gold fingers

But at least you get a lot of pins in a small space which should help to keep board sizes down.

On Sat, 29 Jun 2019, 00:08 'Michael J Strange' via retro-comp, <retro...@googlegroups.com> wrote:

If you want to use the full ISA bus and in need of connectors I sampled the 98-way from Toby Electronics expecting it was going to be a straight forward 49+49 way; it turned out to be an ISA socket so no use to me. All the others on that page are basic 2 row connectors.

https://www.toby.co.uk/board-to-board-pcb-connectors/card-edge-connectors/802-valcon-254mm-vertical-card-edge-socket/

Mike

On Sunday, 23 June 2019 00:29:54 UTC+1, jopil wrote:

Some thoughts:

Guys, I think that it is obvious to anyone that the current bus pattern [2x40 holes female socket] that we use as a design paradigm, has a very limited horizon. We can keep using this kind of back-planes and boards design, but for how long? As one can verify by just looking at Steve's makers boards list, almost everything that was to be said on such designs, has been already successfully said. Makers can keep producing kits for this SBC model for educational and experimental purposes, but maybe the time has come to move onto the next generation of  designs that I think need to be based on a very well tested and proven bus like the ISA 8/16-bit bus  https://upload.wikimedia.org/wikipedia/commons/9/9f/ISA_Bus_pins.svg

Backplane sockets can be sourced easily, though just a bit more expensive, but also some thousandths of successful designs are already available to the makers of our community to revitalize and present them under a new and more leveraged manner. Some quick and easy to comprehend links on ISA bus are following in case some of us here want to take a first look, or refresh their background on this technology. 

http://wearcam.org/ece385/lecture6/isa.htm

https://abhishekdutta.org/interfacing-with-the-isa-bus/

We are not in a hurry to decide. Let's think about it for some time and maybe a new forum category could be opened by the administrators under the title ISA-Revisited and start exchanging some ideas in that place.

Happy solstice period to all,

John    

--
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/faef8c4c-96b2-4829-98f7-40ece5ddef13%40googlegroups.com.

[Steve Cousins]

There seem to have been quite a few posts on this topic, but no real consensus.

I'd like to re-state my view that we should try to agree on the ultimate extension to the RC2014 bus and give it a name. This will allow us to build on our existing RC2014 investments.

There have been several suggestions for adding interfacing off the bus, such as I2C and SPI. I think we should try to agree on common connectors for these and, if possible, common port addresses and bits.

I think there is enough interest here to also start using a more advanced bus.

How to achieve all this is not obvious. Many of the suggestions above are mutually exclusive. Perhaps someone needs to propose a solution and then we debate, iterate and vote.

Steve

[Mark T]

Maybe it would be better to start a new thread to survey everyones proposals. I would suggest putting some limits on the proposals to narrow the discussion. For example a base footprint of 2x40 pin female header for the backplane, should include standard 40 pin rc2014 and enhanced 40+10 rc2014 as subset for backward compatibility.

No proposals for ECB, ISA etc as these don’t contribute to an evolved rc2014 bus, though they are interesting, should have their own threads for discussion.

Mark

[Steve Cousins]

Mark, that sounds like a plan. I'm thinking perhaps to get started with a series of YES/NO questions to help narrow things down a bit.

Steve

[Richard Lewis]

Perhaps setting up a survey would help. I created one on survey monkey and have invited everyone in this topic to comment on it. The link is here: https://www.surveymonkey.com/r/Preview/?sm=bPdeRoNb_2F1I20Buc0BkshI4a_2BB5ZSmHvT4L8k_2FVivMMDYCZqdcP37FvfAQK21t4K

Would be cool if GG had this feature. Probably does but have to pay money for it. 

Please feel free to suggest changes, additional questions etc (I am by no means an expert on this)

[Mark T]

Maybe YES/NO/Don’t Care would help in reducing the variations:)

Should it be restricted to Z80 type bus timing, and then others may be defined where someone wants to redefine the signals for specific processors, if its not easy or they choose not to interface those processors via z80 type bus.

I would propose for a z80 type bus to support 16 bit bus with 8 bit byte access, by adding an upper byte write enable, existing write enable becomes lower byte write enable. Existing read enable would always be 16 bit read, but processor would ignore unwanted byte. I think this simplifies adding 16 bit with byte access to maintain backward compatibility with 8 bit modules.

Mark

[Marten Feldtmann]

In my opinion we have an alternative approach - the 80 pin stuff from Steve - now the question is only what kind of signals do we put on which pin ...

So I would like to divide all signals into several categories:

a) signals defined by RC2014 - perhaps some redefinitions (CLK2 ?)

b) general needed (regardless of which CPU is used)

 e.g. +5V, GND, RESET

c) needed for specific  CPU families:

 -  z80, z180, z280 (Z80 bus 8 bit), ez80 (z80 compatible)

 -  z280 (16 bit databus)

 -  68xxx family

 -  6502

 -  8085

 -  6809

We might perhaps consider the idea, that CPU and RAM systems have direct connections (to reduce the number of address lines needed on the bus) - e.g. I'm now building a Z180 card with RAM and ROM, so the only address lines I have connected are A0 ... A8 (to get 512 IO ports).

[Tadeusz Pycio]

Different processor families require different busses. The RC2014 pinout specification is the Z80 bus, there is no IEI, IEO, /PAUSE (?). You may be wondering about BAI, BAO, DREQ and TEND, here I have my doubts, because such simple systems do not use DMA. Alternatively, you can add I2C, SPI signals, but nobody plans to use them. Other processor families should have a different specification, electrically matched to the existing Z80 bus, so that the wrong use of the module does not cause major damage.

[Marten Feldtmann]

Yes, quite true - but perhaps people starting with RC2014 and they buld their Z80 system. Then they perhaps want to build a 6809 system - and actually the only mayor component they use is the power support and the motherboard. And after that they consider working on a 68K system and again they just use the power support, the motherboard - and perhaps other 68K oriented modules. So some pins may be used on 8 bit systems, while they are used in a different way on 16 bit systems - depending on the CPU family.

I do not want to mix Z80 modules with 68K CPUs modules. I do not want to use Z80 CPU module together with 68K CPU module.

Regarding I2C or SPI - like in software: communication channels are the most important parts of a computer system. Having them offers a chance to play with it. I am not sure, if SPI or I2C are so important, that they might have their own pins on the bus - but having them can open a new world.

On the other hand - its just 8-bt technology, old and sometimes forgotten. Even with the busses available today, one could build a high-end Z80 system with DMA, several INT-lines etc.

Marten

[Tom Szolyga]

I agree with Marten.  I am building a 68K system and I DO NOT want to use Z80 modules with it.  The 68K needs 16 bit data, 24 bit addressing and a large, continuous (not paged) memory.  RC2014 memory modules can not provide this.  With a bare board memory card costing $0.50, it is silly to try an reuse a card not designed for the application.  For I/O cards, the 68K uses -DTACK to signal the end of a cycle and has 5 levels of priority interrupt.  RC2014 uses -WAIT to extend a cycle and a single interrupt and (with extension) a daisy chained priority scheme.  A 68681 serial card instead of a SIO serial card makes sense, especially since the 68681 had dual serial plus 8 bits of parallel. 

One might argue that there is a software investment in programming the RC2014 I/O cards, so reusing them is a good idea.  I am translating Z80 assembly code to 68K assembly code.  It is basically a rewrite using the same algorithms.  Reusing I/O card SW is an illusion.

Tom 

[Mark T]

I thought the dtack to the processor could be generated by inverting the /wait signal. Experimenting with 68k peripherals would probably need other non z80 control signals though.

Mark

[Alan Cox]

On Sunday, 7 July 2019 18:46:22 UTC+1, Tom Szolyga wrote:

One might argue that there is a software investment in programming the RC2014 I/O cards, so reusing them is a good idea.  I am translating Z80 assembly code to 68K assembly code.  It is basically a rewrite using the same algorithms.  Reusing I/O card SW is an illusion.

Really. I'm using the same 16C550A serial on multiple processors, and pretty much all the non Z80 specific cards on my 8085 system. I could use the Z80 SIO as well, as it has the needed support. It's really only the CTC interrupt support and the PIO interrupt support I can't use with a non Z80 processor.

Translating code is also an illusion - it's what compilers were invented for 8)

Alan

[Alan Cox]

On Sunday, 7 July 2019 19:21:46 UTC+1, Mark T wrote:

I thought the dtack to the processor could be generated by inverting the /wait signal. Experimenting with 68k peripherals would probably need other non z80 control signals though.

Mark

I would suggest looking at some of the S100 board documentation. S100 was designed as an 8080 bus with some hacks to make a front panel work nicely. It ran with 8080, 8085, Z80, 6809, 68000, 8086, 32016, PDP-11, TMS9900 and a few other CPU boards by the end so a lot of the signal mangling problems are solved, and in quite a few cases the docs of the time included schematics and even stuff like PAL equations, as do the modern S100 board designs. S100 (especially the IEEE version of it) is horribly complicated and overdone but the basic problems of generating 8080 signals are the same.

S100 systems also supported mixed processor types running under one OS - something nobody ever really supported properly in later computing eras.

Alan

[Greg Holdren]

Simple systems don't use DMA? Z80 DMA was used in many commercial CP/M computers. I consider commercial CP/M computers, simple.  Primarily for fast data rate floppy interface with slow 4MHz Z80s. The CPU is to slow to process the data by polling/int means by itself.

I2C would only use two pins. I'd would potentially use it and design around it were available. This makes a perfect side comm bus for peripherals to configure/inventory HW cards. Many servers use I2C for this reason. Memory modules use it. etc.

SPI, faster but not ideal over a back plane.

Greg

[Tadeusz Pycio]

Hi, Greg

 

Simple systems don't use DMA?

I have not noticed the implementation in RC2014, even in Z180 that have DMA built-in. Users complain about serial transmission errors, and nobody uses what they have.

I2C would only use two pins. I'd would potentially use it and design around it were available. This makes a perfect side comm bus for peripherals to configure/inventory HW cards. Many servers use I2C for this reason. Memory modules use it. etc.

 I proposed using I2C and a small EEPROM to identify the card in the slot. To deprive the address decoder in small PCB modules, this requires a revolutionary change of the RC2014 bus. It gives us the opportunity to introduce even a device service program to use in this memory. The application requires 6 pins, Slot Chip Select, SDA, SCL and hardwired EEPROM addresses A0-A2 of the every socket. This is a very deep change of the RC2014 bus. :/

[Greg Holdren]

On Sunday, July 7, 2019 at 5:00:03 PM UTC-7, Tadeusz Pycio wrote:

Hi, Greg

 

Simple systems don't use DMA?

I have not noticed the implementation in RC2014, even in Z180 that have DMA built-in. Users complain about serial transmission errors, and nobody uses what they have.

Nobody has really used it with RC2014 because >4MHz Z80s and because CF (which is what users use the most for storage) is plenty fast.

I2C would only use two pins. I'd would potentially use it and design around it were available. This makes a perfect side comm bus for peripherals to configure/inventory HW cards. Many servers use I2C for this reason. Memory modules use it. etc.

 I proposed using I2C and a small EEPROM to identify the card in the slot. To deprive the address decoder in small PCB modules, this requires a revolutionary change of the RC2014 bus. It gives us the opportunity to introduce even a device service program to use in this memory. The application requires 6 pins, Slot Chip Select, SDA, SCL and hardwired EEPROM addresses A0-A2 of the every socket. This is a very deep change of the RC2014 bus. :/

I don't know what others are thinking about I2C but I was not envisioning using 6 pin on the bus for I2C. Just 2 as I mentioned. The boot code can interrogate base I2C addressed to detect capabilities and set IO address as needed for the card. i.e. I2C based IO port IC to assist. Of course the I2C address would need to be set on the card then with jumpers, straps or dip switches.

Other (non config) uses for the I2C bus could used for cards lacking IO on the main devices accessible via the CPU bus. I2C could help sense input or drive lines (LEDs) etc. as needed.

Greg

 

[Phillip Stevens]

Greg Holdren wrote:

I don't know what others are thinking about I2C but I was not envisioning using 6 pin on the bus for I2C. Just 2 as I mentioned.

I'd agree, and even further, would even question the value of putting I2C on a 40 or 80 pin bus in the first place?

I guess the only reason would be to identify cards, but that's kind of a limited application that could be done more cheaply with a little EEPROM.

But, the real purpose, imho, of I2C is to connect modern sensors, actuators, and displays at up to 1MHz (fast mode plus).

It is a bus unto itself.

The two pin-outs for the I2C bus that I chose are those of the Seeed Grove system, which provides a multitude of I2C devices, and the Sparkfun I2C standard [Gnd-Vcc-SDA-SCL]. Since these are both small form factor connections, it didn't hurt to have both options available.

Cheers, Phillip

 

[Tadeusz Pycio]

Simple systems don't use DMA?

I have not noticed the implementation in RC2014, even in Z180 that have DMA built-in. Users complain about serial transmission errors, and nobody uses what they have.

Nobody has really used it with RC2014 because >4MHz Z80s and because CF (which is what users use the most for storage) is plenty fast.

 

We are going back to the beginning, simple systems as RC2014 do not have to have additional DMA control signals. Although there is an open question about serial ports, chip without FIFO and adopting as a standard speed of 115 k which is not realistic for transferring more data

[Greg Holdren]

I'm confused. We are in retro-comp right? The subject is new bus spec right? The 40 RC2014 doesn't have the required DMA related

 signals but the 80pin RC2014 does. Therefore one could add a Z80-DMA to the 80 pin RC2014 bus. Maybe I'm missing where you are coming from.

Greg

[Tadeusz Pycio]

I'm confused. We are in retro-comp right? The subject is new bus spec right? The 40 RC2014 doesn't have the required DMA related

 signals but the 80pin RC2014 does. Therefore one could add a Z80-DMA to the 80 pin RC2014 bus. Maybe I'm missing where you are coming from.

 Hi, Greg

I do not think we understood each other. :)  What is currently on the 80 pin bus (BUSREQ, BUSACK) is probably not going to change. I spoke about the BAI, BAO, DREQ-(Here I have doubts) and TEND signals that are missing and I do not see the need to implement them.

[Alan Cox]

On Sunday, 7 July 2019 23:23:30 UTC+1, Greg Holdren wrote:

Simple systems don't use DMA? Z80 DMA was used in many commercial CP/M computers. I consider commercial CP/M computers, simple.  Primarily for fast data rate floppy interface with slow 4MHz Z80s. The CPU is to slow to process the data by polling/int means by itself.

More for 8" floppy and 2MHz 8080 parts although they then tended to use Intel not Zilog DMA controllers. A 4MHz Z80 is fast enough not to need help with 5.25" single/double and with care and good hardware design high density.

There are cases the Z180 DMA would be useful - for example driving the CF adapter at full speed.

[Greg Holdren]

Ok, I see.

[Marten Feldtmann]

Ok, to make things happening - here are my wishes (knowing the rule, that the first offer is never accepted). This is my bus specification for a Z80/Z180 08bit system.

• PIN 01 - SCLK, A15
• PIN 02 - MOSI, A14
• PIN 03 - MISO, A13
• PIN 04 - /DREQ1, A12
• PIN 05 - /TEND1, A11
• PIN 06 - free, A10
• PIN 07 - I2C_SDA, A9
• PIN 08 - I2C_SCL, A8
• PIN 09 - A23 (BAI), A7
• PIN 10 - A22 (BAO), A6
• PIN 11 - A21 (/INT1), A5
• PIN 12 - A20 (/INT2), A4
• PIN 13 - A19, A3
• PIN 14 - A18, A2
• PIN 15 - A17, A1
• PIN 16 - A16, A0
• PIN 17 - GND, GND
• PIN 18 - +5V, +5V
• PIN 19 - /RFSH, /M1
• PIN 20 - /RESET2 (/PAGE), /RESET
• PIN 21 - CLK2
• PIN 22 - /BUSACK, /INT
  
• PIN 23 - /HALT, /MREQ
• PIN 24 - /BUSRQ, /INT
• PIN 25 - /WAIT, /RD
• PIN 26 - /NMI, /IORQ
• PIN 27 - /INT_A, D0
• PIN 28 - /INT_B, D1
• PIN 29 - /INT_C, D2
• PIN 30 - /INT_D, D3
• PIN 31 - /INT_E, D4
• PIN 32 - /INT_F, D5
• PIN 33 - /INT_G, D6
• PIN 34 - /INT_H, D8
• PIN 35 - Tx2, Tx
• PIN 36 - Rx2, Rx
• PIN 37 - USER4, USER1
• PIN 38 - USER5, USER2
• PIN 39 - USER6, USER3
• PIN 40 - IEI, IEO
  

[Alan Cox]

On Tuesday, 9 July 2019 09:09:54 UTC+1, Marten Feldtmann wrote:

Ok, to make things happening - here are my wishes (knowing the rule, that the first offer is never accepted). This is my bus specification for a Z80/Z180 08bit system.

• PIN 01 - SCLK, A15
• PIN 02 - MOSI, A14
• PIN 03 - MISO, A13

SPI requires chip selects so IMHO there is no point running SPI down the bus when you don't have half a dozen GPIO lines for CS, reset, C/D etc that devices also need.

• PIN 07 - I2C_SDA, A9
• PIN 08 - I2C_SCL, A8

And I'd really hate to waste an 80 pin slot for 4 connections to do i2c so I dont see the point oif i2c down the bus either.

• PIN 27 - /INT_A, D0
• PIN 28 - /INT_B, D1
• PIN 29 - /INT_C, D2
• PIN 30 - /INT_D, D3
• PIN 31 - /INT_E, D4
• PIN 32 - /INT_F, D5
• PIN 33 - /INT_G, D6
• PIN 34 - /INT_H, D8

S100 had 8 vectored interrupt lines. Even assuming you had a CPU or interrupt controller card that could use them nothing ever needed that many vectors.

• PIN 40 - IEI, IEO
  

This also needs backplane support for the lookaheads if it is used for more than four devices.

Alan

[Marten Feldtmann]

Am Dienstag, 9. Juli 2019 13:58:31 UTC+2 schrieb Alan Cox:

On Tuesday, 9 July 2019 09:09:54 UTC+1, Marten Feldtmann wrote:

Ok, to make things happening - here are my wishes (knowing the rule, that the first offer is never accepted). This is my bus specification for a Z80/Z180 08bit system.

• PIN 01 - SCLK, A15
• PIN 02 - MOSI, A14
• PIN 03 - MISO, A13

 The CS lines could generates on the modules, using these signal lines ... so three flying lines less ...

 

SPI requires chip selects so IMHO there is no point running SPI down the bus when you don't have half a dozen GPIO lines for CS, reset, C/D etc that devices also need.

• PIN 07 - I2C_SDA, A9
• PIN 08 - I2C_SCL, A8

And I'd really hate to waste an 80 pin slot for 4 connections to do i2c so I dont see the point oif i2c down the bus either.

 If I have lines available I use them. This is not a waste of lines (by the way - only 2 pins), I have them and I use them. If there are other signals more important, then ok, lets speak about it ...

• PIN 27 - /INT_A, D0
• PIN 28 - /INT_B, D1
• PIN 29 - /INT_C, D2
• PIN 30 - /INT_D, D3
• PIN 31 - /INT_E, D4
• PIN 32 - /INT_F, D5
• PIN 33 - /INT_G, D6
• PIN 34 - /INT_H, D8

S100 had 8 vectored interrupt lines. Even assuming you had a CPU or interrupt controller card that could use them nothing ever needed that many vectors.

• PIN 40 - IEI, IEO
  

This also needs backplane support for the lookaheads if it is used for more than four devices.

This is a strange argumentation - we have no official support for 4 devices. Adding these lines makes the sysem at least runnable for four devices.

Alan

[Alan Cox]

>>> PIN 01 - SCLK, A15
>>> PIN 02 - MOSI, A14
>>> PIN 03 - MISO, A13
>>

>  The CS lines could generates on the modules, using these signal lines ... so three flying lines less ...

Not really because it must be impossible to accidentally select two devices at once.  If you are using off the shelf modules then you really want a separate 'bus' for things like SPI, one with small easy to solder connectors. SPI is also mostly 3.3v so that is another reason for keeping it apart  as you want to run the SPI devices on a small 3.3v bus of their own not the 5v.

>  If I have lines available I use them. This is not a waste of lines (by the way - only 2 pins), I have them and I use them. If there are other signals more important, then ok, lets speak about it ...

You use them, and then there are non free for something it turns out we do need later! Nominating a pair of user pins as a default i2c option if wanted does sound sensible.

>>> PIN 40 - IEI, IEO
>>
>>
>> This also needs backplane support for the lookaheads if it is used for more than four devices.
>>
>

> This is a strange argumentation - we have no official support for 4 devices. Adding these lines makes the sysem at least runnable for four devices.

I'm not arguing against them being there, just pointing out that IE0, IE1 is more than just nominating pins and an specification would need to comprehend that.

Alan

[Steve Cousins]

Just a small comment on Alan's point "... it must be impossible to accidentally select two devices at once"

If the hardware has no protection against two devices being selected as once, then a simple 270 ohm resistor could be included as a current limiting resistor in the MISO line. This value should not degrade the signal quality enough to be a problem but would protect the device from physical damage.

Steve

[Steve Cousins]

This topic seems to have stalled.

Looking over the various comments it seems that there are quite a few mutually exclusive ideas. 

Can anyone see a way forward or should we just say the extra pins are available for individual designers to use as they please?

Steve

[Marten Feldtmann]

Yes

Marten

[Karl Albert Brokstad]

I don’t have a strong opinion on this subject other than I follow the “flock” and I think it is important to settle on a standard.
I think the layout that SteveC have been utilized in his design is a great foundation for further standardization.

U1..U4 interrupt chain and module to module communication.
U5..U8 counter, timers, sync signals
Keep d8..d15
Keep a16..a23
X0..X7 for various non signal lines like 12v, 3.3v, and extra bus signals, i2c chain

Karl

[Mark T]

My preference is similar to Karl’s.

Keep A23..A16
Keep D16..D8.

X7..X0 for bussed signals across backplane. Maybe alternate voltages but I think I prefer to keep those off the backplane. Possibly different functions across different sections of backplane.

U1 to U8 for connections to adjacent cards, including timers, interrupts etc. Using links to allow daisy chains for IEI/IEO or BAI/BAO.

Personally I would include Tx/Rx in the same category as U1 to U8, as unlikely these need to connect more than two modules.

Would be good to keep the variations in IEI/IEO to those that already exist. 38 and 39, 79 and 39, 80 and 40.

Mark

[Steve Cousins]

Let's try a very slightly different approach. 

Starting with the official RC2014 specification, let's add in the pin functions that there seems to be general agreement about.

The official RC2014 specification is this:

41 -  Not used      01 -  A15

42 -  Not used      02 -  A14

43 -  Not used      03 -  A13

44 -  Not used      04 -  A12

45 -  Not used      05 -  A11

46 -  Not used      06 -  A10

47 -  Not used      07 -  A9

48 -  Not used      08 -  A8

49 -  Not used      09 -  A7

50 -  Not used      10 -  A6

51 -  Not used      11 -  A5

52 -  Not used      12 -  A4

53 -  Not used      13 -  A3

54 -  Not used      14 -  A2

55 -  Not used      15 -  A1

56 -  Not used      16 -  A0

57 -  GND           17 -  GND

58 -  +5V           18 -  +5V

59 -  /RFSH         19 -  /M1

60 -  /PAGE (/RST2) 20 -  /RESET

61 -  CLK2          21 -  CLK

62 -  /BUSACK       22 -  /INT

63 -  /HALT         23 -  /MREQ

64 -  /BUSRQ        24 -  /WR

65 -  /WAIT         25 -  /RD

66 -  /NMI          26 -  /IORQ

67 -  D8            27 -  D0

68 -  D9            28 -  D1

69 -  D10           29 -  D2

70 -  D11           30 -  D3

71 -  D12           31 -  D4

72 -  D13           32 -  D5

73 -  D14           33 -  D6

74 -  D15           34 -  D7

75 -  Tx2           35 -  Tx

76 -  Rx2           36 -  Rx

77 -  USER5         37 -  USER1

78 -  USER6         38 -  USER2

79 -  USER7         39 -  USER3

80 -  USER8         40 -  USER4 

Signal uses in brackets are alternative functions.

Adding 8 additional address lines seems to be a popular request, giving this pinout:

41 -  Not used      01 -  A15

42 -  Not used      02 -  A14

43 -  Not used      03 -  A13

44 -  Not used      04 -  A12

45 -  Not used      05 -  A11

46 -  Not used      06 -  A10

47 -  Not used      07 -  A9

48 -  Not used      08 -  A8

49 -  A23           09 -  A7

50 -  A22           10 -  A6

51 -  A21           11 -  A5

52 -  A20           12 -  A4

53 -  A19           13 -  A3

54 -  A18           14 -  A2

55 -  A17           15 -  A1

56 -  A16           16 -  A0

57 -  GND           17 -  GND

58 -  +5V           18 -  +5V

59 -  /RFSH         19 -  /M1

60 -  /PAGE (/RST2) 20 -  /RESET

61 -  CLK2          21 -  CLK

62 -  /BUSACK       22 -  /INT

63 -  /HALT         23 -  /MREQ

64 -  /BUSRQ        24 -  /WR

65 -  /WAIT         25 -  /RD

66 -  /NMI          26 -  /IORQ

67 -  D8            27 -  D0

68 -  D9            28 -  D1

69 -  D10           29 -  D2

70 -  D11           30 -  D3

71 -  D12           31 -  D4

72 -  D13           32 -  D5

73 -  D14           33 -  D6

74 -  D15           34 -  D7

75 -  Tx2           35 -  Tx

76 -  Rx2           36 -  Rx

77 -  USER5         37 -  USER1

78 -  USER6         38 -  USER2

79 -  USER7         39 -  USER3

80 -  USER8         40 -  USER4

All required extra signals could be provided by fly wires but my feeling is commonly used signals should be on the bus if possible.

Mark T suggested keeping IEI/IEO in the positions they have previously been used. If these are designated as "alternative" functions to the existing USER pins or made optional (by links or jumpers) I can't see much reason to object to this. 

Currently two schemes have been used: Pins 38/39 and Pins 40/80. Adding these to the specification gives us:

41 -  Not used      01 -  A15

42 -  Not used      02 -  A14

43 -  Not used      03 -  A13

44 -  Not used      04 -  A12

45 -  Not used      05 -  A11

46 -  Not used      06 -  A10

47 -  Not used      07 -  A9

48 -  Not used      08 -  A8

49 -  A23           09 -  A7

50 -  A22           10 -  A6

51 -  A21           11 -  A5

52 -  A20           12 -  A4

53 -  A19           13 -  A3

54 -  A18           14 -  A2

55 -  A17           15 -  A1

56 -  A16           16 -  A0

57 -  GND           17 -  GND

58 -  +5V           18 -  +5V

59 -  /RFSH         19 -  /M1

60 -  /PAGE (/RST2) 20 -  /RESET

61 -  CLK2          21 -  CLK

62 -  /BUSACK       22 -  /INT

63 -  /HALT         23 -  /MREQ

64 -  /BUSRQ        24 -  /WR

65 -  /WAIT         25 -  /RD

66 -  /NMI          26 -  /IORQ

67 -  D8            27 -  D0

68 -  D9            28 -  D1

69 -  D10           29 -  D2

70 -  D11           30 -  D3

71 -  D12           31 -  D4

72 -  D13           32 -  D5

73 -  D14           33 -  D6

74 -  D15           34 -  D7

75 -  Tx2           35 -  Tx

76 -  Rx2           36 -  Rx

77 -  USER5         37 -  USER1

78 -  USER6         38 -  USER2 (IEI)

79 -  USER7         39 -  USER3 (IEO)

80 -  USER8 (IEI)   40 -  USER4 (IEO)

Ideally, we should only have one designated pin for IEI and one for IEO. Currently pins 38/39 are allocated for 40 pin modules while using pins 40/80 causes fewer conflicts on the crowded USER pins but is only suitable for 80 pin modules.

So now the even more controversial signals:

Bus ack in/out daisy-chain - BAI, BAO

I2C - SCL and SDA

SPI - SCLK, MOSI, MISO

IntAck

Additional interrupts - INT1, INT2 (for Z180 etc)

DMA - DREQ, TEND

Other voltages

Personally, I think I2C is desirable. I also would like SPI signals even though it still means generating chip selects locally or by flying leads.

Personally, I'm not keen on having different voltages on the bus. I would prefer them to be generated where needed.

A few extra interrupt signals seem very desirable to me. The Z180, for example, has two additional interrupt inputs.

We have 8 completely uncommitted pins available and 12 signals (listed above) looking for homes. 

Marten suggested:

41 -  SCLK          01 -  A15

42 -  MOSI          02 -  A14

43 -  MISO          03 -  A13

44 -  /DREQ1        04 -  A12

45 -  /TEND1        05 -  A11

46 -  free          06 -  A10

47 -  I2C_SDA       07 -  A9

48 -  I2C_SCL       08 -  A8

This would leave BAI, BAO, IntAck, INT1, INT2 without homes.

I would prefer to have INT1 and INT2 to DREQ and TEND. So perhaps:

41 -  SCLK          01 -  A15

42 -  MOSI          02 -  A14

43 -  MISO          03 -  A13

44 -  /INT1         04 -  A12

45 -  /INT2         05 -  A11

46 -  free          06 -  A10

47 -  I2C_SDA       07 -  A9

48 -  I2C_SCL       08 -  A8

This would leave BAI, BAO, IntAck, /DREQ1, /TEND without homes.

If your priority is to have DMA signals on the bus, then perhaps:

41 -  free          01 -  A15

42 -  /DREQ1        02 -  A14

43 -  /TEND1        03 -  A13

44 -  /INT1         04 -  A12

45 -  /INT2         05 -  A11

46 -  free          06 -  A10

47 -  I2C_SDA       07 -  A9

48 -  I2C_SCL       08 -  A8

This would leave BAI, BAO, IntAck, SCLK, MOSI, MISO without homes.

Additional daisy-chains could be supported by jumpers or links on the backplane (as proposed for IEI/IEO). Perhaps USER6 and USER 7 could be suggested for this.

Designers of backplanes can offer options to limit signals to just groups on sockets rather than being common to the whole bus. This feature can be desirable for USER, TX and RX signals.

I think we should define the backplane signals for Z80 family products. We can produce a separate specification for other processor types, possibly using the same physical backplane and even many common signals. 

There is nothing to stop individual designers using the backplane however they like, but if sharing designs or selling products then non-standard uses would need to be clearly stated. Marten's use of pins 67 to 74 for interrupts would be one example.

So where does that leave us?

My feeling is that we, as a group, should agree what we can. This may be no more than the additional address lines. After that, any uncommitted pins should be designated as additional USER functions and allow individual designers to do whatever they wish with them. Any signals not then on the bus should ideally have agreed header pinouts for use with flying leads and daughter boards.

Thoughts anyone?

Steve

[Mark T]

BAI/BAO would probably be a fairly specialist experiment, also as its easier for me to create a daisy chain in the U1 to U8 pins, then I would make them optional use of U1 to U8 pins.

One of the uses of the CTC module is to provide additional IM2 mode interrupts, via Ux pins. It might be nice if modules that wanted to drive a CTC in this way could also drive /int1 or /int2 on the same pins, so perhaps consider putting /int1 and /int2 onto Ux pins that match the CTC trigger inputs.

D16..D8 used as additional interrupts restricts modules using these to 8 bit processors, but maybe this is not a problem so long as its documented.

I’m not keen on putting spi or i2c on the bus, but if X0 to X7 were to be user defined pins, it would still make sense that if spi or i2c are going to be used that everyone uses the same Xx pins for these functions. Would these always be 3v3 or 5v? Maybe 3v3 signals but 5v tolerant would be a good choice.

Mark

[Marten Feldtmann]

"I think we should define the backplane signals for Z80 family products. We can produce a separate specification for other processor types, possibly using the same physical backplane and even many common signals."

Yes, that is in my view a good way to reduce the complexity: Z80, Z180 ... this would free the A20 ... A23 lines or do we really need more than 1MB RAM/ROM on such a system ?

[Karl Albert Brokstad]

On 19 Aug 2019, at 11:17, Marten Feldtmann <m.fel...@dimap.de> wrote:

"I think we should define the backplane signals for Z80 family products. We can produce a separate specification for other processor types, possibly using the same physical backplane and even many common signals."

Yes, that is in my view a good way to reduce the complexity: Z80, Z180 ... this would free the A20 ... A23 lines or do we really need more than 1MB RAM/ROM on such a system ?

1MB is probably enough, and it is possible to page switch extended memory.

Karl

--
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/801a2718-f139-4791-a37a-af6b846e4ba0%40googlegroups.com.

-----
Karl Albert Brokstad
Kirkeveien 9B, 5072 Bergen
98843314, 55289014
ka...@brokstad.no

[Eric Matecki]

I don't think I2C is useful on the backplane:

* For sensors, you need an 'external' bus (several de facto standard already exists) => a board with a few I2C buses, some already exists.

* For board configuration ROMS as someone suggested :

- no OS support this yet or is easy to adapt

- the board's address should be linked in some way to the I2C address of the ROM (may be easy if there are I2C flashROMs with many address selection inputs, but those I know of have usually only 2 => need for additional logic)

- we'll need an additional standard of what these ROMS should contain, usualy this is some interpreted language code (often forth) for initialisation, finalisation, etc; which means you'll need to integrate an interpreter for this language in your OS => bloatware.

My I2Cents

[Steve Cousins]

Hi Eric

I agree that if you want to interface a bunch of sensors via I2C you probably wouldn't want it done via the backplane.

I also agree all those clever ideas about identifying hardware etc using an I2C bus on the backplane are just too complex to bother with and there is too much non-compliant hardware out there to now make it worth adding on the existing RC based hardware.

My reasons for wanting I2C is that there are some applications which might want to be built on a module fitted to the backplane, where I2C is a good way to communicate with them. These include a real-time clock, status LEDs, configuration DIP switches, simple digital I/O, ADC, DAC. I'm not suggesting there aren't other ways to interface to these devices, just that I2C would be a nice option to have. It seems like a good use of two pins to me.

My reasons for wanting SPI are similar. If you have an SPI master in your system you might well want to use SPI devices on other modules. Three pins on the bus look like a better solution than flying wires. I agree with those who say chip selects are still needed but these can be generated locally on the target module. 

Sharing signals is what a backplane does, so I say, if we can afford the pin count, then use it for all signals that are relatively common.

I would want the backplane signals to be 5 volts with local level shifters where needed.

Steve

[Steve Cousins]

I have roughed out a backplane design where all the existing 8 USER pins and the 4 TX/RX pins can be configured by cutting thin tracks and fitting links or jumper headers.

This allows very flexible isolation of signals to just a pair or group of backplane sockets, any of the USR pin pairs (eg. 40/80) to be converted to a daisy chain, and any adjacent pin pairs (eg. 37/38) to be converted to a daisy chain. 

It could easily be manufactured with defaults set to simple 1 to 1 wiring of all pins or with one or more pairs set up as a daisy chain.

I'm sure this will work and support most of our historical uses of the USER pins, but it feels wrong. It is complicated when a backplane should be simple. It supports all our old baggage when what we would like is a nice clean 'new' design.

It seems to be one of those cases of "if you want to get there, I wouldn't start here mate".

However, as the whole reason for doing this is to build on what we have, rather than start from scratch, perhaps we have our hands tied.

Steve

[Mark T]

Hi Steve,

Very similar to a suggestion I posted some time ago in the other forum, If the header pin layout is adjusted to that original suggestion the trace routing can be simplified and single sided.

I would also recommend changing the trace routing of the bussed connections to also be single sided, Then one side of the board can be a filled ground plane, this might take some adjustment of pad sizes on that side of the board to allow the ground plane to fill between pins. I can do this in eagle without reducing pad size on the solder side of the board but not sure if thats possible in easyeda or kicad.

If I remember correctly you thought pin headers and jumpers close to the backplane connectors would be a problem for access, but I think this could be avoided just be putting the on the underside of the board. This might make the soldering a bit tricky to access between adjacent connectors.

I don't like to use cut away links, but I guess thats OK if the default connections work for most cases.

edited above to correct a typo.

Mark

[Mark T]

If I was going to start from scratch, then I'd probably pick 100mm wide module, using 32 pin din a+b type, to allow pin headers for development and proper connectors for a final system. Also reserve board edges for card rails. I think modern components would be able to fit quite a lot into 100mm square pcb and still keep down the pcb cost.

Mark

[Steve Cousins]

Hi Mark

Yes, I remember you put forward ideas for isolating bus sockets a long time ago. This whole backplane issue has been batted about quite a bit.

You are also right that I am not keen on the headers and jumpers being close to the module sockets. There are enough problems already inserting and removing modules. That is why I have returned to the pads and tracks method. As you say, sensible defaults should mean most people don't need to cut tracks and add links.

It all still feels too complex. A backplane should be simple.

Steve

[Steve Cousins]

ps. I've laid out a 12 slot backplane with tracks on one side as Mark suggests but with the proposed track and pad option there is a need for a track beyond the last pad. This is too close to the edge of the PCB for my liking, thus the proposed layout.

[Steve Cousins]

I've built some Z50Bus systems. These use the same cheap header pins and sockets but are only 2 rows of 25 pins. This makes module removal much easier. It also means the module and backplane size can be reduced, which would allow Mark's PCB case idea using cheap PCB sizes.

Also, I built my own system using headers with 2 rows of 20 pins. This is an I/O only bus but takes less soldering, less space, and easy module removal. I find this a very attractive compromise.

Steve