Ver la versión completa : GPAdvance V1.27
hostbridge
03/07/2004, 08:33
Yes, it's true: There's already another upgrade for GPAdvance, the GBA emulator by enf65!:p :p :p :p
hostbridge
03/07/2004, 08:56
LO HABEIS PROBADO!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Anarchy has visto el pack que viene el emulador y un ejemplo de 3D :eek: :eek: :eek:
Es Impresionante :confused: :confused: :miedo: :miedo: :eek: :eek:
lo interesante seria ke hiciera funiconar juegos de una vez no?
VIVAAAAAAAAAAA
Escrito originalmente por dj syto
lo interesante seria ke hiciera funiconar juegos de una vez no?
VIVAAAAAAAAAAA
Sí, pero vamos a darle un poquito de tiempo (a este paso...) :D :D
Un saludo :brindis:
Si el emulador alguna vez llega a ser viable aun sin sonido creo que veremos como el indice de ventas de la GP se dispara.
de todas formas ten en cuenta ke solo van a funcionar unos pocos juegos.
con q vayan algunos más o menos jugables yo me conformaba...
mortimor
03/07/2004, 10:14
Oye, prodria DreamerXL probar la demo que le paso Xan_Vision a ver si rula en el emu de GBA :)
De donde habeis bajado el pack con la demo 3D?
Syto, lo de los pocos juegos lo dices por el tamaño de las roms? Yo estoy casi convencido de que implementaran un sistema para cargar parcialmente las roms desde la smc bajo demanda.
O acaso el GPCinema no reproduce videos mayores de 6MB? :D
hostbridge
03/07/2004, 11:11
no se si se puede hacer esto pero si acaso no se puede , borradlo Thk
http://www.gp32news.com/gp32news/emus/gpadvance/pack_gpadv1.27.zip
ahy un juegillo mu raro y una demo en 3d creo que bastante potente para ser en un emulador
El pak lo encuentras AKÍ (http://www.gp32news.com/gp32news/emus/gpadvance/pack_gpadv1.27.zip)
Acuerdate de meter las roms en la carpeta GPadv.
Lo de lROMS mayores de 6/8 megas ni idea pero las peliculas siguen un orden determinado de datos con lo que pueden hacer "stream" y en los juegos se accede a toda la ROM de forma salteada por lo que es mas dificil "adivinar" que recursos y de que parte de la ROM los va a cargar... no se si me explico... :p
Propeller
03/07/2004, 11:23
La teoría es muy bonita para estos casos. Tened en cuenta que si encontráramos un sistema de carga anticipada de páginas de código/datos (en las roms suele estar todo mezclado) estaríamos dando solución a un problema que se califica como "imposible" dentro de la informática teórica: El problema de parada.
Y es que no podemos prever a priori cuál va a ser el devenir de un programa: Ni cuando va a acabar su ejecución, ni si va a acabar, ni siquiera cuáles van a ser las páginas de código que va a necesitar en el futuro.
Hay muchos emuladores que agradecerían esto de las "roms en demanda", como aquellos que tienen roms más grandes que la memoria (GBA, Neo Geo, CPs2, etc...).
Lamento ser yo casi siempre quien venga a esfumar los sueños de la gente, pero es que las bases teóricas de la informática llevan sentadas desde los años 30/40 por algo. Un señor llamado Alonzo Church inventó una cosa que se llamaba Lambda Calculus, que fue la precursora del trabajo de Alan Turing (machacado por la gente de la época por ser "afeminado") llamado "The halting problem". O el problema de parada, en el idioma de Cervantes (el escritor, no el pirata del Soul Caaaaalibur).
Siento la charla, pero es que llevo muchos años pensando en cómo paliar el problema de la falta de memoria en sistemas poco potentes, y así aprovecho y me contesto a mi mismo :D
Propeller
Claro que te explicas, pero con una buena gestion de memoria se podria crear un algoritmo que utilizase las bases de proximidad temporal y espacial para preveer los proximos accesos; y una buena politica de reemplazo para eliminar los datos menos usados de la memoria.
Por ejemplo, puedes trabajar con bloques de 128-256k, que no tardaran demasiado en traerse desde la smc y tener siempre en memoria el bloque del cual estas leyendo y el siguiente. Si en algun momento el programa pide un dato de un bloque que no esta en memoria, se produce un fallo de pagina, el juego se para un momentoy se trae desde la smc el bloque demandado, sustituyendo al bloque de memoria que lleve mas tiempo sin ser utilizado.
Seria un poco incomodo, porque en cada fallo de pagina se produciria una pequeña pausilla en el juego, pero hay que tener en cuenta que pocas son las roms mas grandes de 8MB, y con las de 8 estaria casi todo cargado en memoria y no habria demasiados fallos, serian solo en plan al cargar un nuevo escenario o cosas asi.
En fin, es que le estuve dando vueltas y me parecio una buena idea, no se si algun programador mas experimentado me podra confirmar si es viable o incluso podria intentar implementar una demo cutre del gestor a ver si funciona bien... para el emu de SNES vendria de PM :) (Tales of Phantasia POWAAAA)
[Edito] Vaya por dios, si lo dice Propeller entonces es que es imposible... Si lo llego a leer antes me ahorro escribir este tocho xD
Propeller
03/07/2004, 11:26
Locke, léete mi respuesta, que hemos tenido una condición de carrera en el posteo :p
Propeller
Vaya, no conozco ese "problema de parada"... en que consiste? Yo creo que ese problema de parada no es tal, porque se para cuando pulsas el boton de off... :)
Que fallaria en mi teoria? (solo por curiosidad)
¿Y qué tal la ampliación a 32MB? :D :D :D
Propeller
03/07/2004, 11:33
Offtopic: Lo que fallaría en tu hipótesis es que símplemente con la especificación matemática de la función que calcula tu programa, jamás llegaremos a predecir cuándo puñetas pulsarás el reset.
Si un programa ya es impredecible, un agente externo al programa eleva su entropía al infinito.
Propeller
Vaya, me he perdido...:confused: :loco:
Pero continuad, que si llegais a alguna conclusion y yo puedo jugar a algun castelvania de GBA en mi GP32, vamos, cojo al mismisimo PARADA (si, si, el de cine de barrio) pa que os de un premio y un par de besitos de mi parte.:amor:
Un saludo
Lo de la ampliacion pienso que jamas llegara a buen puerto, poque se ha formado un circulo vicioso... :( Los programadores no hacen apps preparadas para 32MB porque no hay suficientes mods para que merezca la pena el trabajo extra. Los usuarios no amplian la memoria porque no hay suficientes programas para que merezca la pena buscar y soldar el chip (que ademas esta al alcance de muy pocos)
A Propeller ya no le entiendo, se me ha ido por las entropias y eso ya me queda muy arriba xD Seguro que hay una buena razon para querer saber cuando acabara un programa, pero no lo acabo de comprender, supongo que si me pongo a implementarlo sera la unica manera de enterarme...
De todas maneras... para un algoritmo que lo unico que hace es traer a memoria el siguiente bloque del que se esta usando... no creo que pase mucho si apagas la consola :P pero weno, no me contestes, que si no voy a tener que volver a preguntar lo mismo de nuevo xDDDD
Un saludo
hostbridge
03/07/2004, 11:42
pues vendria de lujo si se enterasen los del emulador y las instrucciones las adaptasen a los 32 megas.....
Anarchy
Tu ya pones los 32 megas?? en Hardcore-Gamers ???
Hola:
En realidad no hay tal circulo vicioso. El nuevo fGen32 incorpora soporte para la ampliación. Al parecer es MUY sencillo hacerlo y además el soporte solo funciona si la consola tiene los 32MB, es decir, el emulador funcionará igual tanto si hay 8MB como 32MB, pero en el segundo caso, aprovechará la memoria extra.
Un saludo
Anarchy
hostbridge
03/07/2004, 11:53
Anarchy , has visto mi pregunta???
Propeller
03/07/2004, 12:00
¿Cuál es el coste aproximado de la ampliación de memoria? Lo digo para calcular un coeficiente de Euro por cana conseguida...
Propeller
El emulador parece ir por buen camino, la demo 3d esta se sale, ya la vi en gba y va a la misma velocidad que en el emulador.
Con respecto a la ampliacion, si no hay problemas para hacerla yo la haria, bueno,, dejaria que me la hicieran, pero siempre con un minimo de garantias de que la consola no pete.
Asi que si alguien se anima a hacer la ampliacion y no casca las consolas que me lo diga XD
Pues no lo he estimado. Lo malo es que yo no dispongo de la "maquinaria" necesaria para desoldar el chip sin dañar la consola, por lo que dependo de otra persona.
Ah! Esta tarde te respondo a tu e-mail Propeller, que he estado un "poquito" liado :p
pues ocupate ahora de banear al tal ninja ese ke no hizo mas ke abrir post insultando, y eso ke yo me mantuve al margen y no le conteste a ni uno.
Vale, ya lo he localizado.
si solo fuera un post... XDD el pobre chemaris anduvo loco cerrandolos todos.
creo que deberias darle poder a chemaris para poder banear, ya ke es un buen moderador y se lo merece.
hostbridge
03/07/2004, 12:09
si no recuero al eran 4 post , y de los wapos
hostbridge, ayer me fije por primera vez en tu animacion de la gp32 y la plei JAJAJAJA ME PARTO EL CULO XDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
Propeller
03/07/2004, 12:14
Oh, fantástico...
Llevo aguardando esa respuesta tanto tiempo que no se ni lo que te escribí :D
Voy a repasar mis notas...
Propeller
PD: Lo primero es el currelo, eh? Si no tienes tiempo, pasa del e-mail. Y si tienes tiempo pero te apetece jugar un rato a la consola, pasa igualmente :brindis:
Ambos sabemos lo que es estar tiempo sin jugar por el trabajo :miedo:
A todo esto... ¿Quién me envió un mensaje al móvil para avisarme de que se estaban pasando en los foros? No lo tengo registrado :D
Escrito originalmente por Anarchy
A todo esto... ¿Quién me envió un mensaje al móvil para avisarme de que se estaban pasando en los foros? No lo tengo registrado :D
¿Que paso? :confused:
se referira al jaleo ke monto el lamer del ninja.
chemaris
04/07/2004, 15:37
llego a casa y me encuentro con el foro alterao, el ninja ese abriendo post sin sentido insultando al personal y demas, al menos le cerraria 5 hilos
todos quejandonospor las copias de los juegos de la GP32 y despues esperando con ansias el emulador de la advance :D
cuanta hipocresia eh? XDDDDDDDDDd
pedimos un emulador de gba para usar las roms freeware hombre, ke hay muchas. :P
si, esas son las que usare yo seguro :D
Propeller
04/07/2004, 16:14
Atención al bicho raro:
A mi solo me interesa para ver el código y certificar mi idea de que es posible hacerlo.
Propeller
e que no soy ningun bicho raro :mad:
Propeller
04/07/2004, 16:18
Bueno, y para jugar al puyo puyo fever. Pero eso es secundario.
Además, seguramente jugaré de legal, porque lo compraré para la colección de juegos de SEGA que tengo. :D
Propeller
y que tiene que ver sega con nintendo :confused:
Propeller
04/07/2004, 16:19
e que no soy ningun bicho raro
Lee bien, que si te fijas hay dos puntos detrás de la primera frase: Hablo sobre mi.
Propeller
Propeller
04/07/2004, 16:21
y que tiene que ver sega con nintendo
Puyo Puyo Fever es un juego de SEGA (del Sonic Team en concreto), aunque exista para Gameboy Advance.
Y, como mucha gente, colecciono los juegos de SEGA porque me parecen obras de arte.
Esta claro que tu y yo, por la más recóndita razón, no nos entendemos :D
Propeller
esta vez te perdono porque vaz a llevar razon :D
ademas soy un bicho raro tambien :D
Propeller
04/07/2004, 16:24
Entonces ya nos entendemos, y de ello me alegro :brindis:
Propeller
aunque no tirase de roms de mas de 4MB, seria un emu muy interesante igualmente :)
sera por roms de 4MB (unas 50 por lo menos), que hay unas cuantas interesantes como :
Super Mario Advance 3 - Yoshi's Island
que es muy dificil o imposible de emular en condiciones la version de SNES en la GP32, por culpa del "asqueroso" SuperFX chip :D
--------
pero bienvenida sea esa ampliacion de 32MB para la GP32
ya que la mayoria de las roms realmente interesantes de GBA andan entre los 8-16MB
aunque sea mas interesante para el MAME
--------
ya que un juego de GBA nunca ocupa la totalidad de la capacidad del cartucho
la pregunta es:
siempre hay porciones de un juego en los ultimos sectores de la rom?
y si no hay parte del juego, ese espacio esta "vacio" o se rellena con "basura"?
si estuviese "vacio", podria "recortarse" el final de la rom para reducir su tamaño?
me estoy refiriendo siempre al caso particular de los cartuchos (o las roms) de GBA, si es que difiere de otros casos
---------
saludos
A lo mejor lo que digo es una tontería.... pero alli va:
En el mundo PC, cuando no se dispone de bastante memoria, el S.O. crea un archivo en el Disco Duro llamado normalmente, archivo de intercambio (swap) que se usa como "memoria virtual", no se podría hacer igual en la SMC ? el acceso sería mucho mas lento, pero solo afectaria a los tiempos de carga, no? Según tengo entendido si se hiciera un Disco Duro para DC, su funcion principal seria esta, pero para la GP32 es diferente ya que la SMC si que es de escritura/lectura, no solo lectura como la DC.... bueno no se si me he explicado, pero ahi dejo las preguntas. :)
eso ke comentas ya se le ocurrio a propeller, pero la verdad eske parece ke la velocidad de trasnferencia no es la suficiente para eso.
Propeller
04/07/2004, 20:44
Y no sólo está la velocidad (que se podría llegar a suplir con un prefetch efectivo) sino que tendrías que escribir tantas veces en la SMC que te fundirías su vida media en una semana (recordad que las tarjetas SMC tienen una cifra media tope de escrituras).
Propeller
enkonsierto
04/07/2004, 23:03
Se me acaba de ocurrir una animalada sobre la ampliación de memoria...
Técnicamente estamos de acuerdo que poner 32 o 64 mb de ram a la consola es una operación de riesgo, sin contar con que hay que tener un material de precisión no disponible para todo el mundo.
El asunto es: ¿Podría instalarse una "ram" externa por el puerto ext? Quizás sea una idea de pelota impresionante, pero me gustaría que alguien me diga si es un hallazgo o una chorrada bestial, fundamentada en razones...
Propeller
04/07/2004, 23:06
No te saldría bien ni aunque montaras la RAM en un puerto firewire :D
Por supuesto, ni mucho menos en un puerto de baja velocidad como es el EXT de la GP32.
Nice try ;)
Propeller
Pues yo sigo en mis trece convencido de que tengo razon :)
Me baje los fuentes del opensnes9x a ver si podia implementar un sistema de carga de roms mayores de 6MB, pero me he dado cuenta de que mi nivel de C++ es demasiado bajo, y peor aun, mi conocimiento del hardware de SNES es nulo xD
Pero no cejo en mi empeño, voy a seguir en ello y hasta que no lo consiga no paro, soy tan cabezota como Propeller con GBA o Anarchy con CPS1 (y yo tb estaba convencido desde el principio de que estos dos sistemas serian emulados, asi que... :) )
TENGO LA CABEZA DURA, Y QUEEEE!!! ME DA IGUAL!! :p :D :p :D :p :D :p :D
bufalo73
05/07/2004, 09:45
No se si se usó mucho o si era efectivo, pero tenía un sistema por el cual se iba cargando en memoria el programa según el espacio disponible. Técnicamente es usar el propio fichero origen como fichero de intercambio (sólo lectura) lo cual ahorra bastante movimiento de datos. En comparación con la memoria virtual el trasiego de datos es (si no me equivoco) :
- Memoria virtual : Compruebas el tamaño de lo que quieres meter en memoria, liberas la memoria que haga falta, envías al fichero de intercambio las páginas que estaban siendo usadas, cargas el fichero, usas el código.
- Carga desparramada (ese era el nombre, no me lo invento :) ) : Compruebas el tamaño de lo que quieres cargar, compruebas la memoria disponible, cargas el tramo que entra en memoria, cuando te sales del tramo cargas el siguiente tramo.
Que se pueda hacer en la GP32... no lo sé. Que existe la manera de hacerlo, sí.
Hombre habria que ver cuanto sitio libre deja el emulador, pero una via de investigacion seria la siguiente:
El emulador o la aplicacion se "reserva" 4 megas de ram, luego los otros cuatro los va a usar de "cache"
Para ellos la aplicacion crea un mapa de memoria de digamos 32 megas con la mmu (la gp32 tiene mmu no?) y se encarga de hacer la gestion de carga desde la smc a las 4 megas reservadas para la cache cuando alguien acede a esos 32 megas "virtuales"
En teoria mientras el working size de la aplicacion no sea superor a los 4 megas que hemos destinado a la cache pues todo deveria de funcionar.. con parones eso si cuando haya un "cambio de contexto" es decir pasemos de los menu sa una fase y de una fase a otro por ejemplo, ademas con una granulariada de pagina/carga de 64kb el coste de la gestion del cache de memoria en cuanto a tablas y demas seria "barato", en un dword por pagina se puede codificar todo, y dpues un apequeña lista para gestionar las paginas mensu usadas.
De esta manera de programa tendria la ventaja de que si la app tiene mas memoria disponible porque es un gp32 con 32 megas de ram pues no va a tener que descargar cosas... y los usuarios con la gp32 "ampliada" se beneficiarian de ello automaticamente...
P.D: aun no se de gp32 lo suficiente asi que no me pegeis si la gp32 no tien mmu y eso no se puede hacer... :-P
P.D: propeler conectate al messenger que tengo que hablar contigo...
Yo seguramente voy a decir otra burrada pero bueno, si hacen el emulador para que pueda leer el juego comprimido en partes? me refiero a comprimir la room en 3 o 4 partes con el winrar, al fin y al cabo el juego esta dentro, xD
Seria lo mismo, para poder trabajar con esa informacion necesita descomprimirla antes, tu para ver un video dentro de un zip necesitas descomprimir el video antes de verlo por poner un ejemplo.
Ahora me diras "si, pero el divx es comprimido" y yo te dire si, pero se va descomprimiendo para mostrarlo porque en este caso sabes que lo siguiente que descomprimas es lo que debes ver, no se si me explico, intento ponerlo facil para quien no lo entienda muy bien.
El caso es que tu tienes un video y segun vas viendo un fotograma se descomprime el anterior y asi hasta el final (mas o menos XD, queria ponerlo facil) y con un juego no puedes predecir que parte del juego necesitas cargar, porque un cartucho, una rom, es un todo, no hay cargas entre pantallas ni nada por el estilo, esta toda la informacion junta y accesible en todo momento, el problema esta ahi, en no poder meter mas informacion de la que cabe en la ram de la gp y de no poder predecir a que parte de esa rom vas a tener que acceder en el siguiente segundo.
Mi idea yo creo que es la misma que la de una-i, pero con la mmu por software, ya que creo que la gp32 no tiene.
De todas maneras, seria muy simple de implementar, solo es una tabla que te indica que paginas tienes en memoria y en que marco, y para tan poca memoria es un gasto totalmente asequible.
Tambien habria que tener un registro que gestionara los accesos a las paginas cargadas en memoria para saber cual sustituir. Yo creo que el algoritmo mas apropiado es este caso seria sustituir la pagina que lleve mas tiempo sin ser usada.
Entonces una lectura de memoria implicaria lo siguiente: consultar en la "mmu" si la pagina esta en memoria, si es el caso entonces carga el dato y efectua las operaciones necesarias; si no esta en memoria, mira en la otra tabla cual es la pagina que lleva mas tiempo sin usarse, la sustituye por la necesaria, actualiza la mmu y lee el dato.
El problema fundamental de esto es que serian necesarios 2 accesos a memoria, con sus correspondientes calculos para leer cada dato; y eso disminuiria bastante la velocidad del emu (aunque esta memoria sea tan rapida como el procesador). Tambien se notaria tirones en las lecturas de las paginas desde la smc, y eso ocurriria bastante al iniciar cada zona del juego.
La solucion seria mirar el tamaño de la rom al empezar la emulacion, y si es menor de 6MB o se detecta que la consola tiene ampliacion de memoria entonces usar la carga completa, si es mayor usar este sistema, que es peor, pero por lo menos se puede jugar :)
Bueno, ya lo he dicho, a ver si algun programador experto me puede decir si habria otra manera mejor o incluso intenta implementar esta a ver que tal :) O a lo mejor me equivoco y la gp32 si que tiene mmu, pero me parece muy rarow...
Escrito originalmente por rage
aunque no tirase de roms de mas de 4MB, seria un emu muy interesante igualmente :)
sera por roms de 4MB (unas 50 por lo menos), que hay unas cuantas interesantes como :
Super Mario Advance 3 - Yoshi's Island
que es muy dificil o imposible de emular en condiciones la version de SNES en la GP32, por culpa del "asqueroso" SuperFX chip :D
--------
pero bienvenida sea esa ampliacion de 32MB para la GP32
ya que la mayoria de las roms realmente interesantes de GBA andan entre los 8-16MB
aunque sea mas interesante para el MAME
--------
ya que un juego de GBA nunca ocupa la totalidad de la capacidad del cartucho
la pregunta es:
siempre hay porciones de un juego en los ultimos sectores de la rom?
y si no hay parte del juego, ese espacio esta "vacio" o se rellena con "basura"?
si estuviese "vacio", podria "recortarse" el final de la rom para reducir su tamaño?
me estoy refiriendo siempre al caso particular de los cartuchos (o las roms) de GBA, si es que difiere de otros casos
---------
saludos
Totalmente factible y funcional , como ejemplo la rom de castlevania circle of the moon que de 8mb pasa a 5 mb gracias a que tiene cantidad de espacio vacio al final de la rom que podemos eliminar facilmente con un editor hexadecimal y la rom sigue funcionando perfectamente
La GP32 si tiene MMU hardware y gracias a eso estan haciendo el emulador.
Coñe, entonces problema resuelto :)
Hale, que alguien se lo incluya al de SNES que estoy esperando para pdoer jugar a Tales of Phantasia :)
DreamerXL
23/10/2004, 02:43
Escrito originalmente por mortimor
Oye, prodria DreamerXL probar la demo que le paso Xan_Vision a ver si rula en el emu de GBA :)
Weeee, no me había dado cuenta de que estaba esto aquí :D:D:D
En fin, con un poquito de retraso :D; La demo no tira (Se llega a ver el logo de QBIX [Tarda un rato en aparecer] y luego, nada mas empezar a jugar, se cuelga [Da un error raro]).
Siento no haberlo visto antes (Y el Upeo también).
PD: Hablando de QBIX, alguien sabe que ocurrió? (Xan_Vision, estás por ahí? [Eeeeoooeeeooo :D]).
Salu2!
mortimor
23/10/2004, 11:39
jejeje, un "poco" de retraso, pero gracias :D:D:D
En fin, pues con un sistema de cargas similar al del GPAdvance se podria jugar a "algunos" juegos de snes que no se puede hoy dia, pero dudo mucho que podamos jugar a cositas tipo Star Ocean .
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions Inc. All rights reserved.