Frame timing

[Bart]

I see we are running VBL first and I agree it shouldn't matter if it's at the start or at the end.
But what triggers 'vbl'? The IRQ that gets called? Because calling it after 'VBL' doesn't seem to make any difference

It would be interesting to find out what the correct VBL time actually is. Maybe the guys that did the model2 project would know, I am sure the value is similar for that, given they both use the crazy 57.5 fps.

The IRQ is the primary way that the game gets notified of VBL.

Now I'm confused. I don't quite understand why the games care at all about the duration of the VBL because as you say, we assert the IRQ at the beginning and there isn't really anything that informs the games of start-of-frame/end-of-VBL. The VBL bit would certainly serve that purpose. If you raise the bit at the start of VBL and then lower it when VBL is over, you don't see any improvement in behavior?

One thing we are doing is raising all of the other interrupts at the *end* of VBL. Maybe one of them is being used to drive timing somehow in certain games. However, I seem to recall that most of these are unused. Magical Truck may use some of them. I think I posted about that several months ago.

I've been getting more involved with HoloLens stuff to the point that I have no spare time for anything else it seems. But I need to dig in and examine how the games perform frame timing. I'm not sure where to start because the main game loop can be intimidatingly large but I figure I should perhaps disassemble a few of the games' interrupt handlers and see if any of them do anything interesting. I think we've gotten the farthest with scudplus before. Maybe I'll start poking around next week again.

[Ian]

I noticed sometimes the tilegen takes 1-2 complete frames worth of time to update the tile gen memory (ie much longer than v-blank). We are drawing the data when it's not complete so we see significant garbage during some transition scenes like in scud plus.

I noticed in these cases, the game seems to fire off

void CTileGen::WriteRegister(unsigned reg, UINT32 data)

The reg value 0x10, with the value 0x6e. This is some IRQ i I think. If i was to guess i'd say it's telling the tilegen the data is not complete and not to draw anything.

Code: Select all

addr 20d6c 30.173292
addr 20d70 30.173772
addr 20d74 30.174252
addr 20d78 30.174732
addr 20d7c 30.175212
regs 10 6e 30.293652 <-------------------------
addr 21000 30.297372
addr 21004 30.297852
addr 21008 30.298332
addr 2100c 30.298812
addr 21010 30.299292
addr 21014 30.299772
addr 21018 30.300252
addr 2101c 30.300732
addr 21020 30.301212
addr 21024 30.301692
addr 21028 30.302172
addr 2102c 30.302652
addr 21030 30.303132
addr 21034 30.303612
addr 21038 30.304092
addr 2103c 30.304572
addr 21040 30.305052
addr 21044 30.305532
addr 21048 30.306012
addr 2104c 30.306492
addr 21050 30.306972
addr 21054 30.307452
addr 21058 30.307932
addr 2105c 30.308412
addr 21060 30.308892
addr 21064 30.309372
addr 21068 30.309852
addr 2106c 30.310332
addr 21070 30.310812
addr 21074 30.311292
addr 21078 30.311772
addr 2107c 30.312252
addr 21080 30.312732
addr 21084 30.313212
addr 21088 30.313692
addr 2108c 30.314172
addr 21090 30.314652
addr 21094 30.315132
addr 21098 30.315612
addr 2109c 30.316092
addr 210a0 30.316572
addr 210a4 30.317052
addr 210a8 30.317532
addr 210ac 30.318012
addr 210b0 30.318492
addr 210b4 30.318972
addr 210b8 30.319452
addr 210bc 30.319932
addr 210c0 30.320412
addr 210c4 30.320892
addr 210c8 30.321372
addr 210cc 30.321852
addr 210d0 30.322332
addr 210d4 30.322812
addr 210d8 30.323292
addr 210dc 30.323772
addr 210e0 30.324252
addr 210e4 30.324732
addr 210e8 30.325212
addr 210ec 30.325692
addr 210f0 30.326172
addr 210f4 30.326652
addr 210f8 30.327132
addr 210fc 30.327612
addr 21100 30.328092
addr 21104 30.328572
addr 21108 30.329052
addr 2110c 30.329532
addr 21110 30.330012
addr 21114 30.330492
addr 21118 30.330972
addr 2111c 30.331452
addr 21120 30.331932
addr 21124 30.332412
addr 21128 30.332892
addr 2112c 30.333372
addr 21130 30.333852
addr 21134 30.334332
addr 21138 30.334812
addr 2113c 30.335292
addr 21140 30.335772
addr 21144 30.336252
addr 21148 30.336732
addr 2114c 30.337212
addr 21150 30.337692
addr 21154 30.338172
addr 21158 30.338652
addr 2115c 30.339132
addr 21160 30.339612
addr 21164 30.340092
addr 21168 30.340572
addr 2116c 30.341052
addr 21170 30.341532
addr 21174 30.342012
addr 21178 30.342492
addr 2117c 30.342972
regs 10 6e 30.461412    <--------
addr 21400 30.465132
addr 21404 30.465612
addr 21408 30.466092
addr 2140c 30.466572
addr 21410 30.467052
addr 21414 30.467532
addr 21418 30.468012
addr 2141c 30.468492
addr 21420 30.468972
addr 21424 30.469452
addr 21428 30.469932
addr 2142c 30.470412
addr 21430 30.470892
addr 21434 30.471372
addr 21438 30.471852
addr 2143c 30.472332
addr 21440 30.472812
addr 21444 30.473292
addr 21448 30.473772
addr 2144c 30.474252
addr 21450 30.474732
addr 21454 30.475212
addr 21458 30.475692
addr 2145c 30.476172
addr 21460 30.476652
addr 21464 30.477132
addr 21468 30.477612
addr 2146c 30.478092
addr 21470 30.478572
addr 21474 30.479052
addr 21478 30.479532
addr 2147c 30.480012
addr 21480 30.480492
addr 21484 30.480972
addr 21488 30.481452
addr 2148c 30.481932
addr 21490 30.482412
addr 21494 30.482892
addr 21498 30.483372
addr 2149c 30.483852
addr 214a0 30.484332
addr 214a4 30.484812
addr 214a8 30.485292
addr 214ac 30.485772
addr 214b0 30.486252
addr 214b4 30.486732
addr 214b8 30.487212
addr 214bc 30.487692
addr 214c0 30.488172
addr 214c4 30.488652
addr 214c8 30.489132
addr 214cc 30.489612
addr 214d0 30.490092
addr 214d4 30.490572
addr 214d8 30.491052
addr 214dc 30.491532
addr 214e0 30.492012
addr 214e4 30.492492
addr 214e8 30.492972
addr 214ec 30.493452
addr 214f0 30.493932
addr 214f4 30.494412
addr 214f8 30.494892
addr 214fc 30.495372
addr 21500 30.495852
addr 21504 30.496332
addr 21508 30.496812
addr 2150c 30.497292
addr 21510 30.497772
addr 21514 30.498252
addr 21518 30.498732
addr 2151c 30.499212
addr 21520 30.499692
addr 21524 30.500172
addr 21528 30.500652
addr 2152c 30.501132
addr 21530 30.501612
addr 21534 30.502092
addr 21538 30.502572
addr 2153c 30.503052
addr 21540 30.503532
addr 21544 30.504012
addr 21548 30.504492
addr 2154c 30.504972
addr 21550 30.505452
addr 21554 30.505932
addr 21558 30.506412
addr 2155c 30.506892
addr 21560 30.507372
addr 21564 30.507852
addr 21568 30.508332
addr 2156c 30.508812
addr 21570 30.509292
addr 21574 30.509772
addr 21578 30.510252
addr 2157c 30.510732
regs 10 6e 30.629172
addr 21800 30.632892
addr 21804 30.633372
addr 21808 30.633852
addr 2180c 30.634332

[Bart]

That's an IRQ ack, I think. It's kind of strange because it seems there are two different IRQ ack mechanisms, one of them mapped in the tile gen reg space. The tile gen can only fire vsync interrupts.

I wonder maybe something weird is going on like IRQs are being cleared too quickly or at the wrong time. Charles MacDonald has an excellent write up of the System 24 hardware including the tile gen chip. The registers are configured differently and there is no IRQ ack in the same space. But that system also operates at 57.5 Hz and Charles has a detailed breakdown of frame timing we could use to probably fix ours.

https://segaretro.org/Sega_System_24_Ha ... 2013-06-16)

I may have a newer version of this document in my email. I should gather some more info about the order of tile gen writes relative to various events during the frame (VBL begin, status register changed by us, IRQ fired) and see what he makes of it. This two frame bug is a good catch and could help us solve the riddle.

[HarryTuttle]

I'll post what I've done about this subject. It's the result of a ridicule number of rewrites of the function "RunMainBoardFrame" during the last months . I still have not really understood how GPU syncs with Tile Renderer, I just reorganized and redistributed the cycles-per-frame.

I've kept an eye to the "IRQ enable" state of system registers, the GPU flush condition and "commandPortWrittenRO" condition.

I've found that by splitting the frame in 3 "moments" (in this order: sound cycles, GPU cycles, VBlank cycles) we can improve emulation performance and accuracy. That's because, as commented on <Model3.cpp>, only one interrupt at time can be processed. I don't know how much cycles are needed before deasserting a line, mine is just a best guess. In <Real3D.cpp> the "statusChange" now depends on the state of "commandPortWritten".

I've left the choice to tweak "PowerPCFrequency" value in configuration, so it'll still affect part of the process; that's because some game needs a bit more power to function properly (Scud, Dirt Devils, Virtua Striker 2 and variants). A good starting point could be "66" for Step 1.0, "100" for Step 1.5, "166" for Step 2.x, then if a game shows slow-downs or halts or the sound freaks out add a little bit more power, in values of "10".

I've commented every step to try to explain my interpretation of the entire process (except for the sound section comment which is copied from the original code).

I think that could be a starting point, especially for you people with a much better understanding of the machine in general.

Pros:
- general emulation speed increased, also more constant frame rate (like in the Hall-of-Fame scrolling list in ECA);
- the brief FMV intro in Scud Plus doesn't show any tearing;
- the final rapid still image sequence in the attract intro of ECA is not garbled;
- the boot phase in Magical Truck Adventure runs at full speed. The horizontal scrolling text during the attract mode don't show left-overs to the left side of the screen. The multiple "rings" that compose the green skirt of the girl, are perfectly stitched instead of being a bit detached;
- the boot sequence of L.A. Machineguns and VON 2 runs at full speed;
- some fade-in and fade-out effect in various games don't show garbled graphics just before or after (L.A. Machineguns, Daytona 2 intro);
- the briefing in L.A. Machineguns runs at full speed;
- Fighting Vipers intro runs way faster and objects don't show missng/corrupted textures;

Cons:
- due to the big changes in timings, your current save states are now useless. Using them will at best revert to the old behavior, at worst halt emulation. Sorry but there's nothing I could do about that;
- loading a savestate saved with a different "PowerPCFrequency" value could bring the aforementioned problem (to confirm);
- Virtua Striker 2 and variants need a "PowerPCFrequency"of 300 or more;
- Dirt Devils is slow only during the attract mode, to solve that use a "PowerPCFrequency" around 450, but normal gaming will be obviously much slower on lower-end computers;

I've included a couple of bonus fixes in <ConsoleDebugger.cpp>:
- a typo "loststate" -> "loadstate";
- a fix for "ISO C++ forbids comparison between pointer and integer [-fpermissive]" error at compile time for GCC v7.1.x under MSYS2 (it was just a matter of quotes vs double-quotes);

Here it is:

[Ian]

Looks like you've done some good work Harry. I'll let Bart digest this because I only have a limited understanding on how these parts of the system work

[Jiterdomer]

Very nice progress Harry. Once Bart tested it, will it be committed on the next build?

[HarryTuttle]

Once Bart tested it, will it be committed on the next build?

Who knows

Bart is very busy and my code is more a hack than proper emulation, I think he and Ian prefer to better understand the inner working of Model3 than submit a hackish workaround.

Obviously, since there's at last some little improvement from the original code, personally I would like that to be merged...

[HarryTuttle]

PATCH UPDATE:

- Consmetic changes (comments, function names);
- Added GPU and TileGen Begin/End VBlank function calls like in the original code (although they do nothing);
- Lowered the limit of "PowerPCFrequency" to "33";
- The cycles of the supposed VBlank period are now fixed (925000). Should improve overall accuracy and resolves some artifacts in the attract mode of Sega Rally 2. Some game may run a bit slower;
- The boot sequence of Magical Truck Adventure *NEVER* ran at full speed (at least on my PC). Don't know why I wrote that before...

[Ian]

I'm quite interested to see what Bart thinks of this. I'd like to contribute something useful to frame timing but I don't have a lot of low level underlying knowledge of how things like IRQs work.

[Bart]

Just wanted to drop by and say that I will try my best to test this Thursday evening. I'm flying cross-country to San Francisco and will look at this during my 5 hour flight I also plan to keep myself occupied by disassembling Fighting Vipers 2 and perhaps trying to detect its main game loop.

A lot of this sounds very promising but a point of concern is that some games now require clock speeds far in excess of the actual machine's. Note that in emulation, we do *more* work per simulated clock cycle than the actual CPU could have (because we don't emulate instruction timings accurately and don't take into account things like memory latency and stalls that can occur as a result of that). So if 300 MHz is required, something is still not right. But it sounds like you have cleaned up the code and put us on a better track so I'm excited to play around with it.