Programar en Forth

[mcleod_ideafix]

A mi me salen 9 segundos usando este código (que se cronometra él mismo):

Código: Seleccionar todo

DIM x,y as uinteger
DIM ti,tf as ulong
ti=peek(23672)+256*peek(23673)+65536*peek(23674)
FOR y = 16 TO 191
  FOR x = 0 TO 255
    PLOT x,y
  NEXT x
NEXT y
tf=peek(23672)+256*peek(23673)+65536*peek(23674)
print at 23,0;(tf-ti)/50
pause 0

Como referencia, una versión en ensamblador puro que use la rutina de la ROM para dibujar el punto, como ésta:

Código: Seleccionar todo

plotbc                  equ 22e5h  ;B=y, C=x

                        org 32768
                        ld b,175
buclinea                ld c,255
bucpunto                push bc
                        call plotbc
                        pop bc
                        dec c
                        jp nz,bucpunto
                        djnz buclinea
                        ret

                        end 32768

Me tarda 7,32 segundos, medido de esta forma:

Código: Seleccionar todo

10 LET ti=PEEK 23672+256*PEEK 23673+65536*PEEK 23674: RANDOMIZE USR 32768: LET
 tf=PEEK 23672+256*PEEK 23673+256*PEEK 23674: PRINT #0;AT 1,0;(tf-ti)/50: PAUSE 0

[na_th_an]

Por lo que queda demostrado que el compilador de Boriel es la repanhostia en babuchas Felicidades, debes estar orgulloso.

[mcleod_ideafix]

Por lo que queda demostrado que el compilador de Boriel es la repanhostia en babuchas Felicidades, debes estar orgulloso.

Pues fíjate que precisamente hay una diferencia aún bastante evidente entre la versión en ZX Basic y la de ensamblador, aunque las estructuras de control que se usan en ZX Basic admiten todo tipo de optimizaciones. La razón por la que tarda hasta 2 segundos más es porque no me ha dejado usar variables de tipo UBYTE para x,y sino que he tenido que usar UINTEGER, es decir, de 16 bits. Con x,y de tipo UBYTE el programa no funcionaba correctamente. El motivo es éste:

Código: Seleccionar todo

   ld a, (_x)
   ld h, a
   ld a, 255
   cp h
   jp c, __LABEL9

El salto condicional a __LABEL9 jamás se toma, porque la condición jamás es cierta. Pero aún así, es posible escribir bucles que den 256 vueltas usando índices de 8 bits. Podría merecer la pena que el compilador estudie el caso de bucles cuyo índice es una variable de tipo byte, para codificarlos metiendo el índice en el registro B y usando DJNZ (vamos, lo que sería una variable de tipo "register" en C).

Teniendo en cuenta esto, he modificado el programa para que X sea entera, e Y de tipo byte (con Y no pasa esto, claro) y ahora obtengo... lo mismo! 9 segundos.

¿Por qué el código que compara un valor de byte con un número inmediato se codifica así:

Código: Seleccionar todo

   ld a, (_y)
   ld h, a
   ld a, 191
   cp h
   jp c, __LABEL3

en lugar de hacerse así?

Código: Seleccionar todo

   ld a, (_y)
   cp 191
   jp c, __LABEL3

Es decir, fíjate que es como si se usara la misma plantilla de generación de código en 8 y 16 bits. Así se hace en 16 bits:

Código: Seleccionar todo

   ld de, (_x)
   ld hl, 255
   or a
   sbc hl, de
   jp c, __LABEL9

Aquí hay el mismo patrón que en 8 bits: se usan registros de 16 bits, claro, y la inexistente instrucción CP DE,HL se codifica con OR A ; SBC HL,DE . Dado que el Z80 es un micro de 8 bits, se deberían favorecer las operaciones de 8 bits de alguna forma, ¿no? Tal y como se codifican ahora, hay poca diferencia (en tiempo de ejecución) entre usar variables de 16 bits y usar variables de 8 bits.

Voy a ver si puedo hacer pruebas con el SDCC, a ver cómo se comporta con este tipo de bucles...

[Boriel]

Creo que algo no está funcionando bien en el optimizador (-O3) de mirilla.
Por ejemplo, la secuencia de código:

Código: Seleccionar todo

ld a, (_y)
inc a
ld (_y), a

Debería traducirse a

Código: Seleccionar todo

ld hl, _y
inc (hl)

pero no lo está haciendo, pese a que se puede. Qué mosca...

Igualmente, el patrón de código que se comenta de la comparación de 8 bits no está optimizado. Ese puede que me haya olvidado de codificarlo. Lo haré para la siguiente versión.

Por último, el FOR de BASIC es un poco especial, ya que en realidad, si fuera en C se codificaría como

Código: Seleccionar todo

for (x = 0; x <= 255; x += STEP) {
...
}

Es decir, tenemos un <= y además, el tamaño de paso (STEP) es variable. Sería detectar un caso o 2 casos muy concretos y el coste puede no valer la pena. Por ejemplo, haciendo LD B, 0 es posible usar DJNZ para hacer bucles de 256 iteraciones con un byte, pero si el cuerpo del bucle es muy largo pueden pasar dos cosas: Que el djnz no llegue al comienzo del bucle (es un salto relativo de -128 bytes como mucho) o que el registro B sea alterado en algún paso intermedio.

Para rutinas críticas (emisión de sonido, etc.) incluso los juegos comerciales usan ensamblador hoy día (o ANSI C). Pero bueno, iré mirando qué puede hacerse... Gracias!

[mcleod_ideafix]

Por último, el FOR de BASIC es un poco especial, ya que en realidad, si fuera en C se codificaría como

Código: Seleccionar todo

for (x = 0; x <= 255; x += STEP) {
...
}

Sí. Y además, este código fallaría en C de la misma forma que lo hace en ZX BASIC, si x es de tipo unsigned char (el equivalente a un ubyte). Tienes razón que el caso particular de 256 vueltas con DJNZ es, eso, particular, porque sólo vale para bucles pequeños. La optimización de la comparación en 8 bits sí creo que merece la pena hacerse. En tal caso, el código generado por el compilador y uno hecho en ensamblador, para este pequeño "benchmark sintético" daría unos tiempos muy muy similares.

PD: aunque también se podría hacer una optimización de tipo "loop unrolling" y aquello que debe repetirse 256 veces ahora sólo se repetiría pues 128 o 64 veces, con lo que cabría el índice en un registro de 8 bits, sin peligro de desbordamiento. Ahora que... hacer loop unrolling cuando la memoria es un bien muy preciado, como que no, ¿no?

[Boriel]

Bueno, he corregido el fallito de la optimización (espero no haberme cargado nada que lo suelo hacer cada vez que "arreglo algo").
Si alguien quiere probar la versión 1.2.6 beta, está aquí: http://www.boriel.com/files/zxb/ (ojo, no es la "latest version", esas son siempre las estables, no las betas).

He vuelto a hacer las pruebas con -O3 y no baja de los 9 segundos.

na_th_an, respecto a tu optimización, el código:

Código: Seleccionar todo

   ld a, (_y)
   ld h, a
   ld a, 191
   cp h
   jp c, __LABEL9

está calculando 191 - y y saltando si es negativo (o sea, si _y > 191).
Tu optimización:

Código: Seleccionar todo

   ld a, (_y)
   cp 191
   jp c, __LABEL3

calcula _y - 191 y salta mientras (while) y < 191 (ojo, no hace la iteración y=191 y el FOR sí).
Si quieres que se codifique así, usa WHILE y no FOR, ya que los saltos son distintos. Se me ocurre que usando un WHILE con y < 192 podría ir más rápido, y ahora sale:

Código: Seleccionar todo

ld a, (y_)
ld h, 191
cp h
jp c, __LABEL...

Todavía se puede quitar ld h,191 y poner cp 191... codificaré esa optimización para la próxima (tiene una razón de por qué se hace así). En cualquier caso, sigue en 8 segundos.

Respecto al loop unrolling, lo había pensado, pero no sé si valdrá la pena... ¿No será mejor dejar eso al programador? (usando asm)... es que salvo que sean bucles con variables de tipo byte y de pocas iteraciones (por ej. 4 o menos), creo que puede se caro. Por lo que he leído, cuando se le saca partido a esto suele ser a rutinas tipo sprite o generadores de onda (sonido). También en el caso de bucles anidados, el que importa siempre es el interno... Pues no sé que hacer...

[Ecalius]

Hola amigos, he descartado la idea de acceder directamente
a la memoria desde Forth para imprimir un sprite, porque para
acceder a ese nivel es preferible hacerlo desde el código máquina,
que es muchísimo más veloz, y en mi búsqueda de soluciones
alternativas he construido la palabra PLOTSPRITE, que imprime
un sprite en pantalla mediante la palabra PLOT, previamente habiendo
introducido los datos del sprite en la pila, mediante la palabra SPRITE,
y habiendo colocado en las variables ANCHO y ALTO sus dimensiones
en pixels, y sus coordenadas en POSXI y POSYI.

Despues, para probar el sprite en movimiento en construido las palabras
PUTSPRITE, GETSPRITE y MOVESPRITE, y finalmente para verlo en acción
la palabra DEMOSPRITE.

La prueba ha sido un fracaso, por la lentitud del asunto, y veo 3
soluciones para continuar, una de ellas es intentar meter Código Máquina
en el compilador de Forth para crear la nueva palabra PUTSPRITE,
pero el problema es que no sé cómo hacerlo todavía, utilizo el Forth de
Abersoft. Otra es utilizar UDGs y utilizar la palabra adecuada de Forth
para imprimirlos, y hacer todas las animaciones posibles para simular el
movimiento pixel a pixel, y la última es no liarme tanto, usar UDGs y hacer
que el movimiento sea de 8 en 8 pixeles. ;-(

Ya veremos, de momento os dejo el listado para introducirlo en el compilador
de Forth de Abersoft. Leeros primero sus instrucciones para poder introducirlo, ya que su editor es un tanto peculiar.


( PLOTSPRITE: IMPRIME UN SPRITE MEDIANTE PLOTS )

100 VARIABLE POSXI
100 VARIABLE POSYI
0 VARIABLE POSXF
0 VARIABLE POSX
0 VARIABLE POSY
8 VARIABLE ANCHO
8 VARIABLE ALTO
0 VARIABLE COLORSPR

: SPRITE 1111 1111
1111 1111
1111 1111
1111 1111
1111 1111
1111 1111
1111 1111
1111 1111 ;

: PLOT0001 POSX @ 3 + POSY @ PLOT ;
: PLOT0010 POSX @ 2 + POSY @ PLOT ;
: PLOT0011 PLOT0001 PLOT0010 ;
: PLOT0100 POSX @ 1 + POSY @ PLOT ;
: PLOT0101 PLOT0001 PLOT0100 ;
: PLOT0110 PLOT0010 PLOT0100 ;
: PLOT0111 PLOT0001 PLOT0110 ;
: PLOT1000 POSX @ POSY @ PLOT ;
: PLOT1001 PLOT0001 PLOT1000 ;
: PLOT1010 PLOT0010 PLOT1000 ;
: PLOT1011 PLOT0011 PLOT1000 ;
: PLOT1100 PLOT0100 PLOT1000 ;
: PLOT1101 PLOT0001 PLOT1100 ;
: PLOT1110 PLOT0010 PLOT1100 ;
: PLOT1111 PLOT0011 PLOT1100 ;

: PUTPLOTS CASE 0001 OF PLOT0001 ENDOF
0010 OF PLOT0010 ENDOF
0011 OF PLOT0011 ENDOF
0100 OF PLOT0100 ENDOF
0101 OF PLOT0101 ENDOF
0110 OF PLOT0110 ENDOF
0111 OF PLOT0111 ENDOF
1000 OF PLOT1000 ENDOF
1001 OF PLOT1001 ENDOF
1010 OF PLOT1010 ENDOF
1011 OF PLOT1011 ENDOF
1100 OF PLOT1100 ENDOF
1101 OF PLOT1101 ENDOF
1110 OF PLOT1110 ENDOF
1111 OF PLOT1111 ENDOF
ENDCASE ;
: PUTXPLOTS ANCHO @ 4 / 1 + 1 DO PUTPLOTS POSX @
4 - POSX ! LOOP ;
: PUTYPLOTS ALTO @ 1 + 1 DO PUTXPLOTS POSY @
1 + POSY ! POSXF @ POSX ! LOOP ;
: PLOTSPRITE POSXI @ ANCHO @ + 4 - DUP POSX !
POSXF ! POSYI @ ALTO @ - POSY !
COLORSPR @ INK PUTYPLOTS ;


( PUTSPRITE: IMPRIME UN SPRITE MEDIANTE PLOTSPRITE )

: PUTSPRITE 0 COLORSPR ! SPRITE PLOTSPRITE ;

( GETSPRITE: BORRA EL SPRITE MEDIANTE PLOTSPRITE )

: GETSPRITE 7 COLORSPR ! SPRITE PLOTSPRITE ;

( MOVESPRITE: MUEVE EL SPRITE UN PIXEL A LA DERECHA )

: MOVESPRITE GETSPRITE POSXI @ 1 + POSXI ! PUTSPRITE ;


( DEMOSPRITE: PRUEBA DE MOVIMIENTO DEL SPRITE )

: DEMOSPRITE PUTSPRITE 20 1 DO MOVESPRITE LOOP ;



Hasta la próxima amigos!!!

[mcleod_ideafix]

Hola amigos, he descartado la idea de acceder directamente
a la memoria desde Forth para imprimir un sprite, porque para
acceder a ese nivel es preferible hacerlo desde el código máquina

¿En Forth no hay que se parezca a los punteros? No existen las palabras POKE o PEEK?
Si es que donde se ponga C...

alternativas he construido la palabra PLOTSPRITE, que imprime
un sprite en pantalla mediante la palabra PLOT

Ayyyy! Eso debe ser lento hasta la exasperación :O

Creo que tu única opción de acelerar el movimiento de sprites usando únicamente Forth, es que averigües cómo se puede leer y escribir en una posición de memoria determinada. De todas formas... qué quieres que te diga... en el Spectrum, la gestión de sprites es la candidata tradicional para hacerse en código máquina.

[Ecalius]

Hola de nuevo, os explico mi nueva experiencia con Forth!!!

He estado accediendo directamente a la memoria de pantalla del Spectrum, y utilizo unas formulas matemáticas que se ubican en la propia ROM, para calcular la dirección de pantalla que son:

1º Y=175-Y
2º Byte High=64+8*INT(Y/64)+Y( MOD 8 )
3º Byte Low=(32*INT(Y(MOD 64)/8))+INT(X/8)
4º Dirección Pantalla (X,Y)=(Byte High*256) +Byte Low

Por cierto, MOD es módulo, o el resto de una división, y el sistema de pantalla que utilizo, es el propio del basic del Spectrum, la coordenada X va de 0 a 255, y la coordenada Y de 0 a 175.

Aquí está el código Forth:

( PUTSPRITE: Imprime un sprite de 8x8 pixels )

0 VARIABLE DIRXY
0 VARIABLE XDER
0 VARIABLE YDER
0 VARIABLE YDER2
0 VARIABLE BYTETEMP
0 VARIABLE COORDX
0 VARIABLE COORDY

: SPRITE 255 255 255 255 255 255 255 255 ;

: 175-Y 175 SWAP - ;
: ROTARXDER SWAP DUP 8 MOD XDER ! SWAP ;
: ROTARYDER DUP 8 MOD YDER ! ;
: HIGHBYTE DUP 64 / 8 * 64 + YDER @ + DIRXY 1+ C! ;
: ROTARYDER2 64 MOD YDER2 ! ;
: LOWBYTE 8 / YDER2 @ 8 / 32 * + DIRXY C! ;
: CALCDIR 175-Y ROTARXDER ROTARYDER HIGHBYTE ROTARYDER2 LOWBYTE ;

: COLOCADATO XDER @ 0= IF DIRXY @ C! ELSE
XDER @ 0 DO BYTETEMP @ 2 / BYTETEMP !
DUP 2 MOD 1 = IF 128 BYTETEMP @ + BYTETEMP !
ENDIF 2 / LOOP DIRXY @ C@ OR DIRXY @ C!
BYTETEMP @ DIRXY @ 1+ C@ OR DIRXY @ 1+ C!
ENDIF 0 BYTETEMP ! ;

: PUTSPRITE 8 - 2DUP COORDY ! COORDX ! 8 0 DO CALCDIR
COLOCADATO COORDY @ 1+ COORDY ! COORDX @
COORDY @ LOOP ;

Para utilizar PUTSPRITE se requiere el sprite en la pila, y las coordenadas X, e Y también, así que pondriamos en el intérprete de Forth:

SPRITE 100 90
PUTSPRITE

Y seguidamente aparecerá un sprite de 8x8 en las coordenadas X igual a 100, e Y igual a 90.

Bueno, después de haber echo esta prueba, también ha sido un fracaso, por el mismo tema, la velocidad. La rutina compilada de Forth, no es suficiente rápida para mostrar sprites, para ello necesitaría el código máquina, como bien sabeis todos. Pero yo quiero hacer el juego sólo en Forth, y no utilizar
lenguaje máquina, por lo que me dedicaré exclusivamente a él, asi que emplearé UDGs e intentaré crear ilusión en el movimiento.

Bueno, hasta la próxima!!!

[mcleod_ideafix]

Puedes acelerar la cosa si en lugar de tener que calcular la dirección de cada scan, la tienes precalculada. Es decir, tener una tabla de 192 elementos que representan cada uno a una coordenada Y. Cada elemento es un valor de 16 bits que indica la dirección, en pantalla para el pixel cuya coordenada X es 0, y cuya coordenada Y es el número de elemento.

Otra cosa: la resta del principio: 175-Y, creo que sobra. Sencillamente, considera que tu origen de coordenadas está en la esquina superior izquierda, y de ahí hacia abajo. No tiene por qué remedar al sistema de coordenadas del BASIC.

Con una rutina PLOT que se basa en tener precalculadas las direcciones de las coordenadas Y, el benchmark de antes se me queda en 3,32 segundos para el bucle que pinta 256x176 puntos en pantalla. Recuerda que la rutina original, con el PLOT del BASIC, me tardaba 7,32 segundos.

[Ecalius]

Muy buenas, basandome en las fórmulas anteriores para calcular la dirección
de pantalla, y esta vez sin la resta inicial Y=175-Y, el punto de origen ini-
cial X=0 y Y=0 está en la esquina superior izquierda, y la anchura máxima de
X es 255, y la altura máxima de Y es 191. He creado un nuevo código Forth de
la palabra PUTSPRITE, algo más optimizado, y también una tabla precálculo de
las lineas Y cuando X=0, todo ello para mejorar la velocidad, y sobre todo
para probar cualquier solución posible, antes de tocar el código máquina.

Este es el nuevo código:

( PUTSPRITE: IMPRIME UN SPRITE )

0 VARIABLE COORDX
0 VARIABLE COORDY
0 VARIABLE BYTEMP
0 VARIABLE TABDIR 382 ALLOT

: SPRITE 255 255 255 255 255 255 255 255 ;

: BYTL 64 MOD 8 / 32 * SWAP 8 / + ;
: BYTH DUP 64 / 8 * 64 + SWAP 8 MOD + ;
: XYADRESS DUP BYTH 256 * >R BYTL R> + ;
: CALCDIR OVER 8 MOD ROT ROT XYADRESS ;
: SETOCTETO >R DUP 0= IF DROP R> C! ELSE
0 DO 2 /MOD SWAP 128 * BYTEMP @ 2 / + BYTEMP ! LOOP
R C@ OR R C! BYTEMP @ R 1+ C@ OR R> 1+ C! 0 BYTEMP !
ENDIF ;
: PRECALCDIRY 191 0 DO 0 I CALCDIR TABDIR I 2 * + ! DROP LOOP ;
: CALCDESPX 8 /MOD ;
: BUSCADIRXY 2 * TABDIR + @ SWAP CALCDESPX ROT + ;
: PUTSPRITE 8 + 2DUP COORDY ! COORDX ! 8 0 DO BUSCADIRXY
SETOCTETO COORDY @ 1 - COORDY ! COORDX @ COORDY @ LOOP ;


Bien, antes de utilizar la palabra PUTSPRITE, hemos de crear la tabla pre-
calculada de las lineas Y en TABDIR, es decir, las direcciones de pantalla
cuando X=0, así que para imprimir el sprite en X=100 e Y=90 habría que hacer
la primera vez:

PRECALCDIRY

Y después....

SPRITE 100 90

PUTSPRITE

La verdad es que ha sido otro pequeño fracaso en términos de velocidad, pero
no en código, ya que he ido progresando al utilizar nuevas palabras Forth.
La impresión de sprite no es suficientemente rápido, así que tengo que desarrollar
la palabra PUTSPRITE en código máquina. Ya he averiguado que la palabra C, permite
introducir códigos en la definición de una palabra, pero exactamente no sé cómo
utilizarla. Por otro lado, podría no utilizar C.M. y usar UDGs, cómo dije muy
anteriormente, y crear una animación simulada de movimiento "pixeliano".

Bueno, eso es todo por ahora.

[Ecalius]

Hola compis!!!

Tengo un problema con Forth, y es que para poder hacer un programa pequeño,
digamos de unas 150 lineas, el editor lo admite de una tirada con la orden
LOADT y después 1 LOAD para compilar las palabras definidas, pero si es un
programa que va ocupar mas de 150 lineas, y ASTEROID es uno de ellos, debemos
hacer lo mismo por cada "set" de manera manual, y vigilar el cassete que
habría que pararlo hasta que se acabara de compilar las anteriores defini-
ciones. Imaginad que engorro para el usuario cuando quiera cargar el juego.

En basic es fácil, un simple cargador:
10 LOAD "" SCREEN$
20 LOAD "" CODE
30 RANDOMIZE USR lo que sea
En Forth:
1. Cargas el compilador de forth
2. Tecleas LOADT y enter.
3. Tecleas 1 LOAD para compilar, y te esperas..... ( Previamente
paras el cassete ).

4. Vuelves al paso 2 hasta que se acaben los "sets"
5. Ejecutas la palabra principal GAME, por ejemplo, para empezar
a jugar.

He buscado otros Forths, por si había otro sistema, o si el mismo Forth
era capaz de dejar el código del juego en la cinta, para que pudiera cargarlo
con un simple LOAD "" CODE, pero nada de nada ;-( .

Así que en vista del asunto, y después de haber experimentado con él, veo
mejor desarrollar mi juego en BASIC, y ver de lo que és capaz este lenguaje,
y para mejorar su velocidad emplearé algún buen compilador que haya por los
alrededores, je je!!!

Hasta pronto!!!

[mcleod_ideafix]

¿Y un compìlador cruzado que genere código para el Z80? Así podrías programar y compilar en el PC.
Por otra parte... cuando el usuario quiera jugar no debería tener que cargar antes el compilador de Forth. Si es de verdad un compilador, el código generado debería poder ejecutarse de forma independiente a que el compilador esté presente. En las instrucciones quizás diga a partir de qué dirección de memoria se guarda el código generado, con lo que una vez compilador vuelves a BASIC y lo grabas con SAVE...CODE.

[Z80user]

http://z80user.zobyhost.com/foro/ -> Spectrum -> Graficos -> Direccion en pantalla apartir de las coordenadas

Hay tienes ejemplos de como apuntar en la pantalla, es un fusilamiento del documento que hizo Metalbrain para la revista, pero solo el codigo, y con un resumen de tamaño de memoria y tiempo en realizar la operacion, si quieres la documentacion http://www.speccy.org/magazinezx/06/ensamblador.html

Respecto a lo de cargar un juego, si tienes un SAVE "" CODE 32768,32768 al final y lo cargas con LOAD CODE 32768, sin tener que hacer las recargas de memoria, y sus pausas, creo que mejor, asi ahorras tiempo de carga, yo por como esta implementada la memoria en los 128K pienso hacer micro pausaspara ir moviendo la memoria de 8KB en 8KB, como la memoria que hay entre 32K y 48K es siempre rapida, cargar hay lo que se carge de cinta y escribirlo posteriormente en donde deba estar, y la penultima vez, autopisarse la rutina de carga

[tachbach]

Hermoso post. al final en que quedo el asteroids en FORTH? llegue aqui buscando informacion sobre White Lightning de OASIS SOFTWARE (un pack de 2 casetes y dos libritos que mi padre una vez pidio prestado, me fotocopio' y grabo en un caset en el anio 1992) ' http://www.crashonline.org.uk/08/whitelig.htm '. Recuerdo que utilizaba como lenguaje el SPECTRA-FORTH (asi decia el librito), en el cual lo maximo que hice fue 4 scrolls simultaneos en diferentes areas de la pantalla de mi speccy, el primer scroll desplazaba de a 1pixel a la izquierda, el segundo 2 pixel a la derecha, el tercero de a 4 pixel hacia arriba y el cuarto 4 pixel hacia abajo, todo al unísono y corría rapidísimo mientras editaba texto del lenguaje en la parte inferior de la pantalla. Este FORTH esta' orientado sobretodo al manejo de sprites y manejo de pantalla (lo que logro recordar), podria ser muy util para el Asteroids. La programación me esta llamando cual fantasma en el espejo incitandome lo atraviese para nunca volver a esta dimensión. La semana pasada me introduje en HTML, Hace 2 dias con uno de mis hermanos creamos un arkanoid en C++ (la letra 'O' es la pelotita y 5 '=' la barra) bastante amateur pero bien para ser mi primer programación en este lenguaje. Boriel, no se por que no he podido compilar con tu ZX BASIC, no encuentro la manera de generar un archivo a partir del texto, si pudieras explicarme agradecidisisimo.
Nathan, la maniana del sabado me di una paliza de juegos mojonos, felicitaciones por sus trabajos. saludos.