Consola Powkiddy J6, pantalla 4,3",emula 8/16 bits, GBA y CPS1/2/Neo-Geo por 16/17€gi

**bitrider** · 13/12/2020, 15:33

La 7, cogiendo de Steward-fu y compilando para que me permita estático ya que por defecto viene como dinámico sólo. Probé la 10 de mil maneras y nada, la 9 creo que igual, con la 8 no he probado.

En el QEMU no me suena bien debido a que no me deja bajar el "period" hasta lo que necesita el emu pero en la V90 va estupendamente.

Queda muy resultón y el bilinear y no parece chupar muchos recursos. Estás tirando de APU fast o compatible ?

Por otro lado la SDL no da acceso al framebuffer con HWSURFACE y DOUBLE_BUFFER y queda flickering salvo que utilices el DelayedRasterFX que creo que daba problemas en algunos juegos.

**A600** · 13/12/2020, 16:21

Iniciado por bitrider

La 7, cogiendo de Steward-fu y compilando para que me permita estático ya que por defecto viene como dinámico sólo. Probé la 10 de mil maneras y nada, la 9 creo que igual, con la 8 no he probado.

Yo con la de Steward y gcc 10 no tuve problemas y para musl y gcc 10, convirtiendo todos los .cpp a .c cogiendo de base este commit tampoco.

Queda muy resultón y el bilinear y no parece chupar muchos recursos. Estás tirando de APU fast o compatible ?

Con cualquiera de los dos (las imágenes están tomadas con el compatible) no noto bajón en el rendimiento, pero puede ser debido a que igual la velocidad de las operaciones de memoria en el QEMU va a lo máximo que permita el PC y no es comparable con lo que pueda suceder en el hardware real.

Este es el código que uso modificando el de Wiz:

Código:

void gp_video_RGB_setscaling(int W, int H)
{
	uint16_t * pSource = (uint16_t *)pOutputScreen;
	uint16_t * pTarget = (uint16_t *)framebuffer16[currFB];
	unsigned short y;
	unsigned short x;

	if (H == 239)
	{
		for (y = 240; y != 0; y--)
		{
			pSource+=32;
			for (x = 64; x != 0; x--)
			{
				uint16_t  _1 = pSource[0];
				pTarget[0] = _1;
				uint16_t  _2 = pSource[1];
				pTarget[1] = Weight1_3( _1,  _2);
				uint16_t  _3 = pSource[2];
				pTarget[2] = Weight1_1( _2,  _3);
				uint16_t  _4 = pSource[3];
				pTarget[3] = Weight3_1( _3,  _4);
				pTarget[4] = _4;
				pTarget+=5;
				pSource+=4;		
			}
			pSource+=32;
		}
	}
	else // 224
	{
		pSource += 2560;
		unsigned short pos = 2;
		for (y = 240; y != 0; y--)
		{
			pSource+=32;
			for (x = 64; x != 0; x--)
			{
				uint16_t  _1 = pSource[0];
				pTarget[0] = _1;
				uint16_t  _2 = pSource[1];
				pTarget[1] = Weight1_3( _1,  _2);
				uint16_t  _3 = pSource[2];
				pTarget[2] = Weight1_1( _2,  _3);
				uint16_t  _4 = pSource[3];
				pTarget[3] = Weight3_1( _3,  _4);
				pTarget[4] = _4;
				pTarget+=5;
				pSource+=4;		
			}
			pSource+=32;
			pos--;

			if (pos == 0)
			{
				pSource -= 320;
				pos = 14;
			}
		}
	}
}

basado en https://github.com/m45t3r/snes9x2002...s/scaler.c#L31

El de alekmaul para el mame4all se ve bastante peor.

Código:

	if (H == 224)
	        bitmap_scale(32, 8, W, H, 320, 240, 320, 0, pSource, pTarget);
	else
	        bitmap_scale(32, 0, W, H, 320, 240, 320, 0, pSource, pTarget);

**bitrider** · 13/12/2020, 18:59

Uppss, qué curioso, entonces sólo con renombrar de .c a .cpp ya te funcionó o, además, aplicaste los parches del commit (veo que la mayoría son modificaciones vanales)?

A mí me va a 60 fps en hardware real el Super Mario Kart pero sin Scaling, con el DelayedRasterFX (es decir como compilar sin -D__OLD_RASTER_FX__), HWSURFACE, APU compatible, 22050Khz, stereo.

Si desactivo el DelayedRasterFX baja a 50 y pico porque además no puedo escribir directamente en el framebuffer y me veo obligado a usar uno intermedio (igual que si haces re-scaling).

**A600** · 14/12/2020, 02:58

Iniciado por bitrider

Uppss, qué curioso, entonces sólo con renombrar de .c a .cpp ya te funcionó o, además, aplicaste los parches del commit (veo que la mayoría son modificaciones vanales)?

Aplicando los parches, claro.

**A600** · 16/12/2020, 13:15

Iniciado por bitrider

salvo que utilices el DelayedRasterFX que creo que daba problemas en algunos juegos.

¿Recuerdas algún juego en particular con el que diera problemas?

Por fin me ha llegado la V90, pero hasta el fin de semana no podré cacharrear con ella. A ver si la espera ha merecido la pena

**bitrider** · 16/12/2020, 13:45

Ya era hora !!
No recuerdo ahora mismo pero dejo la opción en el menú de hacks por si las moscas.
He aplicado el parche y ya comienza a funcionar con gcc10 pero con caídas de rendimiento. Puedes probar si a ti te funciona bien el the Addams family: Pugsley's scavenger hunt?(cuando tengas tiempo;-) a mi me funciona antes de las modificaciones y con gcc7 después no.

**A600** · 16/12/2020, 13:58

En cuanto pueda lo pruebo. ¿Podrías subir la toolchain de gcc7 a algún sitio? Lo digo porque en el .config del buildroot no aparece para poder compilarla:

Código:

#
# GCC Options
#
# BR2_GCC_VERSION_8_X is not set
# BR2_GCC_VERSION_9_X is not set
BR2_GCC_VERSION_10_X=y
BR2_GCC_VERSION="10.2.0"
BR2_EXTRA_GCC_CONFIG_OPTIONS=""
BR2_TOOLCHAIN_BUILDROOT_CXX=y
# BR2_TOOLCHAIN_BUILDROOT_FORTRAN is not set
BR2_GCC_ENABLE_LTO=y
# BR2_GCC_ENABLE_OPENMP is not set
# BR2_GCC_ENABLE_GRAPHITE is not set
BR2_PACKAGE_HOST_GDB_ARCH_SUPPORTS=y

Muchas gracias.

**bitrider** · 16/12/2020, 18:01

Pillé el buildroot 2018.09.02 que indica steward-fu. Para compilar este quité un montón de libs que no me servían para bajar los tiempos de compilación (he compilado unas 7 u 8 versiones XD).
Te paso el enlace a lo que tengo: https://www.dropbox.com/s/let24w60jk...ic.tar.gz?dl=0

**A600** · 16/12/2020, 19:57

Para poder compilar en paralelo con -jN hay que añadir BR2_PER_PACKAGE_DIRECTORIES, aunque no sé si el buildroot de 2018.09.02 lo soportará y anda que no se nota compilando https://github.com/MiyooCFW/buildroot.git

**A600** · 20/12/2020, 03:14

@bitrider Por fin he podido probar lo que tenía compilado en la V90 y menudo chasco

Lo que en QEMU iba perfecto, en la consola va bastante peor y la versión que subiste tira bastante mejor.

**Shinosuke1991** · 05/01/2021, 14:24

A ver si alguien me hace un favorcito.

Viendo el hilo, me habeis hypeado bastante y pille una V90 yo tambien, que recibí ayer. No queria cacharrear mucho con ella, solo pretendo usarla para emular GBA y hasta el momento con el propio firmware de fabrica y todo bastante bien, casi todos los juegos que he probado y voy a jugar me han funcionado bien, sin ningun fallo. Pero ayer estuve intentando jugar a Mario Power Tennis, con copia de seguridad en version EUR (la unica que he encontrado, he probado 2 distintas pero el mismo error) y no pasa de la pantalla inicial.

A ver si me confirmais los que hayais actualizado o useis otro FW si conseguis ejecutar dicha ROM.

Gracias

**A600** · 05/01/2021, 18:44

No parece que sea compatible con el gpsp:

https://www.reddit.com/r/gba/comment...ut_this_cheap/

**Shinosuke1991** · 06/01/2021, 00:01

Gracias! Intentaré crear un save despues de la intro a ver si asi puedo solventar el tema.

Saludos!

**Damyos02** · 29/01/2021, 10:50

@bitrider @A600

He llegado a este post busco información de la persona que subió a dingocity el port de Drpocketsnes para la powkiddy.

Hace poco recibi una Q90 y vi que la emulación de SNES era bastante regulera, sobre todo en los juegos que me interesan como Fzero, buscando por "san google" acabe en el post de dingocity, instale el port de Drpocketsnes y me quede alucinado, el Fzero a 60fps pero cuando me dio por jugar al Final Fantasy VI me di cuenta de 2 bugs: No funcionan los savestates, es decir, los graba (incluso si miras en la carpeta ves que a creado el archivo) pero no se pueden cargar; el otro bug es un poco más jodido lo que viene siendo el botón "X" no funciona, así que no se puede entrar en el menú este Final Fantasy parece como si no estuviese mapeado en el emulador.

Si necesitáis alguien para testear más cosas aquí me tenéis, y gracias otra vez por el curro que os pegáis.