BMOW title
Floppy Emu banner

Yellowstone Glitch, Part 6: This Is Getting Ridiculous

Driving 11111111 from RAM through the ‘245 onto the data bus is causing trouble. I can see this clearly – other chips begin to glitch the moment the ‘245 is enabled. But driving 11111111 from the FPGA through the ‘245 onto the data bus is apparently OK, and driving other values from RAM is also OK. I can’t explain why. I’ve added extra wires from the power and ground pins of the ‘245 and the RAM directly to the voltage regulator, and added extra bypass capacitors, all in an attempt to satisfy the rush of current. It’s still not behaving how I’d expect.

During a bus cycle, first IOSTROBE goes low, then about 140 ns later the ‘245 is enabled for output. The bus cycle ends after 500 ns when IOSTROBE goes high. I finally captured some oscilloscope traces of a bus cycle when RAM outputs 11111111, and it doesn’t look good. All of the traces shown here are referenced to a ground point on the Apple II motherboard. As mentioned previously, some of the over- and undershoot seen on the scope may be due to my poor probe setup, rather than the signal itself.

  • Blue (Ch4) is address line A1. It’s a 5V input from the Apple II, and it shouldn’t be changing during this bus cycle.
  • Yellow (Ch1) is the 3.3V supply voltage, measured at the VCC pin of the ‘245.
  • Cyan (Ch2) is IOSTROBE, and marks the boundaries of the bus cycle.
  • Pink (Ch3) is the GND voltage, measured at the GND pin of the ‘245, relative to the Apple II motherboard.

When IOSTROBE first goes low, the RAM is enabled and begins drawing 85 mA, but nothing else happens. This causes some small noise in the 3.3V and GND supplies, but nothing terrible. Then after 140 ns when the ‘245 is enabled, all hell breaks loose. There’s major oscillation on the 3.3V and GND supplies, with a period of 20-30 ns, lasting about 100 ns. But what’s really puzzling is the noise on A1! This is an input coming from the Apple II, off-board, so it shouldn’t be affected by power supply problems local to Yellowstone. It also shows a major erroneous spike when IOSTROBE goes high and the bus cycle ends. This is the moment when both the ‘245 and the RAM are disabled. What the hell?

Compare this to a bus cycle reading 11111111 from ROM (the FPGA) instead of from RAM:

When the ‘245 is enabled, the noise on the 3.3V and GND supplies isn’t nearly as bad as before. But the noise on A1 is still very bad.

Here’s an example of reading 00000000 from RAM:

And reading 00000000 from ROM (FPGA):

In all four cases, I captured many bus cycles and used the example that looked worst. Many of them looked mostly fine. I still think it’s important what residual value is remaining on the bus capacitance from the previous bus cycle – some residual values cause trouble and others don’t.


What have we learned from all this? First, there’s some problems no matter what value is driven, and no matter what the source. It’s just that 11111111 from RAM is the worst, but even 00000000 shows problems. Second, my addition of extra power and ground wires and extra bypass capacitors clearly hasn’t prevented some major signal integrity problems whenever the ‘245 is turned on, and when it’s turned off. I’m unsure if it’s due to violating the maximum output voltage of the ‘245, or just due to a large but expected amount of current flowing and stopping. The fact that signal problems occur when the ‘245 is turned off as well as when it’s turned on makes me think it’s probably just large but expected current flows.

The real puzzler is what’s happening with A1. How could a problem with the Yellowstone board affect a signal input from the Apple II?

One possibility is Yellowstone’s PCB routing. All eight of the data bus output traces cross under the traces for address lines A0 to A6. Here you can see the eight red data bus traces coming from the left, passing through vias and terminating at edge connectors on the back of the PCB. Address lines A0 to A6 are the red traces coming from the top and terminating at edge connectors on the front of the PCB.

Maybe when all eight data bus values change at once, the combined change in electric field is enough to influence the address traces on the opposite site of the PCB. Maybe. But I’ve also seen similar noise on other Apple II inputs like IOSTROBE, whose traces are far away from the data bus traces.

Another possibility is that the Apple IIgs is actually the culprit, and it can’t handle the current spike without problems. The sudden current causes weird behavior on the logic board, creating major noise on the peripheral input signals. This might also explain why 11111111 from RAM is worse than 11111111 from the FPGA, because the RAM draws extra current when it’s enabled, so the total current consumption of the board will be highest when RAM is enabled and the ‘245 is outputting all 1 bits. But if the IIgs were choking on the current, I would expect to see weird bugs and lockups, and I haven’t.

No matter what, the clues seem to be pointing towards a solution of reducing the current through the ‘245. My trick of pre-driving 10101010 does this, but there must be better ways. I’ll try some other logic families besides 74LVC that still work for 3.3V to 5V level translation, but with slower slew routes and a reduced peak current. I need a 3.3V chip with 5V tolerant I/Os but slower, softer-driving outputs than 74LVC. Failing that, I’ll keep the 74LVC245 as the bus driver, but add series resistors to the data bus traces in order to limit the current.

Read 12 comments and join the conversation 

12 Comments so far

  1. John Payson - June 19th, 2021 2:29 pm

    Is IOSTROBE specified to be released before any address lines change, or is IOSTROBE generated from address lines (which might change in unspecified order) in the expectation that boards will use the falling edge of phi2 to recognize the end of a cycle?

    If the RAM is remaining active while the address line changes, that could cause weirdness at the end of a cycle, but it might be possible to mitigate that by enabling the RAM for only part of the cycle while the address bus is valid. If your FPGA has bus-keeper circuits, simply enabling the RAM long enough to get a valid value onto your internal bus and disabling it before the address changes should be a simple way to prevent problems.

    Otherwise, if the address inputs can change at the tail end of a bus cycle while the RAM is still enabled, that could easily cause wackiness if the changing addresses cause the RAM to change what data it’s outputting.

    Do you have a schematic of your board anywhere I could look at?

  2. rasz_pl - June 19th, 2021 3:05 pm

    Monitor Apple 5V instead of A1, 2V overshoot on purple trace does look weird.
    I will sound like a broken record :), but lift vreg and power yellowstone pcb with external 3.3V lab/ATX supply. Hell, try powering Apple with external 5/12V.

    Maybe 3.3V regulator is keeping up, but loading Apple 5V supply too much? Could you try powering it from 12V instead? or add capacitance in front of 3.3 reg.

  3. hmn - June 19th, 2021 5:09 pm

    Wouldn’t a >1V difference between two GNDs (pink trace) indicate a problem with grounding?

  4. Steve - June 19th, 2021 9:29 pm

    IOSTROBE is released when 6502 phase 1 ends, so the address lines aren’t changing during output.

    I don’t have a schematic online for the current Yellowstone version, but the relevant parts for this glitching problem are virtually identical to the original version here: The layout is updated, however.

    > Monitor Apple 5V instead of A1

    Good idea, I checked and there’s about 900 mV of peak-to-peak noise on Yellowstone’s 5V input at the time when all the other noise occurs.

    > I will sound like a broken record :), but lift vreg and power yellowstone pcb with external 3.3V lab/ATX supply.

    I did try this earlier, and wrote about it in a previous post. I didn’t lift the leg of the vreg though, so both supplies were operating in parallel.

    > Wouldn’t a >1V difference between two GNDs (pink trace) indicate a problem with grounding?

    Yes, I think it implies that the board is drawing lots of current which must return to the Apple II power supply through the single ground connector. If there’s enough current, the local ground voltage will climb above the Apple II ground, and the vreg will raise its 3.3V output by the same amount. I’m not sure why it would oscillate, though. And when driving 11111111 on the databus, I think the current return path is the data bus lines and not the ground connector, so it doesn’t quite make sense to me.

  5. Chris Combs - June 20th, 2021 5:18 am

    Are you still using MIC5219 as a vreg? Its datasheet doesn’t suggest a whole lot of headroom for current peaks here… “designed for 150 mA to 200 mA output current applications where a high-current spike (500 mA) is needed for short, start-up conditions”

  6. Stephen Moody - June 20th, 2021 5:54 am

    Just read this and your previous post. It’s interesting how the workaround does solve the problem, does sound like it’s a possible current supply issue but I wonder if the capacitance on the bus could part of the problem as well. I’m not sure how driving the data bus with 2 different voltage levels will be affected with a high capacitance like that.

    If you’re going to change the board design, adding series resistors should help but have you considered parts like the 74LVC8T245 as well? It may be better if you could drive the bus at 5V and remove the mixed voltage levels.

  7. Alex Cat3 - June 20th, 2021 6:07 am

    I dont know anything about analog electronics, but it seems very weird to me that noise on IOSTROBE and A1, which as far as I know are 2 inputs from the APPLE II, would have opposite polarity.

  8. John Payson - June 20th, 2021 6:07 am

    If all eight data wires are switching from 11111111 to 00000000, that would tend to pull the ground wire on the board positive. If all eight data wires are switching from 00000000 to 11111111, that would tend to push the ground wire on the board negative. Neither outcome would be good.

    I personally like having resistors separate FPGA-controlled logic from the bus, to minimize the likelihood of damaging anything if the FPGA is misprogrammed or something causes bus contention. I’ve destroyed a 6507’s address line by having a CMOS device drive it to 5 volts, and would expect that a lot of chips on the Apple would be fairly beefy but not indestructible.

    Additionally, adding resistors would make it easier to scope out signals to see which way they’re being driven.

  9. Steve - June 20th, 2021 7:31 am

    The regulator on the new board is the LD1117 from ST Micro, good for at least 800 mA. I just received some substitute regulators that I can try swapping in, to see if it helps anything.

    I also have some 74LVT245 and 74LVC8T245 chips which I can try for replacing the 74LVC245. At this point I’m less convinced those will make a difference, but we’ll see.

    I agree about the series resistors, they could potentially solve multiple problems, and that’s likely what I’ll do in the next board revision.

    Something interesting about the Apple IIgs bus: the data bus driver for the peripheral slots on the motherboard is a 74HCT245. There’s nothing else connected to the data bus, no pull-ups, nothing. I watched some data bus lines on the scope. When Yellowstone drives 3.3V onto a data bus line, at the end of the bus cycle it immediately jumps up to 5V and stays there for about 100 ns before it (sometimes) changes again for the next cycle where the IIgs is driving the bus. But if Yellowstone drives 0V onto a data bus line, it stays at 0V at the end of the bus cycle. It’s like there’s some 5V bus hold circuitry operating on the data bus.

    I think this mysterious 3.3V to 5V transition at the end of the bus cycle may be what’s causing the A1 spikes at the end of the cycle. Or at least is a major contributor to the spikes.

    The only explanation I can think of is that the IIgs is reversing the direction of the 74HCT245 immediately at the end of the bus cycle. Because the CPU isn’t driving a new data value yet, the 74HCT245 drives back the old value but at 5V levels. With a 5V driver on a peripheral card, this wouldn’t cause any problems even if the card continued trying to drive the bus for slightly too long after the bus cycle ends. But with a 3.3V driver, it means the card will be actively driving 3.3V while the 74HCT245 is actively driving 5V, and that’s bad news.

    It’s all conjecture and I haven’t confirmed any of this. But if I’m correct, it means it’s essential that Yellowstone’s 74LVC245 bus driver shuts off immediately when the bus cycle ends in order to avoid a brief 3.3V-with-5V collision with the 74HCT245. And this could be fixed by adjusting the shut-off timing, or adding series resistors on the data bus, or using a dual-supply bus driver chip like 74LVC8T245.

    Maybe I’m completely wrong here, but I think this could be a good explanation for the spikes at the end of the bus cycles. That still leaves the spikes during the bus cycles, when the 74LVC245 is first enabled and begins driving the bus. And the more I think about it, the less I understand. How much current does it really take to drive the inputs of a single 74HCT245 plus a few tens or hundreds pF of bus capacitance? I have a hard time believing there could be so much current as to cause the terrible spikes and noise shown in the scope traces. It’s not driving any significant load. It just doesn’t make sense to me that switching outputs from 11111111 to 00000000 or vice versa when they’re not driving any significant load would involve so much current to create the problems shown on the scope.

    That brings me back to the theory of briefly violating the 74LVC245 max output voltage rating if the bus is already at 5V when the 74LVC245’s output is enabled. That situation should clear up very quickly, but I’m not sure what problems it would cause in the meantime. It seems like a more plausible explanation for major spikes when the 74LVC245’s output is enabled. If I’m right, then the solution is to use series resistors or a dual-supply chip like 74LVC8T245.

    To make a long story short: the 74LVC8T245 may fix all the problems. I’ll give it a try soon.

  10. Ernie - June 20th, 2021 3:14 pm

    I don’t have anything to add, but I’m another lurker who really appreciates your writeups (and might eventually want the finished product!). Thanks so much for all your efforts in engineering and in the writeups!

  11. John Payson - June 21st, 2021 7:13 am

    I think you’ve identified an issue. If your board is trying to output 0xFF at the same time as the other board is doing so, the board will try to clamp eight high-strength 74HCT outputs to 3.3 volts, with no ground return path other than the ground pin. If your board is trying to output e.g. 0xFE, then it will try to clamp seven high-strength HCT outputs to 3.3 volts with two ground return paths: the ground pin, and the data pin which will be connected to ground on both your board and the CPU board.

    I’d suggest building a card-extender board with series resistors on many of the signal pins (including the data bus). Such a card extender could be broadly useful, not only for this particular project, but for future projects as well.

  12. Steve - June 21st, 2021 10:38 am

    I think that’s exactly what’s happening at the end of the bus cycle: a short window of 3.3V-with-5V bus fighting. If I disable the 245 output slightly before the end of the bus cycle, then the end of cycle spikes on A1 are significantly reduced (but there’s still some). In this case, after the 245 is disabled, the bus value stays at 3.3V until the end of the cycle, when it shoots up to 5V, presumably due to the 74HCT245 on the IIgs motherboard changing direction. I’m not 100 percent sure, but the end-of-cycle noise mystery is probably solved. The best way to fix it is debatable, though.

    That still leaves the original problem of noise and glitches when the 245 is first enabled and begins driving the data bus.

Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.