compilador separado

[boriel]

Hola Boriel
Perdona que escriba en español, pero mi inglés es malísimo.

Tu inglés es muy bueno (o al menos tan bueno como el mío, creo yo) y se te entiende perfectamente. Piensa que hay usuarios rusos, alemanes, españoles (de hecho sólo uno es inglés nativo, que yo recuerde) :mrgreen: Lo hacemos así porque, a pesar de la barrera del idioma, creemos que la comunidad debe estar unida.

Más o menos lo que te dije por twitter. Ya que la versión compatible con Sinclair Basic no sería muy útil, sí que se podrías sacar una versión extendida más simple. Se que es mucho trabajo y no te vas a poner después de 2 años, pero ya que es una idea te la comento.
-Quitar el tipo Float Point y todas las rutinas asociadas.

Esto no es necesario. Basta con no usar punto flotante en el programa y ya está. De hecho, es posible declarar las variables con DIM y usar typecast con CAST. Las rutinas de FP sólo se compilan si éste se usa. Lo mismo con todas las demás.

-Simplificar el parser. Por ejemplo impidiendo etiquetas con números y obligar los dos puntos detrás.

No entiendo la ventaja de esto. Un número a principio de linea se considera una etiqueta. De resto no hay nada extra. Las estiquetas normales (con dos puntos detrás) también se admiten. Realmente no es una carga para el compilador.

-Nuevas librerías de sprites: puedes usar las mismas del z88dk.

Ya se discutió en varios foros. Desgraciadamente, nadie las conoce lo suficiente (ni yo). No es sólo saber usarlas, es conocer el compilador y cómo saber integrarlas. Una de las cosas que se discutió es entender el formato .obj del z88dk (que es similar al elf), pero no está documentado y no lo entendí. El código fuente para de z88dk está en C. Habría que pasarlo a ZX BASIC para integrarlo como librería, por ejemplo. En definitiva, que no sabemos cómo hacerlo ni sé donde encontrar información.

-Usar un modo de compilación que no dependa de la ROM. Para este modo los programas serán más largos pero por ejemplo puedes hacer juegos compatibles con interfaz 2.

Eso no sería difícil. El compilador usa la ROM para los cálculos de FP, y creo que para el PLOT/DRAW/CIRCLE (en parte). De resto creo que no se usa para nada más. SCREEN$ es un función externa en library.bas, se puede cambiar. Todo es cuestión de probarlo. El caso es que es trabajo extra, y prefiero ir terminando las cosas pendientes antes de empezar esas otras, ya que es poco probable que algo como lo que dices (la mayoría de la gente lo que quiere es desarrollar juegos para Spectrum 48K y 128K).

-Permitir compilar en los primeros 16K. Esto es útil para juegos en cartucho o para usar los modos especiales del +2a y +3.

Eso se ha hablado en Speccy.org y aquí. No es tan sencillo, realmente es lo complicado. Los compañeros (na_th_an y la gente de The Mojon Twins) me han dicho que lo más usual es emplear esa memoria superior para recursos gráficos, sonidos y mapas (ocupan mucho y es fácilmente "relocatable"). En cambio el código es más complicado. Por ejemplo: habría que hacer que una ejecución de código no cruce un límite de página (page boundary cross) y que al llamar o hacer un retorno se compruebe a demás si la página es la correcta o no. Existen rutinas en la ROM del 128K para esto.

-Usar el doble buffer. Esto es para modelos +2a y +3 que disponen de video shadow (creo que puedes alternar la página 5 y la 7 como memoria de video)

Esto es perfectamente factible, y está parcialmente implementado:
Cuando empecé con las rutinas de salida a pantalla ya tuve eso en cuenta, pues el +2 (tengo uno) soporta el cambio de mapeo de memoria de vídeo (hay dos regiones). Las rutinas de impresión (PRINT) fueron las primeras en soportarlas. Las rutinas de dibujado (PLOT, DRAW, CIRCLE) lo llevan a partir de la versión 1.2.6, pero no está muy testeado aún. Así que esa parte la doy por concluida. Sólo hay que "POKEAR" una variable de la memoria que señala la dirección de comienzo de la RAM de vídeo y las rutinas hacen el resto. Faltaría el swapeo de buffer. Desgraciadamente, no tengo ya la información (creo que era una revista) que decía cual era el OUT que cambiaba la memoria de vídeo.