EZ80 RCBus interfacing

[J.B. Langston]

Alan, I've started a new thread so we don't get too off topic from the z80ctrl NG in the original thread...

Some friends have been looking at this as part of an ez80 design. It's
really really hard to do. The 50MHz ez80 part doesn't leave you very
many nanoseconds to do memory and I/O decode and you also have a lot
of onboard I/O. To shift 5v/3v3 and allow all the I/O decode on the
cards time to work didn't seem doable short of having a high speed
GPIO interface waggling the bus in software (the same way ez80 or a
Raspberry PI is nailed to stuff like S100).

The EZ80 is 5V tolerant according to the datasheet so I don't think level shifting would be required as long as you are using HCT (or more likely ACT) parts.  I'm not sure if some of the retro chips like theTMS9918A and YM2149 would be happy with 3.3V as logic high, or if they would need the data lines to be buffered.

However we arranged it, we ended up with a rocket speed CP/M machine
with fast SPI and other interfaces that just didn't have any reason to
use RCbus devices. Video is easier with SPI, sound is easier with an
SPI DAC, extra serial is easier with a microcontroller over SPI and so
on. Adding the level shifters and the rest of it just made it slow,
bulky and expensive.

Yeah, that makes sense. I guess there's a reason the AgonLight is the way it is. My main complaint with the Agon is that I wish it used SPI instead of UART for the VDU interface.  The serial interface runs at over 1Mbps but it's still a pretty serious bottleneck for high throughput graphics manipulation.  

I also think the RP2040 would have made a better video chip than the ESP32, but maybe it wasn't around yet when he started designing it.  Someday I'll experiment with hooking my AgonLight2 to my RP2040-PICO-PC via the UEXT port and modifying the MOS to interface with it over SPI instead of the ESP32 over serial.

In the meantime I have bodged up my TMS9918 board to connect to the AgonLight's GPIO port (see attached photo), but I haven't worked up the courage to test if the EZ80 is REALLY 5V tolerant yet :).    It won't be software compatible because the code will have to write to the GPIO port instead of doing normal IN/OUT instructions directly to the bus, but I think I should be able to get my TMS9918 demos running on it without much effort.

I also threw together a quick design for an RCBus I/O adapter that I'll have manufactured if the TMS9918A experiment works out. It is a very simple interface. It will basically use the EZ80's Port C as the data bus and then the 4 available pins of Port D as control signals. You'll strobe the ADDR signal to latch the 8-bit I/O address from the port C, then set port C to the 8-bit value you want to read or write from to the selected address and strobe either RD or WR. There are also RESET and INT signals for cards that need it.  I've attached a schematic and 3D model.

[Sergey Kiselev]

On Wednesday, January 10, 2024 at 6:57:44 AM UTC-8 J.B. Langston wrote:

The EZ80 is 5V tolerant according to the datasheet so I don't think level shifting would be required as long as you are using HCT (or more likely ACT) parts.  I'm not sure if some of the retro chips like theTMS9918A and YM2149 would be happy with 3.3V as logic high, or if they would need the data lines to be buffered.

Most CMOS devices have clamping diodes on inputs, connected to GND and VCC, so the actual voltage the device sees would never exceed VCC + whatever the voltage drop on the diode is (0.3 - 0.6 V or so). The exception might be analog inputs, e.g. ADC or a comparator. See: https://www.ti.com/video/6276931683001

It is possible to test if there is a clamping diode. While applying the VCC, connect a 5V (4V if you feel unsure) power supply to the input through a current limiting resistor, e.g. 10k or so. And measure the voltage on the pin. If it is closer to VCC, then there are clamping diodes.

Even if the device is 5V tolerant, it might be not a bad idea to connect resistors between 5V outputs and the inputs, to limit the current on these clamping diodes.

As far as feeding 3.3V CMOS output to 5V TTL to NMOS, that should work just fine. CMOS has a narrower, 33% band for either logic high or logic low, so for 3.3V power supply, the minimal output voltage for logic high is about 2.18V, although, in reality it is often very close to 3.3V, while the minimal input voltage for logic high for TTL 5V ICs is 2V.

[Bill McMullen]

Having briefly looked at the rcbus issues, I fully agree with Alan's comments.  After designing and successfully building several eZ80 systems, I see a LOT of problems trying to put a 50 MHz eZ80 onto the rcbus.  In fact I believe you'd basically end up with an eZ80 SBC with CPU + memory + fast peripherals and a bus interface that would simply be I2C + SPI + some peripherals that MAY work with a lot of wait states or via GPIO pins.

While you may be able to interface a TMS99181A directly to an AgonLite's GPIO with it's eZ80F92 at 18.432 MHz, there are plenty of specification violations if you were to consider connecting it directly to a 50 MHz eZ80F91 or eZ80L92.  For example:

tPVX - data float from CSR going inactive = 100ns whereas eZ80 could put outputs on the data bus in 4ns after CSx\ going inactive.

tW(WL) - CSW pulse width of 200ns is greater than the maximum eZ80 CSx\ wait states (9 + 7*20) = 149 ns at 50 MHz.
tA(CSR)  - Data access time from CRS low at 150 ns pushes the boundary and likely exceeds maximum CSx\ from eZ80.

Any tristate buffers would only add further delays, although FET's might also work.  Regardless, the eZ80 and TMS9918A bus architectures are generations apart in their timing requirements.

There would also be software constraints such as trying to accomodate tW(CS-H1) pulse width chip select high, which is 8 us or up to 400 eZ80 instructions at 50 MHz.

[J.B. Langston]

OK, well I'm glad I brought it up before I went too far down this rabbit hole.  I will let you know the results of my experimentation driving the TMS9918 via the GPIO port. I think it should be doable since all pulse widths should be under software control.

[Talos Thoren]

I feel like making a fairly generic, SBC eZ80 board for the bus should still be a goal for the community, at large. A lot of this discussion seems to be about timing with the existing modules available on the market, but there's no reason to think we'd want to do that with a full speed eZ80. Rather, this would facilitate RCBus compatible peripherals designed for the eZ80 SBC.

While the bus may not have enough free pins to give us full access to both the data/address buses, necessary control lines, _and_ the full 32 gpio pins, it would still behoove us to create an eZ80 module for the bus, particularly given the recent discontinuance of the z80 and z180.

Just my thoughts on it, which are only half formed. I need to explore the eZ80 pinout more deeply before my opinion can mature on the matter.

- David

[Wayne Warthen]

Hi David,

Dean Netherton is working on an eZ80 CPU module for RCBus.  The discussion thread is here: https://groups.google.com/g/rc2014-z80/c/le0RpdAi1G4/m/aECfaXtoAAAJ

-Wayne

[Talos Thoren]

Thanks Wayne!

I'll start digging into this project right away.

Much obliged!

- David

--
You received this message because you are subscribed to a topic in the Google Groups "retro-comp" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/retro-comp/e7R4HK-0jrE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to retro-comp+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/retro-comp/47b601f0-10e7-4df6-b2e0-730e04988f37n%40googlegroups.com.