The ISA OSC Mystery

About twenty years ago I ended up with a spare ISA graphics card from an upgraded computer. It was a SVGA card based on the Cirrus Logic CL-GD5422 chip, equipped with 1 MB video memory.

Cirrus Logic CL-GD5422

This was a very cheap graphics card sold as part of a low-end PC in 1993 by ESCOM, a large European (originally German) PC retailer. It was a basic but hassle-free card, it was no speed demon but did its job well.

Now fast forward nearly twenty years. In the quest for the Ultimate Museum PC, I tried this old VGA card in a 440BX board (Abit BP6). It didn’t work. At all. There was no video signal whatsoever. I assumed that the card was most likely dead, because other (even older) ISA VGA cards did work in the same 440BX system. But I didn’t throw the card out… just in case.

A few months later, I revived an old Soyo SY-4SAW2 486 ISA/VLB/PCI board. Just for the heck of it, I tried the old Cirrus Logic SVGA in the Soyo… and lo and behold, it worked just fine! The same Cirrus Logic SVGA also worked in two other random boards, one with a 386 and the other with a 286 CPU. Nothing wrong with the card, after all.

Not long after, I came across another similar graphics card, only slightly older and with a bit of history behind it.

Acumos and Cirrus Logic

At the beginning of the 1990s, the Californian start-up Acumos began producing VGA-compatible chips based on a proven concept that had not yet been fully applied to graphics: Integrate as much as possible into a single chip. The first Acumos integrated VGA controller was called AVGA1, soon followed by AVGA2.

That meant combining the bus interface, VGA controller, clock generation, and RAMDAC. It’s almost easier to list what wasn’t integrated: video memory and BIOS ROM. In both cases, there were very good reasons not to integrate.

CirrusLogic/Acumos AVGA2

In April 1992, Acumos merged with Cirrus Logic. The above card is a witness of the transitional period: The ROM chip is labeled AVGA2, while the actual controller is CL-GD5402. In Cirrus Logic’s numbering scheme, the AVGA1 was CL-GD5401 while AVGA2 was CL-GD5402. The chips didn’t change, just the labels did.

Cirrus Logic fully exploited the integrated VGA chip concept and quite successfully sold low-end and mid-range graphics chips, especially in the OEM market. The above CL-GD5422 board is one of those. By 1996, graphics chips with integrated RAMDACs and clock generators were standard (S3 Trio64, ATI Mach64 CT/VT/GT) and Cirrus Logic found it much more difficult to compete, but Acumos/Cirrus Logic was there first.

The ISA OSC Signal

One noteworthy “omission” in the Acumos/Cirrus Logic cards is an oscillator. Graphics cards usually have a crystal oscillator; on 1980s graphics cards there might be up to four or more separate oscillators, on newer models a single oscillator feeds a PLL clock generator (whether separate or built into the graphics controller).

The oscillator is needed because a graphics card requires a known time reference and the bus clock (for ISA/VLB/PCI) is not fixed. The need had existed ever since the first IBM PC and to simplify the system design, IBM implemented the OSC (oscillator) pin on the I/O channel, also known as ISA bus. The OSC signal was simply driven by the 14.31818 MHz system clock used in the PC. As everyone knows, the crystal was used because it produced exactly four times the NTSC color subcarrier frequency. It was thus readily available and useful for the CGA in composite mode when driving a TV.

The upshot is that the IBM CGA did not include a clock crystal and used the OSC signal from the bus instead. So did the Acumos AVGA1/AVGA2-based cards, and so does my old Cirrus Logic board. This is in fact quite unusual, and there are not many ISA boards which need a reference clock (some cards run at bus speed and do not need any other time source) yet do not have their own. For example IBM’s own MDA does have an oscillator.

There have been some hints that the ISA OSC signal may not be correctly implemented on all boards, a typical fate of rarely used features in the PC world.

What Works and What Doesn’t

Further plug testing showed that in the Abit BP6 board (equipped with two 533MHz Mendocino Celerons), neither the CL-GD5422 nor the CL-GD5402/AVGA2 produce valid video signal, even though the system does boot up. An interesting factoid is that while the 5422 produced no recognizable signal at all, the 5402 generated an out of sync signal.

However, in other boards (for example Asus P2B-DS) both cards work without any issues. And in the P2B-DS, the card was tested with an 850MHz Pentium III to ensure that a fast CPU is not the problem.

At this point, there wasn’t conclusive evidence that the ISA OSC signal was the problem. But it was a plausible explanation for why two slightly unusual ISA VGA cards wouldn’t work in one 440BX board when they work just fine in another, largely very similar 440BX board. (It should be pointed out that the chipset has nothing to do with the matter, as it is the motherboard itself which needs to supply the 14.31818 MHz signal on the ISA bus.)

What Does an Oscilloscope Say?

With an oscilloscope, it should be possible to simply measure the ISA bus signals and conclusively find out whether a board supplies a reasonable OSC signal or not. To this end, I borrowed a scope and set out to learn how to use it, never having touched an oscilloscope before.

It turned out to be simple enough and the oscilloscope was able to directly measure signal frequency. The first tested system was an old ASUS PVI-486SP3 board (SiS 496/497 chipset). The ISA CLK signal looked like this:

ASUS PVI-486SP3 ISA CLK signal

The ISA bus ran at 8.32 MHz, a fairly standard speed which should not pose any problems. The signal isn’t very pretty but it should be good enough. The actual OSC signal looked like this:

ASUS PVI-486SP3 ISA OSC signal

The signal has a decent shape and runs at 14.4 MHz. It is unclear to me why the oscilloscope shows the frequency as 14.4 MHz instead of 14.31818 MHz. The scope manual warns that the frequency measurement may be inaccurate past 10 MHz, yet I measured 16 and 24 MHz crystals and the oscilloscope reported exactly 16.0 and 24.0 MHz. At any rate, the CL-GD5442 VGA card worked fine in this system.

Next up was the ASUS P2B-DS (440BX chipset). The ISA clock ran at 8.28 MHz. The OSC signal ran at 14.4 MHz as well:

ASUS P2B-DS ISA OSC signal

Again, the CL-GD5422 VGA card worked in this system without any issues. Finally, the troublesome Abit BP6 board (440BX chipset) was subjected to the same testing. The ISA clock ran at 8.22 MHz. The OSC signal was most certainly there, at 14.4 MHz. It didn’t look nearly as good as on the 486 board, but barely different from the P2B-DS:

ABIT BP6 ISA OSC signal

And this time, the CL-GD5442 worked in the BP6 board! It’s not at all clear what the problem really was—the Cirrus Logic VGA card repeatedly failed to function in the BP6 board, and then it suddenly did. It may have been caused by cracks in the board, since it has suffered a fair amount of abuse over the years and some PCI cards also have mysterious problems in certain slots.

The Plot Thickens

Not leaving well enough alone, I tried the troublesome CL-GD5442 in a Tyan Tomcat IIID board (a dual Pentium board, Intel 430HX chipset). The story repeated itself—at first, the VGA card refused to work, but then it changed its mind and started working. The oscilloscope showed that the OSC signal didn’t look very different from the other boards (and again was reported as 14.4 MHz).

This time I measured the OSC signal directly on the VGA card next to the graphics chip (the OSC trace is on the bottom side of the card and there’s a convenient little hole where it crosses over to the component side, making it easy to apply the probe). While the OSC signal was noticeably noisier on the card than it was on the crystal on the board, it was most certainly there, whether the CL-GD5442 produced a valid video signal or not.

While I was at it, I also checked the VGA vertical and horizontal sync signals with the scope. As expected, when the card worked, the VSync was a nice 70 Hz and HSync showed 31.5 kHz. When the card did not work, there was a signal on both the VSync and HSync pins of the VGA connector, but nowhere close to the correct range: it was over 200 kHz for both HSync and VSync.

Experimentation also confirmed that when the board boots up without a valid VGA signal, hard resetting the system may fix the problem. Based on that, my current theory is as follows: The CL-GD5442 chip is very sensitive to the quality of the OSC signal, especially immediately following power-up/reset. The graphics controller’s internal PLL clock synthesizer (I assume there is one) may fail to lock when the card is powered up. If that happens, the PLL can’t lock until the card is powered up again or reset.

Should others have a more plausible explanation, I’m eager to hear it.

This entry was posted in Cirrus Logic, Graphics, PC hardware. Bookmark the permalink.

14 Responses to The ISA OSC Mystery

  1. Raúl Gutiérrez Sanz says:

    The wave in the first picture show a small secondary component which doesn’t affect the total signal in the sense that between peaks you get a flank which is always-ascending or always-descending.

    The wave in the second picture shows a better quality signal.

    But the waves in the last 2 pictures show a less negligible secondary component (a harmonic?) which in the peaks of the main component has opposite sign, resulting in more ascending and descending segments for every cycle of the main component.

    Zero-crossing is correct for all signals, but for a certain card… what is considered a cycle?

    So, the last 2 OSC signals should be more prone to have problems. Of course it doesn’t explain why the same card sometimes work and sometimes don’t work in the same mainboard. As it doesn’t explain why the same card fails more often with the 4th signal, because in the 3rd one the secondary component looks slightly bigger.

  2. Raúl Gutiérrez Sanz says:

    BTW, are these signals expected to approximate sinusoidal or square waves? Because if they should approximate square waves, then I think that 3rd and 4th signals are better than 1st and 2nd ones, adding even more mistery.

  3. Michal Necasek says:

    Available documentation talks about “50% duty cycle”. I don’t think that necessarily implies a specific waveform?

  4. Michal Necasek says:

    The thing is that the OSC signal looked the same whether the VGA card worked or not. That’s why I suspect the problem has something to do with how the signal behaves when the card is reset. But I didn’t try to capture the waveform at reset time with the scope (because I thought of that only after giving the oscilloscope back).

    BTW I think the different-looking OSC waveform was taken with the probe set to 1x mode, while the other two used a 10x setting (but I’m not entirely certain). This has an impact on what the waveform looks like on the scope.

    Of course it’s still possible that the VGA card is sensitive to the exact waveform or the signal noise.

  5. Raúl Gutiérrez Sanz says:

    Did you use always the same power supply? Or a different one for each mainboard?

  6. Michal Necasek says:

    It was the same power supply in all cases. An ATX PSU with an AT adapter.

  7. Tor says:

    Use the probe in 10x mode, otherwise you can’t trust the waveform you observe. The 1x mode is not good for square wave monitoring on any scope. The 1x mode is like connecting a cable directly to the scope, there’s way too much capacitance and this will affect the higher harmonics. The 10x probe setting also changes the impedance load on the circuit by a factor of ten (the capacitance improvement much more).

    -Tor

  8. Michal Necasek says:

    You clearly know a lot more about scopes than I do 🙂 I’m fairly certain that most of the photos were taken with the probe in 10x mode. And before doing the measurements, I adjusted the scope to display a square wave as square using the test signal from the oscilloscope (I noticed that in 1x mode it was not really possible to show it as square).

    Whether the OSC signal is even supposed to be a square wave is still an open question.

  9. Stephen Edwards says:

    The datasheet for the Acumos AVGA1 specifically brags about the chip’s built-in clock synthesizer.
    http://www.datasheets360.com/pdf/6814814553400629212

  10. Michal Necasek says:

    Yes, and also mentions that the OSC signal on the ISA bus is used to drive said synthesizer.

  11. Pingback: Fast Unaccelerated VGA? | OS/2 Museum

  12. Pingback: More ISA VGA Benchmarks | OS/2 Museum

  13. Razvan Vilt says:

    This might explain the incompatibility between CL-GD5410 or 5434 and Transcend 40 pin IDE Modules.
    I have an IBM PS/1 2133 from the spring of 1992. It has an onboard CL-GD5410 which works brilliantly as a VGA except when a Transcend IDE Flash module is inserted (I’ve tried two 2GB ones and a 128MB one). When the flash module is inserted the video signal is completely messed. An LCD won’t display anything, and an analogue monitor will show junk.
    I’ve tried upgrading the VGA card to an ATi Mach64 based G/Xpression, but that won’t boot on the said system (probably) because it has an overlapping IO port (0x102) with the programmable option selector of the IBM motherboard.
    I’ve tried putting in an STB Nitro 64 ISA (CL-GD5434) and it shows the same issues as the onboard CL-GD5410.
    I’m still trying to find 86C928, ET4000AX and Mach32 based adaptors to try them out.

    The PS/1 is difficult to say the least. In Linux, you need to manually give it the ide0=0x1f0,0x3f6,14 hda=3884,16,63 and hda=noprobe parameters since the FDPT has a different offset than the setup.s in Linux expects.

  14. Michal Necasek says:

    Hmm. That sounds a bit like the PS/2 E Model 9533 I’ve been recently fighting with. It’s a 1993 machine and it has an XGA-2 onboard. I’m using it with a CF to IDE adapter and some CF cards cause startup errors and video corruption when installed. It looks like corrupted video memory, the signal as such is fine but the screen is more or less unreadable. Only some (not many) CF cards do that and so far I have no idea a) what mechanism even causes this, and b) what is different about the problematic CF cards. Many CF cards also just don’t work in the PS/2 E (hangs, write corruption), yet there are others that work quite reliably.

    Not all CF cards were created equal, that’s for sure.

Leave a Reply

Your email address will not be published. Required fields are marked *