What about an I/O only bus ?

[Eric Matecki]

Hi,

The rationale behind my thinking are :

- the trend for CPU boards is to put memory on the same board anyway => no need for tons of address signals.

- a lot of I/O boards have only a few 8bits registers => 8 data signals and simple read/write signals.

What will make this more complicated than it appears at first ?  Mainly data storage devices.

- CF works "better" in 16bits mode, but is quite useable in 8bits mode.

- DMA, where I have no experience, and no idea if possible at all in a generic way (mostly for floppies and IDE, but maybe also things like a sampled audio out+DAC ?)

Steve Cousin has already designed and built one, using 2x20 connectors.

Let's try to make it CPU and I/O family agnostic.

This means stuff like a single Write signal, a single Read signal, generated by glue logic from the CPU signals (I/O or memory mapped), either on the CPU board or the backplane.

Maybe it could also do some of the address decoding.

One physical implementation of a whole computer could be inspired (again...) by Steve's modular backplanes,

with the CPU, memory, and I/O bus "bridge" logic on one backplane with only a few (or even no) vertical I/O bus connectors, and an horizontal connector for an expansion I/O backplane.

The Z80 backplane could have an RC2014 horizontal connector on the other side to reuse already existing boards.

I hope my ramblings are clear :)

[Steve Cousins]

Hi Eric,

You've just explained perfectly why my designs have followed the path they have.

The modular backplane system has yet to take full advantage of one of its potential advantages. Originally I anticipated having different backplane sections for different purposes. The only 'special' sections I have currently produced is a Z50Bus to RC2014 bus bridge and a hardware wired IEI/IEO daisy chain on U2 and U3. I haven't even yet produced a bridge to my own I/O bus cards. At some point, I may add sections with mode 2 interrupt lookahead on them and perhaps others with buffering on the main bus signals.

We are lucky that 40 pin long connectors just fit within the size limit of JLCPCB's low-cost PCBs. However, once you've handled boards with shorter pin header connectors, such as Z50Bus or my 2 x 20 pin I/O bus, you will dislike the 40/80 pin connectors even more. Shorter connectors are so much easier to remove but are still plenty stable enough. They also allow the option of narrower backplane PCBs or to free up real-estate for things like look-ahead logic. And did I mention how much less soldering is involved?  

If each major design, such as a motherboard, has one horizontal 80-pin bus connector on it, the modular backplane concept allows all sorts of options for mix and matching different designs and ideas. Now we just need to commit to that pinout :-)

If at some point we also adopt a higher quality bus connector, the modular backplane approach could be used to bridge old and new designs, and to allow some sections to use cheap pin header connectors.

Steve

[Bill Shen]

Eric,
I am very much in agreement with your observation that integration of memory with CPU makes bus for large memory space unnecessary. Take look at the RC2014 bus and you can see the middle 26 I/O pins (from A7 to D7, pin 9-34) is in fact the I/O bus. I have designed numerous single board computers interfacing just through RC2014's I/O bus. Since only 26 pins are needed for I/O bus, the remaining 14 pins of the RC2014 can be reused so the existing 40-pin RC2014 is adequate for my applications.
Bill

[Phillip Stevens]

Eric Matecki wrote:

The rationale behind my thinking are :

- the trend for CPU boards is to put memory on the same board anyway => no need for tons of address signals.

- a lot of I/O boards have only a few 8bits registers => 8 data signals and simple read/write signals.

I agree, and I think this is worth doing, and started a thread on I/O bus some time ago.

 

What will make this more complicated than it appears at first ?  Mainly data storage devices.

- CF works "better" in 16bits mode, but is quite useable in 8bits mode.

Indeed.

 

- DMA, where I have no experience, and no idea if possible at all in a generic way (mostly for floppies and IDE, but maybe also things like a sampled audio out+DAC ?)

The biggest advantage, imho, for IDE as an interface standard (and particularly the 2mm pitch 44 pin version, with power is integrated into the cable) is that there is a lot of existing cheap high quality cables in most people's junk boxes already. The connectors are quite inexpensive. This makes a neat connection.

There is already a RC2014 I/O board available that will support general purpose I/O interfacing with both 40pin and 44pin IDE connectors.

Cheers, Phillip

[Greg Holdren]

I think most people will be fine with all the memory with the CPU but there are others that want to experiment in the full address range with peripherals. myself would like to experiment with DMA and a video interface with a memory mapped frame buffer. That would be out to the A15 (pin1) mark but that's there now. The 68K has more bits of course.

Greg

[Eric Matecki]

I think most people will be fine with all the memory with the CPU but there are others that want to experiment in the full address range with peripherals. myself would like to experiment with DMA and a video interface with a memory mapped frame buffer. That would be out to the A15 (pin1) mark but that's there now. The 68K has more bits of course.

The I/O only bus will not solve all special cases.

DMA is probably not possible in a generic way (at least, without tons of glue logic on every board...or a programmable logic device).

But, as I said for the Z80, you can add a CPU specific connector (or even a whole bus) for these special cases.

Those boards will only work with that specific bus.

I don't think we can do much better than that by staying hobbyist friendly.

No need to redesign something as complex as a S-100 or VME bus, they already exists....

+-----------+ +------------+ +-----------+

| : : : : : |=| :          | |           |

| : : : : : |=| :  Z80   : |=| : : : : : |

| : : : : : |=| :  MoBo  : |=| : : : : : |

| : : : : : |=| :          | |           |

+---------+-+ +------------+ +-----------+

     ^^^     ^  ^  ^^^   ^  ^     ^^^                                                  Example

      |      |  |   |    |  |      +---------------I/O backplane                       (NEW design)

      |      |  |   |    |  +----------------------I/O extension (90°) cnx             (NEW design)

      |      |  |   |    +-------------------------onboard I/O cnx(s)                  (NEW design)

      |      |  |   +------------------------------Motherboard                         (NEW Z(1)80+memory+I/O bus logic+PSU)

      |      |  +----------------------------------onboard CPU specific cnx(s)         (RC2014 like, BP80)

      |      +-------------------------------------CPU specific extension (90°) cnx    (RC2014 like, BP80)

      +--------------------------------------------CPU specific backplane              (SC113)

All the connectors are optional, this represents a maximal system... and becomes physically quite large...

The "MoBo" can even have no CPU/memory/etc and have them on the CPU specific bus.

I can imagine a small PCB with just the I/O glue logic between an SC113 with all the RC2104 pro boards and a I/O backplane. (SC113=in fact the version with PSU whose number I don't remind, or add the PSU to the small PCB)

Or, sacrificing one or two slots on an SC113(with PSU)-like backplane, the glue logic can be fitted there with an I/O extension cnx.

Modular, backward compatible if desired, and can support special cases, improvable :).

[Alan Cox]

You need A15-A8 on the Z80 for I/O interfacing otherwise some devices rapidly run you out of I/O space. The quad UART I'm working on would otherwise need 32 I/O ports, and the WizNet in its fastest mode wants 256. The 40 pin RC2014 bus is basically the I/O bus except for most purposes.

Alan

[Eric Matecki]

You need A15-A8 on the Z80 for I/O interfacing otherwise some devices rapidly run you out of I/O space. The quad UART I'm working on would otherwise need 32 I/O ports, and the WizNet in its fastest mode wants 256. The 40 pin RC2014 bus is basically the I/O bus except for most purposes.

Alan

No problem with 16 address bits if they are needed. Assuming we use a 2x20 pin connector for ease of board insertion/removal, we have 40 pins total.

The RC2014 bus is too Z80 centric for general use with all CPUs. It has IOREQ, MREQ, M1, etc...

The I/O bus should abstract this by providing just a Read and a Write signal (or R/!W and 'strobe').

And several interrupt signals, again abstracted from any specific CPU.

We may well loose Z80 daisy-chaining of interrupts... this is way too Z80 centric.

(This doesn't mean we'll necessarily loose mode2 interrupts, but then we'll have to put a look-ahead circuitry on the Z80 MoBo).

All timings TDB... 

[Mark T]

I would expect processors without IORQ would still have some decoding on the processor card to generate an enable for a block of memory address space to be used for IO, so don’t really see a need to change the method of addressing on already existing modules, or existing Z80 processor modules.

It would be difficult to use z80 peripherals with other processors, but why not include the Z80 signals on the IO bus, with M1 and Rfsh pulled high for other processors. This would allow the z80 systems to use both z80 and non-z80 peripherals on the same bus.

There might be some advantage to sections of backplane, where an IO section would redefine A16-A23 as separate interrupts or other IO specific signals.

Mark

[Alan Cox]

On Monday, 26 August 2019 21:07:28 UTC+1, Mark T wrote:

I would expect processors without IORQ would still have some decoding on the processor card to generate an enable for a block of memory address space to be used for IO, so don’t really see a need to change the method of addressing  on already existing modules, or existing Z80 processor modules.

The 6809 and 6502 cards generate IORQ/MREQ this way. The 8085 has IO/M and decodes it into IORQ and MREQ. This works fine with the 8085 as you can make the bus timings look right. The 8088 I think you can, the 6502 is a bit of a different beastie and it's not friendly with a lot of the I/O cards as a result just due to timings.

 

It would be difficult to use z80 peripherals with other processors, but why not include the Z80 signals on the IO bus, with M1 and Rfsh pulled high for other processors. This would allow the z80 systems to use both z80 and non-z80 peripherals on the same bus.

This is what the CPU cards do today.

There might be some advantage to sections of backplane, where an IO section would redefine A16-A23 as separate interrupts or other IO specific signals.

Sounds an awesome way to confuse the hell out of newbies 8)

Alan