[OFICIAL]: Scene Dingoo A320

[booboo]

Muchas gracia booboo, qué ganas de poder ver a tux en mi Dingoo

Una preguntilla, sabes si el mplayer o el libjpeg que tiene colgado Ingenic usan el "multimedia accelerator" que se supone tiene el JZ4732(JZ4740)?.

No es un procesador acelerador dedicado, sino más bien un conjunto de instrucciones SIMD (single instruction multiple data) que vienen muy bien para aplicaciones multimedia.

Me consta que el mplayer que hay en el FTP de Ingenic sí que utiliza este conjunto de instrucciones.

Y la librería jpeg se llama "jpeg-6b-idctmxu-jz4740-080422.tgz", dado que el conjunto de esas instrucciones Ingenic lo denomina "MXU" sospecho que en efecto sí que hace uso de esa aceleración.

¿Podrá usarse para "agilizar" alguna tarea en el futuro?

Mientras los de Ingenic no proporcionen el manual de procesador con la descripción detallada del funcionamiento de cada instrucción, lo dudo. Sacar el funcionamiento de cada instrucción por ingeniería inversa, sobre todo teniendo ejemplos funcionales de código, es posible, pero es un faenón que no le deseo ni a mi peor enemigo.

[A600]

En el datasheet del jz4740 pone esto:

256×16 bits internal palette RAM

Se supone que si usamos un framebuffer de 8bpp, se copiarán a la GRAM del LCD los colores de 16 bits que tengamos definidos en la paleta, ¿no?

Esta es la función usada para definir la paleta:

static int jzfb_slcd_setcolreg(u32 regno, u8 red, u8 green, u8 blue)
{
	u16 *ptr, ctmp;

	if (regno >= NR_PALETTE)
		return 1;

	red	&= 0xff;
	green	&= 0xff;
	blue	&= 0xff;
	
	jzfb_slcd.palette[regno].red		= red ;
	jzfb_slcd.palette[regno].green	= green;
	jzfb_slcd.palette[regno].blue	= blue;
	
	if (jzfb_slcd.bpp <= 8) {
		if (((jzfb_slcd.cfg & MODE_MASK) == MODE_STN_MONO_SINGLE) ||
		    ((jzfb_slcd.cfg & MODE_MASK) == MODE_STN_MONO_DUAL)) {
			ctmp = (77L * red + 150L * green + 29L * blue) >> 8;
			ctmp = ((ctmp >> 3) << 11) | ((ctmp >> 2) << 5) |
				(ctmp >> 3);
		} else {
			/* RGB 565 */
			if (((red >> 3) == 0) && ((red >> 2) != 0))
				red = 1 << 3;
			if (((blue >> 3) == 0) && ((blue >> 2) != 0))
				blue = 1 << 3;
			ctmp = ((red >> 3) << 11) 
				| ((green >> 2) << 5) | (blue >> 3);
		}

		ptr = (u16 *)jzfb_slcd.pal;
		ptr[regno] = ctmp;
		REG_DMAC_DDA(dma_chan) = PHYS(&slcd_palette_desc);
	} else
		printf("No palette used.\n");

	return 0;
}

[booboo]

El tearing, por los posts que he leído, afecta más a unas Dingoos que a otras aunque yo en la mía no lo he notado en absoluto.

< - >

Exacto.

¿Puedes explicar cómo y por qué afecta al rendimiento?. Si lo entiendo bien quizás pueda intentar arreglarlo cuando me meta a fondo con el framebuffer.

[A600]

¿Puedes explicar cómo y por qué afecta al rendimiento?. Si lo entiendo bien quizás pueda intentar arreglarlo cuando me meta a fondo con el framebuffer.

¿8bpp vs 16 bpp? Tenemos que manejar el doble de bytes así que,sí o sí, tiene que afectar al rendimiento.

[booboo]

En el datasheet del jz4740 pone esto:
Se supone que si usamos un framebuffer de 8bpp, se copiarán a la GRAM del LCD los colores de 16 bits que tengamos definidos en la paleta, ¿no?

Esta es la función usada para definir la paleta:

En efecto, tiene pinta de que el LCD implementa internamente la paleta para modos de 8bpp, lo cual significa que modificando el código del driver framebuffer se debería poder hacer que el display soporte modos 8bpp de forma nativa.

Sin embargo hay dos "peros":

- Esperaba no tener que meterme a programar el controlador del display. Tuve que obtener los valores de inicialización de los registros (como unos 50 !!!) y su secuencia (con retardos y todo) desensamblando el .dl que venía con el unbricker. La idea era utilizar el mismo enfoque que usa el firmware original: se inicializa el LCD en un modo y se trabaja en ese modo sin volver a tocar nada.

- La forma en que está conectado el LCD en la A320 tiene muy mala sombra. Hay un pin que se llama RS# que se usa para indicarle al LCD si se va a acceder a un registro o a la memoria de imágen (tanto en lectura como en escritura). El controlador SLCD del JZ4740 controla automáticamente esta señal. Para ello usa el bit 31 del dato que escribes y lo pone en el pin correspondiente. Pues bien, resulta que, seguramente por un fallo garrafal de diseño en la A320 han conectado esta señal RS# del LCD al pin equivocado del JZ4740.

Obviamente la función de manejar RS# automáticamente está ligada a un pin concreto del JZ4740, de modo que al conectarla a otro pin estamos obligados a hacerlo manualmente (se configura como GPIO de salida y listo). Donde nos hubiéramos limitado a escribir un valor en el LCD, ahora tenemos que activar RS#, escribir el valor, y desactivar RS# (esta es una de las cosas que me llevó de calle para hacer funcionar el display y que no hubiera adivinado ni en mil años de no haber desensamblado el .dl).

Este "apaño" de manejar manualmente la señal RS# no supone un gran problema si usamos el LCD en un solo modo: al principio se escriben todos los registros de configuración y se deja el pin RS# desactivado. Se configura la DMA para que vaya escribiendo continuamente los datos al display y listo.

El problema es que si se quieren cambiar registros del display se podría hacer también usando DMA (sin más que activar el bit 31), pero no se puede por la chapuza. Hay que parar el DMA, modificar los registros, y volver a arrancar el DMA. O mejor aún, aprovechar para escribir los registros antes de iniciar cada ciclo DMA.

Como véis, la cosa se complica significativamente cuando podría ser muy fácil.

< - >

¿8bpp vs 16 bpp? Tenemos que manejar el doble de bytes así que,sí o sí, tiene que afectar al rendimiento.

Hasta ahí ya había llegado yo, simplemente quería saber si había alguna otra implicación que se me escapaba.

¿Se nota realmente tanto en el rendimiento?.

Lo digo porque con la cantidad se cosas que hay que hacer en un emulador, el -al final de toda la cadena- hacer una simple conversión 8bpp->16bpp usando una tabla paleta no me parece tan costoso (se haría en todo caso en el driver framebuffer). Es una percepción, no tengo mucha idea de emuladores.

[otto_xd]

Supongo que si la limitacion de los 8bpp se salta con una conversion, la perdida de rendimiento no sera tan grande, pero normalmente, cuando se usan los 16bpp creo recordar que se activan las tranparencias en los emuladores, y eso si que hace que la emulacion sea mas lenta, ya que todo se hace por micro, no hay apaño que valga, por eso lo de la perdida de rendimiento.

Pero bien pensado, no tiene porque ser asi en todos los emuladores.

Saludos

[A600]

Hasta ahí ya había llegado yo, simplemente quería saber si había alguna otra implicación que se me escapaba.

Ya lo suponía

Lo digo porque con la cantidad se cosas que hay que hacer en un emulador, el -al final de toda la cadena- hacer una simple conversión 8bpp->16bpp usando una tabla paleta no me parece tan costoso (se haría en todo caso en el driver framebuffer). Es una percepción, no tengo mucha idea de emuladores.

Así no creo que el rendimiento bajara demasiado. Con lo de la caída de rendimiento me refería a tener que trabajar a 16 bpp durante todas las operaciones que hiciéramos con la imagen.

[Nekete]

Disculpad si me salgo un poco de la temática pero, ¿de qué sirve una smart LCD?.
Se supone que tiene una memoria intermedia que "vuelca" a pantalla, pero ¿para qué sirve ésto en la vida real?.

Gracias y perdón por el offtopic.

[A600]

El problema es que si se quieren cambiar registros del display se podría hacer también usando DMA (sin más que activar el bit 31), pero no se puede por la chapuza. Hay que parar el DMA, modificar los registros, y volver a arrancar el DMA. O mejor aún, aprovechar para escribir los registros antes de iniciar cada ciclo DMA.

Como véis, la cosa se complica significativamente cuando podría ser muy fácil.

Pues menuda putada. Entonces, ¿para usar la función resize del ILI9325 hay que liar la de Dios?

[booboo]

Pues menuda putada. Entonces, ¿para usar la función resize del ILI9325 hay que liar la de Dios?

Esteeeee... ¿me puedes recordar qué es exáctamente esa función?

< - >

Disculpad si me salgo un poco de la temática pero, ¿de qué sirve una smart LCD?.
Se supone que tiene una memoria intermedia que "vuelca" a pantalla, pero ¿para qué sirve ésto en la vida real?.

Gracias y perdón por el offtopic.

Lo que voy a explicar es una simplificación, pero servirá:

Un display es una matriz de píxels. Los píxels no están iluminados contínuamente, ya que eso obligaría al display a "recordar" el estado de cada uno de ellos. Lo que se hace es un barrido iluminando sucesivamente todos los píxels de cada línea. Como el barrido es muy rápido el ojo humano no lo percibe y la persistencia de la visión hace el resto.

Por lo tanto, los LCD "tontos" no son más que una enorme matriz de píxels con unos cuantos chips controladores que lo único que hacen es permitir ir seleccionando e iluminando cada línea por separado. Alguien debe encargarse de ir haciendo el barrido con una temporización bastante precisa.

Esa temporización tan precisa (y para tantos datos) no se puede lograr programáticamente (mediante instrucciones de un procesador), de modo que se utiliza un controlador especial. En los SoC (system-on-chip) como el JZ4740 este controlador está integrado junto con la CPU y un montón de periféricos más en un sólo chip (de ahí lo de SoC). El controlador LCD lo que hace es, de forma independiente a la CPU, ir tomando los datos de una zona de memoria y enviándolos al LCD junto con las señales adecuadas para ir haciendo el barrido.

Todo eso es para los LCD "tontos". Necesitas un controlador externo que haga el barrido.

Los LCD inteligentes llevan el controlador de barrido integrado junto con cierta cantidad de memoria (como mínimo la suficiente para almacenar el estado de todos los píxels). De esta forma, para la CPU son poco más que una memoria externa en la que escriben las imágenes. El controlador integrado del LCD va leyendo su memoria intera y generando el barrido.

Decía que es paradójico que hayan utilizado un LCD inteligente en la A320 porque el JZ4740 lleva un controlador LCD propio y se podría haber utilizado un LCD "tonto" seguramente más barato, y porque la sincronización de las imágenes es más sencilla en este caso (insisto: siempre que la CPU disponga de un controlador LCD integrado).

[chipan]

Entonces por un error de diseño, implemetar el modo 8 bits supondría un trabajo que probablemente no compensaría en el rendimiento neto dado.

Esteeeee... ¿me puedes recordar qué es exáctamente esa función?

Si es lo que yo pienso, es una funcion que tienen algunos controladores y/o LCDs para ajustar a la resolucion nativa de la matriz del LCD imágenes de otras resoluciones. Esa funcion sirve para muchas cosas pero en estos foros la gente estará pensando principalmente en que la funcion de reescalado por hardware libera a la CPU de los cálculos necesarios para poner a pantalla completa los emuladores que tienen una resolución bastante diferente de la original del LCD.
En ejemplos prácticos... un emulador de Gameboy solo pinta un area de 166x144 pixels en el LCD y eso hace que se vea demasiado pequeño; lo que se hace normalmente es obligar al emulador a redimensionar esa matriz a la resolucion del LCD (ya sea con un simple reescalado por aproximación o usando filtros) antes de escribirla en el framebuffer, con el consecuente gasto de recursos que ello conlleva. Sin embargo con la funcion de reescalado del ILI9325 se podría hacer que el emulador enviase el area de 166x144 al ILI9325 y que éste, sin hacer que la CPU gastase un solo ciclo, hiciese que esa pequeña area ocupase la pantalla al completo.

Que me corrijan si me equivoco.

[booboo]

Estaba yo jugando a hacer ports rápidos de programas y me he acordado del gmenu2x que alguien mencionó (leed los comentarios del video!)

http://www.youtube.com/watch?v=-z8Dq9f5-h8

[A600]

Esteeeee... ¿me puedes recordar qué es exáctamente esa función?

Es una función que permite redimensionar una imagen con un factor 1/2 ó 1/4 ideal, por ej, para mostrar una imagen de 640x480. Copio/pego del pdf:

8.2.7. Resizing Control Register (R04h)
When the RSZ bits are set for resizing, the ILI9325 writes the data according to the resizing factor so that the original image is displayed in horizontal and vertical dimensions, which are contracted.

ILI9325 supports resizing function (x1/2, x1/4), which is performed when writing image data to GRAM. The resizing function is enabled by setting a window address area and the RSZ bit which represents the resizing factor (x1/2, x1/4) of image. The resizing function allows the system to transfer the original-size image data into the GRAM with resized image data.

Perfecto para jugar al Broken Sword 1/2 de PSX con el ScummVM que, a pesar de mostrarlos a 640x480, se ve claramente que la resolución original es 320x240.

< - >

Sin embargo con la funcion de reescalado del ILI9325 se podría hacer que el emulador enviase el area de 166x144 al ILI9325 y que éste, sin hacer que la CPU gastase un solo ciclo, hiciese que esa pequeña area ocupase la pantalla al completo.

^^

El ILI9325 no permite ese tipo de reescalados. Es mucho más simple y chusco

< - >

Estaba yo jugando a hacer ports rápidos de programas y me he acordado del gmenu2x que alguien mencionó (leed los comentarios del video!)

http://www.youtube.com/watch?v=-z8Dq9f5-h8

¡Perfecto!

Yo en la GP2X no lo llegué a instalar porque no la usé ni 10 horas pero, por lo que he leído, es bastante bueno.

[otto_xd]

Estaba yo jugando a hacer ports rápidos de programas y me he acordado del gmenu2x que alguien mencionó (leed los comentarios del video!)

http://www.youtube.com/watch?v=-z8Dq9f5-h8

Madreeeemiaaaaaaaaa, ya veras cuando lo pongan en dingoo-scene o como se llame la pagina, que locura xDDD

Por cierto, aqui si que va el autentico

[NEKRO]

¡Perfecto!

Yo en la GP2X no lo llegué a instalar porque no la usé ni 10 horas pero, por lo que he leído, es bastante bueno.

En la GP2X lo he usado poco pero en la Gizmondo lo tengo puesto como menú por defecto y mejora bastante la experiencia, todo está mucho más accesible y organizado. ¿Alguien sabe donde se puede bajar para la Dingoo?