Puede que me equivoque, pero juraría que el uso de los puertos 98 y 99 directamente solo queda claro a partir del 2+. Ni siquiera el MSX2 lo confirma, aunque podría equivocarme.

En efecto, estoy contigo que esa macro no tiene sentido para MSX1. Y que para programas MSX-DOS sería un caos leer con interslot el registro.  Una solución (que es la que yo utilizo) es leer en unas variables propias esos registros y dejarlas preparadas. Variables tipo vdpreg98_read, vdpreg98_write, vdpreg99_read, vdpreg99_write.

Pero claro, que utilices esto en tus macros, creo que sería MAS caos todavía. Tendrías que explicar que otra pseudo instruccion lee esos puertos y deposita el valor en unas variables en unas posiciones fijas (no se, las primeras de la memoria que defina el usuario).

Y para fastidiar más la cosa, ¿qué tiempo dejas entre out y out? Porque en MSX2 y superior es una cosa, pero en MSX1 es otra... todo un caos.

Si la añades, tal como te la pide 007 dejaría bien claro en el manual qué es, en qué se convierte al preprocesarla y qué efectos podría tener en MSX1 o con la compatibilidad.

Ahora que por fin tengo algún tiempo libre estoy dedicándome a pulir un poco el asMSX, para ver si soy capaz de publicar una nueva distribución completa.

Como propuestas de mejora, os presento conceptualmente las siguientes:

- Directiva ZILOG: permite emplear en asMSX la sintaxis oficial de Zilog, utilizando el paréntesis para las indirecciones y siendo estricto en cuanto a la estructura de los mnemónicos (por ejemplo, asMSX acepta ADD 8 pero la sintaxis oficial de Zilog exige ADD A,8). La idea es mejorar la portabilidad del código a y desde asMSX.

- Selector de CPU: Z80, R800, ¿otras? Para poder desarrollar para diversos sistemas o con código separado según la generación de ordenador. Como posibilidades alternativas, se podría dar soporte a i8080 y Gameboy clásica/color.

- Calculadora de ciclos: igual que @, pero determinando según el tipo de CPU, los ciclos empleados, tanto el máximo como el mínimo. Debería servir para generar código síncrono de una forma más fácil.

Sigo estrujándome las meninges para tratar de encontrar mejoras significativas para los desarrolladores, antes de meterme en la gran asignatura pendiente: incluir un sistema de macros programables por el usuario. Es relativamente fácil: pura teoría de autómatas formales, pero se me resiste.

Y como nota de color, decir que el desarrollo de la aplicación se está haciendo desde Linux, en un pequeño Asus eeePC 701 4G surf, y dando brincos de país en país.

Por otra parte, se han solucionado muchísimos de los problemas de colisión entre etiquetas y macros y debería de haber mejorado de forma significativa la estabilidad de la aplicación.

Una vez que tenga esta versión más o menos completa, sí que me gustaría publicar el código fuente para que puedan realizarse versiones para las plataformas que queráis: Mac, Amiga, etc.

Pero me toca pedir ayuda: ¿alguien me podría echar un cable con alguna forma fácil  para crear un paquete DEB para la distribución de asMSX para Debian y derivados? Y ahora una pregunta para nota: ¿alguien tiene experiencia en creación de MAKEFILES multiplataforma? Me interesa que el mismo MAKEFILE permita compilar la aplicación para Windows y Linux. Ahora mismo tengo que emplear dos distintos, muy parecidos, pero con alguna sutil diferencia.

Gracias por todo.
 

Hola Robsy,

  mi sugerencia: si el argumento de nombre de archivo de entrada no se encuentra en la línea de comandos, stdin puede ser utilizado. En este caso, una opción "fname" para el fichero de salida (como sugiere kabish) sería casi obligatoria.

  Un nombre de archivo predeterminado como "a.rom / a.bin / a.wav / a.sym" podría ser utilizado si no se especifica ningúna "fname" opción y ningún nombre de archivo de entrada.

  El siguiente es sólo una libertad de pensamiento que deseo compartir: cuando no hay sistema de macro incluido en un programa, siempre se puede pre-filtrar propias fuentes con un intérprete de macros externo como m4 (no me mates por favor, sé que m4 tiene un sintaxis horrible ... pero tienes la idea).

--------------------------------

Hi Robsy,

  my suggestion: if input filename argument is missing on the commandline, stdin can be used. In this case an option "fname" for the output filename (as kabish suggests) would be almost mandatory.

  A default output filename like "a.rom/a.bin/a.wav/a.sym" could be used if no "fname" option and no input filename are specified.

  The following is just a free thought that I wish to share: when no macro system is included in a program, one can always filter his own sources with an external macro interpreter like m4 (do not kill me please, I know that m4 has an horrible syntax... but you got the idea).