Ouch. El problema de inestabilidad del parser es antiguo. Cuando te dé problemas de etiquetas, añade un NOP en cualquier sitio y se arreglará. Respecto a los syntax error, son más impredecibles.

La idea es que tendría que reescribir desde 0 el asMSX para hacerlo estable, portable, etc. Me apetece, porque me gustaría darle otro diseño interno, pero no voy sobrado de tiempo últimamente. Además, puede que haga una versión portable de verdad (para ensamblar ROMs de MSX en mi Palm m105 viejecita).

Ok, aclarado, muchas gracias  Es que no había leído ningún comentario al respecto, que yo recuerde, y ya empezaba a preguntarme si sólo me pasaba a mí.

Respecto a reescribirlo, yo me conformo con una aplicación win32 con editor de textos, colores redefinibles, menús, etc. Casi ná, vamos 

¡Venga, a darle al Final Lap! 

¿Qué es Eclipse? ¿Y a qué te refieres con editor de recursos?

Supongo que costará un huevo hacer una aplicación win32, pero ¿te has pensado hacer un entorno autónomo, como el que mencionaba? Sería la leche 

Mis MFCs se han quedado bastante obsoletas; desde hace tiempo, cuando me veo obligado a hacer algo con IDE empleo el Borland Builder que es mucho más católico. Respecto a los kits híbridos Windows/Linux hace poco he empezado a curiosear con las FLTK, a ver que tal. Las GTK las descarté, a pesar de que no están del todo mal, por enrevesadas
El Eclipse no está mal; pero es muy pesado usando Java y tal...; para andar por casa suelo usar, cuando se trata de programillas C estandar en Windows, el Dev-C++, IDE en torno al GCC.
A mi me parece también bastante apropiado el que el asMSX permanezca en modo consola. De todas formas, la mayoría de los editores permiten una integración muy sencilla con los compiladores; así puedes escoger cual te gusta más.

Yo en PC no pasé del Turbo Pascal para DOS 

Pues como funcionalidad adicional, lo suyo sería incluir un editor gráfico [caracteres, patrones, sprites, etc.], editor de sonidos y tracker [con un formato ya dado], compresión bitbuster on-the-fly y alguna que otra guarrería. Se perdería alguna flexibilidad, pero se ganaría en productividad.

Por ejemplo

.COMPRESSED "graficos.bin"

Aunque claro que eso se lo puedo meter a piñón al asMSX junto con el descompresor. Eso sí, lo que no voy a poder hacer fácilmente es la identificación de lo que hay que comprimir y lo que ya lo está. Supongo que comparando simplemente las fecha del fichero original y del comprimido. Si el original tiene una fecha más tardía, pues se recomprime y listo.

Menudo lío. Pero sí, tengo ganas de meterme en un nuevo asMSX, evolucionando el concepto. Eso sí, debo empezar desde 0 con todas las lecciones aprendidas hasta la fecha con el resto de ensambladores que he programado: GAL, GAeL [Gameboy, Gameboy Color], NESasm [NES/6502], asMSX, Rz80 [MSX/Z80]. Tengo ya la combinación Bison/Flex bastante domesticada.

Además, si todo el desarrollo lo hago en C en Linux, no habrá problemas de compatibilidad después para hacer una versión para Win32, Mac, Amiga o lo que os dé la gana.

Por cierto, te serviria el fichero .hlp del NO$MSX? Las instrucciones del Z80 estan bien ordenadas por grupos y como guia de referencia rapida va bastante bien.

saludos!