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.
Honestly, nobody knows. But take into mind some things: if the SVP program was run from the ROM directly, it would slow down as the bus is shared by two hardware at the same time (68k and SVP). So probably it's run somewhere else. But imagine the SVP has an internal ROM. Why should it be accessible from outside? Probably its data bus is just to communicate between the SVP and the rest of the hardware (software really). The program would be internally in the SVP chip and wired internally only, too. It'd be impossible to get it unless you examine it's internal connections, and who's so crazy to try that? You better find a way to get the SVP working first. At least a fake SVP in the case of emulators, as there's only one software for it ever available. Later you'd get deep into the SVP programming...
I know I'm veering somewhat off-topic, but has anyone here actually PLAYED Virtua Racing? Is it any good? Not just graphically ahead of its time and strangely programmed, but is it fun? I've been wondering that for some time. Y'see, normally I'd just emulate it, and pick it up off eBay if I like it (or just burn it to a blank CD in the case of Sega CD games), but I can't really do that here for obvious reasons. =P
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?
If you only care about the gameplay, you can get either the arcade version (and run it in Mame) or the 32X version. They're not much different from the Genesis version, except for the graphics (of course).
I bought the MD cart back in the days and it was very expensive. €115 IIRC. Normal MD carts ranged somewhere between €62.5 - €71 (Of course in the US things were cheaper - you lucky dogs. :P) I would love to see it emulated some day but I'm not holding my breath...
Yep, I picked up that cart soon after it came out (rented it a few times first ). It has been awhile since I played it but we did have fun playing it way back when. IIRC there are only 3 tracks you can race on so it can get old pretty fast if you're not into racing games. If you're the type that loves trying to beat your best lap time over and over again you may like it. Graphics are great considering it is the Genesis. I don't really think the game was worth the money (I recall paying around $120 for it) but these days that isn't such a problem now is it? I really wished they would have used this chip in other games instead of going the 32X route. I can understand why it only made it into one game though, just drove the prices up too much. They should have been less concerned with 3D graphics and more concerned with keeping up with Nintendo in 2D. No doubt in my mind that the latter Genesis games could have looked as good as the later SNES games with some extra horse power in the cart.
Yeah, I know, but what I mean is that unless you know what the SVP is meant to do, it'll be way too hard to understand the code. If you know how should it interact with the rest, at least a small portion, things will be a lot easier. I probably wouldn't have found so much code from Sonic 3D if I didn't know what each RAM address was used for. I got it at the equivalent to 9.33 dollars. Think on it again :P
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
the SVP has now been emulated by Picodrive maybe the documents linked to will be useful in adding SVP emulation to other emulators too. The source code is also available.
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.
True. Even VR still needs work, there is a bug somewhere in ALU/MAC emulation (probably), which causes things to be drawn in a wrong perspective (most visible at the end of second attract mode demo). I tried a lot of things, but haven't found the cause yet.
I once said it may be lack of accuracy. That's the only thing that can come to my mind to cause that bug, perspective projection is way too simple for an emulation bug to cause that: Code (Text): x2d = x3d / z3d; y2d = y3d / z3d; Which further expands so it doesn't stick to -1..1 range: Code (Text): x2d = x3d / z3d * width / 2 + xcenter; y2d = y3d / z3d * height / 2 + ycenter; That in Virtua Racing becomes: Code (Text): x2d = x3d / z3d * 128 + 128; y2d = y3d / z3d * 112 + 112; If it was an emulation bug, then a lot of things should stop working. It could be implemented as a matrix too, but the case is the same as the same kind of operations are used. Moreover, since the game knows the limits of the projection, it in fact becomes even simpler as only multiplications are used, no divisions. The only thing I can think of is lack of accuracy. Remember that the SVP is likely not vanilla SP1601. Probably it's a custom processor based on that one, adding some features and removing others. Maybe there's some unknown register that has the missing accuracy. We don't know :/