SVN repository for Virtual Jaguar

[Shamus]

It's been done already, and it's call MESS. Which project has better compatibility is left as an exercise for the reader.

[akaTONE]

Howdy, I originally got interested in this project to be able to play AvP again. Unfortunately, the DSP emulation was a bit of an issue since it was choppy as could be. I worked on simplifying and speeding up the DSP emulator itself but the real problem was the model of emulating the entire system was incompatible with the AvP usage. The DSP will generate the audio and fill up the output buffers once an interrupt signal is sent to it. The problem is that the interrupt comes from a timer set by the CPU and the signals get out of sync due to each processor moving in large chunks of time and causing massive skew in when the signals are sent/received relative to each other. The DSP emulator will spin its wheels for thousands of cycles checking for whether the interrupt mode was been triggered and use up its time slice of emulation. This causes the DSP emulation to not update the audio out buffers and we get the skipping sound from the output. Anyway, the question I have is, how does the multi-threaded model help this? I'm wanting to get back to this project and actually submit the DSP changes I have. Is the number of cycles emulated per time slice still hard coded globally or can it be changed per game? This could reduce the skew enough to get AvP sound running acceptably. I'll start looking over the latest code in Git to see where things are now.

[Shamus]

Try the latest GIT build from here and see how it goes. Currently the latest is 20120717.

To answer your question, mutli-threaded execution helps in mostly with modern multicore machines--without it, it saturates a single core and doesn't run as well as it could. As a simple way to optimize things, it's a big win there. Not so much on single core machines. And yes, depending on whether the emulated Jaguar is in NTSC mode vs. PAL mode, the DSP gets a fixed amount of time just like on a real machine.

Also, all games pretty much drive the DSP the same way that you described; the solution isn't game specific patches but fixing the emulation so that the delay involved is minimized.

Just to be clear about patches: When we inherited the codebase from Mr. Raingeard, it was full of game specific hacks and we removed ALL of them. They will not reappear in any form.

That said, the DSP emulation needs some correction as it's still not 100% correct. Anything that pushes the DSP in that direction will be gratefully welcomed.

---

Last edited by Shamus; July 24th, 2012 at 14:35..

[zombie_ryushu]

If you try and load a cartridge the emulator will crash. (with a Segfault.)

Doom causes 100% CPU use and looping illegal operation gliches.
Attack of the mutant Penguins results in black screen.

[DarkFalzX]

Getting serious performance issues:
Intel Core 2 Quad Q6600 2.4GHz
8GB RAM
NVIDIA GeForce 9600GT
running W7 64-bit

Only the simplest (68k-only?) 2D games appear to run at full speed. The rest lag badly, and experience badly fractured sound.

Here are some games I tried:

Towers II - Works, but isn't playable due to screen flickering on and off. Slow.
Zero 5 - Fully playable. No problems discovered.
Doom - works fine, but the image isn't stretched full screen.
Fight For Life - the menus are excruciatingly slow, causing what appears to be 100% CPU load. If you can get past them - the game is actually sort of playable... well - as playable as Fight for Life ever was anyway.
Iron Soldier 2 - Music sounds glitched up. The game gets as far as the main menu, then after about a second the screen goes dark whether you do anything or not.
Total Carnage - Works fine. No noticeable glitches.
Soccer Kid - Works great. No noticeable glitches. Extremely fast.
Sky Hammer - Graphical glitches. Isn't playable as there seems to be some kind of a collision glitch at the very beginning of the game, so you can't move, though the game appears to keep running.
Battle Sphere Gold - In all modes - black screen once you get to the actual gameplay.
Phaser Zero - Screen flicker in-game, and graphical glitches on far objects.

[Shamus]

Thanks for the report!

[NGboo]

Ultra Vortek is still not working - goes black after copyright screen.

[Predatux]

Hi, Shamus. I'm trying compile in Ubuntu 12.04 32 bits, but i have this error:


/usr/bin/ld: skipping incompatible obj/libjaguarcore.a when searching for -ljaguarcore
/usr/bin/ld: cannot find -ljaguarcore
/usr/bin/ld: skipping incompatible obj/libm68k.a when searching for -lm68k
/usr/bin/ld: cannot find -lm68k
collect2: ld devolvió el estado de salida 1
make[1]: *** [virtualjaguar] Error 1
make[1]: se sale del directorio «/media/Terabito/Git's/virtualjaguar»
make: *** [virtualjaguar] Error 2


I think all dependencies are installed... can you help, please?

[Shamus]

Did you do a "make clean" before running "make"? It sounds like there are some stale objects that it's trying to link against from a previous compile attempt.

[akaTONE]

Evening again. What I was trying to say was that no matter how fast you make the DSP emulator itself, the current way in which the entire system is emulated is what is causing stutter in many games. Rather than emulating in chunks of a horizontal scanlines of the blitter which was around 1700 dsp cycles and 850 for the 68000, the emulator needs to do much finer granularity timeslices. For AvP, the 68K is the one that sets the timer for the DSP to un-stall and fill out another chunk of the sound buffer. If the CPU fires an interrupt to the DSP, that won't be picked up for 1700 emulated cycles because the timer based "timeslice" determination will not take into account the CPU setting the timer at emulated cycle 1 of its timeslice of 850 cycles until the next iteration of the loop. Multithreading will not make this any better. It could hurt perf by having to synchronize threads far too often for any tangible benefit to be seen. For accuracy, a single bus cycle should be emulated for every processor before progressing. However, that's probably overkill for many games. But, that should be the granularity mechanism, a much smaller fixed amount not based on scan out rates, but on the bus cycles.

Since it appears that the code for TOM is based on performing an entire scanline at a time, what if the 68K, DSP, gpu were added to the event list with the callback set for 32 bus cycles? That would reduce the skew to a much smaller and much less likely to spin its wheels amount since a timer could only be missed for 32 * whatever the bus multiplier is for the DSP cycles.

[Shamus]

Have you tried the latest multithreaded version on a multicore machine? The audio in AvP doesn't stutter at all.

If you're experiencing stuttering, then it's because you're using the single threaded version of VJ and it definitely happens as a direct result of the speed of the emulation. On most modern computers (multicore or not), the single threaded version of VJ is going to saturate a single core; unless that single core is in the neighborhood of 3.5+ GHz, it's going to have stuttering sound because the emulation is going to fall behind the host audio IRQ and thus the host audio's sound card buffers will be starved.

Multithread in this case is a huge win in this case because on a multicore machine the DSP will usually get its own core and the rest of the emulator will get its own. Separating out the rest will only help things in this regard. Synchronization could be problematic until you realize that this is how a real Jaguar works. Any synchronization issues would have to be dealt with by the software running on the Jaguar anyway. The biggest problem that VJ doesn't address at all right now is bus contention, and that will probably necessitate finer grained execution.

I know of no games where the DSP is driven by the 68K--the 68K might trigger samples or set a MOD going, but once that sample is triggered or the MOD is started it is the DSP that does all the work from then on, and it doesn't matter what the other processors do or what the execution timeslice is. The DSP sits in an idle loop a lot of the time because the DSP is waiting for the next IRQ, not because it's waiting for a signal from the 68K to do more work.

That said, anything can drive the audio in a real Jaguar; even the 68K can do it, though it would make no sense to do so when there is a RISC processor dedicated to that purpose (the DSP).

[akaTONE]

I haven't tried the latest multithreaded with AvP yet. I've been bogged down with work and have been less than enthusiastic about spending any more time on the computer afterwards.

Anyways, I may be recalling this incorrectly, but I thought that the 68K was setting the timer to send an interrupt to the DSP. Even after optimizing and reversing the pipeline flow logic to reduce the number of NOPs/stalls being inserted, it was still spinning in the small 4 instruction loop to determine if the DSP had entered interrupt mode. This may also have been before the timer/callback based system so there may be some change for this that I'm missing which plays into this logic that removes the delay. Hopefully soon I will get around to setting up my dev machine again for vj and give it a shot.

Cheers

[Predatux]

Originally Posted by Shamus

Did you do a "make clean" before running "make"? It sounds like there are some stale objects that it's trying to link against from a previous compile attempt.

Solved

Thanks a lot.

One thing, the emulator has audio?

Regards

[Shamus]

Short answer is yes: if you go into Help | Contents... while VJ is running you should find all your questions answered in there. Unfortunately it's only in English at the moment...

[zombie_ryushu]

Any news on a VJ release? It's 2013,

[Shamus]

Yes, it should be coming soon as the major stuff (full screen, gamepad input) has been written. Still a few minor things to fix though. I'm hoping in the next few weeks.

[zombie_ryushu]

Make sure it is well understood, this emulator will be running on some low power devices, such as an ASUS Ion 3, which while having x86_64 support, is very underpowered. I'm hoping that VJ does not require an obscene amount of GPU and CPU power to run at full speed, and can manage 2 GB of RAM well. Addditionally, I hope that as many different functions of the emulator are Game Pad Assignable, (Exit with home button, for example.

[Shamus]

OK everyone, latest release for win32 is on http://outrage.the-crow.co.uk/builds/ (the one with the latest date on it). Please test and report any problems you find here. Thanks!

Known regressions: Cybermorph, Doom, Flip Out!, Wolfenstein 3D. We know about these, and they don't need to be reported here.

[TheUMan]

Any chance to get a Mac OS X build ?

I want to test this :-)

[Shamus]

Well, according to goldenegg, there seems to be some problem with native Mac port, and I haven't been able to help him pinpoint it. In short, it works, but worse than the win32 port running through Parallels on the same machine.