On 03/30/2017 06:01 PM, Brent Hilpert via cctalk wrote: Early Dram memories were fickle to design and many poor designs got out with notable consequences. Examples wer common in the S100 realm and others too. The MITS 88-4K was replaced with 88-S4K for that reason it was that bad and that was using the non-multiplexed 22 pin 4K parts. The later 16K multiplexed 16 pin parts 4116 were worse Tandy TRS80 EI version 1(no buffer) and 2(buffered cable) leading to the later third try a complete redesign. The problem was a high capacitance load of many NMos Drams and the address and data drive. The fix was not trivial. A fairly hard source like a 74S157 (treat as similar in this case to a voltage source) provides a fast stepped input to a signal line and if the line were terminated in its characteristic impedance it would simply transfer the signal and preserve waveform. But an array of 16 DRAM for one address line with board and input capacitance looks like a roughly 160pf capacitor to ground. Your S157 switches and a step waveform goes from ground to +2.7V (lets say) and the instantaneous current is rather large with an exponential decay. Since the line does not see a termination like its characteristic impedance or anything acceptable much of the energy in the pulse is reflected back and you see ringing or waveform distortion (depends on length of the line). So the then simple fix was series resistance by experimental (maybe empirical too) testing for the best waveform and timing compromise. Usually this lead to both re-layout of the board as when you get 8 or 9 lines doing this the ground gridding starts showing noise too. In the end its all transmission lines that have poor termination. What people often forget at DC and very low frequencies the MOS/CMOS input are essentially open circuits. At high frequencies (pulse rates) its a capacitor which is an energy storage device. Changing that voltage across the cap takes energy and time and is not a friendly load by any cable/transmission line. So putting a SD or even a CF at the end of a ribbon or spectra cable without adequate grounds (every other wire or a backplane ground) means the field around those wires will couple and be the fields around its neighbours and make itself known in the most offensive ways. For those that have forgotten.... those that forget history will relive it. *Vonada's Engineering Maxims* are a group of pithy observations about computer engineering compiled by Don Vonada, an engineer at DEC <http://gunkies.org/wiki/DEC>, and reproduced in: * C. Gordon Bell, J. Craig Mudge, John. E. McNamara, "/Computer Engineering/" They are: 1. There is no such thing as ground. 2. Digital circuits are made from analog parts. 3. Prototype designs always work. 4. Asserted timing conditions are designed first; unasserted timing conditions are found later. 5. When all but one wire in a group of wires switch, that one will switch also. 6. When all but one gate in a module switches, that one will switch also. 7. Every little pico farad has a nano henry all its own. 8. Capacitors convert voltage glitches to current glitches (conservation of energy). 9. Interconnecting wires are probably transmission lines. 10. Synchronizing circuits may take forever to make a decision. 11. Worse-case tolerances never add - but when they do, they are found in the best customer's machine. 12. Diagnostics are highly efficient in finding solved problems. 13. Processing systems are only partially tested since it is impractical to simulate all possible machine states. 14. Murphy's Laws apply 95 percent of the time. The other 5 percent of the time is a coffee break. Allison

Yes, the wire is connected to the FPGA at one end. That FPGA I/O pin is *supposed* to be configured for high-Z but that's the only place I can see the DC bias coming from. Because of the way it's built, I'm not seeing a reasonable way to disconnected the FPGA while leaving the rest intact. However, I did move the signal to another wire in the ribbon cable and the problem is basically gone. This lets me move on with other issues but am still a bit puzzled with this one.

Looks like we have an explanation then. We're using an XC7A75T-CSG324, a Xilinx Artix 7 series FPGA. Thank you very much.