Guys, could someone do an independent comparison of the speed of all the firmware versions on their systems, to see if there's actually a performance gain? I collected my own data using Dr.Hard.

At 1st we would need to download all 5 rom images somewhhere, I still have only 3. Btw your mod of 1ws stb rom was done on wrong offset so it cannot have any effect.

Yes, I saw your message. Unfortunately, I don’t have information about the correct offsets for those variables in the STB BIOS.
At the very least, please compare the performance of the original highspeed.rom file from GitHub with my version to confirm that the speed improvement is real and not just a result of some quirks in my hardware setup.

Yes, I need some time to find some free eprom/eeprom, erase it, pogramm... But I have some doubts as even in hispeed rom when disassembled there are no references to offsets you changed anywhere in code. So I would rather aim to reprogramm the mclk pll...

Well, I have found in S3 datasheet that RDY ctl min wait states is set by bit 4 in CR40 register. I wrote a small utility that displays a few S3 options from varoius CRs. With 0WS rom the bit was 0 and with 1WS rom the bit was 1 as expected. CRs seems to be unlocked by bios. So I cleared bit4 to 0 at runtime on 1WS rom and read it back to confirm the value has changed but it has not any effect on performance, strange... I coul search in dasmed 1WS rom if I find any CR40 manipulation and try to change it there.

Other though. Both roms reported me that memory config is 2-cycle EDO. Could modifying to 1-cycle EDO make it faster?

I also plan to add code for reading MCLK PLL regs to check how fast is running.

RayeR wrote on 2025-06-04, 13:44:

Well, I have found in S3 datasheet that RDY ctl min wait states is set by bit 4 in CR40 register. I wrote a small utility that displays a few S3 options from varoius CRs. With 0WS rom the bit was 0 and with 1WS rom the bit was 1 as expected. CRs seems to be unlocked by bios. So I cleared bit4 to 0 at runtime on 1WS rom and read it back to confirm the value has changed but it has not any effect on performance, strange... I coul search in dasmed 1WS rom if I find any CR40 manipulation and try to change it there.

Other though. Both roms reported me that memory config is 2-cycle EDO. Could modifying to 1-cycle EDO make it faster?

I also plan to add code for reading MCLK PLL regs to check how fast is running.

MCLK: There already is a tool for that, see Re: Tool to adjust the memory clock on Cirrus Logic CL-GD542x graphics cards . 2-cycle EDO vs. 1-cycle EDO is a strapping option. I used to think that the 765VL is strapped to 1-cycle EDO. VL with 1WS is already quite fast (up to 44MB/s at 33MHz if the mainboard doesn't add an extra clock for RDY synchronization), so you need a quite fast processor and a mainboard that doesn't add extra wait states to actually notice 0WS (up to 66MB/s at 33MHz). The 0WS/1WS difference is more noticeable on mainboards that do add an extra wait state to synchronize the RDY signal: In that case, zero WS at the cards allows up to 44MB/s and one WS at the card drops to 33MB/s.

Cool, I didn't know about this tool, I'll have to try it.
And what difference would you guess between 1/2-cycle EDO? It seems there are some other video memory timings CRs...

UPDATE:
good tool, changing EDO from 2 cycle to 1 cycle makes a huge difference in VESATEST, 15 -> 22 MB/s (RAM->FB)!

default MCLK=59,96MHz m=65, n=2, r=2 (well BIOS set it but I cannot see it in DASM)
In 2-cycle mode transfer speed scaled with increasing MCLK up to cca 73MHz where it capped to 22MB/s and even change to 1-cycle EDO didn't push more. I could push MCLK insanely high at 100MHz, over 104MHz I saw some snowing artifact and at ~110MHz it messed up textmode and hanged.

In Doom the MCLK effect is zero.
In Quake 320x200 and 640x480 also the same...

Another idea, as I read in other thread about ARK1000, it may help to improve performace lowering the refresh rate. Original 1WS STB BIOS outputs VESA mode at 75Hz which is nice on CRT but for LCD 60Hz is enough and more memory BW could left for GPU/CPU writes. This could be patched in video BIOS...