Pensando seriamente en saltar a MSX-C / Pascal / ASM

Yo veo la disyuntiva ASM vs C más un tema de versatilidad que otra cosa, me explico. El C me parece un lenguaje más multipropósito, el código generado es muy estructurado y legible, y tan pronto puedes hacer un arcade, como un rpg, como un juego de estrategia, como una aventura conversacional, como una aplicación de gestión de ficheros... Digamos que estudias un solo lenguaje y lo puedes usar para todo (por eso se inventó).

El ASM es más específico, está muy bien para el control total de la máquina, pero por ejemplo una aventura conversacional en ASM es innecesariamente compleja mientras en C es realmente sencilla de hacer (por poner un ejemplo extremo). Lo del control del hardware no nos engañemos, en C tenemos bastante control por 2 motivos:

1.- Puedes agregar código inline ASM para rutinas críticas.
2.- Tienes acceso a la MSX-BIOS, que implementa el 90% de las funciones propias del MSX que puedes necesitar.

Resumiendo, para mi el C es como "el anillo único", me basta con él para experimentar en MSX cualquier género.

Es cierto, tienes razón. Si te acostumbras a programar un lenguaje multipropósito como C o Basic, resulta fácil pasar a otro de similares característica. Pero ASM es único, más sencillo de aprender como funciona pero más complicado implementar funciones. Y no digamos realizar un programa/juego completamente con el.

Cada programador tiene sus gustos y sus maneras de programar. Tampoco podemos decir quien programa mejor o peor (salvo ciertas excepciones evidentes). Lo que si está claro es que si lo que se pretende es conseguir la máxima velocidad de ejecución, sobre todo en nuestros MSX que normalmente van solo a 3.5Mhz, hay que utilizar forzosamente ASM. En otras ocasiones no es tan necesario.

Basic si es fácil de programar en casi cualquier dialecto, probablemente pase igual con Pascal y otros. C está a mitad de camino, es fácil de entrada pero dominarlo es complicado. ASM es fácil de aprender, las instrucciones son bastante sencillas, lo difícil es adaptar la forma de pensar a la hora de programarlo sobre todo para programas grandes.

Por eso sigo pensando que ASM siempre estará ahí, es imprescindible para muchas cosas. Pero programar completamente con el puede convertirse en ocasiones en una tarea titánica, all menos para mí, por lo que alabo a aquellos que lo consiguen. En mi caso que estoy bastante acostumbrado a pensar con lenguajes de alto nivel como Basic, me resulta muy difícil hacer eso, salvo pequeñas rutinas en ASM para tareas concretas. Por ejemplo no me imagino desarrollando una BIOS de determinado periférico, que forzosamente debe ser en ASM.

No es que ASM sea un mito inalcanzable, es simplemente que mi forma de programar no me permite utilizar ASM como quizás haceis vosotros. Ya me gustaría. Pero si es cierto que al menos he conseguido hacer cosillas con el, básicas, pero útiles.

Tienes razón osises. En asm, resultan listados kilométricos.
Estamos desarrollando un megarom de 256 KBs. konami scc, de seis puzles, en escreen 8, y el listado ya pasa de las 4400 líneas. Hay un pequeño video en el hilo sobre screen 8.
Pero entiendo que es cuestión de organizarlo por módulos. Luego si se tiene un editor adecuado, y poniendo etiquetas explicativas, es relativamente fácil buscar, buscar y sustituir, etc.
Estoy usando el EditPlus 3, que además se adapta al lenguaje asm, y distingue con colores los distintos conceptos del listado.

Muy bien explicado Axel. Gracias
Viendo los paréntesis anidados del "C" recuerdo que hace años, trabajado con el programa de dibujo Autocad, había la posibilidad de crear algún comando especial tipo macroinstrucción, con el leguaje "Lisp". Creo que era algo parecido.

¡Norl! no... ni de coña, hay mucha mas información en ASM, lo del C lo decia por la comodidad a la hora de programar, pero como es mas "normal" hacerlo en ASM, hay mas información en ASM.