Proposing /IORQGE signal for RCbus-Z80

[Alexander Shabarshin]

Hello, retro friends!

I'm planning to build pretty complex device on top of RCbus-Z80 bus with multiple IO boards and existing straightforward IO address decoding (on many boards it's only partial decode when only a few address bits are used) may not be suitable in my case. I'm thinking about introducing /IORQGE signal into RCbus-Z80 ecosystem - let me explain.

Signal /IORQGE (IORQ Gate Enable) was a signal on original ZX Spectrum 48K (1982) edge extension interface that allowed peripheral device to disable internal computer IO response in some cases (effectively driving internal /IORQ up) - for example peripheral device wants to use some ports that are usually used by on-board computer hardware like alternative keyboard interface - or some port with more granular address decoding while internally ZX Spectrum uses very coarse few bits decode and it may inadvertently cover wider IO address range than needed. 

When in 90s ex-USSR engineers built a lot of very different ZX Spectrum clones out of discrete components they turned ZX Spectrum edge interface into extension slots on some of them that looked as ISA slots, but had pinout of ZX interface even though they added something and changed something that mostly broke compatibility with original ZX interface they called this interface "ZX-BUS" (but now many call it NemoBus to distinguish it from original ZX interface). And one of the changes was introducing kind of "daisy-chaining" for /IORQ signal - slots got priorities - if board in slot N responds to specific IO address request it sets /IORQGE to 1 that will disable /IORQ for the rest of the bus and all other boards starting with slot N+1 will ignore IO activity until board in slot N is done (also computer on-board ports should have lowest priority so if some of the boards recognizes some IO address then computer itself will not respond). In order to achieve that every slot had 2 OR gates on motherboard that implemented that smart gating logic. If some inserted board doesn't drive /IORQGE in its slot then motherboard logic will pull-down this signal from this slot to 0 that will allow further chain of /IORQ signals to work properly.

Why might it be needed in RCbus/RC2014 environment? For example if we take original serial ACIA module then we will see that it respond to any port number that match 10xxxxx0 and 10xxxxx1, so it is not only 0x80/0x81, but also 0xA0/0xA1 (and even 0xBE/0xBF). What if we need to use 2 ACIA interfaces simultaneously - let's say 0x80/0x81 and 0xA0/0xA1? We may design a new ACIA module that responds to full 8-bit IO-address as 0xA0/0xA1 for example and when it's doing this it will set its /IORQGE signal to 1 to disable /IORQ for subsequent boards and one of that boards even might be original ACIA board that will happily ignore 0xA0/0xA1 requests and will only respond to other bit combinations including 0x80/0x81.

So I can design new RCbus-Z80 backplane with /IORQGE logic on-board - question is which signal of RCbus I can use for it? For example I see IEI/IEO (daisy-chain of interrupt requests) took some USER signals in 1st row, and BAI/BAO (daisy-chain of bus requests) took 2nd and 3rd signals in 2nd row - p42 and p43. What if I take p41 to represent /IORQGE signal or it has to be one of the unused USER signals? Is there any RFC-process to assign new signals to "reserved" pins in RCbus specification? 

https://smallcomputercentral.com/rcbus/

Any thoughts? Thank you!

Alexander "Shaos" Shabarshin

http://www.nedopc.org/forum/

[Alan Cox]

On Sat, 22 Nov 2025 at 07:26, Alexander Shabarshin <ashab...@gmail.com> wrote:

Hello, retro friends!

I'm planning to build pretty complex device on top of RCbus-Z80 bus with multiple IO boards and existing straightforward IO address decoding (on many boards it's only partial decode when only a few address bits are used) may not be suitable in my case. I'm thinking about introducing /IORQGE signal into RCbus-Z80 ecosystem - let me explain.

It's a weird Sinclair era corner case so IEI/IEO was a bit different as it is widely used and part of the Z80 setup, whereas IOGE really has no relevance except to Sinclair and clones so just use a user pin for it as user pins were intended IMHO.

It's also horribly glitchy as a design although the logic ought to be fast enough that nothing wrongly responds I guess even at higher rcbus speeds.

I don't personally think IORGE belongs in the rcbus specification, although if you then make a bunch of cards that all use a given user pin as a convention for it then it would probably make sense to note that it is used that way by ZX Spectrum type cards as an informational note.

An rcbus-ish Scorpion/Pentagon style machine would certainly be an interesting use of rcbus.

Alan

[Tadeusz Pycio]

Hi Alexander,

The main objective of RCBus was to maintain full compatibility with RC2014. The proposed solution will not meet these objectives, as the existing modules will not be able to support such an extension.
I completely agree that the problem of incomplete decoding exists, but it is a remnant of the original. I also believe that handling address decoding by individual I/O modules is not the best solution, as it takes up a certain amount of space on the small PCB. The available space means that most designs use incomplete decoding as a compromise, which can be a problem for more complex builds.
I once intended to move decoding to the backplane, where each slot would have its own logical address that would enable setting physical I/O address decoding for individual modules and implement the PnP function. This solution required the use of 6 bus pins. Unfortunately, it is completely incompatible with existing solutions and would create a new standard.

[Alan Cox]

I once intended to move decoding to the backplane, where each slot would have its own logical address that would enable setting physical I/O address decoding for individual modules and implement the PnP function. This solution required the use of 6 bus pins. Unfortunately, it is completely incompatible with existing solutions and would create a new standard.

There is a path to do it with many cards. If you do the A7-A4 decode on the motherboard to generate IORQ RD and WR for the slot then you can assert 1100 on A7-A4 on the slot at all times and just set the cards to decode Cx. Any card specific to the PnP slot design would only decode A3-A0 and would not qualify IORQ/RD/WR itself, any card that is a classic card set to 0xCx would do a secondary pointless address decode which would only matter as a further propagation delay - and most cards have plenty of slack at 8MHz.

I've pondered doing this as a way to produce convenient 1 or 2 chip mini-cards with a smart backplane without breaking compat. You'd still need some conventional slots for the RAM, CPU and any DMA etc that used all the pins.

Alan

 

[Tadeusz Pycio]

Hi Alan,

Yes, that makes sense and is possible without significantly compromising the existing standard. 
When I mentioned PnP, I meant that the system knows which module is in a given slot thanks to a small 24xx EEPROM memory on each module. Something similar to a PCI signature, class, device, capabilities...

[Laszlo Szolnoki]

In my designs, I use the signals !IODI, !MEMDI, and !RDY, IO-, MEM- disable, and IO device ready. All are OC. I have placed these on the RCBus Z80 pins USR4/!IODI, USR8/!RDY, and P79/!MEMDI.
A superuser can now disable IO or MEM devices, which greatly simplifies testing or cascading. It also provides more flexibility when dealing with complex designs.
When it comes to addressing RC2014 devices, I generally do not prefere/like the current addressing style with ambiguose address allocation and use instead always exact addressing. This may sometimes require more ICs, but in most cases it avoids address conflicts. I prefer to use PLDs such as ATF16V8 or ATF22V10 for addressing.
With this implementation I think I still comply with the spec nevertheless have much more flexibility.
Cheers

Laszlo