Frame timing

[Bart]

I think I might have some ideas to try. Unfortunately, I'm really busy with work and HoloLens-related stuff (attending a couple conferences in May), so it's hard for me to dig into core emulation these days. I do want to see this release make it out in the next couple of months. I'm okay with deferring frame timing until after that, if it's not ready by then. For me, I think having specular lighting working in the new engine and making it the default engine is the top priority for a new release. Then we can go from there incrementally -- hopefully that sounds workable to everyone.

Anyway, looking at the code now, the Real3D status bit is driven by VBlank. Nik's idea was that the bit is some sort of a busy bit and that either the Real3D starts rendering at VBL (almost certainly wrong) or that the bit itself is linked to VBL. So at the start of the VBL period, he takes the current PowerPC cycle count, adds some time to it (to simulate the busy time), and then each time the status bit is read, checks to see whether the PowerPC cycle count has exceeded that new target value. Only then does the bit flip.

I think 0x88000000 drives the rendering process. And if so, the busy bit should be synchronized to 0x88000000 being written, not to VBL starting! Need to double check this.

I think what I may try first is experimenting with GPU threading disabled. The threading code adds some complications. We want to probably call SyncGPUs() when 0x88000000 is written, then render the frame. Meanwhile, the PowerPC should let some cycles elapse after that.

In the long run, SyncGPUs() needs to be split up because it also syncs the tile gen, which is not correct. The tilegen should probably wait until the beginning of the next frame to render. We want to do this in the GPU thread as well so maybe it doesn't matter too much. Eventually, the threading code needs to be rewritten so that the GPU thread is synchronized to PowerPC writing 0x88000000. If the GPU is busy rendering the previous frame (extremely unlikely), we can indeed just drop the frame (meaning we would not swap the ping pong memory) or wait for the GPU to free up.

One remaining question I have is about the non-ping pong memory regions. We probably need to treat them as ping pong memory, too.

[Ian]

0x88 can be called up to 10 times per frame - sega bass fishing, sega rally2
I think it just marks memory writes as complete
The cpu definitely syncs with the status bit. With step 1-1.5 games during the boot sequence they will poll the bit until it flips state. It doesn't matter if it's high or low, only that the state changes

[Bart]

The question is do they interleave writes to 0x88000000 with the polling? If so, then I think this write triggers rendering, and then the status bit probably indicates which buffer is active. Maybe the Real3D grabs the buffer and then the bit flips, so the process can proceed.

As for Bass Fishing writing 10x per frame, does it do this in-game? Does it poll in between those writes? It may well be that when the device is busy these writes don't matter. Or, if it's not happening in-game, the scene data may be empty and the Real3D performs no work (other than perhaps uploading textures). Does it write to culling RAM between these writes? If so, is it perhaps nulling out some pointer the first e.g. 9 times and then "enabling" the scene before the final 10th write?

[Ian]

I am pretty sure no gpu writes happen during polling. 0x88 only gets called after texture or culling memory updates

[Bart]

I'll have to check and see what's going on. What I mean is that the game could perhaps upload a "blank" scene and trigger the Real3D multiple times per frame because the scene would complete in virtually no time. It may be the result of some weird way of streaming in textures. I wouldn't rule out 0x88000000 as the rendering trigger just based on one game yet.

[Ian]

Mame uses it as a rendering trigger, but that's why some of the games work at 1fps. Because it's called multiple times per frame

[Bart]

How does MAME handle the status register? Does it actually eat PowerPC cycles or does it just get flipped immediately?

[Ian]

Without looking at the source not sure. But games won't even boot if you do that, they will carry on polling. I messed about with many values for the status bit and it always stopped some random games from starting.

[Bart]

Code: Select all

READ64_MEMBER(model3_state::real3d_status_r)
{
   m_real3d_status ^= 0xffffffffffffffffU;
   if (offset == 0)
   {
      /* pretty sure this is VBLANK */
      m_real3d_status &= ~0x0000000200000000U;
      if (m_screen->vblank())
         m_real3d_status |= 0x0000000200000000U;
      return m_real3d_status;
   }
   return m_real3d_status;
}

[Bart]

It just ties it to VBL... hmmm... That's odd. I would not expect the games to trigger multiple times in such a case. Either that or the subsequent triggers should simply be dropped when a frame is being processed. It's entirely possible that when the device is busy, the command does nothing. Or maybe, it will process texture maps or something else while it waits for a frame to complete.