So, I pretty much have a good grasp on how exactly Virtua Racing handles the generated tiles from the SVP. Normally, a Genesis game would keep itself in sync with VSync, and then do all the major graphics transfers during VBlank. However, because the number of tiles generated by the SVP is so large, even with display disabled and with DMA, it would take too long to transfer all of them to VRAM without some issues. So, here's what Virtua Racing does: The game doesn't (always) sync itself with VSync, but rather it utilized the H-INT and a counter. Every 8 scanlines, a counter (whose base value is 0x1B) is decremented, and once that counter has run out, it resets the counter (V-INT also resets the counter), it then starts doing all the major graphics transfers. Notice that 0x1B * 8 = 216, 8 pixels less than the typical 224 vertical resolution. What the game is doing here is it's making it so that it starts the updates earlier than normal, and also ends before where the graphics start displaying. Of course, with that in mind, it purposely has top and bottom borders, so the game isn't full screen. The H-INT routine also uses a flag in which when clear, it won't run the updates at all. I'll mention it later down below. And also here's how a general game loop works: Wait until the H-INT counter is set to 0x1A Once that condition is met, run one of the following routines Frame initializationn Render setup (part 1) Render setup (part 2) Render setup (part 3) and game execution Frame lag Set to allow updates to run during H-INT and wait for updates to happen Loop The "frame initialization" tells the SVP to start generating tiles and also tells the H-INT to do game mode specific general updates. The "render setup" is split up into 3 parts as you can see. Here's what the H-INT does for each part: Part 1 transfers the first 0x26C0 bytes of generated tile data from the tile buffer via DMA, and also sets the background's HScroll. Part 2 transfers the next 0x1280 bytes from the tile buffer, and if a flag is set, it'll transfer the palette data to CRAM, and then also transfer HScroll data for a scroll by scanline setup (used in the 2P mode to scroll the backgrounds in each screen independently) Part 3 transfers the final 0x26C0 bytes from the tile buffer, and sets the VScroll value, depending on which tile buffer is being used. The "frame lag" only happens when the SVP isn't fully completed with generating tile data. Typically, it'll just tell the H-INT to do the same updates as in "frame initialization". In the end, it's possible that the SVP is capable of producing graphics real quickly, and that the reason the framerate is limited the way it is is due to tile transfer speed limitations, but don't take my word for it. Spoiler: Also... And may I ask, where the tidbit on information on Sega Retro that says that the SVP performs lighting calculations and texture mapping came from? AFAIK, the SVP don't support these at ALL.