Al fin algo de info técnica sobre la GP2X [Archivo] - ZonaDeVicio

Puck2099

21/09/2005, 19:30

Hola,

Como ya he dicho en el post de "Impresiones de los coders", Anna Hong me ha contestado un mail de hace unas 2 o 3 semanas donde le pedía información para empezar a portar cosas a la GP2X.

Como no he firmado nada para tener "la boca cerrada" y tampoco me han pedido que no haga público nada de esto, os comento un poco por encima lo visto.

En su mail me redirige a una web en perfecto coreano que debe ser algo así como una especie de Sourceforge. Bueno, después de indagar y dar unos cuantos "palos de ciego", he conseguido acceder a la zona de descargas que tiene preparada la señorita Anna.

Me he bajado unos 125 MB de información parte en coreano y parte en inglés que todavía tengo que "desglosar". Por lo poco que he podido mirar (estoy en el curro y no es plan ponerse a ver cosas en coreano :p ) creo (y digo creo) que viene entre otras cosas:

- El código fuente del gplayer (un mplayer adaptado para la GP2X).
- Un manual (en coreano) para usar el MMSP2 (el chip de la consola) con WinCE
- Unas librerías para programar para la GP2X (incluye SDL 1.2.7, zlib, ncurses...)
- 3 Manuales técnicos sobre el MMSP2 y su programación bajo Linux en PDF e inglés de unas 1500 pág en total).
- Un archivo word en el que creo que actualizan el kernel de la GP2X, pero no lo tengo muy claro (luego pongo una foto del proceso).
- Un archivo de 75 MB llamado armtools con programas y utilidades que supongo valen para programar para la GP2X (arm-linux-gcc, arm-linux-ar, etc.)

Bueno, pues eso es todo, seguiré informando :)

Bonk666

21/09/2005, 20:01

aupa!

Pues no dudes en poner tus primeras impresiones en cuanto te metas un poco más, que es muy interesante! :)

Aio

Croc

21/09/2005, 20:19

Wenas!

Pero suelta prenda, muchado! :D
Dinos cual es la web esa, ke yo tb tengo ganas de empezar a echarle un ojo a la documentacion tecnica... y no has firmado ningun NDA.
Aunke igual a otros c0ders les hace mas falta ke lo vayan mirando... :)

Salu2

ivanpd

21/09/2005, 21:07

para los q le interesen pueden verlo en la pagina d gpx2, buscad la respuesta q le da anna a puck y teneis la pagina y el user/pass..

Puck2099

21/09/2005, 21:12

Hola,

Acabo de llegar a casa, si queréis puedo subir mañana los archivos al FTP público, que con mis 300 kbs de subida me tiro un huevo, pero con los 4 megas del curro irá volado :p

El problema de la web donde lo he bajado es que varios bajan con el nombre cambiado, como si fueran ejecutables...

Saludos

A600

21/09/2005, 22:00

Yo me lo acabo de descargar ;)

efegea

21/09/2005, 22:10

The requested URL could not be retrieved
While trying to retrieve the URL: http://www.seplus.com/
The following error was encountered:
Unable to determine IP address from host name for www.seplus.com
The dnsserver returned:
Name Server for domain 'www.seplus.com' is unavailable.
This means that:
The cache was not able to resolve the hostname presented in the URL.
Check if the address is correct.

Puck2099

21/09/2005, 22:13

efegea

21/09/2005, 22:19

Prueba de nuevo, porque yo acabo de entrar.

Sino espérate a mañana y lo subo al FTP :)

Pues pa mi que el servidor de nombres de dominio de mi ADSL no tiene registrado ese dominio porque si no no lo pillo :loco:

Me esperaré a ese ftp :)

Croc

21/09/2005, 22:22

Wenas!

Espero no kebrantar nada poniendo sto, xo parece ke los ficheros son accesibles sin hacer login:

http://www.seplus.com/board/board_download.asp?board_file=arm%2Dtools%2Etar%2E gz
http://www.seplus.com/board/board_download.asp?board_file=doc%2Ezip
http://www.seplus.com/board/board_download.asp?board_file=gplayer+explanation% 2Etxt
http://www.seplus.com/board/board_download.asp?board_file=gplayer%2Etar%2Egz
http://www.seplus.com/board/board_download.asp?board_file=installation%2Etxt
http://www.seplus.com/board/board_download.asp?board_file=library%2Etar%2Egz
http://www.seplus.com/board/board_download.asp?board_file=MMSP2+WinCE+Display+ Driver+User+Guide%2Epdf
http://www.seplus.com/board/board_download.asp?board_file=GPX++KERNEL+UPDATE+% B9%E6%B9%FD%2Edoc

Efectivamente, como dice Puck parece ke se renombran automatica a ".exe" :loco: si se bajan mediante el navegador, xo usando el wget parece ke todo va bien :)

Salu2

Puck2099

21/09/2005, 22:25

Efectivamente, como dice Puck parece ke se renombran automatica a ".exe" :loco: si se bajan mediante el navegador, xo usando el wget parece ke todo va bien :)

Es lo malo de no tener un Linux a mano en el curro, que te toca comerte la cabeza pensando porque no se ejecutaban esos .exe ;)

A600

21/09/2005, 22:38

Pues pa mi que el servidor de nombres de dominio de mi ADSL no tiene registrado ese dominio porque si no no lo pillo :loco:

Me esperaré a ese ftp :)

Usa este proxy: 211.185.56.211:8080

Yo intenté descargarlo ayer y me daba el mismo error.

virucho28

21/09/2005, 22:47

Joe por fin algo sobre nuestra futura consolilla, jeje , ya era hora.

efegea

21/09/2005, 23:05

Usa este proxy: 211.185.56.211:8080

Yo intenté descargarlo ayer y me daba el mismo error.

Gracias, así sí me ha funcionado.

¡¡Que cosas más interesantess hay ahí!!

EDITO: GUI Microwindows, QT/embedded(as separate package)

¡Parace que los drivers son open source!

http://usuarios.arsystel.com/frangongue/gp2xlinuxdevicedriver.jpg

AZ!DØ

21/09/2005, 23:10

Wave

21/09/2005, 23:44

Graphic acceleration functions include:
- Rectangular source-copy block transfer (BitBLTs)
- Transparent source-copy BitBLTs
- Masked source-copy BitBLTs
- Monochrome-to-color expansion on source and pattern data
- Pattern and Rectangle Fills
- 256 Raster Operations (ROPs)

Interesante.... MUY interesante.

Bonk666

22/09/2005, 01:52

aupa!

Interesante.... MUY interesante.

Pues si se lo puedes explicar a un ignorante como yo...es que me fastidia ver que os alegrais y no saber el porque, que pasa, es potente?facil de programar? :babea:

Aio

Wave

22/09/2005, 01:59

Segun esas especificaciones, digamos que puede dibujar sprites por hard.

Bonk666

22/09/2005, 02:17

Aupa1

Segun esas especificaciones, digamos que puede dibujar sprites por hard.

Por lo que, según te puedo entender, esos procesos, anteriormente se hacian por soft, por lo que se comian sus recursos, y ahora el dibujado de los sprites es más rapido y dejan más procesador libre?

Aio

Wave

22/09/2005, 02:30

Si, liberara uso de cpu ademas el pintado de sprites con color transparente es algo muy pesado. Esperemos que con el SDK podamos usar todas estas caracteristicas aunque sea a traves de SDL.

Segata Sanshiro

22/09/2005, 02:40

Puck2099

22/09/2005, 02:44

Ahora no se puede ni entrar a la web de seplus (creo que es la empresa de hosting que utiliza GPH?). Pero por lo que decís, esa información debería ser la info confidencial, aunque como nadie ha dicho nada de nada... Pues a ser felices xD

Hombre, a mi además de pasarme la dirección por mail me han contestado en el foro de sugerencias, así que supongo que muy confidencial no será :p

A600

22/09/2005, 02:47

Hombre, a mi además de pasarme la dirección por mail me han contestado en el foro de sugerencias, así que supongo que muy confidencial no será :p

Lo que no me explico es cómo se le ocurre postear en la respuesta su user y pass en vez de mandarte un e-mail con la información.

Puck2099

22/09/2005, 03:09

Lo que no me explico es cómo se le ocurre postear en la respuesta su user y pass en vez de mandarte un e-mail con la información.

Ha hecho ambas cosas...

ArTo

22/09/2005, 03:59

Por cierto, ahora utilizando la búsqueda no aparece el post donde dice el user y el pass y tampoco mirando las páginas del foro... ¿no lo habrán borrado?

Eso sí, poniendo el link desde el historial si que entra en el mensaje.

Saludos...

P.D.: Es verdad que el archivo docs.zip contiene el datasheet del chip de magic eyes con información a bajo nivel como dicen aquí: http://www.gp32x.com/board/index.php?showtopic=20778?

A600

22/09/2005, 04:06

Algunos datos interesantes:

enum {
VK_UP /* 0 */
VK_UP_LEFT /* 1 */
VK_LEFT /* 2 */
VK_DOWN_LEFT /* 3 */
VK_DOWN /* 4 */
VK_DOWN_RIGHT /* 5 */
VK_RIGHT /* 6 */
VK_UP_RIGHT /* 7 */
VK_START /* 8 */
VK_SELECT /* 9 */
VK_FL /* 10*/
VK_FR /* 11 */
VK_FA /* 12 */
VK_FB /* 13 */
VK_FX /* 14 */
VK_FY /* 15 */
VK_VOL_UP /* 16 */
VK_VOL_DOWN /* 17 */
VK_TAT /* 18 */ }
MAP_KEY;

Se pueden leer las diagonales y los botones de volumen. ¿Qué botón será VK_TAT?

ZeNiTRaM

22/09/2005, 04:07

Por cierto, ahora utilizando la búsqueda no aparece el post donde dice el user y el pass y tampoco mirando las páginas del foro... ¿no lo habrán borrado?

Eso sí, poniendo el link desde el historial si que entra en el mensaje.

Saludos...
Pues mi el post me sale.. de todas formas aunque lo borrara no serviria de mucho, ya nos hemos bajado todo..

Aunque tampoco tendria porque borrarlo.. quizas ellos QUIEREN que lo tengamos, pero no puedan hacerlo directamente por algo..

ArTo

22/09/2005, 04:09

Bueno, toda información es bienvenida :)

Segata Sanshiro

22/09/2005, 05:10

Algunos datos interesantes:

Se pueden leer las diagonales y los botones de volumen. ¿Qué botón será VK_TAT?

Qué raro, ni idea O_o El botón de encendido? Encendido por soft?

Edit: vuelven a funcionar los links, a saquear.

ArTo

22/09/2005, 06:06

Si no os va el link aquí va uno alternativo con casi todo http://www.fear.me.uk/gp2x/

Saludos...

Syrion

22/09/2005, 06:13

Se pueden leer las diagonales y los botones de volumen. ¿Qué botón será VK_TAT?

La doble función de select (la retriluminación)? Por cierto, juraria que la cruceta tiene menos direcciones de las que habia leido...

esp3tek

22/09/2005, 06:13

filtrados de informacion.... :babea: :babea: :babea:

ahora se os podrian aparecer 2 hombres de negro en la puerta de vuestra casa a reclamar el "disco"

juas, como molaria, que eso que se ha filtrado, sea algo que ha publicado intencionadamente GPH durante el tiempo suficiente como para decir que ha sido un fallo en la administracion o permisos de directorios :babea: :babea: :babea:

y que sea lo que nos capaba el procesador de magic eyes :babea: :babea:

ArTo

22/09/2005, 06:26

esp3tek

22/09/2005, 06:33

siempre hay algun hacker dispuesto a robar informacion.....a cambiar un archivo de carpeta...rivilegios....vulnerabilidad de su servidor web.....fallo de un administrador tontito.....

ojala sea lo que e dixo antes.. todo se puede justificar

Rein

22/09/2005, 06:39

bueno para mi lo k estais hablando me parece chino mandarin pero komo os veo tan contentos pues BIBAAAAAAAAAAA!!!!!! :arriba:

esp3tek

22/09/2005, 06:45

a ver... supuestamente. hay uno de los cerebros de la Gp2x que no nos daban el conjunto de instrucciones para mandarlo, y hemos encontrado supuestamente parte o la totalidad de esos datos confidenciales. pero no sabremos si esto es verdad hasta que alguien con conocimiento nos lo pueda asegurar

Puck2099

22/09/2005, 06:48

esp3tek

22/09/2005, 06:53

pero la pregunta es.... HEMOS CONSEGUIDO ESA INFORMACION vital del procesador cerrado de magic eyes?

Anarchy

22/09/2005, 07:21

Bueno, ya son dos los coders (ambos MUY FIABLES) que me han dicho que tras ver los documentos "filtrados", la GP2X es MUCHO más cañera de lo que todos habíamos pensado incialmente. :brindis: :brindis: :brindis:

esp3tek

22/09/2005, 07:25

:rever: :rever: :rever: :rever: :rever: ANNA HONG :rever: :rever: :rever: :rever: :rever:

Dios, que buena noticia...espero que bayais poniendo vuestros comentarios. porque parece que la gente este sobando...

y yo aqui "refrescando" y refrescando

kanchi

22/09/2005, 07:26

A mi lo que más me llama la atención es donde está conectado el programador/debugguer, es un puerto EXT!!. Espero que sea accesible desde el exterior porque me parece que no he visto ninguna ranura inferior en las fotos.

WinterN

22/09/2005, 07:30

Es curioso, pero en la web esa que ha puesto ArTo un link (http://www.fear.me.uk/gp2x/), están los siguientes documentos:

Data Book (673 page PDF, 3.6MB)
An in depth description of the MMSP2 system.

Aquí es donde debería estar la chicha, pero curiosamente, las 673 páginas del PDF están en blanco.

Linux User Manual (194 page PDF, 9MB)
Describes the Linux environment on the MMSP2 system.

Este tiene Copyright de MagicEyes. Es posible que tenga información relevante, aunque en principio parece que solo trata las llamadas al SO y el funcionamiento del mismo.

ARM 920 Reference (340 page PDF, 4MB)
Describes the main cpu of the GP2X system.

ARM 940 Reference (230 page PDF, 2.8MB)
Describes the secondary cpu of the GP2X system

Documentación de cada uno de los micros. Está firmado por ARM y no se menciona a MagicEyes por ningún lado; lo que me hace pensar que no contiene nada de la "información oculta". Pero esto no quiere decir que no sean útiles/importantes...

Mplayer (gz, 8.4MB)
Source for a developement version of the GP2X's Mplayer.

Aún no lo he descomprimido, pero me hago una idea de que va a ser el código del reproductor que incluirá la GP

esp3tek

22/09/2005, 07:33

hay que buscar ese archivo completo....

Edit: :babea: :babea: :babea: :babea: :babea:

Puck2099

22/09/2005, 07:38

Data Book (673 page PDF, 3.6MB)
An in depth description of the MMSP2 system.

Aquí es donde debería estar la chicha, pero curiosamente, las 673 páginas del PDF están en blanco.

¿Te has bajado las fuentes coreanas del Acrobat?, lo digo porque uno de los PDF (no estoy seguro de si era ese) también se me veía en blanco y, tras actualizar las fuentes coreanas, salía el texto en inglés :)

WinterN

22/09/2005, 07:52

¿Te has bajado las fuentes coreanas del Acrobat?, lo digo porque uno de los PDF (no estoy seguro de si era ese) también se me veía en blanco y, tras actualizar las fuentes coreanas, salía el texto en inglés :)

Eres un monstruo :arriba:

Antes no se veían ni las imagenes y ahora se ve todo todito todoooo...

y sí, parece que entra a explicar la arquitectura en mayor detalle del que muchos lleguemos a necesitar.

Me parece que se puede montar un buen pollo con todo esto.y espero que no afecte a las fechas de salida de la consola

esp3tek

22/09/2005, 07:55

BENDITO SEA EL SEÑOR!!!!
:brindis: :brindis: :brindis: :brindis: :brindis:

imeko

22/09/2005, 07:57

no entiendo ni papa ,pero si esto kiere decir ke se podra emular cosas impensables como gba o psx 2d,pues :saltando: :saltando: :saltando: :saltando: :saltando: :saltando: :saltando: :saltando: :saltando: :saltando:

esp3tek

22/09/2005, 07:59

quiere decir que la consola ya no es "tan" cerrada como era hace unas horas

WinterN

22/09/2005, 08:32

Yo desde luego me estoy quedando flipado despues de echar un vistazo rápido a las características del hardware:

- Capacidad de captura y codificación de video (quiza con una webcam usb)
- Controlador para Touch pad (¿GP2X DS a base de modding?)
- Controlador para reconocimiento de voz, y por tanto, posibilidad de entrada de micro.
- Controladores de IDE (CD-ROMs, discos duros...)
- Puede ofrecer una salida a 1024x768 a 60Hz (aunque el decoder de video solo ofrezca 720x480)
- USB Host 1.1
- Aceleradora 2D y aceleradora de video independientes del segundo micro (lo que le hace quedar más libre de lo que pensabamos)
- Controles varios de video por HW (Zoom, corrección de la gama, balance de blancos...)
- Soporte para WindowsCE y Direct2D (viva linuuuuux)
- No dice nada de MIDI, pero dado que tiene un controlador AC97 algo me hace pensar que sí.

Ojo, esto no quiere decir que la GP vaya a tener todo esto, sino que el micro es capaz de hacer todo eso...

Bueno, voy a pasar directamente al capitulo 3, que el 2 va de los pines del micro y como que no interesa mucho ;)

Finrod

22/09/2005, 08:59

Bueno, ya sabeis que yo de programacion y de hardware ni papa... pero despues de saber esto ¿Sois un poco mas optimistas respecto a la emulacion de cps2 y GBA?

A600

22/09/2005, 09:04

Ahora sólo falta que alguien se curre un entorno para compilar en Windows :musico:

K-teto

22/09/2005, 09:07

Bueno, he estado hablando con squidge, que posee una de las gp2x sin carcasa de estas que hemos visto fotos ya, y a parte de que ha dumpeado la nand entera, ha estado contando varias cosas.
El alphablending estara muy limitado (ha comentado que solo a capas, pero no se que queria decir)
La rotacion por hardware es a 90º 180º y asi, pero no a un angulo que le digamos (para eso que se lo curre cada uno)
El controlador de la pantalla debe ir metido en el chip porque no lo ha encontrado por ninguna parte de la placa
Tendremos sonido ac97 (que era una de las incognitas, si lo dejarian o lo quitarian)
El chip que se encarga de la salida de video (a tv por ejemplo) es un conexant, no os puedo dar mas datos porque no los se
El uboot son sobre los 100Kb, no mucho, y el contenido de la nand no lo ha dicho.
Hay un kernel que no tira y otro que si, por lo visto el que si tira puede que este disponible (por su parte? yo no lo he dicho) mas adelante.

<K-teto> it does accelerated blitting
<K-teto> but what about alpha blending, rotations and such?
<RobB_afk> I don't think it does alpha blending
<K-teto> or you don't know yet?
<RobB_afk> the blitter does transparency
<Squidge> it does have alpha blending, but very limited
<RobB_afk> which I know is not the same thing
<K-teto> limited?
<Squidge> yes, you can only alpha blend layers apparently.
<Squidge> we don't know enough about the chip yet
<RobB_afk> I'm pretty sure it does some sort of rotation, but whether there is arbitrary angles and dithering is yet to be seen... squidge?
<Squidge> I think the angles are 90/180/270

Para mas informacion pasaos por su blog http://squidgey.co.uk que no para de poner lo que va descubriendo, eso incluye fotos de la placa de la consola.

WinterN

22/09/2005, 09:20

Para mas informacion pasaos por su blog http://squidge.co.uk que no para de poner lo que va descubriendo, eso incluye fotos de la placa de la consola.

El link me lleva a una página de ropa de plástico para tías :loco:

PuNk_NoT_DeAd

22/09/2005, 09:35

Para mas informacion pasaos por su blog http://squidge.co.uk que no para de poner lo que va descubriendo, eso incluye fotos de la placa de la consola.

Tio,eres un deprabado sexuallll.xD xD

Salud.

K-teto

22/09/2005, 09:39

ARGH!!!!!!!
Pero que error mas gordo, os juro que no ha sido intencionado, la pagina es http://squidgey.co.uk o sea, la misma pero con una Y al final, os juro que no ha sido intencionado, de verdad... :llorosr:

neostalker

22/09/2005, 10:05

Se te ha visto el plumero K-teto :D

Drumpi

22/09/2005, 10:11

Bueno, todas las cosas de las que es posible el micro no me fiaria mucho, mas que nada porque tengo un movil que se supone que tiene conexion usb, puerto infrarrojos, camara con zoom2x y posibilidad de video, lector de tarjetas SD/MMC... los que tengan un tsm30 o tsm100 me comprenderan.
Un procesador, por poder, puede mandar un cohete a la luna, con mas o meos dificultad, pero...
Oye, que si lo permiten, yo lo flipo directamente ¿donde esta la fabrica?

K-teto

22/09/2005, 10:15

Soup

22/09/2005, 11:41

ZeNiTRaM

22/09/2005, 14:04

He encontrado en el codigo del Gplayer codigo.. bastante interesante..

#ifdef CX25874
if(disp_mode == DISPLAY_TV) // tv out
fdc_info.DstField = 1; // Field
#endif

fdc_info.ToScaler = 1; // scaler·Î º¸³½´Ù.
#ifdef CX25874
if(disp_mode == DISPLAY_TV) // tv out
fdc_info.ToScaler = 0; // To mem for not shaking
#endif

fdc_info.Width = width;
fdc_info.Height = height;
fdc_info.Y_Offset = y_offset[0];
fdc_info.CB_Offset = cb_offset[0];
fdc_info.CR_Offset = cr_offset[0];
fdc_info.DstBaseAddr = 0; // _caution: ÀÌ°Ô ¿Ö 0ÀÌÁö?, target addressÀÎµ¥...--;, scaler·Î µé¾î°¡¸é 0ÀÎ°¡?
#ifdef CX25874
if(disp_mode == DISPLAY_TV) // tv out
fdc_info.DstBaseAddr = 0x03980000; // 1D memory address..
#endif

ioctl(vpp_fd, IOCTL_MMSP2_SET_FDC, &fdc_info); // setup FDC
// ioctl(vpp_fd, IOCTL_MMSP2_START_FDC, NULL);// enable FDC

#ifdef CX25874
if(disp_mode == DISPLAY_TV)
{
if(width > 720)
yuv_info.DstWidthTop = (unsigned short)(width/((float)800/(float)720)); // TVEncoder 720X480 support
if(height > 480)
yuv_info.DstHeightTop = (unsigned short)(height/((float)600/(float)480)); // TVEncoder 720X480 support
}
#endif
yuv_info.StrideTop = width * 2;

yuv_info.SrcWidthBot = width;
yuv_info.SrcHeightBot = height;
yuv_info.DstWidthBot = cal_width;
yuv_info.DstHeightBot = cal_height;

#ifdef CX25874
if(disp_mode == DISPLAY_TV)
{
if(width > 720)
yuv_info.DstWidthBot = (unsigned short)(width/((float)800/(float)720)); // TVEncoder 720X480 support
if(height > 480)
yuv_info.DstHeightBot = (unsigned short)(height/((float)600/(float)480)); // TVEncoder 720X480 support
}
Esto quiere decir que se podrá controlar la salida de TV por software?
(archivo mmsp2_940_if.c)

Edito: De aqui sacamos (por los #ifdef) que el chip de TV es un Conexant CX25874 (http://www.google.com/search?hl=es&hs=cCy&client=opera&rls=es-ES&q=conexant+CX25874&spell=1) ..que tiene:
True international support for NTSC, PAL and SECAM output
HDTV output capability
Adaptive flicker filtering
Supports resolutions 320 x 200 to 1024 x 768
Software forward capability with the CX25870 and CX25871
Programmable overscan ratios from 0% to 25%
Pin compatible with CX25872 and 25873
64-pin TQFP

:babea: :babea:

Puck2099

22/09/2005, 16:08

Bueno, como prometí ayer, estoy subiendo los archivos que descargué al FTP público, en cuanto esté arriba os aviso :)

oankali

22/09/2005, 16:38

Pero tu movil necesita un software que haga uso de eso, y en el caso de la gp2x nosotros tenemos el hardware, y hacemos el software como nos salga de la punta.
Amos, que no es el mismo caso ni de coña. lo del movil es un problema de software mas que de las capacidades del movil.

Esto no és del todo cierto, no es porqué el chip permite todas estas cosas, que programándo nosotros mismos los chips, tendremos acceso a todo.
Es probable que haya pines del chip inutilizados. Por ejemplo, nadie nos asegura que podamos utilizar el touchpad, aunque el chip tenga un controlador para ello.

Oankali.

Puck2099

22/09/2005, 16:54

Bueno, ya está todo subido en el FTP público.

Podéis descargar los archivos desde la ruta Programacion\GP2X ;)

Por cierto, también he subido las armtools que han "desaparecido" de la web donde las descargué...

nanof

22/09/2005, 16:57

Esto... y cual es la dirección del FTP??? :chupete:

Bueno, ya está todo subido en el FTP público.

Podéis descargar los archivos desde la ruta Programacion\GP2X ;)

Por cierto, también he subido las armtools que han "desaparecido" de la web donde las descargué...

Wave

22/09/2005, 17:19

Lo de las rotaciones y tal es para las capas que puede hacer, 2 o 4 no me acuerdo, pero no serviria para cosas como sprites. Pero esto nos quitara el esfuerzo de rotar la pantalla (que es lo que hay que hacer en gp32) en el caso de que sea una pantalla rotada como en gp32.

Puck2099

22/09/2005, 17:30

Esto... y cual es la dirección del FTP??? :chupete:

servidor: gp32spain.com
usuario: public_ftp@gp32spain.com
password: publico

WinterN

22/09/2005, 17:32

El alphablending estara muy limitado (ha comentado que solo a capas, pero no se que queria decir)

Pues es algo parecido a lo que comenta Wave con el tema de las rotaciones. La GP2X puede manejar 2 capas. En una por ejemplo puedes mostar un video escalado y en la otra los controles de reproducción. Creo, aunque no estoy muy seguro, que el alphablending es aplicable entre estas 2 capas...

Tengo que mirarlo más a fondo, pero ahora estoy en el curro un poco liado :sobando:

oankali

22/09/2005, 18:05

Pues es algo parecido a lo que comenta Wave con el tema de las rotaciones. La GP2X puede manejar 2 capas. En una por ejemplo puedes mostar un video escalado y en la otra los controles de reproducción. Creo, aunque no estoy muy seguro, que el alphablending es aplicable entre estas 2 capas...

Tengo que mirarlo más a fondo, pero ahora estoy en el curro un poco liado :sobando:

No será que lo que quiere decir es que el nivel de alphablending será el mismo para toda la capa y que si lo queremos a nivel de píxel, por ejemplo para hacer antialiasing, lo tengamos que hacer a pelo? Con una máscara por ejemplo.

Oankali.

mortimor

22/09/2005, 18:44

Segun las especificaciones del SoC contamos con 2 capas de overlay, vamos que podemos tener dos capas superpuestas. Como ha dicho Oankaly seguramente el blending se aplique a nivel de capa y utilice el overlay para la superposicion, esto es una suposición.

Esto limita los efectos por hardware bastante creo yo, pero bueno, siempre se podra combinar con efectos por software y aprovechar lo que se pueda.

Me estoy bajando otra vez toda la info, que ayer me la baje de los accesos directos que pusieron y se baajron los ciento y pico megas, pero luego todos los ficheros estaban jodidos. Y eso que me los baje con el NetAnts :(

una-i

22/09/2005, 20:30

El Blit si soporta color mask, es decir puedes decirle un color y que lo interprete trasnparente totalmente, lo que no soporta por hard en los blitters es diferentes niveles de alpha, es decir juegos con sprites con abujeros se pueden hacer y van acelerados...

Pero un sptrite con degradados de trasparencia nasti de plasti...

Unai.

esp3tek

22/09/2005, 22:25

pero... rebela algo del procesador cerrado de magic eyes, sobre su programacion o algo=?

Wave

22/09/2005, 22:30

pero... rebela algo del procesador cerrado de magic eyes, sobre su programacion o algo=?
Rebela las etiquetas a los registros para controlar el chip y como se usa mas o menos, pero no dice sus direcciones fisicas reales.

Topochan

22/09/2005, 22:32

He estado mirando los manuales y hay cosas muy interesantes, pues el magic tiene mucho decodificadores como ac97 y mp3 en el chip aparte de efectos 2d, el manual de instalacion de linux me he chocado un poco pues recomiendan un red hat 7.3 o superior y el kernel un 2.4(que es el recomendado para pequeños dispositivos). De todas maneras si es cerrado algo yo no lo he visto, pues indica todos los pasos de compilacion. asi que el acceso al magic se hara por el kernel, otra manera no creo si es cerrado...

edit: aclaro, la programacion para acceder al segundo micro no habra problemas, siempre y cuando utilicemos el kernel, lo cual yo no veo problema

WinterN

23/09/2005, 00:35

edit: aclaro, la programacion para acceder al segundo micro no habra problemas, siempre y cuando utilicemos el kernel, lo cual yo no veo problema

En el Data book explica de manera bastante clara como funcionan los micros. Existe un controlador de I/F (búsqueda de instrucción) con 32 registros a los que pueden acceder ambos micros. Hay 16 registros correspondientes al ARM940 y otros 16 correspondientes al ARM920.

Cuando el micro que en ese momento esté ejecutado código escribe en cualquiera de éstos registros, el micro correspondiente al registro recibe una interrupción para proseguir la ejecución por el PC (contador de programa) que se haya guardado en el registro...

Esto es a grandes rasgos... En el documento vienen las direcciones físicas reales de dichos registros, por lo que se podrá acceder a ellos y controlar los micros.... :babea: :babea: :babea: :babea: :babea:

Otras cosillas: los dos micros son técnicamente iguales, salvo que el ARM940 (principal) tiene MMU y 16KB de caché de instrucciones y otros 16KB de datos, mientras que el ARM920 (coprocesador) no tiene MMU y la caché es de 4KB en para instrucciones y 4KB para datos.

esp3tek

23/09/2005, 06:43

Cuando el micro que en ese momento esté ejecutado código escribe en cualquiera de éstos registros, el micro correspondiente al registro recibe una interrupción para proseguir la ejecución por el PC (contador de programa) que se haya guardado en el registro...

Esto es a grandes rasgos... En el documento vienen las direcciones físicas reales de dichos registros, por lo que se podrá acceder a ellos y controlar los micros.... :babea: :babea: :babea: :babea: :babea:

impresionantes y buenisimas noticias, que veo que pasan desapercibidas para muchos foreros..

por cierto, lo del MMu que es realmente... influye en que no se puedan usar los 2 pros en paralelo?...

pd: estoy realmente contento con esta noticia

Electric Dreams

23/09/2005, 06:48

impresionantes y buenisimas noticias, que veo que pasan desapercibidas para muchos foreros..

por cierto, lo del MMu que es realmente... influye en que no se puedan usar los 2 pros en paralelo?...

pd: estoy realmente contento con esta noticia

El MMU es el "Memory Management Unit" o Unidad de control de memoria. Eso indica que el primer procesador tiene acceso a la memoria principal de forma directa y el segundo no.

ArTo

23/09/2005, 07:01

¿Entonces con esos documentos tenemos acceso directo al hardware o no?, es que no me termina de quedar claro :loco:

Saludos...

esp3tek

23/09/2005, 07:03

segun nos explica wintern si... pero es verdad, explicaros un poco mas... Que nos abre esta documentacion secreta¿? :chupete: :chupete:

WinterN

23/09/2005, 07:06

la MMU (Memory Management Unit) es un chip que se ubica entre la CPU y el bus. Se encarga de gestionar la memoria de muchas maneras: paginación, segmentación, memoria virtual, permisos de acceso, traducción de direcciones lógicas a físicas, etc.

En algunos sistemas multiprocesador, los procesadores comparten la MMU, para acceder a la memoria, aunque este no parece ser el caso de la GP2X. En la GP2X el procesador principal tiene el uso exclusivo del MMU, mientras que el coprocesador accede directamente a memoria.

Aún no acabo de entender muy bien el significado de esto. Puede ser que el coprocesador solo pueda emplear direcciones físicas, o que deba trabajar sobre la misma página de memoria que el procesador principal.... Estoy estudiandolo, en cuanto sepa algo más lo posteo...

PD: Si me estoy equivocando en algo que alguien me corrija...

esp3tek

23/09/2005, 07:08

Esperamos impacientes tus progresos, y el de toda le gente que esta en ello

WinterN

23/09/2005, 07:58

¿Entonces con esos documentos tenemos acceso directo al hardware o no?, es que no me termina de quedar claro :loco:

Saludos...

A ver como lo explico. Para controlar la máquina necesitamos conocer principalmente 2 cosas: el código ensamblador que usa, y el mapeado de memoria.

En el primer caso se trata de código ensamblador del ARM, que está disponible y se usa desde hace tiempo, por ejemplo para programar la GP32.

Lo que nos faltaba hasta ahora era conocer el mapeado de memoria. El mapeado de memoria es el conjunto de direcciones de memoria sobre las que podemos escribir y/o leer datos. La memoria RAM está mapeada en la memoria, pero también lo están las teclas, el lector de tarjetas, el chip de video etc. A estas última se les suele llamar direcciones especiales, reservadas o de entrada/salida.

Es decir, para conocer desde ensamblador directamente el estado de una tecla, necesitamos sabes que dirección de memoria debemos leer y como interpretar lo que leemos...

Así que básicamente ésto es lo que explica el documento de MagicEyes. También explica otras muchas cosas, como pra qué es cada patilla del micro o los ciclos de reloj, pero a la hora de programar el micro y sacarle el 100% básicamente necesitamos conocer el mapa de memoria.

Por poner algunos ejemplos:
- Para activar el ahorro de energía de la pantalla (si lo tiene), basta con poner el bit nº15 de la dirección C000282h a 1, o a 0 para desactivarlo. Cada dirección tiene 16 bits numerados de 0 a 15.

- En la dirección C0001804h se controla el espejado de la imagen de salida de post-procesador de video. De forma que cada bit significa una cosa (origen/destino del espejado horizontal/vertical, etc).

- En la dirección E002001Ch se puede leer o establecer el color de fondo empleado en algunas operaciones por el acelerador 2D.

- En la dirección C0001532h podemos leer el tipo de mensaje que nos quiere mandar la controladora de SD/MMC cuando envía ella misma una interupción a la CPU (errores de lectura, operacion terminada, en espera de recibir comandos, etc)

Electric Dreams

23/09/2005, 08:07

En algunos sistemas multiprocesador, los procesadores comparten la MMU, para acceder a la memoria, aunque este no parece ser el caso de la GP2X. En la GP2X el procesador principal tiene el uso exclusivo del MMU, mientras que el coprocesador accede directamente a memoria.

Aún no acabo de entender muy bien el significado de esto. Puede ser que el coprocesador solo pueda emplear direcciones físicas, o que deba trabajar sobre la misma página de memoria que el procesador principal.... Estoy estudiandolo, en cuanto sepa algo más lo posteo...

PD: Si me estoy equivocando en algo que alguien me corrija...

Cuando llaman al 940t coprocesador siendo una CPU en toda regla, es por un motivo. El 940t está conectado al 920t mediante la interfaz del coprocesador, por lo que el acceso a memoria se debe realizar a través del procesador principal. El ARM 920t tiene instrucciones especificas para el intercambio de datos con el coprocesador, por lo que es un sistema bastante eficiente aunque no llega al nivel del multiproceso.

En la mayoria de los sistemas multiproceso actuales encontramos muchas variantes. En los Intel, los procesadores comparten el Bus Frontal que los conecta al chipset de la placa base, que es donde está el controlador de memoria. En los Opteron de AMD, sin embargo, el contrlador de memoria se encuentra en el propio procesador.

En los sistemas multiproceso, los procesadores nunca acceden a los mismos bancos de memoria y se divide la memoria del sistema en tantas partes como procesadores haya. Si la GP2X fuera un sistema de procesamiento en paralelo, tendría solo 32MB para cada procesador y creo que es una de las muchas razones por las que decidieron que la consola no procesara en paralelo.

Con las librerias bien implementadas, el procedimiento de acceso será transparante y se pueden obtener muy buenos resultados. Tengo que reconocer que la GP2X me da un buen "feeling" y espero no equivocarme.

WinterN

23/09/2005, 09:52

El 940t está conectado al 920t mediante la interfaz del coprocesador, por lo que el acceso a memoria se debe realizar a través del procesador principal.

Por lo que parece, según la documentación, el 940t no está conectado al interfaz de coprocesador del 920t directamente (aunque esto es lo que en un principio pudiera parecer). La comunicación entre los dos micros se realiza mediante unos registros compartidos y un sistema de interrupciones. Tal y como se describe aquí:

The MP2520F provides the Dual CPU I/F that allows two CPUs built in to transfer data to each other. In addition, it
provides 32 16-bit Data Registers that enables it to exchange data between the ARM920 CPU and the ARM940 CPU. The
Dual CPU I/F has two banks and each bank consist of 16 16-bit Registers. When a Register accesses a CPU, the Dual CPU
I/F can produce an interrupt to the other CPU. Every Register can produce an interrupt and provides an Interrupt Source
respectively.

Lo que parece bastante distinto a la forma de operar del interfaz de coprocesador que se describe en la documentación del 920T

Coprocessors determine the instructions they have to execute by using a pipeline follower in the coprocessor. As each instruction arrives from memory, it enters both the ARM pipeline and the coprocessor pipeline. To avoid a critical path for the instrution being latched by the coprocessor, the coprocessor pipeline must operate one clock pahse behind the AMR920T pipeline. The ARM920T then informs the coprocessor when instructions move from Decode into Execute, and whether the instruction has to be executed.

Según esto, tanto el procesador como el coprocesador deben trabajar a la misma frecuencia, y en el MP2520F pueden configurarse frecuencias diferentes para cada micro (vease tabla 5.3 en la página 119)

También hay algunas citas a la documentación de MagicEyes que me dan motivos para pensar que el 940t puede acceder directamente a memoria.

Nine memory bus masters including ARM920T (TM) CPU,
ARM940T(TM) CPU, Video Processor, Video Post Processor, 2D Graphic Processor, Image Signal Processor, LCD
Controller, USB Host and DMA can access either internal DRAM memory bus or Non-DRAM memory & Fast I/O bus
independently.

The Dual CPU I/F has functions to control the 8-bit upper Address of the ARM940 and to enable the ARM920 CPU to
control the ARM 940 reset.

Según he estado mirando en la documentación del 920T, el control memoria (a falta de MMU) es segmentado con un máximo de 8 segmentos de hasta 1GB. Sin embargo, en conjunción con el 940T me parece interesante esta última cita, que parece permitir especificar una especie de registro base para usar paginación con el 940T

Lo dejo por hoy que mañana me duermo y no llego al curro :sobando:

EDIT: Creo que por el momento voy a investigar un poco más por mi cuenta que ya me estoy dando cuenta de algunas burradas que dije al principio por sacar conclusiones anticipadas. Aunque intentaré dar mi opinión y responder preguntas sobre las cosas que esté más o menos seguro

WinterN

23/09/2005, 15:06

Esto quiere decir que se podrá controlar la salida de TV por software?
(archivo mmsp2_940_if.c)

Pues por lo visto va a ser así. Esto tiene su parte buena y su parte mala.

La parte mala es que los programas que no esten preparados para usar la salida de TV no podremos usarlos con dicha salida, a menos que los de GPH hayan programado algún driver que haga de puente o algo así.

La buena noticia es que como podemos detectar la salida de TV por software, podemos modificar la resolución de nuestras aplicaciones/juegos/emus para ajustarla a ésta, hasta los 1024x768 :babea: :babea: :babea:

Tampoco parece que vayamos a poder usar la salida de TV y la pantalla de la GP2X al mismo tiempo y ni mucho menos sacar cosas distintas por cada una.

EDIT: Creo que la cosa va a funcionar así:
Desde los menús de la consola podremos activar el TV-Out, de forma que la salida de la consola pasa a salir por dicha salida. Cualquier programa que se ejecute entonces aparecerá por la salida de TV esté o no preparado para ello.

Los programas que estén preparados puede detectar cuál de los dos modos está activo y ajustarse a él (por ejemplo el GPlayer a la hora de decidir en que resolución envía el video a la salida). También espero que se pueda cambiar este modo a través del SDK, para aquellos que carguen el soft antes del sistema operativo puedan hacerlo manualmente.

Wave

23/09/2005, 16:24

Según esto, tanto el procesador como el coprocesador deben trabajar a la misma frecuencia, y en el MP2520F pueden configurarse frecuencias diferentes para cada micro (vease tabla 5.3 en la página 119)

También hay algunas citas a la documentación de MagicEyes que me dan motivos para pensar que el 940t puede acceder directamente a memoria.

Cita:
Originalmente Escrito por Data Sheet, page 43
Nine memory bus masters including ARM920T (TM) CPU,
ARM940T(TM) CPU, Video Processor, Video Post Processor, 2D Graphic Processor, Image Signal Processor, LCD
Controller, USB Host and DMA can access either internal DRAM memory bus or Non-DRAM memory & Fast I/O bus
independently.

Por lo que he leido quiza sea que mientras un procesador accede a memoria el otro puede leer de la SD (principal de memoria, secundario de la SD). O uno a perifericos y el otro a la memoria flash.
Algo asi porque al parecer hay un bus para cada cosa.

EDIT: me he colao, WinterN se referia a que el ARM940t y el ARM920t son capaces de tomar el control del bus, de todos modos leí en algun lugar que habia 4 buses.

una-i

23/09/2005, 17:24

Es muy posible que este equivocado, pero la limitación del "coporcesador" por no tener mmu a mi enterder se puede explicar así, si por ejemplo tenemos codigo ejecutandose en el copro y le pasamos un puntero para que que escriba o lea datos... ese puntero tiene que ser un puntero mapeado en memoria fisica, es decir que no necesite la mmu.

Esto es algo que sucede por ejemplo en la xbox1 que pese a tener memoria unificada, la gpu necesita que la memoria de donde lee las texturas por ejemplo sea memoria que este fisicmante continua.

Para hacer esto tendremos que contar con alguna funcio especial del api/operativo, para pedir una allocacion de memoria fisica de un tamaño determinado qu seguramente tendra restriicciones de tamaños al tamaño de la pagina que tenga el operativo.

No es un gran problema pero habra que tenerlo en cuenta...

A600

12/10/2005, 01:28

Malas noticias:

The MMU is exactly the problem. Under Linux (which runs on the 920) all your program will see is virtual addresses, it doesn't know how to translate any virtual address to a physical address, and if you malloc 100KB, the memory will only be contiguous virtually - it could be scattered around in memory physically.

Now the 940 doesn't have an MMU, so expects physical addresses. Since you can't turn your virtuals into physicals or allocate contiguous physical memory, it will be difficult for both the 940 and 920 to process the same data without using a global physical buffer that is allocated by a device driver (which is exactly what the mpeg stuff does).

So, to use both processors properly, we need to either write our own device driver (without being able to rebuild the kernel) or chuck linux in the bin and do away with virtual addresses completely. A lot of devvers are all for throwing linux in the bin just to make life easier.

Chucking Linux in the bin also gives us another thing - lots more memory. The linux kernel and mpeg decoding routines and buffers/etc take up a lot of memory that we can't free in linux (as it's allocated at a physical address in memory on kernel bootup when the driver is initialised) but won't even get allocated if we jump in before linux.

The kernel on the gp2x doesn't have any modules - all the modifications are directly in the kernel.

We have asked GPH for the kernel source many times, and quoted the GPL, but they just say "We can not give you the source code to the kernel".

So, yes, they are breaking the GPL agreement - but what can we do about it? The only option left is to take them to court, and I think that's a little OTT myself.

We'll just have to make our own kernel, get it running, and then make it open. People will flash upgrade when they realise there emulators don't work on the old GPH provided kernel :)

(and before anyone asks, you can reflash the kernel of a gp2x with just a serial lead - no kernel needs to be present, so gp2x's killed by bad flashes should never occur)

Wonder Boy

12/10/2005, 05:47

Ante todo, ésto no es una mala noticia precisamente:

(and before anyone asks, you can reflash the kernel of a gp2x with just a serial lead - no kernel needs to be present, so gp2x's killed by bad flashes should never occur):-)

bulbastre

12/10/2005, 06:46

http://usuarios.arsystel.com/frangongue/gp2xlinuxdevicedriver.jpg

HAMIGOS NO SE HALEGREN NOMAS TODAVIA NO BEN QUE HEN REALIDAT NOS HECTAN BENDIENDO UN NINTENDOPERROS?? NO BEN HACASO EL DRIBER (CONDUCTOR) DE LA PANTAYA TACTIL Y EL WATCH-DOG (MIRA AL PERRITO WEI)??

bulbastre

12/10/2005, 06:59

A ver como lo explico. Para controlar la máquina necesitamos conocer principalmente 2 cosas: el código ensamblador que usa, y el mapeado de memoria.

En el primer caso se trata de código ensamblador del ARM, que está disponible y se usa desde hace tiempo, por ejemplo para programar la GP32.

Lo que nos faltaba hasta ahora era conocer el mapeado de memoria. El mapeado de memoria es el conjunto de direcciones de memoria sobre las que podemos escribir y/o leer datos. La memoria RAM está mapeada en la memoria, pero también lo están las teclas, el lector de tarjetas, el chip de video etc. A estas última se les suele llamar direcciones especiales, reservadas o de entrada/salida.

Es decir, para conocer desde ensamblador directamente el estado de una tecla, necesitamos sabes que dirección de memoria debemos leer y como interpretar lo que leemos...

Así que básicamente ésto es lo que explica el documento de MagicEyes. También explica otras muchas cosas, como pra qué es cada patilla del micro o los ciclos de reloj, pero a la hora de programar el micro y sacarle el 100% básicamente necesitamos conocer el mapa de memoria.

Por poner algunos ejemplos:
- Para activar el ahorro de energía de la pantalla (si lo tiene), basta con poner el bit nº15 de la dirección C000282h a 1, o a 0 para desactivarlo. Cada dirección tiene 16 bits numerados de 0 a 15.

- En la dirección C0001804h se controla el espejado de la imagen de salida de post-procesador de video. De forma que cada bit significa una cosa (origen/destino del espejado horizontal/vertical, etc).

- En la dirección E002001Ch se puede leer o establecer el color de fondo empleado en algunas operaciones por el acelerador 2D.

- En la dirección C0001532h podemos leer el tipo de mensaje que nos quiere mandar la controladora de SD/MMC cuando envía ella misma una interupción a la CPU (errores de lectura, operacion terminada, en espera de recibir comandos, etc)

Pero entonces, lo que conseguimos con esto es dominar el assembler, lo que significa rendimiento, y que la GP2X la podremos exprimir mucho mas que la GP32, voy mal?
Deduzco pues, que ninguna de estas ventajas nos las habian dado con GP32?

Porque entonces hay algunas que nos las deniegan?
Si nos pasamos por el forro y usamos Windows CE (que por ahi habia un manual de como meterlo) estas restricciones nos afectaran, es decir, son restricciones de soft o de hard? porque si son de hard, mal estamos.

Que juegos corren en Windows CE?
Voy a mirar

bulbastre

12/10/2005, 07:21

El alphablending estara muy limitado (ha comentado que solo a capas, pero no se que queria decir)
que es alpha blensing? Tiene que ver con el 3D?

bulbastre

12/10/2005, 07:23

- USB Host 1.1

No era 2.0.?????????????

bulbastre

12/10/2005, 07:26

El link me lleva a una página de ropa de plástico para tías :loco:
Pues hay uno en la pagina de squideY que postea:

"squidge is sexy"

Hay cada colgao por ahi XDD

Puck2099

12/10/2005, 07:38

Tío, ¿por qué no pones todas tus respuestas en un mismo post en vez de abrir uno por pregunta? :)

WinterN

12/10/2005, 07:38

Pero entonces, lo que conseguimos con esto es dominar el assembler, lo que significa rendimiento, y que la GP2X la podremos exprimir mucho mas que la GP32, voy mal?
Deduzco pues, que ninguna de estas ventajas nos las habian dado con GP32?

Porque entonces hay algunas que nos las deniegan?
Si nos pasamos por el forro y usamos Windows CE (que por ahi habia un manual de como meterlo) estas restricciones nos afectaran, es decir, son restricciones de soft o de hard? porque si son de hard, mal estamos.

Que juegos corren en Windows CE?
Voy a mirar

Las restricciones eran respecto al hard. MagicEyes, los fabricantes del micro principal de la consola, no ceden la documentación de la arquitectura a menos que firmes con ellos un NDA (acuerdo de no divulgación). Esto hacía que no se pudiera programar en código ensamblador y por tanto no se le podía exprimir al máximo la consola... hasta que se filtraron esos documentos.

Ahora el problema es que no nos facilitan el núcleo modificado de Linux. Aunque por ley deben liberarlo y supongo que lo acabarán haciendo...

Al 90% de los programadores, entre los que me incluyo, seguramente no nos afecten estas restricciones ya que no programaremos a tan bajo nivel. Aunque existe un 10% que serán los que hagan cosas realmente interesantes y quieran sacarle todo el jugo a la máquina.

Poco a poco se irá descubriendo lo poco que nos queda por saber. Si la PSP, que es un sistema tan cerrado, ha sido destripada, menos le quedará a ésta.

Del Windows CE mejor ni hablar :loco:. Aunque sería interesante si alguien lo consigue meter y ver que se puede hacer... pero ten por seguiro que si hoy no tenemos el linux libre al 100%, mucho menos libre sería un windows...