On Using the Right Tool for the Job
I've been working on bringing up the video card for my PikaPC project. It has had me quite confused. No attempt to communicate with the device had any effect.
Everything I was sending it looked right. Address decoding asserted the chip enable, the state machine on the video card recognized it was being addressed, the emulated VLB cycle started. There only thing that was missing was some acknowledgement from the video chip itself.
I added debug headers and attached fine wires to even finer chip leads. I did manage to catch a few errors — I was asserting the VLB address strobe on the wrong clock edge, and I had omitted a couple pull-up resistors. My fixes did not change the result.
Recently a good friend sent me an HP 1670E logic analyzer. It is a 136-channel beast of a machine that is currently consuming over a third of my available desk space. I must admit some hesitance in attempting to use it. Frankly, I was intimidated. But I had a problem that surpassed what my 16-channel USB analyzer could easily tell me. To solve this problem, I needed to be able to see all of my 32-bit address/data bus plus another 8 bus control signals.
I attached the first 40 probes to my protoboard card, stumbled through the menus to learn how to enable and label each channel & configure the trigger event, and pressed Run. The machine waited. I hit enter on the PikaPC terminal to start a bus cycle addressing the video card.
… and immediately saw the problem.
The first step in initializing VGA is to set an Enable bit on I/O address 0x3c3. But the analyzer captured 0x1c3.
Either I had a short, or a missing address signal. I had already confirmed there were no solder bridges or missing signals on the video card, and I was using my protoboard card anyway. So the problem had to be on my main board.
I captured a few more tests —
0xfc0 captured as 0xfc0 ✅
0x7c0 captured as 0x7c0 ✅
0x5c0 captured as 0x7c0 ❌
0xcc0 captured as 0xec0 ❌
Address bits 9 and 10 were identical in all test results, regardless of input. Probing those address pins on the expansion bus buffer indicated a direct short. The problem did not affect normal operation of the machine, so it was not likely that CPU address pins 9 and 10 were shorted together. I traced the two wires from the buffer back to the CPU and found … both wired to the same CPU pin.
I had finally found my problem. It was a quick fix. Once it was in place, I ran the VGA initialization sequence and my monitor immediately sprang to life.
My video card appears to be working. I still haven't figured out the correct incantation to actually draw anything on screen using these S3 chips. That will be the next hurdle.
I might have eventually found this issue using my small analyzer. I would have had to capture the address bus no more than 8 bits at a time, carefully stepping through multiple captures with different test parameters. It would have taken quite a long time, and there's no guarantee I would have noticed the error no matter how carefully I reviewed at the captures. There just isn't any substitute for using the right tool for the job.