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


If Linux can't give us what we want, I say we throw it out. I mean, just by taking over the interrupt/exception handler then restoring it when we're done this might be enough. It'd destroy all other multitasking going on in the background but I think that's a price people can be willing to pay for this (it's not like their GP2X is part of a compile farm while they play GBA games)

With what I'm thinking of we might want full control of the page fault handler anyway. It's a bit daunting stuff but nothing anyone with a little kernel writing experience can't tackle *_*

It's all kinda daydreaming at this point though ^_- Not like I have a GP2X or anything.


Yeah, throw linux out if you can. When you are playing GBA stuff it is not like you need to run USB or anything.

The only problem is that as soon as the GP2X gets to the point where you can do anything linux is already loaded. I don't know if you can get rid of it at that time.

Plus you would have to write your own SD card drivers etc. That would probably as much work as writing the emu itself.
Someone was working on a non-linux simple loader at one time ("HH") but I guess it was abandoned.
If you did write a non linux loader I bet alot of other coders could use it.
 
Last edited by a moderator:
I don't pay attention to the PSP emulation community, so I'm unfamiliar with this emulator.... Just for comparison, how fast does it run on a PSP? Is the compatibility good?

--Zero
 
If by "ARM code running natively" you mean it will run a ROM through virtualization, it will not use that technique. Just had to clarify that. All applications on the GP2X run ARM code natively though, since it's the only arch's machine code it can understand. That's the purpose of a compiler.

The emulation of the CPU will use a dynamic recompiler when it is completed. It will have the benefit of translating from an ARM arch...to an ARM arch. There are still things other than the CPU instruction set that must be handled, which is what stops someone from being able to execute a GBA game on a GP2X. The hardware other than the CPU is different. And when that occurs, and you need emulation you must deal with CPU flags and etc.

The methods of running the emulator in the best suited way for the GP2X have been outlined by Exophase, and I'm currently researching if they are available options. It's pretty elegant way of going about things, but it might be just gibberish if the GP2X Linux distro restricts it for instance.

I just meant native as in you wouldn't have to emulate an ARM since you already have a real ARM CPU. It wouldn't be like a Megadrive emu where you have to translate 68000 instructions to ARM ones. That is what I was getting at.

I know there are other things keeping GBA stuff from just running. There is the GPU and audio etc. I am just wondering if you could run the arm code natively and emulate the other stuff in spare cycles. The GBA is only like 12 MHz. The GP2X is 20x faster. That is alot of spare time for the CPU. Then you have the second core that could do some simple tasks as well. The resolution is also 1/2 of the GP2X so drawing the fewer pixels is easier. The scary part though is that the GBA is very SNES-like with it's scaling/rotation and transparencies. That could be a bit of an obstacle.
 
Last edited by a moderator:
DaveC:

Maybe I don't mean "get rid of Linux" as much as I mean.. circumvent it for a long time. If taking over interrupts is enough it'll be sufficient, I think. As far as files go, you can go back to Linux whenever you need that stuff. It's devious but could work, depends on a lot of other factors of course. The biggest being where the interrupt vectors live (course you'd also need to be in kernel mode).

True virtualization is not really possible, unless the ARM9's have hidden features I don't know about. There's a subtle distinction that throw a lot of people off, but even though it's ARM->ARM you can't run one on the other because you have to treat certain instructions differently. In particular you have to run the GBA code so it's always in user mode, but make it think it's in whatever mode it's really in. If this can be caught with exceptions then virtualization might be possible. Otherwise a slim dynarec would be used.

BTW, GBA is 16MHz.

The video rendering takes a lot of CPU time, but it can be done on PSP decently well, fully software (no hardware acceleration), so at least that won't be a tremendous concern. Frameskip 1 naturally cuts requirements in half so... I wouldn't recommend using it on the second CPU though, it's too tightly linked with the GBA CPU, sharing a memory space.

Ze_ro:

At this point gpSP is running most games at fullspeed with perhaps a little frameskip - there are a few games that run very slowly but they probably need certain tweaks to overcome this (games that just don't play nice with dynarec).. compatability is okay. Like 80%. Will be higher in the next version. It's not as compatibly as VBA of course.
 
Not like I have a GP2X or anything.

then get one, quickly... :p

and zodttd, seems like davec and epicenter woke some ambition in you lol :)
good luck mate!

and davec: thanks for being grown up this time ;)
 
The video rendering takes a lot of CPU time, but it can be done on PSP decently well, fully software (no hardware acceleration), so at least that won't be a tremendous concern. Frameskip 1 naturally cuts requirements in half so... I wouldn't recommend using it on the second CPU though, it's too tightly linked with the GBA CPU, sharing a memory space.

Ze_ro:

At this point gpSP is running most games at fullspeed with perhaps a little frameskip - there are a few games that run very slowly but they probably need certain tweaks to overcome this (games that just don't play nice with dynarec).. compatability is okay. Like 80%. Will be higher in the next version. It's not as compatibly as VBA of course.

The PSP is 133 MHz faster so I would think the Gp2X would need more help. I was hoping the CPUs being both ARM would help make up the difference.

Could there be something that the second core could do? I know it helps Megadrive emulation alot. It is used to run the audio emulation, and gives a very nice speed boost.

80% is pretty good. It is better than the 0% that we have now :p
 
Last edited by a moderator:
Zodttd, if you hadn't noticed, I sent you a couple of PMs.

Oh, and to whomever put the fellow with his head up his ass in my signature, grow up. This is something I'd expect from a Shadow the Hedgehog fan forum occupied by 6 year olds.
 
If Exophase and zodttd are going to be working together to bring proper gba emulation to the GP2X, perhaps a "donate to get Exophase a gp2x" fund could be set up to try and get him a gp2x. I believe Squidge received his gp2x in a similar manner?
 
The only problem is that as soon as the GP2X gets to the point where you can do anything linux is already loaded. I don't know if you can get rid of it at that time.

Oh, that's easy. Remember Robsters Firmware Updater? That does exactly that :)
Since the first version.
 
Last edited:
Back
Top