This wasn't production, exactly, but it was - in my own humble opinion - an awesome hack, so I'm going to post it. Was the lead software and computer engineer

This wasn't production, exactly, but it was - in my own humble opinion - an awesome hack, so I'm going to post it. Was the lead software and computer engineer on a new robot. We had decided to use compact PCI, which was at that time (late 1990s) a brand new form factor, so a lot of specialized cards weren't available for it yet. But that was OK, because the manufacturers were selling bridge cards that adapted smaller form factor cards to the compact PCI standard. One of the cards we needed was a motor driver card. The particular card that was available to us used an LM629, a very old, widely used, digital servo controller chip. Now, whichever guy or girl designed the LM629 was an anal bastard. The chip had memory-mapped read-only and write-only registers, which was fine. But if you ever read or wrote anything out of order, or tried to read a write-only register or write to a read-only register, the chip would drop into an error state. So the device driver had to be right on the nose, the chip wasn't going to cut you any slack. Because the cPCI standard was so new, I ended up writing the device drivers myself. Which was OK, I had just graduated with a CS degree, knew metal-level C pretty well, things should have been fine. Except I couldn't get this motor driver card to work. Every time I tried to command the motor, the chip would generate an error. I stripped the code down more and more and more, to the point that I was only sending a single 8 bit write and then a single 8 bit read, and still the chip generated an error. After two weeks of banging my head against it I was at the end of my rope. The manufacturer of the LM629 card took pity on us and let us bundle the robot up and bring it to their site, which was in Minneapolis. They gave us a small lab, where we proceeded to bang our heads for another three days with no progress. Eventually he took more pity on us and assigned us his digital logic expert for the afternoon. Dude rolled in the most badass digital logic analyzer setup I had ever seen at that point. The thing took up a full-sized equipment rack. He hooked up to our board and asked me to issue an 8-bit write. That looked fine. Then an 8-bit read. He raised his eyebrows at that one - asked me if I was sure my code was correct, as he had seen a 16 bit read. The top byte of which was mapped to chip memory space we weren't supposed to be tickling. I told him I was 100% positive that the code was not asking for a 16 bit read. Eventually we ended up on the phone with Intel, which made the bridge card chip. They told us that their chip had a known bug; it couldn't translate an 8 bit read on the cPCI bus to an 8 bit read on the daughter card bus. Instead, it issued a 16 bit read and threw the most significant byte away. "This is documented behavior," they said. And sure enough it was, in a footnote in 10 point font on page 52 of the manual. That left us in a quandary, since there didn't seem to be any way to fix things. Then we had a brainstorm. The fix was to cut the address lines of cPCI side of the daughter card and shift them all one line to the left, and tie the least significant address pin of the bridge chip to the most significant address pin of the LM629 address decoder logic. That way any attempt to access odd addresses got mapped into nullspace, memory space somewhere way above what the chip actually had, and the decoder logic just rejected the access request. The chip would never see it. Then we rewrote the code to make the new addresses line up with the chips newly re-jiggered address space. Worked like a charm. We treated ourselves to a high-end steak house that night and flew home. As far as I know the robot worked in that fashion for close to a decade, until they retired it.