GP2X Developing For Gp2x Via Windows

[jimb]

I have given up trying Linux installations.
Every version I've tried fails to work.
I usually get as far as installing/loading then ... blank screen.

Penguins hate me.

@DJWillis .. Sounds terrific!

 

[codesmith]

@DJWillis:

That's pretty cool stuff! I have a question... since we're going to have to link statically, wouldn't it make more sense to use newlib rather than glibc? given that glibc is a lot bigger than newlib, and most of that size difference is made of of posix functions that most gp2x games aren't going to call, it sort makes sense to me...

 

[slygamer]

I am 100% behind any effort to make a Windows development toolchain that does not require Cygwin or MinGW or Msys or any other Unix feel-alike.

 

[Squidge]

I am 100% behind any effort to make a Windows development toolchain that does not require Cygwin or MinGW or Msys or any other Unix feel-alike.

​

Why, whats wrong with them? They make everything a hell of a lot easier...

 

[DJWillis]

I am 100% behind any effort to make a Windows development toolchain that does not require Cygwin or MinGW or Msys or any other Unix feel-alike.

​

Well your out of luck, GCC IS a Unix feel-alike tool-chain, I am trying to build it around MSys, MinGW etc. so you get native Win32 exe's without the needs to install extra DLL’s, CygWin etc., there still the same *Nix tools . If you don't want a lot of extra work mSys will be your friend as it gives you the supporting, non tool-chain, tools that make the job so much easier.

If you want fancy, glossy, tools then the GP32 and GP2X are not for you I am afraid. Considering the GP2X is by default Linux based I would feel that was obvious . Wrappers for using things like GCC from the Visual Studio are avalable (infact I did a lot of work on making GCC errors work with the VS IDE so you could jump to a line of code on an error).

That's pretty cool stuff! I have a question... since we're going to have to link statically, wouldn't it make more sense to use newlib rather than glibc? given that glibc is a lot bigger than newlib, and most of that size difference is made of of posix functions that most gp2x games aren't going to call, it sort makes sense to me...

​

NewLib would be great but it is not suitable from using as a LibC in an ARM-Linux environment, the limited stuff that is running on the raw hardware (i.e. bypassing Linux, ARM-ELF target) is already using a tool-chain built with NewLib .

NewLib could be hacked in to an ARM-Linux tool-chain but this would be the evilest of evil hacks etc. etc. and I would get soooo much flack for it. Shame really as a dislike gLibC is a passion having spent who knows how long getting it working.

 

[codesmith]

@DJWillis:

I see. Well, thanks for the straight answer

 

[codesmith]

I am 100% behind any effort to make a Windows development toolchain that does not require Cygwin or MinGW or Msys or any other Unix feel-alike.

​

Oh, trust me - unix feel-alike is not at all bad. I do agree that I'd much rather have MinGW than CygWin, but that's because I prefer to have a native toolchain rather than one sitting on top of a Unix emulation layer - layers add inefficiency, and why have that when there's a perfectly good version (MinGW) that doesn't.

Unix-like tools all have in common that they get run from the commandline, and all IDEs that I know of (even Visual Studio!) let you specify custom commands for compiling stuff. So, the transition from Unix-like to Windows-like is just an afternoon tweaking command-line switches and saving them to your IDE project file and writing a makefile to handle dependencies for GCC (actually not that hard to do, it's just a list of "to build this object file you need that source file, and this is the commandline you run"); then, you can just keep doing things the way you're used to. I've done that to cross-compile everything from GBA to AmigaOS (and GP32) binaries, all using various flavours of GCC run from within Visual Studio (all the way from 6 to .net beta 2). Now, if there only were a way to integrate remote GDB into visual studio, I'd be all set

 

[judge0]

For Windows users I am just working the bugs out of a customised GCC 4.0.2 based tool-chain that runs on Windows (without the need for CygWin) and it features patches to enable the excellent ARM ASM floating point code that is normally disabled on ARM-Linux GCC builds.

This is already in Open2x's CVS (tool-chain module) and I hope to release a pre-built windows tool-chain/devkit in a few days with a matching set of SDL, SDL_Mixer, SDL_Image, libMAD, Tremor libs etc.

If you use CygWin the scripts already build a working tool-chain already (if you follow the README ), they also build working tool-chains on all the Little Endian Linux boxes I tested.

I am not 100% that the scripts will build a tool-chain on a Big Endian box (I don't have my Solaris box to test on) but for 99.99% of people that is a non issue . If you have a Big Endian box you know what it means .

​

I hate to be the one to ask the stupid question, But here goes .... :unsure:

Which flavor of windows . . . DOS-based or NT?

Reason I ask - I have an overpowered desktop running XP SP2, but for mobility I have an underpowered Compaq running 98SE (helps for fast coding at work)

I'm sure some of the community members will be running ME (gasp), maybe a quick reply will steer them towards the correct solutions instead of trying to install a toolochain not instantly installable on a DOS based OS . . .

Like I said a stupid question

 

[DJWillis]

judge0,

Win32 for the most part goes back to Win95 (hell, Win 3.11 with Win32s but lets not go there) so there is no good reason that people running WinME should not be fine, somebody will need to test it as I do not have anything running a version of Windows so old.

98 and 95 etc. are lightly to be non-starters due to there really ancient versions of core Windows libraries that MinGW builds against.

 

[slygamer]

Well your out of luck, GCC IS a Unix feel-alike tool-chain, I am trying to build it around MSys, MinGW etc. so you get native Win32 exe's without the needs to install extra DLL’s, CygWin etc., there still the same *Nix tools . If you don't want a lot of extra work mSys will be your friend as it gives you the supporting, non tool-chain, tools that make the job so much easier.

If you want fancy, glossy, tools then the GP32 and GP2X are not for you I am afraid. Considering the GP2X is by default Linux based I would feel that was obvious . Wrappers for using things like GCC from the Visual Studio are avalable (infact I did a lot of work on making GCC errors work with the VS IDE so you could jump to a line of code on an error).

​

Having done some more investigating, MinGW is much more preferable to Cygwin.

Fancy, glossy tools are not what I want. A simple build environment IS what I want. I'm going to be building on Win32, so the build environment should work simply on Win32.

I'm going to be playing around with creating games for the GP2X with FreePascal. That is not a fancy, glossy tool by any stretch.

 

[DJWillis]

Fancy, glossy tools are not what I want. A simple build environment IS what I want. I'm going to be building on Win32, so the build environment should work simply on Win32.

Cool, MinGW hosted tools will suit you just fine then

I'm going to be playing around with creating games for the GP2X with FreePascal. That is not a fancy, glossy tool by any stretch.

FreePascal? I did not think there was a build of that running on ARM-Linux without QT behind it?

 

[judge0]

judge0,

Win32 for the most part goes back to Win95 (hell, Win 3.11 with Win32s but lets not go there) so there is no good reason that people running WinME should not be fine, somebody will need to test it as I do not have anything running a version of Windows so old.

98 and 95 etc. are lightly to be non-starters due to there really ancient versions of core Windows libraries that MinGW builds against.

​

Thanks, will have to do something else for the laptop solution . . .

Next silly question, when we compile executables for the GP2X,
do we have to chmod 777 blah blah on the output file before transfer? B)

 

[slygamer]

FreePascal? I did not think there was a build of that running on ARM-Linux without QT behind it?

​

QT is not required. I've now got the ARM cross-compiler built on Win32 from latest FreePascal source, plus there is JEDI-SDL, which is a Pascal port of the SDL headers.

I'm almost ready to start writing something.