SVN repository for Virtual Jaguar

[Shamus]

Well then. In that case, maybe you can try running with the -l switch to look at the generated logfile to get some clues as to what's going wrong with the games that don't work.

Also, how are you running the games? With/without BIOS/GPU/DSP? Also, what version are your system libs? And what is the model of your gamepad, and what are your system specs?

[zombie_ryushu]

The distribution I use is called Rosa 2012 LTS. (A Mandriva Fork). My Game pad is a Street Fighter 4 PS3 Fight pad. Under 2.1.0, it only works in 'DP' mode, but under the GIT Version, LS mode works too.

The only game I have that works is RayMan. I also have Raiden, Attack of the Mutant Penguins, and Doom. They cause the emulator to become unresponsive. All I can do is exit out. DSP mode and Bios mode is turned on. Under 2.1.0, this setup runs RayMan full speed. Under the 'Master' GIT RayMan runs at 75% Speed.

To build the application, I git clone the 'master' branch, and then,tar it up as a virtualjaguar-2.1.1git.tar.bz2. Then I run rpm -ba over it, and it builds in exactly the same way I built 2.1.0. Producing virtualjaguar-2.1.1-1rosa.x86_64.rpm. If you want I can send you a copy of this RPM.
The Motherboard of the system is an Nvidia Pico ITX ION3 from ASUS often referred to as an ION3 Deluxe. It has 2 GB RAM.The Video chipset is an Nvidia 6200 running Driver revision 295.40. (so there is no reason for this not to run full speed, despite having somewhat underpowered hardware.)

[Shamus]

What CPU do you have in that system?

[zombie_ryushu]

Atom 330.

[Shamus]

Well, that's a 1.6 GHz dual core 64-bit CPU, so it should be OK. I'm pretty sure that the Rayman slowdown is due to an adjustment I made to the DSP.

I'm also making adjustments to the core which has introduced some instabilities in booting. Ah, the joys of testing unstable software!

[zombie_ryushu]

Let me know when you have some new code for me to test.

I also took a look at RetroArch. It will make a great addition to the WahCade Project. RetroArch is taking over SNES and Sega CD emulation.

For Virtual Jaguar, I'm going to stick with Shamus's Upstream code for as long as VJ is "Friendly" as far as WahCade integration is concerned. I have no dispute with Shamus as to how is is coding VJ.

[NGboo]

Has anyone managed to download the latest build (20130503)?
I'm constantly getting unfinished file (corrupted archive). :/

edit: Never mind, I finally downloaded it.

---

Last edited by NGboo; May 4th, 2013 at 17:27..

[zombie_ryushu]

Do you have any plans for a future VJ release?

[hcf]

Congratulations for the 2.1.0 release, it's a very good work, thank you very much!!!

By the way, just one curiosity: the changelog says "Preliminary fixes for proper emulation of memory reads between $200000 and $800000."... Do you know any game that takes advantage of this fix? (I mean, is there any game that crashed or didn't work properly in previous versions, and has been fixed with this solution?)

Please, keep going with this awesome emulator!

[Shamus]

@zombie: Of course there will be. Haven't had much free time as of late to work on it though. The next release will come once I've straightened out a few things with the controller config. That's pretty much all that's holding things up right now.

@hcf: It's more of a curiosity than anything. There were some test programs that failed on VJ that worked on real hardware, and I was able to fix that. Nothing released that I know of tries to read past the Jaguar's RAM.

[Robert R]

Hopefully the next release will compile properly for the Mac as well. I take it Goldenegg still has not been able to get version 2.1.0 to run on the Mac?

[hcf]

Originally Posted by Shamus

@hcf: It's more of a curiosity than anything. There were some test programs that failed on VJ that worked on real hardware, and I was able to fix that. Nothing released that I know of tries to read past the Jaguar's RAM.

Thank you very much for the answer! It's amazing how you are targeting to achieve so accurate emulation, even trying to replicate what the real hardware does in so strange cases!

By the way, I would like to ask you another thing. I saw that in the gpu.cpp file, in the SUBC routine, you replaced this:
SET_ZNC_SUB(RN - borrow, RM, res);

with this:
SET_ZNC_SUB(RN, RM + borrow, res);

(to avoid a problem with the carrier). But, don't you think that this fix may be done too in the dsp.cpp (also in the SUBC routine)? It still has the old SET_ZNC_SUB(RN - borrow, RM, res);

Please, excuse me if this is not the correct place to talk about this kind of things. I don't know what the best place is...
Congratulations again by this awesome work!