Uto escribió:
me preocupa más saber en que lugar de la RAM podría ponerse eso sin pisar nada [...] [quizá] machacar la primera instrucción o esa de las funciones glulx que hay justo detrás del :main, dado que incluso si le damos a "jugar otra vez" saltamos justo detŕas de eso,así que no importa machacarlo
Las instrucciones del juego se consideran --si entiendo bien-- ROM, así que esta opción no sería válida. Aunque ya encontramos alternativa, saco el tema de nuevo porque...
En World of Witchcraft hay un problema extra, ya que parece que el autor utiliza algún truco de reescribir su propio código en tiempo de ejecución, o de utilizar un espacio que ha se dejado entre instrucciones para almacenar algún dato (quizá alguna creación dinámica de objetos). No tengo muy claro lo que pretende, pero debido a ello me parece que el parcheo de esta obra no va a ser posible en primera instancia, puede que nunca. Necesitará un intérprete que no compruebe ninguna escritura en ROM.
Código:
Glulxe fatal error: Memory write to read-only address (37A10)
Uto escribió:
supongo que se generará algo como 0x130 0x?? ox?? 0x00 (siendo 0x130 el opcode de 'glk')
Es un poco más complicado que directamente el número de opcode. Hay unas reglas que indican cómo se codifican. En concreto, se representa como 0x81 0x30.
http://eblong.com/zarf/glulx/glulx-spec_1.html#s.51.5 Instruction format.
Uto escribió:
"glkresult" se usa en muchísimos sitios, pero en realidad está definida como "glk_result", esta es muy chunga porque es usada como tercer parámetro de todas las llamadas a glk para retornar un valor. La verdad es que es muy sorprendente que esta función no cause la alerta en glulxe si no está específicamente parcheada. Solo se me ocurre pensar que la escritura en ROM en este caso no la hace exactamente glulxe, sino la librería Glk.
El opcode glk es la primero que parcheó zarf (envío al limbo) en glulxe, antes del añadido de DavidK. Commit 2e182f091461.
Uto escribió:
"nombreanterior" creo que es la que se ha detectado ahora, la variable realmente se llama nombre1anterior y solo aparece en un sitio: copy 255.l (:nombreanterior).l . Probablemente modificar ese 255 y poner otro valores puede dar una idea de como encontrarlo en un binario para parchearlo y hacer que en lugar de copy 255.l (0) use una variable en RAM. Otra cosa es que no entiendo muy bien es que ese supone que eso limpia el nombre de frases anteriores, no recuerdo muy bien por qué, y si lo está grabando en 0 en lugar de donde esté :nombre1anterior pues no lo limpia, lo cual es lo correcto y de hecho en los fuentes actuales la linea está corregida con la variable correcta pero también está comentada (;copy 255.l (:nombre1anterior).l). Quizá lo ideal sería simplemente cambiar ese copy 255.l (0) por nops
Sí, este opcode copy es el que parcheó DavidK y efectivamente es el culpable del error en tiempo de ejecución tras introducir un comando en el juego.
Superglús 1.0 tiene el cambio que mencionas:
Código:
- copy 255.l (:nombreanterior).l
+ ;copy 255.l (:nombre1anterior).l
Así que parece razonable (y ha funcionado bien) parchear con NOPs.
Uto escribió:
"canal_sonido" solo se utiliza una vez, en un sitio donde debería poner "canal_efectos", pero como es de lectura no veo demasiado problema. [...] la llamada a glk es única [...] Este caso de todos modos no es peligroso en cuanto a que dé error el interprete, pero ya que estás...
Como bien decías, es relativamente fácil encontrar la dirección buena. Esto también lo parcheo y mejor reaccionará a la creación del canal.
Entre hoy y mañana te paso una primera versión del script, por si ves algo raro. Por cierto, ya tenemos nombre adecuado para las circunstancias, gracias a la genialidad de Al-K:
Arreglús