Buenas, necesitaría saber que rango de direcciones son las disponibles (al menos en MSX 1 sin expansión, a lo sumo una disquetera y puerto serie como la SVI 738) para programas binarios sin interferir con el BASIC. Tengo idea de haber visto un mapa de la memoria detallado donde indicaba para que se usaba cada parte de la memoria incluyendo variables de BASIC, listado del programa en BASIC, etc. Pero no puedo encontrarlo. El binario se cargaría con BLOAD.
Estoy haciendo una librería en C para manejo de threads , probé varios compiladores, pero como tuve que armarme mi propio crt0 para linkear y elegir un tamaño de heap necesito saber el rango de toda la memoria disponible para el usuario sin tocar nada del BASIC. También hice un programita para agregar la cabecera necesaria al binario para que sea cargable con BLOAD, seguro que existe, pero yo no encontré nada...
Más adelante voy a explicar un poco más lo que estoy haciendo, que no es nada de otro mundo, incluso ya se habrá hecho, pero la idea era hacerlo yo
Por cierto, quise hacer la librería para MSX-DOS ya que tendría más memoria disponible pero debido a que tengo un problema al hacer llamadas al sistema (de MSX-DOS) desde diferentes threads decidí hacerlo directamente sin MSX-DOS sobre la BIOS y el BASIC.

Esto es lo más tecnico que vi, link msxtech.pdf. suerte.

lo tengo a ese, me fije pero no vi nada detallado como yo busco, ya volveré a buscar, por el momento uso 0x9C40 que es la dirección que usa el compilador z88dk.
gracias

No hay nada que no use el sistema desde el comienzo del BASIC hasta el final de la memoria, tenes que cambiar el tope de la memoria del BASIC para reservar espacio para codigo maquina. Yo tuve este problema con el sintetizador de voz por soft, y con el driver para controlar el sintetizador de voz por hard, el primero lo ubique en el medio de la memoria del BASIC, creo que A000 es una de las direcciones que se suelen usar. Cuando quise hacer lo mismo con la aventura conversacional, que ocupaba toda la memoria y tuve que optimizar al maximo, no encontraba un lugar libre para ubicar el driver, de menos de 140 bytes. Ahi vi que contrario a lo que pensaba, la MSX almacena el programa BASIC desde el inicio y las variables justo a continuacion, a diferencia de otros BASIC que almacenan el programa de forma incremental y las variables hacia atras desde el final de la memoria, dejando un hueco libre en el medio.
El asunto con reservar memoria en MSX es que el final de la memoria no es fijo en todos los modelos, porque despues de eso hay una zona usada por el sistema, entre otras cosas para buffers de disco, y estos buffers dependen de la cantidad de unidades conectadas en el arranque, y del tamaño de los discos. Esto implica que podes calcular la direccion del tope de la memoria del BASIC, restarle lo que vos necesitas y correr el tope hacia abajo, pero esa direccion puede no funcionar en otras MSX con distinta configuracion de disketeras.

Fijate en la función "clear", en la página 217 del libro del link:
LINK
Tengo una forma de implementar la función en código de máquina, si la necesitás la busco.

acá hay de lo mismo

muchas gracias a ambos!!
voy a indagar un poco más a partir de la información que me brindaron y seguro que voy a volver con más preguntas

Fernando, ¿si el programa es binario, existe alguna razón en especial para dejar el BASIC? Por ejemplo, en caso de que sólo quieras la carga con un BLOAD desde el BASIC, tal vez te conviene generar un COM y despreocuparte por lo que ocupa el BASIC. 

Hacer espacio en el MSX es complicado cuando se trata de cargar programas grandes. Yo tuve los mismos problemas que comenta Pastbytes. Incluso, una vez solucionados, descubrí que la solución era parcial ya que no funcionaba para todas las MSX. 

El problema es que cada fabricante de MSX o periféricos almacenaban sus drivers o variables de memoria en cualquier región libre que no sea usada por las variables del sistema. De esa forma, siempre está la posibilidad de que exista un uso compartido de ciertas áreas, lo cual genera cuelgues.

Además de las recomendaciones previas de Pastbytes y Juan Carlos, lo que te aconsejo (y que me ha dado muy buenos resultados), es armar la misma configuración de hardware en BlueMSX o OpenMSX, y luego pausar la ejecución y usar el Debugger para inspeccionar cada página de memoria. El debugger te muestra incluso las modificaciones entre una pausa y otra.

Saludos,
S

Hola Saccopharynx, en principio no necesito el BASIC, solo la BIOS para las llamadas. No se bien en que dirección debería cargar con BLOAD para sobreescribir el BASIC sin problemas. En MSX-DOS el cambio de contexto entre threads funciona bien, pero el problema está al hacer llamadas al sistema desde MSX-DOS desde diferentes threads lo que provoca que se cuelgue todo. En cambio con BLOAD haciendo llamadas al BIOS no me pasa eso.
Vos decís que genere un binario tipo COM (dirección 0x0100) y lo cargue con BLOAD? El BIOS utiliza alguna región de memoria o simplemente el stack actual? Estaría bueno poder disponer de los 64k de RAM en un solo slot como hace MSX-DOS.
Con respecto al simulador uso OpenMSX en Linux con las ROMS de la SVI-738 que es una máquina que dispongo. Tambien tengo BlueMSX en un XP sobre VirtualBox, pero con la configuración por defecto (MSX1)
Por el momento como lo que estoy desarrollando es una libería no necesito demasiada memoria RAM, ya que no estoy haciendo una aplicación grande que usa la librería. De hecho no tengo nada especifico pensado para hacer con la librería . De todas maneras está bueno tener el máximo de memoria disponible porque los semáforos (para sincronización) suelen tomarse y liberarse muchas veces seguidas y se implementa con una cola (lista enlazada), por lo cual te imaginarás que la RAM es valiosa. Afortunadamente SDCC trae una implementación aceptable de malloc y free, pero claro, cuando el malloc tiene que empezar a buscar huecos de memoria libre (liberados por free) se pone lenta la cosa. Aunque debo decir que los resultados que he obtenido por el momento con programitas de prueba son bastante satisfactorios , al menos desde mi punto de vista.

No, me refería a generar un COM y ejecutarlo desde el MSX-DOS. Los cuelgues que comentás pueden ser por muchísimas razones pero me inclino por la stack (que termina sobrescribiendo alguna zona de memoria vital), o que estás haciendo las llamadas al BIOS cuando en la primera página de memoria está el MSX-DOS, en lugar del BIOS. Fijate además si estás haciendo el cambio de slot o si estás usando la "interslot call" correctamente. Dale una mirada a esta página: http://map.grauw.nl/sources/callbios.php, y hasta incluso al resto del sitio ya que tiene material muy bueno para el programador.

Saludos,
S