GP2X The Penguin Must Die!

[karmacop911]

I'm interested in HH to do a native GP2X Forth one day.

Everything can be done in 1% the code.

SDL and Linux require more code. with SDL, a C program to draw a pixel onto the screen requires +20 lines of code. In Forth it is possible in 1. Forth is just one of the reasons why HH is needed (by me! ) and shouldn't be discounted.

On the other hand, Linux provides many neat services. People seem to like it because programs written for it are "portable", but doesn't it ALWAYS take some work to port a program to another system? You might as well write a new virtual machine that guarantees the same binary image to run across supported platforms. And anyway, what is true portability?

 

[gfoot]

Portability isn't necessarily the valuable thing about using Linux. I'd guess the most valuable point is reuse of an established API - which covers core C libraries (including interfaces to system calls), as well as specific things like providing the SDL API for game-specific functionality.

Reusing existing APIs saves time when people are learning the system though, and that's one of the stronger benefits of basing its OS on something which already exists. It also means that the knowledge is more or less portable to other systems, even though most games are not without at least some minor tweaking.

It also cuts down the amount of development work needed by the manufacturer, and small companies benefit a lot from that. Also note that there was no SDK supplied with the machine - they wouldn't have been able to get away with that if the tools to do the development weren't already available on the Internet.

Regarding dropping out of Linux to run your Forth virtual machine, it may be possible to draw a pixel to the screen in 1 line of Forth code, but that's not dependent on whether Linux is running or not - you could equally well write a Forth interpretter for GP2X/Linux, and have your 1 line of code to draw a pixel. If you're using an interpretted language like Forth, IMHO you're unlikely to see any significant benefit to bypassing Linux, so you'd just be wasting a lot of time reimplementing things that the kernel already does for you if you'd let it.

Of course, the reimplementation can be fun too, if you're into that kind of thing, but don't get mixed up between enjoying reinventing wheels, and needing to reinvent wheels.

 

[karmacop911]

a valid point. sometimes reinventing the wheel is not what you want to do! one of my options is to write the forth for Linux/GP2X for starters, and then think about native boot. I just don't know which one will be less challenging. the setup code for a Linux-based app can't be negligible, and the standardized SDL system limits what you can do. another drawback is it masks over features of the hardware that constitute the POINT of using the GP2X - what it actually does, on TOP of merely being portable and having a USB interface. to put it simply, i guess, it's just not as *interesting* to use standardized protocols.

To counter your argument about doing it with the "standard" SDK(s), I say it's simpler to assemble a 5 kilobyte source code that will run natively than it is to manage the infrastructure for a C project that uses inline assembly. It's easier to understand the hardware and write your own specific routines to do what you need to do, using libraries not merely because you are compelled to do so in the name of "compatibility", but only when/because it's more convenient..

We have to understand clearly the benefits of Linux versus HH. It's clear both have advantages and possible disadvantages, based upon what you value. I am leaning toward going HH because it seems like it will be well supported and i hope it is! and by well-supported, what i really mean is not hindered or complicated in any way. libraries are secondary.

(this is all based on my assumption that you can't just take over the machine in ASM from a linux-app on the gp2x.)

 

[Cyclops]

considering backward compatibility was *such* an important feature missing on the GP2X surely having a device futureproofed is an even better idea.