My answers to Interstellar questions

As he already did in movies like Inception or Memento, Christopher Nolan has introduced some big open questions in his latest movie, Interstellar, leaving to the spectator the task of filling the blanks with his own interpretation.

I’ve decided to give it a shot, writing here my answers to such questions. As it’s obvious, from this point, there will be HUGE spoilers, so stop reading if you haven’t watched the movie yet (and go to your nearest theater right now! ;-).
(more…)

Read More

Porting socz80 (a retro microcomputer) to DE0-nano

Due to my intrinsic, chronic curiosity, for a long time I wanted to get a in touch with FPGA and related technologies (Verilog, VHDL, etc…), and experience the feeling of total control, having both hardware and software subdued to my control (well, not so much, due to the mysterious and semi-secret process of synthetization and fitting done by the tools involved in the process, but you get the idea).

So finally, some months ago, I bought a DE0-nano. This is a small but nicely built device, easily programmable with an integrated USB Blaster, and with a relatively low price (~70 €), which makes it perfect for learning and practicing a little.

IMG_20140911_235844

After a few project of blinking LEDs and playing with clocks and PLLs, I’ve decided to take a step further and seek for a challenge. Then I came across the socz80 project, an amazingly cool project for building a Z80 compatible computer in FPGA-synthetizable VHDL. The code was targeted for the Papilo Pro board, which is a Xilinx based device (the FPGA world is divided between two major makers, Xilinx and Altera), so I decided to give a try and port it to the DE0-nano.

After a few hours dealing with timing problems, I managed to get it running. This is how I’ve done it.

(more…)

Read More

Getting freedesktop notifications from Telegram CLI

NOTE: In the comments section, AleixDev proposes a simpler solution, calling an external process. Take a look at it if you don’t want to build cdbus and l2dbus by yourself.

Lately, Telegram is gaining a lot of traction as an alternative to WhatsApp. From my point of view, that’s quite cool for a variety of reasons, specially for features like secret chats, but also due to the (reasonably) open nature of its protocol.

This openness will surely lead to a widespread adoption of the protocol, specially on Free Software IM clients (something that WhatsApp has stupidly rejected from its very beginnings, which is something that, IMHO, will hurt their business in the long term), making it available on multiple devices and Operating Systems, effectively ending vendor dictated restrictions and the pain of being forced to use a mobile touchscreen even when you’re in front of a computer with a full size physical keyboard.

In my particular case, until the protocol is implemented in Kopete (I’d like to do this work myself, but I don’t the time right now), I’m using the CLI client created by Vitaly Valtman. Using a command line program for messaging may look awkward to some people, but I’m quite comfortable with it. The only thing I was missing is being notified when a message arrives, so I’ve decided to do something about this.

It was clear to me that the better approach would be to create a DBUS connection for sending a notification through it, something that both KDE and GNOME desktops would know how to interpret and show. My initial intention was to modify the source code to implement this function, but since tg-cli supports Lua, a language I’ve head a lot about but I’ve never actually used, I’ve decided to give it a try, which also saves me from patching the source code.

Installing Telegram CLI with notifications

  1. Clone and build CDBUS: https://github.com/xs-embedded-llc/cdbus
  2. Clone and build L2DBUS: https://github.com/xs-embedded-llc/l2dbus
  3. Clone and build Telegram CLI: https://github.com/vysheng/tg
  4. Clone: https://github.com/slp/tg-notify
  5. (Optional) Grab a cool icon (you can download the official app logo from its repo), place it somewhere, and update the “icon_file” variable in notify.lua to point to it (use full path, not relative).
  6. Run Telegram CLI with notify.lua: ./telegram -s notify.lua

Have fun!

Read More

Aumentando la duración de la batería en GNU/Linux con PowerTOP

En los últimos años, gracias a las nuevas generaciones de procesadores optimizados para portátiles y a la proliferación de discos de estado sólido, hemos visto cómo aparecían ultrabooks cuya autonomía supera con holgura las 5 horas. Por otra parte, a mayor duración de la batería, mayor impacto en la misma tiene la configuración y el comportamiento del software.

Por fortuna, en GNU/Linux disponemos de PowerTOP, una herramienta desarrollada por ingenieros de Intel, que nos ofrece información detallada sobre la distribución del consumo energético, y una serie de recomendaciones para reducirlo.

Usando PowerTOP: ¿Qué procesos despiertan la CPU?

Desde hace varios años, los procesadores x86 ofrecen al sistema operativo la posibilidad de minimizar el consumo energético reduciendo la frecuencia del reloj (Dynamic frequency scaling), o incluso apagándolos parcialmente (saltando entre C-States). Lógicamente, el S.O. sólo puede hacer uso de estas funcionalidades cuando no hay ningún proceso reclamando ser planificado.

powertop1

En esta línea, la primera pantalla de PowerTOP nos muestra información sobre los eventos que “despiertan” la CPU y el origen de los mismos. Conviene que revisemos la parte alta de dicha lista, en busca de algún proceso que no debiera estar allí. Puede sonar extraño, pero dependiendo del escritorio y la distribución que estemos empleando, nos podemos encontrar con un gestor de ventanas que no para de lanzar eventos, o con alguna aplicación de sincronización en la nube que está “demasiado activa”.

Usando PowerTOP: Opciones recomendadas

Una funcionalidad especialmente útil de PowerTOP, es la que nos muestra una lista de configuraciones recomendadas para el S.O. que no tenemos activas, y nos indica el comando que debemos ejecutar para reestablecerlas.

powertop2

Es posible activar dichas opciones pulsando enter sobre ellas, pero dicha configuración no es permanente, y ser perderá tras un reinicio. Una forma sencilla de extraer los comandos para cargarlos en el rc.local (o el equivalente que use nuestra distro), sería algo así:

slp@linux-18od:/tmp> # Generamos un informe en CSV con PowerTOP
slp@linux-18od:/tmp> sudo powertop --csv
Cargado 260 medidas previas
RAPL device for cpu 0
RAPL device for cpu 0
RAPL device for cpu 0
Preparing to take measurements
Taking 1 measurement(s) for a duration of 20 second(s) each.
PowerTOP outputing using base filename powertop.csv
slp@linux-18od:/tmp> # Editamos el fichero powertop.csv, y eliminamos todo menos en la sección "Software Settings in need of Tuning"
slp@linux-18od:/tmp> vi powertop.csv
slp@linux-18od:/tmp> # Preparamos un pequeño script para extraer la parte que nos interesa:
slp@linux-18od:/tmp> cat > pmtun.py << EOF
import re

file = open("powertop.csv", "r")
lines = file.readlines()
for l in lines:
    m = re.match(".*?;(.*)", l)
    if m:
        print m.group(1).replace("\"","").replace(";","")
EOF
slp@linux-18od:/tmp> # Y hacemos uso de él
slp@linux-18od:/tmp> python pmtun.py > commands
slp@linux-18od:/tmp> # Finalmente, revisamos el fichero y hacemos copypaste a nuestro rc.local
slp@linux-18od:/tmp> vi commands

Tras reiniciar, al volver a la misma pantalla de PowerTOP, deberíamos ver cómo todas las configuraciones parecen como ya establecidas:

powertop3

Read More

Running RISCOS on QEMU

UPDATE (17/09/14): Some time after writing this, I’ve replaced the QEMU repository referenced here with a clean one without the changes needed for running RISCOS. I’ve just created another repository with the proper sources: https://github.com/slp/qemu-riscos.

Some time ago, while trying to get NetBSD to run on Efika MX Smartbook (I should write about that), I’ve decided that I would never do any serious OS development on a platform without a JTAG interface, or a working emulator. Being able to stop the execution at will, for looking at the CPU registers, or examining an arbitrary memory location, will save you a lot of hours otherwise invested in a painful trial and error cycle.

For this reason, when I’ve decided to try and do some hacking on RISCOS (and I’m not going to lie, I was attracted by their bounty program), the first option I’ve considered was trying to get it to work under QEMU. This serves a double purpose: establishing a comfortable development environment, and getting myself to know RISCOS internals and its build process.

Nowadays, in addition to other platforms, RISCOS is able to run on BeagleBoard (OMAP3) and Raspberry Pi (BCM2835). I have access to a real RPi, so being able to emulate this platform would allow me to do most part of the coding under QEMU, and then verify the results with a physical device.

The bad news is that QEMU, as is, doesn’t emulate the BCM2835 SoC. True, some people are running Raspberry Pi GNU/Linux distributions under QEMU, but this is being done with a trick, replacing the original kernel with one compiled for VersatilePB SoC, which is fully emulated under QEMU. As the userland doesn’t care much about the SoC (it just needs a platform compatible with its ABI, which it’s mostly the case, unless you’re applying some NEON/VFP3 optimizations), this approach works reasonably well. But, for this strategy to work for RISCOS, I would need to do a new port to the VersatilePB platform, and that’s a project far beyond the size of what I initially considered.

Luckily, I’ve came across the amazing work being done by Gregory Estrade to add real BCM2835 emulation on QEMU. Older versions of RISCOS did run on qemu-rpi, but recent ones refused to boot. With a bit of hacking here and there, I’ve managed to get it to boot to the Desktop, but I still needed a working pointer.

As with the real RPi, the emulated one should be able to provide an USB mouse, but with pre-EHCI interfaces, data polling for USB pointer interfaces its just too expensive, and it showed an erratic behavior. I can’t say this came to me as a surprise, as I still remember the days when the first USB mouse got introduced to x86 desktops, and how it jumped around the screen when the CPU was slightly loaded.

Thinking about this problem, I’ve remembered that QEMU also features USB Tablet emulation. A tablet always provides absolute positions for the pointer, which makes it more precise, even when working with a lower interrupt rate. After applying an ugly and crude (but working!) hack to make QEMU provide resolution adjusted values that RISCOS could properly interpret as pointer positions, I’ve finally got a working RISCOS Desktop:

riscos-qemu

Running it yourself

To be able to run RISCOS on QEMU, follow this steps:

  1. Checkout my fork of qemu-rpi, switch to the rpi branch, and build it (you’ll only need the arm-softmmu target).
  2. Grab a RISCOS for Raspberry Pi SD Card image from here: http://www.raspberrypi.org/downloads
  3. Get my patched ROM: riscos.rom. Alternatively, if you have access to a RISCOS machine and the DDE, you can download this patch and build it yourself.
  4. Uncompress both files.
  5. Launch QEMU with something like this:
    qemu-system-arm -kernel riscos.rom -initrd riscos.rom -cpu arm1176 -M raspi -sd riscos-2013-07-10-RC11.img -d guest_errors -serial stdio -device usb-kbd -device usb-tablet -usb

Stuff to be done

  • Support for USB storages. This needs some fixes on the QEMU BCM2835 USB stack.
  • Network support. This needs some of the fixes mentioned above, and extending RISCOS support for USB CDC network devices.
  • Fix some graphic glitches.

Read More

Table: Libre Mobile OS Alternatives to Android.

Project Core Graphical Backend User Interface Applications Framework Main License Requires Proprietary Components Flagship Device
FirefoxOS Android/b2g GAIA Firefox HTML5+JS MPL Yes Geeksphone Keon/Peak
Ubuntu Touch Android/Ubuntu Mir Unity 8 Qt 5 (C++/QML) GPL Yes Nexus 4
Maemo Debian/Maemo X11 Hildon C+GTK ? Yes Nokia N900
MeeGo Maemo/Moblin X11 ? Qt 4.7 (C++/QML) GPL/LGPL Yes Nokia N9/950
Nemo Mer (MeeGo evolution) Wayland Lipstick Qt 5 (C++/QML) GPL/LGPL Yes Nokia N9/950
Plasma Active Mer (MeeGo evolution) Wayland Plasma Qt 5 (C++/QML) GPL/LGPL Yes ?

Read More

Desarrollando un videojuego sencillo (Parte II – Bucle principal y mapa del nivel)

Pequeño cambio de planes

Aunque en la primera parte había comentado que iba a usar Python+PyGame para escribir el prototipo, he cambiado de idea y voy a emplear HTML5 con JavaScript. Hay varias razones que me han animado a llevar a cabo este cambio:

  • Aparte de anotame.es, no he trabajado mucho con JavaScript, y me apetece reforzar mi experiencia con este lenguaje.
  • JavaScript es también un lenguaje de alto nivel y, aunque no me entusiasma depender del navegador, debo reconocer los ciclos de coding<->debugging<->coding son bastante ágiles.
  • Me permite publicar los ejemplos funcionando en este mismo Blog.
  • Facilita la integración de funciones “sociales” que tan de moda están hoy en día, y con las que puede ser interesante experimentar más adelante.

El bucle principal

Habitualmente, el corazón del código de un videojuego está compuesto por un bucle principal que, al menos conceptualmente, suele ser similar a éste:

  1. Procesar los eventos de entrada.
  2. Actualizar la representación lógica del mundo.
  3. Pintar el mundo en la pantalla (representación visual del mundo).

Para este proyecto, voy a partir del código de del proyecto mortar-game-stub de Mozilla, que nos proporciona un canvas de HTML5 y el esqueleto de la aplicación JavaScript. La función principal se encuentra en el fichero www/js/app.js, donde podemos encontrar además una implementación básica del mencionado bucle (he añadido más comentarios para explicar su funcionamiento):

    // Bucle principal
    function main() {
        // Si nuestra pestaña en el navegador no es visible,
        // omitimos las actualizaciones.
        if(!running) {
            return;
        }

        // Tomamos la referencia del tiempo transcurrido desde
        // la última iteración.
        var now = Date.now();
        var dt = (now - then) / 1000.0;

        // Procesamos los eventos y actualizamos el mundo.
        update(dt);

        // Representamos el mundo en el canvas de HTML5.
        render();

        // Actualizamos la marca de tiempo.
        then = now;

        // Solicitamos al navegador que nos vuelva a llamar
        // cuando considere oportuno.
        requestAnimFrame(main);
    };

 

Pintando el mapa del nivel

Ahora que ya está localizado el bucle principal, hay que empezar a darle forma al juego. A la hora de  diseñar los componentes, se debe tener en cuenta que se tiene que trabajar tanto en su representación visual (cómo se va a ver el componente en la pantalla) como en su representación lógica (las estructuras de datos que permiten definir y manipular el componente en el código).

Voy a empezar por implementar el mapa del nivel, es decir, el mundo por el que se va a mover el personaje del jugador en cada pantalla del juego. Utilizando el Donkey Kong original como inspiración, quiero preparar algo sencillo, con plataformas a varias alturas y escaleras conectándolas. Mirando en el spritesheet del Platformer Art Deluxe, veo cuatro tiles que me pueden venir bien para empezar:

grassMid

 

 

grassRight

 

 

grassLeft

 

 

ladder_mid

 

 

El primero representa la parte central de la plataforma, mientras que el segundo y el tercero se corresponden a los bordes derecho e izquierdo, respectivamente. El cuatro tile será la pieza base para construir las escaleras que conectan las plataformas.

Para poder hacer cambios de forma rápida, voy a hacer que cada nivel se represente en una rejilla de 15×12 celdas, y a definir el contenido de las mismas con números enteros. Como cada tile tiene un tamaño de 70×70 píxeles, la aplicación tendrá un resolución de 1050×840 (más adelante ya la ajustaremos convenientemente).

Dicha rejilla se puede implementar con un doble array (me niego a utilizar la traducción “arreglo”). Un nivel definido de esta forma, quedaría así:

var map = [
[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],
[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],
[1,1,1,1,1,1,1,1,1,1,1,1,1,1,1],
[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],
[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],
[1,1,1,1,1,1,1,1,1,1,1,1,1,1,1],
[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],
[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],
[1,1,1,1,1,2,0,0,3,1,1,1,1,1,1],
[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],
[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],
[1,1,1,1,1,1,1,1,1,1,1,1,1,1,1]]

En este caso, los “0” representan espacios vacíos, los “1” se corresponden con el tile del bloque central, el “2” con el derecho y el “3” con el izquierdo.

Como se puede observar, este mapa no tiene representada ninguna escalera. La razón es que la parte superior de la escalera debe superponerse al bloque de la plataforma, lo que obligaría a incrementar el número de dígitos empleados para representar las combinaciones posibles. De momento, y con el objetivo de simplificar, he creado un mapa independiente para las escaleras:

var map_ladders = [
[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],
[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],
[0,0,0,0,4,0,0,0,0,0,0,0,0,0,0],
[0,0,0,0,4,0,0,0,0,0,0,0,0,0,0],
[0,0,0,0,4,0,0,0,0,0,0,0,0,0,0],
[0,0,4,0,0,0,0,0,0,0,0,0,0,0,0],
[0,0,4,0,0,0,0,0,0,0,0,0,0,0,0],
[0,0,4,0,0,0,0,0,0,0,0,0,0,0,0],
[0,0,0,4,0,0,0,0,0,0,0,4,0,0,0],
[0,0,0,4,0,0,0,0,0,0,0,4,0,0,0],
[0,0,0,4,0,0,0,0,0,0,0,4,0,0,0],
[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]]

Si se mezclara este último mapa con el anterior, se vería que, efectivamente, las escaleras actúan como conectores entre las plataformas, y que la parte superior de las primeras se superpone con el bloque conectado. De todas formas, no hace falta imaginarlo, ya que va a ser posible verlo en cuanto se implemente el pintado del mapa en el canvas.

Como se ha visto en el código del bucle principal, éste llama a una función render que es la encargada de representar el mundo sobre el canvas. Ahora mismo, dicha función tan sólo rellena todo el espacio de color negro, y pinta un cuadrado verde para el jugador.

Voy a eliminar el contenido de la función para que pinte el mapa, pero antes necesito cargar las imágenes para tenerlas disponibles para su uso. Esta tarea se puede realizar añadiendo al principio de la función principal un fragmento de código como éste (he copiado previamente las imágenes que voy a emplear al directorio www/img):

    var imgGrassMid = new Image();
    imgGrassMid.src = 'img/grassMid.png';
    var imgGrassRight = new Image();
    imgGrassRight.src = 'img/grassRight.png';
    var imgGrassLeft = new Image();
    imgGrassLeft.src = 'img/grassLeft.png';
    var imgLadderMid = new Image();
    imgLadderMid.src = 'img/ladder_mid.png';

    var ASSETS = new Array();
    ASSETS.push('');
    ASSETS.push(imgGrassMid);
    ASSETS.push(imgGrassRight);
    ASSETS.push(imgGrassLeft);
    ASSETS.push(imgLadderMid);

El array ASSETS, con ese push vacío al principio, me proporciona una forma sencilla (aunque algo sucia) de posicionar los recursos gráficos en el mismo orden que estoy usando para representarlos en el mapa.

Ahora que los tengo cargados, ya puedo pintarlos en el canvas:

    function render() {
        // Pintamos todo el canvas de azul claro
        ctx.fillStyle = 'lightblue';
        ctx.fillRect(0, 0, canvas.width, canvas.height);
        
        // Recorremos la rejilla pintando los tiles representados
        // en la misma.
        for (var y=0; y < 12; y++) {
            for (var x=0; x < 15; x++) {
                var imgNum = map[y][x];
                if (imgNum != 0) {
                    ctx.drawImage(ASSETS[imgNum], x * BLKSIZE, y * BLKSIZE);
                }
                
                var ladderNum = map_ladders[y][x];
                if (ladderNum != 0) {
                    ctx.drawImage(ASSETS[4], x * BLKSIZE, y * BLKSIZE);
                }
            }
        }
    };

Con esto, ya está implementada la representación lógica y visual del mapa, y el primer nivel del juego queda representado en el navegador:

blog_juego_p2

Por supuesto, esta implementación de la función render es muy ineficiente, ya que se está pintando toda la pantalla indistintamente de lo que cambie. Una de las tareas que será necesario hacer en el futuro, será detectar qué partes de la rejilla han cambiado, y hacer que se pinten sólo estas últimas.

En la siguiente parte, añadiré el personaje del jugador y una lógica sencilla de movimiento, para que el juego empiece a ser algo interactivo.

Read More

Desarrollando un videojuego sencillo (Parte I – Introducción)

Durante mi carrera profesional, he tenido la fortuna de ir probando varias de las distintas vertientes que tiene el campo de las TI. Empecé como técnico de hardware, de ahí pasé a administrador de sistemas y, finalmente, llevo casi cuatro años desarrollando software, con la suerte de haber podido trabajar en proyectos de diversa naturaleza. Durante todo este tiempo, además, he ido complementando mi formación con proyectos personales, especialmente en el área de los Sistemas Operativos. Pero, a pesar de ello, sigo teniendo una espinita clavada: desarrollar un videojuego desde cero. Así pues, he decidido ponerme manos a la obra y, de paso, contar mi experiencia en este blog.

(more…)

Read More

Democracia representativa dinámica: una idea en bruto

Se suele decir que la democracia (haciendo alusión a la democracia representativa) es el menos malo de los sistemas políticos que ha puesto a prueba la humanidad. La situación actual ha evidenciado que lo de “menos malo”, ha pasado de ser un apelativo cariñoso, a un inmerecido piropo. El desgaste de este sistema es cada día más evidente. Y la reciente demostración que ha llevado a cabo el PP de que es posible ganar unas elecciones diciendo “blanco”, para luego gobernar haciendo “negro”, es un achaque más de esta moribunda democracia.

(more…)

Read More

Checking the health of your SSD from GNU/Linux

As you already know, SSDs degrade over time, as its memory cells support a limited amount of writes (a sacrifice that many people, including myself, find worthy in exchange to get rid of those slow and noisy mechanical disks).

This morning, while talking to a colleague, an interesting question was raised: how do we know when our SSD is near to day of its defunction?

Expensive, enterprise-grade SSD cards, like the ones from TMS, come with monitoring tools and a nice entry in “/proc” that can be easily checked by a script. But I had no idea if there’s some similar for consumer SSDs.

Turned out it was quite easy. Most models provide health info via the S.M.A.R.T. feature, so you can obtain it with smartctl (on Fedora, this utility came into the package smartmontools:

[slopez@slp-work ~]$ sudo smartctl -a /dev/sda
(...)
SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
9 Power_On_Hours 0x0032 099 099 --- Old_age Always - 23
12 Power_Cycle_Count 0x0032 099 099 --- Old_age Always - 34
177 Wear_Leveling_Count 0x0013 099 099 --- Pre-fail Always - 1
178 Used_Rsvd_Blk_Cnt_Chip 0x0013 077 077 --- Pre-fail Always - 458
190 Airflow_Temperature_Cel 0x0022 067 051 --- Old_age Always - 33
235 Unknown_Attribute 0x0012 099 099 --- Old_age Always - 10
(...)

The most relevant attribute while checking the health of our SSD, is Wear Leveling Count (more info on Wear_leveling on Wikipedia). But don’t get fooled by its name, it’s not really a count, but an indicator of how healthy are the cells in your disk, where 100 is the best, and 0 the worst.

When this value falls below 20, you should start considering backing up your data and buying a new disk.

Read More