Tilegen

[Bart]

One idea ..
I wonder if we could simply capture all the data from the tilegen (in the emulator) and just send it to the real h/w for testing.
Ie freeze a frame of scud rolling start, then save the data.
If we did that we could eliminate any kind of timing problems. I think the tilegen is compatible between all the different h/w revisions? So could maybe test that that on a step 1.0 board?

This is a great idea! We should absolutely try this. It will reveal a lot.

One of my fears, mentioned in the comments atop Render2D.cpp, is that there is some sort of hardware register involved in setting up an offset. If so, it is being set through JTAG. I know for sure that JTAG is responsible for setting up timing registers that normally would be mapped to some address (as on System 24). I don't know exactly how, though. I just pump in data captured from VF3. However, model3man's information on boundary scan made me realize it should be possible to more diligently analyze how games program the JTAG and actually break down the bit stream into more meaningful parts. Worst case scenario, I could sit down and actually disassemble the entire boundary scan test code. It would take quite a while but we would probably get a really good picture of how the games program each specific chip, which in turn might allow us to isolate the bits that are fed to the tile generator and make sense of them. They almost certainly will map to the various hardware registers that Charles MacDonald has documented on the original System 24 board.

[Ian]

What games use the line scroll mode? As apposed to the whole layer?

[Bart]

Several. VF3 uses it for the screen transition effect during the attract mode and I would guess for the sun ripple effect. Some games might even use it where they technically don’t need to. Not sure how Scud sets up its tiles.

[Ian]

I checked vf3, pretty sure it's just using the whole scroll thing, instead of per line for everything, except the desert stage
Need a few more test cases. Magical truck adventure also isn't using per line scrolling for the text

[Bart]

Just checked and noticed that Scud Race ("Rolling Start" sequence), Daytona USA 2 (during portions of the car/stage select and "Rolling Start"), Virtual On 2 (attract mode), Spikeout (character select) all use it. Why were you interested in it, by the way?

[Ian]

Well if you add an offset of 8 pixels, ie 1 tile scud looks perfect. Was wondering if this could be a display quirk of the hw using the line offset mode. Just needed some test cases to see if it broke anything.

Comparing to the real hw the scrolling is ahead of the emulator by 1 or 2 tiles. I would expect 1 frame ahead by the real hw if the tilegen is single buffered and not drawing into the back buffer. But it looks more than that.

[Bart]

Well if you add an offset of 8 pixels, ie 1 tile scud looks perfect. Was wondering if this could be a display quirk of the hw using the line offset mode. Just needed some test cases to see if it broke anything.

Ah, that's an interesting idea.

What if there is a way to scroll the entire mask via some hardware register? If that were the case, I would expect the mask to be populated once with a fixed pattern and then only the scroll register would be used to shift it in sync with the layer scroll.

Comparing to the real hw the scrolling is ahead of the emulator by 1 or 2 tiles. I would expect 1 frame ahead by the real hw if the tilegen is single buffered and not drawing into the back buffer. But it looks more than that.

I wonder if this is some sort of frame timing related thing but I can't think of how. Surely the game updates the h-scroll value and the mask at roughly the same time.

[Ian]

I wonder if this is some sort of frame timing related thing but I can't think of how. Surely the game updates the h-scroll value and the mask at roughly the same time.

Scud updates everything on IRQ2, except the line scroll values which happen at the ping_pong flip or 66% of the frame.
For us those writes appear in the next frame. I'm pretty sure this logic is correct. But even on the real h/w if they came into effect at 66% of the frame, would still happen in the next frame because the rolling start tiles are drawn at around 50-60 % of the frame. Even if you added 10% vblank time at the time, the writes would still happen after rolling start is drawn. Assuming the screen is drawn from the top? :p



If bump those writes into the same frame, the text looks even more broken.

Give it a try ..

if (lineScrollMode) {
hScroll += 8;
}

Maybe it's a hardware quirk. I dont have time this weekend to really test .. but just give it a spin with some games to see if it has any negative effects anywhere.

[Bart]

Need to make sure this idea works with Magical Truck Adventure. This definitely seems odd. I can see maybe the mask being shifted but the scroll value? I can take a look at other games. Maybe Daytona USA 2 would be a good one because it seems to use line-scrolling to align text during the car select.

And we really should eventually test it on the real hardware to see what's going on. I find it really bizarre that the game does not update the scroll values at the same time as the rest of the tile gen VRAM. However, even if they are doing this incorrectly, being off by one frame would not be noticeable because the mask operates on 32-pixel blocks at a time. So it really depends on when they update this mask value. That seems independent of the frame timing issue, no?

[Ian]

Magical truck doesn't use line scrolling I don't think