Welcome to Emulationworld

Forum Index | FAQ | New User | Login | Search

Make a New PostPrevious ThreadView All ThreadsNext Thread*Show in Threaded Mode


SubjectSpeeding up emulation new Reply to this message
Posted bySnowball 2
Posted on11/26/07 08:52 PM



Homebrew emulation for the PSP is a thriving scene but the problem with most systems more complex than an NES is that the emulation is slow. Normally it's a direct port from a Linux/Windows open source project to the PSP. Difference being how they're built.

There is definitely some horsepower under the hood of the PSP. Sony has written a near perfect emulator of the PS1 that runs at full speed. I'm trying to imagine that the SNES should be able to attain full speed as well.

There may be a couple logical fallacies there as the PS1 is not a SNES and the PSP's hardware may be better suited to handle the PS1's architecture. Maybe it's just a simulator that does a damn good job of recreating the original PS1 hardware functionality. Who knows (outside of Sony?)

Regardless I want to make a faster SNES emulator. I have thought of a number of solutions but I have no idea how feasible or realistic they are. Basically it would be best to start with an open source project and modify components of it to perform better on the native PSP hardware. Forgive my ignorance on the topic but indulge me if you would.

The thoughts in order of no import:

1. Dynarec, baby. How hard would it be to take something like ZSNES and put a dynarec at its core?

2. Inject assembly in key areas. Find areas of commonly executed code and speed them up with assembly.

3. Ummm, there is no 3.

Any takers?

pixel-eight.com



SubjectRe: Speeding up emulation new Reply to this message
Posted byBart T.
Posted on11/26/07 11:05 PM



I think the overhead of code generation and memory management (the basic block hash table) might outweigh the key dynarec benefit of eliminating the fetch/decode loop, especially with a CPU like the SNES's. You'll also have to keep strict account of timing, which is possible in a dynarec, but could get messy depending on whether or not you can simply do the timing on a per-basic block basis.

I would say you ought to profile first. Premature optimization is often a complete waste of time. You need to know what to optimize first. It may be that the CPU isn't the bottleneck. I'm sure that the solution will ultimately require a healthy dose of assembly language in all major components of the emulator (CPU, graphics, sound, etc.) The SNES CPU is fairly simple and given the MIPS' large register file, you should be able to write a pretty nice CPU core.

Fetch/decode might be a bit messy, as will flags, but you can probably store everything in the registers and minimize memory overhead.


> Homebrew emulation for the PSP is a thriving scene but the problem with most
> systems more complex than an NES is that the emulation is slow. Normally it's a
> direct port from a Linux/Windows open source project to the PSP. Difference
> being how they're built.
>
> There is definitely some horsepower under the hood of the PSP. Sony has written
> a near perfect emulator of the PS1 that runs at full speed. I'm trying to
> imagine that the SNES should be able to attain full speed as well.
>
> There may be a couple logical fallacies there as the PS1 is not a SNES and the
> PSP's hardware may be better suited to handle the PS1's architecture. Maybe
> it's just a simulator that does a damn good job of recreating the original PS1
> hardware functionality. Who knows (outside of Sony?)
>
> Regardless I want to make a faster SNES emulator. I have thought of a number of
> solutions but I have no idea how feasible or realistic they are. Basically it
> would be best to start with an open source project and modify components of it
> to perform better on the native PSP hardware. Forgive my ignorance on the topic
> but indulge me if you would.
>
> The thoughts in order of no import:
>
> 1. Dynarec, baby. How hard would it be to take something like ZSNES and put a
> dynarec at its core?
>
> 2. Inject assembly in key areas. Find areas of commonly executed code and
> speed them up with assembly.
>
> 3. Ummm, there is no 3.
>
> Any takers?
>
> pixel-eight.com
>



SubjectRe: Speeding up emulation new Reply to this message
Posted bySnowball 2
Posted on11/27/07 08:45 PM



> I think the overhead of code generation and memory management (the basic block
> hash table) might outweigh the key dynarec benefit of eliminating the
> fetch/decode loop, especially with a CPU like the SNES's. You'll also have to
> keep strict account of timing, which is possible in a dynarec, but could get
> messy depending on whether or not you can simply do the timing on a per-basic
> block basis.
>
> I would say you ought to profile first. Premature optimization is often a
> complete waste of time. You need to know what to optimize first. It may be that
> the CPU isn't the bottleneck. I'm sure that the solution will ultimately require
> a healthy dose of assembly language in all major components of the emulator
> (CPU, graphics, sound, etc.) The SNES CPU is fairly simple and given the MIPS'
> large register file, you should be able to write a pretty nice CPU core.
>
> Fetch/decode might be a bit messy, as will flags, but you can probably store
> everything in the registers and minimize memory overhead.
>
>

As always Bart I enjoy your replies as you seem to genuinely enjoy taking time off to respond to these types of inquiries.

I had thought of the profiler but I was wondering if profiling on the PC might have different results compared to execution on the PSP. Probably nothing huge and I'm sure it's a great indicator either way. Could you recommend any?

I'll look into that and assembly for the PSP. I'm not a stranger to hardware architecture or assembly but it's been a while and it was only x86. I'm sure I'll have to play with it for a bit before I even feel comfortable building a CPU core. Either way I'm always looking for something fun to program and I've squeezed out enough fun with Java, .NET, PHP and so forth. Time to get dirty with the low level stuff again.

pixel-eight.com



SubjectRe: Speeding up emulation new Reply to this message
Posted byBart T.
Posted on11/28/07 01:25 PM



> I had thought of the profiler but I was wondering if profiling on the PC might
> have different results compared to execution on the PSP. Probably nothing huge
> and I'm sure it's a great indicator either way. Could you recommend any?

Are there PSP emulators? Sorry, I'm very much out of the loop these days. If so, using them to profile wouldn't be bad. Profiling on an actual PSP itself is your best bet. Because I'm not familiar with the hardware, I'm not sure what capabilities it has for profiling. Surely it has timers but whether they're fine-grained enough for accurate profiling is something you'll have to determine.

If you're talking about profiling an emulator compiled for X86 on a PC, then that's a different matter. It would give you a qualitative understanding of what is likely to be the main bottle neck but for finer optimization, it wouldn't be much help.

What I expect that you'll find is the graphics are by far the biggest bottleneck. Writing a fast renderer in assembly won't be trivial. It'll be quite an effort just to duplicate the functionality of C/C++ code in assembly, and then a whole lot more in order to design something from the ground up to take advantage of the PSP's graphics hardware and CPU.

Next, you might find that the CPU emulation could be greatly improved. This should be conceptually easier to port to assembly (although it will be tedious and boring.)

Lather, rinse, repeat.

You can try to use actual profiling software (like gprof or Intel's VTune, for PC code), but you can just as well write your own profiling routines to keep track of time spent in different parts of the code. There is plenty of information about how to do this online.



SubjectI'll have to look around for an IDE Reply to this message
Posted bySnowball 2
Posted on11/28/07 08:42 PM



I don't know what the PSP has in the legal variety.

Plenty of technical documentation on the PSP and the main processor is well documented (MIPS R4000). I'll see if I can't get an environment going and get familiar with the inner workings of the MIPS 4k. I've got a lot of reading to do too. We'll see what comes of it.

pixel-eight.com



SubjectRe: I'll have to look around for an IDE new Reply to this message
Posted byDracula-X
Posted on11/30/07 06:56 PM



> Plenty of technical documentation on the PSP and the main processor is well
> documented (MIPS R4000). I'll see if I can't get an environment going and get
> familiar with the inner workings of the MIPS 4k. I've got a lot of reading to
> do too. We'll see what comes of it.

It doesn't matter much, but it isn't an r4k. The Allegrex (PSP CPU) does borrow some of its features however. Like the r5900 in the PS2, the Allegrex is a custom job - It's more of a (somewhat, anyway) mips32R2 cpu with no mmu.

http://rapidshare.com/files/72446657/MipsInstructionSetReference.pdf.html

might be helpful to have around.



SubjectYeah, finding this out as I go new Reply to this message
Posted bySnowball 2
Posted on11/30/07 11:33 PM



I actually picked that up the other day. Thanks for your help regardless (I can use it all!). The ps2dev forum has a wealth of information. I've been skimming it the last few nights but unfortunately I haven't been able to dedicate too much time due to work (crunch time at the office). If you do know any good development tools for the PSP I'd be eternally grateful. I haven't had a chance to look yet.

pixel-eight.com



SubjectRe: Yeah, finding this out as I go new Reply to this message
Posted byDracula-X
Posted on12/01/07 04:43 PM



> I actually picked that up the other day. Thanks for your help regardless (I can
> use it all!). The ps2dev forum has a wealth of information. I've been skimming
> it the last few nights but unfortunately I haven't been able to dedicate too
> much time due to work (crunch time at the office). If you do know any good
> development tools for the PSP I'd be eternally grateful. I haven't had a chance
> to look yet.

I wish I could be more helpful, but I think with the ps2dev forums, you'll find everything you need. As far as IDEs go, it doesn't matter at all, as long as you're comfortable with it. Some people use Eclipse, some use Programmer's Notepad, etc. Depends on your environment. I'm under windows/cygwin, I use a basic editor with syntax highlighting, and I keep a few shells open, one for compiling, two for debugging with PSPLink (it's invaluable).
Aside from the psp sdk, I doubt you'll need anything more than that with respect to emulator development. GDB is available for better debugging, but I haven't had need of it. When your program crashes or throws an exception under PSPlink, it's fairly easy to investigate with the register dump it provides (when you compile with debugging symbols on, you can get the line and function the offending crash happens at). It's a little more hands-on than say, a Visual Studio setup, but it works.





Previous ThreadView All ThreadsNext Thread*Show in Threaded Mode