open2x-devel Mailing List for The Open2x Project

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

  Hi, all.

  I've got open2x libs build scripts from http://x11.gp2x.de/openwiz/openwiz-toolchain-161208.tar.bz2 which I patched for libconfig building.
  May be this is useful for somebody.
Hello everybody.

I suppose everybody has noticed. Few days ago the wiki started to fail with
a db problem.

Is it a big problem?

Thanks in advance.

Hi.

Some mothns ago I started the developing of libDecoder, a simple video
decoding library that uses FFMPEG. The main goal is to get high
performance on low-end machines.

The project is hosted on SourceForge
(http://sourceforge.net/projects/libdecoder) and the current code is
available in the SVN.

I have made some tests on the GP2X and the performance is just "good".
I need to implement some optimizations for the GP2X (like YUV hardware
acceleration, hardware scaler...) to get videos working at fullspeed.

I think this project could be a good video player for the Open2X
firmware but I need some help to finish it because I don't know too
much about how to use the GP2X hardware. Anyone has some free time to
waste in this project? :P

I hope I can finish this project ;)

Greetings,
Miguel Bot=F3n.

Subject: Re: [Open2x-devel] suggestion to use OpenEmbedded for Open2x
> Due to the fact that I will start working with OE and that my hobby is
> developing / porting Games for GP2x, this sounds like a MUST for me.

OpenEmbedded is a huge, ported tree, of linux applications wrapped up  
in a highly sophisticated build system which requires the maintenance  
of files using new and interesting tools to keep it all working and  
together.. the build system is tailored to smaller configurations of  
course, but factually targets many devices.

It is not a light build kit, however; you gotta learn new tools that  
do things 'better' than the tools you probably already know how to  
use, well enough.  This can be a huge distraction for someone who  
wants to get stuff done.

But fortunately, if you write your app for Linux, and obey a few  
simple rules about your library usage using the autotools, you can be  
sure your package will compile and run under OpenEmbedded fairly  
well.  It is nice to have so many libs available, and the package  
maintenance system which lets the user choose how much to ignore  
library/system dependencies is valuable, if a bit sketchy at the  
moment.  There is a security risk, also, with the issue of open and  
public feeds. As always with Linux of course.

It is quite simple to make a 'recipe' for OE, if your app is well- 
behaved linux-wise anyway.  Whether it looks good when it runs on the  
device is up to you (and your code) and your own tests too, of  
course, but there is little independence and lots of dependence in  
bundling along with such a large, built base, of linux OS.

GP2X support would be trivial.

Running OE the GP2X becomes a 'small linux workstation', with all  
those bells and whistles.

At least, with the gta-02 device due in december (where i'm running a  
fork of OE called OpenMoko) there is also talk of having normal 'X'  
services, as well as compiz/beryl/etc. running, already.  so you just  
bump your PDA and the window flips its box, etc.  lovely stuff.

but beware: as such, OE is rather full of cruft, and can be very  
frustrating to maintain if you don't learn a larger toolset.  bitbake  
is not your daddies make!

All that considered, I still think the value of open2x being a  
completely easy and simple makefile-oriented system to tune things  
really to the GP2X, and not so much 'keep up with the distro- 
joneses', should not be overlooked.  The GP2X coders I know, anyway,  
would well benefit from just having their own, bootable, Linux distro  
straight on the SD card, with the bare libs required to do the GP2x  
magic, and their app too, of course.  Remember: the GP2X has an  
application-mode of 'single use/single app', also, and this mode *is*  
supported by the hardware.  {SD boots..}

;

;
--
Jay Vaughan

On Monday 10 September 2007 13:54:40 Robert Schuster wrote:
> Hi Anes,
>
> > Thanks for your post. It sounds interesting.
> > I always thought OE is used to build Apps /Programs for Embedded
> > Devices(especially used in the Automotive Sector, like Controllers etc)
> > which are not controlled by an Operating System.
>
> No, OE is used to built distributions for PDAs, consumer NAS devices
> (Linksys NSLU2), dozens of debug boards, the Gumstix devices and
> whatnot. What all of them share is that they run Linux as the kernel.
>
> > Are there any real examples (compilable, installable and runable) for OE
> > and GP2X ?
>
> No. Not anymore. I wrote the mentioned OE article in 2005 and built
> nano, screen, gnu classpath and jamvm back then.
>
> There are two historical pictures of JamVM running on GNU Classpath:
> http://fsfe.org/en/fellows/robertschuster/images/gp2x_2006
>
> If I find the time I will write a quick distro config which can compile
> application that are compatible to Open2x.
>
> Best regards
> Robert

Hi Robert

Thanks for you quick answer and the provided information.

Due to the fact that I will start working with OE and that my hobby is 
developing / porting Games for GP2x, this sounds like a MUST for me.

Best regards
Anes

Hi Anes,

> Thanks for your post. It sounds interesting.
> I always thought OE is used to build Apps /Programs for Embedded=20
> Devices(especially used in the Automotive Sector, like Controllers etc)=

> which are not controlled by an Operating System.
No, OE is used to built distributions for PDAs, consumer NAS devices
(Linksys NSLU2), dozens of debug boards, the Gumstix devices and
whatnot. What all of them share is that they run Linux as the kernel.

> Are there any real examples (compilable, installable and runable) for O=
E and=20
> GP2X ?
No. Not anymore. I wrote the mentioned OE article in 2005 and built
nano, screen, gnu classpath and jamvm back then.

There are two historical pictures of JamVM running on GNU Classpath:
http://fsfe.org/en/fellows/robertschuster/images/gp2x_2006

If I find the time I will write a quick distro config which can compile
application that are compatible to Open2x.

Best regards
Robert

On Monday 10 September 2007 12:42:00 Robert Schuster wrote:
> Forgot the link.
>
> > I was stumbling through the gp2x Wiki in order to rip some sentences
> >
> >>from my old OpenEmbedded article[0] therein.
>
> Regards
> Robert
>
> [0] -
> http://wiki.gp2x.org/index.php?title=OpenEmbedded_GP2X_development_environm
>ent

Hi Robert

Thanks for your post. It sounds interesting.
I always thought OE is used to build Apps /Programs for Embedded 
Devices(especially used in the Automotive Sector, like Controllers etc)
which are not controlled by an Operating System.
Are there any real examples (compilable, installable and runable) for OE and 
GP2X ?

Best regards
Anes

-- 
Herr/ Mr. Anes Lihovac

Steinkaul Str. 40
52070 Aachen
Email: ane...@we...
Tel.: 	     + 49 241 99 76 313
Mobil(e):+ 49 178 52 50 782

Forgot the link.

> I was stumbling through the gp2x Wiki in order to rip some sentences
>>from my old OpenEmbedded article[0] therein.

Regards
Robert

[0] -
http://wiki.gp2x.org/index.php?title=3DOpenEmbedded_GP2X_development_envi=
ronment

Hi,
by coincidence I just found that Open2x is for real now. :)

I was stumbling through the gp2x Wiki in order to rip some sentences
from my old OpenEmbedded article[0] therein.

When I was planning to build my first software for the GP2X back in 2005
a good friend told me about OpenEmbedded. Since that time I was trying
to understand it and make use of it. My cross-compilation knowledge was
minimal at that time and so understanding the OE specifics was very hard
for me.

But being persistent paid off: I read a book about Linux embedded
development, looked at other cross-compilation suites (buildroot,
freewrt) and nowadays I am doing many of the OE related tasks in the
company I work for. :)

Mastering OE allows us to conveniently build packages for all
distributions that are derived from it like Angstrom and OpenMoko (Not
to mention all the devices that they support).

AFAIK OpenEmbedded is the most flexible approach for doing
cross-platform development. The repository contains build recipes for
around 5000 packages. You are able to quickly replace crucial parts of
your distribution like glibc with a minimum of effort (just change the
preferred version number). It is also possible to customize recipes for
your specific device.

Furthermore you can profit from the advancements of the other OE-based
distributions: Eg. if Angstrom maintainers add a patch to fix an issue
in glibc you get that, too. If they add the recipes for X.Org 1.3
(already done) you can build that package, too.

=46rom the Wiki: "Open2x uses a modified version of the buildroot scripts=
 .."

Rather than forking and modifying someone else's project over and over
again, OE lets everyone do whatever they want but share a common build
environment and package recipes at the same time.

------

If you do not see value in this or think that you are better off
maintaining your own cross-compilation suite that is perfectly OK for
me. I could not help the Open2x project in other ways than contributing
to OE (which ultimately helps all derived projects).

For me it is a lovely vision that a game-centric project like Open2x
would enter OE development and care about the game packages. :)

Best regards
Robert

Hello,
   I just recently noticed that DR2 has some palette problems with Wind and 
water, in both the compatibility mode and normal. I'm not sure if this could 
be related to my similar problems with palettes in Wolf3D, due to the fact 
that I'm not sure if W&W is 8bit or 16bit.

Just a heads up
   TJ Hooka

Hi, 

I am developer, and I would like to know, if it's possible you give me a
open2x developers release.

I really need this because I have a Project in my hands very complicated.

Any question, please email me.

Best Regards,

Filipe Pinho

Dear All

JyCet (via GP32X forum) recommend me to use Open2X for my GP2X.

I realize that Open2X use diferent kernel version from vanila firmware.
So i think i need to know more about it before i jump into it for
development.

Here is my question :

1. Moving back to GPH's Firmware : How is the process ? will it just the
same easy process moving from one GPH firmware to another GPH Firmware ?

2. STERM. Is there any something like STERM that can run with Open2X
firmware ?

Just to inform you about what I want to do is to Turn GP2X tobe a simple MDT
(mobile data terminal), means that i'll need to (at least) :
1. Port PPP. GP2X have to be able to connect to my app server via GPRS
2. Porting (or Find some thing that act, and easy scripable as) "dialog"

Kindly please give me your enlightment

Sincerely
-bino-

Hi Matt,

Sorry for the late response.

>I still have not been able to get the FDC to respond no matter what I send 
>to it.  So I decided to try a different approach and have the 2nd CPU (940)

>convert the YV12 surface to YUY2 for me.  This has proven pretty successful

>and I have also got hardware blitting working to speed up copying the 
>converted YUY2 surface from the 940 to the place where SDL wants the YUY2 
>image (it would be even cooler to not have to do this copy at all but that 
>is an optimization for the future).

That's a real shame about using the FDC. I guess we will have to put that
idea to one side until we better understand it. Anyway, onto the 940 MPEG
lib, in a few simple words, really sweet :). Running the YV12 conversion on
the 940 is a great idea. Out of interest how close is the lib to the
original API's? Just pondering reuse in other apps. 

>I am currently able to get about 30 FPS (ie full speed) using a very low 
>bitrate 320x240 mpeg1/mpeg2 file (250kbps-500kbps), with the mpeg decoding 
>and YV12->YUY2 conversion all being done on the 940.

That is very credible performance, I assume that is an all C implementation,
is the YV12>YUY2 conversion code also C, would it benefit from some ASM
work?

Regards,

John Willis

On Jul 20, 2007, at 9:26 PM, U. N. Owen wrote:
> I am currently able to get about 30 FPS (ie full speed) using a  
> very low
> bitrate 320x240 mpeg1/mpeg2 file (250kbps-500kbps), with the mpeg  
> decoding
> and YV12->YUY2 conversion all being done on the 940.
>

Nice one U.N. Owen!  :)

j.

It was a plain build order problem. The problem gets solved by 
reordering the linker inputs. I wasn't aware that object code (here: 
main.o) adheres the very same rules when trying to link with libraries.

Thanks goto Lithosphere who started to dig in the right hole and brought 
me on the right path.

# compile statically
$ /opt/open2x/gcc-4.1.1-glibc-2.3.6/bin/arm-open2x-linux-g++ 
`/opt/open2x/gcc-4.1.1-glibc-2.3.6/bin/sdl-config --cflags` -I./src 
-I/opt/open2x/gcc-4.1.1-glibc-2.3.6/include ./tests/001/main.o 
-lSDL_Config -lSDL -lpthread -static  -L. -o test1.gpu

(note the main.o appearing before the -lSDL_Config)

StarG

StarG schrieb:
> I tried to get those libs compiling and it seems it works for the first 
> one. When i'm trying to link this created library it fails with 
> "unresolved symbol" linker errors.
 >
 > (...)
 >
> This works fine and creates the library. Now i try to build a supplied 
> test program.
> 
> # compile statically
> /opt/open2x/gcc-4.1.1-glibc-2.3.6/bin/arm-open2x-linux-g++ 
> `/opt/open2x/gcc-4.1.1-glibc-2.3.6/bin/sdl-config --cflags` -I./src 
> -I/opt/open2x/gcc-4.1.1-glibc-2.3.6/include -lSDL_Config -lSDL -static 
> -L. ./tests/001/main.o -o test1.gpu
> 
> this dumps a lot of errors:
> 
> ./tests/001/main.o: In function `main':
> main.cpp:(.text+0x84): undefined reference to `CFG_OpenFile'
> main.cpp:(.text+0x9c): undefined reference to `SDL_GetError'
> main.cpp:(.text+0xd0): undefined reference to `SDL_GetError'
> main.cpp:(.text+0x134): undefined reference to `CFG_ReadInt'
> main.cpp:(.text+0x154): undefined reference to `CFG_SelectGroup'
> [...]
> 
> while the SDL_GetError seems somewhat external and not a real problem 
> here the CFG_* functions are in the library. At least it looks like they 
> do. I'm somewhat helpless in this matter as there is little information 
> in the error what went wrong. I'm looking for ideas how to solve such 
> errors for now and in the future - maybe using a clever way using nm.
> 
> For a deeper look inside here is the my work archive for that library:
> 
> http://nocool.dyndns.org/open2x/SDL_Config.tgz
> 
> The supplied makefile should build the library with "make all" and 
> should try to make the testfiles with "make tests".
> 
> Thanks in advance
> StarG
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Open2x-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/open2x-devel
> 

I tried to get those libs compiling and it seems it works for the first 
one. When i'm trying to link this created library it fails with 
"unresolved symbol" linker errors.

Library creation process:

# compile
/opt/open2x/gcc-4.1.1-glibc-2.3.6/bin/arm-open2x-linux-g++ -DGP2X 
`/opt/open2x/gcc-4.1.1-glibc-2.3.6/bin/sdl-config --cflags` -I./src 
-I/opt/open2x/gcc-4.1.1-glibc-2.3.6/include  -c -o src/SDL_config.o 
src/SDL_config.c

# archive
/opt/open2x/gcc-4.1.1-glibc-2.3.6/bin/arm-open2x-linux-ar rc 
libSDL_Config.a ./src/SDL_config.o

# use ranlib
/opt/open2x/gcc-4.1.1-glibc-2.3.6/bin/arm-open2x-linux-ranlib 
libSDL_Config.a

This works fine and creates the library. Now i try to build a supplied 
test program.

# compile statically
/opt/open2x/gcc-4.1.1-glibc-2.3.6/bin/arm-open2x-linux-g++ 
`/opt/open2x/gcc-4.1.1-glibc-2.3.6/bin/sdl-config --cflags` -I./src 
-I/opt/open2x/gcc-4.1.1-glibc-2.3.6/include -lSDL_Config -lSDL -static 
-L. ./tests/001/main.o -o test1.gpu

this dumps a lot of errors:

./tests/001/main.o: In function `main':
main.cpp:(.text+0x84): undefined reference to `CFG_OpenFile'
main.cpp:(.text+0x9c): undefined reference to `SDL_GetError'
main.cpp:(.text+0xd0): undefined reference to `SDL_GetError'
main.cpp:(.text+0x134): undefined reference to `CFG_ReadInt'
main.cpp:(.text+0x154): undefined reference to `CFG_SelectGroup'
[...]

while the SDL_GetError seems somewhat external and not a real problem 
here the CFG_* functions are in the library. At least it looks like they 
do. I'm somewhat helpless in this matter as there is little information 
in the error what went wrong. I'm looking for ideas how to solve such 
errors for now and in the future - maybe using a clever way using nm.

For a deeper look inside here is the my work archive for that library:

http://nocool.dyndns.org/open2x/SDL_Config.tgz

The supplied makefile should build the library with "make all" and 
should try to make the testfiles with "make tests".

Thanks in advance
StarG

Hi guys,

I still have not been able to get the FDC to respond no matter what I send 
to it.  So I decided to try a different approach and have the 2nd CPU (940) 
convert the YV12 surface to YUY2 for me.  This has proven pretty successful 
and I have also got hardware blitting working to speed up copying the 
converted YUY2 surface from the 940 to the place where SDL wants the YUY2 
image (it would be even cooler to not have to do this copy at all but that 
is an optimization for the future).

I am currently able to get about 30 FPS (ie full speed) using a very low 
bitrate 320x240 mpeg1/mpeg2 file (250kbps-500kbps), with the mpeg decoding 
and YV12->YUY2 conversion all being done on the 940.

_________________________________________________________________
http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507

All,

Just in case anybody has missed the recent announcement take a peek at.

<http://www.open2x.org/open2x/2007/07/firmware-developer-release-1-out-for.h
tml> 

I know we all have some way to go but it's a noteworthy milestone.

John

Hi Matt,

>Ok, I _now_ am interested in getting hardware YV12 surfaces working.

Cool

>I've read the MMSP2 PDF manual and I think I understand everything in there

>(so far) about using the FDC to convert YV12 to YUY2 except the source 
>address part.  All I see is a base offset, X offset, and Y offset for the 
>Luminance, Cb, and Cr planes.  Offset from what?  hehe... I was hoping I 
>could provide a 32-bit absolute memory address but that doesn't seem the 
>case.  Any ideas on how to provide the source address?

I'll try and zip up and mail over what I have so far in the morning, it's
not very neat (understatement) but it does give you an idea of how this
should work, I am working from within a RAW environment (no Linux) but you
should be able to transpose it to use the symbols exposed by the kernel mode
FDC driver (FDC_Util, FDC_Run, FDC_IsBusy and FDC_Stop if I remember rightly
with most usfull stuff passed into FDC_Util). 

The driver defines the various YUV formats with names such as
FDC_CHROMA_420, FDC_CHROMA_422, FDC_CHROMA_444 etc. internally. Other then
that I think it is just as the book says ;).

John

> >This would be better than the current software-only solution.  I 
>personally
>
> >don't need YV12 support right now, but if someone else wants to tackle
> >this, I would be happy to provide the algorithm to convert YV12 to YUY2 
>and
>
> >also provide some advice on how best to accomplish this.
>
>As I am the one that would like it I am happy to have a go at implementing
>this as and when. If you're happy to provide a little help now and then 
>that
>would be wonderful as I am learning as I go.

Ok, I _now_ am interested in getting hardware YV12 surfaces working.

I've read the MMSP2 PDF manual and I think I understand everything in there 
(so far) about using the FDC to convert YV12 to YUY2 except the source 
address part.  All I see is a base offset, X offset, and Y offset for the 
Luminance, Cb, and Cr planes.  Offset from what?  hehe... I was hoping I 
could provide a 32-bit absolute memory address but that doesn't seem the 
case.  Any ideas on how to provide the source address?

_________________________________________________________________
http://im.live.com/messenger/im/home/?source=hmtextlinkjuly07

Here is the promised header. I had some quirrels with the 
sourceforge-lists server which rejected mail with them inside beforehand.

StarG

StarG schrieb:
> Welcome dear mailing list readers,
> 
> this is my first post here so hello to you all. First some
> introductionary words: i found the idea to have an own buildable and
> custom firmware for the GP2X very promising as does the OPEN2X project
> look to me. Let's get work together on it. :)
> 
> I'm currently already involved into some activities around that project.
> I'm both working on a easy to setup variant of the toolchain and a
> userspace tool to help identifying and managing usb devices on GP2X.
> 
> With the upcoming first O2X release the problem for the app / game
> programmers arise to identify the current irmware running on GP2X and/or
> wheter its a pc host build. I did a quick sketch on a library which
> would help to do this task. The thing to debate would be currently only
> its interface as its way for an implementation is a bit vaguely.
> 
> Possible would be directly called functions which return char* strings
> like in the supplied header. Another possibility would be to have an
> 
> char** enumerateAttributes();
> bool isAttributePresent( char* attributename );
> char* getAttribute( char* attributename );
> 
> interface or even a mix of both. I would really like to hear other
> opinions about how to proceed here. I'm also open for discussions of my
> other projects i mentioned above.
> 
> Thanks for listening
> StarG
> 
> 
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Open2x-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/open2x-devel
> 

Welcome dear mailing list readers,

this is my first post here so hello to you all. First some
introductionary words: i found the idea to have an own buildable and
custom firmware for the GP2X very promising as does the OPEN2X project
look to me. Let's get work together on it. :)

I'm currently already involved into some activities around that project.
I'm both working on a easy to setup variant of the toolchain and a
userspace tool to help identifying and managing usb devices on GP2X.

With the upcoming first O2X release the problem for the app / game
programmers arise to identify the current irmware running on GP2X and/or
wheter its a pc host build. I did a quick sketch on a library which
would help to do this task. The thing to debate would be currently only
its interface as its way for an implementation is a bit vaguely.

Possible would be directly called functions which return char* strings
like in the supplied header. Another possibility would be to have an

char** enumerateAttributes();
bool isAttributePresent( char* attributename );
char* getAttribute( char* attributename );

interface or even a mix of both. I would really like to hear other
opinions about how to proceed here. I'm also open for discussions of my
other projects i mentioned above.

Thanks for listening
StarG

Hi Matt,

>I have read over the MMSP2 PDF "documentation" but haven't tried doing 
>anything with the registers.  It's sure hard without example code.

Ahhh, same boat at the rest of us then.

>This would be better than the current software-only solution.  I personally

>don't need YV12 support right now, but if someone else wants to tackle 
>this, I would be happy to provide the algorithm to convert YV12 to YUY2 and

>also provide some advice on how best to accomplish this.

As I am the one that would like it I am happy to have a go at implementing
this as and when. If you're happy to provide a little help now and then that
would be wonderful as I am learning as I go.

>c) SDL_GP2X_GetMiniTicks which does nothing but returns the contents of 
>0xA00 (the 10 minute timer).
>Pros: thread safe, user can decide whether to divide by 7373 or 7372.8, 
>does not need to be called every 10 minutes.
>Cons: user will need to compensate for wraparound themselves, not 
>compatible with SDL_GetTicks

Gets my vote. It would also be easy enough to define out and should not
pollute code much.

Regards,

John

>I thought I better send you a public thank you for the SDL YUV patch.
>As you know this has now gone into the newer SDL 1.2.11/GP2X codebase.

you're welcome :)

>I did however have a few questions. In the code you mention that the only
>supported YUV format on the GP2X is 4:2:2 (YUY2). I assume you arrived at
>the conclusion looking at the docs for the Video Processor?

yes, the native YUV format for the gp2x seems to be YUY2.

>I was wondering if you had looked at this as part of the work you did (i.e.
>is this a dead end and I just don't realise it) or if it was something that
>you did not consider.
>I have not had a chance to have a play with it myself yet but on paper at
>least it has merit.

I have read over the MMSP2 PDF "documentation" but haven't tried doing 
anything with the registers.  It's sure hard without example code.

>Anyway, I am just musing here but personally I can see a strong attraction
>of additionally adding support for SDL_YV12_OVERLAY even if the support 
>just
>internally converts it to YUY2.

This would be better than the current software-only solution.  I personally 
don't need YV12 support right now, but if someone else wants to tackle this, 
I would be happy to provide the algorithm to convert YV12 to YUY2 and also 
provide some advice on how best to accomplish this.

>You mentioned on IRC that you had hit a snag with the GetTicks work?
>The hardware timer was resetting after 10 mins as I understand it.
>
>Whilst there are several workarounds to this I can't see that any of them
>would be that elegant, you mentioned creating a SDL_GP2X_GetTicks, this
>strikes me as the cleanest approach for now but I am still slightly shocked
>by your timer findings.
>
>Could you provide a little more info on what you tried/used etc. maybe a
>wider group could shed some light on the issue and bottom out a nice way to
>tackle it.

Sure... the gp2x's timer is located at 0x0A00 (ie C000 0A00h) and you can 
read about it in that MMSP2 PDF file on page 168.  The docs say that the 
timer ticks every 7.3728MHz so to convert the timer to milliseconds, you 
need to divide by 7372.8 (or 7373 to avoid floating point math at the cost 
of some accuracy).  It also says that the timer rolls over to 0 once it 
passes 0xFFFFFFFF, so by doing a little math, you can see that this amounts 
to a little under 10 minutes.

There are a few ways to take advantage of this timer:
a) SDL_GetTicks, with some global variables as state to hide the 
"wraparound" from the user.
Pros: compatible with current SDL_GetTicks definition.
Cons: not thread safe, program must call SDL_GetTicks at least once every 10 
minutes or a wraparound will be lost.  Also precision will be lost, assuming 
we divide by 7373 instead of 7372.8.

b) SDL_GP2X_GetTicks with the user supplying a structure to hold state 
instead of using global variables.
Pros: thread safe
Cons: not compatible with SDL_GetTicks.  Must be called at least every 10 
minutes to ensure wraparound is detected.  Also, same problem with precision 
if we divide by 7373.

c) SDL_GP2X_GetMiniTicks which does nothing but returns the contents of 
0xA00 (the 10 minute timer).
Pros: thread safe, user can decide whether to divide by 7373 or 7372.8, does 
not need to be called every 10 minutes.
Cons: user will need to compensate for wraparound themselves, not compatible 
with SDL_GetTicks

After giving this a lot of thought, I prefer 'c'.  I think an 
SDL_GP2X_GetMiniTicks provides the user with the most flexibility and will 
work in every case.  SDL_GetTicks will still be available and will still 
work, it will just be slow (which is the current problem with it).

_________________________________________________________________
Get a preview of Live Earth, the hottest event this summer - only on MSN 
http://liveearth.msn.com?source=msntaglineliveearthhm

Hi Matt/All,

>I've been doing some work on hardware YUV support for SDL-GP2X (finished, 
>working great)

I thought I better send you a public thank you for the SDL YUV patch. 
As you know this has now gone into the newer SDL 1.2.11/GP2X codebase.

I did however have a few questions. In the code you mention that the only
supported YUV format on the GP2X is 4:2:2 (YUY2). I assume you arrived at
the conclusion looking at the docs for the Video Processor?

Whilst I agree it is the only format the hardware can use (as I understand
it) I have noticed in the past that there also exists the Frame Dimension
Converter, from what can surmise from the scant documentation this should
perform the same sort of role as FFMPEG's libSWSCALE. Among its functions it
claims to be able to handle in hardware conversion from 4:2:0 (YV12) to
4:2:2 (YUY2) and some funky rotation and scaling.

I was wondering if you had looked at this as part of the work you did (i.e.
is this a dead end and I just don't realise it) or if it was something that
you did not consider. 
I have not had a chance to have a play with it myself yet but on paper at
least it has merit. 

Thinking on those lines, I guess the MMSP2 post processor could also be
wired in to the stream, maybe via something exposed in the environment to
toggle its use? 

This is something I have been pondering for a while (along with getting
RGB<>YUV hardware conversion going to smooth scale SDL RGB surfaces).
I lament the mount of hardware features we just gloss over but never seem to
get very far with wiring them up ;).

Anyway, I am just musing here but personally I can see a strong attraction
of additionally adding support for SDL_YV12_OVERLAY even if the support just
internally converts it to YUY2. This would give SDL on the GP2X the enviable
position of supporting the 2 main YUV formats in hardware and could (I
think) go a long way to helping to kick start work on mplayer and other
video apps that support a SDL video output layer. Another option I guess
would be to work in some ARM ASM conversion code for the YV12 to YUY2 step
but pre-exiting implementations of this approach such as the Nokia 770 live
outside SDL in apps like mplayer (not a very generic solution). 

>My SDL_GetTicks enhancement requires access to the data->io pointer (ie the

>mmap'd "/dev/mem").  What would be the cleanest way to get access to this?

There is not really a clean way, just hack it ;). It is not like the rest of
the system is hack free and our SDL fork is a long way from being fit to
present to mainline ;).

>It seems the most efficient way is to use a global variable but that isn't 
>the cleanest.  I will probably hack in a global variable approach to start 
>with, but if anyone has any ideas to clean it up, that would be great.  (I 
>try to avoid using globals where possible)

I must agree it would not be the cleanest.

You mentioned on IRC that you had hit a snag with the GetTicks work? 
The hardware timer was resetting after 10 mins as I understand it.

Whilst there are several workarounds to this I can't see that any of them
would be that elegant, you mentioned creating a SDL_GP2X_GetTicks, this
strikes me as the cleanest approach for now but I am still slightly shocked
by your timer findings. 

Could you provide a little more info on what you tried/used etc. maybe a
wider group could shed some light on the issue and bottom out a nice way to
tackle it.

Regards,

John Willis

2006	Jan	Feb	Mar (2)	Apr (2)	May	Jun	Jul	Aug (2)	Sep	Oct	Nov	Dec
2007	Jan (16)	Feb (9)	Mar	Apr	May	Jun (8)	Jul (13)	Aug (2)	Sep (7)	Oct (2)	Nov	Dec
2010	Jan	Feb	Mar (1)	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2011	Jan	Feb	Mar (1)	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec

open2x-devel Mailing List for The Open2x Project

open2x-devel — General Open2x Development/Project Discussion