Hola ¿Que tal? En esta entrada no estoy colocando descargas (buuu) ni nada. Simplemente estoy colocando los cheats que encontré para el juego Blazing Souls Accelate de PSP en versión USA.
El juego es RPG táctico relativamente entretenido, pero es muy castigador en el aspecto de que exige mucho tiempo para obtener materiales, accesorios y subir de nivel a los personajes. Además para explorar el mapa utilizas WP, los cuales al inicio del juego son finitos y si te los terminas, quedas atorado sin poder avanzar en el juego.
Algunos de estos cheats los hallé en internet (todos los items de la tienda y todos los títulos), otros están corregidos (como el que te da WP infinitos) y otros son de mi autoría (los que dan todos los STATS y todos los personajes).
Los que pongo aquí están probados y todos funcionan. Estamos en contact.
_S ULUS-10527
_G Blazing Souls Accelate [USA]
_C0 G [MAX]
_L 0x20F3B3A0 0x3B9AC9FF
_C0 WP [MAX]
_L 0x20F3B3A4 0x3B9AC9FF
_C0 CP [MAX]
_L 0x20F3B3A8 0x3B9AC9FF
_C0 PP [MAX]
_L 0x20F3B3AC 0x3B9AC9FF
_C0 EP [MAX]
_L 0x20F3B3B0 0x3B9AC9FF
_C0 Shop Full Items
_L 0x80F3D14A 0x06020001
_L 0x00000001 0x00000000
_C0 Title 1-78
_L 0x40F3BE38 0x004E0001
_L 0x00000002 0x00000000
_C0 Title 79-155
_L 0x40F3BF70 0x004D0001
_L 0x00000002 0x00000000
_C0 MAX AP in Battle(99)
_L 0x21363F34 0x00000063
_L 0x21364EF4 0x00000063
_L 0x21365EB4 0x00000063
_L 0x21366E74 0x00000063
_L 0x21367E34 0x00000063
_L 0x21368DF4 0x00000063
_C0 All Characters available
_L 0x40EF5C18 0x001A0001
_L 0x00000001 0x00000001
_L 0x20EF5CB4 0x0000001A
_L 0x40EF5CB8 0x001A0001
_L 0x00000001 0x00000001
_C0 Zelos All STATS [MAX]
_L 0x20EF6C7C 0x0001869F
_L 0x00EF6C80 0x00000063
_L 0x40EF6C84 0x00070001
_L 0x000003E7 0x00000000
_C0 Adelle All STATS [MAX]
_L 0x20EF7A1C 0x0001869F
_L 0x00EF7A20 0x00000063
_L 0x40EF7A24 0x00070001
_L 0x000003E7 0x00000000
_C0 Aria All STATS [MAX]
_L 0x20EF87BC 0x0001869F
_L 0x00EF87C0 0x00000063
_L 0x40EF87C4 0x00070001
_L 0x000003E7 0x00000000
_C0 Al All STATS [MAX]
_L 0x20EF955C 0x0001869F
_L 0x00EF9560 0x00000063
_L 0x40EF9564 0x00070001
_L 0x000003E7 0x00000000
_C0 Isaac All STATS [MAX]
_L 0x20EFA2FC 0x0001869F
_L 0x00EFA300 0x00000063
_L 0x40EFA304 0x00070001
_L 0x000003E7 0x00000000
_C0 Vaughn All STATS [MAX]
_L 0x20EFB09C 0x0001869F
_L 0x00EFB0A0 0x00000063
_L 0x40EFB0A4 0x00070001
_L 0x000003E7 0x00000000
_C0 Carla All STATS [MAX]
_L 0x20EFBE3C 0x0001869F
_L 0x00EFBE40 0x00000063
_L 0x40EFBE44 0x00070001
_L 0x000003E7 0x00000000
_C0 Kaye All STATS [MAX]
_L 0x20EFCBDC 0x0001869F
_L 0x00EFCBE0 0x00000063
_L 0x40EFCBE4 0x00070001
_L 0x000003E7 0x00000000
_C0 Sciorra All STATS [MAX]
_L 0x20EFD97C 0x0001869F
_L 0x00EFD980 0x00000063
_L 0x40EFD984 0x00070001
_L 0x000003E7 0x00000000
_C0 Shiro All STATS [MAX]
_L 0x20EFE71C 0x0001869F
_L 0x00EFE720 0x00000063
_L 0x40EFE724 0x00070001
_L 0x000003E7 0x00000000
_C0 Duja All STATS [MAX]
_L 0x20EFF4BC 0x0001869F
_L 0x00EFF4C0 0x00000063
_L 0x40EFF4C4 0x00070001
_L 0x000003E7 0x00000000
_C0 Naiz All STATS [MAX]
_L 0x20F0025C 0x0001869F
_L 0x00F00260 0x00000063
_L 0x40F00264 0x00070001
_L 0x000003E7 0x00000000
_C0 Noel All STATS [MAX]
_L 0x20F00FFC 0x0001869F
_L 0x00F01000 0x00000063
_L 0x40F01004 0x00070001
_L 0x000003E7 0x00000000
_C0 Fairuza All STATS [MAX]
_L 0x20F01D9C 0x0001869F
_L 0x00F01DA0 0x00000063
_L 0x40F01DA4 0x00070001
_L 0x000003E7 0x00000000
_C0 Bridgette All STATS [MAX]
_L 0x20F02B3C 0x0001869F
_L 0x00F02B40 0x00000063
_L 0x40F02B44 0x00070001
_L 0x000003E7 0x00000000
_C0 Leeza All STATS [MAX]
_L 0x20F038DC 0x0001869F
_L 0x00F038E0 0x00000063
_L 0x40F038E4 0x00070001
_L 0x000003E7 0x00000000
_C0 Lydia All STATS [MAX]
_L 0x20F0467C 0x0001869F
_L 0x00F04680 0x00000063
_L 0x40F04684 0x00070001
_L 0x000003E7 0x00000000
_C0 Nyuyen Le All STATS [MAX]
_L 0x20F0541C 0x0001869F
_L 0x00F05420 0x00000063
_L 0x40F05424 0x00070001
_L 0x000003E7 0x00000000
_C0 Snow All STATS [MAX]
_L 0x20F061BC 0x0001869F
_L 0x00F061C0 0x00000063
_L 0x40F061C4 0x00070001
_L 0x000003E7 0x00000000
_C0 Jadore All STATS [MAX]
_L 0x20F06F5C 0x0001869F
_L 0x00F06F60 0x00000063
_L 0x40F06F64 0x00070001
_L 0x000003E7 0x00000000
_C0 Edward All STATS [MAX]
_L 0x20F07CFC 0x0001869F
_L 0x00F07D00 0x00000063
_L 0x40F07D04 0x00070001
_L 0x000003E7 0x00000000
_C0 Hermes All STATS [MAX]
_L 0x20F08A9C 0x0001869F
_L 0x00F08AA0 0x00000063
_L 0x40F08AA4 0x00070001
_L 0x000003E7 0x00000000
_C0 Zelena All STATS [MAX]
_L 0x20F0983C 0x0001869F
_L 0x00F09840 0x00000063
_L 0x40F09844 0x00070001
_L 0x000003E7 0x00000000
_C0 Hiro All STATS [MAX]
_L 0x20F0A5DC 0x0001869F
_L 0x00F0A5E0 0x00000063
_L 0x40F0A5E4 0x00070001
_L 0x000003E7 0x00000000
_C0 Yunellia All STATS [MAX]
_L 0x20F0B37C 0x0001869F
_L 0x00F0B380 0x00000063
_L 0x40F0B384 0x00070001
_L 0x000003E7 0x00000000
_C0 Rose All STATS [MAX]
_L 0x20F0C11C 0x0001869F
_L 0x00F0C120 0x00000063
_L 0x40F0C124 0x00070001
_L 0x000003E7 0x00000000
lunes, 4 de diciembre de 2017
lunes, 30 de octubre de 2017
Debraye colosal (EmulationStation edition).
Hola, ¿Cómo están? Espero que se encuentren bien y que estén disfrutando de la recta final del año.
Antes que nada tengo que advertir que esta entrada puede ser un poco larga, difusa y aburrida, pues el motivo principal de la misma es documentar algunas de las cosas en las que he estado perdiendo el tiempo recientemente. A pesar de ello comparto esta información en el blog, ya que existe la remota posibilidad de que algo en lo que he estado experimentando pueda ser de utilidad para usted amable lector.
Hace unas semanas me dí la tarea de organizar unos DVDs con contenido variado que quemé hace cerca de 10 años. Entre la información que encontré en esos DVDs me topé con muchas aplicaciones, juegos y herramientas que databan de la época en que mi computadora de uso cotidiano era una desktop con un procesador Celeron Tualatin a 1.2 Ghz.
Cuando empleaba esa computadora (entre los años 2003 y 2006) ya se encontraban en el mercado los procesadores Pentium 4 con Hyper Threading y los AMD Athlon, por lo que mi computadora se encontraba defasada en términos de potencia. Para tratar de sacar el mayor provecho de la computadora recurría a prácticas bastante engorrosas como la desfragmentación semanal del disco duro y del registro, desactivar y remover la mayor cantidad de servicios y programas que no fueren estrictamente necesarios para que Windows funcionara y por supuesto, usar versiones obsoletas de programas para que sus requerimientos de memoria y procesador fueren los menores posibles.
Mi obsesión llegaba a los extremos de no emplear programas como Winamp 2.x, ya que pese a que era un reproductor que la mayoría de la gente catalogaba como "liviano", la realidad era que se sentía lento y utilizaba mucha más memoria que el Windows Media Player 6.4. Tiempo después aprendí que muchos programas incluídos con Windows como el Windows Media Player, Paint, o Internet Explorer en realidad se "precargan" en memoria al momento que Windows arranca, por lo que se sienten mucho más ligeros y responsivos que las aplicaciones de terceros.
Esa fue una época muy prolifica en el aspecto de aprendizaje, pues en el afán de obtener el máximo rendimiento probaba diferentes versiones de los programas, hacía varios ajustes en el registro e inclusive utilizaba herramientas que prometían contribuir a mejorar el desempeño de la computadora.
Algunas de esas aplicaciones eran Cacheman (para optimizar la memoria y el caché), Rain (en teoría servía para mantener el procesador a baja temperatura mandando instrucciones HLT al CPU), Speedfan (para monitorizar las temperaturas y regular los ventiladores) y RegSupreme (para optimizar el registro de Windows). Aunque algunas aplicaciones tenían una utilidad clara (como Speenfan) otras muy probablemente sólo tenían un efecto placebo o influencia mínima en el rendimiento de la computadora, pues en esa época no acostumbraba hacer mediciones o "benchmarks", simplemente evaluaba de forma subjetiva el desempeño de la computadora.
Aquella computadora no tenía la potencia suficiente para correr los juegos más modernos, por lo que le dedicaba mucho tiempo a jugar Doom 2 y aprovechar la cantidad inmensa de mapas y mods que brindaba la comunidad. Elegía los emuladores que utilizaran la menor cantidad de recursos como el ZSNES, FinalBurn y NeoRAGEx. Dichos emuladores no eran los mejores de su clase ni los más fieles a las plataformas reales, pero tenian el rendimiento suficiente para que los juegos funcionaran a velocidad plena.
Cuando me vi obligado a dejar Windows 98 e instalar Windows XP en la computadora tuve que cambiar muchos de los programas que empleaba, pues eran incompatibles con el nuevo sistema operativo. Entre los damnificados se encontraban los emuladores, pues la versión para Windows de ZSNES tenía un rendimiento muy inferior a la versión de DOS (la cual ni siquiera funcionaba en Windows XP), FinalBurn funcionaba casi igual pero NeoRAGEx tuvo que sufrir parches y modificaciones para mantenerse funcional. Doom 2 y la gran mayoría de los programas en entorno gráfico que había desarrollado para DOS tampoco funcionaban en Windows XP, ni siquiera utilizando todos los modos de compatibilidad disponibles.
Asi fue como tuve que mudarme a emuladores como Snes9x y winKawaks. Para jugar Doom se tenía que recurrir a source ports, entre los cuales había una gran variedad como el Legacy, el prBoom, Risen3D, jDoom/Doomsday y el que me gustaba más que era el zDoom. La ventaja del zDoom es que era muy estable, muy compatible con los mapas que solía emplear, tenía una interfaz intuitiva y era bastante liviano.
En aquella época era reacio a utilizar el MAME, pues solía funcionar más lento que los demás emuladores con los que contaba, además de que en esa época las interfaces gráficas estaban de moda y cualquier cosa que se tuviere que emplear con la línea de comandos era considerada (por lo menos en mi círculo cercano) como algo obsoleto.
Volviendo al presente, la netbook que empleo cotidianamente (una Sony VAIO VPCYB20AL con procesador AMD E-240 a 1.5 Ghz) cuenta con un rendimiento muy similar al Celeron Tualatin a 1.2 Ghz que tenía en aquella época, por lo que decidí instalar Windows XP en una partición del disco duro darle uso de nueva cuenta a esas utilerías de antaño y poner a prueba su efectividad.
Después de batallar un poco tratando de instalar distintas versiones de Windows XP, me decanté por una versión relativamente "limpia" que incluía drivers para controladores de disco SATA. Después de la faena de instalar el sistema y las aplicaciones quedé gratamente sorprendido del rendimiento de la netbook. Funciona de manera sumamente fluida y descubrí que el software que empleaba en esa época sigue sirviendo perfectamente para las labores actuales.
Recientemente me ví en la necesidad de hacer la prueba de actualizar Windows 7 a Windows 10 en otra netbook (una Acer V5 con un Celeron 1007U) y pude experimentar las "bondades" del nuevo Windows. Windows 10 es un sistema operativo muy pesado y que la mayor parte del tiempo se encuentra trabajando en segundo plano "haciendo lo suyo". El uso de memoria, CPU, red y disco duro suelen mantenerse constantemente altos. Incluso da la impresión que el sistema operativo está trabajando "sacando sus pendientes" (o las labores que le halla encomendado Microsoft al crearlo) y que atiende al usuario sólo cuando le queda un poco de tiempo libre y se puede distraer con nuestros "insignificantes encargos", los cuales se ejecutaran con prioridad baja y bajos privilegios por defecto.
Además es un sistema que suele responder de forma muy lenta en hardware poco potente, por lo cual sólo tiene sentido utilizarlo en sistemas modernos de gama media o alta. Y ahi precisamente radica un grave problema, ya que en realidad aporta muy poco a la productividad de las personas y puede llegar a orillar a los usuarios a gastar dinero en adquirir hardware más poderoso para tener una experiencia de uso satisfactoria. Y si bien es posible (como siempre) ponerse manos a la obra para tratar de optimizar el sistema operativo, los servicios del sistema se encuentran muy interconectados y es dificil deshabilitarlos de forma segura sin afectar el sistema de forma impredecible. Además de que las herramientas de configuración se han hecho menos accesibles para el usuario casual, pues se tiene que hacer uso intensivo de la consola de administración para realizar la mayoría de las configuraciones importantes.
Este viaje por los sistemas operativos de antaño y las aplicaciones de tiempos pasados me ha motivado para experimentar un poco con la configuración de la thinclient para tratar de exprimirle el máximo rendimiento. Durante las pruebas he probado distintas instalaciones de Windows XP, tanto con instalaciones propias compiladas con el nLite o con versiones recortadas que se encuentran en internet. A raíz de ello me he percatado que el EWF no funciona en versiones sumamente recortadas de Windows XP, por lo que presumo que su funcionalidad depende de controladores o servicios específicos.
Gracias a las instalaciones que he realizado de Windows XP y Windows 98 en máquinas virtuales y hardware real he podido rescatar muchas demos y programas de tutoriales de hace 15 años o más, en los que se explicaban técnicas en aquél entonces efectivas para hacer efectos visuales de humo, fuego, rotaciones de colores y planos entre muchos otros, principalmente en DOS. Todas esas técnicas han caido en desuso y ya no son útiles en sistemas operativos modernos, pues las interfaces como OpenGL y DirectX no permiten trasladar ese conocimiento para ser empleado en aplicaciones modernas. Inclusive es triste ver muchas homepages con ese tipo de demos y tutoriales y percibir que los autores trataron de trasladar sus técnicas a interfaces más modernas con resultados poco satisfactorios.
Algunos ejemplos bastante interesantes de estas demos se pueden descargar de esta página y en esta otra página podemos encontrar un tutorial bastante completo sobre la técnica de "raycasting" empleada para hacer las proyecciones gráficas empleadas en juegos como Wolfenstein 3D y Doom.
En la página de Fabien Saglard hay información muy interesante sobre diversas técnicas empleadas por algunos de los juegos más influyentes del milenio pasado. Entre los juegos repasados se encuentran los éxitos de iD Software como Wolfenstein 3D, Doom y Quake. Seguí los pasos descritos para compilar Wolfenstein 3D con ayuda de DosBOX y Borland Turbo C++, lo cual me hizo recordar mis tiempos de juventud en los que empleaba herramientas similares para programar.
Eso despertó mi interés por dos cosas en particular, las interfaces de usuario en modo texto (TUI) y el juego Wolfenstein 3D. Traté de buscar información sobre bibliotecas para generar TUIs sin mucho éxito, pues la mayoría de las opciones de suelen reducir a tres opciones:
Es posible hacer interfaces en modo texto en Windows empleando las funcionalidades que brinda el propio sistema operativo. En la página de Ben Ryves podemos encontrar un tutorial bastante didáctico donde podemos aprender el conceptos básicos necesarios para hacer nuestras interfaces en modo texto.
Después de compilar Wolfenstein 3D y leer un poco más sobre su historia en la página de HardCoreGaming 101 me decidí a probar el juego. Conocía de su existencia pero nunca me dió curiosidad por probarlo, pues en las imágenes siempre me daba la impresión de que era una versión muy "cutre" de Doom. Sin embargo al probar el juego se puede percibir una atmósfera peculiar y distinta a la que tiene Doom.
Por fortuna cuando iD Software decidió liberar el código fuente, decidió de forma indirecta y circunstancial preservar el juego para la posteridad, pues es posible usar el juego en sistemas operativos actuales. Y otra gran ventaja es que podemos disfrutar del juego de distintas formas ya que podemos recurrir a un source port como ECWolf o recurrir a las conversiones del juego para source ports de otros juegos como GZDoom.
Otra de las ventajas de contar con los source ports es que podemos aprovechar el trabajo de la comunidad para aplicar mejoras en el juego. En particular las mejoras cosméticas nos pueden permitir mejorar la atmósfera del juego sin impactar de forma negativa el modo de juego. A continuación muestro unas imágenes comparativas entre Wolfenstein 3D funcionando con ECWolf y con GZDoom tanto con texturas en calidad estándar y con texturas en alta calidad.
Les comparto las texturas en alta calidad para ECWolf aquí. El paquete de conversiones para GZDoom se encuentra aquí y las texturas en alta calidad para GZDoom con temática de Wolfenstein 3D se encuentran aquí.
El proyecto Retrorange Pi ha quedado un poco rezagado, pues no hay actualizaciones al mismo desde principios de año y muchos de los problemas que tenía ese sistema (en particular configuraciones con el emulador reicast) han quedado sin solución. Logré hacer una configuración funcional y pude disfrutar de algunos juegos con ella, pero el tiempo de arranque del sistema es sumamente largo (aún empleando una microSD clase 10). Además, la edición de la configuración y el traslado de roms al sistema es algo relativamente engorroso, aún realizándolo desde un sistema linux (que nos permite montar el sistema de archivos de la tarjeta de memoria de forma directa). Configurar el Retrorange Pi usando una computadora con sistema Windows es una labor aún más engorrosa, pues se tiene que recurrir a conectarse a través de SMB y carpetas compartidas o en su defecto, copiar los archivos y roms a una USB y hacer la copia al sistema desde el escritorio XFCE de la Orange Pi.
Otra opción que se tiene para emplear la Orange Pi como sistema de juegos es Lakka, el cual es un sistema dedicado de forma exclusiva a correr Retroarch. Retroarch es una aplicación que nos sirve para administrar y lanzar emuladores que estén compilados como aplicaciones libretro. De esta forma se logra tener consolidada toda la configuración, ya que las aplicaciones libretro cuentan con interfaces comunes para el audio, el video y los controles.
El rendimiento de Lakka es muy bueno y en términos generales es superior al que brinda Retrorange Pi. Cuando se emulan sistemas exigentes como PSP la diferencia de rendimiento es muy notoria. Retroarch es un sistema consolidado y en muchos aspectos es restrictivo, pues no nos permite correr aplicaciones que no sean Libretro.
Recientemente mi amigo MagmaD comenzó el proyecto de darle uso a una netbook Dell con un procesador Atom N270 como máquina para juegos retro. Intentó correr Lakka para sistemas x86 pero no tuvo éxito, por lo que siguiendo la guía de un video de Youtube decidió probar batocera.linux el cual es una distribución Linux que funciona de forma muy similar a Retrorange Pi o Recalbox. Las pruebas de mi amigo en su netbook fueron satisfactorias, por lo que decidí probar esa distribución en mi netbook y el desempeño fue bueno pero tuve inconvenientes para hacer funcionar el audio.
Las pruebas en mi Thinclient fueron decepcionantes, pues batocera.linux no cuenta con controladores para el GPU Radeon X1200 y el rendimiento fue sumamente pobre. Decidí explorar la alternativa de adaptar una interfaz gráfica para emuladores en el Thinclient, con la idea de consolidarlo como una plataforma retro.
En mi Workstation (que funciona sobre Windows 7 de 64 bits) empleo Emulation Station, sin embargo en internet hay muchos reportes de que Emulation Station no funciona sobre Windows XP, por lo que decidí explorar alternativas más antiguas que muy probablemente funcionarían sobre Windows XP.
Las interfaces que probé son las siguientes:
MAMEWah es muy flexible, soporta manejo desde controles USB y es bastante responsivo. Sin embargo presentó problemas para ejecutar los juegos, ya que es posible ejecutar los juegos una sola vez, después de ello el frontend no vuelve a lanzar juegos hasta que se reinicia.
gLaunch es muy responsivo, tiene soporte parcial para controles USB y en general funciona muy bien. Sin embargo no es muy flexible en sus configuraciones y el código fuente tiene muchísimas dependencias que dificultan hacer las modificaciones pertinentes en el programa para adaptarlo a mis caprichos.
LemonLauncher es un mal chiste, es simplemente un lanzador de aplicaciones en texto, pero que para colmo en vez de usar modo texto puro utiliza SDL. No es configurable y sólo soporta teclado, por lo que es más parecido a un menú hecho en un batch que a un frontend.
Kymaera es un frontend muy atractivo y configurable. Después de lidiar algunas horas con su configuración pude hacerlo funcionar de forma correcta. Sin embargo el problema surgió al tratar de usarlo con un control USB, ya que pese a que es una caracteristica que anuncia el programa, en realidad no funciona y todas las horas de pruebas y comprensión de sus enredadas configuraciones fueron una pérdida de tiempo.
MALA es un frontend que además de que cuenta con una página reportada como maliciosa, es sumamente rígido y ni siquiera permite ser utilizado si no se generan bases de datos y no se configura MAME al arrancar el programa.
En la inmensa fuente de sabiduría que son los foros de internet encontré algunas otras recomendaciones como HyperSpin, Launchbox y algunas otras alternativas tanto ultra pesadas como comerciales.
Lo anterior me llevó a seguirme documentando para tratar de hacer mi propia implementación de un frontend que fuera liviano y soportara controles USB. Esa fue una de las motivaciones para buscar bibliotecas para hacer interfaces en modo texto y también busqué información sobre las bibliotecas disponibles para leer los botones de un control en Windows.
En internet hay múltiples ejemplos para bibliotecas como DirectInput, SDL y rawinput, sin embargo todas esas bibliotecas agregan un grado extra de complejidad a una tarea que en esencia es muy simple. Así fue como dí con información sobre la interfaz Winmm que se encuentra disponible de forma estándar en Windows (como Winapi y GDI).
Aquí comparto una breve aplicación que lee el estado de un joystick con WinMM y lo imprime en la consola de texto, para compilarlo basta con enlazarle la biblioteca de windows que emplee nuestro compilador. Está escrito en lenguaje C (el lenguaje de los Campeones).
Después de varios tumbos y estar tratando de consolidar algunas ideas decidí probar Emulation Station en mi instalación de Windows XP... Y para mi sorpresa funcionó perfectamente. En resumen, gran cantidad del tiempo invertido en investigación y pruebas en realidad nunca hicieron falta y se convirtieron en una grandísima pérdida de tiempo.
Como lección he aprendido que tengo seguir las sabias palabras de Abraham Lincoln: "No creas todo lo que ves en internet".
Con el nuevo conocimiento adquirido de que Emulation Station funciona sobre Windows XP el siguiente paso es adaptarlo a nuestras necesidades. Existe el proyecto Portable Game Station el cual es un paquete que combina Emulation Station, Retroarch, temas y configuraciones para tener un paquete portable de emulación para PC que podemos llevar incluso en una memoria USB o grabar en un disco óptico.
He probado este paquete en Windows 7 de 64 bits y funciona correctamente, sin embargo el Retroarch y los núcleos que incluye no funcionan en Windows XP. Probé con versiones viejas tanto de Retroarch como de los núcleos y con algunas combinaciones es posible arrancar algunos emuladores, pero el rendimiento en equipos de bajo poder (como la netbook o el thinclient) es decepcionante.
Decidí probar algunos emuladores obsoletos que tuvieran un buen desempeño y me permitieran correr los juegos en máquinas con poco poder de procesamiento. Para SNES la elección fue clara con ZSNES, para NES primero elegí Nestopia pero tuve que decantarme por FCEUX por cuestión de compatibilidad con hacks y mappers extraños. Para correr juegos de Arcade la primera opción fue FinalBurn Alpha, el cual según la inmensa fuente de sabiduria de internet es compatible con juegos de múltiples plataformas y tiene un rendimiento mucho mejor al papá de todos los emuladores: MAME (que en inglés de pronuncia "meim" X_x).
Hice algunas pruebas con el FBA, sin embargo siempre que arrancaba el emulador insistía en hacer un escaneo en busca de ROMs. La primera vez decidí dejar al emulador hacer el escaneo, pero al pasar más de media hora y ver que el escaneo no terminaba decidí cancelarlo (además de que sólo tenía 10 archivos en el directorio de roms). Después de ello cada vez que arrancaba el emulador (aún pasándole como parámetro el nombre de la rom que quería emular) volvía a aparecer el diálogo del escaneo de roms X_x. Decidí descartar ese emulador y probar MAME.
Mi sorpresa fue mayúscula al ver que MAME en su versión más actual (191b al momento de escribir estas líneas) funcionó mucho mejor que FBA ya que no sólo arrancó más rápido, sino que la emulación es más fluida, además de que la representación visual y auditiva de los juegos es más fiel en MAME que en FBA.
Una vez más internet mostró su "amplia sabiduría" de rumores y mitos urbanos ya que al contrario de lo que se dice en internet, FBA es un emulador inferior a MAME en cada uno de los aspectos más importantes como lo son audio, video, compatibilidad y rendimiento. El único punto a favor de FBA es que ocupa menos espacio en disco. De nuevo Abraham Lincoln tuvo la razón.
El objetivo ahora fue correr MAME desde EmulationStation, para lo cual existen algunas referencias como la de este video. Les recomiendo ver el video, ya que la gran mayoría de la información que hay en internet para configurar MAME con EmulationStation utilizan la versión de MAME del Retroarch y no el MAME "puro". Una de las grandes ventajas de EmulationStation es que para lanzar las aplicaciones el programa hace una llamada system(); lo que nos permite una flexibilidad inmejorable para lanzar nuestras aplicaciones, pues podemos recurrir a comandos batch, scripts, ejecutables, llamadas remotas o lo que se nos ocurra.
En mi caso me plantee como objetivo correr EmulationStation desde una memoria USB que pudiere conectar a distintas computadoras funcionando sobre Windows, por lo que es imperioso utilizar rutas relativas, pues no sabemos que letra de unidad asignará una computadora a nuestra memoria USB. Para ello arrancamos EmulationStation desde el archivo bat que incluye para hacerlo de forma portable. Sin embargo hay que incluir la línea "SET DRV=%~d0" (sin las comillas) al inicio del archivo bat para tener una variable con la letra de unidad desde la que se está ejecutando EmulationStation.
En mi memoria MAME se encuentra en el directorio %DRV%\EMUS\MAME y tenemos que tenerlo correctamente configurado. Mis roms las he clasificado en directorios dentro de la carpeta de roms de MAME, por lo que las roms misceláneas las coloqué en %DRV%\EMUS\MAME\ROMS\MAME
Así que la configuración del sistema MAME para EmulationStation quedó de la siguiente forma:
Otro de los retos es configurar el emulador Zinc para funcionar con EmulationStation, ya que ese emulador no acepta como parámetro el nombre de la rom que deseamos correr, sino que tenemos que pasarle el número de rom con el que el emulador identifica el juego. Otra vez traté de documentarme al respecto en "la infinita sabiduría de internet" y me topé con "útiles" comentarios como "Es mejor MAME", "ZINC es obsoleto y MAME funciona en TODAS las computadoras" y ninguna pista clara de una forma eficiente de hacer funcionar el emulador. Y si bien MAME es un buen emulador, la realidad es que para emular los juegos de los sistemas ZN1, ZN2, System 11 y en general todas las plataformas que usan gráficos tridimensionales MAME requiere de una computadora con mucha potencia; mucha más de la que tienen mi netbook o mi thinclient.
Para hacer funcionar Zinc con EmulationStation opté por poner el emulador en la carpeta %DRV%\EMUS\ZINC y poner la siguiente configuración de sistema:
En la carpeta "systems\zinc" dentro de EmulationStation decidí poner un archivo bat llamado runzinc.bat que nos traduce el nombre de la rom seleccionada. De esta forma podemos aprovechar la caracteristica de EmulationStation de ponerle nombres descriptivos a las roms en el menú de selección (gracias a su base de datos interna), con el bat obtenemos el número de ROM que requiere Zinc para funcionar.
A continuación pongo el contenido del archivo runzinc.bat:
Una vez lograda la configuración para correr estos emuladores que podríamos catalogar de "problemáticos", el siguiente paso es crear un tema a nuestro entero gusto para usar en EmulationStation.
Me inspiré en el menú de selección de juego de mi cartucho de famiclón que contiene muchos juegos de Super Mario para hacer un tema sumamente simple pero con espíritu retro. Irónicamente he notado que los temas de la mayoría de las consolas o computadoras que se utilizan para "retrogamming" son sumamente modernos, suelen tener música, videos y gráficos en alta definición, pero al momento de hacer funcionar los juegos se suele recurrir incluso a filtros para darle una apariencia "retro" a los juegos. También traté de hacer un logo en vectores para el emulador Zinc que honestamente me quedó horrible, pero es funcional y para ser mi primer logo en vectores creo que el resultado no es tan malo.
He aquí unas imágenes del tema aplicado en resoluciones tanto 4:3 como 16:9.
Y aquí se encuentra el enlace del tema que he bautizado retrobrick. Aquí se encuentra una copia de mi configuración de EmulationStation (sin roms ni emuladores) para referencia.
De esta forma concluimos con esta kilométrica entrada, la cual es principalmente para referencia personal, pero estoy seguro que alguien puede rescatar algo útil de todo este debraye.
Estamos en contact.
A continuación muestro como se ve:
Advertencia.
Antes que nada tengo que advertir que esta entrada puede ser un poco larga, difusa y aburrida, pues el motivo principal de la misma es documentar algunas de las cosas en las que he estado perdiendo el tiempo recientemente. A pesar de ello comparto esta información en el blog, ya que existe la remota posibilidad de que algo en lo que he estado experimentando pueda ser de utilidad para usted amable lector.
Un poco de retro.
Hace unas semanas me dí la tarea de organizar unos DVDs con contenido variado que quemé hace cerca de 10 años. Entre la información que encontré en esos DVDs me topé con muchas aplicaciones, juegos y herramientas que databan de la época en que mi computadora de uso cotidiano era una desktop con un procesador Celeron Tualatin a 1.2 Ghz.
Cuando empleaba esa computadora (entre los años 2003 y 2006) ya se encontraban en el mercado los procesadores Pentium 4 con Hyper Threading y los AMD Athlon, por lo que mi computadora se encontraba defasada en términos de potencia. Para tratar de sacar el mayor provecho de la computadora recurría a prácticas bastante engorrosas como la desfragmentación semanal del disco duro y del registro, desactivar y remover la mayor cantidad de servicios y programas que no fueren estrictamente necesarios para que Windows funcionara y por supuesto, usar versiones obsoletas de programas para que sus requerimientos de memoria y procesador fueren los menores posibles.
Mi obsesión llegaba a los extremos de no emplear programas como Winamp 2.x, ya que pese a que era un reproductor que la mayoría de la gente catalogaba como "liviano", la realidad era que se sentía lento y utilizaba mucha más memoria que el Windows Media Player 6.4. Tiempo después aprendí que muchos programas incluídos con Windows como el Windows Media Player, Paint, o Internet Explorer en realidad se "precargan" en memoria al momento que Windows arranca, por lo que se sienten mucho más ligeros y responsivos que las aplicaciones de terceros.
Esa fue una época muy prolifica en el aspecto de aprendizaje, pues en el afán de obtener el máximo rendimiento probaba diferentes versiones de los programas, hacía varios ajustes en el registro e inclusive utilizaba herramientas que prometían contribuir a mejorar el desempeño de la computadora.
Algunas de esas aplicaciones eran Cacheman (para optimizar la memoria y el caché), Rain (en teoría servía para mantener el procesador a baja temperatura mandando instrucciones HLT al CPU), Speedfan (para monitorizar las temperaturas y regular los ventiladores) y RegSupreme (para optimizar el registro de Windows). Aunque algunas aplicaciones tenían una utilidad clara (como Speenfan) otras muy probablemente sólo tenían un efecto placebo o influencia mínima en el rendimiento de la computadora, pues en esa época no acostumbraba hacer mediciones o "benchmarks", simplemente evaluaba de forma subjetiva el desempeño de la computadora.
Aquella computadora no tenía la potencia suficiente para correr los juegos más modernos, por lo que le dedicaba mucho tiempo a jugar Doom 2 y aprovechar la cantidad inmensa de mapas y mods que brindaba la comunidad. Elegía los emuladores que utilizaran la menor cantidad de recursos como el ZSNES, FinalBurn y NeoRAGEx. Dichos emuladores no eran los mejores de su clase ni los más fieles a las plataformas reales, pero tenian el rendimiento suficiente para que los juegos funcionaran a velocidad plena.
Cuando me vi obligado a dejar Windows 98 e instalar Windows XP en la computadora tuve que cambiar muchos de los programas que empleaba, pues eran incompatibles con el nuevo sistema operativo. Entre los damnificados se encontraban los emuladores, pues la versión para Windows de ZSNES tenía un rendimiento muy inferior a la versión de DOS (la cual ni siquiera funcionaba en Windows XP), FinalBurn funcionaba casi igual pero NeoRAGEx tuvo que sufrir parches y modificaciones para mantenerse funcional. Doom 2 y la gran mayoría de los programas en entorno gráfico que había desarrollado para DOS tampoco funcionaban en Windows XP, ni siquiera utilizando todos los modos de compatibilidad disponibles.
Asi fue como tuve que mudarme a emuladores como Snes9x y winKawaks. Para jugar Doom se tenía que recurrir a source ports, entre los cuales había una gran variedad como el Legacy, el prBoom, Risen3D, jDoom/Doomsday y el que me gustaba más que era el zDoom. La ventaja del zDoom es que era muy estable, muy compatible con los mapas que solía emplear, tenía una interfaz intuitiva y era bastante liviano.
En aquella época era reacio a utilizar el MAME, pues solía funcionar más lento que los demás emuladores con los que contaba, además de que en esa época las interfaces gráficas estaban de moda y cualquier cosa que se tuviere que emplear con la línea de comandos era considerada (por lo menos en mi círculo cercano) como algo obsoleto.
Volviendo al presente, la netbook que empleo cotidianamente (una Sony VAIO VPCYB20AL con procesador AMD E-240 a 1.5 Ghz) cuenta con un rendimiento muy similar al Celeron Tualatin a 1.2 Ghz que tenía en aquella época, por lo que decidí instalar Windows XP en una partición del disco duro darle uso de nueva cuenta a esas utilerías de antaño y poner a prueba su efectividad.
Después de batallar un poco tratando de instalar distintas versiones de Windows XP, me decanté por una versión relativamente "limpia" que incluía drivers para controladores de disco SATA. Después de la faena de instalar el sistema y las aplicaciones quedé gratamente sorprendido del rendimiento de la netbook. Funciona de manera sumamente fluida y descubrí que el software que empleaba en esa época sigue sirviendo perfectamente para las labores actuales.
Recientemente me ví en la necesidad de hacer la prueba de actualizar Windows 7 a Windows 10 en otra netbook (una Acer V5 con un Celeron 1007U) y pude experimentar las "bondades" del nuevo Windows. Windows 10 es un sistema operativo muy pesado y que la mayor parte del tiempo se encuentra trabajando en segundo plano "haciendo lo suyo". El uso de memoria, CPU, red y disco duro suelen mantenerse constantemente altos. Incluso da la impresión que el sistema operativo está trabajando "sacando sus pendientes" (o las labores que le halla encomendado Microsoft al crearlo) y que atiende al usuario sólo cuando le queda un poco de tiempo libre y se puede distraer con nuestros "insignificantes encargos", los cuales se ejecutaran con prioridad baja y bajos privilegios por defecto.
Además es un sistema que suele responder de forma muy lenta en hardware poco potente, por lo cual sólo tiene sentido utilizarlo en sistemas modernos de gama media o alta. Y ahi precisamente radica un grave problema, ya que en realidad aporta muy poco a la productividad de las personas y puede llegar a orillar a los usuarios a gastar dinero en adquirir hardware más poderoso para tener una experiencia de uso satisfactoria. Y si bien es posible (como siempre) ponerse manos a la obra para tratar de optimizar el sistema operativo, los servicios del sistema se encuentran muy interconectados y es dificil deshabilitarlos de forma segura sin afectar el sistema de forma impredecible. Además de que las herramientas de configuración se han hecho menos accesibles para el usuario casual, pues se tiene que hacer uso intensivo de la consola de administración para realizar la mayoría de las configuraciones importantes.
Este viaje por los sistemas operativos de antaño y las aplicaciones de tiempos pasados me ha motivado para experimentar un poco con la configuración de la thinclient para tratar de exprimirle el máximo rendimiento. Durante las pruebas he probado distintas instalaciones de Windows XP, tanto con instalaciones propias compiladas con el nLite o con versiones recortadas que se encuentran en internet. A raíz de ello me he percatado que el EWF no funciona en versiones sumamente recortadas de Windows XP, por lo que presumo que su funcionalidad depende de controladores o servicios específicos.
Los gráficos y textos de DOS.
Gracias a las instalaciones que he realizado de Windows XP y Windows 98 en máquinas virtuales y hardware real he podido rescatar muchas demos y programas de tutoriales de hace 15 años o más, en los que se explicaban técnicas en aquél entonces efectivas para hacer efectos visuales de humo, fuego, rotaciones de colores y planos entre muchos otros, principalmente en DOS. Todas esas técnicas han caido en desuso y ya no son útiles en sistemas operativos modernos, pues las interfaces como OpenGL y DirectX no permiten trasladar ese conocimiento para ser empleado en aplicaciones modernas. Inclusive es triste ver muchas homepages con ese tipo de demos y tutoriales y percibir que los autores trataron de trasladar sus técnicas a interfaces más modernas con resultados poco satisfactorios.
Algunos ejemplos bastante interesantes de estas demos se pueden descargar de esta página y en esta otra página podemos encontrar un tutorial bastante completo sobre la técnica de "raycasting" empleada para hacer las proyecciones gráficas empleadas en juegos como Wolfenstein 3D y Doom.
En la página de Fabien Saglard hay información muy interesante sobre diversas técnicas empleadas por algunos de los juegos más influyentes del milenio pasado. Entre los juegos repasados se encuentran los éxitos de iD Software como Wolfenstein 3D, Doom y Quake. Seguí los pasos descritos para compilar Wolfenstein 3D con ayuda de DosBOX y Borland Turbo C++, lo cual me hizo recordar mis tiempos de juventud en los que empleaba herramientas similares para programar.
Eso despertó mi interés por dos cosas en particular, las interfaces de usuario en modo texto (TUI) y el juego Wolfenstein 3D. Traté de buscar información sobre bibliotecas para generar TUIs sin mucho éxito, pues la mayoría de las opciones de suelen reducir a tres opciones:
- ncurses para sistemas POSIX
- TurboVision para sistemas DOS (con ports no oficiales y relativamente abandonados para MinGW y Linux).
- conio.h para sistemas DOS (con ports abandonados para Windows).
Es posible hacer interfaces en modo texto en Windows empleando las funcionalidades que brinda el propio sistema operativo. En la página de Ben Ryves podemos encontrar un tutorial bastante didáctico donde podemos aprender el conceptos básicos necesarios para hacer nuestras interfaces en modo texto.
Wolfenstein 3D.
Después de compilar Wolfenstein 3D y leer un poco más sobre su historia en la página de HardCoreGaming 101 me decidí a probar el juego. Conocía de su existencia pero nunca me dió curiosidad por probarlo, pues en las imágenes siempre me daba la impresión de que era una versión muy "cutre" de Doom. Sin embargo al probar el juego se puede percibir una atmósfera peculiar y distinta a la que tiene Doom.
Por fortuna cuando iD Software decidió liberar el código fuente, decidió de forma indirecta y circunstancial preservar el juego para la posteridad, pues es posible usar el juego en sistemas operativos actuales. Y otra gran ventaja es que podemos disfrutar del juego de distintas formas ya que podemos recurrir a un source port como ECWolf o recurrir a las conversiones del juego para source ports de otros juegos como GZDoom.
Otra de las ventajas de contar con los source ports es que podemos aprovechar el trabajo de la comunidad para aplicar mejoras en el juego. En particular las mejoras cosméticas nos pueden permitir mejorar la atmósfera del juego sin impactar de forma negativa el modo de juego. A continuación muestro unas imágenes comparativas entre Wolfenstein 3D funcionando con ECWolf y con GZDoom tanto con texturas en calidad estándar y con texturas en alta calidad.
 |
| ECWolf con texturas estándar. |
 |
| ECWolf con texturas en alta definición y texturas para el techo y suelo agregados por mí. |
 |
| Conversión en GZDoom con texturas estándar. |
 |
| Conversión en GZDoom con texturas en alta definición. |
Les comparto las texturas en alta calidad para ECWolf aquí. El paquete de conversiones para GZDoom se encuentra aquí y las texturas en alta calidad para GZDoom con temática de Wolfenstein 3D se encuentran aquí.
¿Y el Recalbox apá?
El proyecto Retrorange Pi ha quedado un poco rezagado, pues no hay actualizaciones al mismo desde principios de año y muchos de los problemas que tenía ese sistema (en particular configuraciones con el emulador reicast) han quedado sin solución. Logré hacer una configuración funcional y pude disfrutar de algunos juegos con ella, pero el tiempo de arranque del sistema es sumamente largo (aún empleando una microSD clase 10). Además, la edición de la configuración y el traslado de roms al sistema es algo relativamente engorroso, aún realizándolo desde un sistema linux (que nos permite montar el sistema de archivos de la tarjeta de memoria de forma directa). Configurar el Retrorange Pi usando una computadora con sistema Windows es una labor aún más engorrosa, pues se tiene que recurrir a conectarse a través de SMB y carpetas compartidas o en su defecto, copiar los archivos y roms a una USB y hacer la copia al sistema desde el escritorio XFCE de la Orange Pi.
Otra opción que se tiene para emplear la Orange Pi como sistema de juegos es Lakka, el cual es un sistema dedicado de forma exclusiva a correr Retroarch. Retroarch es una aplicación que nos sirve para administrar y lanzar emuladores que estén compilados como aplicaciones libretro. De esta forma se logra tener consolidada toda la configuración, ya que las aplicaciones libretro cuentan con interfaces comunes para el audio, el video y los controles.
El rendimiento de Lakka es muy bueno y en términos generales es superior al que brinda Retrorange Pi. Cuando se emulan sistemas exigentes como PSP la diferencia de rendimiento es muy notoria. Retroarch es un sistema consolidado y en muchos aspectos es restrictivo, pues no nos permite correr aplicaciones que no sean Libretro.
Recientemente mi amigo MagmaD comenzó el proyecto de darle uso a una netbook Dell con un procesador Atom N270 como máquina para juegos retro. Intentó correr Lakka para sistemas x86 pero no tuvo éxito, por lo que siguiendo la guía de un video de Youtube decidió probar batocera.linux el cual es una distribución Linux que funciona de forma muy similar a Retrorange Pi o Recalbox. Las pruebas de mi amigo en su netbook fueron satisfactorias, por lo que decidí probar esa distribución en mi netbook y el desempeño fue bueno pero tuve inconvenientes para hacer funcionar el audio.
Las pruebas en mi Thinclient fueron decepcionantes, pues batocera.linux no cuenta con controladores para el GPU Radeon X1200 y el rendimiento fue sumamente pobre. Decidí explorar la alternativa de adaptar una interfaz gráfica para emuladores en el Thinclient, con la idea de consolidarlo como una plataforma retro.
En mi Workstation (que funciona sobre Windows 7 de 64 bits) empleo Emulation Station, sin embargo en internet hay muchos reportes de que Emulation Station no funciona sobre Windows XP, por lo que decidí explorar alternativas más antiguas que muy probablemente funcionarían sobre Windows XP.
Las interfaces que probé son las siguientes:
MAMEWah es muy flexible, soporta manejo desde controles USB y es bastante responsivo. Sin embargo presentó problemas para ejecutar los juegos, ya que es posible ejecutar los juegos una sola vez, después de ello el frontend no vuelve a lanzar juegos hasta que se reinicia.
gLaunch es muy responsivo, tiene soporte parcial para controles USB y en general funciona muy bien. Sin embargo no es muy flexible en sus configuraciones y el código fuente tiene muchísimas dependencias que dificultan hacer las modificaciones pertinentes en el programa para adaptarlo a mis caprichos.
LemonLauncher es un mal chiste, es simplemente un lanzador de aplicaciones en texto, pero que para colmo en vez de usar modo texto puro utiliza SDL. No es configurable y sólo soporta teclado, por lo que es más parecido a un menú hecho en un batch que a un frontend.
Kymaera es un frontend muy atractivo y configurable. Después de lidiar algunas horas con su configuración pude hacerlo funcionar de forma correcta. Sin embargo el problema surgió al tratar de usarlo con un control USB, ya que pese a que es una caracteristica que anuncia el programa, en realidad no funciona y todas las horas de pruebas y comprensión de sus enredadas configuraciones fueron una pérdida de tiempo.
MALA es un frontend que además de que cuenta con una página reportada como maliciosa, es sumamente rígido y ni siquiera permite ser utilizado si no se generan bases de datos y no se configura MAME al arrancar el programa.
En la inmensa fuente de sabiduría que son los foros de internet encontré algunas otras recomendaciones como HyperSpin, Launchbox y algunas otras alternativas tanto ultra pesadas como comerciales.
Lo anterior me llevó a seguirme documentando para tratar de hacer mi propia implementación de un frontend que fuera liviano y soportara controles USB. Esa fue una de las motivaciones para buscar bibliotecas para hacer interfaces en modo texto y también busqué información sobre las bibliotecas disponibles para leer los botones de un control en Windows.
En internet hay múltiples ejemplos para bibliotecas como DirectInput, SDL y rawinput, sin embargo todas esas bibliotecas agregan un grado extra de complejidad a una tarea que en esencia es muy simple. Así fue como dí con información sobre la interfaz Winmm que se encuentra disponible de forma estándar en Windows (como Winapi y GDI).
Aquí comparto una breve aplicación que lee el estado de un joystick con WinMM y lo imprime en la consola de texto, para compilarlo basta con enlazarle la biblioteca de windows que emplee nuestro compilador. Está escrito en lenguaje C (el lenguaje de los Campeones).
Después de varios tumbos y estar tratando de consolidar algunas ideas decidí probar Emulation Station en mi instalación de Windows XP... Y para mi sorpresa funcionó perfectamente. En resumen, gran cantidad del tiempo invertido en investigación y pruebas en realidad nunca hicieron falta y se convirtieron en una grandísima pérdida de tiempo.
Como lección he aprendido que tengo seguir las sabias palabras de Abraham Lincoln: "No creas todo lo que ves en internet".
Emulation Station.
Con el nuevo conocimiento adquirido de que Emulation Station funciona sobre Windows XP el siguiente paso es adaptarlo a nuestras necesidades. Existe el proyecto Portable Game Station el cual es un paquete que combina Emulation Station, Retroarch, temas y configuraciones para tener un paquete portable de emulación para PC que podemos llevar incluso en una memoria USB o grabar en un disco óptico.
 |
| No confundir con la "legendaria" Portable Dream Station. Fuente: El secreto de Haruka Nogizaka. |
Decidí probar algunos emuladores obsoletos que tuvieran un buen desempeño y me permitieran correr los juegos en máquinas con poco poder de procesamiento. Para SNES la elección fue clara con ZSNES, para NES primero elegí Nestopia pero tuve que decantarme por FCEUX por cuestión de compatibilidad con hacks y mappers extraños. Para correr juegos de Arcade la primera opción fue FinalBurn Alpha, el cual según la inmensa fuente de sabiduria de internet es compatible con juegos de múltiples plataformas y tiene un rendimiento mucho mejor al papá de todos los emuladores: MAME (que en inglés de pronuncia "meim" X_x).
Hice algunas pruebas con el FBA, sin embargo siempre que arrancaba el emulador insistía en hacer un escaneo en busca de ROMs. La primera vez decidí dejar al emulador hacer el escaneo, pero al pasar más de media hora y ver que el escaneo no terminaba decidí cancelarlo (además de que sólo tenía 10 archivos en el directorio de roms). Después de ello cada vez que arrancaba el emulador (aún pasándole como parámetro el nombre de la rom que quería emular) volvía a aparecer el diálogo del escaneo de roms X_x. Decidí descartar ese emulador y probar MAME.
Mi sorpresa fue mayúscula al ver que MAME en su versión más actual (191b al momento de escribir estas líneas) funcionó mucho mejor que FBA ya que no sólo arrancó más rápido, sino que la emulación es más fluida, además de que la representación visual y auditiva de los juegos es más fiel en MAME que en FBA.
Una vez más internet mostró su "amplia sabiduría" de rumores y mitos urbanos ya que al contrario de lo que se dice en internet, FBA es un emulador inferior a MAME en cada uno de los aspectos más importantes como lo son audio, video, compatibilidad y rendimiento. El único punto a favor de FBA es que ocupa menos espacio en disco. De nuevo Abraham Lincoln tuvo la razón.
El objetivo ahora fue correr MAME desde EmulationStation, para lo cual existen algunas referencias como la de este video. Les recomiendo ver el video, ya que la gran mayoría de la información que hay en internet para configurar MAME con EmulationStation utilizan la versión de MAME del Retroarch y no el MAME "puro". Una de las grandes ventajas de EmulationStation es que para lanzar las aplicaciones el programa hace una llamada system(); lo que nos permite una flexibilidad inmejorable para lanzar nuestras aplicaciones, pues podemos recurrir a comandos batch, scripts, ejecutables, llamadas remotas o lo que se nos ocurra.
En mi caso me plantee como objetivo correr EmulationStation desde una memoria USB que pudiere conectar a distintas computadoras funcionando sobre Windows, por lo que es imperioso utilizar rutas relativas, pues no sabemos que letra de unidad asignará una computadora a nuestra memoria USB. Para ello arrancamos EmulationStation desde el archivo bat que incluye para hacerlo de forma portable. Sin embargo hay que incluir la línea "SET DRV=%~d0" (sin las comillas) al inicio del archivo bat para tener una variable con la letra de unidad desde la que se está ejecutando EmulationStation.
En mi memoria MAME se encuentra en el directorio %DRV%\EMUS\MAME y tenemos que tenerlo correctamente configurado. Mis roms las he clasificado en directorios dentro de la carpeta de roms de MAME, por lo que las roms misceláneas las coloqué en %DRV%\EMUS\MAME\ROMS\MAME
Así que la configuración del sistema MAME para EmulationStation quedó de la siguiente forma:
<system> <name>mame</name> <fullname>MAME</fullname> <path>..\..\..\..\..\EMUS\MAME\roms\mame</path> <extension>.zip .ZIP</extension> <command>START "MAME" /D %DRV%\EMUS\MAME\ /WAIT %DRV%\EMUS\MAME\MAME.exe %BASENAME%</command> <platform>arcade</platform> <theme>mame</theme> </system>
Otro de los retos es configurar el emulador Zinc para funcionar con EmulationStation, ya que ese emulador no acepta como parámetro el nombre de la rom que deseamos correr, sino que tenemos que pasarle el número de rom con el que el emulador identifica el juego. Otra vez traté de documentarme al respecto en "la infinita sabiduría de internet" y me topé con "útiles" comentarios como "Es mejor MAME", "ZINC es obsoleto y MAME funciona en TODAS las computadoras" y ninguna pista clara de una forma eficiente de hacer funcionar el emulador. Y si bien MAME es un buen emulador, la realidad es que para emular los juegos de los sistemas ZN1, ZN2, System 11 y en general todas las plataformas que usan gráficos tridimensionales MAME requiere de una computadora con mucha potencia; mucha más de la que tienen mi netbook o mi thinclient.
Para hacer funcionar Zinc con EmulationStation opté por poner el emulador en la carpeta %DRV%\EMUS\ZINC y poner la siguiente configuración de sistema:
<system> <name>zinc</name> <fullname>Zinc</fullname> <path>..\..\..\..\..\EMUS\zinc\roms</path> <extension>.zip .ZIP</extension> <command>%HOME%\.emulationstation\systems\zinc\runzinc.bat %BASENAME%</command> <platform>arcade</platform> <theme>zinc</theme> </system>
En la carpeta "systems\zinc" dentro de EmulationStation decidí poner un archivo bat llamado runzinc.bat que nos traduce el nombre de la rom seleccionada. De esta forma podemos aprovechar la caracteristica de EmulationStation de ponerle nombres descriptivos a las roms en el menú de selección (gracias a su base de datos interna), con el bat obtenemos el número de ROM que requiere Zinc para funcionar.
A continuación pongo el contenido del archivo runzinc.bat:
@echo off set CURDRV=%~d0 set GAME=%1 IF /I %GAME%==starglad ( set NUMBER=1 goto running ) IF /I %GAME%==sfex ( set NUMBER=2 goto running ) IF /I %GAME%==sfexj ( set NUMBER=3 goto running ) IF /I %GAME%==sfexa ( set NUMBER=4 goto running ) IF /I %GAME%==sfexp ( set NUMBER=5 goto running ) IF /I %GAME%==sfexpu1 ( set NUMBER=6 goto running ) IF /I %GAME%==sfexpj ( set NUMBER=7 goto running ) IF /I %GAME%==sfex2 ( set NUMBER=8 goto running ) IF /I %GAME%==sfex2j ( set NUMBER=9 goto running ) IF /I %GAME%==sfex2p ( set NUMBER=10 goto running ) IF /I %GAME%==sfex2pj ( set NUMBER=11 goto running ) IF /I %GAME%==sfex2pa ( set NUMBER=12 goto running ) IF /I %GAME%==plsmaswd ( set NUMBER=13 goto running ) IF /I %GAME%==stargld2 ( set NUMBER=14 goto running ) IF /I %GAME%==rvschola ( set NUMBER=15 goto running ) IF /I %GAME%==jgakuen ( set NUMBER=16 goto running ) IF /I %GAME%==rvschool ( set NUMBER=17 goto running ) IF /I %GAME%==shiryu2 ( set NUMBER=18 goto running ) IF /I %GAME%==strider2 ( set NUMBER=19 goto running ) IF /I %GAME%==kikaioh ( set NUMBER=20 goto running ) IF /I %GAME%==techromn ( set NUMBER=21 goto running ) IF /I %GAME%==ts2 ( set NUMBER=22 goto running ) IF /I %GAME%==ts2j ( set NUMBER=23 goto running ) IF /I %GAME%==tgmj ( set NUMBER=24 goto running ) IF /I %GAME%==sncwgltd ( set NUMBER=25 goto running ) IF /I %GAME%==beastrzb ( set NUMBER=26 goto running ) IF /I %GAME%==beastrzr ( set NUMBER=27 goto running ) IF /I %GAME%==bldyror2 ( set NUMBER=28 goto running ) IF /I %GAME%==rvblade ( set NUMBER=29 goto running ) IF /I %GAME%==psyforcj ( set NUMBER=30 goto running ) IF /I %GAME%==psyforce ( set NUMBER=31 goto running ) IF /I %GAME%==psyfrcex ( set NUMBER=32 goto running ) IF /I %GAME%==mgcldtex ( set NUMBER=33 goto running ) IF /I %GAME%==raystorj ( set NUMBER=34 goto running ) IF /I %GAME%==raystorm ( set NUMBER=35 goto running ) IF /I %GAME%==ftimpcta ( set NUMBER=36 goto running ) IF /I %GAME%==gdarius ( set NUMBER=37 goto running ) IF /I %GAME%==gdarius2 ( set NUMBER=38 goto running ) IF /I %GAME%==danceyes ( set NUMBER=39 goto running ) IF /I %GAME%==xevi3dg ( set NUMBER=40 goto running ) IF /I %GAME%==starswep ( set NUMBER=41 goto running ) IF /I %GAME%==myangel3 ( set NUMBER=42 goto running ) IF /I %GAME%==tekkenb ( set NUMBER=43 goto running ) IF /I %GAME%==tekkena ( set NUMBER=44 goto running ) IF /I %GAME%==tekken ( set NUMBER=45 goto running ) IF /I %GAME%==tekken2a ( set NUMBER=46 goto running ) IF /I %GAME%==tekken2b ( set NUMBER=47 goto running ) IF /I %GAME%==tekken2 ( set NUMBER=48 goto running ) IF /I %GAME%==souledga ( set NUMBER=49 goto running ) IF /I %GAME%==souledgb ( set NUMBER=50 goto running ) IF /I %GAME%==souledge ( set NUMBER=51 goto running ) IF /I %GAME%==dunkmnia ( set NUMBER=52 goto running ) IF /I %GAME%==dunkmnic ( set NUMBER=53 goto running ) IF /I %GAME%==primglex ( set NUMBER=54 goto running ) IF /I %GAME%==weddingr ( set NUMBER=55 goto running ) IF /I %GAME%==hyperath ( set NUMBER=56 goto running ) IF /I %GAME%==pbball96 ( set NUMBER=57 goto running ) IF /I %GAME%==susume ( set NUMBER=58 goto running ) IF /I %GAME%==fgtlayer ( set NUMBER=59 goto running ) IF /I %GAME%==ehrgeiz ( set NUMBER=60 goto running ) IF /I %GAME%==tekken3 ( set NUMBER=61 goto running ) IF /I %GAME%==mrdrillr ( set NUMBER=62 goto running ) IF /I %GAME%==aquarush ( set NUMBER=63 goto running ) IF /I %GAME%==pacapp ( set NUMBER=64 goto running ) IF /I %GAME%==glpracr3 ( set NUMBER=65 goto running ) IF /I %GAME%==shngmtkb ( set NUMBER=66 goto running ) IF /I %GAME%==cbaj ( set NUMBER=67 goto running ) IF /I %GAME%==doapp ( set NUMBER=68 goto running ) IF /I %GAME%==tondemo ( set NUMBER=69 goto running ) IF /I %GAME%==mfjump ( set NUMBER=70 goto running ) IF /I %GAME%==hvnsgate ( set NUMBER=71 goto running ) goto end :running START "ZINC" /D %CURDRV%\EMUS\ZINC\ /WAIT %CURDRV%\EMUS\ZINC\ZINC.exe %NUMBER% goto end :end echo end
Una vez lograda la configuración para correr estos emuladores que podríamos catalogar de "problemáticos", el siguiente paso es crear un tema a nuestro entero gusto para usar en EmulationStation.
Me inspiré en el menú de selección de juego de mi cartucho de famiclón que contiene muchos juegos de Super Mario para hacer un tema sumamente simple pero con espíritu retro. Irónicamente he notado que los temas de la mayoría de las consolas o computadoras que se utilizan para "retrogamming" son sumamente modernos, suelen tener música, videos y gráficos en alta definición, pero al momento de hacer funcionar los juegos se suele recurrir incluso a filtros para darle una apariencia "retro" a los juegos. También traté de hacer un logo en vectores para el emulador Zinc que honestamente me quedó horrible, pero es funcional y para ser mi primer logo en vectores creo que el resultado no es tan malo.
He aquí unas imágenes del tema aplicado en resoluciones tanto 4:3 como 16:9.
 |
| Selección de sistema en 4:3 |
 |
| Selección de sistema en 16:9 |
 |
| Selección de juego en 4:3 y mostramos la detección de roms de Zinc. |
 |
| Selección de juego en 16:9 (el logo de PC Master Race también lo vectoricé). |
Y aquí se encuentra el enlace del tema que he bautizado retrobrick. Aquí se encuentra una copia de mi configuración de EmulationStation (sin roms ni emuladores) para referencia.
De esta forma concluimos con esta kilométrica entrada, la cual es principalmente para referencia personal, pero estoy seguro que alguien puede rescatar algo útil de todo este debraye.
Estamos en contact.
Actualización.
He realizado un poco de ajuste cosmético al tema de EmulationStation, ya que el logotipo y el marco gris en la parte superior se veían sumamente mal y le quitaban un poco del aire retro.A continuación muestro como se ve:
 |
| Mucho mejor y más retro. |
domingo, 10 de septiembre de 2017
Segunda mudanza hormiga.
Hola ¿Cómo han estado?
Espero que se encuentren bien pese a los huracanes y a los terremotos que hemos estado sufriendo estos últimos días. En esta ocasión sólo tendremos un breve aviso parroquial y el cual es que finalmente nos hemos librado de las garras de Dropbox y de 4shared.
En el pasado empecé a utilizar los servicios de 4shared ya que me parecía un servicio muy cómodo y fácil de administrar. Con el paso del tiempo cambiaron sus políticas y obligaron a registrarse para poder descargar los archivos alojados en sus servidores. A pesar de ello me parece que brindan un excelente servicio, pero sólo para almacenamiento personal en la nube y no para compartir archivos con terceros. También me parece que tener una cuenta de 4shared es muy conveniente, pues es un servicio donde se pueden hallar algunos archivos poco convencionales (como firmwares de celulares muy viejos).
A la vista de esos inconvenientes procedí a utilizar Dropbox. A pesar de que Dropbox brinda un espacio de almacenamiento ridículo y un ancho de banda risible, permitía compartir de una forma muy fácil y cómoda los archivos. Además contaba con la ventaja de que permitía la ejecución remota de scripts flash como el Dewplayer y se podían emplear los archivos MP3 alojados en Dropbox como fuente de datos remota.
Desgraciadamente Dropbox cambió sus políticas este 2017, lo que le hizo perder las únicas ventajas que brindaba sobre otros servicios, además de que ese cambio de políticas provocó que se rompieran todos los enlaces previos que había puesto en el blog (pues cambiaron las direcciones a los archivos y los hicieron privados).
Así pues, decidí pasar todos los datos a Google, por lo que en estos momentos el blog se encuentra alojado íntegramente en los servidores de Google (las entradas del blog, todas las imágenes y ahora también todos los archivos y enlaces).
Espero que este cambio sea para mejorar, pues ha sido una labor bastante ardua la revisión de cada una de las entradas del blog para corroborar que todos los enlaces se encuentren funcionales. Además me pude percatar que algunas de las páginas a las que llegué a hacer referencia ya no existen más, por lo que esos enlaces han sido removidos o cambiados por enlaces a la Wayback Machine.
Que tengan un excelente inicio de semana. ¡Estamos en contact!
Espero que se encuentren bien pese a los huracanes y a los terremotos que hemos estado sufriendo estos últimos días. En esta ocasión sólo tendremos un breve aviso parroquial y el cual es que finalmente nos hemos librado de las garras de Dropbox y de 4shared.
En el pasado empecé a utilizar los servicios de 4shared ya que me parecía un servicio muy cómodo y fácil de administrar. Con el paso del tiempo cambiaron sus políticas y obligaron a registrarse para poder descargar los archivos alojados en sus servidores. A pesar de ello me parece que brindan un excelente servicio, pero sólo para almacenamiento personal en la nube y no para compartir archivos con terceros. También me parece que tener una cuenta de 4shared es muy conveniente, pues es un servicio donde se pueden hallar algunos archivos poco convencionales (como firmwares de celulares muy viejos).
A la vista de esos inconvenientes procedí a utilizar Dropbox. A pesar de que Dropbox brinda un espacio de almacenamiento ridículo y un ancho de banda risible, permitía compartir de una forma muy fácil y cómoda los archivos. Además contaba con la ventaja de que permitía la ejecución remota de scripts flash como el Dewplayer y se podían emplear los archivos MP3 alojados en Dropbox como fuente de datos remota.
Desgraciadamente Dropbox cambió sus políticas este 2017, lo que le hizo perder las únicas ventajas que brindaba sobre otros servicios, además de que ese cambio de políticas provocó que se rompieran todos los enlaces previos que había puesto en el blog (pues cambiaron las direcciones a los archivos y los hicieron privados).
Así pues, decidí pasar todos los datos a Google, por lo que en estos momentos el blog se encuentra alojado íntegramente en los servidores de Google (las entradas del blog, todas las imágenes y ahora también todos los archivos y enlaces).
Espero que este cambio sea para mejorar, pues ha sido una labor bastante ardua la revisión de cada una de las entradas del blog para corroborar que todos los enlaces se encuentren funcionales. Además me pude percatar que algunas de las páginas a las que llegué a hacer referencia ya no existen más, por lo que esos enlaces han sido removidos o cambiados por enlaces a la Wayback Machine.
Que tengan un excelente inicio de semana. ¡Estamos en contact!
martes, 5 de septiembre de 2017
Peashy Master Race (Virtual Memphis Edition)
Hola, ¿Cómo están?
Espero que se encuentren bien. En esta ocasión volvemos a las dosis de debraye dándole continuidad a la entrada anterior y para ello vamos a crear una máquina virtual en la cual instalaremos y ejecutaremos Windows 98 SE. Esto es debido a que muchas veces requerimos de utilizar software que funcionaba en Windows 9x pero no utilizamos puertos, rutinas o periféricos especiales, por lo que una máquina virtual sería una forma cómoda y rápida de poder ejecutar esos programas.
Advertencia 1: Esta entrada es aún más aburrida que la entrada anterior. Así que si lo que buscan es diversión, les recomiendo que acudan a los blogs de mis amigos, donde podrán obtener un poco de esparcimiento n_n.
Advertencia 2: Esta entrada se encuentra plagada de imágenes, así que si se encuentra visualizando este blog en un navegador chafa, o en un dispositivo con pocos recursos (o sea, también chafa) puede sufrir relentizaciones. Si está visualizando este blog con un navegador en modo texto, esta entrada le parecerá insufrible (y chafa).
Ingredientes.
Para nuestra máquina virtual utilizaremos los siguientes ingredientes:
- Una computadora real, no virtual (seguro que ésta no se la esperaban n_n).
- VirtualBox. Usaremos la versión para simples mortales, que tiene interfaz gráfica y se ejecuta sobre el sistema operativo anfitrión. Si usted emplea la versión para sistemas "headless" con administración web o montada sobre interfaces de virtualización más robustas y no simple paravirtualización, definitivamente esta entrada le parecerá perfectamente aburrida y sin información valiosa, pues esta información es nivel "principiante" (referirse a la Advertencia 1 n_n).
- Una imagen de disco de instalación de Windows 98SE (cortesía de Nostalgia Nerd X_x).
- Un sistema operativo funcional que utilizaremos como anfitrión.
- Espacio suficiente para crear una unidad de almacenamiento para la maquina virtual. Puede ser en una unidad de disco, aunque en este ejemplo optaré por utilizar un disco RAM (porque me sobra RAM y hay que usarla en algo n_n).
Primero nos aseguramos de tener todos los ingredientes, instalar VirtualBox, tener a la mano el instalador de Windows 98 SE y su clave de instalación.
Creando la máquina virtual.
Arrancamos VirtualBox y creamos una nueva máquina virtual (en este caso la llamaremos Win98).
 |
| Un nombre sumamente original n_n. |
 |
| ¡Imagínense tener 512 MB de memoria PC100! |
- Abrimos una terminal y nos desplazamos al directorio donde alojaremos el disco virtual.
- Para este ejemplo haremos un disco virtual llamado "image.img" de 1GB de capacidad (1024MB). Tecleamos el siguiente comando: "dd if=/dev/zero of=image.img iflag=fullblock bs=1M count=1024 && sync"
- El comando anterior hace lo siguiente:
- dd (dataset definition) es el comando que nos creará nuestro disco virtual.
- if=/dev/zero (input file) indica que nuestro archivo de entrada serán "ceros".
- of=image.img (output file) indica que nuestro archivo de salida será la imagen de disco.
- iflag=fullblock (input flag) nos sirve para que el parámetro count sea interpretado como la cantidad de bloques que se leerán del archivo de entrada.
- bs=1M (block size, no "bullshit" n_n) indica el tamaño de los bloques que utilizaremos tanto para leer del archivo de entrada, como los que se escribirán en el archivo de salida.
- count=1024 (contador) copiará 1024 bloques del archivo de entrada al archivo de salida. Si no se especifica, crearemos un archivo que llenará el medio de almacenamiento con el que estemos trabajando, así que mucho cuidado en no omitir este parámetro.
 |
| Le ha demorado 2 segundos hacer el archivo. Y presumimos el modelo de la netbook X_x. |
Al terminar la ejecución de dd se ejecuta el comando sync, con la finalidad de que el disco creado se escriba en el medio de almacenamiento y (que en mi caso es también memoria) no se mantenga en memoria. Esto es debido a que Linux prefiere mantener la información en memoria RAM para evitar en la medida de lo posible accesos a los discos (que son más lentos que la RAM).
Una vez creada la imagen del disco virtual, debemos montarla en la máquina host. Para ello primero teclearemos el comando losetup para ver qué unidades loop tenemos en uso. Si al utilizar el comando losetup no ocurre nada, quiere decir que no estamos empleando unidades loop y podemos emplear el valor loop0 para montar el disco virtual. En caso de que nos muestre información de unidades loop, emplearemos la primer unidad loop disponible (loop1, loop2, etc.). Para montar el disco virtual en el loop0 tecleamos el comando: "losetup loop0 image.img"
En caso se que el comando anterior muestre algún error de permisos, podemos ya sea ejecutarlo como superusuario o agregar nuestro usuario al grupo "disk".
Una vez montado nuestro disco podemos verificar que se ha montado la unidad ejecutando el comando: file -s /dev/loop0 y nos debe devolver "/dev/loop0: data". Si nos devuelve "/dev/loop0: empty" nos indica que no se ha montado la unidad loop.
Una vez que esté montada la unidad loop tenemos que crear el archivo VMDK que le permitirá a VirtualBox acceder al disco. Para este ejemplo crearé un archivo VMDK llamado ramloop00.vmdk (el nombre puede ser el que sea) en mi directorio de usuario. Para ello tecleamos el comando: "VBoxManage internalcommands createrawvmdk -filename /home/raven/ramloop00.vmdk -rawdisk /dev/loop0". Recuerden ajustar el comando a los nombres y rutas que empleen en sus computadoras.
Una vez creado el archivo VMDK, volvemos a VirtualBox y seleccionamos ese archivo como nuestra imagen de disco duro.
 |
| Nos debe detectar el tamaño del disco y no nos tiene que mostrar errores. |
Preparando la instalación.
Montamos el ISO del disco de instalación de Windows 98 en la unidad de CD virtual y arrancamos la máquina virtual.
En el primer menú seleccionamos "Boot from CD-ROM".
 |
| Opción 2. |
 |
| De nuevo opción 2. |
 |
| 1GB era considerado un disco ENORME!! |
En el menú principal seleccionamos la primera opción (Create a DOS partition or Logical DOS Drive).
 |
| Opción 1. |
 |
| Se me había olvidado poner esta imagen X_x. |
En la siguiente ventana seleccionamos la opción Y.
 |
| "Y" de YEAHHH!!! |
 |
| No olvidemos reiniciar. |
|
| Opción 2... De nuevo. |
 |
| Deja Vu! |
Después tecleamos "cd win98" y presionamos ENTER.
Tecleamos "format c:" y presionamos ENTER. Nos pedirá que confirmemos si deseamos continuar, a lo que respondemos "Y" (y ENTER), al terminar de formatear nos pedirá la etiqueta del volumen creado, la cual podemos dejar en blanco.
 |
| Notemos el serial, es 1C19-14F8 |
Luego tecleamos "md win98" y presionamos ENTER.
Posteriormente tecleamos "cd win98" y presionamos ENTER.
Tecleamos "d:" y presionamos ENTER.
Tecleamos "copy *.* c:" y presionamos ENTER.
Una vez que termine de copiar los archivos tecleamos "c:" y presionamos ENTER.
Comenzando la instalación.
Iniciaremos (por fin n_n) la instalación de Windows 98, para ello tecleamos "setup /p j" (para forzar la instalación de ACPI) y presionamos ENTER.
 |
| Los parámetros mágicos, son muy importantes. |
 |
| Comienza la diversión. |
 |
| El tradicional directorio Windows. |
 |
| Para sentirnos "Usuarios Avanzados" n_n, |
 |
| ¿De donde rayos sacará esos nombres tan raros? |
 |
| Hasta este punto hemos tecleado ":" con la tecla "Ñ" X_x |
 |
| Olvidamos hacer un disquete virtual X_x. |
 |
| A continuar con la instalación. |
 |
| Sólo nos falta media hora más X_x. |
Mientras podemos disfrutar de los anuncios que acompañan la instalación y maravillarnos con las increíbles posibilidades que este sistema operativo nos brindará, para arrancar el nuevo milenio como unos verdaderos amos de la tecnología y del internet.
 |
| ¿Se podían enlazar varios modems? A buena hora me entero X_x. |
 |
| ¿Alguna vez alguien hizo "streaming" con el Windows Media Player? |
 |
| La promesa que hacen todos los Windows... Y que nunca cumplen X_x. |
 |
| ¡A sacarle jugo a ese hardware gamer! |
 |
| A reiniciar se ha dicho. |
 |
| Soy el encargado de comprar los pudding n_n. |
 |
| ¿Dónde firmo? |
 |
| Favor de no usar esta clave, ya que aunque es válida se muestra sólo como un ejemplo (guiño, guiño) |
 |
| Al instalar Windows 98 en computadoras reales modernas, si no se pasa el parámetro "/p i" a la instalación nos trabaremos en este punto. |
 |
| Compatible con el horario de verano n_n. |
 |
| ¡Ya casi! |
 |
| ¿Y ese "flickering"? |
 |
| No olviden deshabilitar esta pantalla de bienvenida. |
Llegados a este punto y tal como la gran mayoría de los tutoriales que hay en internet concluimos el debraye, pues se ha logrado el objetivo de "instalar" el sistema operativo.
Estamos en contact!
¿El fin?
Mmmm...
Ejem...
¡No es cierto! Aún quedan algunas cosas por hacer antes de que esta máquina virtual sea siquiera de utilidad.
Notaremos de inmediato que la máquina virtual se mueve con la agilidad de un perezoso entrado en sueño X_x. Esto es debido a que la emulación del modo de video de 4 bits le resulta sumamente demandante a VirtualBox. Para resolver este inconveniente tenemos que instalar un driver de video, el cual dependerá del tipo de procesador que tenga nuestra computadora anfitrión. Quizás leer lo anterior le sorprenda, pero es la realidad y le costó un poco de trabajo a su servidor darse cuenta de ello, ya que asumimos que al ser una máquina virtual los dispositivos son virtuales y por lo tanto "independientes" al hardware real. El asumir lo anterior le llevó a su servidor perder una gran cantidad de tiempo que espero, usted amable lector se pueda ahorrar.
Si tenemos un procesador Intel tendremos que emplear el "Display Doctor" de Scitech. Si por otra parte contamos con un procesador AMD tendremos que utilizar los "Universal VESA/VBE Video Display Driver" de BearWindows. Si tratamos de emplear los drivers universales con procesadores Intel todo funcionará bien (en teoría), pero si tratamos de emplear el Display Doctor con un procesador AMD tendremos unos errores relacionados a los dispositivos virtuales del controlador de video y al reiniciar Windows no arrancará (marcará error de protección y se quedará en bucle infinito).
Para facilitarnos la vida un poco he decidido poner cada uno de los drivers de video dentro de una imagen ISO que se deberá montar en el CD-ROM de la máquina virtual.
Los de Display Doctor están acá.
Los de Universal VESA/VBE están acá.
Si nuestro procesador es Intel (equipo azul de los campeones).
Para instalar el driver de video de Scitech tenemos que descargar, descomprimir y montar la imagen ISO en la máquina virtual.
 |
| ¿Qué información contendrá ese archivo de texto misterioso? |
 |
| Esperemos que pronto salga una versión "Final". |
 |
| Tendremos 21 días antes de decidirnos a comprarlo. |
 |
| Nótese el patrón para simular el degradado azul. |
 |
| ¿Que sería de una instalación sin una BSOD n_n? |
 |
| La ventana de la utilería no cabe en la pantalla X_x. |
 |
| Y la interfaz tampoco es de lo más intuitiva, |
En las opciones que se abren tenemos que seleccionar "Scitech Nucleus Driver", presionar en el botón a la derecha que dice "Apply" y reiniciar.
 |
| Queremos máximo rendimiento y confiabilidad n_n. |
 |
| ¡A reiniciar se ha dicho! |
 |
| Se los advertí X_x. |
Si nuestro procesador es AMD (porque no nos alcanzó para uno Intel X_x).
Para instalar los drivers de Bearwindows tenemos que montar la imagen con los drivers en la máquina virtual.
Dar click derecho sobre el ícono de "My Computer" y seleccionar "Properties".
 |
| O teclear Win+Pause |
 |
| Tampoco tenemos drivers para el USB X_x. |
Seleccionamos la pestaña de "Driver" y presionamos el botón "Update Driver".
 |
| M$ y sus claras explicaciones n_n. |
 |
| ¡Siguiente! |
 |
| ¡Siguiente!¡Siguiente! |
 |
| ¿Se imaginan tener una tarjeta con 32MB de video RAM en 1999? |
 |
| ¡Siguiente!¡Siguiente!¡Siguiente! |
 |
| ¿Que aparato es el que se encuentra a la izquierda de la computadora de la imagen? |
 |
| ¿Acaso será un disco externo de 4TB? |
 |
| ¡Mucho mejor! |
 |
| Por fin se ve decente. |
Y... ¿Cómo transferimos archivos entre la máquina virtual y la máquina real?
Esta es una cuestión un tanto curiosa y podemos emplear diversas técnicas, las cuales dependerán de nuestras necesidades, entorno de uso y porqué no decirlo, de nuestras habilidades. La forma favorita de transferir datos en los tutoriales que hay en internet (si es que abarcan este tópico) es a través de la conexión de red, mapeando una carpeta del sistema anfitrión como unidad de red en el sistema huésped y por medio de SMB o FTP intercambiar los archivos. Este método tiene la ventaja de que se puede modificar el contenido de la carpeta compartida en vivo, sin necesidad de apagar la máquina virtual. Sin embargo tenemos que lidiar con crear usuarios en el SMB, establecer la dirección correcta de conexión, los permisos de los usuarios y también los permisos que se le asignan a los archivos.
Para este debraye emplearemos el método de apagar la máquina virtual y montar el disco virtual en la máquina anfitrión para poder hacer la manipulación de archivos.
Si nuestro anfitrión es Windows (7 en adelante) podemos montar el archivo VHD del disco virtual desde el Administrador de Discos. Si el anfitrión es OSX tendremos que usar el programa “Paragon VMDK Mounter" (requiere registro pero es gratuito) para montar el archivo VHD. Si usamos Linux es posible montar los discos con guestfs, pero en mi caso este método no me ha funcionado, es por ello que recurrí a utilizar un disco virtual en un formato RAW que me permita manipularlo con más libertad.
Para poder acceder al contenido del disco virtual desde Linux primero tenemos que apagar la máquina virtual y desmontar la unidad loop con el comando: "losetup -d /dev/loop0" (o el número de dispositivo loop que esté empleando el disco virtual).
Posteriormente tendremos que montar el sistema de archivos (ojo, que es distinto a montar el disco virtual) en la máquina anfitrión. Para ello necesitamos conocer el "offset" en el que se encuentra el inicio del sistema de archivos que deseamos montar.
Utilizaremos el comando fdisk (el de Linux, no el de Windows/DOS que se llama igual y empleamos casi al principio X_x) con los siguientes parámetros: "fdisk -lu image.img"
Esto nos devolverá para el disco virtual (image.img) empleado en el ejemplo la siguiente información:
Disk image.img: 1 GiB, 1073741824 bytes, 2097152 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000
Disposit. Inicio Start Final Sectores Size Id Tipo
image.img1 * 63 2096639 2096577 1023.7M b W95 FAT32
Como podemos apreciar, nos indica que el tamaño de los sectores en el disco es de 512 bytes (resaltado en verde) y que el sistema de archivos FAT32 donde se encuentra instalado el Windows 98 inicia en el sector 63 (resaltado en rojo).
Con estos datos podemos montar el sistema de archivos en una unidad loop con el siguiente comando: "losetup /dev/loop0 image.img -o $((63 * 512))". El parámetro "-o" nos sirve para especificar el offset donde se encuentra el sistema de archivos y podemos pasarle el parámetro como una operación para no tener que hacer la multiplicación a mano (por si no nos alcanzan los dedos para hacer la operación n_n).
Si pasamos los parámetros de forma correcta podremos abrir el sistema de archivos como si se tratase de una carpeta en el sistema anfitrión y podremos manipular los archivos que deseemos (crear, mover, copiar, borrar o editar). Al terminar de manipular los archivos de la unidad virtual bastará con desmontar el sistema de archivos y aplicar el comando "losetup -d /dev/loop0" para desmontar el dispositivo loop.
 |
| Nótese el número de serie con el que se monta el sistema de archivos, el mismo que nos entregó "format c:" (1C19-14F8). |
Otra ventaja que nos da el emplear un disco virtual en formato RAW es que podemos manipularlo con una gran cantidad de herramientas, podremos convertirlo al formato que deseemos e incluso usarlo con otros programas de virtualización o directamente con emuladores. Y si somos realmente osados, podemos escribir directamente la imagen RAW en un dispositivo real.
Ahora sí tenemos una máquina virtual funcional. Por lo cual sólo queda empezar a sacarle provecho. Les recomiendo que una vez que quede bien configurada su máquina virtual hagan un respaldo del archivo del disco duro para evitarse la faena en futuras ocasiones o quedar a salvo en caso se corrupción de archivos, pues recordemos que Windows 9x era célebre por "pudrirse" con el uso cotidiano.
¡Bonus stage!
¿Y si lo único que nos interesa de Windows 98 es su "look and feel" y no su inestabilidad, sus BSOD, sus problemas con el hardware ni sus drivers obsoletos?
En ese caso podemos recurrir a descargar e instalar Plus 98! (acá está un copia local) que nos permitirá tener los temas de escritorio que se incluían en Windows 98 junto con sus cursores y sonidos. Además instala los clásicos protectores de pantalla, entre los cuales se encuentra el favorito de su servidor, el "Laberinto 3D".
Sin embargo, a este paquete le faltan los sonidos de inicio que empleaban los sistemas Windows 9x, en especial el "The Microsoft Sound" (compuesto por Bryan Eno), el cual sin lugar a dudas es uno de los rasgos más característicos de los Windows de aquella época.
Éste es el Microsoft Sound de Windows 95.
Y éste es el Microsoft Sound de Windows 98.
¡Bonus stage 2!
¿Y si queremos hacer una imagen de floppy virtual para usarla con la máquina virtual?
En este caso podemos emplear el comando siguiente:
dd bs=512 count=2880 if=/dev/zero of=floppy.img
El cual nos generará una imagen de floppy 3.5 pulgadas 2HD vacía, que incluso podremos grabar en un floppy real. Una de las grandes virtudes de trabajar con hardware virtual es que no nos cuesta nada, más que unos cuantos segundos, crear los consumibles que necesitemos.
Les acerco una imagen de floppy preformateado y arrancable aquí.
¡Bonus stage 3!
¿Y si lo que necesitamos es hacer imágenes de CD que contengan información que queramos introducir a la máquina virtual? (Tal como hizo su servidor para introducir los drivers de video usados en esta entrada).Para ello podemos meter todos los archivos que nos interese meter en la imagen dentro de un directorio y ejecutamos el comando siguiente:
mkisofs -o imagen.iso ruta_del_directorio
Esto nos generará una imagen ISO que podemos montar en la máquina virtual o incluso grabar en un CD/DVD/BRD real.
Estamos en contact!!!
Suscribirse a:
Entradas (Atom)
¡Feliz 2021! El retorno del debraye pandémico (Edición "Rompemuros").
Hola, ¿Cómo han estado? Espero que estén con bien, con buena salud y con muchas ganas de aburrirse una vez más con una ronda de debrayes. Es...
-
Hola que tal, ¿Cómo están? Espero que se encuentren bien, sobreviviendo a la pandemia y a la nueva normalidad. Por mi parte las cosas han id... -
Hola ¿Que tal? En esta entrada no estoy colocando descargas (buuu) ni nada. Simplemente estoy colocando los cheats que encontré para el jueg...
-
Hola, ¿Cómo están? Como siempre, espero que estén bien. Por fin he podido hacer un poco de espacio en la vida real para dedicarle un poco ...