ATTN Model 3 Board Owners: Anyone willing to run test code?

[Bart]

I had a poke around with vf3 with the status bits. Once the game is loaded the status bit doesn't seem to matter at all. Ie can just return 0 and the game runs at normal speed. So everything must be synced at startup with that particular routine

Right. By the way, do you have your Pro-1000 SDK disassemblies? I've lost them. I'm starting to develop a couple theories and will poke around a little more at home, maybe re-organize my notes on fvipers2 (that is the game into which I've traced the furthest).

Idea 1

The pingpong memory (0x8e000000 according to the API headers) is puzzling to me. If it's a double buffer that swaps, then what prevents it from swapping when a flush is issued immediately after other regions are written? It is absolutely possible that the Real3D keeps tracks of which memory banks are "dirty" and then performs a different action for flush depending on what regions were last modified. Evidence in favor of this is the fact that regardless of whether games flush after each region is written (some games prefer to do this after all memory is updated), they seem to like to flush after every texture upload (IIRC). In this model, "flush" is a "do work" command.

Evidence against this would be the timing routine itself. No memory is written when the flush is performed and the game tries to time the results. Memory is set up ahead of time, and the appropriate flushes are performed then. Nothing is dirty when the flush command is issued in the timing routine I posted, yet something clearly happens.

Idea 2

Maybe rendering happens at fixed points in the frame. Namely, rendering kicks off some time after VBL starts. In this approach, maybe there is a fixed window of time immediately after VBL in which the memory can be written, after which rendering will kick off. Maybe rendering only kicks off if a flush command has been issued. But the point is that it always begins at a given time point. The timing value then represents a sort of window period during which the games are allowed to make updates. If they miss the window, they have to wait until the next frame. If a flush is not issued and the timeout window is missed, or the flush is issued too late, the Real3D will not begin rendering because doing so would make it late the next frame around.

This is essentially what Supermodel currently assumes and what the timing logic is trying to do. It's trying to wait some fixed time after VBL to kick off rendering. Frustratingly, we haven't found the right timing or maybe there is a subtlety we're missing. Or maybe, the flush command acts as a "keep track of what memory regions are dirty", though that makes little sense from a hardware point of view.

At any rate, fvipers2 should help. I have a clear example of frames being missed and the delay routine responsible for that during attract mode. If I can understand how the 3 timing routines work (timing calibration at start up + 2 timing related routines at the beginning and end of the main loop), I think I might be able to crack this.

[Ian]

When i logged what memory addresses were being written most of the time they were the same every frame. In 1996 memory was expensive so i doubt they would use some kind of memory double buffer anyway.

As far as i could tell 3d rendering kicks off after culling memory is updated then 0x88 is called. If the database is updated it's a new frame. Texture and polygon data could be uploaded that's not part of the current scene anyway.

I think if the culling memory is not updated in time the hardware must skip the frame, as it can't render an incomplete database. I think this is what happens when you mess with the start up timing function and vf3 for example will drop to exactly 30fps.

2d rendering ie the tilegen can still render when there is no 3d output, ie during loading sequences.

[Bart]

It would be extremely unusual for hardware to detect that a memory region has been written without some sort of explicit signal. It just isn't done that way.

I'm part of the way through implementing some new frame timing logic. No idea if it will work but I have a hunch that the hardware is indeed frame locked as you once pointed out, and that render stop/start is timed to the VBlank period somehow. I believe the pingpong bit flip duration represents a window of time during which the Real3D is guaranteed not to be rendering, giving the games time to upload data to culling RAM and polygon RAM safely.

I think pingpong memory is indeed a double buffer (they would not name it so otherwise). I don't fully understand the rationale, though, especially if there is a guaranteed idle period. The only thing I can think of is that this is some quirk to support higher refresh rates (the SDK docs indicate support for as high as 120 Hz) or unthrottled rendering. In principle, the pingpong memory (0x8e......) contains all the structures necessary for animating a scene comprised of static culling nodes. It contains the display lists, viewports, and matrices (if I recall correctly). They probably wanted to allow this to be updated while another frame was rendering and, due to memory constraints, were willing to live with a single culling RAM bank and a single polygon RAM bank. It's also entirely possible that there is no real ping-ponging going on at all on Model 3. The bit remains but the actual second memory bank may have been removed.

[Ian]

As far as I can see the real3d standalone works the same way. There is no implicit, render command. The only way it can work is if it detects the database is dirty, then once 0x88 arrives it'll then render.

It would be extremely unusual for hardware to detect that a memory region has been written without some sort of explicit signal. It just isn't done that way.

Same is true with regards to the frame buffer emulation. I don't think any other hardware works that way. Conventional logic would say that design doesn't exist lol. It's possible I guess it works just at fixed timing intervals. If you log the data writes to the culling memory, or just look at the matrices, addresses should swap between frames. I could be wrong but I don't think this is happening.

i *think* but can't remember exactly but the ping/pong buffer swap thing is something happening in the SDK itself. There is one buffer that gets filled up, and another one that actively sends to the device. Then there is a pointer swap between these 2 buffers. But I didn't see the point of it at all because it was single threaded, ie sending would block.

[Bart]

Pingpong memory (8e) is typically accessed last. Is there any game that accesses polygon or culling memory afterwards and expects a frame to be rendered? I didn't realize the SDK double-buffers pingpong memory on the PC side. What is the point of a pingpong bit that is transferred over the SCSI link and which Model 3 games spin on? They all avoid observing its direct value, which suggests it is not a busy bit. Rather, they all wait for it to flip, regardless of initial state. This strongly suggests swapping behavior.

I'm almost certain that writing 0x88000000 doesn't immediately trigger any operation. I think the event is merely stored and later, at a designated time point, is checked to see whether a frame should proceed. A "ready" flag. fvipers2 writes 0x88000000 multiple times per frame. I think Sega Bass Fishing is an extreme case that writes it after every memory region is touched. I believe the way most games are structured is that they can either upload textures, write scene graphs, or both in the same frame. So they have two separate pieces of code that can do either operation, flushing after each. On frames where textures *and* scene graph data are both uploaded, flushing appears to happen twice as a result. fvipers2 often has a flush in the middle of a bunch of transfers but looking more closely, we can see the first flush follows a texture upload.

Maybe what we call the VBL IRQ is actually driven by the Real3D. I noticed that there were two IRQs that fired each frame on my VF3 board (my tests indicated they occurred at the same time, too). If one of these is in fact the Real3D signaling an end-of-frame event, that would explain why the games do not ever need to check the "rendering finished" bit. They all sync to VBL before uploading data...

[Ian]

What is the point of a pingpong bit that is transferred over the SCSI link and which Model 3 games spin on?

I've no idea really. I am guessing quite a few of the bits are probably redundant. I mean the model3 itself only seems to use 1 bit for everything.

Is there any game that accesses polygon or culling memory afterwards and expects a frame to be rendered?

You mean written last? Every game seems to either write culling memory last, or if its mixed in with a bunch of other writes the 0x88 comes last

One game star wars ... from what i recall from memory might be writing this

Texture stuff
PolyRam
Culling mem
0x88
Culling mem
0x88

So either this supports your theory of rendering happening at fixed times. Or we should actually be rendering 2 frames instead of 1 in star wars, and the timing is fubar. I dont know which. I think it was only happening in attract mode.

I think the only way to solve this is to poke the hardware some, and see what it's actually doing. All of my efforts have been unsuccessful so far.

[Bart]

When I say culling RAM I mean specifically 8c, not 8e (ping pong memory). I see 8e being written last. That may just be convention or it may be significant. Does 8c ever get written after 8e?

I did a test last night with interesting results. I was able to get fvipers2 running at full speed through the attract mode and also fixed LA Machineguns tile glitch and mission briefing speed. Results are promising. I think a problem with my previous experimentation was the order in which Supermodel executes the CPU and then renders. I’ll do some more work on it tonight. Current signs point to the bit flip interval as occupying most of the frame time, which would mean it measures the total rendering time per frame.

I agree with you about testing on real hardware. That’s what libmodel3 was intended for but I underestimated the difficulty of getting code up and running on an undocumented board from scratch. Patching games to insert hand-rolled assembly routines will be more likely to succeed.

I’m going to run a few more tests to better understand how games distribute work throughout a frame. I had some flashes of inspiration late last night...

[Jiterdomer]

That's some good news! Keep up the good work!

[VirtuaHunter]

seems promising, nice work Bart