2nd Cpu, Utilised Much In Emulators?


Is that 30fps emulating GBA or GBC ?


Game Boy Advance. Let me clarify. I'm skipping every other frame, so I'm trying to render 30 fps, but it can't keep up, so the game appears to be running about 1/2 normal speed. I don't know if that translates to full speed at 15 fps. Probably does not due to other overhead.
 
Last edited by a moderator:
So... the only way to use the second CPU is... to write a 4k instruction set to work with the first CPU...?

Sound's reasonable, but what could it do...?

I'm not sure what this statement means.

What I meant by limiting to 4k on the 940t is to reduce the amount of code space required to perform the parallel tasks, so that all the code would fit in the 4k cache on the 940 CPU. That way it would not have to goto uncached physical memory for code, which theoretically runs faster.

Currently I have about 32k of code. Even though not all of this is used, i'm thinking the working set is still greater than 4k. Some of the common functions are pretty big. So that means the code space working set of the main loop on the 940t is probably greater than 4k. I'm speculating that the code on the 940t may run faster if the working set of the main loop fits within 4k.

I only have about 1-2k of data, so that should already fit. Most of the big data structures have to be shared, so they are in the 48-64 meg range, which hopefully is rendered uncacheable by the asm startup code in the Dzz example.
 
Last edited by a moderator:
So... the only way to use the second CPU is... to write a 4k instruction set to work with the first CPU...?

Sound's reasonable, but what could it do...?

What I meant by limiting to 4k on the 940t is to reduce the amount of code space required to perform the parallel tasks, so that all the code would fit in the 4k cache on the 940 CPU. That way it would not have to goto uncached physical memory for code, which theoretically runs faster.

That is what I meant...

I'm sorry, I am feeling a little weird today...
 
Last edited by a moderator:
Is that 30fps emulating GBA or GBC ?


Game Boy Advance. Let me clarify. I'm skipping every other frame, so I'm trying to render 30 fps, but it can't keep up, so the game appears to be running about 1/2 normal speed. I don't know if that translates to full speed at 15 fps. Probably does not due to other overhead.


Is that with code running on the ARM to emulate an ARM or is some ARM code running natively? It would seem if instructions ran natively that the speed would be much better wouldn't it? That gives hope for future possibilities.

It seems if this "port" runs at that speed something that was made more specific for the GP2X hardware would be able to theoretically get closer to full speed right?
 
Last edited by a moderator:
I think if one was made for scratch for the 2x when we have a way to actually USE the 940 then full speed would easily be possible. Like maybe Vobbo could move sound onto the 940t for his emu somehow. If he can manage it then we would be looking at 200mhz with sound easy. I mean maybe wit hthe current release as it is currently already rendering sound. Just not implemented.
 
I actually put the 940 to use on this port, and it definitely makes a difference.
I was able to get close to a 2x speed up. Of course I did some serious profiling on the code before hand to see which part was sensible to parallelize.

Care to explain a little further what kind of functions or parts of the emu you have moved onto the 940?

I've been thinking about GBA emulation as well, but from a different angle (writing from scratch for the gp2x hardware, but running under Linux)
 
Last edited by a moderator:
Is that with code running on the ARM to emulate an ARM or is some ARM code running natively? It would seem if instructions ran natively that the speed would be much better wouldn't it? That gives hope for future possibilities.

It seems if this "port" runs at that speed something that was made more specific for the GP2X hardware would be able to theoretically get closer to full speed right?

This is with a port of the C++ source.

I've actually taken a look into this. The general problem is that you're talking about virtualizing the GP2X in the same manner that software like VMWare or Xen works for the Intel x86. Note that even though the CPU is of the same RISC architecture, pretty much everything else is different.

Assuming it's even possible:
1) You'd have to really understand the CPU architecture differences between the GBA and the GP2X.
i.e. the ARM920t and the ARM7 something? I've read from the arm site that it's compatible, but I didn't go into details. There's the obvious issue of memory management and BIOS calls though, which should'be be virtualizable, but will probably require patching the binary code once again. I believe this is partially the approach that VMware takes.

2) You would probably have to massage the binary a bit for the 16 bit mode instructions, or replace, or something..

3) You'd have to figure out how to do the timing for the environment (i.e. video rendering, sound rendering)
You can blindly do 60Hz in the background, but I don't really know what that will do.
If you try to do synchronization, then all your binaries will probably have to be massaged in such a way that you might as well emulate it.

This amongst many many other things must go right for this scheme to work.



I actually put the 940 to use on this port, and it definitely makes a difference.
I was able to get close to a 2x speed up. Of course I did some serious profiling on the code before hand to see which part was sensible to parallelize.

Care to explain a little further what kind of functions or parts of the emu you have moved onto the 940?

I've been thinking about GBA emulation as well, but from a different angle (writing from scratch for the gp2x hardware, but running under Linux)

The graphics rendering. I don't know if Visualboy's approach to rendering is that efficient, but it sure does tons of work on each scanline. So I shared all the state required to do rendering in the 48-64 meg region, and basically let the 940 do it's thing. I don't know the GBA architecture well, but from the code it looks like layer/color/rotation/font/general rendering functions. From my profiling, it appears that close to 50% cpu time is spent doing this. Now granted, it's possible that Visualboy's implementation made many speed sacrifices for compatbility and code clarity reasons, so this may not be the true (optimal) performance breakdown.
 
Last edited by a moderator:
Are you planning on releasing this anytime soon? This sounds really interesting as I did not see emulators utilizing the second cpu. Well on the other hand I also have no idea at all about embedded systems and such.
 
Are you planning on releasing this anytime soon? This sounds really interesting as I did not see emulators utilizing the second cpu. Well on the other hand I also have no idea at all about embedded systems and such.

Probably not until it's somewhat useful. It's still way too slow. I don't think releasing an emulator that supposedly uses the 940t but runs at 15fps max is constructive for promoting the use of the 2nd cpu. :D
 
Last edited by a moderator:
probably true... anyway, I will be donating if you manage a useful release (meaning somewhat playable speed even without sound on gba). This could be what all the gba lovers have been waiting for... er... or was that the ds-lite... whatever.
 
Back
Top