Spitz wrote on 2025-05-31, 10:03:

@sdz M-M-M-MONSTER great job! Is there anything I can support You with?

Thank you! At the moment, the limiting factor is free time. This project is pretty much on hold since my last post, and will probably be for the next few months.
Besides a few remaining BIOS related issues (that I'm sure can be fixed with some effort), the major issue is the lack of sound. I tested a Yamaha YMF724 card, via an expresscard to M2 adapter -> M2 to PCIe x16 -> PCIe to PCI bridge. It works fine under XP, but not under 98.

adamnfs26 wrote on 2025-05-17, 18:21:

so why not open source this, id love to take on my voodoo 4s and make one my own , or sell a kit with just the fpga needed to make one.. or sell em for a resonalbe price ?

otehr wise ill just build a normal retro 3Dfx pc and all this work was for nothing

Maybe check the previous posts?

Out of curiosity, why are you even messing with the BIOS? Even if you get it to work, you will only make it work for this one particular laptop, which you had already done before by routing the LVDS cable directly to the card. It won't be some generic solution that would make your Voodoo MXM card work on every laptop with an MXM slot. Why not start testing the two-VSAs card which is something that offers a much bigger benefit?

I'm messing with the BIOS because this allows the card to be used as a primary card, which means Windows98 support (and DOS). Also, I'm doing this for fun.
I already got it pretty much working. Yes, it will work only for this particular laptop, and that is fine with me.
To make the card universal and have it work in any (any ignoring whitelists) laptop with MXM3.0/3.1 slot, it would need to have an MXM compatible VBIOS. At the moment I haven't looked into this, I have no clue if it's possible or not. The LVDS can easily be routed to the MXM conenctor.
The two VSA card is already tested and works just fine.

sdz wrote on 2025-06-02, 19:05:

I'm messing with the BIOS because this allows the card to be used as a primary card, which means Windows98 support (and DOS).

Which brings a question: Is it possible to use a laptop with an MXM slot but without an iGPU? That way, the BIOS will select the GPU in the MXM slot to be the primary one by default, right?

For example, my old HP Compaq nx9420 has an MXM slot but doesn't have an iGPU (since the CPU it has is the Core Duo T2500 which doesn't have an iGPU). Why not use such a laptop?

If the laptop doesn't like the VSA non MXM compliant VBIOS, it makes no difference if it has an iGPU or not.

A few more soundcards arrived, but none of them worked. In fact, besides the video card and the SATA controller in legacy IDE mode, no other PCIe/PCI device would work (tried even some network and USB cards).
Even tried with the Voodoo4 in the expresscard slot, and the network card shoved into the MXM slot (videocard worked, network card didn't).
In device manager, all PCI/PCI bridges would be detected, if a new hardware was added, it would be detected, but as soon as a driver was installed, it would just throw an error 10, like this:

Under XP/Linux, everything was fine. Spent quite a while investigating this, looking at BARs, MMIO windows, IRQs etc, and trying various things. Couldn't find anything wrong.

This was with 98 installed in APM mode, so I went the ACPI route (which I already knew was partially broken).
In ACPI mode, it would do this:

and say that :
"This device is not working properly because the BIOS in your computer is reporting the resource for the device incorrectly (Code 9)".

No other PCIe/PCI device would be detected. Tried various things again, and ended up looking at how the PCI resources are exposed to the OS via ACPI. Tweaked that.. until I got 98 detecting PCI devices, but broke XP and Linux:

[ 0.141099] acpi PNP0A08:00: _OSC: OS now controls [PCIeHotplug PME AER PCIeCapability LTR DPC]
[ 0.141212] acpi PNP0A08:00: [Firmware Info]: MMCONFIG for domain 0000 [bus 00-3f] only partially covers this bridge
[ 0.171713] pci 0000:02:00.0: can't claim BAR 0 [mem 0xe0000000-0xe7ffffff]: no compatible bridge window
[ 0.171827] pci 0000:02:00.0: can't claim BAR 2 [io 0xf000-0xf0ff]: no compatible bridge window
[ 0.171947] pci 0000:00:19.0: can't claim BAR 2 [io 0xefe0-0xefff]: no compatible bridge window
[ 0.172048] pci 0000:00:1f.2: can't claim BAR 0 [io 0xefb8-0xefbf]: no compatible bridge window
[ 0.172163] pci 0000:00:1f.2: can't claim BAR 1 [io 0xefac-0xefaf]: no compatible bridge window
[ 0.172277] pci 0000:00:1f.2: can't claim BAR 2 [io 0xefb0-0xefb7]: no compatible bridge window
[ 0.172389] pci 0000:00:1f.2: can't claim BAR 3 [io 0xefa8-0xefab]: no compatible bridge window
[ 0.172498] pci 0000:00:1f.2: can't claim BAR 4 [io 0xefd0-0xefdf]: no compatible bridge window
[ 0.172609] pci 0000:00:1f.2: can't claim BAR 5 [io 0xefc0-0xefcf]: no compatible bridge window
[ 0.172720] pci 0000:00:1f.3: can't claim BAR 4 [io 0x0400-0x041f]: no compatible bridge window
[ 0.187668] pci 0000:00:01.0: BAR 13: no space for [io size 0x1000]
[ 0.187762] pci 0000:00:01.0: BAR 13: failed to assign [io size 0x1000]
[ 0.187854] pci 0000:00:19.0: BAR 2: no space for [io size 0x0020]
[ 0.187949] pci 0000:00:19.0: BAR 2: trying firmware assignment [io 0xefe0-0xefff]
[ 0.188064] pci 0000:00:19.0: BAR 2: assigned [io 0xefe0-0xefff]
[ 0.188161] pci 0000:00:1f.3: BAR 4: no space for [io size 0x0020]
[ 0.188255] pci 0000:00:1f.3: BAR 4: trying firmware assignment [io 0x0400-0x041f]
etc.

Then fixed it for other OS-es as well. TL;DR version:
-re-implemented the root-bridge resource set (MCRS) and made _CRS a method that simply returns it instead of doing run-time calculations (seems to work just fine with any OS/DRAM size).
-split the ISA/PCI I/O aperture into two WordIO descriptors
-dedicated IO (Decode16, 0x0CF8, 0x0CF8, 0x01, 0x08) descriptor
-replaced several regions with one 256 MB block at E000 0000h so large (>128 MB) BARs can be mapped cleanly under Linux
-kept a separate 128 MB prefetchable window at D800 0000h.

There was also the issue that SeaBIOS would load the VGA ROM right into one of those regions. That's also fixed now.
acpi PNP0A08:00: ignoring host bridge window [mem 0x000c8000-0x000cbfff window] (conflicts with Video ROM [mem 0x000c0000-0x000c9fff])

Now PCIe/PCI works under 98/XP/Linux with ACPI.

I had the SATA controller initialized in IDE Legacy mode (IRQ 14 and 15). This now caused an issue under 98 with ACPI (resource conflict for IRQ 15), and would not detect the ODD anymore. I changed the controller initialization from IDE Legacy to IDE Native mode. 98 would fail to boot, but using R. Loew's PTCHSATA fixed this. Currently, the 98 installation is pretty vanilla, only using PTCHSATA and PATCHMEM.

The USB controllers (the southbridge ones) now work under 98. Shutdown also works now from 98 (and it actually powers off the machine), but it needs a bit more work as after switching to IDE native and installing PTCHSATA, it throws an error at shutdown: "The volume that was removed had open files on it. Next time please check first to see if the volume can really be removed. Press any key to continue".

Also completely disabled from the BIOS the on board audio.

Now, can I get audio working? Of course not...

YMF724/744 cards now install just fine:

Playing anything or even touching the volume slider kinda freezes the system (cursor is still moving but mmtask stops responding).

AU8810 card installs ok, and I can hear actual sound playing through it, until I restart the system. After that, 98 fails to boot (until the card is removed or driver uninstalled from safe mode).

Under XP, YMF724/744 and AU8810 sound cards work just fine.

The shutdown issue with the SATA controller in IDE native mode and R.Loew's PTCHSATA ("The volume that was removed had open files on it. Next time please check first to see if the volume can really be removed. Press any key to continue") is fixed with the 239887UP.EXE 98SE Shutdown Supplement patch.

Besides the lack of audio, windows98 seems to run really well on this system.

I tested the sound cards with the OEM BIOS.
AU8810 behaves the same, and prevents windows from starting.
YMF7x4 works a little better. Media playback works (but the whole system freezes after a couple of minutes). MIDI playback works but goes wonky after 2-3 seconds. Also, when the card is connected, the USB controllers don't work anymore.

I could also enable DMA for the SSD, and it went from around 2.5MB/s to :

Pretty decent performance.

I'm always lurking this thread.

Great work and I love that you're down to the fiddling. Even is some might not understand "why" you do what you do, I completely get it.
Keep it up and keep up the fun of it!

Love seeing more!

If you've got a working USB controller now you might be able to get a USB Audio class 1.0 sound card to work. The cheap $2 ones from eBay work like this, and the Behringer UCA-202 and clones , and I have also had good luck with Logitech Z-150 usb powered speakers. You won't get AdLib in DOS but basic sound should at least work. No drivers are needed.

Hello! I always enjoy seeing the progress of your project.

I'm sorry this is off topic, but I'm more interested in the PCIe x1 to MXM carrier than the MXM board itself.
Are you planning to open source the design data for the carrier board?

@tehsiggi Thanks! It is pretty fun, I have never messed with coreboot/SeaBIOS and this low level x86 stuff before. And if all goes well, the end result will be a pretty sweet (at least for me) W98/XP laptop (and maybe DOS, though I doubt it).

@onethirdxcubed I tried an UAC1.0 sound card, and it did seem to work just fine. Still, I would like to get a proper sound card working, and have functional MPU-401, for reasons 😀

@kagura1050 I don't mind the off-topic! What kind of PCIe x1 to MXM adapter do you need? VGA, DP, HDMI, LVDS, external power or just from the x1 slot (max. 25W as per PCIe spec).

A CMI8738 to Mini PCIe or M.2 sound card (with MIDI serial port and speaker amplifiers) would be a great hardware project to pair with an overpowered laptop like this.
Alternatively, you should be able to run the Yamaha XG soft synth and not even notice the performance hit.

I have done some research into writing a WDM HD Audio driver for Windows 98 and it should be technically possible, though not all the features like jack retasking or EAX can be implemented. No one has made it happen though. R. Loew tried to backport the Win2k HDA Bus drivers with no success. The 16 bit windows 3.1 driver sort-of works in 9x but breaks power management and gets very unstable when the swap file is used.