Guess What? A Port Of Gpsp (gba) To The Gp2x...


Epicenter: I've been trying to reply to you via PMs, but they're either disabled or your inbox is full. This project isn't meant to provoke you in any manner. When you get the PM issue sorted out, let me know.

Exophase: You could answer the static recompilation question a page back, better than I could.

DaveC: I appreciate your support.

EvilDragon: If you have a spare GP2X around, I might know someone that could use it... Won't need a high overclock this time. ;P
If we went the route of ditching Linux, could users switch between "firmwares" easily? One with Linux, the other with a custom approach for at very least the ability to run gpSP in the most optimal approach.

Vimacs: Sounds like a some-what similar approach of what we have in mind. Though we've been focusing on the main 920T. Weird to see that done on the GP32. Cool!

Once again thanks everyone for the support. Definitely a warm welcome to Exophase. :)
 
I'm not working on this. I put a forum thread about gPSP explaining the gPSP improvements over other GBA emulators, the easy port process, etc, trying to get someone with interest to do the port, because i want to collaborate in another project... I said that if nobody was interested i would start the port myself... But i think there are a lot of people now trying to do the port: Zodttd, Critical, and at least three anonymous additional programmers (i have received some PM and have read some threads in gp32spain). :D Good luck to everybody !!! :lol:
 
I am sure you can pull this off. Playing Golden Sun on the GP2X would be fantastic. Don't you agree, guys?
 
If we went the route of ditching Linux, could users switch between "firmwares" easily? One with Linux, the other with a custom approach for at very least the ability to run gpSP in the most optimal approach.
There are multiple ways to do that, the most user friendly one is robsters "trampoline" which loads your program into ram and then kills linux. http://www.cobbleware.com/files/sdk2x_191205d.tar.gz Its inside the "util" folder.

Another way would be to use art's modified uboot wich allows you to load a different "kernel" from sd on boot up. http://www.artaylor.co.uk/~richard/gp2x/dev/u-boot.html
 
Last edited by a moderator:
If we went the route of ditching Linux, could users switch between "firmwares" easily? One with Linux, the other with a custom approach for at very least the ability to run gpSP in the most optimal approach.
There are multiple ways to do that, the most user friendly one is robsters "trampoline" which loads your program into ram and then kills linux. http://www.cobbleware.com/files/sdk2x_191205d.tar.gz Its inside the "util" folder.

Another way would be to use art's modified uboot wich allows you to load a different "kernel" from sd on boot up. http://www.artaylor.co.uk/~richard/gp2x/dev/u-boot.html
I don't think getting rid of linux will give many advantage. Linux don't really eat many cycles. IIRC, Squidge did some test and the difference weren't noticeable. The only advantage would be taking control over interrupt but I don't clearly see why it would be need.

Anyway, I'm impatient to see a gpSP port :)
 
Last edited by a moderator:
I think the only appreciable advantage is getting full control of the MMU. Everything else would probably have more or less clean solutions. Plus, it leaves open the option for TCP/IP multiplayer.
 
Control of the MMU is exactly what we want though. The overhead of Linux isn't the issue. We would like to create a virtual address space, use IRQs for syncronizing, and be able to use a timer based callback system. Though the techniques we would like might not be feasible, there are of course other ways. :)

Some news of progress:
I just spent an hour with Exophases impressive gpSP code, and I have it compiled for the GP2X. There were very few issues, and it looks like things should go well for this project. The compile I made uses an interpreter. Though I will be getting the ARM Dynarec up and going asap. There are GP2X hardware specific optimizations I could use, though I will see how the various SDL ports handle for the meantime. I had some trouble in the past with the hardware accelerated SDL port for the GP2X. I don't remember specifically why it wasn't working though.

Well I'm going to test this initial build on the GP2X and see how it goes. An update will soon follow.

So far so good.
 
Well I'm going to test this initial build on the GP2X and see how it goes. An update will soon follow.
I looked at this a couple of weeks ago. You might find it crashes when running a ROM because it tries to use paging when it shouldn't need to (when the rom size is under the paging limit).

It's a bit bizarre, as things run fine on the G*zm*nd*. I never really investigated on the GP2X past that... I hope that vague recollection assists. Or rather, I hope it was just something idiotic I was doing, and it runs fine for you ;)

EDIT: spelling
 
Last edited by a moderator:
As much as I would like to play GBA on the road, I am still not convinced enough to buy a GP2X, simply because the headphone jack remains on the top of the unit.
 
As much as I would like to play GBA on the road, I am still not convinced enough to buy a GP2X, simply because the headphone jack remains on the top of the unit.

I don't see a problem with the headphone jack being on the top of the 2X... the one thing that IS annoying is the power socket is on the right side... >_>
 
Last edited by a moderator:
Wow- I wish you the best of luck; this could easily be a killer app for the 2x if all goes well. You have a great deal of verve too! thanks very much for your consistent updates- definitely appreciated.

now I may have an excuse to upgrade to a 2x... :)
 
Afaik you can even control the mmu and other stuff from isnide of linux with some hacking,
after all that's what squidges mmu hack does,
I'm sure that could be modified to do other things as well.
 
Back
Top