Frame timing

Technical discussion for those interested in Supermodel development and Model 3 reverse engineering. Prospective contributors welcome.
Forum rules
Keep it classy!

  • No ROM requests or links.
  • Do not ask to be a play tester.
  • Do not ask about release dates.
  • No drama!

Re: Frame timing

Postby Bart » Wed Dec 27, 2017 12:53 pm

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.
User avatar
Bart
Site Admin
 
Posts: 2135
Joined: Thu Sep 01, 2011 2:13 pm
Location: New York City

Re: Frame timing

Postby Ian » Tue Feb 06, 2018 11:30 am

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?
Ian
 
Posts: 1369
Joined: Tue Feb 23, 2016 9:23 am

Re: Frame timing

Postby Bart » Tue Feb 06, 2018 12:24 pm

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.
User avatar
Bart
Site Admin
 
Posts: 2135
Joined: Thu Sep 01, 2011 2:13 pm
Location: New York City

Previous

Return to The Dark Room

Who is online

Users browsing this forum: No registered users and 1 guest