(Parte I: La teoría)

Por Francisco Javier Rodríguez

Dicho formato se utiliza para que los ficheros sean compatibles con programas diferentes al que se utilizó para crear dicho fichero; de esta forma es factible utilizar ficheros creados con programas gráficos como el Deluxe Paint desde otros programas gráficos.

Este es sin lugar a dudas el camino normal que usan la mayoría de los usuarios, sin embargo no todos los ficheros tienen por qué ser compatibles. Un claro ejemplo, en la búsqueda de la incompatibilidad de los ficheros gráficos, son los videojuegos. En estos tipos de programas no sólo se protege el código o ruinas de 'personas ajenas', sino que también se esconden todos los gráficos que intervienen en el programa tras un formato encriptado. Por supuesto siempre hay juegos que no siguen esta regla.

En este artículo nos centraremos en crear y ver las rutinas necesarias para convertir ficheros gráficos ILBM en ficheros sin formato definido (comúnmente llamados RAW Data). Dichos ficheros suelen ser por lo general más extensos que los ficheros de formato, ya que los datos almacenados en estos últimos han sido comprimidos mediante el logaritmo BYTE RUN 1.

Para que las prestaciones del sistema que se va a utilizar a continuación, sean más efectivas que las ofrecidas por el formato ILBM, también se crearán las rutinas encargadas de comprimir los datos; para que de esta forma se ahorre una sustancial cantidad de memoria de disco.

Por último, para aplicar una utilidad a los nuevos ficheros, también se verán las rutinas encargadas de descomprimir y visualizar posteriormente los dibujos. Para ello los ficheros gráficos a comprimir deberán ser exclusivamente ILBM, con unas características que se describirán posteriormente.

Los ficheros sin formato ofrecen una ventaja principal sobre los ficheros ILBM, y es que los primeros son más rápidos de cargar y visualizar que los segundos; ya que la estructura en la que se encuentran constituidos los ficheros sin formato, permiten leer los datos y transferir estos a pantalla sin la necesidad de realizar continuas comprobaciones.

El lenguaje en el que están escritas estas rutinas es el Ensamblador; con lo cual será imprescindible que posea un macroensamblador para el ensamblado y posterior linkaje de las rutinas en cuestión. El funcionamiento de las rutinas es compatible con los Amiga 500, 2000 y 2500. Para los que deseen utilizar el 'visualizador' de pantallas desde el Basic, también se explicarán los pasos que deberán realizar para que ello sea posible. Pero a continuación pasaremos a centrarnos en el artículo.

IFF vs RAW DATA

En muchas ocasiones es necesario salir de la estandarización del Amiga, ya que puede ocurrir que ésta no sea de su interés debido a diversos motivos. Por ejemplo en este caso, quizá desee que los gráficos que usted ha creado, sean exclusivamente de uso privado; o bien que estos no puedan ser modificados posteriormente mediante algún programa gráfico. Para ello el único camino es la creación del programa necesario para convertir el fichero IFF en un fichero con otro formato en concreto; o simplemente sin formato. Personalmente no conozco ningún programa gráfico que ofrezca otra opción de almacenamiento, salvo el IFF transformer; con el cual se pueden realizar diversas operaciones de carácter gráfico. Dicho programa circula bajo el dominio público, con lo cual no supone una gran dificultad encontrar dicho programa.

Las rutinas que se muestran en este artículo, son un simple ejemplo de la forma en la que posteriormente usted puede construir sus propios ficheros encriptados. De esta forma, mediante la realización de sus propias rutinas, los ficheros quedarán vetados a todas las personas que no conozcan el formato de almacenamiento.

El formato IFF ya se trató con anterioridad desde las páginas de Commodore World (concretamente en los números 43 y 50), sin embargo a continuación se verán las principales características que definen este formato gráfico.

La primera de las características de un fichero compatible, es que la estructura interna de éstos se encuentra dividida en diversos campos o 'Chunks'. Cada uno de estos campos tiene un cometido, siendo generalmente el de contener un grupo de datos comunes. Todos ellos llevan al comienzo una marca identificativa, con lo cual se sabrá posteriormente de qué tipo de fichero se trata; es decir si es un fichero que contiene, por ejemplo, la definición de un instrumento, texto, o un dibujo.

También es muy común que los datos de un fichero gráfico IFF se encuentren comprimidos mediante el método anteriormente citado, de esta forma se consigue consumir menos memoria de disco. La estructuración en este tipo de ficheros es evidente, ya que se pueden encontrar perfectamente agrupadas cada una de las informaciones; de esta forma, si se desea, se puede acceder sólo a una de las informaciones en cuestión, ya que se sabe perfectamente dónde se encuentran posicionadas cada una de ellas.

Actualmente circulan por varios medios los documentos creados por Electronic Arts sobre el formato IFF. En dichos documentos (frecuentemente incluidos en los discos de dominio público), se explica extensamente la estructura del fichero en dicho formato, significado de las cabeceras, orden de los Chunks, etc... Dichos documentos también se encuentran recompilados en gran cantidad de libros, como por ejemplo el Rom Kernal Manual: Includes & Autodocs de la editorial Addison Wesley.

Dicha divulgación se ha realizado con el principal propósito de ofrecer una mejor documentación a los programadores, los cuales mediante la utilización de este formato en sus productos, son quienes realmente hacen posible la compatibilidad de estos ficheros con la casi totalidad de los programas.

Por otro lado se encuentran los ficheros Raw Data. En estos ficheros no se puede hablar de un formato en concreto, ya que este dependerá únicacmente de la estructura seleccionada por el usuario a la hora de realizar las rutinas para la formación del fichero en cuestión.

Los ficheros Raw Data más simples son aquellos en los que la información se encuentra organizada de la siguiente forma:

Suponiendo que el formato de la pantalla se encuentre en baba resolución no entrelazada, con el sistema PAL (320 x 256), utilizando 4 planos (16 colores), la longitud total de un fichero sería de (320*256)*4 = 8192*4 = 32768 Bytes.

La forma de grabar estos datos (32768) a fichero se realizaría con un método muy simple. Primero se grabarían los datos correspondientes a la primera fila del primer plano, a continuación la segunda fila del primer plano, y así consecutivamente hasta llegar a la última de las filas del primer plano; a partir de este punto se realizará la misma operación con el segundo plano y así consecutivamente hasta completar el total de los planos de los que consta el gráfico.

De todas formas un fichero Raw Data no tiene por qué fijarse a este tipo de estructura. Por ejemplo, en la mayoría de los casos, se incluyen en el mismo fichero la información del color y resolución de la pantalla, todo ello para realizar más fácilmente el proceso de recuperación de los datos sobre un formato original de pantalla.

Existe también un formato de ficheros muy similares a los Raw Data, estos ficheros reciben el nombre ACBM. Dichos ficheros se pueden describir como una intersección entre el IFF y el Raw Data, pues aunque su estructura interna sitúe la información de los planos de la misma forma que los ficheros Raw Data, éstos también poseen marcas identificativas, conteniendo a su vez diversas informaciones.

' Programa Show Raw Data
'
' (c) 1990 by Amiga World
'
' (c) 1990 by F. Javier Rodríguez
exec       = 4
clear      = $10002
allocmem   = -198
freemem    = -210
openlib    = -408
open       = -30
read       = -42
tamano     = $8000
existe     = 1005
init:
     move.l    4,a6
     move.l    #tamano,d0
     move.l    #clear,d1
     jsr       allocmem(a6)
     move.l    d0,baseplano
     beq       fin
     lea       nomlib,a1
     moveq     #0,d0
     jsr       openlib(a6)
     move.l    d0,baselib
     beq       fin
     move.l    d0,a6
     move.l    #filename,d1
     move.l    #existe,d2
     jsr       open(a6)
     beq       fin
     move.l    d0,filehandle
     move.l    d0,d1
     move.l    #buffer,d2
     move.l    #tamano,d3
     jsr       read(a6)
     jsr       initstuff
     move.l    #$4000,d0
     lea       buffer,a0
     move.l    baseplano,a1
la1  move.w    (a0)+,(a1)+
     dbra      d0,la1
loop btst      #6,$bfe001
     bme.s     loop
     jsr       copend
     move.l    4,a6
     move.l    baseplano,a1
     move.l    #tamano,d0
     jsr       freemem(a6)
fin  rts
initstuff
     clr.l     d0
     move.l    baseplano,d1
     move.w    #$00e0,d2
     move.w    #3,d4
     lea       planos,a0
makecop
     move.w    d2,(a0)+
     swap      d1
     move.w    d1,(a0)+
     add.w     #2,d2
     move.w    d2,(a0)+
     swap      d1
     move.w    d1,(a0)+
     add.w     #2,d2
     add.l     #$2000,d1
     dbf       d4,makecop
     move.w    #$20,$dff09a
     move.w    #-$7c80,$dff096
     lea       copper,a1
     move.l    a1,$dff084
     clr.w     $dff08a
     rts
copend
     move.w    #-$7fe0,$dff09a
     move.w    #$8000,$dff096
     rts
     cnop 0,2
copper      dc.w  $0100,%0100000000000000
planos      ds.w  16
            dc.w  $008e,$2c81,$0090,$2cc1
            dc.w  $0092,$0038,$0094,$00d0
            dc.w  $0108,$0040,$010a,$0040
            dc.w  $0180,$000f,$0182,$0eee
            dc.w  $0184,$0bbb,$0186,$0243
            dc.w  $0188,$0499,$018a,$0feb
            dc.w  $ffff,$fffe
coplong     dc.w  $0
baseplano:  dc.l 0
baselib:    dc.l 0
nomlib:     dc.b "dos.library",0
filename:   dc.b "df0:prueba.pc",0
     even
buffer:     dc.w $8000
     even
     end

Dicho formato (ACBM), fue concebido para el manejo de gráficos desde el AmigaBasic, ya que el proceso de carga y grabación, se realiza de una forma más rápida. Otro punto en su favor es que dichos ficheros no se encuentran comprimidos mediante el método Run Byte 1. Todos los usuarios de Amiga podrán encontrar un ejemplo práctico de estos ficheros en el disco de Extras, correspondiéndose con los programas LOAD ACBM e ILBM ACBM.

El primero de los programas se encarga exclusivamente de cargar pantallas gráficas que se encuentren bajo este formato; el segundo de ellos es en realidad un conversor que toma ficheros ILBM y almacena la pantalla gráfica de nuevo a un fichero, pero en esta ocasión bajo el formato ACBM. Para los usuarios que realicen habitualmente sus programas en Basic, esta utilidad les resultará de gran ayuda.

Si un fichero Raw Data incluye la información sobre resolución (también pueden incluirse otros parámetros), se preguntarán la diferencia que existe sobre los ficheros IFF. Pues bien, la principal diferencia es la eliminación de los Chuncks, además de almacenarse los datos del gráfico de una forma distinta al proceso realizado en los ficheros IFF y el no saber de una forma precisa dónde se encuentra situadas las informaciones sobre cada cosa.

También existen otras diferencias, como la de que un fichero Raw Data no tiene por qué seguir la estructura de otro fichero Raw Data, con lo cual la incompatibilidad de ficheros está asegurada (Recuerde que esta es la principal función de los ficheros Raw Data). Además de almacenar la información de una forma distinta al IFF, también se pueden realizar diversas operaciones con los datos (además del proceso de compresión). Por ejemplo la operación más interesante es la del encriptado de fichero.

Encriptar: otra forma de 'ver' las cosas

Seguramente ésta no es la primera vez que se encuentra con la palabra 'encriptar'. Tras dicha palabra se encierra un proceso que puede llegar a ser bastante complejo, y que tiene como objetivo la codificación de los datos reales de un fichero.

El propósito está bastante claro, ya que mediante este proceso se evita que los datos, considerados importantes, puedan ser utilizados correctamente por otra persona.

Los procesos de encriptación más sencillos suelen utilizar una máscara, que al ser aplicada a un dato desvirtuará el valor original de este. De esta forma si el fichero cae en manos de personas ajenas, la información que contiene el fichero no será la real y por tanto no será útil para trabajar con ella correctamente.

La máscara que se aplica a un dato puede ser cualquier valor elegido por el usuario. la forma con la cual se desvirtuará el valor original del dato, es mediante la aplicación de una operación lógica (AND, OR, NOT, etc.) con la máscara sobre el dato en cuestión.

Como ejemplo de la función de la máscara, se puede contemplar el siguiente supuesto:

Asignaremos como valor real al dato el Byte #%11001100.

— Se aplicará la operación lógica NOT.
Mascará:
MOVE.B #%11001100,D0
NOT.B D0

— Resultado de la operación:
D0 = #%00110011

Como habrán podido observar, esta es una forma extremadamente sencilla de 'enmascarar' un dato, ya que simplemente se efectúa el complemento a 1 del dato; en dicho dato el valor resultante no se corresponde con el original, por lo que el dato no será operativo.

Si bien en este ejemplo se ha realizado el proceso de encriptado del dato con una sola máscara, también se pueden aplicar varias máscaras sucesivamente a un solo dato, como también varias operaciones lógicas.

Como habrán podido deducir, un programa encriptador debe llevar asociado un programa desencriptador, el cual será el encargado de transformar el fichero encriptado a su estado original, es decir volver a hallar el valor original de los datos.

Dicha rutina, complementaria a la anterior, se encuentra habitualmente en el mismo programa que contiene la rutina compresora; de lo contrario no se podrían cargar los ficheros que han sido grabados mediante el proceso de compresión.

En este caso, y siguiendo el ejemplo anterior, bastaría con aplicar la misma operación lógica (NOT) con el dato enmascarado para de esta forma obtener de nuevo el valor real del mismo, y por consiguiente operar de una forma efectiva con éste.

— Valor enmascarado del dato = #%00110011.

— Se aplicará la función lógica NOT.
MOVE.B #%00110011,D0
NOT.B D0

Tras este proceso se obtendrá, como dato real, el valor #%11001100. COmo podrán comprobar, este es efectivamente el valor real que se asignó al comienzo.

Un aspecto que se deberá contemplar, es la pérdida de velocidad en el proceso de carga y desencriptado: en este supuesto los cálculos necesarios para el proceso de desencriptado son inapreciables, en lo que se refiere a velocidad de proceso. La pérdida de velocidad es debida a los cálculos que hay que hacer para hallar el valor real del dato que se toma del fichero. El tiempo que se tardará en desencriptar un fichero completo, dependerá fundamentalmente de lo complejo que haya sido el proceso de encriptación; pues a mayor complejidad, será necesario realizar un mayor número de operaciones con los datos en cuestión.

Una vez los datos han sido desencriptados, ya se podrá trabajar correctamente con éstos; en nuestro caso mostrar una pantalla gráfica.

Del concepto a la pantalla

Hasta ahora sólo se ha visto, de una forma más o menos global, las características, rutinas que se han de crear o simplemente las peculiaridades de los formatos. A continuación, el siguiente paso que se debe dar, es el de la transformación de los conceptos en el programa para el Amiga, o conjunto de rutinas encargadas de realizar las diferentes funciones.

Como ya sabrán la mayoría de los usuarios dedicados a la programación, el Amiga es un ordenador relavamente fácil de programar. Primero han de seleccionarse las librerías que han de llamarse, así como la forma en la que se desea realizar el programa. Lo 'malo' del Amiga es precisamente que se trata de un ordenador muy completo con cantidad de posibilidades, pero es precisamente esta capacidad lo que a la hora de programar implica una mayor complejidad. Estas son algunos de los problemas que se solucionarán en la segunda parte de este artículo; la cual también contendrá el total de los programas mencionados al inicio.