Ver la versión completa : squide nueva utilidad
I wanted to put a battery monitor into my SNES emu to warn you to save when the batteries start getting low rather than just crashing, so I wrote a simple program that checks the voltage of the batteries. It can be used to check that your adaptor is functioning correctly too - ie, outputing a voltage within specification, so could be useful to some people.
You can get the executable here: http://www.squidgey.plus.com/voltage.gpe
The voltage is constantly checked until you press the START button to exit.
For rechargable batteries, 2.4V and below is considered "empty", 2.5v - 2.6v is considered "medium", and 2.7v+ is considered "full" (same as the battery status in the settings menu).
fuente gp32x
Wild[Kyo]
22/01/2006, 02:21
La verdad es que es una utilidad que tendría su gracia si viniera acompañada con el código fuente, ya que los programadores la podrían utilizar. Incluso se me ocurre la idea de que se podría hacer un actualizador de firmwares más seguro con esta utilidad, implementandolo en el ejecutable del firm, ya que miraria si quedan pocas pilas y no dejaria actualizar.
Gracias, no se sabe nada del codigo fuente?
segun he leido por este foro las mejoras del siguiente snes de squide como minimo son:
sonido
esta aplicacion segun juegas para que te de tiempo a grabar
los deseados savestates
transparencias y bugs arreglados
creo que en poco tiempo tendremos un snes 100%
jejejeje
mañana saldra el nuevo snes de squide
fuente gp32x , en los foros de emus
MeGaHeRz
22/01/2006, 02:34
Pues estaria bien que se iciera publico el codigo fuente de esta aplicacion mas que nada por lo del firmware... asseguraria la actualizacion del firmware....
hermes PS2R
22/01/2006, 16:13
Bueno, creo que estamos todos de acuerdo de que lo importante es el código fuente para poder hacer uso de esa utilidad en todos los programas... (se me ocurre que otros estamos aportando codigos fuentes de los que se beneficia todo el mundo, pero bueno, allá cada uno...)
ya esta publicado el codigo fuente , creo que esto nos va a ser de gran ayuda , jejejje
http://www.gp32x.com/board/index.php?showtopic=24882
fuente gp32x
hermes PS2R
23/01/2006, 04:34
ya esta publicado el codigo fuente , creo que esto nos va a ser de gran ayuda , jejejje
http://www.gp32x.com/board/index.php?showtopic=24882
fuente gp32x
Jejeje, pues si que era 'facil' ;) .
La verdad es que va a venir muy bien en todas las aplicaciones poder contar con un aviso de bateria baja, que a mi no es la primera vez que salvando el estado de un juego hacen las pilas pluffff y se corrompe el fichero (por eso le puse un 'mecanismo' para que salvara en un fichero temporal y evitar la perdida del save state antiguo).
Bien por Squidge por el 'truco' ;)
Wild[Kyo]
23/01/2006, 04:39
Jejeje, pues si que era 'facil' ;) .
La verdad es que va a venir muy bien en todas las aplicaciones poder contar con un aviso de bateria baja, que a mi no es la primera vez que salvando el estado de un juego hacen las pilas pluffff y se corrompe el fichero (por eso le puse un 'mecanismo' para que salvara en un fichero temporal y evitar la perdida del save state antiguo).
Bien por Squidge por el 'truco' ;)
Gracias inui64 por el link y evidentemente a Squidge por liberar el código fuente.
La verdad es que es una muy buena idea...a ver si alguien se anima y hace un sistema seguro para actualizar el firmware para que avise que se tienen las baterias bajas.
Lo acabo de subir para que lo tengais siempre a mano.
http://www.gp32spain.com/foros/downloads.php?do=file&id=350
He probado el nuevo emulador de squidgesnes y he probado a salvar la partida, he apretado el select me ha devuelto al menú, le he dado a save state y me ha devuelto al juego automáticamente. Mi sorpresa ha sido que al
intentar recuperar la partida (he avanzado en el juego) desde el momento de la grabación y sigo en el mismo sitio cuando el juego lo había grabado poco antes ¿Como puedo saber si realmente me ha salvado la partida? ¿Tengo que
poner la carpeta save junto a la rom para que me la guarde?
Lo que a mi m pasa es que la pantalla parpadea en la parte inferior, pero en la pantalla del juego (sin q el juego ocupe toa la pantalla de la gp2x). Me pasa con el Chrono Trigger, el unico que he probado. ¿Es normal?
hermes PS2R
23/01/2006, 07:08
Bueno, hoy es muy tarde (o mas bien, muy temprano :D) y no me apetece ahora pegar código aqui, etc,etc.
He probado a meter el códgo en mi emulador de spectrum y como se requieren 1000 lecturas y lleva tiempo medirlas, resulta que aunque yo le he puesto que mire el estado de las bateriias una vez cada minuto, pues esto se ralentiza durante unos segundos :/
Entonces, he procedido a modificar la rutina de lectura de estado para hacerla diferente y ahora es una funcion que cuando la llamas, te devuelve -1 si no está lista para devolver el resultado o el valor leido si ya terminó.
La funcion necesita ser llamada 1001 veces para obtener el resultado, luego está pensada para ponerse en un bucle y si por ejemplo, es llamada 25 veces por segundo, en unos 40 segundos devolverá el estado de la batería, lo cual no está mal (he tratado de hacer dos pasos por llamada, pero he visto que afecta a la velocidad del emulador y he pensado que con una medida cada 40 segundos, es suficiente)
Asi pues lo que pegaré mañana, consta de tres funciones:
-Una que lee en 1001 pasos el estado de la bateria
-Otra que se utiliza para cerrar el device (si no estaba cerrado ya) cuando queramos salir al sistema
-La ultima, necesita de la minimal library de rlyeh, ya que lo que hace es dibujar una pequeña batería en pantalla, de 15x8 pixeles y que muestra lo llena que está y si se alcanza los valores de estar acabandose, la propia funcion se encarga de hacer que parpadee el grafico para llamar la atencion ;) . Se puede poner en cualquier lugar de la pantalla (tiene codigo para autocorregir la posicion para prevenir un desborde de pantalla) y cambiar el color, aunque esta versión está pensada para 8 bits de color, pero vamos, es facil de modificar para el caso de 16 bits
En fin, que mañana lo cuelgo por aquí, que ahora me voy p'al sobre que toca madrugar...
Es una buena opción, Hermes. Está claro ke no hace falta leer el estado de la bateria en cada frame. Ya pensaba yo en una modificacion por el estilo. Pero no puuuuuedo hacer nada >_< Entre ke hoy tengo examen y ke mi GP2X está hibernando... Uff ke mono tengo ya O_O Anarchy, repárala y enviala de vuelta prontooo >_< La necesito! xD
Hola !
Estava mirando el codigo de Squidge, y aunque no tengo la GP2X para provar ... parece que hace 1000 lecturas para sacar una media (deve ser poco preciso....).
Asi que Hermes, no hace falta hacer 1000 lecuras ..... se puede provar con menos a ver si es "igual" de exacto .....
Bye !
hermes PS2R
24/01/2006, 01:38
Hola !
Estava mirando el codigo de Squidge, y aunque no tengo la GP2X para provar ... parece que hace 1000 lecturas para sacar una media (deve ser poco preciso....).
Asi que Hermes, no hace falta hacer 1000 lecuras ..... se puede provar con menos a ver si es "igual" de exacto .....
Bye !
Sip, ya me dí cuenta que hacia una media ;) .
El medidor es bastante impreciso, claro y se da la nota curiosa de que cuanto mayor es la velocidad de la CPU, mas 'llena' aparece la batería (ayer se me dió un caso de que a 166Mhz, me aparecía como un tercio vacía en mi indicador, en el que lleva de serie la consola a 200 Mhz, marcaba media batería, pero es que si pasaba la velocidad de 200 Mhz, me dice que batería llena en mi indicador...
Bueno, el problema es que si haces dos lecturas seguidas, como necesita esperar los resultados, ralentiza (a mi me ralentiza un bucle que llamo 25 veces por segundo pero que es mas rapido y y usa un timer para esperary evitar que vaya mas rapido de 25 veces/segundo
Obviamente, puedes leer de uno en uno y hacer la media que es lo que hacen estas rutinas:
static int devbatt=-1;
void battery_status_end()
{
if(devbatt>=0) close (devbatt);devbatt=-1;
}
int battery_status() // Thanks Squidge by the trick ;)
{
static int battval;
int i;
static int step=0;
unsigned short cbv;
int v;
if(step==0)
{
if(devbatt<0) devbatt = open ("/dev/batt", O_RDONLY);
if (devbatt<0) return -1;
battval = 0;
step++;
}
if(step<1001)
{
if (read (devbatt, &cbv, 2) == 2)
{battval += cbv;step++;}
return -1;
}
else
{
battval /= 1000;
// do a rough translation
if (battval > 1016) v = 37;
else if (battval > 974) v = 33;
else if (battval > 943) v = 32;
else if (battval > 915) v = 31;
else if (battval > 896) v = 30;
else if (battval > 837) v = 29;
else if (battval > 815) v = 28;
else if (battval > 788) v = 27;
else if (battval > 745) v = 26;
else if (battval > 708) v = 25;
else if (battval > 678) v = 24;
else if (battval > 649) v = 23;
else if (battval > 605) v = 22;
else if (battval > 573) v = 21;
else if (battval > 534) v = 20;
else if (battval > 496) v = 19;
else if (battval > 448) v = 18;
else v = 17;
step=0;
}
//v>26 Full
//v>24 Medium
//v<=24 Empty
return v;
}
// display a box of 15x8 with the battery status
{
void battery_box(int x,int y,unsigned char col,int volt)
int n,m;
static int flip=0;
flip++;
if((flip & 2)!=0 && volt<=24) return;
if(x<0) x=0;
if((x+14)>319) x=320-15;
if(y<0) y=0;
if((y+7)>319) y=240-8;
volt-=22;
if(volt<0) volt=0;
if(volt>4) volt=5;
volt<<=1;
m=y*320;
for(n=0;n<14;n++) {gp2x_screen8[x+n+m]=0;gp2x_screen8[x+n+m+7*320]=0;} // mask rectangle
for(n=0;n<3;n++) {gp2x_screen8[x+m]=0;gp2x_screen8[x+m+13]=0;m+=320;}
for(n=0;n<2;n++) {gp2x_screen8[x+m-1]=0;gp2x_screen8[x+m+13]=0;m+=320;}
for(n=0;n<3;n++) {gp2x_screen8[x+m]=0;gp2x_screen8[x+m+13]=0;m+=320;}
m=(y+1)*320;
x++;
for(n=0;n<12;n++) {gp2x_screen8[x+n+m]=col;gp2x_screen8[x+n+m+5*320]=col;} // rectangle
for(n=0;n<2;n++) {gp2x_screen8[x+m+11]=col;m+=320;}
for(n=0;n<2;n++) {gp2x_screen8[x+m-1]=col;gp2x_screen8[x+m+11]=col;m+=320;}
for(n=0;n<2;n++) {gp2x_screen8[x+m+11]=col;m+=320;}
m=(y+2)*320;
for(n=1;n<volt;n++) {gp2x_screen8[x+10-n+m]=col;
gp2x_screen8[x+10-n+m+320]=col;
gp2x_screen8[x+10-n+m+320*2]=col;
gp2x_screen8[x+10-n+m+320*3]=col;
gp2x_screen8[x+10-n+m+320*4]=col;
}
}
La funcion int battery_status() es la que debemos integrar en nuestro bucle. Ella sola se encarga de abrir el dispositivo y hacer la media, etc, pero devolverá -1 (durante 1000 llamadas) hasta que obtenga el valor. Esto significa que devolverá el estado de la batería cada 40 segundos a 25 fps, mas que suficiente creo yo
La función void battery_status_end() debe ser llamada cuando vayamos a salor del programa para cerrar el dispositivo.
Por ultimo, la función void battery_box(int x,int y,unsigned char col,int volt) está pensada para visualizar un grafico de una batería con indicadór en una pantalla que use paleta de 8 bits (cambiando el tipo del puntero puede ser de 16 bits, evidentemente). Cuando alcanza el nivel de 'vacío' comenzará a parpadear el gráfico. Muestra hasta 5 niveles de carga.
Los parametros x e y son las corrdenadas del pixekl de pantalla donde comenzará a dibujarse el grafico, col es el color con el que se dibujará (se emplea tambien el color 0 para hacer una mascara) y volt es el resultado de la función battery_satus()
La funcion int battery_status() es la que debemos integrar en nuestro bucle. Ella sola se encarga de abrir el dispositivo y hacer la media, etc, pero devolverá -1 (durante 1000 llamadas) hasta que obtenga el valor. Esto significa que devolverá el estado de la batería cada 40 segundos a 25 fps, mas que suficiente creo yo
La función void battery_status_end() debe ser llamada cuando vayamos a salor del programa para cerrar el dispositivo.
Por ultimo, la función void battery_box(int x,int y,unsigned char col,int volt) está pensada para visualizar un grafico de una batería con indicadór en una pantalla que use paleta de 8 bits (cambiando el tipo del puntero puede ser de 16 bits, evidentemente). Cuando alcanza el nivel de 'vacío' comenzará a parpadear el gráfico. Muestra hasta 5 niveles de carga.
Los parametros x e y son las corrdenadas del pixekl de pantalla donde comenzará a dibujarse el grafico, col es el color con el que se dibujará (se emplea tambien el color 0 para hacer una mascara) y volt es el resultado de la función battery_satus()
Umm se me ocurre una cosa, esto hace que de una lectura correcta cada 1001 llamadas... pensando en un uso del tipo de llamo cada frame y actualizo el grafico, obligas al usuario a mirar si devulves -1 si es distinto de -1 actualizar su "dato" etc... no seria mejor que al menos "recordasemo el ultimo valor "bueno" y lo devolviesemos mientras no tenemos otro más actual?, de hecho yo haria una primra lectura "valida" al inicializar y a partir de ahi ya devolveria siempre un valor bueno para que el usuario siempre tubiese un valor correcto.
O incuso mejor dependiendo de lo "exacto" de las mediciones, hacer en la inicializacion una medida "biuena" con 1000 lectuas o lo que sea y despues simplemente cada llamada ir haciendo una media ponderada con el resultado acumulado y que esto vaya "afinando" la lectura "incrementalmente". Esto es algo muy facil y con una linea tla que asi queda bastatne "mono"
valor_acumulado = (valor_acumulado*999 + valor_actual)/1000;
Asi al pasar 1000 llamadas habremos actualizado la media totalmente, si pones 99 y 100 pues se actualiza cada 100, incluso se podria hacer confiigurable el numero de lecturas por llamada y el peso de cada lectura, para hacer un balance de velocidad de actualización, exactitud y velocidad de ejecución.
Unai.
El medidor es bastante impreciso, claro y se da la nota curiosa de que cuanto mayor es la velocidad de la CPU, mas 'llena' aparece la batería (ayer se me dió un caso de que a 166Mhz, me aparecía como un tercio vacía en mi indicador, en el que lleva de serie la consola a 200 Mhz, marcaba media batería, pero es que si pasaba la velocidad de 200 Mhz, me dice que batería llena en mi indicador...
Ufff . que chapuzas :-((
Además, no tiene mucho sentido ... ya que si la CPU trabaja a mas ciclos, el consumo serà mas alto, por lo tanto el voltaje de las pilas bajarà.
Son capaces de haber ocnnectaro la V de la CPU en vez de la pila directamente ....
Otra posible "mejora", es hacer una primera media de 1000, y luego descartar los valores extremos muy lejanos de la media.
Si te dice inicialmente 2.2 V, y luego te dice: 3.2 o 1.5 .... pues de descarta.
Adios !
hermes PS2R
24/01/2006, 02:47
Umm se me ocurre una cosa, esto hace que de una lectura correcta cada 1001 llamadas... pensando en un uso del tipo de llamo cada frame y actualizo el grafico, obligas al usuario a mirar si devulves -1 si es distinto de -1 actualizar su "dato" etc... no seria mejor que al menos "recordasemo el ultimo valor "bueno" y lo devolviesemos mientras no tenemos otro más actual?, de hecho yo haria una primra lectura "valida" al inicializar y a partir de ahi ya devolveria siempre un valor bueno para que el usuario siempre tubiese un valor correcto.
O incuso mejor dependiendo de lo "exacto" de las mediciones, hacer en la inicializacion una medida "biuena" con 1000 lectuas o lo que sea y despues simplemente cada llamada ir haciendo una media ponderada con el resultado acumulado y que esto vaya "afinando" la lectura "incrementalmente". Esto es algo muy facil y con una linea tla que asi queda bastatne "mono"
valor_acumulado = (valor_acumulado*999 + valor_actual)/1000;
Asi al pasar 1000 llamadas habremos actualizado la media totalmente, si pones 99 y 100 pues se actualiza cada 100, incluso se podria hacer confiigurable el numero de lecturas por llamada y el peso de cada lectura, para hacer un balance de velocidad de actualización, exactitud y velocidad de ejecución.
Unai.
Si, se peude hacer que recuerde el ultimo valor obtenido se presente siempre, pero eso no quita que la primera vez, siempre obtengas -1 y leer como dices tu la primera vez, todo del tiron, hace que la maquina se PARE durante unos segundos.
Tienes dos opciones: o asignas un valor previo de por ejemplo, batería a tope o paralizas todo durante varios segundos y partes de ese valor inicial leido.
Pero eso no evita que por ejemplo, otra aplicacion abra el device y no lo cierre correctamente y al intentar abrir tu el device, falle devolviendo un valor negativo tambien.
En resumen: no existen soluciones perfectas y poco le cuesta a nadie añadir ese código extra desde fuera (o desde dentro)
Yo uso un codigo tal que así:
int volt=27;
int ret;
while(1)
{
ret=battery_status();
if(ret>=0) volt=ret;
......
battery_box(300,4,255,volt);
gp2x_video_waitvsync();
gp2x_video_RGB_flip(0);
}
Con eso lees la batería, pero a veces obtienes fluctuaciones en las medidas, y despues de decrecer la carga, de repente, parece que se carga!. Así que puedes optar por ser pesimista y poner siempre el valor mas bajo leido sustituyendo por esto:
ret=battery_status();
if(ret>=0) if(ret<volt) volt=ret;
y esto te garantiza que se almacene el menor valor leido y que no hayan fluctuaciones hacia arriba.
Evidentemente, ese código externo, se puede meter de forma interna si se quiere, pero tambien yo podría tomarme la molestia de programar por entero la utilidad/programa del individuo en cuestión y así no tendría que comerse el tarro [wei5].
En fin, si he puesto ese código es para que personas que están iniciandose en la programación, vean claramente lo que hay que hacer y al mismo tiempo, que lo adapten a su gusto y filosofía y para eso... no s elo puedes dar todo hecho ;)
hermes PS2R
24/01/2006, 02:56
Ufff . que chapuzas :-((
Además, no tiene mucho sentido ... ya que si la CPU trabaja a mas ciclos, el consumo serà mas alto, por lo tanto el voltaje de las pilas bajarà.
Son capaces de haber ocnnectaro la V de la CPU en vez de la pila directamente ....
Otra posible "mejora", es hacer una primera media de 1000, y luego descartar los valores extremos muy lejanos de la media.
Si te dice inicialmente 2.2 V, y luego te dice: 3.2 o 1.5 .... pues de descarta.
Adios !
Lo de la CPU por encima de 200MHZ, es un fenomeno logico: ten en cuenta que esto emplea algun tipo de contador y seguramente depende del reloj del sistema (que es el que cambias) y al hacerse ese tiempo mas corto, da como resultado que está mas lleno (seguramente el medidor de tension se base en medir el tiempo que tarda en descargarse un condensador, es decir: un conversor tension a frecuencia)
Pues es cuestión de provarlo ..... a ver cuanto te devuelve a 166 y a 200, y si es proporcional.
Bye !
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions Inc. All rights reserved.