Pasmo: un ensamblador cruzado para Amstrad CPC

Me he animado a continuar con una pequeña serie sobre algunas cosas que he probado con el emulador de Amstrad CPC, por pura diversión. Esta entrada está dedicada a la instalación y uso de pasmo un ensamblador de Z80 creado por Julian Albo que nos va a permitir generar programas para usar en cualquier emulador de Amstrad CPC. Se instala en cualquier Unix de manera sencilla:

$ wget http://pasmo.speccy.org/bin/pasmo-0.5.4.beta2.tgz
$ tar zxvf pasmo-0.5.4.beta2.tgz
$ cd pasmo-0.5.4.beta2
$ ./configure --prefix=/usr/local
$ make
$ su
# make install

pasmo es un macro ensamblador que nos permite generar ficheros de código máquina en multitud de formatos de antiguas máquinas de 8 bits. Su sintaxis es muy similar al clásico de los 80 GEN3 de Hisoft. Permite macros, definiciones o ensamblado condicional. La documentación está en el fichero HTML pasmodoc.html.

Ensamblar un fichero es muy sencillo. Luego lo podemos transferir a nuestra imagen de disco y montarla en el emulador para ejecutar el programa que hemos ensamblado.

$ pasmo --amsdos mode.asm mode.bin
$ cpmcp imagen.dsk 0:mode.bin

El contenido del fichero mode.asm es un sencillo programa que se carga en la dirección #A000 e imprime el mensaje esto es una prueba

org #A000
        LD HL, MENSAJE
LOOP:   LD A, (HL)
        OR A
        RET Z
        PUSH HL
        CALL #BB5A
        POP HL
        INC HL
        JP LOOP
MENSAJE: DEFM 'Esto es un mensaje de prueba',0

Para cargarlo desde BASIC

MEMORY &9FFF
LOAD "mode.bin",&A000
CALL &A000

Crear imágenes de disco de Amstrad

Más allá del hacking value o de cierta nostalgia de otros tiempos no tiene mucho sentido andar enredando con emuladores de máquinas con micros de 8 bits, que funcionaban a 4 Mhz y tenían 64 o 128 Kb de memoría de RAM, con suerte un disco de 3" o 3.5" y lo más normal un magnetófono de cintas de cassete como medio de almacenamiento. El Amstrad CPC 6128 fue el primer ordenador que tuve. Me lo compraron en las Navidades de 7º de EGB. Junto al mismo, mi padre - sin saber muy bien lo que hacía, sospecho - compró el libro de Código máquina para principiantes con Amstrad de Steve Kramer. Con los años fui aprendiendo, programé algunas cosillas con BASIC y ASM, desemsabléa las ROMs, aprendí algo (poco) sobre el hardware, enredé con CP/M y me divertí bastante con multitud de juegos de la plataforma - sacando también de quicio a mis padres por el camino -. Todo un cóctel que me llevaría a mi actual mundo profesional.

A mis más de cuarenta años, me gusta de vez en cuando, en vez de un partidad a la PS3 , un X-Plane o algún juego de rol online, lanzar el Arnold en el Mac y disfrutar de alguna partitida a algún viejo clásico. En ello estaba, cuando hace unos días pensé, ¿me acordaré de algo de ensamblador de Z80?. ¿De como se programaba la máquina?. Me animé a buscar información y lo primero que me planteé es, ¿se puede trabajar en "cruzado" con las herramientas corriendo nativas en el Mac y luego subiendo al CPC?. Pues la respuesta es sí, por un lado pasmo un ensamblador de Z80 capaz de generar ficheros ejecutables para múltiples plataformas y por otro libdsk y cpmtools que me iban a permitir generar las imágenes que necesito. Esta entrada la voy a centrar, precisamente, en la generación de imágenes. Para ellos necesitamos sólo libdsk y cpmtools. Se compila la primera, se compila la segunda y ya tenemos una serie de programas que nos permiten crear imágenes y acceder a la mismas.

El primer paso es compilar libdsk:

$ wget http://www.seasip.info/Unix/LibDsk/libdsk-1.2.2.tar.gz
$ tar zxvf libdsk-1.2.2.tar.gz
$ cd libdsk-1.2.2
$ ./configure --prefix=/usr/local
$ make
$ su
# make install
# exit

El siguiente paso es compilar cpmtools, pero le vamos a indicar que utilice las librería que hemos compilado en el paso anterior

$ wget http://www.moria.de/~michael/cpmtools/files/cpmtools-2.20.tar.gz
$ tar zxvf cpmtools-2.20.tar.gz
$ cd cpmtools-2.20
$ ./configure --prefix=/usr/local --with-libdsk --with-defformat=cpcdata
$ make
$ su
# make install
# exit

El Amstrad CPC 6128 podía manejar 3 formatos de datos: De sisytema CP/M 3.0, de sistemas CP/M 2.2 y de datos. La diferencia estaba en la reserva de dos pistas en cada cara del disco para el cargador de arranque del sistema y otras propiedades (CP/M 3.0) o para el propio sistema operativo (CP/M 2.2). Además, en el caso del Amstrad, los ficheros podían residir en diferentes areas de usuario, indentificadas por un entero entre 0 y 15 - esto es herencia directa de CP/M -. Decir que por defecto, el CPC sólo es capaz de usar una cara de un disco, aunque el controlador de disco que utilizaba , el NEC 765, el mismo que el de un PC, podía manejar unidades de dos caras simultáneamente sin problemas.

Para crear una imagen de disco de CPC lo único que tenemos es que usar el programa dskform de las libdsk para que nos cree el mismo. Si quiero usar el formato de datos, la orden para generarlo sería la siguiente.

dskform -format cpcdata imagen.dsk

cpmtools instala varias utilidades para manejar ficheros dentro de las imágenes que creemos. En nuestro caso nos interesa las siguientes.

cpmls

Muestra los ficheros que hay en la imagen.

cpmrm

Permite borrar ficheros de la imagen.

cpmcp

Permite copiar ficheros a la imagen.

Por defecto todas estas utilidades están compiladas para usar el formato de datos del Amstrad CPC. Si fuera necesario usar otro, todas admiten el parámetro -f para indicar el formato que se desea usar (usando --help a cualquiera de ellas muestra la lista de formatos soportados).

Copiar un fichero y posteriormente borrarlo se haría con las siguientes órdenes.

$ cpmcp imagen.dsk text.bin 0:text.bin
$ cpmrm imagen.dsk 0:text.bin

Es necesario especificar el área de usuario a la hora de copiar com cpmcp (la que usa el sistema por defecto siempre es la 0). cpmcp no sobreescribe archivos, es necesario borrarlo antes con comrm

Las cuentas gestionadas de gmail y API de auditoría.

Uno de los servicios que ofrece Google para empresas es el correo electrónico. Este se lleva a cabo a través de las llamadas cuentas gestionadas de Google. El administrador de un dominio de este tipo tiene acceso a toda la información que existe en las cuentas que gestiona. Eso incluye acceso a todos los buzones de correo. Pero lo más curioso de todo este tema es que Google pone a disposición de los usuarios de estos servicios un API que permite auditar el correo. Un simple conjunto de llamadas permite obtener toda la información que se quiera de las mismas. Lo interesante es que este API permite establecer monitores que vayan analizando y almacenando los correos que se deseen durante el periodo que se programe.

Ojo, no vayamos a pensar que esto es exclusivo de este tipo de cuentas. Cualquier máquina Unix puedes hacer un grep sobre los ficheros almacenados de correo, en el tradicional /var/spool/mail o Exchange permiten al usuario administrador leer todo el correo del usuario que sea.

Esto no es más que un simple recordatorio de la privacidad que ofrecen todos los sistemas de correo

Imaginando un cisne negro: El cierre repentino de Google

Con todo el escándalo organizado por el trucaje de las emisiones de lo coches diesel de Volkswagen y la pérdida de casi un tercio de su capitalización hasta el punto de poder poner en peligro la viavilidad de la compañía, me ha dado por hacer un poco de ciencia ficción y plantearme el siguiente escenario:

Google se ve envuelto en un gran escándalo - del tipo que sea - que hace que pierda su capitalización bursatil en apenas una semana, situándose financieramente al borde de la bancarrota en cuestión de días.

¿Es disparatado ese escenario?. Probabemente, pero después de ver lo que le pasó British Petroleum tras el accidente de su plataforma en el golfo de Méjico, donde en cuestión de dos meses perdió el 40% de su capitalización bursátil y tuvo que vender activos para poder obtener liquidez y hacer frente a todas las consecuencias del vertido.

Imaginad que a una semana vista, deja de funcionar Gmail, Youtube o el buscador de Google. Bien, me podéis decir que hay alternativas a todos esos servicios, con mayor o menor uso (Yahoo, Bing), pero sinceramente, no es lo más importante. Google se ha convertido en muchos aspectos en una utility, es decir una empresa que da servicios relativamente básicos a otros en Internet: Autentificación, Hosting, medidas de tráfico,... Y multitud de empresas han montado sus servicios entorno a Google, en especial en cosas tan críticas como la autentificación - ya que Google permite tener todo centralizado en una única cuenta. No es la primera vez que una empresa que monta su negocio usando ciertos servicios que daba Google se encuentra con la desagradable sorpresa de que el servicio cierra porque Google no es capaz de monetizarlo o no le interesa. Ahora, imaginad las consecuencias de un escenario donde se plantee el cierre de Google. ¿Esto no va a ocurrir nunca?. Probablemente jamás ocurra. Es un tail event, un cisne negro.

Aunque el futuro de los próximos años parece que será la nube, no dejemos de tener en cuenta dos ideas claves:

• La nube no existe, existe el ordenador de otra empresa donde tenemos nuestra lógica de negocio.
• Si dependemos de servicios de terceros para nuestros negocios, siempre tener pensando un posible plan B. No sólo tenemos que hacer copias de seguridad de nuestros datos, sino evaluar todos los riesgos de que nos pasaría si un proveedor fallara.

Si ocurriera, ¿deberían los gobiernos rescatar a Google o nacionalizarlo? .... Buena pregunta después de todo lo visto estos años con la crisis financiera, la banca y multitud de empresas.

Debian Jessie: Deshabilitar startpar

Una de las nuevas características de Debian Jessie es el uso del sistema de arranque systemd. Uno de los objetivos de systemd es > es paralelizar al máximo el arranque del sistema para que este sea lo más rápido posible¹. Systemd es un conjunto de programas exclusivos de Linux ya que usan ciertas llamadas al sistema que sólo están disponibles en él.

La existencia de systemd no elimina la necesidad de scripts da arranque, ya sea de programas heredados o bien porque hay programas que prefieren usar estos scripts de arranque que facilitan la portabilidad entre sistemas Unix. En Jessie, los scripts de arranque siguen estando en /etc/init.d y el concepto de runlevels sigue existiendo, sólo que ahora lo maneja systemd. Para ejecutar de manera simultánea varios scripts de arranque existe la utilidad startpar. Se supone que los scripts se han escrito de acuerdo a las Linux Standard Base para que puedan declarase las dependencias de manera correcta y startpar pueda ejecutar los mismos paralelizando al máximo y sin problemas de interdepencias entre ellos.

Sin embargo, esto no siempre es así y puede que en un momento dado sea necesario desactivar esta capacidad de arranque en paralelo para corregir problemas que se presenten en el sistema. En Debian es muy fácil realizar desactivarlo creando un fichero:

touch /etc/init.d/.legacy-bootordering

Para volver a disponer del arranque en paralelo de los diferentes scripts, simplemente borramos el fichero anterior

rm /etc/init.d/.legacy-bootordering

Notas

1. Una pequeña maldad: ¿De verdad la gente apaga y enciende el sistema, en especial portátiles y sistema de escritorio o simplemente lo hiberna?.

Repositorio con el código fuente de Unix los últimos 44 años

Diomidis Spinellis ha realizado un inmenso trabajo de recopilación del código fuente de Unix desde su concepción y primera versión en 1972 en Bell Labs hasta el actual FreeBSD 10.x. Las versión está ordenadas en el proyecto Unix History Repository en github. Toda una delicia para aquellos que quieran estudiar el origen Unix. El autor del mismo ha publicado un artículo titulado A Repository with 44 Years of Unix Evolution describiendo el proceso de creación del mismo. Tiene un gráfico muy chulo donde se puede ver la relación de las diferentes versiones.

En este repo no está incluido Linux - que es un clon de Unix - ni los sistemas Unix que derivaron de System V. Ah, ojalá Microsoft hiciese lo mismo con Windows, al menos sus versiones antiguas :)

tmutil: Controlar Time Machine desde la línea de comandos (I)

Introducción

Time Machine es una funcionalidad de copias de seguridad incluida en MacOS X desde la versión 10.5 (Leopard). Permite realizar las copias de seguridad tanto a discos duros locales o a sistemas compartidos en red compatibles con el software. Normalmente se controla desde la interfaz gráfica, pero existe una utilidad de línea de comandos que permite su control.

En el caso de Time Machine, la herramienta de línea de comandos que se encarga del control de las copias de seguridad es tmutil. Normalmente, este comando necesita ejecutarse con permisos de superusuario para realizar su función.

La estructura del comando es la siguiente

tmutil comando [parametros]

Manejo de los discos donde se van a realizar las copias de seguridad

El primer paso que hay que dar para poder utilizar Time Machine es configurar los volúmenes donde se van a realizar las copias de seguridad. Si tenemos un que está montado en /Volumes/My Passport y lo queremos usar para copiar de seguridad, se añade al sistema con el comando setdestination -a path donde en nuestro ejemplo path es /Volumes/My Passport. Con ayuda del comando destinationinfo se pueden ver los volúmenes que están añadidos. El comando destinationinfo permite el uso del argumento -X que vuelca la información en formato XML plist.

root#tmutil  setdestination  -a "/Volumes/My Passport"
root#tmutil  destinationinfo
> ==================================================
Name          : Backups
Kind          : Local
Mount Point   : /Volumes/Backups
ID            : C54F9BEE-AE4F-4E7B-BD9E-6AA18CDD3F83
====================================================
Name          : My Passport
Kind          : Local
Mount Point   : /Volumes/My Passport
ID            : 1044185E-607C-45A6-A5C2-E96BD7C0D836

De la información que vuelca destinationinfo hay dos puntos importantes:

• Cada volumen usado como copia de seguridad está identificado por un uuid único.
• Se utiliza > para señalar cual ha sido el volumen donde se ha intentado realizar la última copia de seguridad del sistema en el caso de que haya varios volúmenes disponibles. En el ejemplo anterior puede verse que que el disco con ID C54F9BEE-AE4F-4E7B-BD9E-6AA18CDD3F83 es el último donde se ha realizado dicha copia.

Para quitar un volumen que se está usando para copia de seguridad se utiliza el comando removedestination id, siendo id el identificador que se obtiene. Por ejemplo, para eliminar el volumen /Volumes/My Passport

root#tmutil removedestination  1044185E-607C-45A6-A5C2-E96BD7C0D836
root#tmutil destinationinfo
====================================================
Name          : Backups
Kind          : Local
Mount Point   : /Volumes/Backups
ID            : C54F9BEE-AE4F-4E7B-BD9E-6AA18CDD3F83

Realizar una copia de seguridad

Realizar la copia de seguridad es muy sencillo. Basta con utilizar el comando startbackup.

root#tmutil startbackup

Una vez lanzada la orden anterior, tmutil contactará con el servidor de copias de seguridad y comenzará la operación de copia. La orden anterior lanza la copia en segundo plano, retornando si no ha habido ningún error. Una cosa curiosa que ocurre al lanzar una copia así es que en caso de error, este aparece en la interfaz gráfica.

Esta orden admite una serie de parámetros

startbackup [-a | --auto] [-b | --block] [-r | --rotation] [-d | --destination dest_id]

• -a La copia de seguridad se realiza de manera similar a aquellas que el sistema programa.
• -b tmutil espera a la finalización de la copia de seguridad para acabar la ejecución.
• -r tmutil rotará las copias de seguridad de manera automática en el volumen donde se realice la misma.
• -d Permite selecionar a través de su identificador el disco donde se quiere que se realice la copia de seguridad.

Por ejemplo, supongamos que se quiere realizar una copia de seguridad del sistema en el disco con id C54F9BEE-AE4F-4E7B-BD9E-6AA18CDD3F83 y esperar a que esta termine:

root#tmutil startbackup -b -d C54F9BEE-AE4F-4E7B-BD9E-6AA18CDD3F83

Restaurar copias de seguridad

El comando que permite la restauración de un fichero determinado es restore src dst. Su sintaxis es la misma que la utilidad cp. Los ficheros o directorios dentro de la copia de seguridad que se quiere restaurar especificado por src y el destino especificado por dst. Por ejemplo si quisiera restaurar dentro de una copia determinada el directorio /Users/terron al directorio /tmp

root#tmutil restore
/Volumes/Backups/Backups.backupdb/menzoberrazan/Latest/Users/terron /tmp

Terminología de Time Machine

Cuando se están realizando copias usando discos locales Time Machine crea en en el mismo la siguiente estructura de directorios

Backups.backupdb
    machine_name
        copia 1
        copia 2
           ⋮
        copia n
        Latest

La terminología que usa Apple para esta estructura es la siguiente

• Al directorio Backups.backupdb se le llama backup store, que podría traducirse como almacén de copias de seguridad.
• machine_name es un directorio que contiene todas las copias de seguridad de una máquina determinada. En el caso de estar usando un disco local para almacenar las copias de seguridad, cada directorio contiene las copias de seguridad de una máquina.
• Dentro de cada máquina, se tiene cada una de las copias de seguridad que se han realizado y un enlace simbólico,Latest, que apunta a la última copia realizada.

A continuación se puede ver un ejemplo de esta estructura:

baldurgate:menzoberrazan terron$ls -al
total 8
drwxr-xr-x@ 4 terron  staff  136 28 ago 12:39 .
drwxr-xr-x+ 7 terron  staff  238  4 feb  2012 ..
drwxr-xr-x@ 7 terron  staff  238 20 may  2010 2010-05-20-225851
lrwxr-xr-x  1 terron  staff   17 28 ago 12:39 Latest -> 2010-05-20-225851
baldurgate:menzoberrazan terron$pwd
/Volumes/Backups/Backups.backupdb/menzoberrazan
baldurgate:menzoberrazan terron$