Confidare Weblog

Mucha gente tiene buenos recuerdos de su época escolar, aquellos tiempos en los que sus únicas preocupaciones eran el colegio y los amigos. Algunos desarrollan amistades que trascienden aunque deban esforzarse en buscar el tiempo para cultivarlas entre las obligaciones de la vida de adultos.

Personalmente, tengo la suerte de haber formado mis más grandes amistades en los tiempos del colegio; siempre pertenecí a un solo curso y los recuerdos de la época tienen gran importancia en mi vida. Como grupo, nuestro problema permanente es mantener el contacto con los amigos que están lejos, ponerse de acuerdo con todos los integrantes del curso para reunirnos, y compartir el material —fotos, videos y grabaciones de audio— que producimos.

Habiendo buscado infructuosamente y durante mucho tiempo una herramienta que nos ayudara a resolver dichos problemas, en septiembre del año pasado en Confidare aceptamos el desafío de construir un software social dedicado exclusivamente a compañeros y ex-compañeros de curso. El 2 de octubre poníamos en línea la versión beta de Excolares, www.excolares.com y recibíamos las primeras registraciones.

Hoy Excolares ofrece un completo, diverso y gratuito conjunto de servicios a sus usuarios registrados, que incluye la publicación de historias (vía wiki) y fotos relativos a la promoción o curso, comunicación vía chat, mensajería instantánea y foros, entre otras características.

Así que ya sea que eres un pingüino escolar o un adulto nostálgico de tus tiempos de colegio, te invitamos a ti y a tus amigos a registrarte en Excolares.

Enlaces recomendados:

• Dar un paseo por Excolares
• Leer la Guía para usuarios nuevos
• Registrarse en Excolares

Es cierto, estos últimos tiempos han estado bastante movidos en todos los ámbitos, de manera que quedé muy atrás en las publicaciones de “El retroprograma de la semana”. Para empezar a ponerme al día, hoy presento a MINOTAUR.BAS.

¿Qué puedo decir sobre este programa? Lo más significativo consiste en que es el mejor ejemplo de un software que comienza siendo algo y va transformándose en el camino en una cosa diferente. Al principio, éste no era sino un ejercicio para demostrar un algoritmo simple de construcción de “laberintos”: se recorre una grilla de puntos en la pantalla y en cada uno de ellos se traza una línea hacia uno de los puntos circundantes vertical u horizontalmente.

Para ilustrar cómo el programa fue mutando voy a presentar una conversación imaginaria entre el área “creativa” y el área “ingenieril” de mi mente (cualquier similitud con el show “Dentro de la Cabeza de Herman” es mera coincidencia).

— Pero, ¿y si pudiéramos recorrer el laberinto con el teclado?
— Basta agregar un ciclo que lo consulte y en base a la tecla pulsada actualice nuestra posición en la pantalla (representada por un punto). Por supuesto, no dejaremos que atraviese las paredes o los bordes.

— Muy bien, pero, ya que estamos dentro, ¿por qué no darnos un objetivo?
— Creemos otro punto que aparezca periódicamente en una posición aleatoria de la pantalla, y que debamos “comernos” para recolectar puntos hasta un límite que nos permita abandonar el laberinto (y visitar el próximo).

— Pero es muy aburrido tomar largos desvíos para atrapar al objetivo. ¿Hagamos que nuestro punto pueda atravesar las paredes?
— Así tal cual el laberinto dejaría de tener sentido. Mejor simulemos una “excavación” del punto a través de la pared, o sea, que deba intentar avanzar unas cinco veces antes de derribarla. Para que se cumpla el principio de conservación de la masa, démosle un punto de recolección cuando lo haga.

— Esto es entretenido, pero, ¿dónde está el peligro?
— Muy bien, creemos un némesis que sea controlable con el joystick de manera similar a nuestro “punto” original, y pongámosle como objetivo atraparlo para que pierda. Para no confundirnos, llamemos al punto original “el recolector” y al nuevo “el perseguidor”.

— Pero, seamos realistas, ¿cada cuánto tiempo viene el Eduardo a jugar?
— Ya, ya. Pongámosle “inteligencia artificial” al perseguidor. Heurísticas simples nada más: hagamos que se mueva en la dirección del recolector hasta atraparlo o topar con una pared. Si lo segundo ocurre, hagámoslo moverse un poco perpendicularmente antes de seguir, a ver si se zafa.

— ¡Wow! ¡Cuando está cerca ese perseguidor es implacable!
— Ejem, bueno, no esperarías menos, pero, hagamos otro “para niñitas”, que simplemente rebote de acá para allá creando nuevas paredes que el recolector tenga que atravesar.

— Excelente, pero ¿y si variamos los tipos de laberintos? ¿y los tamaños de los pasillos? ¿y si hacemos que algunas paredes no sean cavables? ¿y si el recolector pudiese utilizar lo recogido para crear sus propias paredes y así bloquear al perseguidor? ¿y si el recolector tuviese un “botón de pánico”, que lo rodeara de paredes y lo salvara del perseguidor? ¿y si aparecieran líneas aleatoriamente mientras los puntos se mueven? ¿y si algunas de esas líneas fueran de un color “venenoso”, que hiciera perder inmediatamente al recolector al tocarlas? ¿y si integráramos esa nueva rutina que implementa un reloj de tiempo real, aunque no tenga nada que ver? ¿y si…
— !

Supongo que captan la idea. Así fue como terminé con este espagueti de código, de todas mis creaciones sin duda una de las más parecidas a Frankenstein. Ahora bien, aunque la gráfica sea en extremo simple, jugar MINOTAUR es entretenido. Bueno, al menos para mí

MINOTAUR.BAS. 12.4KB en memoria. 274 líneas. Escrito en 1993-1994.

(continue reading…)

Mi recuerdo más antiguo sobre el tema de los juegos inteligentes tiene que ver con el “Club de Ajedrez” de Quintero y la descripción de mi padre sobre una máquina contra la cual los participantes podían probar sus habilidades. Como nunca asistí a dicho club (de hecho, no conozco el ajedrez más allá de sus movimientos básicos), sólo sé sobre el ingenio que tenía distintos niveles de dificultad, y que a mayor dificultad, más (mucho más) tardaba en determinar sus movimientos.

Desde que empecé a desarrollar mis primeros programas me pareció interesante la posibilidad de imitar el pensamiento humano, de manera que cuando vi el tomo Juegos inteligentes en microordenadores de la Enciclopedia Práctica de la Informática Aplicada (Ediciones Siglo Cultural S.A., Octubre 1986) en el kiosko que solía abastecerme de libros antiguos a bajo precio, no lo pensé dos veces y lo compré (en realidad terminé comprando todos los tomos que había disponibles).

Sin embargo, a diferencia de otros volúmenes de la Enciclopedia, la mitad de las técnicas descritas (búsquedas en grafos) eran muy abstractas y no estaban lo suficientemente desarrolladas como para entenderlas a los 15 años y sin instrucción respecto a lo que una estructura de datos es. Por suerte, la otra mitad de las técnicas (sistemas de producción) sí eran abordables.

Fue así como terminé desarrollando este programa, que utiliza heurísticas sencillas para enfrentar al usuario en un duelo de “gato” (también conocido como “tres en raya” o “tic tac toe”). Cada vez que es su turno, analiza una lista de reglas en orden para determinar qué hacer:

1. Si hay una línea con dos casilleros ocupados por él, juega en el tercero para ganar la partida.
2. Si hay una línea con dos casilleros ocupados por el usuario, juega en el tercero para impedirle ganar.
3. Si el casillero central está vacío, juega ahí para afianzar su posición ofensiva.
4. Si ninguna de las condiciones anteriores se cumple, juega en cualquier casillero.

Por cierto que hay otras heurísticas que podrían mejorar el juego del programa (ocupar simultáneamente dos líneas perpendiculares, mantener la ofensiva adquiriendo dos casilleros en una misma línea); el hecho de que mi teclado se quemara debe haber influido en que no las incluyera. Como sea, la lentitud de un Atari es tal que, incluso con estas pocas reglas, el tiempo de respuesta es tan alto que uno puede imaginarse que está jugando contra una máquina de ajedrez profesional en su máximo nivel de dificultad.

GATO.BAS. 2.9KB en memoria. 86 líneas. Escrito en 1995.

(continue reading…)

Hay varios métodos para dibujar gráficos en el BASIC de Atari. Por ejemplo, con paciencia se puede usar PLOT y DRAWTO para crearlos prácticamente punto a punto; otra alternativa es usar las técnicas de jugadores y misiles (missile player graphics) para dibujar sprites predefinidos, incluso con detección de colisiones. La primera técnica se puede aplicar al modo gráfico 3 o superior; la segunda funciona en cualquier modo.

Desafortunadamente, la lentitud del BASIC de Atari limita gravemente el uso práctico de PLOT y DRAWTO para dibujar figuras que cambian en tiempo real; por otro lado, nunca tuve acceso a buena documentación acerca de la técnica missile player graphics, de manera que debía encontrar otra alternativa para desplegar mis naves espaciales y monstruos extraterrestres.

El tomo Gráficos animados con el ordenador de la Enciclopedia Práctica de la Informática Aplicada (Ediciones Siglo Cultural S.A., Octubre 1986) me sugirió la solución: redefinir el juego de caracteres del computador, que es el conjunto de símbolos disponibles en modo texto. Así podría hacer que una “A” se viera como una nave espacial (o una parte de ella), mientras la seguía generando como cualquier letra, con PRINT.

En un Atari, la estructura de cada caracter es almacenada en una matriz de 8 x 8 pixeles, lo cual, con un poco de imaginación es suficiente para representar varias figuras interesantes usando esta técnica. Por ejemplo, una inocente puede volverse una nave espacial disparando sus cohetes de propulsión () o su némesis ().

El problema es que el libro no poseía detalles de implementación para el BASIC de Atari, de manera que sólo pude extraer la idea. Sin embargo, tiempo después la fortuna quiso que descubriera en un manual de Atari un programa que sí la implementaba (ojalá recordara cuál fue). Ahí me di cuenta de que el juego de caracteres estaba almacenado en ROM, por lo que redefinir algunos no era tan sencillo.

Después de algunas cavilaciones construí mi propia implementación, que constaba de varios pasos:

1. Reservar 5 páginas de memoria (cada página es de 256 bytes).
2. Copiar el kilobyte de memoria correspondiente al juego de caracteres de la ROM a la RAM reservada (sí, ya sé que 4 x 256 = 1024, tampoco me explico por qué reservaba 5 páginas en lugar de 4).
3. Modificar el puntero que registra la dirección base del mapa de caracteres para que apunte a la base de la copia en RAM.
4. Alterar la copia del juego de caracteres a gusto.

Las nuevas definiciones de caracteres eran tediosas de generar: tenía que marcar una grilla de 8 x 8 en una hoja de cuaderno de matemáticas y rellenar los cuadros correspondientes a los pixeles que quería encendidos. Una vez satisfecho con los resultados, traducía mentalmente los cuadros pintados a unos y los vacíos a ceros y calculaba (generalmente a mano) la representación decimal del numero binario correspondiente a cada una de las ocho filas, con lo que obtenía ocho decimales listos para ser introducidos en una instrucción DATA. ¡Y todo esto por cada caracter redefinido!

Y entonces se me ocurrió la idea de crear este programa, que es básicamente una versión automatizada de lo mismo que yo hacía en papel y mentalmente. Genera una copia del juego de caracteres en RAM y permite modificarlos interactivamente mientras va calculando los valores decimales de cada fila. Por si fuera poco, además permite aplicar los cambios en forma inmediata, de manera de ver cómo queda el nuevo caracter. No usa colores porque en ese tiempo mi monitor era una TV NEC blanco y negro :-D.

DEFCHR.BAS. 2.2KB (texto) + 1.3KB (datos) en memoria. 52 líneas. Escrito en 1995.

(continue reading…)

Una de mis aficiones de adolescente era la grabación y edición de video en VHS. Dado que los Ataris son generadores de caracteres naturales al poseer una salida de RF, un programa que generase una “carta de ajuste” para pegar entre mis videos era algo factible y útil.

El programa utiliza el “avanzado” modo gráfico 10 (80×192px, 16 colores) y mediante llamadas a la operación XIO 18 va rellenando cada rectángulo de color (hacerlo pixel por pixel hubiera sido mucho más lento).

CAJUSTE.BAS. 2KB en memoria. 40 líneas. Escrito alrededor de 1994.

(continue reading…)

Para todo “atarista” que haya ido más allá de jugar Moctezuma o Mouse Trap, debe ser todo un hito el momento en que compra o construye un cable SIO2PC para traspasar sus viejos programas desde cassettes —o disquetes si tuvo suerte— al disco duro de su PC.

Y es que existe una gran diferencia, al menos a nivel sicológico, entre almacenar tan importantes creaciones en cassettes o disquetes de 5¼, donde en cualquier momento las podemos perder para siempre, y tenerlos en la seguridad de nuestro disco duro. Además, lo último nos permite verlas y usarlas en cualquier momento por medio de los emuladores de máquinas Atari disponibles para la plataforma PC.

Entre 1992 y 1995 llené 2 cassetes de 90 minutos con programas escritos en el BASIC de ATARI (me moría de ganas de aprender el assembler de 6502, pero nunca tuve acceso ni al ensamblador ni a su documentación). Hoy, para traspasar todo eso a mi disco duro me valí de los siguientes componentes:

• Un Atari 130XE.
• Mi vieja y fiel grabadora de programas Atari XC12.
• Una disquetera Atari XF551 con su correspondiente provisión de disquetes.
• Mi PC de escritorio.
• Un cable SIO2PC
• El software APE for Windows (podría haber usado un equivalente en Linux, pero como éste venía con el cable…).

Dado que la grabadora de programas es un “terminador” en la cadena de dispositivos SIO (tiene sólo un enchufe), no pude conectarla simultáneamente con el Atari y el PC (lo que habría sido ideal para traspasar los programas directo de los cassettes al disco duro). En lugar de ello, lo que terminé haciendo fue conectar primero al Atari la disquetera y a ésta la grabadora para pasar a disquete cada programa; luego de eso desconectaba la grabadora y ponía en su lugar el cable SIO2PC para copiarlos al disco duro.

En el proceso descubrí algunos hechos:

1. La confiabilidad relativa de los cassettes y la grabadora no han variado en 10 años. Todo el arreglo sigue fallando en la misma medida que antes, ni más ni menos.
2. Había más de 25 programas en los dos cassettes. Muchos originales y algunos adaptados de revistas o libros; algunos terminados y otros no tanto.
3. Mis juegos eran más divertidos de programar que de jugar.
4. Algunos programas no se ejecutan bien al tener el DOS cargado, porque hay menos RAM disponible. Uno ni siquiera alcanzó a cargar (¡Faltaron sólo 5 vueltas del contador!).