archivo

Archivos Mensuales: octubre 2009

El fin del mundo ha llegado, una web dedicada única y exclusivamente a proporcionar diversión a los usuarios de Sinclair QL y a todos los curiosos que no se atreven a tocarlo y lo miran con deseo. Todo ello aderezado de la rara presencia de capturas de pantalla de todo lo descargable.

Nunca se pensó que fuera tan simple disfrutar de la experiencia de un QL, pero aquí está. Basta que os bajéis unos ficheritos, os grabéis unos discos de 3 1/2″ y os sintáis como si vuestro PC se hubiera convertido en la bestia de Sinclair.

Seguir las indicaciones d ela web y disfrutaréis como enanos, imprescindible probar el Alien Hijack.

logoYA ESTAS TARDANDO EN PULSAR AQUÍ:
http://www.bytemaniacos.com/qlwiki

No os engaño, mucho material del allí expuesto no tiene permiso expreso para distribuirse, pero alguien tenía que tirar la primera piedra para que este sistema no se olvidara.

Este fin de semana se realizó en Madrid una reunión de usuarios de ordenadores clásicos, con el exótico nombre de Tasca Party (por celebrarse en una tasca). Entre los sistemas expuestos estaba el Sinclair QL y pudieron verse varios juegos corriendo en él, algo que no suele verse todos los días. Os dejamos algunos vídeos interesantes.

Alien Hijack

Hopper

Un chaval jugando al Jungle Eddi y un vistazo general al evento

Más vídeos en Youtube.

En varias ocasiones hemos tratado el tema del manejo de la pantalla del QL en Qforum (el foro del QL de sinclairql.es). En ellos hay variedad de información, pero al menos a mí, siempre me han quedado algunas lagunas debido al desconocimiento de cómo trata el QL la pantalla. En muchas ocasiones no he entendido exactamente las aportaciones de los otros usuarios cuando hablan en profundidad de este tema, siempre ha habido conceptos que se me han escapado y que no he llegado a comprender del todo bien. Por ejemplo, el porqué de las distintas resoluciones del QL, como se gestionan los colores, las peculiaridades del “flashing”, etc.

Para cubrir estas lagunas presento este artículo en el cual sólo me he dedicado a rescatar material “enterrado” en varias fuentes que hablan sobre esto. He dividido el artículo en dos partes. Una primera parte con “la teoría” extraída de un buen artículo de la vieja revista Qlave escrito por Javier Boira (¡fantástico el artículo!), y una segunda parte donde se ejemplifica el tratamiento directo de la memoria de pantalla del QL mediante un pequeño programa escrito en SuperBASIC. Este programa no es más que una adaptación de otro pequeño programa de Timothy Swenson publicado en el ezine “QL Hacer’s Journal”. Como veis, el contenido no es de elaboración propia, yo sólo me he limitado a rescatar, traducir, mezclar, decorar y organizar la información que he encontrado.

Bueno, empecemos.

La teoría

La pantalla constituye el medio directo de comunicación del ordenador con el usuario, es lógico pues que dediquemos algún tiempo a conocer más de cerca este elemento tan cercano al programador.

Nuestro QL nos ofrece, ya nada encenderlo, dos posibilidades gráficas; una de ellas con mayor colorido pero menor resolución (256×256), mientras la otra nos ofrece la ventaja de una mayor resolución con 512 puntos horizontales (512×256) a la par que se pierden cuatro colores y la posibilidad de parpadeo.

De todas formas ambos ocupan una misma región de memoria del QL, la cantidad 32K (relativamente grandes para los ordenadores de esta generación). Son estos 32K y sólo ellos los que van a llevar toda la información que se nos ofrece en nuestros monitores. La conversión en imagen visual se realiza a través del conversor de vídeo, este elemento busca la información de cada punto en la memoria (en el momento que se necesite) para darle la tonalidad y contraste necesaria enviándola al monitor y que nosotros reconozcamos la figura claramente. A pesar de que a nosotros nos parezca al utilizar el ordenador que éste nos dedica todo su tiempo esto no es cierto. El microprocesador ha de hallarse constantemente interrumpiendo su labor hacia nosotros (BASIC) para representar la pantalla, manejar Microdrives, atender al teclado y otras muchas cosas que hace mientras nosotros inocentemente creemos estar con nuestro aparato tranquilamente ocupada en el BASIC. Nosotros no nos enteramos del tiempo ocupado en dichos menesteres porque el tiempo utilizado es mínimo para nuestra capacidad de percepción.

Pero volvamos a la memoria de pantalla, que es allí donde se van a definir todas las posibilidades gráficas del QL. Nosotros podemos acceder a toda la información contenida en la memoria de pantalla, así como podemos modificarla con solo “pokear” la zona correspondiente (o “peekear” para leer).

La zona de memoria de pantalla comienza en la dirección $20000, en decimal la 131072, y ocupa exactamente 32768 octetos de memoria RAM, es por esto por lo que de los 128K que lleva instalado nuestro QL de forma estándar, sólo son utilizables menos de 96K. Si multiplicamos estos 32768 bytes por 8 bits que contiene un byte nos dan 262144 en decimal, $40000 bits en hexadecimal. Luego en total disponemos de 262144 unidades mínimas de información, cada bit puede contener un sí o no, uno todo o nada. Luego en estas condiciones podríamos asignar dos colores, uno al si en un bit 1 y el otro al no 0, con lo que con 32K de memoria se podrían definir (si así lo hubiesen definido los diseñadores) 262144 puntos de pantalla. Los diseñadores de SINCLAIR no optaron por esta forma de estructurar la memoria de pantalla, sino por otra, en la que se utilizan cuatro colores. Con un mínimo de conocimiento binario se puede recordar que con dos bits podemos formar cuatro posiciones distintas jugando con los unos y los ceros 00, 01, 10, 11, con lo que con estas dos unidades podemos definir un punto de la pantalla en cuatro posiciones distintas o intensidades (que puede ser como en el QL en alta resolución el negro, rojo, verde y blanco).

Pues bien, si a cada punto dibujable (representable más bien) en la pantalla le asignamos dos bits, en los 262144 bits que disponíamos nos cabe la definición de 131072 puntos dibujables (dividir por dos), exactamente 512 filas por 256 columnas (512×256=131072). Pero además el QL viene dotado de otra resolución más baja, 256×256 puntos en ocho colores y posibilidad de parpadeo. En esta resolución cada punto representable debe hallarse en dieciséis posibles situaciones (negro, azul, rojo, magenta, verde, cian, amarillo, blanco, negro con parpadeo, azul con parpadeo, rojo con parpadeo, magenta con parpadeo, verde con parpadeo, cian con parpadeo, amarillo con parpadeo y blanco con parpadeo), que con bits se puede representar con cuatro (2e4=16, combinaciones de dos elementos “1” y “0” tomados de cuatro en cuatro), por lo que podemos representar 262144/4=65536 ($10000) puntos, es decir 256×256.

Por lo tanto, dependiendo de las combinaciones de unos y ceros en dos bits (alta resolución) o cuatro bits (baja resolución), aparecen en la pantalla los puntos en tonalidad e intensidades deseados. Ahora veamos cómo se colocan estos cuatro o dos bits en la memoria de pantalla.

La zona de memoria de pantalla comienza en la dirección $20000, y acaba en la $27FFF. Cada punto de la pantalla tiene situada su información en dos bytes diferentes y vecinos. Así en el modo de alta resolución cada dos bytes definirán ocho puntos (2×8/2). El primer bit de definición se hallará en el primero de los bytes, y el segundo en el segundo de los bytes. Así el primer punto de la pantalla (el de la esquina superior izquierda) vendrá definido por el primer bit el byte $20000, que seleccionará el color verde (1=verde), y por el primer bit del byte #20001, que seleccionará el color rojo. Si ninguno de ambos bits está activado el punto se hallará en negro, mientras que si se hallan ambos activados (“1”) estará en blanco.

El siguiente punto de la pantalla hacia la derecha viene definido por el segundo bit de los bytes $20000 y $20001 y así sucesivamente, cuando se completan los ocho bits del primer y segundo byte se pasa al primero del tercer y cuarto byte. De este forma los bytes pares contienen la definición del verde de un determinado punto, mitras lo impares del rojo. Cuando se completan los 512 puntos de una línea se pasa a la siguiente. Por lo tanto para localizar el byte en el que se halla de definición de un determinado punto hace falta realizar el siguiente cálculo:

– Punto definido por coordenadas “X” (horizontal) e “Y” (vertical) desde la esquina superior izquierda de la pantalla (0,0) y en puntos reales.

   byte par (verde)   = 131072 + Y * 128 + INT ( X / 8 ) * 2
   byte impar (rojo)  = 131072 + Y * 128 + INT ( X / 8 ) * 2 + 1
   posición del bit dentro del byte = 7 - (X - INT ( X / 8 ) * 8 )

Con estos cálculos podemos hallar la posición de memoria a pokear o leer. Por ejemplo, si deseamos poner en blanco el punto situado a 77 en vertical del origen (arriba) y a 405 en horizontal tendremos:

   byte par (verde)  = 141028
   byte impar (rojo) = 141029
   posicón bit = 2

Luego tenemos que poner el segundo bit de los bytes 141028 y 141029 a 1, con lo que pokeamos con una máscara de la siguiente manera:

   poke 141028, peek(141028) || 4
   poke 141029, peek(141029) || 4

Es decir, hacemos una operación lógica OR del valor 4 (en binario %00000100, el uno en el bit 2) con el contenido anterior, con lo que los bits que no son el bit 2 se quedan como estaban (0 OR 0 = 0, 0 OR 1 = 1), mientras que el bit2 se pone a 1 (0 OR 1 = 1, 1 OR 1 = 1) en los dos bytes, visualizándose dicho punto en color blanco.

Análogo razonamiento deberíamos realizar para la baja resolución, sólo que en esta modalidad cada dos bytes guardan la información de cuatro puntos (2*8/4). El razonamiento para hallar la colocación de un punto quedaría como sigue:

   byte par (verde)   = 131072 + Y * 128 + INT (X / 4) * 2
   byte impar (rojo)  = 131072 + Y * 128 + INT (X / 4) * 2 + 1
   posición del bit verde, rojo = 7 - (X - INT (X / 4) * 4)
   posición del bit azul, parpadeo = 7 - (X - INT (X / 4) * 4) + 1

Notar aquí que los bytes de verde y rojo se hallan en los puestos indicados en los bytes par (verde) e impar (rojo), seguidos inmediatamente de los bits de azul en el byte par y parpadeo en el impar.

Hay que tener cuidado con la utilización del byte de parpadeo pues es un caso muy peculiar. Se pone a uno este bit en alguno de los puntos, dicho punto, así como el resto de la línea derecha hasta el final derecho de la pantalla si no se halla otro bit de parpadeo encendido, se pondrá a parpadear. Así pues el parpadeo se activa desde el punto hasta el siguiente con dicho bit a uno.

Hay que tener mucho cuidado al trabajar con la memoria de pantalla ya que un error de cálculo nos podría llevar a la memoria situada encima de esta zona, que contiene ciertas variables del sistema que al ser alteradas pueden hacer fallar el sistema del ordenador con un consiguiente descontrol del mismo. Esto podría pasar cuando cargamos una pantalla con lbytes y por error lo que cargamos excede de los 32K.

El control de la memoria de pantalla es muy útil sobre todo para la programación en lenguaje máquina, ya que las rutinas que trae el sistema operativo son de carácter muy general, teniendo que contemplar muchos casos particulares con el retardo que esto conlleva. También, los métodos expuestos anteriormente son la base de los comandos del SuperBASIC para el manejo de gráficos en la pantalla.

Un ejemplo práctico
Existen diversidad de rutinas para el tratamiento de la pantalla del QL, prácticamente la totalidad de ellas están escritas en ensamblador por razones de eficiencia.

Con el fin de ilustrar el uso de la pantalla del QL veremos a continuación un programa extraído de la ezine “QL Hackers Journal” de Timothy Swenson.

La finalidad de este pequeño ejemplo es guardar en memoria una zona de una ventana de pantalla para luego recuperarla y pintarla en cualquier otro lugar. Aunque en un programa real estas funciones escritas en SuperBASIC son excesivamente lentas, nos sirven sin embargo para asentar lo que hemos estudiado en este artículo. Además podrían utilizarse como idea base si quisiéramos portar este programa al lenguaje C o al lenguaje ensamblador para un uso real. Esta versión en SuperBASIC es más instructiva a la hora de comprender y testear el algorítmo como paso previo a su versionado en leguajes más eficientes para este tipo de tareas como es el caso del lenguaje ensamblador.

El programa es muy simple de seguir, a continuación mostramos su código fuente y unas capturas de pantalla de los resultados.

100 CLEAR
110 REMark --- Vector para almacenar pantalla
120 DIM store(5000)
130 :
140 REMark --- Cargar pantalla
150 LBYTES flp1_sys_cheetah_scr, 131072
160 :
170 REMark --- Guardar ventana
180 save_bg 120, 100, 360, 20
190 :
200 REMark --- Crear nueva ventana
210 OPEN #3, con_120x100a360x20_32
220 PAPER #3,0: INK #3,7
230 CLS #3
240 PRINT #3,"This is a test"
250 PRINT #3,"of real windows"
260 PAUSE 50
270 CLS #3
280 PRINT #3,"Hit Return"
290 PRINT #3,"to make this"
300 PRINT #3,"go away"
310 INPUT #3,in$
320 CLOSE #3
330 :
340 REMark --- Restaurar ventana
350 load_bg 120, 100, 360, 20
360 :
370 REMark --- Pintar fondo ventana en
380 REMark     varios lugares para demo
390 PAUSE 250
400 CLS:CLS#0:CLS#2
410 load_bg 120, 100, 0, 0
420 load_bg 120, 100, 80, 40
430 load_bg 120, 100, 200, 80
440 PAUSE 250
450 :
460 STOP
470 :
480 :
490 REMark ------------------------------------------
500 REMark   Procedimientos para guardar
510 REMark   y recuperar fondo de ventanas
520 REMark ------------------------------------------
530 :
540 DEFine PROCedure save_bg (length, height, x, y)
550   LOCal   mem, i, j
560   mem = 1
570   FOR i = 131072+(y*128) TO 131072+((y+height)*128) STEP 128
580     FOR j = i + (x/4) TO i + ((x+length)/4) STEP 2
590          store(mem) = PEEK_W(j)
600        mem = mem + 1
610      END FOR j
620   END FOR i
630 END DEFine save_bg
640 :
650 :
660 DEFine PROCedure load_bg (length, height, x, y)
670   LOCal   mem, i, j
680   mem = 1
690   FOR i = 131072+(y*128) TO 131072+((y+height)*128) STEP 128
700     FOR j = i+(x/4) TO i+((x+length)/4) STEP 2
710       POKE_W j,store(mem)
720       mem = mem + 1
730     END FOR j
740   END FOR i
750 END DEFine load_bg
Imágen, fondo de pantalla

Imágen, fondo de pantalla

Fondo, con ventana almacenando fondo de ventana

Fondo, con ventana almacenando fondo de ventana

Réplica de fondo de ventana

Réplica de fondo de ventana

Fuentes.
————
– Revista QLave, “La Pantalla del QL”, Javier Boira.
– QL Hacer’s Journal, Timothy Swenson

QLMatchpoint1En el último número de la revista QL Today (vol. 14, num. 1) se hace mención a un extenso artículo publicado en la revista “Retro Gramer” sobre el Sinclair QL y los juegos. Este artículo es recibido para la comunidad QL como un inesperado homenaje de la prensa actual a nuestra querida máquina.

A continuación os hago un extracto de dichas reseñas:

“Sinclair QL, ¿por qué deberías poseer esta máquina increíblemente rara?”. Con este reclamo en su portada “Retro Gamer” incluye en su último número un extenso artículo de 6 páginas sobre el QL

Después de repetir las razones bien conocidas que motivaron el fracaso comercial del QL, el artículo tiene algunos comentarios interesantes sobre el QL y los juegos de ordenador:

“Sinclair parecía tener una relación amor / odio con los juegos. Por un lado, el éxito del Spectrum fue alimentado por la abundancia de software se juegos de bajo costo disponibles en el mercado, mientras que por otro lado habían rumores sobre cierta información privilegiada dentro de la empresa que apuntaban a que esto menoscababa la dignidad de la empresa. David Karlin (diseñador hardware del QL) no está de acuerdo con estos informes de que el juego era un tabú dentro de Sinclair. Había mucha gente en la empresa que entendía que el mercado de los juegos era beneficioso y se invertía mucho trabajo y dinero en garantizar que el Spectrum estuviera bien posicionado en el mercado y se hizo lo posible para que el QL también lo estuviera. En cualquier caso, nadaba contra corriente dentro de la empresa, la cual estaba centrada decididamente en posicionar al QL en el mundo de los negocios y las empresas. La intención inicial de David era desarrollar una máquina enfocada puramente a los pequeños negocios, diseñada para ser conectado a un monitor. A medida que avanzaba el proyecto las cosas fueron cambiando, se añadieron un interfaz para la conexión con un televisor y puertos para joystick. Se discutió el mantener un puerto para las cintas del Spectrum, pero al final se descartó la idea, se suponía que los Microdrives eran los suficientemente buenos.”

Retro Gamer sugiere que el QL tenía el potencial para poder realizar los complicados cálculos que requerían los juegos, pero su principal obstáculo fue su pantalla que ocupaba 32K de memoria RAM en comparación con los 7K del Spectrum. Esto hizo que el “scrolling” rápido a pantalla completa fuera dificultoso y por lo tanto los primeros juegos del QL se centraron en pantallas estáticas. David Karlin sugiere que una máquina de juegos no debería haber tenido el modo 4 ni coprocesadores. Sin embargo “Retro Gamer” resalta que los dos programas de juegos más famosos de Psion, Chess y Match Point, ambos usaban gráficos en modo 4 para el uso de la alta resolución. La mayoría de otras casas de desarrollo de juegos preferían sin embargo más colores en lugar de mayor resolución. La revista hace una mención especial al juego Wanderer de Pyramide diciendo que ilustra la fortaleza del QL en la utilización de gráficos vectoriales en el desarrollo de juegos -‘…. el 68008 podía comer procesadores de 8 bits para desayunar”.

La lista de los 10 mejores juegos para Retro Gamer son los siguientes:
1: Match Point
2: Karate
3: Jungle Eddi
4: BJ in 3D Land
5: QL Quboids
6: Deathstrike
7: Speedfreaks
8: Pudge
9: Mortville Manor
10: QLPawn

Matchpoint de Psion

Matchpoint de Psion

Jungle

Jungle

criptografia

La criptografía fue una de las primeras aplicaciones de los ordenadores. En la actualidad, elaborar y descifrar un código sencillo está al alcance de un programa de ordenador.

Toda nuestra comunicación con los demás está codificada. Tanto el habla como el lenguaje escrito son inteligibles sólo si la persona que recibe el mensaje conoce el código del comunicante. Lo mismo sucede con nuestras conversaciones con los ordenadores. La mayoría de los ordenadores personales se comunican por medio de una versión del BASIC para ser accesibles a la mayoría de la gente, pero nosotros sabemos que la máquina no emplea este leguaje para realizar sus funciones: ella debe primero interpretar las sentencias en BASIC en una forma puramente numérica que después utiliza para establecer la secuencia de conmutaciones definidas en el programa y, de este modo, producir los resultados deseados. Los códigos de este tipo (lenguajes humanos y lenguajes de programación) son de fácil acceso en nuestra vida cotidiana. Con un poco de esfuerzo y voluntad, cualquiera puede aprender francés, alemán, BASIC o Fortran.

Pero existe otro tipo de codificación (o criptografía, para usar la palabra adecuada) que tiene por objetivo lo contrario de la comunicación; su finalidad consiste en evitar que lo comprendan todos, a excepción de un reducido grupo al cual está destinado el mensaje. Hasta la segunda mitad del siglo XX, la transmisión de información en una forma ininteligible para el público en general era privativa de los gobiernos y de alguno que otro asunto industrial importante. Pero más recientemente la criptografía se ha convertido en algo cotidiano.

Las claves y los códigos oscilan desde los muy simples (la suma o la resta de un valor determinado a cada byte, o la sustitución según el formato de un carácter por otro cada vez que éste aparece) hasta las claves en extremo complejas por las que se encaminan los más recientes avances de la teoría de los números. Estas claves no contienen ningún elemento de repetición y, por consiguiente, no son descifrables con los tradicionales métodos de decodificación por análisis de frecuencia.

Quizás la más sencilla de todas las técnicas significativas de criptografía sea la “clave del César” (que tal vez se utilizó por primera vez en la época del Imperio romano). Para descifrar la clave del César sólo se necesita el mensaje y un conocimiento de la clave, de modo que no hay que consultar voluminosos libros de códigos ni documento alguno, ni se necesita unas máquinas especiales. He aquí un breve mensaje escrito en clave del César:

AYJYZNXNQ W BPYENLCQ

Podemos aventurar algunas suposiciones acerca de estas palabras crípticas, a tenor de la forma en que se separan los grupos cifrados (aunque, por supuesto, ¡esto se podría haber hecho para crear mayor confusión¡). Lo más obvio a que destaca a simple vista es que el mensaje consta de 3 palabras; la primera posee 9 letras, la segunda posee 1 y la última 8. También es claro que la primera y la tercera palabra terminan con la misma letra. Aquí la última letra final común (Q) es, asimismo, una de las tres letras del mensaje que se repiten con mayor frecuencia (las otras dos son la Y y la N). Para el criptoanalista esta observación tiene un valor considerable (al menos, cuando sabe en qué idioma está trabajando). En castellano, las letras que se presentan con mayor frecuencia son la A y la E entre las vocales, y la S entre las consonantes; esta última, dado que con ella se forma el plural, suele hallarse al final de las palabras.

Con una muestra tan reducida como la que tenemos aquí (un total de 18 letras, cifra que todo estadístico considera muy insuficiente para buscar en ella cualquier análisis), es probable que nuestros resultados sean fiables. Pero, aun así, vamos a probar con la sustitución de frecuencia y veremos si los resultados obtenidos tienen algún significado. En primer lugar vamos a reemplazar la Q por la S, por ser aquella la última letra de las dos palabras más largas.

AYJYZNXNs W BPYENLCs

El mensaje aún no tiene significado, pero existen otras pistas. ¿Qué hay de la relación entre la letra original y la letra por la cual la hemos sustituido? En el alfabeto, la Q está dos lugares antes que la S. ¿Qué sucederá si sometemos el resto del mensaje a la misma transformación? Dos lugares después de la Y (la otra de nuestras letras que aparece con mayor frecuencia) está la A (si consideramos el alfabeto como una cadena ininterrumpida), así que vamos a intentar agregar esta información.

AaJaZNXNs W BPaENLCs

En la primera palabra tenemos ahora dos vocales intercaladas, que en castellano es una construcción válida. Además, la letra final es una S, hecho que en esta lengua es de común ocurrencia, de modo que tal vez estemos en el camino correcto. Vamos a someter el resto del mensaje a la misma transformación. Dos lugares tras de la A se encuentra la C; dos lugares después de la J está la N; aplicando la misma correspondencia, la Z de convierte en B, la N en O y la X en Z… De esta forma llegamos a la solución “calabozos y dragones”, un atractivo juego de aventuras.

La clave del César es, pues, un código de sustitución que se basa en “deslizar” el alfabeto hacia atrás o hacia adelante según un número que es secreto y que nos dará el nuevo valor de cada carácter. Sin utilizar las frecuencias, el mensaje puede simplemente construirse según una serie clave de transformaciones: 24225, por ejemplo. En este caso la primera letra se desplazaría dos lugares, la segunda cuatro, la tercera dos y así sucesivamente. Cuando se llega al último número de la serie clave la volveremos a iniciar. Con esta serie clave, el mensaje de muestra “calabozos y dragones” quedaría:

AWJYWNVNQ T BÑYERKLAQ

En este caso, el análisis de frecuencia sería inútil, pues no hay uniformidad en las sustituciones: una letra tendrá distintas sustituidas según su posición en el mensaje global. Otra clave sencilla auto contenido es el mismo mensaje en estos términos:

CBSDOAAOO RGNSLZYAE

Si observamos atentamente, podemos ver que esta serie de caracteres es en realidad un anagrama de “calabozos y dragones”, completo y con los dos espacios entre las palabras. Aquí simplemente estamos tratando de determinar el algoritmo criptográfico, a parir de ejemplos tanto de texto llano como de texto cifrado, un procedimiento sorprendentemente común. Si la clave ha de ser comprensible al destinatario del mensaje, entonces la combinación de las letras debe ser predecible de alguna forma. Esta clave particular, conocida como “bar fence”, también requiere que el decodificador la conozca; en este caso es 3. Vamos a tomar los cinco primeros caracteres y escribirlos con tres espacios de por medio:

C***B***S * D***O

¿Reconoce algo? Entonces probemos con esto: escriba el mensaje de texto llano en tres líneas, yendo de arriba y hacia abajo entre ellas, de la siguiente manera:

C   B   S   D   O
 A A O O *Y* R G N S
  L   Z       A   E

Los asteriscos representan los espacios entre las palabras; el método criptográfico es llano.

Los ejemplos que hemos citado hasta el momento han sido todos cifras, definidas como un método de escritura secreta que utiliza la sustitución o transformación de letras de acuerdo a una clave. Los códigos son algo diferente, en el sentido de que tienden a reemplazar bloques enteros por otros bloques, normalmente más pequeños (permitiendo, de este modo, al mismo tiempo, comprimir los datos). Su inconveniente es que exigen que ambas partes posean un libro de códigos para que se puedan comunicar mensajes. Un ejemplo de esta técnica emplea una novela, un periódico u otro texto que se pueda conseguir con facilidad, e indica las palabras del mensaje dando el número de secuencia en que se producen. Un texto como:

“Maigret leyó con atención el aviso: Por favor, al objeto de favorecer el tráfico, permanezca al volante, no baje del coche. Sonrió. Ahora comprendía por qué en su momento el cadáver de Smith no fue identificado”.

podría ser la clave para el código 4, 6, 7, 17, 2.

Un ordenador de cualquier clase puede ser de enorme valor al intentar cifrar o descifrar mensajes criptográficos. Un requisito primordial de la clave del César, por ejemplo, es la capacidad de desplazamiento a través de una serie alfanumérica, sumando o restando una variable al valor ASCII de cada carácter, que se puede entonces imprimir. Dicha constante ha de ser susceptible de modificarse cuando se ejecuta el programa, y debe hacer que el alfabeto se “enrolle” (es decir, una A, cuando la clave fuera uno, debería dar Z).

(Fuente: Enciclopedia Mi Computer)

¿Nunca te has “atascado” en averiguar los parámetros de la línea de comandos de los compresores de ficheros como zip, zoo, arj, lha …? Pues bien, con el uso de Archivers Control Panel (ACP) se acabaron tus problemas.

Archivers Control Panel (v4e01) es una utilidad para el manejo y administración de archivos comprimidos que funciona bajo el sistema operativo QDOS. Fue desarrollado por Thierry Godefroy, un programador muy activo de la escena QL. Thierry mantiene también un sitio Web con variedad de información y programas de dominio público para el sistema QDOS y derivados.

ACP actúa como “front end” de cara a la administración de archivos comprimidos generados por una gran variedad de compresores (Arc, Lha, Lhq, Zip, Zoo). El programa funciona bajo Pointer Environment (PE) y a golpe de ratón puedes comprimir o descomprimir ficheros empaquetados con compresores como Arc, Lha, Zip, Zoo,… sin necesidad de recordar la sintaxis de la línea de comandos de estos compresores. El programa es muy intuitivo, dispone de dos paneles principales junto a varias opciones para su configuración. En uno de los paneles principales localizado en la zona izquierda puedes seleccionar el archivo comprimido y con un simple clic descomprimir su contenido en el directorio que hayas seleccionado en el panel derecho. Puedes también añadir o extraer archivos sueltos, independientemente del sistema de compresión utilizado.

Puedes descargar ACP desde el sitio Web de Dilwyn Jones (http://www.dilwyn.me.uk/arch/index.html). El paquete original del ACP sólo contiene el gestor que actúa como “front end”, los compresores en sí mismos (“back end”) los debes descargar aparte. También en el sitio de Dilwyn puede econtrar el fichero “Archivers” el cual contiene las últimas versones de Arc, Lha, Lhq, Zip, Unzip y Zoo junto con su documentación y listos para usar con ACP (versión 2.3 o superior).

A continuación se muestran algunas capturas de pantallas:

ACP (Panel principal

ACP (Panel principal)

ACP (Opciones)

ACP (Opciones)

ACP (Ayuda)

ACP (Ayuda)

Se ha iniciado una campaña en favor de la ciencia en España y en contra de los recortes de cerca del 15% en I+D+I de los próximos presupuestos generales del estado.

¡¡¡Como amantes de los ordenadores, y las ciencias en general,  debemos arrimar el hombro!!!

Según la ministra, «no hay recorte… hay austeridad, contención, medidas constrictivas, ajuste, disminución en algunas partidas…» Según el promotor de esta campaña, «se trata  de recortes estructurales por la coyuntura económica actual que dejan la Ciencia a merced de los “remanentes”. En resumen, como hay crisis vamos a recortar a to quisqui. Pero no es tijeretazo, porque ya sacaremos de donde vaya sobrando.»

Puedes seguir las novedades de esta campaña mediante la etiqueta #TijerasNO o vía @TijerasNO en Twitter http://twitter.com/TijerasNO y en Facebook: http://www.facebook.com/group.php?gid=144715368875

A estas horas, ya son más de 500 blogs y más de 3.000 personas en Facebook los que se han unido a la campaña.

Usa la imagen siguiente en tu web o blog. Difunde esta campaña mediante el pásalo.

TijerasNO

Algunos enlaces con información de interés:
Web de la campaña. La aldea irreductible: http://bit.ly/35qo2R
La ciencia, víctima del presupuesto http://bit.ly/1RtDuT
Gabilondo cree “inquietantes” los recortes en Ciencia http://bit.ly/fgsA2
Margarita Salas: “Los jóvenes científicos sufrirán” http://menea.me/gq29
Carta abierta de científicos españoles al Gobierno http://menea.me/gpg9
El espejismo de la ciencia en España: http://bit.ly/zezsu
Entrevista íntegra a Cristina Garmendia en ‘Hoy por Hoy’ http://bit.ly/15mggG
En busca de las tijeras… http://bit.ly/UwNWx