Programación del C64… ¿online? ¿Y en C?

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:

8bitworkshop

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:

8bitworkshop - C

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…

3 comentarios en “Programación del C64… ¿online? ¿Y en C?”

    1. 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 gusta

  1. 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 gusta

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s