Enterprise Forever
:UK => Hardware => Maintenance => Topic started by: BruceTanner on 2015.December.15. 13:45:26
-
Here's a trace taken on an EXDOS card plugged into the expansion port of a standard EP128:
[attachimg=1]
The purple trace is /RD and the blue trace is the same signal after it has passed through an OR gate (other input tied low) on the EXDOS card. The dotted horizontal line is at 0.8v - the "0" to "1" threshold for LS TTL.
Here's the same signal, /RD, on my EPNET card (different timebase on 'scope though):
[attachimg=2]
Just wondered if anyone else has seen this before?
B.
-
Just try:
- to add decoupling capacitor between pins 7 and 14 the OR gates IC,
- replace the whole IC to another producer (or even from another series).
Sometimes it helps.
-
Thanks Pear.
The OR gate I mentioned is on the EXDOS disk card - nothing to do with me! My guess is that Dave Woodfield who designed the EXDOS card (and Dave chip) knew about the glitch, which is why it is buffered by the OR gate and it comes out smaller. It then goes through a NAND gate and comes out even smaller (and inverted). It does make it as far as the WD1772 floppy controller chip but (as far as I have seen) only when the chip is not enabled, but my scope can't trigger on that condition.
I see exactly the same glitch with my EPNET card but it happens when the network module is enabled so I get a double read, which matters particularly because it has an auto-incrementing register. I've played around a lot with decoupling and improving the power supply tracks but with no change.
I don't see it with nothing plugged into the side connector though. I don't have anything else to plug in and try, which is why I wondered if anyone else had seen it with different hardware. I can work around it, just need to be sure I'm not causing it!
-
What you see in pure EP128? For example on the internal memory expansion card.
-
What you see in pure EP128? For example on the internal memory expansion card.
It is there, but smaller, 0.6v. Needs to be 0.8v to count as a "1".
[attachimg=1]
Some pretty nasty noise on "high" too, but doesn't quite go low enough to actually matter:
[attachimg=2]
These measured on the edge connector fingers but with nothing plugged in.
-
That estrange noise on /RD comes from the EP internals?
I think I have the same problem on my EP, as some expansion cards don't work totally "round" when attached to it.
One is my Microteam EXDOS clone and the other is Pear's Spectrum emulator clone.
-
Zozo has found that some Z-80's on other EP's act the same as mine. This can be your problem.
-
And I have some motherboards which not work with expansions at all. These waiting for more investigation :oops:
-
Bruce! Your another machine (EP64) also producing same?
-
Out of curiosity, I check in my EP.
I do not know if I have enough accurate and fast measurement equipment (20 MHz USB adapter), but I'll try (at weekend).
On all 3 of my EPs, all my extensions work without a problem.
But if such a problem exists in other EPs, I'll have to somehow prepare for him.
Maybe FlexiBridge buffers (ACT245) are sufficient and therefore I did not have this problem ?
-
Unmodified EP64 with BASIC cartridge (but the -12v has broken again, I'll mend and re-check):
[attachimg=1]
:shock:
It's not in quite the same place but there's definitely a spike there! And the downwards one is only 0.1v away from hitting the "low" threshold.
Pear: it's only occasionally so you might not see it if you just look at /RD. I am lucky, my 50th birthday present to myself last year was a new scope, and it can trigger on upwards or downwards glitches, that is how I first saw it. I have a borrowed expansion bus with LS245s etc, and the /RD glitch gets through those.
On the EXDOS card the spike is reduced by passing it through an LS gate; on my card using HCT that seemed to make it worse, turning a little spike into a full low-high-low glitch.
I only noticed it because the network module has an auto-incrementing register and I was missing bytes sometimes. I sat in a loop reading the fixed ID register and it read back the correct value every time for over an hour, even with the glitches. So depending on your h/w you might not notice any symptoms.
My "fix" at the moment is to pass /RD through a schmitt trigger.
-
My "fix" at the moment is to pass /RD through a schmitt trigger.
And no better backward connected Schottky diode with pull-up after it ?
It's reduce the levels of approx. 0.2 V to next gate.
-
And no better backward connected Schottky diode with pull-up after it ?
It's reduce the levels of approx. 0.2 V to next gate.
Will try that, thanks for the suggestion, would save a chip! :)
I can now confirm if I just let the scope free run and press "stop", every few stops I can see a glitch, 1uS timebase
-
Other signals (WR,IORQ,MREQ) also have the problem?
but the -12v has broken again, I'll mend and re-check
Did you replaced the C9 at the latest repair?
-
Other signals (WR,IORQ,MREQ) also have the problem?
Did you replaced the C9 at the latest repair?
Ah em...it turned out I still had the monitor brightness turned down to 0 after I was taking photos a few weeks ago and for some reason my EP64's ouput is much darker than my 128's :oops: :oops: :oops: :oops: :oops: :oops: :oops: :oops: !!!
I can see the glitch on /WR, /IORQ and /MREQ but they are much less...too small to cause any harm. But the /RD spike is so big on the EP64 that it triggers my schmitt trigger gate "fix", so turning a spike into a big glitch with nice square corners :roll:
-
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:
[attachimg=1]
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!
-
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.
-
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:
[attachimg=1]
Yellow is the z80 /RD, cyan is after passing through a LS gate, and blue is after glicth suppression.
Now HCT:
[attachimg=2]
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:
[attachimg=3]
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:
[attachimg=4]
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!
-
Thanks! Very interesting!
-
Bruce, did you try to use ferrite beads through the /RD line instead of the RC filter ?
-
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?
-
They occupy less space. Besides, I did not try, hence the curiosity :)
-
I think, it can be interesting to try them if the signals aren't delayed, but I do not have the knowledge.
-
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!
-
Pear can aid you calculating...
-
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.
-
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)?
-
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! :)