Ver la versión completa : ¿Posible solución a roms de más de 64megas?
Pues nada que estaba curioseando por la página de las SDL (www.libsdl.org) y he visto esto: SDL_mmap (http://burningsmell.org/SDL_mmap/)
Entre lo que he visto ahí y en la Wikipedia, parece que la llamada al sistema mmap lo que permite es usar un fichero sin tener que cargarlo en la memoria RAM, siendo el kernel el que se encarga de acceder a las porciones del fichero necesarias. Si no lo he entendido mal, es eso. Mapea el fichero a la memoria virtual, de la que Linux, como buen sistema UNIX-like, hace uso intensivo.
Supongo que esta podría ser la solución a las roms de Neogeo excesivamente grandes (64MB++) siempre y cuando la velocidad de lectura de las tarjetas SD/memoria NAND no sea excesivamente lenta.
Está claro que todo se verá, pero soy optimista y pienso que la velocidad de lectura no va a ser tan lenta. Al menos seguro que es más rápida que la consola original leyendo sus propios cartuchos, la tecnología evoluciona y la Neogeo es muy vieja.
Además no tiene el inconventiente de los ciclos de escritura limitados de las memorias Flash, ya que lo que hacemos es leer, no escribir. En el caso de usar la memoria Flash como RAM virtual (swap) tendríamos que escribir mucho y la memoria moriría pronto.
¿Qué pensáis?
de todas formas,las roms ke okupen mas de 64 megas podrian rular con un emulador de NeoGeoCD,no?
la mayoría de las roms grandes no han salido para neo-geo CD por desgracia.
Electric Dreams
18/10/2005, 00:28
Lo que pasa es que la velocidad de las memorias MMC / SD / MS es muchiiiiiiiiiiiisimo menor que la memoria primaria
Lo que pasa es que la velocidad de las memorias MMC / SD / MS es muchiiiiiiiiiiiisimo menor que la memoria primaria
¿Y cuál es el problema? La Neogeo original accedía directamente al cartucho para leer la parte de la ROM que necesitaba, exactamente de la misma forma que la técnica que he explicado. Los cartuchos de Neogeo estoy seguro que eran mucho más lentos que las memorias MMC / SD / MS. Así que no creo que sea problema, y con linux es muy fácil hacer mmap (o relativamente fácil, para el que sepa programar :rolleyes: )
¿Y cuál es el problema? La Neogeo original accedía directamente al cartucho para leer la parte de la ROM que necesitaba, exactamente de la misma forma que la técnica que he explicado. Los cartuchos de Neogeo estoy seguro que eran mucho más lentos que las memorias MMC / SD / MS. Así que no creo que sea problema, y con linux es muy fácil hacer mmap (o relativamente fácil, para el que sepa programar :rolleyes: )
Una eprom siempre es mas lenta que una rom...
Segata Sanshiro
18/10/2005, 00:43
Los cartuchos de Neogeo estoy seguro que eran mucho más lentos que las memorias MMC / SD / MS.
MEEEEEEEEEEEEC
Error gordo. Cualquier cartucho es más rápido que una SD, una MMC o un M$.
Segata Sanshiro
18/10/2005, 00:44
Una eprom siempre es mas lenta que una rom...
¬¬ Eso me pasa por no recargar la página antes de contestar. :P
Vaya por dios, supuse mal. Pensaba que de una ROM de hace más de una década a una memoria flash de ahora habría una ventaja de velocidad. Veo que no :(
De todas formas, según Squidge el kernel de la GP2X chupa memoria por un tubo que no se puede liberar por culpa de las rutinas de descompresión de MPG2, así que mientras no saquen un kernel modificado, ni siquiera podemos usar esos 64 MB.
bulbastre
18/10/2005, 02:01
Bueno, y si hay tiempos de carga es muy grave?
Damizean
18/10/2005, 04:15
Seria grave si estuviera accediendo a la rom constantemente. De todas formas, los cartuchos actuaban como una extension de la RAM así que era increiblemente rapido para acceder O_o
Bueno, y si hay tiempos de carga es muy grave?
Puedes depende del juego. Si la fase o pantalla completa entrase en memoria, aunque las otras fases se quedasen en la memoria virtual, no habría mucho problema. El problema es que las roms de NeoGeo (al contrario que las de NeoGeoCD) no están pensadas para precargar datos antes de cada nivel, sino que acceden directamente a ellos cuando se necesitan.
Veríamos que el juego de vez en cuando da "tironcillos". Por ejemplo, en un juego de lucha, al hacer una magia determinada por primera vez en la partida, etc... Habría juegos que podrían ir bien, pero no creo que fuese el caso más general.
No seria posible, mediante un emulador de pc, por ejemplo, saber a que direcciones de memoria se accede en un combate, por ejemplo en un juego de lucha?
De esta forma, supongo que se podria deducir que es lo que se va a a necesitar en un momento determinado, y cuando un combate termine, pues se carga lo sguiente, dejando siempre en memoria menus, imagenes etc.Aunque lo veo complicado, creo que si se podria hacer.
Tb se podria jugar sin sonido, sin cargar esas roms, y con las roms desencriptadas que ocupan menos.
Saludos
mortimor
18/10/2005, 16:39
No seria posible, mediante un emulador de pc, por ejemplo, saber a que direcciones de memoria se accede en un combate, por ejemplo en un juego de lucha?
De esta forma, supongo que se podria deducir que es lo que se va a a necesitar en un momento determinado, y cuando un combate termine, pues se carga lo sguiente, dejando siempre en memoria menus, imagenes etc.Aunque lo veo complicado, creo que si se podria hacer.
Tb se podria jugar sin sonido, sin cargar esas roms, y con las roms desencriptadas que ocupan menos.
Saludos
Para eso te haces un juego nuevo :p Eso implicaria revisar explicitamente los datos y conocer las estructuras utilizadas... vamos imposible predecirlo dada la estructura de las roms de neogeo.
Digo yo que el problema de la memoria que se chupa el kernel y los codec (bien agusto 16MB) se soluciona arrancando sin linux por debajo. Aunque esto puede implcar tener que programar el acceso a SD y mas cosas que lo mismo solo estan soportadas como modulos de linux y no como una libreria de C.
Cuantas dudas... creo que hare bien en no comprarmela inicialmente. Con mi GP32 mato el gusanillo de sobra hasta dentro de un tiempo.
Segata Sanshiro
18/10/2005, 23:12
Aparte, habría que tener las roms ya desencriptadas.
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions Inc. All rights reserved.