Thought this deserved a separate thread. I don't think I've found anything particularly interesting yet but I do now recall that some games set model references that appear to point to VROM during the first display frames but which may not be polygon data. There are a couple of spots in Legacy3D.cpp where I even explicitly test for these addresses.

Fighting Vipers 2 performs a very basic set up of culling RAM during the first frame. I will paste the viewport node and culling node it points to here. I print both the integer and float value for each word.

Right after this, the first texture data is written to the FIFO. It's the 0x80 format and the reason Supermodel was never catching it is that for some reason, I now look at (header>>24) & 0x0F rather than all 8 bits. Maybe 0x80 in the most significant byte is just a flag of some sort. In Fighting Vipers 2, it looks like nonsense: an incrementing 8-bit value (the full 32 bits are not written).

Here, the first word encodes the length and the second normally encodes the texture format plus the size. All fields are 0 except the highest bit:

LA Machineguns writes something slightly more interesting. Note that the high bit is now set for each value and that they no longer always increment by 4. Looks like a calibration curve. Might be instructive to plot it vs. offset to see how much it deviates from linearity. The data appear to be organized as 4 64-entry tables.

Something I didn't notice initially is that the last of these 4 tables has the values in descending order. Could this explain the color inversion in Daytona USA? Do the addresses line up in any way with the texture color indices + translator map bits? Daytona 2 uploads the exact same values as VON2 and Fighting Vipers 2.

Can't rule anything out, I suppose. I haven't really followed the lighting model discussions very well but are you guys sure the various differences and exceptions could not be explained by some sort of look-up tables internal to the Real3D being different? It seems highly unlikely that there would be config bits that switch between minor, fixed variations of a lighting model. Being able to modify some sort of internal color table makes more sense but even then, it's exceedingly bizarre that the developers at Sega would request the ability to do so given that the default lighting model already suits their purpose. The whole TAP functionality was probably never intended for anyone outside of Real3D themselves to mess with.

I'll have a look when I get some time this weekend to see what's being written. I don't know how many other games use the TAP after boot-up, so that will be worth investigating as well.