In the two previous blog posts, I wrote about a rare issue that was affecting some early IIGS motherboards with specific early versions of some of the IIGS custom IC's. It was so rare that only 4 people reported it, but it's never good to have any unexplained issues, especially if you are one of the affected users. A fix was released as part of core v5, which fixed the problem for two of these users, but two other users still had the problem, even with v5. Very frustrating, both for him and perhaps even more for me, because even though I enjoy getting to the bottom of unexplained issues like this, it's very difficult to do without having access to the faulty board in question. Because if I don't have it on my desk to hook up to the oscilloscope and try new ideas, I can only guess at the underlying issue.
Then something great happened: the user in question mailed me two (!) of his IIGS motherboards which had this problem (he basically hit the jackpot with two of his boards having this rare issue!), all the way from Canada to the Netherlands. I was a bit worried about this, because what if this package would get lost in the mail? Not only would this nice user lose his two beloved motherboards, but we would possibly be even further away from identifying the sound problem. Fortunately, after about a week it arrived at my door, and I started digging. You may remember the bodge from an earlier blog post: interestingly enough, I found out that on one of his boards, this bodge had been incorrectly applied by the factory. A PCB trace that should have been cut, was not fully cut, so it shorted the 1k resistor that was supposed to slow down transitions.
The trace that wasn't cut can be seen in the center of the image above. It looks somewhat cut, but the multimeter and oscilloscope proved otherwise :). I guess when you have to do 100s of those cuts per day, back in the factory around 1988 in Singapore, boredom and inattentiveness may get the better of you. Surprisingly they apparently didn't check their work, or they only checked the machine still booted, which it did (the bodge isn't that critical).
However, fixing this cut (by cutting it properly this time) didn't improve the sound issue (not entirely surprising, since his other faulty board had a correct bodge). Interestingly, the first thing that started leading me to the real fix was adding a stack of 5 sockets to the AppleSqueezer before inserting it. This normally can be done without issues, but on this faulty machine, it made it even more faulty to the point where it wouldn't boot at all. What this told me was that the issue seemed timing related, where it was at the edge of working but the slight timing differences from the extra stray capacitance of the extra sockets pushed it fully over the edge. This also makes sense, because the board would sometimes boot, and sometimes not, so that's already an indication of timing or signal integrity issues. With this in the back of my mind, I started looking at the FPGA code, and tried some different things that could make some timing difference, changing the phase of some signals. One part related to the BE input of the 68C816. The Bus Enable signal tells the CPU that it can use the bus (the address and data lines) when it is pulled up, and when it cannot (when pulling it low), such as when the IIGS wants to use the bus for something without the CPU interfering. Like when addressing the sound hardware. This BE signal was used correctly by the AppleSqueezer, but there were some exceptions that seemed useful at the time (partly inspired by the Transwarp GS schematic), but that turned out to give this issue. Not for 99% of the machines, but for the remaining 1% :)
Long story short: the fix works well for both of the "faulty" motherboards (which really weren't faulty, just different!) I will do more testing with it and then release it as part of core v6, coming soon! I'm considering adding other features to it first, but I may release it separately because I think it may bring stability improvements for other users. You can check the downloads page to get the latest core version. v6 should be there somewhere in the coming week or two!
Off-topic, but for those who may wonder why (pre-)ordering is currently not possible: certain parts have become impossible to get at the moment. The supplier informed me that these "might be available at the end of Q4". Slightly less than fully reassuring, but I do have a backup plan in case this doesn't pan out, or if I'm getting impatient.