Dreamcast Emulator...Update

[jaycee900]

I couldn't find the old topic or no posts with this new information and since it's one of the major new emulators thought I'd better share the new info on this forum (of course cause its better than GP32X! (sorry if already posted somewhere else though)

Basically the PSP version is getting speed improvements of 6-7x of the previous build, which in some games is 9fps, while they say the beagleboard/pandora port will be 3+x the PSP speed (27fps+) amazing news, check the Shenmue video on the PSP, even that is a massive improvement on the previous 1-2fps!

Great work lads, I for one cannot wait for this, keep chipping away and getting speed improvements, I'll defo donate after the first build for Pandora!

http://www.emudev.org/drkIIRaziel/blog/

 

[Trevsweb]

looks hopeful for the pandora. lets hope he makes some good advances this year.
never really played the Dreamcast when it was out. but ive heard its a great homebrew console now.

 

[craigix]

I mentioned this to TI yesterday, they seemed pretty amazed it was possible.

 

[senorgomez]

That is amazing! I am pretty pumped... I had so many happy times playing soul caliber on the dreamcast.

This might be the flagship emulator for the Pandora, I think.

I hope they got Pandora dev boards so it will work when the Panda starts roaring. I think the beagle board they are using is under-powered compared with the Pandora? Hope that doesn't slow development.

 

[GuSec]

This is amazing!
To repeat, Prince of Persia got 1.2FPS on PSP with last build, it now get around 9FPS. Along with that ZeZu thinks he will be able to get the Pandoraversion running 3x faster, which with optimisations should give PoP a speed of about 27FPS!
Incredible amazing, I'm very eager to hear some news on development of the ARM build. Anyone who remember what was said last year about Dreamcast emulation on Pandora?

 

[Pleng]

Daytona

on the bus?

 

[JayFoxRox]

GuSec: Remember that this is a DynaRec improvment and you can't compare PSP to Pandora anymore at all.
The PSP has 32 general purpose registers which can hold data (Not all can be used - but thats the same for the Pandora), the Pandora only has 16 - this limits it probably. The Dreamcast and its SuperH4 should also have 16 general purpose registers, but you probably need some of the registers to keep dynarec data on the Pandora and as mentioned before, some are needed for the kernel or something else so you can't map them directly.
One advantage the ARM has is that it can "group" instructions which are multiple instructions on the PSP or the Dreamcast. But I still think that the PSP DynaRec is more usefull than the Pandora one so you can't claim it to be 3x faster anymore.
It might work to take advantage of the DSP though: I m thinking about putting my Pandora-PSP DynaRec and games scripting engine on the DSP right now - even if it wasn't made for that it should still be enough to provide real-time data.

//Edit: Small changes

 

[senorgomez]

JayRox:

Right now there are two different development tracks. One is to get the nullDC working on PSP and the other is to get it working on the beagleboard. The Beagleboard fork is being developed by "ZeZu" and is showing tremendous promise as per the last two videos on that blog:

http://www.youtube.com/watch?v=1wIYfutx1ZI

http://www.youtube.com/watch?v=7o4y9k0s_Xc

Most of the info on the blog is about porting DC emu to the PSP, but there is some promising stuff coming for the beagleboard which can be transposed to the Pandora very easily.

I don't have a lot of technical knowledge but I think this clarifies some things.

 

[JayFoxRox]

And I have worked on a small DC emulator myself (for a Demo project) and worked with the PSP (including an Emulator) and the beagleboard and I think I have atleast some knowledge about the technical stuff (not as much as Exophase but still..)

The videos are back from march where the DynaRec was not beeing used. I know them.
All I was saying is that these optimizations will help the PSP more than the beagleboard / Pandora / ARM version therefore GuSecs "quote" about the ARM version beeing 3 times faster than the PSP version is not valid anymore - the PSP version has probably more improved than the Pandora version (or the ARM compiler sucks ).

//Edit: My name is JayFoxRox, but you can call me Fox

 

[senorgomez]

Ahhh I see. Thanks for giving me that technical info.

I thought there was a misunderstanding that there was only one nulldc port. I didn't know about DynaRec and how its benefits aren't applicable to the pandora.

thanks for you patience.

 

[hlidegp2x]

GuSec: Remember that this is a DynaRec improvment and you can't compare PSP to Pandora anymore at all.
The PSP has 32 general purpose registers which can hold data (Not all can be used - but thats the same for the Pandora), the Pandora only has 16 - this limits it probably. The Dreamcast and its SuperH4 should also have 16 general purpose registers, but you probably need some of the registers to keep dynarec data on the Pandora and as mentioned before, some are needed for the kernel or something else so you can't map them directly.

huh, even if PSP has more registers, nullDCe cannot use a 1:1 register mapping for all the existing SH4 registers - so at the end you'll need a save/restore MIPS registers mechanism for some SH4 registers anyway. Besides, Pandora has a more powerful cache, and some hardware improvements like a cache return stack, branch predictions that PSP has not (that is you don't need to code like a pig to optimize !). I'm more confident about nullDCe running faster on Pandora than PSP.

 

[JayFoxRox]

hlide: Ofcourse you can't map 1:1 (atleast its very unlikely). But 32 registers on the PSP should make a huge difference to 16 on the ARM I think. Just think about Zod post about the iPhone problems because one register can't be used, which is available on the GP32X.
You are right though: I forgot about the cache and branch prediction. But don't forget that these already existed without the dynarec - though, probably not worked as efficient as they do with the dynarec.
I still think that the Pandora version is faster than the PSP version - no question, but this DynaRec upgrade had a stronger impact on the PSP version probably (compared to the Pandora version) - its only a wild guess though. Only way to find it out would be testing it I think

PS: I'm still cleaning parts of the Pandora-PSP source so I can give it to you - read your message some weeks ago, sorry for not replying. I had other things to care about.

 

[ldesnogu]

hlide: Ofcourse you can't map 1:1 (atleast its very unlikely). But 32 registers on the PSP should make a huge difference to 16 on the ARM I think.

That would be true only if you don't have a proper register allocator and try to place emulated registers in specific host registers. You don't have to do that and in fact I think you should only use that for very few registers (such as SP) or your simulated code will have poor performance.

Of course more registers is always better, but that shouldn't make a "huge difference".

And BTW, MIPS only has 31 registers (+ hardwired 0) while ARM has 15 (+ PC)

 

[hlidegp2x]

hlide: Ofcourse you can't map 1:1 (atleast its very unlikely). But 32 registers on the PSP should make a huge difference to 16 on the ARM I think.

That would be true only if you don't have a proper register allocator and try to place emulated registers in specific host registers. You don't have to do that and in fact I think you should only use that for very few registers (such as SP) or your simulated code will have poor performance.

Of course more registers is always better, but that shouldn't make a "huge difference".

And BTW, MIPS only has 31 registers (+ hardwired 0) while ARM has 15 (+ PC)

to be exact PSP has : 31 GPR + 32 FPR + 128 scalar VFPU registers (which can be also seen as 32/64 vectors or 8/32 matrixes registers in 2D/3D or 4D)

long before Sony released its psx emulator (POPS) i wanted to use VFPU registers to store PSX registers, but transfering a scalar VFPU register to a GPR costs 6 cycles and it is not pipelined (a situation somewhat similar between arm and neon registers I heard) so it definitely not a good idea to use VFPU for anything else SH4 FPU registers. So there is no great solution apart from using MIPS GPR or load/store to handle SH4 registers which are not FPU. But it is true we can have at least a perfect 1:1 register mapping for FPU.

 

[jaycee900]

Quote from Zezu on GP32X;

Things have been slow on my end, having some trouble with work (or lack of).
The emulator is a long term project, and is definitely still very much alive.
I just shipped my beagleboard out to drk||Raziel, so that ought to speed things nicely

Hopefully he can do his magic and get it upto some decent speeds, maybe not playable just yet but these things take time, maybe other 'methods' - see non techie talking! and more docs from TI will allow greater increases.....

 

[hlidegp2x]

PS: I'm still cleaning parts of the Pandora-PSP source so I can give it to you - read your message some weeks ago, sorry for not replying. I had other things to care about.

Any progress ?

 

[Exophase]

Wait, why can't you perform a 1:1 mapping for PSP registers to SH4 registers? I do this fine with ARM emulation and I'm storing a different register for C, Z, N, and V flags too. SH4 doesn't have all those flags.

 

[drkIIRaziel]

Only if i could get gles libs working ...

The arm builds have been more than 3x faster than psp before.The code is much different now supporting many opcodes for the dynarec and many other optimisations (like idle loop detection).The psp is much weaker and there is no reg alloc done (yet).

Anyway, unless i can get this %Q!$%!#%$ source to build and run i'l be back to working on arm

Exophase:
16 GPRs + 1 status reg (sr.T) + a cycle reg + a context reg (so that we can load other regs on a single opcode) = too many. IIRC there were only 13 or 14 registers saved across calls so it doesn't seem possible to fit em all. And any memory opcode can call a function ...And register allocation is still far away ;p

 

[hlidegp2x]

Exophase:
16 GPRs + 1 status reg (sr.T) + a cycle reg + a context reg (so that we can load other regs on a single opcode) = too many. IIRC there were only 13 or 14 registers saved across calls so it doesn't seem possible to fit em all. And any memory opcode can call a function ...And register allocation is still far away ;p

true save-callee registers are $s0 ... $s7, $s8($fp) and that's all, that is 9 registers. There are other registers which can be save-callee registers but only under some condition ($ra is one).

Sure we could use $t4 ... $t9 to map the other SH4 registers, but we won't be able call a C function from the dynarec code without saving/restoring them across call. Oh well, we can also have $t0 ... $t3 if we don't plan to call a C function with more than 4 integer-like arguments.

If C functions don't call external functions (outside your source), you can clobber $t0-$t9 in your C function (using __asm__ __volatile__ (':::"t0", ..., "t9"); at the beginning of each C function) so you may be sure those functions won't use them in your C source, but that's very hard to maintain.

Right now, basic blocks are very small so a 1:1 mapping is probably not making things better.

Indeed, the equation is not as simple as expected :/.

 

[Exophase]

true save-callee registers are $s0 ... $s7, $s8($fp) and that's all, that is 9 registers. There are other registers which can be save-callee registers but only under some condition ($ra is one).

Sure we could use $t4 ... $t9 to map the other SH4 registers, but we won't be able call a C function from the dynarec code without saving/restoring them across call. Oh well, we can also have $t0 ... $t3 if we don't plan to call a C function with more than 4 integer-like arguments.

All of this is nullDC's problem and not MIPS. It's because you're relying too much on C functions. Anything that the recompiler calls with any frequency should be ASM where you control the convention and keep register usage to a minimum.. and of course isn't poorly generated GCC code. For the times when you do call C code you save/restore what you need to. Works well for gpSP and I'm sure it would work well for you too.

Right now, basic blocks are very small so a 1:1 mapping is probably not making things better.

Eh? That sounds completely backwards. The smaller basic blocks are, the more overhead there will be in loading/storing registers and the shorter the dynamic allocation will last, at least for a local only allocation scheme. Of course global allocation is a huge pain in the ass that no one really wants to do. Static allocation, on the other hand, removes all of that overhead entirely and if it's 1:1 then it's perfect to do so.

Come on guys, get your hands dirty ;P But not too dirty. Any work on doing dynamic register allocation would be a step in a very wrong/unnecessary direction that will only hurt performance if you don't do it globally.