Sdk Released


A couple of really interesting pieces of info:

1) USB 2.0 as specified by GPH is USB 1.1 in the specs (as noted above, could be old specs)
2) Graphics co-pro is seperate from the 2nd core. GPH has always mainained that it IS the second CPU that handles this
 
2) Graphics co-pro is seperate from the 2nd core. GPH has always mainained that it IS the second CPU that handles this

Yes that is very cool! And I believe I saw Squidge say the same thing (which is why in my FAQ it says something similar) so it's been confirmed before. GPH did make it sound less impressive than it apparently really is. Which is always a nice thing. :p
 
Prophet posted on Sep 24 2005 at 06:22 PM said:
2) Graphics co-pro is seperate from the 2nd core. GPH has always mainained that it IS the second CPU that handles this

Yes that is very cool! And I believe I saw Squidge say the same thing (which is why in my FAQ it says something similar) so it's been confirmed before. GPH did make it sound less impressive than it apparently really is. Which is always a nice thing. :p

It may be a good idea to have someone else who knows this sort of stuff corroborate my interpretation before you make any changes to the FAQ though...

[Edit]
Actually, the introduction (setion 1.1 of the PDF) seems to make it pretty clear the two CPU cores are independent of the graphics processing units:
MP2520F incorporates a Dual 32bit CPU Processor, Video Processor, Video Post Processor, 2D Graphic Processor, Image Signal Processor and a variety of I/O peripheral components.
 
Last edited by a moderator:
iignotus posted on Sep 24 2005 at 06:23 PM said:
WOW, codesmith. A HUGE thanks goes out to you for that!
No problem :)

I was going over the specs this morning, thinking "wow, the picture in most people's heads is very different from what this thing is really like", so instead of wasting my time on Counterstrike I decided to write up a quick summary of the features.
 
Last edited by a moderator:
Thanks Codesmith... as you say, I certainly had a slightly different picture of what this thing's capable of going on. Sounds a good bit more promising now :)

Pity it doesn't do rotation outside of 90 degree increments, but hey, can't have everything (although from the looks of it, you can have quite a lot - looking forward to AC'97 audio :) )
 
hehe sounds really cool :)

j/k: a mpeg2 decoder, i want to connect my self powered usb dvd drive to the gp2x and watch movies on tv with 5.1 sound :)

PS: the funny thing is, this is theoretical possible :)
 
Using a custom-compiled Linux on this device seems for me the way to go: that way, you could use it for multiple purposes :) :

- as a remote desktop (attach USB keyboard + USB-SVGA adaptor + USB networkcable)
- as a streamium to play contents on the network (USB networkcable)
- as an EPG, electronic TV program guide (USB networkcable)
- as a webbrowser on the TV (USB keyboard + USB mouse + USB networkcable)

However, for this to function we need an more up-to-date kernel like 2.6 since this kernel contains device drivers for newer USB devices. I've been searching the archives up and down, and the only references to the SDK indicated:

- a 2.4 kernel instead of a 2.6 one;
- several closed drivers, so loosing several devices when using a 2.6 kernel.

What I'm interested in is knowing _which_ devices require a closed-source driver, and therefore will be lost when/if a 2.6-ported kernel will be available?

This is the same situation as with other devices, like the ASUS WL-500g (a LinkSys-compatible wireless router with USB) which I have: it runs 2.4 and needs closed-drivers for the wireless part :( , which makes it impossible to connect every device to it... Alas...

Knowing this will determine whether I think buying such a nice device will be worhwhile for me...

I guess:
- USB controller: probably standard, so probably open driver.
- CPUs: both open. Specs are all out.
The second CPU seems to be as powerfull as the first, but is missing an MMU
(which is required for Linux on SMP).
- GPU for 2D accelleration: closed
- Video-decoder: closed
- TV-out: closed (...but gplayer contained sources to enable TV-out)
- buttons: when connected to the GPIO: open
- more?

Anyone cares to share with us what parts are open, and which parts are closed?
 
with a totally open drivers, you could do much with this system. ok some things are not possible (like touchscreen).
Cant wait for the first linux geek ;) to get USB wifi working. i want to surf the web and play files of my pc in the living room...

PS: could you add later a line in to a console (or other things which are possible)?
 
codesmith posted on Sep 25 2005 at 12:18 AM said:
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.

Does this mean that communication issues aren't likely if we overclock? Also does it cut down heavily on CPU's sitting idle while the other one performs a vital task?

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

So sound playback potentially has minimal CPU usage? How much processing of sound stuff can be passed strait to the sound card?


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.

are there specific processing commands for each codec or is it a general purpose accelerator that is designed to use all the commands these codecs would demand and be future proofed for any codecs not out at release?

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.

I see a potential use of this. You could use FMV backgrounds with simple 3d models or sprites in front to create something along the lines of the Gamecube REmake or FFVIII (they all used fmv bg up until X but VIII has the heaviest use of it)

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.

potential usage for filters or some fancy scene transitions?

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.

I used to have this card....
 
Last edited by a moderator:
yes your right there's no reason to say that a final fantasy 7 style game couldn't be made using FMV backgrounds and basic 3d models....if they lowered the FMV resolution to fit the GP2x screen it would mean lots of video too ;)

Nothing to say a decent MORPG couldn't be made with a bit of work.....just need to get the thing using wifi support hehe
 
abigsmurf posted on Sep 25 2005 at 06:23 AM said:
codesmith posted on Sep 25 2005 at 12:18 AM said:
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.

Does this mean that communication issues aren't likely if we overclock? Also does it cut down heavily on CPU's sitting idle while the other one performs a vital task?

Well, since both CPU cores are part of the same chip, there wouldn't have been communication issues anyway :) but yes, this makes it possible to write distributed programs in a very efficient manner.

abigsmurf posted on Sep 25 2005 at 06:23 AM said:
codesmith posted on Sep 25 2005 at 12:18 AM said:
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 ;)

So sound playback potentially has minimal CPU usage? How much processing of sound stuff can be passed strait to the sound card?

Potentially, yes. If all the sound card does is play canned WAVs (explosions, samples in MODs, etc) then the CPU involvement is minimal. For echo effects, etc, I have no idea - I haven't done much sound programming so I don't know what the AC'97 spec provides.

abigsmurf posted on Sep 25 2005 at 06:23 AM said:
codesmith posted on Sep 25 2005 at 12:18 AM said:
Video Processor
Ah at 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.

are there specific processing commands for each codec or is it a general purpose accelerator that is designed to use all the commands these codecs would demand and be future proofed for any codecs not out at release?

The chapter on the video processor (chapter 13 on the PDF) is very light on details, basically just a feature list. I suspect this is one of the more proprietary parts of the chip, accessible only via closed device driver (not surprising since most of the supported codecs are patented - we're pretty lucky the hardware supports the formats, else we wouldn't be getting a player for them!). I bet the media player source code that came with the docs has more details.

abigsmurf posted on Sep 25 2005 at 06:23 AM said:
codesmith posted on Sep 25 2005 at 12:18 AM said:
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.

potential usage for filters or some fancy scene transitions?

Maybe, who knows? :)

abigsmurf posted on Sep 25 2005 at 06:23 AM said:
codesmith posted on Sep 25 2005 at 12:18 AM said:
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.

I used to have this card....

Actually, AC'97 is a hardware standard for sound cards, a bit like VGA is a hardware standard for graphics cards. Regardless of who manufactured the card, you know that register x is going to do the same thing. Very useful, I wish we had a similar thing with 3D cards on PCs...
 
Last edited by a moderator:
thanks for that detailed info, codesmith!
the sound chip looks to be very high quality, and it's great that the video processor is its own component instead of the second core!
 
Looks interesting, I wonder what capabilities are supported at the kernel level (for example the second CPU should be supported by the process/thread scheduler, so in order to use all one has to do is writing multithreaded apps...)
 
Regarding the USB 1.1 vs 2.0 issue.

I was looking at the mmsp2(gp2x SOC) dev kit on magiceyes (chipset manu) site:

http://www.mesdigital.com/english/Products...development.asp

and it has a big red block USB 2.0 type B device controller hanging off of the same line as the NAND flash, an IDE controller, Ethernet.

It also has a USB type B line coming straight out of teh SOC so that'll be the built in USB 1.1

then over on the left it has a USB type A straight out connected to mouse and storage so that's probably the 1.1 host mode.

So what does this mean for the USB on the GP2X ? USB client only ? Or USB 1.1 CLient & Host ? Or Outdated MagicEye Documents (as has been suggested) and all is USB 2.0 ?

Is there any official news that the USB will be host and client ?

Anyway it is a really nice picture, well worth a look. It also seems to show :
<_< a line in as well as 2 channel mic in to the AC97
:) the video Encoder outputting to TV, RGB Monitor, YPbPr to Difital TV
:p an IR reciever
:eek: a video decoder with TV and s-video input (chipset doesn't mention hardware encoding codec tho')

Much hope for enablement, much fuel for speculation.

------------------------------------------------------------------------
No man not helicoptors those are just crows circling
 
codesmith posted on Sep 25 2005 at 12:18 AM said:
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.

...  When people start mastering all the cool hardware in the MagicEyes chip, the gp2x is going to leave the GP32 in the dust.


Wow sounds cool. After reading this one thing kept popping into my mind:

SNES

:)


Sounds like alot of cool hardware to play with. I could see guys like Reesy, Squidge, Skeezix etc really getting into this.
 
Last edited by a moderator:
May I also suggest the MMSP2 Data Sheet pdf (line on right)

It is for the MM2520F MMSP2 is this the version on the GP2X pictures ?

http://www.mesdigital.com/english/Products/product_mmsp2.asp

In Short: it provides an improved block diagram, excellent descriptive breakdowns of all the blocks, I/O pin descriptions along with the signals and effects for each pin and finally DC and Capacitance Mix Maxes.

I am still downloading the previously mentioned files so apologies for any replication.

Interestingly enough MagicEyes use the MMSP2 for a PMP, an IP Set Box, DVD, DVR, Security Cam Interface but the dev kit for the Arcade Game Machine uses the VRender 3D chip which has more 3D stuff but less video stuff.

In the Key features it ststes that the 940T is a coprocessor used for Video Header Parsing and Video Post Processor Control (both processors are ARM9T the 940 just has less cache and it also suggests the 920T is used for Audio Processing - perhaps this is for encoding of recorder audio and video.

Excitingly it mentions a speech codec, 2 independant Hardware YUV video display overlays on the RGB graphic with 3 staged alpha blends, 6 level video mixing using two YUV sources + OSD [subtitles ?] & the RGN and a hardware cursor.

Those 4 Serial I/O Ports are pretty sweet too.

Oh my is that the time......
 
As a (hobby) developer... This is what I find interesting...

h.263 can be decoded at 352x288 at 30FPS, so it will work on the QVGA.

No max SD read or write speeds are listed.

Didn't read anything about hardware filtering for 2D acceleration.

Pixels are 32-bit including alpha. Colours can be 8-bit, 16-bit and 24-bit.

Dithering for 2x2 and 4x4 is supported.

Hardware cursor is rather 32x32 or 64x64

vSync can be disabled.

From what I previuosly understood, 1024x786 was the max res, but this indicatest that 2048x2048 is the max, depending on memory in the device.

TVOUT seports PAL and NTSC. that "other" one does not seem to be supported.


Has these Luminance Enhancments. Edge enhancement is the only interesting one. Also has auto exposure. These are all just image enhancements used while watching movies.

Sample rate upto 48kHz with upto 20bits a sample. for 5 channels. (AC97)
Sample rate upto 48kHz with upto 16bits a sample. for 2 channels. (IcS)

AC97 and IcS will not work at the same time.

1-Wire is the bus controller (as well as standby) and supports from 4MHz to 120MHz. I'm not sure what the Bus will be clocked at to begin with. or what multipliers are used.

DECSS is in there. I'm not sure if this means you can copy your vob files to your SD card and play them. But it seems to be very coupeled to the CD reader. So maybe not.
 
Back
Top