When I worked at Orange Micro, we used a sound chip and its corresponding driver in a Pentium coprocessor board for Macs. When we used Windows 95, the sound would play one time (just the startup sound), then it would be forever silent. I was assigned the task of fixing this problem.
Shortly after I started working on it, we received a report from one of our customers saying it suspected a bad memory SIMM on one of our boards. It replaced the SIMM with an 8MB SIMM. Sound always worked with that SIMM in place and failed with larger SIMMs, which we verified at our facility.
I gained access to our company's only logic analyzer and found that the sound driver was accessing the sound buffer at the wrong memory address. There was no data, so there was no sound. After spending about a week single-stepping with the DOS debugger through the sound driver code, I found the place where it requested the sound buffer from the Windows 95 OS. I changed a few bytes of code to force it to allocate the buffer in the first 8MB of RAM, and sound worked fine after that.
Fortunately, I made notes on the byte pattern in the critical section of the driver, because soon after I worked through this problem, the manufacturer updated the driver. The buffer allocation code had moved, but we were able to find the pattern and again apply the modification to keep our sound playing.
This entry was submitted by Cliff Harris and edited by Rob Spiegel.
Cliff Harris received formal electronics training in the Army and later went to California State College at Fullerton to get his BSEE degree. He is now semi-retired and still involved in electronic projects at home.
Tell us your experience in solving a knotty engineering problem. Send stories to Rob Spiegel for Sherlock Ohms.