Programando en C64 real

[SingletonJohn]

@SingletonJohn ya he visto que tus juegos van apareciendo en las descargas que acompañan las nuevas Microhobby. Felicidades !

La verdad es que me hace ilusión aparecer en MH, aunque sea por una pichada!
Las conversiones las iba a hacer de todas todas para practicar un poco el BASIC del Commodore (con el que nunca me había puesto en serio).

Jajjajaaj...y hace un par de días, intentando dibujar un Submarino en ASCII, me enteré de una cosa del Charset que seguro que sabéis todos: la línea vertical de 1 pixel tiene en realidad 2 PIXELS, por lo que los caracteres CBM+M y CBM+N SON IGUALES (también ocurre con CBM+G y CBM+H)

Y yo como un idiota todo rayado porque pensaba que mi cacharro tenía algo roto.....jajajaja...al final no pinté ni submarino ni nada

[SingletonJohn]

Hola a todos!

Os dejo la versión C64 del programa Jason de MSX Basic de la MicroHobby

[SingletonJohn]

Este proyecto tiene varias cosas interesantes:
- Se usan sprites que se mueven por basic, pokeando al VIC. La verdad es que me ha sorprendido que el  juego NO ES MUCHO MAS lento de esta manera que moviendo tiles. Lo que igual pierdes haciendo pokes, lo ganas por otro lado, ya que no tienes que borrar el personaje en el fotograma anterior
- Al usarse sprites y querer usar la fuente estándar, la pantalla tiene que moverse al banco 2 de la RAM (desde el punto de vista del VIC). Podría haber movido la memoria del basic hacia adelante (HIMEM), pero me parecía más complicado y quería tener todo el programa en un bloque. De esta manera, el menú principal se muestra en $0400. El registro de la pantalla no se toca, ya que la posición de la pantalla pasa a ser $8400 en el banco 2, y las definiciones de los sprites están de $8800 en adelante. En el banco 2 está cableado el charset en las mismas posiciones que en el Banco 0, por lo que este registro del VIC no se toca tampoco.
-Sé que es totalmente ineficiente definir DATAS con la definición de los gráficos para pokear en la RAM (pierdes el doble de espacio), pero es por conservar el espíritu de los listado de la MH. Eso si, el "pokeo" sólo tiene lugar en el arranque, ya que tarda lo suyo. Durante el proceso apago el renderizado de pantalla para que se acelere todo un poco.
-Ya que el menú y la pantalla de juego están en lugares diferentes, intenté evitar su repintado en sucesivas partidas (como evito el pokeo)....pero me dió algo de pereza por culpa de la ColorRAM, que sí es compartida ya que es única.....hice la optimización, pero después me di cuenta de que no se repintaba bien porque se quedaba la ColorRam de la pantalla de juego y se aplicaba al menú....esto se lo dejo de pasatiempo al que quiera divertirse un rato

[SingletonJohn]

En el próximo proyecto, Rally, el clásico juego de basic de scroll vertical, intentaré hacer el scroll suave por hardware, a ver cómo resulta. Supongo que al ser el BASIC tan lento tendré que usar un doble buffer (el viejo truco de ir alternando dos pantallas) para que no me pille el raster...en fin ya se verá

Saludos y que lo disfrutéis

[SingletonJohn]

Ah! jejejeje......un último detalle.
Si en el Jason interrumpís el juego en la pantalla de juego y le dáis a stop+restore, veréis la pantalla del menú y PARECE que el C64 crashea. Lo que pasa es que el VIC apunta a la pantalla en $0400, pero el resto del hardware NO SE ENTERA. Así que a ciegas, teclead "POKE648,4" y aparecerá el cursor y el READY. Esto es porque en la dirección $288 el firmware guarda el HighByte de la posición de la pantalla, de manera independiente al VIC, y es la dirección de referencia para todos los cálculos de la posición del cursor.

[Bieno]

Fantástico. Me encantan estos "ports" y como te las ingenias para saltarte las limitaciones del Basic del c64

[SingletonJohn]

Gracias @Bieno ! Estas cosas me divierten bastante y aprendo el funcionamiento del C64 en Basic, que es muy interesante

Reconozco que no me he empleado "a fondo", ya que la velocidad del juego en c64 es muy inferior a la de MSX o Spectrum, debido a la velocidad superior del Z80

Tengo que explorar a usar subrutinas de la ROM (esta solución no me gusta mucho, ya que el listado en basic queda indescifrable del todo para un profano) o a intentar puentear el Wedge, que sé que acelera bastante la ejecución

Tengo aún esto pendiente de explorar en sucesivas entregas.....otras opciones serían definir subrutinas en  Código máquina en los datas, o definir la subrutina custom que te deja el firmware de opción....

Creo que la más elegante es la de puentear el Wedge...usar subrutinas en DATAS es magia negra para la gente que está aprendiendo BASIC

[SingletonJohn]

Por cierto....estoy un poco harto de oir ese mantra (que algunos repiten como loros) de que el 6510 es en realidad más rápido que el Z80 que por su pipeline, que por su eficiencia, bla bla bla

Cierto que el 6502 es más eficiente y tarda menos ciclos en hacer ciertas cosas y que el acceso a la página cero es rápido, pero un ciclo de 65110 es cada 1/(10^6) segundos y uno de Z80 es cada 1/(3,5*10^6)segundos....vamos que o se me escapa algo o comparar el número de ciclos es estúpido. Habrá que comparar tiempos....en fin

[josepzin]

Sin saber del tema, yo creo que las características optimizadas del 6510 hace que ese 1Mhz esté muy bien aprovechado. Hasta ahí llego.

En los juegos, los de Z80 que necesitan potencia bruta (los 3D, Filmation...) tengo entendido que los de Z80 van mejor pero estoy tocando de sinver, que tampoco me puse a hacer comparativas

[SingletonJohn]

Viviéndolo en carnes (he programado ensamblador Z80 de spectrum y sobre todo 6510 de commodore y tb basic de ambos) he de decir que por fuerza bruta gana el z80 claramente. el 6510 tiene 1 millón de ciclos por segundo frente a los 3,5 millones de ciclos por segundo del Z80. Con lo cual, aunque el 65110 tarde en una operación 3 ciclos y el z80 5, los ciclos del Z80 son más rápidos....no hay que ver ciclos, hay que ver tiempo que tarda en hacer operaciones, ya que los ciclos NO SON COMPARABLES...tampoco el acceso a RAM de página cero del 6510, que es más rápido....medir el tiempo es la clave.....y el Z80 es más rápido. La clave del C64 son el chip de sonido (que tiene vida al margen de la CPU y la libera un poco)y las posibilidades del chip gráfico (sprites, multiplexing, scroll, etc). Si prescindes de todas esas ayudas y te pones a programar el C64 como si fuera un Spectrum (brute force 100%), pues el 6510 iría echando el bofe. Joer! ya le pasaba esto al MSX y sus portacos desde spectrum, y eso que el procesador del MSX es el mismo que el del spectrum

[josepzin]

La comparación tiene varios frentes, por ejemplo:

¿Movemos sprites sobre un fondo con scroll fino y música? el 64 con sus chips de apoyo lo hace sin despeinarse, el Z80 según en qué equipo esté (Spectrum, MSX, CPC) lo hará de distintas maneras y seguramente peor.

¿Hacemos un filmation o juego 3D que es potencia bruta? el Z80 gana de lejos en cualquiera de las otras plataformas (no sé el MSX, que el video es medio especialito y no sé si puede hacer ciertas cosas)

Es un tema interesante para debatir sin pasiones!

[SingletonJohn]

Más que filmation, Freescape o similar. Filmation no deja de ser algo plano con sprites y movimiento de varios pixeles a bloque....otra cosa es calcular una vista 3d en cada frame.

Tb cuando se compara un Z80 con un 65xx normalmente se olvida de que el z80 tiene más registros y registros (no se cómo llamarlos, híbridos??) que pueden ser o dos de 8 bits o uno de 16 bits. EL registro HL se comporta como un puntero, etc, etc etc

Ya sé que la página cero se puede usar como si fueran registros....pero si usas el firmware, la página cero está totalmente ocupada (excepto 4/8 bytes)....en fin, las debilidades de uno son las fortalezas de otro

[SingletonJohn]

Ya he empezado a trabajar en el Rally
Es un juego clásico de Basic de Spectrum: se definen mediante datas y pokes las 24 definiciones de caracteres custom 8x8 que permite el Spectrum y ahí se definen los tiles de todos los gráficos (algunos son de 2x2 tiles como el coche, árbol, meta...y otros de 1x1).
El coche se mueve de izquierda a derecha en la fila 0 (en saltos de 8 pixels) y en cada frame se detecta ANTES DE MOVERSE si el coche va a invadir una casilla de pantalla con el caracter ":", lo que supone el fin de partida. El coche no se borra, ya que en cada ciclo del bucle principal se repinta toda la pantalla haciendo PRINT en la fila inferior de la pantalla, lo que produce un scroll de 8 pixels automático y hacia arriba. El coche se pinta después de todo esto, con un simple PRINT AT OVER
Mi intención es que el movimiento sea todo lo suave que sea posible, por lo que el coche lo he convertido en un Sprite para que sea todo más cómodo (y que si es posible, el movimiento sea suave). Como el C64 no tiene posibilidad de custom chars, no me queda otra que definir un custom charset

[SingletonJohn]

Al igual que en proyecto anterior (el Jason) dejo el menu principal en el banco cero (pantalla en +$400, charset APARENTEMENTE en +$1000 por el tema del cableado), el inicio del basic en $800.
Para el juego, como necesito usar el custom charset y no quiero pisar el basic y tener espacio para charset y el gráfico del coche, pongo VIC en banco 2(pantalla en +$400,  definiciones de sprites en +$800 y charset en +$2000 para evitar la influencia del cableado). Voy a mantener el tema del scroll como en spectrum, con el scroll automático que se produce al imprimir en la línea 24, pero lo haré cada 8 ciclos del bucle principal, ya que en cada ciclo, usaré el scroll hardware para mover 1 pixel).
En principio voy a intentar evitar el doble buffer de pantalla para no complicarlo mucho (lo usaré sólo si hay mucho parpadeo). Como uso el Scroll hardware, reduciré el número de líneas visibles para tapar el "truco" (lo clásico en estos menesteres)

[SingletonJohn]

Es muy posible que aparezca algún parpadeo y glitching, ya que el scroll es de abajo hacia arriba, por lo tanto a contra-ráster. Mucho me temo que no quede otra que usar el doble buffer.
Otra cosa interesante es que uso el modo gráfico Extended Background Color. Esto me permite hasta 4 colores de fondo distintos en cada celda de texto, pero teniendo sólo acceso a 64 caracteres del charset (más que de sobra, ya que sólo uso 18 caracteres para gráficos). Y es que el terreno es amarillo y el asfalto blanco (). Como sabéis, los 4 colores de fondo se usan mediante CHAR normal y CHAR con SHIFT
(colores 0 y 1 de fondo) y lo mismo en INVERSE MODE(colores 2 y 3). Es decir, se reservan los bits 6 y 7 de cada char para acceder a los 4 colores del background
ya tengo todo listo y montado para empezar a pegarme con el scroll!!