Is this V4/V5 only? No Voodoo1 like in pcem?

Good question. The patch omitted the makefile change but the DXE is required:
# Environment variables:
# CPU optimize for the given processor.
# default = pentium
DXE=1 use DXE modules.
# default = no

I set DXE=1 so the DXE is used, I hope that's ok.

Since we are using DXEs already it's probably the best thing to do in case we ever decide for some reason to update the DXE.

ggorts_ wrote:

Is this V4/V5 only? No Voodoo1 like in pcem?

I don't know how true that is but I can try running it on the pentium 1/voodoo 2 combo and see what happens.

Not necessary if you're busy, I just thought to mention it so the expectation is there.

Well on the voodo 2 it exits from grSstSelect: non-existent SST. So apparently the code paths really do matter (which is unfortunate)

It seems that the glide3 only has h5, but there is an older glide3x package on the site you referenced.

I think glide3 is supposed to support voodoo 3 as well. But I really don't remember, it's been so long.

I'm sure that's right. There is an SDK, just checked, and it has win32 binaries. I wonder if it's just the source code limitation but the binaries are available?

This at that site has the H3: 3dfx Glide3.1 Driver SourceKit Rev. 3.0. We can always build that later, but it seems like it should eventually work out. Edit: for linux but it may be possible to find the differences and build it, if it's necessary.

Yeah, the H4=1 option should be Voodoo 3. I forgot Avenger was the codename.

Perhaps the source code could be added to your tree before the web site disappears. 😀

Indeed. Upload a complete diff. Then I'll start a repository on github

I downloaded the files (I was just joking about the web site because of hdpmi and other sites; sometimes there really is a loss of files permanently). The patch is actually complete against the glide3x which you linked to, but I can upload something tomorrow if that's convenient.

ggorts_ wrote:

Yes, I'll attach the patch now and then a minute or two attach binaries for h5 (voodoo4/5?). This issue was the assembly inline which was likely older gcc. Please verify patch (includes szo pointer fixes).

_grLfbWriteRegion() still has the wrong changes.

Is that the only line? If so, I'll make the changes and upload tomorrow. The patch is complete so it is possible to rebuild binaries and tests before then.

ggorts_ wrote:

Is that the only line? If so, I'll make the changes and upload tomorrow. The patch is complete so it is possible to rebuild binaries and tests before then.

All your changes in _grLfbWriteRegion() are wrong.

SOme of the changes are correct I think, I just missed a few lines in haste. Please verify that the changed lines are correct.

Please correct those lines in your source tree and rebuild binaries and tests.

I think these are correct: grLfbReadRegionOrigin. Those lines should serve as reference to grLfbWriteRegion. I just missed them in editing.