Virtua Racing

Ask anything your want about Megadrive/Genesis programming.

Moderator: BigEvilCorporation

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Sat Feb 09, 2008 7:30 am

Eke wrote:
In the emulator, VR runs FAST... I forget how fast the actual cart was on a real Genesis. I normally use the 32X cart... I'll have to dig through my boxes looking for the Genesis cart to check how it compares to the emulation.
I'm interested if you could capture video of the real cart running on Genesis

Indeed, I implemented the SVP core in my emulator but the Gamecube CPU lacks some power to run everything at full speed (average 45 fps with some downfalls to 25 fps :roll: )...
If I want full framerate, I have to underclock the SVP but then the "3D" rendering is slower (according to Notaz, correct value is approximately 1000 cycles per line, but it's is maybe overclocked a little bit)

Having the real thing to compare and adjust cycles value would be nice
:wink:

or maybe it's time for me to learn PowerPC ASM :)
Um... that would be difficult. I don't have a video camera, and the only video capture card I have is what's built into my old Mac Performa - but it doesn't have a burner or ethernet. I'd have to pull the harddrive, and that is a HUGE pain in the butt on that computer. I didn't get video input on my last video card as I've never used it. Then there's the issue that I'm using a custom RGB cable - I haven't the vaguest idea where the composite cable is. I suspect there's probably video on YouTube of the Genesis VR. I'd check that first.

As to PPC, that's a nice CPU for doing assembly in. My brother and I did a PC emulation in 99% assembly on the PPC Mac. If I remember correctly, the GC has a co-processor that works on the ARAM meant for audio processing, but I imagine it could be used for other things. The most I've seen it used for is resampling and adding channels of audio, but the instruction set seems fairly generic.

Eke
Very interested
Posts: 884
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

Post by Eke » Sat Feb 09, 2008 8:07 am

I understand ;)
Youtube has indeed some videos, the gameplay and 3D rendering is really smooth
As to PPC, that's a nice CPU for doing assembly in. My brother and I did a PC emulation in 99% assembly on the PPC Mac.
Impressive 8)
Even if I have no problem understanding assembly, I am far from being a real ASM programmer myself... is the code really faster as soon as you wrote it in ASM or are todays compilers already good enough at optimizing code so that there is no point in using ASM unless you know how to write crazy optimized algorithms yourself ?


If I remember correctly, the GC has a co-processor that works on the ARAM meant for audio processing, but I imagine it could be used for other things. The most I've seen it used for is resampling and adding channels of audio, but the instruction set seems fairly generic.
Yes, I also thought about the DSP, it has been reverse-engineered and the instruction set is described.
Actually, we only use it to DMA our soundbuffer into Audio Interface and I still need to learn how to run code on it.

evildragon
Very interested
Posts: 326
Joined: Mon Mar 12, 2007 1:53 am
Contact:

Post by evildragon » Sat Feb 09, 2008 4:27 pm

Oh, some good PPC emulators will be great :P i could actually have a chance to breathe 32X and CD emulation..

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Sat Feb 09, 2008 8:58 pm

Eke wrote:I understand ;)
Youtube has indeed some videos, the gameplay and 3D rendering is really smooth
If you find a good video there, please post a link. :)
As to PPC, that's a nice CPU for doing assembly in. My brother and I did a PC emulation in 99% assembly on the PPC Mac.
Impressive 8)
Even if I have no problem understanding assembly, I am far from being a real ASM programmer myself... is the code really faster as soon as you wrote it in ASM or are todays compilers already good enough at optimizing code so that there is no point in using ASM unless you know how to write crazy optimized algorithms yourself ?
The MOST important part of assembly programming is the part compilers still cannot do - global optimization of register usage. Compilers cannot tell when it is best to keep a value in a register, and when it needs to leave it in memory. Oh, it can do that LOCALLY, but not globally. Having a good set of global register allocations can make an emulator two to four times as fast as the best C code. The assembly doesn't even have to be good - lousy assembly code with great globals outperforms the best C code hands down. That's where the x86 fails the worst - lack of registers for storing globals. The best things AMD ever did for the x86 family was double the registers for 64 bit mode. Most of the speedup for 64 bit code comes not from being able to use 64 bits, but from having twice as many registers.
If I remember correctly, the GC has a co-processor that works on the ARAM meant for audio processing, but I imagine it could be used for other things. The most I've seen it used for is resampling and adding channels of audio, but the instruction set seems fairly generic.
Yes, I also thought about the DSP, it has been reverse-engineered and the instruction set is described.
Actually, we only use it to DMA our soundbuffer into Audio Interface and I still need to learn how to run code on it.
Yes, it's a wee bit complicated to use at the moment, but folks will eventually make more use of it than just mixing audio.

Post Reply