JTAG mode word registers

[gm_matthew]

I've been digging around in the Real3D firmware and I've managed to uncover some information that could potentially help us understand more about the Real3D Pro-1000 works.

Each of the ASICs on the video board (Mercury, Venus, etc. but not 3D-RAM) has a 32-bit mode word register which is accessed with the instruction code 01000; this is the most common register accessed via JTAG. I was able to find lists in the Real3D firmware describing what each bit of each mode word does (least significant bit first):

Code: Select all

Jupiter
=======
0 - GLOBAL RESET (LSB)
1 - Enable Two Channel
2 - Enable Interlace
3 - Enable Two Processor
4 - Disable Fog
5 - Disable Illumination
6 - Disable Scroll
7 - Disable S-Buffer
8 - Enable Scroll Smoothing
9 - Display Edges Only
10 - Slope
11 - Trap Pixel Data
12 - Trap Line FIFOs
13 - Threshold[0]
14 - Threshold[1]
15 - Threshold[2]
16 - Threshold[3]
17 - Threshold[4]
18 - Threshold[5]
19 - Enable MISRs
20 - Enable Memory Test
21 - Enable Edge Resolver Compare
22 - Enable Blend Compare
23 - Enable Smudge Compare
24 - Enable Color Calc Test
25 - Gamma Bypass
26 - Dac Strobes Invert
(bits 27-31 unused)

Mercury
=======
0 - NOT Initialized (LSB)
1 - Block CPU Write
2 - Block Culling
3 - Block Burst
4 - Block PingPong
5 - Force PingPong
6 - Block Poly Request
7 - Force Poly Request
8 - Block LOS
9 - MISR Enable
10 - SDRAM Short Refresh
11 - Memory Pointer JTAG
12 - Stats Sel [0]
13 - Stats Sel [1]
14 - Stats Sel [2]
15 - Burst Always
16 - Stack Mem Test [0]
17 - Stack Mem Test [1]
18 - Model FIFO Test
19 - Culling SDRAM Test
20 - Ignore Discard
21 - Model FIFO Ignore Discard
22 - Model FIFO Cycle
23 - LOS Test
24 - MISR MAC Sel
25 - MAC Test
26 - Datamux Test
27 - Counter Test
28 - Mux Isolation Sel [0]
29 - Mux Isolation Sel [1]
30 - Fltfunc Test
31 - Do Nothing (MSB)

Venus
=====
(bits 0-3 unused)
4 - Stop SDRAM writes/reads
5 - Always Available
6 - Test 1x
7 - MISR Enable
8 - Stats Mode[0]
9 - Stats Mode[1]
10 - Projection Scale Disable
11 - Snapshot Enable
12 - Stats Disable
13 - Polygon Mem Test
14 - Texture Update
15 - Polygon FIFO Test
16 - No writes to rd FIFO
17 - No reads to rd FIFO
18 - Short Refresh
19 - Pmem ROM Checksum Enable
20 - Test Mode[0]
21 - Test Mode[1]
22 - Test Mode[2]
23 - Counter Test
(bits 24-31 unused)

Earth
=====
0 - Two Processors (LSB)
1 - Two Monitors
2 - Disable Texture Xluc
3 - Disable Polygon Xluc
4 - Disable Contour Xluc
5 - Disable Stencil
6 - Test/Trap Input FIFO[0]
7 - Test/Trap Input FIFO[1]
8 - Stats Sel[0]
9 - Stats Sel[1]
10 - Stats Sel[2]
11 - Enable LOS Test
12 - Trap Code[0]
13 - Trap Code[1]
14 - Trap Code[2]
15 - Enable DBM Test
16 - Enable Video Mem Test
17 - Cycle Video Mem
18 - Enable MISRs
19 - Disable DRAM Refresh
20 - Disable Mars Freeze
21 - Select Database Color
(bits 22-31 unused)

Mars
====
0 - Two Processors (LSB)
1 - Disable Texture
2 - Disable Shading
3 - Disable Illumination
4 - Disable Fading
5 - Enable Compare Test
6 - Enable MISRs
7 - Enable Memory Test
8 - Enable CDRAM Debug
9 - Short Refresh
10 - Disable Texture Updates
11 - Hi Res
(bits 12-31 unused)


For example, 0x80000 is written to the Mercury mode word register immediately before testing culling RAM.

Interestingly there is nothing that suggests anything to do with sun clamping or signed fixed shading values. Perhaps these are set via different registers, or not even via JTAG at all.

[Ian]

The real3d pro 1000 on the arcade boards is 95% similar to the stand alone.

There are some differences or potentially just undocumented functions. Like daytona uses a special flag that inverts the colours of some textures. It's used for the flashing signs. They could have just used two textures but maybe video ram was tight. Daytona is the only game to use this. Maybe they added this functionality for the game? It doesn't exist in any documentation.

The lighting values are just a best guess really. There is nothing in the viewport data or poly headers that we ever found that would explain why the fixed shaded values are interpreted diffently. But every time they change jtag seems to get updated. So our best guess was that the internal gpu settings were getting updated this way. Some games like star wars will flip between different modes. But as a whole scene. They never mix models together that behave differently.

[Bart]

This is really awesome work! Once we get JTAG re-implemented properly, I feel things will become a lot clearer. Being able to understand what the various bits do is a massive step forward for both emulation and archival documentation purposes.

I'm curious what S-Buffer refers to (seems to differ from Stencil) as well as "Fading" and a few others. Argh... I really wish I had invested time into building a USB programming interface to run code on the actual board when I had more free time. It would be really neat to set up some test scene and play with some of these values.

[gm_matthew]

I have determined that the flags used to determine whether sun clamping should be disabled (internalRenderConfig[0] & 0x800000 and internalRenderConfig[1] & 0x400000) correspond to bit 18 (0x40000) of each of the two Mars ASIC mode word registers. (This bit is listed as unused in the Real3D firmware, but it's plausible that newer revisions make use of it.) The "instruction" 0x3fffffd1ffff addresses the mode word register of the first Mars ASIC and shifts in 42 bits, which consists of a 32-bit value with five dummy bits on each side (these dummy bits would end up in the bypass registers of the other ASICs). Instruction 0x3ffffffe8fff addresses the second Mars ASIC, with six dummy bits on the left and four on the right. 0x800000 = 0x40000 << 5 (dummy bits) and 0x400000 = 0x40000 << 4 (dummy bits). So far, so good.

But the flag used to toggle unsigned fixed shading values (internalRenderConfig[0] & 0x1) corresponds to a dummy bit; it is not intentionally written by the game. It actually originates from the ID code instruction, doing a few laps of our 197-bit data shift register before being caught by the UpdateRenderConfig() function. I don't know how Star Wars Trilogy is set up to treat fixed shading values as unsigned, but it is probably not being triggered by JTAG.

I bring this up because implementing JTAG properly will result in Star Wars Trilogy no longer using unsigned fixed shading like it is supposed to (though the current patch in Games.xml breaks this anyway); a workaround will be required until we find what actually enables it.

[Bart]

Is that only used in one single scene or throughout the entire game? There are unknown configuration registers at 0x9c0000xx that are written once on start-up for each game. I don't know what they do but I think they are video board related. However, given the fact that they are never modified again and only contain a few values, I don't think they contain that sort of configuration information. IIRC, there is an unknown table of values written to the texture FIFO (MAME has a comment speculating this might be some sort of gamma data), and I think there is sometimes some unknown stuff written to polygon RAM. Will need to see if Star Wars does anything weird there.

[gm_matthew]

Is that only used in one single scene or throughout the entire game? There are unknown configuration registers at 0x9c0000xx that are written once on start-up for each game. I don't know what they do but I think they are video board related. However, given the fact that they are never modified again and only contain a few values, I don't think they contain that sort of configuration information. IIRC, there is an unknown table of values written to the texture FIFO (MAME has a comment speculating this might be some sort of gamma data), and I think there is sometimes some unknown stuff written to polygon RAM. Will need to see if Star Wars does anything weird there.

Pretty sure it's the entire game. It's most noticeable in the Death Star II tunnel but it also applies to the ground in the Endor Forest level.

It's not the 0x9c0000xx config registers as Sega Rally 2 writes the exact same values but it uses signed fixed shading like all the other games. The gamma table hypothesis sounds intriguing though

[Ian]

Could it be some other jtag bit?
I can do a diff of the viewport and poly data to see if i can figure something out
It's entirely possible it's not jtag related

[Bart]

Viewports would be a great place to look. Is there any chance the shading calculation involves some sort of a color or brightness LUT? If so, that could also be hiding in polygon RAM, although I don't recall there being too much unaccounted-for data there. As far as I know, it's just mesh data, palettized colors, and maybe a few bytes of unknown stuff.

[Ian]

Do you know if the tilegen chip is ever written to?
I had wondered about a few of the features of the tilegen for a while now

[Bart]

Do you know if the tilegen chip is ever written to?
I had wondered about a few of the features of the tilegen for a while now

I think there are some unknown registers in the tilegen space. But there are also supposed to be timing-related registers that don't exist and may be accessed via JTAG?