One last one for today:
https://1drv.ms/u/s!As-dKk-N73dSmCUzGTSIrzn24luh?e=asxAAi
MD5: 5a1501c656f81fe31b8b7a5d97989cb4

DMATest now returns:

1D:\DMA>dmatest
2DOS/4GW Protected Mode Run-time Version 1.97
3Copyright (c) Rational Systems, Inc. 1990-1994
4NULL Mode set failed
5Failed to access Verite board, error code 0x27270a.
6Errors have been found.

Tomorrow. tomorrow!

Trying to switch to mode 0x807F with Int10h function 0x4F02 fails.Not entirely sure what the response here should be.

done

Thanks.

Latest here too.

Current status:

1For more information read the README file in the DOSBox directory.
2
3Press alt-Pause to enter the debugger or start the exe with DEBUG.
4
5HAVE FUN!
6The DOSBox Team http://www.dosbox.com
7
82:\>SET BLASTER=A220 I7 D1 H5 T6
9
102:\>mount d c:\dos
11Drive D is mounted as local directory c:\dos\
12
132:v>d:\
14
15D:\>cd dma
16
17D:\DMA>dmatest
18DOS/4GW Protected Mode Run-time Version 1.97
19Copyright (c) Rational Systems, Inc. 1990-1994
20Some system BIOSes disable writes to shadow ROM too early in
21the boot process. The video BIOS has successfully worked around this.
22Press ENTER to begin the test; the screen will be blank during testing.
23NOTE: this release works only on Pentiums and Pentium Pros; type
24Ctrl-C to exit now.

It seems to hammer around a loop reading port PORT_BASE + 0x41 (probably waiting for DMA transfers to finish). It times out eventually because DOSbox-Rendition doesn't actually have carry out the transfer.

Another one:
https://1drv.ms/u/s!As-dKk-N73dSmCaph2u95Dl_GRMq?e=W0JkZr
MD5: 5f2bec598ad831e8211040bc76b4be3f

Here ya go.

Thank you kindly!

Kaplah!

This is with heavy logging so very slow AND DMATest isn't actually transferring anything to RReady (yet).

[EDIT] Well done testers. Baby steps complete!

Does ICR2 only use FIFO?

according to what i spot inside exe of icr it should use DMA

"Usage: indycar [switch]
-gRN1 Use Rendition Verit
acceleration (default)
-gRN1f Use Verit
: FIFO instead of DMA (slow)
"

When I run ICR2 (using cartrend.exe) it keeps writing to VRAM at ever increasing addresses.

it doesn't complain about a missing card. None of them do. Need to decode the FIFO and DMA register processing.

This is proving very useful right now:
http://vogonsdrivers.com/getfile.php?fileid=324&menustate=0

well its looks like emulation, i remember i asked DosBox-x author about this https://github.com/joncampbell123/dosbox-x/issues/291
but abandoned , shame to me, i am dumb here(. Wish i could knew more. Also tried to make rredline wrapper ( Rendition Verite Wrapper attempts [need help] ) myself ahhaha), but all that is not relevant probably now.

I haven't seen that thread before and you started at the same time as me. A crash course in C might've been handy. But you did develop a Rendition wrapper. Without your help and that of the entire forum RReady wouldn't exist. Pretty soon, as usual barring showstoppers, we should have Speedy3d support.

RRedline command buffers closely matche the register architecture of the card.

Dosbox - Rendition will pass the stuff written to the registers from dos command buffers on to Rlauncher which will convert them back to RRedline command buffers. These in turn will be passed on to RReady., which will render them.

At least that's the plan at the moment.

If can get it going, maybe we could build a basic dos speedy 3d api.

I don't know if anyone would want one. But it's within the realms of possibility now.

omg =0.
Thanks) well i even can't image trough what painful and hard work you gone/going. We just little helpers) , i glad to help at any time)

If you would like to finish your open source wrapper, I could give you pointers.

Well one mighty RReady by you enough !
i will try other API's to wrap in future , ones which no one touched.

One my last thinks is how to set handler window for opengl , when calling rredline.
Its where i stuck and didn't tried, i saw your project than.

i think if intercept opengl32.dll into opengl32.dll, there is no problem handler exist in game, but when there is other api than opengl should use handler somehow inside of custom opengl32.dll.

Well to be honest i far from this, i can't even explain it in clear way.

One other thing I noticed is that the Rendition architecture (V1000 /V2000) possibly can't access more than 8 mb of texture RAM. Well the structures support it., but one of the registers doesn't have enough bits because part of it is used for something else.

I'll have to double check, but at first glance that's what it looks like.