ah Phils test suite. I dont see teh point of that doom in a snail mail stamp sized window test, and the "normal" test is also not standard window size making it useless for comparing to random internet scores. Anyway looks like ~10 fps aka terrible category unfortunately, might get faster with mclock bump

analog_programmer wrote on 2026-10-30, 07:44:

And here is our fast BIOS candidate I quickly made for less than 5 minutes:

Original bios splitted to two parts: 24K+6K, second part is fonts. Most utils on PC can dump only first part.

VGA 320x240x256 performance on 386-40Mhz (ISA 10Mhz)
512K:

1MODE RESOLUTION     HFrq VFrq    St8  St16  St32 Bus  Mv8   Mv16  Mv32
2───────────────────────────────────────────────────────────────────────
3  13  320x200x256   31.5 70.1   1836  3661  3835 16   1197  2397  2831
4─────────────────────────────────────────────────────────────────────────

1024K:

1MODE RESOLUTION     HFrq VFrq    St8  St16  St32 Bus  Mv8   Mv16  Mv32
2────────────────────────────────────────────────────────────────────────
3  13  320x200x256   31.6 70.1   2366  4732  5319 16   1514  3028  3525
4────────────────────────────────────────────────────────────────────────

analog_programmer wrote on 2026-10-30, 11:59:

No shooting is allowed! I also count on you to push the VRAM frequency up to 70 MHz by demystifying some more JP1-JP2-JP3 combi […]
Show full quote

Nexxen wrote on 2026-10-30, 11:37:

Shoot, I didn't think of modifying the ISA settings in BIOS......
Shame on me! 🤣

No shooting is allowed! I also count on you to push the VRAM frequency up to 70 MHz by demystifying some more JP1-JP2-JP3 combinations. You're the man with the suitable oscilloscope here, so I need you alive 😁

Judging by my overcloced S3 ViRGE card, 60 ns EDO RAM chips can bear 70 MHz clock speed, perhaps this also applies to FPM RAM.

But first, let's see what the "fast" BIOS could give. I'm about to purchase some "new" chinese EEPROMs...

P.S. VESA.COM gives VBE 1.2 in expense of 3 KB of RAM. So, this one (or even better - VBE 2.0) would be better off transplanted into the "fast" BIOS 6 KB free space.

Tested BIOS.
Post screen is blank with a couple of logo pics visible (in the wrong position).
After this it displays normally BIOS and boot.
While it does go through test, it can't load Keen but to a blank screen and Simcity has no fonts.

If the prior posts are accurate, this is because the 6k oprom contains the vga fonts.

That means there is only 2k to work with, for slipping in the vbe vector table handlers. 🙁

(Not impossible, but much more troublesome.)
(The previously linked vbe spec doc will at least give hints about what code paths need included.)

Nexxen wrote on 2026-10-30, 15:21:

Tested BIOS. Post screen is blank with a couple of logo pics visible (in the wrong position). While it does go through test, it […]
Show full quote

Tested BIOS.
Post screen is blank with a couple of logo pics visible (in the wrong position).
While it does go through test, it can't load Keen but to a blank screen and Simcity has no fonts.
I'll post pics later.

Thanks. So, this "OpROM garbage" part is a separated ROM-font, as Mov AX, 0xDEAD first suggested.

No problem, I'll put it back for "take two" 😉

Nexxen, here is the "fast" BIOS with Font-ROM restored:

This one should work in text modes, since "hardware" character set is back 😉

Mov AX, 0xDEAD wrote on 2026-10-30, 14:58:

VGA 320x240x256 performance on 386-40Mhz (ISA 10Mhz) 512K: […]
Show full quote

VGA 320x240x256 performance on 386-40Mhz (ISA 10Mhz)
512K:

Copy code to clipboard

1MODE RESOLUTION     HFrq VFrq    St8  St16  St32 Bus  Mv8   Mv16  Mv32
2───────────────────────────────────────────────────────────────────────
3  13  320x200x256   31.5 70.1   1836  3661  3835 16   1197  2397  2831
4─────────────────────────────────────────────────────────────────────────

1024K:

Copy code to clipboard

1MODE RESOLUTION     HFrq VFrq    St8  St16  St32 Bus  Mv8   Mv16  Mv32
2────────────────────────────────────────────────────────────────────────
3  13  320x200x256   31.6 70.1   2366  4732  5319 16   1514  3028  3525
4────────────────────────────────────────────────────────────────────────

What kind of VGA test utility is this?

wierd_w wrote on 2026-10-30, 15:25:

If the prior posts are accurate, this is because the 6k oprom contains the vga fonts. […]
Show full quote

If the prior posts are accurate, this is because the 6k oprom contains the vga fonts.

That means there is only 2k to work with, for slipping in the vbe vector table handlers. 🙁

(Not impossible, but much more troublesome.)
(The previously linked vbe spec doc will at least give hints about what code paths need included.)

Yep. Another option is BIOS size increased up to 64 KB and there will be a plenty of room for even more "garbage" 😁

Tested, no change from original BIOS. Results are the same.
Tried Rambios, non change.
UVGA utility let me set the resolution and works to an extent on my 4:3 monitor.
Probably it doesn't like the 66Hz refresh rate I have with this 24MHz Vclk. Well, I'll wait for a 25.x to come.
I'll solder a different 50MHz to Mclk. Let's see it it changes anyhting.

Nexxen wrote on 2026-10-30, 16:51:

Tested, no change from original BIOS. Results are the same.
Tried Rambios, non change.

Thanks! So, finally this "fast" BIOS is working. This one is slightly newer, than the stock one. I extracted it from RAMBIOS.SYS "driver", which is basically a loader for it and eats 32 KB of our precious conventional RAM. So, if you're using the "fast" BIOS, there is no more need to load RAMBIOS.SYS.

For me this "fast" BIOS (loaded by RAMBIOS.SYS) is giving increase only in SST2.0 (about four times the original BIOS results) and CheckIt! 3.0 (about two times the original BIOS results for "BIOS VIDEO CPS" test, "DIRECT VIDEO CPS" test results are equal), but not in SST6.0. I have no suitable games for my current 286 test rig to see if will give some slight performance increase in DOS games.

I'm gonna purchase some EEPROMs. At least no more need of RAMBIOS.SYS is "a small win". I will also need a suitable EEPROMs, if I continue these BIOS experiments with VBE 1.2 or 2.0 transplanting.

Nexxen wrote on 2026-10-30, 16:51:

UVGA utility let me set the resolution and works to an extent on my 4:3 monitor.
Probably it doesn't like the 66Hz refresh rate I have with this 24MHz Vclk. Well, I'll wait for a 25.x to come.
I'll solder a different 50MHz to Mclk. Let's see it it changes anyhting.

I can not help here. The old LCD display I use for my retro test configurations "eats" (almost) anything through its VGA port without complain, so I don't know how Hsync and Vsync problems look like.

analog_programmer wrote on 2026-10-30, 17:10:

Thanks! So, finally this "fast" BIOS is working. This one is slightly newer, than the stock one. I extracted it from RAMBIOS.SYS […]
Show full quote

Nexxen wrote on 2026-10-30, 16:51:

Tested, no change from original BIOS. Results are the same.
Tried Rambios, non change.

Thanks! So, finally this "fast" BIOS is working. This one is slightly newer, than the stock one. I extracted it from RAMBIOS.SYS "driver", which is basically a loader for it and eats 32 KB of our precious conventional RAM. So, if you're using the "fast" BIOS, there is no more need to load RAMBIOS.SYS.

For me this "fast" BIOS (loaded by RAMBIOS.SYS) is giving increase only in SST2.0 (about four times the original BIOS results) and CheckIt! 3.0 (about two times the original BIOS results for "BIOS VIDEO CPS" test, "DIRECT VIDEO CPS" test results are equal), but not in SST6.0. I have no suitable games for my current 286 test rig to see if will give some slight performance increase in DOS games.

I'm gonna purchase some EEPROMs. At least no more need of RAMBIOS.SYS is "a small win". I will also need a suitable EEPROMs, if I continue these BIOS experiments with VBE 1.2 or 2.0 transplanting.

Nexxen wrote on 2026-10-30, 16:51:

UVGA utility let me set the resolution and works to an extent on my 4:3 monitor.
Probably it doesn't like the 66Hz refresh rate I have with this 24MHz Vclk. Well, I'll wait for a 25.x to come.
I'll solder a different 50MHz to Mclk. Let's see it it changes anyhting.

I can not help here. The old LCD display I use for my retro test configurations "eats" (almost) anything through its VGA port without complain, so I don't know how Hsync and Vsync problems look like.

Question:

In 'what ways' does the ram-resident vbios differ from the stock bios?

Is the main difference in perf, *just from it being in RAM, with better access times*?

Can we get a comparison with emm386/jemm doing ROM shadowing?

Eg,

Emm386.exe ROM=c000-cfff

(For a full 64k video rom)

I need better tests to see if it does improve.

Could you kindly suggest which ones, different from Phil's pack, would be good candidates.

1) Checkit!
2) ...

Probably the Dos menus he has could be the issue here.
I'll do that tomorrow.

----
I can delete the rambios.sys, ok.
Well, I have to open my screen to check if anything died or there is a bulging capacitor... Screen is old, early 2006.

wierd_w wrote on 2026-10-30, 17:22:

Question: […]
Show full quote

Question:

In 'what ways' does the ram-resident vbios differ from the stock bios?

Is the main difference in perf, *just from it being in RAM, with better access times*?

Can we get a comparison with emm386/jemm doing ROM shadowing?

Eg,

Emm386.exe ROM=c000-cfff

(For a full 64k video rom)

When bit compared, they differ in most of their parts. Only the Font-ROM second part is bit-matching in its entire length. The date of the RAM-resident BIOS is about a month newer compared to the original one.

Currently I'm using 286 test rig, so I have no shadow RAM on this motherboard to test these EMM386/Jemm related things, sorry.

The read-me "manual" says this about the "fast" RAM loaded BIOS :

RAMBIOS device driver: […]
Show full quote

RAMBIOS device driver:

- RAMBIOS SYS ...a program to speed up video read and write operation.

Put DEVICE=RAMBIOS.SYS as the first device driver command in CONFIG.SYS
file. It should be installed before any other device driver in order to be
compatible with most application programs.

- RAMBIOS EXE ...a program for AUTOEXEC.BAT or under dos prompt.

I'm not aware, if RAMBIOS.SYS could be loaded "high", since I don't have UMBs on my test 286 motherboard. RAMBIOS.EXE executed from AUTOEXEC.BAT didn't gave me any speed differences, but eats a bit more conventional RAM (33 KB).

Nexxen wrote on 2026-10-30, 17:36:

I need better tests to see if it does improve. […]
Show full quote

I need better tests to see if it does improve.

Could you kindly suggest which ones, different from Phil's pack, would be good candidates.

1) Checkit!
2) ...

Probably the Dos menus he has could be the issue here.
I'll do that tomorrow.

I have no idea. Doom's time-demo seem like a good test to me. But I can't run Doom on my current 286 test rig.

The "DOS menu" from Phill's test pack is just a batch-file menu, it doesn't change any results.

Nexxen wrote on 2026-10-30, 17:36:

I can delete the rambios.sys, ok.

Yes, you don't need to use RAMBIOS.SYS, if you're using the BIOS I uploaded in my previous post. The newer "fast" BIOS is extracted from RAMBIOS.SYS and I changed the start-up strings to clearly distinguish it from the stock one, since these strings were the same, except for the BIOS date.

I am very curious about shardowed bios.

RAM can be accessed 32bits wide, with no waitstates.

ROM on the isa bus can only accessed 16bits wide, and with a longer fetch cycle.

This can translate to a significant perf boost for code called very frequently. (Especially where caching misses)

If the main 'source of improvement' is 'not crossing the isa bus to run the service routine', then emm's shadow function will give the same benefit, without eating conventional or UMB. (Emm grabs from above 1mb to supply the ram for shadowing, and uses the mmu to remap it.)

A comparison between:

1) Fastrom equipped card, no shadow

2) Fastram.sys loaded

3) Stockrom with shadow

4) Fastrom with shadow

5) stockrom, no shadow

Would be illucidating.

We could tease how much perf improvement comes from 'just being in ram'

Sorry to hear you only have a 286 to test in AP.

Maybe Nexxen can give data.

wierd_w wrote on 2026-10-30, 17:45:

RAM can be accessed 32bits wide, with no waitstates.

So, this could explain my insane "fast" SST 2.0 results with RAMBIOS.SYS loaded. But I got no boost in SST 6.0.

I do have a plenty of other motherboards - 386, 486, Pentium-class, etc., but currently I'm testing a 286 game port for another forum's member, so I don't want to switch my current test rig for newer system configuration. Nexxen currently uses 486 and Pentium test systems, so he could give some answers about these shadow RAM related questions.

wierd_w wrote on 2026-10-30, 17:45:

I am very curious about shardowed bios. […]
Show full quote

I am very curious about shardowed bios.

RAM can be accessed 32bits wide, with no waitstates.

ROM on the isa bus can only accessed 16bits wide, and with a longer fetch cycle.

This can translate to a significant perf boost for code called very frequently. (Especially where caching misses)

If the main 'source of improvement' is 'not crossing the isa bus to run the service routine', then emm's shadow function will give the same benefit, without eating conventional or UMB. (Emm grabs from above 1mb to supply the ram for shadowing, and uses the mmu to remap it.)

A comparison between:

1) Fastrom equipped card, no shadow

2) Fastram.sys loaded

3) Stockrom with shadow

4) Fastrom with shadow

5) stockrom, no shadow

Would be illucidating.

We could tease how much perf improvement comes from 'just being in ram'

Sorry to hear you only have a 286 to test in AP.

Maybe Nexxen can give data.

I will, this is such a snail and we all want to see how "pimping" it can give as an improvement 😀
This is awesome at this point.
I'll change motherboard, maybe with a Super socket 7 or maybe a Socket A... I need more options in BIOS. I'll test in the coming days.

Nexxen, I think, your 486DX system suits the best for this early '90s ISA videocard. A 486DX2-66 system should run Doom fine, right?

For clarity, what emm,'s ROM statement 'does':

Much the same as the Include statement, emm takes memory from above 1mb (xms memory), and uses the MMU to map out the original address, and map in the physical memory above 1mb at that location.

Unlike the include statement, it copies the data from the targetted address to the ram first, does the remapping, then sets the ram read-only.

This is similar to the shadowing functions of some 268 and 386 motherboards, except instead of using the mmu, as emm does, the bios uses chipset functionality to do this transparently.

Old bioses and chipsets will burn 384kb of xms to supply the shadows with.

Emm does similar, on even newer systems that lack chipset shadowing, using the mmu. (Which is present on 386 and newer cpus)

Things that could significantly benefit from being shadowed are isa vga bios, and disk controller bioses.

My current test rig 286 motherboard (Suntac chipset) has 1 MB of on-board RAM installed, from which the upper 386 KB could be configured as EMS or XMS memory. It doesn't support UMBs, so I'm currently using these upper 384 KB as XMS memory (with logical start address at 1 MB) - at least HIMEM.SYS loads part of the DOS high in the first 64 KB after the 1 MB address "threshold" and uses A20. So, any VGA card I install will be speed limited by any direct BIOS functions readings from the slow BIOS ROM chip of the videocard. When I use RAMBIOS.SYS (the newer "fast" BIOS loaded into the memory) it is loaded into the conventional RAM (as suggested in the read-me file for the UM85C408 drivers) these BIOS function readings should became faster. This could be the explanation for my impressive speed improvements in SST 2.0 and CheckIt! 3.0 "BIOS VIDEO CPS". But why there's no speed increase in SST 6.0? Probably a different VGA speed measurement method - something like "DIRECT VIDEO CPS" in CheckIt! 3.0. And why, when I try RAMBIOS.EXE, it loads, but doesn't give any speed improvements in any tests, like the RAMBIOS.SYS does? This RAMBIOS.EXE is mostly empty (it doesn't contain the "fast" BIOS from RAMBIOS.SYS and doesn't call RAMBIOS.SYS to load it from there), so perhaps it is broken release. I definitely have to burn some EEPROM with the "fast" BIOS and compare it to the stock one on at least a 386 motherboard capable of RAM shadowing.

Anyway. I'm glad, that Nexxen managed to partially fix his card and meanwhile I got "a new toy" to tinker with for a while 😀

wierd_w wrote on 2026-10-30, 15:25:

If the prior posts are accurate, this is because the 6k oprom contains the vga fonts.

oh but of course! I was looking at it in binary and wondering why its only two or 3 1bit bursts. Those weird burst are characters 😁
I slopped a quick viewer (single html tiny javascript app attached) and can see one set of 8x16 and one 8x8 with seemingly some garbage in between

Nexxen wrote on 2026-10-30, 16:51:

Probably it doesn't like the 66Hz refresh rate I have with this 24MHz Vclk. Well, I'll wait for a 25.x to come.

Im pretty sure it wants 28.322?

wierd_w wrote on 2026-10-30, 17:22:

In 'what ways' does the ram-resident vbios differ from the stock bios?

only for programs that call bios to do things, so text based dos utilities and naive text speed tests from early eighties. Games call video bios exactly once - when setting up mode 13h 😀

I use VESA.COM to enable Vesa. Version is 1.2D, I'll look for 1.3 or better to see if there is a difference.
This allows 640*480 to work as it finds Vesa to launch benchmarks that need it.

I didn't find any difference in performance except for the cpu, Duron 1000, that ups some but not in an interesting way.
Doom max details runs slower than a P166.

I tried the P166 on a GA-5AA and results were worse.
I soldered a 40MHz crystal to Mclk and results were the same.

IDK but looks like it needs older boards??? 😀 60ns, 70 or 80 makes no difference - something is wrong and it could be 9502 related?
Later I'll do 50MHz but I'm not confident it'll make it go any faster.