Probably it was only you, I didn't write a PM 😀

analog_programmer wrote on 2024-03-04, 15:34:

smola wrote on 2024-03-04, 15:20:

I'd like to answer but seems I'm too fresh fish on forum and can't reply PM msgs. So... Dunno how to solve this issue, seems I need to send more posts to get higher rank to reply PMs...

Sorry, I also wrote PM to you forgetting that you still can't answer. If I'm not mistaken, after you post 20 comments in the forum's threads you'll be able to send PMs.

Oh my, I'm a total dumb 😀 PM to me was sent by analog_programmer, so sorry to you and Dominus for the mess 😉 I promise, I'll get better 😉

@analog_programmer:
Due PM rules for fresh users, if you wanna contact with me, just install signal app from https://signal.org and send me your phone number on PM, I can read msg and then I'll answer you on signal via text.

smola wrote on 2024-03-04, 16:39:

@analog_programmer:
Due PM rules for fresh users, if you wanna contact with me, just install signal app from https://signal.org and send me your phone number on PM, I can read msg and then I'll answer you on signal via text.

Ok, I tried this messenger (desktop version for Linux) and I can't register account without "smartphone", 'cause it demands some QR-code scanning through Signal mobile app. I'm not surprised of this as in last years almost every "free" corporate software pushes people to use pocket tracking devices (so the personal tie can be sealed), but maybe you'll be surprised that I've stopped using "smartphones" since android "kit-kat" (I think that was the name for the OS version) was current. Yes, I'm using "dumb" phone with buttons and firmware (no OS) for many years and I'm still living normal human life 😁

Sorry for this off-topic post. You'll be able to communicate through forum's PM-system soon (if I'm not mistaken the restriction is valid if you have less than 20 thread's posts) 😉

I fully understand your point, moreover, I'd like to do same thing like you did, just drop smartphone and back to classic cell, but real life is tough nowadays 😉 I hope soon I will break the PM limits and we will talk normally 😉

Fantastic investigation! I cant decide what is more impressive, the level of RE or the fact you are using Notepad to read code 😮 😀

analog_programmer wrote on 2024-02-28, 15:57:

I thought that this fog effects are used to limit the view distance and thus the weak GPUs of the time are partially offloaded from texturing and rendering of some "far" objects.

fog is free on 3dfx, and 3dfx didnt do early out on Z buffer hits, thus there is no performance difference.

rasz_pl wrote on 2024-03-14, 17:45:

Fantastic investigation! I cant decide what is more impressive, the level of RE or the fact you are using Notepad to read code 😮 😀

hehe, thx, actually I use notepad++ on win and mcedit on linux console, sometimes nano/vim depending of platform

smola wrote on 2024-03-15, 13:46:

rasz_pl wrote on 2024-03-14, 17:45:

Fantastic investigation! I cant decide what is more impressive, the level of RE or the fact you are using Notepad to read code 😮 😀

hehe, thx, actually I use notepad++ on win and mcedit on linux console, sometimes nano/vim depending of platform

wait a minute, this download/file.php?id=185967&mode=view indeed isnt notepad, so npp with no toolbar/tabs/line numbers/syntax highlighting ??? 😮 To me this is that Cypher "All I see is blond, brunette, redhead" scene :]

Time to send a patch https://github.com/sezero/glide/blob/ee380948 … minihwc.c#L1579 😀

1if (hInfo.boardInfo[monitor].h3Mem == 8) {
2        hInfo.boardInfo[monitor].pciInfo.deviceID = SST_DEVICE_ID_H3 ; /* HACK ALERT: restricting to single TMU for Velocity? */
3      }

Looks like this line was there at least 21 years ago, thats as far as git blame goes? Whoever wrote that comment already knew bad things were afoot.

Reading it back with hindsight this:

* this prompted me to look into the problem, my first focus was unreal, because I had it, after poking around the internet the p […]
Show full quote

* this prompted me to look into the problem, my first focus was unreal, because I had it, after poking around the internet the problem with the lack of fog was solved by adding this entry to the registry:
{
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\Display\xxxx\Glide
key: FX_GLIDE_NUM_TMU
value: 2

was a really good clue. Glide library forcing Banshee restrictions disables second TMU on 8MB Velocity while Unreal Engine recognizes full V3 card thus forces dual TMU use?

wait a minute, this download/file.php?id=185967&mode=view indeed isnt notepad, so npp with no toolbar/tabs/line numbers/syntax highlighting ??? 😮 To me this is that Cypher "All I see is blond, brunette, redhead" scene :]

Your're mad, you know that? 😉 But i like it 😉 And that woman in red... Mmmm, it was great idea, no doubt 😉 Anyway, I composed this screenshot to show all differences in src code, assembly lng, addresses and offsets, because I know that most ppl don't understand output from diff file. Code was highlighted in viewers from total cmd, which look almost same as notepad - I could use more sophisticated editor/comparator but... There wasn't necessary to use heavy weaponry to shot a fly 😉 Simplifying everything is what I like.

Time to send a patch https://github.com/sezero/glide/blob/ee380948 … minihwc.c#L1579 :-) […]
Show full quote

Time to send a patch https://github.com/sezero/glide/blob/ee380948 … minihwc.c#L1579 😀

Copy code to clipboard

1if (hInfo.boardInfo[monitor].h3Mem == 8) {
2        hInfo.boardInfo[monitor].pciInfo.deviceID = SST_DEVICE_ID_H3 ; /* HACK ALERT: restricting to single TMU for Velocity? */
3      }

Well, right now is too early I suppose. There is no "clear explanation" what exactly conditions should be meet to change card's id 😉 For sure #5 shouldn't be changed, but what about #4 which are "slower" variants of avengers gpu/velocity? Adding additional condition to existing one would block others. I mean more tests are necessary, but these cards are very rare, so it may happen... Never? Right now best solution is to use original Amigamerlin 2.9 drivers, and in case of fog problems, just replace installed glide2x.dll to my patched dll. And when we'll collect more data and we'll find some patterns related to chip revisions/device id, then patch to source code on github would be provided 😉

Looks like this line was there at least 21 years ago, thats as far as git blame goes? Whoever wrote that comment already knew bad things were afoot.

Meantime, after I found this issue and sent description to the forum, I did more research and I found some additional things. Seems that line of code was added by guy called Atai on june 99, according to change log included in minihwc.c:

1** 151   6/07/99 3:10p Atai
2** report as Banshee if it is an 8M board

So, previous patch with inverting fogtable could work correctly for few months, but this one was just kill'em'all 😉 I think I should make small update to original text, we'll see 😉

Reading it back with hindsight this: (...) was a really good clue. Glide library forcing Banshee restrictions disables second TMU on 8MB Velocity while Unreal Engine recognizes full V3 card thus forces dual TMU use?

I'm not sure if this happens, I didn't check it after patch. However it's possible because banshee has only one tmu. Also forcing 2nd tmu to 'on' state via registry in fact enables both tmu to work with velocity and finally gpu has same efficiency as younger sister v3 2000 which has been confirmed by few tech portals that times. Velocity has just less vmem by half, but I did another research and it's possible to replace sgrams on pcb to twice large capacity and this should "convert" velocity to v3 2000.

cheers

update: Well, this guy Atai from change log, seems to be the same 'Anthony tai', who in reality isn't the same guy with name Anthony who made v6000? I bet this is same person 😉 If so, I've question, can you throw a bit of light to the situation with fog table and inversion + any info related to banshee problems/differences to banshee/velocity/2000? I'm sure many ppl will be very grateful.

edit:
* added 2 links with problematic cards

smola wrote on 2024-02-20, 18:04:

[translation corrected by Gallu - big thx] […]
Show full quote

[translation corrected by Gallu - big thx]

3dfx Velocity 100 AGP part#2 [25-years old bug in the system] part#1.

info:
* as it turns out that my velocity does not always work as it should, that's because in some of the older games it has a serious chaffing on the screen, the problem was described and reported on vogons by our lukas12p, it related to malfunctioning games nfs2se and carmagedon2. I also experienced this problem with unreal gold, it worked in glide mode but there was no fog.... for nfs3 it worked ok - strange
* this prompted me to look into the problem, my first focus was unreal, because I had it, after poking around the internet the problem with the lack of fog was solved by adding this entry to the registry:
{
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\Display\xxxx\Glide
key: FX_GLIDE_NUM_TMU
value: 2
} string type key, xxxx can be different, depending on how many graphics cards were installed earlier, normally 0000, in my case it was 0018 but it's a test setup for different configurations, you know 😉
* it solved the problem with unreal, but it did not help completely with the 2 previous games
* I only had nfs2se, so I started digging around in sdk glide, I fired up IDA and disassembled the nfs2se exe, I found where the init fog table is, I deactivated it in the new exe, the test went to v2 because there the fog works properly, and indeed it is deactivated, the game looks bit worse but works ok, then I swapped v2 for velocity and.... game fired up without fog but works ok, ugly chaff disappeared 😀
* comparing screenshots of fog on/off it seemed to me that the z-buffer for fog is inverted, because in the background/away the image was ok with textures but crap on close objects, I concluded that fog is "inverted"
* I also checked v3 2000 16MB and the problem was not there - very strange
* I did some tests on diagnostics files for 3dfx, for glide2 crap with fog, but for glide3 it was ok - that was even stranger, because after all they are the same cards
* carving, notes from a chat with a buddy, to whom I reported live the progress of work 😉
{
* i have made many attempts to reverse the loop that generates values for fogtable maps but that had made small differences and improvements, that wasn't it
* in the meantime I made a lot of inline patches, there was a problem with free space in the exe code, I finally fixed it with hiew by using call/jmp, because I did not want to build a whole new environment for the debugger, masm compiler, then recompile and glue exe 😉
* at this point I speculated that the bug must be in the gpu after all, because they implemented the fog arrays in reverse, in the game there are a total of 20 arrays for different cases, each has 64 bytes and contains values in the range 0-ff, there is a function in glide2x.dll that generates this, it is used when you need to reverse the loop to generate this array in reverse order, only a few bytes are missing for the inline patch 😉
* but on the other hand, maybe I could stick the code to reverse the array itself after its generation, then I don't need to patch glide, just paste it in the game exe... such a reverse-order function after the execution of the original procedure, hmmm
* another situation: I have invented an algo for inverting index values from the range 0-63, why should I f* with inverting items, when I can change the main function for calculating values 😉 just for any given 0-63 'do not' and then add 64, perfectly reverses the value, for this I need 15 bytes free, because there is align16 in the exe, I should fit 😀
* and again: i added a patch in glide2x.dll to generate fog table in api and it partially improved, bugs in gpu at 100%
* and the disappoinment: I slowly started to give up on this 'fog' in nfs2, a lot of testing and it f* doesn't work, a little improvement but I wasted my time, it's easier to turn it off and it works perfectly 😉 I think I'll give up coding today and listen to music on my headphones 😀
* I finally found a legitimate carmagedon2 installer, I managed to fix the exe by turning off the fog and it finally looked normal
* in carma2 i tried to invert fog tables, negate indexes but it didn't help much, it must be a bug in early versions of gpu, right after them voodoo3 2000 16mb came out and they worked ok
* I searched the internet, found glide source codes, heavy digging in docs, pdfs, etc...
* and finally: I cracked this 3dfx 😀 the problem is with the card and drivers, the fog works beautifully with nfs2se and carma2 😀
* it wasn't until I downloaded src from glide drivers and rummaged through this crap that I found the place, they had huge problems because of this bug and fixed it wrong, it could have contributed to the downfall of the company too
* it's 1 byte patch, classic jnz->jmp 😀
}
* in the changelog at the beginning of the code there is a visible mention of problems with the fog table, unfortunately no comments in the code but it is visible where it was applied, below important info about changes in the gglide.c file:
{
124 12/18/97 2:13p Peter
fogTable cataclysm
(...)
186 11/18/98 6:29p Dow
Fixed clear problem on banshee/avenger
187 11/24/98 4:21p Jeske
make sure we don't try to apply the banshee (rev<3) fogTable hack to avengers with (rev<3)
}
* as you can see the problem appeared in december 1997 (when the shit hit the fan) and they didn't fix it until a year later in november 1998, unfortunately this fix is bad, because it "spoils" all avengers with revision lower than 3, i.e. for example my velocity 100/v3 1000 8MB and v2 2000 8MB from lukas12p - he even described the problem on vogons but 0 help, a difficult topic 😉
* it can't be ruled out that in banshee chips and early avengers there was a bug in the gpu that required inverting registers from fog and hence these additional conditions, but a quarter of a century has passed and finally it can be corrected 😉
* the list of vulnerable cards is as follows: deviceID=3 and devRev <3, if the card had a bug in the gpu, it will work ok, but if it did not, it will be a chaff with fog on the screen, the bug applies only to games using native glide2x, it is not present in glide3x.dll and that is why nfs3 works ok, the bug also does not apply to all sorts of wrappers like d3d, opengl, nglide etc. - deviceID not quite like that, i will explain later
* crafted glide2x.dll from Amigamerlin v2.9 package, 1 byte classic jnz->jmp patch and.... after dropping it into the directory with the game nfs2se beautiful fog and everything works ok 😀 same with carmagedon2, it is great but there was a dilemma in the analysis because... WHY did my card which has deviceID=5 jump to the code which is intended only for deviceID=3??? - a real brainfu*k
* it made me realize that the error must be somewhere else, even deeper - so, we need to go deeper
* since the critical value is in the condition (gc->bInfo->pciInfo.deviceID == 0x3) I searched all the files from the sources for the string 'pciInfo.deviceID', I found several, the most interesting one is minihwc.c with the following lines:
{
if (hInfo.boardInfo[monitor].h3Mem == 8 ) {
hInfo.boardInfo[monitor].pciInfo.deviceID = SST_DEVICE_ID_H3 ;
}
}
* well I can't believe that someone could write it like that, just a quick verification of the constant SST_DEVICE_ID_H3 and... bingo 😀
{
#define SST_DEVICE_ID_SST1 1
#define SST_DEVICE_ID_SST96 2
#define SST_DEVICE_ID_H3 3
#define SST_DEVICE_ID_H4 4
#define SST_DEVICE_ID_H4_OEM 5
#define SST_DEVICE_ID_AP 6
#define SST_DEVICE_ID_L_AP 6
#define SST_DEVICE_ID_AP_OEM 9
#define SST_DEVICE_ID_H_AP 15
}
* this is where the original error lies, it's in the minihwc.c file inside the hwcInit() function without any checking what card is inserted, the gpu is determined only by the size of the memory, what size? 8MB 😀 so that... if a card with 8MB of vram is inserted, the function will rigidly change the deviceID of the card to SST_DEVICE_ID_H3, that is 3, that is banshee...
* this is a serious bug, because all v3 cards with this amount of memory are susceptible to this regardless of the card ID, and that's why my velocity had the deviceID swapped from 5 to 3 and triggered register inversions from fogtable, this also explains why the v3 2000 lukasa12p works badly - it has 8MB too, f* me 😉
* summarizing this error in 1 line: if vmem 8MB then deviceID=3 and any card becomes voodoo banshee 😀 well, I can't believe how such code can be written 😉
* the only thing left is to disable this nonsense initiation and patch glide2x.dll - I still can't believe what I am seeing 😉
* the patch involves changing the byte under offset 140BF: 75->eb, this will force an unconditional jump to the next instruction with the omission of replacing the card's deviceID
* glide2x.dll patched, tests with nfe2se and carma2 passed, beautiful fog, unreal gold added, because earlier it had a hiccup with operation and did not always start in glide mode and... now beautifully works from the get go, it is the right fog 😀 complete success
* you can now permanently replace this dll in %systemdir% and enjoy trouble-free operation of 8MB vram cards with glide2, this patch may solve problems with other untested games, please comment
* at this time I am curious how this situation affects banshee, unfortunately my card has a burnt gpu and I have no way to check it
* and all owners of v3 cards with 8MB of vram please check the original drivers amigamerlin v2.9 + corrected glide2x.dll, pay attention to the fog or rather lack of it or the havoc it makes on the screen 😉
* used re techniques and static analysis + tools: ida, hiew, totalcmd

it finally works 😀 after 25 years 😀

* hopefully this was NOT the nail in the coffin for 3dfx (but it could have contributed just like the acquisition of stb and sinking $141M + the release of gf256 with t&l by nvidia) - it's a serious flaw and it's clear they didn't patch it, well, we'll probably never know
* inception ended on level 3, 1: fogtable off, 2: fogtable on and disable inversion of values in fogtable registers, 3: fogtable on and disable card swap to banshee if vram 8MB - today I'll end the day with a beer, more than one for sure 😉
* and a final riddle: why do I use the word inversion and not negation, what is the difference in asm between neg and not instructions - this was 1 of the interview questions that candidates for threat analysts position were asked at our company 😉

web:
* lukas12p problem (nfs2se, carma2): 3dfx Voodoo 3 8MB problem
* OpenRift problem (rune gold): Rune Gold: Grey Models in Glide Mode
* Ozzuneoj problem (descent 3): 3dfx Velocity 100 (Gateway OEM Voodoo3 1000G) graphics corruption in Glide?

edit:
* added 2 links with problematic cards

Just wanted to say THANK YOU smola!
Re: 3dfx Velocity 100 (Gateway OEM Voodoo3 1000G) graphics corruption in Glide?

I have had a "Voodoo3 1000G" (a Gateway branded Velocity 100 8MB) since November of 2016 which had these fog table related issues. I now have three of them and I just happened to get around to testing them again recently. If you hadn't posted this fix when you did, they likely would have been stuffed back into a box along with my note from 2016 explaining the issues. Now, they are functional cards. 😀

It's good to hear that another three beauties back to a life. Happy Easter Day!