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.
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...
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.
Yeah, I know, the 3rd bump in a row, but things are really looking up now. I may be able to release this soon!
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.
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.
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). - 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!!
Quick update to the previous post! Today I finally got the board that exposed the Virtua Racing ROM from China and soldered the chip. While waiting for it I played a bit with wirewrapping to have a board that would "translate" the pinout of the chip to a known EEPROM pinout that my EEPROM reader could dump. After some tinkering... I managed to dump the whole thing! So the assumptions I saw over the Internet regarding these ROMs were 100% accurate (posting the same pinout I saw around for reference). So this weekend I'll start working on the adapter boards that will substitute this chip so I can drive custom code to the cartridge . Will keep you posted on how it goes!
@Lostgame thanks!! Even though I liked my first approach, I think this one (using the actual SVP chip) can unveil a lot of unknowns. So looking forward to running custom code on this thing :D
Some progress update on my end . Still gotta review these, but probably tonight I'll send the following boards for manufacturing. The first one is the board that will substitute the ROM (it'll use castellated holes so it can be soldered to the ROM pins in the VR cartridge) and exposes thoses pins to a connector. The other one attaches to that connector and uses an EPROM to provide code to the SVP. I wanted to use EEPROMs, but couldn't find a 5V one that was 2MB and was easily accessible to reprogram with my EEPROM universal programmer (spend some time trying to make a board that would use 4x512K EEPROMs but it was a mess really lol). In any case this would be for my first experiments, and if the SVP can boot up from the EPROM I'll try to prepare a separate board that will connect it to a separate cartridge slot so something like an Everdrive can be used to provide code (which I think would be way more convenient for developers out there that want to take a dip on the SVP using all this). Will keep you updated when these arrive and I can play with them! :D
While hardware comes home, I've started working on a test ROM to execute my current SVP tests (the ones I used to test my FPGA implementation) in a MD ROM that runs on the real thing. It was kinda tricky to make KEGA work (thanks again to the awesome Ralakimus posts for that!), and also considering my experience with M68000 and MD development was totally nil until yesterday. There were also some mistakes in how I assumed the MD side of things worked, had to disassembly the MD-side of the VR hardware test to see how these checks were done there... But here it is! The first test running correctly in KEGA. I've noticed some discrepancies in how KEGA emulates the SVP and how my version did it (also MiSTer's emulation behaves as mine did, funnily) - when the SVP writes in the XST register, these writes aren't accessible in the MD side when emulated by KEGA, but they can be read in MiSTer (and my) emulation. It's gonna be fun to see how the real hardware works! EDIT: Today I was able to run this in real hardware (without a SVP yet) to make sure I have something of my own to test when I mount the board to VR. Funnily the behavior of the Mega Drive trying to run these tests matches the ones of MiSTer (without forcing SVP emulation) and Mega SG (it freezes when I try to access the XST and XST_State registers, or the DRAM chip). Software emulators don't seem to follow this (Exodus, BlastEm and KEGA - without modifying the header to trigger the SVP on) and trigger the "test error" in my code after my checks fail - also random data in XST and XST_State when I print them in screen. It will be really fun to start running these things in real hardware and compare behaviors and all that :D.
Did you think about adding a cartridge slot with Address/Data pins wired to SVP ROM pads and the remaining pins necessary for a flashcart to work Straight through?
@PhyChris yup! That's on my plans as soon as I verify that the EPROM approach works (mainly because it's a pain in the *** to erase them lol). That's part of the reason I used a socket to expose the ROM pins, so I can use different approaches. I have a MD cart slot coming too, so I'll be able to test with prototype boards and see if I can get it working with a flash cartridge . I'm not entirely sure how the AS signal should work so I prefer to test different stuff until I'm sure it works that way too. If I manage to get that working I'll design a separate PCB to allow that (as I guess it's the "proper" way to do it ) EDIT: I've been playing for a bit with SVP code and I was able to generate graphics from the SVP side and put them on the VDP with DMA! It's nothing exciting yet: the MD sends a color to draw to the SVP and it writes a bunch of tiles with that same color. The MD then DMA's them to VDP to show them in an area of the screen. I've had issues so far with how the tilemaps work (I'm a total noob with MD code) but at least seeing the colors pop up was amazing!
