Zooming out so we can see which pins are tied high/low would help...

Sorry, the full picture is available at TRW site. My card and its BIOS chip are identical.

if it is OTP,
which means One Time Programmable,
being the one time at the factory that it got programmed,
then you can not reprogram it and your only option is to find some eeprom chip that will fit the footprint .

I don't know if the chip is OTP or rebranded/relabeled EEPROM. UNIFLASH can not determine the chip type.

Uniflash is for motherboard ROMs, that are generally designed to be reflashable... not video ROMs. Older video cards were not designed to have writable ROMs.
Best guess for that chip would be an AT27C512R. Not erasable. You'd have to find one, program it yourself and fit it to the board. If you try and reflash the existing one you'll just remove more bits.

UNIFLASH can program some PCI cards with EEPROMs by using "/PCIROM" switch. Unfortunately it can't even read correctly the BIOS chip on my S3 ViRGE/GX card. I dumped the BIOS by using NSSI.

I don't want another OTP chip. So, it seems like the only option is to find something like SST27SF256 (I don't need redundant Trio3D BIOS in the chip) for surface mount + some (de)soldering work.

What exactly is the patch for correcting the brightness? If it's simply taking bits out of a value you might be able to get away with using the existing chip. You'd still have to unsolder it though, programming requires pumping VPP voltage into the chip which isn't exactly friendly for other connected parts...

I can see in the photo that pin 1 (A15) has options to tie it either high or low, so that's how the board is choosing which BIOS (virge or trio) to use; I guess if you wanted to replace it with an EEPROM you could remove that 0 ohm resistor (leaving pad 1 unconnected to anything), then use a AT28HC256 with pin 27 (WE#) cut short + tied to VCC and bodge pad 27 across to pad 1.

Two bytes are corrected: 0x20 to 0x00 and the checksum byte 0xE9 to 0x09.

That's totally doable for an OTP chip, no erasing required since you're only taking bits away, not adding them.

jmarsh wrote on 2026-04-25, 09:43:

That's totally doable for an OTP chip, no erasing required since you're only taking bits away, not adding them.

You "just" need a suitable progammer for that OTP chip, though, which might involve suppying +12V to a programming voltage pin. I don't suppose the excess bits can be cleared in-system on the Virge card.

Thank you, guys. But the problem with UNIFLASH remains 🙁 And I don't know any dedicated S3 flashing software.

P.S. I have some newer beta versions of UNIFLASH like 2.0-something, but they lack any documentation and I can't remember, if I ever used them.

Sorry, I'm a little off 😁

I have XGecu T48. So, I have to desolder the original OTP chip from the card, solder it to suitable adapter PCB, reflash it with the patched BIOS without erasing, desolder it from the adapter and finally solred it back to the card... And if it survives all those cycles, I will have working stock card.

Better off to buy some new EEPROM chip for surface mount.

I'm looking at the datasheet for AT28HC256, but I cant see A15 data line. At pin 1 there's A14 data line. On the TRW picture we can see that /WE pin 27 is connected to something and I have to check it, if it is Vcc or GND.

I've just tried something more proper.

I Installed in the system an older ISA video card, so the PCI ViRGE/GX to not be used/initialized at boot as primary video adapter. And finally the UNIFLASH gave me two identical BIOS dumps (the second one after a restart, just to be sure). But it still "says", that the BIOS chip is "unknown". Now I'm not sure, if UNIFLASH is capable to ever show the chip type for any PCI expansion card (for the motherboards it does).

I have to compare the UNIFLASH dumps to the one from NSSI, which I used to make the patched BIOS, and If they are 100% identical, I may take the risk to try if the original chip is EEPROM or OTP-ROM, as UNIFLASH always erases the chip before writing.

Correct me if I'm wrong, but when the (E)EPROM chip is erased, all the bits became 1 (low/no voltage "cell" = 1), so we have only oxFF bytes. In this case I don't see how it will be possible to turn 1 to 0 for 0x20 byte to 0x00 and 0xE9 to 0x09.

aVd wrote on 2026-04-25, 10:05:

I'm looking at the datasheet for AT28HC256, but I cant see A15 data line. At pin 1 there's A14 data line. On the TRW picture we can see that /WE pin 27 is connected to something and I have to check it, if it is Vcc or GND.

It doesn't have A15 because it's a 32KB ROM. The original ROM on your board has A15 (on pin 1) because it's a 64KB ROM. It's divided into two 32KB halves, A15 is the highest address bit so it effectively selects which of those two halves gets read from. On the PCB above the ROM you can see three pads labelled 1, 2, 3. Pad 2 is connected to A15, pads 1 and 3 will be GND and VCC, a 0 ohm resistor is used to bridge 2 of the pads to select which half of the ROM will be used. If you get rid of that resistor, the pin for A15 will be left floating. That's what you want if you're replacing it with an AT28HC256, because being an erasable ROM it has a new pin (WE#) and A14 is moved to the other side of the chip - that's why you'll have to bodge pin 1 to pin 27.

Correct me if I'm wrong, but when the (E)EPROM chip is erased, all the bits became 1 (low/no voltage "cell" = 1), so we have only oxFF bytes. In this case I don't see how it will be possible to turn 1 to 0 for 0x20 byte to 0x00 and 0xE9 to 0x09.

You can't erase an OTP ROM. You can program it multiple times which removes bits. In this case that's fine because that's all the patch requires.

jmarsh wrote on 2026-04-25, 11:20:

It doesn't have A15 because it's a 32KB ROM. The original ROM on your board has A15 (on pin 1) because it's a 64KB ROM. It's divided into two 32KB halves, A15 is the highest address bit so it effectively selects which of those two halves gets read from. On the PCB above the ROM you can see three pads labelled 1, 2, 3. Pad 2 is connected to A15, pads 1 and 3 will be GND and VCC, a 0 ohm resistor is used to bridge 2 of the pads to select which half of the ROM will be used. If you get rid of that resistor, the pin for A15 will be left floating. That's what you want if you're replacing it with an AT28HC256, because being an erasable ROM it has a new pin (WE#) and A14 is moved to the other side of the chip - that's why you'll have to bodge pin 1 to pin 27.

I agree, you are right. I just forgot for a moment, that the original unknown chip is 512k. So, it will be easier to just get new 512k EEPROM instead and double (concatenate) the patched ViRGE/GX BIOS, so it doesn't matter which pads are shorted with the 0 Ohm resistor.

jmarsh wrote on 2026-04-25, 11:20:

You can't erase an OTP ROM. You can program it multiple times which removes bits. In this case that's fine because that's all the patch requires.

If I'm right, think again. I can't make OTP "cells" high for bit 1 to became bit 0 as needed in my case.

EDIT. I have to write, not to erase bits, so you're right again.

What to do next?

Maybe I have to try some UNIFLASH modification/patching so it will not erase the chip before flashing.

The two halves of the UNIFLASH dump are not identical to the one from NSSI, so UNIFLASH is unusable in my case.

I have a DOS version of the Linux FLASHROM tool. I don't recall if it can flash EEPROM chips on PCI cards.

The only option left is (de)soldering + hardware programming.

aVd wrote on 2026-04-25, 12:21:

The two halves of the UNIFLASH dump are not identical to the one from NSSI, so UNIFLASH is unusable in my case.

I guess the NSSI dump is the "bad" one. Note that PCI BIOSes are generally run from shadow RAM, and not executed in place from the ROM chip. While the BIOS initializes the PCI ROM copied to shadow RAM, the shadow RAM is not yet write protected, and the BIOS can patch itself. PCI BIOSes often patch the PCI device number of the slot the card is installed in, or some linear base address, into the BIOS during initialization. NSSI is going to dump the shadow RAM contents.

I don't think you have any chance using Uniflash with the chip soldered on the S3 Virge card. The Virge card most likely is physically unable to generate write instructions to the OTP-ROM chip, so no kind of software can flash the chip "in system" / "in situ" (without desoldering). The tedious way of desoldering the chip from the Virge card, mounting it on a DIP adapter PCB, putting it into the T48 and then soldering it back to the Virge card would be a working method to modify it, yet you still would have to find out what kind of OTP-ROM this actually is to make sure you use the correct programming voltage. Using a new compatible flash chip is likely the best way to start. If that works, but you want to have the card look as original as possible, you can still try to patch the S3 OTP ROM that way.

Yep, I know, that NSSI dumps come from the shadow RAM, and I had some problems in the past while using it for dumping motherboards BIOSes. In this case its video card BIOS dump is Ok (I'm surprised as well) and the checksum is Ok too. The "UNIFLASH /PCIROM" dump turned out to be a complete mess comparing it to NSSI's one with wrong checksums for both halves (ViRGE/GX and Trio3D). Also the NSSI dump works fine when loaded into shadow RAM with RAMBIOS 1.5 or VGABIOS 1.10. The BIOS for this video card is old enough and is only 32KB in size, so it's a different story than motherboards BIOSes with compressed parts. It also starts with "magic" bytes "55 AA" for option ROM, so I doubt it will do some self-modifications while loading into shadow RAM.

Confirmed - I can't use UNIFLASH. And FLASHROM doesn't support such a PCI cards, so... hot-air gun, soldering iron and XGecu T48 will do the job. I know a trick to find the (E)EPROM chip ID with XGecu software, but as I wrote, I don't have a proper DIP28 adapter for this chip package type. I have to order a suitable EEPROM replacement chip + adapter with clamp.

I'm just wondering now, if it's worth the effort and the money spent for changing the BIOS chip, while I still have two pure software solutions for solving the "bright bug" on this card - using RAMBIOS to load the patched BIOS into shadow RAM or using self-made small com-executable for modifying one bit in registers for S3 ViRGE/DX/GX+Trio64V2/DX/GX cards.

jmarsh wrote on 2026-04-25, 11:20:

It doesn't have A15 because it's a 32KB ROM. The original ROM on your board has A15 (on pin 1) because it's a 64KB ROM. It's divided into two 32KB halves, A15 is the highest address bit so it effectively selects which of those two halves gets read from. On the PCB above the ROM you can see three pads labelled 1, 2, 3. Pad 2 is connected to A15, pads 1 and 3 will be GND and VCC, a 0 ohm resistor is used to bridge 2 of the pads to select which half of the ROM will be used. If you get rid of that resistor, the pin for A15 will be left floating. That's what you want if you're replacing it with an AT28HC256, because being an erasable ROM it has a new pin (WE#) and A14 is moved to the other side of the chip - that's why you'll have to bodge pin 1 to pin 27.

To me SST27SF256 chip looks fully compatible without the need to remove the resistor and use bodge wire. Its pin 1 needs +12V for erasing and after flashing with hardware (E)EPROM programmer it doesn't matter anymore if it will be connected to GND or +5Vpp (+5V is not enough to erase this chip). Data line A14 is at the right pin 27:

I'll just need to get SST27SF256 chip or pin compatible in SOIC package. Surface mount DIP is called SOIC, right? But maybe the original chip is with SOP or TSOP package. I have to measure its pin pitch.