Sdk Released


Well, seplus.com is working for me, but anyway, the files have been mirrored @ gp32spain public ftp. (and probably somewhere else soon). Access at:

FTP: ftp.gp32spain.com
User: public_ftp@gp32spain.com
Password: publico
Path: /Programacion/GP2X
 
w007!

I pledge my support. I have no experience with the low level chip/hardware hacking stuff, but as soon as that's done, I will be contributing to the higher level functions of the SDK (graphics, math, physics and other routines).

Bring it on!
 
its doesn't affect those with NDAs obviously otherwise this thread would have revealed alot more....i wonder how many people have actually read this thread lemmie check hehe!
 
pea posted on Sep 23 2005 at 07:10 AM said:
WHy would someone fake a 300+ page chip specification pdf document? :blink:
And why would GPH tell someone to go to a fake document? This looks real, and I'm sure it's real, but they won't tell us..
Maybe the docs weren't intended to be released.. but GPH wants to do it and assume the consequences from MagicEyes..

Or maybe it's a mad plan to attract consumers..

There's some good information in the Gplayer code, such as how the TV-out is controlled via Software.. and there's also the .DOC file showing how to update the kernel.. of a FINAL CONSOLE (you can see it on the picture) with the EXT port and a serial adapter..
 
Last edited by a moderator:
On no! The docs were leaked! Magic Eyes will be mad, but now the Gp2X will end up being even better as a result and more GP2X's will get sold, and more Magic Eyes chips will get purchased as a result!

A winner is everybody!

Oh no! ;)
 
Ultimately it's up to the devs to use this stuff, it's pointless for a non-dev like me. All I can do is sit back and hope that this increases the speed and quality of the applications currently in the works.
 
Alpha2 posted on Sep 24 2005 at 05:47 PM said:
Ultimately it's up to the devs to use this stuff, it's pointless for a non-dev like me. All I can do is sit back and hope that this increases the speed and quality of the applications currently in the works.

Could someone who isn't a dev but has the knowledge not give a run through the pdf's and comment on what they feel is posible and not?
That would be nice....... :D
 
Last edited by a moderator:
the devs are all being tight lipped on this one - NDA or not.

But release is just around the corner now. Weeks to go, not months... Hurrah!
 
well...1 months! i can't wait...i should stop visiting this site and do something else haha
 
Alpha2 posted on Sep 24 2005 at 06:32 PM said:
huh?
why would anyone with the knowledge not be a dev?

Is that 'Huh?' as in shut up newbie?
My question is pretty clear. If you don't take me completely literally you'll see I'm asking discreetly if anybody can comment on the pdf's.
Thanks for the friendly feedback though..... :)
 
Last edited by a moderator:
there's plenty of people with lots of technical knowledge who could get some juicy info from that but don't wish to spend loads of their free time devving (taking your job home etc.).

Wether or not they'd want to trek through the whole SDK just for some tidbits of info on the otherhand...
 
No, that was 'Huh?' as in I don't get it.

But I guess abigsmurf has a point, it'd probably take more than just a few minutes for someone with technical skill to tell if it's more useful than the SDK that comes with the 2X and probably rather let actual developers be the ones to look into it. If they decide to be silent we can only assume one of two things

1. It's worthless and not worth talking about

or

2. It's stuff that's very useful but they just can't talk about it for one reason or another.

I'd like to thnk it's 2, and that all this silence means cooler stuff at launch then I would have imagined... I'd LIKE to but I wont. I'll just sit back and accept what we;re given in this case, I can't do anything more than that without setting myself up for possible dissapointment.

I'd rather expect nothing than be either suprised or uneffected than get my hopes up too high and risk being dissapointed.
 
A lot of information can be extracted from the CrystalEyes pdf in that docs.zip archive. I can comment on it all I want since I'm not an official developer so I'm not under any kind of NDA, but on the other hand I've never touched the actual hardware, so a lot of what I'm saying below depends on exactly how the chip was connected into the gp2x. All the pdf reveals is what *might* be possible, what is actually possible depends on how the chip's wired into the gp2x - that chip has a ton of hardware packed into it, and we know that some parts of it (eg the touchscreen controller) are not used by the gp2x, so it's possible that anything else could also be unused by the console.

That said, I'm going to go through the chapters one by one, briefly explaining what the chapter describes and (if it is wired in for use) how it could be used by gp2x programs. Note that it is also possible that a feature could be wired in, and yet be unsupported by Linux. This is a much lesser problem, since although it means that the feature won't be usable initially, the more talented community members should not have a hard time figuring out how to make those features available for general use after some experimentation. Note that I'm writing this for the more "layman" type reader, so if my tone sounds a bit condescending in places please note that not everyone knows as much as you do.

Note also that this is only a best guess based on my experience with PCs and (lesser) with digital electronics. There's a definite chance that I majorly goofed on some or all of my interpretations of the docs, so if anyone feels that I'm wrong, please go head and correct me (I dare ya! hah!)

OK, here we go:

Memory controller
This seems to provide a maximum of 512MB of SDRAM storage, meaning that there's room for expansion there for those with steady hands. There is also support for static memory (SRAM), this is probably where the flash appears on the memory map. Since the memory bus for this memory area can only be 8 or 16 bits wide, it may make sense (for the sake of performance) to use the Thumb instruction set for programs that run off flash, similarly to the GBA. This is simply a matter of passing a slightly different command line to gcc, so it's not a bit deal.

Dual CPU Interface
This chapter is a bit light on information... it doesn't say how to manage the two CPUs, but it describes how the CPUs can access each other's data, and it describes a very cool section of the chip that allows the two CPUs to communicate with each other using interrupts (this means that both CPUs can be running at full bore, then if one wants to communicate with the other it figuratively taps the other one in the shoulder and says, "hey, here's some data for you". The receiving CPU then can deal with the data and keep doing what it was doing before. This can be very useful for emulators since one CPU can be dedicated to emulating the CPU while the other is doing the emulated chipset, and the two parts of the emulator can run independently of each other, only interrupting each other when neccessary.

Clocks and Power Manager
This chapter describes several internal clocks the chipset has, which are used to keep data flowing in an orderly manner across the different subsystems of the chip, and also the power management features. The clocks are cool in a beanie-hat sort of way, but the power management has some interesting features: the system can be put in several low-power modes (useful for alarm-type applications, where the gp2x can be put in standby mode until a timer wakes it up and it reminds you to do something; there is also a low-battery interrupt, meaning that if the batteries are running low, the user can be alerted or some sort of hybernation mode can be programmed in.

Real Time Clock
This chapter describes the built-in "human time" clock (hours, minutes, seconds). It's a farly standard clock, has a resolution of 1/1024 second and a built-in alarm which, instead of triggering a buzzer, signals the CPU so it can take whatever action you program in. There are also some advanced features but I doubt they're used in the gp2x.

DMA Controller
A DMA controller allows parts of the hardware to talk directly to other parts without using the CPU. The multi-channel DMA controller in the gp2x has many advantages:
  • Using the DMA controller is usually faster than the CPU
  • Since you're not using the CPU to transfer data, it can be doing other work while the transfer is happening
  • The DMA controller is wired to also allow transfers from memory to memory, so copying large blocks of memory around (eg pictures from a buffer to the screen) can be done very efficiently
  • Several of DMA transfers can be taking place simultaneously, eg loading data from SD, playing a tune, copying a data buffer and CPU calculations can take place simultaneously without any annoying glitches.
Interrupt Controller
The interrupt controller manages the "pecking order" when several devices need the attention of the CPU, and how the CPU responds to these requests. It looks pretty standard, except that it seems a lot better than the one built into desktop PCs ;)

Timer/Watch Dog Timer
Another timer... this one is usually used by industrial system and robots. The main purpose of a watchdog timer is to give the program a swift kick if it's taking too long to do something, ie it is used to prevent hangs from causing problems (imagine the program driving a robot arm hanging in the middle of a maneuver, right before the call to stop the motor...) It could be used by the gp2x to drive animations, detect double-clicks and other similar things.

UART
Used for serial communications (RS-232 and the like). This is probably exposed by the EXT port. Has some advanced features like a DMA mode and infrared.

General Purpose IO (GPIO)
This is a set of pins on the chip that are left for use by the hardware it's soldered to. I strongly suspect the buttons, D-Pad and maybe the battery LED are connected to GPIO pins. The GPIO system can be programmed to trigger interrupts, so the buttons won't need to be polled all the time - this means it's possible to write a program that doesn't miss button presses even if it's really busy.

Video Processor
Ah, we start getting to the fun stuff. Note that this "video processor" seems to be totally unrelated to the second ARM CPU core, ie as far as I can tell, it's a separate, dedicated piece of hardware. Loads of technical info here, but it all boils down to this: hardware-accelerated decoding for MPEG1/2/4, JPEG, VCD, DVD, DivX (up to version 5 and Xvid. There is also a hardware-accelerated *en*coder for all those formats but since the gp2x doesn't have video-in (maybe in the EXT port?) that part is probably unused.

Video Postprocessor
Again, this doesn't seem to be the second ARM core, but a section of the chip dedicated to messing with image data. It gives you the following, all hardware accelerated:
  • Scaling, using pixel skipping (quick but pixelated) or filtering (slower but smooth)
  • Rotation (only in 90 degree increments though)
  • Mirroring (horizontal or vertical)
  • Alpha blending (transparency)
  • Picture-in-picture, 5 different regions, each has its own scaling and transparency setting
  • On-screen display (like closed captions), in 4, 16 or 256 colours
  • Adjusting Contrast, Brightness, Hue, Saturation, Dithering, and Gamma correction
  • Hardware cursor (one hardware sprite), 32 bits per pixel, 64x64 pixels
The video postprocessor also allows for colour keying (think weather map and weatherman on the news), but since I doubt the gp2x has video in this is probably unused.

Display Controller
This is the part of the chip that sends all the appropriate control and data signals to the LCD screen.

2D Graphic Accelerator
This implements the requirements for a 2D Graphics Accelerator as defined by Windows CE. This means hardware accelerated image copies with optional binary operations (bit blits) and rotation and accelerated text rendering, as well as solid colour and pattern fills of rectangular regions. Patterns are 8x8 pixels in size. Blits allow the stride, or modulo, to be specified so cool demo ripple effects are possible :)

Image Signal Processor
This implements a lot of realtime image processing algorithms, which are clearly intended for digital cameras (it has things like autofocus and autoexposure). I suspect this is another feature that only makes sense for video in.

Pulse Width Modulator
This generates pulses of different widths and frequencies. I doubt it's connected on the gp2x. If it's exposed on the EXT port, it would make the gp2x a very cool robot brain (pulse width modulation is a very popular technique for controlling the speeds of electric motors, eg on the wheels of a robot)

Pulse Period Measurement
This is the inverse of the previous feature, given a pulse train this measures it. Again, it's useful for things like robotics to implement things like speedometers.

USB Host/Device
This is what implements USB on the gp2x. This part has an interesting contradiction: According to gpx2.com the gp2x is advertised as having a USB 2.0 interface, while the chipset docs say it's USB 1.1. Both those statements cannot be correct at the same time. Given that the pdf is about a year old, I suspect it's out of date. Other than that, the USB controller can behave as a device or host, and it supports normal and bulk USB data transfer modes (not isochronous? well, it's not a webcam so it's not exactly a big deal ;)) and can use DMA.

I2C
This is a bus that is used by chips on a computer to talk to each other. The gp2x propably uses it internally, and it may be exposed on the EXT port, other than that, nothing to see here folks...

SPDIF Controller
This is used for high-end digital audio. Doubt it's connected in the gp2x (maybe in the EXT port?)

AC'97
This is the part that generates audio, it's just like the one that most PC motherboards have built into them, so there's loads of information out on the web about it. It supports 5.1 sorround sound, stereo and mic in, 16 to 20 bit samples, and has a DMA mode. Unlike the chipset in PCs, it does not have support for modems however.

I2S Controller
This is a bus for transferring audio data. The docs say that it's not possible to have that and AC'97 simultaneously, and we know the gp2x uses AC'97, so this is in all likelihood disabled.

SSP/SPI
Another inter-chip bus. See I2C

Transport Stream Interface
Not 100% sure what this does, it seems to be a bus for MPEG2 video data. Probably used by DVD players, most probably not used by the gp2x.

ADC & TPC (Touch Panel Controller)
This is not used by the gp2x (no touchscreen!)

SD/MMC Controller
This is the part that enables reading and writing to SD cards. It supports memory and SDIO cards, and can do DMA transfers.

Memory Stick Controller
Yes folks, this chip has a Sony memory stick controller. Unfortunately, unless the gp2x's socket allows more than one type of card to be plugged in, this is unused by the gp2x.

CD-ROM Decoder
Another part of the chip that is unused by the gp2x.

1-Wire Master
Yet another chip-to-chip bus. See I2C

DECSS
Used to decode DVDs, if you happen not to know any bright Norwegians. Unused by the gp2x.

Well, there you have it. If I were to compare the GP32 to the GP2x, I'd say that except for raw CPU speed, the transition should be about the same as going from C64 to Amiga. When people start mastering all the cool hardware in the MagicEyes chip, the gp2x is going to leave the GP32 in the dust.
 
Back
Top