Gp2x Hardware Reference Manual

[xampi]

Why are demo coders not massively coding demo's for the GP2x and would a (e)book like the Amiga hardware reference manual for the GP2X change that?

I was browsing my old Amiga books this morning and thought that if there was a book like the Amiga Hardware reference manual or mapping the Amiga for the GP2x hardware the scene would evolve.


Please give your opinion.

 

[Squidge]

It already exists and has done since the gp2x was released. Anyone is free to ignore linux and hack the hardware directly, but very few people actually do.

If you look at the HHSDK, it includes a lot of functions for accessing hardware directly, and if you look at things like HWSDL, it contains hardware access functions to blitting for example.

 

[Unfathomable Depths]

Ive just been bumbling along on C and SDL. Any chance of a link to something that has the hardware spec and system calls?

Sorry in advance for being lazy...

 

[Squidge]

http://wiki.gp2x.org/wiki/Docs_and_Papers

 

[Unfathomable Depths]

Cheers Squidge

Thats my late night reading sorted.

 

[Dzz]

Speaking of the hardware, does anybody know how to get at the i2c memory in the newer firmwared? /dev/i2c-0 doesn't exist any more.

More specifically I'm trying to get the serial number.

 

[rlyeh]

Speaking of the hardware, does anybody know how to get at the i2c memory in the newer firmwared? /dev/i2c-0 doesn't exist any more.

More specifically I'm trying to get the serial number.

Here's my own implementation:

CODE

typedef struct { unsigned char id,addr,data;} i2cw;
typedef struct { unsigned char id,addr,*pdata;} i2cr;

void gp2x_i2c_write(unsigned char addr, unsigned char data)
{
i2cw a = {.id = 0x8A, .addr = addr, .data = data};
ioctl(handle, _IOW('v', 0x00, i2cw), &a);
}

unsigned char gp2x_i2c_read(unsigned char addr)
{
unsigned char temp;
i2cr a = {.id = 0x8A, .addr = addr, .pdata = &temp };
ioctl(handle, _IOW('v', 0x01, i2cr), &a);
return (*a.pdata);
}




btw, handle is handle=open("/dev/cx25874",O_RDWR);

dunno if that i2c functions will work for any address or only with cx25874 encoder ones

have fun

 

[Dzz]

Thanks rlyeh, i did try that (having found your code via google), but couldn't get it to work (all addreses returned the same value). I'll give it another shot though, maybe I did something wrong.

 

[HenrikE]

I think I understand what xampi wants, since I'm from the Amiga scene myself and Amiga H.R.F. was written by my old boss, Jez San. 'Tis a well written piece because it's clear, concise and complete, and both list the hw stuff AND has overview and asm examples written by someone knowing the entire machine. (Jez didn't write all of it though.)

There's "showing inputs & outputs" and there's "insightful well-written descriptions showing how it all works together with smart tips and tutorial applications" -- if you know what I mean.

This is absolutely something close to my heart and I would love to see a "learn GP2x hardware inside and out" dedicated homepage. That's why I started code2x.com.

Will take at least a month before anything's up due to current obligations. PM me if you have that insight and want to contribute articles when it's up.

 

[Squidge]

I seem to remember also that although the AHRM was clear, concise and complete, it was also full of typos and errors. I remember a couple of us working on code using the book as a reference, and it wasn't exactly simple!

 

[Orkie]

This is absolutely something close to my heart and I would love to see a "learn GP2x hardware inside and out" dedicated homepage. That's why I started code2x.com.

What's wrong with the wiki?

 

[Dzz]

Thanks rlyeh, i did try that (having found your code via google), but couldn't get it to work (all addreses returned the same value). I'll give it another shot though, maybe I did something wrong.

Well, I tried all id and address combinations; it seems the only id that works is 0x8A, and all addresses for that id return 0xC3, which is apparently a device id of some kind. Oh well. Maybe I can try hacking into gp2xmenu to see how it gets the data. That will be pretty hideous.

Sorry to derail the thread, but if somebody is making a hardware reference manual, please put the answer to this question in it

Edit: looks like the best bet is to do the i2c protocol directly, which is a bit tedious but should be doable.

 

[xampi]

@ Squidge

Yes you are probably right and for a GP2X Guru like yourself the SDK maybe enough. But, for someone like me who is learning C and some ARM assembly more information about the SDK or a hardware reference like the one for the Amiga is welcome, it's exactly like Henrik Erlandsson wrote
 
There's "showing inputs & outputs" and there's "insightful well-written descriptions showing how it all works together with smart tips and tutorial applications" -- if you know what I mean.

I can't wait to see the code2x.com or a website like it online!

take a look here for the Amiga Hardware Reference Manual online
http://pub.elowar.com/AmigaDev/Hardware_Ma...e/node0000.html

I know it's not perfect, but it has help a lot a Amiga coders in the good old days.

 

[Squidge]

Never knew the Amiga HRM was online in a HTML-format - maybe someone should try and create an Amiga emulator from scratch using it.

(yeah, I know, not going to happen)

 

[HenrikE]

Well, the Wiki is a gold mine for the reference stuff and very much needed. But it's a too big step for many to take on the entire chip set and learning how they all interact, and then spend a bunch of time experimenting with their great hardware-close routine that will boost performance.

An idea + having fully understood the reference texts doesn't = working code at all times in the low-level world. Some give up and go to the high-level world, where just correcting the code until it compiles error free and if there's a bug at runtime, look at values (watches) to instantly find the error. (Also, if you want, you can use hw abstraction layers and save tons of code writing. But that's not what turns me on.)

code2x.com won't be only tutorials, sorry if it sounded that way. I'll keep the other features to myself until the site is online, cos I hate promising stuff beforehand. I'm making it to promote my (non-evil, promise!) agenda, it's my responsibility to draw people to it and configure the required components for the site.

One thing site won't have is a full forum. It's better to have that stuff concentrated in established, active forums like this one. (I.e., better with 1 forum where a question or idea gets replied to within hours than 10 forums where you're lucky if you get a reply at all.)

 

[rlyeh]

Edit: looks like the best bet is to do the i2c protocol directly, which is a bit tedious but should be doable.

from what i remember i've done that too. i coded a kernel module for my sdk and i added i2c support there
would you like it maybe?

 

[Dzz]

Edit: looks like the best bet is to do the i2c protocol directly, which is a bit tedious but should be doable.

from what i remember i've done that too. i coded a kernel module for my sdk and i added i2c support there
would you like it maybe?

It's possible that this would help, so thanks!. I got kind of obsessed by this and coded my own i2c functions yesterday but I cannot get any device except 0x8A to acknowledge its address on the i2c bus; it's like the eeprom at 0x50 isn't even there (I tried all addresses). You just do the START sequence, then the sequence putting out the device address, and if somebody matching it is there, they will acknowledge, but it just isn't happening. I wonder if there might be some other GPIO line needed to "enable" the eeprom, or if maybe the MMSP2 SDA and SCL lines are not the right thing to use for the eeprom. I tried looking at the 1.4.0 source off of the SVN server but I cannot track down the code where the driver actually twiddles bits; either that code is missing or I'm just not very good at looking through kernel source. Finally I tried disassembling and staring at the gp2xmenu program but that's like looking for a very small needle in a very large haystack, which will take me many hours. I'm about ready to give up, so any help would be appreciated.

 

[Dzz]

Oh, actually, all I really want to do is identify whether a unit is a Mk1, so that I can adjust colors in my game to compensate for the differences in the LCDs. I did try putting identical firmware versions on a Mk1 and a Mk2 and reading all the mmsp2 registers that might relate to the LCD in hopes that somehow there would be a difference, but they are identical. The serial number would work because the date part will have a certain range for the Mk1s.

Worst case I can just have the user choose which color mode they want, but I'd like to default to the "right" one instead of being wrong on half the machines at startup.

If somebody has a brainstorm about a different approach to telling a Mk1 from a Mk2, that would be super keen.

 

[Orkie]

Allegro segfaults on MK2s unless you do a dummy blit first. Maybe you could exploit that somehow?

 

[Squidge]

I noticed a lot of my test programs either don't work at all, or totally freeze the system on a MK2, but work perfectly on a MK1, and I've no idea why (same firmware on both).

Quite strange!