Crónica 46 RU MSX de Barcelona

Página 7/8
1 | 2 | 3 | 4 | 5 | 6 | | 8

Por Kai Magazine

Paragon (1303)

Imagen del Kai Magazine

01-01-2015, 18:36

Gracias Oskar Smile

El Turbo Basic (o Basic Kun, fuera de europa) es un compilador de basic en tiempo real:
Lo que hace es cojer un trozo de un listado de basic (llamado turbo-bloque), y lo pre-interpreta (se lo pre-lee y lo convierte un un lenguaje mas ameno y rapido de ejecutar).
Solo hay unos cuantos comandos soportados por Turbo basic. No hay acceso a disco y todas las funciones CALL (para invocar a drivers o programas externos al basic o turbo-basic).
Ademas la memoria de los turbo-bloques es muy pequeña. La idea principal del turbo-basic era acelerar ciertas rutinas o subrutinas de basic para que fueran mas rapidas.

Requiere cierto ingenio para hacer caber todo un motor como el del nuts o no name en un solo turbo bloque (ya que si fuese en diversos turbo bloques, dado que tarda unos segundos en compilar, los juegos irian a 1 fotograma cada 5 o 6 segundos).
A base de mucha optimizacion y de dejar muchos bugs sin resolver conseguí hacer caber un motor de juego en un solo turbo bloque.
El resultado, es un programa que corre casi como en ensablador, pero que se tarda muchisimo menos (pero muchisimo menos) en programar.
Esa es la gran ventaja del turbo basic, que se puede crear codigo a gran velocidad.
Puedo crear un listado que en ensamblador se tardaria meses, en solo una semana.
Y poder crear rapido y sin un esfuerzo desmesurado es lo que da pie a que se puedan hacer grandes producciones que de otra manera serian inviables por el excesivo consumo de tiempo.

Feliz año nuevo!

Por oskar666

Champion (357)

Imagen del oskar666

01-01-2015, 22:13

Muy interesante, la verdad es que vuestros juegos se ven geniales, ademas parece que a una velocidad muy muy buena Wink

Por AxelStone

Prophet (2701)

Imagen del AxelStone

01-01-2015, 23:29

A ver señores, no quiero tirar piedras sobre el turbo basic ni mucho menos, pero seamos conscientes que no vamos a tener el rendimiento del ensamblador por mucho empeño y optimización que se haga. Una diferencia fundamental entre el turbo basic y el ASM es que en el primero la rutina de pintado de pantalla es bloqueante, es decir, la CPU no puede hacer nada mientras se dibuja la pantalla. En pocas palabras no paraleliza correctamente CPU y VDP por lo que no aprovecha esta gran ventaja del hardware MSX. La gran ventaja del ASM es que paraleliza ambos a la perfección de modo que mientras el VDP está dibujando la CPU está haciendo todo lo demás: calcular posiciones de los sprites, IA, etc.

En la práctica si hay diferencia entre ambos pero el turbo basic tiene una gran ventaja: puede integrar fragmentos de código en ensamblador. Con esto las rutinas críticas como el dibujado de pantalla podría delegarse en funciones de ensamblador evitando ese efecto bloqueo del turbo basic. Como bien dice Kai lo bueno del Basic es que es un lenguaje muy sencillo que permite generar código a todo trapo, y eso al final redunda en producciones más elaboradas que las que se afrontan íntegramente en ensamblador.

Por Kai Magazine

Paragon (1303)

Imagen del Kai Magazine

02-01-2015, 00:09

Hola Axel, te aclaro un temilla:
El turbo basic si que tiene los 2 modos. Si no nuestros juegos irian mucho mas lentos.
Si en turbo basic se hace un copy que la coordenada de origen X sea par, la coordenada de origen de volumen sea inpar, y la coordenada de destino sea par, el turbo basic usa el modo paralelo.
Para entendernos:
Copy(X origen,Y origen)-(X volumen,Y volumen),1 to (X destino,Y destino),0
Por ejemplo, si en turbo basic hacemos este copy se usará el modo hardware que trabaja en paralelo:
Copy(20,11)-(49,53),1 to (40,13),0

Porque X origen es 20 (par), X volumen es 49 (impar), y X destino es 40 (par)

Este copy usará el modo hardware en paralelo igual que en ensamblador.

Si esta norma se rompe, el copy se hace por software siendo muchisimo mas lento y bloqueando todos los procesos.

De hecho a veces tengo que poner un Pset (0,0),0 antes del set page, para que acabe de dibujar el fotograma antes de mostrarlo, ya que efectivamente trabaja en paralelo, y tengo que coordinar que ambos vayan al mismo tiempo.

Este es un truquillo que descubrí por mi mismo hace 20 años y gracias a el consigo velocidades en turbo-basic similares a ensamblador.

Por otra parte, no digo que turbo basic sea sencillo, tiene muchas restricciones, condiciones y trucos, que otros lenguajes no tienen.
Lo que digo es que se puede programar muy rapido ya que no hace falta compilar todo el programa o proyecto para ejecutarlo y testear cada linea de codigo que integramos.
Tambien digo que se pueden conseguir resultados excelentes, si se conocen sus limitaciones, y como superarlas.

Por Kai Magazine

Paragon (1303)

Imagen del Kai Magazine

02-01-2015, 00:23

carga el turbo basic y prueba esto:

10 screen5
20 set page,1 : bload"imagen.sr5",s
30 call turbo on
40 for i = 0 to 200 step 2
50 Copy(i,0)-(255,211),1 to (0,0),0
60 next i
70 call turbo off

en lugar de "imagen.sr5" pon el nombre de cualquier imagen en screen 5 a pantalla cmpleta que tengas.

Veras que este modo copia en modo hardware.

Ahora haz lo mismo pero cambia el 255 por 254, rompiendo la regla del modo hardware.
Veras que va 6 o 7 veces mas lento. Es el modo software.

Ahora haz este listado (con el 255) en ensamblador y compara velocidades, y veras que va exactamente igual.

Ademas si añades algun proceso matematico justo despues del copy, veras que no se relentiza porque lo hace mientras se está efectuando el copy por hardware, igual que en ensamblador.

Saludos.

Por Guillian

Prophet (3232)

Imagen del Guillian

02-01-2015, 11:01

Un pequeño apunte sobre la velocidad de copiado del VDP y el proceso en paralelo: me temo que el Kun Basic o Turbo Basic no puede hacer otra cosa mientras está ejecutando un comando el VDP.

Ahora no recuerdo si existía algún modificador como el #C+ o el #I que cambiara esto. Pero no me suena.
La solución sería ejecutar esos pintados llamando a una rutina en código máquina y comprobando si el VDP ha terminado el comando anterior antes de mandar uno nuevo. Así mientras el VDP está haciendo una cosa, el Z80 podría estar haciendo otra.

Las diferencias de velocidad al hacer el COPY se debe a que usa dos comandos distintos del VDP:
- HMMM (High speed move VRAM to VRAM)
- LMMM (Logical move VRAM to VRAM)

El primero trabaja por bytes y necesita, como ha explicado Kai, que las coordenadas X de origen, destino y el número de puntos a copiar sean pares. Esto se debe a que en SCREEN 5 cada byte contiene dos puntos de la pantalla (4 bits - 16 colores) cada uno.

El segundo trabaja bit a bit, lo que le permite copiar solo medio byte y aplicar operaciones lógicas.
Si en el ejemplo que puso KAI añadís un ",XOR" al final del COPY veréis que la velocidad es igual de lenta que usando coordenadas impares.

Otra forma de probar esto que digo es usando SCREEN 8, donde cada byte representa un punto (8 bits = 256 colores). Ahí veréis que da igual usar coordenadas pares que impares. En ambos casos usará HMMM. Pero si usáis una operación lógica irá más lento al tener que usar LMMM.

Por AxelStone

Prophet (2701)

Imagen del AxelStone

02-01-2015, 17:10

Guillian wrote:

Un pequeño apunte sobre la velocidad de copiado del VDP y el proceso en paralelo: me temo que el Kun Basic o Turbo Basic no puede hacer otra cosa mientras está ejecutando un comando el VDP.

Justo a eso me refiero: la CPU debe esperar al VDP. A ver no soy gurú del MSX, pero de las pocas cosas que sé esta es una de ellas. El turbo basic donde destaca especialmente es ejecutado en un turbo R, ya que la CPU es tan rápida que no pasa nada por esperar al VDP, sigue funcionando a todo trapo. Algo similar pasa con los juegos de MicroCabin como el Gazzel, que la diferencia entre MSX2 y turbo R es muy grande, si no me equivoco deben estar programados en C o en Basic Kun.

Aún así insisto, la solución es relativamente asequible, y pasa por delegar el dibujado de pantalla en un rutina de ensamblador de forma que la CPU pueda estar trabajando mientras tanto. En un turbo R igual no se nota demasiado, en un MSX2 la diferencia si sería más apreciable.

Por Kai Magazine

Paragon (1303)

Imagen del Kai Magazine

02-01-2015, 17:41

Hola, lo que he explicado de los 2 modos de copiado del turbo basic no me lo he inventado ni es una hipotesis.
Lo tengo mas que comprobado.
De hecho, como ya he dicho, cuando uso el modo hardware tengo que poner una instruccion grafica antes de cambiar el de pagina (doble buffer) para que no muestre el siguiente fotograma antes de tiempo.
De ello, yo personalmente, no tengo la menor duda: el modo de copiado por hardware de turbo basic trabaja en paralelo con la cpu.
Podria poner listados de ejemplo para que lo compruebe quien quiera, pero realmente el consumo de tiempo y el interes que tengo en convencer a quien no esté de acuerdo, no me compensa.
Cada uno es libre de pensar lo que quiera en base a lo que sabe.

Por otra parte, los juegos de micro cabin NO estan programados en turbo-basic. Eso es un hecho bien conocido.

Finalmente, si podeis hacer una rutina de copiado en ASM que sea compatible con tubo basic y el driver de moonblaster, y que no requiera un msx con mas de 64k y no me reduzca la memoria de basic/turbo-basic, estaré encantado de probarla y hacer tests de velocidad.

Saludos.

Por Guillian

Prophet (3232)

Imagen del Guillian

02-01-2015, 18:49

Si tienes que poner una instrucción gráfica para que no muestre el siguiente fotograma antes de tiempo, entonces significa que sí está haciendo dos cosas en paralelo. Hace años que no toco el Kun Basic (desde aquel minijuego/RPG tipo Illusion City) y no recuerdo los detalles.
Por otra parte es lógico que lo haga así, si incluso el BASIC normal permite seguir ejecutando instrucciones mientras el VDP está haciendo otra cosa.

Pero lo que sí te aseguro es que no hay un modo hardware y software de copiado. Y la diferencia de velocidades se debe a lo que he explicado en mi anterior mensaje (usar HMMM o LMMM). Y en ambos casos tendrás que poner una instrucción gráfica para que espere a que termine el comando, sino el flujo del programa continuará (trabajará en paralelo).

Por AxelStone

Prophet (2701)

Imagen del AxelStone

02-01-2015, 21:59

Kai Magazine wrote:

Podria poner listados de ejemplo para que lo compruebe quien quiera, pero realmente el consumo de tiempo y el interes que tengo en convencer a quien no esté de acuerdo, no me compensa.
Cada uno es libre de pensar lo que quiera en base a lo que sabe.

A ver no nos enfademos, te aseguro que yo pensaba lo mismo que Guillian, que el turbo basic no puede simultaneizar ambos. Sin embargo tras lo que dices ya me creas la duda, así que voy a intentar hacer una pequeña rutina en ASM que haga uso intensivo de la CPU y el VDP al mismo tiempo y probamos su equivalente en turbo basic ¿te parece?

Vamos a ser constructivos Kai, el tiempo invertido sí puede merecer la pena en tanto en cuanto muchos de los usuarios activos de MSX son desarrolladores y son cosas como estas las que permiten decantarte por un camino u otro. Créeme, no tengo interés alguno en difamar turbo basic (¡soy programador basic de toda la vida!) y si un pequeño experimento permite comprobar que el turbo basic a día de hoy está a la altura del ASM me das una alegría del 15. A mí y a cualquiera que pretenda empezar algo en MSX Wink

Venga en cuanto tenga algo te aviso y cuelgo aquí el fuente.

P.D.: mientras tanto traslado la pregunta al foro Development, creo que es un tema muy interesante para los desarrolladores, pásate por allí Kai por favor y comenta tus experimentos Smile

Página 7/8
1 | 2 | 3 | 4 | 5 | 6 | | 8