Hoy voy a hacer un pequeño paréntesis en lo que nos ocupa últimamente (juegos de tablero). He descubierto un sitio que seguramente lleva unos años en línea, pero que yo he encontrado recientemente y que me ha parecido interesante: 8bitworkshop.
8bitworkshop es un sitio web que permite programar en ensamblador y en C para varias máquinas de 8 bits y, entre ellas, nuestro querido Commodore 64.
Una primera cosa curiosa es que la programación es online, es decir, directamente en el sitio web y con en el navegador. Esto no me parece especialmente interesante. De hecho, me parece que incluso puede ser poco práctico a la hora de abordar proyectos medianos y grandes.
Lo que sí me parece muy interesante es que, según programas en ensamblador, se va generando automáticamente el código máquina, es decir, se va ensamblando. Todavía más, el efecto que tu programa pudiera tener sobre la pantalla del C64 ($0400 – $07e7) también se actualiza instantáneamente:
Esto hace que sea una herramienta muy interesante para prototipos rápidos.
Otra cuestión que me ha parecido muy interesante es que no sólo permite programar en ensamblador. También permite programar en C para el C64:
Esto tampoco es nuevo, ya que hace tiempo que existe https://www.cc65.org/, que es un compilador cruzado de C para el 6502. Se puede ejecutar sobre sistemas Windows, Linux y otros.
Pero, pensándolo bien, no me parece ninguna tontería. El ensamblador es rápido y potente, pero es complejo. Por su parte, el BASIC es mucho más sencillo, pero se queda escaso y es muy lento.
Sin embargo, el C podría conjugar las virtudes de ambos mundos. Es un lenguaje de alto nivel, pero es compilado (no interpretado como el BASIC). Por tanto, es mucho más rápido. Es más estructurado que el BASIC, que apenas admite estructura, tiene más tipos de datos, etc.
Pero es que además C permite acceder fácilmente a la memoria, ya que tiene punteros y operadores para obtener las direcciones de posiciones de memoria. Esto es esencial para máquinas como el C64, en las que el manejo de gráficos, sonido y entrada/salida requiere un conocimiento profundo del mapa de memoria y el acceso a los chips especiales que se encuentran ahí «mapeados».
Hará unos 25 años que no programo en C, pero en cuanto pueda le daré un tiento sobre el C64…
Programación Retro del Commodore 64 
Es interesante, pero tengo entendido que el rendimiento de estos programas hechos en C o en Pascal es inferior al asm, ya que no están tan optimizados. Yo sigo con el asm…
Me gustaMe gusta
Hola, Paco.
Muchas gracias por tu comentario 🙂 .
Tienes toda la razón. Estoy convencido de que un programa hecho en C y compilado para el 6502 no estará tan optimizado como uno programado directamente en ensamblador.
Aun así, me ha parecido interesante destacar que hay alternativas a la clásica dualidad ensamblador vs BASIC.
Un programa hecho en C y compilado no será tan compacto ni tan rápido como uno hecho en ensamblador. Pero seguro que es notablemente más rápido que uno equivalente hecho en BASIC, que encima es interpretado.
Seguro que es más fácil de programar que en ensamblador. Pero, todavía más, estoy convencido de que será incluso más fácil de programar que en BASIC, cuya falta de estructura yo encuentro especialmente desquiciante 🙂 .
Bueno, cuando tenga oportunidad de echarle un ojo al cc65 ya te daré detalles.
Un saludo, HVSW.
Me gustaMe gusta
Hola de nuevo.
He hecho un prueba rápida. Me he descargado el cc65 de aquí: https://www.cc65.org/oldindex.php#Download.
He programado el típico HelloWorld, que en C es así:
#include <stdio.h>
int main()
{
printf(«Hello World!»);
return 0;
}
Al compilarlo, cc65 genera este código en ensamblador del 6502:
.segment «RODATA»
L0001:
.byte $48,$65,$6C,$6C,$6F,$20,$57,$6F,$72,$6C,$64,$21,$00
; —————————————————————
; int __near__ main (void)
; —————————————————————
.segment «CODE»
.proc _main: near
.segment «CODE»
lda #<(L0001)
ldx #>(L0001)
jsr pushax
ldy #$02
jsr _printf
ldx #$00
lda #$00
jmp L0002
L0002: rts
.endproc
El código parece sencillo y se identifica bien. Primero prepara una cadena hexadecimal para «Hello World!» ($48,$65,$6C,…). Luego prepara un puntero a esa cadena con la parte «lo» en el acumulador y la parte «hi» en el registro X, y se pasan a la rutina «pushax» (que supongo que meterá en la pila el puntero definido por el acumulador y el registro X). Y por último llama a una rutina «_printf», que me imagino que implementa la función «printf(…)» de C.
Este código no se diferencia mucho del que haría yo directamente en ensamblador:
*=$c000
helloworld
ldx #$00
bucle
lda cadena,x
beq fin
jsr $ffd2 ; chrout
inx
jmp bucle
fin
rts
cadena text «hello world!»
byte $00
Sin embargo, las diferencias importantes empiezan al linkar. El archivo prg que genera cc65 ocupa 2.686 bytes, mientras que el prg generado a partir de mi ensamblador ocupa 30 bytes. ¡¡Son casi 100 veces más!!
Me imagino que esta sobrecarga proviene sobre todo de las librerías que mete cc65 y, en particular, por haber metido completa la librería de entrada/salida de C, es decir, stdio.h.
Supongo que esta gran diferencia (100 veces más) se irá diluyendo según el proyecto vaya siendo más grande, y según se vayan usando funciones que ahora se incluyen pero no se usan.
Pero sí, está claro: el código generado al compilar nunca puede estar tan optimizado como si lo hiciéramos directamente en ensamblador.
Un saludo, HVSW.
Me gustaMe gusta
Yep, acabo de ver tu respuesta casi 2 años después, disculpa. Sí, imagino que en un proyecto que aproveche las funciones de esa librería se notará menos la diferencia de tamaño, pero aún así, cuando el proyecto sea muy grande y el uso de la RAM sea crítico, creo que será difícil rascar esos KB que en ensamblador se pueden sacar de alguna manera.
Saludos.
Me gustaMe gusta