Usted está aquí

Palabras desde otro mundo

Bajo un océano de bits, mes XXII

El tiempo continúa transcurriendo y los ánimos se mantienen en un estado de incertidumbre. Estas han sido unas semanas de ver muchos vídeos y leer cosas, pero de picar código ha habido poco. Sigo con el cerebro un poco derretido y no me está dando para mucho.

En lo referente a la práctica activa de la programación, lo único que he hecho ha sido practicar un poco con algunas de las herramientas que disponía1 como son “Droid 64” y ” “petcat” para poder escribir el código en Basic del Commodore desde Linux y luego convertirlo ese texto en un binario que sea capaz de entender VICE.

Los primeros listados en Basic del manual de usuario los escribí hace unos meses directamente en el emulador, pero resultaba una labor bastante incómoda. Aun así, no tenía demasiada opción porque la exportación de los PRG a texto plano que hacía Droid 64 dejaban bastante que desear.

Por otro lado, a la hora de tratar de convertir los archivos de texto directamente a PRG con petcat aquello petaba por todos lados. Cuando trataba de listar el código en el emulador los caracteres que me mostraba no tenían demasiado que ver con los que había escrito. Así pues, al principio la cosa fue complicada. No sabía cómo escribir “desde fuera” las teclas especiales del C64 y eso me rompía el código. Aparte de eso, y al igual que me sucedió con Acme, hasta que no llegué a entender que tenía que escribir todo el código en minúsculas me retrasó bastante. Las mayúsculas no las interpretaba como la letra que yo veía, sino como el carácter especial que aparece en el Commodore cuando las combinas con el “Shift”.

Pero…
Tras extraer con Droid 64 el archivo PRG “en crudo” de uno de los discos virtuales de Commodore que había creado, y realizar la conversión de ese PRG a un archivo de texto con petcat la luz se “hació”

Convertir de Prg a Bas:
petcat -2 -o archivo_de_destino.bas -- archivo_de_origen.prg

Ahí pude ver que mnemónico tenía este programa para combinaciones de teclas como las de “CLR/HOME” del Commodore. Es más, bobo de mi, estaban todas documentadas en su página de ayuda. No sé cuántas veces había mirado ese documento hasta darme cuenta de que eso había estado ahí todo el rato.
En fin, una vez superado ese bache en mi comprensión lectora, la cosa ya fue mucho más sencilla. Es más, comprobé también que podía ahorrarme los mnemotécnicos de petcat utilizando las tablas de código ASCII que vienen en el manual del Commodore. Una vez hecho esto, para convertir un archivo de texto plano a Prg eran tan sencillo como ejecutar un:

petcat -wsimon -o archivo_de_destino.prg -- archivo_de_origen.bas

Pero claro, la cosa no podía quedar ahí y esto me llevó a mirar otra serie de cosas. Consultas basadas en gran medida en los vídeos de la Competición Basic vs C2.
Comprobé que, aunque el resultado en pantalla es idéntico, poner un “10 print "{clr}" no es lo mismo que escribir “10 print chr$(147)”. Al igual que sucede con el BASIC de CPC, el número de caracteres influye en lo que la memoria que va a ocupar el programa.

Emocionado de la vida ante aquel nimio avance, decidí hacer otra prueba loca. Nuevamente con Droid 64 exporté el PRG del Traz a código ensamblador y, tras hacer dos pequeños apaños, traté de compilarlo con Acme sin erótico resultado.
Aquel era el resultado esperado y, obviamente, ya desde antes era consciente de que aún me queda mucho por entender antes de lanzarme a desensamblar un programa, pero en ese punto fue en el que la cosa se volvió a descontrolar… una vez más.

Youtube es una mala influencia y, de vez en cuando, las sugerencias de sus algoritmos parecen acertar y recomendarte algo válido o, cuando menos, prometedor. Referencias que me hacen danzar de un lado a otro3 buscando “el método”. Un método que no voy a encontrar fuera pero que, ahora mismo, no tengo el nivel de concentración necesario para alcanzar por mi mismo.

Más allá de los recién llegados, los viejos conocidos4 continúan produciendo material. Lo nuevo de Ben Eater promete, y las entradas del blog “Programación Retro del Commodore 64” siguen un ritmo que no soy capaz de seguir (más aún cuando no he terminado con el libro original). Por el momento cada una de ellas va alimentando el documento de texto en el que las voy recopilando.
Como premio, con la llegada del nuevo curso, Fran Gallego ha empezado el curso con fuerza siempre con cosas interesantes.

Por su parte, Gamasutra me ha hecho conocer y amar a Jeff Vogel, mientras me mostraba que en Itch.io6 puedes agrupar los juegos por el motor que se ha utilizado para crearlos (teniendo algunos de ellos incluso enlaces al Github en el que se aloja su código).

En fin. Toca recomponerse, tratar de buscar el equilibrio y marcar una ruta que sea capaz de seguir.
En cuatro semanas te cuento si he sido capaz de hacer algo de eso.

Enlaces:

1. Herramientas para Basic
- Petcat es tu amigo
- Droid 64 no tanto

2. La guerra que acabará con todas las guerras
- Amstrad GameDev Challenge #05: BASIC vs C
- Amstrad GameDev Challenge #06: BASIC vs C. Especial RetroZaragoza En Vivo

3. One Lone Coder y más cosas que mirar para evitar ponerse a hacer
- Code-It-Yourself! Tetris - Programming from Scratch (Quick and Simple C++)
- NES Emulator Part #1: Bitwise Basics & Overview
- Learn 6502 Assembly Programming - Lesson1 : For absolute beginners!
- Ensamblador VASM
- VASM
- Retro Insectivores: Finding and Eliminating Bugs in NES Development

4. Los de siempre

Ben Eater
- “Hello, world” from scratch on a 6502

Programación Retro del Commodore 64
- Asteroids: movimiento sencillo de la nave
- Asteroids: movimiento de la nave con ángulo y velocidad
- Asteroids: nave con giros controlados
- Asteroids: eliminación de zonas ocultas
- Asteroids: información en la zona derecha de la pantalla
- Asteroids: disparos
-
Asteroids: disparos – rutinas accesorias
- Asteroids: disparos – algunas mejoras necesarias
- Asteroids: disparos – caracteres personalizados
- Asteroids: los asteroides
- Asteroids: los asteroides – un híbrido entre la nave y los disparos
- Asteroids: configuración y posicionamiento de los asteroides
- Asteroids: movimiento de los asteroides

El profe
- Instalación de CPCtelera 1.5 development branch
- Ejemplo básico: dibujar y mover un cuadrado con CPCtelera 1.5
- Introducción a la arquitectura Entity-Component-System (ECS)
- Arquitectura Entity-System: implementación básica inicial
- Arquitectura Entity-System: revisando la implementación inicial [#ASM #Z80]
- Ensamblador, linker, includes y símbolos globales [#ASM #Z80]
- Gestión automática con macros y constantes [#ASM #Z80]
- Creando Videojuegos: Iteraciones y Calidad de Producto
- Dudas, consejos y fé de erratas [#ASM #Z80]
- Entity-System (II): sistemas físico, input y render [#ASM #Z80]
- IA Básica: Árboles de Decisión y Niveles de Abstracción en Videojuegos [#ASM #Z80]
- Implementando el sistema de IA básico [#ASM #Z80]
- Entity-System (II): revisión y dudas [#ASM #Z80]
- Revisión del modelo de IA básica implementado [#ASM #Z80]

Dan Root
- The Animation of Metal Slug
- The Animation of Hollow Knight

GDC
- Beyond Framerate: Taming Your Timeslice Through Asynchrony
- How to Get a Job Writing for Games
- The Art of Wonder Boy: The Dragon's Trap

5. Jeff Vogel
- Why All My Games Look Like Crap
- I Am the Cheapest Bastard In Indie Games

6. Los motores y más
- Which are the most commonly used Game Engines?
- Juegos por "engine" en Itch.IO
- Spelunky HD en Itch.IO
- Spelunky HD en Github

Bajo un océano de bits, mes XXI

Cuanto más avanzamos más nos vamos alejando del propósito inicial de este reto. Pero esto va del aprendizaje y comprensión de lo binario y sus aledaños, así que el ámbito no tiene límites.

De manera sorpresiva, este mes ha tenido una especial presencia en mi pantalla el mundo de la animación a través de Daniel Floyd y su canal New Frame Plus1. Fue empezar y no poder parar de ver sus vídeos hasta terminar con el último de ellos.
Llegué hasta él a través de un viejo conocido de esta serie de artículos; Dan Root2, a cuyo canal también estoy suscrito y que, con ritmo lento, también continúa aportando datos de lo más interesantes acerca de un mundo al que sólo me había acercado de oídas..
Como con todo, todo lo que rodea a la animación compone un universo insondable, y la cantidad de matices que se pueden sacar del más nimio de los gestos no dejan de sorprenderme.

En otro orden de cosas, este mes se me ha fastidiado uno de los discos duros del servidor que tengo en casa. Y esto no sería nada significativo (no es la primera vez, cosa de montarte un servidor con restos de otros equipos), de no se porque me ha dado por preguntarme ¿y cómo funciona esto?3.
No es que haya profundizado demasiado pero, una vez más, me ha dejado con más preguntas que las que tenía cuando empecé. No escarmiento.

Ya que estaba, también me ha dado por mirar cómo funcionan (funcionaban) los disketes. Más concretamente el formato ADF que utilizan los emuladores de Amiga y la emulación de la disketera del Commodore 644. Para sorpresa de nadie, ha pasado tres cuartas partes de lo mismo que con lo anterior. No me miréis así, sé que soy débil, pero es que me han dibujado así.

También apareció un artículo ante mis ojos en el que mencionaban unos cuantos motores para diseñar videojuegos que no conocía5. A esto me fue más fácil resistirme, pero lo dejo por aquí por su alguien los encuentra de utilidad.

Siguiendo con la parte de los vídeos, por esta casa no han podio faltar el profesor RetroMán6, las charlas del GDC7 y el amigo Ben Eater8.

Sí. Efectivamente. Como habrás podido deducir, de código ha habido poco avance desde la última vez que escribí sobre el asunto.

No obstante, algún pequeño avance sí que he llevado a cabo. Quizás sea tan tenue que apenas pueda ser considerado como avance, pero alguna que otra página del blog “Programación Retro del Commodore 64” ha caído y, recientemente, su autor ha continuado con las entradas para adentrarse en la programación de una versión del Asteriods en ensamblador9.

Y…, más o menos, eso ha sido todo.. Ahora sólo tengo que reunir fuerzas para no terminar de leer la trilogía sobre la historia de Commodore cuya última entrega me ha llegado esta semana y ver si para cuando termine el año tengo algo que sirva para algo como resultado de todo esto.

Tarjeta Commodore
Commodore Final years

Enlaces:

1. New Frame Plus
- Dan Floys en tuister
- La Animación de Punch-Out!!
- What Happened with Mass Effect Andromeda’s Animation?
- Tracer & Pose Design 101 - The Animation of Overwatch
- Where To Learn More About Game Animation
- Como los Personajes de Overwatch transmiten personalidad en primera persona
- How to Animate a Smash Bros Character // MARIO
- How to Animate a Smash Bros Attack // LINK
- Spider-Man: La Animación del Impulso Puntual - New Fram Plus
- ¿Es la animación de Red Dead Redemption 2 muy lenta?
- The Bizarre Animation of MR. GAME & WATCH
- Why Skyrim's Mining Animation Is Bad
- My Favorite Game Animation of 2018
- ¿Pueden los juegos antiguos tener buena animación?
- How To Become a Game Animator
- ¿Cómo ha evolucionado la animación de batalla en Pokémon?
- RITMO - Los 12 Principios de la Animación
- Which Dark Souls Has the Best Parry Animation?
- The Animation of Guilty Gear Xrd & Dragon Ball FighterZ
- How Link's Climbing Animation Works in Breath of the Wild

2. Dan Root
- Dynamic Frames in Dustforce
- Fez's Animated Environments
- Breath of the Wild is a Standalone Game
- Behind the Schemes: GRIS with Nomada Studio
- The Animation of Gris
- How to Wield the Master Sword // Video Game Animation Study

3. Duros de verdá
- How to interpret smartctl messages
- Fixing bad blocks on HDDs using fixhdd.py
- fixhdd.py
- Is this a bad sign: smartd: 1 Currently unreadable (pending) sectors....?

4. Los discos y sus cosas
- El formato ADF
- Pi1541 Build (Commodore 1541 Emulator)
- Pi1541 Build
- 6502 - Writing a disk file using assembly on Commodore 64

5. Más motores
- GDevelop
- Stencyl
- RenPy
- Kodu Game Lab
- Game Salad

6. El profe
- Avance Amstrad GameDev Challenge #04: #TeamBASIC misterio memory leak
- Amstrad GameDev Challenge #04: BASIC vs C. Especial Gráficos UDG
- Sprites con caracteres en BASIC de Amstrad CPC

7. Y las GDC
- Bringing Fantasy to Life in Final Fantasy XV
- Audio Choreography for Battle Design
- Conquering the Creative Challenges in Marvel's Spider-Man
- 09 to '19: A Decade of Approachability in Fighting Games
- Making of ASTRO BOT Rescue Mission: Reinventing Platformers for VR

8. Ben Eater y la detección de errores en las comunicaciones

9. Asteroids para el Commodore 64
- Un primer juego sencillo: Asteroids
- Asteroids: estructura del proyecto
- Un primer juego sencillo: Asteroids
- Asteroids: la pantalla de juego
- Asteroids: la nave
- Asteroids: configuración y posicionamiento de la nave

Bajo un océano de bits, mes XX

Recuperando un poco el tema bajo el que nació este epígrafe, este mes el foco ha vuelto a dirigirse hacia la programación.

Empezaremos con un clásico por estos lares, los vídeos del señor Fran Gallego1. Este mes ha subido cinco nuevas entradas en su canal, todas ellas con reflexiones que siempre viene bien tener presentes.
En las dos primeras habla acerca de la necesidad de no limitarse a copiar cosas de Stackoverflow y similares. En tratar de ir más allá y leer el código de las cosas que estamos utilizando en nuestros proyectos.
Como de costumbre, la cosa aún me viene muy grande, pero no puedo estar más de acuerdo con este señor.

Además de esto, y dentro de su labor de divulgación del CPC, se ha montado un concurso para animar a la gente a programar cosas para esa máquina. Un reto en el que, bajo el justag de tuister #AmstradGameDevChallenge2, Héctor Linares y él están haciendo un “Rpg” para la máquina de Alan Sugar. Dentro de este reto, cada uno de ellos forma parte de un equipo diferente en el enfrentamiento, el de los defensores del BASIC contra el de los partidarios del C.

Por supuesto, mientras se lanzan pullas amistosas entre ellos van demostrando distintas maneras de afrontar los mismos problemas.

Este mes también he descubierto una nueva fuente de información para seguir adelante con mi reto principal; el libro “Programación Retro del Commodore 64”3. Una obra que, lamentablemente, al venderse únicamente a través de Amazon no voy a comprar.

Mandé una consulta a su autor preguntándole por la posibilidad de adquirirlo a través de otras plataformas pero me dijo que, por el momento, no había alternativas. En su respuesta también me decía que, básicamente, lo que venía en el libro no deja de ser lo mismo que había apareciendo en su blog así que, acto seguido, lo que sí que hice fue fabricarme un PDF a partir de las entradas publicadas en él.
Aun así, si a alguien le interesa el libro no llega a los seis euros, así que el dinero no debería ser un problema para que os hagáis con él. Eso sí, igual si le da el coñazo un número mayor de personas decide ponerlo también en Lulu o alguna plataforma de POD.

Entre lo que encuentre en él y las referencias que va mencionando, espero llegar a ser capaz de desensamblar el Traz de Commodore para poder hacer un port lo más fiel posible a todos los niveles para PC.

Como él ha escrito el libro utilizando Windows y CBM Prg Studio, los ejemplos que se pueden descargar de su web no me sirven tal cual están, lo que pretendo utilizar a mi favor dentro de mi proceso de aprendizaje. Dado que el compilador de ese programa no es Acme, tendré que ir haciendo yo las conversiones a mano y ver las diferencias entre ambos.

Por el momento los cambios que he tenido que hacer no hay sido excesivos. Cosas como sustituir las cadena de bytes que Prg studio llama “byte” por “!byte”, o “text” por “!scr”.
También he tenido que añadir unas cuantas cabeceras para que el programa resultante funcione en el emulador. Por más que el compilador no diese errores a la hora de crear el archivo, el prg resultante no funcionaba en el emulador.

Las cabeceras

Supongo que estas son cosas que CBM Prg Studio “ofusca” y hace de forma automática dentro de sus proyectos para simplificar la labor del desarrollador, pero prefiero hacerlas a mano (y tratar de entender que hay en las posiciones de memoria a las que se llama byte a byte)

Otra diferencia que he encontrado es que ambos no tratan de la misma manera los caracteres y que, si quiero que me aparezca texto, tengo que escribir este en minúsculas ya que, si lo escribo en mayúsculas, lo que aparece en pantalla son los símbolos especiales que se encuentran en esas teclas.
Supongo que si quiero escribir el texto en minúsculas tendré que llamar a la rutina que cambia el modo gráfico de la pantalla, pero aún no he llegado a eso.

En paralelo a todo esto también he comenzado a mirar con un poco más de detenimiento los tutoriales de Dustlayer4 donde hay unos cuantos artículos muy interesantes acerca del hardware del Commodore. Por otro lado, los ejemplos que trae están diseñados para Acme, por lo que esos no voy a tener que tocarlos para que funcionen (aunque su autor los haya creado en un Mac).

Dentro de mis búsquedas a través de la red también he encontrado una nueva herramienta para el desarrollo, C64 Unit5; un framework de pruebas para software de Commodore. Aún queda mucho para que pueda plantearme el utilizarlo, pero no está de más el tenerlo localizado.
Eso sí, para compilarlo he necesitado instalar un compilador cruzado más; 64tass.

Antes de terminar por hoy, sólo pondré un par de apuntes adicionales.
Por un lado, que no lo haya mencionado en esta entrada no quiere decir que haya abandonado el tema de las EEPROMS6. He retomado (por vez N) un libro de fundamentos de la electrónica que me dejó un amigo hace años. A falta de más vídeos de Ben Eater, también sigo buscando otras fuentes a ese respecto (aunque no todas son igual de amistosas).

Por otro, y siguiendo con el tema del visionado de vídeos, no podían faltar por aquí los habituales enlaces a las charlas del GDC7 que han caído este mes.

Y más o menos eso ha sido todo lo que he hecho desde la última entrada. A día de hoy, mi escenario de trabajo es Vim + Acme + Vim-acme + Droid 64 + Vice 3.3 y, de aquí a un tiempo, supongo que empezaré a utilizar SpritePad, VChar64 y C64 Debugger.

Salvo Vim, el resto de cosas que voy utilizando las he compilado a mano porque, en la versión de Vice que está en los repositorios de Ubuntu, el monitor con el que se accede al estado de la memoria tenía un comportamiento un poco extraño.

Si a alguien le interesa montarse un entorno similar, no tendría problema en publicar por aquí una guía acerca de cómo he ido montando esto en mi máquina.

Enlaces:

1. Profesor Retromán
- C++ : ¿Por qué reserva 71K un programa vacío?
- Habilidades para ser mejores ingenieros

- Amstrad GameDev Challenge #01: BASIC vs C
- Amstrad GameDev Challenge #02: BASIC vs C
- Amstrad GameDev Challenge #03: BASIC vs C

2. Los contendientes y su juastag
- Fran Gallego
- Hector Linares
- #AmstradGameDevChallenge

3. Programación Retro del Commodore 64
- El libro
- El blog
- Entrevista al autor en AmigaWave #168

4. Dustlayer y el hardware
- Ram under Rom - a brief look into C64 memory
- Hardware Basics Part 1 - Tick Tock, know your Clock
- Hardware Basics Part 2 - A Complicated Relationship

5. C64 Unit
- C64 Unit - La web
- C64 Unit - En BitBucket
- 64tass - El compilador
- 64tass - La guía

6. La electrónica
- The Learning Circuit - How Logic Gates Work
- The Learning Circuit - Making Logic Gates From Discrete Components
- Fundamentos de Sistemas Digitales
- Basic Willem EPROM Programmer To Make Sega Genesis/Mega Drive Reproductions
- Retro EPROM Programming Tutorial
- Lecture 36 ROM-EPROM,EEPROM and Flash EPROM

7. Charlas GDC
- Letting Go: A Florence Postmortem
- Motion Capture Performance: An Actor's Approach
- Trailer Made: What Makes a Successful and Memorable Game Trailer
- Math for Game Programmers: Dark Secrets of the RNG
- Three Statistical Tests Every Game Developer Should Know
- 2019 Animation Tricks of the Trade

Bajo un océano de bits, mes XIX

Este mes la cosa va de desvíos.
Sí, otra vez.

Cuando ya está claro que el propósito con el que afirmaba dar comienzo a este viaje ha quedado totalmente desvirtuado, cada vez me voy dirigiendo hacia lugares cuya visita tenía planteada para mucho más adelante.
Temas íntimamente relacionados con esto pero que, al mismo tiempo, se encuentran en sus antípodas dentro del modelo OSI1. La eterna pelea entre el software y el hardware. Entre los desarrolladores y los tipos de sistemas.

Y mucho de la culpa de todo esto la tiene Ben Eater2.
Tras terminar de ver los cuarenta y cuatro vídeos que componen su Obra Magna; aquella que muestra y explica la fabricación de un ordenador de 8 bits, va el hombre y comienza con otra saga igualmente interesante; la de la creación de una tarjeta de vídeo.

Muy bien. Centrémonos.
Ahora ya tengo una idea más aproximada de lo que buscaba cuando comencé con estos vídeos. Tengo… más o menos claro, qué es lo que hace un ordenador (o, al menos, el del amigo Ben) en un ciclo de reloj. He visto cómo se hablan los registros, la memoria y el bus, he visto cómo se programa el micro-código que va en el procesador y qué son exactamente los mnemónicos que utiliza el ensamblador.

He visto todo eso… y yo también quiero hacerlo. Quiero interiorizar ese conocimiento. Pensar en ciclos de reloj y en bits cuando programo en lugar de bucles de lenguajes de alto nivel.
Como ya decía hace unos meses, ser un ingeniero sin hacer la carrera.
Aún estoy muy lejos porque apenas he comenzado a rascar la superficie, pero voy dando pequeños pasos.

En los vídeos todo está claro, incluso los fallos que van apareciendo, pero cuando he tratado de llevar hasta el mundo real lo más nimio de cuando se muestra en ellos, sigo sin saber por dónde empezar.

Necesito ir de menos a más. De algo un poco más concreto que el “Me voy a hacer un ordenador”. Porque he dicho que quiero hacerlo, no que quiera copiar el suyo. No pretendo ir parando los vídeos, comprando los componentes que utiliza y replicar paso por paso su camino. Quiero hacer algo que me viene aún muy grande.

Pero claro, tengo cosas más pequeñitas por las que podría empezar. Por mi salón aguardan como roboces sin carcasa varios ordenadores desmembrados a la espera de unas nuevas ROMS3, y por mi habitación no dejo de ver un montón de chips a la espera de ser tostados4.

A partir del visionado del vídeo en el que el amigo Ben se fabricaba un programador de EEPROMS con un Arduino5, me dio por leer poco más al respecto6. Por trata de profundizar algo más que la última vez que me puse a ello, pero todo está aún muy neblinoso.

Pero las formas van tomando consistencia. Parece que me voy acercando a algo y, a pesar de que por el momento no soy capaz de “leer” las especificaciones de los chips que tengo, hay formas que sí que voy siendo capaz de discernir.
Por un lado, y si no lo he interpretado mal, el chip que compré para actualizar a los Amiga sí que valdrá para ellos.

mx29f1615

Por un lado, y por más que tenga 42 pines, encaja tanto en el zócalo del Amiga 500 (slot de 40 pines) como en el del Amiga 600 (42 pines, y lo que me llevó a conectar mal uno de los que había comprado con la última versión del Workbench). Por otro, igual aún puedo recuperar la ROM que me cargué.

Porque la cosa es que me dio por levantar la pegatina que tenía con la versión del sistema operativo, número de serie y temas similares, y resulta que es una EPROM que se puede borrar con luz ultra violeta y se puede volver a grabar.

am27c400

Aparte de esto, comparando los patillajes vi que el direccionamiento de los pines de ambos se corresponde. Las patas 41 y 42 corresponden a dos líneas de entrada adicionales. Dos pata que no es necesario que use y que, en el caso del Amiga 500, sobresalen sin estorbar en el zócalo de 40 pines.

El hecho de que coincida su patillaje hace que tenga bastante confianza a la hora de afirmar que no la cagué a la hora de pedir esos chips que. Además, y como premio, resulta que son regrabables.

A partir del modelo de las ROMs originales de los Amiga he tratado de buscar correspondencias, pero no he encontrado nada directo. Las búsquedas de Google me han llevado siempre hasta foros en los que no se decía nada explícitamente, pero sí que se hacía referencia a cosas como el MX23C4100; otra EPROM cuyo patillaje es idéntico al de las que tengo por aquí.

mx23c4100

Así pues, parece que la cosa promete.

Viendo el vídeo del programador del señor Eater también me ha quedado clara alguna que otra cosa más; el programador Willem7 que compré también me servirá para tostar EPROMs que tienen más patas que su zócalo.
Había leído que existían adaptadores para realizar la conversión, pero aquello era algo que se me hacía muy contraintuitivo. La parte técnica aún está un poco neblinosa en mi cabeza, pero tengo claro que la cosa va a funcionar (y he pedido el adaptador de marras).
En mi momento de flipamiento pensé en hacerme yo el adaptador pero, como de costumbre, cuando me puse a ello no tenía ni idea de por dónde empezar. Aun así no desespero, igual de aquí a un tiempo me lanzo a ello y a otras movidas que se me van pasando por la cabeza.

Por lo pronto, lo único con lo que puedo trastear hasta que me llegue el aparato son las ROMs del Atari.

m27c256b

Tengo cuarenta de ellas y sólo me hacen falta dos, así que puedo destrozar un montón sin sentirme (demasiado) culpable.

Y eso ha sido más o menos para lo que ha dado el mes. Por supuesto, no ha faltado el visionado de otro montón de vídeos8 de temas relacionados con el motivo original de este reto. Tengo intención de seguir adelante con la programación de juego y, por más que mi foco de atención haya cambiado de forma drástica, no me olvido de él.

Tengo claro que cuando vuelva con el código que ya tengo escrito tendré que volver a replanteármelo todo casi desde cero. Hay unas cuantas decisiones que tomé que, para mi yo de entonces, tenían sentido, pero a día de hoy me queda claro que fueron barbaridades.
El programa no se resiente, cosas de que las CPUs de hoy van sobradas para tragar lo que hice y que aún les sobren ciclos para dar y regalar, pero no quiero que mi criatura desaproveche ni un ciclo aunque el procesador se dedique a rascarse la barriga mientras tanto.

En fin. Planes y más planes.
Proyectos que no terminan de irse y flipamientos que no dejan de llegar.

La historia de mi vida resumida.

Enlaces:

1. El modelo

2. Ben Eater, ese hombre
- Building an 8-bit breadboard computer!
- The world's worst video card?

3. En anteriores capítulos...
- Nunca a la última 004
- Nunca a la última 009

4. Los chips
- Atari - M27C256B (UV EPROM)
- Amiga - MX23C4100 (¿Amiga Original?)
- Amiga - MX29F1615 (EEPROM Flash)
- Amiga - AM27C400 (AmigaStore)

5. Build an Arduino EEPROM programmer

6. Lo básico
- Basic information about memory chips and programming
- EPROMS: The minimum you need to know to burn your own
- Settings for Willem 4.1 Eprom Programmer
Con Raspberry
- Raspberry-Pi-Python-EEPROM-Programmer
- Raspberry Pi SPI and I2C Tutorial
- Raspberry-Pi I2C 256K EEPROM Tutorial
Con Arduino
- Arduino MX29F1615 programmer
- Arduino EEPROM programmer
- TommyPROM - An Arduino-based EEPROM programmer
A pelo
- Retro EPROM Programming Tutorial
- 27c801 EPROM Programmer Project
Borrando
- Improvising an EPROM programmer

7. Willem
- Adapter EPROM 16 Bit from Toomas Toots
- Willem EPROM Programmer User Guide
- Enhanced Willem EPROM Programmer – Manual
- Willem Eprom programmer for Win 9x/ME/NT/2000/XP
- Start CD

8. Vídeos de animación, retro y temas relacionados
- Cartridge Save File Preservation - Backup, Transfer & Restore Your Save Games
- RetroPixel 2019 - Conferencia Blasphemous
- Dead Cells: What the F*n!?
- Gato Roboto's Animation
- Game Discoverability Day: NOTICE ME: The Grind Behind the $272K Funding Success of Boyfriend Dungeon
- ¿Debe la universidad enseñar lo que demandan las empresas?
- Amstrad GameDev Challenge #01: BASIC vs C
- Planet X3 -The Making of, Part 4

Bajo un océano de bits, mes XVIII

Este ha sido un mes de esos de no avanzar demasiado. Uno de esos meses en los que la cabeza no da demasiado de sí y en los que no sabes hacia dónde tirar. Uno de esos en los que, como cada vez me veo sumergido en ellos, me limito a bucear bajito asomando mucho la cabeza. Uno de esos en los que, principalmente, me dedico a la parte más pasiva de este reto; a ver vídeos a tutiplén.

A ver si con el verano la cosa remonta.

Empecé con las clases de matemáticas del canal de Fran Gallego1. Unas clases que no están impartidas por él sino por uno de sus compañeros, y que no tratan de lo que esperaba sino que versan acerca de la lógica de primer orden2, Prolog y otros tema derivados de ambas dos.
Después de ver los primeros diez vídeos decidí dejar eso para más adelante. Había matices que se me escapaban y, como es de rigor, tenía la sensación de llegar a la sala con la película ya empezada. Tampoco tenía la cabeza como para ponerme a profundizar en ello, así que queda aparcado por el momento.
Pero volveré.

Después de eso volví hasta el profe titular3 y los vídeos que me faltan por ver de su canal. Ya falta menos para terminar con ellos… aunque tengo la impresión de que debería volver a darles otra vuelta cuando empiece a hacer algo en ensamblador. Los conceptos importantes están ahí, pero hasta que no me ensucie las manos con código no voy a ser capaz de determinar si he entendido realmente las cosas.

Este mes también ha sido la primera edición del Retro Madrid Academy4. Más allá de lo interesante de las ponencias, lo mejor que saqué de la visita fue el ver al amigo Multimaniaco5, y las conversaciones en el coche durante la ida y la vuelta hasta la capi. Es increíble lo que ayuda el tratar de verbalizar las cosas que crees haber entendido para terminar de asentar conceptos, o para darte cuenta de lo verdes que los tienes aún.
Necesito tener más conversaciones activas acerca de programación.

Tras largo tiempo en el dique seco, también he visto que se sigue hablando acerca del controlador adaptativo de Microsoft6 y la gente que le está dando uso para distintas terapias. Que no decaiga.

En mi pajarear en busca de conocimiento también he seguido con los temas de electrónica7 a través de los canales de Ben Eater y Element 14, pero sigo necesitando encontrarme centrado, pillar componentes, y cambiar mi estado de ánimo hacia algo un poco más activo (un poco menos vago) para empezar a llevar a la práctica algunas de las cosas que explican ahí.

Y, para terminar, y llenando huecos, como siempre, ahí estaban al rescate las charlas de las GDC8 y Dan Root9. Visionados ligeros que me permiten decir que ”técnicamente” no he incumplido el reto durante esos días. Actividades que no dejan de ser un poco placebo en cuanto a lo que se refiere al conocimiento puro. Eso no quiere decir que sean una pérdida de tiempo o que no sean interesantes, pero no dejan de ser tecnicismos con los que rellenar el expediente.

Muy mal.
Que no me pase nada ahora que empiezan los calores.

Enlaces:

1. Clases de Teoría de Matemáticas 1

2. Lógica y otras cosas
- Lógica de primer orden
- Prolog
- PL Man

3. Profesor Retroman

4. Despega RetroMadrid Academy

5. No tan locos giros de guión

6. Más sobre el mando adaptativo de la X-Box
- The Making of the Xbox Adaptive Controller
- Able Gamers
- Special Effect

7. Más electrónica
- How a transistor works
- Making logic gates from transistors
- SR latch
- How Integrated Circuits Work - The Learning Circuit

8. A tope con el GDC
- The Animation Process Of Ori & The Blind Forest
- Art Direction Bootcamp: Pantalones! Things I Wished I knew Prior to Becoming an Art Director
- Visual Effects Bootcamp: Artistic Principles of VFX
- Classic Game Postmortem: Panzer Dragoon, Panzer Dragoon Zwei, and Panzer Dragoon Saga
- Building a Living World from Ancient Ruins in Assassin's Creed Odyssey
- Classic Game Postmortem: Paperboy
- Why Fashion in (Most) Games Sucks, and Why You Should Care
- GDC Live Q&A: Lucas Pope and Return of the Obra Dinn

9. Y con Dan Root
- Alucard's Running Animation
- The Beauty of Parallax
- How to Animate a 2D Fighting Game [redux]
- Making Fluid and Powerful Animations For Skullgirls
- Animator's survival kit
- Fighters Generation
- Zweifuss, personajes de Street fighter y sus animaciones

Bajo un océano de bits, mes XVII

Este mes ha sido entretenido a la par que ilustrativo en lo referente a este reto. Pero no lo ha sido porque haya avanzado demasiado en el terreno de la programación, sino porque mi tiempo se ha centrado mayormente en buscar, probar y conocer las herramientas que se encuentran a mi disposición si quiero programar cosicas para el Commodore desde un entorno con arquitectura x86.

Podríamos decir que este mes se lo hemos dedicado a entender un poco mejor el legado de los chicos de Commodore Bussiness Machines1.

Un vez hecha esta introducción, vamos al turrón.

¿Qué herramientas tenemos a nuestra disposición?

Pues depende.

Si queremos programar en BASIC para el C642 la cosa es bien sencilla. Basta con tener el VICE y utilizar su “petcat” sobre cualquier archivo de texto plano en el que hayas introducido las líneas de código. Con esto te generará un archivo .prg que reconozca el emulador.
De premio, utilizando su comando c1541 puedes meter eso dentro de una imagen de disco .d64.
Es algo tan sencillo que ha sido lo que más me ha costado encontrar. Porque la Internet es asín.

También tenemos la opción de ejecutar “nativamente” en Linux o Windows comandos del BASIC de Commodore con CBM Basic, pero no tienes la posibilidad de usar pokes o sprites por hardware. Cosas de los sistemas operativos modernos

Si queremos ir al ensamblador3 el abanico se amplia. Sólo mirando las herramientas que aparecen en 6502.org la cosa puede llegar a ser abrumadora. Si ya vas a los foros de Lemon 64 o Commodoremania puedes perder un par de vidas tratando de hacer la criba.

Al final el tema de los ensabladores lo he dejado reducido a dos; ACME y CC65.
El primero por el nombre y porque he visto que hay varios tutoriales sobre él, y el segundo porque se encuentra en los repositorios de Ubuntu. Lo que ha terminado por decantar mi criba por ambos ha sido que existen resaltadores de sintaxis de los dos para VIM.

Si la gente no quiere liarse a “compilar el compilador de ensamblador” se puede descargar Kick Assembler, que está hecho en Java y le serviría para cualquier sistema operativo sin liarse demasiado la manta a la cabeza.
En caso de que busque algo aún más sencillo, también podría decantarse por alguno de los IDEs5 que tiene a su disposición por ahí.

Relaunch está hecho en Java, así que funcionaría tanto en Linux como en Windows o en Mac, y tanto C64 Studio como Kickass IDE funciona bajo Wine, así que tendría la papeleta solucionada en lo que respecta a cualquiera de los sistemas operativos mayoritarios sin necesidad de tener que compilar nada.
Eso sí, Relaunch no trae compilador “de serie”, pero lo puedes arrejuntar con Kick Assembler y asunto resuelto.

Porque la compilación. Vaya movida.
Si hay algo que me ha quedado claro últimamente es que no sólo tienes que aprender a programar en un lenguaje. Tienes que hacerlo pensando en el compilador que utilizarás y la arquitectura del procesador. De acuerdo a lo que he podido entender (seguramente de manera errónea) durante estas “investigación” esto es algo especialmente sensible en el caso de los compiladores cruzados.

He bajado el código fuente de distintos juegos escritos en ensamblador para el C64 y cada uno sólo puede ser compilado con la herramienta para la que fue pensado. Amigüitos, no intentéis compilar algo hecho para ACME con CC65. Y no intentéis compilar nada de CBM Prg Studio con otro ensamblador.

Pasamos a la caza de bichos6 y la cosa se complica un poco más.
Vice tenía un compilador bastante apañado en su versión 3.1 para Windows (y sólo en esa), pero desapareció en la 3.3 (la última que ha salido), donde sólo ha quedado el Monitor que te permite consultar y modificar la memoria y registros desde la línea de comandos.

Si queremos tirar de herramientas gráficas, WinVICE 3.1 funcionan bajo Wine y sigue estando disponible para su, así que por ahí podríamos tener la cosa apañada, pero también existen otras alternativas.

C64 debugger tiene versión nativa tanto para Linux como para Windows y Mac, así que mejor os ahorráis el tratar de compilarlo desde su código fuente (yo no he sido capaz). De cualquier manera, lo que aparece en pantalla nada más arrancar es tan colorido y movido que asusta.

Step 6502 sólo está para Windows, pero funciona bajo Wine, así que se puede usar sin problemas en Linux. Por lo poco que lo he tocado me ha parecido un poco… especial. Hasta donde he podido entender, arranca un emulador en blanco y en estado de pausa. Eres tú quien se dedica a meter a mano los valores hexadecimales en memoria y a avanzar “paso a paso” los ciclos del reloj. Para los muy cafeteros.

Por lo que he podido leer de Vice PDB Monitor la cosa parece interesante, pero ni he conseguido compilarlo ni he logrado que funcione su binario en Windows, así que igual toca investigar un poco más.

Como herramientas para realizar distintas operaciones7 como pueda ser hacer gráficos y caracteres o gestionar el contenido de los archivos ,d64 tendríamos SpritePad, Vchar 64 y Droid D64. Las dos primeras sólo están dispobibles para Windows pero funcionan a la perfección en Wine y la tercera está hecha en Java, así que hasta ahí tendríamos la papeleta solucionada en Linux.
Más allá de esto SpritePad, entre otras cosas, también te permite extraer los gráficos de un snapshot de VICE y Droid D64 te permite desensamblar el contenido de los discos y verlo en formato hexadecimal o ensamblador.
Un par de joyicas ambos dos.

Si eres un usuario de Mac no preocuparse, porque ahí está Actraiser y su Dustlayer8. Este señor han preparado un entorno de desarrollo para la máquina de la manzanita y, de premio tienen varios tutoriales de ensamblador con ACME.

En lo referente al aprendizaje9 también tenemos bastante en lo que rascar más allá de Dustlayer, y a ese respecto CodeBase 64 promete especialmente.

Y con esto creo que terminaríamos este pequeño repaso. Ando tentado de meterme a hacer el equivalente a una CPCtelera para el Commodore con todo lo que he ido encontrando, pero aún estoy über verde como para meterme en un embolado de ese calibre. Tiempo al tiempo.

Más allá del mundo Commodore, este mes también he seguido viendo vídeo a cholón.
Por un lado, he terminado con los de teoría de redes de Ben Eater10 que comencé el mes pasado y he seguido con los que tiene de electrónica. Lo mola todo, pero si quiero entender estas cosa de verdad tendré para un rato largo.
Por otro, y como no podía faltar, también he seguido con los de Fran Gallego11 como si no hubiera un mañana.

También he encontrado una lista de reproducción de “Matemáticas para desarrolladores de vídeo juegos”12 a la que le hincaré el diente… algún día.

Y, ahora sí, yo diría que ya habéis tenido suficiente por hoy.

Enlaces:

1. La famiglia
- Gracias por todo, Jack
- Chuck Peddle, father of the personalcomputer
- Bil Herd

2. Basic de C64 en x86
- The Versatile Commodore Emulator
- Compilando Basic de Commodore gracias a VICE
- Manual de petcat
- Manual de c1541
- CBM Basic GitHub

3. Ensablador de 6502 en x86
- Herramientas para C64 - 6502.org
- Acme GitHub
- Vim Acme GitHub
- CC65 GitHub
- Vim CC65 GitHub
- Kick Assembler

5. IDEs:
- Commodore IDE for Windows 32 and Linux
- K2 Devel
- C64 Kickass IDE
- Relaunch 64
- Info en C64 Wiki
- Unity 8 Bits
- C64 Studio
- CBM Prg Studio
- C64 Kickass IDE

6. Debug de C64 en x86
- Using the Vice monitor
- C64 Debugger
- Step 6502 GitHub
- Step 6502 en CSDB
- Vice PDB Monitor GitHub
- Vice PDB Monitor en CSDB
- Debugging 6502 assembly doesn’t have to be awful

7. Más herramientas
- Sprites con SpritePad
- Droid D64
- VChar 64 en GitHub
- VChar 64en CSDB

8. Dustlayer

9. Más tutoriales
- CodeBase 64
-
C64 Brain
- A full C64 game in 2013
- The bear essentials developing a Commodore 64 game

10. Más Ben Eater

Terminamos lo de las redes
- Networking tutorial 08 of 13 - The Internet Protocol
- Networking tutorial 09 of 13 - ARP: Mapping between IP and Ethernet
- Networking tutorial 10 of 13 - Looking at ARP and ping packets
- Networking tutorial 11 of 13 - Hop-by-hop routing
- Networking tutorial 12 of 13 - TCP: Transmission control protocol
- Networking tutorial 13 of 13 - TCP connection walkthrough

Electrónica y semiconductores
- Digital electronics tutorial
- How semiconductors work
- Stepping through a program on the 8-bit breadboard computer
- Comparing C to machine language
- Programming Fibonacci on a breadboard computer
- Building an 8-bit breadboard computer

11. Más Profedor Retromán

Ensamblador Z80
- Cargadores de Casete Propios
- Creando un Micro-GameEngine 1
- Creando un Micro-GameEngine 2
- Entidades con comportamientos variables
- Controlando un personaje con teclado
- Múltiples ficheros fuente, includes, símbolos globales y macros

C++
- C++ - Rvalue references, move constructor & move assignment operator

General
- Replanificación y entrega de producto
- ¿Por qué enseñar a programar en ensamblador?
- Clases de Teoría de Matemáticas

12. Math for Game Developers

Bajo un océano de bits, mes XVI

Dispérsense, aquí no hay nada que ver.

Estoy en una de esas épocas. En una de esas temporadas en las que soy incapaz de concentrarme para poder leer algo de manera continuada. Uno de esos lapsos de tiempo que pueden llegar a durar años.
Aunque mucho me temo que el problema no es únicamente ese.

Reviso mi perfil de Goodreads1 y veo que en estos momentos tengo en curso la lectura de diecinueve libros, trece de los cuales han sido añadidos como apoyo para este reto.
Durante los primeros pasos de este reto leí cuatro libros, dos de los cuales sólo dos de ellos eran puramente técnicos. Ambos me costó un horror terminarlos y, una vez despachados, seguía sin tener las cosas demasiado claras.

Es increíble la cantidad de capas de abstracción que es necesario atravesar para llegar hasta los niveles de concreción que requiere un programa. Y el problema es igual de complejo en ambos extremos.

La cantidad de factores que debes tener presentes si quieres llegar hasta los niveles más concretos es abrumadora. Cuanto más profundizas en esos niveles todo es a la vez más abstracto y más concreto, y quiero llegar hasta esos el último de ellos.

En estos momentos el juego es lo de menos, la programación sólo es un paso para entender lo que pasa dentro de la máquina. Quiero convertirme en un ingeniero sin hacer la carrera. Quiero un atajo para llegar hasta mi destino, pero para ciertos recorridos no hay un camino fácil.

Cada párrafo de cada uno de los libros que tengo empezados me ha hecho ir hasta sus fuentes, ir hacia un nivel anterior, aparcarlo y comenzar a leer otro libro que no tardo en dejar por otro. Y eso no tiene ningún sentido.
Necesito ir hasta el principio pero… ¿dónde está?.
Corrijo. La pregunta no es dónde está ese comienzo, sino dónde estoy yo. Si encontrar la respuesta a la segunda pregunta no puedo plantearme la primera.

Pero aquí hemos venido a hablar de mi plan. Sí, ese, y el otro, y el otro también.
Como decía el sabio, no existen planes perfectos, sólo intenciones perfectas.

Continúo con los vídeos del Fran Gallego2 y me parece que tengo la comprensión al alcance de la mano, a una interrupción sináptica de distancia, pero cuando trato de concretar sus palabras veo que realmente todo está mucho más lejos.
Bajo un nivel y veo a Ben Eater3. Todo se me hace más cercano y lejano al mismo tiempo, más concreto. Pero, a pesar de su tamaño de la circuitería, cuando trato de extrapolar lo que veo funcionando a la escala de las arquitecturas modernas, todo es abrumadoramente pequeño y se mueve a una velocidad tal que no soy capaz de visualizarlas.

Y, más allá de esto, para interiorizarlo todo, para terminar de encajar las piezas, tengo que mancharme las manos. Tengo que hacerlo yo de principio a fin. Y sé que en cuanto me ponga a ello encontraré nuevas carencias, que tendré que volver a bajar hasta otro nivel.

Voy bajando una y otra vez sólo para terminar regresando siempre hasta el punto de partida. Necesito ensuciarme las manos en algo que pueda terminar. En algo que pueda llevar a cabo en un periodo de tiempo concreto.

Así pues, una vez más, ¿cuál es el objetivo?
Supongo que el de siempre… ver hasta donde llego.
De acuerdo, reformularemos la pregunta:
¿Ensamblador, C++?
¿Qué camino vas a seguir?
¿Hacia dónde vas?

Por el momento seguiremos con ensamblador. En cuanto haga funcionar en Vim el resaltado de la sintaxis4 para x86, z80 y 6502 (y que no se pegue con el precompilador de YouCompleteMe) empezaré a meterme con los registros de esos cacharros.

A ver si con un poco de suerte la parada lectora termina y puedo continuar con alguno de los libros que tengo empezados.

Enlaces:

1. Mis lecturas en curso

2. Más profesor Retromán
Ensamblador
- Optimizando la Memoria en Amstrad CPC (Z80) #2
- Números pseudo-aleatorios en Amstrad CPC (Z80)
- Optimización del Compilador para Amstrad CPC (Z80)
- Físicas con coma fija en Amstrad CPC (Z80)
- Optimizando en Amstrad CPC (Z80) #3
- Optimizando la memoria en Amstrad CPC (Z80) #3
- Empezando con Ensamblador del Z80
- Empezando con Ensamblador del Z80 (II)
- Empezando con Ensamblador del Z80 (III)
- Depurando el salto del personaje en ensamblador de Z80
- Múltiples ficheros en ensamblador de Z80 con CPCtelera
- Obstáculos en movimiento en ensamblador Z80
- Teoría: Colisiones entre Bounding Boxes
- Tip: cómo optimizar detección de colisiones por frecuencias
- Revisión del proceso de ensamblado y ficheros
- Convertir y dibujar sprites en ensamblador con CPCtelera
- Convertir y dibujar mapas de tiles en ensamblador con CPCtelera
- Detección de colisiones en ensamblador Z80
- Estructuras de datos y objetos en ensamblador Z80 con IX #1
- Estructuras de datos y objetos en ensamblador Z80 con IX #2
- Estructuras de datos con macros en ensamblador Z80
- Reproduciendo música en ensamblador Z80 con CPCtelera
- Música por interrupciones en ensamblador Z80 con CPCtelera
- Revisión de dudas y Consejos en ensamblador Z80
- Efecto de scroll por software en ensamblador Z80
- Scroll por software + double buffer en ensamblador Z80
- Llamar a funciones en C desde ensamblador del Z80
- Revisión del Micro-GameEngine
C++
- C++: Sensores para Enemigos
- C++: Memoria dinámica, ejercicio de nivel intermedio 1
- C++: Memória dinámica, arrays y alineamiento
- C++: Profiling basico, optimización y caché
- C++: Gestión Avanzada de Memoria con Placement New
- C++: Ejercicio. Independizar el render
- C++: Strategy, pimpl y façade para independizar un renderer
- C++: Múltiples renderers. Análisis de código
Juegos de CPC para Android
- Crea videojuegos en Amstrad para millones de jugadores en 2019

3. Ben Eater
Redes
- Networking tutorial 01 of 13 - Sending digital information over a wire
- Networking tutorial 02 of 13 - Intro to fiber optics and RF encoding
- Networking tutorial 03 of 13 - Clock synchronization and Manchester coding
- Networking tutorial 04 of 13 - Analyzing actual Ethernet encoding
- Networking tutorial 05 of 13 - The importance of framing
- Networking tutorial 06 of 13 - Frame formats
- Networking tutorial 07 of 13 - Lower layers of the OSI model
Construyendo un ordenador de 8 Bits
- Learn how computers add numbers and build a 4 bit adder circuit
- Programming my 8-bit breadboard computer

4. Ensamblador para VIM
- Ensamblador de x86 para Vim
- Ensamblador de z80 para Vim
- Ensamblador de 6502 para Vim

Bajo un océano de bits, mes XV

Tras mucho demorarlo, finalmente, llegó el día.
Y quizás alguno se pregunte... ¿qué día? ¿el día de qué?.

A lo que respondería: El día en el que bajamos de nivel. Una respuesta que, en sí misma, tampoco es que diga gran cosa.

No, no voy a bajar el nivel de presión (algo que ya es de por sí bastante bajo). No voy a dejar esto.
Bueno, no voy a dejarlo… aunque sí.
Con esta respuesta tan intencionadamente ambigua lo que quiero decir es que abandonamos un nivel de abstracción para sumergirnos en la dirección de las simas más profundas. Bajamos un peldaño idiomático, nos dirigimos hacia las fosas abisales del ensamblador.
Un viaje de destino incierto y que veo complicado que finalice antes de que este reto llegue a su hipotético final.

Y la culpa de todo esto la tiene un hombre; Fran Gallego, el Profedor Retromán1
Como decía aquel, cada vez que veo uno de sus vídeos me doy cuenta de que no sé nada. No sé lo que sucede en la circuitería o en el procesador, no sé la cantidad de recursos que estoy consumiendo con cada comando, no sé en qué está convirtiendo el compilador las cosas que yo puedo considerar "ordenadas y claras".
No sé lo importante. No sé aquello con lo que tendría que haber empezado.

Así pues, toca cambiar de rumbo y profundizar, pero no a tontas y a locas. No voy a ponerme ahora a estudiar la arquitecturas de los procesadores x642, sino que me encuentro camino de algo mucho más básico y molón; Las tripas del MOS 65103, las entrañas del Commodore 64. Aunque, claro está, esto era algo que ya se veía venir de lejos.

Por supuesto, tengo intención de volver más adelante al C++, pero antes quiero entender lo que sucede entre bambalinas. Quiero saber cuántos ciclos de reloj le cuesta a la máquina ejecutar una orden, cuántos bits ocupan mis artefactos, cómo hablan entre sí cada uno de los elementos del ordenador, y esto es algo que me va a ser imposible con las arquitecturas modernas, no sólo por su complejidad intrínseca, sino también por la capa de abstracción y ofuscación que supone el mismo sistema operativo.
Confío en que, una vez entienda este tipo de cosas, ese conocimiento me ayudará a comprender la información que me proporcionan herramientas4 como Valgrind, C++ Insights o Compiler Explorer. Seré capaz de entender la razón detrás de la “Regla de los tres” (y la de los cinco). No quiero limitarme a repetir sin criterio alguno lo que he leído en los libros o los tutoriales.

Y, sí, también, y por supuesto, tengo un plan.
... sí, otro. Ya sabéis cómo va esto.

Borrón y cuenta nueva.
He comenzado a leer los manuales oficiales que venían con el ordenador5. Empezaré por el “Commodore 64 Users Guide” y continuaré por el “Programmer's Reference Guide”. Después de eso ya veré por dónde sigo, porque documentación hay para aburrir.

También ha dado comienzo la parte divertida, la del acopio de herramientas6, el tema de entenderlas, realizar una criba y saber cómo, dónde y cuándo usar cada una de ellas ya es otro mundo.

En algún momento indeterminado del futuro, muy probablemente cuando termine con los dos primeros libros, volveré a los curros de ensamblador para CPC del señor Gallego y trataré de ir alternando y replicando los ejercicios que propone para el Z80 con el 6510. Tengo claro que sus arquitecturas no se parecen en mucho, pero ambos son procesadores sencillos. Si logro entender ambos no sólo tendré una parte del camino recorrida ante lo que quiero hacer, sino que me aportaría una base no sólo para plantearme proyectos para el CPC o el Commodore, sino también para Spectrum, MSX, NES, Game Boy y Master System.
Soñar es gratis y los planes tampoco cuestan dinero. El tiempo y mi capacidad para comprender y asimilar la información ya son otro asunto.

Así que aquí me tenéis, a mi edad, escribiendo programas en BASIC para hacer que una pelotita recorra la pantalla de un lado a otro parpadeando como una condenada.

Enlaces:

1. El culpable
- Optimizando en C para Z80 en Amstrad CPC #1
- Optimizando en C para Z80 en Amstrad CPC #2
- Optimizando la memoria en Amstrad CPC #1
- Renderizado Sincronizado en Amstrad CPC
- Interrupciones y música en Amstrad CPC
- Estructuras de datos y funciones en ensamblador Z80 (Amstrad CPC)
- Depurando programas en Amstrad CPC (Z80)
- Renderizado con Double Buffer en Amstrad CPC
- Tips rápidos de programación en ensamblador 1
- C++ : Optimizando accesos básicos a la memoria caché
- C++ : Entendiendo y optimizando std::vector
- C++ : La regla de los tres, constructores y copias
- C++ : Constructores Delegados
- C++ : Operador asignación con copy-and-swap idiom
- C++ : Entendiendo emplace_back y placement new
- C++ : Copy-elision y Return Value Optimization (NRVO / RVO)

2. Gritones de transistores

3. MOS 6510
- El cerebro
- La máquina

4. Herramientas para C++
- Compiler Explorer
- CPP Insights
- Valgrind - Cachegrind manual
- C++ rule of three

5. Los libros
- Commodore books.
- Commodore 64 User's Guide
- Commodore 64 Programmer's Reference Guide
- Anatomy of the Commodore 64
- Assembly Language Programming With The Commodore 64
- What's Really Inside the Commodore 64
-
Cómo programar en Ensamblador x86

6. Herramientas para el Commodore
- CodeBase 64
- A$$emble it!
- C64 Dev kit
- CC65
- CC65 Documentaci
- CC65 en GitHub
- Relaunch 64
- Relaunch 64 en Github
- Relaunch 64 binarios de la última versión
- XA (xa65)
- Awesome C64

Bajo un océano de bits, mes XIV

Dejamos esto hace cuatro semanas con los ánimos a tope y lo retomamos un poco de aquella manera.

Después de la última entrada la cosa continuó mejorando un poco. Encontré un “fuga de memoria”1 en la clase dedicada a dibujar las imágenes y fui capaz de corregirla. Me las prometía muy felices hasta que llegó el momento de gestionar los eventos2 y determinar cómo iban a ser las interacciones con la aplicación.

Hasta el momento había trabajado con el código que se encargaba de estas tareas que venía en el curso, pero a la hora de tratar de hacer cosas distintas de cambiar un valor por otro la cosa se empezó a torcer.

Me explico.

Mi bucle principal es muy sencillo:

1 - Miro todo lo que pasa en el sistema y, mientras el valor “Salir” no tenga un valor verdadero, hago lo que se encuentra definido en un bucle infinito.

Bucle principal

Recolección de eventos

2 - Pregunto si se ha pulsado alguna tecla.

Captura de estado del teclado

3 - Se cargan las músicas e imágenes del modo de juego que tenga seleccionado.

Modos des programa

4 - Se vuelca todo eso en la pantalla principal.
5 - Le digo que no se flipe demasiado y que no pase de las 100 pintadas por segundo.

Hasta ahora no me había hecho falta precisión alguna a la hora de controlar la respuesta del teclado. Con que al pulsar una tecla esta asignase a una variable un valor concreto me era suficiente

Acción a realizar al pulsar una tecla en la presentación
Pantalla de presentación

Sólo había un estado posible.

Pero ahora, al ir al menú en sí mismo, la cosa se complica. Tenemos tres estados posibles:

Acción a realizar al pulsar una tecla en el menú
Menú principal

Cada vez que pulso una tecla, el valor de “opcion” (sin tilde), tendría que aumentar o disminuir en uno. Sencillo, pero no hay manera.

Y no hay manera porque el procesador es muy rápido. Entre que pulso la tecla y la suelto pasan varios ciclos de reloj y la pantalla se ha redibujado más o menos entre 4 y 10 veces (acordaos que le he dicho que, como mucho, lo haga 100 veces por segundo, pero aún así es demasiado para esta manera de gestionar las cosas). Así que, cada golpe de teclado, implica que el valor de “opcion” se incremente o disminuya en ese número.

He hecho un apaño con la función “precision” (también sin tilde)… pero no es muy precisa que digamos y sigo atrapado en este punto desde el mes pasado.
La documentación de SDL a este respecto3 no me ha ayudado mucho, el código en el que me baso tampoco. La manera que tiene de controlar el movimiento del cursor no tiene nada que ver con la mía, y no quiero copiar tal cual la suya. Como suelo decir siempre por aquí, quiero entenderlo.

Y no deja de ser una pijada. A la hora de mover bichos por la pantalla esto no importa nada porque, a pesar de trabajar con la resolución de un Commodore 64, recorrer los 384 pixels de altura de la pantalla o los 272 de anchura es una tarea mucho más sencilla de gestionar, pero quiero que esto funcione de la manera en la que lo he decidido (o rehacerlo todo, pero que todo quede como yo decida en base a unas razones que considere razonadas y aceptables).

Por supuesto, podría buscar otras librerías para hacer esto, o podría ponerme a copiar a otros. Podría dedicarme a ver los vídeos de Jonathan Blow4 o Fran Gallego5. Podría mandarlo todo a paseo y meterme con Unity 8 Bits6. Mirar como afronta estos problemas un centenar de personas pero, por más cosas que me vayan descubriendo las píldoras de conocimiento que van soltando, quiero hacerlo a mi manera.

Y no hay mucho más que decir por ahora más allá de…
Continuará.

Enlaces:

1. Memorias a la fuga

2. Los eventos
- Event
- Event loop
- Event driven programming

3. SDL y los eventos
- SDL Events
- Handling the Keyboard

4. Jonathan Blow y sus Game Engina Programmng

5. Fran Gallego
- C++: Optimizando costes básicos de acceso a memoria
- Fuentes propias de texto y código absoluto
- Volatile
- Compiler Explorer/a>

6. Unity 8 Bits

Bajo un océano de bits, mes XIII

Podría decirse que hemos empezado bien el año en lo referente al C++.
Podríamos decirlo, claro, pero, de hecho, mentiríamos (al menos parcialmente).

Porque el año, en sí mismo, empezó regulero.

Habíamos dejado este tema, como de costumbre, con una mezcla de esperanza y frustración sumada a las dudas habituales. Con la lectura de un libro, Programming - Princples and Practice Using C++, que sigue ahí comienzo polvo virtual en su página doscientos (de 1312).

Terminé el año pasado con la moral a media asta y con la sensación de que “todo mal”, el reto, el código, mi comprensión lectora y mi capacidad para llevar esto hasta algún punto al que merezca la pena llegar. Pero bueno, el reto no era llegar hasta ningún lado concreto sino ver hasta dónde conseguimos llegar, así que… veamos.

Este último mes ha seguido la misma tónica que los anteriores; una sucesión de pequeñas alegrías, hostiazos de realidad y, con suerte, algo de aprendizaje y recapacitación.

Comencé consiguiendo hacer algo que había estado persiguiendo desde hace tiempo, una función que me permitiese invocar a los objetos almacenados en los vectores de recursos por su nombre y no por su identificador.
A la hora de determinar el funcionamiento de la aplicación no supone nada. Es más, probablemente suponga un pequeño incremento en el consumo de recursos del ordenador, pero tanto a mi como a cualquier hipotético usuario que pudiese haber de este “motor” que estoy haciendo, nos haría las cosa un poco más sencillas a la hora de invocar a esos recursos.
Tenía la solución en la periferia de mis neuronas desde hace meses pero no ha sido hasta hace un par de semanas que por fin logré agarrarla.
En el código de la aplicación en la que me estoy basando esto estaba solucionado con un enumerador1, pero esta solución no me servía si quería que la clase que se dedica a gestionar de los recursos fuese dinámica (o lo que es lo mismo, no tener que tocarla ni recompilarla cada vez que añado un recurso adicional).

Tras jugar con vectores que contuviesen objetos “mixtos” (conjuntos de datos de tipo cadena texto y objetos del tipo de objeto que quería devolver) juntados en un "struct"2, al final opté por tener dos vectores por por cada tipo de objeto; uno para los nombres y otro para los objetos en sí mismos.

Cargando los recursos

Con esto puedo tener una única función consultora a la que invocan aquellas que devuelven el tipo de objeto concreto (Imagen, Color, Fuente, Sonido, Canción, etc...).

Buscando a los recursos

Con esto no pierdo la posibilidad de llamar a los objetos de la manera anterior, pero sí que me ahorro el tener que mirar a qué número corresponde cada uno de ellos:

Invocando a los recursos

Mientras hacía esto también rehice por completo la clase que se dedicaba a pintar el texto. Aún tengo que ser capaz de lograr que me muestre cosas como tildes y otros caracteres especiales, pero esa parte la voy a dejar para un poco más adelante.

Y la tuve que rehacer porque había cometido un error muy gordo a la hora de interpretar qué significaba definir una variable como “static” y eso me había vuelto un poco loco.
Por culpa de esto las cosas empezaron a fallar cuando di comienzo a la creación de la siguiente clase, la que se encarga de gestionar la animación de los objetos.

Cuando esta clase era invocada por más de una animación pasaba olímpicamente de todo valor posterior posterior al primero. Poner diferentes variables “static” en un único archivo no daba problema, pero cuando quería crear más de una instancia de cualquiera de ellas el resultado no era bonito (generalmente un pete en ejecución, que no en compilación).

Tras mucho leer y no entender, en un foro de Arduino vi lo más parecido que encontré a una respuesta, pero no era capaz de aterrizar el código unitario que presentaban en una estructura de clases.
Después de volverme loco, de hacer mil pruebas y de rehacer doscientas veces las clase “Menu”, “Animacion” y “Texto” logré hacer funcionar aquello, pero seguía sin estar convencido de cómo había quedado, y con razón.
Serendipias de la vida, esa misma noche las piezas encajaron en mi cabeza. La cosa había funcionado, sí, pero había sido por casualidad.

Estoy convencido de que lo habré leído mil veces en todos los libros que me he echado encima, pero no fue hasta esa noche con la cabeza apoyada sobre la almohada que las piezas encajaron y entendí una más tanto el papel que cumplen la declaración de variables como privadas y la función del constructor3.

Al día siguiente cambié las tres clases y todo funcionó. Rehice todo aquello que funcionaba de chiripa y quité todos los “static” que sobraba y funcionó, volví a replantearme las clases principales… y falló, pero porque me equivoqué con la sintaxis, no por un error de comprensión.

Y así he llegado hasta hoy a tope de ánimo. No hay como el ser cabezón para se capaz de derribar las paredes de tu estupidez gracias a tu férrea determinación y tu sólida estructura craneal.

Enlaces:

1. Ha llegado el enumerador

2. Las estructuras y sus cosas

3. De constructores y objetos

Páginas

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer