RCBus signals

[Tadeusz Pycio]

I have a question if anyone knows of any RCBus/RC2014 module that uses the Refesh signal located on the bus? It might be worth thinking about its alternative use for the address latch signal (ALE) for processors with multiplexed data and address bus (8085, 8051, NSC800)? Such a change enables direct use of peripherals designed for such a CPU bus.

[Alan Cox]

On Sun, 6 Jul 2025 at 11:55, Tadeusz Pycio <ta...@wp.pl> wrote:

I have a question if anyone knows of any RCBus/RC2014 module that uses the Refesh signal located on the bus? It might be worth thinking about its alternative use for the address latch signal (ALE) for processors with multiplexed data and address bus (8085, 8051, NSC800)? Such a change enables direct use of peripherals designed for such a CPU bus.

There are a bunch of problems with using it for ALE including the fact that processors don't agree on the timing, direction or even which pins are multiplexed. 65C816 for example it's going to provide you A23-A16, some processors it will switch between address/data and others it will switch between A7-A0/A15-A8.

I did ponder putting ALE on a user pin for 8080/85 when I did the boards as it wouldn't be hard and it could overlap the E and RW usage as the 680x/HC11 whilst multiplexed really needs the lines buffered on the CPU card anyway to avoid ground bounce problems.

I don't know of any cards using \RFSH though and I think only the classic Z80 card even reliably provides it as the Z180 boards turn it off on boot up. As a CPU specific weirdness I just don't see why you'd put it anywhere but a user pin. Certainly none of my other CPU cards generate \RFSH and I've never met anything that even connected it.

It's also really easy to interface a muxed bus expecting device to the standard rcbus in most cases, and then everyone can use it. Both the PC style RTC and the 80 column video card actually use chips that expect a multiplexed bus (but not quite the same one) and both work with any CPU card because they handle it on the card instead.

Alan

[Tadeusz Pycio]

Hi Alan,

Yes, adapting the multiplexed CPU bus to RCBus is commonplace, I was more concerned with enabling I/O chips that require such a signal (8155, 8256, NSC810). The chips in question are architecture specific anyway, so their use with other processors will not work together. It is true that for a given processor family the ALE signal has a different application and even polarity, e.g. /AS for the Z8000, but in a compatible configuration it will enable them to work. In addition, I don't see the point of keeping the /RFSH signal on the bus, as presumably no one is going to use hard-to-find DRAM.

[Bill Shen]

ZRC is a RC2014 compatible SBC using 2-meg DRAM as its memory; rev2 of ZRC uses SIMM30 module as memory.  They need the Z80 refresh signal to start the refresh cycle, but since it is a SBC, the signal comes directly from the Z80 onboard instead of the bus signal.  /RFSH signal may be needed if people want to design with cheap DRAM-based RC2014 memory boards.

Bill

[Alan Cox]

On Sun, 6 Jul 2025 at 13:27, Tadeusz Pycio <ta...@wp.pl> wrote:

Hi Alan,

Yes, adapting the multiplexed CPU bus to RCBus is commonplace, I was more concerned with enabling I/O chips that require such a signal (8155, 8256, NSC810). The chips in question are architecture specific anyway, so their use with other processors will not work together. It is true that for a given processor family the ALE signal has a different application and even polarity, e.g. /AS for the Z8000, but in a compatible configuration it will enable them to work. In addition, I don't see the point of keeping the /RFSH signal on the bus, as presumably no one is going to use hard-to-find DRAM.

Because it makes rc2014 a strict subset of rcbus. Also if the line is different  for each processor and application and that is *why* we have user pins and also why we've got user pin usages for particular CPU families as appendices in the spec. No need to mess up rc2014 compatibility.