Frame timing

[Bart]

I think Step 1.5 uses SCSI as well. Step 2.x uses the Real3D DMA, which is indeed simpler. But I think that the Real3D memory space is actually visible to the PowerPC directly, so for testing purposes, data can be copied over that way. The hard part is figuring out which obscure bit in which magic register is blowing things up It's just trial and error really. The easiest way to proceed is to duplicate everything the games write initially and then experiment with removing/changing the values.

Unfortunately, I'm back in New York now so it'll be a few months before I have access to the boards again. But if a promising development solution (a convenient adapter board or SRAM-based EPROM emulator) ends up materializing sooner, I'll probably just snag another board off of eBay for use here in New York.

[Ian]

Random question for Bart
In our main emulator loop we are asserting IRQ 2 once per frame. On the real hardware what would be driving this thing? Is it possible the timing of these irqs are off somehow?

[Bart]

On the real hardware, it would be the tile generator's internal frame-timing circuitry. The timing of the IRQ corresponds to the VBL signal. It is 100% certain that the tilegen generates such a signal (Charles has documented this extensively). However, it is entirely possible that the Real3D also generates an equivalent signal with slightly different timing. Without attaching a logic analyzer to the boards, it's hard to know for sure, but I think it's very reasonable to assume this is coming from the tilegen. My findings from running actual code on the board are that there are *two* IRQs asserted each frame (I think IRQ 0x1 and 0x2). And I think they are asserted simultaneously. It could be the same line wired to two IRQ controller inputs for some reason (the games stub out the IRQ 0x1 handler) or it could be two separate sources generating an IRQ at the same time (e.g., Real3D + tilegen).

It definitely doesn't happen more than once per frame, though. I think my Model 3 test program confirms that. In fact, I use this IRQ to compute the refresh rate, which matches exactly the System 24 and Model 2 rates. If the IRQ was fired more than once per frame, this number would be way off.

As for the timing within the frame being off, it's possible. I think I made a note about what Charles' documentation says. He's mapped out precisely at which point in the frame this IRQ is raised. When I was playing around with frame timing, I thought maybe on Model 3, it was raised on a different scanline. It's hard to say for sure because the Real3D status bit timing value also plays a crucial role in frame timing.

[Ian]

:edited

[sonic32]

Thanks Ian, that's another big progress.

[Ian]

actually i screwed up the maths somewhat >_<
the investigation continues ..

[Ian]

Bart
if you got some time try this ..

Code: Select all

void CModel3::RunMainBoardFrame(void)
{
  UINT32 start = CThread::GetTicks();

  // Compute display and VBlank timings
  unsigned ppcCycles   = m_config["PowerPCFrequency"].ValueAs<unsigned>() * 1000000;
  unsigned frameCycles = ppcCycles / 57.5;
  unsigned vblCycles   = (unsigned)((float) frameCycles * 5.f/100.0f);
  unsigned dispCycles  = frameCycles - vblCycles;
 
  // Scale PPC timer ratio according to speed at which the PowerPC is being emulated so that the observed running frequency of the PPC timer
  // registers is more or less correct.  This is needed to get the Virtua Striker 2 series of games running at the right speed (they are
  // too slow otherwise).  Other games appear to not be affected by this ratio so much as their running speed depends more on the timing of
  // the Real3D status bit below.
  ppc_set_timer_ratio(ppc_get_bus_freq_multipler() * 2 * ppcCycles / ppc_get_cycles_per_sec());
 
  unsigned statusCycles;
  statusCycles = (unsigned)((float)frameCycles * 5.0f / 100.0f);

Code: Select all

// Registers seem to range from 0x00 to around 0x3C but they are not understood
uint32_t CReal3D::ReadRegister(unsigned reg)
{
  DebugLog("Real3D: Read reg %X\n", reg);
  if (reg == 0)
  {
#ifndef NEW_FRAME_TIMING
     uint32_t status = (ppc_total_cycles() >= statusChange ? 0x02000000 : 0);

It works with virtually everything (at the correct speed too)

I know why the textures too never showed up (or showed up late) in fighting vipers. If you look at where the writes happen in the frame you can kind of estimate the CPU usage for the current frame. Basically the places where the textures load late, cpu usage for the frame is nearly 100%. So I assume it uses spare time to push textures to the real3d, only at 50mhz it's simply not fast enough. Bumping to 100 or 166 basicallly fixes the issue.

[Ian]

scud plus works too with no tearing

[Joaquim Gonçalves]

Galaxy Car shine...

[Ian]

Some more updates
With regards to skichamp anyway .. the status bit controls when to start writing to the 3d. I've dumped the timing values as to when in the frame they are written. You can see the status bit directly controls when this happens.





With regards to scud plus timing. I couldn't figure out in my own code why it was working sometimes and not others. It's not the timing value that it cares about so much. I don't think it cares for any specific numbers to be that accurate.

But what makes all the difference is doing this

Code: Select all

   ppc_execute(vblCycles);
   IRQ.Assert(0x02);

If you run VBL cycles before irq2, timing is almost always perfect, tearing is almost completely eliminated in the video, same for a whole bunch of other games. They don't seem to care exactly when you fire IRQ2 or what the value of the status bit is set to.

But ski champ wont even boot if you run vbl cycles first, regardless of any status bit values you give it. I think LA machine guns has the same issue.

So it's the order of our IRQs I think that could be off somehow.