ZX Spectrum – Cargando BASIC de manera personalizada (IV): compresión ZX7

AVISO: Hasta ahora, todo lo que he hecho se podía hacer tanto en una máquina real como con emuladores (yo he usado emuladores por comodidad). A partir de aquí, vamos a tener que hacer manipulaciones que van a involucrar obligatoriamente a un PC (aunque luego el resultado pueda usarse en un Spectrum normalito).

Ahora vamos a complicar algo más las cosas. Hay dos formas de reducir el tiempo de carga: acelerando la rutina de carga o haciendo el programa más pequeño. Ahora vamos a usar zx7 para poder hacer más pequeño el programa y que cargue más rápido. Para eso vamos a utilizar un compresor, en este caso el zx7.

La teoría es sencilla: puesto que nuestro BASIC es ahora una tira de bytes (CODE), lo comprimimos. Después debemos cargarlo y volver a descomprimirlo en su sitio (23552). El mayor problema de esta teoría es buscar un sitio para el BASIC comprimido: si no elegimos bien el sitio, puede que al descomprimirlo escribamos por encima de los datos comprimidos y la liemos. Os acordáis de que STKEND nos marca el lugar donde acaba el BASIC, ¿verdad? Pues este dato va a ser terriblemente importante, ya que no podremos meter los datos comprimidos por debajo de STKEND (bueno, en realidad vamos a dejar un poco más de espacio por si las moscas). De momento, hacemos MERGE “” a nuestro programa y ejecutamos PRINT PEEK 23653+256*PEEK 23654. A este resultado (en mi caso 52957) le añadimos unos 500 bytes para hacer sitio a la pila y otras cosas. Así que ahora modificamos la línea de grabación del programa:

9999 CLEAR 53499:
     LET STKEND=PEEK 23653+256*PEEK 23654:
     SAVE "basic" CODE 23552,STKEND-23500:
     CLEAR 65367: RUN 7600

Como he colocado el CLEAR muy bajo, voy a restaurarlo al valor por defecto antes de hacer el RUN (por si acaso el programa genera muchas variables y necesita mucha memoria). Hago el consabido GO TO 9999 y obtengo un bloque CODE para manipular a mi antojo.

Ahora vienen las cosas raras. Cogemos el tzx que acabamos de grabar y lo metemos al ZX Block Editor. Nos ponemos sobre el último bloque y pulsamos el botón derecho del ratón.  Elegimos Export as > Export as binary file y lo llamamos almacen.bin. En mi caso, he exportado un fichero de 29547 bytes con el BASIC de mi programa.

Ahora ejecuto zx7 almacen.bin y zx7 nos genera un fichero almacen.bin.zx7 que ocupa 7275 bytes, lo que es un ahorro bastante importante de espacio.

Mi plan es cargar esos datos comprimidos a partir de 53600, ya que entre 53500 y 53600 voy a poner la rutina de descompresión. Tiro de calculadora y veo que caben perfectamente en la memoria. Perfecto. Ahora viene la siguiente manipulación rara.

Abro ZX Spin y tecleo lo siguiente:

CLEAR 53499: SAVE "basic" CODE 53500,7275+100

Cuando me aparece el mensaje “Press REC & PLAY…” no pulso ninguna tecla (por llevar la contraria) y hago las siguientes cosas:

– Voy al menú Tools > ZX Assembler y tecleo lo siguiente:

org 53500
ld hl,53600
ld de,23552

Sin hacer nada más, abro el fichero dzx_standard.asm que se incluye en zx7, corto todo el texto y lo copio en la ventana del ZX Assembler.

Con todo ese texto en la ventana, voy al menú File > Assemble… y le doy a OK. ZX Spin me informa que ha ensamblado 75 bytes. Ahora voy a la ventana principal de ZX Spin y le doy a File > Load Binary File. En el cuadro de diálogo elijo mi fichero (almacen.bin.zx7) y como Start Address marco 53600.

Ahora que ya tengo los datos comprimidos en la memoria del Spectrum, pulso Enter y dejo que el bloque CODE se grabe. Para comprobar que el juego es ejecutable, hago un PRINT USR 53500.

Así que tengo ya un fichero CODE que contiene el BASIC comprimido y se puede ejecutar… vale, toca hacer el cargador BASIC. Esta vez será lo siguiente:

10 BORDER 0: PAPER 0: INK 0: CLEAR 53499
20 LOAD "" CODE
30 PRINT USR 53500

Una detalle interesante: si los datos comprimidos ocupan menos de 6000 bytes y no usáis pantalla de carga, podéis cargar tanto la rutina descompresora como los datos comprimidos en la memoria de pantalla. Haciéndolo así nos ahorraremos dolores de cabeza acerca de dónde poner el CLEAR y si el BASIC nos pisará los datos comprimidos.

Y los más avispados se preguntarán… ¿qué nos impide ponerle un contador o un turbo a este bloque de datos? Y después de meditarlo, la respuesta es… nada.

He incluido versiones con contador y turbo en la cinta, pero como ya he explicado cómo utilizar esas herramientas me reservo el derecho (o no) de explicarlo en otros artículos. La única precaución en estos casos es que el bloque comprimido no colisione con las rutinas de carga.

Enlaces interesantes:

  • Almacén Lunar: Todas las versiones de este programa.
  • ZX Spin: Mi emulador favorito, el que uso para todos los parcheos.
  • ZX7: Compresor para Spectrum. Hay descargas del compresor para PC y código fuente para las rutinas en ensamblador para descomprimir. Hay un hilo dedicado a este compresor en World of Spectrum.
  • ZX Block Editor: Completo programa para manipular ficheros de Spectrum.

ZX Spectrum – Cargando BASIC de manera personalizada (III): carga Turbo

Para esto emplearemos la rutina nanodrive de la Microhobby 65, mejorada luego en la revista 81. La rutina tal cual no me sirve (llamar a la rutina con DEF FN no es compatible con sobreescribir el BASIC). Así que después de depurarla un poco, vamos a ver qué es lo que no nos han contado los de Microhobby.

A la rutina se entra por 65170, e inmediatamente después empiezan a cargar datos desde el calculador. Una vez metidos en registros (65192) se comprueba si vamos a cargar o salvar, se pone el flag a 255 y se salta a la rutina correspondiente. Así que tenemos 3 puntos alternativos de entrada de los que no nos habían contado nada:

  • En la dirección 65192, es la entrada “general”. En IX ponemos el inicio del bloque, en DE la longitud y en A ponemos 0 para grabar y 1 para cargar. El flag siempre es 255.
  • En la dirección 65206 tenemos la rutina SAVE, y se aceptan los mismos parámetros que en la de la ROM.
  • En la dirección 65333 tenemos la rutina LOAD, y también acepta los parámetros de la ROM.

De momento, para hacer más genérica la cosa, entraré por 65192. Hago un pequeño parche de 12 bytes que cargue los registros como quiero y así no tengo que usar DEF FN:

org 65158
ld a,0
ld ix,23552
ld de,35083
jp 65192

Mi nueva rutina cargará a partir de 65158 y tendrá una longitud de 377 bytes. La voy a manejar con los siguientes POKEs:

POKE 65159,n: REM 0 para grabar, 1 para cargar
POKE 65162,ixl: POKE 65163,ixh: REM bytes bajo y alto del inicio del bloque
POKE 65165,del: POKE 65166,deh: REM bytes bajo y alto de la longitud

El resto de POKEs son los mismos que los publicados en el número 81, y mi rutina está ya modificada para ir a 3850 baudios. Una vez generada mi rutina modificada, tenemos que liarnos con dos cosillas:

– El CLEAR 65157.
– Guardar el BASIC como bloque turbo.

Así que nuestra nueva línea para grabar el juego será algo así:

9999 CLEAR 65157:
     POKE 65159,0:
     POKE 65162,0:POKE 65163,92:
     POKE 65165,PEEK 23653: POKE 65166,(PEEK 23654)-91:
     SAVE "nanodrvz" CODE 65158,377:
     PRINT USR 65158:RUN 7600

Esta línea solo funcionará si ya está cargada la rutina nanodrive en memoria.

Destripándola un poco, los tres primeros POKEs indican que voy a grabar desde la dirección 23552. No son necesarios porque la rutina nanodrive que hay en la cinta ya tiene esos valores puestos. Luego POKEo la longitud. Para ello copio los valores de STKEND, pero al byte alto le resto 91 (lo que hace que POKEe en realidad STKEND-23296), lo que me da un bloque que copia 256 bytes extra (por si las moscas). Por último, grabo la rutina nanodrive ya POKEada y el bloque turbo. Dos pequeñas cosas:

– Según las instrucciones de Microhobby, para que nanodrive grabe hay que pulsar la tecla 0.
– La mayoría de emuladores no pueden grabar bloques turbo a tzx. El único que he conseguido que funcione es el ZX Spin, pero no funciona automáticamente. Para que grabe el bloque turbo, hay que ir al menú Recording > Tape Recording > Start Recording. Utilizando esta opción, generará un bloque de tipo “Direct Recording” bastante hermoso… estoy investigando como convertirlo a un bloque turbo “normal”.

En cuanto al cargador BASIC, será algo de este estilo:

10 BORDER 0: PAPER 0: INK 0: CLEAR 65157
20 LOAD "" CODE: POKE 65159,1
30 PRINT USR 65158

…y con esto tenemos un BASIC turbo. Observad que no POKEo ni inicio ni longitud… en los pasos anteriores hemos grabado la rutina con estos datos ya incluídos. Lo único que meto es el POKE para que en vez de grabar, cargue.

Enlaces interesantes:

ZX Spectrum – Cargando BASIC de manera personalizada (II): cuenta atrás

Ahora empezamos a ponerle cosas “raras” a nuestro programa, y como vamos a grabar el juego un montón de veces voy a utilizar la variante de Crash (para no tener que escribir un montón de veces las instrucciones de grabación). Ya sabemos cómo cargar un BASIC como CODE, se lo podemos servir en bandeja a diferentes rutinas de carga. Empezaremos por una de las fáciles: la rutina de carga con contador publicada en Microhobby en el número 191.

Leyendo las instrucciones, vemos que no hay muchas cosas que hacer… hacemos un CLEAR, cargamos la rutina en 64768, la pokeamos un rato (si queremos) y la ponemos a cargar un bloque CODE con USR 65313. Aquí hay un cambio con lo que hemos hecho antes: no creo que sea buena idea cargar nuestro bloque de datos con un CLEAR modificado. Así que (por si las moscas) vamos a grabar nuestro basic con un CLEAR 64767. Lo ponemos en la línea 9999, de forma que quede así:

9999 CLEAR 64767:
     LET STKEND=PEEK 23653+256*PEEK 23654:
     SAVE "basic" CODE 23552,STKEND-23500:
     RUN 7600

Además, es muy mala idea modificar las variables del sistema, por lo que un RANDOMIZE USR 65313 no es aconsejable. Podemos poner PRINT USR, que no toca las variables del sistema y no nos dará problemas. El cargador nos quedaría así:

10 BORDER 0: PAPER 0: INK 0: CLEAR 64767
20 LOAD "" CODE: PRINT USR 65313

Salvamos nuestro cargador, salvamos la rutina de Microhobby y después salvamos nuestro BASIC usando el GO TO 9999. Ya tenemos nuestro programa grabado con contador.

Enlaces interesantes:

ZX Spectrum – Cargando BASIC de manera personalizada (I): BASIC como CODE

Este es un mini-tutorial casero sobre cómo hacer que programas BASIC carguen de maneras “raras”.

Esto no es un tutorial sobre protecciones (hay cientos), aunque indirectamente se impida hacer un MERGE “”, y a estas alturas de la historia tampoco recomendaría proteger un juego de Spectrum. Simplemente, es para hacer el chulo. Si vas a usar algunos de estos trucos, te recomendaría que guardes una copia desprotegida; también estaría bien que dejes que otra gente espíe tus proyectos y pueda aprender de ellos.

No soy un especialista en programación, así que para todos estos ejemplos he pillado rutinas publicadas en revistas o internet (además, no tiene sentido reinventar la rueda). Por eso no hay una rutina con contador y turbo a la vez… es que básicamente no la he encontrado y no me veo capaz de desarrollarla.

Empecemos…

¿Qué es lo que necesitamos?

Aunque hay muchas rutinas que pueden hacer cargas no estándar para juegos en código máquina, no hay ninguna que lo haga para juegos en BASIC. ¿Por qué? Pues se me ocurren un montón de razones, pero la primera de todas es que no hacen falta. El BASIC acaba siendo también una secuencia de bytes en memoria, así que puede ser también grabado como CODE, y todas las rutinas no estándar aceptan bloques CODE.

Por supuesto, la cosa no es tan sencilla (aunque tampoco es mucho más complicada). Para hacer funcionar un programa BASIC, el Spectrum necesita saber una serie de cosas, como la longitud del BASIC, las variables, cuál es la siguiente instrucción a ejecutar… cuando cargas un bloque con LOAD “”, estos datos los va rellenando con lo que se encuentra en la cabecera; cuando cargas con LOAD “” CODE se limita a meter las cosas a martillazos en memoria. Afortunadamente, si has cargado el juego de una manera normal, el Spectrum ya conoce estos datos y los tiene en memoria. Todo esto está bien guardadito en el área de variables (dirección 23552 en adelante). Teniendo en cuenta que después del área de variables viene el BASIC en sí, podríamos empezar a grabar desde ahí y no tendríamos problemas.

Lo que no vamos a necesitar es la memoria de pantalla (aunque luego podrías querer poner una pantalla de carga), el buffer de impresora (esto es MUY importante… en los 128k esto puede hacer que casque el equipo), la pila (de nuevo: peligro de bloqueo/reseteo) y los UDG (la mayor parte de las veces se generan en el BASIC).

Nuestro juego de prueba va a ser el “Almacén Lunar”, publicado en la Microhobby número 100 (y la cinta correspondiente de Microhobby Semanal). ¿Por qué este juego? Pues principalmente, porque es un juego bastante hermoso (unos 30k) escrito únicamente en BASIC, tiene autorun en la línea 7600 y además me tocó los cojones intentando depurar un error (al final lo resolvió NeilParsons del Proyecto BASIC ZX). La versión que voy a utilizar está modificada (ver línea 7601) para funcionar en un 128k, por lo demás es la misma.

Grabando BASIC como CODE:

Ya sabemos dónde debemos empezar a grabar (23552), así que ahora queda averiguar cuánto debemos grabar. A partir de aquí tenemos dos alternativas: la mía y la publicada en Crash (número 34). La diferencia es que la mía no deja “restos” en el programa BASIC, y la de Crash necesita incluir una línea BASIC especial.

Empecemos por la teoría. Como he dicho antes, el Spectrum guarda en el área de variables un montón de datos, entre ellos la dirección de inicio del BASIC, de las variables, de la línea de comandos, del calculador… si sabemos qué viene detrás del BASIC (vale, son las variables, pero también podemos querer grabarlas), podemos hacer un bloque CODE que empiece en 23552 y acabar en la última dirección “interesante”.

La revista Crash sugiere añadir esta línea al programa:

9999 LET STKEND=PEEK 23653+256*PEEK 23654:
     SAVE "basic" CODE 23552,STKEND-23500:
     RUN 7600

En este caso, utilizan la variable del sistema STKEND para calcular el tamaño del programa. Esta variable marca el inicio de la memoria “libre” del Spectrum.  Al ejecutar un GO TO 9999, se grabará todo el BASIC como CODE. Dos observaciones acerca de esto:

  • Como grabamos todas las variables del sistema incluyendo la línea e instrucción que se está ejecutando, al terminar de cargar ejecutará ese RUN 7600 y lanzará el programa.
  • El autor del truco ha grabado un cacho más (concretamente 52 bytes) de lo que necesitaba. Creo que aquí no es necesario, pero tampoco hace daño.

Mi variante es algo más basta e implica el uso de la variable K_CUR (23643) que indica la posición de memoria del cursor. Si estás metiendo una instrucción, eso apuntará a la línea de instrucciones, pasados el BASIC y el área de variables del BASIC.

Así que cargamos el juego con MERGE “” y ejecutamos PRINT PEEK 23643+256*PEEK 23644. En mi caso, el Spectrum me devuelve 52908. Así que la longitud de lo que voy a grabar será 52908-23552+50 (para hacer sitio a mi línea de comandos). Eso da un resultado de 29406. En este caso sí que debo grabar más datos de los necesarios, ya que en la cinta van a ir el BASIC y la línea de comandos.

Así que ahora hago un SAVE “basic” CODE 23552,29406: RUN 7600 y obtendré un bloque CODE que luego puedo cargar sin problemas.

El método de grabación es lo de menos. Por lo general os diría que usáseis el publicado en Crash (por si tenéis que hacer muchas pruebas). En cuanto al cargador, eso va a ser muy sencillo:

10 BORDER 0: PAPER 0: INK 0: CLS
20 LOAD "" CODE

NOTA: Otra variante sin cálculos tan complejos es hacer un SAVE “basic” CODE 16384,49152: RUN 7600. Este método lo veo muy desaconsejable ya que váis a grabar toooda la RAM ocupando innecesariamente espacio en cinta (y alargando el tiempo de carga). Además, luego no quedará espacio para meter otras cosas, como cargas turbo o compresores.

Enlaces interesantes:

  • Almacén Lunar: El fichero conteniendo todas las versiones de este programa.

Instalación DNI electrónico en Debian 5.0 AMD64

Bueno, parece que el DNI electrónico está dando algún que otro problemilla al instalarse… de hecho, no he encontrado equipo ni en Windows ni en Linux que funcione tras haber seguido por completo la guía del gobierno. En este caso, la instalación se va a realizar sobre una Debian 5.0 AMD64, pero para la distribución de 32 bits el procedimiento debería ser parecido. Para empezar, necesitaremos dos ficheros de la web oficial (http://www.dnielectronico.es):

  • Los módulos criptográficos para Debian/AMD64. Se encuentran en el Área de descargas > Sistemas GNU/Linux y MacOS > Software para las distribuciones Linux > opensc-dnie_1.4.6 > Arquitectura_64bits > Debian_Lenny-64bits.
  • El certificado raíz de la policía. Está en Área de descargas > Certificados x509 > AC Raíz y bajamos el certificado sha256.

Una vez que los tengamos, el procedimiento de instalación sería algo así:

  • Lo primero, se descomprime en un directorio temporal el certificado raíz y los módulos criptográficos:
    unzip ACRAIZ-SHA2.zip
    tar -xvf Debian_Lenny_opensc-dnie_1.4.6-2_amd64.deb.tar
  • Instalamos pcscd y libltdl3. Sus dependencias instalarán la mayoría de los paquetes que nos harán falta, y además el lector no parece funcionar sin pcscd (esto NO viene mencionado en la guía de instalación).
    apt-get install pcscd libltdl3
  • Después, borramos (si hubiera) otros módulos de opensc. Esto es muy importante, ya que los paquetes más modernos no funcionarán.
    apt-get --purge remove libopensc2 opensc opensc-dnie
  • Procedemos a la instalación de los módulos criptográficos mediante dpkg.
    dpkg -i libopensc2_0.11.7-7_amd64.deb
    dpkg -i opensc_0.11.7-7_amd64.deb
    dpkg -i opensc-dnie_1.4.6-2_amd64.deb

Después de esto, el lector debería ya estar operativo.  Lo podemos confirmar usando opensc-tool -l (para que nos liste los lectores instalados) y opensc-tool --reader (nos dará el número de serie del DNI electrónico). Si en algún paso da error, es que alguno de los paquetes no está instalado. Los errores que he visto yo han sido causados por no tener instalado pcscd y porque las versiones de opensc no son las debidas (me sigo preguntando por qué no funcionan las más recientes).

Como hemos visto al instalar opensc-dnie, se nos indica que ejecutando cierto programa Firefox estará ya preparado para operar con el lector. Ni caso. Es una mentira más, no me ha funcionado nunca. Los pasos para que Firefox funcione son los siguientes:

  • Instalar el certificado de la policía. Iniciamos Firefox y vamos a Editar > Preferencias > Avanzado > Cifrado > Ver Certificados. Ahí elegimos Autoridades y pulsamos sobre el botón de Importar. Elegimos el fichero .crt que hemos conseguido, marcamos todas las casillas de la ventana que aparece y le damos a Aceptar. En la lista de autoridades debería aparecer una entrada de la DIRECCION GENERAL DE POLICIA. Cerramos el administrador de certificados.
  • Instalar el módulo criptográfico. En la misma pestaña de Cifrado, pulsamos sobre el botón Dispositivos de seguridad y sobre el botón Cargar. En nombre del módulo escribimos DNI electrónico, y en archivo del módulo elegimos /usr/lib/opensc-pkcs11.so (o lo buscamos con el navegador). Aceptamos todo y reiniciamos el navegador.

Si todo ha ido bien, la siguiente vez que vayamos al administrador de certificados nos pedirá el PIN del DNI electrónico. Una vez introducido, podremos ver en la lista de certificados los dos certificados asociados a nuestro DNI. Ya solo quedan los últimos detalles.

Para que todo esto funcione, le hemos suministrado unos paquetes con unas versiones muy concretas de opensc y libopensc2. Cuando actualicemos la distribución, va a intentar actualizar esos paquetes, con lo que el DNI electrónico dejará de funcionar. Para evitarlo, debemos bloquear esos paquetes. Un método como cualquier otro es soltarle estas tres instrucciones:

  • echo libopensc2 hold | dpkg --set-selections
  • echo opensc hold | dpkg --set-selections
  • echo opensc-dnie hold | dpkg --set-selections

Esto evitará que apt-get actualice los paquetes. En caso de que se publiquen nuevas versiones, bastará con bajarlas de la página oficial e instalarlas con dpkg (aunque no sé si al hacerlo se retirará la marca de “hold” de los paquetes).

Compilando parcialmente el kernel de linux

Esta semana he estado maldiciendo un poco mi suerte con los gamepad. Después de la muerte súbita de dos cacharros, he estado haciendo experimentos con la vibración… para darme cuenta de que pocos dispositivos la soportan. Los dispositivos logitech están bastante bien soportados, pero personalmente me parecen blandurrios, y no creo que vuelva a comprar ninguno.

Así que mangoneando un poco en los fuentes del núcleo, vi que hacer la modificación para que mi gamepad estuviera soportado era fácil (al fin y al cabo, hay un fichero que casi los controla… sólo hace falta añadir mis dispositivos). El problema vino después cuando quise compilar mis cambios. Lo que yo quería hacer era:

  • Compilar únicamente los módulos modificados, o la rama correspondiente.
  • Compilar los módulos contra el kernel instalado en mi equipo… un kernel Debian de serie (así mis modificaciones podrían servir para otros equipos sin recompilar).

Los módulos que quería modificar pertenecían a la parte que lleva el HID. El procedimiento que he seguido ha sido el siguiente:

  1. Bajar las fuentes del kernel actual y descomprimirlas
  2. Ir al directorio de las fuentes
  3. Copiar el fichero de configuración del kernel actual (habitualmente en /boot; en mi caso cp /boot/config-2.6.29-2-amd64 .config ).
  4. Copiar la información de símbolos de los módulos ( cp /lib/modules/2.6.29-2/build/Module.symvers . ).
  5. Obtener la versión del núcleo y modificar Makefile para que sea igual a la del instalado.
  6. Preparar la compilación de los módulos (make prepare ;  make prepare_modules)
  7. Compilar los módulos elegidos. Se hace con make M=(modulos)

Hay que tener en cuenta que sólo los pasos 1, 2, 6 y 7 son necesarios si el kernel que se ha compilado es “propio”. Los pasos 3, 4 y 5 son necesarios para asegurarse de que los módulos correrán en el mismo kernel que tiene en ese momento la máquina. Es útil cuando se recompilan módulos en una máquina que no se puede reiniciar, o se compilan módulos para distribuir a otros equipos.

También hay que tener en cuenta que en algún lugar entre el paso 2 y el 3 se deberían haber editado/parcheado los ficheros que queremos modificar. En mi caso, las instrucciones fueron las siguientes (marco a qué paso corresponde cada una):

  • 1) apt-get install linux-source-2.6.30
  • 1) cd /usr/src
  • 1) tar -jxvf  linux-source-2.6.30.tar.bz2
  • 2) cd /usr/src/linux-source-2.6.30
  • 3) cp /boot/config-2.6.30-1-amd64 .
  • 4) cp /lib/modules/2.6.30-1/build/Modules.symvers .
  • 5) uname -r
  • 5) nano Makefile (más acerca de esto abajo)
  • 6) make prepare
  • 6) make prepare_modules
  • 7) make M=drivers/hid

Acerca de la edición del fichero Makefile:

El fichero Makefile debe ser editado para que la versión sea idéntica a la de nuestro kernel (o el módulo no se cargará). Esto es importante porque muchas distribuciones (Debian, RedHat y compañía) suelen añadir “sufijos” a sus versiones propias del kernel. El comando uname -r nos dará la versión completa del kernel. En el caso de mi Debian, uname escupió (atentos al coloreado, que es importante):

2.6.30-1-amd64

En esta versión coloreada, podemos ver los tres números principales de versión del kernel (rojo, verde y fucsia) y, sobre todo, la información extra del kernel (azul). Esta es la que varía de distribución a distribución. Al editar Makefile, veremos que comienza con las siguientes líneas:

VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 30
EXTRAVERSION =
NAME = Man-Eating Seals of Antiquity

Nuestra labor será alterarlas para que la versión coincida completamente. Esto significa dejar el Makefile de esta manera:

VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 30
EXTRAVERSION = -1-amd64
NAME = Man-Eating Seals of Antiquity

Con esto y un poco de suerte, la compilación parcial debería realizarse correctamente. En caso de que los módulos no carguen, dmesg nos dará una razón (probablemente algún problema con la configuración o versión). Si los módulos se compilan y se insertan bien, pero no se comportan como deberían (vamos, que las modificaciones que se les habían hecho no son buenas), para recompilar habría que repetir únicamente el paso 7.

Una de virtualización

Llevo varios días viendo a los usuarios de cierto website bastante meneados con el tema de la virtualización. Aunque la virtualización es un gran invento de moda en centros de proceso de datos (por sus ventajas en redundancia, facilidad de instalación y potencia), estos usuarios se dedican a utilizar máquinas virtuales para utilizar programas (léase: juegos) viejos. Parece que los sistemas operativos antiguos deberían ser más fáciles de virtualizar (menos recursos y todo eso), pero es todo lo contrario.

Así que aquí empieza una serie de artículos sobre virtualización de sistemas operativos viejos. Pero ¿qué es una máquina virtual? Una máquina virtual es un emulador de un ordenador completo (guest) dentro de otro equipo (host). Es decir, el ordenador tendrá su propio disco duro, su propia tarjeta de video, su propia memoria y lo que pase dentro de él estará contenido dentro de esos elementos (y, al menos en teoría, no debería afectar al resto de cosas que corren en el host).

En centros de datos, tiene una serie de ventajas ya comentadas, en un ordenador de sobremesa puede servir para ejecutar diferentes sistemas operativos (un Windows 95 dentro de un Linux) o, dado que son máquinas contenidas, poder hacer burradas y pruebas en una máquina virtual que no nos atrevemos a hacer en una real (si la cosa va realmente mal, copiamos otra vez los archivos de la máquina virtual y la tenemos como al principio).

Programas para virtualizar hay bastantes, pero aquí voy a comentar únicamente 4 entornos que son con los que, en principio, trabajaremos.

  • VMWare: Hoy en día es el “rey” de la virtualización. Es un programa maduro, estable y con infinidad de versiones para cubrir las necesidades desde curiosos hasta grandes empresas. Las versiones de mayor interés sería la VMWare Server, que es gratuita y no está limitada para un usuario normal. Funciona en entornos Windows y Linux. Las ventajas son su gran soporte de sistemas y su inconveniente sería que es algo perezosa con sistemas sin drivers de video (por ejemplo, DOS o Linux trabajando en consola).
  • Virtualbox: Aspira a ser el otro gran referente de la virtualización. Viene en dos sabores: Virtualbox “normal” y Virtualbox-OSE (Open Source Edition), que sería una versión totalmente libre. También funciona en Windows y en Linux. Sus ventajas son un mejor manejo de video en guests Windows 2000 y posteriores, y mayor velocidad en sistemas no soportados directamente. Sus inconvenientes son que no tiene herramientas para Windows 9x/Me, y que el soporte de USB es bastante “raro” (una de las diferencias entre la versión normal y la OSE es que OSE no soporta USB).
  • DOSBox: Este programa no es una máquina virtual, sino un simulador muy completo de MS-DOS. Si vas a ejecutar juegos de MS-DOS, es la primera y mejor opción. Funciona en Linux, Windows, Mac, teléfonos móviles… Las ventajas son su especialización que le permite ejecutar las aplicaciones a toda velocidad y una mejor emulación de video y audio; las desventajas son su especialización que no le permitirá ejecutar ningún otro sistema operativo, que no todas las aplicaciones funcionan (prefieren que funcionen los juegos) y que no permite usar la red libremente (aunque emula IPX sobre TCP/IP para que varios DOSBox puedan jugar a juegos en red).
  • Wine: Este ni es una máquina virtual ni un emulador, sino un “wrapper” que se dedica a ejecutar programas Windows en máquinas Linux. Es la primera opción si sólo se quiere ejecutar un programa de Windows, pero si no funciona en Wine, lo mejor es utilizar una máquina virtual real. Tiene una base de datos de compatibilidad muy completa, que da mucha información a la hora de configurar las aplicaciones. Sus ventajas son que es muy rápida y que no hay que esperar a que arranque el sistema emulado completo para ejecutar programas; sus desventajas son que no podrá ejecutar nada que no sea Windows.
  • Otras aplicaciones de virtualización y emulación: hay otras que no menciono, porque son bastante más complejas de instalar (bochs, qemu), tienen menor compatibilidad (dosemu) o directamente no puedo ejecutarlas (Parallel Desktops sólo corre en Mac). De todas formas, en los siguientes artículos se trabajará básicamente con DOSBox o con Virtualbox (son las que utilizo actualmente).

En próximas entregas, iré comentando procedimientos de instalación de sistemas en estas máquinas.