Another one gona for VLB5 with an updated memtrace.txt file (This one should be much smaller, around 10 KB):

H0ld off on this. It's broken.

[EDIT] No, I need the results from this. If you could please run VLB5 with this memtrace.txt file. It should be under 10 KB (please check).

sharangad wrote on 2025-06-05, 10:57:

Another one gona for VLB5 with an updated memtrace.txt file (This one should be much smaller, around 10 KB):

H0ld off on this. It's broken.

[EDIT] No, I need the results from this. If you could please run VLB5 with this memtrace.txt file. It should be under 10 KB (please check).

VLB5 works just like last time although I have removed the SCSI card and only I have load an initialisator for the 3D Blaster VLB nothing else.

Gona wrote on 2025-06-05, 13:14:

sharangad wrote on 2025-06-05, 10:57:

Another one gona for VLB5 with an updated memtrace.txt file (This one should be much smaller, around 10 KB):

H0ld off on this. It's broken.

[EDIT] No, I need the results from this. If you could please run VLB5 with this memtrace.txt file. It should be under 10 KB (please check).

VLB5 works just like last time although I have removed the SCSI card and only I have load an initialisator for the 3D Blaster VLB nothing else.

Thanks Gona, but vlb5 once again needs the new memtrace.txt file (renamed memtrace.txt and kept in the same folder as vlb5.exe when executedl

The memory access data is missing in the output file.

Actually hold off on repeating that test.

Dosbox is now crashing with RebelMoon VLB with:
Exit to error: CALL:Descriptor type 13 unsupported

This error is in the function CPU_CALL as the default case in a switch statement.

sharangad wrote on 2025-06-05, 14:08:

Gona wrote on 2025-06-05, 13:14:

sharangad wrote on 2025-06-05, 10:57:

Another one gona for VLB5 with an updated memtrace.txt file (This one should be much smaller, around 10 KB):

H0ld off on this. It's broken.

[EDIT] No, I need the results from this. If you could please run VLB5 with this memtrace.txt file. It should be under 10 KB (please check).

VLB5 works just like last time although I have removed the SCSI card and only I have load an initialisator for the 3D Blaster VLB nothing else.

Thanks Gona, but vlb5 once again needs the new memtrace.txt file (renamed memtrace.txt and kept in the same folder as vlb5.exe when executedl

The memory access data is missing in the output file.

How could I be so careless... I transferred it to the computer in a zip file, but I didn't copy memtrace.txt to the floppy...
Sorry.
Here it is.

Gona wrote on 2025-06-06, 13:13:

How could I be so careless... I transferred it to the computer in a zip file, but I didn't copy memtrace.txt to the floppy... So […]
Show full quote

sharangad wrote on 2025-06-05, 14:08:

Gona wrote on 2025-06-05, 13:14:

VLB5 works just like last time although I have removed the SCSI card and only I have load an initialisator for the 3D Blaster VLB nothing else.

Thanks Gona, but vlb5 once again needs the new memtrace.txt file (renamed memtrace.txt and kept in the same folder as vlb5.exe when executedl

The memory access data is missing in the output file.

How could I be so careless... I transferred it to the computer in a zip file, but I didn't copy memtrace.txt to the floppy...
Sorry.
Here it is.

Thanks Gona! This is very interesting. It seems to be returning a bunch of magic bytes there, possibly a device ID.

In other news my Sandy Bridge based i7 test system is on the fritz. Started getting a burning smell and lost video. This was under indoor lighting and I couldn't see anything wrong with the mobo. Removed the gpu and powered up again using integrated graphics. Everything was fine and dandy until I got into windows and lost video again. The psu is new on that pc.

I'll have to deal with it tomorrow. Was looking into Internet multiplayer for icr2. Dennis over at icr2.net had worked out the protocol for 2 player multiplayer over a null modem cable. It would be nice if it were possible to extend it to 8 players over the net through dosbox's modem emulation. The protocol seems to be able to handle it, but whether the game will allow it is the question.

I figured I'd try to give a boost to the 3DB work - I've been messing around with different versions of the Creative CGL SDK for a little while. I got hold of an early version of the SDK (where the CGL driver for GiGi is linked instead of hot-loaded) from some folks who made a demoscene demo that supported 3D Blaster. The cool thing about this version of the SDK is that since the CGL driver is an OMF library there's enough metadata to do some useful reverse engineering to understand how it is programming the hardware. I am including a .zip with that version of the SDK, as well as disassembly for each of the hardware interface source files. Note that there's 2 objects for each source file in the OMF to support multiple calling conventions (I think stdcall and watcall). If you need help with the disassembly lmk.

https://www.dropbox.com/scl/fi/13txc99jsnhz02 … t=twiy5tpy&dl=1

Edit: I forgot to mention that some time ago I was provided a lot of the datasheets for 3dlabs chips. Unfortunately not for GG but the register maps for SX and TX may help.
https://www.dropbox.com/scl/fo/qpeeyt5tkfdm73 … t=fw6onvi4&dl=0

furan wrote on 2025-06-06, 16:03:

I figured I'd try to give a boost to the 3DB work - I've been messing around with different versions of the Creative CGL SDK for […]
Show full quote

I figured I'd try to give a boost to the 3DB work - I've been messing around with different versions of the Creative CGL SDK for a little while. I got hold of an early version of the SDK (where the CGL driver for GiGi is linked instead of hot-loaded) from some folks who made a demoscene demo that supported 3D Blaster. The cool thing about this version of the SDK is that since the CGL driver is an OMF library there's enough metadata to do some useful reverse engineering to understand how it is programming the hardware. I am including a .zip with that version of the SDK, as well as disassembly for each of the hardware interface source files. Note that there's 2 objects for each source file in the OMF to support multiple calling conventions (I think stdcall and watcall). If you need help with the disassembly lmk.

https://www.dropbox.com/scl/fi/13txc99jsnhz02 … t=twiy5tpy&dl=1

Edit: I forgot to mention that some time ago I was provided a lot of the datasheets for 3dlabs chips. Unfortunately not for GG but the register maps for SX and TX may help.
https://www.dropbox.com/scl/fo/qpeeyt5tkfdm73 … t=fw6onvi4&dl=0

Thanks Furan. This will help a lot. I've read through the entire cgl thread multiple times and it's proven very useful. You and Gona and Vetz and everyone else have done a tremendous amount of work on cgl.

My original plan was to swap out the cgl driver files with a custom implementation that used a proprietary api to talk to rready; one that's dosbox specific . If i can get this to work maybe I can patch out the static linked cgl drivers in games like magic carpet.

I think that's a good idea - the HOTCGL format isn't too complicated and I was going to try to build a glide proxy this way sometime back. I'll try and see what I had as far as reversing the format - I don't think I got very far.

Here's a SDK app I wrote that will load and initialize a CGL driver using the fixed point API and dump caps.
https://www.dropbox.com/scl/fi/h0i199kregrc5q … t=gmugqyzd&dl=1

furan wrote on 2025-06-06, 17:37:

I think that's a good idea - the HOTCGL format isn't too complicated and I was going to try to build a glide proxy this way sometime back. I'll try and see what I had as far as reversing the format - I don't think I got very far.

Here's a SDK app I wrote that will load and initialize a CGL driver using the fixed point API and dump caps.
https://www.dropbox.com/scl/fi/h0i199kregrc5q … t=gmugqyzd&dl=1

The register map is a treasure trove.

I don't seem to be able to find the cglload function. Is the demo the 21st century digital boy?

RaVeN-05 shared some code from a game or part of it, but that was also headers only.

yeah that's the demo.
cglload is implemented between cdl.asm and cglcdl.asm:
https://www.dropbox.com/scl/fi/91kl1adm48r1gk … t=ojh91tsr&dl=1

furan wrote on 2025-06-06, 19:23:

yeah that's the demo.
cglload is implemented between cdl.asm and cglcdl.asm:
https://www.dropbox.com/scl/fi/91kl1adm48r1gk … t=ojh91tsr&dl=1

Thanks! That seems to be the missing link. Working this out will be my task first thing tomorrow.

3DBInfo locked up on my 3DBPCI with an out of range frequency and never came back. I modified the app to switch to 60 Hz, but the same thing happened.

Added console output before and after each CGL command and then it worked OK. This is what I got:

1Board Version: Verite CGL 1.70 beta 7
2
3Board ID: 16 VRAM size: 64 MaxColorFormat: 0
4
5Capabilities:
6	Texture:0 Stipple:0 LineStipple:0 DepthCue:0 Shade:0
7	Overlay:0 Chroma:0 Dither:0 AlphaBlend:0 Pick:0 Extent:0
8	Bitmask:0 LogicOps:0 DepthTest:0 Clipping:0 Stencil:0 

I ran the cglLoader code through an AI based reverse compiler and here's the C translation of it. Unfortunately it's a literal conversion of assembler, which is what I would expect from a non-AI based reverse compiler. Should be able to use that to figure out the offsets within the file of each cgl function.

[EDIT] I tried it again on the P4 without logging and now it just works without any lockups.

Furan , do you have any idea what arg_7 is?
For VRIT CGL files it's always 0x54 (84), gpuType is 0x10 (16)and version is 0xAA (170). Version and GPU type can be set to 0. Unless my manual correction is wrong.

Setting it to 0 causes a failure. I've hardcoded 0x54 for now.

1int cdl_load(const char* filename, unsigned char stack[STACK_SIZE], struct cdl_struct* cdl_struct, short version, char arg_7, char gpuType, int arg_C)

[EDIT] My test harness segfaults so something in the conversion is wrong somewhere. The stack parameter I've added manually. Thjs will disappear once I've worked out the structure of cdl_struct, unless that's already there in the source.

furan wrote on 2025-06-06, 16:03:

I figured I'd try to give a boost to the 3DB work - I've been messing around with different versions of the Creative CGL SDK for […]
Show full quote

I figured I'd try to give a boost to the 3DB work - I've been messing around with different versions of the Creative CGL SDK for a little while. I got hold of an early version of the SDK (where the CGL driver for GiGi is linked instead of hot-loaded) from some folks who made a demoscene demo that supported 3D Blaster. The cool thing about this version of the SDK is that since the CGL driver is an OMF library there's enough metadata to do some useful reverse engineering to understand how it is programming the hardware. I am including a .zip with that version of the SDK, as well as disassembly for each of the hardware interface source files. Note that there's 2 objects for each source file in the OMF to support multiple calling conventions (I think stdcall and watcall). If you need help with the disassembly lmk.

https://www.dropbox.com/scl/fi/13txc99jsnhz02 … t=twiy5tpy&dl=1

Edit: I forgot to mention that some time ago I was provided a lot of the datasheets for 3dlabs chips. Unfortunately not for GG but the register maps for SX and TX may help.
https://www.dropbox.com/scl/fo/qpeeyt5tkfdm73 … t=fw6onvi4&dl=0

How'd you get the disassembly from the LIB files? Did you do it manually? The CGL loader expects a byte parameter at stack pos -0xFC. I don't know what this is. It uses this as an offset into the file.

IDA (per screenshot). I might try to take some time this weekend and look at it a little bit more.

furan wrote on 2025-06-13, 02:26:

IDA (per screenshot). I might try to take some time this weekend and look at it a little bit more.

I've got half of it translated to c++, still working on the rest. Once the translation is complete. The data structures can be properly decoded.

I forgot all about ida. Didn't realise it could handle lib files.

Should be done with the conversion tomorrow (Fingers crossed).

A quick update on another Rendition Ready Track: Elkhart Enhanced (Papyrus:
https://youtu.be/4UB-lSmxB_8

The 1997, 1998 and 2003 versions of the track are also in the video. A direct link to the enhanced track can be found in the video description.

GUI Based ICR2 carset/track MIP map reduction tool

https://nirvtek.com/downloads/GTREdit.V1.0.1.7z
MD5: d1948d3806377437157531874302f09f
https://nirvtek.com/downloads/GTREdit.V1.0.0.7z
MD5: 7cd5e27a46a3fe8bff805ba3f95b2bf0

https://youtu.be/mXPotS1o-os

It should be fairly self-explanatory. An unzipped carset or track (with or without dat) is the source folder, the output folder is where the MIP reduced version goes, it's best if this is different to the final destination and it should be empty.
The number of MIP maps dropdown is used to select the maximum number of MIP maps to retain for each texture. If the texture has fewer it's left along, if not the smallest mip maps are removed.