Utilidades de modificación de ROMs, o ROMhacking

En esta sección, podréis haceros con distintas aplicaciones que permiten el modificado de ROMs o imágenes de disco (ISOs), así como de archivos de programa (por ejemplo ejecutables).

Hemos elaborado una selección de las más importantes.

Aplicadores y creadores de parches .IPS

LunarIPS para Windows, aplicador rápido y sencillo de parches .IPS.

SNESTool para MS-DOS, aplicador de parches .IPS con multitud de opciones avanzadas, ideado para ROMs de Super Nintendo, válido para Nintendo NES.

SEGATool para MS-DOS, aplicador de parches .IPS con multitud de opciones avanzadas, ideado para ROMs de Mega Drive y Master System. Permite corregir la suma de verificación en ROMs de Mega Drive.

Ucon64 para Windows, utilidad de ROMhacking multifunción y multiplataforma. Identifica y muestra las características principales de una ROM, así como la plataforma a que pertenece. Convierte entre diferentes formatos de ROM. Unifica ROMs divididas en un solo archivo, o las divide en varios (posibilitando su lectura en copiones a través de disquetes). Aplica y crea parches. Corrige sumas de verificación erróneas. Asimismo, es capaz de detectar y eliminar bloqueos de región.

Ucon64 para MS-DOS. Versión avanzada de Ucon, en modo protegido (32 bits), para DOS. Requiere 386 o superior.

Ucon para MS-DOS. Versión clásica de Ucon, en modo real (16 bits), para DOS.

Agregador / Eliminador de cabeceras .SMC en ROMs de Super Nintendo

Tush para Windows, permite añadir o eliminar la cabecera de 512 bytes de una ROM de SNES, lo que es necesario para que sea compatible con determinados parches .IPS, y que éstos no corrompan la ROM.

Correctores de suma de verificación

Corrector de suma de verificación de Master System, para Windows. Este programa corrige la suma de verificación (por su voz inglesa checksum) de los juegos de Master System y Game Gear que han sido modificados o traducidos, evitando la aparición del mensaje de "SOFTWARE ERROR" en determinadas BIOS de Master System y Game Gear, como por ejemplo en la Master System II con Alex Kidd en memoria.

Corrector de suma de verificación de Mega Drive y 32X, para Windows. Evita que algunos juegos, que tienen control de suma de verificación en el arranque, bloqueen su propia ejecución, tras ser modificados o traducidos. Algunos ejemplos de tales juegos son el Chiki Chiki Boys, el Jurassic Park, etc.

Corrector de suma de verificación de Super Nintendo, para Windows. Corrige la suma de verificación de juegos de SNES, haciendo que aparezca corregida en emuladores, si han sido previamente traducidos o modificados.

Modificador de parámetros de ROM

NES2Edit, para Windows. Modifica parámetros de ROMs de Nintendo, como el tipo de región (NTSC, PAL o dual), el formato de cabecera, o el tipo de mapeador utilizado.

Editor hexadecimal

Hexpose o Hexposure, para MS-DOS. Permite la edición hexadecimal de un archivo o ROM. Puede ejecutarse en Windows actuales, o en Linux, mediante DOSBox.

Editor de teselas (o por su voz inglesa tiles)

Tile Layer, para MS-DOS. Permite la edición de los gráficos almacenados en el interior de una ROM o archivo.

Reproductor y grabador de imágenes de cinta

PlayTZX, para Windows. Sencillo programa por línea de comandos que permite la reproducción analógica, es decir, en forma de audio, de una imagen de cinta de Spectrum o Amstrad CPC. Esto es extremadamente útil para cargar juegos en el Spectrum o Amstrad desde el PC. Basta conectar un cable de audio jack que vaya de la salida de auricular del PC a la entrada de micro del Spectrum y ejecutar el comando de carga (en Spectrum, LOAD "", en Amstrad, RUN ""). En ordenadores Amstrad CPC 6128 necesitaremos un cable DIN-5 a jack para poder realizar esta operación. En ordenadores Spectrum +2 y Amstrad CPC 464 ó 472 necesitaremos una falsa cinta de cassette conectada a un cable jack utilizada para reproducir CDs y mp3 en reproductores de cassette del coche antiguos, de alta utilidad y cuya posesión es prácticamente obligada por parte del usuario contemporáneo de todo ordenador de casete que se precie: el cable jack irá conectado a la salida de audio del PC, y la falsa cinta insertada en la unidad de cassette del CPC o del Spectrum. PlayTZX también puede utilizarse para pasar imágenes de cinta del ordenador a una cinta de cassette, la cual luego podremos utilizar cómodamente en nuestro ordenador de cintas, conectando dicho cable jack a la entrada de micro de un radiocassette y dándole a grabar.

TZX2WAV, para Windows. Sencillísimo programa que permite convertir imágenes de cinta de Spectrum y Amstrad CPC a formato onda de sonido, es decir, .WAV, el cual puedes reproducir desde tu ordenador conectando mediante un cable jack la salida de altavoz de tu PC a la entrada de micro de tu Spectrum (o a una falsa cinta de cassette unida a un cable jack en caso de poseer un Spectrum +2); también puedes convertir dicho archivo .wav a .mp3 y reproducirlo cómodamente desde tu teléfono móvil, discman, reproductor USB, .mp4 o lo que sea.

Utilidades TZX, para MS-DOS. Incluye el programa PlayTZX para DOS, así como utilidades conversoras de .TZX a .TAP y viceversa, archivos de onda de sonido (formato .VOC, similar al .WAV) a .TZX, así como utilidades lectoras, conversoras y grabadoras de cintas de Commodore 64. Ideal, y totalmente necesario, para la conversión de imágenes de cinta entre formatos, y para la preservación de cintas de Commodore, imposible de otro modo.

TAP_PLR, para Winamp 2.7. Plugin de Winamp que permite la reproducción de imágenes de cinta .TAP, para Spectrum, posibilitando su carga en un Spectrum real o su volcado a cassette.

Se conoce como ROM a toda la información contenida en un chip de memoria de solo lectura de un cartucho o de una tarjeta de expansión. Dicho de otro modo: la ROM es la parte de un cartucho que contiene todo el código e información del juego; y puede leerse, y volcarse a un ordenador como archivo. A este archivo también se lo denomina convencionalmente "una ROM". Dentro del cartucho, la ROM es leída por la videoconsola como si se tratase de una parte más de su memoria RAM, es decir: la lectura de una ROM por la videoconsola es inmediata, no requiere tiempos de carga, pues ya está cargada desde el momento en que se inyecta en la ranura de cartuchos y se enciende la consola: es parte de la memoria. Ni siquiera es necesario copiar todo el contenido de una ROM a la memoria RAM de una consola u ordenador para que éstos lo lean. No obstante, ciertas tareas de cálculo de operaciones, modificación de variables y descompresión de gráficos o textos que se encuentran dentro de la ROM comprimidos, sí se realizan en la RAM, o volcando contenido a la RAM:

Supongamos que tenemos por ejemplo los fondos de un nivel comprimidos en la ROM del cartucho de Super Nintendo o Mega Drive: la consola leerá gradualmente dicho bloque comprimido y lo irá copiando en forma descomprimida en la RAM. Por ese motivo, ningún bloque de datos comprimidos puede ser mayor que la memoria RAM de su videoconsola u ordenador. En el caso de ordenadores, la existencia de sistemas operativos que también debían ser leídos del disco y cargados en memoria, a veces junto con controladores de dispositivo y programas residentes en memoria, todo lo cual ocupa RAM, puede hacer que un determinado juego diseñado para ejecutar en ese ordenador no pueda cargarse por falta de memoria, lo que obligaba a reconfigurar la secuencia de arranque prescindiendo de controladores de dispositivo y de programas residentes que no fueran estrictamente necesarios. He tenido que hacer infinidad de veces esto en MS-DOS, en mis Pentium I y II, y en 486, a menudo con la ayuda del programa MEMMAKER.EXE, de MS-DOS 6.22. Otras veces, Windows 95 permitía reiniciar temporalmente el ordenador sólo para ejecutar un juego de MS-DOS determinado en el proceso de arranque, antes de que el ordenador pudiera cargar toda la panoplia de controladores innecesarios. Recuerdo haber tenido que hacer infinidad de veces, también, esto, con juegos como Blackthorne, de DOS, Legend of Kyrandia, Dune 2, Alone in the Dark 2, y muchos otros.

La razón por la que en videoconsolas, tanto si son de cartucho como de discos, no es necesario hacer nada de esto, es porque no requieren de un sistema operativo de disco, separado del que se incluye en la propia BIOS, o memoria ROM de arranque de la placa base de la consola, dejando libre, de este modo, el conjunto de la RAM y permitiendo contar a los programadores de distintos juegos con la totalidad de ella.

Cuando elaboramos una traducción, o cualquier modificación de ROM de algún tipo, denominadas alteración de ROM, o por su voz inglesa ROMhack, dicha modificación puede ser almacenada como parche. El parche es un archivo que contiene las diferencias entre la ROM no modificada y la ROM alterada. En el caso de una traducción, el parche contendrá únicamente la traducción, los cambios que dicha traducción hace al texto original en otro idioma, nada más. El formato más habitual de parches es el .IPS, pero hay otros más sofisticados. Aplicando dicho parche a la ROM original para la que ha sido diseñado, podemos extraer una ROM modificada traducida, o con las diferencias que fueren. A este tipo de ROM se la denomina ROM modificada o hackeada, utilizando la voz inglesa.

Es habitual que los ordenadores y muchas videoconsolas, estas últimas, sobre todo, a partir de la irrupción del CD-ROM, utilicen como soporte principal de lectura y almacenamiento de datos sistemas de discos, en lugar de cartuchos. La diferencia principal entre un disco y un cartucho es que toda la información del programa o juego no es accesible por parte de la computadora desde el mismo instante en que se inserta y enciende la máquina, sino que ésta debe acceder a distintas partes de la superficie del disco para leer los archivos e información concreta que le interesa en cada momento. Esto es debido a que la ROM de un cartucho es reconocida por la máquina como parte de su memoria desde el momento de su encendido, pero no sucede así con el disco. De hecho, para que un cartucho funcione, la máquina debe ser encendida con él ya dentro, y éste no se puede extraer durante su ejecución, o dejará de funcionar (ya que echará a faltar una parte de su memoria); en tanto que el disco se puede introducir, extraer y cambiar después de encendida la computadora.

Al igual que sucede en una memoria ROM, en un disco no es necesario leer la totalidad de un archivo de una sola vez, se puede acceder a puntos concretos en el interior de éste. A este sistema de lectura se le llama "acceso directo". Se opone a la "lectura secuencial", propia de los sistemas de cintas. Para que tal cosa sea posible, el disco debe tener formato: una división de su superficie en sectores y/o pistas, con una tabla inicial de asignación de archivos, y códigos de control cada cierta cantidad de bytes que ayuden a obviar o corregir errores de lectura. Al proceso de dar formato a un disco se denomina formatear un disco.

Existen dos tipos de discos: discos magnéticos, como los disquetes o discos duros, y discos ópticos, como los CD-ROM o DVD. Los primeros almacenan la información en el disco grabando en él impulsos magnético-químicos, que modifican la polaridad de un determinado punto de la superficie del disco. La polaridad positiva equivale a un 1 binario, la polaridad negativa equivale a un 0, la falta de carga magnética equivale a superficie no grabada. Por su parte, los discos ópticos almacenan la información sobre sí mediante agujeros: un punto con agujero equivale a un 1, un punto sin él, equivale a 0. La principal diferencia entre ambos sistemas, magnético y óptico, es que el primero es regrabable, y el segundo, sólo puede ser grabado una vez, ya sea de forma industrial o casera, y leído tantas veces como se quiera. En el caso de un CD regrabable (CD-RW), podemos borrar la totalidad de su contenido una vez grabado, y volver a repetir el proceso de reescritura. Sigue siendo un sistema de grabación una sola vez y lectura muchas, a diferencia del disco magnético, pero con la posibilidad adicional de borrado post-grabado.

A una imagen de disco óptico (CD-ROM o DVD) se la denomina ISO (aunque existen de ella varios formatos). A una imagen de disco magnético se la denomina IMG ó DSK.

La principal diferencia entre una imagen de ROM y una imagen de disco es la existencia habitual, en la segunda, de códigos de control, e información de formato: de tabla de asginación de archivos, sector de arranque y subdivisión en sectores y pistas. Por ese motivo, no nos es posible modificar mediante editor hexadecimal una imagen de disco en su totalidad, crear un parche .IPS con sus diferencias con la original, y aplicar el parche a otra imagen de disco a lo bruto, ya que no estaremos actualizando los códigos de control y muy probablemente al leer ese disco o imagen de disco la máquina nos detectará un error de lectura, cuando no directamente corregirá lo modificado restableciéndolo a su forma original.

Para aplicar parches a una imagen ISO o IMG necesitamos un sistema más sofisticado, como por ejemplo, un parche .PPS.

En sistemas de ordenador, a menudo nos es posible trabajar directamente con los archivos que se hallan sobre la superficie de un disco, ya sean archivos de datos creados por el usuario, o archivos incluidos como parte de un programa de ordenador. Podemos visualizar los archivos que componen un programa y acceder directamente a cada uno de ellos en el disco. Así, si el texto que queremos traducir se halla en uno de los archivos de un programa no nos es necesario modificar todo el programa: podemos fácilmente elaborar un parche de ese archivo. Este parche puede ser un simple .IPS, y contendrá las diferencias entre ese archivo original y su contraparte modificada. Cuando distribuyamos nuestra traducción del programa de ordenador vía parche, deberemos acompañarla con las debidas instrucciones sobre a qué archivo concreto del programa es necesario aplicar el parche, a fin de evitar errores. Unas veces el parche modificará el propio archivo ejecutable, o .EXE / .COM, y otras, alguno de los archivos de datos que se incluyen con el programa y que deberán ser leídos, en tiempo de ejecución, por el programa.

En sistemas de ordenador lo suficientemente antiguos era habitual encontrar cintas y unidades de cinta como sistema de almacenamiento normal de datos. Muy comunes, en ordenadores personales de 8 bits, eran las cintas de cassette, sistema rudimentario no diseñado para el almacenamiento de datos sino para audio, pero de muy bajo coste.

Inicialmente, en los inicios de la computación, los superordenadores y los primeros ordenadores personales utilizaban con frecuencia cintas de papel, como sistema de almacenamiento principal de datos. Éstas no eran más que una evolución de la tarjeta perforada. Ambos contenían en forma de agujeros la información: un agujero equivalía a un 1 binario, la ausencia de agujero a un 0. La aparición de las cintas magnéticas supuso un salto evolutivo, permitiendo almacenar mucha mayor información en menos espacio.

Las cintas se diferencian de los discos en que su sistema de lectura es secuencial, deben ser leídas en orden, de principio a fin, ya sea en su totalidad o por fragmentos, a fin de poder acceder al programa o archivo concretos que se encuentra en ella al cual queremos acceder. En cintas de cassette de ordenador era habitual que los programas y juegos distribuidos comercialmente abarcaran la totalidad de la cinta o de una de las dos caras de la cinta. La media de tiempo de carga solía oscilar entre los 3 y 5 minutos. Si se trataba de un programa de una sola carga, sólo debíamos leer una de las dos caras del programa; por lo general ambas caras contenían lo mismo. Todo el programa era volcado en la memoria del ordenador, por lo que el contenido en bytes de la cinta no podía exceder la capacidad de RAM total del ordenador. En un Amstrad CPC 464, de 64 kilobytes, la cinta no podía contener un programa que abarcase más de 64 KB.

Si se trataba de un programa a dos cargas, éste se subdividía en dos partes, que a menudo eran dos programas o juegos diferentes, los cuales se almacenaban, cada uno, en una cara de la cinta. La carga de la cara B, o cara 2, exigía por lo general una contraseña o palabra de paso que nos era dada al completar la parte hallada en la primera cara. No obstante había juegos que permitían la carga de cualquiera de ambas caras a placer. Si se trataba de un programa multicargas, la cinta se subdividía en niveles, de forma tal que una primera carga contenía el ejecutable y a menudo el primer nivel; tras completar éste, el ordenador nos pedía pulsar el botón de PLAY y procedía a cargar el segundo nivel, pisando el contenido del primero; lo mismo con el tercer nivel, y así sucesivamente. Si nos mataban, dependiendo de lo bien que hubiese sido diseñado el programa, había dos opciones: que el programa principal no hubiese sido pisado por las sucesivas cargas, y no nos pidiera rebobinar y volver a cargar de cero la cinta, y que, sólo al comenzar una nueva partida, se nos pidiese rebobinar hasta antes del primer nivel; o que el menú de inicio y presentación del juego ya hubiese sido parcial o totalmente pisado por las sucesivas cargas, y tuviésemos que volver a cargar el juego entero. A esto se debe buena parte de la mala fama de los juegos multicargas: resultaban a menudo tediosos y poco jugables. La cantidad de horas potencial de juego se veía obstaculizada y decrementada por el constante rebobinado y carga.

Podemos extraer el contenido íntegro de una cinta magnética, sea o no de cassette, a nuestro ordenador, en forma de imagen de cinta. Éstas son distinguidas a menudo mediante la extensión .TAP, a modo de distintivo, aunque otras extensiones pueden ser utilizadas, según el formato: .DAT, en el caso de cintas digitales utilizadas para copias de seguridad, y no analógicas. Además, en ordenadores Spectrum, conjuntamente con el formato .TAP, es muy habitual el formato .TZX, mucho más sofisticado, pues no es una imagen literal binaria de los bytes que contiene la cinta, sino una imagen de su contenido analógico compartimentado en bloques con sus respectivas cabeceras, resultando mucho más exacta. En Amstrad CPC existe un equivalente del formato .TZX llamado formato .CDT, que utiliza el mismo formato. En Commodore 64, existe el formato .64 ó .C64, algo diferente.

Una cinta magnética puede ser digital o analógica. Las cintas de cassette son analógicas: esto significa que aunque sus datos, una vez leídos, sean binarios, su sistema de escritura y lectura es analógico, se basa en ondas de sonido de distintas frecuencias prolongadas durante la suficiente cantidad de tiempo como para poder ser diferenciadas y reconocidas por la rutina de carga del ordenador, y las cuales equivalen a un 1, a un 0, a la cabecera de un archivo, o a la cabecera de un bloque de datos, perteneciente o no a un archivo.

Se pueden aplicar parches básicos, como los de tipo .IPS, a una imagen de cinta .TAP, generando su contraparte modificada, ya sea de tipo traducción o de cualquier otro tipo, pero no se recomienda hacerlo sobre imágenes .TZX, dado que a diferencia de la primera, que es una imagen literal en bytes del contenido de la cinta, las segundas contienen códigos de control, así como datos digitales de codificación de onda de sonido que son difílmente reconocibles por un editor hexadecimal y pueden variar ligeralmente de un volcado desde el cassette a otro. Un ejemplo de juego de cinta que tenemos traducido en nuestra página a partir de un .TAP es el Donkey Kong, para ZX Spectrum.