DEV Community: Baltasar García Perez-Schofield

Street Smart Coding

Baltasar García Perez-Schofield — Wed, 01 Apr 2026 13:15:38 +0000

Hace ya algún tiempo que tengo Street Smart Coding, un libro de programación escrito en inglés, por César Aguirre, uno de los escritores más prolíficos aquí en dev.to, y me propuse escribir una revisión del mismo.

Cuando lees este libro, te das cuenta de un detalle importantísimo, y que para mi valida su contenido como para recomendarlo a cualquiera: está escrito desde la experiencia. Es decir, no te dice cómo hay que hacer las cosas, sino cómo aprendió personalmente cómo hay que hacer las cosas.

Pongamos un ejemplo. He escogido este porque no tiene que ver directamente con programación, sino con lo que hoy en día se denomina soft skills. A mi me gusta más el término acuñado ya hace unos años: peopleware.

That day, I learned it's never just five minutes. Next time someone says "just five minutes," remember it could turn into 3:00AM the next day. Say no.

Encontraremos este párrafo en el capítulo Learn to say no, junto con Saying yes to everything often means saying no to the people who matter most. You need healthy boundaries instead. Sometimes, all it takes is one single word: no. Efectivamente, aprender a decir no es muy importante, tan importante que si no lo haces, puede implicar decir no a tus más allegados: los límites son importantes. ¿Pero, cómo puedes explicarle a un desarrollador junior que es importante saber decir no? La única forma es hacerlo a través de una experiencia personal (experiencia que encontraremos en ese capítulo, junto a las conclusiones ya mencionadas), y ahí es donde está la fortaleza real de este libro.

Never, ever, ever tell anyone they're wrong.

Efectivamente, siempre hay una forma distinta de hablar con alguien, incluso convercerlo de algo, más productiva, en lugar de decirle: "no, eso está mal." Personalmente, esto lo aprendí en mi trabajo como profesor; pronto me di cuenta de que decirle a un alumno que algo que había dicho estaba mal era la mejor forma de conseguir que dejase de participar en clase. Quizás en una relación profesor-alumno podemos asumir que decir "no, eso está mal", debería ser una posibilidad real y por lo tanto constructiva, pero no lo es. Así, una pequeña modificación de esa frase tan simple podría ser: "eso es cierto, pero también hay que tener en cuenta..." Y es que, la confianza de tu interlocutor en ti termina cuando le dices que algo está mal. Es indiferente si tienes razón o no.

Vamos con algo de código, C# en este caso:

var movies = [ "The Matrix", "Inception", "Interstellar" ];

string result = movies[0];

for (int i = 1; i < movies.Count; i++) {
    result += "," + movies[i];
}

César nos explica que podemos sustituir el código de arriba por el siguiente:

var movies = [ "The Matrix", "Inception", "Interstellar" ];

string result = string.Join( ", ", movies );

¿La diferencia? Que hay código que no escribimos nosotros. Efectivamente, siempre que abordo un proyecto cualquiera, siempre tengo que descender por debajo del nivel de abstracción en el que yo deseo estar; es decir, siempre que me planteo escribir código como el de arriba, me pregunto. ¿Para algo tan básico y repetitivo, no hay ya una función/clase/biblioteca que lo haga?

Podemos encontrar este ejemplo en Know your standard library. ¿Por qué no escribir código es algo importante? Porque podemos apoyarnos en código ya escrito, de manera que nos evitemos una tarea menor y repetitiva, reutilizando código que alguien ya se ha molestado en desarrollar y probar para nosotros, lo que nos permite centrarnos en el código realmente importante. No reinventes la rueda, apóyate en código de calidad, en cambio.

¿Por qué nos comenta el autor esto? Pues porque él mismo se ha encontrado con código similar, independientemente del lenguaje de programación, en casi todos los trabajos en los que ha estado. Volvemos así al aspecto de la experiencia personal.

Estos son solo unos pocos ejemplos de lo que puedes encontrar en Street Smart Coding. ¿Te lo vas a perder?

Un nuevo C: el C++ ligero.

Baltasar García Perez-Schofield — Mon, 23 Mar 2026 12:09:51 +0000

Buscando el camino

Hay muchas críticas que se le pueden hacer a C++: que si permite comportamiento indefinido sin avisar (incluso lo aplica en el modo de optimización más agresivo), que si ha crecido hasta límites desmesurados, que si el precio a pagar es el de unos ejecutables monstruosos... Últimamente, la crítica se ha centrado en la seguridad del manejo de la memoria. Por ejemplo, la Casa Blanca ha pedido pasarse a lenguajes más seguros, como por ejemplo C# o Rust. La NSA ha emitido recomendaciones similares sobre abandonar C y C++. Incluso la Wikipedia tiene una página dedicada a las críticas a C++. Esta crítica a C++ no ha sentado nada bien a Bjarne Stroustrup, el creador original del lenguaje de programación C++.

En cualquier caso, todo esto lo que ha provocado es que hayan surgido nuevos lenguajes de programación para sustituir a C++, siendo los más conocidos C# y Java.

Pero esto no quiere decir que no existan muchos más, que han surgido buscando eliminar puntos de fricción de C++, simplificar la experiencia de programación, y aportar sus propias características. Notables menciones son Zig, V, o Rust.

En 2013, Bas vd Berg creó C2, una evolución del lenguaje de programación C con el objetivo de eliminar complejidad innecesaria. Por ejemplo, no presenta archivos de cabecera .h, no hay macros...

El lenguaje de programación C3 se basa en C2 para ofrecer un mismo objetivo, pero además con ciertas capacidades que lo acercan a C++. Y este es el objetivo de este artículo.

C3

El ¡Hola, mundo! en este lenguaje de programación es como sigue a continuación.

import std::io;

fn void main()
{
    io::println("¡Hola, mundo!");
}

Para compilarlo, aunque podríamos haber creado un proyecto completo, podemos simplemente hacer:

$ c3c compile holamundo.c3
$ ./holamundo
¡Hola, mundo!

Las diferencias sintáticas con C son muy pocas: las funciones van ahora precedidas de fn, de manera que se distingan facilmente de cualquier otra estructura. No hay archivos de cabecera, sino verdaderos módulos que son utilizados mediante import. El significado, la semántica del programa, es mucho más evidente que en C.

El siguiente es un programa que trata de generar ternas pitagóricas a partir de números aleatorios.

import std::io;
import std::time;
import std::core::string;
import std::collections::list;
import std::math::random;


struct Terna {
    ulong a;
    ulong b;
    ulong c;
}

fn bool Terna.chk(&self)
{
    ulong sqa = self.a * self.a;
    ulong sqb = self.b * self.b;
    ulong sqc = self.c * self.c;

    return ( sqc == ( sqa + sqb ) );
}

fn String Terna.str(&self)
{
    return string::tformat( "(%d, %d, %d)", self.a, self.b, self.c );
}

fn void main()
{
    random::Lcg128Random rand;
    List{ Terna } l;

    io::printn( "Ternas pitagóricas\nCalculando..." );

    l.push( { 3, 4, 5 } );

    ulong i;
    for(i = 0; i < 1_000_000_000; i++) {
        Terna t = { rand.next_long(), rand.next_long(), rand.next_long() };

        if ( t.chk() ) {
            l.push( t );
        }
    }

    io::printf( "%d ternas encontradas tras %d ciclos.\n", l.len(), i );

    foreach(Terna t: l) {
        io::printn( t.str() );
    }
}

El programa crea una estructura Terna, que consta de tres enteros long (128 bits) sin signo. La idea es que la suma de los cuadrados de a y b debe ser igual a c. Esta propiedad se verifica mediante el método Terna.chk(). El método Terna.str() devuelve los valores de la terna como texto.

Así que utilizamos Lcg128Random del módulo std::math::random para generar enteros de 128 bits. Con un bucle, probamos a generar números aleatorios, y si se crea una terna válida, se añade a una lista (esta lista puede crecer dinámicamente).

C3 se siente bastante directo, fácil de comprender (no existe una nueva sintaxis), con un compilador que genera ejecutables rápidamente, y que son muy rápidos ellos mismos.

$ c3c compile ternas_pitagoricas.c3
$ ./ternas_pitagoricas                                                  Ternas pitagóricas
Calculando...
1 ternas encontradas tras 1000000000 ciclos.
(3, 4, 5)

El ejecutable realiza mil millones (1 000 000 000) de ciclos en unos 17 segundos de manera consistente. Esto involucra crear una terna, llamar su método chk() (que consiste en un cálculo matemático), y añadirlo o no a una lista.

$ time ./ternas_pitagoricas
Ternas pitagóricas
Calculando...
1 ternas encontradas tras 1000000000 ciclos.
(3, 4, 5)
./ternas_pitagoricas  16,38s user 0,00s system 99% cpu 16,438 total

$ time ./ternas_pitagoricas
Ternas pitagóricas
Calculando...
1 ternas encontradas tras 1000000000 ciclos.
(3, 4, 5)
./ternas_pitagoricas  16,35s user 0,00s system 99% cpu 16,402 total

$ time ./ternas_pitagoricas
Ternas pitagóricas
Calculando...
1 ternas encontradas tras 1000000000 ciclos.
(3, 4, 5)
./ternas_pitagoricas  16,31s user 0,00s system 99% cpu 16,368 total

El ejecutable es de unos 700 k, como se muestra a continuación.

$ ls -l ternas_pitagoricas                                             
-rwxr-xr-x 1 baltasarq baltasarq 702640 mar 23 12:13 ternas_pitagoricas

¿Podemos compararlo con una versión C++? Pues claro.

#include <string>
#include <list>
#include <cstdio>


class Terna {
public:
    Terna(ulong a, ulong b, ulong c)
        :a(a), b(b), c(c)
    {}

    bool chk() const
    {
        ulong sqa = a * a;
        ulong sqb = b * b;
        ulong sqc = c * c;

        return ( sqc == ( sqa + sqb ) );
    }

    std::string str() const
    {
        return std::to_string( a )
                + ", " + std::to_string( b )
                + ", " + std::to_string( c );
    }
private:
    ulong a;
    ulong b;
    ulong c;
};


int main()
{
    std::list<Terna> l;

    printf( "Ternas pitagóricas\n" );

    ulong i = 0;
    l.push_back( Terna( 3, 4, 5 ) );

    for(; i < 1000000000ul; ++i) {
        Terna t( std::rand(), std::rand(), std::rand() );

        if ( t.chk() ) {
            l.push_back( t );
        }
    }

    printf( "%lu ternas encontradas tras %lu ciclos.\n", l.size(), i );

    for(Terna t: l) {
        printf( "%s\n", t.str().c_str() );
    }
}

La salida devuelve la solución tras mil millones de ciclos en unos 17 segundos de manera consistente.

$ g++ ternas_pitagoricas.cpp -o ternas_pitagoricas
$ time ./ternas_pitagoricas
Ternas pitagóricas
1 ternas encontradas tras 1000000000 ciclos.
3, 4, 5
./ternas_pitagoricas  17,20s user 0,00s system 99% cpu 17,270 total

Obtenemos un resultado similar. Esto no es extraño, pues aprovecha el backend de LLVM.

En este caso, C++ es capaz de generar el ejecutable más pequeño, aunque es cierto que no se emplea la estructura de entrada y salida oficial, IOStreams. También es importante notar que el ejecutable enlaza con la librería estándar de C++, que no es, precisamente, pequeña (unos 3 MB). C3 genera, por otra parte, un ejecutable que es autocontenido.

$ g++ ternas_pitagoricas.cpp -o ternas_pitagoricas    
$ ls -l ternas_pitagoricas
-rwxr-xr-x 1 baltasarq baltasarq 44320 mar 23 12:54 ternas_pitagoricas
$ ldd ternas_pitagoricas                                                
        linux-vdso.so.1 (0x00007faefdf04000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007faefdc00000)
        libm.so.6 => /usr/lib/libm.so.6 (0x00007faefdae2000)
        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007faefdab5000)
        libc.so.6 => /usr/lib/libc.so.6 (0x00007faefd8c4000)
        /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007faefdf06000)

$ c3c compile ternas_pitagoricas.c3                                    
Program linked to executable './ternas_pitagoricas'.
$ ldd ternas_pitagoricas
        linux-vdso.so.1 (0x00007fad32973000)
        libm.so.6 => /usr/lib/libm.so.6 (0x00007fad32796000)
        libc.so.6 => /usr/lib/libc.so.6 (0x00007fad325a5000)
        /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fad32975000)

¿El sucesor oficial, o al menos un lenguaje estable? Es difícil decirlo, solo el tiempo lo dirá.

Hackeando en 8 bits (y IV)

Baltasar García Perez-Schofield — Mon, 16 Mar 2026 17:43:35 +0000

Y vamos a terminar ahora con la serie dedicada a hackear juegos en el Speccy, lo que se conocía en la época como desprotegerlos. Vamos a buscar vidas infinitas em Abu Simbel Profanation e Ikari Warriors. Y como herramienta, utilizaremos em emulador de Spectrum Zesarux.

En la última entrega de esta serie, vimos a grandes rasgos cómo crear uno de aquellos cargadores que proporcionaban vidas infinitas o bombas infinitas, o cualquier otro cheat, metiendo POKEs justo antes de la ejecución del programa.

Pero en esta entrega vamos a centrarnos en otro tipo de hack: simularemos que tenemos un Multiface. Este aparato permite, conectado a la parte trasera del Speccy, pulsar un botón rojo que genera una NMI (Non Maskable Interruption o interrupción no enmascarable). Al pulsar el botón, al Speccy no le queda más remedio, esté haciendo lo que esté haciendo, que ejecutar el código del vector de interrupción dado, lo que ejecuta su software mientras el software está en memoria. Lo que se podía hacer entonces era guardar el contenido de la memoria (con lo que podías guardar el juego tal cual se estaba ejecutando en ese momento), introducir POKEs, o explorar la memoria.

Vamos a simular, como decía, la forma de utilizar un periférico como Multiface, pero con la comodidad de un emulador de hoy en día. Todo lo que vamos a hacer aquí se puede hacer con dicho aparato enchufado y siguiendo sus instrucciones, pero lógicamente es mucho más tedioso.

Abu Simbel Profanation

Este juego fue creado por Víctor Ruiz para su sello familiar (compartido con sus heramanos), Dinamic. Según las entrevistas que se le han hecho con el tiempo, fue creado en una especie de versión más limitada de BASIC, que era posible compilar a código máquina.

Al arrancar Zesarux, seleccionamos la cinta a cargar en el menú Z >> smart load, que en este caso será el .TAP o .TZX descargado desde la web de World of Spectrum. Este emulador es muy particular, y cargará la cinta él solo, como si hubiéramos tecleado la secuencia de comandos.

Cuando el juego se ejecute, seleccionamos la opción 3. keyboard (o 2. kempston si tenemos un controlador conectado), y el juego nos sitúa dentro de la pirámide con cierta (infame) gota cayendo desde el techo.

En la parte superior del escritorio de Zesarux, a la derecha de la pantalla del Speccy, veremos un icono de una cucaracha: se trata de las opciones que nos permitirán depurar un programa. Vamos a utilizarlo para encontrar pokes. Nos metemos en la opción Debug >> Find >> Find bytes.

#	Menú	Submenú	Submenú	Submenú
1	Debug	Find	Find bytes	Find bytes (initial)
2				Find bytes (next)
3				View results
4				Clear results

En la tabla anterior vemos las posibilidades del menú. Aunque hay opciones automatizadas para buscar POKEs, lo haremos de forma genérica para permitir buscar cheats sobre municiones, granadas, etc.

Comenzamos. La primera vez seleccionamos (1), Find bytes (initial). Ahora que estamos en el juego podemos buscar el valor 10, que introducimos, pues es el número inicial de vidas. Nos dará varios cientos de resultados, como es de esperar, pero lo importante es que Zesarux va a recordar los resultados. Así, la siguiente vez que entremos en el menú, nos encontraremos con (2) Find bytes (next), en lugar de la opción (1). ¡Pero espera! Aún es pronto.

Mueve a Johnny Jones con las teclas O (izquierda), P (derecha), y Q (salto) hasta... sí, la gota. Ponle debajo y pierde una vida. Confía en mi, merecerá la pena... Es verdad, ahora solo tienes 9 vidas, pero verás lo que pasa.

Volvemos al menú de Find y (2) Find bytes (next), y esta vez introducimos 9. ¡Solo hay una coincidencia! Pulsamos ESC y volvemos al mismo submenú para seleccionar (3) View results. La dirección de memoria con valor 9 es 38818. ¡Ya sabemos en qué posición de memoria guarda el juego las vidas!

Nos vamos de nuevo al menú Debug, y esta vez seleccionamos la opción POKE. Seleccionamos la primera opción, POKE.... Nos pregunta la dirección, introducimos 38818. A continuación, nos pregunta con qué valor queremos modificar la dirección 38818. En cada posición de memoria, solo podemos escribir un valor entre 0 y 255. Sabemos que va a ser el número de vidas disponible, así que... ¡qué caray! ¡Introduzcamos 255! ¡Mejor que zozobre que no que zofalte!

A continuación, nos pregunta cuántos bytes queremos modificar. Lo más normal es, como en esta ocasión, que sea solo uno. Pero es posible que, para valores por encima de 255, un juego utilice dos (el mínimo), o más bytes. En este caso, simplemente introducimos 1.

Tras pulsar ENTER, puede que pensemos que algo ha ido mal. Que no ha cambiado nada. Pero... llevemos a Johnny hasta la gota, para morir de nuevo. Solo una vez más. Si lo hacemos... ¡habrán aparecido 254 vidas restantes! Tiene sentido que el juego solo actualice el marcador de vidas del jugador cuando este número cambia... es decir, cambia según las reglas normales del juego.

Un detalle curioso es que no aparece solo "254", sino "0254". Está claro que Víctor Ruiz quería que los marcadores estuvieran "equilibrados", ya que hay más de 10 pantallas, y en la primera se muestra como "01", no como "1". Está claro que el número de vidas es tan exagerademente alto, que el algoritmo para mostrar vidas se desborda. Literalmente.

Un detalle... creo que es en la segunda o en la tercera pantalla que es posible caer en un pozo vertical que termina en unas mortíferas agujas... Es importante que no caigas ahí, o... tendrás que esperar a morir doscientas y pico veces (o, mejor, hacer un POKE de 38818 con 1).

Si queremos buscar algún otro valor en memoria, tendremos que seleccionar (4) Clear results, para poder volver a empezar, seleccionando de nuevo la opción (1) Find bytes (initial).

Ikari Warriors

El siguiente juego que desprotegeremos es Ikari Warriors. Descárgate el .TAP o el .TZX, y cárgalo en Zesarux, de nuevo mediante la opción de menú Z >> Smart load. El juego pide seleccionar el controlador del primer jugador, y después del segundo jugador. En mi caso, redefeniré las teclas (opción 1), del juego para el Jugador 1, y cualquier otra cosa pra el Jugador 2, pues no pienso usarlo. Finalmente, seleccionamos (1) (Start one player game) para comenzar el juego.

Las vidas están representadas mediante cabezas del héroe, son 6 en total. Así que seleccionamos (1) Find bytes (initial), e introducimos 6 (o las vidas que nos queden en ese momento, el juego no se anda con chiquitas). Nos dirá que hay más de seiscientos resultados. Seguramente ya nos habrán matado una o dos veces, seleccionamos (2) Find bytes (next) e introducimos el número de vidas que nos quede. Ahora ya solo aparecerá un resultado. Con (3) View results, comprobaremos que la dirección de memoria de las vidas es 58478. Ahora seleccionamos Debug >> Poke >> Poke.... Introducimos la dirección de memoria, 58478. A continuación, nos pide un valor, sabemos que como máximo puede estar entre 0 y 255. Pero... ¡cuidado! Recuerda que las vidas se representan con figuras en la pantalla. Si introducimos un valor demasiado alto, las figuras se extenderán corrompiendo la pantalla, e impidiendo que nuestro héroe se mueva por ella. Un valor seguro es 40, ya que son las 10 filas por cuatro figuras que se pueden representar en pantalla sin sobrepasar el espacio destinado para ellas. El juego, como decía, no se anda con chiquitas, así que tendrás que introducir el POKE a 58478 con 40 varias veces. En cambio, es bastante improbable que te quedes sin granadas, pudiendo llegar a acumular varias docenas. Así que, personalmente, no creo que merezca la pena buscar el POKE correspondiente. Aún así, lo hice por experimentar, pero... no salió nada, ni con las granadas ni con los disparos. Probablemente, algún tema de ofuscación, curioso.

En cualquier caso, ya sabes cómo encontrar vidas en un juego. ¡Enhorabuena, eres un hacker!

¿Qué?
¿Cómo?
¿Qué con estas técnicas y ciertos programas buscadores de cheats, también se pueden buscar vidas infinitas en lo juegos de ahora? No tengo ni idea de lo que me estás hablando...

Hackeando en 8 bits (y III)

Baltasar García Perez-Schofield — Fri, 13 Mar 2026 12:18:41 +0000

Como hemos visto en las dos entregas anteriores, todo se reduce a un concepto: cambiar la memoria. Si lo hacemos cuidadosamente, podemos colocar, o bien nuestras propias instrucciones, cambiando el comportamiento del programa, o bien nuestros propios datos, de manera que podamos cambiar el número de vidas, el número de balas, el número de bombas... etc.

En esta entrega vamos a ver un ejemplo real, centrándonos en Stop the express. Vamos a seguir el proceso de creación de un cargador que nos proporcione vidas y tiempo infinito. Lo que hoy en día se conoce como cheats.

Encontrar las posiciones de memoria adecuadas y saber modificarlas, implica tener conocimientos de ensamblador y código máquina del Z80, el microprocesador dentro del ZX Spectrum. En este pequeño artículo lo haremos paso a paso, sin asumir conocimientos previos.

Comencemos el proceso de crear un cargador con Stop the Express. Tras encender el Spectrum, y colocar la cinta en el reproductor de cassette, tecleamos merge "" y pulsamos PLAY. Bueno, esto es la idea, a partir de ahora vamos a manejarnos con un emulador de Spectrum, llamado FBZX. Precisamente, nos permitirá emular insertar una cinta, ponerla en marcha, etc.

Así, pulsamos F3 y 1 para indicar que queremos cargar una cinta, el .tap o .tzx de Stop the Express que nos hayamos descargado de World of Spectrum. Teclamos merge"" como se ve en la imagen anterior. Es importante que nos fijemos en que hemos desactivado la carga rápida y la carga turbo.

Ahora, de vuelta en la pantalla de Spectrum, pulsamos ENTER para cargar la cinta, y pulsamos F6 para ponerla en marcha (virtualmente). Una vez que aparece Ok 0:1, pulsamos F5 para parar la cinta. Volvemos a pulsar ENTER para ver el código en pantalla.

Introducimos 20 y ENTER y en la línea 50 eliminamos los colores, de manera que solo nos quede la línea 20, que es la que carga la pantalla de presentación (load "" screen$), el código máquina del juego (load "" code), y la ejecución del mismo randomize usr 48096. Este último lo vamos a modificar poniendo REM delante, lo que lo transforma en un comentario.

50 load "StopExpr2" screen$: load "StopExpr3" code: rem randomize usr 48096

Esta última instrucción es interesante. Ahora le hemos puesto rem delante, con lo que la hemos transformado en un comentario y no se va a ejecutar. La pregunta ahora es: ¿cómo es que esta instrucción ejecuta el juego? La parte importante es USR 48096. Lo que sucede es que es una función, no una instrucción. Necesita una instrucción a la cual va a ser pasada por parámetro. ¿Cuál instrucción exactamente? Realmente no importa demasiado, solo la necesitamos para que evalúe sus argumentos. Concretamente, se usa RANDOMIZE, que inicializa la semilla aleatoria que alimenta a la función RND, que devuelve un valor aleatorio entre 0 y 1. Así, una vez que RANDOMIZE evalúe su parámetro, podrá inicializar la semilla aleatoria. Lo que pasa es que nunca se producirá un retorno de la función que llama al código máquina del juego, claro...

La documentación del ZX Spectrum nos dice que cuando ejecutamos un load "" code, en realidad estamos haciendo un load "" code 32768. Estamos cargando el código del juego a partir de la dirección de memoria 32768. Si tenemos en cuenta que el código tiene un tamaño de 15394 bytes, entonces sabemos que ocupará desde la dirección en memoria 32768 hasta la dirección 48162, inclusive. El resto de la memoria, desde la dirección en memoria 48163 hasta 64k (65536), queda libre.

Tener parte de la memoria libre es importante porque necesitamos espacio para poder cargar un desensamblador, sin "pisar" el programa, es decir, sin utilizar la memoria que está siendo ocupada por el programa. El desensamblador nos va a decir las instrucciones que están en memoria, sin necesidad de que interpretemos los números en ella directamente.

Hasta ahora hemos utilizado emulador el mejor Spectrum posible, el creado por Investrónica en 1986, con características mejoradas como el chip de sonido de tres canales, o la memoria de 128k. Se trata del Sinclair Spectrum + 128k. Pero Stop the express necesita un modelo de 48k, el modelo anterior, así que por si acaso, pasaremos a ese modo con la instrucción SPECTRUM. Si ahora pulsamos la tecla K, veremos que aparece la instrucción LIST en pantalla. Pulsamos ENTER y veremos de nuevo el listado.

Esta forma de manejarse con el teclado es típica del ZX Spectrum original, el de 48k. Se concibió como una manera de ahorrar memoria, y también de ayudar a los usuarios a teclear programas en BASIC. Hay muchos detractores de esta forma de operación, así como fervientes seguidores de la misma.

Ahora pulsamos R (aparece RUNen pantalla) y pulsamos ENTER. Pulsamos F6 para volver a poner la cinta en marcha. El programa cargará la pantalla de presentación, y después el bloque de código máquina del juego en sí.

Cuando termine, veremos en la parte inferior de la pantalla Ok 50:2. Aparentemente, no ha pasado nada, pero tenemos el juego en memoria. Si pulsamos V (aparece CLS), y ENTER, y K (aparece LIST), y ENTER, veremos que seguimos teniendo el cargador en memoria.

Ahora es necesario cargar el desensamblador que mencionamos. Vamos a utilizar HiSoft MONS. El primer archivo, HiSoftDevpacV3M2Mons.tap.zip ya nos vale. Lo descomprimimos, por ejemplo en el mismo directorio de descargas, con lo que nos quedamos con MONS321.tap. Esta cinta, es decir, este archivo .tap, solo tiene un programa, que es el propio desensamblador, que cargaremos con load "" code 52000. Volvemos a FBZX, pulsamos F3 y 1 para seleccionar MONS321.tap, y ESC para volver a la emulación. Pulsamos J (aparece LOAD), pulsamos Ctrl + P dos veces para obtener dos dobles comillas, y a continuación pulsamos Ctrl + Shift, y soltamos (el cursor cambia para mostrar una E parpadeante), y entonces pulsamos la tecla I (aparece CODE en pantalla). Finalmente, tecleamos 52000, para obtener load "" code 52000. Pulsamos ENTER para pasar al modo de carga, y F6 para comenzar la reproducción de la cinta. En pantalla aparecerá BYTES: MONS3M2, y realizará la carga correspondiente, hasta mostrar Ok 0:1.

El proceso de carga del juego para su desensamblado, en realidad suele hacerse desde el mismo MONS, pero para no entrar en excesivas tecnicidades, y explorar también al propio Spectrum 48k, al final he decidido hacerlo así.

Para ejecutar el desenamblador, tecleamos T(aparece RANDOMIZE), Ctrl + Shift (el cursor cambia a una E parpadeante), y L (aparece USR). Tecleamos a continuación 52000, para obtener RANDOMIZE USR 52000. Pulsamos ENTER.

Veremos brevemente un mensaje de bienvenida de MONS3, y después una pantalla con el contenido de los registros del Z80, el contenido de una zona de la memoria en hexadecimal, y un cursor parpadeante en la zona inferior de la pantalla.

Como yo no soy un experto en ensamblador del Z80, me dirijo a los pokes disponibles, que son los siguientes para vidas infinitas y tiempo infinito. A continuación aparecen las direcciones en memoria a cambiar, el valor en hexadecimal del nuevo valor a poner en memoria, y su opcode correspondiente en el Z80.

Dirección en memoria	Valor	Significado	Hex	Opcode
34464	183	Vidas infinitas	B7	OR A, A
34926	183	Vidas infinitas	B7	OR A, A
35257	183	Vidas infinitas	B7	OR A, A
35780	0	Tiempo infinito	0	NOP
39549	0	Tiempo infinito	0	NOP

En Mons3, si pulsamos la combinación de teclas Shift + 1, volvemos a BASIC. Para volver a entrar en Mons3, necesitaremos volver a teclear randomize usr 52000, es decir, T, Ctrl+ Shift, L, 52000 y ENTER.

Con Ctrl+ 3, desensamblamos el programa empezando en la dirección de memoria por defecto, que al principio es 0, es decir, estaríamos desensamblando la ROM del Speccy, la que contiene el intérprete de BASIC, etc.

Con H, y un número decimal, obtenemos su valor hexadecimal equivalente. Por ejemplo, H y 52000 nos devuelve CB20, que es la posición en memoria de Mons3. Si convertimos 34464, la dirección del primer POKE, nos devuelve 86A0.

Con 'M', y un valor en memoria hexadecimal, nos pasamos a esa dirección en memoria. En lugar de utilizar directamente 86A0, utilizaremos 869B, así, con M', 869B yCtrl`+ 3, obtendremos un listado como el siguiente:

plaintext 869V 1102A7 LD DE, #A702 869E 96 SUB (HL) 869F 5F LD E, A 86A0 9D SBC A, L ; este es el valor a cambiar 86A1 93 SUB E 86A2 AA XOR D 96A3 ...

En la primera columna aparece la dirección en memoria en hexadecimal. A continuación, los valores en hexadecimal para la instrucción. Hay que tener en cuenta que hay instrucciones que ocupan varios bytes. Por ejemplo, la primera en 869V es 1102A7. El valor 11 es el de la instrucción LD, concretamente LD DE, cargar en el registro DE el valor A702, que como vemos aparece como 02A7, ya que el Z80 codifica los valores como LSB (Least Significan Byte), es decir, coloca primero el byte menos significativo de un valor en 16 bits. El registro DE es el formado por el par de registros de 8 bits D y E, para conformar un registro de 16 bits. En cambio, en la dirección 86A0 tenemos 9D, una instrucción que ocupa un solo byte y que significa que se debe restar el contenido del registro L + el bit de acarreo, del contenido del registro A. El resultado se guarda en A.

Si en esta posición ponemos en cambio el byte B7, entonces estaremos haciendo un OR del valor del registro A con el valor del registro A. La operación OR comprueba un valor en binario con otro, y pone a 1 aquellos pares de valores que contengan 0 y 1, o 1 y 1. Por ejemplo, si tomamos un valor en binario como 0110, que es 6 en binario, con 1100, que es 12, obtendremos 1110, que es 14. Sí, ¡se puede utilizar para sumar! ¿Pero, qué pasa si hacemos un OR de un valor consigo mismo? Pues nada. El valor se queda como estaba. Y eso es lo que quiere conseguir el POKE: eliminar la resta para que no se reste una vida. Pero, a la vez, deja el registro A y el acarreo como tiene que estar para poder continuar la ejecución sin que esta se vea afectada.

De acuerdo. La dirección en memoria 36780 (8FAC), contiene una instrucción que debemos poner a 0 para que el tiempo sea infinito. El opcode 0 es NOP, es decir, no hacer nada. Si nos fijamos, en esa posición hay otro SBC, otra resta teniendo en cuenta el acarreo. Si la ponemos a 0, simplemente no se hace. En este caso, no es necesario dejar el registro A y el acarreo de ninguna manera especial para que la ejecución continúe correctamente.

Y bueno, este es el proceso que seguiría un hacker de 8 bits para encontrar los POKEs del juego. Buscaríamos por ejemplo el valor 3, descartando todos los valores hasta encontrar el número de vidas inicial en una dirección de memoria concreta. Después buscar restas de esa posición en memoria, buscando por el opcode SUB o SBC hasta encontrar la instrucción que resta la vida, y encontrar el valor adecuado que consigue que se haga la resta mientras a la vez consigue que continúe la ejecución sin errores. Y cada error, supone cargar el Mons3 desde cinta, y a continuación el juego desde cinta. Tiene mérito, ¿eh?

Y ahora es necesario crear el cargador del juego. Es decir, la parte BASIC que carga el juego. Nos habíamos quedado con esto:

bbcbasic 20 load "StopExpr2" screen$: load "StopExpr3" code: rem randomize usr 48096

Vamos a pasarlo a lo siguiente. Tenemos que cambiar los valores después de cargar el juego, y antes de ejecutarlo. Podemos hacerlo como aparece a continuación, creando el archivo cargador.bas:

bbcbasic 10 load "StopExpr2" screen$ 20 load "StopExpr3" code 30 cls:print "Stop the Express cracked" 40 input "Vidas infinitas (s/n):";v$ 50 if v$(1)<>"n" then poke 34464, 183:poke 34926, 183:poke 35257,183 60 input "Tiempo infinito (s/n):";t$ 70 if t$(1)<>"n" then poke 35780, 0: poke 39549, 0 100 randomize usr 48096

Nos podemos descargar BasinC, y ejecutarlo (en linux, necesitaremos Wine). Cargamos el archivo cargador.bas en BasinC, y seleccionamos File >> Export as tap, guardándolo como cargador.tap.

Ya solo queda volver FBZX, y pulsar F3 para seleccionar una cinta, escoger cargador.tap, pulsar ESC e introducir SPECTRUM, y después pulsar J, Ctrl + P dos veces y ENTER para ejecutar load "", pulsando entonces F6. Al terminar la carga, pulsamos R y ENTER para ejecutar el programa. Seleccionamos la cinta del juego original con F3 y 1, y al pulsar ESC y F6, el juego se cargará saltándose el BASIC original, y preguntándonos si queremos vidas y tiempo infinito. Al terminar las preguntas, el juego se ejecutará modificado.

Enhorabuena, ¡eres un hacker!

Retro-imprimiendo (y II)

Baltasar García Perez-Schofield — Tue, 03 Mar 2026 12:11:16 +0000

En la década de los 80 y 90 del siglo pasado (el siglo XX), era muy típico imprimir utilizando interfaces de tipo paralelo, o serie. En aquella época, el estándar USB no existía, y, en cualquier caso, la impresión era muy, muy distinta a como es hoy en día, que básicamente se basa en imprimir una imagen, incluso cuando lo que se está imprimiendo es texto puro.

Pero no nos desviemos. Las impresoras de aquella época imprimían en verdadero modo texto. Es decir, les mandabas un texto, y los caracteres (no sus mapas de bits), viajaban por el cable entre el ordenador y la impresora, imprimiéndose directamente. Lo que controlaba el aspecto del texto (lo que hoy conocemos como font, y traducimos como fuente), eran unos dips o palanquitas de configuración de la impresora. Así, y según lo completa que fuera la impresora, podrías elegir entre Times New Roman o Helvetia, por poner un ejemplo. Si es que existían en aquella época, claro. También se utilizaban para establecer la página de códigos para el idioma utilizado, como por ejemplo Latin-1 para Español.

Una vez que nos poníamos a imprimir, el texto podía controlarse mediante códigos de impresión. Algunos eran estándar ASCII, pero había otros más elaborados que veremos a continuación.

Código	Significado
8	BS - Back Space, borrado hacia atrás
9	HT - Horizontal Tab, tabulador
10	LF - Line Feed, salto de línea
12	FF - Form Feed, salto de página
13	CR - Carriage return, retorno de carro

Como comentábamos en la anterior entrega, realmente en estas impresoras (de ellas las más conocidas eran las matriciales), tenían un carro que era el que se movía para imprimir por la página, de ahí la diferencia entre CR y LF.

También como vimos, podemos imprimir directamente con print.py desde línea de comando con:

$ python print.py --send "¡Hola, mundo!^v"

El código ^v es entendido por el programa como el carácter número 12, por lo que se imprimirá el mensaje de saludo, y después saldrá la página de la impresora. Esto código 12 al principio era innecesario, pues el usuario podía manipular directamente el rodillo de alimentación de papel (sí, se parecía mucho a una máquina de escribir). Pero se fue haciendo particularmente útil con las impresoras modernas, que tienen un buffer de impresión que, si no se llena (y tampoco se alcanza el final de página), aparentemente no pasa nada, de manera frustrante.

Pero la impresora manejaba más que estos códigos, y seguía haciéndolo utilizando la manera estándar que proporcionan los códigos ASCII por debajo de 32: utilizando el código 27. Efectivamente, también es el código de la tecla de escape. La idea es que, anteponiendo ESC a la secuencia de códigos, se pueden definir las secuencias de código de control que se desee. El fabricante EPSON creó las secuencias de códigos de control de impresión ESC/P, es decir, Epson Standard Code for Printers, que se hicieron muy, muy populares. Por supuesto, tenía que haber otro estándar (estándares de facto, claro), apareciendo la competencia: las secuencias de códigos de control de impresión de IBM. Estos códigos de control estaban sobre todo dedicados a las impresoras de los grandes ordenadores o mainframes, siendo ESC/P el estándar más popular para el IBM PC y compatibles.

El sistema de secuencias de control ESC/P se configuraba a partir del código ESC. En el programa anterior print.py, ESC se representa como ^], algo muy habitual en la época. Así, a continuación podemos ver una tabla con los códigos más habituales.

Código	Enviar	Significado
ESC E	^]E	Comienzo del texto en negrita.
ESC F	^]F	Fin del texto en negrita.
ESC 4	^]4	Comienzo del texto en itálica.
ESC 5	^]5	Fin del texto en itálica.
ESC -	^]-	Comienzo o fin de subrayado.
ESC W 0	^]W0	Comienzo de caracteres de doble ancho.
ESC W 1	^]W1	Fin de caracteres de doble ancho.
ESC SI	^]SI	Comienzo de caracteres comprimidos.
DC2	^DC2	Fin de los caracteres comprimidos.

Efectivamente, podíamos especificar caracteres con el doble de ancho (permitiendo hasta 40 caracteres por línea), o caracteres comprimidos (alcanzando las 120 columnas, un modo muy popular para informes).

Así que, si ejecutamos:

$ python print.py --send "¡Hola, ^]EMundo^]F!^V"

¿Obtendremos en el papel: "¡Hola, mundo!"?

Por desgracia, no. Las impresoras modernas han eliminado de sus firmwares el soporte para ESC/P. En su mayoría, las impresoras que lo soportan hoy en día son impresoras de tickets. Las impresoras modernas "normales", a veces lo soportan configurándolas previamente como en modo de línea o modo texto. También hay que recordar que las impresoras láser nacieron soportando PostScript, por lo que esos modelos nunca han tenido la necesidad de soportar ESC/P.

Así que, si quieres practicar retro-impresión, solo puedes hacerlo adquiriendo una impresora de tickets que indique que es compatible con ESC/POS (la variante moderna de ESC/P, especializada en POS, Point Of Sale o punto de venta). ESC/POS tiene muchos códigos nuevos como abrir el monedero, por ejemplo, pero los básicos de la tabla anterior siguen siendo soportados.

La mejor forma es adquirir una impresora matricial propiamente. Puede ser una impresora retro de los 80 o 90, adquirida a través de aplicaciones especializadas en productos de segunda mano como eBay o Wallapop. Pero todavía las hay modernas, tanto de tickets como de tamaño folio (DIN A4). Por ejemplo, en el momento de escribir este texto, la Epson LX-350, o la OKI 3320ECO son de tamaño folio y soportan ESC/P.

IA: una historia real

Baltasar García Perez-Schofield — Thu, 26 Feb 2026 15:52:26 +0000

La IA generativa ha estado constantemente (y errónameante), entronada como la sustituta de los programadores. Ya he publicado algún comentario en este medio sobre las experiencias (casi siempre, decepcionantes) que he tenido con la IA (1 2 3 4). Esto no quiere decir que la IA no sirva: es una herramienta más, como trataré de describir aquí.

Hace algunos días, estaba trabajando con Java, su toolkit gráfico Swing, que estaba utilizando para mostrar el contenido de notas creadas por el usuario. Una de las posibilidades contempladas es la de crear cajas de verificiación como listas de tareas. Por ejemplo:

[ ] - Comprar pan.
[X] - Crear el programa para la mañana.
[ ] - Reunión de las 11h.

Estas cajas en Mark Down se interpretarían como HTML, concretamente como un check box. El único componente que puede interpretar HTML es un JEditorPane.

La forma de representar un check box en HTML 5 es la siguiente:

<input type="checkbox">

Si el check box está marcado, entonces aparecería con el atributo checked. Este atributo no se asigna a ningún valor, sino que su mera existencia indica el marcado o no (algo que, por cierto, no me gusta nada... ¿era demasiado tener un atributo como cheched="1" o similar?).

<input type="checkbox" checked>

Pues nada, hago mis pruebas, las notas con casillas se convierten a HTML con estos check boxes, y después vuelven a guardarse como MarkDown.

Pero entonces, me encuentro con algo sorprendente, un error extraño: daba igual si marcabas o no la casilla, nunca se generaba el atributo checked... ¿qué estaba pasando?

Las búsquedas mediante los buscadores habituales enseguida devolvían respuestas relacionadas con JavaScript, lo que no era demasiado útil. Decidí irme a la IA. Elegí Deep Seek. Sobre todo, porque me permite usarlo de manera gratuita, más que nada.

Le pregunté a la IA la razón de por qué me pasaba lo que me pasaba, y... sí, me entendió a la primera. Es decir, no tuve que refinar mi pregunta descartando posibles problemas y soluciones orientadas al navegador con JavaScript. Esto es un buen punto para la IA.

Su respuesta me sorprendió: This is a known issue with HTMLEditorKit - when you call getText(), it serializes the current document state and resets all input values to their default values (as defined in the HTML). Traducido, este es un problema conocido en JEditorPane empleando un HTMLEditorKit, o sea, trabajando con HTML. El problema es que los señores de Sun Microsystems decidieron no "conectar" los valores de entrada de este tipo de campos input, según parece, debido a que JEditorPane no es un navegador. De acuerdo, pero entonces... ¿por qué los input de tipo text sí se respetan, de modo que los valores de entrada sí se reflejan en el DOM HTML del editor? Mi personal interpretación es que se cansaron a mitad de trabajo, probablemente pensando algo así como: "total, esto lo no lo va a usar nadie..."

Bueno, el caso. La cuestión es que me da varias soluciones. Una de ellas es captar, (1) mediante un código en JavaScript los valores de las check boxes y meterlas en los elementos del DOM HTML del editor. Otra es (2) crear una versión propia de HTMLEditorKit quer genere el código correctamente, y otra es (3) tomar el atributo checkeddel DOM HTML del editor y almacenarlo en una estructura de datos.

Hay varios problemas con estas soluciones. La (1), utilizando JavaScript es excesiva, en mi opinión. Tras examinar la (2), resulta que o bien no existe una manera elegante de recorrer los nodos, o bien la IA no la conoce y no tengo tiempo de investigarlo, y en contraste, la tercera es la que parece más interesante. Así que me la leo, la entiendo, elimino todo el código redundante, y la incorporo a mi código. Pero no funciona.

Y es que, en realidad, ninguna de las soluciones funcionan, porque todas tienen que ver con el HTML DOM que mantiene el editor. Y tiene todo el sentido, porque si volvemos a leer el origen del problema, la cuestión es que la parte visual no está conectada con el DOM HTML. Así, podemos "trastear" con el HTML DOM lo que queramos. Nos pongamos como nos pongamos,no tendremos los checked aunque los check boxes están marcados.

Para mi, esto supone un problema con la IA. Me ha propuesto varias soluciones que seguramente fueron ensayadas por alguien, pero que fueron solo meros intentos, pues no solucionan el problema. Además, no le molesta proponer una solución basada en ejecutar JavaScript dentro del editor, lo que me parece especialmente subóptimo. Por último, es necesario "pulir" la respuesta: hay mucho código redundante, que no aporta nada a la solución.

El caso es que le respondo a la IA que la solución propuesta no es válida. Su respuesta es:

You're right to be skeptical! This is actually a known limitation of HTMLEditorKit - checkbox states are not stored in the document attributes the way we might expect. The checked state is maintained in the visual representation/View, but not in the underlying Document model's attributes.

Es decir, que al no estar conectada la parte visual del HTML DOM, no tiene sentido manejar el DOM.

No puedo evitar pegar un respingo cuando la leo. No tiene sentido que me propongas las soluciones anteriores "sabiendo" esto. De hecho, debería haberme dado cuenta, pero he confiado en que la IA me propondría soluciones válidas.

Las soluciones propuestas son (1) tomar las marcas directamente de la vista del documento (no del HTML DOM), o (2) usar el ElementIterator de HTMLDocument . La segunda solución tiene un código kilométrico, y visto lo visto, no me fio de adoptarlo sin más. Además, lo que hace básicamente es crear un listener que, en caso de marcar un check box, pasa un booleano a una estructura de datos aparte... esta estructura de datos es la misma que utiliza la primera solución, mucho más corta, así que me centro en esta.

Leo el código. Básicamente, lo que hace es recorrer los "nodos" de la vista, y busca objetos JChecbBox, asociados a un objeto ParagraphView, clase derivada de ComponentView (que se corresponde con un elemento de HTML DOM <input type="checbox">). Cuando se encuentra uno, accede a su marca. El algoritmo es el siguiente:

    private static void traverseViewForCheckboxes(View view, Map<String, Boolean> states) {
        if (view instanceof javax.swing.text.html.ParagraphView) {
            // Check if this view contains a checkbox
            Component component = findComponentInView(view);
            if (component instanceof JCheckBox) {
                JCheckBox checkBox = (JCheckBox) component;
                String name = checkBox.getName();
                if (name != null) {
                    states.put(name, checkBox.isSelected());
                }
            }
        }

        // Recursively traverse child views
        for (int i = 0; i < view.getViewCount(); i++) {
            traverseViewForCheckboxes(view.getView(i), states);
        }
    }

La división entre el HTML DOM y la vista sigue el patrón Bridge.

Primero se busca en la vista los objetos ParagraphView. Entonces se comprueba con su método getComponent() si el componente visual equivalente es un JCheckBox, accede a su marca. Y entonces me fijo en el método findComponentInView( view ). Está justo debajo:

private static Component findComponentInView(View view) {
        // This is a simplified approach - in reality, you might need to
        // access the ComponentView's component
        if (view instanceof javax.swing.text.html.ComponentView) {
            try {
                java.lang.reflect.Method getComponentMethod = 
                    ComponentView.class.getDeclaredMethod("getComponent");
                getComponentMethod.setAccessible(true);
                return (Component) getComponentMethod.invoke(view);
            } catch (Exception e) {
                // Reflection failed, try alternative approach
            }
        }
        return null;
    }

¡Está utilizando reflexión para acceder al método View::getComponent, y retornarlo. Me resulta realmente extraño este código. Supongo que será parte de algún código de prueba de alguien, pero... no tiene sentido. No tiene sentido porque View::getElement es un método totalmente accesible.

Dicho de otra forma, la llamada al método propuesto findComponentInView( view ), especialmente subóptimo pues emplea reflexión...

Component component = findComponentInView(view);

Se puede sustituir por una línea de código:

var component = view.getComponent();

Cuando le señalo este extremo a la IA, reconoce que sí, que View::getComponent(), se puede llamar directamente (?). No hay explicación, pero si no te das cuenta, pues te comes el código.

Podemos resumir el proceso anterior en unos puntos fuertes y débiles de esta sesión con IA como sigue:

Cuestión	Punto fuerte de la IA	Punto debil de la IA
Búsqueda de problemas	La IA encuentra el problema específico, mientras con un buscador necesitas mucho más esfuerzo.
Resolución de problemas		La IA puede generar soluciones que no son correctas.
		No le importa generar soluciones que suponen una elevada carga, al resultar extremadamente subóptima (ejecutar JavaScript).
		Genera un código excesivo, que hay que pulir y sobre todo, recortar.
	Al final, analizar las posibles soluciones propuestas, encuentras una que es prometedora, lo que evita de nuevo costosas y esforzadas búsquedas.
		En general, crea código subóptimo; de nuevo, es necesaria una revisión detallada (llamada mediante reflexión).

Si leemos detalladamente este resumen, y damos un paso atrás, entendemos, efectivamente, cómo funciona la IA: proporciona texto con una alta probabilidad de aparecer junto al texto de entrada. Si tenemos esto último en cuenta, es obvio el por qué es necesario leer, entender, analizar, y pulir tanto las posibles soluciones como el código que proporciona. No hay otra.

The Spanish ZX Spectrum + 128K by Investrónica

Baltasar García Perez-Schofield — Wed, 18 Feb 2026 17:23:05 +0000

This post was previously published in Spanish, in ZonaDePruebas

This computer was designed and released in 1985 by Investrónica, a subsidiary company in the El Corte Inglés group at the time, holding the distribtion rights for the Sinclair products in Spain.

Due to the Spanish law, the engineers of Investrónica couldn't release these Sinclair computers without support for the Spanish language. This especially included the 'ñ' character, as well as translated system messages.

With the experience gained after the development of the 128k, they would later release a Spanish ZX Spectrum +, translating all system messages and including support for the 'ñ' character as well.

Investrónica always tried to convert, or at least show the Spectrum as a bussiness machine. Thus, this microcomputer came with a keypad included (also known as independent numeric keypad), which made program edition more comfortable, since it allowed advanced editing (word-by-word skipping, for instance).

This Spanish computer's final shape probably didn't convince the engineers at Sinclair UK, since they finally discarded the keypad, removed the text editor, the BASIC editor advanced capabilities, but added screen menus. Those menus made the computer more pleasant at first glance, and a completely different aspect in contrast to the Spanish Spectrum 128k. A year later the English Spectrum + 128k was finally out, selling the keypad separately, and completely diverging from the path opened by Investrónica.

With the pass of time, the Spanish 128k almost fell into oblivion, ditched as a rarity in a local (the Spanish), market. Especially in regard to its differences with the UK computer, its advanced possibilities became forgotten.

A text editor embedded in ROM

The Spanish Spectrum 128k had an embedded text editor. In order to enter it, you only had to use the command edit, followed by the name of a string variable. All the text typed inside the editor was stored inside that variable, which could handle many pages, almost up until filling the Speccy's memory. For instance, typing edit e$ from the main screen, you would enter in the text editor mode with the current contents of the e$ variable. All changes were stored inside it upon exit, of course.

The Spanish Spectrum 128k memory

The amount of available memory was around thirty-some kilobutes. Where was then that extra memory (up to 128k) to be found? It was only accessible using some special commands, such as save ! "" and load ! "". In order to list its contents, you could type cat !. Thus, that extra RAM was made available as a RAM drive.

All this survived in the UK model, and it was indeed called RAM Disk, and identified as "m:". The extended commands using '!' would be removed, and drive selectors would be supported in file names, such as "a:', "b:" and "m:". You could save screens (screen$), machine code (code), and arrays (data), as well as regular BASIC programs, that is.

REM storing in the RAM disk
save ! "pant.scr" screen$
save ! "gamestat" data pos
cat !

The text editor capabilities

The text editor included many functions present in other professional editors (such as Tasword, for instance), though it was really lacking, so it could hardly could be called professional itself. It's true that this was more related to the Speccy's internals than anything else.

The text editor supported word wrapping, insertion and overwriting, and, using the keypad, word skipping, text's home and end by line, and other cursor movements unknown in a Speccy.

The limitations of the editor, were severe, though. In the first place, the output was of 32 columns, only as many as the Speccy was able to show. This made it possible to print the text correctly only in a ZX Printer, using the command lrpint e$. From the perspective that gives the pass of time, I think they should have tried to double the columns as Tasword did (using 4-pixels-wide characters). Maybe the space in ROM was too limited for that, I don't know.

The problem was that the ZX Printer was rubbish (though probably a smart invention), and nobody would have thought of delivering a document on the mini-paper used by this device. It was a special thermal paper, more similar, both in quality, technology, and size, to a modern supermarket ticket printer.

The official way to plug a ZX Printer to a Speccy (or any other printer, by the way), was to use the Interface 1. This interface was incompatible with the ZX Spectrum 128k, however. For starters, the 48k mode was forced, and all extra capabilities present in the Spectrum 128k were therefore gone, such as the RS-232 socket, the advanced editing capabilities, and of course, making the access to text editor in ROM impossible.

Using the RS-232C output (the physical inlet was the same one as the keypad), plus a serial to centronics converter available for the Sinclair QL, you could connect an actual printer to your Spectrum 128k. The result, however, was disappointing. As one could expect, the text would only reach column #32 (instead of using the whole 80 columns), almost wasting the 60% of the available space of a DIN A4 piece of paper.

You could print your documents in the Spanish ZX Spectrum 128k, but without using the text editor in ROM.

Thus, the actual utility of this text editor was very limited in practice.

Editing BASIC programs

The capabilities of the text editor were also used for the Sinclair BASIC editor, widely improved in contrast to the Spectrum +. These were, for some reason, discarded by Sinclair UK for their Spectrum 128k. Maybe this was due to incompatibilities, though the Spectrum 128k was quite compatible with the 48k software library, and you even could type SPECTRUM in order to force a 48k 100% compatibility mode. The notion of a whole-screen editor was adopted, anyway.

The Spanish Spectrum 128k presented your programs in a more cleaner way than any other Spectrum, including the later ones such as the +2, +2A, +3B and +3. This is shown in the previous image of a small BASIC program, as well as in the next image with the listing of the typical Hello, world! program.

The source code can be edited using the whole screen, or over the status bar (provided it fits), by means of the edit <line_number> command.

Apart from this, the Spanish Speccy 128k supported a few extra useful commands:

RENUM: It renumbers all the lines in a program. It does not only change the line numbers, but it also keeps them in sync with all jumps (GO TO's and GO SUB's). This possibility survived in the UK Spectrum 128k, though widely limited. RENUM could be feed with three parameters, of which all were optional: the starting current line number, the new starting line number, and the increment between lines. For instance, RENUM renumbered all lines starting with the new line number 10, and using an increment of 10 between lines. RENUM 1000, 5000, 5, would renumber from line 1000 on, using 5000 as the starting line number, and 5 as increment, so the current line 1000 would become 5000, and the current line, say, 1010, would become 5005, and so forth.
DELETE: You could remove all lines in a given range (thus, it's dangerous). The parameters were indeed the starting line and the ending line, such as in DELETE 100, 200.

Also, as it was commented above, the whole system messages set were translated into Spanish, and the keyboard included ñ and ü. Instead of the UK Pound symbol, the Spanish Peseta Pt was included as a single character instead. Amusingly, the accented vowels were not supported, you could only show them using OVER 1 with the regular vowels.

print at 1, 1; "a"
print at 1, 1; over 1; "'"

A calculator

The calculator survived in the UK Spectrum 128k, though it seems to me to be more elegant in the Spanish Spectrum 128k. It was not necessary to enter any special mode, nor choose any special option, in order to access the calculator. Just entering a numeric calculation in the status bar or in any blank line of the screen would do (you could just press ENTER to make space below the current line).

If this possibility was used with the keypad the result was quite useful.

The Spectrum will always store the last result, so you could easily chain calculations.

Links to ads of the Spanish Spectrum 128k

Acknowledgements

All screens above were captured using the FBZX emulator by RasterSoft, downloading the Spanish ROMS from the website of Rodolfo Guerra.

El ZX Spectrum + 128K de Investrónica

Baltasar García Perez-Schofield — Mon, 16 Feb 2026 10:47:47 +0000

Este post lo publiqué previamente en ZonaDePruebas

Este ordenador fue diseñado y comercializado en 1985 por Investrónica, en aquel momento una filial de El Corte Inglés que tenía los derechos de distribución de los productos de Sinclair en España.

Debido a la legislación española, los señores de Investrónica se verían obligados a sacar a la venta este ordenador con soporte en español, es decir, mensajes traducidos, carácter 'ñ' , etc.

Con la experiencia acumulada tras el desarrollo del 128, castellanizaron el ZX Spectrum + (traduciendo mensajes de error e incorporando la 'ñ') en 1986.

En Investrónica, siempre intentaron convertir o hacer ver al Spectrum como un ordenador de gestión. Así, el micro venía de serie con un keypad o teclado numérico independiente, que hacía mucho más cómoda la edición de programas, ya que se podía avanzar, por ejemplo, de palabra en palabra.

El ordenador no debió convencer a los señores de Sinclair UK, ya que finalmente descartaron prácticamente el teclado numérico independiente (sólo se podía adquirir aparte), eliminaron el editor de textos, y crearon unos menús que hacían al ordenador más agradable a primera vista. Eliminaron también el editor de programas BASIC mejorado. Así salió al mercado, un año más tarde, el ZX Spectrum 128 inglés, sin el keypad, y obviamente diferente al español.

Con el tiempo, el 128k español cayó prácticamente en el olvido, sobre todo en cuanto a sus diferencias con el inglés y sus posibilidades mejoradas.

Un editor de textos integrado en ROM

El Spectrum 128 español venía de serie con un editor de textos integrado en ROM. Para acceder a él, bastaba utilizar el comando edit, seguido del nombre de una variable de cadena. De esta forma, todo el texto creado mediante el editor pasaba a estar almacenado en dicha variable, que podía conservar páginas y páginas hasta completar la memoria del Spectrum. Por ejemplo, tecleando desde la pantalla principal: edit e$, se entraba en el modo de editor de textos con el contenido de esa variable e$. Y al salir, la variable conservaba los cambios, claro.

La memoria del Spectrum 128k

La memoria disponible era de unos treinta y pico kilobytes libres, ya que la memoria extra sólo era accesible empleando unos comandos especiales, save ! "" y load ! "", que permitían acceder a ella. Para listar su contenido, se empleaba el comando cat !. Es decir, solo se podía utilizar como RAMDisk.

Todo esto sí sobrevivió en el modelo inglés, llamándosele, de hecho, unidad de disco en memoria, y posteriormente, eliminando las extensiones a load y save con el símbolo de admiración, y creando los selectores de unidad en los nombres de archivo a:, b:, y m:. Era posible salvaguardar pantallas (screen$), código máquina (code) y matrices (data), así como programas completos en BASIC, claro está.

REM guardando en el disco RAM
save ! "pant.scr" screen$
save ! "ramjuego" data pos
cat !

Posibilidades del editor de textos

El editor de textos incorporaba muchas funciones presentes en otros editores (como Tasword, por ejemplo), aunque desde luego le faltaba bastante para llegar a un nivel profesional.

El editor de textos permitía el enrollado de palabra o Word wrap (que la palabras no se cortasen al llegar al borde del papel), inserción o sobreescritura y, utilizando el teclado numérico independiente, se podía pasar de palabra en palabra y borrar una palabra entera o hasta el final de la línea, así como movimientos varios de ese tipo, desconocidos en un Spectrum.

Las limitaciones del editor, sin embargo, eran severas. En primer lugar, la salida era de 32 columnas, tantas como mostraba el Speccy en pantalla. Eso hacía posible imprimir el texto adecuadamente solamente en una ZX Printer, mediante la ejecución del comando lprint e$. Con la perspectiva del paso del tiempo, creo que deberían haber soportado 64 columnas, como hacía Tasword (con caracteres de 4 píxeles de ancho). Quizás el espacio en la ROM era demasiado limitado para eso, no lo sé.

El problema era que la ZX Printer era una porquería (por ingeniosa que fuera), y nadie se hubiera planteado entregar un documento de trabajo con el mini-papel que empleaba ese dispositivo (era un papel térmico especial). Se parecía más, tanto en tamaño, como en tecnología o calidad de impresión, a una moderna impresora de tickets del supermercado.

La forma "oficial" de enchufar una ZX Printer al Spectrum (o cualquier otra impresora), era utilizar el Interface 1. Esta interfaz no era compatible con el Spectrum 128k. Ya para empezar, forzaba el modo 48k, y todas las posibilidades extra del Spectrum quedaban deshabilitadas, por ejemplo, el conector RS-232 del que disponía el Spectrum. El editor de textos, por descontado, era inaccesible.

Utilizando la salida RS-232C del Spectrum 128k español (el enchufe físico era el mismo que el del teclado numérico independiente), más un conversor de serie a paralelo (disponible para el Sinclair QL), se podía enchufar una impresora de verdad al Spectrum. El resultado, sin embargo, era decepcionante; como era de esperar, el texto llegaba hasta la columna 32 y no aprovechaba las 80 columnas.

Podías imprimir tus documentos en el ZX Spectrum 128k español, pero sin utilizar el editor de textos incorporado.

Así, la utilidad real de este editor de textos era muy limitada en la práctica.

El editor de programas BASIC

Las posibilidades del editor de textos también se aprovechaban para el editor de Sinclair BASIC, ampliamente mejorado con respecto al modelo Spectrum +, y que fue, por alguna razón (quizás por incompatibilidades) descartado por Sinclair para llevarlo incorporado de serie en su propio 128 (el inglés). Eso sí, del 128 español tomaron la idea de poder moverse a pantalla completa editando código.

El Spectrum 128 presenta los programas de una manera más limpia y ordenada que cualquier otro modelo de Spectrum, incluyendo todos los posteriores como el +2, +2A, +2B, y +3. Se aprecia en la siguiente imagen el listado del típico ¡Hola, mundo!

El código puede editarse a pantalla completa o sobre la barra de estado (siempre que quepa), mediante el comando EDIT <numLinea>.

Además, el Spectrum español admitía un par de comandos extras muy útiles:

RENUM: Permite renumerar un programa, pero no sólo renumera los números de línea, sino que mantiene sincronizados los números de línea en los saltos GOTO s y GOSUB s. Esta posibilidad sobrevivió, si bien muy recortada. RENUM admitía tres parámetros; la línea de comienzo, el número de línea nuevo para esa línea, y el intervalo que se deseaba que hubiera entre esa línea y las siguientes.
DELETE: Permitía borrar las líneas comprendidas entre dos números de línea dados, que se pasaban como parámetros.

Además, como ya se ha comentado, los mensajes de error estaban traducidos al español, y el teclado contenía la ñ, y la u con diéresis (ü). Eso sí, sorprendentemente, las vocales acentuadas no estaban disponibles. Solo se podían mostrar con OVER 1 y el apóstrofe.

print at 1, 1; "a"
print at 1, 1; over 1; "'"

La calculadora

La calculadora sí sobrevivió en el 128k inglés, aunque a mi parecer era mucho más elegante en el 128k español. No era necesario seleccionar ninguna opción, ni realizar ninguna acción especial, para hacer cualquier cálculo en cualquier momento. Bastaba con mover el cursor a la barra de estdo, o pulsar ENTER para hacer un hueco en el listado BASIC.

Si esta posibilidad se empleaba en conjunción con el teclado numérico independiente, el resultado era bastante útil.

El Spectrum siempre guarda el último resultado, obteniendo la posibilidad de encadenar operaciones.

Enlaces a publicidad del Spectrum 128 español

Agradecimientos

Estas imágenes han sido capturadas con el emulador FBZX de RasterSoft, bajando las ROMS españolas de la web de Rodolfo Guerra.

C, ¿el lenguaje de programación de los chamanes?

Baltasar García Perez-Schofield — Mon, 09 Feb 2026 08:42:22 +0000

Cada vez más, los estudiantes de informática se forman con lenguajes de programación de verdadero alto nivel, como el típico Java, C#, Python... Todos ellos tienen algo en común: cuando te manejas con arrays, o matrices: te avisan cuando no aciertas a acceder dentro del array (por ejemplo, a la posición 90 en un vector de 10 posiciones).

Por ejemplo: el siguiente código lanza la excepción: IndexError, ya que obviamente no existe esa posición.

# Python

v = [11, 12, 13, 14 15]
print(v[90])

Salida:

v[55]
~^^^^
IndexError: list index out of range

Hay diferentes versiones para esto mismo en C# y Java. En C# se lanza la excepción IndexOutOfRangeException.

// C#

int[] v = [11, 12, 13, 14, 15];
System.Console.WriteLine( v[ 90 ] );

Salida:

Unhandled exception. System.IndexOutOfRangeException: Index was outside the bounds of the array.

En Java, se lanza la excepción ArrayIndexOutOfBoundsException.

// Java

public class Main {
    public static void main(String[] args)
    {
        int v[] = new int[]{ 11, 12, 13, 14, 15 };
        System.out.println( v[ 90 ] );
    }
}

Salida

Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index 90 out of bounds for length 5

Por cierto, un pequeño detalle que me gustaría explorar en otro post: ¿por qué es necesario renombrar todos los conceptos cuando se crea un lenguaje de programación nuevo? Python y Java fueron diseñados más o menos al mismo tiempo, así que tienen su excusa, pero... ¿por qué Java y C# tienen nombres distintos para las excepciones, o para las clases y métodos de acceso a la consola? Más aún cuando muchos programas en Java pueden compilarse sin modificaciones en C#.

Volviendo al tema entre manos, está claro que, especialmente con la forma de enseñar programación en la gran mayoría de las facultades de informática, todos los estudiantes asumen que este es el comportamiento "normal". Dicho de otra forma, todos los lenguajes de programación "normales" se comportan de esta manera. No es "culpa" de nadie, así es como son las cosas, punto.

La pregunta surgió en clases cuando llegamos al punto de los índices negativos en Python. ¡Sí! Python permite la siguiente transformación:

v = [11, 12, 13, 14, 15]

for i in range(len(v)):
    print(f"#{i=}: {v[i]=} | #{(i + 1)=}: #{(len(v) - (i + 1))=}: {v[(len(v) - (i + 1))]=} | #{-(i + 1)=}: {v[-(i + 1)]=}")

Salida:

#i=0: v[i]=11 | #(i + 1)=1: #(len(v) - (i + 1))=4: v[(len(v) - (i + 1))]=15 | #-(i + 1)=-1: v[-(i + 1)]=15
#i=1: v[i]=12 | #(i + 1)=2: #(len(v) - (i + 1))=3: v[(len(v) - (i + 1))]=14 | #-(i + 1)=-2: v[-(i + 1)]=14
#i=2: v[i]=13 | #(i + 1)=3: #(len(v) - (i + 1))=2: v[(len(v) - (i + 1))]=13 | #-(i + 1)=-3: v[-(i + 1)]=13
#i=3: v[i]=14 | #(i + 1)=4: #(len(v) - (i + 1))=1: v[(len(v) - (i + 1))]=12 | #-(i + 1)=-4: v[-(i + 1)]=12
#i=4: v[i]=15 | #(i + 1)=5: #(len(v) - (i + 1))=0: v[(len(v) - (i + 1))]=11 | #-(i + 1)=-5: v[-(i + 1)]=11

Efectivamente, v[len(v) - 1], que obtiene la última posición, es equivalente a v[-1]. En realidad, no es que realmente Python acepte índices negativos, sino que es una más de las posibilidades expresivas de Python: los índices negativos se transforman, de manera que cuentan desde la longitud total del vector. Una forma alternativa de expresar esto mismo es la de C#, que permite v[^1].

¡Pero ningún lenguaje de programación "normal" permite índice negativos! ¿No?
Bueno, con C sí puedes hacerlo.
Y así es como desciendes por la madriguera del conejo hacia el mundo de las maravillas.

El siguiente programa es válido en C, y también en C++:

#include <stdio.h>


int main(int argc, char **argv)
{
    int v[] = {11, 12, 13, 14, 15};

    for(int i = 0; i < (sizeof( v ) / sizeof( int )); ++i) {
        printf( " #%d: %d |", i, i[ v ] );
    }

    return 0;
}

Salida:

 0: 11 | 1: 12 | 2: 13 | 3: 14 | 4: 15 |

La razón de que esto funcione es simple: en realidad, v[ i ] (o i[ v ]), no son más que azúcar sintáctico para *(v + i) o *(i + v). Ya más tarde, cuando el compilador genera el código, esto se transforma en: *(v + (sizeof(int) * i)), ya que los incrementos o decrementos reales siempre dependen del tamaño del tipo del puntero. Claro, es indiferente generar *(v + i) desde v[ i ]. o *(i + v) desde i[v].

¿Qué tiene que ver esta peculiaridad de C con los índices negativos? Bueno, se trata de que nos hagamos a la idea de que el lenguaje de programación C es muy, muy antiguo y relativamente sencillo (de hecho, ya no se considera de forma pura un lenguaje de alto nivel). Hay que tener en cuenta que C es un lenguaje de programación de sistemas, por lo que es normal que su nivel de expresividad esté muy cercana al hardware.

Así que... ¿se pueden indicar valores negativos en C? Por supuesto. Veámoslo:

#include <stdio.h>


int main(int argc, char **argv)
{
    int v[] = {11, 12, 13, 14, 15};
    int len = sizeof( v ) / sizeof( int );

    for(int i = -len; i < len; ++i) {
        printf( " #%d: %d |", i, i[ v ] );
    }

    return 0;
}

Salida:

#-5: 1 | #-4: 0 | #-3: 0 | #-2: -2 | #-1: 5 | #0: 11 | #1: 12 | #2: 13 | #3: 14 | #4: 15 |

En el caso de este programa, estamos recorriendo el espacio en memoria anterior a la posición de v. En este caso, funciona, y nos devuelve el contenido de la memoria en esas posiciones. Por supuesto, esto entra dentro de lo que se conoce como comportamiento indefinido (undefined behaviour), ya que está recorriendo memoria que no se ha reservado previamente. De nuevo, en este caso, estamos explorando las posiciones previas a v dentro de la pila de llamadas o stack. Recordemos que, para cada función, se crea un marco dentro del stack en el que se almacena la dirección de retorno y las variables locales.

Podemos, de hecho, ver el contenido de v1 desde v2.

#include <stdio.h>


int main(int argc, char **argv)
{
    int v1[] = {11, 12, 13, 14, 15};
    int v2[] = {21, 22, 23, 24, 25};    
    int len = sizeof( v1 ) / sizeof( int );

    for(int i = -(2 * len); i < len; ++i) {
        printf( " #%d: %d |", i, i[ v2 ] );
    }

    return 0;
}

Salida:

#-10: -10 | #-9: 5 | #-8: 11 | #-7: 12 | #-6: 13 | #-5: 14 | #-4: 15 | #-3: 0 | #-2: 0 | #-1: 0 | #0: 21 | #1: 22 | #2: 23 | #3: 24 | #4: 25 |

Efectivamente, dado que tanto v1 como v2 están creados dentro del stack, y teniendo en cuenta que uno se crea antes que el otro, es probable que suceda que si recorremos las posiciones anteriores a v2 (interpretadas como int), aparezcan los valores de v1.

Ni qué decir tiene que esto vuelve a ser comportamiento indefinido. No tiene sentido que se asuma que, por el hecho de que hayan sido definidos unos antes que otros, la posición de un vector en memoria puede adivinarse desde otro.

Estas prácticas son conocidas como aritmética de punteros. Esta característica tiene mucha utilidad... bien utilizada, claro.

Sí, hay usos legítimos de la aritmética de punteros. Por ejemplo, teniendo en cuenta que C almacena las matrices por filas, podríamos utilizar la aritmética de punteros para recorrer una matriz por columnas.

#include <stdio.h>


#define LEN 3


int main(int argc, char **argv)
{
    const int m0[][LEN] = {{11, 12, 13}, {21, 22, 23}, {31, 32, 33}};    
    const int * m = &m0[0][0];

    // Recorrido por columnas
    for(int i = 0; i < LEN; ++i) {
        for(int j = 0; j < LEN; ++j) {
            printf( " #%d, %d |",
                    ( j * LEN ) + i,
                    m[ ( j * LEN ) + i ] );
        }
    }

    // Recorrido secuencial
    printf("\n");
    for(int n = 0; n < LEN * LEN; ++n) {
        printf( " %d ", m[ n ] );
    }

    return 0;
}

Salida:

#0, 11 | #3, 21 | #6, 31 | #1, 12 | #4, 22 | #7, 32 | #2, 13 | #5, 23 | #8, 33 |
 11  12  13  21  22  23  31  32  33

En la salida, podemos ver el recorrido por columnas en la primera línea, y el recorrido por filas, lineal, en la siguiente; a pesar de que la matriz está creada como un vector de vectores, o lo que es lo mismo, un vector de punteros a vectores (por cada una de las filas). Pero esto no es más que un artificio creado por C, como se puede ver en el siguiente esquema:

[ 0 ]   --->   [11,
                12,
                13,
[ 1 ]   --->    21,
                22,
                23,
[ 2 ]   --->    31,
                32,
               [33]

En conclusión, C es un lenguaje de programación muy antiguo y relativamente sencillo, que crea muy pequeñas abstracciones por encima del hardware. Esto proporciona a C una gran potencia, pero también provoca grandes errores potenciales de seguridad, casi siempre basados en escribir más allá del final de un vector, algo que puede aprovecharse para colocar código directamente para ser ejecutado tras el retorno de la función.

Por otra parte, debido precisamente a la presencia potencial de errores de seguridad, C es hoy por hoy un lenguaje de programación que las nuevas generaciones de programadores desconoce, pues la enseñanza ha pasado a enfocarse en lenguajes de programación de mucho más alto nivel.

Y es por eso que, hoy por hoy, para las nuevas generaciones de informáticos C, es poco más o menos que magia negra.

Retro-imprimiendo

Baltasar García Perez-Schofield — Wed, 04 Feb 2026 10:49:28 +0000

Ya he escrito varias veces sobre mis (des)aventuras tratando de utilizar una impresora con mi Sinclair Spectrum 128k.

Bien, pero... ¿cómo se imprimía en papel en aquella época? ¿Se puede seguir imprimiendo así? Bueno... Es una historia muy larga. ¿Alguna vez te has fijado en los códigos ASCII por debajo del espacio en blanco (el #32)?

DEC	HEX	Símbolo	Descripción
0	0	NUL	Carácter Nulo
1	1	SOH	Inicio de Encabezado
2	2	STX	Inicio de Texto
3	3	ETX	Fin de Texto
4	4	EOT	Fin de Transmisión
5	5	ENQ	Consulta
6	6	ACK	Acuse de recibo
7	7	BEL	Timbre
8	8	BS	Retroceso (borrar)
9	9	HT	Tabulación
10	0A	LF	Salto de línea
11	0B	VT	Tabulación Vertical
12	0C	FF	Avance de página
13	0D	CR	Retorno de carro
14	0E	SO	Desactivar mayúsculas
15	0F	SI	Activar mayúsculas
16	10	DLE	Escape enlace datos
17	11	DC1	Ctrl. dispositivo 1
18	12	DC2	Ctrl. dispositivo 2
19	13	DC3	Ctrl. dispositivo 3
20	14	DC4	Ctrl. dispositivo 4
21	15	NAK	ACK negativo
22	16	SYN	Síncronía en espera
23	17	ETB	Fin bloque
24	18	CAN	Cancelar
25	19		Fin del medio
26	1A		Substitución
27	1B	ESC	Escape
28	1C	FS	Separador de archivos
29	1D	GS	Separador de grupo
30	1E	RS	Separador de registro
31	1F	US	Separador de unidad

Los primeros ordendores no tenían pantallas, sino que se comunicaban con el usuario a través de una impresora, que funcionaba como una especie de teletipo. La conexión se realizaba a través de la interfaz serie RS-232. Es cierto; no existía USB en aquella época. Esta conexión serie es la responsable de la necesidad de códigos de caracteres como #4 (fin de la transmisión), #6 (ACK o acuse de recibo).

Para el manejo de la impresora son los códigos #10 (salto de línea), #13 (retorno de carro), o #7 (la campana). ¿En qué se inspiraron para estas impresoras? Pues en las máquinas de escribir de la época.

Mención aparte merecen los códigos #13 y #10. Si vemos un archivo de texto en Windows o MS-DOS con un visor hexadecimal, veremos cada cambio de línea representado con los códigos 0A0D, es decir LF y CR. Y es que, aquellas impresoras funcionaban con un carro que llevaba una cabecera de matriz de puntos (de ahí que se las llamara impresoras matriciales o dot matrix printers). Y, sí, en este tipo de impresoras no solo era necesario hacer avanzar el papel (cosa que se hacía con un rodillo, como en las máquinas de escribir, solo que automatizado con un motor), sino también llevar el carro hacia la izquierda. ¿Por qué no es así en UNIX/LINUX? Los desarrolladores decidieron que dedicar dos caracteres por cada cambio de línea era excesivo, una vez descartados aquellos teletipos y asumidos los terminales, así que lo simplificaron a solo LF.

Por cierto, es importante tener en cuenta que los terminales no eran ordenadores, sino solo proporcionaban una pantalla para ver la salida del ordenador, y un teclado integrado para introducir datos en él.

Hoy por hoy, la necesidad de un protocolo serie ha sida eliminada de cuajo al tener USB, que permite conexiones y desconexiones en caliente, mucha más velocidad, y otras ventajas, como la autoconfiguración, también llamada Plug & Play. Además las impresoras ya no utilizan estos caracteres especiales para saber cómo imprimir texto, sino que utilizan PostScript, por lo que, hoy por hoy, estos 31 caracteres (con algunas excepciones, como el #27 (escape), o el #8 (borrado a la izquierda), no se utilizan.

Así, imprimir un archivo podía hacerse tan fácil como volcar un archivo en un archivo "especial". Y es que, todos los sistemas operativos actuales siguen la metáfora todo es un archivo. Es decir, en lugar de tratar cada dispositivo como un caso especial, se trata de obtener datos de él haciendo como que se lee de un archivo, y enviarle datos haciendo como que se escribe en un archivo. Todos los programadores sabemos que, en un programa en C, los descriptores de archivo 0 y 1 se corresponden, respectivamente, con el teclado y la pantalla. Es decir, el archivo #0 es un archivo de solo lectura, y leyendo de él se obtiene la entrada del usuario. El archivo #1 es de solo escritura, y escribiendo en él se muestra texto en la pantalla del usuario.

Muchos dispositivos requieren sin embargo un manejo más detallado, para lo que existe la llamada al sistema operativo IOCTL, que es capaz de enviar códigos y datos de manera especial para acceder a características de bajo nivel.

En cualquier caso, en Windows y en MS-DOS se puede imprimir un archivo de texto archivo.txt en la impresora por defecto utilizando:

$ type archivo.txt > prn

Sí, PRN es un archivo especial que representa a la impresora, y es la razón por la que no se puede crear un archivo de nombre prn en MS-DOS o Windows.

En UNIX/LINUX, el comando es ligeramente distinto, pero el resultado es el mismo.

$ cat archivo.txt > /dev/lp0

El comando cat vuelva el archivo, igual que type en MS_DOS o Windows. El carácter > indica que la salida del anterior comando se va a redirigir, de la pantalla a otro dispositivo. PRN es el dispositivo de la impresora en MS_DOS/Windows, mientras que en UNIX solía ser /dev/lp0, pero en tiempos modernos es /dev/usb/lp0.

He escrito print.py, una pequeña utilidad que permite volcar datos en texto plano directamente a la impresora por defecto. Admite algunos códigos, como los siguientes:

^[  : chr(s) 27
^v  : chr(s) 12
^l  : chr(s) 10
^r  : chr(s) 13

Si quieremos enviar un texto a la impresora, podemos hacer lo siguiente:

$ python print.py --send "hola!^v"

El comando anterior vuelca el mensaje hola en la impresora, que lo imprime, y a continuación manda el código ^v, que se corresponde con el carácter #12, y realiza un FF (form feed), o alimentación de página, lo que hará que salga el papel.

Si preferimos imprimir un archivo de texto, podemos hacerlo con:

$ python print.py --file datos.txt

¿Cuál es el corazón del programa? Pues nada, abrir un archivo en modo texto y escribir en él.

class Printer:
    # más cosas...

    @property
    def device(self):
        return self.__dev
    ...

    def send(self, data: str):
        """Sends new data to the printer.
            :param data: the data to send to the printer, as str.
        """
        with open(self.device, "wt") as dev:
            dev.write(data)
        ...
    ...

    def sendfile(self, filename: str):
        """Sends a whole file to the printer.
            :param filename: the path of the file to print.
        """
        with open(filename, "rt") as f:
            for l in f:
                self.send(l.rstrip())
                self.send(interpret_data("^r^l"))
            ...
        ...

        self.send(interpret_data("^v"))
    ...

Para terminar... ¿se puede comprar hoy en día una impresora matricial? La respuesta es sí: desde impresoras "normales" hasta impresoras de tickets para comercios.

Continuará.

qb64: un "retro" GW-BASIC, para ordenadores modernos

Baltasar García Perez-Schofield — Wed, 28 Jan 2026 15:20:41 +0000

QB64 es un entorno completo de programación que resulta ser un clon de aquel QBasic/QuickBasic de los años de MS-DOS.

Si sabes de lo que estoy escribiendo, es que viviste aquella época de los 90, como yo. Si no, es que te lo has perdido todo.

También en aquellos años (en los 90), existía QBasic, que era muy parecido a QuickBasic, pero sin la capacidad de compilar su código.

Por cierto, en Options >> Display, encontraremos la oportunidad de cambiar la visualización de 80x25 a 120x50, mucho más aconsejable.

Si, sí. QB64 genera código ejecutable de 64 bits. Pero además, es portable a nivel de código fuente entre Mac, Windows y Linux.

O dicho de otra forma: además de Free Pascal (para Pascal "retro"), puedes programar en BASIC "retro" y generar código sin que exista forma alguna de distinguirlo del código generado por gcc para C, por poner un ejemplo.

Así, en modo texto (aunque existe un IDE gráfico llamado Phoenix), podemos teclear nuestros programas, que el IDE los compile, y ejecutarlos con solo pulsar F5.

Como ejemplo, programé este cálculo de Fibonacci:

' Secuencia de Fibonacci

For n = 1 To 25
    Print fibo(n);
Next


Function fibo (x)
    Dim n1 As Long
    Dim n2 As Long
    Dim aux As Long

    n1 = 1
    n2 = 1

    For n = 2 To x
        aux = n2
        n2 = n1 + n2
        n1 = aux
    Next

    fibo = n2
End Function

Con la salida, previsible, siguiente.

1 1 2 3 5 8 13 21 34 55 89 144 233 377...

Para poder llegar a los resultados más altos, es necesario cambiar Integer, el tipo que usaríamos normalmente, por Long, un entero de 32 bits.

Pero... ¿qué incorpora este ejecutable?

$ ldd fibo                                                                   
        linux-vdso.so.1 (0x00007f7cc39f9000)
        libGL.so.1 => /usr/lib/libGL.so.1 (0x00007f7cc394b000)
        libGLU.so.1 => /usr/lib/libGLU.so.1 (0x00007f7cc38f4000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0x00007f7cc37b2000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f7cc3400000)
        libm.so.6 => /usr/lib/libm.so.6 (0x00007f7cc36a4000)
        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f7cc33d3000)
        libc.so.6 => /usr/lib/libc.so.6 (0x00007f7cc3000000)
        libGLdispatch.so.0 => /usr/lib/libGLdispatch.so.0 (0x00007f7cc335a000)
        libGLX.so.0 => /usr/lib/libGLX.so.0 (0x00007f7cc3329000)
        libOpenGL.so.0 => /usr/lib/libOpenGL.so.0 (0x00007f7cc3305000)
        libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007f7cc32da000)
        /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f7cc39fb000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0x00007f7cc369b000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007f7cc32d2000)

Podemos ver cómo, además de incorporar las bibliotecas básicas del sistema operativo (esto cambiará en Windows o Mac), está claro que genera código C++, pues incluye la librería estándar de este lenguaje de programación. También podemos ver que proporciona capacidades gráficas, pues OpenGL está presente.

¡Probemos! Sí que tenemos que hacer algo "raro" con respecto a GW-BASIC: crear una "pantalla" del ancho y alto que deseamos:

screen _newImage(ancho, alto, profundidad_de_color)

Podemos dibujar una línea con line:

line (x1, y1) - (x2, y2)

¿Podemos dibujar un triángulo? Al margen de que haya otras maneras, si dibujamos "todas" las líneas desde un vértice superior hasta, primero, el vértice inferior izquierdo, y después al vértice inferior derecho, y todas las líneas intermedias, ya lo tendremos.

La esquina superior izquierda es el origen de coordenadas, es decir, (0, 0). Podemos colocar el vértice superior en (maxX / 2, maxY / 2). El vértice inferior izquierdo sería (100, maxY), y el vértice inferior derecho, (maxX - 100, maxY).

' Draw a triangle

Const maxX = 620
Const maxY = 450
Screen _NewImage(maxX, maxY, 32)


Call drawTriangle(maxX, maxY, maxY / 2)

Sub drawTriangle (maxX, maxY, length)
    ' The upper vertex is the center of the screen
    orgX = Int(maxX / 2)
    orgY = Int(maxY / 2)

    ' From the lower left to the lower right
    For x = 100 To maxX - 100
        Line (orgX, orgY)-(x, orgX + length)
    Next
End Sub

La salida es un triángulo, lo prometido.

Mientras las funciones (que se crean con FUNCTION... END FUNCTION) pueden ser invocadas directamente, tal y como estamos acostumbrados en lenguajes de programación modernos, los procedimientos tienen que ser invocados con CALL.

BASIC es sin duda el lenguaje de programación retro. No puedo dejar de pensar en ZX BASIC de Boriel, el Basic del ZX Spectrum pero mucho más moderno, capaz de compilar para el aparato de Sinclair o el ZX Spectrum Next.

¿Y tú? ¿Cuáles son tus vivencias con BASIC?

El acertijo de Monty Hall

Baltasar García Perez-Schofield — Wed, 21 Jan 2026 13:15:03 +0000

El acertijo o Problema de Monty Hall ya es ampliamente conocido a estas alturas. De hecho, incluso el problema de Monty Hall tiene su propia entrada en la Wikipedia. Pero no lo mires todavía, ¡vas a estropear la diversión! Más aún, si le planteas este problema a una IA, lo reconocerá sin dudar aunque no le indiques cuál es su nombre.

Recientemente, Raquel de la Morena y su equipo han dedicado un vídeo a explicar el problema de Monty Hall. ¿He dicho ya que si te lo ves ahora, vas a estropear la diversión?

Todo proviene de un concurso presentado por Monty Hall (de ahí el nombre por el que es conocido). En este concurso se presentaban tres puertas, detrás de las cuales había dos cabras y un coche deportivo. El concurso consistía, claro, en acertar con la puerta que escondía el coche. Es posible que a alguno le gustase la posibilidad de llevarse a una cabra a casa, pero no tengo ni idea de si era posible o no. El caso es que, en este concurso, el presentador podía abrir una de las puertas donde él sabía que no estaba el coche. En estos casos, ¿era más ventajoso mantener la elección inicial de la puerta, o en cambio, elegir la que aún está cerrada?

Una mujer, reconocida como poseedora del índice de inteligencia mayor del mundo, Marilyn vos Savant, tenía una columna en un periódico para responder preguntas (se supone que especialmente difíciles, claro). Un lector le propuso la misma pregunta un poco más arriba. Su respuesta fue polémica: es mucho más recomendable cambiar de puerta.

Si pensaste "da igual", estás, como yo, entre la gran mayoría de personas. Si pensaste lo mismo que Marilyn vos Savant, entonces estás entre los "escogidos", la gente excepcionalmente inteligente que no se deja engañar por las apariencias. Porque este problema se plantea como una paradoja, es decir, casi todo el mundo, independientemente de sus conocimientos o formación, se decanta por la primera opción, la mayoritaria. Mayoritaria e incorrecta.

De hecho, buena parte de la polémica que se lió con aquella columna tomó la forma de miles de cartas, alrededor de diez mil. Más aún, de estas, mil provenían de matemáticos que estaban visceralmente en desacuerdo con esta mujer, lo que dejaron claro con una actitud claramente clasista, y también machista.

¿Por qué la respuesta es la que no es intuitiva? Eso es lo que resolveremos mediante código Python, con el que simularemos, utilizando números pseudo-aleatorios (lo que vendría a ser un método Montecarlo), varias jugadas, a ver cuál estrategia (cambiar o no cambiar), es la que objetivamente resulta ser la mejor.


import random as rnd


def generate_random_list(max):
    toret = []
    for _ in range(max):
        toret.append(rnd.randint(1, 3))
    ...

    return toret
...


if __name__ == "__main__":
    print(str.join(", ", [str(x) for x in generate_random_list(10)]))
    print(str.join(", ", [str(x) for x in generate_random_list(10)]))
...

Esto puede producir la siguiente salida:

3, 2, 2, 1, 3, 3, 3, 1, 2, 1
2, 1, 2, 2, 2, 3, 1, 2, 3, 2

Podríamos interpretarla de la manera siguiente: la fila superior es el número de puerta (de 1 a 3) en la que se sitúa el premio, mientras que la segunda fila es el número de puerta (también de 1 a 3) elegida por el concursante. Podemos maquillar un poco la salida:

0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1
1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0
-------------------------------------
1 | 1 | 3 | 2 | 3 | 1 | 1 | 3 | 1 | 3
3 | 1 | 3 | 2 | 2 | 1 | 2 | 2 | 3 | 1
-------------------------------------
Aciertos:  4

Esto lo obtenemos cambiando un poco el código, como se ve a continuación (no se incluye la función generate_random_list(), que se mantiene tal cual).

def count_coincidences(l1, l2):
    toret = 0
    for i in range(len(l1)):
        if l1[ i ] == l2[ i ]:
            toret += 1
        ...
    ...

    return toret
...


if __name__ == "__main__":
    rnd.seed()
    l_elecciones = generate_random_list(10)
    l_premios = generate_random_list(10)
    print("0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1")
    print("1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0")
    print("-------------------------------------")
    print(str.join(" | ", [str(x) for x in l_elecciones]))
    print(str.join(" | ", [str(x) for x in l_premios]))
    print("-------------------------------------")
    print("Aciertos: ", count_coincidences(l_elecciones, l_premios))    
...

Lo que estamos haciendo es utilizar listas paralelas. En la primera, colocamos las elecciones realizadas, mientras en la segunda colocamos las puertas con premios. Podemos compactarlo todo un poco si utilizamos una sola lista, pero de pares. Cada par está formado por la misma información. Es decir, si la puerta elegida fue la primera, y la puerta con premio la tercera, el par será (1, 3). Si hacemos una prueba con 10 puertas, como más arriba, tendremos una lista como [(1, 3, (1, 1), (3, 3), (2, 2), (3, 2), (1, 1), (1, 2), (3, 2), (1, 3), (3, 1)], mientras antes teníamos dos listas: [1, 1, 3, 2, 3, 1, 1, 3, 1, 3], y [3, 1, 3, 2, 2, 1, 2, 2, 3, 1].

def generate_random_list_door_pairs(max, num_doors=3):
    toret = []
    for _ in range(max):
        toret.append(
                tuple([rnd.randint(1, num_doors),
                        rnd.randint(1, num_doors)]))
    ...

    return toret
...

Además, podemos mover el código para visualizar los datos a su propia función. Ahora tenemos que tener en cuenta que recibimos una sola lista, de pares.

def print_to(f, l_pairs):
    print("0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1", file=f)
    print("1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0", file=f)
    print("-------------------------------------")
    print(
            str.join(" | ", [str(x) for x in
                                [pair[0] for pair in l_pairs]]),
            file=f)
    print(
            str.join(" | ", [str(x) for x in
                                [pair[1] for pair in l_pairs]]),
            file=f)
    print("-------------------------------------", file=f)
    num_correct = len(extract_coincidences(l_pairs))
    total = len(l_pairs)
    percentage = (num_correct / total) * 100
    print(f"Correct: {num_correct}/{total} ({percentage:5.2f}%)\n", file=f)
...

Finalmente, podemos extraer los pares con ambos valores iguales, en lugar de contarlos directamente. Tomando la longitud de esta lista de pares extraidos, tenemos el número de coincidencias. En lugar de utilizar un bucle, utilizaremos una comprensión de listas.

def extract_coincidences(l_pairs):
    return [pair for pair in l_pairs if pair[0] == pair[1]]
...

Podemos invocar el código con:

if __name__ == "__main__":
    # more...
    max = 100000

    if args.get("verbose"):
        max = 10
    ...

    generated_pairs = generate_random_list_door_pairs(max)

    if max < 40:
        print_to(sys.stdout, generated_pairs)
    ...
...

La salida sería como la siguiente:

0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1
1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0
-------------------------------------
3 | 1 | 3 | 1 | 3 | 3 | 2 | 1 | 3 | 2
1 | 3 | 1 | 3 | 1 | 1 | 2 | 3 | 2 | 2
-------------------------------------
Correct: 2/10 (20.00%)

Claramente vemos que hay dos coincidencias, en la 7ª y 10ª (esto depende de la ejecución, en otras podemos llegar incluso al 50%). Podemos utilizar matplotlib para crear una gráfica, un simple gráfico de barras sobre el porcentaje de aciertos.

def show_graph(percentage_correct, msg_explain):
    plt.bar(
        [msg_explain],
        [percentage_correct],
        color=["blue", "green"])

    plt.yticks(range(0, 101, 10))
    plt.title("Monty Hall paradox")
    plt.ylabel("Percentage (0-100%)")
    plt.show()
...

Si invocamos todo esto con un número considerable de pruebas, es decir, si la lista de pares es de, pongamos, 10000, conseguiremos una estadística suficientemente fiable, respaldada por un número de casos considerable.

if __name__ == "__main__":
    # more...
    max = 100000

    if args.get("verbose"):
        max = 10
    ...

    generated_pairs = generate_random_list_door_pairs(max)
    msg = "correct selections (no door change)"
    correct_pairs = extract_coincidences(generated_pairs)
    num_correct = len(correct_pairs)
    percentage = (num_correct / max) * 100

    if max < 40:
        print_to(sys.stdout, generated_pairs)
    ...

    show_graph(percentage, f"{msg}: {percentage: 5.2f}%")
...

La gráfica sería la siguiente:

Podemos ver cómo los casos con acierto de premio alcanzan un 33.2% del total.

Esto tiene todo el sentido. Si no cambiamos de puerta, lo que estamos haciendo es confiar en que nuestra primera elección fue desde el principio la correcta, que esa es la puerta con premio. Dado que hay tres puertas, la probabilidad es de 1/3 o 33% sobre el total.

Podemos ahora abordar la estrategia de cambiar de puerta. Para crear un par (puerta_con_premio, puerta_elegida), si cambiamos de puerta tras revelar otra (sin premio), podemos utilizar el siguiente código:

def create_selection_changed(num_doors=3):
    # Initial choice
    doors = list(range(1, num_doors + 1))
    treasure_door = rnd.choice(doors)
    chosen_door = rnd.choice(doors)

    # One door not containing the treasure is revealed
    # Also it won't be the selected door
    door_revealed = set(doors)
    door_revealed.discard(treasure_door)
    door_revealed.discard(chosen_door)
    revealed_door = rnd.choice(list(door_revealed))

    # Change your chosen door
    available_doors = set(doors)
    available_doors.discard(chosen_door)
    available_doors.discard(revealed_door)
    chosen_door2 = rnd.choice(list(available_doors))

    return tuple([treasure_door, chosen_door2])
...

La puerta elegida es chosen_door, mientras que la prueba tras la que se esconde el premio es la treasure_door. Creamos un conjunto set() con las tres puertas (es decir, {1, 2, 3}), llamado door_revealed. Si a este conjunto le quitamos la puerta premiada (nunca revelaremos la puerta premiada), y también la puerta elegida por el concursante (estas dos puertas pueden ser la misma), entonces nos quedan las puertas que pueden ser reveladas (en el caso de tres puertas, serán dos posibles puertas si el concursante ha elegido la puerta premiada, o una sola en otro caso).

Así, empezamos con {1, 2, 3}, y tenemos en cuenta que la puerta premiada es la 1, y la elegida por el concursante es la 3. Así, la puerta a revelar es la 2. El concursante tiene la duda de mantenerse con la que eligió inicialmente (la 1), o cambiar (a otra que no sea ni la 1, ni la 2, una la elegida inicialmente, y la otra la revelada como que no tiene premio). Es decir, si tenemos {1, 2, 3}, eliminamos la 1 y la 2, y nos queda que la puerta elegida es la 3. Así, finalmente el par generado sería (3, 3).

Si empezamos igual que antes, con {1, 2, 3} pero con la puerta premiada siendo la 3, y la puerta elegida siendo también la 3, entonces la puerta a revelar puede ser la 1 o la 2, lo cual se elige al azar. Para cambiar la puerta, eliminamos la puerta elegida inicialmente, la 3, y la puerta revelada (pongamos que la 1), entonces nos queda que la única posibilidad para poder cambiar es la 2. Por tanto, el par ahora sería (3, 2).

Podemos crear fácilmente el número que deseemos de estos pares con la estrategia de cambio de puerta mediante la siguiente función:

def generate_random_list_door_pairs_after_change(max, num_doors=3):
    selections_changed = []

    for _ in range(max):
        selections_changed.append(create_selection_changed(num_doors))
    ...

    return selections_changed
...

Solo tenemos que invocar el código de la forma siguiente:

if __name__ == "__main__":
    # more...
    max = 100000

    if args.get("verbose"):
        max = 10
    ...

    generated_pairs = generate_random_list_door_pairs_after_change(max)
    msg = "correct selections (door changed)"
    correct_pairs = extract_coincidences(generated_pairs)
    num_correct = len(correct_pairs)
    percentage = (num_correct / max) * 100

    if max < 40:
        print_to(sys.stdout, generated_pairs)
    ...

    show_graph(percentage, f"{msg}: {percentage: 5.2f}%")
...

Y ya está. El código Python completo para esta paradoja de Monty Hall es un poco distinto porque permite seleccionar el cálculo de la estrategia con cambio, la estrategia sin cambio, o ambas para poder compararlas.

Si creamos, de nuevo, una lista de casos de 100000 elementos, tendremos una base de casos suficiente como para respaldar una estadística fiable.

Si lo invocamos, la salida será la siguiente.

Ahora, lo que tenemos es una probabilidad de acierto... ¡de más del 66%!

El software creado nos permite probar ambas estrategias, y compararlas en una gráfica común, como se puede ver a continuación.

Pues resulta que hemos demostrado que, efectivamente, la estrategia que proporciona más probabilidad de acierto es el cambio de puerta. La clave resulta ser que la puerta revelada no lo es al azar, sino que el presentador la escoge entre las puertas que no tienen premio y que el concursante no ha elegido, lo que al final en lugar de 1/3 tenemos 2/3 de posibilidades de acertar. Es decir, más de un 66%.

Supongamos que en lugar de tres, son diez puertas. El concursante escoge una de las puertas, con 1/10 de probabilidades de acertar, y por tanto, 9/10 de errar. El presentador le revela una puerta donde puede estar el premio o no, además de la elegida inicialmente. Y además, le dice que el resto de las puertas no tienen premios. Es decir, de 10 puertas el concursante escoge la 3. El presentador le revela que en la 9 puede haber o no premio, pero que en todas las restantes (1, 2, 4, 5, 6, 7, 8, 10), solo hay cabras.

¿Es más probable que hayamos acertado en nuestra elección inicial (1/9 de posibilidades de acertar con la puerta del premio), o será mejor cambiar a esa puerta que estaba inicialmente entre el 9/10 restante?

Código Python completo para simular la paradoja de Monty Hall