Viaje a los inicios de la Web ¿Cómo probar Viola Browser y Erwise

Viola WWW y Erwise fueron dos browsers pioneros

-junto con Midas browser- que precedieron a Mosaic, el browser desarrollado por NCSA que sería la base de la mayoría de los browsers que lo sucedieron (Netscape Navigator, Internet Explorer, Firfox y la lista sigue). Este es un breve paso a paso de cómo se puede crear el ambiente (una máquina virtual con el sistema operativo requerido Sun OS 2.6/Solaris 5.6 o similar) para poder ejecutar estos browsers.
Esta experiencia empezó hace algunas semanas cuando me propuse una experiencia (o un juego) que consistía en un tipo de arqueología de software. Gracias a internet en general y sites como archive.org tenemos a disposición el código fuente y a veces incluso archivos binarios de muchas piezas de software histórico. De esa forma, empecé por compilar para un linux de 64bits el código del servidor web CERN httpd, el primer servidor web que fue desarrollado por el equipo que lideraba Tim Berners-Lee a principios de los años '90 en el CERN. Esa experiencia puede verse en el siguiente video:


Después del servidor, los browsers
De entre los navegadores pioneros, el más popular y famoso fue el Mosaic, desarrollado inicialmente en el NCSA. Pero lo cierto es que lo precedieron algunos otros. El primer browser gráfico que corrió en el CERN solo podía ejecutarse en el sistema operativo Next OS, que equipaba las workstations Next. A ese browser del CERN, le siguieron Viola Browser, Erwise y Midas. Los tres fueron los browsers pioneros para sistemas Unix. El código fuente y algunos binarios (para arquitectura sparc) de estos browsers está disponible ahí afuera en la web, siguen los links:

Viola WWW:ftp://ftp.cuhk.hk/pub/packages/info-systems/www/viola/
Erwise:ftp://ftp.funet.fi/pub/networking/services/www/erwisE/

Además Pei Wei, autor de ViolaWWW mantiene activo el site viola.org que es una réplica del sitio web original donde fue ofrecido ViolaWWW al principio. A diferencia del servidor web, lograr compilar estas piezas de software en un sistema linux actual requiere un cierto trabajo de "portar" el software para que se entienda de manera adecuada con las APIs de X11 de las librerías más recientes. Algunas han cambiado bastante y ese esfuerzo no es trivial. Posiblemente a sus autores a gente más avezada que yo en eso les resulte acaso realizable, a mí me hubiera llevado bastante tiempo de prueba y error. Pero entre el código fuente se encuentran binarios que fueron compilados para la arquitectura Sparc, puntualmente las CPUs que equipaban las workstations de Sun y que corrían SunOS. El resultado de la experienca, ejecutando ViolaWWW y Erwise puede verse en el siguiente video:



¿Cómo recrear el ambiente de pruebas (SunOS/Solaris)?

Después de ver el video, un amigo me sugirió que sería interesante poder reproducir la experiencia. Siguen abajo algunas de las referencias que seguí para instalar ese antiguo SunOS:
Para emular una arquitectura Sparc en una de nuestras máquinas Intel x86 hay que utilizar la aplicación qemu-system-sparc. Una guía detalladísima sobre cómo instalar el SunOS 2.6 se puede encontrar en el siguiente link:
Running Solaris 2.6 Sparc on qemu-system-sparc in linux x86_64

La única diferencia en el procedimiento se encuentra en el modelo de networking elegido. Yo no tenía necesidad de usar el modo bridged de manera que opté por la configuración más sencilla que qemu tiene disponible -net user, de esta forma la vm guest va a utilizar un modelo similar a NAT. No es posible acceder al guest desde la máquina host, pero en mi caso me bastaba: solo necesitaba salir hacia internet y desde el guest poder comunicarme con el host, donde correría el servidor web. De manera que una vez que el OS guest (SunOs) estuvo instalado en el hd virtual, para iniciarlo se deben ejecutar las siguientes líneas en la consola:

$ export SDL_VIDEO_X11_DGAMOUSE=0 $ qemu-system-sparc -L . -m 128 -M SS-5 -vga cg3 -drive file=/path/a/disk1.img,bus=0,unit=0,media=disk -net nic -net user

La primera línea sirve para corregir un problema con el puntero del mouse que resultaba totalmente errático de otra forma. Quizá por esa misma razón, no pude utilizar software basado en ffmpeg para capturar la pantalla, ya que al intentar hacerlo se producía un conflicto con el puntero del mouse del guest. El resto de la experiencia puede verse en el video. Continuar »

Elogio de la conversación

Los podcasts no son nuevos. Están entre nosotros hace más de quince años. Ya a estas alturas todos nosotros, el público o los consumidores, los percibimos como una experiencia distinta a la radio.

Las líneas en este blog son solo unas observaciones preliminares y por lo tanto, también quizá provisionales. Parto de la base de algunos hechos: los medios tradicionales ya envejecieron pero dificilmente vayan a desaparecer. En ese sentido la oferta y la promesa del podcast es diferente. Posiblemente vengan a ocupar un nicho que nada ni nadie consiguió atender antes. Porque (por suerte) el podcast no es la radio, quizá venga a ofrecernos algo radicalmente distinto.

Icon made from Icon Fonts is licensed by CC BY 3.0

La radio de gran público (FM o AM, poco importa) ha envejecido, eso no es novedad. Con todo, es difícil que esos medios, junto con las tecnologías que lo construyeron (la transmisión de ondas hertzianas en modo "broadcasting") vayan a desaparecer por completo.
Cuando era adolescente con mis amigos escuchábamos regligiosamente cada noche un programa que se llamaba Historock. Iba por FM de la Ciudad que en aquella época se llamaba "la Metro". Teníamos más o menos la misma edad que hoy tiene mi hija mayor, con lo que quiero decir que ya ese tiempo me parece realmente lejano. Posiblemente el tiempo tienda a comprimir algunos hechos en mi memoria pero creo que por entonces, apenas si había TV por cable en algunas casas. Si tenías la suerte de que algún amigo por casualidad la tuviera, te ibas a pasar horas en su casa extasiado por los clips como el de "Last Dance with Mary Jane" de Petty al que acompañaba la misteriosamente bella Kim Basinger o "Gimme All Your Lovin'" de ZZ Top. Pero volvamos a la radio.
Historock era un programa que se emitía de lunes a viernes, de 22 a 24 hs. Repasaba al detalle, con información y muchísimas grabaciones, algunas realmente raras, la historia, como se imaginarán, del Rock. Desde los pioneros del sello Sun de Sam Phillips en Memphis, pasando por la explosión del rock y blues británico hasta "nuestros" días, que eran los días de nuestra contemporaneidad de entonces, más o menos cuando Nirvana lanzaba "Nevermind". Historock podía pasarte el disco entero "Thick As a Brick" de Jethro Tull (dos temas de 20 minutos cada uno), posiblemente porque iba por una radio pública. Por los motivos que fueran, lo hacían.
¿Por qué el ejemplo? Lo que vale de él no es ninguna anécdota. Sino que creo que ejemplifica un "modelo" o un tipo de contrato que la radio le proponía a sus oyentes que ya no existe como tal, o que por lo menos ya no forma parte de ningún "mainstream". Para nosotros, como para el resto de la audiencia, era claro que aquellos que conducían Historock eran la autoridad suprema en cuanto al conocimiento de la música que nos gustaba. Si algo queríamos era llegar a saber tanto como ellos. Tener tantos discos como ellos, o si el presupuesto era escaso -como lo era- al menos tener muchos cassettes grabados, pero escuchar mucha música al fin. El contrato o la forma en que la audiencía podía relacionarse con programas como aquel, era de tipo "pedagógico", un tipo de intercambio necesariamente complementario, en donde una instancia (la "emisión") es el que sabe y la otra instancia, los oyentes son los que quieren aprender.
Ese tipo de intercambio, en radio, televisión o el medio "masivo" que sea desapareció o quedó relegado a lugares marginales. Más cerca en el tiempo Alfredo Rosso encarnaba una posición similar, pero está muy lejos del mainstream de la radio actual.
Ese modelo "pedagógico" -ya fuera alrededor de la música o de algún otro tema- fue desapareciendo o pasando muy a segundo plano durante la década de los '90. Posiblemente y a muy a grandes rasgos la radio actual propone un tipo de intercambio basado en el contacto: vos estás ahí, nosotros estamos aquí. Y poco más, la radio como compañía presente. Aquello de lo que se habla a veces pasa a segundo plano. Pero la conversación no es demasiado central. Los media o lo que queda de ellos tienden a construir un star-system bastante berreta en algunas ocasiones.
Y ahora una valoración, supongo que pese a ser absolutamente subjetiva, quizá sea compartida. En la radio actual no encuentro nada. Nada que me retrotraiga a la escena originaria de Historock. No soy el mismo, claro, pero la radio tampoco es la misma. En la radio la música, al menos parte de las músicas que me gustan ya tiene una existencia totalmente marginal. Importa más un star system estúpido de periodistas que entrevistan mal o que aburren. La radio actual presupone que va a ser parte de un continuo sonoro y que sus oyentes harán escuchas "flotantes", mientras hacen otras actividades. Apagué la radio. Me voy con la música a otra parte.


(Por suerte) los podcast no son la radio

No temo en exagerar al decir que Internet, en tanto red de múltiples redes interconectadas y altamente resiliente a fallas (salvo la de nuestros paupérrimos ISPs), será una de las más grandes creaciones de la humanidad. No deja de llamarme la atención que un desarrollo originalmente militar (promovido y financiado por fondos para la Defensa de los Estados Unidos en tiempo de la Guerra Fría) se haya vuelto algo tan definitivamente "abierto" y "colectivo". Muchas teorías conspirativas hacen agua. Mi explicación quizá naif, mientras leo y reviso algunos libros como "Inventing The Internet" de Janet Abbate o "Where Wizards Stay Up Late" de Hatie Hafner, es que pese a ser un desarrollo completamente cerrado (en el sentido de secreto) llevó el presupuesto a organizaciones civiles -universidades y empresas- en donde había mucha gente que pensaba "más allá", pensaba en estándares, pensaba en intercambios entre iguales, eran si se quiere la expresión de una cierta contra-cultura. Lo que empezó siendo una red para asegurar las comunicaciones ante la eventualidad catastrófica de un ataque nuclear terminó siendo una de las mayores (sino la mayor) herramienta de interconexión que la cultura haya jamás construido.
De los orígenes de internet a los podcast hay una gran distancia. No podría recorrerla aquí. Pero la democratización a escala mundial de las computadoras primero y del acceso a la red después, puso a nuestro alcance toda una serie de herramientas antes desconocidas. Internet no es un "medio", es un paquete dinámico de diferentes medios de comunicación que pueden nacer, desarrollarse y también morir. Internet es la base técnica, la capa de base que permite esos diferentes intercambios.
Un podcast no es solo palabra hablada grabada. Para que "algo" sea reconocido y consumido como un podcast tendrá que tener ciertos atributos que lo caractericen como tal. Siguen un puñado de las que podrían ser a mi juicio algunas de las características específicas del podcast.

Palabra no institucional. En el broadcasting tradicional (la radio como la conocimos) siempre cualquier enunciación por más individualizada que sea en la voz de un locutor, (por poner un ejemplo histórico Antonio Carrizo) está siempre acompañada por otra "voz" en sentido figurado, que es la voz institucional de la propia broadcasting. En el mismo ejemplo histórico, el programa de Carrizo era "La vida y el Canto por Radio Rivadavia". La institución emisora en broadcasting siempre es responsable no solo por la calidad técnica de la emisión sino también por todo lo que se dijera en sus transmisiones. Cuando algún locutor (o locutora) tuviera un exabrupto o accidentalmente ofendiera algún tipo de sentimientos de algún grupo, la voz de la institución emisora se tiene que hacer presente para expresas que "esos dichos no coinciden con sus principios y blah blah.
El podcast es por definición palabra no institucional. Incluso aquellos podcast por ejemplo de periodistas de algún diario, su palabra en el podcast estará el alguna medida despojada de la visión "editora" de la organización a la que pertenece. Es palabra personal y en primera persona. La voz, como se ha dicho muchas veces es producto directo de nuestro cuerpo, es nuestro medio de expresión más directamente visceral, como la caja de un instrumento de cuerda determina su timbre y volúmen.

Un podcast se define por su periodicidad. Construir una audiencia no es sencillo, y la periodicidad más o menos regular manda. Un podcast no es un producto único, sino más bien el resultado de una cadencia de episodios más o menos regular.
En cuanto a su composición un podcast puede articularse sobre la voz de varios -dos o tres a lo sumo- "hosts" (presentadores a falta de un mejor término en .es) que regularmente participan de cada episodio y a los que eventualmente se le suman algún/os invitados. En otros el "host" es la voz regular y "dueño" del podcast y como interlocutor se le suma algún invitado. Posiblemente los podcast absolutamente en solitario (una voz única) sean los más raros, nuestra cultura tiende a desconfiar de los que hablan solos, pero en ese caso están solos con su audiencia.
Los podcast como medio, y quizá lo que su "lenguaje" tenga de interesante es que en algún aspecto vuelven a ponerle diversión al paisaje sonoro actual. En el podcast lo central es la conversación. Este es un tipo de intercambio que escasea en los otros media (los más o menos masivos, o lo que queda de ellos). Veamos por qué escasea: la conversación se define como un tipo de intercambio simétrico en el que dos iguales o pares interactúan a base de la palabra hablada. Se distingue de un intercambio como el del maestro y sus alumnos, del médico y su paciente, del entrevistador y el entrevistado, de la astróloga y sus clientes. Esos son, por el contrario, intercambios basados en la complementariedad o asimetría en donde uno "sabe" (o tiene algún poder) y el otro participante no.
La conversación requiere una cierta durabilidad, un desarrollo temporal que quizá ya no cabe bien en los media tradicionales. Quizá porque la radio presupone que todos sus oyentes hacen una escucha "flotante" entrando y saliendo en la temporalidad de la emisión. La conversación en cambio requiere del compromiso tanto de los interlocutores como de los "testigos" que son la audiencia del podcast. No creo que resulte sencillo escuchar un podcast con la atención "flotante", mientras trabajamos o hacemos otra cosa. En general el intercambio horizontal que se plantea entre los que conversan en un podcast tiende a reproducirse con su audiencia. La invitación, al menos en un contrato no explícitamente escrito es a ser testigo o parte de una conversación entre iguales.
Los podcast dificilmente recreen la escena originaria, de tono pedagógico y divulgador como era el ejemplo de Historock que citaba. Por el contrario, el podcast es un intercambio planteado y ofrecido más bien entre pares (por ejemplo "hecho por fanáticos de Linux para que lo escuchen fanáticos de Linux", o "Hecho por fanáticos de Ford, para que lo escuchen fanáticos de Ford).
¿Producto de nicho? Posiblemente, la complejidad actual de cualquier sociedad moderna está compuesta por miles de "mercados"/"tribus"/"subculturas" no importa qué nombre se les de. Posiblemente durante un mismo día surfeemos atravesando varias de esas sub-culturas. Pero en todo caso, la conversación es un bien escaso y como tal tiene un valor enorme, precisamente por ser un intercambio entre pares. Posiblemente hoy mientras sobrellevamos los días del confinamiento del covid, valoremos la conversación más que nunca, cómo la necesitamos a diario y todo su efecto terapéutico.
Lo que sí de alguna forma el podcast construye de nuevo es una manera de escuchar. Modo de escuchar que la radio de gran público abandonó. De manera parecida a como nos poníamos a escuchar religiosamente Historock el podcast requiere que lo escuches de principio a fin atendiendo al flujo de esa conversación. No es fácil tener buenas conversaciones, lo que sí es seguro es que ellas suelen tener un efecto poderoso sobre nuestras mentes.

retux (Matías Gutierrez Reto)


Continuar »

Meeprommer, grabador de EEPROMs. Notas sobre el troubleshooting.

Desde que era chico y tuve mi primera compu tuve curiosidad por cómo funcionaban los "cartuchos" con memoria de lecturá solamente, como los que también usaban, además de las primeras computadoras personales (msx, atari, commodore, etc) las consolas de videojuegos de segunda y tercera generación.

Los años pasan y por alguna profunda u oscura razones nos siguen gustando juguetes parecidos, a veces quizá algo más caro. Aunque los precios de la electrónica, con el tiempo fueron reduciéndose exponencialmente.
Aquí comento brevemente la construcción -y sobre todo el troubleshooting- de un grabador -diseñado por Mario Keller- de eeprom para aquellas computadoras de 8 bits.

Tiempo atrás, cartuchos como los mencionados solían utilizar EPROMs como la 2764 o 27256. Aquellas EPROMs requerían de exposición a una fuente de luz UV para su borrado. Normalmente se ponía un pequeño tubo UV en una caja estanca y se las exponía por un cierto tiempo, en general 10-15 minutos.

Posteriormente se desarrollaron las "Electrically Erasable Programmable Read Only Memory", que ya no tienen en su encapsulado la ventana para el ingreso de luz UV, porque se pueden borrar eléctricamente.
Hay EEPROMs con distinto tipo de buses, pero las de bus paralelo, como la 28C256 presentan un pinout retrocompatibles con las EPROMs de bus paralelo de generaciones previas, como la 27256.

Para que estas EEPROMs/EPROM puedan servir, por ejemplo para algún proyecto con algún microprocesador de 8 bits (z80,6809, etc) o para programar un cartucho para la Commodore 64 por ejemplo, es necesario usar un grabador. Hoy en día, los grabadores para EEPROMs de bus paralelo pueden ser relativamente costosos.

MEEPROMMER

MEEPROMMER es el nombre de un diseño de Mario Keller basado en un Arduino, publicado bajo licencia open source (MIT): https://github.com/mkeller0815/MEEPROMMER. El autor también desarrolló una aplicación Java que sirve para interactuar con el grabador, para grabar o leer datos desde la memoria, comparar la imagen con el contenido de la memoria, etc. El esquemático puede verse a continuación:

Aquí se puede ver el circuito montado, ya funcionando:

Para llegar a esto, fue necesario un troubleshooting bastante laborioso.

Sobre el troubleshooting

En varios aspectos un montaje electrónico se parece a cualquier otra artesanía: en general una vez montado el circuito en un prototipo o no, siempre es necesario dedicar tiempo al troubleshooting. Por errores humanos u otros factores, siempre algo puede fallar, algo habrá que mejorar o depurar. Estas notas son la historia de este troubleshooting, supongo que quizá le sean de utilidad a otros o posiblemente a mí mismo, cuando me haya olvidado de lo que tuve que hacer para detectar la falla.
Además de el proyecto en github, me fue muy útil para el troubleshooting la información disponible en este site en español: https://8bit65.wordpress.com/2014/09/04/programando-la-eeprom/
También los consejos de foros y de mi amigo el Bocha me fueron de gran utilidad.
Como en un troubleshooting de cualquier cosa, la técnica que me resulta más eficaz es dividir el problema en partes más pequeñas, hasta identificar las fallas.
El diseño de Mario se basa en dos shift registers (los chips 74HC595) que sirven para resolver el problema de la cantidad de pines I/O necesarios para el bus de direcciones (15) más el bus de datos (8) y pines de control de la memoria. Por supuesto, los pines de un arduino nano no serían suficientes. El registro de desplazamiento permite controlar 8 salidas al mismo tiempo, mientras solo se utilizan unos pocos pines del microcontrotrolados. Una buena explicación acerca del principio de funcionamiento puede leerse en: https://www.arduino.cc/en/Tutorial/ShiftOut

Luego de que las primeras pruebas indicaran que algo estaba fallando, para el troubleshooting del circuito seguí el siguiente orden:

1) Testeado del cableado en la placa experimental.

2) Se puede utilizar el monitor serie de arduino IDE o cualquier programa de comunicaciones serie, funcionando a 115200 bps para interactuar con el circuito, utilizando el protocolo que el autor implementó. Pasando un caracter 'V' nos mostrará los comandos disponibles y también se pueden ver con más detalle aquí: https://8bit65.wordpress.com/2014/09/04/programando-la-eeprom/

3) Prueba del bus de direcciones (salida de ambos shift registers). El código original de Keller tiene un comando muy útil para el troubleshooting: A,ADDRESS. Pasándole la dirección en hexadecimal, el bus de direcciones tendrá que asumir el valor dado. Así se encuentra documentado en el código:

// Set the address bus to an arbitrary value.
// Useful for debugging shift-register wiring, byte-order.
// e.g. A,00FF

Entonces el comando A,00FF habrá de poner los primeros 8 bits del bus de direcciones en 1.

Con un array de leds probé el bus de direcciones:

Con esto descubrí que había un problema con mi cableado del bus de direcciones que no había detectado en (1)

Corregido el cableado ahora el bus de direcciones comenzó a funcionar al 100%, pero por algún otro motivo la grabación de datos continuaba fallando.

4) Prueba de lectura: Para las pruebas también me ayudó bastante haber encontrado guardada una RAM estática, memoria que se graba y accede de una forma muy similar a estas eeproms.
Como puede consultarse en su hoja de datos, para concluir cada ciclo de escritura -ya sea de un byte, o de una página de 64 bytes- se lleva a cabo un proceso de "data polling". Se lee la salida del bus de datos, y una vez que esta coincide con el byte que se quería almacenar, concluye el ciclo de escritura.
Seguí el consejo de mi amigo el Bocha y uní algunas líneas del bus de direcciones con el bus de datos. De esta manera, podría setear una dirección arbitraria y leer un byte del bus. Si los datos coincidían la lectura estaría funcionando correctamente.
Agregué una función corta al código para esas pruebas y los datos concidieron. Las cosas empezaban a mejorar, direcciones y lectura funcionaban ok. Como para escritura se utiliza el mismo bus de datos, tenía certeza de que esas líneas estaban ok. Fue necesario además, poner unas resistencias de unos 10K entre los pines del bus de datos que no se usaban y masa, para evitar que en la lectura dichos pines quedara en estado indefinido.

5) El siguiente paso era intentar escribir apenas un byte en una dirección de la memoria y leerlo para ver si el valor conicidía. Para ello una breve función de tests:

void run_tests(void) {
//void fast_write(unsigned int address, byte data)
Serial.println("\nWriting \'c\' char to addr 0000...");
fast_write(0000,'c');
delay(100);
Serial.println("\nReading from addr 0000. Should get ascii 99 ...");
byte data = read_byte(0000);
Serial.print(" ");
Serial.print(data);
}

Esta prueba, con la SRAM tenía éxito, pero con la eeprom no. A esas alturas ya estaba bastante claro que el circuito se encontraba funcionando, pero algo fallaba en la interacción con la memoria eeprom.
La falla resultó ser bastante rara. Pero no solo me había ocurrido a mí. La eeprom tiene un código de bloqueo, que si uno desea establecerlo bloquea la eeprom. No se pueden borrar los datos, si no se envía antes el código de desbloqueo que el fabricante especifica.
Aparentemente, la EEPROM 28C256 que tenía (la única por el momento) había venido bloqueada.
Luego de envíar el código de desbloqueo el circuito empezó a funcionar correctamente.

No me queda más que agradecer a Mario Keller por compartir su diseño, a Marcel Van Kervinck

https://github.com/kervinck (su versión del código me ayudó para el desbloqueo), otros del foro 6502.org y a mi amigo el Bocha. Ahora solo queda darle algún uso interesante al grabador, para divertirse un rato con retro computing.
Continuar »