does it run without any parameters?

robertmo3 wrote on 2025-04-24, 05:32:

does it run without any parameters?

It just exits, just the same as with params.

Would you like me to share the binary?

[EDIT]
https://nirvtek.com/downloads/qemu-system-i386w.7z
MD5: 30b1bfffb44dd7667f0a585325d2b74b

It's 17 MB compressed, 80 MB decompressed.

use the
qemu-system-i386.exe
because
qemu-system-i386w.exe
does not output any comments

This is what I get:

1C:\msys64\ucrt64\bin\qemu-system-i386.exe: window-close=off: drive with bus=0, unit=0 (index=0) exists

and I had to remove the no-hpet switch. It didn't like that.

you added a space after comma, it shouldn't be there
-display sdl,window-close=off

and this one is this now
-machine hpet=off

That seems to work:

1Windows Hypervisor Platform accelerator is operational
2qemu: could not load PC BIOS 'bios-256k.bin'

[EDIT] Works! Copying the missing DLLs produce a weird error about missing exports (libvirgl*.dll, missing function epoxy_eglBindAPI could not be location in libvirglrenderer-1.dll). Running it straight off the ucrt64 folder works with a different working folder.

where do you copy missing dlls from?

robertmo3 wrote on 2025-04-24, 09:31:

where do you copy missing dlls from?

Msys/ucrt /bin.

Edit: maybe I copied it from msys/bin.

there is no msys/bin folder

if you run from ucrt64 than there is no guarantee you are actually running the file you built yourself cause ucrt64 has its own qemu installation and you most probably run that one
to confirm that, rename the executable to something unique (like qemushar.exe) and check again

that is why you should run it from cmd from a separate folder

robertmo3 wrote on 2025-04-24, 10:15:

there is no msys/bin folder […]
Show full quote

there is no msys/bin folder

if you run from ucrt64 than there is no guarantee you are actually running the file you built yourself cause ucrt64 has its own qemu installation and you most probably run that one
to confirm that, rename the executable to something unique (like qemushar.exe) and check again

that is why you should run it from cmd from a separate folder

I overwrote the one there with mine and it does run from that folder.

you can try if qemu from here works for you
https://qemu.weilnetz.de/w64/qemu-w64-setup-20250422.exe

robertmo3 wrote on 2025-04-24, 16:45:

you can try if qemu from here works for you
https://qemu.weilnetz.de/w64/qemu-w64-setup-20250422.exe

The version msys2 built works now with the corrected command line.

robertmo3 wrote on 2025-04-24, 16:45:

you can try if qemu from here works for you
https://qemu.weilnetz.de/w64/qemu-w64-setup-20250422.exe

Also works if I copy all the DLLs from ucrt64/bin into the qemu build folder. It moans about just 2 dlls, but doesn't in fact work without all of them.

A quick update on CGL. I had a quick look at how Toshinden access the VR?T?*.CGL files.

It seeks to offset 0x73 (115) and reads the block. The type as @Furan already report here is at offset 0x77 (Re: Fun with CGL (Creative Graphics Library) on 3D Blaster): What comes after that are offsets for each of the functions.

In VRITB*.CGL (Integer params, watcom calling convention(register based passing)) there are 44 functions and their offsets appear to be pointed to be stored at
0x73 (value at this position here somehow converts to 0x4173),
0xFF (points to 0x5173),
0x107 (0x6173),
0x10F (0x7173),
0x117 (0x8173),
0x11F (0x9173),
0x127 (0xA173),

The pattern is different after a while, but there's always a pattern.

That'll be my job for every coming Sunday. I think swapping out the calls with a hand assembled custom VRITB*.CGL driver is our best bet. It'll also allow CGL to run on 3Dfx and other cards.

Hope you can make it and it's possible.
Making CGL to run on other 3d cards is awesome would be.