EigthyOne: Modificar fichero de la ROM

Elurdio
Mensajes: 510
Registrado: 07 Dic 2021 21:33
Ubicación: Barcelona
Agradecido : 115 veces
Agradecimiento recibido: 95 veces

EigthyOne: Modificar fichero de la ROM

Mensajepor Elurdio » 16 Ago 2022 12:10

Quiero hacer una pequeña modificación en la ROM que usa el emulador del JA.

En concreto cambiar la definición de una palabra por otra. Al ser más corta me cabe sin problemas y sin tener que alterar nada más.

Pensé en sobreescribir con HexEdit el contenido del fichero que contiene la ROM en el emulador. ¿Es eso suficiente o hay que hacer algo más?

La modificación afecta a 10 bytes que les cambio el valor, no muevo nada ni cambia el tamaño del fichero.

Lo digo porque lo he hecho. La modificación funciona bien. Pero aparece un problema nuevo que, según mi parecer, no tienen relación directa con el cambio realizado. Algo se me escapa...

Si vuelvo a modificar el fichero ROM dejándolo como al principio se arregla el problema. Lo cual me hace pensar que sí que tiene que ver con lo que hago, pero no alcanzo a ver qué pasa.

Porque la palabra que modifico, funciona correctamente. Y programas muy complejos que cargo funcionan sin problema... pero si uso LIST con una palabra de la ROM (cualquiera, aunque no sea la que modifico) da problemas.

El JA comprueba que la palabra a la que va a hacer el LIST no sea de la ROM (comparando la dirección que ocupa con la del final de la ROM). Si es así, da ERROR 13 y punto. Pero ahora me da ERROR ERROR .... contínuamente.

EDIT1: ya lo tengo más localizado. Lo que falla es el RST $20 que se encarga de generar el mensaje de ERROR. Pero sigo sin ver qué relación puede tener con el cambio realizado...

BlackHole
Mensajes: 1414
Registrado: 03 Ago 2011 23:07
Ubicación: Aluche, Madrid
Agradecido : 16 veces
Agradecimiento recibido: 388 veces

Re: EigthyOne: Modificar fichero de la ROM

Mensajepor BlackHole » 16 Ago 2022 13:16

Podrías empezar diciendo cuál es ese problema nuevo que observas. Sin conocer cómo funciona esa ROM del Jupiter Ace, y a partir de mi experiencia hackeando códigos de ciertos juegos para traducir en diversas plataformas (Commodore 64, Super Nintendo...) el inicio del comando o palabra clave suele tener un puntero asociado. Luego la longitud del comando puede estar en otro lugar almacenada, a no ser que cada palabra tenga un caracter de finalización específico que estás ignorando o sobreescribiendo. A veces solo existe el puntero al inicio de la lista de comandos, y el resto vienen encadenados a partir de sus longitudes... puede haberse hecho de mil formas. Solo son ideas que me vienen a la cabeza, la verdad es que no describes muy bien qué estás haciendo.

Elurdio
Mensajes: 510
Registrado: 07 Dic 2021 21:33
Ubicación: Barcelona
Agradecido : 115 veces
Agradecimiento recibido: 95 veces

Re: EigthyOne: Modificar fichero de la ROM

Mensajepor Elurdio » 16 Ago 2022 13:52

BlackHole escribió:Podrías empezar diciendo cuál es ese problema nuevo que observas. Sin conocer cómo funciona esa ROM del Jupiter Ace, y a partir de mi experiencia hackeando códigos de ciertos juegos para traducir en diversas plataformas (Commodore 64, Super Nintendo...) el inicio del comando o palabra clave suele tener un puntero asociado. Luego la longitud del comando puede estar en otro lugar almacenada, a no ser que cada palabra tenga un caracter de finalización específico que estás ignorando o sobreescribiendo. A veces solo existe el puntero al inicio de la lista de comandos, y el resto vienen encadenados a partir de sus longitudes... puede haberse hecho de mil formas. Solo son ideas que me vienen a la cabeza, la verdad es que no describes muy bien qué estás haciendo.


Tienes razón, no explico muy bien lo que pasa. Pero lo que quería saber era lo que preguntaba, si había que hacer algo más aparte de modificar la ROM desde el punto de vista del emulador.

Lo que me temo es que alguna rutina del Ace Forth hace un uso "parcial" de la palabra modificada. O sea, no ejecuta la palabra sino que solo "aprovecha" parte de su "código". Si es así, como lo he cambiado, pues mal va la cosa. Esto me lleva a la conclusión que modificar la ROM es muy arriesgado, pues siempre puede haber una rutina que haga uso parcial de otra. Así, aunque lo que modifico funcione bien como un todo, no garantiza que no haya problemas.

Voy a intentar confirmar mis sospechas, ya que empecé a buscarla, pero lo de tocar la ROM ...

BlackHole
Mensajes: 1414
Registrado: 03 Ago 2011 23:07
Ubicación: Aluche, Madrid
Agradecido : 16 veces
Agradecimiento recibido: 388 veces

Re: EigthyOne: Modificar fichero de la ROM

Mensajepor BlackHole » 16 Ago 2022 14:35

La rutina puede ser similar a la de Spectrum, que tiene disponible su desensamblado comentado, pero como dije antes, puede programarse de muchas formas para obtener el resultado. Supongo que el problema será usar una longitud menor, pero no tengo experiencia en Forth donde puedes definir tu propio léxico. Siempre tirábamos de BASIC con comandos fijos de los que no te podías salir; además muchos BASIC se "tokenizaban" tras el paso por el analizador sintáctico, para ahorrar bytes.

Elurdio
Mensajes: 510
Registrado: 07 Dic 2021 21:33
Ubicación: Barcelona
Agradecido : 115 veces
Agradecimiento recibido: 95 veces

Re: EigthyOne: Modificar fichero de la ROM

Mensajepor Elurdio » 16 Ago 2022 15:04

BlackHole escribió:La rutina puede ser similar a la de Spectrum, que tiene disponible su desensamblado comentado, pero como dije antes, puede programarse de muchas formas para obtener el resultado. Supongo que el problema será usar una longitud menor, pero no tengo experiencia en Forth donde puedes definir tu propio léxico. Siempre tirábamos de BASIC con comandos fijos de los que no te podías salir; además muchos BASIC se "tokenizaban" tras el paso por el analizador sintáctico, para ahorrar bytes.


Lo que he hecho es modificar la palabra ROT. En Forth las palabras tienen una cabecera y un cuerpo (parameter Field). La cabecera ni la he tocado, es idéntica. Solo he cambiado el cuerpo por otro (ni mayor ni menor, igual de largo pero diferente) para que se ejecute más rápido.

Esta palabra se usa mucho en Forth. Pero la modificacón funciona bien, sin problemas. La rutina que falla es la que se encarga de generar los mensajes de error en el JA (el restart 32). Lo he comprobado. Cualquier mensaje de error que se produzca hará que falle el programa. Pero solo eso. Si no hay ningún mensaje de error, cualquier programa (de los que he probado, alguno muy complejo) funciona perfectamente y segurísimo que usan el ROT en algún momento u otro (lo más probable es que lo usen cientos de veces).

Pero es posible que, para ahorrase uno o dos bytes (típico de la época) alguna rutina totalmente ajena al ROT esté utilizando una parte de su cuerpo que casualmente es lo que necesita hacer. Esto es lo que voy a intentar comprobar rastreando con el debugger. Desde luego, si es esto, se ha cumplido del todo la Ley de Murphy, pues de 142 palabras que hay me ha ido a tocar con esta. la Pero igual es otra cosa.

Había pensado en hacer lo mismo con otra palabra y ver si no daba problemas, pero ahora mismo no he encontrado otra adecuada.

Tenía la esperanza que los emuladores, aparte de la ROM tuvieran algún fichero auxiliar o algo que hacer que se me había pasado (de emuladores solo sé el concepto, pero del know-how ni zorra).

BlackHole
Mensajes: 1414
Registrado: 03 Ago 2011 23:07
Ubicación: Aluche, Madrid
Agradecido : 16 veces
Agradecimiento recibido: 388 veces

Re: EigthyOne: Modificar fichero de la ROM

Mensajepor BlackHole » 16 Ago 2022 16:47

¡Ah! Empiezo a vislumbrar ahora qué querías decir al principio, y yo lo entendía de una forma completamente diferente. No es que hubieses cambiado la definición del comando de la ROM para que apuntase a otro sitio, o cambiar la lista de tokens reconocidos, sino que has cambiado el propio código máquina Z80 asociado al comando, su implementación. Por supuesto que otros comandos, sobre todo los que veo asociados a la reordenación de los datos en el stack (por lo que leo en un Wiki sobre FORTH) podrían usar perfectamente parte del código de ROT para realizar parte de sus cálculos, saltando en medio del código. Si tú lo has cambiado, los resultados pueden ser inesperados; bastante suerte que no se haya acabado colgando todo.

El ZX Spectrum también usa un salto rápido RST para mostrar mensajes de error, exactamente RST 08h si no recuerdo mal. Usar RST es una forma rápida de acceder a algunas posiciones críticas de código aprovechando que usan solo 1 byte en vez de los típicos 3 de un CALL. Por supuesto en cada máquina basada en Z80, el código de esas posiciones será completamente diferente y ajustado a las necesidades de la máquina. Lo que tendrías que hacer es desensamblar para ver qué hace la máquina después de saltar a la posición 0020h; tal vez la rutina de gestión de errores presente en 0020h tome valores de otros registros, que se han podido ver alterados por tu código.

BlackHole
Mensajes: 1414
Registrado: 03 Ago 2011 23:07
Ubicación: Aluche, Madrid
Agradecido : 16 veces
Agradecimiento recibido: 388 veces

Re: EigthyOne: Modificar fichero de la ROM

Mensajepor BlackHole » 16 Ago 2022 17:27

Aquí (http://www.jupiter-ace.co.uk/romlisting.html) hay un desensamblado comentado de la ROM del Jupiter Ace. Por lo que veo todo es más complejo que la estructura "lineal" que más o menos tiene BASIC. Aquí hay que cambiar el paradigma en la forma de pensar los cálculos en notación polaca inversa, y está tirando de los punteros de la pila constantemente. Teniendo ahora el desensamblado, quizás estaría bien que compartieses qué cambios has realizado y en qué posiciones exactas, por si podemos intuir el fallo.

Veo que en $0901 los siguientes 10 bytes definen 5 llamadas a 5 subrutinas presentes en otros lugares, como si fuesen una tabla de saltos. Parece que el Jupiter Ace va tomando las direcciones de esas tablas y las va ejecutando desde algún bucle principal. Así puestos, la palabra ROT va a ejecutar las siguientes 5 subrutinas presentes en otra parte de la ROM: >R, swap, R>, swap y exit.

L0901: DEFW L08D2 ; >R
L0903: DEFW L0885 ; swap
L0905: DEFW L08DF ; R>
L0907: DEFW L0885 ; swap
L0909: DEFW L04B6 ; exit

Solo necesitamos hacer una búsqueda en el listado por si desde otro sitio se nombrase directamente $0903, $0905, $0907 ó $0909 pero no es el caso. Nada salta en medio de la tabla de esas 5 llamadas, así que lo que tú suponías no está pasando. ¿Has conseguido hacer el ROT en solo 8 bytes? ¿Cómo? Ten en cuenta que si en vez de una tabla de saltos a subrutinas, usas código máquina puro, la última instrucción debe ser JP (IY) para saltar a la siguiente instrucción.

Elurdio
Mensajes: 510
Registrado: 07 Dic 2021 21:33
Ubicación: Barcelona
Agradecido : 115 veces
Agradecimiento recibido: 95 veces

Re: EigthyOne: Modificar fichero de la ROM

Mensajepor Elurdio » 16 Ago 2022 21:15

Ese es el desensamblado que utilizo.

En el Ace Forth (como en otros) se definen unas pocas/no_tan_pocas palabras en código máquina (primitivas) y el resto de palabras se construyen a partir de esas y de las que se vayan definiendo con esas. Digamos que palabras son lo que las subrutinas al basic. (aunque yo el Basic, el lenguaje que más he utilizado (por afición (amstrad) y por trabajo (Quick Basic), su funcionamiento interno lo desconozco. )

ROT no es una primitiva. Se define con la lista de palabras que pones. Todas son primitivas. Cuando se ejecuta ROT este arranca un intérprete interno (se lo indica la Cabecera) que va ejecutando todas y cada una de las palabras que la componen en el orden especificado.

Lo que hago es cambiar la lista de palabras por otra que aumente en un 100% la velocidad de ejecución de ROT (que ya he comentado en otro hilo). Usa el hecho que 3 ROLL es lo mismo que ROT y ROLL sí que está en código máquina (primitiva).


Cabecera de ROT (8 bytes)

Cuerpo:

L0901: DEFW L1011 ; LITERAL
L0903: DEFW L0003 ; 3
L0905: DEFW L0933 ; ROLL
L0907: DEFW L04B6 ; EXIT
L0909: DEFW L04B6 ; exit (no se usa, el EXIT anterior termina el cuerpo) Lo dejo tal cual.


Y tengo localizado el problema. Y todo parece indicar que es como dices: NO tiene nada que ver con aprovechar ROT parcialmente. Va por otro lado.

Luego me explico mejor. Ahora estoy viendo la retrocrypta.

Elurdio
Mensajes: 510
Registrado: 07 Dic 2021 21:33
Ubicación: Barcelona
Agradecido : 115 veces
Agradecimiento recibido: 95 veces

Re: EigthyOne: Modificar fichero de la ROM

Mensajepor Elurdio » 16 Ago 2022 22:56

El problema se produce en la rutina de impresión de Error, cuando imprime el número de error. Usa la palabra . (punto) (la palabra punto que se escribe con un punto ortográfico es el "print" del Forht) y ahí se produce el problema solo si uso la ROT modificada. La palabra . (punto) llama a ROT y ahí se ve que se produce algún error que no he detectado, con lo que se llama de nuevo a la rutina de ERROR y así sucesivamente en un bucle sin fin (hasta que se llena la pila de retornos) que llena la pantalla de la palabra ERROR sin el número que no lo llega a imprimir.

Que el error es cuando . (punto) llama a ROT lo he comprobando cambiando la llamada a ROT por un SWAP (el efecto es que si el número que se imprime es negativo lo imprime como positivo, pero como el número del error es siempre positivo, no afecta). Entonces NO se produce ningún error y todo va bien.

Lo que no alcanzo a dilucidar es porqué solo sucede con la ROT alterada.

Rastrearlo con el debugger es que me acabo perdiendo y ya no sé lo que está haciendo la máquina.. Encima el debugger del Eigthyone tiene un bug (o no lo uso bien) que hace que la opción OVER ni puto caso, tienes que estar poniendo stops y es un latazo.

Además el error solo es al ser llamada punto desde la rutina de error. Si punto la llama un programa o yo a mano, no pasa nada. Incluso he creado un palabra en código máquina que llama a punto al estilo que lo hace restart 32 y funciona bien (con el ROT modificado).

He creado otra versión de ROT, esta sí es en código máquina (sacada de TURTLE.TAP) y lo mismo: Funciona perfecto el ROT modificado, menos cuando lo ejecuta . (punto) llamado por restart 32.

Seguro que es una chorrada, pero no lo acabo de ver.

Ya estoy mareado, de momento lo dejo aquí y ya lo retomaré.

BlackHole
Mensajes: 1414
Registrado: 03 Ago 2011 23:07
Ubicación: Aluche, Madrid
Agradecido : 16 veces
Agradecimiento recibido: 388 veces

Re: EigthyOne: Modificar fichero de la ROM

Mensajepor BlackHole » 16 Ago 2022 23:23

Mmmmm.... yo no sé nada del lenguaje Forth, y la ROM la primera vez en mi vida la he visto esta tarde, pero... la palabra LITERAL tiene su inicio del ¿cuerpo? en $1006 y no en $1011.
No sé si eso puede ser importante, parece que te saltases un nivel entero y con todo el gigantesco jaleo de punteros de pila anidados, tal vez se vuelva loco y no retorne a donde debe.
Es que si llamas a $1011 lo que estás llamando es a la función "Stack Next Word" que es llamada por muchas otras funciones a lo largo de la ROM, y no llama a la palabra "," que parece meter el número en la pila.

(¡Razón tenía la enciclopedia Mi Computer cuando decía que si el BASIC parecían recetas, en FORTH parecían conjuros!)

Elurdio
Mensajes: 510
Registrado: 07 Dic 2021 21:33
Ubicación: Barcelona
Agradecido : 115 veces
Agradecimiento recibido: 95 veces

Re: EigthyOne: Modificar fichero de la ROM

Mensajepor Elurdio » 16 Ago 2022 23:54

Gracias por tu interés. Para no saber Forth interno, te manejas muy rápido.

Ojalá hubiera sido ese el fallo. Pero no lo es.

ROT definido así funciona. Solo falla cuando lo llama . (punto) desde el restart 32. El porqué, pues aún no lo sé.

En cuanto al $1006, cierto, el CFA de LITERAL es $1006. Pero LITERAL es una palabra tipo COMPILER interno. Tiene dos CFA. Uno el que dices que lo que hace es compilar un número que coge de la pila (durante la compilación de una palabra) y $1011 que es el CFA de su Runtime, el que hace lo opuesto, coloca el número que $1006 compiló, de nuevo en la pila cuando se ejecuta la palabra que lo contiene.

Si ves un $1011 debe ir seguido de dos bytes con un entero de 16 bits, que es el numero que pondrá en la pila. En nuestro caso es un 3. Luego viene ROLL que toma ese tres de la pila.

Lo que comentas de , (coma) no vas desencaminado, pues cuando se ejecuta $1006 (si miras el desensensamblado de LITERAL) verás que ejecuta , (coma).

Elurdio
Mensajes: 510
Registrado: 07 Dic 2021 21:33
Ubicación: Barcelona
Agradecido : 115 veces
Agradecimiento recibido: 95 veces

Re: EigthyOne: Modificar fichero de la ROM

Mensajepor Elurdio » 17 Ago 2022 13:03

He encontrado el problema, pero no la causa

Provoco un fallo a propósito y lo debugeo. La rutina de imprimir el error imprime en pantalla ERROR y ahora debería imprimir el número. En un momento dado el código de error a imprimir (13 o $D) está en la tercera posición de la pila y se ejecuta un ROT que lo pone en la primera posición. Listo para ser impreso justo después de ERROR. Todo bien.

Pero ahora el ROLL comprueba que la pila no está vacía y, no sé dónde ni cuando la pifió el JA, pero los datos le dicen que está vacía y salta a la rutina de error (estando ya en la rutina de error, o sea entramos en un bucle: error llama a error que llama a error etc.hasta que se llena la pila de retornos)

La pila no está vacía, lo que están mal son los punteros de la misma. En fin que si cambiando el PC hago que siga como si la pila está bien, pues se genera el ERROR 13 y todo perfecto.

Pero sigo igual. Rastrear donde se equivoca el programa con el tamaño de la pila va a ser duro....

jltursan
Mensajes: 4726
Registrado: 20 Sep 2011 13:59
Ubicación: Madrid
Agradecido : 701 veces
Agradecimiento recibido: 1552 veces
Contactar:

Re: EigthyOne: Modificar fichero de la ROM

Mensajepor jltursan » 17 Ago 2022 15:01

Con un debugger en condiciones no debería costar tanto averiguar cuando se descabala el puntero a la pila. ¿Le has comunicado al autor del EightyOne el posible problema que encontraste con el OVER en las llamadas?, y por que soy muy machacon, ¿has probado con el ZEsarUX?. Aquí su interfaz puede suponerte un handicap; pero puede merecer la pena.

Elurdio
Mensajes: 510
Registrado: 07 Dic 2021 21:33
Ubicación: Barcelona
Agradecido : 115 veces
Agradecimiento recibido: 95 veces

Re: EigthyOne: Modificar fichero de la ROM

Mensajepor Elurdio » 17 Ago 2022 15:52

jltursan escribió:Con un debugger en condiciones no debería costar tanto averiguar cuando se descabala el puntero a la pila. ¿Le has comunicado al autor del EightyOne el posible problema que encontraste con el OVER en las llamadas?, y por que soy muy machacon, ¿has probado con el ZEsarUX?. Aquí su interfaz puede suponerte un handicap; pero puede merecer la pena.


Lo que dices, el interfaz del ZEsarUX al no ser tan Windows me cuesta. El problema es que estoy muy acostumbrado al EightyOne. Si hubiera empezado con el ZEsarUX posiblemente ni querría oír hablar del EightyOne... ya soy mayor con espíritu de viejo, me cuesta mucho cambiar...

Además del tema del OVER (que ya se lo han comunicado otros en el foro del referencia) es que las palabras que usa la rutina del RST$20 se ejecutan como COLON, lo cual es muy liado de seguir. Pues cada una es una lista de palabras, que a su vez son también una lista, etc..
He tenido que usar una combinación de breakpoints de ejecución y breakpoints de contenido de registros para hacerlo.

Pero lo bueno es que creo, por no decir que estoy seguro, haber encontrado el problema.

En lugar de rastrear donde se producía el problema, pensé ¿y si es así?. Entonces hice el debugado de un ERROR forzado por mí pero con el ROM original y llegado al punto equivalente (el número 13=$D en el top de la pila a punto para ser impreso) compruebo mirando los punteros de la pila que la situación es igual de incorrecta.

Me acordé que la rutina RST$20 una de las primeras cosas que hace es poner el JA en modo FAST. NO le veía mucho el sentido, puesto que se va a parar por haber un error, ¿de qué servía?... Ahora lo entiendo. Lo pone en FAST no para que vaya más rápido sino para que no compruebe errores. Como esta rutina no puede fallar, no hay necesidad de comprobar nada (alguna cosa sí que comprueba, como que el código de error a imprimir sea válido y quizás algo más). Entonces puede trabajar con pilas incorrectas y demás. Supongo que así se ahorran bytes de código. Como un ERROR provoca el reseteado de la pila de datos (se pierde todo el contenido que pudiera tener y se reinician los punteros), da igual que esté corrompida.

Pero si modifico el ROT para que funcione como 3 ROLL, resulta que la palabra ROLL comprueba por sí misma, independientemente de si estamos en modo FAST o SLOW, que la pila esté "correcta". Como NO lo está, pues genera error.

Esto, además me aclara por qué no usaron lo del 3 ROLL en vez de ROT definido como está definido, siendo 3 ROLL 2 veces más rápido.

NO me extraña que ya me estuviera acercando al punto de tirarlo todo por la ventana, pues que se te ocurra pensar que la rutina de error está trabajando pasando de errores, es difícil.

Elurdio
Mensajes: 510
Registrado: 07 Dic 2021 21:33
Ubicación: Barcelona
Agradecido : 115 veces
Agradecimiento recibido: 95 veces

Re: EigthyOne: Modificar fichero de la ROM

Mensajepor Elurdio » 17 Ago 2022 22:11

Bueno, al menos he podido alterar la ROM para poner la versión en código máquina del OVER de TURTLE.tap. No da problemas de momento. Hace un uso parcial de ROLL y no pasa por la parte de comprobación de la pila. Solo comprueba que el número que usa no sea ni cero ni negativo.

Tras unas mediciones más precisas, las diferencia de velocidad entre ambas versiones es (Slow/Fast) de 3.7/3.5 veces más rápida la versión TURTLE puesta en la ROM.

Una pena no poder hacer lo mismo con ROT, con unas diferencias de 2.9/2.4 veces más rápida.

Elurdio
Mensajes: 510
Registrado: 07 Dic 2021 21:33
Ubicación: Barcelona
Agradecido : 115 veces
Agradecimiento recibido: 95 veces

Re: EigthyOne: Modificar fichero de la ROM

Mensajepor Elurdio » 18 Ago 2022 11:05

jltursan escribió:··· ¿Le has comunicado al autor del EightyOne el posible problema que encontraste con el OVER en las llamadas?···


Te pongo aquí el post que te comenté. Yo también entiendo que el comando OVER debería hacer lo que dice el post.

I've been making good use of the built-in debugger in latest version of EightyOne (V 1.29). It is really useful (as is the profiler) but I do see an issue when single-stepping throuhg a program. Specifically, I assume the Over button, when used on a CALL command, runs the called code and then resumes single-stepping when returning from the called code. For me, this doesn't work. The debugging just carries on executing code. The work-around is to set a breakpoint for the command immediately following the call, but this is quite cumbersome. Am I misunderstanding how Over works?


Sin respuesta hasta la fecha.

Aquí el link


Volver a “Emulaciones software, FPGA y otras soluciones”

¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 1 invitado