Virtua Racing! Reveal your secrets!

I've been doing a little more prodding at Virtua Racing over the weekend. I'm trying to find a way to raid the internal ROM data in the SVP. It's defeated me so far, but I'm picking up another 2 or 3 copies off ebay which I can destroy mercilessly. Once they arrive I'll be able to try some more extreme measures hardware wise. Until then, I'll be attacking it more thoroughly from the software side with the aid of the MegaCD. With the aid of MoD's extremely useful SegaCD transfer suite, I should be able to upload a few small programs to map out the boundaries of the interface to the SVP, and hopefully find an avenue I can use to trojan the chip. I've also been dumping the contents of the DRAM and other memory in the range 0x300000-0x400000 from the system during execution, but nothing particularly interesting has come from it.

Anyway, for any of you who have Virtua Racing and are curious to see a debugging curiosity that few others have seen, I've got a process to kick the game into its internal test menu. Charles MacDonald put out some notes years ago about his discoveries from disassembling the test menu code, but I don't know that he ever had a way to activate it on the real system, or if he did he never published it. If you have a Game Genie, you can activate the test menu. Note that the Pro Action Replay will NOT work. There's a clash on memory addresses between the PAR and the SVP interface in Virtua Racing. Virtua Racing is unable to boot with any of the 3 versions of the PAR attached. Anyway, here's my rough notes about enabling the test menu that I wrote while I was going:

I've got some other preliminary notes on the SVP interface which are a little more complete than what's currently out there, but I'll wait until I've done some of my tests from the MegaCD before I publish those. Hopefully even if I can't find a way to get at the internal ROM, I can document enough of the SVP interface so that it can be emulated as a black box anyway. I'll post anything else of interest when I come across it.

 

After some further analysis, I don't believe there is any internal ROM data in the SVP chipset. I've been tearing the ROM to peices, and I can identify the purpose of every block of data in the entire ROM, except large sections from 0x00200-0x1B000. Some data in this section looks suspiciously like code, but not for any machine code format I know.

It appears the entire ROM from 0x0-0x20000 is a canned SVP bootstrapper. There is no code or data in this section which is called at any time during the normal execution of the game. The entry point is at 0x20000 after the end of the bootstrapper, and in fact, the only 68000 code in this block at all is the code and data for the small SVP test menu mentioned in my post above, and it makes perfect sense for this to be in the bootstrapper. Apart from this test menu right at the end of the block, and several sections of significant padding (which would normally be unusual for the start of a ROM), there appears to be mainly code for the SVP, and some large data tables. I'd bet any amount of money this section was built as a self-contained bootstrapper, and all the code which runs on the SVP lies in this region.

I don't have any direct way to confirm this 100% yet, but I'll try and come up with something. There's still some key questions I can't answer confidently yet either, like how the SVP knows what its entry point is in the ROM. I'm guessing it's 0x800, but I don't know how it knows that. I also don't know what position the ROM data is based at in the SVP memory map. I'll keep on digging.

If we do in fact have all the code for the SVP however, which I believe we do, this is a major step forward. Chances are, the SVP isn't completely custom. Its machine code will almost certanly resemble another processor family out there. Perhaps now we can positively identify the type of chipset the SVP is based on, which is the first step in emulating it.

 

Not necessarily. If you believe the speculation about the architecture of the SVP, it has internal IRAM (instruction ram). Think of it as an L2 cache. It could potentially keep most or all of its code buffered in IRAM, and only have to generate external bus queries to the ROM chipset when it needs to access data outside the page of memory which is currently cached. The SVP probably also runs its bus at a higher clock speed, meaning even if there is no IRAM, if the SVP is designed cleverly enough, constant access from the 68000 to ROM might only steal say 1/3 of the maximum access time from SVP to ROM communication from the SVP code, depending on the exact clock speeds and 1000 other factors.

Well, IF it has internal ROM, there's probably no reason to make it accessible externally, aside from perhaps an external ROM integrity test. Internal ROM is much less flexible though, and more expensive in a lot of ways. The only benefit is saving on the development and manufacturing costs if you can do away with an external ROM entirely, but they still needed an external ROM anyhow, so they wouldn't gain anything by doing it.

The only way we've ever going to get it 100% correct is by emulating the SVP code. You could reverse-engineer the interface and simulate the SVP, but it would probably take quite awhile to get it to look just right. You'd have to make a lot of guesses and assumptions. It could be done, and if we can't get at the SVP code this is the next best thing, but if we do in fact already have the code sitting right in front of us, why not try and actually emulate it and do the job properly?

 

Well, fortunately we do have a point of reference. The 68000 code writes particular command words to to SVP to put it into different states. You can see those same command words as constants in the SVP code. There's enough context to figure out compare and branch instructions, and from that you can start to explore the rest of the code. It'd still be a lot of work to build up a reasonable set of instructions, but a guy called Tasco Deluxe has already done the hard work, and managed to figure out a large number of instructions with a fair degree of certanty, and somehow managed to map out the registers too. The documents are called the "SVP Reference Guide" and the "SVP Register Guide", and are linked to by the SVP Wikipedia article.

There isn't enough to emulate the SVP, but I'm hoping to match the machine code format for the SVP to another known processor. Chances are the machine code format isn't unique. If the SVP is a Samsung SSP1601M as is generally believed at this point, then from what I've read, the machine code format is fairly universal for the entire SSP16 family of DSP chipsets from Samsung. If we can find a reference for another chipset in that family, it might be enough to emulate the SVP. From what I can tell though, the manual we really want is called the "SSP16 Family Digital Signal Processor User's Manual", by Samsung.


Anyway, I think I can pretty much confirm that Samsung was indeed the manufacturer of the SVP. I desoldered the SVP chip from a copy of Virtua Racing yesterday. There are several markings on the bottom of the chip I have yet to identify, but what I can identify is the line "Made in Korea". Samsung is of course based in Korea, and is their largest manufacturer of IC's. I don't think there was any other Korean-based manufacturer in the early 90's that produced DSPs.

 

I picked up a japanese copy recently, along with the US version and several copies of the European version. I haven't looked at the Japanese one that much so far, but from what I've seen, there doesn't seem to be a massive difference between them.

Anyway, I've put exploring Virtua Racing on ice for the time being while I ramp up work on Exodus, my Mega Drive emulator. I'm trying to get a fully functional public release out by February. I'll probably have another serious look at Virtua Racing sometime after that release. The next thing I'll probably attempt for Virtua Racing is decapping the chip. I don't know how much useful info that will actually yield, but it should be fun. :D

 

Yeah, I meant to make a post about this. The SVP has indeed been emulated, and we finally have some real, proven documentation. It needs work, and while it emulates Virtua Racing (albeit with a few bugs), it is far from a complete emulator for the SVP itself. While this is secondary to getting Virtua Racing working, there's still a lot of research and testing to do before we can fully emulate all the behaviour of the SVP. Still, that's more academic now than a practical cause worth pursuing.