IS-FORTH

[Elurdio]

Usé una de las configuraciones que salen a escoger con File>Configuration>Load from ASCII file. No me acuerdo de cual. Eso de escoger segmentos no he hecho nada ni sé como hacerlo.

De ROMS tengo añadidas la de FORTH y la de EPFILEIO además de las que ya me pone la configuración que cargué. Los blocks se guardan en el disco duro en un directorio que he escogido con la opción "Set Working Directory".

Lo de recurrir al cero es por si me olvido de hacer el "I" y al volver no recuerdo lo que había. Como "casi" siempre es cero (hasta ahora siempre veo un cero) pues tengo una alta probabilidad de arreglar el entuerto.

Lo que me interesaría es una manera de, desde el IS-FORTH, poder acceder a un fichero en el disco duro que no sean los BLOCKS allí guardados. Algo equivalente al "Load/Save Memory Blokc" del EightyOne o mejor aún, poder leer/escribir ficheros desde IS-FORTH (aunque me conformo con lo primero). Es por el tema del código máquina generado externamente (con TASM o en el JA con Boldfield). No puedo pasarlo tal cual (en binario) usando los BLOCKS porque al cargarlos el IS-FORTH filtra el contenido (solo pasan códigos entre 32 y 127, los demás lo quita) pues espera texto, no binario.

De momento hago un rodeo. Total, para las pocas cosas que hago en código máquina aquí, ya me sirve de momento.

[Elurdio]

El rodeo actual es:

• El fichero binario generado con TASM lo paso al emulador del Jupite Ace
• Con un programa que ya tenía hecho antes de conocer el is-forth, genero el fuente de un cargador FORTH para definir la palabra en código máquina.
• Este fichero fuente lo guardo como un BLOCK en el disco (sea por ejemplo el block #24).
• Desde el IS-FORTH cargo y interpreto este Block y ya tengo la palabra en código máquina

Esto es lo que tengo en el IS-FORTH como BLOCK #24 (generado en el Jupiter Ace a partir del binario de TASM)

mimc.png (41.64 KiB) Visto 1691 veces

Hay un método más corto: A partir del Listado del TASM con el volcado hexadecimal (como texto) del binario generado lo convierto en un BLOCK y lo paso al IS-FORTH. Una vez allí, con una palabra que aún no me he hecho, lo convierto en la palabra en código máquina.

[Elurdio]

He hecho el programa en IS-FORTH para hacer el método más corto de carga de código máquina externo. Veamos un ejemplo:

• Guardo como BLOCK #23 el volcado HEX del código generado con TASM (usando la opción -h del TASM). Será el fichero 23.4TH que se coloca en el directorio de trabajo del ep128emu (asegurarse que tiene al menos 1024 bytes de tamaño rellenando con espacios):
  

  

  mimc.png (13.19 KiB) Visto 1673 veces

• En el bloque 24 he tecleado esto:
  

  

  tomc.png (13.37 KiB) Visto 1673 veces

• Al cargar el bloque 24 (24 LOAD) se generan dos palabras: >MC y MIMC

>MC es la palabra que lee el contenido del bloque 23 en la pila y lo compila en MIMC que acabará siendo la palabra en código máquina que ejecuta el idem que se generó con el TASM. Al terminar se borra pues no se necesita.

>MC espera en la pila el número de bloque que contiene el volcado hexadecimal y la dirección del PF de la palabra que contendrá el código máquina.

Ventajas de este rodeo:

• Es más corto (no tengo que pasar por el Jupiter Ace).
• Caben más bytes de código máquina por Block (es más compacto que el otro)(*)

Inconvenientes (por poner uno):

• Usa dos Bloques.

NOTA-1: Los bloques escogidos (23 y 24) son arbitrarios. Se podían haber seleccionado otros cualesquiera.

NOTA-2: El programa del bloque 24 utiliza como datos el número del bloque que contiene el volcado HEX (23 en el ejemplo), el número de bytes del volcado HEX (66 en el ejemplo) y el nombre que se dará a la palabra en código máquina (MIMC en el ejemplo). OJO, el nombre se usa en dos sitios, al inicio, con CREATE (en la primera línea) y al final como parámetro en la ejecución de >MC (en la penúltima línea)

(*) El otro, el que genera el Jupiter Ace, se podría compactar más usando Words en vez de Bytes y "!" en vez de "C!".

EDIT: (17-3-2022) OJO, el código máquina de este ejemplo está tomado de una palabra para el Jupiter Ace por lo que en el IS-FORT no sirve. No ejecutarla, a saber que pasaría.

[Elurdio]

No te fíes de que segmento está en cada página cuando entras en el debugger. El EP hace un uso muy eficiente de la paginación, y su sistema está todo el tiempo cambiando esos registros.

No se que configuración de emulación has elegido. Puedes configurarlo a tu gusto y grabar tu perfil. O dejarlo tal cual si te funciona....

Un EP128 de fábrica lleva este mapa de memoria:

EXOS2.1+WP --->00-01---32KB Rom
Basic Rom ------>04-------16KB Rom cartucho, Forth, Lisp, Pascal
64KB internal--->F8-FB---64KB Ram
64KB video----->FC-FF---64KB Ram

Pero el EXOS2.1(como la Bios en un PC) tenía varios errores que se fueron subsanando con los años, por lo que es recomendable tener este mapa:

EXOS2.4+WP+Basic->00-03---64KB Rom
cartucho 64KB-----> 04-07----llénalo como quieras. Es recomendable el uso del lector SD en segmento 07, que necesita Rom EXDOS, en 06
64KB internal--->F8-FB---64KB Ram
64KB video----->FC-FF---64KB Ram

En cualquiera de estas dos configuraciones se puede añadir más Ram, pero es el Emulador el que elige donde la pone, creciendo hacia abajo desde el segmento FF.

Para facilitar las cosas en un PC, el emulador tiene un modo de ficheros virtuales, que seguramente ya has descubierto. Este funciona a través de una Rom llamada epfileio.rom que habitualmente verás en el segmento 10. Esto no quiere decir nada, todas las Roms(menos EXOS) pueden estar en cualquier segmento. Lo que hace epfileio.rom es que todas las llamadas al sistema de ficheros sean reconducidas a un directorio del PC. Hay una opción para cambiarlo en Options/Set working directory. Además, se puede deshabilitar esa opción en la ventana que se despliega con Machine/Configure, en la pestaña General.

Ahora lo he mirado bien y tengo la ROM del Forth en el segmento 5 y la del Basic el 4. En el cero está el primer segemento del Exos21, etc. Lo que no entiendo es como seleccionando el 4 (que es el del Basic) veía la Rom del Forth en el desensamblador. Tendría que ser siempre el 5 con mi configuración ¿NO?

[gflorez]

Puede que la Rom del IS-FORTH estuviese al mismo tiempo en otra de las páginas y no lo sabías porque aun no te lo había explicado. En la misma Rom puede haber trozos que se ejecutan en distintas páginas. Me refiero a que el código de una Rom no suele ser relocalizable desde el punto de vista del Z80, si hay saltos o llamadas directas(JPs o CALLs), solo pueden ejecutarse en una de las 4 páginas de 16KB del Z80. Y una misma Rom de 16KB puede estar incluso en las cuatro páginas. de hecho es lo que pasa en el arranque: 00h, o EXOS, en las cuatro páginas.

Otra cosa, prueba la EXOS2.4, te irá mucho mejor el sistema. Podrás prescindir de la Rom de Basic en la zona de los 64KB del cartucho, 04-07. Podrás tener mucha más Ram sin tener que esperar el lentísimo chequeo de Ram en los rebots. Y te dará la opción de hacer un reset completo solo con con pulsar F11+c, un reset que puede omitir el borrado de Roms emuladas. Pero esa es otra historia...

[Elurdio]

···
Otra cosa, prueba la EXOS2.4, te irá mucho mejor el sistema. Podrás prescindir de la Rom de Basic en la zona de los 64KB del cartucho, 04-07. Podrás tener mucha más Ram sin tener que esperar el lentísimo chequeo de Ram en los rebots. Y te dará la opción de hacer un reset completo solo con con pulsar F11+c, un reset que puede omitir el borrado de Roms emuladas. Pero esa es otra historia...

He instalado el Exos2.4es. La memoria disponible es la misma (supongo que habría que aumentarla, pero con 105.000 bytes tengo de sobras). Eso sí, arranca más rápido.

He pasado la rom de Forth al segmento que ocupaba el basic (el 4).

[Elurdio]

O no sé usarla o hay un bug, pero la palabra NUMBER me devuelve siempre el error:

*** NUMBER not found.

Incluso si la ejecuto indirectamente con su CFA EXECUTE.

La he probado interactivamente y colocándola dentro de una definición, siempre me da error. Si está dentro de una definición, por ejemplo dentro de la palabra TEST, entonces el error es:

*** TEST not found.

Siempre pongo el texto contado en el PAD con " 12345" y la dirección está en la pila antes de ejecutar NUMBER o la palabra que lo contiene. No hay manera.

La he mirado con DUMP y la cabecera está bien. Todo encaja, el tamaño del nombre, el nombre, el lInk a la anterior está bien y el CFA apunta al código máquina.

[gflorez]

O no sé usarla...

Mirando el manual, dice que NUMBER se usa para convertir cadenas de texto a número(en la base especificada en la variable de sistema BASE: 2, 10 o 16).

Se usa así: NUMBER addr - d (dirección-en-memoria y variable-numérica).

Las cadenas de texto en el EP siempre son un puntero a memoria, donde el primer byte es el contador de caracteres y los siguientes la cadena en si.

Espero que te sirva...

[Elurdio]

Sí, eso es lo que dice el manual, pero no funciona.

En Forth los parámetros que espera una palabra en la pila se indican poniendo entre paréntesis primero los que espera antes de ejecutarse la palabra y después del guion, los que pone la palabra en la pila después de ejecutarse.

Así:

NUMBER (addr - d)

Significa que NUMBER espera una dirección en la pila y después de ejecutarse devuelve un número entero de doble precisión en la pila.
En este caso, se especifica que la dirección addr apunta a una cadena de texto contada (contada significa que el primer byte es el tamaño de la cadena y ésta viene a continuación tal como explicas).

Esto es lo que hago en modo interactivo:

Código: Seleccionar todo

" 1234567" NUMBER

Comillas es una palabra de IS-FORTH que pone el texto que viene a continuación (sin contar el espacio en blanco justo después de las comillas de la izquierda) en el PAD (en memoria) con el primer byte conteniendo el tamaño. Y deja en la pila la dirección de ese byte de tamaño.

Luego NUMBER tiene en la pila la addr que necesita, pero da error.

Como hay palabras que en modo interactivo no funcionan correctamente, hago lo mismo poniéndola en una definición:

Código: Seleccionar todo

DECIMAL
: TEST NUMBER ;
" 1234567"
TEST

Me da error, pero ahora dice: *** TEST not found. (y existe y se ve con VLIST).

NOTA: En ambos casos compruebo después de darme error, que en la dirección que había en la pila antes de ejecutar NUMBER (es la dirección que queda en la pila si ejecutas PAD) había la cadena contada. Lo compruebo con PAD COUNT TYPE y me imprime en pantalla : 1234567

Incluso PAD NUMBER da error y si a continuación hago PAD COUNT TYPE me imprime el 1234567 lo que me confirma que en la pila había un addr que apuntaba a la cadena contada " 1234567" pero NUMBER da error.

O estoy cometiendo todo el rato un mismo error y no me doy cuenta (como cuando repites y repites una multiplicación a mano y, sin darte cuenta, siempre haces 3*4=11 en el mismo paso y no te das cuentas hasta que dejas pasar unas horas y lo repites) o NUMBER no funciona.

[gflorez]

Ni idea... Lo más que puedo hacer es reportar el error al autor, que escribió ese lenguaje allá por el 84....

¿Hay alguna función que haga algo parecido?

[Elurdio]

Ni idea... Lo más que puedo hacer es reportar el error al autor, que escribió ese lenguaje allá por el 84....

¿Hay alguna función que haga algo parecido?

Estoy continuando con mi post de palabras que en el Ace y el ISF se llaman iguales pero funcionan diferentes y ésta es una. Lo de comunicar el Bug no vale la pena a estas alturas salvo para saber si realmente es un Bug o el bug soy yo...

Seguro que se puede programar en Forth una palabra que haga lo que hace NUMBER.

EDIT: Lo curioso es que el error que da es el típico cuando NO encuentra la palabra a ejecutar. Pero en cambio, al definir TEST que la contiene, sí que la ha encontrado, pues si no daría error al cargar el BLOCK con la definición de TEST.

EDIT2: Ahora recuerdo que tengo hecha en Forth una palabra "equivalent" a NUMBER pero en versión Ace Forth. En el Ace Forth el equivalente al NUMBER de ISF funcionaría así:

NUMBER 1234567

y dejaría 1234567 como entero doble precisión en la pila. O sea, en el Ace toma la cadena de texto del Bufer de entrada. Esta palabra la hice y se llama DINPUT (creo recordar, de Double precisión INPUT). Pues sería hacer algo parecido a lo que hice con el FIND de ISF que me creé el FINDJ que funciona en el ISF como lo haría el FIND del Ace (ya lo comenté en un post en este mismo hilo) pero al revés: Convertir DINPUT del Ace a NUMBER del ISF.

Este es la definición de DINPUT en el Ace Forth:
Funciona así:
DINPUT 1234567
Deja en la pila el número entero de doble precisión 1234567

Código: Seleccionar todo

: DINPUT 
 0 0 32 WORD DUP 
 1+ C@ ASCII - = 
 IF 
  1+ CONVERT DROP DNEGATE 
 ELSE 
  CONVERT DROP 
 THEN 
;

[Elurdio]

A raíz del post anterior, me estoy peleando con CONVERT en versión ISF idéntico al CONVERT del Ace Forth. Pues que no me funciona tampoco, por lo que empiezo a sospechar que, como me temía, el Bug soy yo.... (no es el mismo error, pero no da el resultado que espero)

Dejaré enfríar el tema hasta mañana, a ver si así me aclaro. Seguro que estoy cometiendo una y otra vez el mismo error de bulto (a saber cual)

FALSA ALARMA: Este ya me aclaré, me olvidaba de hacer el DROP después del CONVERT. El dato de encima de la pila no forma parte del entero doble precisión. Solo indica en qué posición de la cadena dejó de convertir.

En cuanto a NUMBER, como he dicho, lo dejaré hasta mañana.

[Elurdio]

No he podido aguantarme y he vuelto a la carga con NUMBER tras un rato.

Creo que ya sé lo que pasa. En el manual lo describe así:

NUMBER (addr - d) y especifica que addr apunta a una cadena contada. "d" significa que devuelve un número de doble precisión.

Pues parece ser que:

1. Aunque la cadena es contada, no mira byte de tamaño, se lo salta (como hace CONVERT) y termina de convertir al primer carácter que encuenta que no sea un dígito en la base actual.
2. NO genera un número de Doble precisión sino uno de precisión sencilla.

Por (1) resulta que si no dejo un espacio al final, depende del caso, de la basura que haya tras el último dígito seguirá procesando más allá y puede dar error. En mi caso, para evitarlo he de dejar un espacio al final:

En vez de " 12345" hay que poner " 12345 " (con el espacio al final)

Veamos un ejemplo:

Código: Seleccionar todo

" 12345 " NUMBER U.
Imprime 12345
" 3" NUMBER U.
Imprime 32345

Esto pasa porque en el segundo caso no he dejado el espacio en blanco al final y NUMBER encuentra el 3 que he puesto y sigue con la basura del caso anterior que es el 2345 que han quedado en memoria hasta el espacio que había de antes.

Ahora bien, lo que no entiendo es por qué antes me daba error siempre y ahora solo si no hay la cadena de texto.... ¿será un problema del emulador? ¿Depende de lo que tenga cargado en el diccionario? ... Igual es que antes, la zona de la cadena contada daba la casualidad que tenía mucha basura con dígitos y se pasaba de largo, pues yo nunca puse el espacio en blanco al final...

[Elurdio]

NUMBER funciona bien, lo que está mál explicado en el manual o lo entendí mal. Luego lo explico.

[Elurdio]

Funcionamiento de NUMBER:

Si colocas en la cadena contada unos dígitos que no acaban en "." genera un entero sencillo (si no cabe pone lo que se puede)

Si colocas en la cadena contada unos dígitos que acaban en "." entonces te genera un entero doble precisión. (el . al final es el indicador de doble precisión en el ISF)

SIEMPRE HA DE HABER UN ESPACIO AL FINAL DE LA CADENA CONTADA

En resumen: Para que funcione como se espera (que devuelve un número entero doble precisión) el texto contado ha de acabar en "." seguido de un espacio.

El fallo mío es que no me acordaba que en el ISF los enteros en doble precisión llevan el punto al final. La que he liado para nada. Lo único que se echa en falta en el manual es lo del espacio al final (que igual lo dice en algún otro sitio y no lo he visto)

NOTA: Según la sesión, lo del espacio al final no tiene ningún efecto...

EDIT: (18-3-2022). Lo del espacio en blanco al final después del punto es mejor hacerlo siempre. En realidad vale cualquier carácter con ASCII mayor que 31 (el espacio es 32). A veces parece que no hace falta y es porque la "basura" que hay en el PAD casualmente lo pone por ti si tú no lo has puesto. Por eso, para estar seguros, ponerlo siempre.

[gflorez]

Ya he visto en el manual lo de los números de doble precisión, en la sección 2.5.3.

Bueno, no te apures... es complicado este lenguaje, y siempre hay variaciones entre implementaciones.

Aun con sus particularidades, me asombra mucho como fueron capaces de integrar todas las peculiaridades del ordenador es esta versión.