Guía de Haking de la Tecnología Lock-On La referencia completa para agregar las mejoras de la Tecnología "Lock-On" a Sonic the Hedgehog 2, 3 y otros. Por NO CARRIER Versión: 2.1ES (Español) Terminado: 20/01/00 Traducido: 06/02/00 por Wiseman English | Español | Français

Este documento es para proveer documentación técnica completa de la tecnología "Lock-On" del juego "Sonic & Knuckles" de SEGA. Esta información es el resultado de años de investigación de varios contribuyentes, incluyéndome a mí. ¡Esperamos que lo encuentres útil!

Sólo formato binario
Asegúrate de que las ROMs que usas en este proyecto están en formato binario (.BIN). Los otros formatos de archivo, como .SMD y .MD no funcionarán. La razón para esto es porque esos formatos de archivo graban información de una forma que difiere del original. Hablando claro, pone bloques de bytes en diferentes lugares. El formato binario, sin embargo, es un volcado directo de los datos de la ROM original, lo cual significa que los datos que ves se guardan en los mismos lugares que en el equivalente físico. Para la explicación detallada de los formatos .SMD y .MD y para comprender mejor por qué esos formatos no pueden usarse, ve a este documento. Documentación de Lanchtool de las ROMs de Genesis.

Si tienes las ROMs en el formato .MD o .SMD, no desesperes. Pueden convertirse fácilmente al formato .BIN usando una utilidad de conversión de ROMs. Prefiero Launchtool para esta tarea porque es la más rápida y fácil de usar. Página web de Lanchtool.Si tienes un Mac,he aquí los programas de otro miembro del SSRG dedicados al Mac: un convertidor al formato BIN desde el SMD, y otro que hace el LockOn de las ROMs.

ROMs sucias
Después de meses de experiencia me he dado cuenta de que hay algunas copias de la ROM de S&K flotando por la red que están "sucias". Eso significa que algunos bytes en la ROM no coinciden con los originales. Hay varias explicaciones posibles de por qué unos pocos bytes podrían estar en 0, como una señal perdida absorbida por la circuitería del copiador de ROMs, pero lo raro es que sólo unos pocos bytes están en 0 y en los mismos lugares.

¿Cómo puede ser esto? Bueno, no tengo experiencia en copiadores de ROM, pero podría ser un error de diseño en el vocador mismo. Los bytes que están en 0 no están demasiado lejos de la cabecera, por ello si esos bytes estuvieran mal, no sería demasiado crucial para la operación normal de la ROM. Sin embargo, los bytes en cuestión se hallan justo en el área de la ROM donde se cree que se toma la decisión de qué ROM se halla en el puerto de expansión. Por eso, es creíble suponer que una ROM final de S&K diferente existe y está flotando por la red junto con la normal.

De todas formas, si tienes una ROM sucia de S&K, solamente necesitarás un paso adicional de coger un editor hexadecimal y corregir los bytes alterados. Si utilizar un editor hexadecimal te da escalofríos, puedes probar uno de estos parches IPS que he hecho. Este paso puede hacerse antes o después de que S&K sea combinado con otro juego.

Combinando las ROMs
Este paso es muy simple, en serio. Debes entender que cuando pones otro juego en el puerto de expansión, la Genesis tratará las memorias de los 2 cartuchos como un gran segmento de memoria contíguo. Por ello que no te sorprenda que para crear un juego que sea como, digamos S&K con Sonic 3, sencillamente encadenamos las dos ROMs juntas para generar "un gran segmento de memoria contíguo" que la Genesis verá.

Este paso puede hacerse poniendo los bytes del principio de Sonic 3 al final de S&K, que es una tarea agotadora si se hace a mano con un editor hexadecimal. Se puede escribir un programa para hacerlo, pero la forma más fácil de hacerlo es utilizar el comando COPY del DOS. Podemos decirle a COPY que haga una concatenación binaria de 2 archivos en uno. La sintaxis es esta:

COPY /B S&K.BIN + SONIC3.BIN SONIC4.BIN
           |            |            |
           |            |            - Nombre final (Puede ser lo que quieras.)
           |            |
           |            - Nombre de la ROM para insertar
           |
           - Nombre de la ROM de Sonic & Knuckles

Para entender por qué esto funciona en un emulador, necesitamos mirar el hardware desde la perspectiva de un programador. Para que el programa acceda a los datos, debe especificar una dirección. Por ello, si un programador pide datos de Sonic 3, el programador necesita llamar a la dirección correspondiente de esa parte de la ROM. Para lo que hace no se necesita saber cómo es gestionado por el hardware, excepto que las memorias de los 2 cartuchos es tratada como "un gran segmento de memoria contíguo". Por eso esta técnica funciona correctamente en un emulador sin necesidad de hacer un patch inteligente de la ROM ni ninguna condición en el emulador: ¡no hay hardware programable adicional para hacerlo!

Para comprender mejor cómo es esta implementación del hardware, necesitarás examinar la circuitería extra en la ROM y figurarte qué hace. Descarga este esquema de la circuitería clave en la ROM y lee esta explicación técnica que he escrito. Para acortar una historia larga para aquellos experimentados en hardware, el circuito extra se comporta como un mecanismo de intercambio de bancos, que activa/desactiva la ROM apropiada basado en los bits altos de una petición de dirección. La circuitería incorporada es más avanzada que la que se usa para intercambiar digamos chips de ROM de 4-64 KB, por lo tanto tal vez quieras echar un vistazo de todos modos.

Sonic 3 and Knuckles (S3&K)
Stealth, Tom, y otros han dicho que la tecnología Lock-On es una vergüenza. La razón es que hay evidencias de que Sonic 3 fue diseñado para asociarse con la ROM de S&K en el futuro. Un ejemplo es la posibilidad de seleccionar a Knuckles en la pantalla de selección de personaje de Sonic 3. Esto puede hacerse con un poco de edición hexadecimal inteligente de una partida salvada de esa parte en el juego.Para más información de cómo hacer este hack, visita la Estación de Hacking de Sonic de Tom.

La evidencia más obvia es cómo el chip de SRAM de Sonic 3 es utilizado por Sonic 3 y S&K. Si salvas una partida en Sonic 3 y después intentas salvar un juego en el mismo lugar con Sonic 3 conectado a S&K, descubrirás que el lugar en cuestión está en blanco o que contiene una partida diferente. El hecho de que no se sobreescriben las partidas el uno al otro prueba que uno fue escrito con el otro en mente. (Prueba esto con los juegos reales y con un emulador!)

Pero vaya, hay un problema si intentas salvar un juego con la ROM generada de S3&K en un emulador: no salva el juego al disco. Este problema se atribuye al hecho de que la ROM de S&K no especifica explícitamente que existe SRAM. Para entender por qué es esto un problema, y cómo solucionarlo, necesitamos entender cómo funciona la SRAM.

Si examinas la circuitería del cartucho de S&K, verás que el juego pasa todas sus líneas de datos y direcciones al cartucho en el puerto de expansión. Esta circuitería se asegura de que cada vez que se necesite acceso a la SRAM, el cartucho en el puerto de expansión, o sea Sonic 3, lo recibirá.

Desde la perspectiva de un programador, cualquier hardware de Genesis, sea un registro, la RAM principal, ROM, VRAM o incluso SRAM, es accedido direccionando memoria dentro de un cierto rango (banda) de memoria. Esta técnica se llama mapeo de E/S. Un emulador registrará cualquier dato escrito a/desde cualquier banda de memoria y lo almacenará en su memoria, la SRAM no es una excepción. Por tanto si un juego pide escribir un bloque de datos en la SRAM, el emulador almacenará los nuevos datos y registros en su memoria. Será tarea del emulador asegurar que el nuevo bloque de datos actúe correctamente en la emulación.

Al salir del emulador, los datos en su memoria se pierden, lo cual significa que los datos que estaban eb la RAM principal, la VRAM, etc. se pierden también. Como el emulador no sabe que existe la SRAM, no se molesta en emular la SRAM salvando sus datos al disco. Podría parecer tonto para un autor de un emulador no grabar nada en una banda de memoria usada primariamente para SRAM. Sin embargo, no todos los cartuchos tienen SRAM, y los datos direccionados allí podrían no tener ningún sentido.

Por tanto ahora puedes imaginarte que la solución es hacer que el emulador crea que el juego S&K tiene SRAM. Este paso requerirá un poco de edición hexadecimal de la cabecera de la imagen de la ROM combinada de S3&K.

Los datos desde 1B0h hasta 1BBh de la cabecera de la ROM especifican si hay o no memoria externa (o sea SRAM) disponible. Si la hay, también especificará el rango de su memoria con el principio y el fin de su dirección E/S. Me gusta pensarlo como la "base" y el "registro límite", que se encuentran en la mayoría de las CPUs modernas.

Si no hay memoria externa, esa parte de la cabecera se llena con caracteres de espacio en blanco (20h). Si miras la cabecera de una ROM de S&K, verás que eso es lo que hay. Por tanto, necesitamos cambiar esos bitsd para informar explícitamente al emulador de que existe la SRAM. Esto se hace poniendo los datos de la SRAM de la cabecera de Sonic 3 en la cabecera de S3&K.

Reemplaza datos desde 1B0h hasta 1BCh con 5241 F820 0020 0001 0020 03FF

Donde:
1B0h to 1B3h: -> Informa que hay una unidad de memoria externa. Se usa un código "RA".
1B4h to 1B7h: -> Dirección E/S de comienzo de la RAM externa.
1B8h to 1BBh: -> Dirección E/S de final de la RAM externa.

Graba los cambios y tu emulador favorito debería reconocer que tu ROM de S3&K tiene SRAM. Como un ejercicio, mira a ver si puedes decrubrir tú mismo que los juegos de Sonic 3 y S3&K no se sobreescriben la SRAM uno a otro usados en un emulador.

Lo que hizo esto tan problemático por tanto tiempo fue el hecho de que S&K contiene un parche oculto de 256 KB. Si intentaras copiar los contenidos de S2&K con un copiador de ROMs, no lo reconocería. Esta ROM especial oculta de 256 KB sólo se activa si el juego lo hace; en caso contrario es inaccesible. Ve a mi documento técnico (en inglés) mencionado antes para información de cómo se hace este cambio. Para información de cómo volcar este chip de ROM oculto, mira el documento técnico de Rizzo (en inglés). Si no eres tan ambicioso como para volcar la ROM por tí mismo, puedes descargártela desde este sitio.

Por favor observa que el tamaño correcto de la ROM es de 256 KB, no 512 KB como se sospechaba antes. Aparentemente, el pin asociado con el Address 18 es un pin en blanco, lo cual significa que no está conectado al chip. Además, la cabecera de la ROM de Sonic & Knuckles te dice que es 256 KB.

Hay una sección no documentada en la cabecera para especificar la existencia de módulos de ROM secundarios en el cartucho. El lugar en cuestión se ha documentado como "memo" (desde 1C8h hasta 1EEh). Aparentemente, parece que este lugar de la memoria se había reservado para uso futuro.

Esta sección oculta empieza en 1E0h con "RO," (para ROM,) y luego tiene las direcciones 300000h y 33FFFFh (la dirección I/O de principio y fin). Esto implica que la ROM es 33FFFFh menos 300000h de larga, o sea, 256 KB.

Hay varias razones creíbles de por qué se utilizó una ROM oculta. Para entenderlas, necesitas examinar las teorías de cómo se pasa el control de S&K a Sonic 2. Discutiré la teoría que mejor me suena.

Algunos sospechan que la ROM en sí misma es un parche a los gráficos y niveles en Sonic 2 (por eso aparecen 2 fechas de copyright en la pantalla de título de S2&K). Esto significaría que la ROM de S&K tiene control total del juego de Sonic 2 y usa los datos de Sonic 2 originales meramente para datos. Si esto es cierto, ¿por qué no ocultar este "parche" en la ROM de S&K en sí misma? La razón es porque sencillamente no hay espacio suficiente en la ROM de S&K.

Por tanto, ¿por qué no usaron un chip de ROM más grande? Los chips que SEGA usa en sus cartuchos son de 4 Mbit, 8 Mbit o 32 Mbit, para 256 KB extra habrían tenido que expandir la ROM principal al menos otros 4 Mbit, que habría sido más costoso. También habría complicado la circuitería y la programación por varias razones. Y ya que los datos que guardaría sólo necesitan ser accedidos opr una ROM, fue una solución factible.

De vuelta a lo nuestro. Si miras los esquemas de Rizzo (en inglés) del cartucho de S&K y revisas mi documentación técnica (en inglés) sobre el mecanismo del cartuchio, descubrirás que la forma de concatenar 3 imágenes ROM es básicamente la misma que antes. Por hacerlo simple, el comando es:

COPY /B S&K.BIN + SONIC2.BIN + S2KUPMEM.BIN SONIC4.BIN
           |            |           | 		|
           |            |           | 		- Nombre final (Puede ser lo que quieras.)
           |            |           |
           |            |           - ROM oculta o "parche"
           |	        |
           |            - Nombre de la ROM de Sonic 2
           |
           - Nombre de la ROM de Sonic & Knuckles

Tu nueva imagen ROM funcionará en todos los emuladores, excepto KGen98. La razón es porque KGen98 es un emulador más preciso que los otros al nivel de hardware. Esto significa que KGen98 es más estricto con lo que lee y ejecuta. Nuevamente, este problema se atribuye al síndrome de la "ROM sucia" mencionado antes. Sencillamente modifica este byte para activar la ROM en KGen98.

000003B5: 01->02

Nota: Este byte puede modificarse sin importar qué emulador se va a usar.

Una vez que has completado el último nivel del juego, vuelves atrás y comienzas todo otra vez en el nivel 0, que te lleva al nivel 1, etc. Como podrás ver, este juego no tiene mucho sentido (a menos que estés practicando), por ello aquí hay algunos códigos por si quisieras emprender este reto tridimensional.

De vuelta a lo nuestro. Suponiendo que tienes una copia de S&K a mano, deberías poder combinar los 2 cartuchos igual que antes sin problemas. Si todo va bien, verás una pantalla con un cartel de "NO WAY" scrolleando arriba. Sin embargo, si tu ROM de S&K está sucia, verás la animación normal de inicio de S&K. Para corregir este problema, necesitarás hacer la siguiente modificación en la ROM:

00000433: 00->2C

Nuevamente, este byte está en la zona de la ROM que se cree ser donde se toma la decisión de qué ROM hay en el puerto de expansión.

Por curiosidad, hay algo que he descubierto que no puedo explicar. Necesitarás una ROM de S&K sucia, pero siempre puedes "contaminar" alguna para que no funcione con Sonic 1. Combina la ROM de S&K sucia con Sonic 1 y reemplaza los bytes siguientes:

0000042D: FF->00
0000042F: AE->A1

La ROM te presentará una pantalla en negro. Ahora modifica el byte siguiente como antes:

00000433: 00->2C

y la ROM funciona. Lo que hace esto tan inusual es el hecho de que los primeros 2 bytes (42Dh y 42Fh) están antes del tercero (433h). Podrías pensar que alterar el tercer bytes no tiene efectos en el cambio hecho a los 2 primeros, ¡pero los tiene! Lo que es también raro es que en vez de mostrar la animación de apertura de S&K, esta modificación causa que la ROM se cuelgue con una pantalla negra. Por tanto, ¿qué representan los 2 primeros bytes? Podría ser una dirección, una instrucción de máquina, o una variable. En cualquier caso, parecen estar relacionados... o tal vez no.

GM 00001009-00 (Sonic 1 americano)
GM 00004049-00 (Sonic 1 haponés)

           |---  Cambiar estos bytes no surte ningún efecto.
GM 00004028-008
   |-----|-|
       |  |
       |  -- Estos 2 bytes cambian el color y la dificultad.
       |
       -  Estos bytes cambian el tipo de nivel, color y difcultad.