VOGONS


First post, by riplin

User metadata
Rank Newbie
Rank
Newbie

Matrox Mystique PCI BIOS disassembly here.

Matrox G100 AGP BIOS disassembly here.

Matrox G200 AGP BIOS disassembly here.

Matrox G200 PCI BIOS disassembly here.

Matrox G400 AGP BIOS disassembly here.

Some quick analyis:

- The G200 AGP and PCI BIOSes are almost the same, they could have been merged, there's only two places that really differ; the AGP bus setup and the device ID (The PCIR structure is what's holding this back since the device ID's differ).
- The G400 is very close to the G200 code base, with only G400 specific stuff different.
- The G100 BIOS is clearly older than the other BIOSes. At some point they replaced the VESA implementation in this codebase. There are also a number of bug fixes missing in this BIOS (mostly to do with disabling interrupts during sensitive operations). The code is smaller, yet feels more wasteful with large tables.
- All BIOSes check to see if they are running on an Intel Triton 430FX chipset and if that's the case, they configure the video card to not do retries (this is in violation of the PCI spec according to the datasheet).
- All BIOSes check to see if they are running on an ALI Aladdin V chipset and if that's the case, they configure the chipset to disable fixed VGA Framebuffer.
- All BIOSes reboot the chip on startup and they take their sweet time. This is probably why it takes so long for these cards to show an image on startup.

The BIOSes all love to call back into their own interrupt handlers with functions that they themselves don't implement, leading me to believe it's depending on something like UNIVBE or some other extension to help them.
They also call back into themselves for other reasons which makes figuring out what it's doing really annoying.

I focused on the memory timing stuff and I think I found a "bug" in the G200 BIOSes. It's loading a default timing value that's meant for the G100 card (the value is the same as the G100, but the register has changed and now bits are falling in reserved sections).

I also tried figuring out the DDC code, but that's pretty dense to get through.

If anyone has any more information or wants to help, let me know!

Edit: some more findings:

The G100 BIOS also doesn't cache the PCI Bus, Device ID and Function ID of the card, so every time it needs to talk to the PCI configuration space (which is a lot), it searches for the card all over again. This is all IO space comms, so it's pretty slow. The G200 and G400 BIOSes cache this value.

There is also speed sensitive code in there. A few places doing jumps to the next instruction between IO operations and a couple places that run an empty loop for a number of cycles.

There is some vestigial data and code in these BIOSes that could be cleaned out. Some places also have inefficient instruction encodings that can be fixed.

There is a print screen handler in all of them that’s pretty useless.

Some functions could have their input and output registers reshuffled to make them more easy to use, saving more instructions.

Also a bunch of nops in functions and between functions and data (for alignment). Some of the nops in functions result in misaligned code. Go figure.

I wish the creator of GX00VBE would open source the code so those extra VESA modes could be put in.

Last edited by riplin on 2025-05-05, 17:29. Edited 5 times in total.

Reply 1 of 8, by Nemo1985

User metadata
Rank Oldbie
Rank
Oldbie
riplin wrote on 2025-04-27, 23:30:

I focused on the memory timing stuff and I think I found a "bug" in the G200 BIOSes. It's loading a default timing value that's meant for the G100 card (the value is the same as the G100, but the register has changed and now bits are falling in reserved sections).

Very interesting finding, fix the bug would let the g200 have higher perfomance?

Reply 2 of 8, by riplin

User metadata
Rank Newbie
Rank
Newbie

That would really depend on how the values are interpreted by the card. I haven’t gone through the trouble of figuring that out yet. There’s so many interesting things to look at.

Reply 3 of 8, by vvbee

User metadata
Rank Oldbie
Rank
Oldbie

The G100 is a close iteration of the Mystique, so you might compare those. The G550 is the remnants of the buried G800, should be close to the G400 but how close? It has a dual texturing pipeline but works with G400 drivers from a year prior.

Reply 4 of 8, by riplin

User metadata
Rank Newbie
Rank
Newbie

I was intending to also disassemble the Mystique (not the 220, no data sheet for that one), Millennium and Millennium II BIOSes, but I’m taking a bit of a breather. These things take a long time to disassemble and annotate. Only the PCI version of the G200 was quick because it was so similar to the AGP version.

Edit: I also looked at the G450 BIOS, but it's larger than the G400 BIOS by 2KB + "extra" (BIOS files have to be multiples of 512 bytes and that's reported in the 3rd byte). There's 338 bytes at the end. Also, I don't have the data sheet for the G450 and given that they added DDR memory support to this card, the memory timings are going to be completely different. A large part of that code is going to be: Unknown value written to Unknown register. Not really useful.

Reply 5 of 8, by riplin

User metadata
Rank Newbie
Rank
Newbie

I added the Matrox Mystique PCI BIOS disassembly.

I also had a look at the Millennium and Millennium II BIOSes, but the datasheets don't document any of the indirect registers. These contain the PLL setup registers, so kind of flying blind there. 🙁 I also had a look at the Atlas and Athena, but those are very different from the other chips. They emulate older hardware through software. When a Hercules / MDA / CGA register is poked, an interrupt is generated and the BIOS will then see what register was accessed and apply an equivalent change to the VGA registers. brrrrr. 😖 Not touching that.

So I think I'll keep it to the BIOSes I have disassembled right now and annotate those as much as I can. I've already done more work in the G200 BIOS, but I'll have to port those findings over to the other BIOSes. Keeping them all in sync is a lot of work.

Reply 6 of 8, by analog_programmer

User metadata
Rank Oldbie
Rank
Oldbie

Good job! A G100 BIOS modification with proprietary Matrox Simple Interface (MSI) 3D API support (like in Mystique videocards) will be something cool.

The word Idiot refers to a person with many ideas, especially stupid and harmful ideas.
This world goes south since everything's run by financiers and economists.
This isn't voice chat, yet some people overusing online communications talk and hear voices.

Reply 7 of 8, by weedeewee

User metadata
Rank l33t
Rank
l33t
riplin wrote on 2025-05-05, 17:27:

I also had a look at the Millennium and Millennium II BIOSes, but the datasheets don't document any of the indirect registers. These contain the PLL setup registers, so kind of flying blind there. 🙁

I was wondering if you also used the sources from the linux fb driver and X window system video driver as possible information sources to further annotate the disassembled code ? If at all usable & possible.

Right to repair is fundamental. You own it, you're allowed to fix it.
How To Ask Questions The Smart Way
Do not ask Why !
https://www.vogonswiki.com/index.php/Serial_port

Reply 8 of 8, by riplin

User metadata
Rank Newbie
Rank
Newbie

That’s a good idea, I’ll have a look at those.

As for the other bioses, it’s not mainly a lack of documentation that’s hindering me there. It’s a lack of understanding 😀. There’s a lot going on and sometimes functions do things that are seemingly unrelated to each other. Very annoying.