More Yellowstone Trouble
I did some surgery on the Yellowstone board, in an attempt to address major problems with power supply noise and data bus overshoot, previously discussed here and here. I replaced the 74LVC245 that drives the data bus with a 74LVC8T245. That’s a dual-supply chip that some readers suggested earlier: it ensures the bus outputs will drive all the way up to 5V, while hopefully reducing any noise coupled to the 3.3V supply, and avoiding the possible violation of limiting values with the 74LVC245 that I mentioned in my last comment to the previous blog post. The Yellowstone board still mostly works with the 74LVC8T245, but now the data bus overshoot climbs to a whopping 9 volts! Arrrrgh.
Channel 1 (yellow) is a copy of the Apple II slot’s /IOSELECT signal, passed through the FPGA. When it goes low, it means the Apple II wants the card to drive the bus.
Channel 2 (light blue) shows D0 on the data bus, with a nasty overshoot.
Channel 3 (pink) is an internal active-high debug signal from the FPGA that shows when it’s outputting a value for the 74LVC8T245 buffer. This is a sanity check on what’s happening.
Channel 4 (dark blue) shows the Yellowstone card’s ground, with respect to the Apple II system ground. Note there’s about 1V of peak-to-peak ground noise.
Something is badly wrong, and I can’t find it. I could design a new board with some series termination resistors, as a few people suggested, but my intuition is that isn’t really the main problem. None of the other Apple II cards I’ve examined appear to use any termination at all. 9V is a massive overshoot. And termination issues wouldn’t explain the problems observed on the card’s 3.3V power and GND supplies. I feel like I’m headed down the wrong path.
I’ll probably ice this project for a while, since enthusiasm for further debugging has run out. On to something else…
Read 9 comments and join the conversation9 Comments so far
Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.
Suspect your oscilloscope probe(s). A probe is not just passive, it is also a capacitive load and has a little bit of inductivity. So yes, a probe may resonate a little bit, especially if you feed it with sharp pulses.
Try measuring a working circuit (e.g. the Floppy Emu, or some Arduino). If you find overshooting there, it\’s very likely your probe, and you can ignore it.
Or, you could try to reduce the overshooting. Shorten the GND connections (your probe set should inclode a little ground spring to be used instead of the usual ground clip). Switch from 1:1 to 10:1.
I don’t think I can blame the scope probes, although I wish I could. The probe switch is at 10:1. Signal looks the same with the ground spring or the 3-inch ground wire. Substituting a different brand of probe gives a very similar picture; the overshoot appears as 8.something volts.
Even a 10x probe certainly can give you ground bounce like that. It’s basically what I would expect to see in a system like the Apple II where the ‘ground’ is just a bunch of traces (no plane, large inductance).
I previously posted how to build a probe that won’t produce those ground bounces. I find it common that folks think the expensive probes that came with the scope, set on 10x, will be better than something they could build themselves… that isn’t true. Showing the evidence has sometimes even failed to convince, it just can’t be true that their probes have been lying to them all along. But impedance and matching still always applies, no matter how much you pay for the probe or what name is on it.
Here is an article that describes this is more detail, and what results to expect: http://www.sigcon.com/Pubs/straight/probes.htm and a construction article for a Cadillac version of it http://emcesd.com/1ghzprob.htm and the quick and dirty 7GHz (!) version http://jahonen.kapsi.fi/Electronics/DIY%201k%20probe/
I’ve been thinking about the issues you’re having when I have some spare time, which sadly isn’t much these days. Please forgive me if I get some of the details wrong.
Here are the basic thoughts I’ve had:
Noise on the ground could be indicative of a ground loop. 1 V is a very significant amount, and could possibly lead to some logic errors. Your 3.3 V signal shooting up to 4.6 V could be the 3.3 V signal with that 1 V noise from the ground, depending on where your reference is and the timing. One thing I recall is that between a logic high and low, there is an ambiguous region. It’s not a hard line between the two. The noise may cause a signal to fall into that range, and different devices may interpret it with different results.
I did a quick Google search, and the site I found said that the Apple II bus was capable of sourcing 350 mA. Perhaps an aging power supply reduces that capability and which device is connected to which card exacerbates that. Though I would have expected it to be the issue when the Unidisk 3.5 is connected to Yellowstone, not the Floppy EMU. Unless the Liron card draws more power for the Unidisk 3.5 than the Floppy EMU. Yellowstone may be more capable of sourcing power to the Unidisk 3.5 and the Floppy EMU is less of a draw on the Liron card, when other cards are present and also drawing power from the bus.
Sulfur is a yellow stone, Hell is said to smell of sulfur. Perhaps you aptly named a project from hell….. I’m kidding, of course. I just thought a silly joke would cheer you up a bit.
I know they’re very basic thoughts for the problem, but that’s where I’d start looking. I figure those are the simplest explanations, and should be fairly simple to rule out.
Regardless, I love reading your blog and all about your projects. I recently rescued a sad Apple IIe that had been left in a garage with no cover and the case and display are covered in paint overspray. I’m looking forward to trying to resurrect it.
Sorry to hear this is on hold at least for now. I was hoping to get one of these cards… 🙁 Maybe inspiration will strike or you’ll find motivation to continue with it at some point in the future. I’m hoping for that.
Did you try to measure a different, working circuit that works at similar (or higher) speeds? FloppyEmu could be a good candidate. If you see overshooting in the working circuit, you can safely ignore them.
At work, I rarely use probes, just simple cables with a 2.54 mm header on one end and a 4 mm plug at the other end, connected via a 4mm to BNC adapter. No shielding, GND from somewhere via another flying wire. Of course, this setup picks up some noise and has some ringing at the edges of the signals. But I\’m rarely interested in the exact signal form, timing and order of signals is much more important to me. After all, I\’m working as a software developer, and our hardware team is very good at designing the hardware.
The effort isn’t dead, just resting. 🙂 I didn’t do any extra scope tests this time, but I’ve used this scope and these probes in the past with Floppy Emu and other projects. There’s often some modest ringing or overshoot observed, but I don’t recall ever seeing anything this severe. There are still unexplained functional problems with the Yellowstone card, so I don’t think the issue on the scope is entirely fiction. Although I suppose the functional problems could be due to a completely different cause.
Rather than worrying more about the scope now, or trying to build custom probes, I think my next step will be to design a version 1.1 board with improvements that *should* help. Or at least that can’t hurt. A bigger voltage regulator, bigger and better power traces, more careful attention to decoupling capacitors, option for termination resistors, better provisions for tapping internal signals for debugging, etc. Then I can see where things stand. But it’ll probably be a while until I’m ready to tackle that.
The overshoot looks rather bus-fighty to me. The data bus floating around and then suddenly snapping to high, with attendant ground bounce could easily be the sign of a bus fight.
The time period right around the rise of phi0 is prone to bus contention. The motherboard bus driver is always in tri state mode during phi1, but with the direction set to “out”, that is driving the slots. When phi0 begins, even though ioselect is asserted, the driver still has to turn around, which can take 50ns or so. This isn’t a problem for vintage hardware because it needs time to react to ioselect, but your card reacting in 5-10ns is just too fast, and you might be causing a bus fight.
Try delaying your driving of the bus by 150ns or so. The cpu doesn’t latch data until the falling edge of phi0, so you do have plenty of time. Read the IIe technical note #2, which is written for DMA but which gives the real truth about bus timing (since you aren’t doing DMA you don’t have to follow all those rules but the information is still useful!)
http://www.1000bit.it/support/manuali/apple/technotes/aiie/tn.aiie.02.html
“Most bus fights occur at the beginning of the CPU cycle…” about 80% of the way down. You should wait 155ns before driving the bus after the start of phi0. If you were making a DMA card you’d only have 50ns after that to drive the bus before the RAM needed the data, but since you aren’t, you have almost the whole remaining 330ns or so before phi0 falls. But surely you can meet those timing requirements with modern silicon…