Testing continues for my Yellowstone disk controller card for Apple II computers. One of the design goals for Yellowstone was to support Macintosh floppy drives, and today I got a Mac drive working for the first time! I transplanted a 1.44 MB high density internal floppy drive from a Macintosh LC, and successfully used it to boot an Apple IIe with an 800K ProDOS disk. Hooray!

Some more details: The 1.44 MB Macintosh drive can be used to read 800K Apple II disks. Yellowstone does not support 1.44 MB disks. While I haven’t tried it yet, an 800K Macintosh drive should work too. 400K Macintosh drives will not work, but 400K disks in 800K or 1.44 MB drives should work. Clearly there will need to be substantial testing for all this.

So far, so good. But there was some cheating involved in this test, related to differences in pin assignments between Apple II and Macintosh floppy drives. Now I need to determine how to make everything work for real.

 
RD and SENSE Pin Usage

The first issue involves how the drive sends information to the computer. The Sony 3.5 inch drive mechanism sends all its disk data and status info on a single pin: RD, pin 16 of the 20-pin rectangular connector. But for reasons I don’t understand the Apple II software is designed to expect 3.5 inch disk data on the RD pin but status info on pin 20. If you look inside the Apple 3.5 Drive enclosure, you’ll find an adapter board that (among other functions) copies the value from RD onto pin 20 also. But when direct-connecting a Sony 3.5 inch drive mechanism without an enclosure, there’s no adapter, and the Apple II gets confused.

For this test, I was able to get things working by modifying the FPGA logic to use pin 16 instead of pin 20 when looking for status info, but this breaks the 5.25 inch and Smartport disk modes. I need to find some auto-magic way of doing this only when necessary.

 
-12V Supply Connection

The second issue is with the -12V power supply for the drive. Somewhere over the years and the generations of Apple II and Macintosh computers, Apple changed the meaning of pin 9 of the 20-pin rectangular floppy drive connector. On Apple II computers and disk controllers, and on the earliest Macs, this pin is -12V. But on later Macintosh models, pin 9 is not connected at the disk controller side. On the drive side (at least with the 1.44 MB drive I pulled from my Macintosh LC) pin 9 is a redundant 5V power supply connection, and -12V isn’t used. That means using a 20-pin ribbon cable to plug a Macintosh 3.5 inch drive directly into the Yellowstone card will create a short circuit between -12V and +5V. Ouch!

I avoided this short-circuit by physically cutting the wire for pin 9 on my disk cable, but that’s not an acceptable long-term solution. I could add a -12V enable jumper to the Yellowstone card, and that would work, but it would still leave the possibility of accidental -12 to +5V short circuits if somebody made a mistake or didn’t read the instructions. A better solution would somehow detect what kind of drive was connected, and automatically enable or disable -12V accordingly.

How might that work? Why do some drives need -12V anyway? As far as I know, the only drives that actually need the -12V supply input are 5.25 inch drives like the Disk II. From a quick look at the Disk II schematic, -12V appears to be part of a 10K ohm potentiometer circuit, with +12V on the other side of the pot. Maybe this is the pot used to adjust the disk rotation speed? I’m not sure.

Whether pin 9 is a -12V supply input, or is a second +5V pin (with the primary +5V supply on pin 11), the direction of current flow will be from the drive to the disk controller. So I can’t solve this problem with a simple diode. Maybe there’s something clever I can do here with a transistor? If the pin is supposed to be a -12V supply input, but the Yellowstone board hasn’t (yet) provided the necessary -12V, then I’m not sure what voltage will be sensed at the pin. My guess is it will be +12V, as seen through that 10K pot. Based on this, I don’t see any easy and reliable method of auto-detection, so maybe a -12V jumper is the only viable solution.

Hi! This is Alice. I’ll be helping out with some of the engineering work at BMOW.

Version 0.3.6 for the ADB-USB Wombat is now available. The Wombat is a bidirectional ADB-to-USB and USB-to-ADB converter for keyboards and mice. Connect modern USB keyboards and mice to a classic ADB-based Macintosh, Apple IIgs, or NeXT, or connect legacy ADB input hardware to a USB-based computer running Windows, OSX, or Linux.

The new version fixes a small bug with the Power Key in ADB to USB mode. This fix enables the Wombat to register the Power Key being held at the same time as another key, allowing it to be useful in different mappings such as a Fn key.

The Wombat is available now on the BMOW store!

Good news! I’ve completed the stress test involving seven filled peripheral slots to increase the data bus capacitance to its maximum, and Yellowstone is still performing OK. I tried this stress test on both the Apple IIgs and Apple IIe, with Yellowstone connected to an Apple 3.5 Drive, Unidisk 3.5, or Apple 5.25 Drive. With more peripheral cards and more bus capacitance, this test should produce the highest currents through Yellowstone’s 74LVC245 bus driver chip. If the card were ever going to malfunction due to high currents, ground bounce, or similar electrical problems, this test should have revealed it.

Despite all the various hardware modifications that I tried, the resolution was ultimately implemented entirely with FPGA logic changes designed to minimize current and avoid simultaneously switching current. Here’s the complex dance that happens now when the CPU reads a byte from Yellowstone’s RAM:

• t=0: IOSTROBE is asserted by the Apple II. The FPGA puts the value 10101010 on the input pins of the ‘245 bus driver, but the ‘245 is not yet enabled.
• t=140ns: The ‘245 bus driver gets enabled. This 140 ns delay avoids a period of bus-fighting due to the slow-turn around time of the motherboard’s data bus driver. The value 10101010 is driven onto the data bus.
• t=210ns: The FPGA disables its output pins, and enables the RAM. The actual RAM value is now driven onto the data bus.
• t=350ns: RAM gets disabled. Now nothing is driving the ‘245 inputs, but the FPGA’s keeper circuitry maintains the last value from RAM. This early RAM shutoff separates the change in supply current from further changes happening at the next step.
• t=420ns: The ‘245 bus driver gets disabled. Now nothing is driving the data bus, but bus capacitance maintains the last-driven value.
• t=490ns: (or t=630ns for long clock cycles) IOSTROBE is deasserted and the bus cycle ends.

So is this saga all done? Everything good? End of story? Not exactly.

Even though it may not be absolutely necessary, I’m going to replace the 74LVC245 bus driver with a 74LVCR2245. This is a drop-in replacement with integrated 26 ohm series resistors on the outputs to limit the current. Thanks to LIV2 for making me aware of this option. I’ll sleep better at night with the 74LVCR2245 replacement. Its only real drawbacks are that it increases the BOM count and cost slightly, and it’s not exactly the most common chip, so availability might become a problem in the future. But if that happens I can just switch back to 74LVC245 without needing any PCB modifications.

Now that I’ve opened this can of worms on signal integrity, I find it mentally difficult to close it again. My design has mainly focused on correctness of the digital logic, with little thought given to the low-level world of currents and voltages that implement the digital abstraction. Now I see that many of my design practices were not very good, and I want to improve them. I already needed to design a Yellowstone 2.1 PCB to fix an overlapping signal trace, and I’m including several other changes in 2.1 as well:

• widened all the power and ground traces as much as possible
• improved the ground fills, addressing some choke points and connecting dead-end areas
• spread out some signal traces that were unnecessarily crowded
• added a 0.1uF capacitor across 5V and GND at the card’s supply pins (there was already a 10uF here)
• moved the 0.1uF capacitor on the 3.3V regulator output to be closer to the regulator
• moved all the decoupling capacitors to be close to the chips’ VCC pins instead of their GND pins
• rerouted the data bus traces so they don’t all cross under the A0-A6 address traces

I’m not sure whether rerouting the data bus traces was really necessary. But if there’s a total instantaneous current through all eight data traces of 250 to 500 mA, with a sharp change in current, and all eight of the data traces pass under an address trace on the opposite side of a 2-layer board, is that enough to induce a glitch in the address? Maybe? If so, rerouting those traces should help.

In hindsight I’m not sure whether it was wise to move decoupling capacitors to be adjacent to VCC pins instead of GND pins. Most advice that I’ve read says to place them as close as possible to the supply pins, meaning both power and ground. But on a chip where the VCC and GND pins are in opposite corners, it’s a direct tradeoff: the closer the capacitor is to the VCC pin, the further it is from GND. Faced with this choice, is one location better than another?

My first thought was that it doesn’t matter, and what’s important is minimizing the total combined trace length from the capacitor to the VCC and GND pins. This makes some intuitive sense. But then I did some more reading, and I think capacitors close to the GND pin may actually be more effective at reducing ground bounce, while capacitors close to the VCC pin may be more effective at reducing VCC sag.

Consider the case of an open drain buffer, which at its simplest could just be a single transistor with its source connected to ground, its gate connected to the input signal, and its drain connected to the output. When the input is high, it will pull the output low, and when the input is low, the output floats:

A buffer like this would be susceptible to ground bounce, but there’s no VCC here at all. So what good would it do to locate a capacitor close to the buffer’s VCC pin, if it even had one? To minimize ground bounce, it seems to me that the capacitor should be located close to the ground pin, with the other terminal connected to any other supply source, which doesn’t necessarily need to be the VCC pin. But I’m having some difficulty imagining the current flows in this example, and maybe my reasoning is wrong.

I’ll keep tinkering with this stuff in the background, but now I can finally return to functional testing of Yellowstone and addressing high-level firmware bugs. It’s progress.

The role of Steve will now be played by a small red-faced boy

Oops. I’ve verified that the spikes I’m seeing on data signals are largely due to the embarrassingly poor ground connections on my oscilloscope probes, rather than issues with the signals themselves. I had the ground leads of all four scope probes clipped together, connected to a 12 inch wire, which was then plugged into a ground point on the Apple IIgs motherboard, which was about 8 inches away from the peripheral slot where the Yellowstone card was installed. That’s a very long return path. I hadn’t appreciated how important it is to have a good short ground lead connection for the scope probe when measuring signals with fast edges, even though nice people kept trying to explain it to me. Now I have some new data using better ground connections.

To begin, I removed the spring hook adapter from the probe, and also detached its standard ground lead (a 4 inch wire with an alligator clip). This left me with a sharp-tipped spike probe. Then I wrapped a small ground spring around the outside of the probe. This was included with my bag of oscilloscope parts, but I’d never used it before. The end result looked similar to the photo above. Now I was ready to take some new measurements.

To review, here’s another look at the scope capture from part 7, with the old bad probe grounding. This was the example where I captured signals from an unpopulated PCB, when the Yellowstone card was not installed in the computer. Yellow (Ch1) is the 5V supply voltage, measured at the 5V pin of the PCB. Notice how there are spikes of more than 1V peak-to-peak in the 5V supply.

Now here’s the same experiment again, but with the probe tip for 5V directly touching the 5V pin, and the ground spring touching an adjacent GND point a few millimeters away. The probes for the other signals were still connected in the old way.

Wow! The spikes on the 5V supply completely disappeared with this more careful measurement. But I quickly discovered that it’s very difficult to accurately position a spike probe and a ground spring in a live circuit. While taking these measurements I managed to accidentally short 5V and GND not once but twice. One of the episodes produced sparks. Yikes.

Next I reinstalled the Yellowstone card, and repeated some of my earlier measurements, but with a better ground setup. It wasn’t practical to use the spike probe and ground spring here, but I did the best I could. I hooked a short piece of wire to a ground point on the Yellowstone board, and connected the standard ground leads from all four probes to this wire. Here’s what I saw:

• Blue (Ch4) is address line A1. It’s a 5V input from the Apple II
• Purple (Ch3) is data bus D0 from the Apple II
• Yellow (Ch1) is the 3.3V supply voltage, measured at the VCC pin of the ‘245.
• Cyan (Ch2) is IOSTROBE from the Apple II, and marks the boundaries of the bus cycle.

Now I could see some supply noise again (yellow channel), but it looked fairly minor. Also some modest ringing on the data bus D0, though probably not enough to worry about. Unfortunately I still observed lots of spikes on A1 (dark blue channel). It appeared that whenever the data bus value changed (pink channel), it created spikes on A1. This was true regardless of whether Yellowstone was driving the data bus, during the low period of IOSTROBE (cyan channel), or if something else was driving the data bus, during the high period of IOSTROBE.

That degree of spikes on A1 looked concerning – possibly enough to cause a malfunction if the scope were showing a true representation of the signal. To get a better look, I needed a better ground lead for the probe. So I soldered a tiny coiled wire to the A1 pin to use as an anchor for the probe, and went back to my spike plus ground coil setup. Then I veeeery carefully applied the probe and took a measurement, without any sparks. This time I didn’t capture D0 or 3.3V, and A1 was on Yellow Ch1:

It’s harder to understand what’s happening here without the D0 trace for reference. There’s still some spiking on A1 during the bus cycle when IOSTROBE is low. This is the moment when Yellowstone’s 245 is enabled and driving the data bus. But the amplitude of the spikes during the bus cycle looks much smaller than before, only reaching about 400 mV at worst. That should probably be OK.

There’s worse spikes on A1 when its value changes, after the bus cycle ends, but I don’t think I can do anything about that since Yellowstone is inactive at this time.

Using the same probe setup, I took some other measurements of A1 (not shown) outside of Yellowstone bus cycles, during times when the data bus value changes due to something else driving the bus. I observed similar spikes of about +/- 300mV on A1 whenever the data bus changed. I’m not sure what’s causing that, but it seems to be unrelated to anything that Yellowstone is doing.

 
TLDNR

In short, after taking better measurements with better probe grounding, all the signals looked decently OK.

Given this, it’s probably time to try the stress test: fill all the peripheral slots with 1980s vintage cards, which should increase the bus capacitance to its maximum, which in turn should produce the highest currents through Yellowstone’s 245 bus driver chip. It shouldn’t really matter what those other cards are or what they’re doing, the only important thing is that they’re installed. If Yellowstone is ever going to fail due to high currents, ground bounce, or similar electrical problems, this should reveal it.

For this test I’ll use a new Yellowstone board with the normal chips, instead of the Frankenstein board with which I’ve been experimenting up until now, that’s been modified too many times to count. I’ll use the updated FPGA logic with pre-driving 10101010 and other changes I’ve made to help reduce peak current, but otherwise it will be identical to the board whose mysterious IIgs failures originally launched this whole glitching saga. If this test reveals any problems, I’ll look more into adding series resistors. Otherwise I’ll move on.

This glitching investigation has taken a turn down a strange path. Although the Yellowstone board seems to be working, I wanted to further reduce the nasty-looking signal spikes seen on the oscilloscope. Series resistors on the data bus seem like a good way to do that. So I performed some more board surgery, and separated the output pins of the 74LVC245 from the pads on the PCB. Then I used 16 fine-gauge wires to insert a socket between the ‘245 and the PCB pads, so I could experiment with resistors of different values in the socket.

I tested it with 100 ohm series resistors, and the steepness of the edges on data bus transitions were noticeably more gentle. I measured about 0.15V per ns, instead of 0.4V per ns before. But I was very surprised that the weird spikes I’ve been chasing on D0, A1, and the 3.3V power supply didn’t improve at all. As far as I could tell, series resistors didn’t help even a little bit. They were a total dud, at least for 100 ohms.

My attention then returned to something I’d noticed before. There were also spikes on the signals at other times, not during the Yellowstone bus cycle. What was that about? Is Yellowstone doing something odd from an electrical standpoint, even when it’s not driving the bus or receiving a value from the bus?

Then I got to thinking: three of the four signals that I’ve been measuring in each scope experiment are just Apple II bus signals, not Yellowstone signals. So what would happen if I completely removed the Yellowstone card from the computer, and just measured those signals? I took a blank unpopulated PCB, and soldered a few wires to points on the board so I could measure some voltages. Then I ran a test program on the Apple IIgs that attempted to read values from the non-existent peripheral card.

• Blue (Ch4) is address line A1. It’s a 5V input from the Apple II
• Yellow (Ch1) is the 5V supply voltage, measured at the VCC pin of the PCB.
• Cyan (Ch2) is IOSTROBE, and marks the boundaries of the bus cycle.

All those ugly signal spikes are still as bad as ever when the Yellowstone card isn’t even present. Cue disorienting sound effects, flashing lights, evil laughter, fade to black…

What have I even been looking at for these past few days? Either it’s some noise inherent in the Apple IIgs itself, or more likely it’s just operator error and an artifact of my crappy probe setup. But it’s not a problem with Yellowstone.

I’m still confident there was initially a signal integrity problem with Yellowstone, probably multiple problems, caused by high current flows through the 74LVC245. But my earlier attempts to address the issue may have been more successful than I realized, and now I’ve been chasing phantoms for several days.

All these Yellowstone glitching mysteries may finally be headed for a conclusion. It looks like there are at least two separate problems with different causes: one causing glitching during a bus cycle and the other causing glitching at the end of a bus cycle.

 
Fighting at End of Bus Cycles?

This one is complicated to explain, so bear with me. You should understand that the Apple IIgs is a 5V system, but Yellowstone uses a 3.3V 74LVC245 to communicate on the data bus. This works because the LVC family is 5V tolerant on its inputs, and its 3.3V output is high enough to be sensed as a valid “high” by 5V logic chips. On the IIgs motherboard there’s a 74HCT245 that handles the computer’s side of transfers to and from the data bus.

Yesterday I noticed something curious: when Yellowstone is driving a 3.3V high value onto the data bus, at the end of the bus cycle the voltage always immediately jumps up to 5V, and stays there for a few hundred nanoseconds until something else puts a value on the pus. What’s doing that? Is there a 5V pull-up resistor on the bus, or something similar? No. When Yellowstone is driving a 0V low value onto the data bus, the voltage remains at 0V after the end of the bus cycle.

I’m not 100 percent sure, but I think at the end of a bus cycle the IIgs is immediately reversing the direction of its 74HCT245. Previously this chip was taking the peripheral card’s data from the peripheral slot data bus and moving it to an internal data bus, but now it begins taking data from the internal data bus and moving it to the peripheral slot data bus. And what data is that? In the first tens of nanoseconds after the direction is reversed, it’s actually the same data that the peripheral card was outputting, now briefly stored in the bus capacitance of the internal data bus.

What happens if the peripheral card’s output driver is a bit slow to turn off at the end of a bus cycle, due to propagation delays on the control signals? Since the peripheral card and the 74HCT245 from the IIgs are both driving the same data onto the bus, normally it should be OK. But for Yellowstone and its 3.3V 74LVC245, it’s not OK. For a time of roughly 15 ns, it causes 5V and 3.3V sources to both try to drive the bus at the same time, resulting in high current flows into the 3.3V supply, and overall badness. This is what I strongly suspect is causing Yellowstone’s end-of-cycle spikes and glitching.

There are several possible solutions:

1. adjust Yellowstone’s ‘245 turn-off so it happens earlier, before the bus cycle is theoretically over
2. modify Yellowstone to use a true 5V output driver, so there’s no 3.3V-to-5V conflict
3. insert series resistors on the data bus to limit the current from 3.3V-to-5V conflict to safe levels

I implemented option 1, and it substantially reduced the spikes at the end of bus cycles. Surprisingly, it didn’t eliminate them completely. It feels strange to disable the ‘245 before the bus cycle is over, because the CPU doesn’t capture the bus value until the very end of the cycle. It seems like it should cause bad data to be read, causing malfunctions. But in practice it appears to work OK, probably thanks to that bus capacitance persisting the data value even after the ‘245 shuts off.

I also implemented option 2, through a bit of board surgery in which I replaced Yellowstone’s 74LVC245 with a dual-supply 74LVC8T245. This almost completely eliminated the spikes at the end of bus cycles, because the voltage on the bus stays constant at 5V after the cycle ends.

I would like to try option 3, but that will take more effort to set up.

 
High Current During Bus Cycles?

The second problem is the one I was chasing initially: spikes and glitches during a bus cycle, at the moment when the 74LVC245 is enabled and begins driving the data bus. I had a theory this was caused by a brief violation of the max output voltage spec of the 74LVC245, when it tries to output 3.3V but finds the bus capacitance is already charged to 5V. So I desoldered the 74LVC245 and replaced it with a 74LVT245, a nearly identical chip but with a higher max output voltage spec above 5V. Unfortunately this did nothing to help the spikes and glitches during bus cycles. Then I replaced the 74LVT245 with a 74LVC8T245, a dual-voltage chip with true 5V I/O on the Apple II side. Again this did nothing to solve the problems during bus cycles.

Based on these two tests, I concluded that violating the max output voltage spec of the 74LVC245 was never a problem, or at least it was never the main problem. The signal spikes are very likely caused by a large amount of current briefly flowing when all the data bus outputs change simultaneously from 1 to 0 or vice-versa. This is a “normal” condition, not a violation, but it’s troublesome. I’ve attempted several board modifications to help meet this sudden current demand, including adding a 10 uF bypass capacitor to the ‘245, and adding extra power and ground wires from the ‘245 straight back to the voltage regulator. None of it seemed to help.

I can’t quite explain this, since I didn’t think there should really be all that much current flowing. I guess I was wrong. But the only solution seems to be finding ways to reduce the current, or spread it out over a longer period of time. That’s what my 10101010 pre-driving trick accomplishes, but there’s plenty more room for reducing the current further.

Some possible options here:

1. replace the 74LVC245 bidirectional buffer with two unidirectional buffers: an LVC buffer for input and an LS buffer for output
2. insert series resistors on the data bus to limit the current
3. something else I’m overlooking

The 74LS245 is an appealing option because the LS family just can’t drive very hard, at least not when outputting a high voltage. But it won’t work as a bidirectional substitute for the 74LVC245, because its 5V outputs (or close enough to 5V) would damage the FPGA. So I’d need to use the LS chip for output only, and use an LVC chip for input. That’s not very appealing. I’m also not sure how well it would reduce the current when driving low voltages instead of high ones. It might still draw too much current, or it might be fine. Isn’t this basically how all 1980s vintage peripheral cards worked? How did they avoid this problem?

Options 1 and 2 should both resolve the problems at the end of the bus cycle too, so that’s good. The other alternatives have more limited application. Adjusting the ‘245 turn-off timing does nothing to help the problems during the bus cycle, nor does using a 74LVC8T245 chip.

 
Unsolved Mysteries

Sadly none of the above can explain why these same problems didn’t appear in revision 1 of Yellowstone. Probably they did, but they weren’t severe enough to cause bit flips and malfunctions, so I never noticed. The only partial explanation I can think of is that revision 2’s RAM chip is to blame. Revision 1 used internal FPGA RAM and didn’t have a separate RAM chip. My guess is that the extra current used by the RAM is exacerbating the problem somehow.

 
Next Steps?

If you’re still reading this wall of text, it’s time to evaluate the possible solutions and make a choice. Let’s start with the simplest option: do nothing (at least from a hardware standpoint). By implementing the 10101010 pre-driving trick, adjusting the ‘245 turn-off timing, and a few other small timing changes, I’ve already improved things enough to get my prototype board working.

Here’s what things look like with only the FPGA logic changes. Same as in part 6, the traces shown are:

• Blue (Ch4) is address line A1. It’s a 5V input from the Apple II
• 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.

I didn’t capture GND this time.

Yeah it still doesn’t look great, but it works. If you’ve forgotten how bad everything looked before I made the FPGA logic changes, here’s the headline image again from part 6:

So maybe this is good enough now, without needing further hardware changes? Especially if some of the ringing shown in the scope traces is due to my poor probe setup rather than being a true representation of the signal?

If a hardware change is needed, series resistors are attractive because they’re simple and easy. But what value of resistor? It must be big enough to significantly limit the current in a bus-fighting scenario, but not so big that it results in failure to meet the Vil and Vih specs of the other chips on the data bus that are receiving data.

Let’s say I used 100 ohm series resistors. In a 3.3V-to-5V bus fighting scenario at the end of a bus cycle, that would limit the current to 1.7 / 100 = 17 mA per data bus line, or 136 mA total. That’s still pretty high. Too high, I think.

If I used 500 ohm resistors, it would limit the total current to a much more modest 27.2 mA total, but it would create a new problem. For the 74LS family inputs on the data bus of the Apple IIe, and for as many as six other peripheral cards installed that use 74LS parts, the inputs source 0.2 mA when they’re “receiving” a logical low value. All combined that’s 1.4 mA worst case. With 500 ohm resistors and a current of 1.4 mA, even if Yellowstone could output a true 0.0V logical low value, the LS inputs would see a voltage of 1.4 * 500 = 0.7V, which is almost above the Vil threshold for 74LS family parts. In short, with a fully loaded set of 7 peripheral cards that all use 74LS logic, and 500 ohm resistors, Yellowstone might not work.

There’s some middle ground here. Resistor values from roughly 150 to 500 could probably work to solve both problems, but it’s a narrow enough range that it makes me slightly nervous. Maybe go with 220 or 330 ohm.

If a hardware change is needed but series resistors won’t do, then I think the only viable alternative is a two-chip solution with 74LS output and 74LVC input. But I don’t love this solution, for the reasons mentioned previously: extra chips, extra design complexity, and a concern it might not work anyway for driving a logical low voltage. There would be a small amount of additional control complexity too. Each chip would need a separate enable signal from the FPGA, where spare pins are scarce, and extra care would be needed to prevent enabling both at once.

Some other combination of solutions might be possible too, like 74LVC8T245 with series resistors. But I don’t want to go overboard.

As you might expect, I’ve grown very tired of this glitching problem, and my enthusiasm for further tests and experiments is low. My gut says to accept the software-only solution and call it good, or else maybe to add series resistors. But I don’t want to sweep this problem under the rug, only to have it reappear later in rare circumstances I can’t troubleshoot. If you were me, what would you do?