Karoshi MSX Community

Pues sí, señores. Empiezan las rebajas de verano.

Ahora que parece que el tema de portabilidad del asMSX se ha resuelto felizmente o casi (falta hacer más pruebas y quiero conseguir que funcione en Mac), les ofrezco a los usuarios del susodicho que pidan por sus respectivas boquitas lo que consideren que debería añadirse al ensamblador. Así tal cual, a medida. Se trata de "fidelizar" a los consumidores habituales para que asMSX sea cada vez más útil y potente.

En mi wishlist privado está lo siguiente:

- Versión para Mac
- Completar la documentación y traducirla al inglés (distribución bilingüe)
- Aportar más ejemplos de programas un poco más "densos" que el PONG y el MINESWEEPER
- Actualizar las herramientas de apoyo: RLEPACK sux, MSXWAV sux y PCX2MSX ultra-sux
- Incorporar las sugerencias / correcciones que se os ocurran

Ojo. Lo que me planteo es que las herramientas tipo MSXWAV y PCX2MSX queden de algún modo integradas dentro del asMSX para que pueda funcionar de forma autónoma. De hecho, parte de la funcionalidad del MSXWAV ya se ha integrado con las directivas WAV y CAS. Ahora faltaría crear el INCGFX o algo así para incorporar gráficos, pero puede ser un lío de cuidado... Me gusta el formato PNG, pero es demasiado complejo. Probablemente opte por TGA en True-Color a 24-bits, con conversión directa, con y sin dithering.

Lo dejo en vuestras manos: sugerid de forma razonada que habría que incluir o modificar. Si tenéis bug-reports, también los agradecería, dado que se perdió en el último bajonazo del foro el hilo donde se discutían estas cosillas, y no sé si quedó algo pendiente de corregir.

Por supuesto, que quede claro el objetivo del asMSX: un ensamblador específico para la programación para MSX, especialmente dedicado a la creación de video-juegos.

Hmmm... tengo que echarle un vistazo a la nueva versión.

Lo que comentas me parece bien, pero... no me acaba de gustar el tema de "integrar" tantas cosas en el asMSX. Quiero decir que me gusta más que PCX2MSX, por ejemplo, sea un programa externo al asMSX. En cualquier caso, tanto da: si me gusta más la versión "externa", pues uso la externa.  ;D

Otro temilla es el de los gráficos... ¿crees que vale la pena hacer un conversor PNG/TGA/lo_que_sea a MSX? El PCX2MSX va perfecto, y cualquier editor gráfico para Windows, Mac o Linux te permite guardar en PCX.

Anyway, Robsy, ya sabes mi opinión sobre el asMSX y utilidades asociadas: muy buena! Buen trabajo!

El PCX2MSX hace su trabajo, pero es muy limitado. Por mi parte, la funcionalidad que me gustar'ia darle es la siguiente:

- Conversi'on autom'atica de colores, con y sin dithering, desde 24bpp
- Conversi'on monocroma forzada
- Selecci'on de un 'unico color para importar sprites multiplano
- Selecci'on de "ventanas" a importar dentro del gr'afico total
- Optimizaci'on, en el sentido de eliminar los tiles repetidos y generar, por tanto, tambi'en una tabla de nombres para reconstruir el gr'afico original

Todas estas cosas, que he venido usando en mis propias producciones, las he hecho siempre "on-the-fly" con mini-aplicaciones en C programadas al efecto. Va siendo hora de juntarlo todo y tirar adelante.

En cuanto a mis dudas respecto del formato PCX, el principal inconveniente que le veo es que el Photoshop se obstina en hacerlo "al reve's" que el resto de programas. Por eso le tengo alguna man'ia...

-Version para amiga. (Voluntario: yo mismo e ofrezco a portar-lo)

Por mi parte, encantado, aunque dudo que pueda ocuparme del mantenimiento. En principio, todo lo que deber'ias tener para ser capaz de compilarlo en Amiga ser'ia una versi'on actual del GCC (3 o 4 valen), Flex y Bison. Con eso y un bizcocho, deber'ia funcionar. Un Make tambi'en ayudar'ia, claro...

En cuanto tenga la distro cerrada, te lo paso para que juguet'ees todo lo que quieras.

Esta opció sí la veo interesante. Mucho.


Nada, nada, a tirar de GIMP ;-)

A mi se me ocurre meter la pseudo instruccion  REPEAT , aunque ahora no recuerdo si esta implementada.
Para el tema de la optimizacion de tiles yo uso unas herramientas al efecto que encontre en la pagina de retroespec en la seccion de utilidades.
No recuerdo el nombre ahora.
Pesonalmente prefiero las utilidades separadas del ensamblador como hasta ahora.

Nada mas.

Okis. De momento parece que las utilidades separadas son la opción elegida por la mayoría, así que ningún problema. Lo que quizás sí sería bueno es incluir entonces la posibilidad de llamar a dichas herramientas desde dentro del asMSX, con una pseudoinstrucción tipo EXECUTE "pack datos.bin". ¿Qué os parece?

El REPEAT está ya implementado, con la instrucción REPT n / ENDR. Además, permite anidaciones y es ideal para hacer algunas guarradas como tablas autogeneradas:

Eso puede ser práctico. Este tipo de cosas las hago ahoracon un ".bat", donde llamo a PCX2MSX, bitbuster, ... y al asMSX

De todas formas, no se hasta que punto mi opinión es "relevante": sólo he usado asMSX. La gente que haya trabajado con otros ensambladores podrá comentarte más cosillas.

Un saludo

Nada de integrar herramientas, yo quitaría lo del wav y el cas y me centraría en dejarlo estable...

Recojo el guante como usuario habitual del asMSX y voy a intentar aportar mi granito de arena en este interesante debate.

Respecto a lo de herramientas integradas si o no, personalmente me da igual. Nada veo de malo en que estén integradas, si se quiere se usan y si no, pues no.


Y respecto a aportaciones, yo soy de la opinión de que en los tiempos que corren no deberíamos conformarnos con un ensamblador a la antigua usanza. Me explico, a mi me vendría de perlas por ejemplo funciones integradas, a modo de “print(puntero a texto)”  para imprimir mensajes en pantalla  o “print(score)” para imprimir marcadores. También tipo “put_sprite”, “define_sprite”, “pon color”. etc, etc. Dónde el ensamblador incluiría el código correspondiente, algo parecido a lo que se hace con la directiva .SEARCH.

Si esto no fuera posible, propongo que el ensamblador se distribuya con una serie de funciones útiles para los programadores. A modo de biblioteca de funciones.

Incluso si me apuras, para agilizar la programación para los que como yo no disponen de tiempo libre de forma continua, incluiría instrucciones condicionales tipo “if registro n> registro m then JP etiqueta” o para los amantes del C “if (HL<BC) ….”. Por supuesto si se incluye condiciones complejas tipo “or” y “and” ya sería perfecto.

Aunque pueda parecer un giro hacia los lenguajes de alto nivel, lo que planteo en realidad es que se podrían incluir MACROS a nivel de ensamblador para aquellas tareas que son habituales, y que en general suelen ser sencillas de programar. Combinando el ensamblador puro y duro con macros predefinidas para aquellas tareas rutinarias que no precisen de un grado elevado de optimización.
 
Y el que quiera que las use y el que no pues no.

Esta es mi propuesta-opinión respecto al ensamblador asMSX.

Talmente de acuerdo con SapphiRe, yo no volcaría esfuerzos en complicar más el ensamblador, o por lo menos hasta que no esté mucho más rodado y tengamos claro que puede ser útil.

Yo habitualmente utilizo lo siguiente:

1) PSP o Gimp para diseñar los gráficos que posteriormente grabaré como PCX. El Gimp en este aspecto es algo superior al PSP.
2) Convierto los gráficos con el PCX2MSX. Si no me equivoco continúa existiendo el problema que seguro que Robsy recuerda, la libre interpretación de que píxeles se convertirán en 0 y cuales en 1. A veces me veo obligado a retocar los resultados a mano...:(
3) Los comprimo de forma independiente ya que me parece muy útil tener presente el tamaño del archivo comprimido, algo que perderías de vista si se embebiera en el ensamblador.

Respecto al ensamblador, en el asMSX sólo recuerdo haber echado de menos las macros, que si que suelo usar con frecuencia y los structs que, aunque uso poco, siempre vienen bien.


Usease, MACROs a medida ;)


Tal cual.


De todas formas, al que veo más necesitado es al PCX2MSX. Para los que usan programas de diseño convencionales es una herramienta imprescindible. Claro que, con todo lo que se le podría meter, casi que se convertiría en un programa con GUI incluida :-)

Como programador tanto de juegos MSX como de compiladores, opino que cuanto más compleja sea una herramienta más susceptible de que surjan errores inesperados. Abogo por herramientas simples, más sencillas de mantener.

Algo que en algún juego (del que igual se ve algo el sábado) es imprescindible.


Efectivamente, tienes más control si lo haces por separado que dependiendo de una misma herramienta.

Buenas,

Aprovecho este hilo (aunque un poco tarde) para proponer un par de mejoras para el asMSX:

Hace una semana rescate uno de mis antiguos sources que programe con el Ensamblador COMPASS. (haca ya 7 años)

Lo he estado adaptando al asMSX para poder seguir su desarrollo desde el PC usando asMSX + blueMSX.

Mientras hacia la migracion del codigo fuente de COMPASS a asMSX me he encontrado con un par de limitaciones del asMSX que serian interesantes que las soportara, estas son:

- Permitir en el comando DS (o DEFS) indicase que byte queremos que se repita n veces, en vez de obligarnos a que sea siempre cero. En el COMPASS se pone asi: DS 100,$45 (esto insertaria 100 veces el byte $45 en memoria) ahora mismo solo se pueden insertar CEROS con asMSX.

- Permitir poner los PUSH y POP agrupando uno o varios registros, por ejemplo: COMPASS permite poner en una misma linea: PUSH HL,BC,DE,BC y en otra: POP BC,DE,BC,HL, parece una tonteria, pero el codigo queda mucho mas limpio y legible... Menudas ristras de PUSHs y POPs tengo ahora en el codigo :S

- Lo ultimo es el soporte de MACROS, pero esto ya es mucho mas laborioso, por suerte mi source solo usaba una unica macro, asi que no ha sido muy duro eliminarla... eso si... quedaba mucho mas limpio con esa macro, venia a ser algo asi: escribias VDP $82,20 y la macro se extendia en los pertientes OUTs $99... parece una tonteria, pero el codigo se entendia muchisimo mejor que ahora :P

Sobre lo que estoy adaptando... es secreto... ya se vera cuando este terminado :)

Solo añadir, mis mayores felicitaciones para Robsy, por su magnifico asMSX... y todo lo que se ha currado estos ultimos años... que no es poco la verdad...

Hola, doble07:

Gracias por tu mensaje. Trataré de responderte brevemente a lo que planteas:

- El comando DS no inserta ceros, sino que reserva posiciones. Efectivamente, si no va al final del código, introduce un cero para evitar problemas. Si lo que te interesa es introducir un valor definido, hay que usar los comandos DB, DW o DT. Si, además, quieres introducir un valor repetido un número determinado de veces, te sugiero que lo combines con el comando REPT, que es muy potente. Por lo tanto, lo que indicas como DS 100,$45 se podría escribir en asMSX de la forma siguiente:


- En cuanto a los comandos múltiples para gestión de pila, lo cierto es que es una decisión personal: no me gusta porque puede generar errores de programación de difícil depuración y porque la experiencia me ha demostrado que este tipo de comandos enlazados hacen que el programador no optimice lo suficiente el código. De todas maneras, si se considera que es una necesidad, no habría muchas dificultades en incorporar esta función al asMSX.

- El soporte para macros es una de las principales carencias del asMSX. Lo creáis o no, existe un motor de macros programado de forma paralela desde el asMSX 0.10, pero no se ha incorporado a ninguna de las distribuciones por un doble motivo: primero, porque no es lo suficientemente estable, y segundo, porque no estoy satisfecho con la sintaxis que desarrollé para su funcionamiento.

Ahora que el asMSX ha ganado mucho en estabilidad y fiabilidad, me falta publicar una versión oficial con todos los aspectos corregidos. En la que seguirá a ésta, es mi intención incorporar el soporte para macros.

En cualquier caso, gracias por el feedback y por usar asMSX como herramienta de desarrollo. Estoy seguro de que nos beneficiaremos todos de tu decisión de retomar tu código fuente.

Hola Robsy,

- lo de usar REPT es lo que he usado, pero queda mas elegante usando el DS 100,$45 (Yo tambien tengo mis manias, como todos los programadores :) )

- Sobre los PUSH y POP agrupados, es otra mania mia para que el codigo quede mas "elegante". Y por supuesto, solo hago PUSH y POP de los registros afectados, no todos :)

- Lo de las macros, yo creo que es lo mas importante de todo, creo que todos le encontraremos una buena funcionalidad.

Un par de detalles mas sobre los problemas en la migracion de mi codigo en formato COMPASS a asMSX:

- Cuando usaba etiquetas en mi codigo que para el asMSX estan reservadas (como "MSXDOS" o "Print") devuelve un error de "syntax error" cuando quedaria mas claro algo como "reserved symbol not permited as label"

- Cuando uso el comando EQU, si la etiqueta termina con ":" (dos puntos) me da un mensaje de error, yo creo que esto podria ser opcional... pues al final y al cabo no deja de ser una etiqueta, y siempre acaban con ":"


Sobre mi codigo, pues la verdad es que hace años que estoy pendiente del asMSX, desde que tu mismo en una ru de BCN estubimos charlando y me hablaste de él. Pero entre una cosa y otra nunca lo he llegado a utilizar.

Bueno, espero que mi pequeña aportacion a mejorar el asMSX sea positiva, y como minimo, algo mas compatible con el COMPASS. En mi opinion, el mejor ensamblador y mas completo para desarrollar usando el MSX2. (en su dia me registre y siempre tuve ilusion por ver la version 2.0 que nunca llego a publicarse...  :( )

Esto mas que un deseo es una pequeña duda.

¿Se pueden incluir  secciones de archivos a partir de un offset mayor de $10000 bytes?

Obtengo el siguiente error al compilar:

Vale. Pues me imagino que con la versión actual no, como has podido comprobar. Tendré que meterle mano a las tripas y cambiarlo, porque no tendría que haber problemas para usar hasta 32 bits de tamaño tanto para el offset (ay!) como para la longitud (ouch!).

Apuntado para la próxima revisión, WYZ.

Y, por cierto, ¿qué haces metiéndole mano al OPF con el asMSX? ;)

Ok! me vas a hacer usar el editor hexadecimal hasta la próxima revisión ;D

Al OPF, ... pues imagínate, jejeje. Es lo que tiene usar la MegaFlashRom de Pazos sin disquetera! y por cierto, un gustazo lo fácil que resulta usarla. Ya tengo montados varios MultiROMs y lo que mola mas aun, meterle los últimos Konamis parcheados.

WYZ: dado que eres mi cliente más antiguo y fiel, he introducido el cambio en el asMSX y te he puesto una nueva versión on-line, asMSX 0.15b (http://www.robsy.net/asmsx015b.zip). Con esto debería quedar solventado el error, aunque fíate de la informática y no corras :P

Si tuvieras cualquier otra dificultad, ya sabes dónde y cómo pedir. Por cierto, que también hice mis pruebas con el MegaFlashSCC vía cinta y eran muy prometedoras. Cargaba páginas de 8 KB comprimidas y con turbo directamente.

Gracias Robsy!!! me siento el enchufao del AsMSX ;D

Tenemos que poner cosas en común sobre la MegaFlash. En la RetroMadrid me dijo Manuel que tu ya habías estado peleándote con esto y mi idea sería hacer un frontend que facilitara las cosas... tiempo al tiempo.

Hola Robsy y DoraimonPPC,

Hace unos cuantos posts hablabais de un port para Amiga del asMSX... llegasteis a hacer algo?

Estaria muy interesado en este port, si es posible podria hacer el port yo mismo, y añadir el soporte de MACROS al mismo, que es lo que mas le echo en falta.

Ya me decis algo, gracias.

Juan

¿Me gustaría saber si al final hay versión de Mac? Lo pregunto porque me voy a poner a hacer un juego chorra ( mi primer juego chorra ) para MSX y no tengo ni puñetera idea de por donde empezar. Y claro, algo me dice que tendré que pasarme a windows para desarrollarlo.

Precisamente estoy igual. El código fuente manquesea, para mirar de compilarlo  ::)

Los comienzos serán duros, pero la recompensa será muy reconfortante. Los codigos fuente del pong de Karoshi ya no están en el foro. ¿Alguien los podría colgar? Please  :saimazoom:

Buenas Robsy,

Imagino que estas muy liado y demas, solo dejar una sugerencia mas de las mias para el asMSX que considero muy interesante:

Ya que el soporte de MACROS es muy tedioso, te comento la unica macro que yo usaba en COMPASS y que realmente me venia de perlas para ver el código mucho mas claro:

se trata de una macro para escribir al VDP en una sola linea:

   VDP   $87,$34

Esta macro expandida seria:

   LD   A,$34
   OUT  [$99],A
   LD   A,$87
   OUT   [$99],A

Parece una chorrada, pero lo estoy notando muchisimo hoy dia. He pensado que se podria soportar en el asMSX como un comando mas de los que ya hay... Esto yo creo que seria muy facil.

otros ejemplos podrian ser:

   VDP   $86,A
   VDP   $86,(HL)
   VDP   $86,0      (este usaria un XOR A)


la macro en compass es asi:

VDP:   MACRO   @D2,@D1
   LD   A,@D1
   OUT   ($99),A
   LD   A,@D2
   OUT   ($99),A
   ENDM

Bueno, lo dejo en tus manos...

Gracias

Juan

Deja que me lo piense, aunque no me parece mala idea...

Rezo para que asi sea :)

Gracias

Juan

Hola!

Después de considerar la implantación de la pseudoinstrucción VDP me surgen varias dudas importantes:

1.- Por cómo la planteas, entiendo que básicamente tiene sentido para MSX2, ¿verdad? Para MSX1 también, pero no se escribe tanto a la VDP directamente. Por otra parte, en la macro que indicas, ¿no habría que hacer que el bit de escritura 10XX XXXX lo pusiera directamente la macro? Lo digo porque es como más elegante a efectos de leer el código después.

2.- Podría generar muchos problemas de compatibilidad si no se comprueba primero que el puerto de VDP es el que indicas (99h), pero hacer que en cada llamada lea la posición de la BIOS puede hacer mucho más larga la ejecución de la instrucción, con un escenario malo, que sería leer cada vez la BIOS, y uno catastrófico, que sería tener que leer la BIOS con una llamada interslot, que sería necesaria en el caso de que estuviéramos trasteando en MSX-DOS o se hubiera cargado una ROM o cualquier cosa en la página 0 y no fuera directamente accesible.

Por todo esto, aunque sea perfectamente factible implementarla, me da mucho miedo hacerlo, por el "mal uso" y las "malas prácticas" en que puede desembocar una macro así. A ver si Ramones, protector de la compatibilidad y defensor del estándar, puede darnos alguna orientación.

Un saludo,

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.

Hola Robsy,

Entiendo los problemas que planteas, en los cuales tienes toda la razon del mundo, como respuesta a dicho problema se me ha ocurrido convertir el problema en un remedio, me explico:

Hagamos que la pseudoinstrucción VDP cumpla al 100% con el standard.

Yo siempre he usado los puertos $99 para acceder al VDP, cuando lo standard es usar el puerto que nos indica la BIOS del MSX, tal y como dice Ramones, lo mejor es apuntarnos cual es el puerto para acceder al VDP.

Mi solucion consiste en utilizar una direccion de memoria donde se encuentra el puerto de acceso al VDP:

VDP_PORT:   DB.B   $99

El programador deberia cargar esta direccion de memoria con el numero de puerto correcto antes de usar la macro VDP, que ahora quedaria asi:

VDP:   MACRO   @D2,@D1
   LD   A,[VDP_PORT]
   LD   C,A
   LD   A,@D1
   OUT   (C),A
   LD   A,@D2
   OUT   (C),A
   ENDM

Lo que comentas de poner los bits 10xxxxxx para acceder al VDP, se podria controlar dentro de la macro como sugieres, yo no lo hacia por temas de optimizacion.

Ya me dices que tal lo ves.

Al final y al cabo, esta macro es solo para que el codigo fuente se vea mucho mas claro y sea menos traumatico al programar al acceder al VDP, yo he usado mucho esta macro, y os aseguro que el no tenerla ahora se nota muchisimo.

Gracias

Juan

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.
 

Quizas podrias añadir una directiva para poder definir el nombre del fichero ensamblado, al estilo del 'fname' del tniasm. Creo que seria muy interesante.

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).