Ok, the BIOS extraction worked for the 3D Blaster EXEs from DOS Box.

I'll also need your video BIOS. The V2200 BIOSs I have appear to be identical (AxlePCI.VBI and supergrace8mbagp.VBI, Reference BIOS) .

I don't know whether yours will be the same.

Also a dump from a V1000 user would be handy.

I expect it to return CX=09FC, DX =C000.

sharangad wrote on 2024-01-05, 10:52:

Ok, the BIOS extraction worked for the 3D Blaster EXEs from DOS Box.

I'll also need your video BIOS. The V2200 BIOSs I have appear to be identical (AxlePCI.VBI and supergrace8mbagp.VBI, Reference BIOS) .

I don't know whether yours will be the same.

my bioses (i done test of setmode only on v2200)

Thanks Raven-05.

Is the V2100 a Diamon Stealth II S220 of some sort? If it's not too much trouble could you run setmode on it? If you need to install the board don't bother.

The V2200 BIOS appears to be similar to the others. The stealth board has a very different BIOS.

[EDIT] A run of setmode.exe from a V1000 user would be handy as well.
[EDIT2] Can you run the new SetMode.exe on the V2200 again to see if it returns the exact same results?

v2100 = Diamon Stealth II S220
v2200 = idk (seems unnamed)
new setmode returns different data (on v2200)
for v2100 i can install, say it and i will do)

Thanks Raven.

If it's not too much of a hassle, could you try v2100?

OK no problem.
https://fex.net/ru/s/4aa7tx5
This is photos of my cards, as you see v2200 unnamed, or maybe I blind)))

this is what i get on v2100

Thanks Raven.

Yup, you have some sort of unbranded card.

The results of SetMode confirm that the address returned in the cx and dx registers are a pointer to the bios a few bytes before a rendition string Id. [EDIT2] The Stealth II returns a different address because the string is somewhere else (0xc000094c as opposed to 0xc0000a2c on a reference bios).

Need to see if a v1000 return something similar.

Trawling through pretty much any speedy3d app's disassembly shows that it scans the bytes from that address onwards until it encounters 0x79 ([EDIT3] 'y', which occurs). This comes from the the block containing a string which starts a few bytes out from that address (3 bytes, "Rendition Reference Board", more bytes 'y').

[EDIT] it counts how many bytes from the start it takes to hit 0x79.

Does vquake need to be patched for a v2k or does it work out of the box?

@Raven-05

Could you try this as well? (On a single card)

https://1drv.ms/u/s!As-dKk-N73dSlw8Mo-Zu9Ad0nTvO
MD5: 4cd999b10c26e7293cecfa7c2280da8f

On further inspection both vQuake and DMA Test appear to shift DX by 4 bits to the left, not 16. So I need the data dump again.

vquake works out of the box.

Thanks Raven. Could you recommend a decent book on x86 DOS protected mode coding?

There's no video BIOS access on Win32 and I have no idea how memory mapping/paging works on x86.

[EDIT] Though this will probably help: https://en.wikibooks.org/wiki/X86_Assembly/Protected_Mode seems to help.

Unfortunately not a dos programmer, can't help here.
Only reads asm x86 by Paul Carter
Excellent book
https://pacman128.github.io/pcasm/

RaVeN-05 wrote on 2024-01-06, 11:12:

Unfortunately not a dos programmer, can't help here. Only reads asm x86 by Paul Carter Excellent book https://pacman128.github.i […]
Show full quote

Unfortunately not a dos programmer, can't help here.
Only reads asm x86 by Paul Carter
Excellent book
https://pacman128.github.io/pcasm/

Should hopefully cover instructions like lldt and smsw.

http://rcollins.org/articles/pmbasics/tspec_a1_doc.html has details on the gdt and ldt.

I've done some stuff on and off on in-memory patching, but it doesn't work. The patching does work, the addresses are all wrong, I've checked against an ati rage wrapper (https://github.com/ata4/glrage) which does it and RReady appears to be doing things right.

The DLL size in memory is a lot bigger than it is on disk and I'm guessing the layout of the DLL isn't the same. I think the static variables block on disk is compressed.

If I post a build which'll dump out the in memory dll /exe to a file and add support to Rendition.cfg for patching individual bytes in ref_v1k and vh2.exe can someone here (Raven-05?) work out the addresses? I'll add support for it to RReady and upload a build if anyone's willing.

On Speedy3D support, I need to build a better text editor. One which can handle >300 GB text disassembly text files and do split view and do it quickly. It's a bit painful at the moment. Turning on logging in vquake, it takes more than half an hour to produce a debug dump with full debugging (and that's just for vquake to fail with an error or crash) and the text editors are horrendously slow when they're not crashing. There're already text editors which can do this, but as far as I can not one of them does everything I need.

RReady test build January 10 2024
*************************************************************************************
Preliminary support for vQuake 2/vHexen II in-memory patching. This should leave the original binaries unpatched. For Quake 2 you will still need a copy of ref_v1k
that supports native fullscreen modes. The fullscreen toggle happens before RReady loads and it has no control over the parent EXE at that point.

The only change in this binary is the patching, but that doesn't mean that nothing's broken.

https://1drv.ms/u/s!As-dKk-N73dSlxgMo-Zu9Ad0nTvO
MD5: 51d976481231f74edc3cd29dbf699fbf

*************************************************************************************

This build probably won't be pushed out to the store yet because of testing time constraints.

An update on Speedy 3D:
This is slow going. Trawling through hundreds of gigs of assembly dumps takes time. My knowledge of protected mode x86 (DOS) assembler is improving, but not quite there yet. A lot of assumptions I've had related to Speedy3D have been proven wrong. My breaks from Speedy3D involve things like in-memory patching.

It's going to take a long time.

I don't know whether there's a need for native OpenGL based DirectDraw support for RReady. Some games like Heavy Gear/Interstate 76 need DirectDraw support. DxWnd and dgVoodoo do the job mostly, but I don't know how pressing native support is. If there's a heavily requested feature, I can make it my next side project.

It will be done at some point, just not yet.

Do you still need something to be run on V1000?
I have miroCrystal VRX here.

sharangad wrote on 2024-01-10, 09:38:

If there's a heavily requested feature, I can make it my next side project.

My vote is for Speedy3D games over RRedline games. But, considering how difficult is to write an emulator/wrapper without any technical documentation, do what you think is best.

ntalaec wrote on 2024-01-10, 15:21:

sharangad wrote on 2024-01-10, 09:38:

If there's a heavily requested feature, I can make it my next side project.

My vote is for Speedy3D games over RRedline games. But, considering how difficult is to write an emulator/wrapper without any technical documentation, do what you think is best.

Rredline games are already done. He was asking if anyone would want any other wrapper for rredline insted of opengl.

Speedy3d is on the way