planning a new GP32 port

[kidchaos2k8]

Hi all!

Maybe is a little late, but anyway i would like to open a new topic for development of a gp32 scummvm port... My 3 years-old gp is still working fine and im still interested in developments on the little one... Recently i managed to port beat2x to the gp32, and now i would like to help in the development of this stopped gp32 port if still there is some interest on it...

I have already done some testings with the latest CVS version and compiled (using dkpro-eabi) the gp32 port which executes but reboots the console after some output, as i checked that this version is being developed with the official GPSDK i have also tried to compile the SDL backend using chui's libs+pthread, but there seems to be some problems with SMC access functions which are hard to debug...

I saw a lot of custom code for the gp32 backend, which seems more specific than the SDL backend, but my thoughs are that reusing the SDL backend might reduce the development time a lot (i dont have much spare time anyway )..

Comments and opinions are welcome, the gp32 scene is dead, but hope there is still someone interested on giving some suggestions...

Regards,

@B^)>

[sev]

Yay! That would be fantastic!


Eugene

[DJWillis]

Hi all!

Maybe is a little late, but anyway i would like to open a new topic for development of a gp32 scummvm port... My 3 years-old gp is still working fine and im still interested in developments on the little one... Recently i managed to port beat2x to the gp32, and now i would like to help in the development of this stopped gp32 port if still there is some interest on it...

Really cool to see some life in the old GP32. It's a shame mine died some time ago. I guess you must have one of the later backlit ones if it is 3 years old, the screen on them was very nice.

I have already done some testings with the latest CVS version and compiled (using dkpro-eabi) the gp32 port which executes but reboots the console after some output, as i checked that this version is being developed with the official GPSDK i have also tried to compile the SDL backend using chui's libs+pthread, but there seems to be some problems with SMC access functions which are hard to debug...

CVS? I assume you mean SVN but that is a rather good situation. If your using the GPSDK I assume your using my EABI versions of the libs? What is output out of interest from the GPSDK build?

I saw a lot of custom code for the gp32 backend, which seems more specific than the SDL backend, but my thoughts are that reusing the SDL backend might reduce the development time a lot (i dont have much spare time anyway )..

Comments and opinions are welcome, the gp32 scene is dead, but hope there is still someone interested on giving some suggestions...

Regards,

@B^)>

I would personally be hesitant about using the SDL backend in its entirety but that is only because that every time I tried this it ended up hard against the 8MB limit of the GP32 (much less when you take everything into account) and the less then ideal performance of SDL on the GP32.

It can be done and would be a very nice thing to do but at the very least your going to have to do a build per engine like the DS and do some work creating a hybrid backend of a mixture of SDL, some GP32 specific code and the odd hack . Trust me, it is not as bad as I have just made it sound.

I'll make the same offer I have made to other people who have looked to resurrect the port, I am more then willing to help in any way I can (sans having a GP32) as I would love to see this going again. I still have most of my toolchains setup and as I did a lot of work on the GP32 support for DevKitARM I should be able to help with that also.

Good Luck,

John

[fingolfin]

Note: it is also possible to use SDL only for some stuff, and use custom code for others. Like, use SDL for audio handling, but use custom graphics code. The latter may make sense since (a) you only deal with one fixed screen resolution, and (b) we already have a range of hand optimized ARM assembler routines for blitting, used in other backend.

Also, make sure to enable that ARM code for sound & smush (=SCUMM video); grep the configure file for ARM to see how it's done for e.g. the gp2x.

[kidchaos2k8]

I guess you must have one of the later backlit ones if it is 3 years old, the screen on them was very nice.

Yep, im still very happy with my BLU. Actually i own two, one for development and the other which i use mostly for mp3 playing, gaming and some divx in my travels to work I always have appreciatted the battery life and for me it covers much of my needs ... Here in spain you can afford one at a well known online megastore for less than 80$, and it seems they still have lots of second-hand BLUs in stock, ... I smashed two 64 Mbs smc while porting Beat2x, but the gp is still able to access them, and from time to time i find cheap smc's in my city... ... Hope it will be last for long...

CVS? I assume you mean SVN but that is a rather good situation. If your using the GPSDK I assume your using my EABI versions of the libs? What is output out of interest from the GPSDK build?

Yep it was from SVN... However I realized that everything i have used in gp32 developments (GPTremor, SDL, gdb-stub) are very related to you... So i consider you the "Godfather" of the GP32 And i am very thankful for your help and suggestions during this time...

Regarding the output of the scumm build (using your EABI libs with the prior release of dkpro) it was more related to initilization of the engine... From there when i tried to enter to the scumm menu appeared some warning which says that the gp were obliged to reboot, but after closing the systems correctly... Not bad at all, however at the GP32 specifics options screen always crashed without warning... I did not debug at all, so it was mostly to test the current state of the engine...

I would personally be hesitant about using the SDL backend in its entirety but that is only because that every time I tried this it ended up hard against the 8MB limit of the GP32 (much less when you take everything into account) and the less then ideal performance of SDL on the GP32.

It can be done and would be a very nice thing to do but at the very least your going to have to do a build per engine like the DS and do some work creating a hybrid backend of a mixture of SDL, some GP32 specific code and the odd hack . Trust me, it is not as bad as I have just made it sound.

we already have a range of hand optimized ARM assembler routines for blitting, used in other backend.

Well, ill try to do my best on hacking code but i am not that good on ARM assembly ... [@fingolfin] chui's GP32 SDL port also have some ARM code for graphic and sound... Ill compare the ARM versions available in scummvm...

AnywayI still dont know how to performance code or detect memory limits... My experience with the Beat2X port was painfull specially on getting GPTremor to work with the SDLMixer, but i will swear that the generated code using versions of gcc4 works fine, and the tools are still compatible with the GP32 as debug with the EABI versions of GDB works quite well ... I did some tests adding pthread to SDL from sources of the FreeSCI port and seemed to work fine also... My concern around SDL is related to portability, I would love to port more sources rather than stick just to the GPSDK in this project...

I'll make the same offer I have made to other people who have looked to resurrect the port, I am more then willing to help in any way I can (sans having a GP32) as I would love to see this going again. I still have most of my toolchains setup and as I did a lot of work on the GP32 support for DevKitARM I should be able to help with that also.

Good Luck,

John

I really appreciate your offer, i hope there is no bad sign on trying to keep on with the project... Here goes some questions:

- Build a recent toolchain of DKArm from scratch would be great, with the EABI versions, as i am using the x_gp32library/custom syscalls i have no way to init HW resources on startup but manually,... Ill try by myself anyway, but some help would be ok...

- Also, would you recommend to build from the latest SVN or use a previous stable version? Checking the scummvm documentation i saw that in latest versions is not strictly necessary to use threads, but a clock implementation could be provided, i dont fully understand it but i would try to do some thread testing if it is possible based on the FreeSCI port implementation...

- About debugging, i test directly on HW using insight and the Mithris GDB stub via the pclink cable, its a bit clumsy but works fine for me, so i also need to use part of the EABI-GPSDK, i dont know if there is a better way...

Thanks for everything, ill keep you informed about news...

@B^)>

[Anotherguest]

The generic ARM assembler parts should work as is (ARM assembler that is present in the engine source for Scumm for example) (Since it works for Symbian OS it is very portable ).

For other ASM optimisations for specific needs and from other platforms, I guess some integration work might be needed.

[A600]

I ported ScummVM (0.7 or 0.8, I can't remember) to the GP32 using the SDL backend two years ago and the speed was very good (I even completed BASS without problems)

Sadly I never finished the port and now, I can't find the sources

[kidchaos2k8]

I ported ScummVM (0.7 or 0.8, I can't remember) to the GP32 using the SDL backend two years ago and the speed was very good (I even completed BASS without problems)

Sadly I never finished the port and now, I can't find the sources

Yeah, i think too that backups are for syssies ... Anyway, if you could give some hints on building i would appreciatte very much anyway ..

@B^)>

[md5]

Btw, I assume you already know this, but the code for the now-removed obsolete GP32 port can still be found in ScummVM's SVN tree (rev 32138):
http://scummvm.svn.sourceforge.net/view ... hrev=32138

[A600]

Yeah, i think too that backups are for syssies ...

I found the sources on a DVD I forgot I burned

Anyway, if you could give some hints on building i would appreciatte very much anyway ..

I only remember that SDL_SetTimer doesn't work on the GP32 SDL libs and that I had to do some nasty hacks to get BASS working.

Scumm games, BASS and Simon the Sorcerer worked. Gobliiins crashed due to some filesystem bug that I couldn't trace because I only used printf to debug and it was a pain in the ass

Here are the sources I have:

- Scumm folder has the 0.51 version port
- Scumm3 and Scumm4 folders have the 0.82 version port

Edit the makefile in the root folder to enable the drivers you want to compile (don't forget to add the objs for the drivers)

[kidchaos2k8]

Thank you very much, one day i will make some backup of all these stuff also ...

I cant believe that you managed to build just using printf! Also i saw your posts in gp32spain, is it true that you did it in 10 hours? Impressive...

Ill try to build it...

Regards,

@B^)>