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 Yesterday, 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 Yesterday, 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 Yesterday, 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 Yesterday, 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.