Release Yabause


ari64

Magic Emulator Fairy
Joined
Aug 26, 2009
Messages
560
Now that I have a Pandora, I made a PND of Yabause (Saturn emulator). As expected, it is rather slow. Some games are playable if you overclock and don't mind using frameskip.


PND is here: http://hotfile.com/dl/124843269/071b2b7/yabause-r2657.pnd.html


Source code is here: http://yabause.svn.sf.net/viewvc/yabause/branches/yabause-dynarec/


Under the Yabause menu, select Preferences. Under bios, select your bios file. Under cdrom, select ISO or CUE file, then the filename of game you want to play. You can optionally select a directory for save states, if you want to use this feature. Save states are a bit buggy.


Under Video, select "Software video interface" and "Enable frame skipping/limiting". I recommend window mode, as fullscreen is rather slow.


Under Sound, select "SDL Sound Interface".


Under Cart/Memory, you must enter a filename under 'Memory' if you want normal saves to work without using savestates.


Under Input, set up your keyboard/buttons however you want.


Under Advanced, for SH2 Interpreter select dynamic recompiler. You can select the audio sync option if you want, depending on which setting you find least annoying.


There is a second executable in the PND, called "yabause-underclocked". This emulates the SH2 CPU at 14MHz instead of 28MHz. This will cause some games to run slow or out of sync, but may reduce the frameskip.
 
Yes!, Yes! Shining Force III on my future pandy!


I can't wait until my number comes up in batch2...


Now for a port of Satourne...(I can dream, can't I?) :lol:
 
Last edited by a moderator:
Now for a port of Satourne...(I can dream, can't I?)
I feel like a broken robot : no sources, no port, no exception.
That's what I meant when I said that I could dream. Some closed source programs/ games eventually go open source, take for example blender, doom and quake and slightly more recent: Dink Smallwood.


try


find(source);


port(source);


link(compile(source));


except


writeln("Source not found");
 
Last edited by a moderator:
Now that I have a Pandora, I made a PND of Yabause (Saturn emulator). As expected, it is rather slow. Some games are playable if you overclock and don't mind using frameskip.
Nice! I can see some familiar code there, maybe you can make it translate ia32 code too? B)


So it translates master and slave code to separate caches, right? For how many cycles it usually runs before switching cores?
 
Damn, now there'll be another Ari64 recompiler I'll have to study. Are you going to writeup this one on the Wiki too? :eek:


I suspect that for Saturn emulation to reach decent speeds it's the VDP1/VDP2 stuff that'll need to get much faster.
 
Now that I have a Pandora, I made a PND of Yabause (Saturn emulator). As expected, it is rather slow. Some games are playable if you overclock and don't mind using frameskip.
Nice! I can see some familiar code there, maybe you can make it translate ia32 code too? B)


So it translates master and slave code to separate caches, right? For how many cycles it usually runs before switching cores?
The register allocation and delay slot handling is largely the same. I made some changes to the constant propagation to handle the PC-relative loads, and there's a hack in the liveness analysis to handle the T bit separately.


Code on the master and slave sh2s is compiled separately. It would be theoretically possible to re-use the generated code, but you'd have to change some pointers and add something so that interrupts get dispatched to the right places.


It switches cores 10 times per scanline, which is roughly every 170 cycles (varies slightly depending on PAL or NTSC). I tried changing it to once per scanline (as in the PSP version of Yabause) but a lot of games didn't work, so I put it back to 10x per scanline.
 
Last edited by a moderator:
Ari64, you are a GOD among men!


Thankyou so much for making the greatest ever console available to us :)


And a HUGE thankyou for anyone who feels inspired to continue this project!


Now to get on with the testing :)
 
I didn't think it was, and you've probably seen where I've mentioned before that I think that SH2 recompilation to ARM may benefit more from a lot of the allocation registers being statically selected instead of dynamically if it doesn't cross blocks. At least I convinced notaz to do that.. would be interesting to see which works out as better I guess.


And from what I recall from drk||Raziel, SH code relies on a lot of constants loaded from PC-relative areas, particularly branch targets. And that it helps recompilation a lot if you can assume these are constants at compile-time, but then have to have some way of determining if they're modified (drk used MMU-assisted write protection w/OS signals for this).. are you currently doing anything like this?


That and I guess the memory stuff would be pretty different from N64 and PS1 since the memory is no longer at 0x80000000.. I guess my question is if a majority of accesses still tend to go to only one of the RAM regions, since I'm sure that determines what solution you've used.
 
The very first sentence of the very first post contains the highest concentration of good news I've sen here in quite a while :D Woot, woot, etc.
 
Back
Top