1 de Julio, 2015

»BitBitJam 2015 · Se han anunciado fechas para la siguiente BitBit Jam: el fin de semana del 24 de Julio. Esta game jam consiste en hacer un juego para un sistema antiguo (de 8/16 bits), con la principal restricción de que debe funcionar en el hardware original, no solo en emuladores. Es complicado y todo tiene que ser desde cero, pudiendo usar librerías públicas existentes, y entregando el código fuente al final. No sé cuántos juegos se presentarán, pero mirando la edición anterior parece que los juegos basados en motores existentes se imponen (como por ejemplo la Churrera); lo cual hace el resultado algo menos interesante (podría ser la Churrera Jam, ¿no? :P).

Hay 0 comentarios, anotación clasificada en: programming.

24 de Junio, 2015

»Vuelve la leyenda · He empezado con el desarrollo, y a ver cuándo acabo. Será la secuela de The Legend of Traxtor, uno de los juegos que más me gustan de todos los que hice el año pasado. Lo estoy programanto también para el ZX Spectrum 48k (o superior :P), y espero corregir todos los fallos del original al mismo tiempo que añado nuevas ideas a la mecánica básica.

Menú provisional
Menú provisional, con colaboración de Craig Stevenson

Hay 0 comentarios, anotación clasificada en: speccy, programming.

23 de Junio, 2015

»ZX Dev 2015 · Se ha convocado la primera edición de ZX Dev, un concurso de programación de video juegos inspirado en el exitoso MSX Dev de MSX, que va básicamente de programar un juego para el ZX Spectrum (cualquier modelo). Ya me parecía raro que no hubiera una competición establecida (aparte del comp.sys.sinclair crap games competition, pero el espíritu del crap no es tanto hace un juego como pasarlo bien :P), así que a ver si hay respuesta, la gente participa y se convierte en un clásico de la escena homebrew. Yo por mi parte intentaré presentar algo, que hace tiempo que no me lío a hacer un juego desde que acabara el reto de un juego al mes ;).

Hay 0 comentarios, anotación clasificada en: speccy.

7 de Junio, 2015

»Nostalgia y retro · He estado suscrito por un año a la revista Retro Gamer, más o menos desde que me volví a encontrar con el ZX Spectrum; y la verdad es que al menos para mi celebrar la nostalgia no funciona. A mi me gusta que hablen de los juegos, pero parece que la moda retro no va de eso, es más entrevistar a la gente tras ellos y saber qué ha sido de sus vidas, lo cual me parece más bien poco interesante. Aparte está la linea editorial de esta revista, en la que es buena idea poner dos páginas a todo color con un pantallazo de Atari o Comodore 16 (o algo con resolución similar), con pixeles enormes, y una triste columna de texto acompañando que, nuevamente, tampoco me dice nada; o hacer reportajes de juegos y plataformas que para mi no son nada retro (o es que soy ya bastante viejo). La verdad, mejor estoy releyendo la MicroHobby, que eso sí era una revista ;).

Hay 0 comentarios

29 de Mayo, 2015

El descenso a los abismos de SourceForge

Hace tiempo que SourceForge dejó de ser relevante; primero porque Google Code apareció como alternativa porque no es bueno tener todos los proyectos en el mismo sitio (volveremos a esto más adelante), y más tarde cuando otros sitios más modernos y con mejores herramientas aparecieron, como GitHub, BitBucket o Gitorious.

Resumiendo mucho, digamos que el modelo de negocio de SF siempre ha sido complicado, y finalmente tomaron la decisión de ofrecer a los proyectos la posibilidad de empaquetar open source con añadidos (que suelen ser basura que ni loco deberías instalar en tu máquina).

Bueno, es algo opcional, y salvo algunos proyectos (notablemente FileZilla, aunque seguro que hay otros), en realidad es tan irrelevante como el propio SF.

El problema viene cuando SF decide hacerse cargo de un proyecto abandonado (algo discutible, proyectos finales tienen poco mantenimiento y pueden pasar años sin nuevas versiones), concretamente GIMP-Win (que empaqueta y distribuye GIMP para Windows), y añaden un instalador que incluye esos añadidos^W^W basura; sin permiso del desarrollador.

Está explicado en esta entrada en la bitácora de SF, donde se excusan diciendo que ellos solo retomaron algo que estaba abandonado, como ya habían hecho antes con otros proyectos.

No es ilegal que distribuyan software libre con un instalador que añade programas de dudosa ética a nuestro sistema, siempre que cumplan con la licencia del software (en este caso GPL v3+); como otros portales de descagas vienen haciendo desde hace años. Me resulta difícil entender porqué alguien iría a Softonic o Downloads a bajar una copia reempaquetada y adulterada de un programa cuando el mismo proyecto ofrece una copia limpia para instalar (salvo excepciones como la mencionada de FileZilla; obviamente no puedo recomendar ese software).

Además la GPL impide que el autor y propietario de los derechos pueda invalidar la licencia, ni siquiera para un caso concreto como este, e impedir así que se sigua distribuyendo el programa de una forma que perjudica al proyecto original (en este caso GIMP).

Esto no es malo, al contrario, es esencial para que el software libre funcione: si el fabricante puede cancelar la licencia en cualquier momento y, por ejemplo, pedir una cantidad económica para continuar usando el software; ¡nadie usaría software libre!

Por ese motivo muchos proyectos registran una marca (el caso más conocido es quizás Firefox, propiedad de la Mozilla Foundation); que impide que estas cosas pasen, y si pasan... no será asociado al nombre del proyecto original.

Hubo un tiempo en el que SF era lo mejor para mantener open source gratis, y es dificíl de entender cómo han llegado a estos extremos y todo eso; pero es interesante tenerlo en cuenta especialmente ahora que todo va a parar a GitHub. Veremos qué nos depara el futuro.

Hay 0 comentarios, anotación clasificada en: software libre.

28 de Mayo, 2015

»Adiós a Fedora · Hace tiempo que evaluaba Debian 6.0 como alternativa a Fedora, porque los cambios que la distribución iba introduciendo no me convencían (aunque lo intenté bastante, ojo). Al final me he dado cuenta que no uso mucho de lo que se instala por defecto, ni me llama tanto contribuir (ese aspecto en la distro ha cambiado, pero eso es tema para otro momento), y ahora que Debian stable tiene software maduro (incluso más reciente que lo que vengo usando en Fedora 20, que se acerca su end of life), ha llegado la hora de cambiar; o más bien de volver a Debian.

Hay 0 comentarios, anotación clasificada en: fedora, software libre.

7 de Mayo, 2015

»pysdl2 fácil · No hace falta que introduzca SDL por aquí, pero sí recordar que SDL2 es bastante diferente, sobretodo porque soprta 2D con aceleración por hardware. Hay algunos módulos que permiten trabajar con SDL2 en Python, pero tienen interfaces poco pitónicos. En un par de días he llegado a algo funcional en pysdl2-harness, que son un par de clases para usar pysdl2 ocultando la parte fea de SDL, un poco como si fuera pyglet (pero mucho más sencillo).

Hay 0 comentarios, anotación clasificada en: sdl, python.

25 de Abril, 2015

Cuidado con los "fuses"

Los fuses (¿fusibles?) son 3 bytes de memoria permanente que determinan ciertas partes del comportamiento del microcontrolador.

Esta semana he estado trabajando con los ATtiny84, que es un microcontrolador de la subfamilia tiny de AVR. Es un MCU más pequeńo que el que viene con el Arduino Uno, y tiene algunas diferencias en cuanto a funcionalidad (ya hablaré de eso en otro momento).

Estos microcontroladores vienen de casa configurados para usar un oscilador RC interno a 8 MHz, pero tienen activado el flag CKDIV8 que divide por 8 la velocidad del oscilador, con lo que el MCU funciona a solo 1 MHz.

Como para mi proyecto quiero usar los 8 MHz (que además es una frecuencia soportada para 3v que puedes conseguir con dos pilas AAA), tengo que cambiar los fuses para desactivar ese flag.

Estoy usando un programador muy barato llamado USBasp que utiliza el interfaz SPI del microcontrolador sin la necesidad de un bootloader (como usa el Arduino), y nos deja disponible así toda la memoria para nuestro programa.

USBasp está soportado por avrdude, así que es bastante fácil reprogramar el MCU.

En primer lugar hay que usar la opción -B de avrdude a un valor de al menos 10 porque sino no será capaz de compunicarse con el MCU a 1 MHz.

Podemos confirmar que los fuses están como esperamos con:

avrdude -c usbasp -p attiny84 -P usb -v -B 10

Y cambiamos el low fuse para desactivar CKDIV8:

avrdude -c usbasp -p attiny84 -P usb -v -B 10 -U lfuse:w:0xe2:m

Muy fácil. A partir de ahora ya no es necesario usar la opción -B porque el MCU funcionará a 8 MHz.

La documentación del microcontrolador explica los fuses en detalle, pero hay que ir con mucho ojo porque podemos inutilizar el MCU (sin la ayuda del microcontrolador, USBasp es incapaz de programarlo).

Por ejemplo yo me equivoqué probando un cristal externo, confundiendo reloj externo con cristal externo; y no es lo mismo. De hecho no tengo un reloj externo y básicamente inutilicé el MCU porque no arrancaba sin el reloj :(.

Bueno, realmente no ;). Teniendo un Arduino a mano se puede generar una señal de reloj, lo que me permitió recuperar el microcontrolador y configurar los fuses correctamente.

Este es mi código de rescate:

// Generate a clock pulse with Aduino (digital port 5)
#define F_CPU	16000000

#include <avr/io.h>
#include <avr/interrupt.h>

int
main()
{
    cli();

    DDRD |= _BV(DDD5);

    TCCR0A = _BV(WGM00) | _BV(WGM01) | _BV(COM0B1);
    TCCR0B = _BV(CS00);
    TCNT0 = 0;
    TIFR0 = 0;
    OCR0B = 127;

    sei();

    while(1);
}

Ese código genera una señal de reloj en el pin 5 como la que espera el ATtiny84 configurado para usar un reloj externo, así que por esta vez... he podido salvar la situación fácilmente ;).

Hay 0 comentarios, anotación clasificada en: avr.

19 de Abril, 2015

»Reproduciendo audio · Todavía no me he decidido a soldar una de las placas, básicamente porque las de Elecrow están rotas, y las de OSH Park tienen un fallo (este sí es culpa mía). En teoría puedo meter una ñapa y todavía usar las de OSH Park, pero mientras me decido he estado revisando mi código para reproducir módulos de sonido con PWM (en el ejemplo ya con soporte para módulos de Impulse Tracker, porque uso Schism Tracker en Linux). Todavía es pronto, pero estoy pensando en el siguiente proyecto, que espero tenga menos componentes (no es que DAN64 tenga tantos, pero la placa no es tan sencilla).

Hay 2 comentarios, anotación clasificada en: avr, arduino.

6 de Abril, 2015

»DAN64 publicado · Ahora el proyecto tienene página web pública: DAN64, y el código está disponible en dan64 en GitHub. Todavía no he soldado una de las placas, pero como todo lo demás estaba listo, he decidido publicar versión (bueno, lo decidí ayer que era mi cumpleaños; pero entre una cosa y otra no he podido acabar hasta hoy :P).

Actualización: notas en the DAN64: a Minimal Hardware AVR Microcomputer (Hackaday) y Building a minimal 8-bit microcomputer with AVR (Atmel); entre otros. Parece que el proyecto ha gustado :).

Hay 1 comentario, anotación clasificada en: avr, arduino.

Entradas antiguas