Ver la versión completa : Mi libreria de uso de doble CPU y control de frecuencia
hermes PS2R
09/12/2005, 04:15
Buenas,
tal y como dije el otro día en el foro general, aquí os dejo la libreria que he hecho para control de ambos procesadores con ejemplos.
La libreria en cuestion se llama cpuctrl.c y contiene metodos para:
- Apagar el 940t
- Cargar un programa en el 940t
- Parar el 940t
- Poner en marcha el 940t
- Ajustar/leer la frecuencia de reloj
- Ajustar/leer los divisores de frecuencia para 920, 940 y DCLK
- Tambien dispone un metodo para salvar/cargar ciertos registros para volver al sistema con los valores correctos
Me he basado en los fuentes de squidge y tambien en los fuentes publicados hasta ahora y por supuesto, la minimal library 0.5 de rlyeh que he utilizado en mi programa Pintor.
El ejecutable de prueba se llama dualcpu.gpe y lo que hace es poner como frecuencia de trabajo 200Mhz (el firm que yo tengo trabaja a 220Mhz!), cargar el ejecutable del 940t y esperar a que pulses A para calcular una operacion en el 940t de forma paralela.
OBSERVACIONES:
- Si se saliera del programa si usar la funcion load_system_regs() y se hace ajustes en los divisores o en la frecuencia o se apaga el 940t, los programas del sistema (como el reproductor de MP3) se ven afectados. asi que es una buena forma de ahorrar pilas ahí tambien :)
-Si compilais el codigo de 940, recordad copiar 940tcode.h al directorio dualcore para que se enlace con la aplicacion al compilar
En fin, un saludete y espero vuestros comentarios y sugerencias ;)
ACTUALIZADO: Version 1.02 que corrige DEFINITIVAMENTE los problemas de ajuste de reloj de los que se ha hablado a lo largo del hilo
:arriba: :arriba:
Dando guerra como siempre hermes :musico:
creo k lo de
- Apagar el 940t
Seria un gran paso para ahorrar las pilas :P
k kieres decir con k se ve afectado el reproductor mp3??
PD: Cuando vi k trastearias la gp2x ya se me caia la baba, viendo lo k hiciste con la ps2 , no me kiero imaginar lo k haras con la gp2x :babea: :babea:
otro que va a mi lista de gente para hacerle un monumento :D
great work! impresionante!
LukStarkiller
09/12/2005, 04:39
k kieres decir con k se ve afectado el reproductor mp3??
Si no me equivoco el 940t es posible que lo este usando el reproductor para procesar el audio, a saber alomejor me equivoco, pero pro lo que tengo entendido es una posibilidad y seguroq eu se refiere a o que deja de funcionar o que funciona mal, alguien que tenga la GP2X y queira provarlo ya lo dira ^^
por ceirto excelente trabajo tio a este paso si se prepara bien al cosa gastara emnos bateria que un rerpoductor normal de mp3 XD
parece que tenemos escene :)
a ver si eso hace que las pilas no se agotan tan rapido como dicen....a mi gp32 le duran mucho la verdad
saucjedi
09/12/2005, 04:54
¡Al fin se pueden ir dando los primeros pasos! Mi mas sincera enhorabuena por este trabajo. Habra que empezar a trastear un poco
Esto parece un gran paso adelante, muchas gracias por tu trabajo :brindis:
¿ Alguien se anima a hacer un ejecutable que desconecte uno de los dos procesadores ? Creo que esta podria ser la primera utilidad practica para esta libreria.
Saludos.
en realidad hay 2 utilidades wenas para esta libreria
1º Ahorro de pilas -> Apagando el procesador
2º Overclocking -> subirla a.... 250 mhz... o hasta k las pilas aguanten ? :babea: :ametra: :canon2:
en realidad hay 2 utilidades wenas para esta libreria
1º Ahorro de pilas -> Apagando el procesador
2º Overclocking -> subirla a.... 250 mhz... o hasta k las pilas aguanten ? :babea: :ametra: :canon2:
Según las specs de MagicEyes, los micros son a 266Mhz, por lo que hasta esa frecuencia deberían ponerse sin riesgo. :)
aguanta hasta 266 mhz cada uno, pero come pilas como una condená
Puck2099
09/12/2005, 05:33
Según las specs de MagicEyes, los micros son a 266Mhz, por lo que hasta esa frecuencia deberían ponerse sin riesgo. :)
¿Y las memorias aguantarían la subida? Recordemos que lo que limitaba el overclocking en la GP32 era la RAM :)
Saludos
¡Gracias!
Creía que sabía C, pero líneas de código como "volatile unsigned short *MEM_REG;" o "system_reg.DUALINT940=MEM_REG[0x3B42>>1];" pueden conmigo. Hermes y Rlyeh (y supongo que unos cuantos más), qué cosas más raras programáis, c0ño... :)
AguilaBlanca
09/12/2005, 05:36
No estoy seguro, pero lo que se aumenta no es el multiplicador de cada CPU? ene se caso no tendría que afectar a la RAM ¿no? solo que no funcionarían sincronizadas las CPU de la RAM (puede que me equivoque XD)
¿Y las memorias aguantarían la subida? Recordemos que lo que limitaba el overclocking en la GP32 era la RAM :)
SaludosBajo HH ya han probado a ponerlos a 266Mhz sin problemas :D
Creo que el problema del overclock, seria que crearia un cuello de botella, es decir que la ram no podria "aceptar"todos los datos que le llegan de los micros no?Lo que hay que conseguir es una estabilidad de velocidad entre el micro y la ram, corregidme por favor :chupete:
Hasta otra
no entiendo mucho komo acerlo, si apago el segundo micrio consumira menos no???
pero komo lo pngo por + por - o por *???
saludos
hermes PS2R
09/12/2005, 06:03
Bueno, estoy testeando un programa que utiliza estas funciones y anula el 940 y permite ajustar la frecuencia de los procesadores, etc
Lo primero que llama la atencion, es que si bajamos la frecuencia del FCLK lo suficiente, se aprecia parpadeo y scanlines en la pantalla y si la subimos tiende a desaparecer.
Sobre overclocking, al menos tocando estos valores, el valor de frecuencia mas alto estable, es de 220MHZ y con 240MHZ he conseguido que funcione (teniendo una imagen sin parpadeos) pero me veo obligado a ajustar el divisor a 1 (equivale a dividir por 2) o la maquina se cuelga.
Todas estas cosas se resumen en que si queremos ajustar la frecuencia d elos procesadores, lo mejor es jugar siempre con un valor suficientemente alto de FCLK y ajustar los divisores correspondientes.
Segun los fuentes de uboot la frecuencia seria FCLK/(div+1) donde div tiene un valor de 0 a 7
Si os esperais un poco, cuelgo la utilidad en el foro general
hermes, tengo una curiosidad. Si se ejecuta tu utilidad y se coloca la CPU principal por ejemplo a 220Mhz o 233Mhz... ¿todo el software que se ejecute después de esta y que no envíe ordenes de cambio de velocidad al micro funcionará a la velocidad que se le haya indicado previamente? De ser así sería interesante probarlo con algunos emuladores :D
hermes, tengo una curiosidad. Si se ejecuta tu utilidad y se coloca la CPU principal por ejemplo a 220Mhz o 233Mhz... ¿todo el software que se ejecute después de esta y que no envíe ordenes de cambio de velocidad al micro funcionará a la velocidad que se le haya indicado previamente? De ser así sería interesante probarlo con algunos emuladores :D
Yo me apostaría unas cervezas a que la respuesta a esa pregunta es SI (y no lo he probado que conste). :brindis:
hermes PS2R
09/12/2005, 06:55
hermes, tengo una curiosidad. Si se ejecuta tu utilidad y se coloca la CPU principal por ejemplo a 220Mhz o 233Mhz... ¿todo el software que se ejecute después de esta y que no envíe ordenes de cambio de velocidad al micro funcionará a la velocidad que se le haya indicado previamente? De ser así sería interesante probarlo con algunos emuladores :D
Si, de hecho, si bajas la frecuencia bastante en el repro de MP3 se entrecorta o en mi juego Pintor la cosa se ralentiza mucho (en el Player de Divx la cosa se suele poner malita...)
He dejado la utilidad aquí:
http://www.gp32spain.com/foros/showthread.php?t=25205
Aunque no he dejado valores de overclocking para no tener problemas...
Coñeeeee. Pon al menos que se pueda subir hasta 220Mhz, que es solo un 10% y ya nos serviría para poder probar si se notan cambios en el emu de neogeo cd, el de psx, snes, etc... :)
Ah, y si quieres enviarme una versión que pueda subir hasta 266Mhz por e-mail, no hay problema. Tengo una unidad sobre la que puedo hacer pruebas sin miedo a cascarla, ya que es de las primeras que mandaron con el hardware sin acabar :)
hermes PS2R
09/12/2005, 07:23
Coñeeeee. Pon al menos que se pueda subir hasta 220Mhz, que es solo un 10% y ya nos serviría para poder probar si se notan cambios en el emu de neogeo cd, el de psx, snes, etc... :)
Ah, y si quieres enviarme una versión que pueda subir hasta 266Mhz por e-mail, no hay problema. Tengo una unidad sobre la que puedo hacer pruebas sin miedo a cascarla, ya que es de las primeras que mandaron con el hardware sin acabar :)
A 220Mhz, hay fallos raros en la pantalla y cuelgues cuando le da la gana. A 240 si no activo el divisor a 1 (que en ese caso, todo tira a 120 Mhz) se cuelga tambien e incluso con el divisor, aprecio unas bandas de interferencia en la pantalla...
Es posible que si se mete un divisor mayor en DCLK se pueda aumentar algo la frecuencia (habra que probar) y tambien recuerdo haber visto unos registros para ajustar el timing de RAM, pero vamos, todo es cosa de estudiarlo en su debido momento :P
joe, que hace 2 dias no tenía ni puñetera idea de nada, porque de hecho, no tengo información de ningún tipo, salvo la que proporcionan los fuentes que se han publicado y uno que anda avispado para obtener por ejemplo, la frecuencia del sistema indirectamente usando un log que colgó si no me equivoco, efegea. Asi que calma en las trincheras, que apenas he tenido tiempo de asimilar la info que he posteado ;)
Ok, ok :D
Hace un tiempo creo que alguien de los que estaba desarrollando o testeando el HH (el arranque directo sobre hardware) dijo que habían comprobado los micros a 266Mhz sin problemas. Quizá tenga algo que ver con el timing.
Cuando vayas avanzando ya sabes quien te lo puede testear, siempre que no me explote en la cara, claro :D :D :D
Un saludo
Anarchy
Pues la verdad es ke de lo ke hablais entiendo el 0.00000001 % y ese misero 1 es porke hablais el mismo idioma ke yo sino seria el 0% jajaja.
Que recomendais ke se use el programa ese para dejar solo el uso del primer cpu? si lo hiciera no cambiaria nada con respecto a los emus, el rep. mp3 y de videos no?
salu2.
Pues la verdad es ke de lo ke hablais entiendo el 0.00000001 % y ese misero 1 es porke hablais el mismo idioma ke yo sino seria el 0% jajaja.
Que recomendais ke se use el programa ese para dejar solo el uso del primer cpu? si lo hiciera no cambiaria nada con respecto a los emus, el rep. mp3 y de videos no?
salu2.
Es ideal si por ejemplo vas a usar un juego/emulador/aplicacion que no precisa de muchos recursos, o si por ejemplo vas a reproducir mp3. Reduciendo la frecuencia ganarás mucho más tiempo de duración de las pilas :)
mmmm y videos?
También. Lee lo que ha puesto Quest en el otro hilo:
http://www.gp32spain.com/foros/showthread.php?p=298960#post298946
Puck2099
09/12/2005, 15:12
Mira que bien me van a venir estas librerías para desactivar el segundo procesador en el código de mis juegos :)
Una duda que tengo, ¿sabéis si estos micros tienen instrucciones de idle en las que se "apaguen"? Para concretar, ¿gastarán más pilas con los dos micros trabajando que con los dos micros encendidos sin más?
Saludos
joe, que hace 2 dias no tenía ni puñetera idea de nada, porque de hecho, no tengo información de ningún tipo, salvo la que proporcionan los fuentes que se han publicado y uno que anda avispado para obtener por ejemplo, la frecuencia del sistema indirectamente usando un log que colgó si no me equivoco, efegea. Asi que calma en las trincheras, que apenas he tenido tiempo de asimilar la info que he posteado ;)
Te recomiendo que eches un vistazo a los documentos de esta página (http://fear.me.uk/gp2x/). Especialmente a los dos primeros.
Ah! si usas el acrobat reader tendrás que instalar el plugin para las fuentes coreanas, aunque todo el texto es en inglés.
hermes PS2R
09/12/2005, 17:24
Bueno, hago una advertencia de que estoy revisando la libreria y subire las actualizaciones hoy.
Os cuento el problema, que actualmente, ya tengo resuleto pero es que ocurre una cosa increible...
Para desarrollar esta lib, me he basado en los fuentes que se liberaron de U-Boot sobre todo. Según esos fuentes, la velocidad del reloj del sistema, es de 7372800 Hz, pero utilizando las formulas presentes en en speed.c, me encontre con un extraño problema: resulta que la gp2x estaba trabajando a una frecuencia imposible, por lo que descarté que el reloj del sistema tuviera esa frecuencia.
Entonces recordé el log de booteo que había colgado efegea y le eché un vistazo por si aparecia algo que pudiera mostarme el camino. En ese log, aparece visualizada la frecuencia de reloj FCLK junto con los valores de Multiplicador, Divisor y Escala del Divisor.
Con estos ultimos valores y haciendo una pequeña ecuacion, me fue facil determinar que la velocidad del sistema debería corresponder a unos 2726927Hz y con eso he estado trabajando hasta ahora.
PERO, me parecia muy raro estas cosas:
1) Que usando estas formulas, el sistema iba con un reloj mayor de 200 Mhz, cuando debería ser de 200Mhz (igual que en el log del boot de efegea, aunque es un boot distinto)
2) La velocidad informada es de 220Mhz, pero si la grabo, el Player Divx me peta o el sistema hace cosas raras
3) raro es que la frecuencia del systema sea distinta a la que se ve en los includes.
Con eso he llegado a la conclusion facil de que hay algo que no acaba de cuadrar, sobre todo cuando Anarchy comenta que s eha podido overclockear la consola a 266 Mhz y funcionaba
Así que recurriendo al log he calculado otras frecuencias mostradas y no coincide la frecuencia del sistema.
Así que he recurrido a hacer calculos nuevos basandome en la frecuencia de los includes y he averiguado que el problema está en que el fuente de speed.c no es correcto y hay que hacer unas correciones en el divisor.
El problema es el siguiente: tengo la formula apropiada y por ejemplo, si pido la frecuencia UCLK , me da la MISMA que en el log, pero cuando pido la de FCLK, ahí es donde está el problema: tengo el factor de multiplicacion adecuado en el registro, pero NO el de division.
La verdad es que me tiene comido el tarro :/, segun esto, la gp2x viaja a casi 300Mhz, así que o es un bug que tiene el kernel y pone una frecuencia inapropiada, o hay que hacer una ligera correccion en el divisor de la formula para que me de el valor apropiado, pero en ese caso, el valor de UCLK no sería bueno (me da un valor 1,5 veces menor).
Aqui teneis parte del log que colgó efegea:
MP2520F FCLK: 199065600 Hz, M = 0x49 P = 1 S = 0
MP2520F UCLK: 95846400 Hz, M = 0x60 P = 0 S = 2
MP2520F ACLK: 147456000 Hz, M = 0x98 P = 0 S = 2
Pues bien, el problema que tengo es que en FCLK, P=0 leido directamente (cuando en el log es 1) y para el calculo la formula es algo así:
freq=(CLOCKSYS*(M+8)) / ((P+2)<<S), con lo que se obtienen cerca de 300Mhz al menos con el firmware que yo tengo :rolleyes:
La verdad es que me tiene comido el tarro :/, segun esto, la gp2x viaja a casi 300Mhz, así que o es un bug que tiene el kernel y pone una frecuencia inapropiada, o hay que hacer una ligera correccion en el divisor de la formula para que me de el valor apropiado, pero en ese caso, el valor de UCLK no sería bueno (me da un valor 1,5 veces menor).
pues si es cierto ke va a 300MHz,tenemos makina para rato;o hasta ke se gasten las pilas [wei4]
Puck2099
09/12/2005, 17:55
pues si es cierto ke va a 300MHz,tenemos makina para rato;o hasta ke se gasten las pilas [wei4]
Espero que no sea verdad, porque si fuera a 300 MHz adios al overclocking para que fueran más rápidos los emus...
Espero que no sea verdad, porque si fuera a 300 MHz adios al overclocking para que fueran más rápidos los emus...
Seguro que con el tiempo podria depurarse el codigo para que funcionasen a 200 igual que a 300 MHz, pero entretanto y contando con un cargador de corriente el excesivo consumo podria considerarse un mal menor frente al beneficio de poder usar esos emuladores al 99%.
Saludos.
Puck2099
09/12/2005, 18:01
Seguro que con el tiempo podria depurarse el codigo para que funcionasen a 200 igual que a 300 MHz, pero entretanto y contando con un cargador de corriente el excesivo consumo podria considerarse un mal menor frente al beneficio de poder usar esos emuladores al 99%.
Saludos.
Ya, Fosfy, pero me refiero a que si ahora mismo va la consola a 300 MHz y aun así queda mucho para que vayan perfectos algunos emus, nos estaríamos quedando sin la opción de subir más la consola (porque dudo mucho que pase de los 300 MHz) para que vayan al 99%.
Saludos
hermes PS2R
09/12/2005, 18:12
Pues llamadme loco si quereis.. pero si ajusto el tema de forma que me informe 200Mhz en vez de los 298Mhz (haciendo bueno ese divisor a 0), incluso programando la frecuencia a 200Mhz PETA, es imposible pasar de esos 200Mhz.
Sin embargo si utilizo los valores, tal y como deberian ser (entendiendo como buena esa frecuencia de 298Mhz teorica), puedo poner 266Mhz sin ningun problema .
He hecho un downgrade a 1.0, pero como suponia, no se ha corregido el problema, ya que es cosa del boot.
Supongo que para conocer si es un problema de la actualizacion del boot, debería probar la aplicacion alguien que tenga una gpx2 con el boot 1.0 (en ese caso si la aplicacion que estoy haciendo informa 200Mhz en vez de 298Mhz, ya sabemos donde esta el problema)
En fin, yo creo que así como lo tengo es la forma correcta: ya digo que de la otra forma no puedo subir de 199Mhz o se cuelga directamente :rolleyes:
Actualizo en unos minutos tanto esta lib como la de control de velocidad del foro general.
Ya, Fosfy, pero me refiero a que si ahora mismo va la consola a 300 MHz y aun así queda mucho para que vayan perfectos algunos emus, nos estaríamos quedando sin la opción de subir más la consola (porque dudo mucho que pase de los 300 MHz) para que vayan al 99%.
Saludos
Ups!, malinterprete tus palabras :D
Por cierto, y offtopiqueando un poco; ¿ te llego a funcionar la ddr que te envié ?
Saludos.
Pues llamadme loco si quereis.. pero si ajusto el tema de forma que me informe 200Mhz en vez de los 298Mhz (haciendo bueno ese divisor a 0), incluso programando la frecuencia a 200Mhz PETA, es imposible pasar de esos 200Mhz.
Sin embargo si utilizo los valores, tal y como deberian ser (entendiendo como buena esa frecuencia de 298Mhz teorica), puedo poner 266Mhz sin ningun problema .
He hecho un downgrade a 1.0, pero como suponia, no se ha corregido el problema, ya que es cosa del boot.
Supongo que para conocer si es un problema de la actualizacion del boot, debería probar la aplicacion alguien que tenga una gpx2 con el boot 1.0 (en ese caso si la aplicacion que estoy haciendo informa 200Mhz en vez de 298Mhz, ya sabemos donde esta el problema)
En fin, yo creo que así como lo tengo es la forma correcta: ya digo que de la otra forma no puedo subir de 199Mhz o se cuelga directamente :rolleyes:
Actualizo en unos minutos tanto esta lib como la de control de velocidad del foro general.
Muchisimas gracias de nuevo :brindis: :brindis: :brindis:
Puck2099
09/12/2005, 18:15
Ups!, malinterprete tus palabras :D
Por cierto, y offtopiqueando un poco; ¿ te llego a funcionar la ddr que te envié ?
Saludos.
Pues si te digo la verdad, todavía no he sacado un rato para probarla :(
Ahora estoy empleando mi poco tiempo libre en portar el LK a la GP2X...
Saludos
Ya, Fosfy, pero me refiero a que si ahora mismo va la consola a 300 MHz y aun así queda mucho para que vayan perfectos algunos emus, nos estaríamos quedando sin la opción de subir más la consola (porque dudo mucho que pase de los 300 MHz) para que vayan al 99%.
Saludos
vaya,pues yo pensaba ke la consola va a 200MHz pero ke se podria poner a 298MHz sin overclokear.de todas formas todavia solo se ha utilizado un procesador para los emus,ya veremos.
Las especificaciones iniciales de la consola eran de 10h de pila a 200Mhz, ahora se ve que a penas llegamos a las 5 o 6 h y se sospecha de que pudiera ir la consola a 300Mhz... creo que las cosas empiezan a cuadrar.
Al final me veo que lo suyo sera tener un bootloader que cargue el linux a peticion del usuario, y paralelo a el (y a mas bajo nivel y si no se carga el linux mediante un lilo o un gurb) un arranque tipo al de la GP32.
freq=(CLOCKSYS*(M+8)) / ((P+2)<<S), con lo que se obtienen cerca de 300Mhz al menos con el firmware que yo tengo :rolleyes:
ROFLMAO :shock:
mortimor
09/12/2005, 18:52
Y, si esto es cierto, todas las aplicaciones que parecen tener tanto futuro en realidad estan tirando casi del maximo de la potencia de un procesador, lo cual haria necesario utilizar medianamente bien el segundo procesador para obtener un resultado similar co un consumo de pilas "normal".... uuuyyyy
No especulemos, que no hay datos concluyentes :p
hermes PS2R
09/12/2005, 18:57
ROFLMAO :shock:
Si, bonita formula ¿eh? (la anterior sumaba al divisor 1, en vez de 2 (que por cierto, en los fuentes aparece como comentario)
Ya estan actualizadas las aplicaciones, con los fuentes, aunque me parece increible que haya estado trabajando a 298 Mhz en casi todo (pero por otro lado eso explica que cuando ajustabamos una frecuencia baja, el procesador tuviese potencia para mover una pelicula o reproducir un mp3, ya que antes la frecuencia ajustada era superior). Tambien explica que chupe pilas como una condenada la maquina (pilas de 2300 MA fundidas en 2H 40 Min no es moco de pavo)
Entonces a ver si me aclaro: segun tus especulaciones...
-Realmente la consola va a 300 mhz
-Tu programita cree que va a 200mhz por lo tanto cuando la ponemos a 133 realmente la estamos poniendo a 200mhz, no? y cuando bajamos a 100 va a 150mhz.
Esto explicaria muchas cosas pero me asusta una cosa: espero que la escene sea capaz de hacer trabajar esos emuladores de 16bits para abajo a una velocidad que no sea 300mhz porque si no vaya ruina de autonomia... casi mejor la gp32 para emular la snes y la megadrive...
slaudos
Pues si te digo la verdad, todavía no he sacado un rato para probarla :(
Ahora estoy empleando mi poco tiempo libre en portar el LK a la GP2X...
Saludos
LOL
Tranqui, cuando la pruebes ya me dirás.
Saludos.
hermes PS2R
09/12/2005, 19:15
Entonces a ver si me aclaro: segun tus especulaciones...
-Realmente la consola va a 300 mhz
-Tu programita cree que va a 200mhz por lo tanto cuando la ponemos a 133 realmente la estamos poniendo a 200mhz, no? y cuando bajamos a 100 va a 150mhz.
Esto explicaria muchas cosas pero me asusta una cosa: espero que la escene sea capaz de hacer trabajar esos emuladores de 16bits para abajo a una velocidad que no sea 300mhz porque si no vaya ruina de autonomia... casi mejor la gp32 para emular la snes y la megadrive...
slaudos
Si, eso es: cuando ajustabas una frecuencia con mi utilidad antes, la frecuencia real era mucho mayor que la informada (ahora mismo estoy oyendo un MP3 a 80MHZ de 256Kbits y a veces se entrecorta)
Eso no solo parece mas coherente con lo realmente observado, si no que como tu dices, explica bastantes cosas.
Ahora mismo la aplicacion cpu_speed nueva que he subido, informa de la velocidad del sistema y otros relojes. Pues bien, si ajustas la velocidad a 200Mhz, los valores son EXACTAMENTE iguales a los del log que posteo efegea (no recuerdo ahora el hilo, pero estaba en el foro general y un 'cacho' lo he subido antes)
Ojo! yo creo que ese problema se da solo en la 1.01 (en el bootloader), puesto que el log ese del que hablo, tiene que haber salido de un firm anterior supongo
Y, si esto es cierto, todas las aplicaciones que parecen tener tanto futuro en realidad estan tirando casi del maximo de la potencia de un procesador, lo cual haria necesario utilizar medianamente bien el segundo procesador para obtener un resultado similar co un consumo de pilas "normal".... uuuyyyy
No especulemos, que no hay datos concluyentes :p
Pues yo veo justo todo lo contrario!!!
Si realmente va a 298Mhz tendría sentido cómo es posible que el emu de NeoGeo vaya tan bien siendo un port directo o cómo el emu de PSX avanza tan deprisa, cuando habíamos pensado que el primer micro iba a 200Mhz.
Pero eso tiene una contra-prestación brutal:
Con 300Mhz hay cantidad de emuladores que una vez depurados podrán funcionar perfectamente sin tener que hacer uso del segundo micro, como el de NeoGeo y todos los 16 bits irán muy pero que muy sobrados.
El segundo micro también se podrá poner a 300Mhz!!! Esto supone tener doble micro con un 33% más de potencia de lo que habíamos pensado!!! Cuando se comience a usar el segundo micro puede ser un bombazo.
Se podrán depurar las aplicaciones para reducir el consumo. Tiene sentido el consumo actual de pilas si ambos procesadores están funcionando por defecto a 300Mhz.
Vamos, que si todo esto es cierto, tenemos mucha más máquina de lo que habíamos soñado entre nuestras manos :fieston: :fieston:
Y si al final no resultase ser así y estuvieran a 200Mhz, también tendría su parte positiva, ya que sabemos que se podría poner a 266Mhz, ganando también un 33% de rendimiento sobre ambos procesadores. :babea:
a mi me informa 280mhz con el firm 1.0.
Y ayer haciendo pruebas con la primera version de tu programa , bajando la velocidad a 133mhz (que serian los 200mhz reales) el emulador de neogeo va bastante bien, no se nota demasiado la bajada de rendimiento.
slaudos
Pues yo veo justo todo lo contrario!!!
Si realmente va a 298Mhz tendría sentido cómo es posible que el emu de NeoGeo vaya tan bien siendo un port directo o cómo el emu de PSX avanza tan deprisa, cuando habíamos pensado que el primer micro iba a 200Mhz.
Pero eso tiene una contra-prestación brutal:
Con 300Mhz hay cantidad de emuladores que una vez depurados podrán funcionar perfectamente sin tener que hacer uso del segundo micro, como el de NeoGeo y todos los 16 bits irán muy pero que muy sobrados.
El segundo micro también se podrá poner a 300Mhz!!! Esto supone tener doble micro con un 33% más de potencia de lo que habíamos pensado!!! Cuando se comience a usar el segundo micro puede ser un bombazo.
Se podrán depurar las aplicaciones para reducir el consumo. Tiene sentido el consumo actual de pilas si ambos procesadores están funcionando por defecto a 300Mhz.
Vamos, que si todo esto es cierto, tenemos mucha más máquina de lo que habíamos soñado entre nuestras manos :fieston: :fieston:
Y si al final no resultase ser así y estuvieran a 200Mhz, también tendría su parte positiva, ya que sabemos que se podría poner a 266Mhz, ganando también un 33% de rendimiento sobre ambos procesadores. :babea:
deja-vu? :D post repe en dos hilos :D
deja-vu? :D post repe en dos hilos :D
Sí, he hecho copy-paste porque me parecía que iba bien en ambos hilos :D
A ver, he hecho un par de pruebas con el micro a 200mhz reales. firm 1.0
-quake: se nota bastante la bajada de fps, pero no es algo como para echarse a llorar.
-duke nukem 3d: no se nota nada, va igual de fluido que antes, aunque he notado algun paron a la hora de leer sonidos de la sd, aunque creo que es cosa de mi sd.
-emu neogeo: aumenta bastante el frameskip, pero el widjammers sigue siendo jugable, que es con el que he estado haciendo pruebas.
videos y mp3 no he hecho pruebas.
slaudos
PD: ya seguire probando cosillas
A ver, he hecho un par de pruebas con el micro a 200mhz reales. firm 1.0
-quake: se nota bastante la bajada de fps, pero no es algo como para echarse a llorar.
-duke nukem 3d: no se nota nada, va igual de fluido que antes, aunque he notado algun paron a la hora de leer sonidos de la sd, aunque creo que es cosa de mi sd.
-emu neogeo: aumenta bastante el frameskip, pero el widjammers sigue siendo jugable, que es con el que he estado haciendo pruebas.
videos y mp3 no he hecho pruebas.
slaudos
PD: ya seguire probando cosillas
¿Puedes probar el emu de SMS? :)
Pues no consigo hacer funcionar el sms. lo pongo en una carpeta, renombro la rom a alexkidd.sms y nada de nada, se me sale al menu.
slaudos
Pues no consigo hacer funcionar el sms. lo pongo en una carpeta, renombro la rom a alexkidd.sms y nada de nada, se me sale al menu.
slaudos
En el zip te venia sólo un .gpe y un binario? Porque parece que estas intentando ejecutar la version antigua. Prueba a bajarlo de mi web, que esta en mi firma ^_^
La version "buena" debe de tener unos cuantos textos de copyright, el de las SDL y de la fuente bistream vera. Por algun extraño motivo ni anarchy ni luisodin han actualizado la seccion de descargas :loco:
siento decirte que a mi a 200mhz se me sale al menu, pero a 300 si funciona sin problemas...
slaudos
-quake: se nota bastante la bajada de fps, pero no es algo como para echarse a llorar.
Los fps que posteó woogal de la versión para gp2x coincidían con los que daría una gp32 a 200 mhz, pero si me dices que en realidad funciona a 300 mhz, pues no sé.
A mí ésto de los 300 mhz me parece una muy mala noticia. Si el emu de Snes con el core en ensamblador y sin sonido no va a fullspeed a 300 mhz,...
hermes PS2R
10/12/2005, 01:33
Los fps que posteó woogal de la versión para gp2x coincidían con los que daría una gp32 a 200 mhz, pero si me dices que en realidad funciona a 300 mhz, pues no sé.
A mí ésto de los 300 mhz me parece una muy mala noticia. Si el emu de Snes con el core en ensamblador y sin sonido no va a fullspeed a 300 mhz,...
Veamos, no es lo mismo decir que el reloj del sistema va a 298Mhz, que decir que el 920t va a 298Mhz, no se si me explico.
Si el limite de frecuencia del procesador es de 266Mhz, esos 298 Mhz no es un gran incremento y digamos, el procesador se podría comportar como si tuviera un reloj no demasiado regular y de vez en cuando, colgarse.
Es curioso pero se me ha ocurrido la idea de que poniendo un frecuencia mucho mas alta y ajustando los divisores, la cosa debería funcionar aunque encontrara otro tipo de problemas.
En efecto, poniendo 400Mhz y divisor 1 (equivale a 200Mhz) todo iba perfectamente, pero observo una interferencia en pantalla que la recorre desde una diagonal.
Entonces he vuelto y he ajustado 400 Mhz directamente y he salido. El resultado es que se corrompian algunos graficos, pero no se ha colgado la consola (o sea que tiene el reloj bastante jodidillo, pero aguanta parcialmente el tipo)
Como curiosidad, tengo un PDF de MagicEyes, concretamente mmspx2ux.pdf y en la pagina 50
(si lo tienes) veras que ajusta el reloj con los mismos factores M y P que tengo yo para esa misma frecuencia. Esos valores son tal y como son leido directamente de los registros, sin suma alguna.
Pues ahí es donde esta el problema: que P en el log y en el pdf tiene valor 1 y la consola devuelve 0 :loco: . Eso quiere decir que el reloj trabaja a 298 Mhz, pero ni puñetera idea de como afecta eso al rendimiento de los procesadores....
mortimor
10/12/2005, 02:08
Los fps que posteó woogal de la versión para gp2x coincidían con los que daría una gp32 a 200 mhz, pero si me dices que en realidad funciona a 300 mhz, pues no sé.
A mí ésto de los 300 mhz me parece una muy mala noticia. Si el emu de Snes con el core en ensamblador y sin sonido no va a fullspeed a 300 mhz,...
Estoy deacuerdo contigo al 100%.
El problema puede estar en la memoria que segun parece funciona a 133Mhz y supone un cuello de botella enorme, recuerda que en GP32 a 200 Mhz casi no se le ganan fps a los emuladores por esa misma razon. Habria que utilizar multiproceso para realmente marcar la diferencia si fuera ese el problema.
Realmente lo unico bueno de esta noticia es que se podra poner la consola a una frecuencia "normal" y obtener una autonomia como dios manda. Bueno, y que ahora se sabe ya cuanto duraran las pilas cuando se exprima el hardware de la maquina (mas no puede consumir).
No os engañeis, si va a 300Mhz, el margen de mejora esta ya solo en el software y todo lo que parecia tan sorprendente y que se achacaba a la estructura de la maquina no lo es tanto. Menos mal que parece que ya se esta explorando el tema de 940, porque sino...
Wonder Boy
10/12/2005, 02:32
A mí ésto de los 300 mhz me parece una muy mala noticia. Si el emu de Snes con el core en ensamblador y sin sonido no va a fullspeed a 300 mhz,...H0stia pues sí que es una muy mala noticia (no lo era cuando se suponía que la consola funcionaba a sus 200 MHz base y por tanto overclockeables...).
Ahora mira.
Está comentando Robster en el canal #gp2xdev de EFnet que hay un error en ese código y que en realidad va a 200Mhz como se nos había dicho. Lo que pasa es que yo no tengo el conocimiento para buscar el fallo y lo único que dijeron fue esto:
<RobB_afk> that spanish guy that's saying the GP2X is running at 210MHz or 300MHz? There's a dumb bug in his code :D
<Oscaruzzo> really?
<Oscaruzzo> lol :D
<hooka> heh, already given it a look robster?
<RobB_afk> took about 0.00001 seconds to find
<RobB_afk> (that's 12 cycles at 300MHz :D )
<hooka> nice :)
<RobB_afk> well, it is if you apply spanish arithmetic to it
<RobB_afk> (sorry rlyeh :)
<Oscaruzzo> lol
<Oscaruzzo> so in the end
<Oscaruzzo> the clock speed is?
<Oscaruzzo> 200Mhz?
<doc_death> okay for some interesting info ewll maybe interesting
<doc_death> i'm on the very early firmware where the screen is terrible
<RobB_afk> 199065600 to be exact :)
<doc_death> if i set my cpu speed to 200mhz the contrast of my screen is corrected entirely !
<Oscaruzzo> nice to know
<doc_death> just like what the new firmwares are meant to do
<doc_death> so i can watch movies with good contrast wooh
<Oscaruzzo> i was becoming afraid to leave it on for long times :)
<doc_death> so apparently the first firmware is running 280mhz default ???
<RobB_afk> doc_death: NO! NO! NO! They're all running at 200MHz
Saludos...
EDIT: Aquí (http://www.gp32x.com/board/index.php?showtopic=23011&st=60&p=312334&#entry312334) especifica el fallo.
mortimor
10/12/2005, 04:25
Bueno, si esta equivocado Hermes, pues de lo dicho nada :) Para ahorrar bateria habra que poner la maquinita a 133Mhz y no se perdera tanto fuelle :)
No me gusta el tono despectivo de Robster con lo de aritmetica española. Por que una persona en un determinado momento se equivoque... que tonteria, lo mismo prefiere que sigamos hablando de los yankis como basura sin cultura como muchos de ellos creen que España esta en Mejico...
Bueno, si esta equivocado Hermes, pues de lo dicho nada :) Para ahorrar bateria habra que poner la maquinita a 133Mhz y no se perdera tanto fuelle :)
No me gusta el tono despectivo de Robster con lo de aritmetica española. Por que una persona en un determinado momento se equivoque... que tonteria, lo mismo prefiere que sigamos hablando de los yankis como basura sin cultura como muchos de ellos creen que España esta en Mejico...
Yo creo que está de coña en ese momento en el chat, a veces no está mal reirse de los prejuicios. Por cierto, es de Nueva Zelanda xD.
Saludos...
mortimor
10/12/2005, 04:38
No se de donde es y no me importa (si te gusta, cambio el ejemplo por el de residuo ingles...??? es despectivo e igualmente estupido, pero es solo un ejemplo).
Supongo que estara de coña, porque sino... :loco:
Por otro lado, creo que es un tipo inteligente y bien informado (lo ha demostrado muchas veces) y su opinion al respecto del tema que importa me tranquiliza.
PD: al fin y al cabo, un fallo lo tiene cualquiera y Hermes ya dijo que esto era algo experimental y qeu se basaba en un log y tal... no pasa nada.
Puck2099
10/12/2005, 04:43
No me gusta el tono despectivo de Robster con lo de aritmetica española. Por que una persona en un determinado momento se equivoque... que tonteria, lo mismo prefiere que sigamos hablando de los yankis como basura sin cultura como muchos de ellos creen que España esta en Mejico...
Creo que le estaba vacilando a Rlyeh que estaba en el mismo canal ;)
Creo que le estaba vacilando a Rlyeh que estaba en el mismo canal ;)
Sí, se estaba metiendo conmigo, es amigo mío xD
No tiene nada que ver con Hermes, va por mí la puñalada ains xDD
No os preocupéis que el Robster es guena gente y va sin maldad ni arrogancia :-)
Buenas noticias entonces :)
Wonder Boy
10/12/2005, 05:54
Pues sí. ....
hermes PS2R
10/12/2005, 16:31
Buenas,
no os tomeis a pecho el ligero 'cachondeito' a costa mía por el citado error, hombre!
Acabo de subir las versiones 1.02 corregidas y en el caso de cpu_speed ahora si permite hacer overclocking hasta 266 Mhz.
Todo el problema viene de que GPH no hace los deberes: se supone que debería liberar los fuentes que usan bajo GPL (aparte del prometido SDK) y en vez de eso, nos relesea un u-boot que no es ni mucho menos el de la versión 1.0 si en fichero speed.c tiene esta funcion así
m = ((r & 0xFF00) >> 8) + 8; /* m = MDIV + * */
p = ((r & 0xFC) >> 3) + 1; /* p = PDIV + 2 */
s = r & 0x03; /* s = s */
return ((CONFIG_SYS_CLK_FREQ * m) / (p << s));
Con esta funcion así la frecuencia informada era de unos 533 Mhz :loco: y a mí lo primero que se me ocurrío fue que quizá la frecuencia del sistema era otra, en vez de sospechar que un codigo que SE SUPONE tenemos funcionando para el booteo de la consola, está mal
Ayer verifiqué los valores de los otros relojes y me dí cuenta que la frecuencia del sistema que yo averigué indirectamente, no era correcta y basandome en la que SI lo es, saqué la ecuacion correcta, pero claro, el PROBLEMA era a la hora de adquirir el valor P que con el desplazamiento a 3 se iba a hacer puñetas.
Todo esto viene de que GPH no ha sabido dar las herramientas adecuadas ni cumple con sus deberes para con la GPL y que por otro lado, hay gente como Robster que tienen buena información y programadores como nosostros, necesitados de información y tenemos dos caminos:
1) Sentarnos a esperar pacientemente hasta que la gente que tiene la información y por algún motivo, la retiene ( NDA e historias de esas) la acabe soltando poco a poco o publicando librerías ya sean de codigo abierto o cerrado.
2) Ponernos manos a la obra y analizar los fuentes disponibles en busca de información útil y tal vez equivocarnos por culpa de un bug en el código y luego ser corregidos a toro pasado, por gente como Robster.
De todo esto, tenemos que sacar una conclusión: que hace dos días, ninguno sabiamos que hacer para controlar la velocidad de la maquinita y que no chupe tanta pila y ahora tenemos una librería que funciona correctamente, util para todos ;)
Di que si, que te estamos todos muy agradecidos. Ademas podemos apagar el otro procesador, que eso ya e sun tesoro.
yo por mi parte voy a hacer pruebas con el emu de megadrive a menos velocidad a ver hasta cuanto se peude bajar.
slaudos
Molondro
11/12/2005, 17:41
Una pregunta un poco tonta: según Anarchy, hay consolas que se vuelven inestables o sencillamente se cuelgan cuando se pone a 266 Mhz, cuando el micro está preparado y certificado (me equivoco?) para funcionar a esa frecuencia. Podría ser esto a causa de que en GPH le hayan bajado el voltaje de serie para reducir el consumo?
Saludos
mortimor
11/12/2005, 18:04
Una pregunta un poco tonta: según Anarchy, hay consolas que se vuelven inestables o sencillamente se cuelgan cuando se pone a 266 Mhz, cuando el micro está preparado y certificado (me equivoco?) para funcionar a esa frecuencia. Podría ser esto a causa de que en GPH le hayan bajado el voltaje de serie para reducir el consumo?
Saludos
Sencillamente, el problema esta en que otro componentes no funcionan bien a esa frecuencia, vease memoria ram :( El mismo problema que hacia que en las GP32 unas fueran a 133 y otras hasta 266.
Molondro
11/12/2005, 18:13
pues que gaita... :( y que metida de pata por parte de GPH :shock:
BUHOnero
11/12/2005, 18:26
Alguien puede hacer un poqueño manual de como funciona el programa¿? yo solo veo eso de la suma resta o multiplicación, pero no se como elegir la frecuencia, o como leer los datos que se dan por pantalla, y me da miedo meterle alguna frecuencia que me joda la GP2x, ademas no hay ni un mísero txt con información... :rolleyes:
guilleml
11/12/2005, 19:11
Alguien puede hacer un poqueño manual de como funciona el programa¿? yo solo veo eso de la suma resta o multiplicación, pero no se como elegir la frecuencia, o como leer los datos que se dan por pantalla, y me da miedo meterle alguna frecuencia que me joda la GP2x, ademas no hay ni un mísero txt con información... :rolleyes:
Sino me equivoco, puedes elegir la frecuencia usando los gatillos de la consola.
Powered by vBulletin® Version 4.2.5 Copyright © 2026 vBulletin Solutions Inc. All rights reserved.