Rayman Pirate-Community

Reese Riverson wrote: Thu Oct 23, 2025 4:37 am That is an interesting thought, come to think of it, I know VRAM usually counts against the system memory within the limits. I wonder if the audio cards memory are even factored in the same way?

I wouldn't think so. I imagine that since soundfont programming is a kind of "once-off" thing (or at least not done very often), the data is passed word-by-word from the CPU to the soundcard by an I/O port using the "out" or "outs" instructions. So it's not mapped into the CPU's address space at all, it's entirely separate. Could be wrong though!

Reese Riverson wrote: Thu Oct 23, 2025 4:37 am So I decided to partially disassemble my 486 media system so I can get some nice pictures and document things, while getting a look at the capacitors on the motherboard. Maybe you'll like seeing this, PluM?
MIDIMAN MM-401

Wow, an 8-bit ISA card! I've never seen one of those in real life

Anyhoo, here's my blog post, here's hoping someone finds it useful: https://www.vigovproductions.net/intera ... us12V.html

PluMGMK wrote: Thu Oct 23, 2025 10:06 pm Wow, an 8-bit ISA card! I've never seen one of those in real life

Yeah, I've seen at least a dial-up modem like that too, but I guess you don't need more than 8-bits to run external midi devices!


I also finally found that other 486 PCI motherboard I had on hand, and with a bit of digging I was able to identify it.
Thankfully the Retro Web was able to help narrow it down, it's a Shuttle HOT-433 (REV. 1) motherboard. I've even found an interesting post from a user on Vogons with their system specs over a decade ago mentioning what I believe is one of the AM5x86 CPUs I have on hand that I've been wanting to put back into play.

Another interesting fact is they ran one of the exact Matrox graphics cards I wanted to use to push for high resolution Windows 3.1 as well. So this could be a promising start to my journey.

Another fun fact is this is the very motherboard I tested my USB PCI card on, and had my flash drive pull up in MS-DOS back in 2018 with an AMD 486DX2 behind it.

Here are some pictures from 2018 regarding the USB:
Have you ever thought a 486 CPU would ever see USB in it's lifetime, PluM?

Reese Riverson wrote: Fri Oct 24, 2025 12:12 am PluM

Dagnabbit! You dang reds, always discriminating against us greens. Why, back in my day...

I'm glad you found the motherboard! Not only that, but managed to figure out which exact model it is. It's also just great to see a CRT monitor in those images, even if they're older ones. Also, the thing we talked about on Discord where older GPUs had slots to upgrade them is pretty cool.

That's amazing! I'm not surprised about the 486 doing USB, but the fact that you could read a USB stick from DOS, and install SmartDrv over it, is something I didn't think I'd see! And that was years ago

I once read an article that 10% of pcs still used XP as their primary computer. Now I was not shocked… until I went to my favourite comic book store in the mall.

They still use XP to process payments! Which means that they’re using XP to keep track of purchases. I’m not sure how secure that is, but when I asked the guy running it (older man) he said “If it works it works, don’t need to change it.”… and I’m like. Yeah good point.

So now I’m wondering how many businesses still use operating systems like XP purely because they’re run by older individuals who cannot figure out newer software and computers. Have yall ever experienced something like this?

PluMGMK wrote: Fri Oct 17, 2025 8:29 pm Forgot to post this last night, but here's an updated version, which prints some output before the FPU exception hits (or is supposed to hit anyway!)

Alright man! Got some news for you, my friend! I got my replacement for the DALLAS RTC chips in, and I got my AMD 486DX4 rig up and running, despite having some issues with the compact flash card self-nuking itself when files written vanish, and files deleted re-appear... (It self-nuked in the middle of using Winimage to make a backup)... FORTUNATELY however, I was smart and already had a backup on my storage server so! On it lives!

So first, a video of it with the /s switch:



Then system pictures!

I love it all so much!

The good news is that after a week of quasi-sleepless nights, I finally have a definitive explanation for why the program crashes on my machine, which can be seen at https://github.com/PluMGMK/vbesvga.drv/ ... 3448566106 and https://github.com/PluMGMK/vbesvga.drv/ ... 3448587606
It turns out that my firmware's System Management Mode code is quite careful about floating-point exceptions, and even sets the control word to mask them all – but it turns out that on my CPU, loading the control word can itself cause an exception to be raised! What's worse is that when the exception is delivered, it literally does this: For those not familiar with assembly, "jmp $" basically means "keep executing this same ineffectual instruction over and over again, forever"

And instead of loading the control word, the firmware could have just reset the FPU, which would have been totally safe because its state is fully backed up earlier in the SMM entry code

So basically, my firmware is overengineered and buggy, and I can't see a way to overcome it other than patching it and flashing (which I don't really want to risk doing ). Though I suppose I should check for firmware updates, in case MSI did fix this at some point. I don't think I've ever risked doing a firmware update on this PC, so it's possible that there was a fix in the past which I missed!

EDIT: just downloaded the latest firmware update from https://www.msi.com/Motherboard/Z97-GAMING-3/support and analysed it in IDA: the relevant code is exactly the same, so that also wouldn't help

Ah, that's a shame about the firmware. I don't know an incredible amount of assembly, but I've had to use some 6502 for Famicom / NES purposes. I'd contributed a fair bit to a program named FamiStudio, an open-source DAW like program for composing using 2A03 / 2A07. The exports can play on the real console, hence the idea of working with some 6502 assembly in the process.

One of the things I'd worked on involved me to work with assembly, since it had to be functional on the actual hardware as well as the app emulation. I will say that it was fun to work with and try to optimise the instructions to save on cycles.

PluMGMK wrote: Sun Oct 26, 2025 3:56 pm but it turns out that on my CPU, loading the control word can itself cause an exception to be raised!

That's why one of the first things they teach you about C++ exceptions is not to throw exceptions from destructors.

Ah yes, that makes sense! Destructor raises exception, handler tries to destroy object, which re-raises exception – aaaah!

It's really interesting though, Intel's manuals are kinda vague on whether or not "fldcw" is a waiting instruction (i.e. one that can cause an exception to be raised). The opcode doesn't begin with 9Bh, so it "shouldn't" be, and yet I've tested it on two different CPUs (a 4th-gen Core i7 and an 8th-gen Core i5) and in both cases it is. I think I need to do another survey, but this time with a Win32 app that anyone can try (including Linux users via Wine).
I just need to figure out how exceptions work in Win32 first

Well that was rather unfortunate, Plum. At least you know it works well on a 486, hehe.

So in the end, what does this mean for your modern graphics driver then? Are you still able to tend to proper development regardless?

Oh this has nothing to do with the graphics driver!

The only reason it's on an issue thread there is that someone discovered a floating point bug in an old video player program and jumped to the conclusion that the driver was responsible. Once I concluded that it wasn't, everything else in that thread became a weird side quest

(Also, when you say "it works on a 486", that's not what it tells me: it tells me that the firmware in your 486 machine is not using the FPU stupidly, like my firmware is. The firmware in your PII laptop may well have a similar bug!)

Ah, okay, thanks for clearing that up. I guess I thought it affected it, but yeah I'm glad all is well then. So no point in me really running this FPU test on any further systems then.

But yeah, it does sound like the laptop may have a similar bug for sure, which is interesting! Which funnily enough, I think the BIOS settings are modified through some embedded version of Windows 3.1 too. I think it's no longer on that laptop specifically since I put a different drive in to install Windows 98SE from scratch, buuuut I do remember it existing on the other drive.

I guess the BIOS settings don't matter, it's just what code the firmware runs in System Management Mode (SMM), and how often that code is triggered by a System Managment Interrupt (SMI). I will most likely be doing another survey on whether or not the "fldcw" instruction causes an exception, and I'd like people to run it on as many systems as possible, just for data gathering!

Anyway, on a more positive note, as of today's v0.9.3 release, my VDDVBE.386 can finally boot on a modern GeForce

Then perhaps I should give you more information regarding that 486 system I ran your test on, so you have full data on hand for that system. Fortunately it's already listed on my site here when I built the system.

There will be another 486 PCI board for me to test this out on as well, whenever I get the other system built.

Also great work on the driver update! I can picture it now, I can just use one of my extra 1080 Ti EVGA cards just for Windows 3.1 for the grins and giggles.

I finally set up a Windows XP VM.

Why, you may ask. I have Wendy, my winXP pc right next to me at all times.

However, i set it up to make web graphics from old graphics that cannot be used on windows 11. Wendy is still my main machine, and i love her, but this is also convenient.

Convenience does help a lot in many situations for sure.

So an update to my post above, I got my new to me 486 motherboard in, which should even allow me to use my AM5x86 chip I once had in a previous motherboard that had unfortunate battery leakage damage. Whether or not I use that CPU in this or not, I have yet to decide.

I figured I'd best test this board immediately, since it did come from eBay, if there was an issue, I can have that taken care of.

So I nabbed the jumper settings from The Retro Web page on the board, configured it for a 486DX CPU since I nabbed that out of my CPU tray I keep in my drawer, grabbed a PCI S3 VGA card of some kind, and a PSU I used as a bench power supply test, hooked it up, and nothing.

I dig out my diagnostics card, plug that in, and there's no code, but I was missing 3.3V, but apparently it isn't exactly needed for most 486 boards anyway, but I wasn't sure about the PCI VGA card, but the ISA VGA card I tested didn't make it any better. So I tried a PSU from another chassis that did provide 3.3V, and still nothing. Though the keyboard LED's did flash this time around.

So at this point, I decided to go ahead and try a different CPU, so I grabbed a 486DX2 chip, and the system immediately posts.

I don't remember where that specific 486DX chip came from, as it was either a random thing I received many many years ago, or pulled from a random system that was dead, but so far I'm led to believe this specific CPU is just dead.



The jumper settings are exactly the same between a 486DX and 486DX2, so that's certainly not it.

-Edit-

Alright, so I went down a rabbit hole and I've forgotten that AT power supplies actually do not supply 3.3VDC.

So I'm actually betting the voltage regulator on that motherboard supplies both the CPU and PCI bus the 3.3VDC the system needs, and the first PSU I used was actually faulty since I was missing power to the regulator.

Yeah, the AT standard predates 0.35-μm CMOS, so 3.3 V wasn't a thing back then!

PluMGMK wrote: Fri Oct 31, 2025 7:14 pm Yeah, the AT standard predates 0.35-μm CMOS, so 3.3 V wasn't a thing back then!

Which is funny, because I was both right and wrong about what my issues were.

We know that 3.3VDC was missing on that motherboard, that much is true. It was in fact caused by a faulty PSU, but not because of a lack of a 3.3V rail on said PSU.

I'd say it has to be one of the 5V rails missing that supplies the power to the motherboard that the regulator relied upon or an under-volting situation. I can only be sure if I actually probe it, but I really don't think there's much of a need to concern myself over it, as we know that the motherboard fully functions with a known-working unit.

Yeah, trying to debug a PSU is a diminishing-returns situation for sure!

Actually, case in point: when I posted that video of the electrolytic cap blowing up, a kind person offered to send me a new cap, but I felt I had to decline and just buy a new PSU