Apuntes de eduardófilo

G&W Zelda hack

Sun, 08 Mar 2026 15:45:00 +0100

Un conocido fabricante japonés de videojuegos empezó a comercializar a finales de 2022, un par de máquinas replicando el aspecto de algunas de las viejas G&W, sobre la base de un microcontrolador STM32H7 que ejecuta un firmware baremetal con emuladores de NES y GB, tres juegos clásicos y una aplicación reloj inspirados en la franquicia Zelda. La máquina resulta muy interesante por las virtudes de estar basada en un microcontrolador, en lugar de un microprocesador, es decir gran duración de la pequeña batería que contiene (la de un joycon de Switch), arranque y modo suspensión instantáneos. El soporte de datos es un pequeño chip flash NOR de 4MB (en el caso del modelo Zelda), suficiente para alojar los emuladores y juegos mencionados, pero muy escaso si se quiere sacar partido de la máquina y de su relativamente potente CPU.

El firmware original sirve para comprobar la solvencia de la plataforma para emular al menos las máquinas de 8 bit que funcionan originalmente, por lo que en seguida el dispositivo resultó atractivo para la comunidad hacker. Al poco tiempo de empezar a comercializarse ya aparecieron procedimientos para desbloquear y modificar la máquina de manera que se pudieran instalar más emuladores y juegos.

La primera modificación importante propuesta por la comunidad consistía en sustituir el chip flash por otro de 64MB para disponer de más espacio para juegos y emuladores. Tiempo después la modificación evolucionó para incluir un slot de tarjetas microSD donde almacenar los juegos y savestates, así como para simplificar enormemente el proceso de actualización, convirtiendo a la máquina así modificada en una máquina de emulación portátil inigualable en aspectos como portabilidad, tamaño, duración de la batería y tiempos de arranque.

Con cualquiera de las dos modificaciones se consigue emular las siguientes máquinas:

Amstrad CPC6128 (beta)
Atari 2600
Atari 7800
ColecoVision
Gameboy / Gameboy Color
Game & Watch / LCD Games
MSX1/2/2+
Nintendo Entertainment System
PC Engine / TurboGrafx-16
Pokémon Mini
Sega Game Gear
Sega Genesis / Megadrive
Sega Master System
Sega SG-1000
Tamagotchi P1
Watara Supervision

En este artículo vamos a describir los pasos para realizar las dos modificaciones. La modificación para añadir el slot microSD requiere también la sustitución de la flash, ya que cada vez que carguemos un juego nuevo de la microSD se grabará en el chip flash, y el original de 4MB soporta pocos ciclos de escritura dado que no estaba previsto que se utilizara de esta forma.

Todo el proceso ha sido realizado sobre un sistema Linux. En principio el desarrollo sobre sistemas Windows y MacOS X también es posible, pero los pasos para instalar los requerimientos y el software que utilizaremos necesariamente cambiarán.

Conexión al puerto SWD¶

El desbloqueo del procesador y la modificación del firmware se hacen a través del puerto SWD que habitualmente tienen los microcontroladores STM32 para programar su memoria flash interna y depurar los desarrollos. Este puerto SWD se encuentra en la PCB sin poblar, es decir sin pines o conectores soldados.

Para hacer la conexión con dicho puerto hay varias opciones:

Soldar cables directamente.
Introducir cables limpios o cables de pin macho, inclinándolos para forzar el contacto.
Utilizar pinzas sonda de conexión especializadas.
Utilizar pinzas pogo pin (Single row 5pin).
Rutear los pines SWDIO y SWCLK hacia el puerto USB-C.

Versión difícil¶

Como empecé a cacharrear con la máquina antes de que apareciera el mod de microSD, en su momento realicé el ruteado del puerto SWD al USB-C. Si se va a terminar realizando el mod de microSD no merece la pena el esfuerzo, dado que a partir de entonces el flasheo del firmware se realizará desde la propia microSD. De todas formas, a propósitos de documentación vamos a describir cómo se haría el ruteado.

El puerto USB-C sólo tiene conectados los pines de alimentación ya que está previsto únicamente para cargar la máquina. Por tanto se pueden utilizar los pines D+ y D- que están libres para cablearlos a los pines SWDIO y SWCLK que son los únicos imprescindibles del puerto SWD. Necesitaremos también conectar a 5V y GND, pero estos ya se encuentran cableados en el puerto USB-C. El ruteado se hace con un fino cable barnizado (enamel) de los que se utilizan para construir bobinas. La soldadura a los dos pines centrales del puerto USB-C que son los que corresponden a D+ y D- es complicada al tener un paso muy pequeño, pero con paciencia y flux puede lograrse.

Una vez resuelto la única parte difícil del procedimiento, es decir soldar los cables al puerto USB, estos se van sujetando cada cierta distancia con cinta Kapton y dirigiendo hacia la zona de la batería por donde se aprovecha el rebaje a ambos lados que hay del alojamiento que la rodea para pasar uno de los cables. El otro se conduce por el espacio que hay entre alojamiento de la batería y la PCB. De esta forma se consigue que ambos cables no puedan tocarse, aunque en teoría al estar barnizados no debería haber problema, se adopta este camino separado como precaución adicional.

Una vez que los cables alcanzan las proximidades del puerto SWD, se utilizan los dos test pads que pueden verse en la foto para realizar las soldaduras.

La correspondencia entre D+ y D- en el puerto USB-C con los SWDIO y SWCLK del puerto SWD, puede hacerse de cualquier forma siempre que tengamos claro donde está cada cual para más tarde hacer el adaptador USB-SWD que necesitaremos. En este montaje se ha optado por la siguiente correspondencia.

D+ ↔ SWDIO
D- ↔ SWCLK

Warning

La idea en un principio era adoptar la correspondencia utilizada en esta otra guía, pero por un error cometido al principio, se terminó haciendo justo al revés. Como se comentaba antes, en realidad no es problema siempre que se tenga claro cómo están hechas las conexiones. Este aviso es sólo por si alguien intenta seguir ambas guías de forma simultánea, para que se tenga en cuenta dicha diferencia.

Una vez hecho el ruteado del puerto, necesitaremos construir el adaptador para poder extraer las señales SWDIO y SWCLK del puerto USB-C. Para ello se corta un cable USB-A convencional para tener acceso a los cuatro cables que contiene por separado y se sueldan a ellos conectores hembra de pin. El adaptador se completa con un adaptador USB-A a USB-C que se marca para orientarlo correctamente cuando lo vayamos a utilizar, ya que sólo hemos ruteado los pines D+ y D- de uno de los dos lados (el puerto USB-C es reversible).

Los colores de los cables suelen estar estandarizados de la siguiente forma:

Rojo: 5V
Negro: GND
Verde: D+
Blanco: D-

Versión fácil¶

La manera recomendada para hacer la conexión al puerto SWD (si no se quiere soldar, que es la opción más fiable) es mediante pinzas sonda de conexión especializadas. Para aplicar dichas pinzas, es recomendable desconectar previamente la batería de la consola. El conector de la batería salta fácilmente al introducir una pieza fina de plástico por debajo del mismo.

Sonda de programación¶

Ya tenemos resuelto dónde conectar en la consola. Ahora necesitamos un dispositivo capaz de comunicarse con ese puerto SWD del microcontrolador. Las opciones son:

Me decanté por usar una Raspberry Pi Pico. Para que funcione como sonda de programación SWD hay que cargarle el firmware debugprobe. En mi caso utilicé el fichero picoprobe.uf2 de esta release en concreto. Para flashear la Pico sólo hay que conectarla al ordenador por USB mientras pulsamos el botón BOOTSEL para forzar el modo en el que se monta como una unidad de almacenamiento y arrastrar el fichero .uf2 a esa unidad. Tras autoflashearse, la Pico se reiniciará automáticamente y empezará a funcionar como sonda de programación SWD.

Una vez programada la Pico, solo queda hacer las conexiones de los cables que habíamos conectado al puerto SWD de la Game&Watch. Podemos utilizar el mismo tipo de pinzas que aplicamos a la consola, aunque en mi caso utilicé otras similares pero un poco más robustas, ya que el espaciado de los pines GPIO de la Pico es mucho mayor.

El conexionado entre Game&Watch y Raspberry Pi Pico es:

Pico	GnW	Color
3	3	Negro
4	5	Blanco
5	2	Verde

Desbloqueo del microcontrolador¶

Una vez resuelta la conectividad a la placa, el primer paso en la modificación es el desbloqueo del microcontrolador STM32H7 para que podamos sustituir el firmware que hay en su memoria flash interna así como poder escribir en la memoria flash externa (con código que inyectaremos en el propio microcontrolador).

Esta tarea se efectúa con el conjunto de utilidades gnwmanager. Este paquete se encuentra registrado en PyPI por lo que se puede instalar muy fácilmente con pip (preferiblemente dentro de un entorno virtual Python).

bash$ pip install gnwmanager$ gnwmanager install openocd

Ahora, tras volver a conectar la batería de la consola si la habíamos desconectado, ejecutaremos el siguiente comando:

(gnwmanager) $ gnwmanager unlock

El proceso se interrumpirá en un par de ocasiones dando instrucciones por la terminal que deberemos seguir. Una salida típica sería:

```(gnwmanager) [edu@thinkpad ~]$ gnwmanager unlock

If interrupted, resume unlocking with: gnwmanager unlock --backup-dir=backups-2025-10-27-19-28-14

Detected ZELDA game and watch.Backing up itcm to "backups-2025-10-27-19-28-14/itcm_backup_zelda.bin"... complete!Backing up external flash to "backups-2025-10-27-19-28-14/flash_backup_zelda.bin"... complete!Flashing payload to external flash... complete!

Payload successfully flashed. Perform the following steps:

Fully remove power, then re-apply power.
Press the power button to turn on the device; the screen should turn blue.

Press the "enter" key when the screen is blue: Backing up internal flash to "backups-2025-10-27-19-28-14/internal_flash_backup_zelda.bin"... complete!Unlocking device... complete!Restoring firmware... complete!Unlocking complete!Pressing the power button should launch the original firmware.```

Aparecerán los ficheros internal_flash_backup_zelda.bin, flash_backup_zelda.bin y itcm_backup_zelda.bin en un directorio backups-FECHA-HORA que conviene guardar.

Si encendemos en este momento la consola, no notaremos ningún cambio, es decir ejecutará el firmware original, pero ahora el chip estará desprotegido y podremos flashearle otro firmware.

Modificación 1: retro-go¶

Sustitución de la flash¶

En este momento toca empezar a modificar la consola seriamente. Como se comentaba al principio, el chip de almacenamiento externo del microcontrolador es una memoria flash de solo 4MB (modelo Zelda). No solo es pequeño para poder cargar muchos juegos, sino que tiene pocos ciclos de escritura, por lo que sustituir los juegos frecuentemente, o cachearlos cuando se hace la modificación para añadir la microSD, puede desgastarlo rápidamente. La modificación habitual es desoldar el chip flash de 4MB original y sustituirlo por otro de 64MB, concretamente el modelo MX25U51245GZ4I00.

Para retirar el chip flash original, es muy recomendable extraer la placa de la consola, desconectando las dos fajas de datos de la pantalla, desoldando el altavoz y retirando todos los tornillos. Una vez que tengamos la placa sobre la mesa de trabajo, protegemos con cinta kapton los alrededores del chip y lo extraemos aplicando flux y aire caliente con una pistola.

A continuación limpiamos con malla desoldadora la huella del chip que acabamos de retirar. También, aunque hay que hacerlo con sumo cuidado, ayuda rascar (con la punta de las pinzas por ejemplo) la máscara de soldadura de la PCB para ampliar hacia el exterior la superficie soldable de la huella de soldadura del chip.

El nuevo chip flash tiene formato QFN-8 de soldadura superficial que no resulta sencillo de soldar. Es recomendable aplicar flux y preestañar los pads de dicho chip por la parte inferior. También recomiendo poner una tira de cinta kapton en la parte inferior de manera que este no quede directamente apoyado sobre la PCB, lo que dificultaría el flujo de estaño por los pads.

Hay que fijarse bien en el punto que lleva el chip en su encapsulado que marca el pin número 1 que se corresponde con el que tiene un triángulo indicador en la PCB como se puede ver en la segunda foto de las siguientes.

Flasheo retro-go¶

Una vez instalado el chip, es hora de flashear el firmware. Para esta modificación, me decanto por no hacer dual boot, es decir no instalar el firmware original parcheado junto a retro-go, para así tener todo el espacio de la memoria flash dedicado a los juegos. Para ello empezamos bajando el repositorio del mismo:

bashcd ~/gitgit clone --recursive https://github.com/sylverb/game-and-watch-retro-go -b filesystem_wipcd game-and-watch-retro-go

Una vez bajado el código, toca instalar las ROMs en los directorios correspondientes a las distintas máquinas soportadas que encontraremos en ~/git/game-and-watch-retro-go/roms/. Por ejemplo, para instalar las ROMs de NES, copiamos las ROMs a ~/git/game-and-watch-retro-go/roms/nes/. Si queremos portadillas para los juegos, situaremos en los mismos directorios y con los mismos nombres de fichero de las ROMs correspondientes, las imágenes en formato jpg o png. Por ejemplo, para la ROM zelda.nes, situaremos la portada en ~/git/game-and-watch-retro-go/roms/nes/zelda.jpg.

Tenemos que tener en cuenta que todas las ROMs y sus portadillas tienen que caber en el chip flash de 64 MB que hemos instalado a la consola. La mayoría de las ROMs se comprimen, por lo que como regla de partida, utilizaremos el criterio de elegir ROMs por un tamaño total de aproximadamente el doble (128MB).

Ahora toca compilar el firmware (si no vamos a utilizar portadillas para aprovechar el espacio de sus ficheros para poder poner más ROMs, no incluir las variables de entorno COVERFLOW y JPG_QUALITY en los comandos de compilación y flasheo):

```bashmake docker_buildmake docker

(docker) gnwmanager install openocd(docker) export GNW_TARGET=zelda(docker) export ADAPTER=cmsis-dap(docker) make clean(docker) COVERFLOW=1 JPG_QUALITY=90 EXTFLASH_SIZE_MB=64 make -j$(nproc)```

Al terminar la compilación se nos informará del tamaño resultante del binario que se flasheará en el chip. Por ejemplo:

External flash usage Capacity: 61050880 Bytes ( 58.223 MB) Usage: 54335345 Bytes ( 51.818 MB) Free: 6715535 Bytes ( 6.404 MB)

Con esa información a la vista podremos iterar el proceso añadiendo o retirando ROMs hasta obtener un binario de unos 55MB, ya que hay que prever algo para los savestates de los juegos.

Una vez que estemos satisfechos con la ocupación del espacio, flashearemos el firmware volviendo a conectar la sonda de programación que comentamos en el apartado Sonda de programación.

bash(docker) COVERFLOW=1 JPG_QUALITY=90 EXTFLASH_SIZE_MB=64 make flash

Una salida típica sería:

bashdocker@53335bdd9199:/opt/workdir$ COVERFLOW=1 JPG_QUALITY=90 EXTFLASH_SIZE_MB=64 make flash_gnwmanagerEntering 'LCD-Game-Emulator'Entering 'blueMSX-go'Entering 'caprice32-go'Entering 'fceumm-go'Entering 'gwenesis'Entering 'potator'Entering 'prosystem-go'Entering 'retro-go-stm32'Entering 'smw'Entering 'tamalib'Entering 'zelda3'[ BASH ] Checking for updated roms100%|█████████████████████████████████████████████████████████████████| 208/208 [04:20<00:00, 1.25s/it]

Es importante que guardemos el fichero build/gw_retro_go.elf porque lo necesitaremos para extraer los savestates en el futuro.

Respaldar savestates retro-go¶

Si más adelante queremos extraer los savestates de los juegos, para poder volverlos a instalar tras flashear un nuevo firmware, en primer lugar necesitaremos depositar en el directorio build el fichero gw_retro_go.elf que obtuvimos en el paso anterior. Después podremos arrancar de nuevo el entorno docker y ejecutar el script de backup:

```bashcd ~/git/game-and-watch-retro-gomake docker

(docker) export GNW_TARGET=zelda(docker) export ADAPTER=cmsis-dap(docker) ./scripts/saves_backup.sh build/gw_retro_go.elf```

Los savestates aparecerán en el subdirectorio ~/git/game-and-watch-retro-go/save_states. Una vez que hayamos compilado y flasheado un nuevo firmware, podremos restaurarlos ejecutando el script de restauración:

bash(docker) ./scripts/saves_restore.sh

La restauración se hace de forma inteligente, es decir, si tenemos savestates de un juego que no está en el nuevo firmware, dicho savestate no se instalará en la consola, para evitar desperdiciar espacio de la memoria flash.

Modificación 2: retro-go-sd¶

Instalación módulo slot microSD¶

Al igual que con la modificación para el retro-go normal, para utilizar retro-go-sd hay que empezar haciendo una modificación hardware a la consola. Esta vez es más complicada, sobre todo la fase final de soldadura del módulo directamente sobre las patitas del microcontrolador, que tienen un paso muy pequeño.

El módulo se compone del propio lector de tarjetas microSD y 4 componentes. Todo ello soldado sobre una PCB tipo flex. La lista de componentes completa es:

1 lector de tarjetas microSD
1 resistencia 100kΩ 0603 o 0805
2 condensadores de 1μF 0603 o 0805
1 regulador de tensión RT9193-28GB. Hay personas que han reportado problemas con este modelo comprado en Aliexpress y recomiendan como reemplazo el "MIC5504-2.8YM5-TR".
1 PCB flex: Aquí se utiliza la versión de PrimoAngelo. La original que suele referenciarse en la mayoría de las guías es la de Tim Schuerewegen / hundshamer.

Empezaremos soldando los componentes sobre el PCB flex.

Lo siguiente como decíamos al principio será el difícil paso de instalar el módulo en la consola. Retiramos los cuatro tornillos que caen en su superficie y lo presentamos de forma que consigamos que los pads de la flex se encuentren alineados con las patitas del microcontrolador a la vez que estos quedan a sus pies, es decir de esta forma.

Una vez que se encuentre alineado a nuestro gusto, procederemos a fijarlo en su posición atornillando los cuatro tornillos. Ahora será cuando tendremos que armarnos de paciencia y flux de buena calidad para lograr hacer las soldaduras de los pads del flex y evitar a la vez los puentes entre las mismas. Será necesario comprobar continuidad de las soldaduras así como la no existencia de puentes entre las patitas adyacentes. Si finalmente lo conseguimos, solo resta añadir un punto de soldadura entre el pad marcado con +4V y el terminal del condensador que queda a su lado.

Flasheo bootloader¶

Lo siguiente será flashear el bootloader junto al firmware original parcheado de la consola para permitir el dual boot (esta vez sí merece la pena al contar con espacio prácticamente ilimitado para ROMs en la microSD). Desde el directorio donde estén los ficheros de backup de la consola y con un entorno Python que tenga instalado gnwmanager, ejecutaremos el siguiente comando:

bash(gnwmanager) $ gnwmanager flash-patch zelda internal_flash_backup_zelda.bin flash_backup_zelda.bin --bootloader

Una salida típica sería:

bash(gnwmanager) $ gnwmanager flash-patch zelda internal_flash_backup_zelda.bin flash_backup_zelda.bin --bootloader100%|███████████████████████████████████████████████████████████████████| 16/16 [00:58<00:00, 3.66s/it]

Si encendemos en ese momento la consola, tras haber retirado la sonda de programación, veremos que arranca el firmware original (parcheado). Tras pulsar GAME + LEFT se ejecutará el bootloader y, como en ese momento Retro-Go SD todavía no estará instalado en la flash interna del STM32, se nos muestrará el siguiente aviso:

Instalación de Retro-Go SD¶

Solo nos restará instalar el firmware de Retro-Go SD. Para ello, copiaremos el fichero retro-go_update.bin que descargaremos de la última release publicada por Sylverb en el repositorio de Retro-Go SD al directorio raíz de la microSD. Al arrancar por primera vez, veremos en pantalla cómo se copian los ficheros de retro-go y los cores de los emuladores a la misma microSD.

A la vez se creará en la microSD la estructura de directorios siguiente:

retro-go/├── CONFIG├── bios/│ ├── coleco/│ ├── msx/│ ├── nes/├── cores/│ ├── mappers/│ ├── a2600.bin│ ├── a2600_defprops.bin│ ├── a7800.bin│ └── ...├── data/│ ├── a2600/│ ├── a7800/│ ├── amstrad/│ └── ...├── fonts/│ ├── cp1251_greybeard.bin│ ├── cp1251_sans_serif.bin│ ├── cp1251_sans_serif_bold.bin│ └── ...└── roms/ ├── a2600/ ├── a7800/ ├── amstrad/ └── ...

Sólo restará copiar las ROMs que queramos emular en los directorios correspondientes. Si queremos portadillas para los juegos, tendremos que crear el subdirectorio covers con los mismos subdirectorios del directorio roms y colocar allí las imágenes. Estas tienen que estar en un formato especial IMG que generaremos con un script que se incluye en el repositorio de Retro-Go SD. Los nombres de los archivos IMG tendrán que coincidir con los de las ROMs en su correspondiente directorio.

Carcasa trasera¶

Al colocar el slot microSD hay que modificar la tapa trasera de la consola puesto que el lector cae sobre unos postes de apoyo de la cruceta. También hay que perforar el lateral para dejar paso a la microSD para poder extraerla e insertarla cuando queramos cambiar los juegos, rescatar savestates o actualizar el firmware. Para realizar la perforación existen unos utillajes diseñados por el usuario facelesstech que ayudan mucho a que la ranura quede limpia. En el vídeo que hay al final de este artículo, puede verse cómo se realiza esta modificación.

Existe una alternativa si no queremos arriesgarnos a estropear definitivamente la tapa original, y es imprimir en 3D el modelo creado por el usuario Aradia y que puede descargarse de aquí.

El color verde que he encontrado más parecido al de la consola Zelda es el 15-Verde de OVERTURE.

Controles¶

Indicamos a continuación las combinaciones de teclas de manejo de Retro-go SD (aunque muchas de ellas funcionan también en Retro-go). Manteniendo pulsado el botón PAUSE/SET mientras se presionan otros botones se realizan las siguientes acciones:

Combinación de teclas	Acción
`PAUSE/SET` + `GAME`	Guardar una captura de pantalla (deshabilitado por defecto en builds con flash de 1MB)
`PAUSE/SET` + `TIME`	Cambiar velocidad de ejecución (1x/1.5x)
`PAUSE/SET` + `UP`	Aumentar brillo
`PAUSE/SET` + `DOWN`	Disminuir brillo
`PAUSE/SET` + `RIGHT`	Aumentar volumen
`PAUSE/SET` + `LEFT`	Disminuir volumen
`PAUSE/SET` + `B`	Cargar state
`PAUSE/SET` + `A`	Guardar state
`PAUSE/SET` + `A`	Autodisparo en botón A
`PAUSE/SET` + `B`	Autodisparo en botón B
`PAUSE/SET` + `POWER`	Apagar sin guardar savestate
`PAUSE/SET` + `POWER`	Después de haber hecho `PAUSE/SET` y seleccionar `Power off`, arrancará el bootloader sin llegar a llamar a Retro-go, lo que nos permitirá ver la versión del bootloader así como información sobre la detección de la microSD y el estado de las memorias flash interna y externa

Referencias¶

No quiero terminar sin hacer mención al servidor de Discord de stacksmashing y a los siguientes usuarios cuyo trabajo ha hecho posible estas modificaciones:

stacksmashing
kbeckmann
Tim Schuerewegen
BrianPugh
GMMan
tfmoe__
Sylver Bruneau
facelesstech
DasBoss
bxhxx
Benjamin Solberg
orzeus
ducalex
ZimM
Ninoh-FOX
PrimoAngelo
Aradia

En el siguiente video de Macho Nacho se puede ver el todo el proceso de modificación de la consola (el flex del módulo microSD es el modelo que no se sujeta con los tornillos sino con puntos de soldadura sobre la PCB de la G&W):

G&W Zelda hack

Sun, 08 Mar 2026 15:45:00 +0100

A well-known Japanese video game manufacturer began selling a pair of machines at the end of 2022, replicating the appearance of some of the old G&W, based on an STM32H7 microcontroller running a baremetal firmware with NES and GB emulators, three classic games and a clock application inspired by the Zelda franchise. The machine is very interesting because of the virtues of being based on a microcontroller instead of a microprocessor, that is, great battery life (the one from a Switch joycon), instant boot and sleep mode. The storage medium is a small 4MB NOR flash chip (in the case of the Zelda model), enough to host the mentioned emulators and games, but very scarce if you want to take advantage of the machine and its relatively powerful CPU.

The original firmware serves to verify the solvency of the platform to emulate at least the 8-bit machines that originally run, so the device immediately became attractive to the hacker community. Shortly after it went on sale, procedures appeared to unlock and modify the machine so that more emulators and games could be installed.

The first major modification proposed by the community consisted of replacing the flash chip with a 64MB one to have more space for games and emulators. Later, the modification evolved to include a microSD card slot to store games and savestates, as well as to greatly simplify the update process, turning the modified machine into an unparalleled portable emulation machine in aspects such as portability, size, battery life, and boot times.

With either of the two modifications, it is possible to emulate the following machines:

Amstrad CPC6128 (beta)
Atari 2600
Atari 7800
ColecoVision
Gameboy / Gameboy Color
Game & Watch / LCD Games
MSX1/2/2+
Nintendo Entertainment System
PC Engine / TurboGrafx-16
Pokémon Mini
Sega Game Gear
Sega Genesis / Megadrive
Sega Master System
Sega SG-1000
Tamagotchi P1
Watara Supervision

In this article we will describe the steps to perform these two modifications. The modification to add the microSD slot also requires replacing the flash, since every time we load a new game from the microSD it will be written to the flash chip, and the original 4MB one supports few write cycles since it was not intended to be used this way.

The entire process has been performed on a Linux system. In principle, development on Windows and MacOS X systems is also possible, but the steps to install the requirements and the software we will use will necessarily change.

Connection to the SWD port¶

Unlocking the processor and modifying the firmware are done through the SWD port that STM32 microcontrollers usually have to program their internal flash memory and debug developments. This SWD port is located on the PCB unpopulated, that is, without soldered pins or connectors.

To make the connection to this port there are several options:

Solder wires directly.
Insert bare wires or male pin wires, tilting them to force contact.
Use specialized connection probe clips.
Use pogo pin clips (Single row 5pin).
Route the SWDIO and SWCLK pins to the USB-C port.

Hard version¶

Since I started tinkering with the machine before the microSD mod appeared, at the time I routed the SWD port to the USB-C. If you end up doing the microSD mod, the effort is not very worthwhile, since from then on flashing the firmware will be done from the microSD itself. However, for documentation purposes we will describe how the routing would be done.

The USB-C port only has the power pins connected since it is only intended to charge the machine. Therefore, the D+ and D- pins that are free can be used to wire them to the SWDIO and SWCLK pins, which are the only essential ones for the SWD port. We will also need to connect to 5V and GND, but these are already wired in the USB-C port. The routing is done with fine enameled wire like the one used to build coils. Soldering to the two central pins of the USB-C port which correspond to D+ and D- is complicated having a very small pitch, but with patience and flux it can be achieved.

Once the only difficult part of the procedure is solved, that is, soldering the wires to the USB port, these are secured every so often with Kapton tape and directed towards the battery area where the recess on both sides of the housing that surrounds it is used to pass one of the cables. The other is routed through the space between the battery housing and the PCB. This way both cables cannot touch each other, although in theory being varnished there should be no problem, this separate path is adopted as an additional precaution.

Once the wires reach the vicinity of the SWD port, the two test pads that can be seen in the photo are used to solder them.

The correspondence between D+ and D- on the USB-C port with SWDIO and SWCLK of the SWD port can be done in any way as long as we are clear on where each one is to later make the USB-SWD adapter we will need. In this assembly the following correspondence has been chosen:

D+ ↔ SWDIO
D- ↔ SWCLK

Warning

The idea at first was to adopt the correspondence used in this other guide, but due to a mistake made at the beginning, it ended up being done exactly the other way around. As mentioned earlier, it's really not a problem as long as you know how the connections are made. This warning is only in case someone tries to follow both guides simultaneously, so that this difference is taken into account.

Once the port is routed, we will need to build the adapter to extract the SWDIO and SWCLK signals from the USB-C port. To do this, cut a conventional USB-A cable to have access to the four separate cables it contains and solder female pin connectors to them. The adapter is completed with a USB-A to USB-C adapter that is marked to orient it correctly when we are going to use it, since we have only routed the D+ and D- pins on one of the two sides (the USB-C port is reversible).

The cable colors are usually standardized as follows:

Red: 5V
Black: GND
Green: D+
White: D-

Easy version¶

The recommended way to make the connection to the SWD port (if you don't want to solder, which is the most reliable option) is using specialized connection probe clips. To apply these clips, it is recommended to previously disconnect the console's battery. The battery connector pops off easily by inserting a thin piece of plastic underneath it.

Programming probe¶

We have solved where to connect on the console. Now we need a device capable of communicating with that SWD port of the microcontroller. The options are:

I chose to use a Raspberry Pi Pico. For it to work as an SWD programming probe, the debugprobe firmware must be loaded. In my case I used the picoprobe.uf2 file from this specific release. To flash the Pico, just connect it to the computer via USB while pressing the BOOTSEL button to force the mode in which it mounts as a storage drive and drag the .uf2 file to that drive. After autoflashing, the Pico will automatically restart and begin to function as an SWD programming probe.

Once the Pico is programmed, the only thing left is to make the connections of the cables that we had connected to the SWD port of the Game&Watch. We can use the same type of clips that we applied to the console, although in my case I used similar ones but slightly more robust, since the spacing of the GPIO pins of the Pico is much larger.

The wiring between Game&Watch and Raspberry Pi Pico is:

Pico	GnW	Color
3	3	Black
4	5	White
5	2	Green

Microcontroller unlocking¶

Once the connectivity to the board is solved, the first step in the modification is unlocking the STM32H7 microcontroller so that we can replace the firmware in its internal flash memory as well as write to the external flash memory (with code that we will inject into the microcontroller itself).

This task is performed with the gnwmanager utility suite. This package is registered on PyPI so it can be installed very easily with pip (preferably inside a Python virtual environment).

bash$ pip install gnwmanager$ gnwmanager install openocd

Now, after reconnecting the console's battery if we had disconnected it, we will execute the following command:

(gnwmanager) $ gnwmanager unlock

The process will pause on a couple of occasions giving instructions through the terminal that we must follow. A typical output would be:

```(gnwmanager) [edu@thinkpad ~]$ gnwmanager unlock

If interrupted, resume unlocking with: gnwmanager unlock --backup-dir=backups-2025-10-27-19-28-14

Payload successfully flashed. Perform the following steps:

Fully remove power, then re-apply power.
Press the power button to turn on the device; the screen should turn blue.

The files internal_flash_backup_zelda.bin, flash_backup_zelda.bin and itcm_backup_zelda.bin will appear in a backups-DATE-TIME directory that should be saved.

If we turn on the console at this point, we won't notice any change, meaning it will run the original firmware, but now the chip will be unprotected and we can flash another firmware to it.

Modification 1: retro-go¶

Flash replacement¶

At this time we start modifying the console seriously. As mentioned at the beginning, the microcontroller's external storage chip is a flash memory of only 4MB (Zelda model). Not only is it small for loading many games, but it has few write cycles, so replacing games frequently, or caching them when making the modification to add the microSD, can wear it out quickly. The usual modification is to desolder the original 4MB flash chip and replace it with a 64MB one, specifically the MX25U51245GZ4I00 model.

To remove the original flash chip, it is highly recommended to extract the console's motherboard, disconnecting the two data ribbon cables from the screen, desoldering the speaker, and removing all screws. Once we have the board on the workbench, we protect the surroundings of the chip with kapton tape and extract it by applying flux and hot air with a heat gun.

Next, we clean the footprint of the chip we just removed with desoldering braid. Also, although it must be done with great care, it helps to scratch (with the tip of tweezers, for example) the solder mask of the PCB to expand outwards the solderable surface of the chip's solder footprint.

The new flash chip has a surface mount QFN-8 format that is not easy to solder. It is recommended to apply flux and pre-tin the pads of said chip on the bottom. I also recommend putting a strip of kapton tape on the bottom so that it does not rest directly on the PCB, which would hinder the flow of solder through the pads.

You must pay close attention to the dot on the chip's package that marks pin number 1, which corresponds to the one with an indicator triangle on the PCB as can be seen in the second photo of the following.

Flashing retro-go¶

Once the chip is installed, it's time to flash the firmware. For this modification, I choose not to set up dual boot, that is, not to install the patched original firmware alongside retro-go, to have all the flash memory space dedicated to games. To do this we start by downloading its repository:

bashcd ~/gitgit clone --recursive https://github.com/sylverb/game-and-watch-retro-go -b filesystem_wipcd game-and-watch-retro-go

Once the code is downloaded, it's time to install the ROMs in the directories corresponding to the different supported machines that we will find in ~/git/game-and-watch-retro-go/roms/. For example, to install the NES ROMs, we copy the ROMs to ~/git/game-and-watch-retro-go/roms/nes/. If we want cover art for the games, we will place the images in jpg or png format in the same directories and with the same file names of the corresponding ROMs. For example, for the zelda.nes ROM, we will place the cover at ~/git/game-and-watch-retro-go/roms/nes/zelda.jpg.

We have to keep in mind that all ROMs and their covers must fit in the 64 MB flash chip we installed in the console. Most ROMs compress, so as a starting rule, we will use the criteria of choosing ROMs for a total size of roughly double (128MB).

Now it's time to build the firmware (if we are not going to use covers to take advantage of the space of their files to be able to put more ROMs, do not include the COVERFLOW and JPG_QUALITY environment variables in the build and flash commands):

```bashmake docker_buildmake docker

(docker) gnwmanager install openocd(docker) export GNW_TARGET=zelda(docker) export ADAPTER=cmsis-dap(docker) make clean(docker) COVERFLOW=1 JPG_QUALITY=90 EXTFLASH_SIZE_MB=64 make -j$(nproc)```

When building finishes, we will be informed of the resulting binary size that will be flashed to the chip. For example:

External flash usage Capacity: 61050880 Bytes ( 58.223 MB) Usage: 54335345 Bytes ( 51.818 MB) Free: 6715535 Bytes ( 6.404 MB)

With that information in sight we can iterate the process adding or removing ROMs until obtaining a binary of about 55MB, since something must be anticipated for the game savestates.

Once we are satisfied with the space usage, we will flash the firmware reconnecting the programming probe discussed in the Programming probe section.

bash(docker) COVERFLOW=1 JPG_QUALITY=90 EXTFLASH_SIZE_MB=64 make flash

A typical output would be:

It is important that we keep the build/gw_retro_go.elf file because we will need it to extract the savestates in the future.

Backup retro-go savestates¶

If later we want to extract the game savestates, to be able to reinstall them after flashing a new firmware, first we will need to place the gw_retro_go.elf file we obtained in the previous step in the build directory. Then we can restart the docker environment and run the backup script:

```bashcd ~/git/game-and-watch-retro-gomake docker

(docker) export GNW_TARGET=zelda(docker) export ADAPTER=cmsis-dap(docker) ./scripts/saves_backup.sh build/gw_retro_go.elf```

The savestates will appear in the ~/git/game-and-watch-retro-go/save_states subdirectory. Once we have built and flashed a new firmware, we can restore them by running the restoration script:

bash(docker) ./scripts/saves_restore.sh

Restoration is done intelligently, that is, if we have savestates of a game that is not in the new firmware, that savestate will not be installed on the console, to avoid wasting flash memory space.

Modification 2: retro-go-sd¶

microSD slot module installation¶

As with the modification for normal retro-go, to use retro-go-sd you must start by making a hardware modification to the console. This time it is more complicated, especially the final phase of soldering the module directly onto the microcontroller's pins, which have a very small pitch.

The module consists of the microSD card reader itself and 4 components. All this soldered onto a flex-type PCB. The complete list of components is:

1 microSD card reader
1 100kΩ 0603 resistor or 0805
2 1μF 0603 capacitors or 0805
1 RT9193-28GB voltage regulator. There are people who have reported problems with this model bought on Aliexpress and recommend the "MIC5504-2.8YM5-TR" as a replacement.
1 flex PCB: Here the version by PrimoAngelo is used. The original one usually referenced in most guides is the one by Tim Schuerewegen / hundshamer.

We will begin by soldering the components onto the flex PCB.

The next step as we said at the beginning will be the difficult step of installing the module in the console. We remove the four screws that fall on its surface and present it in a way that we get the pads of the flex to align with the pins of the microcontroller while these end up at their feet, that is, like this.

Once it is aligned to our liking, we will proceed to fix it in its position by driving in the four screws. Now is when we will have to arm ourselves with patience and high-quality flux to manage to solder the pads of the flex and simultaneously avoid bridges between them. It will be necessary to check the continuity of the solders as well as the non-existence of bridges between adjacent pins. If we finally succeed, all that remains is to add a solder point between the pad marked with +4V and the capacitor terminal next to it.

Bootloader flashing¶

The next step will be to flash the bootloader along with the console's patched original firmware to allow dual boot (this time it is worthwhile as we have practically unlimited space for ROMs on the microSD). From the directory where the console backup files are located and with a Python environment that has gnwmanager installed, we will execute the following command:

bash(gnwmanager) $ gnwmanager flash-patch zelda internal_flash_backup_zelda.bin flash_backup_zelda.bin --bootloader

A typical output would be:

If we turn on the console at that moment, after removing the programming probe, we will see that the (patched) original firmware starts. After pressing GAME + LEFT, the bootloader will execute and, as Retro-Go SD is not yet installed in the internal flash of the STM32 at that moment, we will be shown the following warning:

Retro-Go SD installation¶

All that remains is to install the Retro-Go SD firmware. To do this, we will copy the retro-go_update.bin file that we will download from the latest release published by Sylverb in the Retro-Go SD repository to the root directory of the microSD. When booting for the first time, we will see on screen how the retro-go files and emulator cores are copied to the microSD itself.

At the same time, the following directory structure will be created on the microSD:

All that remains is to copy the ROMs we want to emulate to the corresponding directories. If we want cover art for the games, we will need to create the covers subdirectory with the same subdirectories as the roms directory and place the images there. These must be in a special IMG format that we will generate with a script included in the Retro-Go SD repository. The IMG file names must match those of the ROMs in their corresponding directory.

Back case¶

When installing the microSD slot, you need to modify the back cover of the console because the reader falls over some support posts on the d-pad. You also need to drill a hole in the side to allow access to the microSD so you can extract and insert it when you want to change games, rescue savestates, or update the firmware. To perform the drilling, there are some tools designed by the user facelesstech that help keep the slot clean. You can see how this modification is performed in the video at the end of this article.

There is an alternative if we don't want to risk permanently damaging the original cover, and that is to 3D print the model created by the user Aradia, which can be downloaded here.

The green color I found most similar to the Zelda console is the 15-Green from OVERTURE.

Controls¶

Below we indicate the key combinations for controlling Retro-go SD (although many of them also work in Retro-go). Holding down the PAUSE/SET button while pressing other buttons performs the following actions:

Key combination	Action
`PAUSE/SET` + `GAME`	Save a screenshot (disabled by default in builds with 1MB flash)
`PAUSE/SET` + `TIME`	Change execution speed (1x/1.5x)
`PAUSE/SET` + `UP`	Increase brightness
`PAUSE/SET` + `DOWN`	Decrease brightness
`PAUSE/SET` + `RIGHT`	Increase volume
`PAUSE/SET` + `LEFT`	Decrease volume
`PAUSE/SET` + `B`	Load state
`PAUSE/SET` + `A`	Save state
`PAUSE/SET` + `A`	Autofire on button A
`PAUSE/SET` + `B`	Autofire on button B
`PAUSE/SET` + `POWER`	Poweroff without savestate
`PAUSE/SET` + `POWER`	After having done `PAUSE/SET` and selected `Power off`, the bootloader will start without calling Retro-go, allowing us to see the bootloader version as well as information about the microSD detection and the state of the internal and external flash memories

References¶

I would not like to finish without mentioning the stacksmashing Discord server and the following users whose work has made these modifications possible:

stacksmashing
kbeckmann
Tim Schuerewegen
BrianPugh
GMMan
tfmoe__
Sylver Bruneau
facelesstech
DasBoss
bxhxx
Benjamin Solberg
orzeus
ducalex
ZimM
Ninoh-FOX
PrimoAngelo
Aradia

In the following Macho Nacho video you can see the whole console modification process (the flex of the microSD module is the model that is not held by screws but with solder points on the G&W PCB):

Instalación Arch Linux en Lenovo ThinkPad T480

Sat, 28 Jun 2025 22:30:00 +0200

Tras cruzarme por casualidad con varios vídeos contando las excelencias del Lenovo ThinkPad T480 y de estar ligeramente disgustado con el portátil que adquirí el verano pasado como equipo principal, decidí comprar uno de segunda mano. En concreto el modelo que compré es el T480 con un procesador Intel Core i5-8250U, 16GB de RAM y disco SSD de 1TB. Costó 252€ puesto en casa al día siguiente, y fue adquirido en un vendendor especializado en reacondicionar equipos del que también vi algún vídeo por lo que esperaba que el equipo estuviera en buen estado. Así fue. El equipo llegó con un aspecto impecable, como nuevo, con sus dos baterías funcionales (la interna y la externa). El ThinkPad T480, en su momento tenía muchas opciones de configuración a la hora de adquirirlo. Por este motivo, al comprarlo en una de estas empresas de reacondicionamiento, es posible que el equipo tenga características distintas. Esta es la hoja de especificaciones del equipo donde pueden verse todas las opciones de hardware: PSREF Lenovo ThinkPad T480.

El Lenovo ThinkPad T480 es un portátil de 14" con un teclado excelente, una pantalla IPS FullHD (1920x1080) y una buena conectividad (2 puertos USB-C uno de ellos Thunderbolt, 2 puertos USB-A 3.0, HDMI, Ethernet, lector de tarjetas SD y jack de auriculares/micrófono). Internamente es muy modificable, ya que tiene la RAM en dos sockets SODIMM, el disco SSD en un socket SATA que se puede convertir en M.2, un par de puertos PCIe donde se puede conectar más almacenamiento intento SSD o cosas como un modem 5G y la batería interna es también sustituible fácilmente. Además, la compatibilidad con Linux está asegurada, ya que Lenovo proporciona drivers para Linux y la comunidad ha desarrollado drivers para el resto de componentes.

Lo que sigue es el procedimiento completo que he utilizado para instalar Arch Linux en él.

Reparticionado del disco¶

El equipo trae Windows 11 Pro instalado ocupando todo el disco. El plan es mantenerlo y hacer sitio para instalar Arch Linux junto a él. El tamaño de 1TB del disco SSD del equipo es perfecto para poder alojar dos sistemas operativos sin problemas.

El primer paso es encoger la partición de Windows. Para poder hacerlo, BitLocker debe estar desactivado. En la instalación de Windows 11 que trae el equipo, BitLocker estaba ya desactivado. La partición la podemos encoger con el propio Windows en marcha, desde el Administrador de discos (buscándolo en el menú Inicio o pulsando Win+X). Una vez en el Administrador de discos, pulsamos con el botón derecho del ratón sobre la partición C: y seleccionamos la opción Reducir volumen.... En mi caso, reduje el volumen en 750GB, quedando la partición de Windows con un tamaño de unos 220GB.

En las instalaciones de Windows, hay una patición pequeña al final del disco que es la partición de recuperación. Al encoger la partición principal, el espacio libre queda antes de esta partición y por tanto, al crear las particiones para Linux más adelante, éstas tendrán un número superior a la partición de recuperación, pero se encontrarán antes. Esto en sistemas de archivos GPT no es un problema.

Instalación base¶

Para el proceso de instalación del sistema base me decanté por el camino convencional siguiendo las instrucciones de la guía de instalación en el wiki de Arch. Dicha instalación utiliza una ISO de un sistema Arch que podremos arrancar desde una unidad extraíble USB con el que instalaremos los paquetes mínimos para tener un sistema arrancable y muy básico.

Antes de comenzar, comentar que por las características tan dinámicas de la distribución Arch Linux, es muy posible que esta guía quede desactualizada en algún momento. Por lo que recomiendo consultar la guía oficial en caso de encontrar que algo no sale como se supone.

A continuación vemos paso a paso el proceso de instalación:

Descargar la ISO de Arch Linux. En concreto en mi caso utilicé ésta versión.
Instalar la ISO en un pendrive. Puede utilizarse un programa como Balena Etcher o el comando dd de Linux si se sabe manejar (donde /dev/sdX es el dispositivo del pendrive; puede comprobarse con el comando lsblk):
bashsudo dd bs=4M if=archlinux-2025.06.01-x86_64.iso of=/dev/sdX conv=fsync oflag=direct status=progress
Arrancar el portátil con el pendrive insertado. Pulsar Enter cuando ofrece interrumpir el proceso normal de arranque y acto seguido F12. Esto hace que el ordenador arranque en el Boot Menu.
Seleccionar la opción para arrancar desde el dispositivo extraíble que aparecerá en el menú como USB HDD: Mass Storage Device.
Una vez que termine de arrancar el sistema live de instalación de Arch, ejecutar los siguiente comandos en orden. En caso de conectar a la red por cable Ethernet, se puede evitar la sesión con iwctl (en la cual sustituiremos <SSID> por nuestro SSID e introduciremos la contraseña cuando se nos pida):
```bash
loadkeys es¶
iwctl¶
[iwd]# station wlan0 scan[iwd]# station wlan0 get-networks[iwd]# station wlan0 connect [iwd]# exit
timedatectl¶
fdisk /dev/sda¶
```
En el programa fdisk crear las siguientes particiones (en mi caso):
- sda5: 8GB, tipo Linux swap, con el identificador 19.
- sda6: Espacio restante (724,4GB), tipo Linux filesystem, con el identificador 20.
Salir de fdisk escribiendo w y pulsando Enter. Continuar con los siguientes comandos (sustituir <USER> por el nombre de usuario que se quiera crear):
```
mkfs.ext4 /dev/sda6¶
mkswap /dev/sda5¶
mount /dev/sda6 /mnt¶
mount --mkdir /dev/sda1 /mnt/boot/efi¶
swapon /dev/sda5¶
pacstrap -K /mnt base base-devel linux linux-firmware sudo vi ntfs-3g networkmanager intel-ucode grub efibootmgr os-prober¶
genfstab -U /mnt >> /mnt/etc/fstab¶
arch-chroot /mnt¶
ln -sf /usr/share/zoneinfo/Europe/Madrid /etc/localtime¶
hwclock --systohc¶
vi /etc/locale.gen # Descomentar 'en_US.UTF-8 UTF-8' y 'es_ES.UTF-8 UTF-8'¶
locale-gen¶
echo "LANG=es_ES.UTF-8" > /etc/locale.conf¶
echo "KEYMAP=es" > /etc/vconsole.conf¶
echo "thinkpad" > /etc/hostname¶
echo -e "\n127.0.0.1 localhost\n::1 localhost\n127.0.1.1 thinkpad.localdomain thinkpad" >> /etc/hosts¶
passwd¶
useradd -m -G wheel,audio,video,storage -s /bin/bash ¶
passwd ¶
visudo # Descomentar '%wheel ALL=(ALL) ALL'¶
systemctl enable NetworkManager¶
vi /etc/default/grub # Descomentar 'GRUB_DISABLE_OS_PROBER=false'¶
os-prober¶
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB¶
grub-mkconfig -o /boot/grub/grub.cfg¶
su - ¶
```

Instalación entorno gráfico¶

Continuamos donde nos habíamos quedado, es decir en la sesión chroot desde el sistema live de instalación de Arch Linux. Lo haremos ya con el usuario normal (no root) por lo que a partir de ahora haremos uso con frecuencia de sudo.

Ahora vamos a instalar el entorno gráfico, en mi caso XFCE4. En caso de elegir otro, aquí hay una lista de entornos gráficos soportados oficialmente por Arch Linux y las instrucciones correspondientes.
bash$ sudo pacman -Syy$ sudo pacman -S xfce4 xfce4-goodies xorg xdg-user-dirs pavucontrol gvfs gvfs-smb thunar-archive-plugin unzip unrar lightdm lightdm-gtk-greeter lightdm-gtk-greeter-settings pipewire pipewire-pulse pipewire-alsa wireplumber git cmake$ sudo systemctl enable lightdm
Instalar el gestor de paquetes yay para poder instalar paquetes desde AUR:
bash$ git clone https://aur.archlinux.org/yay.git$ cd yay$ makepkg -si
Por último instalar algunos programas y paquetes que nos serán útiles:
bash$ sudo pacman -S firefox firefox-i18n-es libreoffice-fresh gimp vlc vlc-plugins-all usbutils htop btop openssh man-pages-es xdg-user-dirs-gtk alsa-utils network-manager-applet blueman fwupd gparted terminator vlc gimp shutter audacity openshot ghex net-tools sshuttle gucharmap$ sudo systemctl enable --now sshd
Cerramos la sesión chroot, desmontamos las particiones y reiniciamos el sistema:
```bash$ exit
exit¶
umount -R /mnt¶
reboot¶
```

Applet NetworkManager y Bluetooth¶

Para que el applet de NetworkManager funcione correctamente, debemos instalar el paquete network-manager-applet y añadirlo al autostart de XFCE4. Vamos a hacer algo parecido con el Bluetooth. Para ello, una vez iniciado el entorno gráfico, ejecutar:

bash$ sudo pacman -S network-manager-applet blueman$ sudo systemctl start bluetooth$ sudo systemctl enable --now bluetooth

Ahora debemos añadir los applets al autostart de XFCE4. Para ello, ir a Configuración > Sesión y arranque > Aplicaciones de inicio y pulsar en Añadir. En el campo Nombre escribir NetworkManager Applet, en Comando escribir nm-applet y en Comentario podemos dejarlo vacío o poner algo como Applet de NetworkManager. Hacemos lo mismo para el Bluetooth, añadiendo un nuevo applet con el nombre Bluetooth, el comando blueman-applet y un comentario opcional.

Instalación pamac¶

Para facilitar la instalación de paquetes desde la interfaz gráfica, vamos a instalar pamac:

bash$ yay -S pamac-aur

Una vez instalado, abrirlo (buscando Añadir/Quitar software en el cajón de aplicaciones) y activar el soporte AUR en Preferencias > Terceros > Activar soporte de AUR.

Conclusión¶

Y esto sería todo. Ahora tenemos un sistema dualboot Arch Linux / Windows en el ThinkPad T480.

Enlaces de interés¶

Guía de instalación de Arch Linux
Instalación y configuración de Arch Linux en un portátil Lenovo ThinPad T480
Hoja de especificaciones del Lenovo ThinPad T480
Actualización de firmwares con fwupd
Howdy for Linux: Howdy proporciona autenticación estilo Windows Hello™ para Linux. Usa los emisores IR y la cámara integrados junto con reconocimiento facial para verificar tu identidad.
Install Libreboot on Lenovo ThinkPad T480 and/or T480s
Problema en el firmware Thunderbolt:
- Critical Intel Thunderbolt Software and Firmware Updates - ThinkPad
- Sustitución EPROM

Arch Linux Installation on Lenovo ThinkPad T480

Sat, 28 Jun 2025 22:30:00 +0200

After stumbling upon several videos praising the Lenovo ThinkPad T480 and feeling slightly dissatisfied with the laptop I bought last summer as my main device, I decided to buy a second-hand one. Specifically, I bought the T480 model with an Intel Core i5-8250U processor, 16GB RAM, and a 1TB SSD. It cost €252 delivered the next day, and I purchased it from a specialized refurbisher whose videos I had also seen, so I expected the machine to be in good condition. And it was. The laptop arrived in impeccable condition, like new, with both its batteries functional (internal and external). The ThinkPad T480 originally had many configuration options available. For this reason, when buying it from a refurbisher, it may come with different hardware features. Here is the full spec sheet where all hardware options can be seen: PSREF Lenovo ThinkPad T480.

The Lenovo ThinkPad T480 is a 14" laptop with an excellent keyboard, an IPS FullHD screen (1920x1080), and good connectivity (2 USB-C ports, one of them Thunderbolt, 2 USB-A 3.0 ports, HDMI, Ethernet, SD card reader, and audio/mic jack). Internally it's very customizable, as it has two SODIMM RAM slots, an SSD in a SATA slot that can be converted to M.2, a couple of PCIe ports for additional SSD storage or a 5G modem, and the internal battery is also easily replaceable. Moreover, Linux compatibility is excellent, as Lenovo provides Linux drivers and the community has developed drivers for the rest of the components.

What follows is the full procedure I used to install Arch Linux on it.

Disk repartitioning¶

The laptop comes with Windows 11 Pro installed occupying the entire disk. The plan is to keep it and make room to install Arch Linux alongside. The 1TB SSD is perfect to accommodate two operating systems without issues.

The first step is to shrink the Windows partition. To do so, BitLocker must be disabled. In the Windows 11 installation that came with the machine, BitLocker was already disabled. We can shrink the partition using Windows itself, through the Disk Management tool (search in Start menu or press Win+X). Once there, right-click the C: partition and select Shrink Volume.... In my case, I shrank it by 750GB, leaving around 220GB for Windows.

Windows installations have a small recovery partition at the end of the disk. When shrinking the main partition, the free space appears before this recovery partition. Thus, when creating Linux partitions later, their numbering will be higher than the recovery partition but will physically be located before it. This is not a problem when using GPT partitioning schemes.

Base installation¶

For the base system installation, I chose the conventional route following the installation guide from the Arch wiki. This installation uses an ISO of an Arch live system that we boot from a removable USB drive and use to install the minimal packages for a bootable, very basic system.

Before we begin, it's worth noting that due to the dynamic nature of Arch Linux, this guide may become outdated. I recommend checking the official guide if something doesn't go as expected.

Here is the step-by-step installation process:

Download the Arch Linux ISO. I used this version.
Flash the ISO to a USB stick using Balena Etcher or the dd command in Linux (if you know how to use it):
bashsudo dd bs=4M if=archlinux-2025.06.01-x86_64.iso of=/dev/sdX conv=fsync oflag=direct status=progress
Boot the laptop with the USB stick inserted. Press Enter when prompted to interrupt normal boot, then press F12 to enter the Boot Menu.
Select the option to boot from the removable device, listed as USB HDD: Mass Storage Device.
Once the Arch live system boots, run the following commands in order. If using a wired Ethernet connection, you can skip the iwctl session (replace <SSID> with your network name and enter the password when prompted):
```bash
loadkeys es¶
iwctl¶
[iwd]# station wlan0 scan[iwd]# station wlan0 get-networks[iwd]# station wlan0 connect [iwd]# exit
timedatectl¶
fdisk /dev/sda¶
```
In fdisk, create the following partitions:
- sda5: 8GB, type Linux swap, ID 19.
- sda6: Remaining space (724.4GB), type Linux filesystem, ID 20.
Exit fdisk by typing w and pressing Enter. Continue with the following commands (replace <USER> with your desired username):
```
mkfs.ext4 /dev/sda6¶
mkswap /dev/sda5¶
mount /dev/sda6 /mnt¶
mount --mkdir /dev/sda1 /mnt/boot/efi¶
swapon /dev/sda5¶
pacstrap -K /mnt base base-devel linux linux-firmware sudo vi ntfs-3g networkmanager intel-ucode grub efibootmgr os-prober¶
genfstab -U /mnt >> /mnt/etc/fstab¶
arch-chroot /mnt¶
ln -sf /usr/share/zoneinfo/Europe/Madrid /etc/localtime¶
hwclock --systohc¶
vi /etc/locale.gen # Uncomment 'en_US.UTF-8 UTF-8' and 'es_ES.UTF-8 UTF-8'¶
locale-gen¶
echo "LANG=es_ES.UTF-8" > /etc/locale.conf¶
echo "KEYMAP=es" > /etc/vconsole.conf¶
echo "thinkpad" > /etc/hostname¶
echo -e "\n127.0.0.1 localhost\n::1 localhost\n127.0.1.1 thinkpad.localdomain thinkpad" >> /etc/hosts¶
passwd¶
useradd -m -G wheel,audio,video,storage -s /bin/bash ¶
passwd ¶
visudo # Uncomment '%wheel ALL=(ALL) ALL'¶
systemctl enable NetworkManager¶
vi /etc/default/grub # Uncomment 'GRUB_DISABLE_OS_PROBER=false'¶
os-prober¶
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB¶
grub-mkconfig -o /boot/grub/grub.cfg¶
su - ¶
```

Graphical environment installation¶

We continue from where we left off, that is, in the chroot session from the Arch Linux live installer. From now on we'll use a regular user (not root), so we'll often use sudo.

Now install the graphical environment — I chose XFCE4. If you prefer another one, here is a list of officially supported desktop environments and instructions.
bash$ sudo pacman -Syy$ sudo pacman -S xfce4 xfce4-goodies xorg xdg-user-dirs pavucontrol gvfs gvfs-smb thunar-archive-plugin unzip unrar lightdm lightdm-gtk-greeter lightdm-gtk-greeter-settings pipewire pipewire-pulse pipewire-alsa wireplumber git cmake$ sudo systemctl enable lightdm
Install the yay package manager to install packages from AUR:
bash$ git clone https://aur.archlinux.org/yay.git$ cd yay$ makepkg -si
Finally, install some useful applications and packages:
bash$ sudo pacman -S firefox firefox-i18n-es libreoffice-fresh gimp vlc vlc-plugins-all usbutils htop btop openssh man-pages-es xdg-user-dirs-gtk alsa-utils network-manager-applet blueman fwupd gparted terminator vlc gimp shutter audacity openshot ghex net-tools sshuttle gucharmap$ sudo systemctl enable --now sshd
Exit the chroot session, unmount the partitions, and reboot:
```bash$ exit
exit¶
umount -R /mnt¶
reboot¶
```

NetworkManager and Bluetooth Applets¶

To make the NetworkManager applet work properly, we need to install the network-manager-applet package and add it to XFCE4 autostart. We’ll do something similar for Bluetooth. Once in the graphical environment, run:

bash$ sudo pacman -S network-manager-applet blueman$ sudo systemctl start bluetooth$ sudo systemctl enable --now bluetooth

Now add both applets to XFCE4 autostart. Go to Settings > Session and Startup > Application Autostart and click Add. In Name, enter NetworkManager Applet, in Command, enter nm-applet, and you can leave Comment empty or write something like NetworkManager applet. Do the same for Bluetooth: name Bluetooth, command blueman-applet, optional comment.

Installing pamac¶

To make graphical package management easier, install pamac:

bash$ yay -S pamac-aur

Once installed, open it (search for Add/Remove Software in the application menu) and enable AUR support under Preferences > Third Party > Enable AUR support.

Conclusion¶

And that’s it. Now we have a dual boot Arch Linux / Windows system on the ThinkPad T480.

Links of interest¶

Arch Linux Installation Guide
Installation and configuration of Arch Linux on a Lenovo T480 laptop
Lenovo ThinkPad T480 Specification Sheet
Firmware updates with fwupd
Howdy for Linux: Howdy provides Windows Hello™ style authentication for Linux. Use your built-in IR emitters and camera in combination with facial recognition to prove who you are.
Install Libreboot on Lenovo ThinkPad T480 and/or T480s
Thunderbolt firmware problem:
- Critical Intel Thunderbolt Software and Firmware Updates - ThinkPad
- EPROM replacement

ZX Mechtrum

Mon, 09 Sep 2024 12:00:00 +0200

Hace tiempo que me apetecía montar un kit de ZX Spectrum Harlequin 128. Es el Spectrum perfecto (128KB, soporte de todos los modelos/ROMs de las distintas versiones producidas por Sinclair y Amstrad, y con componentes que se pueden adquirir a día de hoy, incluida la ULA que está reemplazada por lógica discreta). Pero para la caja, la opción de adquirir una de las carcasas réplica del 48K original (gomas), no me entusiasmaba.

Hace unos meses conocí el proyecto ZX Mechtrum de Lee Smith, una caja para placas de formato 48KB con un teclado mecánico, y me pareció el complemento perfecto para el Harlequin. De hecho, en el vídeo del canal More Fun Making It gracias al que supe de su existencia, su creador comenta que tiene el proyecto inmediato de instalar un Harlequin 128 en una de estas cajas.

Como ya existen varios vídeos y guías tanto del kit Harlequin como de la caja ZX Mechtrum, no voy a detallar el proceso de montaje, pero sí describirlo en general y comentar algunas particularidades y problemas que he encontrado.

Mechtrum¶

Como el kit Harlequin 128 es distribuido por Byte Delight, por lo que su disponibilidad es bastante estable, el punto más crítico del plan era adquirir el Mechtrum de Lee Smith, ya que la venta de productos no es su principal actividad. De hecho pude conseguir la última unidad de una tirada que hizo a finales de 2023. En el momento de escribir esto (septiembre 2024) vuelve a estar a la venta, pero no es de esperar que se mantenga siempre así. El caso es que pude adquirir una unidad que llegó ya montada. Mi unidad venía con 3 faceplates, una para el 48K, otra para el Sifzif 512 y otra para el Harlequin 128.

Harlequin 128¶

El Harlequin 128, es un diseño de Don Superfo y puede adquirirse la PCB a través de los enlaces que hay en el repositorio base del proyecto. En el repositorio se encuentra también la BOM (Bill Of Materials) para las distintas versiones con todos los componentes necesarios. Pero con diferencia la opción más sencilla es adquirir uno de los kits que distribuye Ben Versteeg, de Byte Delight. El kit viene con una PCB de la versión issue 2D y todos los componentes necesarios para montarlo, convenientemente clasificados en bolsitas junto a un manual con el que es casi imposible perderse. También hay épocas en las que no está disponible en su tienda, pero es cuestión de estar atento o suscribirse a las notificaciones de disponibilidad. En mi caso tuve que esperar un par de meses a que volviera a estar disponible.

El único problema que tuve durante su montaje fue que según el manual el array de resistencias R61 es opcional si no se va a instalar la interfaz de joystick. Pero esas resistencias, además de dar servicio al puerto de joystick, hacen de pullup para los microinterruptores de selección del banco de ROM, por lo que sin instalarlas, la selección de bancos de ROM superiores al 0 no era estable. Tras instalar el array R61, todo funcionó correctamente.

Resultado¶

El resultado es un sueño hecho realidad, un Spectrum 128K con teclado mecánico y componentes fiables. Además de una belleza. 🤩

ZX Mechtrum

Mon, 09 Sep 2024 12:00:00 +0200

For a while, I’ve wanted to assemble a ZX Spectrum Harlequin 128 kit. It’s the perfect Spectrum (128KB, supports all models/ROMs from the various versions produced by Sinclair and Amstrad, and with components that can still be acquired today, including the ULA, which has been replaced by discrete logic). However, the option of purchasing a replica case of the original 48K (rubber keys) didn’t really excite me.

A few months ago, I came across Lee Smith’s ZX Mechtrum project, a case for 48KB-format boards with a mechanical keyboard, and it seemed like the perfect complement for the Harlequin. In fact, in the video from the More Fun Making It channel, through which I learned of its existence, its creator mentions that he plans to install a Harlequin 128 in one of these cases soon.

Since there are already several videos and guides for both the Harlequin kit and the ZX Mechtrum case, I won’t detail the assembly process but will instead describe it generally and mention some peculiarities and problems I encountered.

Mechtrum¶

Since the Harlequin 128 kit is distributed by Byte Delight, its availability is quite stable, so the most critical point of the plan was acquiring the Mechtrum from Lee Smith, as selling products is not his main activity. In fact, I managed to get the last unit from a batch he made in late 2023. As of writing this (September 2024), it’s back on sale, but it’s not expected to remain available for long. In any case, I was able to acquire a unit that arrived pre-assembled. My unit came with 3 faceplates, one for the 48K, another for the Sifzif 512, and one for the Harlequin 128.

Harlequin 128¶

The Harlequin 128 is a design by Don Superfo, and the PCB can be purchased through the links provided in the project’s base repository. The repository also contains the BOM (Bill Of Materials) for the different versions with all the necessary components. However, by far the easiest option is to purchase one of the kits distributed by Ben Versteeg from Byte Delight. The kit comes with an issue 2D version PCB and all the necessary components to assemble it, conveniently sorted into bags along with a manual that makes it almost impossible to get lost. There are times when it’s not available in his store, but it’s just a matter of staying alert or subscribing to availability notifications. In my case, I had to wait a couple of months for it to become available again.

The only problem I encountered during assembly was that, according to the manual, the R61 resistor array is optional if you’re not going to install the joystick interface. However, these resistors, in addition to serving the joystick port, also act as pullups for the ROM bank selection microswitches, so without them, selecting ROM banks higher than 0 was unstable. After installing the R61 array, everything worked correctly.

Resultado¶

The result is a dream come true: a 128K Spectrum with a mechanical keyboard and reliable components. And it’s a beauty. 🤩

Instalación Arch Linux en Steam Deck

Wed, 04 Sep 2024 15:30:00 +0200

Pérdida de dual boot al actualizar SteamOS

En la actualización de SteamOS a la rama 3.6 (en concreto la primera versión estable de esa rama fue la 3.6.19) se perdió la configuración del dualboot por lo que la máquina sólo arrancaba en SteamOS. La solución fue volver a seguir los pasos de Instalación gestor dualboot a partir del paso 4.

En julio de 2024 durante unas semanas, el modelo de 512GB de la Steam Deck LCD pudo adquirirse por debajo de los 400€. Un precio muy atractivo para una máquina decente con procesador AMD de arquitectura x86 (AMD64), 16GB de RAM, disco SSD tipo NVMe de la capacidad mencionada antes, pantalla táctil y controles de juego integrados. Es decir un PC consolizado, pero un PC al fin y al cabo. Pero sobre todo lo que hace para mi especialmente atractiva la máquina es su soporte Linux completo, lo que la convierte en una plataforma ideal para cacharrear con distribuciones Linux o utilizarlo como PC portátil secundario. Todo esto naturalmente además de su uso convencional para jugar y emular videojuegos.

SteamOS, el sistema operativo que trae de serie, está basado en Arch Linux, y en su modo escritorio, puede utilizarse prácticamente como un Arch Linux normal. La principal restricción es que está construido en modo inmutable y a pesar de que este tipo de configuración de sistema tiene sus virtudes y se entiende perfectamente que Valve lo haya escogido para su máquina, todavía prefiero un sistema normal (mutable), por lo que me decidí por instalar un Arch normal y aprender a instalar de paso esta distribución. Según el wiki de Arch, el hardware del modelo LCD de la Steam Deck está soportado al 100% en Arch.

Lo que sigue es el procedimiento completo que he utilizado.

Teclado/ratón¶

Aunque gran parte de las operaciones pueden hacerse utilizando la pantalla táctil y los trackpads de la Steam Deck, es muy recomendable conectar un teclado y ratón a la consola para facilitar la instalación, sobre todo durante la sesión de terminal con la que instalaremos el sistema base. La Steam Deck sólo posee un puerto USB-C, por lo que lo más práctico es utilizar un dock. También puede ser suficiente (sobre todo si ejecutamos los sistemas live desde una microSD) con un dongle de teclado/ratón inalámbricos conectados con un adaptador USB<->USB-C, aunque en ese caso conviene asegurarse de que la Steam Deck tiene la batería completamente cargada.

En mi caso utilicé un dock DA310z de Dell.

Reparticionado del disco¶

El disco SSD de la Steam Deck que adquirí es de 512GB y de tipo NVMe. Es el tamaño mínimo si queremos instalar otro sistema junto a SteamOS.

Antes de empezar con la instalación debemos hacer hueco para la misma encogiendo la partición principal (la número 8). Para ello podemos utilizar prácticamente cualquier distribución live Linux que arranquemos desde una unidad extraíble (USB o microSD) ya que todas ellas llevan algún programa para gestionar particiones. En mi caso utilicé una ISO del programa gparted.

El procedimiento completo puede verse a continuación:

Descargar la ISO de gparted. En concreto en mi caso utilicé ésta versión.
Instalar la ISO en un pendrive o mejor aún en una microSD (ya que la Steam Deck posee una ranura para éstas). Puede utilizarse un programa como Balena Etcher o el comando dd de Linux si se sabe manejar.
Arrancar la Steam Deck con el pendrive o la microSD insertada manteniendo pulsado el botón de bajar el volumen hasta que se escuchen los tonos de encendido. Esto hace que la consola arranque en el menú Boot Manager.
Seleccionar la opción de arrancar desde el dispositivo extraíble que aparecerá en el menú como EFI USB Device (USB) o EFI SD/MMC Card (XX XXXX XXXX) según si utilizamos un pendrive o una microSD respectivamente.
Aparece una pantalla de configuración en la que hacemos las siguientes selecciones:
- Policy for handling keymaps => Don't touch keymap
- Which language do you prefer? => 25
- Which mode do you prefer? => 0
Tras aceptar la última opción anterior, arrancará el programa gparted en modo gráfico (con la pantalla girada, eso sí). Haremos cambios hasta dejar las particiones como se ve en la foto. Básicamente lo que haremos será encoger la partición #8 unos 100GB, crear la #9 de 4GB para swap y la #10 con el espacio restante para el sistema raíz de Arch:

Destacar a la vista de las particiones que utiliza SteamOS que hace uso de un sistema de particiones A/B, habitual en Android, por el cual la mayoría de las particiones del sistema (excepto la de usuario) están duplicadas. Dicho sistema está pensado para facilitar las actualizaciones, o más bien para volver atrás en caso de problemas durante las mismas.

Instalación base¶

Para el proceso de instalación del sistema base me decanté por el camino convencional siguiendo las instrucciones de la guía de instalación en el wiki de Arch. Dicha instalación utiliza una ISO de un sistema Arch que podremos arrancar desde una unidad extraíble (USB o microSD) con el que instalaremos los paquetes básicos para tener un sistema arrancable y muy básico.

Antes de comenzar, comentar que por las características tan dinámicas de la distribución Arch Linux, es muy posible que esta guía quede desactualizada en poco tiempo. Por lo que recomiendo consultar la guía oficial en caso de encontrar que algo no sale como se supone.

A continuación vemos paso a paso el proceso de instalación:

Descargar la ISO de Arch Linux. En concreto en mi caso utilicé ésta versión.
Instalar la ISO en un pendrive o mejor aún en una microSD para utilizar la ranura que posee la Steam Deck. Puede utilizarse un programa como Balena Etcher o el comando dd de Linux si se sabe manejar.
Arrancar la Steam Deck con el pendrive o la microSD insertada manteniendo pulsado el botón de bajar el volumen hasta que se escuchen los tonos de encendido. Esto hace que la consola arranque en el menú Boot Manager.
Seleccionar la opción de arrancar desde el dispositivo extraíble que aparecerá en el menú como EFI USB Device (USB) o EFI SD/MMC Card (XX XXXX XXXX) según si utilizamos un pendrive o una microSD respectivamente.
Una vez que termine de arrancar el sistema live de instalación de Arch, ejecutar los siguiente comandos en orden (en la sesión con iwctl sustituiremos <SSID> por el nuestro e introduciremos la contraseña cuando se nos pida; también sustituiremos el identificador de usuario <USER> por el que queramos utilizar):
```bash
loadkeys es¶
iwctl¶
[iwd]# station wlan0 scan[iwd]# station wlan0 get-networks[iwd]# station wlan0 connect [iwd]# exit
mkfs.ext4 /dev/nvme0n1p10¶
mkswap /dev/nvme0n1p9¶
mount /dev/nvme0n1p10 /mnt¶
mount --mkdir /dev/nvme0n1p1 /mnt/boot/efi¶
swapon /dev/nvme0n1p9¶
pacstrap -K /mnt base base-devel linux linux-firmware sudo vi ntfs-3g networkmanager amd-ucode grub efibootmgr git cmake qt5-wayland¶
genfstab -U /mnt >> /mnt/etc/fstab¶
arch-chroot /mnt¶
ln -sf /usr/share/zoneinfo/Europe/Madrid /etc/localtime¶
hwclock --systohc¶
vi /etc/locale.gen # descomentar 'en_US.UTF-8 UTF-8' y 'es_ES.UTF-8 UTF-8'¶
locale-gen¶
echo "LANG=es_ES.UTF-8" > /etc/locale.conf¶
echo "KEYMAP=es" > /etc/vconsole.conf¶
echo "deck" > /etc/hostname¶
echo -e "\n127.0.0.1 localhost\n::1 localhost\n127.0.1.1 deck" >> /etc/hosts¶
passwd¶
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Arch¶
grub-mkconfig -o /boot/grub/grub.cfg¶
systemctl enable NetworkManager¶
useradd -m -G wheel,audio,video,storage ¶
passwd ¶
chmod u+w /etc/sudoers¶
vi /etc/sudoers # Descomentar '%wheel ALL=(ALL) ALL'¶
chmod u-w /etc/sudoers¶
pacman -Syy¶
pacman -S xorg-server xf86-video-amdgpu maliit-keyboard qt5-wayland¶
su - ¶
```

El password que elegiremos cuando ejecutemos el comando passwd <USER> debe ser numérico si queremos utilizar Plasma Mobile, ya que la pantalla de desbloqueo sólo nos permite introducir un PIN.

Instalación entorno gráfico¶

Ahora vamos a instalar los entornos gráficos. Lo digo en plural porque vamos a instalar dos, Plasma y Plasma Mobile. Hago esto porque dependiendo de si vamos a utilizar la Steam Deck con Arch en modo escritorio (con teclado/ratón y posiblemente pantalla) o portátil (sin teclado/ratón), nos convendrá más un sistema u otro, dado que Plasma Mobile presenta un interfaz diseñado para ser manejado con una pantalla táctil (estilo tablet).

En realidad no es necesario instalar los dos escritorios, por eso se han separado sus pasos de instalación. Podemos instalar uno, el otro o ambos.

Plasma¶

bash$ sudo pacman -S plasma-meta

Durante la instalación del paquete anterior se nos harán una serie de preguntas. A la tercera pregunta responder 2) noto-fonts. En el resto ofrecer la respuesta predeterminada (pulsando retorno).

Plasma Mobile¶

Plasma Mobile no se encuentra todavía en los repositorios oficiales. Tenemos que utilizar AUR:

Empezamos instalando algunas dependencias:
bash$ sudo pacman -S plasma-workspace kcontacts kirigami2 kpeople libphonenumber
Instalamos los paquetes de AUR plasma-nano, plasma-settings y plasma-mobile en este orden:
bash$ cd ~$ git clone https://aur.archlinux.org/plasma-nano.git$ cd plasma-nano$ makepkg -si$ cd ~$ git clone https://aur.archlinux.org/plasma-settings.git$ cd plasma-settings$ makepkg -si$ cd ~$ git clone https://aur.archlinux.org/plasma-mobile.git$ cd plasma-mobile$ makepkg -si

Fin de instalación entorno gráfico¶

Instalamos el gestor de sesiones SDDM y algunas aplicaciones que nos harán falta para terminar la instalación desde el modo gráfico:
bash$ sudo pacman -S sddm konsole dolphin kwrite partitionmanager power-profiles-daemon$ sudo systemctl enable sddm$ exit
Cerramos la sesión chroot, desmontamos las particiones y reiniciamos el sistema:
```bash
exit¶
umount -R /mnt¶
reboot¶
```

Configuración básica¶

Tras reiniciar deberíamos ver el gestor de sesiones SDDM, inicialmente con la pantalla girada y sin posibilidad de utilizar el teclado en pantalla, por lo que todavía continuaremos utilizando el teclado y ratón externos.

Una vez que hayamos iniciado sesión en Plasma o Plasma Mobile, lo primero que tenemos que hacer es configurar la conexión a internet. Para ello hacemos click sobre el icono correspondiente en la bandeja del sistema abajo a la derecha en Plasma o arriba a la derecha en Plasma Mobile.

Una vez que tengamos conexión, abrimos la aplicación Konsole y ejecutamos los siguientes comandos para instalar el paquete de aplicaciones básico de KDE, el navegador Firefox y el servidor SSH:

bash$ sudo pacman -S firefox kde-applications-meta openssh usbutils lshw man-db htop spectacle$ sudo systemctl start sshd$ sudo systemctl enable sshd

Finalmente hacemos las siguientes configuraciones:

Preferencias > Preferencias del sistema > Entrada y salida > Pantalla y monitor > Escalar: Configurar la escala de la pantalla a 110%.
Preferencias > Preferencias del sistema > Entrada y salida > Teclado > Distribuciones > Configurar distribuciones > Añadir: Añadir la distribución de teclado español.
Preferencias > Preferencias del sistema > Entrada y salida > Teclado > Teclado virtual: Seleccionar Maliit.
Preferencias > Preferencias del sistema > Idioma y hora > Fecha y hora > Zona horaria: Seleccionar Madrid.
Preferencias > Preferencias del sistema > Aspecto y estilo > Texto y tipos de letra > Tipos de letra. Ajustar estos valores:
- General: Noto Sans 11pt
- Anchura fija: Hack 10pt
- Pequeña: Noto Sans 9pt
- Barra de herramientas: Noto Sans 11pt
- Menú: Noto Sans 11pt
- Título de la ventana: Noto Sans 10pt
Botón derecho (L2) sobre la barra de tareas y seleccionar Mostrar configuración del panel. En Preferencias del panel > Altura del panel subir la altura a 54px.
Botón derecho (L2) sobre el icono que sirve para mostrar los iconos ocultos en la bandeja del sistema y seleccionar Configurar Bandeja del sistema. En General seleccionar estos valores:
- Tamaño de los iconos del panel: Escalar a la altura del panel
- Espacio entre los iconos del panel: Normal
Botón derecho (L2) sobre el icono que sirve para mostrar los iconos ocultos en la bandeja del sistema y seleccionar Mostrar configuración del panel. Veremos un minireloj que antes no se veía sobre el que pulsaremos con el botón derecho (L2). Seleccionamos Mostrar alternativas y de los elementos gráficos alternativos que aparecen escogemos Reloj digital.

Configuración de SDDM¶

Finalmente vamos a mejorar la configuración del gestor de sesiones SDDM para que permita el teclado en pantalla, tenga mejor aspecto y muestre la pantalla en la orientación correcta:

Crear fichero /etc/sddm.conf.d/10-wayland.conf con el siguiente contenido:
```ini[General]DisplayServer=waylandGreeterEnvironment=QT_WAYLAND_SHELL_INTEGRATION=layer-shell
[Wayland]CompositorCommand=kwin_wayland --drm --no-lockscreen --no-global-shortcuts --locale1 --inputmethod maliit-keyboard```
Abrir Preferencias > Pantalla de inicio de sesión (SDDM), seleccionar Brisa como theme y pulsar el botón Aplicar las preferencias de Plasma... arriba a la derecha.

Configuración sonido¶

Tal y como comenta el wiki de Arch, el volumen por defecto en la Steam Deck es muy bajo. Para solucionarlo hay que instalar el paquete alsa-utils y ejecutar el comando alsamixer para ajustar el volumen de algunos de los canales.

bash$ sudo pacman -S alsa-utils$ alsamixer

Para acceder a los mismos, una vez en alsamixer, hay que pulsar F6 para poder seleccionar el dispositivo de audio acp5x ya que por defecto aparecen seleccionado el dispositivo 0 que es el asociado a la salida HDMI del chip gráfico:

Una vez seleccionado el dispositivo correcto, veremos todos sus canales que son muy numerosos. Localizaremos los que menciona el wiki para ajustarlos a los siguientes valores:

Canal	Valor
Analog PCM	85%
Digital	86%
Digital PCM	85%
Left Analog PCM	85%
Left Digital PCM	85%
Right Analog PCM	85%
Right Digital PCM	85%

Instalación pamac¶

Para facilitar la instalación de paquetes desde la interfaz gráfica, vamos a instalar pamac:

bash$ yay -S pamac-aur

Una vez instalado lo abrimos (buscando Añadir/Quitar software en el cajón de aplicaciones) y activamos el soporte AUR en Preferencias > Terceros > Activar soporte de AUR.

Instalación gestor dualboot¶

El sistema Arch ya está listo y podemos arrancarlo encendiendo la consola en modo Boot Manager (manteniendo pulsada la tecla de bajar volumen) y seleccionando la opción Arch. Pero para facilitar el arranque de SteamOS, vamos a instalar un gestor de arranque dualboot llamado rEFInd.

Arrancar SteamOS (con Volume- + Power).
Desde una terminal en modo escritorio ejecutar:
bashcd $HOME && rm -rf $HOME/SteamDeck_rEFInd/ && git clone https://github.com/jlobue10/SteamDeck_rEFInd && cd SteamDeck_rEFInd && chmod +x install-GUI.sh && ./install-GUI.sh
Descargar o crear un icono de Arch Linux de 128x128px.
Abrir el lanzador del escritorio que encontraremos en el escritorio.
Configurar de la siguiente forma (seleccionar en el campo Boot Option #2 Icon el icono descargado o creado anteriormente):
Pulsar botón Create Config.
Editar el fichero que encontraremos en ~/.local/SteamDeck_rEFInd/GUI/refind.conf y modificar la última entrada de la siguiente forma:
confmenuentry "Arch" { icon /EFI/refind/os_icon2.png loader /EFI/Arch/grubx64.efi graphics on}
Pulsar el botón Install rEFInd.
Pulsar el botón Install Config

La ruta /EFI/Arch/grubx64.efi del paso 6 puede cambiar si en el comando grub-install ejecutado durante la instalación del sistema base se eligió otro identificador que no fuera Arch. En ese caso habría que adaptar la ruta.

Conclusión¶

Y esto sería todo. Ahora tenemos un sistema Arch Linux en nuestra Steam Deck con un gestor de arranque dualboot que nos permite arrancar también SteamOS. A partir de aquí tendremos una máquina con una naturaleza doble, una (SteamOS) para jugar y otra (Arch) para ser utilizada como un PC (Plasma) o tabletPC (Plasma Mobile).

Para elegir el entorno gráfico Plasma normal o el Plasma Mobile, utilizaremos el menú desplegable que aparece abajo a la izquierda en el gestor de inicios de sesión SDDM.

Algunos enlaces de interés consultados durante la elaboración de esta guía:

Installing Arch Linux on Steam Deck

Wed, 04 Sep 2024 15:30:00 +0200

Loss of dual boot after updating SteamOS

In the update of SteamOS to the 3.6 branch (specifically, the first stable version of that branch was 3.6.19), the dual-boot configuration was lost, so the machine would only boot into SteamOS. The solution was to follow the steps in Dual Boot manager installation starting from step 4.

In July 2024, the 512GB LCD model of the Steam Deck was available for under €400 for a few weeks. This price was very appealing for a decent machine with an AMD processor based on x86 (AMD64) architecture, 16GB of RAM, an NVMe SSD of the mentioned capacity, a touchscreen, and integrated gaming controls. Essentially, it's a handheld PC, but still a PC. What makes this machine especially attractive to me is its full Linux support, making it an ideal platform for tinkering with Linux distributions or using it as a secondary portable PC. Of course, this is in addition to its conventional use for gaming and emulating video games.

SteamOS, the default operating system, is based on Arch Linux, and in desktop mode, it can be used almost like a regular Arch Linux system. The main restriction is that it's built in immutable mode. While this type of system configuration has its virtues and it's understandable why Valve chose it for their machine, I still prefer a normal (mutable) system. So, I decided to install a regular Arch Linux and learn how to install this distribution. According to the Arch wiki, the hardware of the Steam Deck LCD model is 100% supported by Arch.

The following is the complete procedure I used.

Keyboard/Mouse¶

Although most operations can be performed using the Steam Deck's touchscreen and trackpads, it's highly recommended to connect a keyboard and mouse to the console to facilitate the installation, especially during the terminal session where we'll install the base system. The Steam Deck only has one USB-C port, so the most practical solution is to use a dock. It may also suffice (especially if we run live systems from a microSD) to use a wireless keyboard/mouse dongle connected with a USB<->USB-C adapter, though in that case, it's advisable to ensure the Steam Deck is fully charged.

In my case, I used a Dell DA310z dock.

Disk repartitioning¶

The Steam Deck's SSD I purchased is 512GB and of the NVMe type. This is the minimum size if we want to install another system alongside SteamOS.

Before starting the installation, we need to make space by shrinking the main partition (number 8). For this, we can use almost any live Linux distribution that we boot from a removable drive (USB or microSD) since all of them come with some partition management program. I used a gparted ISO.

The complete procedure can be seen below:

Download the gparted ISO. Specifically, I used this version.
Install the ISO on a USB drive or, even better, on a microSD (since the Steam Deck has a slot for these). You can use a program like Balena Etcher or the dd command in Linux if you know how to use it.
Boot the Steam Deck with the USB drive or microSD inserted by holding down the volume- button until you hear the power-up tones. This causes the console to boot into the Boot Manager menu.
Select the option to boot from the removable device, which will appear in the menu as EFI USB Device (USB) or EFI SD/MMC Card (XX XXXX XXXX) depending on whether you used a USB drive or a microSD respectively.
A configuration screen appears where we make the following selections:
- Policy for handling keymaps => Don't touch keymap
- Which language do you prefer? => 25
- Which mode do you prefer? => 0
After accepting the last option, the gparted program will start in graphical mode (with the screen rotated, though). We will make changes until the partitions look like the screenshot. Essentially, we'll shrink partition #8 by about 100GB, create #9 with 4GB for swap, and #10 with the remaining space for the Arch root system:

Note, when looking at the partitions used by SteamOS, that it uses an A/B partition system, common in Android, where most of the system partitions (except the user space one) are duplicated. This system is designed to facilitate updates, or rather to roll back in case of problems during them.

Base installation¶

For the base system installation, I opted for the conventional method following the instructions in the installation guide on the Arch wiki. This installation uses an Arch system ISO that we can boot from a removable drive (USB or microSD) to install the basic packages needed for a bootable and very basic system.

Before starting, note that due to the dynamic nature of the Arch Linux distribution, it's very likely that this guide will become outdated soon. Therefore, I recommend checking the official guide if something doesn't go as expected.

Below is the step-by-step installation process:

Download the Arch Linux ISO. Specifically, I used this version.
Install the ISO on a USB drive or, even better, on a microSD to use the slot on the Steam Deck. You can use a program like Balena Etcher or the dd command in Linux if you know how to use it.
Boot the Steam Deck with the USB drive or microSD inserted by holding down the volume- button until you hear the power-up tones. This causes the console to boot into the Boot Manager menu.
Select the option to boot from the removable device, which will appear in the menu as EFI USB Device (USB) or EFI SD/MMC Card (XX XXXX XXXX) depending on whether you used a USB drive or a microSD respectively.
Once the Arch live installation system finishes booting, run the following commands in order (in the iwctl session, replace <SSID> with your own and enter the password when prompted; also replace the user identifier <USER> with the one you want to use):
```bash
loadkeys en¶
iwctl¶
[iwd]# station wlan0 scan[iwd]# station wlan0 get-networks[iwd]# station wlan0 connect [iwd]# exit
mkfs.ext4 /dev/nvme0n1p10¶
mkswap /dev/nvme0n1p9¶
mount /dev/nvme0n1p10 /mnt¶
mount --mkdir /dev/nvme0n1p1 /mnt/boot/efi¶
swapon /dev/nvme0n1p9¶
pacstrap -K /mnt base base-devel linux linux-firmware sudo vi ntfs-3g networkmanager amd-ucode grub efibootmgr git cmake qt5-wayland¶
genfstab -U /mnt >> /mnt/etc/fstab¶
arch-chroot /mnt¶
ln -sf /usr/share/zoneinfo/Europe/Madrid /etc/localtime¶
hwclock --systohc¶
vi /etc/locale.gen # uncomment 'en_US.UTF-8 UTF-8'¶
locale-gen¶
echo "LANG=en_US.UTF-8" > /etc/locale.conf¶
echo "KEYMAP=en" > /etc/vconsole.conf¶
echo "deck" > /etc/hostname¶
echo -e "\n127.0.0.1 localhost\n::1 localhost\n127.0.1.1 deck" >> /etc/hosts¶
passwd¶
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Arch¶
grub-mkconfig -o /boot/grub/grub.cfg¶
systemctl enable NetworkManager¶
useradd -m -G wheel,audio,video,storage ¶
passwd ¶
chmod u+w /etc/sudoers¶
vi /etc/sudoers # Uncomment '%wheel ALL=(ALL) ALL'¶
chmod u-w /etc/sudoers¶
pacman -Syy¶
pacman -S xorg-server xf86-video-amdgpu maliit-keyboard qt5-wayland¶
su - ¶
```

The password you choose when running the passwd <USER> command should be numeric if you want to use Plasma Mobile, as the unlock screen only allows you to enter a PIN.

Graphical environment installation¶

Continuing from where we left off, that is, in the chroot session from the Arch Linux live installation system. We will now do this as a normal user (not root), so from now on, we will frequently use sudo.

Now we are going to install the graphical environments. I say this in plural because we will install two: Plasma and Plasma Mobile. I do this because, depending on whether we will use the Steam Deck with Arch in desktop mode (with keyboard/mouse and possibly a screen) or portable mode (without keyboard/mouse), one system or the other will be more convenient, as Plasma Mobile has an interface designed to be operated with a touchscreen (tablet-style).

Really, it's not necessary to install both desktops, so their installation steps are separated. You can install one, the other, or both.

Plasma¶

bash$ sudo pacman -S plasma-meta

During the installation of the above package, you will be asked several questions. On the third question, answer 2) noto-fonts. For the rest, provide the default answer (by pressing enter).

Plasma Mobile¶

Plasma Mobile is not yet available in the official repositories. We have to use AUR:

Start by installing some dependencies:
bash$ sudo pacman -S plasma-workspace kcontacts kirigami2 kpeople libphonenumber
Install the AUR packages plasma-nano, plasma-settings, and plasma-mobile in this order:
bash$ cd ~$ git clone https://aur.archlinux.org/plasma-nano.git$ cd plasma-nano$ makepkg -si$ cd ~$ git clone https://aur.archlinux.org/plasma-settings.git$ cd plasma-settings$ makepkg -si$ cd ~$ git clone https://aur.archlinux.org/plasma-mobile.git$ cd plasma-mobile$ makepkg -si

End of graphical environment installation¶

Install the SDDM session manager and some applications, which we'll need to finish the installation from the graphical mode:
bash$ sudo pacman -S sddm konsole dolphin kwrite partitionmanager power-profiles-daemon$ sudo systemctl enable sddm$ exit
Close the chroot session, unmount the partitions, and reboot the system:
```bash
exit¶
umount -R /mnt¶
reboot¶
```

Basic configuration¶

After rebooting, you should see the SDDM session manager, initially with the screen rotated and without the ability to use the on-screen keyboard, so we'll still be using the external keyboard and mouse.

Once we have logged into Plasma or Plasma Mobile, the first thing we need to do is configure the internet connection. To do this, click on the corresponding icon in the system tray at the bottom right in Plasma or at the top right in Plasma Mobile.

Once connected, open the Konsole application and run the following commands to install the basic KDE application package, Firefox browser and the SSH server:

bash$ sudo pacman -S firefox kde-applications-meta openssh usbutils lshw man-db htop spectacle$ sudo systemctl start sshd$ sudo systemctl enable sshd

Finally, we make the following configurations:

Preferences > System Preferences > Input & Output > Display & Monitor > Scale: Set the screen scale to 110%.
Preferences > System Preferences > Input & Output > Keyboard > Layouts > Configure Layouts > Add: Add the English keyboard layout.
Preferences > System Preferences > Input & Output > Keyboard > Virtual Keyboard: Select Maliit.
Preferences > System Preferences > Language & Time > Date & Time > Time Zone: Select your city.
Preferences > System Preferences > Appearance & Style > Text & Fonts > Fonts. Set this values:
- General: Noto Sans 11pt
- Fixed width: Hack 10pt
- Small: Noto Sans 9pt
- Toolbar: Noto Sans 11pt
- Menu: Noto Sans 11pt
- Window title: Noto Sans 10pt
Right-click (L2) on the taskbar and select Show panel settings. In Panel Preferences > Panel Height increase the height to 54px.
Right-click (L2) on the icon used to show hidden icons in the system tray and select Configure System Tray. In General select these values:
- Panel icon size: Scale to panel height
- Spacing between panel icons: Normal
Right-click (L2) on the icon used to show hidden icons in the system tray and select Show panel settings. You will see a small clock that was not visible before, right-click (L2) on it. Select Show alternatives and from the alternative graphics that appear, choose Digital clock.

SDDM configuration¶

Finally, we'll improve the SDDM session manager configuration to enable the on-screen keyboard, enhance the appearance, and display the screen in the correct orientation:

Create the file /etc/sddm.conf.d/10-wayland.conf with the following content:
```ini[General]DisplayServer=waylandGreeterEnvironment=QT_WAYLAND_SHELL_INTEGRATION=layer-shell
[Wayland]CompositorCommand=kwin_wayland --drm --no-lockscreen --no-global-shortcuts --locale1 --inputmethod maliit-keyboard```
Open Preferences > Login Screen (SDDM), select Breeze as the theme, and click the Apply Plasma settings... button in the top right corner.

Sound configuration¶

As the Arch wiki mentions, the default volume on the Steam Deck is very low. To fix this, you need to install the alsa-utils package and run the alsamixer command to adjust the volume of some of the channels.

bash$ sudo pacman -S alsa-utils$ alsamixer

To access them, once in alsamixer, press F6 to select the acp5x audio device, as by default the selected device is 0, which is associated with the HDMI output of the graphics chip:

Once the correct device is selected, you will see all its channels, which are quite numerous. Locate the ones mentioned in the wiki and adjust them to the following values:

Channel	Value
Analog PCM	85%
Digital	86%
Digital PCM	85%
Left Analog PCM	85%
Left Digital PCM	85%
Right Analog PCM	85%
Right Digital PCM	85%

Pamac Installation¶

To facilitate package installation from the graphical interface, we are going to install pamac:

bash$ yay -S pamac-aur

Once installed, open it (by searching for Add/Remove Software in the application drawer) and enable AUR support in Preferences > Third Party > Enable AUR support.

Dual Boot manager installation¶

The Arch system is now ready and can be booted by starting the console in Boot Manager mode (holding down the volume- key) and selecting the Arch option. But to make it easier to boot SteamOS, we'll install a dual boot manager called rEFInd.

Boot SteamOS (with Volume- + Power).
From a terminal in desktop mode, run:
bashcd $HOME && rm -rf $HOME/SteamDeck_rEFInd/ && git clone https://github.com/jlobue10/SteamDeck_rEFInd && cd SteamDeck_rEFInd && chmod +x install-GUI.sh && ./install-GUI.sh
Download or create an Arch Linux icon of 128x128px.
Open the desktop launcher found on the desktop.
Configure it as follows (select the icon downloaded or created earlier in the Boot Option #2 Icon field):
Click the Create Config button.
Edit the file found at ~/.local/SteamDeck_rEFInd/GUI/refind.conf and modify the last entry as follows:
confmenuentry "Arch" { icon /EFI/refind/os_icon2.png loader /EFI/Arch/grubx64.efi graphics on}
Click the Install rEFInd button.
Click the Install Config button.

The path /EFI/Arch/grubx64.efi in step 6 may change if you chose a different identifier than Arch during the grub-install command executed during the base system installation. In that case, you'll need to adapt the path.

Conclusion¶

And that's it. Now we have an Arch Linux system on our Steam Deck with a dual boot manager that allows us to boot into SteamOS as well. From here, we have a machine with a dual nature, one (SteamOS) for gaming and another (Arch) to be used as a PC (Plasma) or tablet PC (Plasma Mobile).

To choose between the normal Plasma or Plasma Mobile graphical environment, use the dropdown menu that appears at the bottom left in the SDDM login manager.

Some interesting links consulted during the creation of this guide:

Vías Zaragoza - Campus en bicicleta

Fri, 31 May 2024 08:00:00 +0200

Foto de Javier Rodrigo

Ruta por margen derecha cortada

El camino que discurre por la margen derecha del Gállego (la ruta con nombre "Azud - Campus (por margen der. Gállego)" en la tabla final) está cortado por desprendimientos entre los waypoints 14 y 15, cuando se pasa junto a un muro que rodea un terreno muy próximo al propio río, al menos en fecha 2025-02-18. Una opción para evitar ese punto es salir momentáneamente a la carretera de Cogullada que discurre frente al lado opuesto del terreno con el muro.

Actualmente trabajo en el Campus de Aula Dei, a unos 15Km de Zaragoza. Aunque existen varias opciones para acudir al campus en autobús, en mi caso particular la combinación de rutas y horarios no es favorable, por lo que desde un principio opté por ir en bicicleta. Tras unos días realizando pruebas, ajusté la ruta y la equipación para hacerla más conveniente y segura. En este post enumero las distintas opciones que he terminado conociendo y describo a mi parecer sus ventajas e inconvenientes.

Problemas y soluciones¶

Hay que comentar desde un principio que desafortunadamente el acceso al campus en bicicleta no es muy favorable. Por un lado existen las barreras naturales de la acequia de Urdán y sobre todo el río Gállego para el que existen muy pocos pasos. Si no tenemos en cuenta los puentes de las distintas carreteras, sólo existen las pasarelas peatonales de Santa Isabel y la próxima a San Juan de Mozarrifar que se indican en el plano siguiente. La foto que hay a continuación del plano es de la segunda pasarela.

Por otro lado, la carretera de acceso al campus (A-123) carece de arcén en gran parte de su trazado, tiene límite de 70 km/h, muchas incorporaciones/salidas y considerable tráfico de tractores, camiones y autobuses (sobre todo a las horas de comienzo y fin de la jornada), por lo que la considero inconveniente para ciclistas. Pero evitar las carreteras conlleva algunos inconvenientes que vamos a analizar.

Ensuciamiento de la bicicleta¶

Los caminos en verano son muy polvorientos y en invierno se embarran y forman lagunas. Ambas situaciones ensucian la bicicleta, sobre todo el polvo en verano que ataca la transmisión (cadena, platos y piñones), bujes y pedalier. Para el barro y los charcos lo mejor es que la bicicleta disponga de guardabarros, aunque en mi caso particular no los puedo (ni quiero) poner.

Considerando ambos problemas, aún así me he decantado por utilizar los caminos rurales y limpiar la bicicleta con la frecuencia que la situación requiera. Pero hay momentos puntuales, tras varios días de lluvia por ejemplo, en los que conviene tener una alternativa por asfalto. Para esa situación, y en mi caso particular, recurro a la carretera que conecta San Gregorio con San Juan de Mozarrifar que termina en la carretera de Cogullada, otra buena alternativa si se accede desde una zona situada al noroeste de Zaragoza. Ambos tramos de carretera tienen poco tráfico y límite de 50 km/h. Desde la carretera de Cogullada se puede acceder a la pasarela cerca de San Juan saliendo hacia el campo de fútbol de San Juan.

De todas formas en términos de minimizar el ensuciamiento y mantenimiento de la bicicleta, la mejor ruta en mi opinión es la que me enseñó el compañero Magí que utilizando la pasarela de Santa Isabel para superar el Gállego, transcurre por asfalto hasta más arriba de la Montañanesa. Es la denominada Azud - Campus (margen izq. Gállego, asfalto) en la tabla de rutas final. Poco antes de llegar a la acequia de Urdán (en este punto) tenemos las opciones de terminar por caminos rurales por la izquierda o girar a la derecha para salir delante de la Montañanesa a la carretera de Montañana de la que recorreremos un pequeño tramo hasta tomar el Camino el Soaso para alcanzar el campus integramente por asfalto y por vías con poco tráfico. Si no utilizo personalmente esta ruta es porque tengo que dar algo de vuelta para poder acceder a ella y porque disfruto más rodando por caminos rurales con la bicicleta de montaña.

Otra ruta un poco más larga pero íntegramente por asfalto y que minimiza el tránsito por la carretera de Montañana es la que me enseñó el compañero Ricardo y que desde Santa Isable discurre enteramente por calzadas paralelas a la de Montañana. Es la denominada Azud - Campus (todo asfalto 3) en la tabla de rutas final.

En cuanto a la limpieza de la bicicleta en sí, he llegado al compromiso de fijarme exclusivamente en la transmisión (cadena, platos y piñones). He terminado usando lubicante basado en cera, que tiene el inconveniente de que hay que reponerlo cada pocos días (3 ó 4) pero a cambio la cadena no acumula la típica mugre mezcla de grasa y polvo. Utilizo el de la marca X-sauce (en tiendas de comercio local cuesta la mitad que en Amazon).

Una vez al mes llevo la bicicleta a un lavadero de coches. Empiezo limpiando la cadena con un accesorio para facilitar la tarea que lleno de desengrasante biodegradable (la marca BLUB en concreto me da un resultado excelente). Tras eso, retiro las pastillas de freno para que no se contaminen y le doy un manguerazo a la bicicleta. En casa seco, aplico WD-40 en las articulaciones de los desviadores y lubrico la cadena con el producto mencionado antes.

Charcos y barro¶

El tema de los charcos puede parecer menor, pero al menos la pasada temporada fría (2023/2024), desde octubre hasta abril han existido en varios puntos de mi ruta habitual, tres zonas difíciles de pasar, es decir, el problema va más allá de que se ensucie la bicicleta. Uno de los puntos es el puente del ferrocarril que accede a la Montañanesa en su paso sobre la pista que trascurre por la margen derecha del Gállego. Afortunadamente descubrí que poco antes de ese punto sale una vía a la derecha que permite pasar el puente por uno de sus vanos menores más adelante.

Otro paso incluso peor, dado que no existe alternativa una vez que estás allí (está entre una valla y un campo que en ocasiones no es practicable), es el que hay en un punto del camino muy próximo al puente comentado antes. Durante todos estos meses fríos han existido unas lagunas cuyos bordes se mantenían permanentemente embarrados por el agua que desplazaban los vehículos al pasar. En los peores momentos la alternativa era dar un poco de vuelta subiendo un poco por la carretera de Cogullada para acceder al camino que discurre por el otro lado de la vía del ferrocarril y de paso evitar el puente.

Frío y noche¶

En invierno el principal enemigo es el frío en las manos y la iluminación. Para lo primero he probado muchos modelos de guantes con y sin calefacción, y no ha sido hasta adquirir los últimos que no he conseguido solucionar el problema. Desafortunadamente en el momento de escribir este artículo no se encuentran a la venta, aunque podría ser por no estar todavía en la temporada de invierno. Son el modelo "HEAT CONCEPT BIKE" de la marca Ekoi.

En cuanto a la iluminación, hace tiempo que adquirí un foco potente (parecido a éste) para las excursiones veraniegas nocturnas. Empecé a tener problemas con la batería, pero por lo que he podido ver el formato de las mismas es bastante estándar o popular (8,4V) por lo que pude encontrar reemplazo fácilmente.

Mayor riesgo de pinchazos¶

Aquí sólo puedo hacer la natural recomendación de llevar bomba encima para por lo menos poder ir hinchando la rueda en caso de pinchar hasta llegar al destino. En mi caso llevo las ruedas montadas sin cámara o en tubeless, cosa que recomiendo a pesar de los inconvenientes que tiene (requiere mantenimiento y es mucho más engorroso desmontar el neumático). Gracias a ello me he podido olvidar del tema de los pinchazos desde hace años (salvo un par de episodios dramáticos en los que el neumático se hubiera destrozado llevase lo que llevase).

Más tiempo de viaje¶

Utilizar los caminos rurales conlleva más tiempo por una parte por la menor velocidad de circulación y por otra por los rodeos que hay que hacer para lograr la conexión de pistas. Aunque como puede verse en el mapa final con las rutas, la mayoría son bastante directas.

Orientación inicial¶

Relacionado con el punto anterior existe la posibilidad de despistarse, al menos durante los primeros días, sobre todo si se utiliza la opción de los caminos rurales, al no haber señalización y ser los caminos/campos parecidos. El primer día que intenté ir al campus en bicicleta fue un desastre. Tuve que improvisar en las proximidades del recinto porque la ruta que llevaba pretrazada con Google Maps me llevaba por un paso bloqueado. Ese día empleé una hora más de la cuenta dando vueltas por un terreno salvaje que hay entre el Gállego y el recinto del campus y más adelante atravesando unos campos encharcados que parecían una buena opción para atajar 🤦.

Para evitar este problema, por una parte conviene utilizar la herramienta adecuada para trazar la ruta, que no es Google Maps como el compañero Miguel me enseñó, sino otra basada en los mapas de OpenStreetMap como GraphHopper donde sí están correctamente mapeado el perímetro del recinto del campus. Por otra parte, conviene llevar un GPS que nos permita seguir la ruta sin tener que parar a mirar el mapa. En mi caso empecé utilizando un viejo Garmin Edge 305 que ya que ahora domino de memoria las distinas opciones, puedo prestar a otras personas que se animen a ir en bici al campus para que se aprendan el recorrido. Si se dispone de un soporte de manillar para smartphone, también se puede utilizar una aplicación de navegación como OsmAnd con los tracks precargados.

Rutas¶

A continuación se enumera la coleccion de rutas que he seleccionado. Uno de los objetivos de la selección ha sido cubrir distintos puntos de partida repartidos por el noreste de Zaragoza. Otro el que existan opciones que discurran íntegramente por asfalto, bien por los días en que los caminos estén embarrados o pensando en las personas que sólo cuenten con bicicletas de carretera. El tiempo estimado que aparece en la tabla es una aproximación que puede variar en función de la forma física, el tipo de bicicleta y las condiciones meteorológicas (¡hola cierzo!). En la columna de observaciones se indican los puntos conflictivos o a tener en cuenta en cada ruta. Por último, la primera columna contiene un enlace para descargar los tracks GPX de forma que se puedan instalar en aplicaciones como la mencionada OsmAnd.

Ruta	Distancia	Tiempo estimado	Observaciones
Juslibol/Actur - Campus (por San Gregorio)	14,38 km	40m-1h	Hay que cruzar la carretera de Huesca pero se puede hacer por paso elevado. 🚧
Arrabal/Picarral - Campus (por Corbera Alta)	13,05 km	35m-55m	🚧
Cogullada - Campus (Carretera Cogullada)	9,95 km	30m-45m	Poco tráfico. 🚧
Azud - Campus (por margen der. Gállego)	13,00 km	35m-55m	La más divertida. 🚧
Azud - Campus (margen izq. Gállego, asfalto)	12,05 km	35m-50m	En mi opinión la mejor, buen equilibrio entre rapidez, pocos coches, limpieza de bici y opción a terminar del todo por asfalto.
Azud - Campus (margen izq. Gállego, caminos)	11,73 km	35m-50m	Paralela a la anterior, sin coches pero ensucia más la bicicleta. 🚧
Azud - Campus (todo asfalto)	13,08 km	35m-55m	Tramo compartido con tráfico rodado desde Montañanesa hasta entrada a Camino el Saso.
Azud - Campus (todo asfalto 2)	12,12 km	35m-50m	Tramo compartido con tráfico rodado desde Santa Isabel hasta Montañana.
Azud - Campus (todo asfalto 3)	13,02 km	35m-55m	Sólo discurre por la carretera de Montañana un pequeño tramo con arcén.

El emoji 🚧 en las observaciones de algunas de las rutas de la tabla significa que hay que hacer el paso por el acueducto sobre la acequia de Urdán. Se trata del acueducto de la foto. Puede ser un poco complicado de pasar junto a la bici, sobre todo cuando transporta agua o está mojado, ya que se vuelve resbaladizo y es estrecho. En caso de no verlo claro, se puede pasar al otro lado de la acequia por un paso a nivel que hay más adelante a unos 400m.

Ver a pantalla completa

Zaragoza - Campus routes by bike

Fri, 31 May 2024 08:00:00 +0200

Photo by Javier Rodrigo

Right margin route closed

The path that runs along the right bank of the Gállego River (the route named "Azud - Campus (right bank of Gállego)" in the final table) is blocked by landslides between waypoints 14 and 15, where it passes next to a wall enclosing a plot of land very close to the river itself, at least as of 2025-02-18. One option to bypass this point is to temporarily exit onto the Cogullada road, which runs opposite the walled plot of land.

Currently, I work at the Aula Dei Campus, about 15 km from Zaragoza. Although there are several options for getting to the campus by bus, in my particular case, the combination of routes and schedules is not favorable, so from the beginning, I chose to go by bike. After a few days of testing, I adjusted the route and equipment to make it more convenient and safe. In this post, I list the different options I have come to know and describe, in my opinion, their pros and cons.

Problems and solutions¶

It should be noted from the beginning that unfortunately, access to the campus by bike is not very favorable. On one hand, there are natural barriers such as the Urdán canal and especially the Gállego river, for which there are very few crossings. If we don't consider the road bridges, there are only the pedestrian walkways of Santa Isabel and the one near San Juan de Mozarrifar, as indicated on the following map. The photo below the map is of the second walkway.

On the other hand, the access road to the campus (A-123) lacks a shoulder for most of its route, has a speed limit of 70 km/h, many entry and exit points, and considerable traffic from tractors, trucks, and buses (especially at the start and end of the workday), which makes it unsuitable for cyclists in my opinion. However, avoiding the roads brings some drawbacks that we are going to analyze.

Bike dirt accumulation¶

The paths are very dusty in summer and become muddy with puddles in winter. Both situations dirty the bike, especially the dust in summer, which affects the transmission (chain, chainrings, and cogs), hubs and pedal axle. For mud and puddles, the best solution is to have fenders on the bike, although in my particular case, I cannot (nor do I want to) install them.

Considering both problems, I have still chosen to use the rural paths and clean the bike as often as needed. However, there are certain times, after several days of rain for example, when it’s useful to have an asphalt alternative. For this situation, and in my particular case, I use the road that connects San Gregorio with San Juan de Mozarrifar, which ends at the Cogullada road, another good alternative if accessing from an area northwest of Zaragoza. Both road sections have little traffic and a speed limit of 50 km/h. From the Cogullada road, you can access the walkway near San Juan by heading towards the San Juan football field.

In any case, in terms of minimizing cleaning and bike maintenance, the best route in my opinion is the one shown to me by my colleague Magí, which uses the Santa Isabel walkway to cross the Gállego river and follows asphalt up to above Montañanesa. It's called Azud - Campus (left bank of Gállego, asphalt) in the final route table. Shortly before reaching the Urdán canal (at this point), we have the options of finishing on rural paths to the left or turning right to exit in front of Montañanesa onto the Montañana road, which we will follow for a short distance before taking the Camino el Soaso to reach the campus entirely on asphalt and on low-traffic roads. The reason I don't personally use this route is because I have to make a bit of a detour to access it and because I enjoy riding on rural paths with the mountain bike.

Another route, slightly longer but entirely on asphalt and minimizing traffic on the Montañana road, is the one my colleague Ricardo showed me. From Santa Isabel, it runs entirely on roads parallel to the Montañana road. It is listed as Azud - Campus (all asphalt 3) in the final route table.

As for cleaning the bike itself, I’ve come to the compromise of focusing exclusively on the drivetrain (chain, chainrings, and cogs). I ended up using a wax-based lubricant, which has the downside of needing to be reapplied every few days (3 or 4), but in return, the chain doesn’t accumulate the typical grime mix of grease and dust. I use the X-sauce brand (it costs half as much in local stores as it does on Amazon).

Once a month, I take the bike to a car wash. I start by cleaning the chain with a chain cleaner tool, which I fill with biodegradable degreaser (the BLUB brand, in particular, works excellently for me). After that, I remove the brake pads to prevent contamination and hose down the bike. At home, I dry it, apply WD-40 to the derailleur joints, and lubricate the chain with the previously mentioned product.

Puddles and mud¶

The issue of puddles may seem minor, but at least during the last cold season (2023/2024), from October to April, there were three difficult-to-pass areas at various points on my usual route, meaning the problem goes beyond just getting the bike dirty. One of these points is the railroad bridge that accesses Montañanesa as it crosses the path running along the right bank of the Gállego. Fortunately, I discovered that shortly before that point, a path branches off to the right, allowing you to pass under the bridge through one of its smaller arches further ahead.

Another even worse crossing, given that there is no alternative once you are there (it is between a fence and a field that is sometimes non-cyclable), is at a point on the path very close to the previously mentioned bridge. Throughout these cold months, there were ponds whose edges remained permanently muddy due to the water displaced by passing vehicles. In the worst moments, the alternative was to take a slight detour up the Cogullada road to access the path that runs on the other side of the railway and thereby avoid the bridge.

Cold and Night¶

In winter, the main enemies are cold hands and lighting. For the former, I’ve tried many models of gloves, both heated and non-heated, and it wasn’t until I purchased the latest ones that I managed to solve the problem. Unfortunately, at the time of writing this article, they are not available for sale, although this might be due to the winter season not yet starting. They are the "HEAT CONCEPT BIKE" model from the brand Ekoi.

As for lighting, some time ago I bought a powerful light (similar to this one) for summer night rides. I started having problems with the battery, but from what I’ve seen, the battery format is quite standard or popular (8.4V), so I was able to easily find a replacement.

Increased risk of punctures¶

Here, I can only offer the natural recommendation to carry a pump with you, at least to be able to inflate the tire in case of a puncture until reaching your destination. In my case, I have my tires set up tubeless, which I recommend despite the inconveniences it has (it requires maintenance and it's much more cumbersome to remove the tire). Thanks to this, I have been able to forget about punctures for years (except for a couple of dramatic episodes where the tire would have been destroyed regardless of the tire type).

Longer travel times¶

Using rural paths takes more time, partly due to the slower travel speed and partly due to detours required to connect tracks. Although, as can be seen on the final map with the routes, most are quite direct.

Initial orientation¶

Related to the previous point, there's the possibility of getting lost, at least during the first few days, especially when using rural paths, as there's no signage and the paths/fields look similar. The first day I attempted to bike to the campus was a disaster. I had to improvise near the campus because the route I had pre-mapped with Google Maps led me to a blocked fence. That day I spent an extra hour circling through wild terrain between the Gállego river and the campus area, and later on, crossing some waterlogged fields that seemed like a good shortcut option 🤦.

To avoid this problem, on one hand, it's advisable to use the appropriate tool to plan the route, which is not Google Maps as my colleague Miguel taught me, but another based on OpenStreetMap like GraphHopper where the campus perimeter is correctly mapped. On the other hand, it's advisable to carry a GPS device that allows us to follow the route without having to stop and check the map. In my case, I started using an old Garmin Edge 305. Now that I know all the different options by heart, I can lend it to other people who are encouraged to bike to the campus so they can learn the route. If you have a handlebar mount for a smartphone, you can also use a navigation app like OsmAnd with preloaded tracks.

Routes¶

Below is the collection of routes I have selected. One of the objectives of the selection has been to cover different starting points scattered throughout the northeast of Zaragoza. Another objective is to have options that run entirely on asphalt, either for days when the paths are muddy or for people who only have road bikes. The estimated time shown in the table is an approximation that may vary depending on physical fitness, bike type, and weather conditions (hello Zaragoza wind!). The observations column indicates any problematic points or factors to consider on each route. Finally, the first column contains a link to download the GPX tracks so they can be installed in applications such as the mentioned OsmAnd.

Route	Distance	Estimated time	Observations
Juslibol/Actur - Campus (by San Gregorio)	14,38 km	40m-1h	You have to cross the Huesca road, but it can be done via an overpass. 🚧
Arrabal/Picarral - Campus (by Corbera Alta)	13,05 km	35m-55m	🚧
Cogullada - Campus (Cogullada road)	9,95 km	30m-45m	Low traffic. 🚧
Azud - Campus (right bank of Gállego)	13,00 km	35m-55m	The most fun. 🚧
Azud - Campus (left bank of Gállego, asphalt)	12,05 km	35m-50m	In my opinion the best option, offers a good balance between speed, few cars, bike cleanliness, and the possibility to finish entirely on asphalt.
Azud - Campus (left bank of Gállego, rural paths)	11,73 km	35m-50m	Parallel to the previous one, without cars but it dirties the bike more. 🚧
Azud - Campus (all asphalt)	13,08 km	35m-55m	It has a section shared with road traffic from Montañanesa to the entrance of Camino el Saso.
Azud - Campus (all asphalt 2)	12,12 km	35m-50m	It has a section shared with road traffic from Santa Isabel to Montañana.
Azud - Campus (all asphalt 3)	13,02 km	35m-55m	There is only a small section along the Montañana road but have a shoulder.

The emoji 🚧 in the observations of some routes in the table means that you have to cross the aqueduct over the Urdán canal. This is the aqueduct in the photo. It can be a bit tricky to pass with the bike, especially when it's carrying water or wet, as it becomes slippery and it is narrow. If it's not clear, you can cross to the other side of the canal via a level crossing further ahead, about 400m away.

Full screen view

Apuntes de eduardófilo

G&W Zelda hack

Conexión al puerto SWD¶

Versión difícil¶

Versión fácil¶

Sonda de programación¶

Desbloqueo del microcontrolador¶

Modificación 1: retro-go¶

Sustitución de la flash¶

Flasheo retro-go¶

Respaldar savestates retro-go¶

Modificación 2: retro-go-sd¶

Instalación módulo slot microSD¶

Flasheo bootloader¶

Instalación de Retro-Go SD¶

Carcasa trasera¶

Controles¶

Referencias¶

G&W Zelda hack

Connection to the SWD port¶

Hard version¶

Easy version¶

Programming probe¶

Microcontroller unlocking¶

Modification 1: retro-go¶

Flash replacement¶

Flashing retro-go¶

Backup retro-go savestates¶

Modification 2: retro-go-sd¶

microSD slot module installation¶

Bootloader flashing¶

Retro-Go SD installation¶

Back case¶

Controls¶

References¶

Instalación Arch Linux en Lenovo ThinkPad T480

Reparticionado del disco¶

Instalación base¶

loadkeys es¶

iwctl¶

timedatectl¶

fdisk /dev/sda¶

mkfs.ext4 /dev/sda6¶

mkswap /dev/sda5¶

mount /dev/sda6 /mnt¶

mount --mkdir /dev/sda1 /mnt/boot/efi¶

swapon /dev/sda5¶

pacstrap -K /mnt base base-devel linux linux-firmware sudo vi ntfs-3g networkmanager intel-ucode grub efibootmgr os-prober¶

genfstab -U /mnt >> /mnt/etc/fstab¶

arch-chroot /mnt¶

ln -sf /usr/share/zoneinfo/Europe/Madrid /etc/localtime¶

hwclock --systohc¶

vi /etc/locale.gen # Descomentar 'en_US.UTF-8 UTF-8' y 'es_ES.UTF-8 UTF-8'¶

locale-gen¶

echo "LANG=es_ES.UTF-8" > /etc/locale.conf¶

echo "KEYMAP=es" > /etc/vconsole.conf¶

echo "thinkpad" > /etc/hostname¶

echo -e "\n127.0.0.1 localhost\n::1 localhost\n127.0.1.1 thinkpad.localdomain thinkpad" >> /etc/hosts¶

passwd¶

useradd -m -G wheel,audio,video,storage -s /bin/bash ¶

passwd ¶

visudo # Descomentar '%wheel ALL=(ALL) ALL'¶

systemctl enable NetworkManager¶

vi /etc/default/grub # Descomentar 'GRUB_DISABLE_OS_PROBER=false'¶

os-prober¶

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB¶

grub-mkconfig -o /boot/grub/grub.cfg¶

su - ¶

Instalación entorno gráfico¶

exit¶

umount -R /mnt¶

reboot¶

Applet NetworkManager y Bluetooth¶

Instalación pamac¶

Conclusión¶

Enlaces de interés¶

Arch Linux Installation on Lenovo ThinkPad T480

Disk repartitioning¶

Base installation¶

loadkeys es¶