Looks awesome !!

RaVeN-05 wrote on 2026-04-01, 10:28:

Looks awesome !!

Not if you're trying to game on Win 11, but thanks!

Still haven't fixed the MDK scaling issue. V_LockBuffer/V_UnlockBuffer has the world background which needs to be blitted, but it doesn't scale correctly with some resolutions (and not just 1680x1050). The Pixel boundaries seem to go off.

@Goneau:

I found a bug in my 3dbVLB test app.

Could you rerun this test:
https://nirvtek.com/downloads/3DBVLB%2C.20260413.001.7z
MD5: 5de142ae96ae7d604f433bd75d64773a

I don't know if the IO port range will affect it.

[edit]
Port 0x279 appears to be the Isa pnp initialisation.

[edit 2]
Does anyone know how the isa pnp init works? Wikipedia has some details and Microsoft has a doc on the bios side of things.

sharangad wrote on 2026-04-01, 11:59:

Still haven't fixed the MDK scaling issue. V_LockBuffer/V_UnlockBuffer has the world background which needs to be blitted, but it doesn't scale correctly with some resolutions (and not just 1680x1050). The Pixel boundaries seem to go off.

The mdk stray pixel edge problem appears to occur in D3D mode as seen here:
https://www.youtube.com/watch?v=voz7N_2HmAM&t=321s

Bull Run 2k, Chenoa, Chicago (1999), Chicago (N99) and Chicagoland are Rendition Ready by default.
https://youtu.be/RaXbsoUq_Oo

3dbVLB.txt attached.

I have only one board with VLB slot (and it has only one VLB slot), that is PnP:
SOYO 4SAW2 (a Socket 3 - SiS 496/497 board)
and the VLB PnP init work the same as like the ISA PnP init (at least in appearance).
But with PnP, the 3D Blaster VLB get different resources than default, and some Rebel Moon don't like it so I have used DOS initiator program (INIT3D.EXE) in this board too.

sharangad wrote on 2026-04-13, 10:47:

@Goneau: […]
Show full quote

@Goneau:

I found a bug in my 3dbVLB test app.

Could you rerun this test:
https://nirvtek.com/downloads/3DBVLB%2C.20260413.001.7z
MD5: 5de142ae96ae7d604f433bd75d64773a

I don't know if the IO port range will affect it.

[edit]
Port 0x279 appears to be the Isa pnp initialisation.

[edit 2]
Does anyone know how the isa pnp init works? Wikipedia has some details and Microsoft has a doc on the bios side of things.

Thanks Gona!

The isa pnp should return a device Id from somewhere after this sequence, after setting all non-pnp cards to query mode with a key.

It looks like the test app is still broken.

One more Gona,

https://nirvtek.com/downloads/3DBVLB.20260416.001.7z
MD5: 0367e20cacb61a499fe0c7d64be30b39

I was missing IO for port 0xA79 earlier. Hopefully the device ID will show up now.

or @Putas

Here it is.

Gona wrote on 2026-04-18, 20:34:

Here it is.

Thanks Gona!

That's produced a response on port 0x22b and the adjacent port. Need to plug this into dosbox and see what happens. I'll have a fresh build tomorrow. Today's an icr2/widescreen day.

@Gona, if you run Microsoft's ISAPNP.EXE (from the Windows 95/98 resource kit), does it list the device identifier (for the 3db vlb)? It should be a 72 bit identifier.

That might be easier than testing this bit by bit at a time with each build.

I don't have Microsoft's ISAPNP.EXE.

I don't know whether exporting this reg key will work:
HKEY_LOCAL_MACHINE\Enum\ISAPNP

In theory at least, the device id should be there.

On my 486 with an Opti ISA sound card I get ffffffff as the device id, but it might be different for the VLB, maybe.

[EDIT] If it doesn't, I can try knocking up a test app, though I don't really know how well it would work.

This is something DeepSeek knocked up, so it could be entirely wrong (well, maybe slightly. It does fix a couple of bugs I had with my previous test app):
https://nirvtek.com/downloads/ISAPNP.7z
MD5: 70a3bfe9a26dc054366d035c9d51e868

My 486 has a PnP Opti 931, but maybe the motherboard predates PnP, I dunno. This detects 10 cards with the same ID (FF FF FF ... FF) on that. It may work better on yours.

[EDIT] Or this (ChatGPT)
https://nirvtek.com/downloads/ISAPNP2.7z
MD5: e4707609bc4bc43cad0185f819d7715e

This doesn't work on my 486 either (o card(s) detected.

After waiting 6 hours for an ICR track to load in debug mode, I turned on logging and realised a bug in there had turned it off immediately. Fixed the problem and kicked it off again and it's almost 6 hours again now. But while the track was loading I had a CGL epiphany.

I think I've found part of the signature of the function which assigns function pointers for CGL functions. Not everything has this (21st), but even VLB games have a slightly different form of the function in there:

1                           FUN_00010c18                                    XREF[1]:     FUN_000110a4:0001158d (c)  
2        00010c18 53              PUSH       EBX
3        00010c19 52              PUSH       EDX
4        00010c1a 89  c2           MOV        EDX ,EAX
5        00010c1c 8b  40  27       MOV        EAX ,dword ptr [EAX  + 0x27 ] 
6
753 52  c2    8b  40 

The last byte changes. The precise offsets are different and the function pointers which are relocatable are usually totally different. This is from 3DBInfo, but most CGL games including a few VLB games have something similar:

1       00010c1f 8b  58  04       MOV        EBX ,dword ptr [EAX  + 0x4 ]
2        00010c22 89  1d  38       MOV        dword ptr [PTR_FUN_00020438 ],EBX                = 00010c10
3                 04  02  00
4        00010c28 8b  58  08       MOV        EBX ,dword ptr [EAX  + 0x8 ]
5        00010c2b 89  1d  3c       MOV        dword ptr [PTR_FUN_0002043c ],EBX                = 00010c10
6                 04  02  00
7        00010c31 8b  58  0c       MOV        EBX ,dword ptr [EAX  + 0xc ]
8        00010c34 89  1d  40       MOV        dword ptr [PTR_FUN_00020440 ],EBX                = 00010c10
9                 04  02  00
10        00010c3a 8b  58  10       MOV        EBX ,dword ptr [EAX  + 0x10 ]
11        00010c3d 89  1d  44       MOV        dword ptr [PTR_FUN_00020444 ],EBX                = 00010c10
12                 04  02  00
13        00010c43 8b  58  14       MOV        EBX ,dword ptr [EAX  + 0x14 ]
14        00010c46 89  1d  48       MOV        dword ptr [PTR_FUN_00020448 ],EBX                = 00010c10
15                 04  02  00
16        00010c4c 8b  58  18       MOV        EBX ,dword ptr [EAX  + 0x18 ]
17        00010c4f 89  1d  4c       MOV        dword ptr [PTR_FUN_0002044c ],EBX                = 00010c10
18                 04  02  00

If these are in fact the CGL function pointers, swapping out the values at these addresses with custom code calls to Dosbox should make things work.