Convirtiendo juegos a disco: cargadores coñazo

[zup]

Llevo una temporadita convirtiendo juegos a disco para el +3, y después de ciertos problemas iniciales la cosa no parece que se me esté dando tan mal. Tengo problemas con algunas protecciones especialmente difíciles de digerir. Normalmente trato de evitarlas (buscando versiones que tengan protecciones más asequibles), pero hay juegos que no me dejan otra opción.

Me niego a usar snapshots (me gusta tener en disco solo lo que se carga originalmente) o compresores, y necesitaría alguna idea fresca sobre cómo intentar atacarlas.

- Bleepload (Magnetron, Fist+): Por lo que he visto, son una cantidad enorme de minibloques, algunos cifrados. Por lo que he leído, se cargan todos en un buffer, se descifran, se mueven a su ubicación destino y luego se salta a una dirección que viene especificada en el bloque que se ha cargado (habitualmente, se salta otra vez a la rutina de carga; el último bloque presumiblementes salta al código). El problema con esta es que, si fueran uno o dos bloques, no habría mucho problema (se tira de lápiz y papel y listo); hay muuuuchos bloques y realmente me interesa saber qué areas de la memoria se usan y dónde se salta al programa principal.

- Speedlock (Dragon Ninja, Robocop): El inicio de la rutina es todo un coñazo. Lo que se hace al inicio es algo así: muevo un bloque de pocos bytes justo detrás de mi rutina, lo desencripto y salto a la siguiente rutina... que hace exactamente lo mismo... y lo mismo... y así un buen número de veces hasta que llegamos a la chicha. De nuevo estaría bien averiguar dónde empieza realmente la carga del programa, ir dando saltos rutina por rutina lleva bastante tiempo.

- Alkatraz (Ghouls'n'ghosts 128k, The Muncher): Ni lo he tocado. La forma que tiene de cargar la pantalla implica que los datos no se meten a la memoria en el orden en que se cargan, y en el caso del Ghouls, se cargan casi 100k de un golpe (lo que significa que la rutina de carga pagina al vuelo).

- Cargadores especiales de Dinamic (Astro Marine Corps, Freddy Hardest en Manhattan Sur): Tampoco les he metido mano. Hay montones de bloques (como en Bleepload), y en el caso de AMC se mezclan junto con un Master Mind para que te entretengas con la carga.

Una aproximación para estos casos es comparar la memoria antes y después de que el programa haya cargado, para saber qué áreas corresponden al juego. El problema es que (aparte de saber qué áreas están usadas) necesitaría la dirección de inicio del código.

También había pensado mirar en la Tipshop y buscar si hay cargadores para estos juegos (o buscar en mis cintas de Microhobby), destripar los cargadores y saber así cuándo se ha terminado de cargar (justo antes de los pokes) y a dónde se salta después de cargar.

NOTA: La idea de esto es crear juegos que puedan cargar desde disquete o disco duro. No me sirve que me digáis que Robocop salió para +3, porque el juego no se carga mediante ficheros (se leen determinadas zonas del disco) y ese método de carga no va a funcionar desde el disco duro de un +3e.

[antoniovillena]

Con unos archivos .bat y algunas herramientas no es difícil. Lo complicado es saber dónde empieza el juego y qué bloques de memoria son los importantes (desechando cargadores, restos de datos comprimidos, etc...), ya que requiere pelearse un buen rato con el debugger.

Aquí tengo 2 ejemplos de juegos pasados a disco (en la carpeta DSK se generan sin comprimir y en CDSK comprimidos) partiendo del archivo TZX con protección (Alkatraz y Speedlock 2).

http://antoniovillena.es/imagenes_foros ... tected.zip

[zup]

Pueeees... ese es el paso que me falta y que me gustaría acelerar. He visto tu fichero, veo lo que haces y me imagino por qué lo haces, pero lo que me interesa realmente es saber cómo has llegado a los dos datos que necesito:

- Áreas de RAM ocupadas.
- Dirección de inicio del programa (y por dónde anda el sp, y el estado de las interrupciones).

Después de escribir el mensaje, he echado una ojeada a la página de Tipshop, y creo que ya tengo el ataque que voy a usar con Magnetron:

- Rellenar la memoria con un patrón determinado y ejecutar el cargador.
- Volcar la memoria y después correr un programa que me diga en qué áreas sigue presente mi patrón (vamos, las áreas que NO se usan).
- En la Tipshop hay un cargador, y lo último que hace es un jp 40960. Ahí tengo mi dirección de inicio. Comprobando desde ZX Spin, efectivamente se llega ahí cuando está ya todo cargado. Con el breakpoint ahí veo que se llega con sp=$61a8 y las interrupciones activadas.

El tema es que me he peleado con otros juegos (Rainbow Islands, Rambo III) y es más o menos fácil y rápido localizar dónde están las rutinas que cargan los datos y de ahí qué se carga, cuándo y dónde. Otros (Exolon) desencriptan una rutina y de ahí sigue el cargador... los Bleepload, Alkatraz y Speedlock comen mucho tiempo (me tiré media hora con un Speedlock y no llegué muy lejos).

Otro tema sobre el que tengo dudas es mi aproximación a los juegos de 128k multicarga (Rambo III, Rainbow Islands, próximamente Chase HQ). En estos juegos lo que hago es buscar la llamada a la función que carga las fases (p.ej.: en Rambo III está en 32929) y sustituir su llamada o salto (en 32909) por un salto a la función principal (en 25847) o (si se hace algo entre medias, como activar un flag o algo así) una llamada a esa función justo después de la carga del último bloque. No estoy muy seguro de si es la forma más conveniente de hacerlo, también aceptaría sugerencias.

Como curiosidad: Magnetron no termina de cargar en un +3 emulado. Hay un montón de juegos que por usar zonas de memoria reservadas cascan (Rio Blanco) y que si les cargas los datos y los pones a martillazos en su sitio, funcionan correctamente. El caso más sangrante fue Amaurote, que tiene una forma de comprobar si se ejecuta en un 128k tan bestia que directamente resetea los +2A/+3. Si te saltas esa comprobación, todo funciona.

[zx81]

El caso más sangrante fue Amaurote, que tiene una forma de comprobar si se ejecuta en un 128k tan bestia que directamente resetea los +2A/+3. Si te saltas esa comprobación, todo funciona.

Hombre, esto es interesante. Una de las cosas que tenía pendientes en mi emulador era averiguar porqué no funcionaba en modo +2a/+3. Pensaba que era defecto de la emulación. ¿Qué clase de barbaridad intenta hacer, si es que puede saberse?

[zup]

Bueno, llamarlo salvajada quizás ha sido algo precipitado...

Básicamente el problema está en que el juego tiene una rutina en la dirección 36924 que se encarga de comprobar si está en un 48k o un 128k. El procedimiento es el siguiente:

- Meto la página 0 y leo un byte de la dirección 49152 (primera dirección de la RAM paginada).
- Meto la página 7 y escribo un dato en esa dirección.
- Vuelvo a meter la página 0 y compruebo el contenido de esa dirección.
- Si el contenido es igual, el mecanismo de paginación no funciona (48k). Si es diferente, es un 128k.

Ya. Página 7. Escribiendo en una zona reservada por el +3 DOS. Y además, la primera vez que se ejecuta esta comprobación todavía estamos en el BASIC (después se vuelve a ejecutar, pero desde c/m). Al final, lo que pasa es que el +3 se vuelve loco y casca. Una solución es hacer un POKE 36938,19 antes del USR 36924, para que en vez de usar la página 7 haga la comprobación sobre la página 3 (que no se usa para nada en el juego).

Otra solución (si cargas desde disco) es cargar las páginas de memoria primero, cargar el bloque principal después y lanzar el código máquina (sin hacer la comprobación desde el BASIC)... para cuando intenta hacer la comprobación desde el c/m el DOS ya no es un problema. En este caso, además, hay que desactivar la caché (o la página 1 se corromperá).

Hay una cosa muy curiosa que me llamó la atención sobre este juego. Si se mira en WOS, Amaurote apareció en compilaciones en disco, pero eran versiones 48k (probablemente snapshots).

[antoniovillena]

Pueeees... ese es el paso que me falta y que me gustaría acelerar. He visto tu fichero, veo lo que haces y me imagino por qué lo haces, pero lo que me interesa realmente es saber cómo has llegado a los dos datos que necesito:

- Áreas de RAM ocupadas.
- Dirección de inicio del programa (y por dónde anda el sp, y el estado de las interrupciones).

Pues ahí está la gracia, que no hay una forma fácil. Tienes que ir depurando paso a paso y poniendo puntos de ruptura, viendo qué bloques se cargan y en qué direcciones y anotar todo lo que veas relevante, para que la próxima vez que te encuentres con el mismo tipo de protección te sea más fácil desprotegerlo.

Los scripts que he falicitado son para que una vez conozcas estos datos, el proceso de extracción/generación sea totalmente automático.

[zup]

He copiado este hilo en World of Spectrum (donde también abrí un hilo interesante acerca del uso de la RAM en la página 7).

Resumiendo, me han dado un par de pistas muy buenas (más bien me han dado instrucciones sobre el uso de los breakpoints en fuse y ZXSpin). Básicamente, estas son las pistas (primero en fuse, luego en ZXSpin):

- br event tape:stop - Al parecer esto se dispara después de leer el último byte del bloque que se esté cargando. Eso nos sitúa en los últimos restos de la rutina de carga, antes de devolver el control a quien la haya llamado. No parece haber equivalente en ZXSpin.
- br port write 0x7ffd - Esto se dispara al escribir al puerto de paginación de los 128k, lo que nos sitúa en medio de la rutina de paginación. Aunque es fácil ver en ZXSpin qué página de RAM está metida, ver quién llama y desde dónde a la rutina de paginación es muy útil. En ZXSpin la condición sería WPORT=32765.
- br port read 0xfe - Esto sse dispara cuando se lee el puerto 254. habría que afinar un poco, pero nos puede colocar en medio de la rutina de carga (bueno, también se dispara cuando se leen teclas). En ZXSpin la condición es RPORT=254.

Hay que tener en cuenta que las dos últimas condiciones se van a disparar también cuando el BASIC del Spectrum pagine o cuando la rutina de carga del Spectrum lea datos. En ambos casos, sugeriría poner el breakpoint después de que haya saltado al código máquina (es decir, poner primero un breakpoint al inicio del c/m, esperar a que se dispare y entonces poner el siguiente breakpoint).

[zup]

Bueno, después de que me hayan chivado algo de información sobre Bleepload, este cargador ya no es un problema.

Al parecer, por algún extraño motivo, siempre hay un cargador "alternativo" en los juegos. Si se pone el debugger a media carga y se busca 1366 en la memoria, suele aparecer un cargador para el bloque principal y, poco más abajo, el inicio del juego. Con esos datos, grabar sólo lo que se necesita es trivial (de hecho, he convertido un montón de juegos y los he enviado al trastero).

Ahora quedan algunos coñazo: el problema con Speedlock sigue vigente... para llegar al cargador hay que pasearse por cinco o seis rutinas de desencriptado. En principio parece que eso lleva bastante tiempo... hasta que lees por ahí que Alkatraz utiliza entre 150 y 200 rutinas para fastidiar al cracker.

Tirando de la tipshop tengo ya bastantes direcciones de inicio de juegos con estos cargadores. En el peor de los casos puedo preservar toda la RAM y saltar a la dirección de inicio que se indica.

[soilengreen]

Una forma menos complicada es buscar la versión hack normalmente en TAP del juego y ahí el pirata de turno ya hizo hace 25 años gran parte de la faena.
Tengo pendiente (entre otras mil cosas) pasar a disco el Ghost 'n' Goblins

[zup]

Bueno, para mí es algo más satisfactorio "derrotar" las protecciones. Hay otras razones para analizar los cargadores:

- Algunas "conversiones" a tap siguen usando c/m para cargar (aunque sea llamando a 1366), lo que hace que deban ser analizados para que carguen desde disco.

- Otras conversiones usan compresión para reducir los tiempos de carga (en el +3, sería para que quepan más programas por disco). No está mal, pero es algo más problemático si quieres permitir POKEs. Existe un caso mezcla de los otros dos, y es cuando se quita la protección pero se usa una rutina de carga turbo (o turbo+compresión de datos), que también ofrece problemas para usar POKEs.

- En muchos casos, las conversiones cubren un amplio número de juegos de 48k, los de 128k son otra cosa (en especial si 128k significa usar la memoria paginada).

- Hay casos en los que el juego carga niveles en 48k, pero en 128k carga de una tirada (Chase HQ). En otros casos hay un menú que luego carga fases (Viaje al centro de la tierra, Stormlord 2). Y no te digo si pretendes que un juego multicarga cargue los niveles desde disco (usando +3DOS).

- También hay cosas que no suceden al cargar de cinta, como la corrupción de la página 1 y la 7... ese tipo de cosas hay que tenerlas en cuenta cuando cargas cosas desde disco.

Por cierto, yo ya tengo pasado Ghost'n'Goblins. Por ahí encontré una versión comercial sin protecciones, pero no recuerdo dónde (supongo que en alguna recopilación). Quería enviarlo cuando tenga convertido Ghouls'n'ghosts... pero el jodío es un Alkatraz y va a costarme bastante.

[speccy]

Creo recordar que yo tenia por ahi un Ghouls'n Ghosts de carga normal o mas o menos normal. Lo que no recuerdo es si lo tenia pasado a PlusD o no... Hace de eso unos 20 añitos...

[soilengreen]

En su momento todos los intentos de cargar el Ghost n Goblins desde cinta en el +3 acababan en fracaso ,ya cuando cargaba el screen me salían algún cuadro en colorines raro, siempre los mismos y probado en años diferentes pero por ejemplo la versión transtapeada si que cargaba. Lo que me hace pensar/recordar que la incompatibilidad era del loader en si y no del juego..
Son cosas que se me quedaron en el tintero y difícilmente voy a retomar 20 años después de no hacer nada con el Spectrum.

EDIT

Acabo de encontrar esto

Spectrum version
The Spectrum version does not load on Spanish +2A or +3 models, as their ROM mapping is slightly different from the UK models. An unofficial patch is available however.

Fuente: http://www.mobygames.com/game/zx-spectr ... -n-goblins

DE ahí el mosqueo que llevo que el tzx que no carga en mi +3 real si lo haga en el spectaculador en modo +3, pero claro es UK y por eso tira.