Vida antes del Kenbak-1: Heathkit EC-1, o que es un ordenador analógico

Entradas relacionadas: Simon (1950), Geniac (1955), Heathkit EC-1 (1960), Minivac 601 (1961), Digi-Comp I (1963), DEC PDP-8 (1965), Paperclip Computer (1967), Honeywell Kitchen Computer (1969), Imlac PDS-1 (1970).

Índices: El camino al O.P.       Historia de la Informática

---

Estamos acostumbrados a los ordenadores digitales, aquellos en los que las magnitudes con las que trata se representan como ceros y unos, lo que físicamente se representa por que exista o no electricidad, y su componente básico es la puerta lógica, construida con relés, lámparas o transistores, que actualmente se encapsulan en un chip. Los ordenadores trabajan ejecutando programas en su memoria mediante un procesador, que usa micro-programación actualmente, aunque los primero usaban lógica cableada, pero eran mas calculadoras programables que ordenadores.

El ordenador analógico es muy diferente, trabaja operando con voltajes variables en un rango continuo, y puede operar sumando, restando, multiplicando o dividiendo entre si esos voltajes, usando para ello un componente llamado amplificador operacional, construido con lámparas o transistores, que actualmente se encapsula en un chip. No ejecutan un programa como tal, solo se unen los amplificadores operaciones para operar con los voltajes, usando lógica cableada únicamente. Todo ello de manera casi inmediata.

Su uso principal era por los ingenieros, para comprobar elementos como los condensadores y para probar los diseños y testear los fallos, pero su capacidad de ejecutar cálculos matemáticos rápidos tuvo un uso práctico muy temprano, anterior al de los ordenadores digitales. Para disparar un torpedo un submarino debe hacer un cálculo de distancia, velocidad y rumbo del barco al que disparar, y en función del rumbo y velocidad de submarino y de la velocidad del torpedo, usando trigonometría y física elemental, se calcula el ángulo en que se debe disparar. Se disparan varios torpedos con pequeñas diferencias en los ángulos para compensar los errores de la estimación y el posible desvío de las corrientes. Este cálculo en la primera guerra mundial se hacía mediante reglas de cálculo, y en la segunda con un ordenador analógico al que los alemanes denominaban TZR

TZR del U-564 (Fuente: tvre.org)

La Heath Company es una empresa creada en 1926, y todavía en activo, especializada en material para la ingeniería electrónica. Produjo material en forma de kits entre 1947 y 1992, principalmente aparatos de radio, en una gama a la que denominó HeathKit, muy difundida en su momento por su alto nivel de calidad. Aunque la compañía continua en activo ha pasado por muchos altibajos, quedando en el 2000 al borde del cierre, y ha cambiado de propietarios varias veces desde entonces. Actualmente su mercado principal es el educativo, y ha vuelto a entrar en el mercado de los kits, dispone de algunos en venta, pero también vende los manuales de sus antiguos kits.

El EC-1 (Fuente: technikum29.de)

En 1956 lanza el H1, un monstruo que dispone de 70 lámparas, 45 ubicadas en su exterior por temas de calor, un aparato potente y de muy buena calidad, pero muy caro, por lo que en 1960 lanza el EC-1 Educational Analog Computer, a un precio muy ajustado los aficionados podían disponer de una herramienta de calidad, que podían adquirir tanto en kit como montado. En su interior había nueve amplificadores operacionales a lámparas y dos fuentes de alimentación, una proporcionaba +300 y -300 voltios para el manejo de las lámparas, y una variable de entre +60 y -60 voltios a 25 miliamperios. La fuente variable proporcionaba los voltajes que se podían interconectar entre sí y ajustar mediante contactos, potenciómetros y conmutadores en su panel frontal. El voltímetro podía conectarse a cualquier punto para verificar el voltaje en dicho punto, y las numerosas tomas permitían su uso junto a un osciloscopio para analizar las señales. Los operacionales trabajaban pudiendo realizando operaciones en un rango de entre 15 por segundo hasta una cada 10 segundos.

Interior de un EC-1 restaurado. (Fuente: https://www.nutsvolts.com)

Su interior es muy espartano con el chasis metálico usual en la época, sobre el aparecen los 9 tubos de los operacionales, dos transformadores y varios tubos forman las dos fuentes del aparato. Por debajo del chasis se sitúan condensadores, resistencias y un montón de cables. Al fondo se ve el frontal con sus conectores. Todo esto alcanzaba un peso de 21 kilos.

Los amplificadores trabajaban en bucle abierto, con una ganancia máxima de 1000, pudiendo manejar voltajes en el rango de -60 a +60 voltios, aunque solo soportaban señales de unos pocos miliamperios.

Como vemos, no es un ordenador como tal, es un computador, pero ayudó mucho a los aficionados en el diseño y montaje de los ordenadores posteriores.

Vida antes del Kenbak-1: El GENIAC, o como construir un ordenador sin electrónica

Entradas relacionadas: Simon (1950), Geniac (1955), Heathkit EC-1 (1960), Minivac 601 (1961), Digi-Comp I (1963), DEC PDP-8 (1965), Paperclip Computer (1967), Honeywell Kitchen Computer (1969), Imlac PDS-1 (1970).

Índices: El camino al O.P.       Historia de la Informática

---

En la entrada anterior hablé del Simón, el ordenador electro-mecánico a relés diseñado por Edmund Berkeley, uno de los padres de la ciencia de los ordenadores.

Junto a Oliver Garfield diseñaron un curioso "juguete" (ya que lo es, aunque también es algo mas que eso). El Geniac fue comercializado por Berkeley Enterprises entre 1955 y 1958, luego se separaron ambos creadores, Garfield lo siguió comercializando hasta mediados de los 1960, mientras que Berkeley hizo algunos cambios y lo vendió con otros nombres, por eso lo podemos encontrar como:

• Geniac (Genius Almost-Automatic Compute, Genio Casi-Ordenador automático, aunque también se le menciona como acrónimo de Genius y de Eniac, nombre del primer ordenador americano)
• Tyniac (Tiny Almost-Automatic Computer, Pequeño Casi-Ordenador automático)
• Weeniac (Weeny Almost-Automatic Computer, Pequeño Casi-Ordenador automático), del que solo se fabricaron 60 unidades
• Brainiac (Brain-Imitating Almost-Automatic Computer, Imitador-de-Cerebro Casi-Ordenador automático), que no hay que confundir con el Súper-Villano de los comics del mismo nombre.

Manual del Geniac (Fuente: blinkenlights.com)

Consistía en un tablero base y un conjunto de seis discos giratorios construidos con Masonita, un tipo de madera aglomerada con apariencia de cartón, en la parte posterior de los discos disponía de una serie de ubicaciones donde se podían insertar unos contactos metálicos. En el tablero base del equipo se insertaban los discos en ubicaciones que les permitían girar libremente, y sus insertos metálicos podían contactar con unos remaches de latón en la base, que se podían cablearse entre sí para formar los circuitos, y a través de la corriente suministrada por unas pilas podían iluminar una serie de bombillas de linterna.

Un Geniac en su caja sin montar, con todos sus elementos y sus manuales (Fuente: vintagecomputer.net)

Con esta configuración tan básica Geniac era capaz de simular circuitos de lógica combinacional, en el que sus salidas dependían solo de las entradas conectadas. Sin ningún elemento electrónico ni motores, sin ningún tipo de memoria, sin elementos de lógica binaria, aun así era un buen entrenador permitiendo crear de manera sencilla máquinas de estados, aunque los cambio de uno a otro estado se debía realizar de forma manual girando los discos en función de las instrucciones del circuito y del estado de las bombillas, lo que en ciertas máquinas de estados un poco mas complejas era bastante lioso.

El aparato se acompañaba de un libro de instrucciones que explicaba el aparato y su manejo, y de otro libro con varios circuitos, todos con los diagramas de cableado, las posiciones de los puentes y las instrucciones de manejo de la "máquina" construida, desde las mas básicas hasta otras con ecuaciones booleanas mas complejas.

Un circuito de ejemplo era una máquina detectora de una cualidad de algo que pudiera tener dos posibles, como masculino y femenino, animal o mineral, etc. Se definían cinco preguntas con dos posibles respuestas cada una, se construía y cableaba el circuito, y se ubicaban los discos en la respuesta a cada pregunta, el circuito contaba cuantas respuestas de cada tipo se habían dado y seleccionaba la que mas tuviera para dar el resultado, iluminando una u otra bombilla.

Anuncio en la revista "Ciencia popular" de Oct/1957 (fuente: blinkenlights.com)

Se publicitó mucho en revistas de la época de todo tipo, por ejemplo en "Galaxy Ciencia ficción", y es un preciado objeto para los coleccionistas de ordenadores actuales. Podéis encontrar aquí información y ejemplos de circuitos, aunque en inglés.

Vida antes del Kenbak-1: El Simon, relés y mas relés

Entradas relacionadas: Simon (1950), Geniac (1955), Heathkit EC-1 (1960), Minivac 601 (1961), Digi-Comp I (1963), DEC PDP-8 (1965), Paperclip Computer (1967), Honeywell Kitchen Computer (1969), Imlac PDS-1 (1970).

Índices: El camino al O.P.       Historia de la Informática

---

Según una votación que se realizó por el Computer History Museum, el título de primer ordenador personal se le dio al Kenbak-1 que se comercializó en 1971. Esta máquina era un ordenador  operativo completo, con la estructura básica de un ordenador, 255 bytes de memoria, varios registros y un conjunto variado de operadores. No era una idea plasmada en un libro o una revista, no era un kit para expertos en electrónica, era un equipo montado, funcional, perfectamente programable, con un juego de instrucciones básico pero completo, y completamente operativo.

Antes de que surgiera la primera forma de vida que podemos reconocer como tal, tuvieron que surgir formas rudimentarias incompletas, que evolucionaron, se unieron y formaron la primera célula. De igual manera, antes del Kenbak-1 existieron una serie de máquinas que podemos decir son los antecedentes de un ordenador personal, aunque no llegaban a serlo, por lo que en estas entradas quiero hablar de ellas y rendirles su merecido homenaje como pioneros de un mundo desconocido en ese momento, son el electro-mecánico Simon de 1950, del mismo autor y aunque no era un ordenador como tal el Geniac de 1955, el ordenador analógico a lámparas Heathkit EC-1 de 1959, el entrenador de electrónica digital Minivac 601 de 1961, el  descrito en un libro Paperclip Computer de 1967 (que fue construido posteriormente por una empresa en 1969), y aunque no eran ordenadores personales sino minis quiero mencionar también tres máquinas que influyeron en el momento, el DEC PDP-8 de 1965, el no fabricado Honeywell Kitchen Computer de 1966, y el Imlac PDS-1 de 1970.

En el libro guinnes de los records (igual de fiable que la Wikipedia en general) aparece esta entrada:

"El primer ordenador personal (PC), conocido como Simón, fue lanzado en 1950. Fue vendido al por menor por 600 Dólares, y tenía una memoria de seis palabras de 2 bits, disponiendo de 12 bits de memoria total. Fue desarrollado por Edmund Berkeley (EE.UU.). El Simon también es conocido como el cerebro mecánico Simon y el ordenador personal electromecánico Simon. Berkeley esbozó la idea del equipo Simon en su libro de 1959 "Giant Brains, or Machines That Think" (Grandes cerebros, o máquinas que piensan), pasando a desarrollar sus teorías en una serie de 13 artículos publicados entre 1950 y 1951 en la revista Radio-Electronics."

El Simón en la portada de Radio Electronics de octubre de 1950 (fuente: blinkenlights.com)

Al simón se le designa como computador electro-mecánico, ya que estaba construido con relés como componentes digitales, realmente le faltaban varios elementos para ser un ordenador personal como tal, aunque eso no le quita el mérito real de abrir el camino a que los aficionados pudieran experimentar con esa nueva rama de la ciencia que estaba surgiendo. La descripción publicada en 13 artículos de la revista Radio Electonics era mucho mas amplia que la máquina en sí, solo los 6 primero textos eran sobre la máquina de relés, el resto eran ampliaciones con ideas sobre máquinas electrónicas con tubos de vacío, y en general se correspondía con el contenido del libro. Luego la empresa que fundó Berkeley diseñó y construyó una máquina que se vendía como un Kit de montaje por unos 600$.

El simón, se ven todos sus relés (fuente: cedmagic.com)

Basada físicamente en 80 relés de dos y cuatro polos, a la unidad había que añadir una fuente de alimentación externa y una lectora/perforadora de cinta de papel para que funcionara. Se decía que era personal pues lo podías llevar en una mano (difícil por el peso, y mas cuando en la otra debías cargar con la fuente de alimentación y la perforadora).

Los programas estaban escritos en la cinta de papel, la unidad de cinta leía el programa y la máquina luego ejecutaba las instrucciones secuencialmente. La unidad de relés formaba por 6 registros binarios de dos bits cada uno (valores posibles 0, 1, 2 y 3 únicamente), mas la Unidad Aritmético/Lógica que era capaz de realizar cuatro operaciones únicamente: suma, negación, comparar con mayor que, y seleccionar registro, pero no disponía de instrucciones de salto por ejemplo. Para la salida disponía de 5 bombillas indicadoras, o con modificaciones se podía grabar en la cinta. La entrada de datos se podía realizar desde 5 teclas en el frontal, o desde la propia cinta. con ampliaciones la cinta podía usarse también como memoria intermedia.

Como veis, su capacidad era tan baja con solo 2 bits y 4 instrucciones, que es mas un entrenador que otra cosa. Se vendía como un Kit que costaba 600$, del que se vendieron unos 400, y se conocen aficionados que la ampliaron y publicaron esquemas de ello, lo que se conoce como los modelos Simon II y Simon III.


El libro se puede conseguir en PDF gratuito ya que ha pasado a dominio público, por ejemplo en Archive, y también hay ejemplares en venta en (al menos a fecha de 27/05/16) en Amazon. En el se mencionan todos (literalmente) los ordenadores operativos en ese momento, ya que se podían contar con los dedos en aquel momento.

Mucha mas información, incluyendo algunos esquemas, programas, descripciones y simuladores del Simón los podeis encontrar en The University of British Columbia, de Canadá

Cómo escribir juegos para el ZX Spectrum. Apendice

Índice de entradas

Esta serie de artículos han sido traducidos a partir del documento "How to Write ZX Spectrum Games" con permiso de su autor, Jonathan Cauldwell, un gran desarrollador de juegos para el Spectrum, os recomiendo visitar su Web donde está el texto original. El documento original, y por tanto esta traducción, tiene © Jonathan Cauldwell y solo puede duplicarse con permiso expreso por escrito de su autor.

---

Direcciones útiles de ROM y RAM

ROM

    0: inicio de la ROM.
  654: rutina ROM que devuelve la tecla pulsada (0-39) en el registro e,

       o 255 si nada presionado.
  949: rutina BEEPER.  Ajustar la duración en DE y el tono en el HL.
 3503: rutina para borrar la pantalla, estableciendo el color en (23693).
 6683: muestra en pantalla el valor numérico del par de registros BC, 

       hasta un valor máximo de 9999.
 8252: muestra en pantalla una cadena de longitud BC ubicada en la dirección DE.
 8859: rutina para configurar el color del borde con el valor del acumulador.
15616: dirección de las fuentes en la ROM, 96 caracteres * 8 bytes.

RAM. Zona de pantalla

16384: 256x192 zona de pixeles.
22528:  32x24  zona de atributos de color.

RAM. Zona de variables

23296: variables del sistema.
23606: puntero a las fuentes, menos 256. (256 = 32 * 8 bytes, 32 es el código 

       para el primer carácter imprimible)
23560: código ASCII de la última tecla pulsada.
23672: reloj, se incrementa 50 veces por segundo.
23693: PAPER/INK/BRIGHT color.
23695: PAPER/INK/BRIGHT color.
23734: canales de E/S.
23755: área del BASIC, seguido de espacio para programas en código máquina. 

       Si usas hardware adicional puede moverlo.
24000: Podría decirse que es el punto de partida realista mas bajo para 

       un juego, permitiendo 41536 bytes.
32767: último byte de RAM en un Spectrum de 16K.
32768: Principio de la zona no contenida, la RAM más rápida.
65535: último byte de RAM en un Spectrum de 48K.

Cómo escribir juegos para el ZX Spectrum. Capítulo 19

Índice de entradas

Esta serie de artículos han sido traducidos a partir del documento "How to Write ZX Spectrum Games" con permiso de su autor, Jonathan Cauldwell, un gran desarrollador de juegos para el Spectrum, os recomiendo visitar su Web donde está el texto original. El documento original, y por tanto esta traducción, tiene © Jonathan Cauldwell y solo puede duplicarse con permiso expreso por escrito de su autor.

---

Diseño de juegos

Cincuenta por cien Arte, Cincuenta por cien Ciencia

Ahora ya debes tener suficientes conocimientos para ser capaz de juntar las instrucciones para formar el motor de un juego. Felicitaciones, ahora conoces el cincuenta por ciento de la manera de escribir un juego. Este capítulo tiene como objetivo hacer frente a la otra mitad. Es fácil caer en la trampa de pensar que la escritura de un juego es tan simple como aprender cómo ordenar una enorme variedad de instrucciones en una secuencia coherente, con el fin de llevar a cabo un gran plan. El aspecto técnico es, por supuesto, esencial. Sin embargo, un buen desarrollador de juegos tiene que ser mucho más que un técnico especializado. Tiene que ser también un artista. Eso no significa que debas ser un artista de los gráficos, aunque estos deben ser agradables visualmente no es a lo que me refiero. Estoy, por supuesto, hablando sobre el arte del diseño de juegos.

Se podría optar por seguir el camino de la técnica, escribit tu código para deslumbrar a otros "techies" que saben cómo funciona el Spectrum y lo que puede hacer normalmente. Sin embargo eso es poco probable que impresione a todo el mundo. Para empezar, el juego puede parecer increíble pero podría ser aburrido de jugar y no mantener la atención más de cinco minutos. Lo que es más, no todos los fans del Spectrum conoce las limitaciones de la máquina. Si realmente deseas maximizar tu audiencia, necesitas apelar a los que no saben ni le importa lo que el Spectrum puede hacer. Considera esto: imagina que dos programadores de Commodore 64 liberan sus juegos el mismo día. Uno de ellos escribió un clon del Space Invaders, que sorprendió a los chicos mas técnicos de la escena de Commodore, y el otro escribió un juego técnicamente nada especial pero adictivo, diferente a todo lo que se ha visto antes. Como propietario de un Spectrum que tienes poco conocimiento de los límites de hardware del C64, ¿a cual sería más probable que echaras un vistazo? Los clones del Space Invaders pueden mostrar una increíble magia técnica para esa máquina, pero ¿no es probable que no veas nada que no hayas visto antes en algún otro formato? Consideremos ahora ese escenario al revés: ¿por qué un fan de Commodore, Amstrad, Acorn u Oric quiere descargar tu juego? ¿Que lo hace tan especial que no puedes encontrar algo similar o mejor en su máquina favorita?

Si deseas maximizar el interés, es buena idea ofrecer algo único.

Mecánicas de juegos

Escribir el código del programa es como hacer una gran construcción de Lego formada por miles de minúsculos ladrillos, las instrucciones individuales que dicen a la CPU qué hacer. La mecánica del juego es más afin a Duplo; piezas más grandes pero aún con infinitas maneras de reorganizarlas para alcanzar el efecto que deseas. Un enfoque para el diseño de juegos podría ser considerar los siguientes pasos.

En primer lugar, empieza por considerar el método de control del jugador. ¿Cómo se mueve? Piensa si se limita de alguna manera, y si es así, ¿cómo? ¿Será capaz de realizar acciones o completar tareas para aumentar o modificar su capacidad de maniobra de alguna manera? En líneas generales, cualquier método de control que puedas concebir probablemente ya se ha hecho antes, pero eso no debe impedir que te hagas estas preguntas y busques interesantes variaciones.

En segundo lugar, ten en cuenta las tareas que el jugador tiene que asumir. ¿Cuál es su objetivo? ¿Cómo alcanza la victoria? ¿Está disparando a cosas, procede a su recogida, las coloca en un lugar, previene que suceda algo? ¿Está moviendo cosas alrededor de la zona del juego con algún propósito? La respuesta a estas preguntas unidas con una técnica de control diferente es donde el juego puede empezar a diferenciarse de los innumerables juegos de plataformas, shoot-em-ups, juegos de laberinto o de puzle que hay desarrollados. Empieza de forma sencilla en un primer momento y ve añadiendo ideas a medida que avanzas. No tengas miedo de llegar a puntos donde ya no funciona, incluso si has pasado horas agonizando sobre tu código. Si una mecánica no funciona, no tiene cabida en tu juego.

El tercer paso es considerar los peligros que enfrentará el jugador. ¿Hay un tiempo límite? ¿Hay enemigos que se mueven por el juego? ¿Cómo se mueven, de manera predecible o de otra forma más interesante? ¿Son mortales al contacto o solo hacen que disminuya la energía del jugador? ¿Deben ser destruidos, deben evitarse o ambas cosas? ¿Cambian a medida que avanza el juego? ¿Se pueden utilizar de alguna manera?

Cuando hayas respondido a estas preguntas es necesario considerar si el jugador puede recoger pequeñas bonificaciones, o debe completar mini-tareas que le dan habilidades extra, aumentar su puntuación o su bonificación, aumentar vidas o ayudarlo de alguna otra manera. ¿Esto se debe lograr en un orden determinado para obtener una ventaja aún mayor? Puedes también explorar el camino contrario: ¿existen elementos que pueden ser recogidos que dificultan al jugador?, por ejemplo, con la inversión de sus controles o su fuerte desaceleración. Un error común (que he cometido yo mismo) es reducir las oportunidades de bonificación del jugador conforme el juego progresa. A medida que el juego se vuelve más difícil de jugar, generalmente es buena idea aumentar las bonificaciones con el fin de dar al jugador una oportunidad en el combate.

Si realmente quieres ir a la ciudad, es posible que desees añadir un poco más de profundidad. ¿Debe el jugador considerar una imagen más grande de la que ve en una sola pantalla? ¿Necesita pensar en algo mientras está esquivando, saltando o disparando? ¿Sus logros están llenando un mapa, o un cuadro? ¿Está jugando un juego gigante de tres en raya, de animal, vegetal o mineral, de batallas navales? ¿Puedes incluir elementos en el jardín mientras el jugador sigue su camino por su juego?

Juega mucho con tu juego mientras lo estás desarrollando y sigue haciéndote preguntas. Sé inseguro.

Cuando hayas hecho todo esto, es posible que desees considerar los gráficos, la historia o tal vez incluso la música. Evitar la tentación de comenzar con la historia cuando estás desarrollando un juego para una máquina de ocho bits que, simplemente, no tiene el manejo de gráficos o memoria suficientes para producir la atmósfera que haga justicia a una historia brillante. No vas a escribir el siguiente Grim Fandango. Adapta tu historia en torno al diseño del juego, y no al revés.

Por último, no importa lo bueno y original que sea tu juego, recuerda que no se puede contentar a siempre a todo el mundo. Simplemente disfruta de lo que estás haciendo, diviértete y no te lo tomes demasiado en serio.

¡Feliz desarrollo!

Cómo escribir juegos para el ZX Spectrum. Capítulo 18

Índice de entradas

Esta serie de artículos han sido traducidos a partir del documento "How to Write ZX Spectrum Games" con permiso de su autor, Jonathan Cauldwell, un gran desarrollador de juegos para el Spectrum, os recomiendo visitar su Web donde está el texto original. El documento original, y por tanto esta traducción, tiene © Jonathan Cauldwell y solo puede duplicarse con permiso expreso por escrito de su autor.

---

Juegos que carguen y se ejecuten automáticamente

Aunque esto es bastante simple para un programador experimentado en Sinclair BASIC, se trata de un área que se suele pasar por alto. En particular, los programadores que se han pasado al Spectrum desde otras máquinas no estarán familiarizados con la forma como se hace.

Para poder ejecutar una rutina en código de máquina tenemos que empezar desde el BASIC. Usando este escribimos un pequeño programa cargador básico, que reserva sitio para el código máquina, carga dicho código y luego lo ejecuta. El tipo más simple de cargador sería el contenido es estas líneas:

10 CLEAR 24575: LOAD ""CODE: RANDOMIZE USR 24576

El primer comando, CLEAR, establece la variable RAMTOP por debajo de la zona ocupada por el código máquina, de modo que el BASIC no lo sobrescriba. También borra la pantalla y mueve la pila fuera del camino. El número que sigue por lo general debe estar un byte por debajo del primer byte de tu juego. LOAD ""CODE carga el siguiente archivo de código desde la cinta, y RANDOMIZE USR llama a la rutina en código máquina en la dirección especificada, en este caso 24576. Este debe ser el punto de entrada para tu juego. En un Spectrum, la ROM se encuentra en los primeros 16K, y va seguido por varias cosas como la memoria de video, las variables del sistema y del BASIC. Un lugar seguro para tu código es por encima de esta zona, en cualquier lugar hasta el final de la RAM en la dirección 65535. Solo con un pequeño cargador en BASIC a la dirección de inicio 24576, o incluso 24000, te dará un montón de espacio para su juego.

Este programa cargador se guarda a continuación en cinta con un comando como este

SAVE "name" LINE 10

LINE 10 indica que cuando termine de cargar, el programa en BASIC se auto-ejecuta desde la línea 10.

Después del cargador BASIC viene el archivo de código. Puedes guardar un archivo de código así:

SAVE "name" CODE 24576,40960

CODE le dice al Spectrum que guarde un archivo de código, en lugar de en BASIC. El primer número de después es la dirección de inicio del bloque de código, y el último número es su longitud.

Esto es bastante simple, pero ¿y si queremos añadir una pantalla de carga? Bueno, es bastante sencillo. Podemos cargar una pantalla utilizando

LOAD ""SCREEN$

Lo que esto va a hacer es cargar un bloque de código de 6912 bytes de longitud, al inicio de la dirección de pantalla en 16384. Poner el archivo de pantalla en memoria es un poco más complicado, ya que no podemos simplemente guardar la pantalla como un archivo ya que las dos líneas de la parte inferior se pueden sobrescribir con mensajes del tipo "Start tape, then press any key". Así que cargaremos nuestra imagen en otro punto de la memoria RAM, como 32768, para a continuación utilizar

SAVE "name" CODE 32768,6912

6912 es el tamaño de la RAM de pantalla del Spectrum. Cuando volvemos a cargar el bloque de cinta utilizando LOAD ""SCREEN$, estamos especificando que queremos forzar a que el archivo de código se cargue en la memoria de pantalla. En estas circunstancias, no importa donde se encontraba el archivo de código cuando se guardó.

Ahora tenemos otro posible problema: ¿el mensaje Bytes: name que se imprime antes de la carga del código no aparecerá tapando parte de nuestra pantalla? Bueno, sí que lo hará. Podemos superar esto pokeando en el flujo de salida.

POKE 23739,111

Esto hará el truco para nosotros. Así que nuestro cargador BASIC ahora se ve así:

10 CLEAR 24575: LOAD ""SCREEN$: POKE 23739,111: LOAD ""CODE: RANDOMIZE USR 24576

Cómo escribir juegos para el ZX Spectrum. Capítulo 17

Índice de entradas

Esta serie de artículos han sido traducidos a partir del documento "How to Write ZX Spectrum Games" con permiso de su autor, Jonathan Cauldwell, un gran desarrollador de juegos para el Spectrum, os recomiendo visitar su Web donde está el texto original. El documento original, y por tanto esta traducción, tiene © Jonathan Cauldwell y solo puede duplicarse con permiso expreso por escrito de su autor.

---

Interrupciones

La creación de tus propias interrupciones puede ser una pesadilla la primera vez que lo intentes, ya que es un asunto complicado. Con práctica se convierte en un poco más fácil. Para hacer que el Spectrum ejecute nuestra propia rutina de interrupción hay que decirle en que ubicación está nuestra rutina, poner la máquina en modo 2 de interrupción, y garantizar que las interrupciones están habilitadas. ¿Suena bastante simple? La parte difícil es decirle al Spectrum, donde se encuentra nuestra rutina.

Con la máquina en modo 2, el Z80 utiliza el registro i para determinar el byte alto de la dirección del puntero a la dirección de la rutina de servicio de interrupción. El byte bajo es suministrado por el hardware. En la práctica, nunca se sabe lo que va a contener el byte bajo, ¿ves el problema? El byte bajo igual podría ser 0, que podría ser 255, o que podría estar en cualquier posición intermedia. Esto significa que necesitamos todo un bloque de 257 bytes de punteros a la dirección de inicio de nuestra rutina de servicio. Como el byte bajo suministrado por el hardware puede ser par o impar, tenemos que asegurarnos de que el byte bajo y el byte alto de la dirección de nuestra rutina de servicio son idénticos. Esto limita seriamente donde podemos localizar nuestra rutina. También debemos localizar nuestra tabla de punteros y nuestra rutina sólo en la memoria RAM no contenida. No lo coloques por debajo de la dirección 32768. Incluso ubicándolo en la memoria RAM no contenida, como por ejemplo en el banco 1, producirá problemas en ciertos modelos del Spectrum. Personalmente, encuentro el banco 0 un lugar tan bueno como cualquier otro.

Digamos que elegimos la dirección 51400 como la ubicación de nuestra rutina de interrupción. Esto es válido ya que tanto el byte alto como el byte bajo son 200, ya 200*256+200=51400. A continuación, necesitamos una tabla de 129 punteros que apunten todos a esta dirección, o 257 veces DEFB 200, situada en el inicio de un límite de página de 256 bytes. Suponiendo que lo ponemos en lo alto del camino, podríamos empezar por 254*256=65024.

Debemos hacer esto

       org 51400

int    ; rutina de servicio de interrupción.


       org 65024

       ; punteros a rutina de interrupción.

       defb 200,200,200,200
       defb 200,200,200,200
       .
       .
       defb 200,200,200,200
       defb 200

¡Uf! Aún así, ahora llegamos a nuestra rutina de interrupción. Las interrupciones pueden ocurrir durante cualquier período, por lo que tenemos que conservar los registros que es probable que se utilicen, ejecutar nuestro código, llamar opcionalmente a  la rutina de servicio de la ROM, restaurar los registros, volver a habilitar las interrupciones y por último regresar de la interrupción con un reti. Nuestra rutina podría asemejarse a esta:

int    push af             ; preservar registros.
       push bc
       push hl
       push de
       push ix
       call 49158          ; hacer sonar la música.
       rst 56              ; rutina ROM, leer teclas y actualizar el reloj.
       pop ix              ; restaurar registros.
       pop de
       pop hl
       pop bc
       pop af
       ei                  ; Volver a habilitar interrupciones antes de regresar.
       reti                ; echo.
       ret

Si no estás leyendo el teclado a través de las variables del sistema, puedes desear prescindir del rst 56. Si lo haces, vas a liberar los registros iy. Sin embargo, si el temporizador de tu juego cuenta los cuadros usando el método descrito en el capitulo de temporización, tendrás que incrementar el contador de cuadros por ti mismo:

       ld hl,23672         ; contador de cuadros.
       inc (hl)            ; aumentarlo.

Con todo esto en su lugar, estamos listos para deshabilitar las interrupciones. Hay que apuntar al registro i en la tabla de punteros y seleccionar el modo 2 de interrupción. Este código va a hacer el trabajo por nosotros:

       di                  ; deshabilitar las interrupciones por precaución.
       ld a,200            ; byte alto del puntero a la tabla de ubicaciones.
       ld i,a              ; establecer el byte alto.
       im2                 ; seleccionar el modo2 de interrupción.
       ei                  ; habilitar las interrupciones.