Gpsp (dynarec) Beta Testing


Btw, just some cross-promotion. Squidge just released Spot. The GP32 "emulator". This is my favorite project going, and I've been talking to Squidge about it. The interesting part about this project is it's potential for virtualisation. The same technique can be used with gpSP2X, so Squidge and I will have to discuss the potential for it's use in gpSP2X.

While waiting for the next version of the gpSP2X beta, check out the Spot thread. ;)
 
Status update: My next release will be a more stable gpSP2X public release. :)

After that release I plan to use virtualisation. ;)
 
zodttd posted on Mar 14 2007 at 01:44 AM said:
Status update: My next release will be a more stable gpSP2X public release. :)

After that release I plan to use virtualisation. ;)
Tonight? :lol:
Thank you Zodttd :)
 
Last edited by a moderator:
Sweetness. Too bad my mom took my 4gb card for the week and all I've got is a 1gb and my low power 1800mah batteries....

"After that release I plan to use virtualisation. ;) "
Working with Squidge?
 
zodttd posted on Mar 14 2007 at 08:15 AM said:
Btw at just some cross-promotion. Squidge just released Spot. The GP32 "emulator". This is my favorite project going, and I've been talking to Squidge about it. The interesting part about this project is it's potential for virtualisation. The same technique can be used with gpSP2X, so Squidge and I will have to discuss the potential for it's use in gpSP2X.

While waiting for the next version of the gpSP2X beta, check out the Spot thread. ;)

One more problem, :p

I found that gpSP cannot save the game in the 9005 version. But it has no problem at 9004d.

hm.. what soft of virtualisation will you do ? :unsure:
 
Last edited by a moderator:
hilarycheng posted on Mar 14 2007 at 02:53 AM said:
zodttd posted on Mar 14 2007 at 08:15 AM said:
Btw at just some cross-promotion. Squidge just released Spot. The GP32 "emulator". This is my favorite project going, and I've been talking to Squidge about it. The interesting part about this project is it's potential for virtualisation. The same technique can be used with gpSP2X, so Squidge and I will have to discuss the potential for it's use in gpSP2X.

While waiting for the next version of the gpSP2X beta, check out the Spot thread. ;)

One more problem, :p

I found that gpSP cannot save the game in the 9005 version. But it has no problem at 9004d.

hm.. what soft of virtualisation will you do ? :unsure:
I can save correctly ;) Just put over save slot 0 and press X, or maybe B.
When you want to load another day, launch the game and put over load and press B or X i don´t remember, but i am playing Zelda and saving every 5 minutes so i can progress loading after crashes.
 
Last edited by a moderator:
Does anyone understand this virtualisation idea and why it could be so helpful?
 
imhotep posted on Mar 14 2007 at 03:23 AM said:
Does anyone understand this virtualisation idea and why it could be so helpful?

I think because then you can run ARM instructions natively on the ARM. This is much faster than an ARM CPU emulating itself. It think :unsure:
 
Last edited by a moderator:
imhotep posted on Mar 14 2007 at 03:23 AM said:
Does anyone understand this virtualisation idea and why it could be so helpful?

I believe it will vastly increase the speed of any emulator that can actually use the technique.

Reason is, normally an emulator cannot take the binary code of the original executable and run it on your machine's CPU. Typically, the machine it is trying to emulate is a completely different CPU and so it must go through many further steps to interpret what's going on. This is what the BOCHS PC emulator does, and also why it is dog-slow.

Now, what if you're trying to emulate a PC on a PC, like the awesome VMWare product does. Then, you can vastly speed things up because a lot of the code can simply be sent directly to the CPU unaltered. There will be times, of course, when a direct access to hardware will screw everything up and then you can catch that and emulate just the bits and pieces you have to. This, I believe, is virtualization.

The Gameboy Advance uses an ARM chip, and so does the GP2X. That is why virtualization could potentially speed things up.
 
Last edited by a moderator:
Nice explanation, Senor Quack.

I guess virtualization could be considered a half-way point between full emulation and running the code natively. This will be amazing if it comes off. :)
 
From what understand about it, it takes the instruction set from the CPU you want to emulate, and runs it natively on the target CPU (in this case, the GP2X's CPU). The only way virtualization works is if both CPUs are of the same architecture. So since Gameboy Advance CPU is an ARM7 and GP2X's is an ARM9, the instructions are compatible because they are both of the ARM CPU architecture. So you couldn't do virtualization with say a MIPS CPU and SuperH CPU.

What I am curious about is would virtualization mean a complete re-write of Exophase's code, and be tougher than the dynarec ZodTTD has been wrestling with?

Edit: Beaten by Senor Quack. Nice post btw!
 
Virtualisation is currently used in VirtualPC, VMWare, Parallels...you know, those commercial products used to run another OS within Windows/Linux/Mac.

The concept definitely works. I hope Squidge jumps on soon so I can get started on it. ;)

Allowing a GBA ROM to run natively on the GP2X and hook into the routines that handle the specifics of the GBA that are different on the GP2X, will speed things up greatly. It's nice to know it can be done on the GP2X. :)
 
Back
Top