Wow! It's been nearly 2 years since I first saw glitches on /RD, so here's an update with my current knowledge about it, finishing with a fix!
1. All EPs have some glitches on /RD but they are often too small to cause a problem. The glitches need to be >0.8V to cause a problem.
2. EP64s with ISSUE 4 PCBs are the worst offenders and often do not work with add-ons like the Microteam card.
3. zozo has seen a couple of ISSUE 6s which also do not work with add-ons.
4. Although /RD is the main glitchy signal, on a "bad" EP64 some other z80 signals glitch too, eg. /MREQ, /IORQ and even address lines.
5. Original EXDOS cards are better than most add-ons but even so some ISSUE 4s do not work with EXDOS cards.
6. Some EXDOS cards (~10% ?) have a glitch-suppressing resistor and capacitor on /RD going to the EPROM. This is a factory-fitted mod: they are all identical and professionally done. There are two revs of EXDOS PCBs: ISS 1 and ISS B
and the mod has been seen on both versions. Maybe done when returned by the customer as "faulty"?
I have found modern 74HCTs logic worse than 74LS at handling glitches (ie. a glitch on HCT inputs causes a bigger glitch on the output than with LS). Here's an example, first with LS:
[ Guests cannot view attachments ]
Yellow is the z80 /RD,
cyan is after passing through a LS gate, and
blue is after glicth suppression.
Now HCT:
[ Guests cannot view attachments ]
Here
cyan is after passing through an HCT gate instead of LS.
Not every /RD cycle on the EP has a glitch, but every /RD cycle to EPNET does:
[ Guests cannot view attachments ]
Purple is EPNET's enable signal to the LS245 ie. it starts driving the EP's data bus.
What I have noticed is that the glitch seems to be caused by enabling the LS245! It always starts just after _CEN, and is always there as far as I have seen. Other EP /RD cycles, not to EPNET, have the glitch in various places within the /RD cycle, quite possibly just as they too start driving the data bus.
Now if you drive the '245 with a nice clean signal, you just get one short, sharp glitch on /RD as above. But most designs add-ons /RD to control the direction that the '245 is driving in, and also as part of memory decoding. So I think what often happens is: output is enabled, a /RD glitch occurs, the /RD glitch briefly stops the '245 driving the bus but then starts again, so causing another /RD glitch...oscillation!
I have seen this in the past:
[ Guests cannot view attachments ]
Here
cyan is /RD.
This is a particularly bad example, often I have seen 2 or 3 cycles of oscillations getting smaller each cycle.
I now have EPNET working fine on a "bad" ISSUE4 EP64, with one of its RAM segments in page 0 and an interrupt routine in ROM, so plenty of cycles!
I apply the same fix as the EXDOS mod, but to more than just /RD, and to everything on the card, not just the ROM. The fix is a resistor inline with the signal, followed by a capacitor to ground, forming a low-pass filter (who said this was digital electronics?
). The EXDOS fix uses a 75R resistor and a 220R capacitor, but as 75R is a strange value I have been using 100R and 220pF successfully.
So /RD and /WR first pass through a LS OR gate, then the de-glitching, and then another OR gate to ensure a sharp edge. This is passed to ROM, RAM, the network module, the Compact Flash interface and of course the '245.
There are two lots of memory decoding: one for I/O addresses and one for memory addresses. Rather than de-glitch every z80 signal there is one set of de-glitching on the output of each of the address decoders so that the /CS signals seen by everything on the card including the '245 is clean. Thus if there are glitches on the address lines this won't affect the '245 so won't cause more glitching, but might be seen by the memory. Hopefully by the end of the /RD cycle when the z80 samples the data bus the glitch will be over and the output stable
- I think this is what the whole of the EP operation depends on!
My original problem long ago was that the network module saw 2 reads due to the glitch, but now both /RD and /CS is deglitched this does not happen.
As I used a higher value of resistor than the EXDOS mod, I thought I would see how low a value I could get away with. The answer: 0!
Using no resistor, there is still a small glitch present but <0.8V.
But this means it would be easy to apply to other add-ons such as the Microteam card: it is far easier to just solder a capacitor to ground than to cut PCB tracks etc to put a resistor inline with the signal. So with my "bad" EP64 and a non-working Microteam card I tried a 220pF capacitor on /RD and it still did not work. I added another on /MREQ and then everything worked!
This isn't a great long-term solution because it is modifying the z80 signal itself, it really needs to pass through a buffer first. If 2 cards did this there would be 440pF on the signal...but experimentally I have had 1000pF AND 100R on /RD and it still worked!
(at 4MHz anyway!). So for EPNET I am sticking with a resistor and capacitor. I do not yet know if it works at 8MHz or 10MHz.
It might even be possible to "fix" a "bad" EP64 this way but I haven't tried it on mine because a "bad" EP64 is useful to me for EPNET testing!
Finally on the subject of '245s: HCT is a CMOS technology and a big no-no with CMOS technology is leaving inputs floating - the inputs are very high impedance and can pick up all sorts of noise, including internally, leading to oscillation and even chip overheating. So what happens if you connect a HCT245 to a tri-state data bus? The inputs are left floating when everything on the bus tri-states!
So I use a LS245 on EPNET
Sorry for the long post!
