Guía práctica de uso Action Replay de C64 (Monitor CM aún en desarrollo )

[BlackHole]

Último mensaje de la página anterior:

Sí te has explicado bien, pero creo que la aproximación que tomas no es del todo correcta. Si buscas por sí solo un 4 en memoria puede haber cientos. NO es lo que hay que buscar, no es la forma más óptima. Teniendo en cuenta que estamos en el procesador 6502 (el 6510 del Commodore 64 es un 6502 modificado para tener más puertos de I/O) pues solo tenemos 3 registros de 8 bits: A, X e Y. Lo que habría que buscar es un LDA #$04, LDX #$04 o LDY #$04 (en opcodes hexadecimal A9 04, A2 04 y A0 04). El buscar 2 bytes en vez de 1 va a ofrecer muchos menos resultados.

Luego a la hora de desensamblar hay que empezar bastantes bytes antes del resultado de la búsqueda. Yo solía empezar 128 antes ($80) porque así vas viendo si hay código o si hay basura (u otros datos), si el flujo del desensamblado sigue una cadena lógica y no hay instrucciones desconocidas (marcadas con ???) en medio de alguna instrucción con sentido. En contraposición al Z80 cuyos bytes a 0 son un NOP, el 0 del procesador 6502 equivale a la instrucción BRK que rompe el flujo del programa: en definitiva no hay ceros en medio de un código 6502 del Commodore 64 (el Apple II sí que puede llegar a utilizar alguna vez la instrucción BRK).

El contenido cargado en un registro no vale para nada si no se deposita en una dirección de memoria, así que inmediatamente después o alguna instrucción más tarde, debe haber un STA, STX o STY con una dirección de memoria (bien en direccionamiento absoluto de 2 bytes, bien en página cero con 1 solo byte) que son las que debemos apuntar en nuestro cuaderno. Al menos, hemos bajado de cientos a pocas unidades. Son estas direcciones las que iremos vigilando mientras perdemos vidas, a ver si suena la flauta.

[BlackHole]

minter: Tu método era para los juegos primigenios, quizás alguno antes de 1984. En cuanto los desarrolladores fueron entendiendo la máquina mejor y usando toda la memoria disponible para hacer virguerías, dejaron de existir los juegos en los que podías hacer un RESET y volver a ejecutarlos con un SYS. No solo bloqueaban el RESET (que aunque es una señal hardware, en el C64 hay un puntero de ejecución tras el RESET que puede ser modificado por software: Commando (C) 1985 Elite es un ejemplo), sino que colocaban cosas en áreas que la propia inicialización del BASIC iba a borrar. De ahí que los cartuchos con botón "freezer" (congelador) que saltaba a una ROM especial del propio cartucho, fuesen cruciales en el avance de la escena.

[minter]

Si, siempre fui muy primate, digo... Primogenio.
Efectivamente, nunca tuve un cartucho serio para esas cosas, por o que me quedé estancado en los primeros, tipo donkey kong, zaxxon, arabian, ghostbusters, grog revenge, popeye...
Juegos que cargaban en poca memoria.
Mira por donde, el Mission Imposible de Epix, con sintesis de voz y todo, entraba en ese hueco. Podías ir al Basic y volver al juego. Ahora, algo cambiaban en la ROM, porque el comando SYS lo tenía pisado con la marca JEDI.
Cuando calleron en mis manos Robocops , Last Ninjas, Dragons Lair, ... Eso se acabó.

Creo que igual el Garfield tambien se podía tracear comodamente y no era tan prehistorico.

[BlackHole]

Pues eso, el Impossible Mission de Epyx es de 1984, además es yankee... y los americanos programaban según las reglas aconsejadas por CBM.
Fueron los europeos quienes luego se las saltaron todas, hahaha. Por cierto, una ROM no se puede cambiar: como su nombre indica es memoria de solo lectura.
No me vayas a ser ahora de los niñatos que llaman "ROMs" a los programas de ordenador, como si fuesen una videoconsola. Tú estás por encima de eso

[minter]

No hombre... No.
Cuando me refiero a la ROM de Basic, es a la instrucción pero no a la ROM.
Ya se que la ROM no es modificable, pero cuando cambian un comando, me refiero a un cambio a donde apunta.
Explicar con el movil, que tiene los botones muy chiquitos es dificil, pero me refería a cambios de vectores. O comamndos nuevos añadidos al Basic descargado en su zona reservada de RAM, con el nombre de JEDI por ejemplo, pero no grabado en la ROM. XD

La ROM solo puede ser cambiada mediante la instrucciön no documentada mediante esta forma:
PAK $h55
PAK $h55

[Chema]

La ROM solo puede ser cambiada mediante la instrucciön no documentada mediante esta forma:
PAK $h55
PAK $h55

[BlackHole]

minter: Todavía no te he entendido nada. Es que no sé qué es eso de JEDI de lo que hablas. ¿Seguro que no sería algo que soñaste?

[minter]

minter: Todavía no te he entendido nada. Es que no sé qué es eso de JEDI de lo que hablas. ¿Seguro que no sería algo que soñaste?

Eso me pasaba aquí, en el juego Mission Imposible.
Cuando lo cargaba sin ejecución automática, me salía algo parecido a lo que adjunto.

IM Load.JPG (20.88 KiB) Visto 391 veces

Pero en vez de salir: 1993 SYS 4096 por ejemplo.... me salía 1993 JEDI 4096... o 1993 JEDI a secas.. eso no lo recuerdo.
Y con el RUN, me lanzaba el juego.

Por otro lado... respecto a lo del trainer... me he fijado en los juegos antiguos y me parece los mas habitual... que las vidas, objetos, cosas, niveles... se almacenan en la página CERO.
Lo que había que buscar es la instrucción que hace el decremento en ese contador de la página CERO.
Osea, identificar que es cada cosa en la página cero y después buscar la instrucción tipo DEC o la que sea, pero de página cero + posición en pg CERO.

Si. Esto en juegos modernos no va a ir. Pero voy a mirar alguno por curiosidad.

Por cierto, estoy haciendo trampas con el ICU64 para ir mas rapido.

[Chema]

Si desensamblamos el contenido en $183E, originalmente era DEC $28 y ahora ha sido modificado por LDA $28
Sencillo, ¿no?

Pues funciona de misericordia, ¿no? porque acabas de cargarte lo que sea que hubiese en el registro A, mientras que DEC no lo hace...

Supongo que es porque si no hay que parchear más bytes. Quiero decir, que si pones NOP, te queda el $28 por ahí, lo que en este caso es PLP, pero podría ser cualquier cosa, incluso ilegal, o una instrucción que necesite más bytes como parámetro y mandarlo todo al carajo. No. En este caso hay que poner dos NOPs seguidos, pero si las vidas no están en página cero, entonces habría que parchear 3 bytes con NOP.

Eso se sabe por el opcode:

Código: Seleccionar todo

MODE           SYNTAX       HEX LEN TIM
Zero Page     DEC $44       $C6  2   5
Zero Page,X   DEC $44,X     $D6  2   6
Absolute      DEC $4400     $CE  3   6
Absolute,X    DEC $4400,X   $DE  3   7

Si se quiere parchear un solo byte, igual es más fácil usar BIT ($24 para página cero, ejemplo anterior, y $2c para absoluto).

Ahora que lo pienso, la verdad es que no es muy natural tener en el registro A nada en ese caso. Probablemente se haga DEC vidas : BEQ gameover, de forma que lo típico es que A se cargue, si se hace, después, pero vete tú a saber...

[kikems]

Ya he publicado en el primer post "La guía de uso del Action Replay de C64", a falta de completar la parte del Monitor CM, que es en lo que estamos a lo largo de este hilo.
Al igual que en otras guías, lo he intentado explicar de la forma más fácil posible, pero como siempre, eso no significa que consiga hacerlo bien.

[kikems]

Si desensamblamos el contenido en $183E, originalmente era DEC $28 y ahora ha sido modificado por LDA $28
Sencillo, ¿no?

Pues funciona de misericordia, ¿no? porque acabas de cargarte lo que sea que hubiese en el registro A, mientras que DEC no lo hace...

...

Lo he probado en varios casos y te aseguro que funciona perfectamente, cambias el DEC por LDA y listo. Mi problema está en encontrar lo más fácilmente posible un modo de localizar la dirección de memoria donde se almacena el valor de las vidas.

[kikems]

El método que yo uso es bastante simple y efectivo, aunque me falta pulir la primera parte ( lo que hace que de momento no sea ni simple, ni efectivo ).

1- En el juego miro el número de vidas que tengo, voy al Monitor y realizo la búsqueda de las posibles direcciones de memoria que almacenan ese valor. ( esta es la parte floja de mi sistema ya que no consigo acotar correctamente la búsqueda ).

Desde el Monitor hago un hunt de toda la memoria buscando , por ejemplo, 4 de las vidas que tengo.

H 08000 FFFF 04

Con solo esto me salen demasiadas direcciones de memoria con 04, así que por lo que he ido trazando en varios juegos puedo buscar ( 0400 , 040000, 04AD, 04BD, 0400AD, 0400BD ... ) más o menos con estos siempre arroja un resultado al desensamblar así.

.>3B1E 20 AA 3A JSR $3AAA
.>3B21 04 __ __ ??? ( esta es la línea de la variable )
.>3B23 AD 00 4E LDA $4E00

2- De las direcciones que obtengo de la anterior búsqueda, hago otra búsqueda de los registros que hagan una llamada con decremento hacia cada una de esas direcciones , de la siguiente manera ( si voy a comprobar por ejemplo la dirección 3B21 , lo hago así ):

Para hacer la búsqueda tengo que invertir la dirección deseada $3B21 , la corto en dos partes de dos dígitos y el resultado es poner primero los 2 últimos dígitos y luego los 2 primeros. Delante pongo CE o C6 que es decremento.

H 0800 FFFF CE213B
4B8E ( imaginemos que muestra este resultado )

3- Si me ofrece resultados, voy directamente a las direcciones de los resultados y las desensamblo.

.>4B8E 04 CE 21 3B DEC $3B2104

en el momento que me encuentro algo como esto, ya está localizado el truco, cambio DEC por LDA y funciona.

.>4B8E 04 09 21 3B LDA $3B2104

Con esto me resulta un proceso fácil sin tener ni idea, ni de ASM, ni de CM, lo único que me falta por pulir, para ser efectivo, es acotar o modificar la búsqueda del punto 1.
Para los que saben más del tema, puede que les parezca que estoy haciendo el animal ya que cualquiera de estás búsquedas o no arrojan resultado o arrojan unos cuantos resultados, en ocasiones demasiados y comprobar cada resultado lleva su tiempo , hasta que encuentras el correcto.

Imagino que cuando sabes bien de ASM, es posible que la gente buscara un área libre de memoria y escribiera una pequeña rutina que realizara la primera búsqueda y luego aplicara la segunda búsqueda de forma recursiva con los resultados de la primera, arrojando solo unos pocos resultados ( de 1 a 5 generalmente ) a los que vas a examinar manualmente, con lo que se simplifica el proceso enormemente, pero mis conocimientos no dan para elaborar esa rutina. ( Me temo que la función PokeFinder del AR es más o menos esto lo que hace ).
Con esta rutina podrías usar el método, de fuerza bruta, de buscar en el primer paso solo un 04.

PD: de nuevo, no tengo claro que se entienda algo de lo que he descrito

[minter]

muy buena la guía. Hacía falta algo así.
Lo de Pokear juegos, es como dice BlackHole, ciencia inffusa. Muchas veces puedes, pero si el programador es un cabroncete, te lo pondrá complicado (conscientemente o no)

[kikems]

muy buena la guía. Hacía falta algo así.
Lo de Pokear juegos, es como dice BlackHole, ciencia inffusa. Muchas veces puedes, pero si el programador es un cabroncete, te lo pondrá complicado (conscientemente o no)

¿Puedes explicar más detalladamente cómo es el método “gusarapu” ese de ir a explorar la pantalla y desde la zona del marcador de vidas, ir tirando del hilo hasta dar con la dirección a pokear?

[kikems]

Por cierto, estoy haciendo trampas con el ICU64 para ir mas rapido.

Con el ICU es muy fácil ya q es capaz de espiar los valores al vuelo y ver cuál ha cambiado de valor al perder la vida y te da directamente la dirección de memoria de la variable.

Pero lo q me interesa es conocer los métodos clásicos.

[BlackHole]

Pues funciona de misericordia, ¿no? porque acabas de cargarte lo que sea que hubiese en el registro A, mientras que DEC no lo hace...

Yo siempre en mis trainers usaba BIT. Realmente no es que hiciese lo que el AR decía, solo servía para encontrar el valor.

¿Puedes explicar más detalladamente cómo es el método “gusarapu” ese de ir a explorar la pantalla y desde la zona del marcador de vidas, ir tirando del hilo hasta dar con la dirección a pokear?

Aunque sí crackeaba, no hice apenas trainers antes de tener el Action Replay, dos o tres (mi memoria es confusa). Pero incluso con el aparato, había cosas que no salían solas. Un ejemplo son las barras de energía. Si éstas se pintan en pantalla, tienes que averiguar cuál es la zona del bitmap que se modifica para intentar buscar algo. La pantalla del C64 es complicada: puede ser bitmap puro o pueden ser caracteres redefinidos. Además afinar las coordenadas para obtener la dirección absoluta del pixel es difícil. Lo veo hoy en día y me pregunto como lograba hacerlo hace 28 años (porque si lo reintento hoy con VICE que tiene mil ayudas, ya lo veo super complicado). Era más joven y tendría más energía. Energía infinita, claro.

Muchas veces puedes, pero si el programador es un cabroncete, te lo pondrá complicado (conscientemente o no)

Sí, a veces puede que ni fuese consciente si se programaba en pseudocódigo o en un lenguaje de mayor nivel que fuese compilado. Esto ya lo ví más tarde en Amiga, que se notaba un huevo que eran rutinas reentrantes en C y no código puro 68K. El valor podría pasarse en la pila y seguirle la pista a un byte era como buscar una aguja en un pajar. Lo curioso es que de mi etapa con Amiga no me acuerdo NADA... y eso que fue posterior.

[Chema]

Lo curioso es que de mi etapa con Amiga no me acuerdo NADA... y eso que fue posterior.

Tu mente ha bloqueado los recuerdos para evitar males mayores... suele ocurrir con las experiencias traumáticas. Y es que pasar de un 6502 y una arquitectura normal a un Amiga...