Sega Virtua Processor/Virtua Racing Research

Discussion in 'Engineering & Reverse Engineering' started by Ralakimus, Nov 12, 2018.

  1. Ralakimus

    Ralakimus

    pretty much a dead account Tech Member
    557
    162
    43
    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.

    [​IMG]

    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.

    [​IMG]

    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.
     
    Last edited: Oct 21, 2019
    • Informative Informative x 3
    • Like Like x 1
    • List
  2. biggestsonicfan

    biggestsonicfan

    Model2wannaB Tech Member
    1,182
    130
    43
    Formerly Sonic the Fighters
    Holy SHIT my mind is blown!
     
  3. Ralakimus

    Ralakimus

    pretty much a dead account Tech Member
    557
    162
    43
    Just an FYI for that screenshot, I made a simple converter that converts SVP models to OBJ... with a material file that has every possible color combination from the palette lol. Gonna eventually make a simple OBJ to SVP converter so I can create custom models.

    EDIT: Actually...
    [​IMG] [​IMG]
     
    Last edited: Oct 22, 2019
    • Like Like x 2
    • Useful Useful x 1
    • List
  4. Overlord

    Overlord

    Now playable in Smash Bros Ultimate Moderator
    17,976
    236
    43
    Berkshire, England
    Learning Cymraeg
    That's really really cool.
     
  5. JaviTaiyou

    JaviTaiyou

    Member
    4
    5
    3
    This is superb work, congratulations!!
     
  6. Ralakimus

    Ralakimus

    pretty much a dead account Tech Member
    557
    162
    43
    [​IMG]
    [​IMG]

    :)
     
    Last edited: Oct 24, 2019
    • Informative Informative x 2
    • List
  7. Aesculapius Piranha

    Aesculapius Piranha

    つづく Oldbie
    4,323
    32
    28
    Unknown
    Diva
    Who needs trees when you have monkey heads?
     
  8. Ralakimus

    Ralakimus

    pretty much a dead account Tech Member
    557
    162
    43
    I ripped all the models I could find in Virtua Racing and converted them into OBJ format. I also provided the original SVP format files as well.

    Download

    I still need to figure out how to handle palettes for exporting before I release this add-on for Blender at all. If anyone here has any ideas at all, please shoot em towards me. The way I currently have it set up for importing is that it creates a material for every possible color combination from a palette. This wouldn't be so bad if it weren't for the fact that each face is assigned 2 colors from the palette, so with this setup, it's super counter intuitive and hackish.
     
    Last edited: Apr 18, 2020
    • Like Like x 4
    • Useful Useful x 1
    • List
  9. Ralakimus

    Ralakimus

    pretty much a dead account Tech Member
    557
    162
    43
    upload_2020-4-17_23-1-55.png

    Getting something figured out...
     
  10. Ralakimus

    Ralakimus

    pretty much a dead account Tech Member
    557
    162
    43
    Yeah, I know, the 3rd bump in a row, but things are really looking up now.

    upload_2020-4-20_5-0-55.png
    upload_2020-4-20_7-26-52.png

    I may be able to release this soon!
     
    Last edited: Apr 20, 2020
  11. LForoni

    LForoni

    Member
    2
    0
    1
    Your work is amazing.
    Truly inspire me to try something.

    Sometime ago I tried to recreate the beginner track by hand, and failed spectacularly.
    Can't wait to see more.
     
  12. Ralakimus

    Ralakimus

    pretty much a dead account Tech Member
    557
    162
    43
    I wouldn't expect to see much more in the near future. I have other crap to work on + IRL stuff getting in the way. I would've gotten the plugin finished a good while ago, but shit happened.
     
  13. JaviTaiyou

    JaviTaiyou

    Member
    4
    5
    3
    Hi! As I've already posted about my own progresses in the past with SVP research (nothing as far as the progresses Ralakimus has done in the thread), let me continue this thread with what happened to my project and where it's going. I've been posting this kind of stuff in Twitter but I guess it's a good idea to continue here too just in case people in the forum are interested :).

    1) My original approach was to replicate the SVP as faithfully as possible in an FPGA, in order to place it in a dev cart to be able to develop new games for it. I got as far as having a more or less faithful replica of the SVP (or at least how I understood it works), with a set of dev tools (an assembler, already published in the thread 2 years ago - also a full-fledged debugger that allows to read/write registers, all memories... in real time while the thing was running on hardware). But my design was EXTREMELY (and needlessly) complex and it all fell appart while I was trying to interface my replica with the Sega Genesis. So I'd consider this approach... a failure lol. I left that project aside and focused on relearning Verilog and learning a bit of basic electronics beyond FPGAs to help me go further with other stuff.

    2) I fell it was a shame that the work I did with it was for nothing, so during this Xmas holidays I had the idea of taking another approach. Instead of building a whole dev cart, why not interface the actual SVP in the Virtua Racing cartridge? So I started working on this! The following are the steps I'm going to attempt:

    - Desoldering the ROM chip. This was already done, hopefully without destroying the ROM chip in the process. (In the picture above is my original childhood copy of VR for the SEGA Mega Drive, below is a spare copy I've picked up for this project - ROM already desoldered).

    [​IMG]
    [​IMG]

    - Dumping the game from the ROM chip to confirm the actual pinout. There's been a couple of attempts to verify this AFAIK, by looking at the traces of the Virtua Racing dev cart and the ones in the actual cartridge. AFAIK no one has tried to confirm this from the chip itself (if I'm wrong please let me know :D). I've got an "adapter" coming from JLCPCB that will expose the chip pins easily so I can interface it. My two approaches on this step are first try to reroute the pins to a known similar EEPROM that's compatible with my EEPROM universal programmer so I can try to trick it into dumping the whole thing. Otherwise I'll need to resort to use my FPGA to do it by hand (hope that I don't have to get to that).

    - Designing a ROM-EEPROM adapter board. Once I verify the pinout of the ROM chip I'll be in a position to reroute these. My current idea is to have one board that will be soldered in place of the previous ROM and will expose a set of header pins. Then another board that will carry a set of EEPROMs sockets (PLCC) that I can write with my universal writer and then place on this board and connect it to the pins I mentioned. Potentially at this stage I'd be able to run a regular ROM and then Virtua Racing to verify that everything's going fine.

    - Running custom code on this thing. If I get to this point I'd be able to run actual SVP code. At this stage I'd start by making a small "hello world" that communicates with the SVP from the 68K side and sees if the whole communication is working. Later I want to build a ROM that contains all the "unit tests suites" I have developed for the SVP while I was working with my original approach. These test most of the instruction set and features (i.e.: running code from IRAM, working with the programmable memory registers...). This will probably take a while as 1) I don't have any idea about 68K assembly lol (will probably use SGDK in any case) 2) potentially there'll be lots of tests failings, and I'll need to make sure what's the issue with these (i.e.: the assembler that I wrote is not 100% accurate? I took wrong assumptions on what the hardware actually does?)

    - Other steps. Getting here, besides being a happy and proud person, I'd be focused on researching on unknown stuff regarding the SVP (i.e.: what's the function of PM5?), and trying to confirm what's already known to the best of my knowledge. Also once I verify that the EEPROM thing is working I'll release the dev boards and all that so that anyone could build it and play with it. Potentially there's also the option of building another adapter that could redirect the ROM pins to an actual Genesis cart slot (ala passthrough cartridge, as it was once thought it'd work), but that's way too long in the future to tell :).

    Anyway, not much information yet but I'll try to keep you posted with any future progresses.

    Thanks!!