compilador separado

[sindecencia]

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

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.
-Simplificar el parser. Por ejemplo impidiendo etiquetas con números y obligar los dos puntos detrás.
-Nuevas librerías de sprites: puedes usar las mismas del z88dk.
-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.
-Permitir compilar en los primeros 16K. Esto es útil para juegos en cartucho o para usar los modos especiales del +2a y +3.
-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)

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

[sindecencia]

Perdona, no había visto tu respuesta. Pensé que el post estaba duplicado por error.

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.

Gracias, sé que me meto muchos patones gramaticales y ortográficos, pero si lo entendéis más o menos, me alegro.

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.

Ya, bueno lo dije por desconocimiento, pensaba que el runtime era fijo.

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

La ventaja no es para quitar carga al compilador, es para obligar al programador. Es decir que elijas entre una sintaxis "compatible", con números de línea, sin acabar con END IF... o entre una sintaxis mejorada tipo FreeBasic. Pero impedir que puedas mezclarlas, y así mejorar la legibilidad de los códigos. Tengo una base de datos con un montón de .taps, si quieres puedo filtrarte los que tengan 2 bloques (cabecera y basic). La idea es pasarle un filtro (no sé si existe) que lo convierta a Ascii (legible por ZXBC) y ver hasta qué punto los programas son compatibles. Te lo digo porque si por ejemplo el 90% usan vals sencillos (de estos que convierten cadenas a números) igual compensa hacer una implementación cutre de VAL, READ e INPUT y poner el switch de compilación -legacy

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

No sé, pensaba que estaba el código asm disponible, como no lo está pues habrá que desensamblar los .obj. Le echaré un vistazo a ver si puedo ayudar en esto.

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

Ya hombre no quiero agobiarte. Más que para juegos IF2 lo veo interesante para el modo todo RAM en +2A/+3. Disponer de un 33% más de RAM direccionable es una ventaja que no se puede despreciar.

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

No veo la complicación. Mueves el cargador a $FF00 (en la última página del modo todo RAM). Luego conmutas al modo todo RAM y saltas al cargador. Podrías cargar todo el programa en un único bloque de casi 64Kb. Eso sí el cargador debe incluir la rutina de carga estandar en cinta. Serían 3 bloques de carga en total (cabecera, cargador y programa).

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

Qué dices pero si eso está en WOS (te busco el enlace)
.
.
.
.
.
.
.
<!-- m --><a class="postlink" href="http://www.worldofspectrum.org/faq/reference/128kreference.htm">http://www.worldofspectrum.org/faq/refe ... erence.htm</a><!-- m -->

puerto 0x7ffd Bit 3
o en modos especiales +2A/+3 con bit 1 y 2 del puerto 0x1ffd

[sindecencia]

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.

Acabo de bajarme el código fuente de z88dk de aquí:
<!-- m --><a class="postlink" href="http://sourceforge.net/projects/z88dk/files/z88dk/1.9/z88dk-src-1.9.tgz/download">http://sourceforge.net/projects/z88dk/f ... z/download</a><!-- m -->

Las librerías de sprites están disponibles en ASM, métete por ejemplo en z88dk\libsrc\sprites\software\sp1\spectrum\sprites

[boriel]

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.

Acabo de bajarme el código fuente de z88dk de aquí:
<!-- m --><a class="postlink" href="http://sourceforge.net/projects/z88dk/files/z88dk/1.9/z88dk-src-1.9.tgz/download">http://sourceforge.net/projects/z88dk/f ... z/download</a><!-- m -->

Las librerías de sprites están disponibles en ASM, métete por ejemplo en z88dk\libsrc\sprites\software\sp1\spectrum\sprites

No me expliqué bien: sé que existe el fuente (de hecho lo tengo), pero no sé ni cómo aprovecharlo para el ZX Basic. Es enorme, no sé si existe documentación (la última vez que miré, no mucha), ni sé todas las subrutinas que tendría que portar. Las que están en ASM son casi directas (mi ensamblador no soporta algunas de las directivas del z88dk, pero eso se puede arreglar). El otro problema es convertir de C a BASIC (o a ASM) el resto del código.

Lo que hablamos en WOS era aprovechar directamente los obj, porque así se podría llamar directamente a los módulos C del z88dk ;-) y aprovechar todo lo que ofrece.