Search results

The speeds that you're talking about aren't really all that relevant. It could be that the SD card gets run in 1-bit MMC mode, which will mean 10Mb/sec or 900kB/sec. Or it could be run in 4-bit SD mode, which will mean 100Mb/sec or 9MB/sec. However, there's so much overhead involved, with the...

Hey there Rlyeh :) If I understand you correctly, you're asking for a few extra features: 1) Extra icon sizes: 48x48, 64x64, 80x80. I don't know about having varying sizes. In my (non-artist's) imagination, a file launcher where the icons had varying sizes would look a bit messy, and I'd...

I never said that Linux should be abandoned, just that my personal interest lies in getting stuff running on the raw hardware. I do see a pre-linux loader, something to replace U-Boot, but I always thought it would boot Linux by default (even, boot Linux immediately unless a specific button is...

one trivial thing, this is little-endian so the magic should be 0x3145584F or else someone looking at a dump of the file will see "1EXO"... or is that what you wanted?

Yep, that's all good. The app can be linked to start executing at the specified start address, the loader can stuff the header somewhere (maybe just ignore the icon data) and load the code etc sections at the specified start address and start executing it. In the original idea, I was quite keen...

OK, hit a little snag: remember that the icons aren't there until the app is post-processed by a elf2g2x sort of program, so they aren't there when the app is linked. Putting in a variable number of icons will cause a problem because it will move the .text section and the addresses won't work...

OK, a couple of little issues: 1) I'd forgotten about icon transparency, which we should support. We could just define a transparent colour (maybe max red, min green, max blue -> 0xF81F) or include a transparency map, which will be extra space (128 bytes for a 32x32 bitmap). How do people feel...

Quite likely this will all go down the drain once the 'official' SDK comes out, by the way :) Also might be good to avoid putting anything important in the first 4k of memory, as this is where the NAND bootloader's bootstrap code goes.

This is just a suggestion! I think it's a good idea to have a fixed format so that (for example) app launchers or file managers can display metadata about the files on SD. Inside Linux things are already defined, this is for apps that run outside of Linux. GP2X "Open Executable" format (name...

judge0 is closest to the truth, but a bit confused about cache :) If you're talking about the raw CPU, then there are two general-purpose ARM cores, a 920T and a 940T. The difference between these is indeed in the cache size (920T: 16k + 16k, 940T: 4k + 4k) and the fact that the 940T doesn't...

Oops! Sorry, I forgot to mention the media formats. Anything that can be played on Linux at the moment with an open-source player, can be played on GP2X if someone ports the player software. That is, there's no reason why you won't be able to watch your MPEGs, DIVXs, etc. There was until...

I think, DaveC, that your reply would have been more useful if you'd included the answers to your questions :) Secumax was used on the GP32 to "lock" a commercial game to either a specific SMC card or a specific GP32. A locked game could be copied from the SMC and distributed, but when copied...

Not sure if I've understoof the question right, so please forgive me if the answer is irrelevant :) I presume you're talking about your ARM gcc - in which case the more recent, the better. There's been many improvements over time, and now you have a choice of gcc-3.3.6 which is very mature and...

In my experience with closed TI DSPs, there's *nothing* anyone can do about us creating header files with register names and addresses in them, and making these available. That's not protectable information. For example, see this eCos port for the TI DM270. I fully intend to make standard...

Nice try iignotus, but you're quite wrong :) The CPU is a single chip, with dual cores - one is an ARM920, the other is an ARM940. These cores are very similar except that the 940 has smaller caches and it does not have a memory management unit. The CPU in the GP2X is the MMSP2 from MagicEyes...

Signed or unsigned doesn't matter, because they only differ if bit 7 is set, ie. if the signed number is negative / the unsigned number is >127. There are other rules though that govern characters that are acceptable for filenames, and the acceptable ones (in DOS anyway) are all less than 128...

Hmm... two processors... one dedicated to video... How about making Mesa3D run on the video processor, so that you effectively have a 3D accelerator? Quake 2 shouldn't be out of the question... That's one of the things I intend to look at, anyway. There's plenty to be excited about in this new...

OK, I've figured it out. You can prevent an unaligned access from causing an exception and crashing the GP32, but it still won't do the access the way you want it to. The flag you want is in the control register of co-processor 15. Look in appendix 2 of um_s3c2400x_rev1.1.pdf, which you can get...

Hey pea, You have got the byte order wrong - the GP32 is little-endian (although I think it can also do big-endian?). Also, the CPU can do unaligned 32-bit reads quite happily, but there's a flag in one of its registers that can be set to disable such accesses. You could look it up in the data...

Far from being our hard-working and slightly cranky GP32x mod, it seems that EvilDragon has been running a whole other life! Really, I have to say I'm a bit shocked. What next? Mr. Spiv a Columbian drug-runner? Rlyeh a South African diamond thief? Skeezix a Mafia hitman?