elcrys wrote on 2026-08-10, 20:22:

When connected like this, the motherboard sends 1 long, 3 short beeps (no video card or bad video RAM), then proceeds to boot with a black screen.

This is the interesting part to me.
What happens if you attach no screen at all, leaving the output empty?

Don't have a thorough answer, but something to be suspicious of... last year I lost 2 afternoons of playtime figuring out that I had one or more DVI cables that work with Radeons but not Geforce. Thought I was having a pandemic of dying cards and monitors. Seemed to be something to do with whether they tried analog first or not. There seem to be pure digital cables with no analog mode too, or maybe mine had a bad wire.

Anyway, was an eye opener that you don't just have a card<>monitor compatibility thing, but also a card<>cable<>monitor love or hate triangle in some instances. So would suggest you try the most theoretically compatible monitor, and every cable you can lay your hands on.

Good point about the cables. I was testing this card more thoroughly a few years back and I believe I tried more than one cable. Come to think of it I have one DVI cable marked as faulty, because I had some problems with it in the past, but it turned out to be a compatibility issue later on. Currently I have two DVI cables at hand + one DVI-HDMI adaptor, everything is DVI-D (Single Link). So these are all pure digital. When I look in the Sil154 datasheet it doesn't specify which type of cable it wants, it only mentions "a single link interface" and "standards compliant with DVI 1.0 (DVI is backward compliant with VESA P&D and DFP)". Now, when I look at the VESA P&D these were also available in a digital only variant (P&D-D), question is what was the standard back then and what the card wants. Perhaps the safest bet would be to try a DVI-I dual link cable. I will try to dig out more cables for testing and we'll see.

tehsiggi wrote on 2026-08-11, 13:25:

elcrys wrote on 2026-08-10, 20:22:

When connected like this, the motherboard sends 1 long, 3 short beeps (no video card or bad video RAM), then proceeds to boot with a black screen.

This is the interesting part to me.
What happens if you attach no screen at all, leaving the output empty?

I believe I tested this back then (it wasn't in my recent test scenario) and it was the same result, but I will need to check this again, probably with the new cables when I find some. I also tried some hot-plugging, also without result. I guess when you switch from VGA to DVI there is a new EDID negotiation so that doesn't solve the issue.

Also I was thinking about modding the BIOS in RAM (using VGA BIOS shadowing), something like this: Re: Outputting 720x400@70Hz with the ATi R300 DVI output in DOS, but I will save it for later.

Does Windows recognize the monitor connected through VGA? Does it display correct supported resolutions list in settings or you are able select any resolution up to 2048x1536?

Hello, I have the same card and it is working in the BIOS under DVI-D (single-link). The monitor is an NEC Multisync 2090UXi, it's not a newer kind but neither is it old for the DVI era. The motherboard is KT333 based and the port is universal AGP 2.0. Unfortunately, Windoes is currently setup to use a NVIDIA card so I can't give you the VBIOS version too easily, unless you have some alternative method.

Most of the main BIOS is disabled to free up resources or has been set to some performance setting. If I remember correctly, the only thing that wouldn't stick was 'Turbo' RAM.

Hope that helps! 😀

Interesting, that would mean DVI-I, or DVI-D (dual link) is not necessary and the card can work on modern-ish monitors (as confirmed from other sources). Also, I didn't realize you cannot connect DVI-I to LCD monitors, at least not to those I have available.

I used NSSI (https://www.navsoft.cz/products.htm) for vBIOS extraction, this is a DOS SW, you don't need to boot Windows.

tehsiggi wrote on 2026-08-11, 13:25:

elcrys wrote on 2026-08-10, 20:22:

When connected like this, the motherboard sends 1 long, 3 short beeps (no video card or bad video RAM), then proceeds to boot with a black screen.

This is the interesting part to me.
What happens if you attach no screen at all, leaving the output empty?

I finished another tests and I can confirm if I leave the card disconnected (no VGA or DVI cable) the system beeps the same (1 long, 3 short) as with the DVI cable connected.

I tried to find another DVI cables for the test, but it seems I don't have any other, I will need to source them externally. I did find my EDID emulator, another DVI (dual link) to HDMI adaptor and an active HDMI to VGA adaptor so I was trying combinations like Card -> DVI-HDMI -> HDMI-VGA -> Monitor, or Card -> DVI-HDMI -> EDID emulator (set for 720p) -> HDMI cable -> Monitor, but still nothing. As soon as you want a digital output, the card refuses to cooperate.

kokornov wrote on 2026-08-12, 18:08:

Does Windows recognize the monitor connected through VGA? Does it display correct supported resolutions list in settings or you are able select any resolution up to 2048x1536?

Yes, the monitor is correctly recognized by its name and there is a list of resolutions compatible with it available. The maximum was 1280x1024 at 75 Hz, which is correct.

Based on your description I didn't think it was a BIOS issue, until I took a second look at the version you're running. I was leaning to hardware, but given the huge difference with versions it might be worthwhile flashing it. Lucky you, it seems I have the newest version known to mankind.

Do you think the analog signal passes through the chip? If it does then it seems unlikely to me that the chip would be the cause, it just seems unlikely that only digital breaks but analog still works. Maybe it's worth inspecting the legs to see if one's lifted? I see there's a couple of traces below the chip, on the neck and on the side where the analog signal comes out of the plug, so maybe it doesn't pass though the chip. I just don't know ...

Is your one (snickers) DVI cable known to be good and working? Shop thrift stores for a spare, I see them there every time.

Great, thanks for the BIOS! This gets even more interesting. Turns out my version 2.1D.29c (dated 06/29/00) is newer than yours 4.1F.14 (dated 10/05/99)! And if you compare the headers, my version comes directly from S3, yours mentions Number Nine and identification of the model. I think we are onto something here. That would also explain misidentification of BIOS version in Number Nine drivers as the structure is different. I don't know what Number Nine was doing with late production cards, but it's entirely possible they killed DVI output in the process. Now I only need to find a way how to try the original BIOS. I would very much like to avoid soldering. Maybe someone else will chime in with some information about flashing procedure for S3 cards.

Btw. there is a revision on the bracket, like here https://theretroweb.com/expansioncards/s/numb … -nine-sr9-sgram
Mine says "Rev 04".

I will also try to buy more DVI cables, just in case.

I see what you mean about the version/dates in the drivers. Yeah, this is getting stranger with every turn. I agree there's enough evidence to support the BIOS being the cause, but what's going on here? I wonder if N9 shuttered their doors around that time, or, maybe this is a custom BIOS with an unobvious purpose that actually saw real world use.

You might want to create a new thread specifically about flashing S3 cards to redirect the focus. Also, my sticker says Rev 3 which is consistent with what NSSI reports.

Yeah, could still be the cable. It wouldn't be bad to rule out that possibility. 😀

That sounds like the system does not detect any monitor. TMDS encoder is likely irrelevant (unless the card tries to talk to it via I2C, one could even remove it, and the system won't fail to boot).
I'd check the 5V rail at the DVI connector, without it, the EDID can't be read from the monitor and the monitor won't usually assert HPD. Then check the I2C bus through which EDID is read, and check the HPD signal. The Savage4 Extreme likely has separate DDC buses for VGA and DVI.
If it helps here is a Savage4 Pro DVI schematic: S3 Savage4 Pro PCI low profile HDMI

SUCCESS! I have a functional DVI on my card!

TL;DR:
1. It's a BIOS version issue, as I suspected — you need version 4.1F.14 for DVI to work.
2. DVI cable compatibility ruled out.
3. Monitor compatibility ruled out.
4. The 41F14.VBI BIOS is likely not fully compatible with Rev. 004 cards under Windows.

Longer version:

I finally got two new NOS DVI cables, and it didn't change a thing — the system still sends 1 long, 3 short beeps and there's no picture.

After that, I decided to test the older BIOS. The easiest way to do this without flashing is to swap the cached video BIOS in main memory (shadow RAM).

The first step is to enable "Video BIOS Cacheable" in the motherboard BIOS setup. The default video shadow window most BIOSes enable is only 32KB (C0000–C7FFF), but the 41F14.VBI BIOS is 40KB, so it spills 8KB past that into the C8000–C9FFF range — meaning "C8000-CBFFF Shadow" needs to be enabled too.

Then I spent a long session with claude.ai and DEBUG trying to unlock the shadow RAM region for writing. This is chipset-specific — for my QDI Advance 10T (VT82C694T), it goes like this:

1debug
2o cf8 60
3o cf9 00
4o cfa 00
5o cfb 80
6o cfd ff
7i cfd
8q

(Offset 0x61 of PCI configuration space, Device 0 — the host bridge — is the "Shadow RAM Control 1" register, and it controls the C0000h-CFFFFh range in four 16KB blocks.)

Then I spent an even longer session trying to actually write the new video BIOS in. In theory this is very easy; in practice it's quite difficult. C0000-C9FFF isn't just "some RAM" at that point — it's the live, currently-executing video BIOS, and the system is still relying on that exact code for any INT 10h call. DEBUG's own copy command doesn't disable interrupts while it works, and interrupts kept firing throughout, causing repeated hangs. I'll spare you the details — in the end I gave up on doing it manually and used SVBL (Shadow Video BIOS Loader) instead:
Re: S3 AGP Cards (and possibly others) Too Bright

This tool has very limited chipset compatibility on its own, but since I could already unlock the shadow RAM manually via DEBUG, all I needed was its generic "already open" mode:

1svbl.com /c:opened.cps /b:41F14.VBI /k /l

However, the utility printed two messages:
Shadow RAM close error
Incorrect video BIOS checksum in shadow RAM

Still, I went ahead and disconnected the VGA cable and hot-plugged in DVI. The result was a black screen, and at that point I'd practically given up — but then I remembered the PC can boot even with no cable connected at all, so I set everything up in autoexec.bat and attempted a headless start into Windows 98 with the DVI cable plugged in. After powering on, there was the same beep code as always, but then, to my great surprise, right after SVBL executed, the picture came on for the first time ever on DVI! I soon learned the drivers hadn't loaded (resolution restricted to 640x480 - probably a consequence of the checksum failure), but this still definitively proved there was nothing wrong with the hardware — cables, card, and monitor were all fine. Also HWiNFO confirmed BIOS version 4.1F.14 is in.

After that, I ventured to investigate why the checksum was failing. I found that two bytes get flipped every single time SVBL runs:

offset 0xDE9: should be 0x31 - became 0xCE (0x31 XOR 0xFF)
offset 0xDEA: should be 0x01 - became 0xFE (0x01 XOR 0xFF)

I also learned that this didn't matter for DOS — I ran some gaming tests and all video modes worked fine, on both VGA and DVI. All the DOS utilities correctly showed the new/old BIOS version too.

To fix the two flipped bytes, I used DEBUG again:

1debug
2e c000:0de9 31 01

I then pulled the video BIOS from shadow RAM and compared it to 41F14.VBI again — this time it was a perfect, byte-for-byte match. For DOS, nothing changed: everything still worked fine, even over DVI. For Windows, though, there was an interesting change — the OS now attempts to load the drivers, but fails, leaving an active-but-black screen/freeze. This leads me to the conclusion that the BIOS might not be fully compatible with my revision of the card.

In the end, I achieved what I set out to do: solving the mystery of why DVI wasn't functional on my card. I now know the card itself isn't faulty, and it's not a matter of incompatible monitors or cables — it's simply that this card is a later revision for which Number Nine (N9) never bothered to adapt the BIOS they got from S3, and never bothered to test it either. Given both companies were on the verge of bankruptcy at the time, it's honestly no surprise.

I GOT IT WORKING IN WINDOWS! (sorry for all-caps)

All that was needed was to ditch piece of junk driver pack from N9 and install s3_savage4_4.12.01.8226
POST is still headless, but as soon as Windows loads the glorious all-digital picture is in with acceleration and everything!
Also the shadow RAM trick do downgrade BIOS is still needed. 2.1D.29c is definitely bugged.

sdz wrote on 2026-08-19, 14:58:

That sounds like the system does not detect any monitor. TMDS encoder is likely irrelevant (unless the card tries to talk to it via I2C, one could even remove it, and the system won't fail to boot).
I'd check the 5V rail at the DVI connector, without it, the EDID can't be read from the monitor and the monitor won't usually assert HPD. Then check the I2C bus through which EDID is read, and check the HPD signal. The Savage4 Extreme likely has separate DDC buses for VGA and DVI.
If it helps here is a Savage4 Pro DVI schematic: S3 Savage4 Pro PCI low profile HDMI

Thank you for the tips. You got a nice project there. Do you happen to know if BIOS is somehow flashable via SW?

Thanks @elcrys for the investigation and thanks @bartonxp for sharing the bios 4.1F.14 with dvi compatibility. The attached s3flash tool let me flash the said bios (card is installed in a board with Intel 440LX chipset, clean DOS 7.10 environment, bios version originally dumped 2.1D.29 without "c", see attachment). Once more dumped the bios afterwards and the comparison with the provided 4.1F.14 was positive (no deviations). No guarantee it works on other systems, I just tried while also having the opportunity to unsolder the bios chip (32 lead PLCC SST39VF512) and flash it separately and put a socket to the card for better handling.

The DVI output now worked as stated but the following issues came along:

• Only able to choose resolution up to 1024x768 and max 60 Hz when connected via DVI. Tried using an inf-file for the display (Eizo S1910) but to no avail. Using the VGA input via adapter let's me choose the native max resolution of 1280 x 1024 @ max 75 Hz.

• 2D desktop operation shows no obvious problems but 3D applications that worked before most likely won't start or will freeze the system. Tried re-installing the driver, lowering the AGP speed to 1x and disable side band addressing (SBA) using S3Tweak but didn't work. After re-flashing the original bios version 2.1D.29 there is no more the option to enable/disable SBA as before in S3Tweak and the 3D is working again. This might point to incompatibility issues with the used mainboard/chipset others had encountered with the combination.

• Some 3D application (GL Excess was it) did work though to some extend, but the screen would turn on and off intermittently, flickering badly.

• Curiosity: While having allegedly flashed version 4.1F.14 the S3Tweak "About" screen shows version 2.1D.09 (with deviation from original bios number) but NSSI in DOS environment shows 4.1F.14, after re-flashing the original bios 2.1D.29 the correct string is shown. According to the sticker on the bios chip it should have been version 4.1F.13b (was obviously not installed). After flashing 2.1D.29c the S3Tweak screen shows no "c" but NSSI shows the string completely...

Conclusion?
- s3flash seems to work, to be absolutely sure it would be necessary soldering and flashing externally
- bios version 4.1F.14 might be internally also 2.1D.09, DVI is indeed activated but somehow crippled at least on my system
- later versions 2.1D.29 might be tuned for more compatibility working surprisingly stable on this system
- trying on other mainboard chipsets would be interesting and may lead to different conclusions, anybody?

Well that sounds like a lot of fun. </sarcasm>

Yeeesh, well I am glad you made some progress. It is sounding like different BIOS versions are good for different things. I wonder if utils that force BIOS shadowing could be persuaded to stick BIOS of choice in the shadow RAM so you could switch back and forward.

bjrnx wrote on 2026-08-31, 23:10:

... The DVI output now worked as stated but the following issues came along: […]
Show full quote

...
The DVI output now worked as stated but the following issues came along:

• Only able to choose resolution up to 1024x768 and max 60 Hz when connected via DVI. Tried using an inf-file for the display (Eizo S1910) but to no avail. Using the VGA input via adapter let's me choose the native max resolution of 1280 x 1024 @ max 75 Hz.

..[/list]

Good find about the s3flash, I wasn't aware this tool existed. For the record, I didn't have any problems with limited resolution or with 3D acceleration on my test system (VIA 694T). In fact, Windows set a correct native mode for my monitor (1280x1024 @ 75Hz) automatically, although this is outside Sil154 specification (max 1280x1024 @ 60Hz). As a result the picture was a little blurry, but once I lowered refresh rate to 60 Hz, picture was perfect.
Did you try the driver version I mentioned? I would also suggest a clean installation of Windows 98, to avoid issues with remnants of other versions of graphics drivers.
As expected 2.1D.29 version is slightly older than my 2.1D.29c and is also not adapted by N9 (judging by BIOS strings).

Also I forgot to mention another interesting observation:
2.1D.29c runs GPU @ 160 MHz, Memory @ 166 MHz;
4.1F.14 runs GPU @ 143 MHz, Memory @ 166 MHz.

The driver used is the one you mentioned, and it is the only driver version ever used on that installation, no other S3 driver, no other graphics card ever. After flashing the bios I purged it once with DH Driver Cleaner Professional Edition plus removing the relevant inf-file from Windows folder and reinstalled after only Standard PCI adapter was detected. I think I'd rather try the SR9 on another board with a later chipset like VIA KT... or 440BX to rule out the probably unfavorable combination of picky boards/chipsets/drivers. The bios of the AL440LX board I used unfortunately doesn't have options to influence possibly problematic AGP features. Another try is to leave only the graphics card installed and remove everything else.
What I didn't observe was the change of GPU clock IIRC, I think it stayed on 160 MHz but I may have to flash once more to be sure.
Did you try flashing the bios or have you used the shadow loader all the time?

All my experiments were done with the shadow loader. Tool used for clock detection was HWiNFO and it could also detect BIOS version correctly (original and later the swapped one).

I remember having similar problem with 3D acceleration while I was trying to run GeForce 6200 PCI on Pentium 1 platform. Turned out there was some CPU instruction missing the nvidia driver needed. 440BX and P3 was fine though.