Welcome, Guest. Please login or register.


Author Topic: Glitch on /RD (Read 18064 times)

Offline BruceTanner

  • EP lover
  • *
  • Posts: 609
  • Country: gb
Re: Glitch on /RD
« Reply #15 on: 2015.December.17. 23:32:56 »
I haven't had time to do much more on this over the last 2 days (at the weekend hopefully...), but I thought I'd try my EXDOS card on my "bad" EP64:

[ Guests cannot view attachments ]

The yellow trace is the /CE signal on the WD1770 :shock: The purple trace is the z80 /RD signal. The blue trace is the WD1770's R/!W, high=read, low=write (so this is a read cycle).

So contrary to what I said previously, the /RD glitch does get as far as the WD1770, on my EP64 anyway.

But it still works!

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14779
  • Country: hu
    • http://enterprise.iko.hu/
Re: Glitch on /RD
« Reply #16 on: 2015.December.18. 07:54:11 »
But it still works!
Probably the old components need more time for recognize the signal changes. The Wiznet are modern and too fast :-) then it is can react for this spikes.

Offline BruceTanner

  • EP lover
  • *
  • Posts: 609
  • Country: gb
Re: Glitch on /RD
« Reply #17 on: 2017.September.26. 16:36:02 »
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 :lol: 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! :shock: :shock: :shock: 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.

*** The Fix ***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? :lol: ). 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 :lol: - I think this is what the whole of the EP operation depends on! :shock:

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! :lol: 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! :lol: (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! :lol: :lol: :lol:

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! :shock: :shock: :shock: So I use a LS245 on EPNET :ds_icon_cheesygrin:

Sorry for the long post!

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14779
  • Country: hu
    • http://enterprise.iko.hu/
Re: Glitch on /RD
« Reply #18 on: 2017.September.27. 09:14:56 »
Thanks! Very interesting!

Offline pear

  • EP lover
  • *
  • Posts: 825
  • Country: pl
  • Z80 only
    • Támogató Támogató
Re: Glitch on /RD
« Reply #19 on: 2017.September.27. 14:04:58 »
Bruce, did you try to use ferrite beads through the /RD line instead of the RC filter ?

Offline BruceTanner

  • EP lover
  • *
  • Posts: 609
  • Country: gb
Re: Glitch on /RD
« Reply #20 on: 2017.September.27. 14:33:45 »
Bruce, did you try to use ferrite beads through the /RD line instead of the RC filter ?
No I didn't, I just copied the original EXDOS fix but applied it wider (ie. to more signals than just /RD, and to more components than just the ROM).

Would there likely to be an advantage over using a RC filter?

Offline pear

  • EP lover
  • *
  • Posts: 825
  • Country: pl
  • Z80 only
    • Támogató Támogató
Re: Glitch on /RD
« Reply #21 on: 2017.September.27. 14:46:41 »
They occupy less space. Besides, I did not try, hence the curiosity :)

Offline gflorez

  • EP addict
  • *
  • Posts: 3615
  • Country: es
    • Támogató Támogató
Re: Glitch on /RD
« Reply #22 on: 2017.September.27. 14:53:23 »
I think, it can be interesting to try them if the signals aren't delayed, but I do not have the knowledge.

Offline BruceTanner

  • EP lover
  • *
  • Posts: 609
  • Country: gb
Re: Glitch on /RD
« Reply #23 on: 2017.September.27. 14:56:25 »
To be honest talk of ferrite beads takes me out of my "comfort zone" - I would have no idea how to calculate the sort of value I need. But as they are cheap I might have a play for my own education. :) Thanks for the suggestion!

Offline gflorez

  • EP addict
  • *
  • Posts: 3615
  • Country: es
    • Támogató Támogató
Re: Glitch on /RD
« Reply #24 on: 2017.September.27. 14:58:22 »
Pear can aid you calculating...

Offline pear

  • EP lover
  • *
  • Posts: 825
  • Country: pl
  • Z80 only
    • Támogató Támogató
Re: Glitch on /RD
« Reply #25 on: 2017.September.27. 18:42:05 »
Impedance of ferrite bead grows with frequency.
We are interested in a frequency in the range of 1 to 2.5 MHz (for CPU clocked from 4 to 10 MHz).
As I wrote, I have not tried this solution yet. Need to do a trial.
Ferrite beads have two impedance values: for 25 and 100 MHz. If more steep growth then better.

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14779
  • Country: hu
    • http://enterprise.iko.hu/
Re: Glitch on /RD
« Reply #26 on: 2017.October.01. 20:48:40 »
Bruce! Where you added the capacitors to the MICROTEAM card? On the external (coming from the machine) RD/MREQ or on the internal signals (after the IC13A, IC12B)?

Offline BruceTanner

  • EP lover
  • *
  • Posts: 609
  • Country: gb
Re: Glitch on /RD
« Reply #27 on: 2017.October.01. 21:01:07 »
I added them on the external /RD and /MREQ - because it was temporary for me and this was an easy place (there is a suitable ground point right near where /RD comes in :ds_icon_cheesygrin:). But a better permanent fix would be on the internal signals so you're not actually changing the EP's signals! Also you might need one on /IORQ if you're going to use the floppy interface - I was just trying it to see if it fixed the RAM test failures (it did!).

I will be very interested to know if it works for you! :)