i think VQuake 1.08 requires renaming .uc to .uc2 for v2000
.uc is used by v1000 only in 1.08

MSxyz wrote on 2024-05-27, 09:17:

Here you go: […]
Show full quote

DrAnthony wrote on 2024-05-26, 19:22:

A 2nd gen Verite on a 486 is basically an unknown to me and I'd love to see where it lands. My guess would be right around where vQuake is hitting.

Here you go:

The system specs:

Motherboard: Zida 4DPS v3.1
Chipset: SiS 85C496/85C497
BIOS Date: 10/17/96
CPU: AMD Am5x86 (ADZ)
External Cache: 4 x 64KB, 15ns
Main Memory: 2 x 16MB, 72 Pin, 60ns
I/O Card: -
Video card:
1 - Hercules Dynamite 128 - Tseng Labs ET6000 2MB PCI (90MHz MCLK)
2 - Diamond Stealth S220 - Rendition Verite v2100 4 MB PCI (BIOS v1.36 - 55 MHZ Clock)

Quake Demo v1.06 (from Phil's benchmark disk)
Software rendering: QUAKE.EXE 1.06, default settings, Mode 0 (320x200 VGA)
Hardware rendering: VQUAKE.EXE 1.06b12 patched with V2DOSFIX, default settings (NODMA, can't do otherwise on this board), Mode 0 (320x200).

TIMEDEMO DEMO1 @ 133MHz
Software rendering: 14.6 FPS
Hardware rendering: 17.8 FPS

TIMEDEMO DEMO1 @ 160MHz
Software rendering 17.0 FPS
Hardware rendering: 20.4 FPS

Note: DMA should be worth an extra 10% in performance, but it doesn't work on this motherboard. On a 160MHz 5x86, it's borderline playable with a Veritee. Graphics are also nicer, which is an added bonus. Enabling antialiasing results in a -1 FPS hit. Since distant objects textures tend to be somewhat blurry at this low resolution, using D_MIPSCALE 0.5 makes them sharp again, but it has a -2FPS penalty.

NOTE: For the love of God, I can't get Vquake version 1.07 or 1.08 work neither on this PC nor in my makeshift Pentium 4 test bed. The EXE crashes to DOS with the following error:
"Problem Starting Verite. Probable cause: missing or outdated microcode (spd3d.uc). Error code 0x406"

I've tried with different .uc files, patching the exe and other stuff out of desperation. Note that, on the P4 system, I get this error both with this specific card and with another Rendition V2200 board (this time with AGP connector) I have at home. If someone has a verified working copy of VQuake 1.08, would he be so kind to send me the .exe and the matching .uc file? I can't explain what's going on. One theory I have it's that the EXE was compiled with specific Pentium code and won't run on anything that isn't a P5 or P6.

Very cool, but I was referencing GLQuake. I was guessing performance on a 2xxx would fall near vQuake but since they are incredibly different in their approaches, probably never considered 486 platforms, and the beta status of the ICD it's a total unknown for me.

robertmo3 wrote on 2024-05-27, 13:04:

i think VQuake 1.08 requires renaming .uc to .uc2 for v2000
.uc is used by v1000 only in 1.08

You're my hero! 😀
I renamed the .uc file and everything worked!

Running VQuake 1.07/1.08 results in a modest fps increase.

From 17.8 to 18.0 at 133MHz
From 20.4 to 20.7 at 160 MHz

I've tried the option r_surfacelookup 0 (8 to 16 bit texture conversion done by the CPU instead of the GPU) but there are no gains/losses.

DrAnthony wrote on 2024-05-27, 13:44:

Very cool, but I was referencing GLQuake. I was guessing performance on a 2xxx would fall near vQuake but since they are incredibly different in their approaches, probably never considered 486 platforms, and the beta status of the ICD it's a total unknown for me.

Oh, sorry I didn't understand. Unfortunately, I'm not planning to install Windows. It has been at least 20 years since I last used Win 9x and I recall making a highly optimised Win 98SE Lite version especially for my gaming rigs because the retail version shipped with a load of crap. Unfortunately the boot CD with that highly tuned version must have been lost during a relocation and I'm not really interested in recreating it. I'm happy with my trimmed down XP build for old systems, but I'm afraid it's a bit too much even for a powerful 486 PC.

What kind of microcode is talked about? Does RV GPU chip has it's own microcode? Is is distributed separately from the driver? So driver code can load different uc files? I didn't explore verite dos drivers structure yet... where to download most rcent/best working drivers?

RayeR wrote on 2024-05-27, 15:43:

What kind of microcode is talked about? Does RV GPU chip has it's own microcode? Is is distributed separately from the driver? So driver code can load different uc files? I didn't explore verite dos drivers structure yet... where to download most rcent/best working drivers?

Under DOS, each game modified to run on Verite was distributed along with a file named SPD3D.UC. These files contains an executable program for the Verite chip. I don't know the specifics, but basically the Verite behaves like separate processor running a program in its dedicated memory; the main CPU sends strings of data via the PCI interface and the Verite read this data and performs various tasks according to the program that is running inside its memory.

.UC files are, to a certain degree, interchangeable. For example, all files named SPD3d are custom programs created for the SPEEDY 3D library to accelerate graphics under DOS. There are other UC files for 2D GUI acceleration, OpenGL hardware acceleration or DirectX that are used under Windows 9x. Somebody posted a whole archive of .UC files a few pages ago. Others may be obtained through drivers or game patches.

Aha, so every 3D engine use it's own UC to comunicate properly with GPU. Seems to be different approach from 3dfx voodoo where one glide2x.ovl driver was used by all dos games (patched by 3d patches). There's also opensource glide dxe module for games compiled by djgpp. Is there available some documentation about verite GPU or how to interface some UC API?

chuky wrote on 2023-12-15, 16:46:

there's a zip file with a collection of all known spd3d.uc files if you want to test. http://www.mediafire.com/file/01ciw6qaq393w8z … ion-uc.zip/file

Rendition Verite VQuake v1.07 beta 5. has one more

RayeR wrote on 2024-05-27, 18:54:

Aha, so every 3D engine use it's own UC to comunicate properly with GPU. Seems to be different approach from 3dfx voodoo where one glide2x.ovl driver was used by all dos games (patched by 3d patches). There's also opensource glide dxe module for games compiled by djgpp. Is there available some documentation about verite GPU or how to interface some UC API?

UC is the OS for the Verité board. It occupies the first n bytes of VRAM and is followed by the framebuffer and then the rest of RAM is used for textures.

The UC tells the Verité how to interpret command buffer and texture data. V1000 and V2000 use different instruction sets, though the V2000 has a V1000 compatibility mode. RReadline (Windows) and SPDY3D(DOS) internally use the same command codes and data format so are almost 100% compatible though Speedy3D games only pass the contents of command buffers and VRAM address. RRedline also has low level access (used almost completely by games like SODA Offroad and a few otehrs), though most games use the high level abstractions using vsurface and buffer groups. RReady supports 128 MB of VRAM for RRedline games and only 4 MB for Speedy 3D simply because the DOS games don't actually query the amount of RAM, at least as far as I can tell. Also low level structures limit VRAM to 16 MB though RRedline (with RReady) can mask it using the high level structures and expose more RAM.

I wrote RReady, the Rendition Verité wrapper, and I'm currently adding Speedy3D support. RReady (and for DOS support Dosbox-Rendition) expects a fixed UC file (so that the framebuffer address can be fixed. THere's no eay way of determining it).

[EDIT] There's an entire thread about it here:
RReady (Rendition Verite wrapper) Test Build (Alpha 1)
though you'll have to pop over to the end find Speedy3D vids.[/EDIT]

RayeR wrote on 2024-05-27, 18:54:

Aha, so every 3D engine use it's own UC to comunicate properly with GPU. Seems to be different approach from 3dfx voodoo where one glide2x.ovl driver was used by all dos games (patched by 3d patches). There's also opensource glide dxe module for games compiled by djgpp. Is there available some documentation about verite GPU or how to interface some UC API?

In theory each software developer, given the proper SDK, would be able to write its own 'microcode' to control the Verite CPU. In practice, I suspect most developers stuck to what Rendition released, hence why UC files are interchangeable to a degree. I don't even know if Rendition released this information to developers or just made them use their Speedy / RRline libraries.

In retrospect, an architecture like the Verite would have been better suited to a console where programmers can go 'close to the metal': the main CPU does game logic and geometry transformations, the Verite can do the rest of the 3d engine by itself.

In a certain way the Verite is reminiscent of the Nintendo SuperFx chip for the snes: a risc CPU, with its own memory and dedicated instructions to accelerate graphic manipulation, that ran alongside the snes CPU and was used to create 3d graphics. The Nintendo 64 Rsx coprocessor is also something similar but even more sophisticated, since it includes also a vector ALU for geometry processing.

MSxyz wrote on 2024-05-27, 14:45:

DrAnthony wrote on 2024-05-27, 13:44:

Very cool, but I was referencing GLQuake. I was guessing performance on a 2xxx would fall near vQuake but since they are incredibly different in their approaches, probably never considered 486 platforms, and the beta status of the ICD it's a total unknown for me.

Oh, sorry I didn't understand. Unfortunately, I'm not planning to install Windows. It has been at least 20 years since I last used Win 9x and I recall making a highly optimised Win 98SE Lite version especially for my gaming rigs because the retail version shipped with a load of crap. Unfortunately the boot CD with that highly tuned version must have been lost during a relocation and I'm not really interested in recreating it. I'm happy with my trimmed down XP build for old systems, but I'm afraid it's a bit too much even for a powerful 486 PC.

No worries, I totally understand the amount of tinkering it takes to get these systems just right.

Could someone with a Rendition board and 10 minutes to spare run this from dos (run.bat after unzipping all 3 files) and post the output file:

Re: RReady (Rendition Verite wrapper) Test Build (Alpha 1)

Thanks!

Guys, thanks for more explanation about VR arch, interesting... I didn't know it has some links to Nintendo, I don't know consoles HW...
Oh, well, Vogons driver lib contains some nice PDF including RISC programming... https://www.vogonsdrivers.com/getfile.php?fil … &menustate=17,1

>sharangad
I got access dedied error on onedrive. Also please could you upload your wrapper somewhere else? It requires MS account and I think I'll never register one 😀

RayeR wrote on 2024-05-28, 01:21:

Guys, thanks for more explanation about VR arch, interesting... I didn't know it has some links to Nintendo, I don't know consoles HW...

>sharangad
I got access dedied error on onedrive. Also please could you upload your wrapper somewhere else? It requires MS account and I think I'll never register one 😀

OK. Give me 25 mins.

The FIFO Test app is here:

https://nirvtek.com/downloads/Fifo.20240528.001.zip
MD5: 1108f5f1b91b7e67a192e9a10082425d

The wrapper can be found here:
https://nirvtek.com/downloads/Speedy3D.202405 … 7.Alpha.001.zip
MD5: 812bf0e104f75ead64898c6614eec13a

(This is a slow server).

Should fix Tomb Raider menus and use full res render to texture targets.

- Tomb Raider almost complete (health bar not visible)
- ICR2/Cart 2 100%
- Stability issues remain
- Other games have partial compatibility (Whiplash/Rebel Moon somewhat playable. Nascar 2/1999 has major corruption and stability issues)
- Windows games might work properly with this release. They haven't been tested for regressions and the debugging will definitely break the
Interstate games. For playing Windows games, use a fully tested release from below.

Extract Dosbox into a fixed folder and RReady into another (can be a temp folder). Run the unzipped Rlauncher and add dosbox as an app under Win apps. Eventually it'll move into it's own tab.
- Configure upscaling resolution, vsync and framerate indicator, if necessary.
- Run dosbox by clicking the Launch button.
- Dosbox-Rendition.conf in %localappdata%\temp contains the dosbox settings for this build of dosbox.
In this file the following settings are available:
[rendition]
# threadsafe: Thread safety seting for dosbox
threadsafe = false
fullscreen = true
threadsafe is crash proof with DMA, but will kill performance. fullscreen decides whether the app runs in a window or not. There will be window scaling and positioning options when not fullscreen in a later release, but this isn't a priority at the moment. I've disabled the [ALT+ENTER] fullscreen toggle because this broke ICR's cockpit view. Without support from games this toggle won't work properly anyway. Configuring the statup up full screen flag will allow correct rendering either in fullscreen or a window without a toggle.

I just tried VQUAKE 1.08. I got ucodes package from Mediafire and needed to try more to find one that worked. Those SPD3D.UC with size 56680 B produced only black screen while one 72280 B show garbaged screen and hanged. That 65176 B and 67280 B worked for me. A small benchmark on my Tillamook @300MHz GA-5AA 2.2 setup:
software 640x480: 14,1 FPS
RV 640x480: 32,0 FPS
RV 1024x768: 17,0 FPS
I noticed that FPS during demo play and game play was fluctuating a lot from visible framing to smooth and fast, it would be better to have more stable FPS. The RV chip run quite hot during 3D - I cannot hold my finger more than a few seconds, some heatsing would be helpful...

And here is the output of FIFO test:

RayeR wrote on 2024-05-28, 04:11:

And here is the output of FIFO test:

Thanks @RayeR

Is there a way to overclock under DOS the Verite chips? I've learnt how easy it was under Windows; one would imagine that somebody thought about making a small utility for DOS, too...

I also happen to have a QDI Legend V2200 AGP 8MB that is clocked at 50/100... Is there a way to flash a modified bios with higher CPU frequency? When both my Verite cards were installed in the Pentium 4, I noticed that the Diamond Stealth S220 was faster than the QDI despite using the PCI bus! Those extra 5 MHz were worth more than the additional bandwidth provided by the AGP slot

MSxyz wrote on 2024-05-28, 05:50:

Is there a way to overclock under DOS the Verite chips? I've learnt how easy it was under Windows; one would imagine that somebody thought about making a small utility for DOS, too...

I also happen to have a QDI Legend V2200 AGP 8MB that is clocked at 50/100... Is there a way to flash a modified bios with higher CPU frequency? When both my Verite cards were installed in the Pentium 4, I noticed that the Diamond Stealth S220 was faster than the QDI despite using the PCI bus! Those extra 5 MHz were worth more than the additional bandwidth provided by the AGP slot

My understanding of the video BIOS is very poor. I still haven't been able to create a virtual BIOS. Dosbox-Rendition (which needs a BIOS, unlike the RRedline apps) needs a copy of an actual BIOS to work and through software is also at the moment difficult. I've isolated the calls used by RenUtil, and know the expected behaviour. But a lot of BIOS calls (INT10h ) are still an unknown. RReady can run ICR2, Nascar2/1999 (with issues), Tomb Raider, Rebel Moon and Whiplash, but vQuake fails with a UC error related to the BIOS.

I'm sure other people on this forum could help with that.

MSxyz wrote on 2024-05-28, 05:50:

Is there a way to flash a modified bios with higher CPU frequency?

Just a suggestion: if there is an original BIOS dump file from V2100 card (for example Diamond Stealth II) and a BIOS file for upgrading the very same V2100 card to V2200, maybe it would be possible to find out which bytes are responsible for setting the video chipset and memory frequencies.