Blue Protoman said:Why the hell does Exophase refuse to port GPSP natively?
Blue Protoman said:Why the hell does Exophase refuse to port GPSP natively?
Exophase said:Blue Protoman said: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.
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.PokeParadox said: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.
crow_riot said: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 said: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.
notaz said: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).
In the Wiz version, inline asm already has clobbered register list that should deal with this..crow_riot said: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.
It shouldn't be, but maybe. I guess I'll try to look at it soon(ish).crow_riot said: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?