@mbandalauk
For now, yes, my focus is on MXM variants. After I'm done with these, I'll likely make these cards in PCIe/PCI/AGP, just for completion's sake.
I could make a batch/batches, but what I really can't do is ship who knows how many packages.

@K4sum1
What do you mean by legacy coreboot setup? The laptop runs mainline coreboot, with patches specific for my use case. I will release everything, but it's not ready yet, and I also need to clean things up a bit.
In the meantime, is there anything specific you want to accomplish?

@Deksor
While it would be really nice, it won't be either cheap or easy doing such a thing.

Last week I finally got time to finish the cards and started testing. I'm glad I did, as compared to the first card I made (and used a lot), some of the other cards had an issue.

Sometimes, the system would just start with a black screen (failure % varied by card). System reboot would not help. Investigated a little, it wasn't the FPGA or the VSA-100. That left the video scaler IC.

Connected an oscilloscope to the scaler IC reset signal, the two power rails (1V8 and 3V3), the crystal, and the SPI bus. When it worked it looked like this:

Top line is the reset line, followed by the 1V8 rail (3V3 not in this screenshot, and part of the SPI bus), crystal, and the SPI clock line.

When it failed it looked like this:

It wasn't even attempting to start. Now, the weird thing, when it got into this state, manually pulling the reset line low and releasing it wouldn't actually reset the IC.

The little blip on the reset signal is caused by the RC on the reset line. Then, the line goes low. This is actually the scaler IC pulling its own reset line low (.....) . The reset line was also connected to the MCU, but that GPIO was set to high impedance.
Now, there is no documentation in the datasheet about power sequencing, ramp up, reset signal, etc. I tried changing how the power rails come up (order and timings) and asserting reset at various points. This only made it worse.

Lastly, I increased the capacitor on the reset line. After this, it would always attempt to load the firmware, which was nice.

What wasn't nice is that after a few power cycles, it again started showing a black screen (always). This was weird, as I was still seeing activity on the SPI bus (which did not happen before, black screen and SPI activity).
Tried another board, it worked for a few power cycles, then permanently failed as the previous one.

Removed the flash ICs and dumped them, random bytes were changed compared to the bin I flashed. The scaler has no reason to write anything in the flash IC. All settings that can be changed are saved in the I2C EEPROM.
The issue was, at power off, as the rails were falling, the RESET line would always be a little higher than the 3V3 line (because of the larger cap on the reset) and the scaler would just start doing crap as its power rails were falling and reset was still high. Tied the flash write protect line low, and now it can't do that anymore and everything works fine.

I have to say, powering on a couple of Voodoo4 laptops at the same time sure is satisfying.

I'll upload everything soon (maybe even today).

I have uploaded the files here: https://sdz-mods.com/index.php/2024/06/04/voodoo-4-m4800/

And also in this post. It contains editable PCB/schematic, pdf schematic, GERBER files, BOM, P&P files, and binaries that need to be flashed (VSA-100 VBIOS, VSA-100 EDID, PCIe-PCI bridge config, scaler firmware, scaler config, FPGA bitstream, MCU firmware).

sdz wrote on 2025-09-01, 16:07:

I have to say, powering on a couple of Voodoo4 laptops at the same time sure is satisfying.

Amazing work! Its so nice to follow your progress on this cool project.

@janih
Thanks! It is pretty much good to go as it is (as described in the first posts, XP only, OEM BIOS).

What's next is to get sound working under 98 with coreboot/SeaBIOS, but all that is currently on hold, and I don't know when I'll start working on it again.

sdz wrote on 2025-09-05, 13:52:

@janih
Thanks! It is pretty much good to go as it is (as described in the first posts, XP only, OEM BIOS).

What's next is to get sound working under 98 with coreboot/SeaBIOS, but all that is currently on hold, and I don't know when I'll start working on it again.

My country is still watching You! 😉 Congrats!
shorturl.at/CB6zf

Some recent software updates that might help with this project:

CSMWrap 3.0 now supports forcing the primary display adapter for Windows 98 https://github.com/FlyGoat/CSMWrap/releases/tag/3.0.0

Sweetlow has written a NVMe driver for Windows 9x: https://github.com/LordOfMice/Tools/commits/m … ster/nvme9x.zip though note that it can only boot from a CHS partition in the first 8gb because that's all that works with the legacy int 13h emulation.

My WDM HD Audio driver is now fairly reliable with Intel chipsets and Realtek codecs as are in this laptop, but still doesn't support power management well (because I still haven't been able to get 98se working in ACPI mode on ANY laptop with HD audio). https://github.com/andrew-hoffman/WDMHDA/releases

@onethirdxcubed

Thanks! I was aware of the NVMe driver and CSMWrap, those are really nice projects.

Your WDM HD Audio driver sounds perfect for the M4800 with coreboot/SeaBIOS. The project is currently on hold, but I will give it a shot when I have some free time. (Have to un-nuke the HD audio, and actually get it working on XP/Linux/whatever first, as it never produced any sound and I didn't investigate the issue).
Windows98 SE runs in ACPI mode on the coreboot/SeaBIOS Dell M4800.

I made some PCI VSA-100 cards, similar to the MXM cards, in the sense that they use the FPGA as a TMDS encoder (so I can fix from the FPGA the VSA-100 bug where the image is shifted to the right by 4 pixels when using NT operating systems).
At 720x400p@70Hz, they had the exact issue as the MXM cards, worked stable for a bit, until they got a bit hot. After that, on some HDMI monitors, the image looked messed up, while with other monitors it looked OK.

I always suspected that the reason for this is that in that mode the VSA-100 outputs a lot of jitter, even more when it gets hotter. Made a simple test with the FPGA, generated an image (just some color bars) and only used from the VSA-100 the pixel clock. When the VSA was outputting the 720x400@70Hz pixel clock, even the color bars were messed up on some monitors. So indeed, VSA-100 clock jitter.

Next, I tried various fixes inside the FPGA for cleaning that jitter (clock and data were both jittery btw, so data sampling was actually OK), including sampling the video data directly with the jittery clock, feed it to a FIFO, and using both available MMCMs to clean the incoming clock (also generate the rest of the needed clocks), then, read the data from the FIFO with the clean clocks and feed it to the TMDS encoder (also fed with cleaned clocks). This helped a bit but did not fix the issue.

So, I decided to look into what the VSA-100 VBIOS was doing when this resolution was set, compared to the other that worked fine, and found the reason why this was happening.
For some video modes, it used fixed 25.175MHz and 28.322MHz clocks, while the modes that worked fine used programmable PLL clocks. I patched the BIOS to use programmable PLL clocks for all resolutions via the DVI path, and that worked. Now, all DVI resolutions worked just fine on all monitors.

During testing, I also noticed that both my card and a reference V4 card with reference BIOS had quite a bit of jitter on the VGA output when using the same affected video modes. Applied the same above fix also on the VGA path, and now that is way cleaner than the reference card with reference BIOS.

Since I was there, I decided to implement other fixes in the VBIOS, here is the changelog:

-Replaced fixed 25.175 MHz and 28.322 MHz VGA clock sources with equivalent programmable VSA-100 PLL clocks.
Applied programmable clocks to both DVI and VGA paths.
Fixed severe digital RGB video clock & data jitter in legacy modes such as 720x400@70 Hz.
Improved VGA signal quality and reduced visible noise in several modes compared to reference BIOS on reference cards.
Preserved the original resolutions, refresh rates, and CRTC timings.

-1280x1024 DVI fix
Fixed 1280x1024@60 Hz failing over DVI in DOS/VESA modes that affected reference cards with reference BIOS.
Prevented the BIOS from incorrectly modifying valid standard timings when 1280x1024 is absent from the EDID detailed-timing list.
Covered VESA modes:107h: 1280x1024x8
11Ah: 1280x1024x16
11Bh: 1280x1024x24

-Dual-output fix
Changed POST monitor detection so DVI is still probed when VGA is already detected. On reference cards with reference BIOS, if both DVI and VGA were connected at power on, only VGA would initialize.
When both cables are connected at power-on, VGA and DVI now initialize simultaneously.
Preserved the existing behavior when only one display is connected.

If there is any interest, I could provide BIOS files for various reference cards with these fixes.

Now back to the M4800. Flashed the patched BIOS, and 720x400@70Hz is working properly on the V4 laptop:

Since now, with the patched VBIOS, I could actually have VGA working at the same time as the digital video output that is driving the panel, I decided to get that working on the laptop.
This was not easy. The motherboard has a VGA mux IC, that is controlled by the EC, by commands sent over the LPC bus. I should have probably hooked up a logic analyzer to a system with the OEM BIOS, log the LPC bus traffic with and without the dGPU installed, and see what is difference. Being lazy, I went the brute force with reverse engineering the OEM BIOS approach. After 2 days of work:

Now we have coreboot, V4 as the primary (and only card) with both digital video output and VGA working!

Also re-enabled HDA, and pulled an upstream commit that sent the unmute command to the EC, and now sound is working and audible (XP and above).

Next thing on the list was getting Intel SpeedStep actually working under XP. Coreboot's ACPI implementation regarding this was a bit too new for XP to understand. Downgraded that and now the CPU cores sit at a nice 800MHz under XP when the system is idle (instead of sitting at a fixed 3.x GHz and only clocking lower if it got too hot):

Hello Daniel,

Very interesting work- it isamazing.

Yes, I would be very interested in obtaining those BIOS files, if you are willing to share them.

Best regards,
Oscar.

@osckhar Thanks! Will do.

Some more updates:

-fixed the SeaBIOS bug/quirk where the caps lock LED (probably the other LEDs were affected as well, but I don't have the palmrest connected at the moment) would not work under DOS/W98. Now, it works under all tested operating systems.

-during disk benchmarks under XP, I noticed that the system is a bit stuttery, even if the benchmarks have really good results (>400MB/s). After that, also noticed that when the system is idle, one CPU core has a 50% load, with "System Idle Process" eating all of that. From previous experience, this can mean IRQ issues. Checked with perfmon, and sure enough, there is an IRQ request storm, about 179000 IRQs/seconds. This doesn't happen under Linux, only noticed it under XP. 98 seems fine, but I have yet to confirm.

For XP, as far as I know, there really isn't an easy way to see which IRQ (and which device if the IRQ is shared) is at fault. I had some suspicions that it might be due to the SATA controller when initialized in IDE native mode (have yet to confirm this). I did add back the AHCI mode, and made a compile switch so I can select between AHCI, IDE native and IDE legacy modes. However, I didn't really feel like rebuilding and reflashing the BIOS for these tests.

Coreboot/SeaBIOS don't have a regular PC BIOS setup screen, so I added one (with default values, data saved in nvram etc):

Since I was there, I also added support for identifying the MXM cards (M3800, M4800, M5800, LVDS or eDP models and hardware revision for each) as well as implemented the bidirectional communication protocol through the PCIe-PCI bridge GPIOs that is used for talking to card (that was used in the Control Panel XP application shown some posts back).

Now, from this setup screen, MXM card info can be read and writeable parameters can be configured (can also be done later in the OS).

I might make it look nicer, it's still very much a work in progress.

I'm also interested by the patched V4 bios !
I now own a v4 myself, and also just to put it on TRW (with credits ofc) for easier access

@Deksor will do! It will take a bit of time, as I have to make them for all the variants out there.

Regarding the IRQ storm under XP, it is indeed because of the SATA controller. It only happens under XP, when the SATA controller is initialized in IDE native mode. IDE legacy and AHCI work just fine. Windows98 or Linux aren't affected by this, and work OK in IDE native mode.
I will investigate more at a later date, as I already spent the last day trying to fix this with no results (made a lot of changes, and now it is configured identically to how the OEM BIOS does it).
Still, not a huge issue, DOS/98 work in IDE native mode, XP and above can use AHCI with no issues. In both cases, the drive does >400MB/s.

Last night I tried onethirdxcubed's WDMHDA driver under W98 (installed in ACPI mode) and it works perfectly! Only issue I had was that when playing sound, moving the mouse would cause the sound to start looping the last 2 seconds or so, and the mouse to stop working. Rest of the system was responsive though. I had HDA and USB on the same IRQ, and after moving the HDA to a non-shared IRQ, it works without issues! Played a bit of Quake2 and it was a really smooth experience.

Edit: coreboot/SeaBIOS repo here: https://github.com/sdz-mods/coreboot_m4800_3dfx

Reworked the BIOS setup screen:

Re-wrote the control application, it was XP (and above) only before and required .NET Framework. That's no longer needed. Also, the core/memory clocks can now be changed live. Before it was done via registry, and applied by the 3dfx driver (with the card initialized as a secondary adapter, the OC settings would not stick).

Now with 98 support:

And for completeness:

On a different topic:

Modern Linux with patched xf86-video-tdfx (PLL-related fix and added EXA 2D acceleration (XAA was dropped more than a decade ago)).
It is very usable even at 1080p.