Proyecto Basic CoCo/Dragon/DP400 (Discusiones)

[jltursan]

Último mensaje de la página anterior:

Escuchando lo que persigues, no me queda otra que estar de acuerdo con los compañeros. ¿Por qué un BASIC interpretado?, ¿o no te he entendido bien y buscas crear un compilador de un BASIC avanzado?

Quiero decir, como dices, un BASIC es todo un mundo a la hora de buscarle los trucos que hacen que se ejecute más rápido. Me parece mucho más interesante eso que la creación de un nuevo intérprete. Siendo un BASIC Microsoft seguro que comparte todos estas curiosidades relativas al BASIC de Microsoft:

- Eliminar todos los comentarios.
- Usar siempre que sea posible variables de un sólo caracter.
- Nada de blancos redundantes. El código será ilegible; pero se ejecutará más rápido.
- Meter todos los comandos BASIC que se puedan en una sola línea.
- Usar siempre IF ... THEN [línea] o IF ... GOTO [línea] (la más rápida). Nunca IF ... THEN GOTO [línea].
- Las subrutinas más usadas deben de estar al comienzo del programa.
- Preferiblemente los GOTO se harán hacia delante y no hacia atrás.
- Usar siempre que se pueda variables INT declarando DEFINT a-Z al comienzo del programa. A veces da mejores resultados el usar el caracter % para identificar a una variable como INT, es cuestión de probar en cada caso en particular, cual funciona mejor (esta no creo que sea aplicable al BASIC del CoCo)
- Usar NEXT en lugar de NEXT [variable]. Es casi el doble de rápida.

Y bueno, otra cosa sería si te plantearas la creación de un compilador para el Extended BASIC por ejemplo. Eso si que sería una revolución bien recibida.

Por último, si uno de los objetivos es darle vidilla a la "scene" CoCo creando algo que permita desarrollar con comodidad nuevos juegos....¿no has visto el nuevo AGD Dragon/CoCo que ha convertido Pere?, es de lo más asequible a la hora de crear buenos juegos de calidad con el mínimo esfuerzo

[luiscoco]

Escuchando lo que persigues, no me queda otra que estar de acuerdo con los compañeros. ¿Por qué un BASIC interpretado?, ¿o no te he entendido bien y buscas crear un compilador de un BASIC avanzado?

Quiero decir, como dices, un BASIC es todo un mundo a la hora de buscarle los trucos que hacen que se ejecute más rápido. Me parece mucho más interesante eso que la creación de un nuevo intérprete. Siendo un BASIC Microsoft seguro que comparte todos estas curiosidades relativas al BASIC de Microsoft:

- Eliminar todos los comentarios.
- Usar siempre que sea posible variables de un sólo caracter.
- Nada de blancos redundantes. El código será ilegible; pero se ejecutará más rápido.
- Meter todos los comandos BASIC que se puedan en una sola línea.
- Usar siempre IF ... THEN [línea] o IF ... GOTO [línea] (la más rápida). Nunca IF ... THEN GOTO [línea].
- Las subrutinas más usadas deben de estar al comienzo del programa.
- Preferiblemente los GOTO se harán hacia delante y no hacia atrás.
- Usar siempre que se pueda variables INT declarando DEFINT a-Z al comienzo del programa. A veces da mejores resultados el usar el caracter % para identificar a una variable como INT, es cuestión de probar en cada caso en particular, cual funciona mejor (esta no creo que sea aplicable al BASIC del CoCo)
- Usar NEXT en lugar de NEXT [variable]. Es casi el doble de rápida.

Y bueno, otra cosa sería si te plantearas la creación de un compilador para el Extended BASIC por ejemplo. Eso si que sería una revolución bien recibida.

Por último, si uno de los objetivos es darle vidilla a la "scene" CoCo creando algo que permita desarrollar con comodidad nuevos juegos....¿no has visto el nuevo AGD Dragon/CoCo que ha convertido Pere?, es de lo más asequible a la hora de crear buenos juegos de calidad con el mínimo esfuerzo

Es un Basic con las ventajas de un interpretado pero estará casi completamente compilado. es lo que llama microsoft un código intermedio, algo que implementó muy bien en VB6 y en los Basic para aplicaciones como el basic que hay dentro de WORD, EXCEL y ACCESS que son los que uso actualmente.

Con respecto a las eficiencias que bien colocas, ninguna se aplica a mi basic, ya que precisamente quita todas.
El programador no tiene que lidiar con ninguna de esas cosas, si quieres te explico el porque de casa una.
Este basic correrá casi tan rápido interpretado como compilado, solo mejora un 5 a un 10% al compilarlo.
y con respecto a AGD, lo conozco a fondo, hago una conversión para AMIGA. pero tiene sus limitaciones. pienso que un basic que pueda hacer lo mismo seria positivo. Como prueba pongo el AMOS que debido a los 500 comandos que tiene puede hacer cosas que solo en assembler se podrían hacer.
Ademas el editor de la color computer/dragon me mata, jajaja. mejor full screen y mas en coco3 con 80 columnas.
Tratare de que se pueda colocar en ROM y mantener la capacidad de usar HD sin perder la mitad del espacio. (defectillo extra).

[pser1]

Es un Basic con las ventajas de un interpretado pero estará casi completamente compilado. es lo que llama microsoft un código intermedio, algo que implemento muy bien en VB6 y en los Basic para aplicaciones como el basic que hay dentro de WORD, EXCEL y ACCESS que son los que uso actualmente.
Con respecto a las eficiencias que bien colocas, ninguna se aplica a mi basic, ya que precisamente quita todas.
El programador no tiene que lidiar con ninguna de esas cosas, si quieres te explico el porque de casa una.
Este basic correrá casi tan rápido interpretado como compilado, solo mejora un 5 a un 10% al compilarlo.
y con respecto a AGD, lo conozco a fondo, hago una conversión para AMIGA. pero tiene sus limitaciones. pienso que un basic que pueda hacer lo mismo seria positivo. Como prueba pongo el AMOS que debido a los 500 comandos que tiene puede hacer cosas que solo en assembler se podrían hacer.
Ademas el editor de la color computer/dragon me mata, jajaja. mejor full screen y mas en coco3 con 80 columnas.
Tratare de que se pueda colocar en ROM y mantener la capacidad de usar HD sin perder la mitad del espacio. (defectillo extra).

Hola Luis,
creo que estamos confundiendo conceptos con ideas o ganas ...
Si el programador escribe en un lenguaje de alto nivel, como por ejemplo tu nuevo Basic en lugar de ensamblador, entonces
esto será *interpretado* linea a línea cada vez que se ejecute. Así es el Basic, que usará las rutinas que tu hayas implementado en
ensamblador tal como hizo Microsoft en su momento.
No capto esto de "estará casi completamente compilado", ¿Existirá un fichero que habrá que guardar como código 'intermedio'?
¿En que momento se generará?
Lo siento, pero cuanto mas leo de este hilo menos lo entiendo ...
saludos
pere

[luiscoco]

Hola Luis,
creo que estamos confundiendo conceptos con ideas o ganas ...
Si el programador escribe en un lenguaje de alto nivel, como por ejemplo tu nuevo Basic en lugar de ensamblador, entonces
esto será *interpretado* linea a línea cada vez que se ejecute. Así es el Basic, que usará las rutinas que tu hayas implementado en
ensamblador tal como hizo Microsoft en su momento.
No capto esto de "estará casi completamente compilado", ¿Existirá un fichero que habrá que guardar como código 'intermedio'?
¿En que momento se generará?
Lo siento, pero cuanto mas leo de este hilo menos lo entiendo ...
saludos
pere

Te explico la idea, cuando compilas, tomas cada palabra y le colocas una llamada directa a la función con sus parámetros estandarizados. El basic normalmente llama a las funciones (o comandos) en forma eficiente con los token, solo busca el token y lo lanza a la rutina, hay poca mejora en poner el JSR directamente y no indexadamente, pero lo podría hacer, luego con los parámetros el basic normal chequea en vivo la sintaxis, el mio tendrá todo chequeado desde el editor (en parte, solo avisos, no prohibiciones) y antes de rodar y solo la primera vez, chequea obligatorio o no corre, así no mas, como AMOS, se detendrá y te explicara la burrada que hiciste, jajaja.
Una vez hecho esto procesara los parámetros como un compilador, tratara de convertir en binario los literales, dará lugar fijo a las variables con acceso directo, sin búsquedas, a los datos, y al igual que un compilador algunas cosa dependerán de sus valores y no podrán hacer mas. Quedaran indicadas en forma eficiente.
- Mis Funciones y Comandos, por ahora permanecen indexados, se podrían cambiar a jump directos, colocando el jump después del token, mantengo el token para los listados, pero lo puedo quitar.
- Todas las variables antes de rodar se les asignan lugares fijos (por ahora, excepto las de los SUB y FUNCTIONS que son dinámicas, aun por discutir)
- Todos los literales pasan a binario.
- Todos los parámetros están exceptos de errores.
- Todos los GOTOs y GOSUBs tiene delante de número o label un jump directo al destino(en el fuente), este jump se crea en el primer rodaje, como el chequeo de sintaxis y la creación de variables fijas con acceso directo a sus valores.
- Manejo de INTEGER, BYTE, DOUBLE, STRING * N de largo fijo, string de 64k, estructuras, Funciones y SUbs con variables independientes.
- Nombres largos de variables, solo se almacena el nombre una vez. Todas las llamadas a esta variable son cambiadas por su dirección.
- Mas unas 150 Funciones y comandos nuevos, gráficos, ASM en linea y demás.
Después de todo esto, creo que poco puede aportar un compilador. Pero todo es posible. El mayor desafió es detenerlo cambiar o crear variables y lineas y continuar ejecutándolo como hace VB6. En esta parte esto ahora pensando.

Abre tu mente, se puede, y no lo invente yo, al menos no el concepto, esta VB6 y AMOS que corren prácticamente igual si los compilas o no.
Puede que sea una locura, pero mas bien por el lado de que lo pueda lograr, no por el concepto en si.

[luiscoco]

Hay cosas que aun no entiendo del basic normal, cuando llama a las rutinas a veces ya cuanta con uno o dos parámetros en las manos y aveces no, por ejemplo el RIGHT$ no busca la coma ni el segundo parámetro, ya los tiene o los busca en el STACK, pero el POKE llama a evaluar 2 expresiones como si no le hubieran enviado ni una sola analizada. tengo que profundizar.

[pser1]

Hola Luis,
sigo a cuadros a pesar de tu explicación.
En modo edición es difícil chequear cosas ya que muchas veces se llaman partes de códgo que todavía no has escrito ...
Pero, en fin, dejémoslo ... Cada uno se dedica a lo que le gusta y está claro que ésto lleva tiempo rondando por tu cabeza! Suerte!
Yo he empezado ahora a trastear con la tarjeta GMC (Game Master Cartridge) de John W Linville que contiene un generador de sonido
basado en el chip SN76489 que, de alguna forma, puede emular los AY-3-8xxx o sea tres canales de sonido mas uno de ruidos/efectos.
Así que, por ejemplo, podría utilizarse para escuchar la música de los juegos AGD (algunos tienen).
Como puedes ver, proyecto pequeño, con cosas ya analizadas y con soft ya hecho para el CoCo. La única complicación, y será grande, va a ser
convertir el código de Spectrum para el AY-3-8xxx a 6809 y encontrar donde lo puedo ubicar en mi motor6809
Como alternativa dispongo de un módulo CoCo-PSG de Ed Snider (basado en un YM2149) que además del chip de sonido contiene
la barbaridad de 512K de RAM y 512k de ROM (hecha con flash RAM). La flash podría contener el 'motor' de sonido a piñón fijo
y la RAM podría contener las canciones que se necesiten. Parece una buena opción si el soft no 'cabe' en los 64K estandar de CoCo-Dragon
El GMC también tiene 64K de EEPROM que se podrían usar para grabar el motor de sonido de AGD
saludos
pere

[luiscoco]

Muy interesante, Sí, es mas conciso, yo me estoy arriesgando a que sea perdida de tiempo, pero bueno, ni modo.
Yo tambien flipo con lo que haces y lo rápido que lo haces, nada que ver con mi lentitud, pero ni modo, adelante.
Ya le daré soporte desde basic, porque si no solo quedan drivers desde NitrOS-9 o AGD

[luiscoco]

Pregunta a Pser1 o si alguien se anima.
En el LOOP principal del Basic LOOP principal,¿Veis para que sirven los links?, los comandos son buscados mediante su TOKEN, y luego saltan al código.
Hasta donde entiendo solo se carga el primer byte en ACCA (en las funciones 2 byes) y se salta a la rutina, ahora bien, no logro ver porque la rutina CHR$ (mira que lindo queda, jajaja), la rutina comienza asumiendo que el primer parámetro (un número) esta ya listo en el FPA0 y trata de pasarlo a entero. Pero yo no veo ninguna llamada al evaluador de expresiones para que evalué el parámetro numérico de CHR$(X) y lo ponga en FPA0 y me he recorrido todo el proceso inclusive el loop, obviamente estoy equivocado pero no veo donde.
Alguien me puede ayudar?

Edito: Después de varios días, hoy explicándole a mi hijo el problema, me di cuenta de mi error, resulta que obviamente el CHR$ es una función y no puede ir de primero en una linea, sino después de un PRINT o en el lado derecho de una expresión y por eso es que el FPA0 esta lleno con el parámetro (seguramente el evaluador de expresiones hizo el trabajo).

[luiscoco]

Estoy pasando casi todo el hilo original a un documento con sus links en WORD luego se podrá borrar o dejar parcialmente.
Comenzare ha hacer parte del trabajo y como prueba usare el CLS

Curiosidades del CLS
Normalmente se puede usar el CLS sin parámetros para borrar la pantalla en verde y coloca el cursor en la esquina superior izquierda o si usamos CLSN o CLS____N (con espacios en medio) o CLS(N) siendo N un número de 0-8 entonces limpia la pantalla con el color indicado.
- Si usamos para N, desde el 9 al 255, nos limpia la pantalla pero pone "MICROSOFT", en DRAGON sale "(C) 1982 BY MICROSOFT"
- Si usamos para N, un número mayor de 255 o menor que 0, También con cadenas dará Error "FC" = Illegal Function Call, Llamada a función ilegal.
- No usa ni modifica el color de fondo, solo en coco3 en texto alta definición con Width 40 o 80 si lo usa y lo modifica, con Width 32 no.

Ahora bien, la curiosidad de imprimir "MICROSOFT" no ayuda en nada. Me imagino que es una forma rápida de saber de quien es el basic.
Lo que no se explica y aunque no importe me parece una incoherencia es que si usas el CLS solo, entonces borra con el carácter $60 que el espacio en texto (el $20=32 es el espacio pero para el PRINT), y si se usa el CLS1 Borra tambien en verde, pero usa el $80=96 que es el bloque gráfico verde. Al final borra verde igual pero no se porque esa decisión o error.

Me parece que hay que estudiar si permitir usar comandos con paréntesis, me imagino que es como si usáramos los paréntesis en cualquier expresión y como solo hay un solo parámetro, pues da igual. Pero por ser comando no necesita los paréntesis.

Nuevo BASIC
Pienso que se puede mejorar así:
CLS N Para el parámetro N=color, podemos tomar la N como color para el rango 0-8 y para los demás valores seria interesante tomarlo como BYTE de relleno, se podrían hacer pantallas de cualquier bloque o carácter. Ademas podemos pintar zonas de la pantalla, se pueden hacer marcos complejos a alta velocidad.
CLS N[,X,Y]: Donde los 2 parámetros siguientes son opcionales y serán números desde 0 al 511, con las posiciones de comienzo y fin en caracteres seguidos como en el PRINT @.
CLS N[, X, Y, X1, Y1]: Donde los 4 parámetros siguientes son opcionales y serán números desde 0 al 31 para la X y la X1, y desde el 0 al 15 para la Y y la Y1 con las coordenadas (X,Y) de la esquina superior izquierda y (X1,Y1) serán las coordenadas de la esquina inferior derecha en caracteres.

- Es posible que se pudieran hacer zonas como en el SET (64 x 32) (pixeles gordos) pero creo que se complicaría, tal vez se pueda implementar un LINE para baja resolución que haga recuadros y cajas o bordes y rellenos.

El original de microsoft solo trabaja de byte en byte

Código: Seleccionar todo

1324 * CLEAR SCREEN
LA928   LDB #$60         BLANK
      LDX #VIDRAM      GET ADDR OF START OF SCREEN BUFFER
LA92D   STX   CURPOS      SAVE IT IN CURPOS
LA92F   STB ,X+         FILL SCREEN WITH CONTENTS OF ACCB
      CMPX #VIDRAM+511   END OF SCREEN?
      BLS LA92F         NO
      RTS

Dos códigos para CLS muy buenos del amigo Simon Jonassen
El primero muy simple pero ya mejor que el de microsoft, ya que coloca de 2 en 2 los bytes.

Código: Seleccionar todo

;****************************   
; CLEAR THE SCREEN
;****************************   
   ldd   #$8080
   ldx   #$400
clrsc   std   ,x++
   cmpx   #$600
   blo   clrsc


El segundo muy veloz, ya que solo comprueba la mitad de las veces tambien de 2 en 2, o mas bien de 4 en 4

Código: Seleccionar todo

;***************************
; funky cls
;***************************
fcls
   ldx   #$400
   ldu   #$600

waitr   lda   $ff03
   bpl   waitr
   lda   $ff02
w2   lda   $ff03
   bpl   w2
   lda   $ff02

   ldd   #$8080
tline   std   ,x++
   std   ,--u
   cmpx   #$500
   bne   waitr
   rts


Código final próximamente