Tenía pendiente desde hace un tiempo escribir un artículo sobre el desarrollo de Retroterm, nuestra terminal multimedia multiplataforma, que nació en Commodore 64 y luego se expandió para soportar también Commodore Plus/4 y MSX.
Como algunos sabrán, en el año 2006 nos reunimos Diego Chiacchio, Pablo Roldán y yo, Jorge Castillo, y decidimos crear el foro de Retrocomputacion.com. De los tres, Pablo y yo, aunque en distintas épocas y ciudades, habíamos seguido caminos similares: fuimos usuarios de Commodore 64 y después de Amiga, programamos en lenguaje ensamblador e hicimos proyectos de electrónica. Pero no fue hasta 2020 con el proyecto Retroterm que empezamos a publicar software con el nombre Retrocomputación.
A diferencia de otros proyectos que empezaron por alguna necesidad concreta, por lo general para complementar otros desarrollos de hardware o de software, el desarrollo de Retroterm no fue algo planificado o siquiera esperado.
En el año 2019 estaba haciendo algunas pruebas de conexión entre retrocomputadoras, a veces a través de un cable RS232, otras veces a través de módems telefónicos. Se me ocurrió que pocos tuvimos la suerte de ver este tipo de cosas en los 80s, y empecé a publicar los videos en las redes. De los comentarios y las preguntas de la gente sobre los módems surgió la idea de hacer un video explicando como funcionaba esa antigua tecnología, y así inauguramos un nuevo canal de Retrocomputación en youtube, dedicado a videos orientados a lo educativo.
Lo que empezó como un video que iba a grabarse en poco tiempo terminó convirtiéndose en un proyecto de 4 meses, por lo que al finalizar decidí que el próximo video no iba a tener nada que ver con ese tema: haría un video sobre computadoras portátiles de los 80s, ya que tengo algunas para mostrar en funcionamiento.
A principios de 2020, pensando en como abordar la producción del video, me doy cuenta de que por el espacio físico limitado del que dispongo y por una cuestión de no limitarme a tomas fijas, se verían en pantalla otras computadoras y monitores que hay alrededor. Como no podía evitar que esos otros equipos aparecieran, se me ocurrió darles uso: haría un programa de presentaciones, para que la Commodore con su monitor mostrara imágenes relativas a las explicaciones del video.
Lo primero que hice fue preparar la interfaz RS232 para la Commodore, que se conectaría con un cable a una PC fuera de cámara, desde la que se enviarían imágenes y texto para ilustrar lo que se diría en el video. Luego había que escribir soft para Commodore que en principio recibiría texto por RS232 y lo imprimiría en pantalla, y escribir soft para PC que me permitiera editar y enviar el texto a la Commodore.
Para el lado de PC consideré escribir un programa en C para MSDOS, y usar una portátil antigua, pero después encontré la manera de hacerlo con Python en mi PC principal. Para el lado de Commodore, aproveché algunos experimentos que había hecho anteriormente para recibir datos por RS232 a una velocidad de 57600 bps. En principio no era necesario enviar datos desde la Commodore, ni siquiera tocar el teclado, ya que todo se controlaría desde la PC.
Una vez que logré el envío de textos desde la PC a la Commodore, el siguiente paso fue enviar imágenes. Cuatro años antes había hecho un experimento transfiriendo un bloque de datos binarios a máxima velocidad, pero el texto y los bloques de datos requerían dos tipos de recepción diferentes, así que había que integrarlos de alguna manera. La recepción de datos a 57600 bps fue un desarrollo anterior que hice para mis sintetizadores de voz con microcontroladores. Sin entrar en detalles muy técnicos, en la recepción de texto la idea era recibir pocos caracteres por segundo, porque con eso alcanzaba para un sintetizador, pero a la velocidad más alta posible, para usar muy poco tiempo por cada caracter. En la recepción de datos binarios en cambio, la idea es transferir todos los datos de una sola vez a máxima velocidad, pero esto nos obliga a apagar la pantalla en la Commodore, para evitar interferencias del chip de video. Durante la recepción de texto sí podemos mantener la pantalla activa.
Para coordinar todo esto la Commodore tenía que diferenciar si había que imprimir en pantalla lo que se recibía (modo texto) o si había que apagar la pantalla y recibir datos binarios a máxima velocidad (modo turbo). Decidí usar el caracter 255, que es un caracter gráfico repetido, como indicador para entrar a un modo comando, donde se podría cambiar de modo de recepción. Si el programa en la Commodore estaba en modo texto simplemente imprimiría en pantalla, pero si estaba en modo turbo tendría que prepararse para recibir datos y almacenarlos en memoria. Sin embargo esto no era suficiente para transferir una imagen, también hacía falta definir más comandos, entre ellos por ejemplo alguno para indicarle a la Commodore que había que cambiar el modo de pantalla. De esta manera se fue creando lo que ahora es el protocolo TURBO56K.
A esta altura tenía hecho un sistema que permitía enviar texto e imágenes a la Commodore, bajo control de la PC. Por pura curiosidad se me ocurrió probar si era posible hacer streaming de audio PCM (digitalizado) usando la transferencia turbo, y resultó que sí, aunque no sin antes corregir unos cuantos problemas de sincronización. En ese momento la función de streaming no tenía una utilidad práctica en el proyecto, simplemente se agregó “porque podíamos hacerlo”.
Es aquí cuando veo que a la Commodore sólo le faltaba leer el teclado y enviar los datos para convertirse en una terminal. Así es que el 2 de febrero, casi un mes después de haber empezado el desarrollo, nacía Retroterm, una terminal PETSCII con características muy particulares.
El programa en la PC se convirtió en RetroBBS, un pequeño servidor que mostraba un menú para que el usuario pudiera ver unos ejemplos de imágenes, escuchar un par de audios de prueba, y descargar unos juegos directamente a memoria. En esta etapa ya contamos con la ayuda de Ezequiel Filgueiras, quien se armó la RS232 y probó estas primeras versiones de Retroterm y RetroBBS, y tiempo después pondría en línea uno de los primeros RetroBBS públicos.
Retroterm cambió mucho en las primeras versiones: al principio el fondo no era negro, luego lo fue, se agregó el sonido de impresión, se agregó soporte para sintetizadores de voz, se agregó un puntero controlado por el ratón Commodore 1351, se fue aumentando la cantidad de caracteres recibidos por cuadro, y se eliminó el puntero. Para la versión 0.11, la última que hice, las características de la terminal estaban más o menos definidas.
El rumbo del proyecto cambiaría drásticamente cuando decidí cambiar la conexión por RS232 por una conexión inalámbrica a través de un módem wifi. Ahora no sólo podía controlar la Commodore desde la PC local sino también desde cualquier computadora conectada a internet. Las cosas empezaron a cambiar, ya no teníamos una conexión permanente entre Commodore y PC, sino que ahora había que establecerla llamando desde la Commodore. Es en este momento en el que Pablo se suma al proyecto desarrollando a partir de la versión 0.12, y también se encargaría de las versiones para Commodore Plus/4 y MSX. Pablo hizo dos contribuciones fundamentales en el inicio del desarrollo: mejoró la recepción a 57600 bps para que funcionara en todos los modelos de C64, y reescribió practicamente desde cero el código de RetroBBS. Pero para poner esto en contexto tenemos que volver un poco hacia atrás.
En el año 2016 escribí el código para enviar y recibir datos por RS232 a 57600 bps, para poder comunicar la Commodore con mis sintetizadores de voz. El sistema estaba implementado como una tarea de fondo sincronizada con la interrupción de video, de manera que se enviaba un caracter y se recibía otro en cada cuadro de video. De esta manera se podía controlar los sintetizadores de voz desde el BASIC cargando previamente el “driver” para la comunicación. Cuatro años después, en 2020, este código sería la base de lo que luego se convertiría en Retroterm.
Cuando usábamos la Commodore conectada a la PC por RS232, las respuestas por parte del servidor eran prácticamente instantáneas. Pero esto cambió cuando empezamos a usar el módem wifi, ya que estos tiempos no se cumplían de la misma manera, en particular los tiempos de respuesta al trabajar con RTS y CTS.
Para poder entender el comportamiento del firmware zimodem tuve que hacer capturas de la comunicación usando el único recurso que tenía a mano: una tarjeta de sonido capaz de capturar audio a 192 Khz.
Aunque esta resolución pueda parecer alta, apenas era suficiente para saber qué estaba pasando en la comunicación, pero no alcanzaba para medir tiempos precisos. Y aún así, después de muchas pruebas y mediciones, sirvió para lograr una comunicación estable.
Paralelamente a la versión estándar de Retroterm empecé a investigar si sería posible probar la terminal desde algún emulador, con algún hard que soportara 57600 bps y que estuviera emulado en lo posible en VICE. Resultó que la expansión Turbo232, que contiene un chip ACIA 6551, soportaba esa velocidad y estaba emulada en VICE. Este chip fue diseñado en una época en que las líneas RTS y CTS se usaban de otra manera, pero después de hacer unas cuantas pruebas se pudo hacer andar. Ya podíamos conectarnos a un RetroBBS desde cualquier PC.
Para entonces Retroterm empezaba a conocerse en Europa, y aquí es donde encontramos el primer problema importante: la comunicación fallaba en algún momento en las Commodore 64 PAL, en particular cuando se hacían transferencias turbo. Cuando empecé con Retroterm me encontré con la realidad de las diferentes velocidades de reloj del 6510, según el sistema de video de cada máquina (NTSC/PAL-N/PAL). Ya que la recepción se hace exclusivamente por software, la velocidad de reloj influye en los tiempos, pero habiendo hecho los cálculos concluí que a 57600 bps la diferencia sería mínima, por lo que decidí simplificar las cosas y usar como referencia un reloj de 1 MHz. Todo funcionó bien hasta que se probó Retroterm en una C64 PAL, un modelo que es muy difícil de encontrar en Argentina. Este problema quedó sin resolver por un tiempo, ya que no teníamos herramientas para detectar donde estaba el error.
Continuando con el desarrollo, Pablo había empezado a extender Retroterm usando la versión para ACIA desde VICE, y después se hace cargo también de la versión estándar para el puerto del usuario, publicando la versión 0.12. Aquí también hace un reordenamiento del código, la integración de las versiones estándar y ACIA en el mismo código fuente, y se empieza a publicar en github la versión 0.13. Estamos en el año 2021.
En esta etapa ocurre una sucesión de eventos que llevaron a la solución del problema de comunicación en máquinas PAL. William McCabe, el autor de un por entonces nuevo emulador llamado Z64K, quería soportar la versión de Retroterm para el puerto del usuario, entonces se contacta con Pablo y colaboran para lograr el primer emulador capaz de ejecutar todas las versiones de Retroterm. Luego de eso Pablo empieza a modificar el código de VICE logrando los mismos resultados, y en el proceso mejora la emulación de las comunicaciones en el emulador. La emulación del puerto del usuario resulta tan bien que puede conectar el módem wifi a la PC usando la versión de Retroterm para el puerto del usuario. De esta manera puede tener una idea clara de lo que ocurre durante la comunicación, lo que le permite ajustar el código de recepción de forma que sea compatible con todas las C64, resolviendo el problema que había quedado pendiente. Tiempo después las modificaciones son aceptadas por el equipo de VICE, y él se suma como desarrollador.
Terminadas las mejoras en el código de VICE, decide empezar el desarrollo de Retroterm MSX. Llevábamos un tiempo pensando cómo tendría que ser un port para MSX, y lo que se decidió fue que usaríamos el modo de pantalla 2, que nos daba la posibilidad de tener tanto bitmaps de 256×192 en 16 colores como un modo texto de 32×24, el cual habría que inventar. La idea era soportar en lo posible todas las funciones de Retroterm para Commodore, y ya que no conocíamos lo suficiente de la arquitectura como para lanzar el programa desde el BASIC, decidimos que sería mejor hacer un ejecutable para MSX-DOS, lo cual además nos dejaba toda la memoria libre para descargar juegos a RAM. En cuanto a la conexión, los planes inmediatos eran soportar la RS232 estándar, que pocos MSX incluían, mientras desarrollábamos nuestro propio módem wifi para el puerto paralelo. Por suerte Diego disponía de una Spectravideo SVI-738 que tenía todo lo necesario: unidad de disco incorporada para ejecutar MSX-DOS, y RS232 integrada. Yo había estado armando un módem wifi que pude probar con la SVI, por lo que ya teníamos todo lo necesario para el proyecto.
Aprovechando la experiencia del desarrollo de Retroterm usando VICE, Pablo decide seguir el mismo camino en MSX, investigando el código del emulador OpenMSX para hacer pruebas desde la PC con el mismo módem que usamos en hard real. De la misma manera que había ocurrido con VICE, esto termina en una reescritura del código de comunicaciones de OpenMSX, con cambios que después fueron incorporados oficialmente al emulador.
Mientras tanto, yo estuve diseñando un módem wifi para el puerto paralelo, y creando una terminal básica para probarlo: Microterm. Con la ayuda de Roberto Mandracchia se pudo armar un módem wifi con conector Centronics integrado y se pudo probar una versión limitada de Retroterm, pero este es un proyecto que recién empieza y todavía va a necesitar muchas pruebas para estar listo.
Con el tiempo Retroterm fue sumando características y se fue extendiendo el protocolo TURBO56K, incorporando comandos de manejo de pantalla, ventanas, pantalla combinada de texto y gráficos, streaming de música SID, y la descarga de archivos a disco. También se portó a Commodore Plus/4, donde funciona a una velocidad de 19200 bps usando el mismo módem wifi (zimodem) de Commodore 64, y a MSX, usando por el momento la RS232 estándar del sistema y en el futuro nuestro módem wifi para puerto de impresora, y el cartucho de comunicaciones BaDCaT.
RetroBBS, por otro lado, hoy es un servidor multimedia muy potente que soporta varias conexiones desde Commodore 64, Commodore Plus/4 y MSX. Retroterm incorporó desde muy temprano un sistema de identificación de terminal, que se fue extendiendo para permitir a RetroBBS detectar las características de esa terminal y su plataforma, de manera de adaptar el contenido al juego de caracteres, resolución de texto y gráficos, tipo de sonido y velocidad de conexión. A diferencia de las primeras versiones, que se basaban en contenido binario adaptado específicamente para Retroterm, el nuevo RetroBBS adapta el contenido en el momento, renderizando y componiendo bitmaps para la plataforma particular, o convirtiendo el sonido PCM de los formatos comunes a algo adaptado para la velocidad de esa terminal. Del desarrollo de RetroBBS salió el conversor de imágenes ClashState, que se puede ejecutar de manera independiente para convertir cualquier foto en bitmaps de Commodore 64, Commodore Plus/4, MSX y Spectrum.
En cuanto a mí, cuando dejé de mantener el código de Retroterm me centré en el contenido y la estética de RetroBBS, y en el diseño de circuitos de referencia para el armado de RS232 y módems wifi, que además se pueden ver desde Retroterm. La ironía de este proyecto es que nació porque no quería ver más módems, queriendo desarrollar un programa de presentaciones para un video sobre computadoras portátiles que nunca se hizo. Y al final, el video donde se usó Retroterm para ilustrar las explicaciones, fue el propio video dedicado a presentar Retroterm.
Durante mi tiempo desarrollando Retroterm surgieron otros proyectos relacionados, entre ellos el más obvio es la terminal Microterm para Commodore Plus/4, que estaba basada en el código de Retroterm para ACIA y nació simplemente porque no pude encontrar una terminal PETSCII para conectarme a BBS de Commodore 64. Esto sirvió después como base para portar Retroterm a Plus/4. Pero tal vez lo más inesperado fue el desarrollo de RetroLoader128 y Start Apps, que aunque no parezca deben su existencia a Retroterm.
Como algunos sabrán, la Commodore 128 es la retrocomputadora que más uso, por lo que al pensar en cual podría ser la segunda plataforma soportada por Retroterm, la elección fue obvia, sería la C128, por supuesto en modo 128. Aunque es un sistema bastante diferente, comparte mucho con la C64, por lo que no sería tan complicado adaptar la terminal, excepto por un detalle: no podríamos usar la descarga de juegos directo a memoria, ya que no podemos ejecutar juegos de C64 en el modo 128. Había que hacer algo al respecto.
Muchas veces antes había intentado hacer soft para la Commodore 128, pero después de leer una gran parte de la documentación técnica, todavía no terminaba de entender lo suficiente como para empezar. Esta vez estaba decidido a programar en modo 128, por lo que continué leyendo documentación sobre la memoria, la MMU y lo que ocurre al cambiar al modo C64. Después de hacer unas pruebas descubrí que no se perdía el contenido de la RAM al pasar a modo 64, sino que se perdía después al ejecutar la inicialización de la ROM. Si pudiera pasar a modo 64 de manera manual, evitando que la ROM borrara el programa, podría descargar juegos de C64 desde Retroterm128, para luego ejecutarlos reconfigurando la C128 como una C64.
No pasó mucho tiempo hasta que tuve código que me permitía cargar y ejecutar cualquier PRG de C64 desde el modo 128. Ya tenía lo que faltaba para poder portar Retroterm a C128. Sin embargo, en lugar de portar Retroterm, seguí desarrollando RetroLoader, que primero se integró en un menú hecho en BASIC, para que cualquiera pudiera armar su compilado de juegos de C64 booteable desde el modo 128. Luego se me ocurrió que sería más fácil si el propio programa obtenía la lista de archivos del disco en lugar de que el usuario tuviera que editar el programa BASIC. RetroLoader se había convertido en un navegador de archivos.
Por haber investigado el arranque de la C128, y porque ahora estaba usando RetroLoader128 como mi navegador preferido, tuve la idea de crear un cartucho para el zócalo U36, con un compilado de programas que tendría disponibles al arrancar la máquina. No sería otra cosa que una variación de RetroLoader pero en formato ROM, con un menú de programas en lugar del navegador. Así es como nace Start Apps, que por supuesto incluyó originalmente tanto Retroterm como RetroLoader128.
Del proyecto Start Apps también saldría otro proyecto: InDev Tester.
Pero eso es otra larga historia.
Más información:
Página del proyecto en Pastbytes: https://www.pastbytes.com/retroterm/
Retroterm en github: https://github.com/retrocomputacion/retroterm
RetroBBS en github: https://github.com/retrocomputacion/retrobbs