RaVeN-05wrote on 2026-05-03, 17:36:Well I tried v2100 as "closest" to v1000.
Used Rebel Moon :
Unpatched:
init_gfx: about to cglLoad […] Show full quote
Well I tried v2100 as "closest" to v1000.
Used Rebel Moon :
Unpatched:
init_gfx: about to cglLoad
init_gfx() : CGL Load Failed error - - 0
Patched: (xor eax, eax)
init_gfx: about to cglLoad
About to cglQueryScreeb
Failure: Query Screen returned - 122
No CGL Found!!!!!! Using VESA driver.
We need to try to test on non Creative v1000 card owners. I am sure owners here.
What if cglQueryScreen is patched out in exactly the same way as cglboard present?
This is at offset 0x10551. Will give it a go tomorrow, it's time for bed here.
Also the mode numbers might be embedded into the driver. Will check tomorrow.
looks like 0 zero is always good sign, and later game crashes, so v2100 and probably v2200 soon of all are no go.
maybe v1000 non creative can work
I plugged some of the cglQueryScreen code into an Ai. It seems to suggest that it's looking for a specific non-verité chip (conexant) , but it's probably wrong. The 3db pci is a bigger card than the v2100 I have (stealth ii s220) with more chips, though that might be due better integration on the newer card.
so i need look closer to card, it could be GLINT at same board where Verite chip, or even unified? that was if true very ridiculous.
That's a pretty stupid idea of mine. I tried to get DeepSeek to disassemble the functions from vritb170 with the offsets and it gave give complete and utter garbage. On manual inspection, It does look for 0x1163 (Creative/Rendition) and 0x001 (V1000) in a BIOS call int 1A from protected mode through the extenders Int 31 dispatcher. It could be looking for something in the ROM BIOS, something unique to the card. I'll look into this once I've got a basic wrapper working.
I had a few problems with that. The function offsets are correct, but for some reason Dosbox mangles the machine code for some instructions, various bytes at random offsets are corrupted. I don't know whether my patching is broken, ICR23 widescreen support is corrupting something OR dosbox's instruction parser (happens with every single type of core) is messing things up.
Last edited by sharangad on 2026-05-08, 08:24. Edited 1 time in total.
so i need look closer to card, it could be GLINT at same board where Verite chip, or even unified? that was if true very ridiculous.
I had a few problems with that. The function offsets are correct, but for some reason Dosbox mangles the machine code for some instructions, various bytes at random offsets are corrupted. I don't know whether my patching is broken, ICR23 widescreen support is corrupting something OR dosbox's instruction parser (happens with every single type of core) is messing things up.
Figured out the problem with the modified driver bytes becoming corrupted: relocatable code. Bits containing addresses which need to be modified are encoded in there somewhere. Maybe I can append stuff to the end of the file and update the index. Need to see if that'll work.
Update : nope it still modifies the same bytes relative to the start of the offset. This also explains why my latest attempts at patching icr2 is crashing the game.
Imul [address] is what I'm trying to patch and four bytes after the opcode will change.
Figured out the problem with the modified driver bytes becoming corrupted: relocatable code. Bits containing addresses which need to be modified are encoded in there somewhere. Maybe I can append stuff to the end of the file and update the index. Need to see if that'll work.
Update : nope it still modifies the same bytes relative to the start of the offset. This also explains why my latest attempts at patching icr2 is crashing the game.
Imul [address] is what I'm trying to patch and four bytes after the opcode will change.
thanks for continuing to carry the torch on this, here is some of my holiday research distilled down - I can't remember how much of this slop I verified but there is some useful stuff on sections and reloc tables.
edit: this is part of an ongoing side-effort to write a software renderer, I let LLM tools continue my reverse engineering work instead of me doing it. it seemed useful but I never got around to verifying this, just wanted to pass it on in case there's anything useful in there.
Figured out the problem with the modified driver bytes becoming corrupted: relocatable code. Bits containing addresses which need to be modified are encoded in there somewhere. Maybe I can append stuff to the end of the file and update the index. Need to see if that'll work.
Update : nope it still modifies the same bytes relative to the start of the offset. This also explains why my latest attempts at patching icr2 is crashing the game.
Imul [address] is what I'm trying to patch and four bytes after the opcode will change.
thanks for continuing to carry the torch on this, here is some of my holiday research distilled down - I can't remember how much of this slop I verified but there is some useful stuff on sections and reloc tables.
edit: this is part of an ongoing side-effort to write a software renderer, I let LLM tools continue my reverse engineering work instead of me doing it. it seemed useful but I never got around to verifying this, just wanted to pass it on in case there's anything useful in there.
Thanks Furan! That's extremely useful. That looks correct. I was never able to figure out the sections before.
Thanks Furan! That's extremely useful. That looks correct. I was never able to figure out the sections before.
Great - I'm including my loader & gaming glint driver/register level reverse engineering work also. Enjoy.
The section header read should be 0x20 bytes and not 0x18. There're a few kinks to be worked out. I've got some ICR2 stuff to do today. So this is a job for next week. My ultimate goal would be to build a brand new CGL driver from scratch for dosbox-rendition.
I used your prototype and got almost everything working, everything except relocation. It now identifies all the function addresses but the relocation table doesn't seem to load.
