I need help with the CF interface.

[Tadeusz Pycio]

I need help in selecting a better solution for the CF interface. I am missing one OR gate and the following attempts to work around this problem.
1. incomplete address decoding or using diode logic (I don't know if delaying the /IOWR signal through the gate makes sense for a /CE0 signal controlled by /IORQ)

2. direct connection of the /WR line to the /IOWR input, because here I am sure that the device selection is complete.


CF cards have their specific needs and /IORD delay is required. Which option would you choose? Maybe some other ideas?

[Phillip Stevens]

1. incomplete address decoding or using diode logic.

The 744078 8 input OR gate is useful to eliminate address ghosts, without diodes loading the address lines.

Used one on my UX Module to minimise the number of address lines being handled in the processor. 

https://github.com/feilipu/ux_module

P.--

Sent from a Mobile Device. Replies may appear terse.

[Tadeusz Pycio]

The 744078 8 input OR gate is useful to eliminate address ghosts, without diodes loading the address lines.

In the example shown, the 74HCT138 decodes more devices, I have removed these connections to improve readability. I can't change to 744078 in this case, and I don't want to use GAL16V8 which would solve all the problems.

The output at address 0x10 controls the /CS0 input of the CF card, the schematic does not show this.

[Steve Cousins]

My solution delays both RD and WR. See attached.

I don't like diodes and resistors loading bus lines. Given that your 138 decodes other devices your hands are rather tied.

Steve

[Bill Shen]

What other devices are driven by your 74HCT138?  Do they require ~IORQ qualification? 

There are two issues with schematic 1 & 2:
1.  ~IORD signal to CF interface needs to be filtered with 100ohm resistor/100pF capacitor network to reduce the effect of ground bounce.
2.  The setup time from ~CF asserted to ~IORD or ~IOWR asserted is too short in schematic 1  (just one HCT32 gate delay).  In schematic 2, ~WR is likely asserted before ~CF is asserted which is bad.

Ideally you want to do what Steve Cousins did, i.e.,remove ~IORQ from 74HC138 so to generate ~CF as soon as addresses settled (I would also connect ~M1 to pin 6 of 74138) to give plenty of setup time before assertion of ~IOWR and ~IORD.  The OR gate combining ~IORQ and ~CF is not necessary (unless 74138 is extremely slow, ~CF will always be asserted when ~IORQ is asserted); just connect ~IORQ to ~WR to generate ~IOWR and ~IORQ to ~RD to generate ~IORD.  Be sure to insert a 100 ohm resistor and 100pF RC network in line of ~IORD.

However, if your other devices driven by 74HC138 require qualification by ~IORQ, then the solution of above paragraph won't work.
  Bill

[Steve Cousins]

Attached is my solution for the Z50Bus.

Steve

On Tuesday, 5 July 2022 at 09:29:23 UTC+1 Tadeusz Pycio wrote:

[Mark T]

As you are qualifying both RD and WR there is no need to qualify M1. You could try connecting MREQ to pin 6 of the 138 and use pin 4 and 5 for A6 and A7.

This does give a risk of race hazards at the beginning of memory read cycles, so might need to be verified on actual hardware.

[Tadeusz Pycio]

Looking at the CF specification and the Z80 time waveforms in the I/O read cycle, this problem is not related to our attempts to delay the /IORD signal, but more to the skipping of the /OE signal for CF cards or as Bill rightly pointed out the extension of the /CE signal relative to /IORD.

In our designs, the rising edge of the /IORD and /CE signals occur at the same time. I will try to shorten the /IORD signal with the falling edge of the clock in cycle T3.

[Steve Cousins]

"In our designs, the rising edge of the /IORD and /CE signals occur at the same time"

That's why I don't include /IORQ in my /CE circuit. /CE is then enabled for as long as the address is stable (nearly half a clock cycle after /RD goes high)

Steve

[Tadeusz Pycio]

That's why I don't include /IORQ in my /CE circuit. /CE is then enabled for as long as the address is stable (nearly half a clock cycle after /RD goes high)

Steve you are right, in your project the /CE signal takes longer, I used too much abbreviation. 

My list of missing elements is growing dramatically. :)

[Bill Shen]

In CPLD I have the luxury of adding flip flop to delay the generation of CF write and read strobes.  In the few TTL logic based designs, I tried to assert the CF chip select as early as possible and negate it as late as possible, but qualify CF's write and read strobes with IORQ so to provide adequate setup and hold time.  Many brands of CF disk do not need the specified setup/hold time so you can generally find a few CF disks that will work even with significant violation of the setup/hold time.
For your reference:
CF interface for RIZ180:
https://www.retrobrewcomputers.org/lib/exe/fetch.php?media=builderpages:plasmo:riz180:riz180_rev0_scm.pdf

CF interface for Simpe80:
https://www.retrobrewcomputers.org/lib/exe/fetch.php?media=builderpages:plasmo:simple80:simplecf_scm.pdf

[Tadeusz Pycio]

The result of our discussion currently takes this form, there are some simplifications and probably errors that I need to correct. I drew it up quickly. The design was intended to be simple.

[Tadeusz Pycio]

Revised version with working ROM switch. I don't know why I previously decided to use the JK Flip Flop...

[Tadeusz Pycio]

Minor tweaks and it's time to test it in the real world, which is how this project was sent to production. Thank you Steve and Bill for your helpful comments.