Entradas de la categoría ‘Zona friqui’

Cuando pensamos en las grandes innovaciones de la informática clásica solemos imaginar microprocesadores cada vez más rápidos, discos duros con capacidades que entonces parecían imposibles o tarjetas gráficas capaces de poner más colores y píxeles en pantalla. Sin embargo, durante los años ochenta existió otra clase de innovación bastante menos sofisticada que podía duplicar, al menos en determinadas máquinas, la capacidad útil de nuestros disquetes. La tecnología necesaria no podía ser más sencilla: hacer una muesca adicional en un trozo de plástico. Y no se trataba simplemente de una chapuza doméstica, porque llegó a existir una pequeña industria dedicada a fabricar herramientas cuya única misión consistía en practicar ese corte exactamente en el lugar adecuado.

Para entender por qué aquello funcionaba hay que regresar a la época de los disquetes flexibles de 5¼ pulgadas. Ordenadores como el Commodore 64, el Apple II y otros muchos sistemas domésticos utilizaban unidades que, en determinados modelos, disponían de una sola cabeza de lectura y escritura. Eso significaba que la unidad únicamente podía acceder a una de las superficies magnéticas del disco mientras este se encontraba introducido en su posición normal. Si queríamos utilizar la otra cara, la cabeza no podía desplazarse mágicamente hasta ella porque, sencillamente, no había una segunda cabeza al otro lado.

Dentro de la funda cuadrada de un disquete de 5¼ pulgadas había un disco circular flexible, normalmente fabricado con una base de poliéster y recubierto con material magnético. Aunque un disquete se comercializase como single sided, o de una sola cara, físicamente existía otra superficie magnética al otro lado. Ello no significaba necesariamente que el fabricante hubiese probado y certificado esa segunda superficie para almacenar datos con la misma fiabilidad, pero sí abría una posibilidad bastante evidente para cualquiera que se parase a pensar cómo funcionaba la unidad, ya que, si la cabeza sólo podía acceder a una cara, quizá bastaba con sacar el disco, darle la vuelta y volver a introducirlo.

Eso fue exactamente lo que empezaron a hacer muchos usuarios. Una vez llena la primera cara, extraían el disquete, lo giraban físicamente e intentaban utilizar la superficie posterior como si se tratase de otro disco completamente diferente. Desde el punto de vista magnético, la idea tenía sentido, pero existía un pequeño inconveniente mecánico. Las unidades de 5¼ pulgadas no se limitaban a leer el material magnético, sino que también utilizaban determinadas características de la funda exterior para saber cómo tratar el soporte que acababa de introducir el usuario.

Además de la gran abertura central y de la ventana longitudinal por la que la cabeza entraba en contacto con la superficie magnética, los disquetes podían incorporar otras referencias físicas. Una de las más importantes para esta historia era la muesca lateral utilizada por el mecanismo de protección contra escritura. Dependiendo del diseño de la unidad, la presencia o ausencia de esa abertura indicaba si estaba permitido modificar el contenido del disco. Cuando se daba la vuelta al soporte, la muesca original quedaba en el lado contrario y dejaba de encontrarse donde la unidad esperaba verla.

La solución consistió en practicar otra muesca en posición simétrica. De esta manera, al girar físicamente el disquete, la unidad volvía a encontrar la abertura en el lugar adecuado y permitía escribir sobre la segunda superficie. La modificación no aumentaba la densidad del soporte, no alteraba electrónicamente la unidad y tampoco activaba ninguna característica oculta del material magnético; simplemente engañaba a un mecanismo de detección extraordinariamente sencillo para permitir que el disco fuese utilizado en una orientación para la que su funda no había sido preparada originalmente.

Así nacieron los llamados flippy disks, cuyo nombre describía perfectamente su funcionamiento. Cuando una cara estaba llena, el usuario sacaba el disquete, le daba la vuelta —flip— y continuaba utilizando la otra superficie. En las máquinas compatibles, cada cara podía tratarse prácticamente como un disco independiente, de modo que un sencillo corte en la carcasa permitía obtener aproximadamente el doble de almacenamiento aprovechable.

Uno de los sistemas en los que esta práctica se hizo especialmente popular fue Commodore 64 con su unidad Commodore 1541. Un disquete formateado normalmente por la 1541 podía almacenar alrededor de 170 KB por cara, de manera que convertirlo en flippy permitía disponer de dos superficies independientes y superar los 300 KB de capacidad total. Visto desde un ordenador actual parece una cantidad ridícula, pero en aquella época 170 KB podían contener numerosos programas, documentos, partidas guardadas o una colección considerable de pequeños archivos.

La 1541, además, tenía una característica que facilitaba considerablemente el truco. Algunas unidades de disquete utilizaban el denominado agujero de índice, una perforación de referencia que, junto con un sensor de la unidad, permitía conocer la posición angular del disco durante su rotación. En sistemas que dependían de este mecanismo, darle la vuelta al soporte podía provocar problemas porque la geometría de las perforaciones dejaba de coincidir con la posición esperada. El sistema utilizado por la unidad Commodore 1541 no dependía de ese agujero de índice de la misma manera, ya que obtenía la sincronización necesaria a partir de la información grabada magnéticamente en las pistas. Aquello convertía a la unidad de Commodore en una candidata especialmente apropiada para utilizar discos invertidos.

La famosa muesca lateral, por su parte, tenía una función mucho más sencilla de lo que podría sugerir el truco, y es que estaba relacionada con la protección contra escritura. En muchos disquetes de 5¼, la unidad detectaba aquella abertura para determinar si podía grabar información. Si el usuario quería proteger el contenido, había de cubrir la muesca con una pequeña pegatina opaca, evitando así que la unidad autorizase operaciones de escritura. Al darle la vuelta al disquete, la abertura original dejaba de estar en la posición esperada, por lo que crear una segunda muesca simétrica permitía recuperar la posibilidad de escribir en la cara invertida.

Como ocurre con casi cualquier truco informático suficientemente popular, alguien terminó viendo una oportunidad comercial. Aparecieron herramientas diseñadas específicamente para convertir disquetes normales en flippy disks, conocidas habitualmente como disk notchers o diskette notchers. Su aspecto recordaba a una mezcla entre unos alicates, una grapadora y una perforadora de oficina. El usuario introducía el borde del disquete, apretaba la herramienta y esta retiraba un pequeño fragmento de plástico exactamente en la posición necesaria. No había electrónica, motores, circuitos ni ninguna clase de comunicación con el ordenador. Era, en esencia, un sacabocados especialmente preciso para disquetes.

Naturalmente, los propietarios de ordenadores domésticos de los años ochenta tampoco eran conocidos por comprar un accesorio especializado cuando el mismo resultado podía conseguirse con lo que hubiera por casa. Las perforadoras comerciales convivieron con toda clase de soluciones artesanales, y tijeras, cúteres, perforadoras de cuero, pequeñas limas, alicates modificados y plantillas caseras terminaron utilizándose para fabricar flippy disks. Un procedimiento bastante lógico consistía en tomar otro disco como referencia, marcar cuidadosamente la posición equivalente en el lado contrario y retirar una pequeña sección de la funda.

Había que hacerlo con cierto cuidado, porque dentro de aquella aparentemente robusta carcasa de plástico se encontraba una superficie magnética bastante más delicada. Un corte excesivamente profundo podía alcanzar el disco propiamente dicho, y dejar pequeños restos de plástico dentro de la funda tampoco era una idea particularmente buena. El soporte giraba a varios cientos de revoluciones por minuto y la cabeza trabajaba muy cerca de su superficie, así que introducir fragmentos de plástico, polvo o suciedad podía convertir un intento de ahorrar dinero en una excelente forma de destruir datos. Aun así, muchos usuarios adquirieron bastante práctica y algunos discos modificados artesanalmente presentaban un acabado sorprendentemente limpio. Otros parecían haber sido abiertos con los dientes, pero mientras la muesca estuviera aproximadamente en el lugar correcto podían funcionar exactamente igual.

La cuestión más discutible era si la segunda cara de un disquete vendido como de una sola cara resultaba realmente tan fiable como la primera. Que existiese material magnético por ambos lados no significaba necesariamente que las dos superficies hubieran pasado los mismos controles de calidad. La industria distinguía entre soportes single sided y double sided, y un fabricante podía certificar únicamente la superficie destinada oficialmente a almacenar información. La cara posterior podía funcionar perfectamente, presentar algunos defectos o empezar a producir errores después de cierto tiempo.

En la práctica, muchos usuarios comprobaron que una gran cantidad de discos de una cara podían formatearse y utilizarse por ambos lados sin ningún problema aparente. Aquello alimentó durante años la discusión sobre hasta qué punto existían diferencias reales entre determinados modelos comercializados como de una o de dos caras. La respuesta dependía del fabricante, de la época, del proceso de producción y de los controles de calidad aplicados. No era correcto asumir que todos los disquetes de una cara eran simplemente modelos de doble cara vendidos más baratos, pero tampoco era raro encontrar unidades cuya segunda superficie funcionaba sin inconvenientes.

La filosofía doméstica solía ser bastante pragmática: si la segunda cara podía formatearse, superar una verificación y guardar archivos sin producir errores, se utilizaba. Probablemente no era el lugar ideal para conservar la única copia existente de un trabajo importante, pero para juegos, programas fácilmente recuperables, copias temporales o software intercambiado entre amigos resultaba difícil resistirse a la posibilidad de obtener el doble de espacio sin comprar más discos.

Para comprender hasta qué punto podía resultar atractivo hay que situarse en la economía informática de principios y mediados de los años ochenta. El almacenamiento era caro y los discos duros se encontraban fuera del alcance de buena parte de los propietarios de microordenadores domésticos. Una colección de unas decenas o centenares de disquetes podía representar prácticamente todo el archivo digital de una persona. Programas, juegos, documentos y copias de seguridad ocupaban un soporte físico que había que comprar, etiquetar, ordenar y conservar. Si una caja de diez disquetes podía proporcionar, a efectos prácticos, veinte superficies independientes de almacenamiento, el ahorro resultaba evidente. Para estudiantes, aficionados y usuarios que intercambiaban constantemente programas, la diferencia tenía bastante más importancia que la que podemos imaginar desde un mundo en el que una diminuta tarjeta de memoria almacena millones de veces más información.

Además, un flippy disk no era exactamente equivalente a un disquete convencional de doble cara utilizado en una unidad de dos cabezas. En el primero, las superficies podían funcionar como dos discos independientes y era necesario invertir físicamente el soporte para pasar de una a otra. En una unidad de doble cara, en cambio, el hardware podía acceder a las dos superficies sin intervención del usuario. Esta diferencia explica también por qué algunos programas comerciales llegaron a distribuirse en discos que debían darse la vuelta manualmente. En determinados ecosistemas aquello dejó de ser un truco de aficionados y se convirtió en una forma perfectamente normal de distribuir software.

Los flippy disks resultan especialmente interesantes porque pertenecen a una clase de trucos informáticos que hoy parece casi arqueológica. No había que modificar el firmware, parchear el sistema operativo, instalar un controlador ni escribir una sola línea de código. El truco consistía en comprender la interacción entre el soporte físico, la unidad y sus sensores y modificar unos pocos milímetros de plástico para conseguir que el hardware aceptase algo que su diseño exterior no contemplaba directamente. Esa forma de enfrentarse a las limitaciones era muy característica de la microinformática de los años setenta y ochenta. Las máquinas tenían unas capacidades extremadamente reducidas comparadas con las actuales, pero muchos de sus mecanismos eran suficientemente visibles y comprensibles como para que un usuario curioso pudiera investigar cómo funcionaban. Era posible abrir el ordenador, estudiar sus conectores, observar cómo giraba un disquete, averiguar para qué servía cada abertura de la funda y terminar descubriendo que un problema de almacenamiento podía resolverse con una modificación puramente mecánica.

Y es por todo ello que ahí residía buena parte del encanto de los flippy disks. No añadían transistores, no aumentaban la frecuencia del procesador, no inventaban un nuevo sistema de codificación magnética y ni siquiera modificaban realmente la capacidad física del medio. Se limitaban a aprovechar una característica que ya estaba allí y que las limitaciones mecánicas de determinadas unidades dejaban sin utilizar. Miles de usuarios descubrieron que, en algunos ordenadores, la frontera entre quedarse sin espacio y disponer prácticamente del doble podía depender de retirar unos pocos milímetros de plástico. Y pocas veces en la historia de la informática se ha conseguido tanto haciendo, literalmente, un agujero en el sitio correcto.

Hubo un tiempo en el que instalar cualquier programa descargado de Internet parecía una idea perfectamente razonable. Nadie hablaba todavía de sandboxing, ni de permisos peligrosos, ni de telemetría invasiva. Windows apenas protegía al usuario de sí mismo y la mayoría de la gente ejecutaba archivos .EXE descargados desde páginas llenas de imágenes GIF parpadeantes sin hacerse demasiadas preguntas. En medio de aquel ecosistema delirante apareció una de las criaturas más extrañas y memorables de toda la Internet de finales de los noventa: BonziBuddy, el infame mono morado que durante unos años se infiltró en millones de ordenadores domésticos disfrazado de asistente virtual simpático.

A primera vista parecía completamente inofensivo. BonziBuddy se presentaba como una especie de ayudante inteligente para Windows, una mascota digital capaz de hablar, contar chistes, leer texto en voz alta y acompañar al usuario mientras navegaba por Internet. Visualmente era imposible olvidarlo: un gorila tridimensional de color púrpura que aparecía en el escritorio realizando animaciones absurdas mientras una voz sintética metálica saludaba al usuario con entusiasmo inquietante. En teoría, aquello era simplemente entretenimiento interactivo; en la práctica terminó convirtiéndose en uno de los ejemplos más claros de cómo la ingeniería social empezaba a dominar Internet muchísimo antes de que el término malware se popularizara entre el gran público.

La ciencia detrás de BonziBuddy representaba perfectamente el optimismo extraño de aquella época. El programa utilizaba Microsoft Agent, una tecnología desarrollada por el gigante de Redmond para crear personajes animados capaces de interactuar con el usuario mediante síntesis de voz. Era de la misma familia tecnológica de Clipo (Clippy, en inglés), el famoso clip de Office que interrumpía constantemente mientras escribías documentos dando golpecitos en el monitor, pero llevada a un extremo muchísimo más agresivo. En un momento donde tener elementos tridimensionales moviéndose por el escritorio parecía casi ciencia ficción, BonziBuddy impresionaba muchísimo a los usuarios domésticos. Hay que recordar el contexto: la gente personalizaba Windows con skins imposibles, barras transparentes, cursores animados y efectos visuales absurdos. Internet estaba llena de software experimental, caótico y profundamente hortera. BonziBuddy encajaba perfectamente dentro de aquella estética.

El problema era que el mono hacía bastantes más cosas, aparte de contar chistes malos. Poco a poco los usuarios empezaron a descubrir que el programa recopilaba información del sistema, monitorizaba hábitos de navegación y bombardeaba constantemente al usuario con publicidad y recomendaciones sospechosas. BonziBuddy actuaba como una especie de spyware primitivo disfrazado de mascota amigable. Hoy probablemente sería detectado inmediatamente por cualquier antivirus moderno pero, a principios de los 2000, la línea entre programa gratuito, adware y malware era extremadamente difusa. Muchísima gente ni siquiera sabía que existían diferencias reales entre esos conceptos. Si algo era gratis y funcionaba, bastaba.

Y ahí residía precisamente el verdadero genio perverso del programa. Técnicamente BonziBuddy no era un virus clásico, no destruía archivos ni explotaba vulnerabilidades sofisticadas del sistema operativo. Funcionaba usando algo muchísimo más eficaz: manipulación psicológica. El usuario instalaba el programa voluntariamente convencido de que estaba obteniendo una herramienta divertida o útil. Una vez dentro del sistema, el mono se convertía en una presencia constante y pegajosa. Modificaba configuraciones, añadía procesos al arranque, instalaba componentes adicionales y aparecía continuamente reclamando atención. El software no «hackeaba» Windows; «hackeaba» directamente el comportamiento humano.

La experiencia de convivir con BonziBuddy era profundamente extraña. Encendías el ordenador familiar y ahí estaba él, moviéndose lentamente sobre el escritorio CRT mientras el ventilador del Pentium III sonaba como un secador industrial. De repente una voz sintética espantosa lanzaba algún comentario absurdo o intentaba iniciar interacción contigo sin haberla pedido. Visto hoy resulta casi perturbador, y es que hay algo genuinamente inquietante en recordar aquellos asistentes digitales primitivos intentando comportarse como compañeros virtuales amistosos mientras recopilaban datos silenciosamente de fondo. BonziBuddy pertenecía a una época concreta de Internet donde el software todavía tenía una personalidad exagerada, caótica y ligeramente amenazante.

El programa además empezó a distribuirse empaquetado junto a otras aplicaciones gratuitas. Descargabas un reproductor MP3, un paquete de iconos, un gestor de descargas o cualquier utilidad shareware obtenida desde páginas sospechosas y, sin darte demasiada cuenta, terminabas instalando también el mono morado. Fue uno de los grandes precursores de la cultura del bundle basura que después invadiría Internet durante años. Muchas infecciones domésticas de principios de los 2000 empezaban precisamente así, como una instalación aparentemente inocente que acababa llenando Windows de barras de herramientas, spyware y programas residentes imposibles de eliminar completamente.

Las máquinas domésticas de la época sufrían especialmente con este tipo de software. Windows 95, 98, ME e, incluso, XP tenían arquitecturas bastante frágiles comparadas con los sistemas modernos. La gestión de memoria era limitada, la estabilidad general dejaba muchísimo que desear y cualquier programa residente adicional podía convertir el ordenador en un desastre lento e impredecible. BonziBuddy consumía recursos constantemente mientras convivía con ‘Kazaa’, ‘eMule’, ‘Winamp’, ‘Internet Explorer’ a tope de toolbars y una colección de procesos extraños ejecutándose en el inicio del sistema. Muchos pecés domésticos funcionaban permanentemente al borde del colapso total.

Lo fascinante es que BonziBuddy terminó convirtiéndose en símbolo de una Internet muchísimo más salvaje y experimental que la actual. Una red donde cualquiera podía distribuir software, donde nadie verificaba demasiado nada y donde instalar ejecutables aleatorios formaba parte normal de la experiencia digital. Era un ecosistema profundamente inseguro, sí, pero también increíblemente libre y caótico. Los usuarios aprendían seguridad informática precisamente después de infectar el ordenador varias veces, no antes.

Con el tiempo, Bonzi Software —la compañía detrás el engendro— terminó enfrentándose a denuncias y problemas legales relacionados con privacidad y publicidad engañosa. Poco a poco el mono desapareció de Internet, pero dejó una huella extrañísima en la memoria colectiva de toda una generación.

Hoy ver una captura de BonziBuddy provoca una mezcla muy concreta de nostalgia y terror tecnológico. Porque el mono morado no fue simplemente un programa molesto, fue uno de los primeros grandes ejemplos de algo que hoy domina Internet completamente, esto es, el software diseñado para explotar psicológicamente al usuario mientras finge ser su amigo. Y quizá lo más inquietante de todo es pensar que, en el fondo, gran parte de la Internet moderna sigue funcionando exactamente igual. Sólo que ahora los monos morados son muchísimo más sofisticados.

Hubo un tiempo, allá por los dosmiles, en el que Internet comenzó a hablar, pero no con voz humana. Hablaba con una voz robótica, metálica y, a ratos, inintencionadamente cómica. Hablaba con Loquendo (pronunciado /lo.cuén.do/). Pero todo aquello venía de mucho tiempo atrás.

Loquendo TTS (Text To Speech) fue uno de los sistemas de conversión de texto a voz más reconocibles de aquella década. Detrás estaba la empresa italiana Loquendo S.p.A., una derivación tecnológica de Telecom Italia que desarrolló motores de síntesis de voz en múltiples idiomas. Sin embargo, fue su versión en español la que se convirtió en estrella inesperada del circo digital. En particular, la voz masculina conocida como «Jorge» se ganó un lugar especial en la cultura digital en línea por su tono monocorde, su acento indefinible y una cadencia que, sin quererlo, aportaba más dramatismo que muchos actores profesionales.

Loquendo era, originalmente, una comunidad de investigación creada a mediados de los años setenta del siglo pasado por los administradores del IRI-STET (predecesora de Telecom Italia) en los laboratorios de CSELT (Centro se Estudio y Telecomunicaciones, en Turín) antes de convertirse en una compañía, en 2001. Aplicando la técnica de los llamados difonos (la unión de una consonante y una vocal, 150 en total en el idioma italiano), el grupo creó el primer sintetizador de voz alta gran inteligibilidad en 1975, al que llamaron MUSA (por sus siglas en inglés de Multichannel Speaking Automaton), y que demostró que aquello era más que posible con la tecnología de la época.

Posteriormente, en los años noventa, nació Eloquens, un sintetizador de voz multiplataforma para varios sistemas operativos —incluyendo DOS, Windows, System 7 y Unix— y también para tarjetas telefónicas con varios canales, como las usadas por las operadoras de telefonía italianas para obtener la dirección y la identidad del suscripto a la red.

Loquendo se hizo viral antes de que el concepto de «viral» existiera como tal. Su popularidad explotó gracias a la escena emergente de creadores en YouTube, cuando la plataforma aún era joven, tosca y libre. Para muchos adolescentes sin micrófono o sin ganas de exponer su voz, Loquendo era la solución perfecta: escribías el guion, lo pegabas en el programa, le dabas al botón de reproducir y ya tenías a Jorge leyendo tus pensamientos con la misma emoción que un cajero automático. Sin embargo, funcionaba. Funcionaba porque esa neutralidad robótica tenía una magia extraña, un carisma que se colaba en vídeos de terror, en tutoriales para hackear el Messenger, en historias inventadas de encuentros con lo paranormal o en los ranking de los 10 juegos más malditos de la historia.

Internet se llenó de narraciones leídas por Loquendo. Era omnipresente. En algunos rincones de YouTube, incluso parecía que no había otro modo de contar una historia. La estética era reconocible: fondo negro, letras rojas en fuente Comic Sans o Impact, música ambiental de Silent Hill y aquella voz artificial diciendo cosas como: «Hola, amigos de YouTube. Hoy les traigo una historia real que me pasó cuando tenía seis años».

El software no solo hablaba, también obedecía. Algunos usuarios descubrieron que podían manipular su entonación, insertar pausas o trucos tipográficos para simular emociones. Había cierta artesanía en usar Loquendo bien, como un doblaje artesanal de ciencia ficción de serie B. Incluso llegó a existir una especie de competencia por ver quién podía hacer decir a Jorge las frases más surrealistas y provocadoras sin que sonara ridículo…, o precisamente buscando que sonara lo más ridículo posible.

Con el tiempo, las voces sintéticas evolucionaron. Se volvieron más realistas, más cálidas, más humanas. Y con ello, paradójicamente, perdieron parte del encanto. Loquendo fue comprado por Nuance Communications en 2011 y, poco después, su motor de voz dejó de estar disponible para el público general. Los asistentes de voz como Siri, Alexa o Google Assistant tomaron el relevo, con sus dicciones limpias y calculadas. Pero ninguno de ellos hizo reír, asustó o narró absurdeces como Jorge. Ninguno pasó a formar parte de la mitología de Internet como lo hizo esa voz sin alma pero con tanto carácter.

A día de hoy, aún sobreviven cientos —sino miles— de vídeos con Loquendo repartidos por la Red como cápsulas de una época. Son vestigios de una Internet distinta, menos profesional, más caótica e infinitamente más libre. Escuchar a Jorge hoy es un viaje en el tiempo, una mezcla de nostalgia y risa, como leer tus propios mensajes de Tuenti o revisar una carpeta de GIF animados en un pendrive perdido.

Quizá nunca debimos dejar que Jorge se callara. O quizá su voz era sólo para aquel Internet que ya no existe. Pero, si prestas atención, si rebuscas entre los rincones de YouTube, es posible que todavía lo escuches decir aquello de «hola, amigos de YouTube…”.

Hubo una época en la que encender un PC era un ritual. No bastaba con apretar el botón y esperar, había que afinar el sistema operativo como quien templa las cuerdas de una guitarra desafinada por la humedad. El verdadero usuario de MS-DOS, el que tenía cicatrices de guerra en forma de sectores dañados, conocía el alma de su máquina: el dúo dinámico formado por AUTOEXEC.BAT y CONFIG.SYS. Y dentro de ese templo de inicializaciones místicas, se escondían pequeños conjuros oscuros, secretos que hoy suenan a hechizos: ANSI.SYS, ALT+255, PROMPT, CTTY, LH, DEVICEHIGH, etcétera.

ANSI.SYS era el chaleco de lentejuelas de MS-DOS. Cargándolo desde CONFIG.SYS, uno podía usar secuencias ANSI para decorar la consola con colores, mover el cursor, crear menús interactivos y —aquí viene lo jugoso— redefinir teclas. Con una línea bien puesta en el AUTOEXEC.BAT podías hacer que, por ejemplo, pulsar F1 lanzara QBasic, o que al pulsar la tecla X se abriera Norton Commander como si fuera magia. Más de uno se creyó un hacker por conseguir que al escribir «hola» se ejecutara un DIR /P. El efecto era tan espectacular para la época que en el instituto te convertías en el gurú informático si sabías hacer algo así, aunque fuera copiado de una revista.

AUTOEXEC.BAT consistía, en el fondo, en algo así como tu pequeño manifiesto personal. Desde ahí lanzabas los TSR (residentes en memoria), ajustabas la ruta del sistema, cargabas el teclado en español, dabas un poco de amor a la tarjeta de sonido con sus variables de entorno y, si eras un poco canalla, ponías un ECHO con mensajes intimidatorios al arrancar: «Sistema encriptado. Acceso restringido. FBI monitoring active». Le daba ese toque Matrix antes de que Matrix existiera.

Aquel ecosistema de pantallas negras y texto parpadeante era todo menos amigable, pero también era infinitamente moldeable. No tenías un entorno gráfico que hiciera el trabajo sucio por ti: tenías que pelear con la máquina. Y en esa pelea, el que sabía usar ANSI.SYS, el que conocía los códigos ALT, el que recitaba de memoria la diferencia entre SET BLASTER y SET PATH era un dios menor del instituto, una suerte de chamán digital que podía hacer cosas que parecían brujería.

Y si AUTOEXEC.BAT era tu carta de presentación ante el sistema, el comando PROMPT era el marco dorado que la adornaba. Con PROMPT podías modificar el aspecto de la línea de comandos a voluntad: mostrar la hora, el directorio actual, el número de unidad e incluso insertar colores si jugabas bien tus cartas con ANSI.SYS. Pero el verdadero arte estaba en poner mensajes personalizados que aparecían como si fueran parte del sistema. ¿Quién no tuvo alguna vez un PROMPT que decía algo como [SISTEMA SEGURO C:\>] o [\u@\h \w]\$ (intentando emular bash antes de que supiéramos qué era bash)? Eran tiempos en los que maquillar el mensaje del DOS era una forma legítima de expresarte, como tunear una Vespa con calaveras y luces verdes.

Luego estaba CTTY, un comando tan oscuro como potente. Cambiaba el dispositivo de entrada y salida del sistema. Lo que en la práctica significaba que, si lo sabías usar bien (o mal), podías bloquear el teclado, redirigir la consola a otro puerto o incluso dejar el sistema mudo e inservible si te pasabas de listo. Muchos bromistas de aula de informática jugaban a poner CTTY NUL en un AUTOEXEC.BAT ajeno y luego observaban cómo la víctima reiniciaba su PC solo para encontrarse con una pantalla negra y la impotencia absoluta. Era una forma de guerra fría con BIOS y disquetes como armas.

Los comandos LH y DEVICEHIGH eran los favoritos de los que se tomaban la optimización como un deporte olímpico. El objetivo era claro: liberar memoria convencional. Porque en los noventa, tener 640 KB libres era como tener un ático en Manhattan. Cualquier programa TSR que se pudiera cargar en la memoria alta era una victoria. Juegos como Doom, Monkey Island o Dark Forces exigían su trozo exacto de memoria convencional, ni un byte más ni uno menos. Y tú, con tu editor de texto y tus horas de ensayo y error, conseguías milagros. A veces, lograr ejecutar un juego requería una coreografía perfecta entre DEVICEHIGH, HIMEM.SYS, EMM386.EXE y una plegaria al dios de los registros segmentados.

Y, como no, estaba el truco sucio por excelencia: ALT+255. Una pulsación arcana que introducía un carácter ASCII invisible (el carácter 255, espacio sin romper). ¿Para qué? Para ponerle nombre a directorios o archivos que parecían vacíos o que no podías borrar fácilmente desde la línea de comandos. Un clásico: crear una carpeta llamada sólo con ese carácter y comprobar cómo el sistema se volvía loco al intentar acceder. Un truco barato pero eficaz para esconder juegos, fotografías «interesantes« o simplemente vacilar al compañero de turno.

Hoy todo eso ha desaparecido. Los sistemas operativos arrancan solos, se configuran solos, se actualizan solos y casi piensan solos. Pero con ello hemos perdido también esa sensación de control absoluto, de entender lo que ocurría bajo el capó, de meter las manos en la grasa del sistema operativo. Porque, reconozcámoslo, nunca te sentiste más poderoso que la primera vez que hiciste que tu PC dijera «Bienvenido, Pepito» al arrancar. Aunque fuera con un simple ECHO.

El autor de este humilde blog se complace en presentarles su libro ‘Desarrollo en MicroPython para Raspberry Pi Pico‘, una obra de consulta y aprendizaje ideal para todos aquellos que se quieran iniciar o deseen profundizar en la programación de placas microcontroladoras Raspberry Pi Pico en lenguaje MicroPython.

Raspberry Pi Pico es una placa microcontroladora de desarrollo de bajo costo fabricada por Raspberry Pi Foundation, un circuito integrado programable, capaz de ejecutar las órdenes grabadas en su memoria. Pico ofrece un rendimiento sólido para una variedad de aplicaciones de hardware de bajo consumo, por lo que puede ser dedicada a una amplia gama de proyectos, desde sistemas embebidos simples hasta dispositivos IoT (Internet of Things, o Internet de las cosas) más complejos.

Python es un lenguaje de programación interpretado simple, de propósito general y orientado a objetos. Además, es también de código abierto. Por su lado, MicroPython es una implementación ágil y eficiente de Python 3.0 —su última versión mayor, por el momento— que incluye un pequeño subconjunto de las bibliotecas estándar del lenguaje padre, la sintaxis y funcionalidad completa, y que, además, está optimizado para ejecutarse en microcontroladores y en entornos restringidos, como en el interior de Raspberry Pi Pico, entre otros.

Con el libro ‘Desarrollo en MicroPython para Raspberry Pi Pico’ aprenderás de una forma sencilla e intuitiva cómo programar una tarjeta Pico o Pico W (o sus hermanas mayores, Pico 2 y Pico 2 W) para que haga lo que tú quieras. Las posibilidades son infinitas, desde un sensor ultrasónico para detectar presencia hasta un servidor web para tus proyectos o una sonda de temperatura Bluetooth, pasando por controlar una pantalla de segmentos, una impresora térmica, un panel LCD o un motor de corriente continua. ¡Y mil cosas más!

Estás ante el manual de programación en MicroPython para Raspberry Pi Pico en español más completo del mercado. Cuenta con 377 páginas, fotografías, esquemas gráficos, ejemplos de código fuente y aplicaciones prácticas:

• Explicaciones detalladas, amenas y muy completas de todas y cada una de las características de la tarjeta Raspberry Pi Pico y de sus componentes, así como del lenguaje MicroPython.
• Infinidad de ejemplos prácticos de código fuente en MicroPython que sirven de explicación a cada uno de los capítulos, epígrafes y apéndices de información contenida en el libro.
• Rigurosos esquemas de conexión que explican los pormenores de la interacción de Raspberry Pi Pico con elementos externos, cables, pinzas, placas protboard, placas de pruebas, etcétera.
• Descripción minuciosa de proyectos completos de aplicación con fotografías, código fuente, explicaciones, conexiones y hojas de especificaciones de componentes.

Disponible, en Amazon, en dos formatos, a saber: Tabla blanda y versión Kindle.

---

CONTENIDO GENERAL DE CAPÍTULOS PRINCIPALES.

---

CAPÍTULO I • LA PLACA RASPBERRY PI PICO.

CAPÍTULO II • PROGRAMANDO PICO.

CAPÍTULO III • LENGUAJE PYTHON PARA PRINCIPIANTES.

CAPÍTULO IV • ¡HOLA, MUNDO!

CAPÍTULO V • LOS PINES DE PICO, QUÉ PODEMOS CONECTAR EN ELLOS Y CÓMO HACERLO.

CAPÍTULO VI • DESARROLLO BÁSICO DE APLICACIONES PRÁCTICAS.

CAPÍTULO VII • MÁS SOBRE LOS PINES DE PICO: EL MÓDULO machine y LAS CLASES Pin Y Signal.

CAPÍTULO VIII • ENTRADAS Y SALIDAS ANALÓGICAS: LAS CLASES ADC Y PWM.

CAPÍTULO IX • COMUNICACIÓN SERIE DÚPLEX: UART Y USART.

CAPÍTULO X • PROTOCOLO SERIE SÍNCRONO PARA PERIFÉRICOS: SPI.

CAPÍTULO XI • EL PROTOCOLO SERIE DE DOS HILOS: I2C.

CAPÍTULO XII • EL PROTOCOLO SERIE PARA AUDIO DIGITAL: I2S.

CAPÍTULO XIII • CONEXIÓN WI-FI CON RASPBERRY PI PICO W.

CAPÍTULO XIV • RASPBERRY PI PICO W Y CONEXIONES BLUETOOTH.

CAPÍTULO XV • IMPLEMENTANDO RASPBERRY PI PICO COMO DISPOSITIVO USB.

CAPÍTULO XVI • CONTROLANDO LOS TIEMPOS: LAS CLASES RTC, Timer y WDT del módulo machine.

CAPÍTULO XVII • EL SISTEMA DE ARCHIVOS LOCAL DE RASPBERRY PI PICO.

CAPÍTULO XVIII • NEOPIXEL.

CAPÍTULO XIX • FUNCIONES ESPECÍFICAS DE RASPBERRY PI PICO: EL MÓDULO rp2.

APÉNDICE A • ENTORNO DE PROGRAMACIÓN REPL.

APÉNDICE B • REFERENCIA DEL LENGUAJE PYTHON.

APÉNDICE C • SECUENCIAS DE ESCAPE.

APÉNDICE D • COMPILAR MICROPYTHON.

APÉNDICE E • RASPBERRY PI PICO|PICO W FRENTE A RASPBERRY PI PICO 2|PICO 2 W.

APÉNDICE F • ECONOMIZAR MEMORIA A LA HORA DE PROGRAMAR.

APÉNDICE G • DEPURACIÓN CON RASPBERRY PI PICO.

APÉNDICE H • CÓDIGOS DE ERROR DE PYTHON.

APÉNDICE I • ESCRIBIR BUENOS MANEJADORES DE INTERRUPCCIONES.

---

¡Disfrútalo, y a desarrollar para Raspberry Pi Pico!