Rita's Cafe wrote on 2021-10-14, 05:04:
mkarcher wrote on 2021-10-11, 18:31:
Due to some discussions on different BIOS contents for CL-GD5429 graphics card, I coded a simple memory clock adjust utility for Cirrus Logic chips between 5424 and 5429.
Interesting. I own three CL-GD5429 based VLB cards and all have the same 1.00A ROM. And I once searched for a newer ROM but couldn't find one.
That's also the ROM I used on Disruptor's card where I benched those values. I compared that ROM with the ROM dump that recently appeared in different thread and found out that despite being the same version, one byte is different - it's the MCLK initialization value which is customizable by card vendors.
Rita's Cafe wrote on 2021-10-14, 05:04:
From memory, the datasheet for the 542X says that the highest clock is 60MHz for the 5429 with the others being lower (50MHz?). But your chart goes beyond 65MHz. Is this safe to do? Does it automatically add wait states where needed?
You are right. I recklessly exceeded the specified frequency, i.e. I overclocked the memory interface of the 5429. I can't tell you whether this might cause local overheating of the chip or accelerate the aging process and cause premature failure of the graphics controller. Use it at your own risk. I can tell you that I didn't observe any kind of garbage on the screen, though.
The chip doesn't add wait states to the RAM interface based on the MCLK. It does have a configuration strap (not overridable in software) that adds a wait state on page misses. The recommendation by Cirrus is to make use of the extra wait state on page misses to allow higher MCLK timings, that still work on page hits (the common case). Indeed, Disruptor's card uses the extra wait state (7MCLK RAS cycle), as likely most CL-GD5429 cards do. Page hits should be rare, so the performance loss by this wait state is likely insignificant in most use cases.
Rita's Cafe wrote on 2021-10-14, 05:04:
BTW how did you record this data? I'd like to try benchmarking my VLB cards at 33MHz & 40MHz FSB.
I used CTCM, a cache benchmark by the German c't magazine. It can measure video transfer speeds if you call it with "/VID", but it comes with a couple of pecularities so I wouldn't generally recommend it. For example even on VESA 1.2 BIOSes, the tool tries to bench 800x600 (256 colors) in LFB mode by default. That mode gets rejected by the BIOS, and the result is that the tool benches mode $13 twice, but calls it 800x600 in the result table. You need to specify "/vid=$103" to prevent it. The values I recorded are the MOVSB and MOVSD speeds, measured on L1 cache hits, which are nearly identical to STOSB/STOSD speeds. If you need a simple low level performance benchmark tool, I recommend VIDSPEED instead. As this low-level bench is very well defined (well, there is only one kind of REP STOSD...), the tool performing the test is likely irrelevant and the data is comparable even across different tools. I benchmarked modes $13 (VGA 256-color), $103 (not running CLMODE before, so at 56 Hz), $12 (VGA 16-color) and 3 (text). The byte performance of $13 and $12 is identical, so I merged those two values into "VGA bytes", not specifying the color count.
