archivo

Archivos Mensuales: septiembre 2009


Autor: Dilwyn Jones
Traducción y adaptación: afx

A raíz de nuestro anterior artículo (“Dispositivos DEV y el uso del comando DEV_USE” en la Gold Card) para adaptar el software antiguo a que se ejecute desde subdirectorios en discos duros o en discos de alta densidad, yo presentaré la segunda parte de este tratado de los dispositivos DEV. Esta vez mostraré cómo poner en práctica un mecanismo para simular las facilidades del PATH en un PC.

Esto significa que puedes teclear LOAD ‘miprograma’ sin tener que recordar o establecer el nombre del subdirectorio donde se encuentra ‘miprograma’. ¡Esto es fantásico! Pero entonces ¿por qué alguien no nos ha hablado de esto antes?

Básicamente, se necesita la combinación de dos facilidades disponibles en las tarjetas Gold Card. Normalmente solo funcionará con software que usan las facilidades de directorios por defecto DATA_USE o PROG_USE del Toolkit 2. El BASIC es un buen ejemplo de esto, puedes hacer un excelente uso de esta facilidad solo con el uso de los comandos LOAD o EXEC. Ten mucho cuidado con el uso de SAVE ya que podrías no saber dónde se ha guardado exactamente un fichero.

El manual de la Gold Card explica que mediante el uso de un tercer parámetro en el comando DEV_USE, puedes crear una cadena enlazada de nombres de dispositivos DEV. Así que, si intentas cargar un programa o archivo desde DEV1_ y falla, también se intentará cargar desde el nombre de dispositivo DEV2_ y así sucesivamente. Ahora, si hacemos que los valores de directorios por defecto del Toolkit2 apunte un dispositivo DEV, nosotros podemos hacer que el sistema mire a través de 8 directorios para encontrar el archivo que queremos.

El ejemplo siguiente es sólo un ejemplo sencillo que podrás adaptar a tus requerimientos. El ejemplo presupone el uso de un disco duro (dispositivos WIN) pero puedes adaptarlo al uso de otros dispositivos como una disquetera (sustityendo WIN por FLP). En este ejemplo muestro el encadenamiento de 7 subdirectorios para los programas de uso común.

100 REMark uso de DEV con subdirectorios
110 REMark esto emula la facilidad del PATH en el PC
120:
130 REMark se puede establecer una cadena de hasta 8
135 REMark directorios
137 :
140 REMark adáptalo a tus necesidades
150 DEV_USE 1,WIN1_,2
160 DEV_USE 2,WIN1_QUILL_,3
170 DEV_USE 3,WIN1_ARCHIVE_,4
180 DEV_USE 4,WIN1_ABACUS_,5
190 DEV_USE 5,WIN1_EASEL_,6
200 DEV_USE 6,WIN1_PERFECTION_,7
210 DEV_USE 7,WIN1_TEXT87_,8
220 DEV_USE 8,WIN1_BASIC_
230 :
240 REMark hacer uso de los defaults del Toolkit 2 
245 REMark a través de la cadena DEV's
250 DATA_USE dev1_
260 PROG_USE dev1_
270:
280 REMark cargar ahora con LOAD myprog or EXEC archivo
290 REMark ... se carga aunque esté escondido en algún dir.
300 REMark solo funciona con software que chequea los 
305 REMark defaults de Toolkit 2

Supongamos que intentas cargar el programa WIN1_BASIC_myprog_bas, pero no recuerdas donde lo habías grabado. Puedes usar LOAD ‘myprog_bas’ para después ejecutarlo. El QL intenta cargarlo pero fallará, normalmente dándonos el error ‘not found’. Pero antes de esto el QL añade el “default” del ToolKit 2 e intenta cargarlo otra vez como LOAD DEV1_myprog_bas. Esto debería ser lo mismo que LOAD WIN_myprog_bas. Sin embargo, si el fichero no se encuentra allí, LOAD debería renunciar, pero el QL identifica que hay un enlace desde DEV_1 a DEV2_

Ahora intenta cargarlo como WIN_quill_myprog_bas. ¡Y falla otra vez! Pero hay otro enlace al directorio “Archive”, así que el QL lo intenta en WIN1_archive_myprog_bas. Esto vuelve a fallar, así que trata de recorrer todos los eslabones hasta WIN1_basic_myprog_bas donde finalmente lo logra.

Podrías pensar que la búsqueda por varios directorios puede ser lento. Esto no es tan malo en discos duros o en discos ED, pero puede ser excesivamente lento si se accede a unidades de disco que no contienen el disquete introducido (en mi sistema además hace un terrible ruido intentando acceder al disco ¡No sugiero que lo intentes!).

La respuesta sencilla al problema de la velocidad de búsqueda es poner los subdirectorios usados más frecuentemente al inicio de la lista. Si los dos mayores usos que haces de tu QL es utilizarlo como procesador de textos y para la programación en SuperBasic, haz los ajustes en las especificaciones de DEV1_ y DEV2_.

Puede que te guste experimentar con DEV_USE ‘FLP’ como yo indiqué en mi artículo previo (“Dispositivos DEV y el uso del comando DEV_USE”) con programas que no soporten el “Default” del ToolKit 2, pero ten cuidado y procura salvar tus trabajos ¡Es muy fácil perder ficheros accidentalmente guardándolos en directorios equivocados!

Cuando yo lo experimenté, lo que hice para prevenir el riesgo de destruir los datos del disco duro fue el utilizar un disco ED formateado o un ramdisk con el controlador FLP o RAM renombrado como WIN mediante el uso de los comandos FLP_USE WIN o RAM_USE WIN.

Creé los directorios necesarios para las pruebas con el comando MAKE_DIR, copie unos cuantos ficheros dentro de ellos, y renombré el dispositivo con FLP_USE WIN o RAM_USE WIN. Por un momento, tuve por todas partes dispositivos renombrados, dispositivos que eran ignorados y “defaults” que apuntaban a una cadena de lugares. En ese memento me quedé totalmente confundido, aunque logré aprender lo suficiente para hacerlo funcionar ¡Lo que no me gustó es volverlo a desentrañar todo de nuevo!

Por favor, ten en cuenta la advertencia del manual de la Gold Card – “es fácil llegar a confundirse acerca de la configuración”. Se necesita tener la menta clara para hacer un seguimiento de lo que está pasando, así que si lo dudas, no uses esta facilidad a pesar que es potencialmente útil cuando se utiliza con cuidado.

Aunque esto es solamente utilizable en la Gold y Super Gold Card, los usuarios con otras interfaces como la Trump Card que no soportan los dispositivos DEV pueden usar las utilidades llamadas PATH u SUB escritas por el ex-presidente de Quanta Phil Borman. Éstas están disponibles en la librería de software de Quanta.

atari_st_aEn la primera década de existencia del QL (1984 a 1994) el Atari fue la máquina más afín al Sinclair QL y donde se lograron las mejores emulaciones QL de la época. En algunos foros también se ha etiquetado al Atari ST como una máquina muy “camaleónica” debido a sus facilidades a la hora de emular otras plataformas. Además de la emulación del Sinclair QL (donde el éxito fue bastante menor), adquirió bastante relevancia la emulación del Mac original. Sus promotores consideraban que se conseguía, por un precio más barato, una máquina tan potente como la máquina original. Además de las posibilidades de emulación, el hardware del Atari jugó un importante papel en la evolución del QDOS como el SMS y SMSQ/E.

Todo esto viene a cuento porque hace unas semanas compré una ampliación para mi Atari STe. Se trata de la tarjeta SuperSatanDisk con la que podemos dotar de un “disco duro” a nuestro Atari ST empleando tarjetas SD (ver hilo en http://www.zonadepruebas.com/modules/newbb/viewtopic.php?topic_id=6490&forum=2&post_id=49212#forumpost49212). La mencionada tarjeta es una pequeña joya par la ampliación de un ST, pero eso es otra historia (prepararé otro post más adelante relatando mi experiencia con ella).

Uno de mis objetivos con esta ampliación era poder transformar mi Atari en un sistema QDOS, además de poder disfrutar, por supuesto, de la gran biblioteca de software escrita para la gama ST de Atari.

El primer paso para conseguir el objetivo de convertir mi Atari en una máquina QDOS fue, obviamente, buscar información en Internet. De lo que he podido encontrar, destaco 4 alternativas descritas a continuación. De esas alternativas, la única que parece más viable es la última que describo (SMSQ/E para Atari), ya que el resto o bien no se producen en la actualidad o no tienen las prestaciones suficientes para un uso real de un sistema compatible con el Sinclair QL.

1) Strong QL/Atari emulator.

Este emulador consistía en un placa conectable al Atari que también era conocida como placa emuladora “Futura Data Centre QL emulator” para Atari ST. Fue desarrollado inicialmente por la empresa Noruega Futura Data Centre, cuyo nombre no tiene nada que ver con otro proyecto llamado Futura que era un derivado del QL.

El emulador completo consistía en un kit formado por un adaptador hardware, un disco con formato Atari que contenía ficheros relevantes para convertir el Atari ST en modo QL y un disco con formato QL que contenía una rutina para extraer la ROM del QL y transferir el QDOS desde el QL al disquete con formato Atari.

El emulador hardware consistía en una pequeña tajeta con circuitos impresos que se montaba y desplazaba al chig Shifter, una ULA QL 8301 y varios chis TTL. La instalación de la tarjeta requería la retirada del blindaje metálico interior del Atari. La conexión al ST se hacía con solamente siete cables pero dos conexiones al chip GLUE del Atari debían ser modificados para permitir al software conmutar entre el “modo Atari” y el “modo QL”.

2) Tarjeta Merz QVME

La tarjeta QVME es una tarjeta basada en el bus VME (para el Atari STE y la serie TT) que contenía una emulación completa del QL. Esta tarjeta emula a un QL estándar donde la resolución de la pantalla era programable (en tiempo de ejecución), por ejemplo, 1024×830 o 1280×700. La tarjeta simplemente se conectaba en el bus VME de los STe o TT. Para el uso en un ST estándar se necesitaba un adaptador extra. La tarjeta tenía un conector de monitor para conectar el Atari directamente a un monitor multisync. La tarjeta QVME no podía usar monitores monocromo. Tenía también un “modo de compatibilidad” para el uso de programas que escribían directamente en la pantalla del QL (es decir, el área RAM que representa la salida a pantalla del QL). Se podían usar 4MB de la RAM del Atari para el QDOS. Además todos los dispositivos del Atari eran usables por el QDOS, por ejemplo, las unidades de disco, puertos serie, puertos paralelo, el puerto del ratón y discos duros. Debido a diferencias en el hardware, la red del QL no está soportada en la emulación. Los controladores de dispositivos ofrecían opciones adicionales, por ejemplo, subdirectorios reales en el disco duro, canalizaciones, etc. El software de emulación estaba en un disco y debía cargarse en el Atari (esto significaba que también se podía usar el Atari como tal).

3) QLem

QLem es un emulador software para ciertas máquinas de la serie Atari ST. El emulador es obra de Johan Klockars y es un programa freeware que puede ser descargado de la dirección http://www.devili.iki.fi/pub/emulators/Sinclair/QL/. QLem viene acompañado de un volcado de la ROM JS del QDOS y del programa QL2ST que consiste en una utilidad con dos funciones fundamentales, inicializar discos en formato QL y convertir ficheros en discos con formato QL a discos con sistema de ficheros TOS de Atari. QLem se puede ejecutar tanto en monitor y resolución monocromo como en los monitores y resoluciones en color del Atari. Se soportan disquetes TOS/DOS pero sólo a nivel de directorio raíz. Parcialmente se implementa la emulación de un puerto paralelo (PAR), una segunda unidad de disco y emulación del Joystick.

4) SMSQ/E para ATARI ST, STE, TT

La última de las posibilidades de “emulación” es SMSQ/E. He puesto emulación entre comillas porque realmente no se trata de un emulador sino de la versión del sistema QDOS más avanzada que corre de forma nativa en el hardware de Atari.

SMSQ/E puede convertir cualquier ordenador Atari basado en el motorola 68000 (excepto el Falcon030 y el Atari ST Book) en un sistema en el que se puede ejecutar la mayoría del software escrito para el QL. Además el sistema da soporte a gran cantidad de hardware adicional integrado en el Atari, tal como:
– Soporte de discos duros ACSI & SCSI
– Soporte de discos removibles SyQuest
– Lectura y escritura de particiones de discos duros TOS
– Dispositivos de pueto paraleleo (PAR)
– Hasta 4 puerots serie (SER)
– Se soporta muchas tarjetas aceleradoras (HyperCache, HyperCache 030, PAK etc.)
– Soporte de FAST RAM (TT)
– Driver de dispositivos MIDInet y MIDI

SMSQ/E emula la pantalla de 640×400 en monocromo porque esta es la única resolución mayor o igual que los 512×256 del QL. Se puede usar la resolución completa incluso desde el BASIC. Si se requiere mayor resolución o mayor compatibilidad se puede utilizar hardware adicional que da soporte nativo a la organización de pantalla del QL original, las posibilidades son las siguientes:
– “QL Emulator original”: sólo para el ST y Mega ST. Requiere el chip de video ZX8301 del QL. Emula resoluciones de 512×256 en 4 colores y 256×256 en 8 colores.
– “QL Emulator extended”: sólo para ST y Mega ST. No requiere del ZX8301 y da resoluciones de 512×256 en 4 colores y 768×280 en 4 colores. Pude ser conectada a monitores QL originales.
– QVME: placa conectable el bus VME del Mega STE y TT. Es enteramente programable y soporta modos desde los 512×256 hasta 1280×900 en múltiplos de 8 pixels. Las frecuencias horizontales y verticales son también programables.

Q-Trans es un programa que viene incluido en el paquete LaunchPad de Dilwyn Jones, pero que puede ser usado de forma autónoma.

Básicamente es el programa típico para la gestión de ficheros donde podemos copiar, mover, renombrar, borrar ficheros, etc de forma cómoda e intuitiva. Posee además interesantes opciones para la búsqueda de ficheros; estadísticas de archivos y dispositivos de almacenamiento; y la posibilidad de ejecución de programas desde el propio entorno.

Tiene una interesante gestión de una especie de “papelera de reciclaje” desde donde podemos recuperar ficheros que hayamos borrado por error.

El programa funciona bajo PE (el entorno de ventas del QL) y la navegación por unidades y subdirectorio es muy cómoda. Hay disponibles dos versiones, la versión 1 para sistemas antiguos, y la versión 2 para sistemas que soporte Window Manager 2 – SMSQ/E version 3.0 o superior. El programa consta de un solo ejecutable y viene acompañado de un completo manual en formato _doc de Quill.

Personalmente lo encuentro mucho más cómodo y útil que el gestor de ficheros de QPAC II.

A continuación os pongo algunas pantallas:

QTrans-a

QTrans-b

QTrans-c


Autor: Dilwyn Jones
Traducción y adaptación: afx

Muchos usuarios actuales del QL tienen ahora acceso a los directorios de nivel 2 en sus sistemas, ya sea bien a través de discos duros o mediante el uso de un sistema con disqueteras HD o discos ED. Es bastante fácil instalar el software en estos discos organizados en directorios para asegurarnos que los discos individuales o unidades de disco duro no se llenen de masas de pequeños programas en el directorio raíz. Pero muchos programas QL fueron escritos para usuarios que no tenían disco duro o sistemas de directorios de nivel 2, y muchos de ellos no ofrecen la posibilidad de trabajar con sub-directorios. El manual de la Gold Card nos sugiere una forma de hacer que estos antiguos programas sigan funcionando mediante el empleo de dispositivos DEV y el comando DEV_USE, pero esto no es muy obvio debido a que las indicaciones están ocultas en medio de los detalles de las distintas opciones disponibles. Es conveniente leer primero las notas sobre los dispositivos DEV en el manual de la Gold Card, luego leer este artículo y probar los ejemplos que se ofrecen más abajo.

El uso es simple, copia los ficheros de los programas dentro de un subdirectorio, a continuación usa el comando DEV_USE para asignar los directorios predeterminados y, finalmente, cambia el nombre del dispositivo DEV para que responda a los dispositivos habituales como FLP1_ y FLP2_ que son reconocidos por la mayoría de los programas. En otras palabras, “mágicamente” esto hace que el software funcione desde un disco duro o desde un subdirectorio sin tener que actualizar o cambiar los programas que no están preparados para el uso de subdirectorios.

Tomemos como ejemplo el procesador de textos Quill. Dado que los usuarios de Quill tienden a generar una gran cantidad de archivos de texto, sería deseable poder colocar los archivos del propio Quill dentro de su propio ‘slot’ o ‘carpeta’ en la unidad, de modo que la relación extensa de archivos de texto esté en otra localización y no se mezclen con los archivos del programa. Para ello podemos crear 2 directorios de la siguiente manera:

    MAKE_DIR WIN1_QUILL_

Los ficheros de Quill los colocaremos en este directorio, WIN1_QUILL_ (los dispositivos WIN corresponden al disco duro de un sistema QL). Luego podemos crear un sub-directorio para almacenar los ficheros de texto.

 
    MAKE_DIR WIN1_QUILL_DATA_

Por lo tanto nuestros archivos de texto pueden ser guardados al estilo de WIN1_QUILL_DATA_carta1_doc, por ejemplo. Pero ¡NO!, ¡Quill no te permitirá ficheros con nombres largos de esa manera! Aquí es donde el dispositivo DEV viene al rescate.

Básicamente, lo que hacemos ahora es dejar que el software siga funcionando por sí solo como siempre lo ha hecho y que crea que se sigue cargando y guardando datos desde FLP1_ y FLP2_. Sin embargo, el QL cambiará automáticamente estos nombres para que redirigirlos a WIN1_QUILL_ y WIN1_QUILL_DATA respectivamente, ofreciendo una forma automática y sencilla de utilizar directorios con el mínimo esfuerzo por parte del usuario sin la necesidad de hacer cambios difíciles de software que no está preparado para trabajar con directorios.

Mediante los dispositivos DEV y el comando DEV_USE podemos hacer creer a nuestros programas que están colocados en los FLP1_, FLP2_, MDV1_, MDV2_ (o cualquier otro dispositivo) aunque ellos estén alojados físicamente en un subdirectorio particular.

Siguiendo nuestro ejemplo, podemos establecer dos dispositivos DEV, uno para acceder al programa, a los archivos de ayuda, al controlador de la impresora y cosas así; y el otro para los ficheros de datos. Asumiendo que tenemos configurado Quill para cargar los archivos de ayuda desde FLP1_, para acceder a sus archivos DAT de los controladores de impresora desde FLP1_, y para cargar y guardar archivos a y desde FLP2_, tendríamos que asignar los directorios de la siguiente manera.

100 DEV_USE 1, WIN1_QUILL
110 DEV_USE 2, WIN1_QUILL_DATA
120 DEV_USE 'FLP'

Por lo tanto, cada vez que le dices a Quill que guardare un archivo como ‘FLP2_micarta_doc’ realmente lo está convirtiendo en WIN1_QUILL_DATA_micarta_DOC. Cada vez que le pides a Quill que liste los archivos de FLP2_, realmente la lista de archivos se está extrayendo de WIN1_QUILL_DATA_.

Tendrás que hacer un pequeño programa en Basic como este para cada programa al que le quieras reasignar sus unidades, pero esto supone bastante menos trabajo que modificar u obtener versiones actualizadas (si las hubiera) de todos tus programas que no funcionen de forma adecuada con sub-directorios. Úsalo en un programa boot de tu aplicación (renombra el boot normal del programa como ‘boot2’ por ejemplo, y salva este como el BOOT de tu programa en un direcotorio relevante).

NOS QUEDA UN PROBLEMA. ¡Ahora no podremos usar los discos flexibles! Cualquier referencia a FLP1_ y FLP2_ automáticamente el sistema nos estará redirigiendo al disco duro. La solución es renombrar los dispositivos floppy también. Esto no debería ser un problema grave en el sistema que hemos descrito ya que los disquetes se usan muy poco en un equipo con disco duro. Para hacer esta reasignación usaremos el comando FLP_USE ‘fdv’ para renombrar los discos FLP a FDV (FDV al estilo de los MDV de los microdrives). Así accederemos a las unidades de disquete usando FDV1_ y FDV2_ en lugar de FLP1_ o FLP2_.

Esto es algo que lleva algún tiempo comprender y dominar, pero no se puede explicar de una forma más simple. Es obvio que habrá excepciones, los programas que no funcionan, por ejemplo, programas de Microdrive protegidos y algunos programas que necesiten más de dos DEVS instalados, pero al menos esto es un ejemplo de trabajo que muestra lo simple que puede ser. ¡Oh sí!, no te olvides de restablecer los dispositivos después de usar el programa con el comando DEV_USE ‘dev’ y, posiblemente, FLP_USE ‘FLP’ si los habías cambiado también.

(NOTA: Asegúrate de restablecer la configuración a la normalidad cuando dejes de usar el programa en cuestión.”DEV_USE” por sí mismo, cancelará cualquier asignación DEV que hayas hecho. El no cancelar esta configuración afectará al próximo programa que ejecutes.)

leonardo_torres_quevedo


Además de construir dirigibles y transbordadores, este científico español contribuyó decisivamente al desarrollo de la informática.

Leonardo Torres Quevedo, el científico que aplicó por primera vez la aritmética de coma flotante a los ordenadores, nació en Santa Cruz (Cantabria) el 28 de Diciembre de 1852. Estudio en el Instituto de Bilbao y en la Facultad de Ingeniería de Madrid.

Su genio inventor alcanzó su punto culminante en los últimos años de su vida. A él se le debe la construcción del transbordador funicular aéreo junto a las cataratas del Niágara, que en la actualidad continúa en uso; además diseñó un dirigible dotado de una armadura funicular que reunía las características de los dirigibles rígidos y flexibles. Pero, básicamente, Torres era un hijo de su época y su principal interés se centraba en los dispositivos electromecánicos. En 1906, en Bilbao, exhibió ante el rey de España, Alfonso XIII, el prototipo de un barco dirigido a distancia por medio de las ondas hertzianas, y en 1911 inventó el primer jugador de ajedrez autómata. Para mover las piezas la máquina utilizaba unos electroimanes situados debajo de la mesa; estaba programada para ganarle una partida sencilla a un oponente humano.

El interés de Torres por los autómatas nació a raíz de su experiencia en las líneas de montaje de las plantas industriales de Europa de comienzos de siglo XX; y a lo largo de toda su vida se esforzó por separar los tipos de problemas que requerían pensamiento humano para su resolución de aquellos que se podían resolver automáticamente.

En 1914 publicó un estudio en el que demostraba la viabilidad de la construcción del ingenio analítico de Babbage empleando técnicas electromecánicas, y fue en este documento donde sugirió por primera vez la utilización de aritmética de coma flotante para todo futuro ordenador. En 1920 construyó una calculadora electromecánica que utilizaba una máquina de escribir adaptada para dar entrada a los números e imprimía los resultados automáticamente. La máquina de escribir estaba conectada a la calculadora mediante cables telefónicos, y Torres previó la posibilidad de acoplar muchos terminales a una calculadora central (o unidad de proceso).

Torres Quevedo fue condecorado por la Academia Francesa de Ciencias, y con posterioridad sería nombrado presidente de honor vitalicio de la Academia de las Ciencias de Madrid. Falleció en Madrid el 18 de diciembre de 1936.

(Fuente: Mi Computer, fascículo 18. Editorial Delta, 1984.)

micro_menPor el blog de Sarah Dobbs nos enteramos de que está en preparación, por la BBC, una película llamada ‘Micro Men‘ (proyecto anteriormente conocido como ‘Syntax Era’), un drama-comedia de 90 minutos acerca de los días embriagadores de la industria informática británica en la década de 1980, que mostrará la rivalidad entre Clive Sinclair y el co-fundador de Acorn Chris Curry por ir en cabeza del creciente mercado del ordenador doméstico. Una rivalidad que llegó a las manos en cierta ocasión en una pelea celebrada entre ellos en un pub de Cambridge

A la BBC no sólo le motiva en este caso la reciente historia de su país. Hablar de Acorn en UK es hablar del BBC Micro, un ordenador producido por esa empresa para la cadena de TV, que hizo frente al ZX Spectrum de Clive.

Richard Klein, de BBC4, dijo: “Quienes vivimos la década de 1980 recordamos la emoción que sentíamos cuando comenzaron a entrar en nuestros hogares  los gadgets y la tecnología, pero no muchos de nosotros sabemos las fascinantes historias detrás de su llegada.”

Los papeles principales serán interpretados por Martin Freeman, de ‘The Office’, y por su oponente en la ficción, Alexander Armstrong, de ‘Armstrong and Miller sketch show fame’, que hará de Sinclair.

“Siempre me ha impresionado Clive Sinclair” -dice Armstrong- “Soy de la generación que recuerda lo mejor de él, pero el C5 es su legado, y eso es injusto”. En la película se muestra un Sinclair brillante, pero poco dispuesto a la colaboración, mientras que Curry es práctico pero poco centrado.

Para la elaboración del guión se consultó a los implicados reales y algunos anuncios como el del Sinclair QL en el que Clive salta por encima de un PC gigante del tamaño de un edificio aparecen en la película. Armstrong pasó tres horas en maquillaje todos los días para mostrar la apariencia de Clive. El C5 también tiene su hueco y se ha contado con la ayuda de ‘The Haverhill’s Centre of Computing History‘.

El rodaje empezó el lunes, 22 de junio en Londres. Fue escrita por Tony Saint, y es probable que se emita este otoño por el canal BBC4.

La noticia aparecerá también en la edición de octubre de Wired UK.

Preparad vuestros vídeos.

Reportaje sobre la película:
http://www.next-gen.biz/magazine/sir-clive-vs-the-bbc

Fuentes de la noticia:
El blog de Sarah Doobs
BBC
comedy.org.uk
imdb
drobe.co.uk
retrocomputers.wordpress.com