GP2X Any News Devs On Hh??

[Digital Awakening]

HHH

Hardcore Hardware Hack

 

[Squidge]

TLA = Two Letter Ackronym

 

[karmacop911]

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)

 

[rhk]

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.

 

[karmacop911]

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.

 

[codesmith]

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...)

 

[torpor]

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 ..

 

[Squidge]

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.

 

[codesmith]

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

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.

 

[DJWillis]

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.

 

[karmacop911]

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...

 

[DJWillis]

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.

 

[Squidge]

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...

 

[karmacop911]

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.)

 

[Robster]

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?

 

[gfoot]

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.

 

[nickspoon]

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.