GP2X Any News Devs On Hh??


what exactly are the services linux provides in the background of a "normal" application?

also does HH (or HHB now, whatever) code need to be "relocatable"?

(not that it matters all that much for the second one, just wondering and trying to get an idea of the difference)
 
karmacop911 posted on Dec 1 2005 at 12:07 PM said:
what exactly are the services linux provides in the background of a "normal" application?

Linux provides filesystem support so you can load resources and save/load a save game file. It provides a thin layer on top of the framebuffer to access it. It provides memory management, multithreading (not that I'd recommend using that), and a decent api to allow portability.
 
Last edited by a moderator:
rhk posted on Dec 1 2005 at 08:01 PM said:
karmacop911 posted on Dec 1 2005 at 12:07 PM said:
what exactly are the services linux provides in the background of a "normal" application?

Linux provides filesystem support so you can load resources and save/load a save game file. It provides a thin layer on top of the framebuffer to access it. It provides memory management, multithreading (not that I'd recommend using that), and a decent api to allow portability.

oh, ok. that's helpful. (!sarcastic)

could an HH game access data from the flash drive without linux? like say, through the bios, or directly.

i have a bunch of other questions now, but i think i should probably open up a topic devoted to them when i get around to it.
 
Last edited by a moderator:
codesmith, we are already doing that, but not from early on in the linux init script, more like before the linux kernel is even loaded. After all, no point loading the kernel if your not going to use it :)
???

Now I'm really confused. I thought you needed Linux to access the SD card? (closed source drivers and all that...)
 
Last edited by a moderator:
HH is a small ball of wax, just waiting to happen. what it is, 'really', is an API without adherence to predictable, reliable standards, such as those offered by Linux and other kernels.

its one thing to link with the minlib; in point of fact, its a nice way to have control over the important aspects of the device (screen/control/sound), but to ignore the bonus of a kernel layer for such things as i/o management is to be a bit, shall we say, bold ..

and, well, why not. do whatever it takes to make the game play well; fortunately with the gp2x right now, 'tis a pretty even ground for us all .. the little machine runs well. i, for one, am happy of its power, used or not, so far ..
 
codesmith posted on Dec 2 2005 at 02:41 AM said:
codesmith, we are already doing that, but not from early on in the linux init script, more like before the linux kernel is even loaded. After all, no point loading the kernel if your not going to use it :)
???

Now I'm really confused. I thought you needed Linux to access the SD card? (closed source drivers and all that...)

Rob has written his own SD card drivers. They don't for all cards, but I'm sure we'll get there in the end. LCD and controls/etc work, so we are looking at audio and usb support now.
 
Last edited by a moderator:
Squidge posted on Dec 2 2005 at 02:14 AM said:
codesmith posted on Dec 2 2005 at 02:41 AM said:
codesmith, we are already doing that, but not from early on in the linux init script, more like before the linux kernel is even loaded. After all, no point loading the kernel if your not going to use it :)
???

Now I'm really confused. I thought you needed Linux to access the SD card? (closed source drivers and all that...)

Rob has written his own SD card drivers. They don't for all cards, but I'm sure we'll get there in the end. LCD and controls/etc work, so we are looking at audio and usb support now.

Sweeeet :D

Someone should contribute those to the U-Boot project, I was reading up on SD cards on other UBoot-based devices, and that is a major disappointment for most people.
 
Last edited by a moderator:
codesmith posted on Dec 3 2005 at 01:21 AM said:
Someone should contribute those to the U-Boot project, I was reading up on SD cards on other UBoot-based devices, and that is a major disappointment for most people.

Don't worry, when it works it will be very open and public. U-Boot will no doubt be informed about it. The drivers have some MMSP2 specific code but they could be made generic given time I am sure.

The one thing that does need cleaning up with HH is the SDK that is being written. That's comming along very nicely last time I saw it.
 
Last edited by a moderator:
DJWillis posted on Dec 3 2005 at 06:29 AM said:
codesmith posted on Dec 3 2005 at 01:21 AM said:
Someone should contribute those to the U-Boot project, I was reading up on SD cards on other UBoot-based devices, and that is a major disappointment for most people.

Don't worry, when it works it will be very open and public. U-Boot will no doubt be informed about it. The drivers have some MMSP2 specific code but they could be made generic given time I am sure.

The one thing that does need cleaning up with HH is the SDK that is being written. That's comming along very nicely last time I saw it.

who's in charge of writing the SDK?

from where is he/she (if it's not gph) getting their documentation?

i'm looking for low-level info on the gp2x. thanks...
 
Last edited by a moderator:
karmacop911 posted on Dec 3 2005 at 06:02 PM said:
who's in charge of writing the SDK?

from where is he/she (if it's not gph) getting their documentation?

i'm looking for low-level info on the gp2x. thanks...

Nobody ;),

HH is just a name coined to sum up what a few of us in #GP2XDEV have been hacking about with.

If you want low level docs on the MMSP2 they are hanging about in vairous places.
 
Last edited by a moderator:
If you want low level docs on the MMSP2 they are hanging about in vairous places.

and don't forget that the official ones have more bugs in them than a compost heap :)

So, use them wisely, but don't use them as the bible...
 
DJWillis posted on Dec 3 2005 at 06:29 AM said:
codesmith posted on Dec 3 2005 at 01:21 AM said:
Someone should contribute those to the U-Boot project, I was reading up on SD cards on other UBoot-based devices, and that is a major disappointment for most people.

Don't worry, when it works it will be very open and public. U-Boot will no doubt be informed about it. The drivers have some MMSP2 specific code but they could be made generic given time I am sure.

The one thing that does need cleaning up with HH is the SDK that is being written. That's comming along very nicely last time I saw it.

hey, the functions of the SDK could be importable into an assembly program, right?

the reason i ask is i would prefer writing direct ARM assembly program rather than C. (it is a personal opinion, so I hope C adherants wouldn't judge it.)
 
Last edited by a moderator:
karmacop911: Of course, all SDK functions will be "importable" into assembly projects. In fact, you can compile the SDK code with -S to generate the assembly output, and then hack away on the assembly files if you like :)

And I won't judge you, even though I believe that C is far superior to asm and only a masochist would choose to program in it if there were any option at all. Do you, by any chance, enjoy putting fish-hooks through your flesh? :D
 
torpor posted on Dec 2 2005 at 03:31 AM said:
its one thing to link with the minlib; in point of fact, its a nice way to have control over the important aspects of the device (screen/control/sound), but to ignore the bonus of a kernel layer for such things as i/o management is to be a bit, shall we say, bold ..

I'd agree with you from a general game development perspective, and as you said later it's up to people what they want to use on their own equipment. One interesting use though is using this hook to boot your own build of the kernel - one which doesn't take so long to load (turning off compression has been mentioned for example). Hardcoding some of the initialization has also been suggested as a way to cut out a good portion of the current startup time.

It's definitely interesting to be able to hook into the boot process at this level, even if you're not interested in a ground-up custom OS for the device.

Who knows, in the end you might be bold enough to reflash your device, when you've got your kernel booting properly! Then you can be more confident you're not going to brick it in the process.
 
Last edited by a moderator:
Squidge posted on Dec 3 2005 at 07:34 PM said:
So, use them wisely, but don't use them as the bible...

Bad analogy. The Bible has more bugs in it than... the MMSP2 documentation.
 
Last edited by a moderator:
Back
Top