Gba Emulator That You Can Adjust The Screen Size

[R.B]

Is there an GBA emulator for the Pandora that you can adjust the screen size to make it bigger not like the yoshis_pandora_emulator_pack_v06

 

[Prometheus]

The simple answer to this is "No, not really".

The longer answer is "Yes, but it runs too choppily to really be playable". Look for the VisualBoyAdvance PND, if this is what you're after.

 

[Blue Protoman]

Why the hell does Exophase refuse to port GPSP natively?

 

[pder]

Why the hell does Exophase refuse to port GPSP natively?

I think several people have tried to port it without success, and gave up. I also spent an afternoon on it and ran into a wall. Perhaps someone more qualified understands the issues- I found it very difficult to debug.

 

[Exophase]

Why the hell does Exophase refuse to port GPSP natively?

Why should I? The source is available and it doesn't take some kind of special emulator coding magic to port it. I don't want to work on gpSP and moreover I have other things to do these days.

 

[moxie]

Well, obviously it is your Eternal Duty to port anything and everything you ever done to any new platform available. You didn't read the fine print when you submitted gpSP to the archives, I suppose?

(ha-ha-not-serious, obviously)

 

[PokeParadox]

Why the hell does Exophase refuse to port GPSP natively?

Why should I? The source is available and it doesn't take some kind of special emulator coding magic to port it. I don't want to work on gpSP and moreover I have other things to do these days.

Well sure it's not that you HAVE to port it... but as mentioned, it seems there are issues with the current source that various people have run into when porting and maybe you know how to work around them... and it is kick-ass emulator running GBA games on GP2X at 260MHz! *flutters eyelashes*

GINGE version is fine in speed terms... it would just be nice to have a clean scale that makes better use of the Pandora's larger screen.

so... um... pretty pretty please with a cherry on top?

 

[fusion_power]

GINGE version is fine in speed terms... it would just be nice to have a clean scale that makes better use of the Pandora's larger screen.

Thats the Point. GBA would fit niceley with 3x scaling but nobody portet it yet with this option. So the image looks not even close as good as it could. Otherwise, GPSP with Ginge runs fine ,except that it does not save the rom path somehow.

 

[mcobit]

Well, I tried to compile it for Pandora and it worked after ripping out the mmuhack and some other gp2xspecific stuff.
But on start it now just says "bus error" and it refuses to start.

Also when I compile with -Wcast-align it gives me a lot of "warning: cast increases required alignment of target type".

Is there a problem with memorymapping of some sort?

Edit: I think someone with a lot more knowledge than me will have to have a look at this. Didn't notaz port it for the gp2x?

 

[Blue Protoman]

I might add that it's actually a bit choppy through Ginge, as is GPFCE-GP2X.

 

[Exophase]

Plenty of other people have ported gpSP to other platforms mostly w/o my help, and I don't think Pandora is harder.. maybe you should talk to some of them.

zodttd and I did the first GP2X versions but notaz took over from there, and did the Wiz version(s). I'm sure he'd have no problem porting it to Pandora but he probably has much more important things to work on.

 

[TitanUranus]

I'm still waiting on R.B to finish his original question...

Still, it seems like he's asking something along the lines of "are there any trousers I can wear that will make my crotch bulge appear bigger than it really is?". This of course would be a recipe for disappoint all round.

 

[crow_riot]

well i was just giving this a shot, starting from the latest notaz sources.

i've changed some SDL surface init code, so at least the menu shows up and i can choose a rom.

but launching a rom just crashes, sadly (yeah, i've chosen one that works with ginged gpsp)

*edit*removed*edit*

 

[mcobit]

well i was just giving this a shot, starting from the latest notaz sources.

i've changed some SDL surface init code, so at least the menu shows up and i can choose a rom.

but launching a rom just crashes, sadly (yeah, i've chosen one that works with ginged gpsp)

*edit*removed*edit*

Hi, You may want to try to get the latest maemosources going. They have a ogles scaler in them too. I could't make it work, but you got more far with notaz' sources, so you might be successful.
The Maemo sources need some other stuff, but that is buildable for pandora too.

 

[crow_riot]

Hi, You may want to try to get the latest maemosources going. They have a ogles scaler in them too. I could't make it work, but you got more far with notaz' sources, so you might be successful.
The Maemo sources need some other stuff, but that is buildable for pandora too.

the problem lies somewhere within the recompiler - and all the arm ports use the same one, there's no slight change in any of them. the maemo porter also asked about help here in the forum, because he had the same problem I'm experiencing here. From the makefile comments it was the "-fno-common" compiler flag that "was required to get games to start" .

*edit*
i've investigated a little further. it seems that the flushing the cache doesnt work as expected.
i've replaced the sys_cacheflush instruction to use __clear_cache function provided by the toolchain.
it seems that it gets a little further now, but now i get bad jump errors (e.g. bad jump e007fe0 (3007d76) (0) )

i wonder if this has something todo with the statement i've read here:
__clear_cache() works, but only if the memory area in question was allocated using mmap() with PROT_EXEC set. Linux will not flush the instruction cache if you provide it with a memory range that comes from regular malloc()ed memory, even if the processor seems to be happy to execute code from malloc()ed memory.

 

[Schnatterplatsch]

I hope you have success. Would be nice to see to what degree the speed improvements go.

Has GpSP problems with Golden Sun? I recall random crashes on the WiZ, but maybe I just overclocked too much...

 

[notaz]

It's strange so many people are having problems with this. If I were to do it, I'd start with my Wiz sources here, as the old GP2X ones have cache invalidate code that doesn't play nice with 2.6 kernel. I'd also use OMAP scaler instead of GLES as I think the former is better suited for this; it's documented in the wiki.

mcobit reported he has tried the Wiz ones and got wARM errors (those can be ignored, it reverts to correct kernel syscall), and what I understood Wiz hardware register mmap failure, which is normal since this is not Wiz. The later would need to be changed to use framebuffer+hw scaler and all should work well. Wiz version's cache handling should be right, it works fine under Ginge (Ginge doesn't do anything with invalidate syscall).

 

[mcobit]

I would really appreciate, if exophase could help a bit with this.

 

[crow_riot]

It's strange so many people are having problems with this. If I were to do it, I'd start with my Wiz sources here, as the old GP2X ones have cache invalidate code that doesn't play nice with 2.6 kernel. I'd also use OMAP scaler instead of GLES as I think the former is better suited for this; it's documented in the wiki.

mcobit reported he has tried the Wiz ones and got wARM errors (those can be ignored, it reverts to correct kernel syscall), and what I understood Wiz hardware register mmap failure, which is normal since this is not Wiz. The later would need to be changed to use framebuffer+hw scaler and all should work well. Wiz version's cache handling should be right, it works fine under Ginge (Ginge doesn't do anything with invalidate syscall).

well your way is exactly the one i wanted to go, but first i just replaced the GP2X sdl+input with plain SDL because that seemed to be the fastest way to get a build running. i have not changed a thing in the recompiler.

i also tried with different approaches of flushing the cache - your wARM version, the toolchain version, another one replacing swi with svc. then i read about that flushing only works for mmap'ed memory with PROT_EXEC, also changed the code to that. still no success.

there's only one thing left to try, before i throw the whole thing out of the window - mainly "improving" the cache flush assembler by pushing/popping the registers before they are used - but i dont know if that is required.

i should probably remote debug, because launching gdb and showing backtrace didnt reveal very much (well, nothing).

the only main difference i think is that the Wiz/Ginge version uses OABI and the compiled version uses EABI - could that be a reason for the problems arising here?

 

[notaz]

there's only one thing left to try, before i throw the whole thing out of the window - mainly "improving" the cache flush assembler by pushing/popping the registers before they are used - but i dont know if that is required.

In the Wiz version, inline asm already has clobbered register list that should deal with this..

the only main difference i think is that the Wiz/Ginge version uses OABI and the compiled version uses EABI - could that be a reason for the problems arising here?

It shouldn't be, but maybe. I guess I'll try to look at it soon(ish).