ZX Spectrum: escribir en pantalla con POKE

[Bubu]

No, AjAJAJAJ, para nada loco, haces bien en decirlo, pero ese RANDOMIZE te podría servir para muchas cosas a la vez: dibujar sprites 16x16 a color p.ej.

[explorer]

Hummm... teniendo soluciones como el ZXBasic comentado antes, yo creo que ya no tiene sentido hacer programas en el BASIC del Spectrum. Simplemente, haces el programa en ZXBasic, lo compilas y ya tienes el programa ejecutable. Casi ni necesitas hacer nada en el ensamblador. Y si lo necesitas, trae los comandos ASM .. END ASM que permiten escribir ensamblador, así que al final lo tienes todo para hacer programas interesantes.

Código: Seleccionar todo

FUNCTION FASTCALL whatLetter (A AS UBYTE) AS UBYTE
   ASM
             JP START
   DATA:     DEFB "A Man, A Plan, A Canal, Panama"
   START:    LD HL,DATA
             LD E, A
             LD D, 0
             ADD HL, DE
             LD A, (HL)
   END ASM
END FUNCTION

Desde luego, el BASIC no permite hacer las diabluras que tienen otros lenguajes, como el C++, el más utilizado para hacer juegos, pero su curva de aprendizaje es mucho más amable.

[Bubu]

Yo debo estar como una cabra, porque pogramo direstamente en ensamblador, una a una las instrucciones, AjJAjAjAJA. Me gustaría un día catar el Z88DK ese, pero es que me temo que el resultado no va a ser de mi agrado... ya iré viendo.

Ah, se me olvida decir, que él no quiere usar compiladores ni cosas raras, porque lo quiere pogramar direstamente en el ordeñador, no en un PC. Por eso tié que usar BASIC sí o sí (aunque haya otras soluciones, como cargar otro intérprete, pero esto ya es demasiado exótico)

[BlackHole]

La rutina de PRINT de la ROM no es que sea la más optimizada del mundo, porque tiene que ver muchas variables: el stream a pintar (0 pantalla superior, 1 pantalla inferior, 4 impresora, etc.) tiene que comprobar las coordenadas y traducirlas al particular sistema de video-RAM del Spectrum, tiene que comprobar la variable del sistema de la tinta y del papel en curso que tenemos por defecto, tiene que comprobar si está activado el modo OVER para hacer un OR con los pixeles previos, en fin... mil y una cosas.

También hay que tener en cuenta que imprimir 2000 números no es una buena prueba de la rapidez de un código compilado, porque hay 22 líneas (24 si se dibuja en toda la pantalla) y entonces tendría que hacer scroll 1976 veces. Pero es que el scroll mueve TODA la pantalla, casi 7k de datos cada vez. No es la prueba más adecuada para ello, en mi humilde opinión.

[Bubu]

Pero sí sería una buena prueba de velocidad si hace el PRINT AT siempre en las mismas coordenadas.

[explorer]

Yo debo estar como una cabra, porque pogramo direstamente en ensamblador, una a una las instrucciones, AjJAjAjAJA. Me gustaría un día catar el Z88DK ese, pero es que me temo que el resultado no va a ser de mi agrado... ya iré viendo.

Puedes hacer también una cosa híbrida: haces el juego en C, lo compilas, y miras el listado en ensamblador generado, y lo conviertes a programar ensamblador y lo dejas a tu gusto, pero lo más rollo, que es la inteligencia del programa, los menús, las pantallas iniciales, ya la tienes hecho.

Yo solía hacer algo parecido: escribía el programa en C o C++. Miraba el resultado, y buscaba aquellas partes más lentas, y las reescribía en ensamblador, con inline __asm() dentro del propio programa, o como archivo .asm y luego usaba el enlazador para unir todas las partes.

Pero todo esto... ya es tecnología antigua...

Lo más molón es poder escribir/programar directamente en la memoria de la máquina virtual del emulador, mientras está funcionando, para ver los cambios de forma instantánea.

Pero hay muy pocos emuladores que permitan hacerlo. Creo que solo conozco al Vice del C64.

[oscarbraindead]

La idea era usar el zxuno go+ directamente, de ahí lo de usar basic. Aunque después de las pruebas usaré el compilador hisoft basic, que lo puedo usar en el zxuno sin problema. No es eficiente ni práctico comparado con usar z88dk o el compilador de boriel en un pc... pero es por dar uso al cacharro.
Para la prueba de "rendimiento" compilado/interpretado usé print at, para ahorrar el scroll y ambos usando, como es lógico, el mismo código... casi un 40% de mejora en la prueba. He probado también el código de berzerk que comencé, movimiento básico del jugador con kempstom, y la diferencia es importante. Técnicamente se puede hacer, a ver si yo soy capaz

Gracias a todos por las ideas y conocimientos vertidos!

[Bubu]

Pues nada y... ¡¡me encantaría un pantallazo cuando se pueda ver algo!!

[explorer]

Lo más molón es poder escribir/programar directamente en la memoria de la máquina virtual del emulador, mientras está funcionando, para ver los cambios de forma instantánea.

Pero hay muy pocos emuladores que permitan hacerlo. Creo que solo conozco al Vice del C64.

Vaya... acabo de encontrar uno para la Sega Genesis. Lo interesante empieza en el momento 07:54

[Bubu]

JAjAjAjAjAJA ¡qué bueno! Estas cosas las hacía yo en Spectrum, pero tenía que poner un punto de ruptura, modificar el pograma, y continuar con la ejecución. Pero es más, con el emulador pausado en el punto de ruptura, podía hacer p.ej.

LD A, 255
LD (16384), A

y efestivamente salía una rayita negra arriba. Esto ayuda lo más grande, lo que no recuerdo es con qué emulador era, quizás EmuZWin.