De La Emulación de Las Máquinas Recreativas - JOSÉ TEJADA GÓMEZ - (147Págs)

De la emulación de máquinas recreativas José Tejada Gómez

1

De la emulación de máquinas recreativas

José Tejada Gómez [email protected]

mailto:[email protected]


2

Introducción ................................................................................................................................6 Objetivos ......................................................................................................................................8 1ª parte..........................................................................................................................................9 Los sistemas de las máquinas recreativas de vídeo...............................................................9

Descripción general: El mueble, las palancas y el monedero...........................................9 El monitor..............................................................................................................................14

Conexión de una máquina recreativa a un televisor doméstico ...............................14 La placa..................................................................................................................................16

El sistema de vídeo de una máquina de videojuegos..........................................................18 Almacenamiento de las imágenes......................................................................................18 Composición de los fondos.................................................................................................18 Movimiento de los objetos ..................................................................................................21

El sistema de audio de una máquina de videojuegos .........................................................22 Introito histórico ...................................................................................................................22 Diagrama de bloques de un sintetizador basado en MIC ..............................................23 Bloques de un sintetizador FM...........................................................................................25

Los operadores .................................................................................................................25 Funciones posibles ...........................................................................................................25 Conexionado de los operadores.....................................................................................27 Efectos añadidos: El enventanado.................................................................................27

Estudio de algunos circuitos integrados comerciales. ....................................................28 El YM-2149, sintetizador MIC ........................................................................................28

Características ..............................................................................................................28 Descripción de funciones............................................................................................28 Modelo de programación del YM-2149....................................................................29

El YM-2203 ........................................................................................................................30 Características ..............................................................................................................30 Descripción de funciones............................................................................................30 Modelo de programación ...........................................................................................31

El YM-2151, sintetizador FM de varios operadores. ...................................................32 Características ..............................................................................................................32 Descripción de funciones............................................................................................32 Circuito de ejemplo .....................................................................................................34

La arquitectura del sistema .....................................................................................................35 Bloques fundamentales .......................................................................................................35 Esquema eléctrico de Gryzor..............................................................................................39

Las palancas de juego y las monedas............................................................................39 Los microinterruptores DIP............................................................................................40 Los cuentamonedas .........................................................................................................40 El oscilador........................................................................................................................41 El procesador principal ...................................................................................................41 Los circuitos gráficos .......................................................................................................42 Procesador de audio ........................................................................................................43 Circuito de sonido............................................................................................................44

Mecanismos de protección contra copias .........................................................................45 2ª Parte........................................................................................................................................49 Modelo de un emulador ..........................................................................................................49

Diagrama principal ..............................................................................................................49 El arranque ............................................................................................................................50 Bucle de la emulación ..........................................................................................................51


3

El bucle de la máquina real.............................................................................................52 Ingeniería inversa: investigación del equipo ........................................................................53

Investigación de Gryzor ......................................................................................................53 Fichero g-1.rom ................................................................................................................54 Fichero G-2.rom................................................................................................................56 Fichero G-3.rom................................................................................................................58 Ficheros G-4, G-5, G-6... ..................................................................................................59 Análisis del código...........................................................................................................59 Uso .....................................................................................................................................65

El menú “Procesador”.................................................................................................66 El menú “Memoria” ....................................................................................................67 El menú “Ver”..............................................................................................................68 El menú “Ventana”......................................................................................................68

La emulación del procesador ..................................................................................................69 El Motorola 6809...................................................................................................................72 Juego de instrucciones .........................................................................................................74 El compilador de un emulador...........................................................................................78

Análisis de algunas instrucciones y su compilación...................................................83 Ficheros que componen el emulador del 6809.............................................................84

Programación de la función Exg (intercambio de registros) .................................85 El direccionamiento indexado ...................................................................................86

Registros y variables del emulador ...............................................................................88 La función Ejecuta ............................................................................................................89 Emulación interna del registro de banderas ................................................................90 Disparo de la interrupción IRQ......................................................................................91

El emulador del 6809 de Larry Bank .................................................................................92 La sincronía ...............................................................................................................................93

Sincronización mediante promediado de imágenes .......................................................94 Sincronización cronometrada.............................................................................................96

La emulación del sonido..........................................................................................................97 Descripciones técnicas detalladas de las máquinas emuladas...........................................98

Ghosts & Goblins..................................................................................................................98 Paginación y mapa de memoria.....................................................................................99 Codificación de los gráficos en las memorias ROM..................................................100 Funcionamiento del circuito gráfico............................................................................101

Formato de los octetos de atributos de los caracteres ..........................................101 Formato de los octetos de atributos de los fondos................................................101 Formato de los octetos de atributos de los objetos ...............................................101 Paleta ...........................................................................................................................102 Contenido ...................................................................................................................102

Interruptores DIP ...........................................................................................................103 El modo de pruebas.......................................................................................................105 Miscelánea.......................................................................................................................106

Gryzor ..................................................................................................................................107 Contenido de los ficheros ROM...................................................................................107 Paginación y mapa de memoria...................................................................................107 Codificación de los gráficos en las memorias ROM..................................................109

Caracteres y fondos ...................................................................................................109 Objetos.........................................................................................................................109

Funcionamiento del circuito gráfico............................................................................110 El primer fondo..........................................................................................................110


4

El segundo fondo.......................................................................................................111 Los objetos ..................................................................................................................111 La paleta gráfica.........................................................................................................111

Interruptores DIP ...........................................................................................................113 Primer microinterruptor ...........................................................................................113 Segundo microinterruptor........................................................................................114 Tercer microinterruptor ............................................................................................114

El modo de pruebas.......................................................................................................115 Miscelánea.......................................................................................................................116

Combat School ....................................................................................................................117 Contenido de los ficheros ROM...................................................................................117

Descripción.................................................................................................................117 Codificación de los gráficos en las memorias ROM..................................................117 Paginación y mapa de memoria...................................................................................118

Registro 500h..............................................................................................................118 Funcionamiento del circuito gráfico............................................................................119

Los fondos...................................................................................................................119 Los objetos ..................................................................................................................120

El modo de pruebas.......................................................................................................121 Miscelánea.......................................................................................................................122

Conexión de una palanca normal............................................................................122 Salto de los retardos iniciales...................................................................................122

Los emuladores .......................................................................................................................123 Mapefer3, emulador de Ghosts & Goblins .....................................................................123

Plataforma de desarrollo...............................................................................................123 Diagramas de flujo fundamentales..............................................................................125

Función main ..............................................................................................................125 Preparación y bucle de la emulación ......................................................................126

Explicación del código fuente ......................................................................................127 main..............................................................................................................................127 OpIlegal.......................................................................................................................129 Inicia6809 ....................................................................................................................129 prepara_memoria ......................................................................................................130 teclado .........................................................................................................................131 escribe_mensaje..........................................................................................................131 dibuja_pantalla...........................................................................................................132 Fondo y dibuja_fondo...............................................................................................132

Resumen de las funciones.............................................................................................134 Diamond Run y Makaimura ............................................................................................135

Grytra , emulador de Gryzor y Contra............................................................................136 Plataforma de desarrollo...............................................................................................136 Explicación del código fuente ......................................................................................136

vuelca_ram .................................................................................................................137 muestra_mapa............................................................................................................137 salva y carga .................................................................................................................137 muestra_muñecos......................................................................................................137

Escuela de combate, emulador de Combat School........................................................138 Plataforma de desarrollo...............................................................................................138 Explicación del código fuente ......................................................................................139

WinMain .....................................................................................................................139 Arranca........................................................................................................................140


5

ArrancaGraficos.........................................................................................................141 WindowFunc..............................................................................................................141 Emula6809...................................................................................................................143 Teclado ........................................................................................................................143

Conclusión e investigaciones ulteriores ..............................................................................144 Juego............................................................................................................................144

Bibliografía ..........................................................................................................................146


6

Introducción Durante los años ochenta el sector del videojuego profesional vivió su época dorada. Era un tiempo en que los sistemas domésticos eran muy inferiores a los sistemas especializados que ofrecían los salones recreativos. Los éxitos se sucedían para las compañías desarrolladoras que integraban en su plantilla ingenieros electrónicos y de programación para confeccionar a medida cada nuevo título. Las empresas que hoy son punta de lanza en el sector del videojuego doméstico comenzaron su andadura diseñando estos completos sistemas donde se cuidaban desde los aspectos electrónicos de circuitos integrados específicos para cada juego, hasta el prosaico mueble de madera. En 1987 había en las casas ordenadores Spectrum, Amstrad, Commodore, Dragón... todos ellos con un ancho de bus de un octeto y frecuencias de reloj en torno a 4 MHz. Las máquinas que poblaban los salones recreativos portaban, por lo general, los mismos procesadores que los ordenadores domésticos; sin embargo llevaban muchísima circuitería adicional especializada en sonido y vídeo. La distancia técnica era enorme, el precio también: Una placa de vídeo profesional costaba unas 150 000 pesetas (unos 1000€) cuando un ordenador completo, compuesto por monitor, placa, teclado y lectora de cintas costaba unas 50000 Ptas. (unos 300€). Al precio de la placa de vídeo había que añadir el del mueble, monitor y fuente de alimentación. Las partidas solían pagarse a 25 Ptas. (unos 15 céntimos), el mismo juego podía comprarse para ordenador por unas 875 Ptas. (poco más de 5€); el precio de 35 partidas. La diferencia, sin embargo, entre la versión original, de recreativa y la conversión a ordenador era abismal.

Gryzor, versión de Amstrad CPC (1987) Gryzor, versión original (1987)

En las imágenes vemos la primera fase de Gryzor (©Konami, 1987) en sus versiones de máquina recreativa y de ordenador. Pese a la obvia superioridad de la máquina, estas imágenes no descubren todos los ámbitos de éstas: El juego original ofrecía un suave desplazamiento de fondos, con dos planos distintos para aportar sensación de profundidad; la versión doméstica presentaba una sucesión de pantallas fijas, sin movimiento. El original ofrecía música y efectos sonoros simultáneamente; en el ordenador, había que elegir entre uno u otro, estando disponible la música sólo para los poseedores del equipo de gama alta: CPC 6128 (128 koct de memoria en vez de 64)


7

Pero el tiempo pasó, la electrónica aumentó su capacidad de integración y procesadores y equipos cada vez más potentes fueron abaratándose y ocupando un lugar en las casas. Un equipo moderno barato es varias veces superior en cualquier aspecto a cualquiera de esas máquinas de los años ochenta, viejas reinas del videojuego. Con los nuevos equipos surge una nueva posibilidad: en vez de reprogramar el juego original (conversión), aprovechar la potencia del ordenador y simular el entorno donde se ejecutaba el programa original: emular la máquina. La emulación consiste en tomar la parte intangible del juego: código del programa, gráficos y sonido (toda ella almacenada en memorias ROM) e interpretarla en un equipo distinto a través de un programa llamado emulador, pues emula al sistema original sin serlo. Podemos entender la emulación como una traducción instantánea que haría, por ejemplo, un intérprete en el Parlamento Europeo: escucha el mensaje original y va produciendo otro adecuado al oyente. Antiguamente, estos juegos se llevaban al ordenador mediante “conversiones” que, siguiendo el símil, serían como resumir un libro escrito en otro idioma usando para ellos sólo unas pocas hojas y perdiendo multitud de detalles por el camino. La programación de un emulador tiene dos retos: desentrañar el sistema a emular, y escribir el emulador en sí. Dado que estos juegos son propiedad intelectual de las compañías desarrolladoras, la información disponible sobre su funcionamiento interno es escasísima; incluso la que se ofrecía al servicio técnico sería insuficiente para nuestro propósito. La forma de averiguar el funcionamiento del equipo es tomar el código máquina de las memorias ROM esparcidas por el equipo y analizarlo con sumo cuidado. El estudio detallado de éste, apoyado por conocimientos suficientes de electrónica digital y computadores, irá desvelando poco a poco el funcionamiento de la circuitería que estaba originalmente conectada en la placa. Con esta información se puede empezar a imitar el comportamiento del juego en el ordenador, las pruebas de lo ya simulado con el código original irá descubriendo anomalías y abriendo nuevas formas de investigación. De forma iterativa aunque nada mecánica se harán converger lo que espera el código original y lo que ofrece el emulador hasta que la discrepancia sea inapreciable. Nunca se emula toda la circuitería, sólo aquella que es apreciable durante el juego; por ejemplo, el circuito de autoarranque (usado para arrancar la máquina de nuevo si se hubiese colgado) no suele simularse pues carece de sentido en un ordenador. Entre la emulación de una máquina recreativa y la ejecución de código Java hay muchas similitudes. El código Java está formado por instrucciones máquina que corresponden a un equipo imaginario: la máquina Java. Cualquier ordenador disponible de una máquina virtual Java puede ejecutar un programa Java. La máquina virtual no es más que un emulador que recrea las circunstancias que espera encontrar el código. En este proyecto de final de carrera, se va a explicar el funcionamiento de las clásicas máquinas recreativas con sistemas gráficos de mosaico (en contraposición a las actuales, con gráficos tridimensionales) y se van a presentar tres emuladores distintos


8

explicando con detalle el proceso de análisis y el posterior diseño y redacción del programa. La primera parte describirá las generalidades sobre los equipos y manifestará además las diferencias con un ordenador moderno y con otros sistemas electrónicos, actuales y de la época; tratando de poner en perspectiva al lector. La segunda parte cubre el análisis completo de las tres máquinas emuladas: “Gryzor”, “Combat School” y “Ghosts & Goblins”; y el desarrollo de los emuladores desde el punto de vista informático, se destacarán las optimizaciones efectuadas para elevar el rendimiento de los programas y se comentarán las exigencias que impone el sistema operativo para el cual se desarrolle el programa. Finalmente, se presentan los resultados que son los tres emuladores en sí. Éstos pueden probarse de antemano pues están grabados en el mismo disco que esta presentación.

Objetivos Este proyecto de final de carrera pretende documentar con gran detalle el funcionamiento de los sistemas recreativos de vídeo especialmente en cuanto sistemas electrónicos aunque también se comentarán aspectos mecánicos y comerciales de los mismos. La labor de documentación persigue el mantenimiento y conservación del patrimonio técnico que estos equipos constituyen como parte de la historia de la electrónica. Ahora que ya parecen llegar a su ocaso, las máquinas recreativas constituyen un conjunto cerrado y coherente cuya evolución es menester que sea escrita y guardada. Mas para dotar a este trabajo de mayor valía técnica, nos proponemos utilizar todos los datos descritos a lo largo del presente documento para elaborar varios programas –emuladores- que simularán el entorno electrónico etológicamente1 y harán posible que el código máquina original que antaño estaba grabado en memorias ROM se ejecute en nuestros modernos ordenadores de manera fidedigna, siendo, por tanto, facsímiles de las máquinas verdaderas. El desarrollo de estos emuladores implica aunar dotes de ingeniería inversa y directa , de electrónica y de informática, de inducción y de deducción; constituyendo, por tanto, una labor cuya realización satisface enormemente al ingeniero que encuentra en ella la resolución de problemas de naturaleza lógica y la ordenación de lo hallado en pro de la construcción de un nuevo ingenio. Resumidamente los objetivos son:

• Describir los componentes de una máquina • Explicar el funcionamiento de los sistemas gráfico y sonoro • Mostrar cómo se realiza la investigación mediante ingeniería inversa • Escribir un emulador del procesador 6809 con un compilador intermedio • Realizar los emuladores de tres máquinas: Ghosts&Goblins, Gryzor y Combat

School.

1 De etología –estudio del comportamiento. Hemos preferido este cultismo frente al barbarismo behavioural.


9

1ª parte

Los sistemas de las máquinas recreativas de vídeo Las máquinas recreativas de vídeo son sistemas electrónicos especializados en proporcionar una partida a un videojuego a cambio de un pago previo. El caso más habitual es la máquina de diseño a medida: una placa, unas palancas y botones, un armario y en ocasiones hasta una fuente de alimentación específicas para el juego en sí y que no sirven para ningún otro. La máquina recreativa se compone de un mueble de madera, donde se montan las demás partes; de luces, que iluminan el espacio en torno al equipo; de unas palancas y botones, para accionar el juego; de un monedero y cofre, que filtra las monedas que entran y las almacena; de una placa de circuito impreso, donde está el juego en sí; de altavoces, para la música y efectos sonoros; y de una fuente de alimentación que proporciona potencia eléctrica a todo lo demás: luces, monedero y placa (los altavoces y las palancas se alimentan desde la placa)

Descripción general: El mueble, las palancas y el monedero El mueble da robustez al equipo y ha de soportar los malos tratos de niños y adultos. Existen dos modelos básicos: vertical y de mesilla. El vertical es el más popular por ocupar menos espacio y tener el cristal menos expuesto. El monitor va en horizontal y un espejo se encarga de reflejarlo para que al jugador le parezca tenerlo enfrente, de esta forma se ahorra profundidad, pues el largo tubo de rayos va hacia abajo; quedando además más protegido de esta forma. En las mesillas el monitor también está horizontal pero no hay espejo, sino un cristal plano sobre la pantalla que actúa de protector; los jugadores utilizan el espacio plano que se forma para depositar las bebidas o apoyarse mientras ven a otros jugar. Las mesillas favorecen la sociabilidad del juego y la exhibición del mismo, pero ocupan mucho espacio en comparación con los muebles verticales que terminaron imponiéndose.

Ms Pac-Man2, mueble normal Ms Pac-Mac, mueble mesilla

2 © Midway/Namco, 1982


10

Las placas llevaban normalmente un conmutador para seleccionar el tipo de mueble donde estaban instaladas y la orientación del monitor. Si el monitor estuviese enfrascado en un armario vertical la imagen habría que mostrarla girada e invertida para que al reflejarse en el cristal ésta se viese correctamente. Los conmutadores de reflejo horizontal y vertical de los gráficos son muy comunes en todas las placas y constituyen un ejemplo de lo que no se suele emular por carecer de sentido: ¿Para qué ver el juego al revés en un ordenador? No simular esta circuitería es inocuo pues aunque el procesador lea el conmutador para averiguar como debe pintar los gráficos realmente no los pinta él uno a uno, sino que ordena a la circuitería gráfica que los pinte invertidos. El lazo no se cierra y el procesador no tiene forma de averiguar si los gráficos salen del derecho o del revés, por lo que no emular este comportamiento ahorra trabajo y no tiene efectos en el juego. Pese a esto, recientemente ha comenzado a ser habitual incluir esta función, pues se ha popularizado el uso de muebles de máquina recreativa conectados a ordenadores; en esa circunstancia vuelve a tener sentido el incluir esta característica. En la cabeza del armario, por encima del jugador, se forma una pequeña techumbre (marquesina) donde muchas veces se colocan los altavoces (pues a los lados de un mueble suele ir otro) y tras un cristal va un dibujo que se ilumina con un tubo por detrás. En algunos equipos este tubo está conectado a la placa y es controlable por el juego para manejarlo según la acción.

Marquesina de Contra (Apodo de Gryzor en Europa)


11

1 tubo fluorescente de la marquesina 13 soporte del monitor (dos posiciones) 2 plástico de la marquesina 14 monitor RGB3 3 pareja de altavoces de 8 Ω 15 paredes de madera 4 soporte de la marquesina 16 placa del juego 5 espuma protectora del monitor 17 interruptor de encendido 6 plástico tintado 18 contador de monedas 7 cristal 19 interruptor de encendido 8 panel de control de madera 20 cable de red 9 cierre del panel (dos piezas) 21 fuente de alimentación con cuatro

salidas 10 puertas de los monederos 22 fusibles 11 interruptor de encendido 23 transformador 12 pernos del monitor 24 filtro de red

elementos de un mueble de máquina recreativa Ya en la mitad inferior del armario, sobre una repisa se colocan las palancas y los botones. La calidad de estos suele ser muy elevada, pese a lo cual no son irrompibles y solían acabar sucumbiendo ante la furia de jugadores insatisfechos. Los botones y la palanca no son más que interruptores que llevan su señal por un cable cada uno (sin ninguna multiplexación) hasta la placa, que es además quién suministra la tensión eléctrica necesaria para su funcionamiento. La placa puede colocarse verticalmente en uno de los laterales de la máquina o en horizontal sobre unas baldas disponibles al efecto. La placa tiene por lo general un conector normalizado llamado jamma, al que llega la “manguera” de cables provenientes de altavoces, tubo, palancas, monitor y fuente. La alimentación está colocada al fondo del mueble y es la única conexión con el exterior. Suele proveer de +5V y +12V, el primero para la lógica digital y el segundo

3 RGB, rojo verde y azul; hace referencia a que la señal llega al monitor separada por tres canales y no en forma de crominancia y luminancia como en un televisor


12

para los componentes analógicos (por ejemplo, los amplificadores de audio sitos en la placa)

El monedero 4 básico se conecta tan sólo a la alimentación y a la placa para hacer llegar la señal que indica la inserción de monedas, ésta se activa a nivel bajo (0V). Otra conexión común va desde el monedero hasta un contador que registra el número y tipo de monedas insertadas. Esta función está a veces realizada en la propia placa del juego, se puede acceder a la contabilidad activando el modo de “servicio”. La imagen a la izquierda muestra la pantalla de contabilidad de Crater5 en ella los apartados Chute indican cuántas monedas han entrado por cada tobera. Los otros datos, como puntuación máxima y partida más

larga sirven para decidir si hay que subir el nivel de dificultad del juego o bajarlo según la audiencia. Los monederos se componen de una ranura por la que se introduce la moneda y que conduce a un pasaje en cuyo final hay una pieza móvil controlada por un relé. Si la moneda es aceptada el relé la dejará pasar a la siguiente etapa y si no la devolverá al cliente. No es habitual que en las máquinas de vídeo halla un sistema de clasificación de monedas puesto que no es necesario, sólo en las tragaperras de premio se incluye una etapa posterior al monedero que, siguiendo las órdenes de este, hará pasar la moneda por una u otra tobera hasta la caja o el monedero para pagar premios. Cuando la moneda está cayendo por la ranura unos fotodiodos detectan su paso y se toma una medida de la permitividad magnética de la misma y del tiempo que tarda la moneda en caer. En algunos monederos, una galga trata de medir además el peso. Todas estas medidas se digitalizan y se contrastan con unas tablas grabadas en la EPROM del microcontrolador donde hay cotas para cada valor. Con el tiempo, el monedero empieza a errar la medida debido al envejecimiento de los componentes; los valores tomados comienzan a caer fuera de los intervalos permitidos y se rechazan muchas de las monedas. Cuando esto ocurre es necesario reprogramar el monedero. Para ello basta con volver a calibrarlo insertando monedas válidas y midiendo los máximos y los mínimos que causan. Acto seguido se modifican los valores de las tablas en la EPROM y el monedero ya está listo otra vez. Las tablas limitan a su vez el número máximo de monedas distintas que aceptará el monedero, pues el número de filas de estas tablas está limitado en cada modelo; lo normal es dieciséis. Para cada moneda hay, por tanto, una fila en la tabla de medidas pero también otras filas en otras tablas para indicar el número de pulsos que enviará el monedero, el canal por el que saldrán y cada cuantas monedas. Dos ejemplos de programación válidos serían:

Tipo de moneda Canal Pulsos Nº de monedas 25 1 1 1

4 La empresa navarra Azkoyen es la principal suministradora de monederos en España 5 © Bally Midway, 1984


13

100 1 4 1 500 1 20 1

Para partidas a 25 Ptas. usando un solo canal

Tipo de moneda Canal Pulsos Nº de monedas 25 1 1 2 100 1 2 1 500 1 10 1

Para partidas a 50 Ptas. usando dos canales. Las placas de vídeo siempre tienen al menos dos canales para aceptar monedas aunque suele usarse sólo uno por simplicidad, mandando sencillamente más o menos pulsos. El número de partidas que da la máquina por cada moneda se controla mediante microinterruptores DIP siendo lo más común dar una partida por moneda en el primer canal y cuatro por moneda en el segundo (si es que se usa)

monedero real, desmontaje


14

El monitor El monitor de las máquinas recreativas funcionaba con una frecuencia horizontal de 15 kHz y una vertical de 60 Hz. La manera de conectarlo a la placa y al mueble se describe en otros apartados, en éste vamos a ocuparnos de valernos de un televisor como monitor.

Conexión de una máquina recreativa a un televisor doméstico6 Con el advenimiento de televisores con euroconector es posible enchufar la placa al televisor sin necesidad de ningún circuito intermedio. El televisor debe estar preparado para aceptar una entrada separada en el triplete básico: rojo, verde y azul (RGB). Esta exigencia no se cumple en muchos televisores que sólo admiten vídeo compuesto.

fotografía de un cable euroconector-euroconector

El conexionado es como sigue:

6 Esta sección está basada en el trabajo de Jonathan Dawes

1. salida del canal de sonido B 2. entrada del sonido B 3. salida del sonido A 4. masa de los canales de sonido 5. masa del canal del color azul 6. entrada del sonido A 7. azul 8. conmutación de funciones 9. masa del verde 10. 2ª línea de comunicaciones 11. verde

12. 1ª línea de comunicaciones 13. masa del rojo 14. masa de las comunicaciones 15. rojo 16. blanco 17. masa del vídeo compuesto 18. masa del blanco 19. salida de vídeo compuesto 20. entrada de vídeo compuesto 21. masa común (carcasa del conector)


15

Según la norma Jamma, hay que hacer:

placa patilla del euroconector número de la patilla rojo rojo 15 verde verde 11 azul azul 7 masa masas 5,9,13,18 y 21 sincronía entrada de vídeo 20 +5V blanco 16

Además las patillas 8 y 16 sirven para seleccionar el tipo de señal de entrada, en nuestro caso ambas deben estar activadas. De esta forma habremos conseguido la imagen, el sonido se puede obtener en algunas máquinas a través del conector jamma y en otras –como Gryzor- mediante una conexión aparte. Para enchufarlos en este caso tampoco hace falta ninguna interfaz, un cable directo bastará. Una vez conectada la placa al televisor se puede utilizar una fuente de alimentación de ordenador y una palanca de juegos normal (que no sea USB) para completar el equipo. Las fuentes de ordenador comúnmente suministran +5V y +12V, algunas placas requieren además de estas dos tensiones las mismas en negativo, si bien son las menos. En cuanto a la palanca será necesario desmontarla y cablear directamente cada interruptor con la placa de videojuegos.


16

La placa La placa contiene el videojuego en sí, la descripción de los circuitos que la componen se realizará más adelante; en este apartado nos ocuparemos de la interconexión de ésta con el resto del sistema.

posición de la placa en el

mueble normal posición de la placa en el mueble mesilla

La placa suele ir atornillada verticalmente al mueble en la parte inferior del mismo, aunque a veces se encuentran placas en posición horizontal, sobre todo si estas tienen varios pisos. La conexión de la placa con el resto del sistema se realiza con un conector normalizado llamado jamma, la imagen en la página siguiente detalla el conexionado de la máquina recreativa Gryzor, que es un ejemplo muy representativo al tratarse de la típica interfaz para dos palancas y cuatro botones. El conector jamma se encuentra en uno de los bordes de la placa y se compone de 56 contactos, 28 por cada cara e incluye alimentación, controles (palancas y monederos) , monitor y audio. En ocasiones el sonido tiene un conector aparte para evitar la parafonía y el ruido inducidos por la circuitería digital. La alimentación era originalmente bipolar, ±5V y ±12V; pero ya por mediados de los años ochenta lo común era utilizar únicamente alimentación positiva +5V para la lógica y ocasionalmente ±12V para la etapa de audio. Las patillas de alimentación están separadas de las demás por una muesca que indica también el sentido del conector. Tras la muesca vienen las salidas del contador de monedas. Cada vez que se introduce una, la placa genera un pulso (activo a nivel bajo, como todas las demás señales) que informa al contador de monedas. Estos contadores sirven para conocer la recaudación del equipo y llevar la contabilidad.


17

conexionado de Gryzor Como se indica en la imagen superior, todas las entradas son activas a nivel bajo y no existe ninguna multiplexación de las señales; aunque esto eleva el número de cables simplifica la circuitería de las palancas a la mínima expresión posible: un interruptor; facilitando, por tanto, las reparaciones posteriores.


18

El sistema de vídeo de una máquina de videojuegos

Almacenamiento de las imágenes

Composición de los fondos Dibujar un fondo de 256x256 puntos con un octeto por punto representa mover 64ko de memoria. Para un procesador de 8 dígitos esta cantidad representa toda la memoria direccionable y un tiempo de proceso muy elevado. En el caso del 6809 suponiendo un direccionamiento indexado para leer y escribir los datos serían precisos aproximadamente (6+8)*65536=917504 ciclos de reloj, a 1MHz eso implica casi un segundo, siendo optimista7; una animación suave exige al menos 24 fotogramas por segundo, esta cantidad es imposible de alcanzar con los datos presentados.

Para solventarlo las máquinas de vídeo disponen de un circuito gráfico encargado de hacer la labor citada, lo único que necesita este dispositivo para funcionar es saber qué pintar. En el caso de los fondos esta información viene en forma de mosaico de octetos. Los fondos del juego se almacenan cortados en bloques numerados. El circuito gráfico dispone de una memoria mapeada en el espacio direccionable del procesador principal. Éste escribirá en ella los números de los bloques a dibujar. El ahorro es enorme: para pintar un bloque de 16x16 puntos basta con escribir un único octeto, la ventaja es de

64 a 1. Esta memoria además funciona de forma secuencial, es decir, desde donde empieza cada octeto equivale a un bloque de 16x16 en la pantalla, de forma lineal. Esto evita la necesidad de tener que escribir la posición del bloque en el dibujo, pues está implícita según el orden que ocupa en la memoria gráfica. Asociado a cada bloque de la pantalla hay, por lo menos, otro octeto que da información adicional como:

• ¿Ha de dibujarse girado horizontalmente? • ¿Ha de dibujarse girado verticalmente? • ¿Qué paleta gráfica utilizará? • ¿Ha de tapar a los objetos?

Estos datos suelen codificarse en un solo dígito cada uno salvo la paleta que habitualmente ocupa entre dos y cuatro dígitos. El asociar una paleta cambiable a los gráficos permite efectos como el de la famosa cascada, cuya agua no se mueve sino que sus colores ciclan; es decir, lo único que el procesador toca son los dígitos que indican con que paleta se pinta el bloque, el efecto ocurre por sí mismo. 7 El optimismo reside en no contar el tiempo invertido en descontar la variable que formaría el bucle y en realizar el salto al final de cada iteración


19

La memoria de fondos tiene habitualmente una correspondencia lineal con la pantalla. Si suponemos una imagen de 256x256 puntos, que será dibujada usando bloques de 8x8 puntos (32x32 bloques); la memoria de fondos estaría organizada de forma que los primeros 32 octetos estarían relacionados con la primera fila a pintar, los siguientes 32 octetos con la segunda, etc. La relación entre la memoria de fondos y la pantalla es por lo tanto directa y no hay que precisar en qué posición se pintará cada bloque puesto que esta información está implícita en la dirección de memoria en que se ha escrito el código del bloque.

Funcionamiento de la memoria de fondos

La operación de dibujar una imagen es costosa, sin embargo, una vez dibujada no ha terminado el trabajo: es necesario desplazarla. El escenario sobre el que se juega es esencialmente móvil, ha de avanzar cuando el personaje avanza, puesto que si fuese al contrario (un escenario inmóvil y un personaje ambulante) el jugador acabaría rebasando los límites de la pantalla obligando a un cambio brusco de fondo; esta situación siempre trata de evitarse. Lo habitual es que el jugador ocupe siempre una situación próxima al centro del monitor y que sea el fondo el que refleje los movimientos del personaje. Desplazar la imagen costaría tanto como volver a pintarla si fuese el procesador el encargado de hacer el trabajo. Habría que tomar cada punto del fondo y repintarlo en otras coordenadas, la labor para un procesador de 8 dígitos es inmensa. Los circuitos gráficos tienen unos registros en los que se indica el desplace de la imagen en coordenadas. De esta forma si se desea mover el fondo cinco puntos a la izquierda bastará con almacenar un cinco (o menos cinco) en el registro de desplace horizontal, ídem para los casos verticales. Si pintamos todo desplazado cinco puntos a la izquierda estaremos empezando cinco puntos más tarde a pintar y estaremos acabando cinco puntos después: ¿de dónde salen esos puntos adicionales a la derecha? La solución viene de trabajar con una pantalla virtual habitualmente cuatro veces mayor que la real, de forma que lo que se nos presenta no es más que una ventana dentro de un espacio mayor. La esquina superior de esa ventana por la que nos asomamos al fondo constituyen los registros de desplace mencionados.


20

Funcionamiento de la pantalla virtual

Las máquinas que llegaron a partir de 1986 comenzaron a incluir varios planos de fondo en lugar de uno sólo, para dar así profundidad a la imagen. La técnica consiste en colocar debajo del fondo que hemos estudiado otro de idénticas características, pero que se desplazará a una velocidad inferior. Se trata de imitar las líneas de fuga que tienen las imágenes reales –tridimensionales. Cuando vamos en un tren y miramos por la ventanilla, los postes de la catenaria pasan raudos ante nosotros, pero las distantes montañas se desplazan con lentitud, entre nuestra posición y el horizonte cada punto parece moverse a una velocidad. Incluir dos planos de fondo se convirtió pronto en una necesidad, sin embargo los juegos con más de dos planos fueron pocos, aunque hay casos donde se llegó a incluir más de una decena de planos, a veces formados por finas bandas horizontales para mostrar nubes o montañas lejanas, el caso más renombrado fue el juego “Shadow of the Beast”. Añadir un segundo plano es más una sobrecarga para la memoria que para el procesador, pero en ambos casos supone poco esfuerzo adicional. Al ser un plano más lento no es necesario actualizar los bloques que lo componen de forma tan frecuente y generalmente se permite que la animación sea cíclica de manera que la montaña o nube que sale por un lado de la pantalla aparece por el opuesto. El tiempo de proceso requerido es escaso y la memoria también ha de serlo, puesto que la variedad de imágenes a almacenar es considerablemente menor. Desde el punto de vista de la circuitería sí que se añade una complicación considerable. El dibujado del fondo ha de hacerse ahora en paralelo, duplicando la circuitería y utilizando una puerta lógica al final que dejará pasar el punto del segundo plano sólo cuando el del primero sea cero.


21

Movimiento de los objetos Entenderemos por objetos todos aquellos pequeños elementos móviles sobre el fondo (escenario) en el que se desarrolla la acción; es decir, los personajes que maneja el jugador o que controla la máquina. Estos objetos se enfrentan a la misma problemática de ineficiencia que los fondos: demasiados puntos y dígitos por punto para un procesador tan lento. La solución esta vez no puede venir en forma de mosaico, ya que los objetos pueden ocupar cualquier posición de la pantalla, por lo que el planteamiento de memoria direccionada según el orden de la pantalla ya no es válido. En su lugar los objetos se controlan con una estructura que contiene, al menos, la siguiente información:

• bloque gráfico en la ROM que representa al objeto • coordenadas en la pantalla • ¿está girado (horizontalmente)? • paleta

Los bloques son en general de 16x16 puntos, pero eso no implica un problema a la hora de dibujar objetos mayores, ya que puede pintarse un bloque junto a otro para componer objetos mayores. En ocasiones la misma circuitería gráfica dispone de aceleración para este caso, por ejemplo, en la máquina Gryzor hay un dígito asociado a los objetos que indica si habrá de pintarse el siguiente objeto almacenado en la ROM gráfica justo debajo del objeto pintado. El número máximo de objetos dibujables depende de la circuitería gráfica, siendo lo habitual una cifra entre 16 y 64. Como habitualmente sólo se trabaja con un pequeño número de objetos muy inferior a las capacidades de la circuitería, las estructuras de los objetos inutilizados se rellenan de forma que sus coordenadas de dibujado indican la esquina inferior derecha de la pantalla, por lo que se pintarán fuera del área visible por el jugador.


22

El sistema de audio de una máquina de videojuegos En esta sección aprenderemos por qué la música basada en modular la frecuencia de un tono es una elección común en las máquinas recreativas, así como la forma en que se consigue generar melodías, con especial atención al modelo real de sintetizador de F.M.

Introito histórico Los circuitos que vamos a estudiar surgen de la necesidad de tener sonido a bajo coste en sistemas donde la música no es el objetivo principal. Ejemplos de aparatos que cumplen este requisito son: Los ordenadores personales: aunque en ocasiones escuchamos música en ellos, no es su principal función; por tanto, son candidatos a soluciones de bajo coste. Las máquinas recreativas tipo A y B: En este grupo se incluyen las denominadas “tragaperras”, los “pitufos”8 y las máquinas de videojuegos. En todas ellas, la música, los sonidos o las voces son elementos importantes para atraer al cliente; pero no la función primordial9 Teléfonos: hoy día se usan en telefonía móvil, aunque no es un modelo basado en MF sino en MIC10 por lo general. Electrodomésticos y juguetes electrónicos. La problemática en estos aparatos es conseguir una calidad de sonido aceptable a un coste pequeño (orientativamente, menor del 5% del costo total). Las primeras soluciones, en los albores de la electrónica integrada, fue digitalizar el sonido para reproducirlo posteriormente. El inconveniente es el tamaño de las memorias ROM necesarias; para solventarlo se recurría (allá por 1980) a bajas frecuencias de muestreo y codificaciones de alta relación señal-ruido, como la modulación diferencial y adaptativa de pulsos codificados (ADPCM). Esto se traduce en baja calidad, máxime hace veinte años, cuando el precio de una ROM de 4kB era prohibitivo. El remedio pasa por generar la música sobre la marcha11, a través de un sistema que a modo de instrumentista, reproduce adecuadamente la composición. De esta forma la información a guardar sería sólo de notas y tiempo, mucho menor que antaño. Aunque ahora es necesario un “director”, un procesador que indicase qué nota tocar en cada

8 Son máquinas destinadas a los niños de menor edad. En general son algún tipo de móvil sobre el que el niño se sienta. Al insertar el dinero éste se moverá y producirá sonidos. 9 La función primordial de estos ejemplos sería, respectivamente: el premio aleatorio, el movimiento mecánico y el juego en sí. 10 Modulación de Impulsos Codificados, básicamente son trenes de pulsos de frecuencia programable 11 En el mercado de los videojuegos se habla de cuatro generaciones: la primera se basaba en gráficos, sonido y comportamiento predeterminados; la segunda generación incluyó el sonido desarrollado en “tiempo real” (usando sintetizadores); la tercera la vivimos en la actualidad, donde los gráficos del videojuego también se calculan conforme se necesitan sin dibujarse previamente; la cuarta pretende que el comportamiento de las entelequias (enemigos, etc...) del juego también se calculen sobre la marcha, es decir, busca un comportamiento más “inteligente” de los rivales.


23

momento, y por cuánto tiempo. Una configuración típica en máquinas recreativas (que aun en diseños actuales12 se sostiene) es un procesador Z80 con una EPROM de 32kB (con código y datos), acompañando a algún sintetizador. Como vemos, las necesidades del director son pequeñas.

Diagrama de bloques de un sintetizador basado en MIC Como hemos visto en el apartado anterior, es necesario un circuito que pueda configurarse para producir distintas notas. Básicamente esto significa que el espectro de la señal de salida es deslizable, pudiendo centrarse en un conjunto de frecuencias distintas; produciendo así música. Dado que estos circuitos sintetizadores son digitales, parece natural que la primera forma de onda que se escogiese (sin ningún criterio musical) fuese el tren de pulsos. De él podemos modificar dos parámetros: la amplitud y la frecuencia13. El primero será importante a la hora de mezclar varios canales de sonido. La frecuencia es fundamental, pues marcará la nota que estamos reproduciendo.

tren de pulsos, se indican el período y la amplitud

Tenemos una última forma de modificar la señal: envolverla. Hay muchos tipos de ventana14, es decir: funciones con las que multiplicamos la señal. La más común en estos circuitos es la mostrada en la figura inferior; se trata de una trapezoide que introduce el sonido y más tarde lo atenúa. Su utilidad es evidente; permite introducir las notas con suavidad y apagarlas con naturalidad. Aunque este enfoque puede parecer a priori ineficaz por su excesiva sencillez, la realidad es que estamos rodeados de él, en formas incluso más simplificadas (sin envolvente); es el típico pitido electrónico. Si bien ha sido la base sonora de sistemas antiguamente tan potentes como el Atari ST15.

envolvente típica de una nota

12 En el año de 1999, aun encontramos placas de máquinas recreativas nuevas que usan procesadores tan antiguos como el Z80; si bien son las más económicas y su diseño no es innovador en ningún aspecto. 13 Ciertamente, el ciclo de trabajo podría haber sido modificado también. Esto hubiese afectado al espectro ensanchándolo o comprimiéndolo. Sin embargo, no he encontrado ningún circuito real que permita modificar esta característica. 14 Utilizaré el término ventana, que se aplica en la disciplina de proceso digital con un significado distinto, pero similar a éste. 15 El Atari ST fue un ordenador basado en el M68000, su interfaz de usuario era gráfica.


24

Recapitulando, el diagrama de bloques genérico para estos circuitos sería:

Diagrama de bloques de un sintetizador MIC Externamente se colocaría un filtro paso bajo, como complemento al convertidor D/A; aunque este filtro puede realizar más labores y en general su forma no será plana en la banda de paso, sino que introducirá alguna ecualización o realce.


25

Bloques de un sintetizador FM El sintetizador FM es notablemente más complejo que el MIC, huelga decir que una modulación en frecuencia es ya de por sí conceptualmente mucho más complicada que una señal MIC.

Los operadores El subsistema fundamental dentro un sintetizador de MF es el operador. Un operador es un circuito electrónico digital que genera una señal binaria representación de una forma de onda periódica programable, generada internamente, relacionada matemáticamente con la señal presente a su entrada. La combinación de operadores permite conseguir señales discretas complicadas, el parecido de estas secuencias a lo que se obtendría digitalizando el sonido de un instrumento musical es lo que dotará una melodía de realismo. El objetivo se cifra entonces en la semejanza de dos señales temporales o de dos espectros; si bien el resultado debe ser evaluado auditivamente, por lo que secuencias diferentes a las reales pueden ser válidas en ciertos contextos.

Funciones posibles Un operador responde en general a la siguiente expresión:

( ) ( )[ ]wtDNsentBwtDNsentAtE mmcc +++= )()()( Vemos que A(t) es la envolvente de volumen, y B(t) la envolvente de tono. Los parámetros Nx y Dx, controlan la tonalidad asociada a sus senoidales. Cuando B(t) es mayor que cero la salida ya no es senoidal, sino una forma con gran componente armónica. Veamos algunos ejemplos:

0 200 400 600 800 1000 1200 1400 1600-1

-0.8

-0.6

-0.4

-0.2

0

0.2

0.4

0.6

0.8

1

0 200 400 600 800 1000 1200 1400 1600

-1

-0.8

-0.6

-0.4

-0.2

0

0.2

0.4

0.6

0.8

1

Fig. 1 B(t)=0, (Nc+Dc)=1, A(t)=1 Fig.2 B(t)=0.5

0 200 400 600 800 1000 1200 1400 1600-1

-0.8

-0.6

-0.4

-0.2

0

0.2

0.4

0.6

0.8

1

0 200 400 600 800 1000 1200 1400 1600

-1

-0.8

-0.6

-0.4

-0.2

0

0.2

0.4

0.6

0.8

1

Fig. 3 B(t) = 1 Fig. 4 B(t)=1.5


26

0 200 400 600 800 1000 1200 1400 1600-1

-0.8

-0.6

-0.4

-0.2

0

0.2

0.4

0.6

0.8

1

0 200 400 600 800 1000 1200 1400 1600-1

-0.8

-0.6

-0.4

-0.2

0

0.2

0.4

0.6

0.8

1

Fig. 5 B(t) = 2 Fig. 6 5.0)(;5.0 ==

++ tB

DNDN

mm

cc

0 200 400 600 800 1000 1200 1400 1600-1

-0.8

-0.6

-0.4

-0.2

0

0.2

0.4

0.6

0.8

1

0 200 400 600 800 1000 1200 1400 1600-1

-0.8

-0.6

-0.4

-0.2

0

0.2

0.4

0.6

0.8

1

Fig. 7 0.1)(;5.0 ==++

tBDNDN

mm

cc Fig. 8 5.1)(;5.0 ==++ tB

DNDN

mm

cc

Vemos que el cociente mm

cc

DNDN

++

determina dónde va a ser más influyente la

modulación. Así si vale la unidad el efecto es más claro en los puntos donde la modulada corta el eje de abscisas; y si vale 0.5 es más notorio el efecto en los máximos y mínimos de la modulada.


27

Conexionado de los operadores Siendo cada operador básicamente el generador de una señal periódica función de su entrada; la forma en que interconectemos estos elementos determinará totalmente el sonido. La conexión básica en MF es en cascada, donde la salida del primer operador (o modulador) domina la entrada del segundo (o modulado). Una situación común consiste en que el primer modulador también se realimente de sí mismo; aumentando así la complejidad de la modulación. Configuraciones interesantes son también aquella en que un operador modula a otros tres, cuyas salidas se suman; consiguiendo así efectos de eco y coro. O por ejemplo, cuatro operadores sumados directamente, imitando el comportamiento de los sintetizadores MIC.

Efectos añadidos: El enventanado Una envolvente habitual está compuesta de cuatro segmentos que contribuirán a hacer sonar la nota de forma más realista:

• Tasa de ataque: Determina la duración del tiempo de Ataque. (TA). Durante el

tiempo de ataque el sonido pasa desde la máxima atenuación hasta la mínima • Primer tiempo de caída: La amplitud decrece con mucha pendiente • Segundo tiempo de caída: La amplitud cae más lentamente • Tiempo de liberación: La nota deja definitivamente de sonar

TATD1 TD2 TR


28

Estudio de algunos circuitos integrados comerciales.

El YM-2149, sintetizador MIC El YM-2149 es un antiguo sintetizador16 de la casa Yamaha. En la documentación suministrada por el fabricante vemos que lo llama SSG, acrónimo de Software Sound Generator y lo describe como la solución final para los equipos que precisen sonido. Como veremos, sus características hoy día nos parecen casi ridículas, pero no debemos despreciar este integrado, tan capaz hoy como antes de generar música.

Características Circuito fabricado con tecnología NMOS LSI Facilidad de conexión a CPUs de 8 y 16-dígitos. Dos puertos de 8-dígitos de propósito general para conectar a sistemas externos. Ancho de banda musical de ocho octavas. Suave atenuación producida por un generador de envolvente de 5-dígitos Convertidor D/A de 5-dígitos integrado Compatible conexión a conexión con el AY-3-891017 De entre estas características destaca la curiosa inclusión de los dos puertos de 8-dígitos. Eso añade un valor adicional al integrado en una época en la que el diseño de computadoras estaba dominado por procesadores de 8-dígitos como el Z80 o el M6809.

Descripción de funciones El YM2149 se controlaba programando sus dieciséis registros internos, tras lo cual la CPU quedaba libre para trabajar en otras tareas. Sus posibilidades son: Generador de música: Produce ondas cuadradas de distintas frecuencias para cada uno de sus canales (A,B, y C) Generador de ruido: Formas de onda seudo-aleatorias por el canal de ruido. Mezclador: La salida es la suma de los tres canales de música y el de ruido. Control de nivel: El volumen global de cada canal lo controla la CPU externa. El volumen final vendrá dado también por el generador de envolvente. Convertidor D/A: Ahorra la necesidad de un convertidor externo.

16 Su fecha de salida al mercado está en torno a 1986, quizá finales de 1985. 17 El AY-3-8910 fue un integrado fabricado por GI de características similares al presente, pero más antiguo. Fue un auténtico éxito y se convirtió en el estándar de facto hasta la llegada de los sintetizadores basados en FM.


29

Modelo de programación del YM-2149 Toda la programación de este integrado consiste en escribir los parámetros de cada canal de ondas cuadradas, del generador de ruido y del generador de envolvente en el mapa de registros del circuito. A continuación se expone este mapa: B7 B6 B5 B4 B3 B2 B1 R0 Ajuste de tono fino con 8-dígitos R1

Frecuencia del canal A Sin usar Ajuste grueso, 4 dígitos R2 Ajuste de tono fino con 8-dígitos R3

Frecuencia del canal B Sin usar Ajuste grueso, 4 dígitos R4 Ajuste de tono fino con 8-dígitos R5

Frecuencia del canal C Sin usar Ajuste grueso, 4 dígitos E/S Ruido Tono R7

Mezclador y puertos de E/S ES/B ES/A C B A CB A

R8 Volumen del canal A Sin usar

M L3 L2 L1 L0

R9 Volumen del canal B Sin usar M L3 L2 L1 L0 RA Volumen del canal C Sin usar M L3 L2 L1 L0 RB Ajuste grueso de 8-dígitos RC

Frecuencia de la envolvente Ajuste fino de 8-dígitos

RD Forma de la envolvente Sin usar CONT ATT ALT HOLDRE Puerto de E/S de datos A 8-dígitos de datos RF Puerto de E/S de datos B 8-dígitos de datos Como vemos, la simple descripción es ya bastante intuitiva. Cabe explicar las distintas formas de envolvente admitidas:

B3 B2 B1 B0CONT ATT ALT HOLD 0 0 X X 0 1 X X 1 0 0 0 1 0 0 1 1 0 1 0 1 0 1 1 1 1 0 0 1 1 0 1 1 1 1 0 1 1 1 1


30

El YM-2203 El YM-2203 representa la transición entre los sintetizadores basados en MIC y los puramente de FM Vemos como pese a introducir la nueva tecnología de FM la compatibilidad con los circuitos existentes basados en MIC se consideró básica en su diseño.

Características

• El sistema de sonido FM produce tres sonidos distintos al mismo tiempo. • Uno de los tres sonidos anteriores puede colocarse en un modo bajo el cual

pueden realizarse efectos sonoros específicos, denominado de onda senoidal compuesta.

• Dos temporizadores programables incorporados. • Dos puertos de E/S de propósito general. • Además de los sonidos FM pueden producirse tres señales cuadradas y un

ruido seudo-blanco. • Niveles compatibles con TTL • Tecnología MOS; LSI. • Alimentación entre 0V y +5V. • Compatible con programas para YM2149; AY-3-8910 y el 8912 producido por

GI. 18 Descripción de funciones

El YM-2203 se controla en base a los datos escritos en sus registros. Así el microprocesador está despreocupado del sonido salvo, por enviar las órdenes a los registros. El generador de sonido FM determina el sonido por la modulación de ondas senoidales. Se permiten los sistemas de simple FM, múltiple FM y FM realimentada. En cuanto al generador de onda cuadrada es compatible con el YM2149, el AY-3-8910 y el 8912 (conocido como PSG GI) en cuanto a programación. Cada bloque del YM-2203 funciona como sigue: • Generador de envolvente (EG)

Determina el índice de modulación de la envolvente y de la onda de modulación de la fuente FM.

• Generador de fase (PG) Determina la fase de la onda senoidal en cada paso temporal del generador de música FM.

• Operador (OP) Calcula el valor E*sen(theta) sobre la base de la amplitud del generador de envolvente y la fase proveniente del generador de fase.

• Acumulador (ACC) Suma la salida del operador de cada canal para mezclar el sonido FM y atacar el convertidor D/A

• Generador de onda cuadrada y de ruido. Genera tres ondas cuadradas diferentes y ruido seudo-blanco. Puede mezclar el

18 Yamaha también tenía su propio 8912


31

ruido y las ondas cuadradas. En cuanto al volumen puede ser fijo o determinado por diez envolventes distintas. Existe un convertidor D/A por cada sonido.

• Puerto de control de Entrada / salida Son de nuevo dos puertos de propósito general de Entrada / salida

• Temporizador Se proveen dos tipos de temporizadores.

Modelo de programación Comparte el mismo modelo que el YM-2149; y añade un nuevo conjunto de registros. grosso modo el mapa de registros es el siguiente:

(1) $00 ~ $05 Frecuencia de las ondas senoidales.

(2) $06 Frecuencia de la fuente de ruido. (3) $07 Control de los puertos de E/S.

(4) $08 ~ $0A Volumen. Puede ser fijo (por CPU) o variable (por el generador de envolvente)

(5) $0B ~ $0C Controla el ciclo de envolvente en el sistema de volumen variable

(6) $0D Especifica la forma de la envolvente.

(7) $0E ~ $0F Dos puertos de 8-dígitos de propósito general

(8) $21 Información de prueba, siempre vale “0”

(9) $24 ~ $26 Tiempo de disparo de los temporizadores A y B

(10) $27 Controla la operación de los temporizadores.

(11) $2D ~ $2F Especifica por cuanto se divide la señal de reloj de entrada.

(12) $30 ~ $3E Controla la relación entre el tono principal y el primer armónico.

(13) $40 ~ $4E Controla el nivel total. Es el índice de modulación para la envolvente.

(14) $50 ~ $5E Controles de clave y escala. Control del tiempo de ataque de la envolvente.

(15) $60 ~ $6E Tiempo de caída de la envolvente.

(16) $70 ~ $7E Tasa de mantenimiento de la envolvente.

(17) $80 ~ $8E Nivel de mantenimiento de la envolvente.

(18) $90 ~ $9E Generación del patrón de la envolvente.

(19) $A0 ~ $A6

Número de frecuencia de cada canal


32

(20) $A8 ~ $AE

Número de frecuencia de los canales en el modo especial (CSW)

(21) $B0 ~ $B2 Sistema de conexión de los operadores

Se han añadido nuevos registros para controlar las operaciones de FM pero además ahora hay dos temporizadores que ayudarán al procesador a controlar más adecuadamente el sonido que ha de orquestar.

El YM-2151, sintetizador FM de varios operadores. El YM-2151 representa uno de los sintetizadores profesionales más extendidos. Ahora el integrado ya está plenamente dedicado a sonido FM y existen más operadores así como nuevas posibilidades (estéreo, señales primitivas asenoidales) Con el terminamos este breve paseo por los sintetizadores FM y para culminarlo ofreceremos un circuito donde se muestra la forma de conectar este integrado.

Características

• Genera hasta ocho notas simultáneamente • Produce ruido • El timbre puede ser cambiado temporalmente. • El armónico superior puede ser extraído de la frecuencia base. • Desarmonización entre octavas. • Configuración de intervalos de hasta 1.6 centésimas de segundo. • Añade vibrato y modulación de amplitud. • Genera una amplia variedad de efectos a través de la desarmonización del

armónico superior de la frecuencia base, vibrato masivo y modulación de amplitud.

Descripción de funciones El mapa de registros ocupa 256 octetos; y sirve para configurar los circuitos que producen el sonido. Vamos a ver qué significan algunos de estos registros. B: WRITE BUSY FLAG (Sólo lectura). Por primera vez aparece un elemento de sincronización. Cuando sea necesario escribir continuamente en el integrado hay que consultar este dígito y comprobar que sea cero antes de continuar. KON: KEY ON Activa la salida de un canal. Generador de fase: Utiliza la combinación de los siguientes valores: KC: KEY CODE( Octava, nota) Se guarda la nota en 7-dígitos, tres para la octava y cuatro para la nota. KF: KEY FRACTION Compuesto por 6-dígitos permite separar la información de fase dividiendo el intervalo de nota MUL: PHASE MULTIPLY Sirve como factor que multiplica a KC y KF DT1 (DETUNE 1) Se utiliza para desemparejar la información de fase con la de frecuencia. DT2 (DETUNE 2) Idéntico al interior. Cuando se desincroniza fase y frecuencia se producen efectos sonoros útiles.


33

PMS: PHASE MODULATION SENSITIVITY Sirve para obtener sonido vibrantes y temblantes. Operador FM: Lee la información de fase del generador de fase y recorre la tabla senoidal. La señal leída se multiplica por la información de envolvente. CON (CONNECTION) Define cómo se conectan los operadores FL: SELF FEEDBACK LEVEL La salida del operador puede realimentarle as sí mismo. Este parámetro indica en qué grado lo hace. Generador de envolvente Su comportamiento se define por los cuatro segmentos que componen la envolvente. La forma de la envolvente comienza a producirse cuando se da el valor KEY ON Tasa de ataque Tasa de primera caída Tasa de segunda caída Tasa de liberación (o desaparición) TL: TOTAL LEVEL Representa el volumen máximo para la nota. AMS: AMPLITUDE MODULATION SENSITIVITY Define si la nota se ve modulada en amplitud, y en qué medida. Generador de ruido: El ruido también está controlado por el generador de envolvente, sólo que aquí el ataque ya no es logarítmico, sino exponencial. NE: NOISE ENABLE Caso de activarse sonará el ruido NFRQ: NOISE FREQUENCY La relación entre NFRQ y la frecuencia de ruido es

NFRQkHzkHzf M

noise *32)(

)(φ

= donde kHzM 545.3579=φ Y puede variar entre 3.5 kHz hasta

111.9 kHz LFO: Low Frequency OSC Provee de sonido a la modulación de frecuencia y de amplitud. LFRQ: LOW FREQUENCY Se fija la frecuencia de oscilación con 8-dígitos W: WAVE FORM Se elige entre ocho formas de onda, variantes de señales en rampa, triangulares, cuadradas y ruido. PMD/MAD: PHASE MODULATION DEPTH/AMPLITUDE MODULATION DEPTH: Representa los índices de modulación. Temporizadores El circuito dispone de dos temporizadores programables, uno de 10-dígitos y otro de 8-dígitos. Provocan una interrupción cuando su cuenta ha terminado.


34

Circuito de ejemplo En la figura siguiente se muestra cómo se conecta el YM-2151 al convertidor D/A compañero YM-3012. A este se le conectan seguidamente cuatro operacionales que proporcionan tensiones de referencia o hacen de seguidores de tensión para la salida de los canales de audio.

Circuito recomendado del YM2151


35

La arquitectura del sistema Vamos a explicar en esta sección la arquitectura electrónica básica de una máquina recreativa con varios diagramas de bloques para luego analizar con los esquemas reales el diseño electrónico de los juegos Ms Pacman y Gryzor.

Bloques fundamentales Una máquina de videojuegos se compone básicamente de un sistema de proceso, un sistema de vídeo y un sistema de entrada de datos:

Bloques fundamentales

el sistema de entrada tiene dos labores:

• comienzo de la partida: monedero y botón de comienzo • juego: palanca y botones

el sistema de proceso realiza las funciones de:

• presentación del videojuego hasta que comienza una partida • análisis de la entrada del usuario • desarrollo del juego • ordenar cómo se ha de dibujar la pantalla

y el sistema de vídeo:

• dibujo de la pantalla en una memoria RAM • uso de esa memoria para dibujar la imagen en un monitor de rayos catódicos


36

Si reducimos un nivel la abstracción; la entrada es un conjunto de interruptores, el sistema de proceso se descompone en UCP más memorias y el sistema de vídeo en dos secciones:

diagrama básico de una placa de videojuegos


37

El diagrama superior representa lo que ocurre básicamente en el sistema, pero aun es demasiado abstracto. Las máquinas también tienen sonido y éste se produce por un circuito especializado que se conecta también al procesador y cuya salida ha de ser convertida a señal analógica y amplificada. El siguiente diagrama representa esta situación.

diagrama básico de una placa de videojuegos con sonido


38

Sin embargo esta situación dejó pronto de darse, los juegos eran cada vez más complicados y requerían más potencia de cálculo, por lo que la función de dirigir la orquesta pasó a ser desempeñada por un segundo procesador que recibía órdenes a través de un registro, de un octeto de longitud.

diagrama básico de una placa de videojuegos con sonido y dos procesadores


39

Esquema eléctrico de Gryzor Para seguir profundizando en el conocimiento de los sistemas de máquinas recreativas vamos a analizar el esquema de Gryzor repasando los bloques fundamentales y estudiando la conexión entre ellos. En todas las imágenes, las líneas remarcadas en verde indican el bus de datos y las anaranjadas el de direcciones. Todos los integrados que comiencen por 00 (doble cero) son circuitos propios de Konami.

Las palancas de juego y las monedas

Conexión de las entradas Todas las señales procedentes del usuario: movimientos de palanca, pulsaciones de botones e inserción de monedas siguen el mismo esquema que el mostrado en la figura. En ella podemos ver las siguientes señales, de arriba abajo: arriba del 1er jugador, del 2º jugador, 2ª moneda, derecha del 1er jugador, del 2º, 1ª moneda, izquierda del 1er jugador y del 2º. Todas ellas pasan por un integrado de Konami numerado 005273 y que no es más que un eliminador de rebotes. A continuación se introducen en un LS253, que como se lee en la figura es un multiplexor dual de palabras de cuatro dígitos con salida triestado. Las entradas B y A provienen de las patillas A1 y A0 del bus de direcciones del 6809 y la s entradas de habilitación 1G y 2G se atacan con la señal I0EN (Input Enable, habilitación de las entradas)


40

Los microinterruptores DIP

conexión de los microinterruptores

Los microinterruptores se conectan a través de búferes triestado controlados por el bus de direcciones, se utilizan las típicas resistencias a nivel alto para limitar la corriente que circula cuando los interruptores se cierran. El procesador accede a estos interruptores como si se tratase de un registro de sólo lectura. Nótese además que no es necesaria la presencia de antirrebotes puesto que estos interruptores se modifican sólo durante la puesta a punto del equipo.

Los cuentamonedas

bcuentamonedas

Los cuentamonedas son los que llevan la caja, es decir, la contabilidad del juego. Cada vez que la máquina acepta una moneda ha de enviar una señal a estos para que contabilicen la partida. La forma de hacerlo en Gryzor es a través de un registro LS174 que sigue los cambios de las señales provenientes del monedero y de un circuito propio, el 005924 que ataca a los cuentamonedas (externos a la placa)


41

El oscilador

Oscilador a 24MHz El oscilador usado en Gryzor es un cristal a 24MHz que sufre varias divisiones de frecuencia para servir a cada circuito.

El procesador principal

Conexión del procesador principal y las memorias El procesador responsable del juego, un 6809E, va conectado a dos memorias ROM de 64koct cada una y a una RAM de 8koct. Los buses del sistema van conectados además de a las entradas, a los circuitos gráficos y al registro de sonido (que comunica a este procesador con el responsable del sonido)


42

Los circuitos gráficos

Parte superior del primer circuito gráfico En Gryzor hay dos circuitos gráficos 007121, que posibilitan la existencia de dos fondos simultáneos en la imagen. Sólo hemos mostrado una parte de estos en la figura puesto que se trata de integrados inmensos con más de 200 conexiones. En la placa ocupan un tamaño notable por lo que seguramente, debajo del encapsulado cerámico se encuentren no uno sino varios circuitos integrados. Hemos querido destacar en la imagen el hecho de que estos circuitos se conectaban a memorias ROM (donde estaban los dibujos) y a memorias RAM (donde se pintaba la pantalla)

generador de color

Los circuitos gráficos desembocaban al final en un convertidor digital analógico que, visto en la placa, era una especie de plano con conexiones sólo por un lado. En su interior podían palparse componentes y su aspecto era como el de una serpiente debajo de cuya piel pudieran verse sus víctimas. Todo esto parece indicar que se trataba de un conversor resistivo realizado con componentes discretos. Esta pieza era muy sensible.


43

Procesador de audio

procesador de audio El segundo 6809E era responsable del sonido del equipo. La comunicación se realizaba a través de un registro donde el procesador principal escribía y éste leía tras responder a la interrupción que le hacía llegar el principal (ver el registro 13D en la figura). Podemos ver también que este procesador tenía un oscilador separado a 3,58MHz y contaba sólo con una memoria RAM de 1koct y una memoria ROM de 32koct. Las líneas de este subsistema siguen hasta la circuitería de música FM.


44

Circuito de sonido

Esquema de los circuitos generadores de sonido y de la etapa analógica Un YM-2151 es utilizado para generar la música y un YM-3012 es el convertidor digital analógico usado. El circuito es bastante similar al recomendado por Yamaha, salvo por la inclusión de un filtrado (activo) de paso bajo adicional. El circuito LA4445 es un amplificador de potencia que en la placa requería de un disipador.


45

Mecanismos de protección contra copias Pese a que una placa de circuito impreso no es tan fácilmente copiable como un programa de ordenador, en la práctica el precio de los equipos originales provocaba muchas veces la piratería de los grandes éxitos. El gran problema de las máquinas piratas era replicar la circuitería de diseño del equipo original, es decir los integrados a medida para el videojuego. Mediante un proceso de ingeniería inversa -similar al desarrollado para la programación de los emuladores presentados- se desentrañaba el funcionamiento de la circuitería de diseño y se sustituía por lógica discreta. Las placas piratas eran, por tanto, mucho mayores que las originales; estaban formadas en general por dos placas, una para el procesador principal, el de sonido y las memorias de programa y otra exclusiva para vídeo puesto que el vídeo era normalmente el único componente a medida de la placa.

portada de Double Dragon partida de Double Dragon

Hubo casos escandalosos como el de Double Dragon19, en Valencia era prácticamente imposible encontrar una placa original de este juego. La pirata no sólo era la más popular sino que además, debido a fallos en el diseño, se colgaba con mucha facilidad –algo raro en este tipo de equipos. El caso de Double Dragon es también paradigmático por su dificultad de pirateo. Un microcontrolador 63701 era el encargado de gestionar los objetos del juego y tenía la peculiaridad de tener el código encriptado. No era posible leer el contenido de la memoria de programa –interna- de este microcontrolador, por lo que la máquina se suponía incopiable. El éxito de este juego acrecentó la voluntad de copiarlo y finalmente se descifró no el código del programa en sí, sino lo que el procesador principal esperaba de él. Habiendo deducido las especificaciones se sustituyó el componente en el juego pirata por un 6809 y así quedó la placa con tres procesadores 6809 en lugar de los dos originales. La facilidad en copiar un juego de máquina recreativa estribaba en que el código de los procesadores, los gráficos y el sonido; es decir, el alma del juego; residía en memorias ROM fácilmente leíbles por cualquiera. La dificultad estribaba en los componentes de diseño, no disponibles en las tiendas, que contenía la placa. La situación era, como ya se ha dicho, pareja a la programación de un emulador: se tenían los datos, de ellos se

19 © 1987 Tecmos


46

deducían las fórmulas y los artificios que realizasen esas fórmulas con esos datos se diseñaban desde cero con lógica discreta (en un emulador, se programan); los piratas disponían, sin embargo, de una ventaja frente a los programadores de emuladores: tenían una placa original y los recursos para probarla e investigarla a fondo, de esa forma podían reemplazar el código del procesador principal en la placa auténtica y utilizarlo para desentrañar el funcionamiento de los circuitos de diseño con más facilidad que tan sólo mirando el código, como hace un programador de emuladores. Los intentos de codificar las memorias ROM tampoco fueron siempre exitosos. Se basaban en aplicar alguna operación lógica reversible bien a los datos, bien al código del programa. Esta operación se deshacía en un circuito de diseño; sin embargo la disponibilidad de la placa original y todos sus circuitos por parte de los piratas hacían que se pudiera investigar la encriptación y deshacerla.

portada de Haunted Castle partida de Haunted Castle Dado que el tener componentes de diseño y microcontroladores encriptados no bastó para parar la piratería, la empresa japonesa Konami dio un paso más allá y en 1988 comenzó a introducir juegos donde el procesador principal era un componente de diseño: bajo un encapsulado cerámico negro y sujeto por más de cuarenta patillas se escondía una UCP propia, de la que nadie conocía el juego de instrucciones. Las técnicas tradicionales de pirateo ya no podían aplicarse, porque si bien puede reemplazarse un circuito gráfico con lógica discreta, no puede realizarse un procesador con los mismos medios, máxime cuando ni se sabe cómo es el procesador por tratarse de un modelo privado sin venta al público. Este procesador se usó en juegos como Super Contra, Haunted Castle, Chequered Flag y Typhoon; todos ellos de Konami, desarrolladora del procesador privado. El tiempo todo lo cura, así recientemente el procesador privado de Konami fue desentrañado por Manuel Abadía y los juegos que lo utilizaban incorporados al multiemulador MAME. El procesador de Konami resultó ser un 6809 modificado: se habían cambiado los códigos de las instrucciones y se habían añadido algunos nuevos registros y operaciones. La forma en que Abadía descubrió el funcionamiento del procesador de Konami se basó en la observación del código máquina buscando una lógica en él: unas ciertas operaciones al inicio de la máquina, códigos de operación muy repetidos. Se esperaba que el procesador fuera en el fondo un 6809 así que eso ayudó, el esquema electrónico siguiente contiene la guía de descodificación de instrucciones del procesador de Konami.


47

codificación del procesador de Konami.

Las líneas P, representan al procesador; las A, el bus de memoria y las D el bus de datos

He aquí un extracto del código fuente del multiemulador MAME20, que codifica el circuito mostrado: unsigned char decodebyte( unsigned char opcode, unsigned short address ) /* > CPU_D7 = (EPROM_D7 & ~ADDRESS_1) | (~EPROM_D7 & ADDRESS_1) > > CPU_D6 = EPROM_D6 > CPU_D5 = (EPROM_D5 & ADDRESS_1) | (~EPROM_D5 & ~ADDRESS_1) > > CPU_D4 = EPROM_D4 > CPU_D3 = (EPROM_D3 & ~ADDRESS_3) | (~EPROM_D3 & ADDRESS_3) > > CPU_D2 = EPROM_D2 > CPU_D1 = (EPROM_D1 & ADDRESS_3) | (~EPROM_D1 & ~ADDRESS_3) > > CPU_D0 = EPROM_D0 */ unsigned char xormask; xormask = 0; if (address & 0x02) xormask |= 0x80; else xormask |= 0x20; if (address & 0x08) xormask |= 0x08; else xormask |= 0x02; return opcode ^ xormask;

20 El proyecto MAME es un intento de emular con un único programa todas las máquinas diseñadas. El autor colaboró con información técnica sobre Combat School y Gryzor. Videre www.mame.net


48

La compañía española Gaelco utilizaba también microcontroladores para proteger sus juegos. El dispositivo que usaron fue el Dallas DS500, que no permitía el acceso al código una vez grabado. Gaelco recubría toda la porción de la placa alrededor del Dallas con una carcasa negra, a modo de integrado de diseño, y amenazaba con anular la garantía si ésta se quitaba.

Microcontrolador empleado por Gaelco

En los años 90 la piratería comenzó a dejar de ser rentable y fue decayendo como poco después caería toda la industria del videojuego de salón. El uso de circuitos gráficos más complicados, que ya no podían realizarse con lógica discreta, el tamaño creciente de las memorias ROM que dificultaba su compra a pequeña escala y la pérdida de mercado en pro de las consolas domésticas fue haciendo desaparecer la industria pirata que gozó a mediados de los años 80 de su cenit.


49

2ª Parte Tras haber descrito la construcción de los sistemas de máquinas recreativas en la primera parte; en esta segunda vamos a explicar cómo se realiza la emulación de estos equipos, teniendo en mente la plataforma PC como emuladora.

Modelo de un emulador Vamos a presentar en esta sección modelos UML que describen el funcionamiento de un emulador, estos diagramas ilustran con sencillez el funcionamiento de los programas desarrollados.

Diagrama principal Las dos funciones básicas que ejecuta un emulador consisten en la preparación del entorno y en la ejecución –en un bucle continuo- de la emulación.

diagrama principal de un emulador

• Arranque: incluye el análisis de la línea de comandos, la reserva de memoria, la carga de los ficheros ROM en ella y el arranque del procesador virtual

• Bucle de emulación: ejecuta un lapso de instrucciones del juego emulado, interpreta la memoria gráfica para pintar la pantalla y actualiza los puertos de entrada virtuales para reflejar las pulsaciones de teclado del jugador.


50

El arranque Las operaciones de arranque preparan el programa para ejecutar la emulación y configuran algunos aspectos de la misma

procedimientos de arranque

• Análisis de la línea de comandos: el usuario puede escribir opciones cuando ejecuta el emulador para modificar aspectos como el directorio donde están los ficheros ROM, la resolución de pantalla a utilizar, activar o desactivar el sincronismo con la señal de barrido vertical del monitor21

• Carga de las memorias ROM: el emulador en sí no contiene el juego en absoluto, no es más que en conjunto de rutinas que simulan el comportamiento de un circuito controlado por un programa. Ese programa estaba contenido en memorias ROM cuyo volcado en ficheros binarios se carga al comienzo de la emulación

• Descodificación de los gráficos: las imágenes almacenadas en las memorias ROM están en un formato apto para la circuitería gráfica original pero que no resulta práctica para los circuitos de un ordenador moderno; por lo tanto hay que reordenar los dígitos y los puntos de forma que resulten manejables por el ordenador.

• Preparación del procesador virtual: para que éste sea capaz de ejecutar el juego hay que colocar las memorias ROM tal y como estaban en el original y hay que iniciar los registros internos con los valores adecuados (posición del vector de arranque, de la pila...)

21 Sobre este sincronismo se hablará más adelante en el apartado de “Sincronía”


51

Bucle de la emulación Tras el arranque del sistema, el programa entra en bucle sin fin como sigue:

diagrama del bucle de la emulación

• Ejecución de N instrucciones: el procesador virtual recibe la orden de emular

N instrucciones, siendo N el número de operaciones ejecutables en el lapso que hay entre dos refrescos de pantalla. Si el monitor de la máquina funcionaba a 60Hz, ese lapso será de 16,7ms virtuales. Naturalmente ese tiempo virtual necesita ser simulado en muchos menos milisegundos para dar tiempo al ordenador a realizar otras funciones.

• Dibujado de la pantalla: después del lapso anterior el procesador virtual ha debido de dejar órdenes en los registros de la circuitería gráfica (mapeados en memoria) para pintar la pantalla. Estas órdenes se interpretan en este paso para dibujar en el ordenador el fotograma del juego.

• Lectura del teclado: se comprueba el estado de las palancas de juego y de las teclas para informar al procesador virtual a través de sus puertos de entrada (mapeados en memoria)

• Interrupción del sincronismo: Cada vez que se producía un refresco vertical en la máquina, se disparaba una interrupción; de esta forma el procesador tenía conciencia del tiempo transcurrido y utilizaba la interrupción como sincronización. El monitor sólo refleja los cambios en la imagen cada vez que el haz recorre el tubo así que el tiempo de retraza vertical es en el que se puede modificar la imagen con seguridad de no provocar particiones (media pantalla del fotograma anterior y la otra media del nuevo)


52

De este bucle sólo se puede salir por imperativo del usuario, habitualmente a través de la tecla de escape, en caso contrario el bucle es infinito, como lo sería en una máquina real.

El bucle de la máquina real Existe un gran paralelismo entre el bucle de emulación y el bucle de juego que ejecuta el procesador virtual internamente. Podemos entender el videojuego como una máquina de estados en la que las pulsaciones del usuario la hacen conmutar de uno a otro estado. Cuando se encuentra en medio de una partida, de una fase determinada, la máquina ejecuta constantemente este bucle:

bucle principal del juego (procesador virtual)

Como vemos las acciones son esencialmente las mismas: lectura de las entradas, ejecución de unas instrucciones (en este caso para mover al jugador, a los enemigos, el fondo, etc.), esperar la interrupción que dará vía libre a la pantalla sin que el usuario note que se está modificando la imagen y el pintado en sí. El contenido de la casilla Desarrollo de la acción es lo que realmente cambia de una fase del juego a otra o del estado de atracción de jugadores (el famoso introduzca una moneda) al estado de juego; las otras acciones son las mismas siempre.


53

Ingeniería inversa: investigación del equipo Cuando se va a realizar el emulador de una máquina se dispone únicamente de un conjunto de ficheros binarios obtenidos a partir de las memorias EPROM y ROM de la placa original. Si uno ha realizado el volcado por sí mismo tendrá al menos una idea a partir de la posición que ocupaban las memorias de su utilidad, pero lo normal es que el volcado provenga de una persona desconocida o que haya sido descargado de alguna página de interné. El punto de partida es, por lo tanto, un juego de ficheros de contenido desconocido y un amasijo de recuerdos sobre como era el original. Con un poco de suerte, será posible conseguir por interné fotografías de la máquina que nos orienten mínimamente en cuanto a la paleta gráfica. En este capítulo vamos a estudiar el caso de Gryzor, cómo se realizó el análisis de los ficheros y de su contenido hasta extraer suficiente información como para realizar el emulador. Posteriormente se comentará el desarrollo de un programa llamado Analizador y que sirvió para investigar Combat School. Sobre Ghosts & Goblins no diremos nada puesto que la información técnica de esta máquina fue suministrada por Paul Leaman y Roberto Ventura; quienes desarrollaron emuladores por su cuenta para este juego.

Investigación de Gryzor Nada más recibir el volcado de la ROM procedente de Lewin Edwards (Australia) lo único que se podía ver era: Directorio de C:\pfc\gryzor\Rom 20/09/1997 18:33 32.768 G-1.ROM 20/09/1997 18:48 65.536 G-10.ROM 20/09/1997 18:49 65.536 G-11.ROM 20/09/1997 18:50 65.536 G-12.ROM 20/09/1997 18:51 65.536 G-13.ROM 20/09/1997 18:51 65.536 G-14.ROM 20/09/1997 18:52 65.536 G-15.ROM 20/09/1997 18:53 65.536 G-16.ROM 20/09/1997 18:54 65.536 G-17.ROM 20/09/1997 18:55 65.536 G-18.ROM 20/09/1997 18:35 65.536 G-2.ROM 20/09/1997 18:37 65.536 G-3.ROM 20/09/1997 18:39 65.536 G-4.ROM 20/09/1997 18:43 65.536 G-5.ROM 20/09/1997 18:44 65.536 G-6.ROM 20/09/1997 18:46 65.536 G-7.ROM 20/09/1997 18:47 65.536 G-8.ROM 20/09/1997 18:47 65.536 G-9.ROM 18 archivos 1.146.880 bytes 0 dirs 1.827.024.896 bytes libres Un total de 18 archivos y algo más de 1Moct, ¡comparado con los escasos 300 koct de G&G el juego prometía! Afortunadamente algo se sabía de la placa: llevaba dos


54

procesadores 6809. Así que entre esos ficheros debía haber algunos que, pasados por un desensamblador, tuviesen sentido. Por interné circulan varios desensambladores de este procesador, el escogido fue el d6809.

Fichero g-1.rom Al ejecutar d6809 g-1.rom > g-1.s y leer la salida vemos: ORG $0000 0000: F7 60 22 STB $6022 0003: F6 20 01 LDB $2001 0006: C4 80 ANDB #$80 0008: 26 F9 BNE $0003 000A: B7 20 00 STA $2000 000D: F6 20 01 LDB $2001

0010: C4 80 ANDB #$80 0012: 26 F9 BNE $000D 0014: F6 60 22 LDB $6022 0017: F7 20 01 STB $2001 001A: 39 RTS 001B: CC 14 39 LDD #$1439 001E: 8D E0 BSR $0000 0020: CC 12 F9 LDD #$12F9 0023: 8D DB BSR $0000 0025: CC 14 3B LDD #$143B 0028: 20 D6 BRA $0000 etc.

La secuencia de instrucciones tiene sentido: primero salva el valor en B, entonces carga el valor en 2001h22 le aplica una operación y según el resultado salta a una posición u otra. Tras unas cuantas líneas se termina con un retorno desde subrutina (RTS). Todo tiene sentido. Si abrimos el fichero G-1.ROM con un editor hexadecimal veremos que los dos últimos octetos son 802A. Eso, en un 6809, indica la posición de arranque del código. Sin embargo el fichero no tiene una longitud tan grande (sólo ocupa 8000h octetos) así que la lógica implica que esta memoria ocupaba los 32koct superiores de un procesador 6809, de esa forma la posición 802A sería la 002A del fichero. Desensamblando a partir de ahí:

002A: 10 8E 60 00 LDY #$6000 002E: 4F CLRA 002F: A7 A0 STA ,Y+ 0031: 10 8C 67 FF CMPY #$67FF 0035: 26 F8 BNE $002F 0037: 10 CE 68 00 LDS #$6800 003B: 86 60 LDA #$60 003D: 1F 8B TFR A,DP 003F: 1C EF ANDCC #$EF 0041: BD 82 B5 JSR $82B5 0044: 86 07 LDA #$07

22 Es importante tomar nota de posiciones explícitas de memoria pues indican puertos de E/S (dispositivos mapeados en memoria)


55

0046: B7 60 31 STA $6031 0049: 86 08 LDA #$08 004B: B7 60 34 STA $6034 004E: 8D CB BSR $001B 0050: CC 08 00 LDD #$0800 0053: 8D AB BSR $0000 0055: F6 60 22 LDB $6022 0058: 5C INCB 0059: C1 08 CMPB #$08 etc.

Para que este código sea coherente ha de cumplir que no presuponga nada, puesto que suponemos que es el de arranque del procesador. Si seguimos las instrucciones vemos que efectivamente el código comienza a construir el proceso sin suponer ningún valor conocido en registros ni en memoria. Así que aceptamos la hipótesis: este fichero corresponde a un 6809 y ocupa los 32koct superiores de la memoria. Siguiendo con el desensamblado llegamos a puntos tales como:

0698: FE 00 00 LDU $0000 069B: 0F 0A CLR $0A 069D: 1F 00 TFR D,D 069F: 00 F8 NEG $F8 06A1: 00 8C NEG $8C 06A3: 1F 16 TFR X,inv 06A5: 00 F8 NEG $F8 06A7: 01 Illegal Opcode 06A8: 90 1F SUBA $1F 06AA: 12 NOP 06AB: 00 F8 NEG $F8 06AD: 01 Illegal Opcode 06AE: 90 1F SUBA $1F 06B0: 12 NOP 06B1: 00 F8 NEG $F8 06B3: CE 86 98 LDU #$8698 06B6: BD 83 FC JSR $83FC 06B9: CC 07 50 LDD #$0750 etc.

Estos tramos de desensamblado con códigos de operación ilegales corresponden a datos y no a programa por eso su desensamblado no tiene sentido. Un vistazo al resto de este fichero muestra algo imprevisto: esta casi vacío. No parece, por tanto, probable que sea el programa principal pero por otra parte contiene código de arranque. La conclusión es que este fichero pertenece al procesador de sonido.


56

Fichero G-2.rom Al comenzar a desensamblar este fichero lo primero que encontramos es desolador:

0000: 00 00 NEG $00 0002: 00 00 NEG $00 0004: 00 00 NEG $00 0006: 00 00 NEG $00 0008: 10 00 Illegal Opcode 000A: 10 00 Illegal Opcode 000C: 10 00 Illegal Opcode 000E: 10 00 Illegal Opcode etc.

Sin embargo, si seguimos escudriñando encontramos secciones como esta:

EF56: A6 10 LDA $FFF0,X EF58: 84 BF ANDA #$BF EF5A: E6 13 LDB $FFF3,X EF5C: EA 03 ORB $0003,X EF5E: C4 01 ANDB #$01 EF60: 26 02 BNE $EF64 EF62: 8A 40 ORA #$40 EF64: A7 10 STA $FFF0,X EF66: 39 RTS

Esta rutina es completamente coherente e indica la existencia de código en el fichero. Si miramos los dos últimos octetos –en busca del vector de arranque- encontramos 8000h, como este fichero tiene 64koct (10000h octetos) desensamblamos desde la posición 8000h (32koct) para descubrir:

8000: 4F CLRA 8001: B7 00 07 STA $0007 8004: 97 F0 STA $F0 8006: B7 70 00 STA $7000 8009: 7E 61 11 JMP $6111

Estas simples instrucciones entrañan mucha información de valor: comienzan borrando el registro A, lo cual es importante porque implica que el programa no espera un valor de antemano –cosa imposible en un arranque; a continuación almacena ese valor nulo en tres posiciones de memoria concretas -lo que indica su importancia- y más tarde salta a la posición 6111h. Esta posición es importante porque es menor que 8000h que era la de arranque. Si hacemos cuentas tenemos que

• Esta memoria parece válida para arrancar desde ella • Para ello los últimos 32koct de este fichero han de ocupar la mitad superior de

la memoria del 6809, esto es así porque el vector de arranque está al final del fichero y la posición que éste indica está 32koct antes

• En consecuencia quedan sólo 32koct para el resto de elementos: RAM, páginas de ROM, memoria de vídeo y otros puertos de E/S


57

A partir de estos datos, y de la experiencia acumulada con el Ghosts&Goblins, la conclusión es que la memoria paginada ocupa probablemente desde 6000h hasta 7FFFh y además el registro de paginación está en una de estas posiciones: 0007h, 00F0h o bien 7000h. ¿Por qué desde 6000h? Porque el código de arranque salta a la posición 6111h, sería viable que las páginas empezaran en la posición 6111h pero parece algo caprichoso. La opción más sistemática, más ingenieril es 6000h. ¿Por qué hasta 7FFFh? Porque el código de arranque empieza en la posición 8000h. ¿Y por qué esas tres posibles direcciones para el registro de paginación? Porque son las tres iniciadas antes de saltar a la memoria paginada. Existe todavía otro argumento a rebatir: ¿Por qué no aceptar que el código en 6111h es sencillamente el que precede en el fichero al que está en 8000h, es decir, sin paginación, el fichero tal cual? La respuesta es indiscutible: si desensamblamos la posición 6111h del fichero G-2.rom encontramos:

6111: 70 06 80 NEG $0680 6114: 06 70 ROR $70 6116: 06 60 ROR $60 6118: 00 01 NEG $01 611A: 61 Illegal Opcode 611B: 1C 06 ANDCC #$06 611D: 70 06 80 NEG $0680 6120: 06 90 ROR $90 etc.

código absurdo y con instrucciones ilegales. Hemos obtenido además otra información adicional: el segmento 6000h-7FFFh de G-2.rom no corresponde a la página número cero, sea cual sea el registro de paginación. ¿Cómo sabemos que no es la página cero? Porque el proceso seleccionó la página cero antes de saltar a 6111h, si este segmento no contiene nada válido en esa posición es porque no es la respuesta. ¿Dónde esta el código correspondiente a 6111h? Antes de responder esta pregunta, echemos un vistazo al siguiente archivo.


58

Fichero G-3.rom El comienzo del desensamblado de este fichero no podría ser más halagüeño:

0000: 8D 24 BSR $0026 0002: CE 30 00 LDU #$3000 0005: 96 F1 LDA $F1 0007: 84 08 ANDA #$08 0009: 26 03 BNE $000E 000B: CE 38 00 LDU #$3800 000E: BD 60 B5 JSR $60B5 0011: BD 60 AE JSR $60AE 0014: 86 11 LDA #$11 0016: 97 54 STA $54 0018: CC F0 08 LDD #$F008 001B: A7 42 STA $0002,U 001D: E7 44 STB $0004,U 001F: 33 45 LEAU $0005,U 0021: 0A 54 DEC $54 0023: 26 F6 BNE $001B 0025: 39 RTS etc.

Una rutina completa y con sentido. Las sorpresas no acaban aquí, si cargamos el fichero con un editor hexadecimal encontramos resultados como el mostrado en la imagen inferior:

Vista de G-3.rom con un editor hexadecimal

Como vemos aparecen multitud de palabras legibles en ASCII, tales como: COIN1, COIN2,DEMO SOUND, DIFFICULTY, FIRST AT, EASY,TEST, DIP, SERVICE, etc. Sin lugar a dudas nos encontramos ante un nuevo fichero de código de 6809, otros 64koct más de programa. Antes de seguir investigando el funcionamiento del juego veamos qué hay en los otros archivos.


59

Ficheros G-4, G-5, G-6... El desensamblado de los restantes ficheros no arroja ninguna información congruente; sin embargo, su volcado hexadecimal muestra patrones repetitivos lo que sugiere que estos archivos contienen los gráficos del juego. El desentrañado de la codificación gráfica es una labor costosa pero generalmente asequible tras varios intentos, no hay un método definido para realizarla pero si que debemos tener algunas ideas en mente:

• Los gráficos se almacenarán como mezcla de puntos, planos de color y bloques • Los elementos anteriores pueden combinarse bien en un solo fichero, bien en

varios de ellos • Cada tipo de gráficos puede tener una cantidad de planos y área de los bloques

distinta • Los gráficos pueden estar almacenados girados 90, 180 o 270 grados • Obviamente, no se dispondrá de los colores reales hasta que se avance en la

emulación. Al contrario de los formatos modernos de imágenes, en las máquinas recreativas no se incluía la paleta gráfica junto a la imagen, sino que ésta estaba mezclada con el programa

Sobre la codificación de estos ficheros consúltese la sección dedicada a las memorias gráficas de Gryzor más adelante.

Análisis del código Anteriormente habíamos llegado a la conclusión de que el juego arrancaba con los 32koct superiores de G-2.rom y que entonces saltaba a una rutina sita en 6111h, ¿pero en qué fichero está esa rutina? Siguiendo con la hipótesis de que las páginas son de 8koct (2000h octetos) debemos buscar esa rutina en las posiciones x111h de los ficheros G-2.rom y G-3.rom donde x es una cifra par (porque al mapear ese fichero en la memoria comenzará a partir de 6000h, luego para que x111h se convierta en 6111h, dadas páginas de longitud 2000h; x ha de ser par) Comenzamos a buscar en G-2.rom. En la posición 0111h encontramos código en principio válido:

0111: B7 60 2C STA $602C 0114: 39 RTS

Almacena A, cuyo valor era cero, y vuelve... realmente no tiene sentido puesto que la llamada a 6111h era en realidad un salto y no una invocación a subrutina. Descartamos, por tanto, el bloque 0000-1FFFh de G-2. rom como página cero. Veamos el siguiente: 2000h-3FFFh:

2111: 23 2A BLS $213D 2113: 23 2D BLS $2142 2115: 23 05 BLS $211C 2117: 23 04 BLS $211D


60

El desensamblado no tiene sentido, ¿por qué hacer un salto condicional nada más comenzar la emulación, en base a qué? Además cerca de estas instrucciones hay operaciones ilegales. Queda descartado 2000h-3FFFh, veamos 4000h-5FFFh:

4111: 33 33 LEAU $FFF3,Y No cabe discusión alguna sobre ésta: utiliza el registro Y pero éste no había sido iniciado antes, no puede ser, por tanto, la que buscamos. Aun queda el bloque 6000h-7FFFh:

6111: 70 06 80 NEG $0680 6114: 06 70 ROR $70 6116: 06 60 ROR $60 6118: 00 01 NEG $01 611A: 61 Illegal Opcode

Una vez más hemos fracasado en la búsqueda. Vayamos ahora al siguiente fichero: g-3.rom, comenzando desde el principio:

0111: 86 01 LDA #$01 0113: C6 05 LDB #$05 0115: 8E 80 00 LDX #$8000 0118: B7 00 1E STA $1E 011B: 30 1F LEAX $FFFF,X 011D: 26 F9 BNE $0118 011F: 5A DECB 0120: 26 F3 BNE $0115 etc.

El fragmento mostrado tiene doble lógica: no presupone valores en los registros –como corresponde al arranque- y es un bucle de espera. ¿Qué mejor hacer al arrancar el equipo que esperar a que el monitor se encienda completamente? En el interior del doble bucle (resaltado en verde) vemos insistentes escrituras del valor ‘1’ en la posición 001E, lo que indica –con pocas dudas- que esa es la posición del registro de autoarranque23. Ya estamos tras la pista correcta, ahora queda seguir leyendo el código fuente con ojos críticos para ir averiguando más y más. Tras la espera, el programa sigue su labor iniciando diversas posiciones de memoria con valores conocidos hasta que llega a24:

6182: 4F CLRA 6183: CE 10 00 LDU #$1000 6186: 8E 10 00 LDX #$1000 6189: B7 00 1E STA AUTOARRANQUE 618C: A7 C0 STA ,U+ 618E: 30 1F LEAX $FFFF,X 6190: 26 F7 BNE $6189 6192: CE 10 00 LDU #$1000 6195: 8E 10 00 LDX #$1000

23 El registro de autoarranque se incrementaba automáticamente por la circuitería externa al procesador, en caso de llegar a cero provocaba el arranque del sistema. Servía para solucionar cuelgues inesperados en la máquina. 24 En el código siguiente se ha adaptado la numeración a la posición real en memoria: 0182h ha pasado a ser 6182h, además a la dirección 001E se le llama AUTOARRANQUE, en base al razonamiento anterior.


61

6198: A1 C0 CMPA ,U+ 619A: 10 26 01 4F LBNE $62ED

619E: 30 1F LEAX $FFFF,X 61A0: 26 F6 BNE $6198 61A2: 8B 55 ADDA #$55 61A4: 81 54 CMPA #$54 61A6: 26 DB BNE $6183

Este fragmento es muy significativo: se realizan escrituras y verificaciones de lo escrito con los siguientes valores: 00h, 55h, AAh, FFh. Dicho así no dice mucho, pero ¿y en binario?

Hexadecimal Binario 00 0000000055 01010101

AA 10101010FF 11111111

La secuencia de valores cumple la condición de haber hecho pasar a todos los dígitos por ‘1’ y por ‘0’. Estamos, por tanto, ante un fragmento de código que verifica el funcionamiento correcto en cuanto a lectura y escritura de todos los dígitos desde 1000h hasta 1FFFh. Lo que se deduce de esto es que la región 1000h-1FFFh es una memoria RAM de 4koct. Esta información es fundamental a la hora de ir elaborando el mapa de memoria de la máquina. Si lo anterior era una verificación de la RAM, ¿qué ocurría si ésta fallaba? Siguiendo la rutina vemos que en caso de error se salta a 62ED, busquemos ese procedimiento:

62ED: 8E 26 49 LDX #$2649 62F0: CE 63 05 LDU #$6305 62F3: 5F CLRB 62F4: A6 C0 LDA ,U+ 62F6: 10 27 1D 06 LBEQ $8000 62FA: E7 89 FC 00 STB $FC00,X 62FE: A7 84 STA ,X 6300: 30 88 E0 LEAX -$20,X 6303: 20 EF BRA $62F4

Este sucinto fragmento encierra muchísima información sobre la máquina si se lee adecuadamente: se trata de un bucle que lee valores desde 6305 y los copia en 2649 y, paralelamente, escribe ceros en 2249 (STB $FC00,X). Tras llegar a un nulo reinicia la máquina saltando a 8000. Los valores en 6305 son: 01,03,14,10,10,12,11,14,00 (todos en hexadecimal); a bote pronto esto no nos dice mucho, lamentablemente no son códigos ASCII; sin embargo a estas alturas disponíamos de los bloques gráficos en formato visible y aunque no sepamos la correspondencia entre estos números y los bloques podemos echar un vistazo al orden en que aparecen en la ROM los bloques alfanuméricos para ver si le encontramos algún sentido:


62

Caracteres de Gryzor Cada fila tiene 16 bloques, interpretando la secuencia anterior podemos leer: 13D BAD. Es bien sabido que en las placas electrónicas se nombran los componentes siguiendo una matriz de números y letras para filas y columnas. Este escueto mensaje nos indica que el integrado en la posición 13D no funciona. Aun hay más información de valor en ese fragmento de código. Para escribir el mensaje en pantalla se han realizado escrituras en 2649 y 2249, además las hechas en 2249 han sido siempre ceros. De aquí se colige la siguiente hipótesis: hay un circuito gráfico mapeado desde las posiciones 2000 hasta 27FF que se descompone en dos, uno ocupa 2000-23FF y contiene los atributos de los bloques y otro ocupa 2400-27FF y contiene el número de bloque. Un tamaño de 400h octetos equivale a 322, es decir 32 filas por 32 columnas, rellenos con bloques de 8x8 puntos equivale a 256x256 puntos. ¡Hemos deducido la resolución de la pantalla! Aun no acaba aquí, esas nueve líneas de código nos van a decir algo más: el monitor está girado. Ya sabíamos que los gráficos estaban girados 90º (vide codificación gráfica de Gryzor) pero ahora vemos además que el programa ha escrito el mensaje de abajo a arriba: cada carácter está 20h bloques antes que el anterior, es decir 32 bloques, que según nuestra hipótesis equivale a una fila. La máquina esta imprimiendo cada mensaje encima del siguiente, sin embargo han de verse en posición horizontal en el monitor: conclusión, el monitor está volcado 90º. Esto es de capital importancia a la hora de realizar las rutinas gráficas. Cabe preguntarse, ¿por qué usar el monitor tumbado? Bien, Gryzor tenía una pantalla algo más larga que ancha, pese a que de momento trabajamos con la hipótesis de 256x256 puntos eso sólo atañe a este circuito gráfico; la resolución total aun está por hallar. Otra pregunta válida sería ¿Por qué suponemos que esta todo girado en la placa: los gráficos, la pantalla... no podría ser ese su funcionamiento normal? La realidad es que la circuitería gráfica de un videojuego solía utilizarse en otros, lo más sensato es pensar que estos circuitos se diseñaron para monitores horizontales y aquí se usan con uno en vertical, a costa de complicar la programación y de girar los gráficos. Tras ese código verificador se suceden más secuencias del mismo estilo, comprobando cada vez distintas áreas; como la [C00,D00[ (correspondiente a la paleta gráfica); la [2000,4000[ (los circuitos gráficos) y la [4000,6000[. Acto seguido el programa vuelve a la posición 800C, justo después de la llamada a 6111 ya comentada.


63

800C: CE 80 E6 LDU #$80E6 800F: CC 00 00 LDD #$0000 8012: DD 5C STD $5C 8014: CC 00 08 LDD #$0008 8017: DD 5E STD $5E 8019: BD 80 D3 JSR $80D3 801C: 0C 5E INC $5E 801E: 0A 5F DEC $5F 8020: 26 F7 BNE $8019 8022: 10 A3 C1 CMPD ,U++ 8025: 27 06 BEQ $802D 8027: 96 58 LDA $58 8029: 8A 80 ORA #$80 802B: 97 58 STA $58 802D: 8E 80 00 LDX #8000 8030: 10 8E 00 00 LDY #$0000 8034: BD 80 C5 JSR $80C5 8037: DD 5C STD $5C 8039: CC 08 04 LDD #$0804 803C: DD 5E STD $5E 803E: BD 80 D3 JSR $80D3 8041: 0C 5E INC $5E 8043: 0A 5F DEC $5F 8045: 26 F7 BNE $803E 8047: 10 A3 C1 CMPD ,U++ 804A: 27 06 BEQ $8052 804C: 96 59 LDA $59 804E: 8A 80 ORA #$80 8050: 97 59 STA $59 8052: 4F CLRA

Este bloque de código es fundamental, ya que es una comprobación de las memorias ROM que permite identificar las páginas. El programa hace llamadas a una rutina sita en 80D3 (que no mostramos) que suma todos los valores de la memoria y compara el resultado con los precalculados y guardados en la posición 80E6, de esta forma se determina si alguna de las ROM está corrupta. Como la verificación incluye las páginas obtenemos ahora los datos definitivos: 12 páginas de 8koct ubicadas en el área [6000,8000[ Con un pequeño programa en C se puede obtener el valor correspondiente a cada bloque de 8koct de las memorias G-2.ROM y G-3.ROM para compararlo con lo predicho en 80E6 emparejando de esta forma el código almacenado en el registro de página con el bloque que ha de copiarse en [6000,8000[. Siguiendo el código pueden verse rutinas de impresión en pantalla en 65EB donde se muestra el mensaje de “RAM OK” y de las que se puede extraer información adicional sobre el funcionamiento del vídeo. Cabe destacar que a estas alturas, con la paginación ya conocida, puede arrancarse el programa dentro del emulador sin que se cuelgue y de esta forma tener un banco de ensayo mucho mejor. Utilizando el emulador aun en desarrollo y volcados de memoria reales del proceso emulado se puede seguir desentrañando el funcionamiento de la máquina. Para esta labor se desarrolló una herramienta especifica a utilizar con el juego Combat School: el Analizador.


64

El “Analizador” de Combat School Con el propósito de facilitar la investigación de Combat School se desarrolló un programa para Windows utilizando las MFC25 que permitía un estudio cómodo y evolutivo de la máquina. Cómodo porque la emulación del procesador estaba integrada en el programa y evolutivo porque aceptaba modificaciones según se fuera descubriendo cómo funcionaba el equipo.

Pantalla de inicio del Analizador Las posibilidades del Analizador eran:

• emular el procesador y la memoria • mostrar un volcado de la memoria y el desensamblado de las instrucciones • mostrar el contenido de los registros del 6809 • dibujar las diferentes memorias gráficas • reconfigurar las páginas de la máquina • disparar interrupciones y reiniciar el procesador • añadir comentarios al código y guardarlo para ulterior referencia.

En muchos aspectos el Analizador se parecía a un depurador de código máquina como el usado en los laboratorios de SED26, aunque su objetivo era bien distinto. De entre las posibilidades mostradas la reconfiguración de las páginas era realmente importante al principio del proyecto, cuando no se sabía ni la posición del registro de paginación ni la equivalencia entre unas posiciones y otras. A continuación se detalla el uso de este programa que fue de gran utilidad para desarrollar el emulador Escuela de Combate; pese a que se invirtió bastante tiempo en su desarrollo, la ventaja de tener una plataforma de investigación robusta y fiable añadió rigor al proyecto y enriqueció el resultado final.

25 Microsoft Foundation Classes (Clases Básicas de Microsoft). Las MFC son un conjunto de clases de C++ que ofrecen una base para desarrollar aplicaciones más rápidamente que con C puro. 26 Sistemas Electrónicos Digitales, antigua asignatura del tercer año de Ingeniería de Telecomunicaciones en la UPV


65

Uso Cuando se ejecuta el Analizador, tras una pantalla de presentación, se nos ofrece una ventana típica de una aplicación MDI27. Los elementos se describen a continuación:

Partes de la ventana de Analizador

1. La barra de título: Se compone del nombre del programa (“Analizador”) seguido del nombre del documento activo, en el ejemplo “Arcade2”

2. La barra de menú: Permite acceder a todas las posibilidades del programa. Además de las opciones habituales hay dos menús (“Procesador” y “Memoria”) que centran el uso de la aplicación

3. La barra de herramientas: Es una vía rápida a las acciones del menú. Destacan los botones de traza, ejecución hasta el cursor y ejecución hasta el PC que serán explicados más tarde

4. Los documentos: Las ventanas de documento contienen una máquina virtual que emula a la recreativa, son independientes entre sí y se puede tener tantas como se quiera simultáneamente. Posteriormente se explicará con detalle esta ventana

5. El documento activo: La ventana seleccionada aparece con el título remarcado 6. La barra de estado: Presenta información sobre las opciones de los menús y la

barra de herramientas 27 Multiple Document Interface (Interfaz de Múltiples Documentos -pluridocumento), este acrónimo se refiere a las aplicaciones que albergan más de un documento a la vez en contraste con las SDI (Single Documente Interface, Interfaz monodocumento). Un ejemplo de aplicación monodocumento es Ms Paint y uno de pluridocumento Ms Excel.


66

El menú “Procesador” Las acciones disponibles son:

• Reiniciar: ejecuta la rutina de arranque del procesador devolviendo la máquina al estado inicial

• Traza: emula una instrucción del 6809, actualiza la memoria y los registros y devuelve el control al usuario

• Ejecutar hasta PC: el usuario introduce a través de un cuadro de diálogo la dirección hasta la que se emulará el procesador

• Configurar páginas: a través de un cuadro de diálogo el usuario establece la relación entre el número escrito en cierta posición de memoria considerada el registro de paginación y la página que se conmuta en la memoria del 6809. Esta opción se eliminó del programa cuando el funcionamiento de la paginación estuvo claro

Diálogo de configuración de las páginas

• Próxima imagen: ejecuta IPI instrucciones, lanza una interrupción y dibuja la

pantalla (en la ventana de vista gráfica) • Cargar / salvar estado: almacena o restaura el estado de la máquina, es decir:

memoria RAM y registros. Permite continuar el análisis donde se dejase anteriormente

• Disparar IRQ: inicia el proceso de interrupción del procesador. Las operaciones del 6809, sin embargo, no comenzarán a evaluarse hasta que no se procese alguna de las órdenes de ejecución de instrucciones explícitamente desde el menú

• Comentar dirección: una de las capacidades más útiles del Analizador es el comentario de direcciones. Mediante un sencillo cuadro de diálogo se pueden añadir notas que aparecerán al lado del desensamblado o marcar zonas de memoria como datos y, por lo tanto, evitar que sean desensambladas


67

cuadro de diálogo para añadir comentarios

Ejemplo de comentario de texto y comentario de datos.

El intervalo de datos se marca con el comentario en vez de desensamblarse

• Borrar el comentario: basta pulsar suprimir para eliminar el comentario, del tipo que fuere, del desensamblado

El menú “Memoria”

Las acciones disponibles son:

• Ir a: a través de un cuadro de diálogo permite ir a la posición de memoria especificada. El contenido de la ventana de volcado cambiará consecuentemente

• Cambiar la página: fuerza un cambio en la página seleccionada. Esto resultaba útil cuando se investigaba el funcionamiento de la paginación

• Configurar la vista de la memoria (gráfica): Combat School tenía dos circuitos gráficos superpuestos en la misma posición de memoria. Un registro situado en 500h elegía a cuál de los dos se dirigían las operaciones del procesador

opciones de configuración de la vista de memoria


68

El menú “Ver” Aparte de las habituales opciones de ocultar o mostrar las barras de estado y herramientas, se incluye la posibilidad de activar la vista de registros. En caso de hacerlo obtendríamos el siguiente cuadro de diálogo sin modo28 :

cuadro de registros

Cuando la ventana activa es una vista gráfica, el menú ver se amplía a las siguientes opciones:

• Grupos: a través de un cuadro de diálogo permite configurar de forma similar a lo hecho con la paginación, la relación existente entre el código de grupo a pintar y el grupo en la memoria ROM

• 1er fondo (volcado): muestra en la vista gráfica el volcado de la memoria ROM del fondo. Este es un gráfico estático (ya que la ROM no puede cambiar) y sirve para identificar códigos de bloques y grupos

• 2º fondo (volcado): ídem con el 2º fondo • 1er juego de objetos: ídem con el primer juego de objetos • 2º juego de objetos: ídem con el 2º juego de objetos • 2000-27FF: analiza esta porción de la RAM gráfica y la dibuja • 2800-2FFF: ídem con este otro intervalo • Objetos: ídem con la memoria de objetos

El menú “Ventana”

Obviando las omnipresentes entradas de “cascada”, “mosaico” y “organizar iconos”, hay dos acciones disponibles en esté menú: crear nueva vista mixta y crear nueva vista gráfica. Ambas abren nuevas ventanas para observar la misma máquina. Es decir, no emulan otro equipo adicional, sino que nos permiten ver desde más ángulos un mismo sistema. Esto permite, por ejemplo, tener en una ventana la memoria RAM mientras en otra se observa la memoria del circuito gráfico, ambas del mismo procesador. En el caso de la vista gráfica permite, por ejemplo, ver en una ventana el dibujo del 2º fondo mientras que en la otra se ven sólo los objetos.

28 Sin modo se refiere a que el cuadro de diálogo no interrumpe la operación de la aplicación principal. No existe un diálogo síncrono entre este tipo de diálogos y el programa. El término inglés “modeless”, algo obscuro, seguramente no está bien recogido en esta traducción (común en los libros) y otras soluciones como “cuadro de diálogo asíncrono” serían más intuitivas


69

La emulación del procesador El procesador es el núcleo vital de la máquina y donde sucede el juego en sí. La emulación de éste es la pieza inicial en la programación del emulador y la que determinará en gran medida el rendimiento del programa. Un procesador está compuesto, a nivel lógico, por un conjunto de operaciones que afectan a un juego de registros y a una memoria externa. Estos son, por tanto, los tres elementos a simular. Resulta sencillo imaginar un boceto del emulador como sigue: struct _registros unsigned char a,b; /* etc. */ registros; char mem[64*1024*1024]; /* 64 kOct de memoria */ void emula_ucp() do ejecuta_op( mem[registros.ip] ); registros.ip++; while(); La idea del código anterior es simular los registros con una estructura, la memoria con un vector y el conjunto de operaciones por una función (ejecuta_op). Se ha representado también el uso del registro de puntero de instrucción (IP), como se sabe este registro apunta a la siguiente instrucción a ejecutar; después de procesarla, el contenido del registro ha de incrementarse para pasar a la siguiente29. ¿Cómo podemos realizar la función ejecuta_op? Lo más obvio es utilizar la construcción case: #define SUMAR 0x12 /*Código máquina de la suma */ #define RESTAR 0x13 /* ídem de la resta */ switch( op ) case SUMAR: haz_suma(); break; case RESTAR:haz_resta(); break; Este enfoque con un compilador adecuado puede producir código muy rápido. Para ello es necesario que la dirección de memoria donde salta el código esté relacionada con el número de la operación. Es decir, queremos que la dirección donde salta el programa a partir de la instrucción switch se componga de:

29 Salvo cuando existan saltos.


70

DIRECCIÓN = BASE + FACTOR*OPERACIÓN De esa forma se puede codificar el salto de forma muy eficiente. Esto, sin embargo, es difícil de conseguir directamente sin fraccionar la memoria ya que cada operación emulada se resuelve con un código diferente y, por tanto, no siempre ocupa la misma memoria, sin ese requisito no es posible saber el “FACTOR” a usar en la fórmula anterior. Muchos compiladores utilizan una tabla intermedia para aprovechar la velocidad de la fórmula anterior. Así el abanico de sendas que se abre con la instrucción swift se codifica de forma eficiente a través de dos saltos:

Instrucción swift codificada con una tabla intermedia asociada a op En el caso de que el compilador no sea capaz de generar esta tabla de forma automática se puede realizar utilizando un vector de punteros a función de la siguiente forma: void haz_suma(); void haz_resta(); ... void (*funciones())[256]; funciones[0] = haz_suma; funciones[1] = haz_resta; (funciones[op])(); /* Llama a la función en la posición op*/ La realización anterior es muy eficiente ya que no es necesario comparar el valor de la operación, el salto es directo. Internamente, el compilador genera un código paralelo al mostrado en la figura anterior. Cada operación emulada responde al siguiente modelo: void operación_emulada() carga_operando ejecuta_operación actualiza_señalizadores


71

La carga del operando traerá a una variable el dato sobre el que se ejecuta la operación. Esta carga depende directamente del modo de direccionamiento (inmediato, directo, indexado, etc.) y se estudiará con detalle en el caso del 6809. La revisión de los señalizadores (o banderas) es distinta según cada operación, pues algunas afectan al acarreo y al desbordamiento, mientras que otras afectarán al de cero. Pese a que cada una afecte de una manera, son pocas las operaciones que no afectan a ningún señalizador. La ejecución de la operación misma es la única parte que difiere radicalmente en cada caso, desde no hacer nada (nop u operación nula) hasta una multiplicación, toda una baraja de casos distintos se despliega en este apartado. Debido a que el coste de ejecución de una operación es elevado en cuanto a coste fijo: entrar en la función que evalúa cuál se ejecuta y salir de ella; trataremos de reducir ese coste ejecutando lotes de operaciones en un bucle, se ahorran así apilaciones y desempilaciones de datos. El inconveniente es que las interrupciones no son emuladas de forma muy realista, ya que en lugar de parar la ejecución del programa en cualquier instante lo harán sólo en medio de uno de estos paquetes. En la práctica no se aprecia la diferencia, en especial porque la única interrupción que ocurre habitualmente en una máquina de vídeo proviene del sistema de vídeo y dada la estructura del juego, el código debe estar en un bucle de espera de la interrupción cuando ésta llega; no importa, por tanto, realmente que se interrumpa el hilo de ejecución en un punto u otro.


72

El Motorola 6809 El procesador M6809 es una UCP de 8 dígitos, CISC, con un juego de registros reducido:

Nombre Tamaño (octetos) Descripción A 1 acumulador B 1 acumulador X 2 índice Y 2 índice U 2 índice S 2 índice para la pila CC 1 banderas DP 1 índice directo PC 2 puntero de operación

Además de estos registros, existe otro más formado por la unión de A y B: El registro D, de dos octetos de longitud. Las operaciones se ejecutan siempre sobre los acumuladores, llevando luego los resultados a memoria con otra instrucción. El ancho del bus de direcciones es de 16 dígitos, por tanto, los punteros (X,Y,U,S y PC) abarcan toda la memoria direccionable (64 koct). Los índices se utilizan según el modo de direccionamiento:

• Inmediato: El operando viene en el siguiente octeto apuntado por PC • Directo: La dirección del operando se construye uniendo el siguiente octeto

apuntado por PC al contenido del registro DP • Indexado: Este modo sirve para indexar tablas y está basado en utilizar el

operando dado como índice respecto al contenido del registro de puntero X o de otro registro. Las posibilidades son:

o Post1: Lee de donde X indique y a continuación lo incrementa en uno. o Post2: Ídem pero incrementando en dos. o Pre1: Primero se incrementa en uno y luego se lee o Pre2: Ídem pero incrementando en dos. o Sólo registro: se lee de X sin modificarlo o Acumulador A: se lee de la posición X+A o Acumulador B: ídem de X+B o Desplazamiento de un octeto: se suma el siguiente octeto (apuntado

por el registro de instrucción, PC) a X, y se lee de la memoria indicada por el resultada

o Desplazamiento de dos octetos: ídem, salvo que el operando a sumar ocupa ahora dos octetos y permite, por tanto, indexar toda la memoria

o Acumulador D: Se lee de X+D, recuérdese que D es el registro de 16 dígitos compuesto por la concatenación de A y B

o Relativo a PC+8: La lectura no depende de X sino del puntero de instrucción PC, a éste se le añade un desplazamiento de 8 dígitos de longitud

o Relativo a PC+16: La lectura es desde el PC pero el desplazamiento ocupa ahora dos octetos


73

o Extendido indirecto: Se lee el valor de 16 dígitos apuntado por PC, a continuación se usa ese dato como puntero para leer de memoria otros 16 dígitos que indican la posición final del operando

• Extendido: La dirección del operando viene en los dos siguientes octetos apuntados por PC

Las instrucciones tienen habitualmente una versión para cada modo de direccionamiento, por ejemplo la operación LDA (LoaD A, cargar un dato en A) admite, entre otras, las siguientes versiones: 86 12 LDA 12h ;A=12h 96 12 LDA #12 ;A=(DP*256+12) B6 12 00 LDA $1200h;A=(1200h)


74

Juego de instrucciones

Modo de direccionamiento Banderas (CC)

Immediato Directo Indexado Extendid

o Inherente 5 3 2 1 0

Instrucción

Nemónico Op ~ # Op ~ # Op ~ # Op ~ # O

p ~ # Descripción H N Z V C

ABX 3A 3 1 X = B+X (sin

signo)

ADCA 89 2 2 99 4 2 A9 4+ 2+ B9 5 3 A = A+M+C +

+ ++

++

++

++ADC

ADCB C9 2 2 D9 4 2 E9 4+ 2+ F9 5 3 B = B+M+C + + + + +

ADDA 8B 2 2 9B 4 2 AB 4+ 2+ BB 5 3 A = A+M + + + + +

ADDB CB 2 2 DB 4 2 EB 4+ 2+ FB 5 3 B = B+M + + + + +ADD

ADDD C3 4 3 D3 6 2 E3 6+ 2+ F3 7 3 D = D+M:M+1 + + + +

ANDA 84 2 2 94 4 2 A4 4+

2+ B4 5 3 A = A && M + + 0

ANDB C4 2 2 D4 4 2 E4 4+

2+ F4 5 3 B = B && M + + 0 AND

ANDCC 1C 3 2 C = CC && INM ? ? ? ? ?

ASLA 48 2 1 8 + + + +ASLB 58 2 1 8 + + + +ASL

ASL 08 6 2 68 6+ 2+ 78 7 3

desplazamiento aritmético a la izquierda 8 + + + +

ASRA 47 2 1 8 + + +ASRB 57 2 1 8 + + +ASR

ASR 07 6 2 67 6+ 2+ 77 7 3

desplazamiento aritmético a la derecha 8 + + +

BITA 85 2 2 95 4 2 A5 4+ 2+ B5 5 3 probar dígito

en A (M&&A) + + 0 BIT

BITB C5 2 2 D5 4 2 E5 4+ 2+ F5 5 3 probar dígito

en B (M&&B) + + 0

CLRA 4F 2 1 A = 0 0 1 0 0CLRB 5F 2 1 B = 0 0 1 0 0CLR

CLR 0F 6 2 6F 6+

2+ 7F 7 3 M = 0 0 1 0 0

CMPA 81 2 2 91 4 2 A1 4+

2+ B1 5 3 compara M con A

8 + + + +

CMPB C1 2 2 D1 4 2 E1 4+

2+ F1 5 3 compara M con B

8 + + + +

CMPD 10 83

5 4 10 93

7 3 10 A3

7+

3+ 10 B3

8 4 compara M:M+1 con D + + + +

CMPS 11 8C

5 4 11 9C

7 3 11 AC

7+

3+ 11 BC

8 4 compara M:M+1 con S + + + +

CMP

CMPU 11 83

5 4 11 93

7 3 11 A3

7+

3+ 11 B3

8 4 compara M:M+1 con U + + + +


75

CMPX 8C 4 3 9C 6 2 AC 6+

2+ BC 7 3 compara M:M+1 con X + + + +

CMPY 10 8C

5 4 10 9C

7 3 10 AC

7+

3+ 10 BC

8 4 compara M:M+1 con Y + + + +

COMA 43 2 1 A = complemento(A)

+ + 0 1

COMB 53 2 1 B = complemento(B)

+ + 0 1COM

COM 03 6 2 63 6+ 2+ 73 7 3

M = complemento(M)

+ + 0 1

CWAI 3C => 20 2

CC = CC ^ INM; espera hasta la próxima interrupción

7

DAA 19 2 1 ajuste decimal A + + 0 +

DECA 4A 2 1 A = A 1 + + +

DECB 5A 2 1 B = B 1 + + + DEC

DEC 0A 6 2 6A 6+ 2+ 7A 7 3 M = M 1 + + +

EORA 88 2 2 98 4 2 A8 4+ 2+ B8 5 3 A = A XOR M + + 0

EOR EORB C8 2 2 D8 4 2 E8 4

+ 2+ F8 5 3 B = M XOR B + + 0

EXG R1,R2 1E 8 2 Intercambia R1,R2

INCA 4C 2 1 A = A + 1 + + + INCB 5C 2 1 B = B + 1 + + + INC

INC 0C 6 2 6C 6+ 2+ 7C 7 3 M = M + 1 + + +

JMP 0E 3 2 6E 3+ 2+ 7E 4 3 pc = EA

JSR 9D 7 2 AD 7+ 2+ BD 8 3 salto a

subrutina

LDA 86 2 2 96 4 2 A6 4+ 2+

B6 5 3 A = M + + 0

LDB C6 2 2 D6 4 2 E6 4+ 2+

F6 5 3 B = M + + 0

LDD CC 3 3 DC 5 2 EC 5+ 2+

FC 6 3 D = M:M+1 + + 0

LDS 10CE

4 4 10 DE

6 3 10EE

6+ 3+

10 FE

7 4 S = M:M+1 + + 0

LDU CE 3 3 DE 5 2 EE 5+ 2+

FE 6 3 U = M:M+1 + + 0

LDX 8E 3 3 9E 5 2 AE 5+ 2+

BE 6 3 X = M:M+1 + + 0

LD

LDY 10 8E

4 4 10 9E

6 3 10 AE

6+ 3+

10 BE

7 4 Y = M:M+1 + + 0


76

LEAS 32 4+ 2+ S = EA

LEAU 33 4+ 2+ U = EA

LEAX 30 4+ 2+ X = EA +

LEA

LEAY 31 4+ 2+ Y = EA +

LSLA 48 2 1 + + + +LSLB 58 2 1 + + + +LSL

LSL 08 6 2 68 6+ 2+ 78 7 3

Desplazamiento a la izquierda

+ + + +

LSRA 44 2 1 0 + +LSRB 54 2 1 0 + +LSR

LSR 04 6 2 64 6+ 2+ 74 7 3

Desplazamiento a la derecha

0 + +

MUL 3D 11 1 D = A*B (sin

signo) + 9

NEGA 40 2 1 A = !A + 1 8 + + + +NEGB 50 2 1 B = !B + 1 8 + + + +NEG

NEG 00 6 2 60 6+ 2+ 70 7 3 M = !M + 1 8 + + + +

NOP 12 2 1 No hace nada

ORA 8A 2 2 9A 4 2 AA

4+ 2+

BA 5 3 A = A || M + + 0

ORB CA 2 2 DA 4 2 EA 4+ 2+

FA 5 3 B = B || M + + 0 OR

ORCC 1A 3 2 C = CC || IMM ? ? ? ? ?

PSHS 34 5+ 2 Meter en S PSH PSHU 36 5+ 2 Meter en U PULS 35 5+ 2 Sacar de S PUL PULU 37 5+ 2 Sacar de U ROLA 49 2 1 + + + +ROLB 59 2 1 + + + +ROL

ROL 09 6 2 69 6+ 2+ 79 7 3

Rotar a la izquierda con acarreo + + + +

RORA 46 2 1 0 + +RORB 56 2 1 0 + +ROR

ROR 06 6 2 66 6+ 2+ 76 7 3

Rotar a la derecha con acarreo 0 + +

RTI 3B 6/15 1 Retorno de interrupción ? ? ? ? ?

RTS 39 5 1 Retorno de subrutina

SBCA 82 2 2 92 4 2 A2 4+ 2+

B2 5 3 A = A - M - C 8 + + + +

SBC SBCB C2 2 2 D2 4 2 E2 4+ 2

+F2 5 3 B = B - M - C 8 + + + +

SEX 1D 2 1 Extender el

signo de A en B + + 0

ST STA 97 4 2 A7 4+ 2+

B7 5 3 M = A + + 0


77

STB D7 4 2 E7 4+ 2+

F7 5 3 M = B + + 0

STD DD 5 2 ED 5+ 2+

FD 6 3 M:M+1 = D + + 0

STS 10 DF

6 3 10EF

6+ 3+

10 FF

7 4 M:M+1 = S + + 0

STU DF 5 2 EF 5+ 2+

FF 6 3 M:M+1 = U + + 0

STX 9F 5 2 AF 5+ 2+

BF 6 3 M:M+1 = X + + 0

STY 10 9F

6 3 10 AF

6+ 3+

10 BF

7 4 M:M+1 = Y + + 0

SUBA 80 2 2 90 4 2 A0 4+ 2+

B0 5 3 A = A - M 8 + + + +

SUBB C0 2 2 D0 4 2 E0 4+ 2+

F0 5 3 B = B - M 8 + + + +SUB

SUBD 83 4 3 93 6 2 A3 6+ 2+

B3 7 3 D = D - M:M+1 + + + +

SWI 3F 19 1 interrupción por programa 1

SWI2 10 3F

20 2 interrupción por programa 2 SWI

SWI3 11 3F

20 2 interrupción por programa 3

SYNC 13 >= 4 1

sincronizarse con la interrupción

TFR R1,R2 1F 6 2 R2 = R1

TSTA 4D 2 1 prueba A + + 0

TSTB 5D 2 1 prueba B + + 0 TST

TST 0D 6 2 6D 6+ 2+ 7D 7 3 prueba M + + 0

Leyenda

! Complemento de M + afectado OP código de la operación (hexadecimal)

= asignación - no se afecta ~ Number of MPU Cycles H semiacarreo (del dígito 3)

CC banderas (códigos de condición) # número de octetos

N bandera de signo : Concatenation + suma aritmética Z cero || o lógica - resta aritmética V desbordamiento, complemento a 2 && y lógica * multiplicación

C acarreo de la UAL EOR o éxclusiva EA dirección efectiva: w


78

El compilador de un emulador El emulador del procesador es una pieza clave en la velocidad del conjunto del programa y su fiabilidad imprescindible ya que quando caput dolet caetera membra dolent30, es decir, si el director de la orquesta presenta fallos la emulación no funcionará. Durante el desarrollo del emulador de Ghosts & Goblins descubrimos accidentalmente una situación curiosa relacionada con la importancia de un procesador bien emulado. Cuando hacía las primeras pruebas del juego funcionando con la UCP emulada todo parecía ir bien hasta que programamos las rutinas de entrada de monedas y pudimos comenzar la partida. En la escena de introducción aparece un vampiro enorme que secuestra a la doncella y da comienzo a la acción, en su ataque, el vampiro recorre una línea recta oblicua desde el cielo hasta el suelo, donde yace la dama. Curiosamente si la operación de rotación con acarreo de los dígitos está implementada como desplazamiento a secas31 el vampiro no es capaz de atrapar a la doncella y queda eternamente dando vueltas alrededor de la pantalla quedándose “colgado” el juego.

introducción de Ghosts & Goblins

Como vemos una instrucción mal emulada puede detener completamente el proceso, la relación entre el error visual (el vampiro dando vueltas) y el error real (desplazar por rotar) no es obvia y su depuración puede llevar varias horas o no encontrarse nunca. Teniendo en cuenta el número de instrucciones a codificar la probabilidad de cometer errores es enorme, máxime si se pretende escribir el emulador en ensamblador para maximizar su velocidad. Tras un par de tentativas fracasadas ante erratas imposibles de encontrar se llegó a la conclusión de que la mejor forma de escribir un emulador era no escribiéndolo, compilándolo. Todas las órdenes del procesador tienen una gran simetría entre sí: todas cargan datos de memoria, todas operan sobre ellos y todas alteran las banderas. La forma de cargar los datos y de afectar las banderas es también común: todas las órdenes que cargan de modo indexado lo hacen igual, todas las que modifican la bandera de cero lo hacen por 30 Cuando duele la cabeza, duelen el resto de los miembros 31 Rotación implica que no se pierde información, que el dígito que sale por un extremo entra por el otro; en el desplazamiento se pierden dígitos que se sustituyen por cero


79

la misma razón. Sólo la operación sobre los operandos varía de un caso a otro y aun así es común para cada variante de una instrucción con distinto modo de direccionamiento. ¿Acaso no habría una forma de sacar ventaja de esto? Se escribió un pequeño fichero que describía todas las instrucciones del 6809 de forma concisa, con un formato estricto y que minimizaba la posibilidad de error. Al ser sólo unas cuantas líneas la depuración era muy sencilla y la perfección por diseño estaba prácticamente garantizada. Con este fichero escrito, sólo hacía falta un compilador que lo transformase en código ensamblador Intel para luego ensamblarlo y enlazarlo al resto del emulador. Las órdenes se describen utilizando el siguiente formato: nombre,direccionamiento, OP, banderas, código, comentario

• nombre: es el nemónico de la instrucción, nombrará a las rutinas en ensamblador que ejecutarán esta orden

• direccionamiento: cada orden puede leer los operandos de distintas formas, una letra indica que modos están permitidos:

o i: inmediato o d: directo o x: indexado o e: extendido o b: salto corto (sólo en las operaciones de salto) o lb: salto largo (sólo en las operaciones de salto) o nada: la operación es inherente a la UCP, no necesita operandos

• OP: código de operación para el direccionamiento inmediato. Debido al modo de funcionamiento de la unidad de descodificación del 6809, los códigos OP aumentan en 10h según el direccionamiento así: 89h para inmediato, 99h para directo, A9 para indexado y B9 para extendido; por ejemplo

• banderas: banderas afectas por la orden. Cada letra indica que ha de evaluarse su condición y alterar su respectiva bandera según sea el resultado:

o H: acarreo entre cuartetos o N: resultado negativo o Z: resultado nulo o V: desbordamiento o C: acarreo entre octetos

• código: esta es la parte distinta en cada operación y común entre distintos modos de direccionamiento de una misma operación. Está escrita en código ensamblador Intel y utiliza la arroba (@) para hacer referencia al operando (cuyo registro o posición diferirá según el modo de direccionamiento)

• comentario: una breve línea para recordar qué se hizo y por qué A continuación se detalla el fichero crea.gen32 que contiene todas las instrucciones, tras él se analizarán algunas instrucciones de cada tipo y la codificación que genera el compilador –por nosotros programado- de ellas.

32 Se decidió nominar la extensión como “gen” en alusión a que este fichero era la “génesis” del emulador


80

abx,,3a,-,"mov %bl,%al\nmovb $0,%ah\naddw %ax,_x" adca, idxe, 89, HNZVC, "adcb @,%bh" Añade el valor a A con acarreo adcb, idxe, c9, HNZVC, "adcb @,%bl" Añade el valor a b con acarreo adda, idxe, 8B, HNZVC-, "addb @,%bh" Añade el valor a A addb, idxe, CB, HNZVC-, "addb @,%bl" Añade el valor a B addd,idxe0, c3, hnzvc-, "add %ax,%bx" Añade el valor a D anda, idxe, 84, nzv-, "andb @,%bh" V=0 siempre andb, idxe, c4, nzv-, "andb @,%bl" andcc,i,1c,-,"call _de_CCF_a_cc\nand %al,_cc\ncall _de_cc_a_CCF" asla,,48,hnzvc-,"salb $1,%bh" aslb,,58,hnzvc-,"salb $1,%bl" asl,dxe+,8,hnzvc-,"salb $1,(%ebp,%eax)" asra,,47,hnzvc-,"sarb $1,%bh" asrb,,57,hnzvc-,"sarb $1,%bl" asr,dxe+,7,hnzvc-,"sarb $1,(%ebp,%eax)" dígitoa, idxe, 85, nzv-, "testb @,%bh" V=0 siempre dígitob, idxe, c5, nzv-, "testb @,%bl" clra, , 4F, N0 Z1 V0 C0 -, "xor %bh,%bh" Borra A clrb, , 5F, N0 Z1 V0 C0 -, "xor %bl,%bl" Borra B clr, dxe+, f, n0 z1 v0 c0 -, "movb $0,(%ebp,%eax)" Borra el octeto cmpa,idxe ,81,hnzvc-,"cmpb @,%bh" cmpb,idxe ,c1,hnzvc-,"cmpb @,%bl" cmpd,idxe0,1083,nzvc-,"cmpw %ax,%bx" cmps,idxe0,118c,nzvc-,"cmpw %ax,_s" cmpu,idxe0,1183,nzvc-,"cmpw %ax,_u" cmpx,idxe0,8c,nzvc-,"cmpw %ax,_x" cmpy,idxe0,108c,nzvc-,"cmpw %ax,_y" coma,,43, nzvc-,"not %bh\naddb $0,%bh\nstc" V=0,C=1 siempre. comb,,53, nzvc-,"not %bl\naddb $0,%bl\nstc" com,dxe+,3,nzvc-,"notb (%ebp,%eax)\naddb $0,(%ebp,%eax)\nstc" daa,,19,nzvc,"mov %bh,%al\ndaa\nmov %al,%bh" deca,,4a,nzv-,"dec %bh" decb,,5a,nzv-,"dec %bl" dec,dxe+,a,nzv-,"decb (%ebp,%eax)" eora,idxe,88,nzv-,"xorb @,%bh" V=0 siempre eorb,idxe,c8,nzv-,"xorb @,%bl" inca,,4c,nzv-,"inc %bh" incb,,5c,nzv-,"inc %bl" inc,dxe+,c,nzv-,"incb (%ebp,%eax)" jmp, dxe+, 0E,-,"movw %ax,%si" Salto incondicional jsr, dxe+, 9d,-,"mov %si,%dx \nxchg %dh,%dl \ subw $2,_s \nxor %ecx,%ecx\nmovw _s,%ecx \nmovw %dx,(%ebp,%ecx) \nmov %ax,%si" lda, idxe, 86, nzv-, "movb @,%bh\naddb $0,%bh" Carga el valor en A ldb, idxe, c6, nzv-, "movb @,%bl\naddb $0,%bl" Carga el valor en B ldd,0idxe, cc, nzv-, "movw %ax,%bx\naddw $0,%bx" Carga el valor en D lds,0idxe,10CE, nzv-, "movw %ax,_s \naddw $0,%ax" Carga el valor en S ldu,0idxe, ce, nzv-, "movw %ax,_u \naddw $0,%ax" Carga el valor en U


81

ldx,0idxe, 8e, nzv-, "movw %ax,_x \naddw $0,%ax" Carga el valor en X ldy,0idxe,108e, nzv-, "movw %ax,_y \naddw $0,%ax" Carga el valor en Y leas, x+, 32, -, "movw %ax,_s" leau, x+, 33, -, "movw %ax,_u" leax, x+, 30, -,"movw %ax,_x\ncmpw $0,%ax\nje leax_z\nandl $0xffffffbf,CCF\nret\nleax_z:orl $0x40,CCF" leay, x+, 31, -,"movw %ax,_y\ncmpw $0,%ax\nje leay_z\nandl $0xffffffbf,CCF\nret\nleay_z:orl $0x40,CCF" lsra,,44,nzc-,"shrb $1,%bh" N=0 siempre lsrb,,54,nzc-,"shrb $1,%bl" lsr,dxe+,4,nzc-,"shrb $1,(%ebp,%eax)" mul,,3d,zc,"mov %bl,%al\nmulb %bh\nmov %ax,%bx\naddw $0,%bx\nbt $0x7,%ebx" nega,,40, hnzvc-,"neg %bh" negb,,50, hnzvc-,"neg %bl" neg,dxe+,0, hnzvc-,"negb (%ebp,%eax)" nop,,12,-,"" No hace nada ora,idxe,8a,nzv-,"orb @,%bh" V=0 siempre pues el or del x86 lo hace as¡ orb,idxe,ca,nzv-,"orb @,%bl" orcc, i,1a,-,"call _de_CCF_a_cc\nor %al,_cc\ncall _de_cc_a_CCF" rola,,49,vc!,"rclb $1,%bh\nmov %bh,%al" rolb,,59,vc!,"rclb $1,%bl\nmov %bl,%al" rol,dxe+,9,vc!,"rclb $1,(%ebp,%eax)\nmovb (%ebp,%eax),%al" rora,,46,c!,"rcrb $1,%bh\nmov %bh,%al" rorb,,56,c!,"rcrb $1,%bl\nmov %bl,%al" ror,dxe+,6,c!,"rcrb $1,(%ebp,%eax)\nmovb (%ebp,%eax),%al" rts,,39,-,"xor %eax,%eax\nmovw _s,%ax \nmovw (%ebp,%eax),%ax\nxchg %ah,%al \nmov %ax,%si \naddw $2,_s" sbca,idxe,82,hnzvc,"sbbb @,%bh" sbcb,idxe,c2,hnzvc,"sbbb @,%bl" sex,,1d,nz-,"mov %bl,%al\ncbw\nmov %ah,%bh\naddw $0,%ax" sta,dxe+,97,nzv-,"movb %bh,(%ebp,%eax)\ncall pagina\naddb $0,%bh" stb,dxe+,d7,nzv-,"movb %bl,(%ebp,%eax)\ncall pagina\naddb $0,%bl" std,dxe+,dd,nzv-,"movw %bx,%cx\nxchg %ch,%cl\nmovw %cx,(%ebp,%eax)\naddw $0,%bx" sts,dxe+,10df,nzv-,"movw _s,%cx\nxchg %ch,%cl\nmovw %cx,(%ebp,%eax)\naddw $0,_s" stu,dxe+,df,nzv-,"movw _u,%cx\nxchg %ch,%cl\nmovw %cx,(%ebp,%eax)\naddw $0,_u" stx,dxe+,9f,nzv-,"movw _x,%cx\nxchg %ch,%cl\nmovw %cx,(%ebp,%eax)\naddw $0,_x" sty,dxe+,109f,nzv-,"movw _y,%cx\nxchg %ch,%cl\nmovw %cx,(%ebp,%eax)\naddw $0,_y" suba,idxe,80,hnzvc-,"subb @,%bh" subb,idxe,c0,hnzvc-,"subb @,%bl" subd,idxe0,83,hnzvc-,"subw %ax,%bx" sync,,13,-,"" nihil facit. tsta, ,4d,nzv-,"addb $0,%bh" V = 0 siempre tstb, ,5d,nzv-,"addb $0,%bl" V = 0 siempre tst,dxe+,d,nzv-,"addb $0,(%ebp,%eax)" V = 0 siempre


82

Las instrucciones de salto tienen siempre una equivalencia exacta en los procesadores x86, de forma que la traducción es muy sencilla. Para su codificación se han añadido dos nuevos tipos de direccionamiento: el b (del inglés branch, rama, todas las instrucciones de salto del 6809 comienzan por está letra) y el lb (de long branch, rama larga; las instrucciones que implican un salto demasiado largo para caber en un octeto comienzan por lb). Los saltos cortos se basan en la idea de almacenar la diferencia entre la posición actual y la deseada en un octeto que se almacena siguiendo al OP; los saltos largos precisan de dos octetos pese a que el valor sigue siendo relativo a la posición actual. Se podría haber rizado el rizo en el compilador y haberle exigido que generase automáticamente los saltos largos a partir de los cortos ya que, como puede verse en el código adjunto, hay una regularidad en cuanto a los códigos OP: los saltos largos tienen el mismo código OP que su correspondiente corto aunque precedido por el prefijo 10h. En todos los saltos que impliquen leer una palabra de 16 dígitos es preciso invertir el orden de los octetos antes de realizar ninguna operación con ellos. bra,i,20,-,"cbw\nadd %ax,%si" Salta siempre brn,i,21,-,"" No salta bhi,b,22,,"ja"ZoC=0 bls,b,23,,"jna" jna=jbe C o Z = 1 bcc,b,24,,"jnc" Si C=0 bcs,b,25,,"jc" Si C=1 bne,b,26,,"jnz" Si Z=1 beq,b,27,,"jz" Si Z=0 bvc,b,28,,"jno" Si V=0 bvs,b,29,,"jo" Si V=1 bpl,b,2A,,"jns" Si N=0 bmi,b,2B,,"js" Si N=1 bge,b,2c,,"jge" Si N==V blt,b,2d,,"jl" Si N!=V bgt,b,2e,,"jnle" Z=0 y N==V ble,b,2f,,"jle" Z=1 ó N!=V lbra,i0,16,-,"add %ax,%si" Salta siempre lbrn,i0,1021,-,"" No salta lbhi,lb,1022,,"ja" lbls,lb,1023,,"jna" lbcc,lb,1024,,"jnc" lbcs,lb,1025,,"jc" lbne,lb,1026,,"jne" lbeq,lb,1027,,"je" lbvc,lb,1028,,"jno" lbvs,lb,1029,,"jo" lbpl,lb,102A,,"jns" lbmi,lb,102B,,"js" lbge,lb,102c,,"jge" lblt,lb,102d,,"jl" lbgt,lb,102e,,"jnle" lble,lb,102f,,"jle" bsr,i,8d,-,"mov %si,%dx \nxchg %dh,%dl \ subw $2,_s \nxor %ecx,%ecx\nmovw _s,%cx \nmovw %dx,(%ebp,%ecx) \ncbw\nadd %ax,%si" lbsr,i0,17,-,"mov %si,%dx \nxchg %dh,%dl \ subw $2,_s \nxor %ecx,%ecx\nmovw _s,%cx \nmovw %dx,(%ebp,%ecx) \nadd %ax,%si"


83

Análisis de algunas instrucciones y su compilación Para mejorar la comprensión de cómo funciona el compilador del emulador vamos a presentar ahora varios ejemplos de instrucciones según se describen en crea.gen y según quedan compiladas en código ensamblador por el compilador (crea.exe) adca, idxe, 89, HNZVC, "adcb @,%bh" Añade el valor a A con acarreo

La instrucción adca está codificada como adcb @,%bh en código Intel, representando que se añadirá al registro A (emulado con el registro bh del 8086) el valor del operando representado por @, éste se obtendrá según el modo de direccionamiento: inmediato, directo, indexado o extendido. Además las banderas de cuarteto, de signo, de cero, de desbordamiento y de acarreo resultarán afectadas. Para optimizar la velocidad, cada modo de direccionamiento se codifica con una función distinta; el código que genera el compilador es: .align 4 _adcaI: #adca Inmediato pushl CCF popfl inc %si #código singular adcb -1(%ebp,%esi),%bh #final pushfl popl CCF ret

.align 4 _adcaD: #adca Directo xor %eax,%eax #carga en EAX el octeto de desplazamiento movb (%ebp,%esi),%al inc %si #ajusta el PC movb _dp,%ah # Pone en AH DP pushl CCF popfl #código singular adcb (%ebp,%eax),%bh #final pushfl popl CCF ret

adca, inmediato adca, directo .align 4 _adcaX: #adca Indexado xor %eax,%eax movb (%ebp,%esi),%al lea _index,%ecx incw %si call (%ecx,%eax,4) pushl CCF popfl #código singular adcb (%ebp,%eax),%bh #final pushfl popl CCF ret

.align 4 _adcaE: #adca Extendido xor %eax,%eax movw (%ebp,%esi),%ax addw $2,%si #ajusta el PC xchgb %ah,%al #dirección en EAX pushl CCF popfl #código singular adcb (%ebp,%eax),%bh #final pushfl popl CCF ret

adca, indexado adca, extendido El modo de direccionamiento decide como empieza cada función, en el caso de direcc. inmediato hay que incrementar el puntero de instrucciones (IP, emulador por SI) para que apunte al operando que será cargado usando la combinación: -1(%ebp,%esi). Para los demás casos el desarrollo es más complicado pero obvio salvo en el direcc.


84

indexado que es tan complejo que requiere una llamada a una función para cargar el operando. Sobre este tema volveremos un poco más adelante. Tras resolver el modo de carga del operando se realiza la operación en sí. La arroba se ha sustituido por un expresión cuyo resultado es el operando, está marcada en azul en el cuadro superior. Queda por decidir como se verán afectados las banderas. Aquí se ha empleado un truco muy eficiente que no siempre es válido. Coincide que el 8086 modifica las banderas como el 6809 tras esta instrucción luego sería ideal utilizar el mecanismo interno del 8086 para realizar esa tarea. Esto se consigue cargando el registro de banderas del 6809 (CCF) en el del 8086, ejecutando la instrucción y copiando las banderas resultantes del 8086 en el 6809. Este esquema es muy eficiente y compacto pero exige que las banderas afectadas y los criterios para modificarlas sean las mismas en los dos procesadores. La directiva .align 4 que encabeza cada función indica al ensamblador que escoja un múltiplo de 32 para la posición en memoria de estas funciones, esto acelera el salto a ellas en procesadores de 32 dígitos. Como vemos la ventaja de usar el compilador es evidente, a partir de una sola línea ha generado un código pulcro, eficiente y sin errores. El desarrollo del compilador lleva un poco de tiempo, pero mucho menor que el que llevaría la codificación de todas estas instrucciones a mano. El ahorro es máximo si se considera que la depuración necesaria es mínima.

Ficheros que componen el emulador del 6809 Ya hemos descrito la estrategia seguida para emular el procesador, ahora vamos a explicar qué ficheros son necesarios para ensamblar el programa, cómo se generan y su contenido. Estos archivos son los utilizados en los emuladores Mapefer3 y Grytra. En total se programaron ocho compiladores y generadores de código: Nombre Descripción Ficheros resultantes

crea Es el compilador del fichero génesis descrito anteriormente

6809.s ops.s

rellena.s

EXG Genera el código de la operación de intercambio EXG Exg.s, exg.re

TFR Ídem con la instrucción de transferencia, TFR Tfr.s, tfr.re Index Genera el código del direccionamiento indexado Index.s, index.re

Pshs, Pshu Ídem de la instrucción de apilar con el registro S o con el U

Pshs.s, pshs.re pshu.s, pshu.re

Puls, Pulu Ídem de la instrucción de desempilar con el registro S o con el U

Puls.s, puls.re Pulu.s, pulu.re


85

El único compilador es crea puesto que interpreta el contenido de un fichero (crea.gen) y genera a partir de él otros. Los restantes programas son específicos para un problema y no leen ningún dato externo. Los generadores (Exg, Tfr, Index, etc.) escriben código para una sola función. No vamos a detallar cada caso, puesto que son mimos unos de otros, explicaremos sólo dos ejemplos: El programa Exg y el programa Index

Programación de la función Exg (intercambio de registros) La función exg del 6809 intercambia el contenido de dos registros. Se compone de dos octetos: el código de operación 1Eh y un octeto que indica que dos registros se intercambian. Pese a que la instrucción es conceptualmente muy sencilla su emulación de forma eficiente es complicada. El problema reside en que para saber qué hacer hay que descifrar el operando y eso implica varios saltos condicionados; como ya se sabe, los saltos son lentos puesto que pueden forzar la limpieza de la memoria caché del procesador y, por tanto, interrumpir el flujo natural de instrucciones. Este argumento genérico no siempre está justificado puesto que si la caché es suficientemente grande el salto no es tan grave. Aun omitiendo el problema de la caché existe otra razón: en los procesadores con unidades de descodificación paralelas la cola de instrucciones ha de borrarse en caso de saltos. Una vez más el argumento es discutible, puesto que los procesadores que disponen de anticipación de instrucciones son capaces de prevenir esta situación y actuar en consecuencia. La única forma de llegar a un acuerdo es delimitar el problema a un procesador concreto: el 80386. El emulador mapefer3 se desarrolló teniendo como objetivo que fuera jugable en un 386DX a 40MHz, para ese procesador en concreto merece la pena programar la función EXG no en base a varios saltos condicionados sino como un piélago de rutinas distintas para cada caso posible. El código de la función EXG queda descompuesto, por tanto, en rutinas como la que se muestra a continuación:

.align 4 _exgA8: xchgb %bh,_cc ret #finito .align 4 _exgA9: xchgb %bl,_cc ret #finito .align 4 _exgAB: movb _dp,%al movb _cc,%ah movb %al,_cc movb %ah,_dp ret #finito

donde el nombre se compone del prefijo _exg seguido del código del operando en hexadecimal. Cuando el procesador encuentra una operación EXG salta en primer lugar al siguiente código en ensamblador (extraído de 6809.s):


86

.align 4 _exg: xor %eax,%eax movb (%ebp,%esi),%al lea _exgTabla,%ecx incw %si jmp (%ecx,%eax,4) #salta a la instrucción apropiada Desde aquí se realiza un nuevo salto en base al operando que se utiliza como índice de la tabla de punteros _exgTabla. Nótese que no se realiza una llamada a subrutina sino un salto incondicional jmp, de esta forma la orden de retorno sita al final de cada rutina _exgXX volverá no a esta rutina si no a la que llamó a ésta. El resultado: el procesador evita la ejecución de una instrucción ret adicional y un posible borrado de caché. Esta idea y otras similares se han usado hasta el agotamiento en todo el emulador. Los restantes programas: TFR, y los cuatro relacionados con la pila PSHU/S, PULU/S; generan ficheros similares a éste y se basan en la misma optimización de cambiar espacio en memoria por velocidad de ejecución.

El direccionamiento indexado Como ya se vió cuando se explicaron los modos de direccionamiento, bajo la denominación de direccionamiento indexado se esconden muchísimos casos distintos y la lógica aplicable a EXG tiene validez aquí también: en lugar de analizar el operando cada vez, es más rápido tener rutinas separadas para ocasión. El fichero ensamblador generado por este programa contiene más de 1500 líneas de código y desmenuza absolutamente este modo de direccionamiento. Vamos a mostrar someramente el programa en C encargado de generar ese código ensamblador. La función main es sencillamente un bucle que evalúa los 256 posibles casos y según cada uno invoca a una función encargada de escribir esa operación concreta.

void main() …/… for( con=0; con<=255; con++ ) modo = con; /* lo convertimos a 8-dígitos */ if ( (modo&0x80)==0 ) desp5(); else switch( modo & 0xf )

case 0: post1(); break; case 1: post2(); break; case 2: pre1(); break; case 3: pre2(); break; case 4: solo_reg(); break; case 5: accB(); break; case 6: accA(); break; case 8: desp8(); break; case 9: desp16(); break; case 11:accD(); break; case 12:pc8(); break; case 13:pc16(); break; case 15:extI(); break;


87

Cada una de las funciones está muy basada en el uso de macros, tanto en C como en ensamblador: void desp8() ALIGN; registro(); if ( modo & 0x10 ) fprintf(s,"_desp8%s_I:\n",reg ); else fprintf(s,"_desp8%s:\n",reg ); carga_registro2(); carga_i8(); fputs("\taddw %cx,%ax\n",s); if ( modo & 0x10 ) indirecto(); fprintf(r,"RELLENA _desp8%s_I,0x%X\n",reg,modo ); else fprintf(r,"RELLENA _desp8%s,0x%X\n",reg,modo ); FIN; Por ejemplo, la macro ALIGN está definida como

#define ALIGN fputs("\t.align 4\n",s) y es la responsible de que todas las funciones comiencen en direcciones de memoria múltiplos de 32. El código generado invoca a la macro RELLENA, definida como:

.macro RELLENA nombre,codigo lea \nombre,%eax movl %eax,\codigo*4(%ebx) .endm

Esta macro se utiliza en ensamblador para rellenar las tablas con las direcciones de las funciones. Todos los generadores crean ficheros con extenión re cuyo contenido son invocaciones a esta macro, por ejemplo la anterior función en C genera entradas como: RELLENA _desp8_y_I,0xB8 Que van rellenando la tabla de punteros elemento a elemento. En la rutina Inicia6809, escrita en ensamblador, se ejecuta cada uno de estos ficheros rellenantes cargando previamente la dirección de la tabla a completar en el registro ebx.

lea _exgTabla,%ebx .include "exg.re"


88

Registros y variables del emulador En el fichero principal, 6809.s, hay un conjunto de variables definidas directamente en ensamblador y que son una componente esencial del simulador. Dado que su número es escaso y su importancia grande las comentaremos en esta sección. .data .align 4 _ram:.globl _ram .long 0 .align 4 contador: .long 0 .align 4 msj_ilegal: .string "Op ilegal = %X\n" #registro de concidiciones .align 4 CCF: .long 0 #registros .align 4 _pc: .word 0 .align 4 _x : .word 0 .align 4 _y : .word 0 .align 4 _u : .word 0 .align 4 _s : .word 0 .align 4 _dp: .byte 0 .align 4 _cc: .byte 0 .align 4 _b : .byte 0 .align 4 _a : .byte 0 .global _pc .global _x .global _y .global _u .global _s .global _dp .global _cc .global _b .global _a

Especifica que comienza un segmento de datos. ram es un puntero a los 64koct de memoria virtual. contador se utiliza para llevar la cuenta de las instrucciones. msj_ilegal sirve para indicar la alarma cuando no se reconoce un código OP. A continuación van los registros del 6809, pese a que algunos ocupan sólo un octeto, todos ellos están colocados en posiciones de memoria múltiplos de 32 (.align 4) para que sea más rápido el acceso a los mismos. Las directivas .global permiten que el enlazador comparta estos símbolos con el resto de módulos a enlazar.

Variables usadas por el emulador del 6809


89

La función Ejecuta Esta es la función que une al emulador del procesador con el resto del programa. Éste dirá ejecuta(10) y diez instrucciones serán simuladas. Algunos registros del 6809 se colocan en el interior del x86 para acelerar la emulación, a esto lo llamaremos registro emulado internamente, estos son:

Registro 6809 Registro x86 A Bh B Bl PC + puntero a la RAM ESI Operando AX Puntero a la RAM EBP

Además el registro de banderas también se emula internamente, siguiendo el procedimiento detallado en la siguiente sección. .align 4 _ejecuta:.globl _ejecuta pushl %esi pushl %edi pushl %ebp movl 16(%esp),%eax movl %eax,contador movb _a,%bh movb _b,%bl movl _ram,%ebp xor %esi,%esi movw _pc,%si otra_instruccion: xor %eax,%eax movb (%ebp,%esi),%al lea _ops,%ecx inc %si call (%ecx,%eax,4) decl contador jnz otra_instruccion movb %bh,_a movb %bl,_b movw %si,_pc popl %ebp popl %edi popl %esi ret

Apila los registros que se modificarán Número de instrucciones a emular Registros del 6809 simulados internamente Carga el código de la instrucción. El registro ecx contiene la tabla de códigos de operación Invoca a la rutina encargada de su gestión Salva los registros emulados internamente Restaura los registros originales y devuelve el control

Código fuente de la función ejecuta En esta rutina se puede apreciar la sencillez obtenida gracias al esquema de tablas de punteros. La descodificación de la instrucción no es más que leer el valor de una tabla e invocar a la rutina que ese valor indica.


90

Emulación interna del registro de banderas Todos los procesadores tienen un registro destinado a anotar el resultado de las últimas operaciones. En el 6809 las situaciones que se registran son:

• Semiacarreo (H): Indica que se ha producido acarreo desde el cuarteto inferior de A al cuarteto superior.

• Acarreo (C): Al realizar una operación aritmética de ocho dígitos, el resultado excedió la capacidad del registro destino por un dígito, ese dígito se deja almacenado en el registro C.

• Desbordamiento (V): Las multiplicaciones o divisiones pueden exceder totalmente la capacidad de los registros. En ese caso se activa el dígito de desbordamiento.

• Cero (Z): Si el resultado de la operación ha sido nulo, se activa el dígito de cero. • Negativo (N): ídem si el resultado fue negativo.

Cada instrucción del 6809 afecta a todos, algunos o ninguno de estos indicadores. Por ejemplo la instrucción daa (ajuste decimal, utilizada con números codificados en BCD) no altera ninguna de las banderas pero la instrucción asl (desplazamiento a la izquierda) las modifica todas. Evaluar cada condición posible al final de cada instrucción es simultáneamente un engorro de programar, una fuente de errores y una considerable pérdida de tiempo de proceso. Si la capacidad para realizar esta comprobación está ya imbuida en el procesador x86 ¿por qué no utilizarla? Nada más ejecutar una instrucción el x86 modifica sus propias banderas en función del resultado así que parecería que no hay más que copiar su valor a la variable que simula el registro del 6809; sin embargo hay que tomar algunas precauciones:

1. Muchas instrucciones no sólo modifican las banderas sino que requieren de su valor para operar correctamente.

2. No todas las órdenes del 6809 afectan los mismos dígitos que sus homónimas del x86, en algunos casos no hay ninguna correspondencia. Estas excepciones son muy peligrosas.

3. El tamaño del registro del 6809 es de un octeto, el del x86 de cuatro. Esto se soluciona realizando una conversión cuando alguna orden lo requiere.

La 2ª cuestión no es en sí muy grave, entraña el riesgo de poder causar errores debidos a despistes, pero teniendo claros los diferentes casos basta hacer un código específico para las pocas ocasiones en que esto ocurre. Una de estas instrucciones es la de carga del acumulador (lda), en el 6809 modifica las banderas N,Z y V; sin embargo en el x86 no afecta absolutamente a ninguna. Esto puede solucionarse fácilmente añadiendo una suma tras la carga: ¿qué valor sumar? Ninguno:

movb -1(%ebp,%esi),%bh addb $0,%bh

De esta forma se fuerza una modificación del registro de banderas del x86. Lamentablemente addb también cambia el dígito de acarreo y para evitar su modificación en el 6809 es necesario filtrar el resultado con operaciones lógicas and y or.


91

El mecanismo que se sigue para emular internamente el registro de banderas consisten en cargar –si la instrucción así lo requiriese- el registro de banderas virtual del 6809 en el real del x86, ejecutar la operación y copiar el registro real del x86 al virtual del 6809. Dado que los procesadores Intel no disponen de instrucciones para manipular el registro de banderas directamente, su copia hay que hacerla a través de la pila. A continuación se muestra cómo se realiza este proceso en la órden ADCA (suma con acarreo) pushl CCF popfl #código singular adcb (%ebp,%eax),%bh #final pushfl popl CCF

Se copia el CCF (6809) al registro del x86 Se ejecuta la suma con acarreo Se copia el registro del x86 a la variable CCF (6809)

Algunas instrucciones del 6809 operan directamente con el registro de banderas, concretamente las órdenes de apilado y desempilado. Éstas necesitan el registro con el tamaño verdadero: un octeto, y no la versión de 32 dígitos (la variable CCF) que hemos manejado hasta ahora. Para convertir del registro real (llamado CC) al largo (CCF) se utiliza una pareja de funciones llamadas de_cc_a_CCF y de_CCF_a_CC.

Disparo de la interrupción IRQ La interrupción irq hace falta para todos los juegos, puesto que el retrazado vertical del monitor de la máquina la provocaba. Al ser un código sencillo y directo está programada en C, cabe destacar que en esta ocasión es necesaria la conversión de la variable CCF (de 32 dígitos) al formato corto (variable CC, un octeto) para apilarla. void irq() if ( (cc & CC_I )== 0) METES16( pc ); METES16( u ); METES16( y ); METES16( x ); METES8( dp ); METES8( b ); METES8( a ); cc |= CC_E; de_CCF_a_cc(); METES8( cc ); cc |= CC_I; pc = LEE16( 0xfff8 );

Apila todos los registros del 6809 Convierte el registro de banderas CCF al formato corto y lo apila El puntero de programa se carga con el vector de interrupción


92

El emulador del 6809 de Larry Bank Para el Escuela de combate se utilizó un emulador diferente programado por Larry Bank. Éste tenía la ventaja de ser compatible con Win32 y de tener un enfoque más genérico. Su principal inconveniente es la lentitud, pese a estar escrito en ensamblador, es más rápido que la mayoría de emuladores del 6809 disponibles, pero más lento que el enfoque discutido anteriormente. Para utilizar este emulador hay que enlazar el código objeto A6809.obj y definir la función TRACE6809 en el programa principal de C. Esta función sólo se utilizará si quisiéramos depurar el programa; si no, basta definirla vacía:

TRACE6809()

return 0;

El emulador se arranca invocando a la función ARESET6809 que precisa de un puntero al mapa de memoria del 6809 y otro a la estructura de registros:

ARESET6809(pMem6809, &regs6809 ); El mapa de memoria es una región de 3x64 kilo octetos, cada parte de 64koct contiene un tipo de información: la primera tiene la ROM de la máquina, la segunda la RAM y la última un mapa sobre cómo interpretar cada octeto: un cero indica RAM; un uno, ROM; y cualquier número mayor que dos implica que para acceder a esa posición hay que hacer una llamada a una función definida por el usuario. Una determinada estructura contiene los punteros a estas funciones en un orden tal que según sea el valor escrito en el mapa de memoria se llamará a una u otra. En Escuela de combate esta estructura se inicia de la siguiente forma:

static EMUHANDLERS emuh[3] = LeePagina,EscribePagina, LeeVideo,EscribeVideo, Lee500,Escribe500 ;

Luego el mapa de memoria se modifica como en este ejemplo:

pMem6809[ MEM_FLAGS + 0x500 ] = 4; // registro de selecciones Esto significa que si se accediese a la posición 500h, el emulador ejecutará las funciones que ocupen la tercera posición (4-1=3) de la estructura; en este caso, las funciones: Lee500 y Escribe500. Durante el desarrollo de Escuela de combate, el emulador de Larry Blank demostró ser un programa rápido, estable y fiable; no se encontró ningún error de programación ni comportamiento anómalo durante todo el proceso.


93

La sincronía Los máquinas de videojuegos no disponían normalmente de reloj interno. El mecanismo empleado para medir el tiempo consistía en contar el número de sincronismos verticales de la imagen. Como cada uno producía una interrupción, sabiendo la frecuencia de los mismos y el número de interrupciones que había pasado se sabía el paso del tiempo con suficiente exactitud. El caso más habitual era el de monitores a 60 Hz, lo que implica sesenta interrupciones por segundo. Cuando se emula el juego no se puede tener un control preciso sobre el tiempo pero tampoco es necesario. Pese a que se sepa exactamente cuánto tardaría una determinada instrucción en ejecutarse en el procesador, no tiene utilidad el emularla justo en ese tiempo. Lo único que percibe el usuario son las imágenes del juego y la música del mismo, sólo en estos dos apartados la sincronía es importante. Nuestra preocupación es, por lo tanto, dibujar imágenes cada sesentavo de segundo. Sin embargo esto implica una primera preocupación: ¿cuántas instrucciones hay que ejecutar entre pantalla y pantalla? Si llevásemos a cabo una cuenta exhaustiva de los ciclos de reloj acaecidos en el procesador podríamos replantear la pregunta a ¿cuántos ciclos de reloj han de pasar entre pantalla y pantalla? La respuesta entonces sería inmediata: el producto de la frecuencia de reloj por el intervalo entre imágenes, así para un procesador a 1 MHz operando con una pantalla a 60 Hz deberíamos de ejecutar 16,666 ciclos. Este enfoque, aunque riguroso, es poco práctico pues implica añadir código adicional a la emulación del procesador que enlentecería la operación. Una solución aproximada es tomar la media de ciclos por instrucción como medida para ejecutar no un número de ciclos sino de instrucciones: por ejemplo, el 6809 tiene una ejecución media de una instrucción por cada dos ciclos, luego el intervalo propuesto es aproximadamente equivalente a 33,333 ciclos. Lamentablemente la solución anterior no funciona a la perfección produciendo situaciones en las que el emulador dispara una interrupción antes de cuenta, provocando un funcionamiento anómalo que causa retardos en la animación. La forma de solventar este problema es operar con exceso: Cuando el bucle del videojuego llega a la fase de espera no importa cuántas instrucciones se ejecuten, puesto que la acción ya no avanzará hasta que se dispare una interrupción. La solución final es por tanto, emular entre imágenes un número de instrucciones superior (en torno a un 10%) al número de instrucciones ejecutables durante ese tiempo, basado en el promedio de ciclos por operación. Desde un punto de vista básico: una vez ejecutadas las IPI33 correspondientes, el emulador dibuja la pantalla y lee la entrada del teclado; acto seguido el bucle vuelve a empezar. De ser así, sin embargo, en un ordenador moderno el juego se desplazaría a tal velocidad que sería injugable; y en un equipo lento la acción se vería retardada. Es necesario incluir un mecanismo de ajuste de la velocidad para no pecar ni por exceso ni por defecto. En las próximas secciones se estudian los dos mecanismos básicos de sincronía.

33 IPI: Instrucciones Por Imagen


94

Sincronización mediante promediado de imágenes Este mecanismo de sincronización se basa en contar cuántas imágenes se han dibujado ya y cuántas deberían haberse dibujado. Para realizarlo se programa una función temporizada que se ejecute cada sesentavo de segundo y que se encargue de incrementar un contador al que llamaremos IPS34 ideal. Durante la ejecución del bucle de emulación, se incrementará una variable a la que llamaremos IPS real, de esta forma podremos comparar si el programa va más rápido o más lento de lo necesario. En caso de que el emulador no sea capaz de mantener una tasa de IPS reales semejante a las ideales será síntoma de que el equipo en el que se está ejecutando el programa no es suficientemente rápido para esta labor. Existe, sin embargo, una sencilla forma de acelerar la emulación en detrimento de la suavidad de las animaciones: consiste en cancelar el dibujado de algunas de las sesenta imágenes a procesar por segundo. La cifra de 60 Hz no surge de la necesidad de tener animaciones fluidas, sino para evitar que el ojo perciba parpadeo. La máquina original debía dibujar a un ritmo de 60 Hz para mantener el refresco de la pantalla, pero en el ordenador la circuitería gráfica ya se encarga de que no haya parpadeo aunque la imagen presente sea siempre la misma. Podemos, por tanto, reducir las IPS mostradas hasta dígitos tan bajas como 30 IPS sin que la calidad del juego se vea notablemente afectada. El no dibujar la imagen no implica no calcularla, la emulación de las IPI instrucciones hay que realizarla siempre o el juego se enlentecerá; el ahorro temporal proviene de evitar transformar la memoria de vídeo de la máquina emulada en imágenes visibles por el ordenador, el ritmo de emulación del procesador hay que mantenerlo siempre. Existen circunstancias en las que este recorte de imágenes será obvio para el jugador: tradicionalmente el estado de invulnerabilidad35 del jugador se ha marcado mediante un parpadeo del mismo y la forma más sencilla de conseguir éste efecto es no dibujar al jugador en las imágenes pares (o nones) y hacerlo en las nones (o pares). Supongamos que el mecanismo de promediado de imágenes saltándose una de cada dos imágenes para poder alcanzar la meta de emular el procesador al 100% de velocidad; ocurrirá entonces que el personaje se dejará de ver completamente durante el tiempo de invulnerabilidad o se verá siempre (sin notarse el parpadeo), según haya coincidido el pintado del personaje por parte del videojuego con el dibujado de la pantalla por parte del programa. Las tasas de dibujado que no sean potencias de dos (como por ejemplo, dibujar dos de cada tres imágenes) evitan este problema. Puede ocurrir el caso contrario: el ordenador es tan rápido que las IPS reales exceden a las ideales. En tal circunstancia el promediado de imágenes producirá un videojuego acelerado ya que nada impide que se emule y procese un segundo de tiempo virtual en menos de un segundo real; el aumento de velocidad puede hacer el juego injugable. La forma más sencilla y efectiva de evitar este problema es utilizar el sincronismo vertical del ordenador. Al igual que la máquina recreativa, el ordenador consta de un monitor

34 Imágenes Por Segundo 35 La invulnerabilidad hace referencia a un estado en el que el héroe del videojuego no puede morir, generalmente este es el estado inicial tras perder una vida, recibir un golpe o empezar un nivel. La invulnerabilidad dura habitualmente unos tres segundos, pasados los cuales el jugador vuelve a ser mortal.


95

que ha de refrescarse periódicamente; desde el programa podemos saber cuándo se produce dicho refresco. El procedimiento de sincronía consiste en, una vez emuladas las IPI instrucciones y dibujada la pantalla, esperar a la llegada del refresco antes de iniciar un nuevo ciclo del bucle de emulación. En un procesador suficientemente rápido como para acabar a tiempo siempre, este mecanismo produce la emulación más fluida posible; sin embargo si el ordenador se retrasa a veces36 puede ocurrir que llegue al punto de espera nada más ocurrir el refresco y tenga que esperar 17ms hasta el siguiente. Cuando eso pasa, el retardo es evidente y produce una animación brusca. El siguiente extracto de código, procedente de mapefer337 muestra cómo se realiza el sincronismo por promediado de imágenes. En primer lugar se crea una función temporizada: void temporizador()

ips_ideal++; Esta función se ejecutará sesenta veces por segundo automáticamente, el sistema operativo se encargará de ello. Durante el bucle de la emulación se ejecuta –simplificadamente- lo siguiente: for(;;) ejecuta( ipi ); irq(); if ( ips_real > ips_ideal ) dibuja_pantalla( ant_munecos ); if ( ips_ideal >= 59 ) ips_ideal=0; ips_real = 0; ips_real++; La pantalla se dibuja únicamente si el emulador va más rápido de lo necesario, sin embargo la instrucciones se simulan siempre. Dentro de la función dibuja_pantalla se encuentra la espera de la señal de refresco. Cuando el contador de IPS ideales sobrepasa el valor 60 se reinicia a cero, ésta operación es necesaria porque da la oportunidad a ips_real de pillar a ips_ideal por lo menos una vez por segundo y elimina el retardo acumulado; sin esta puesta a cero, en un ordenador lento se podría llegar a tal desfase entre las dos variables que nunca se dibujase ninguna imagen. Al final del bucle el contador de IPS reales se incrementa.

36 No todos los ciclos son iguales. Las rutinas de optimización del vídeo son las máximas responsables de que unos ciclos sean más lentos o rápidos que otros. 37 El emulador de G&G


96

Sincronización cronometrada Cuando el equipo emulante es suficientemente rápido se hace necesario buscar una forma eficaz de sincronizar el proceso de emulación y pintado de imágenes. Por una parte, al sobrar tiempo entre uno y otro fotograma, sería recomendable desocupar el procesador para que el sistema operativo dé ese lapso a otros procesos. Por otra parte, los monitores actuales suelen operar con refrescos muy superiores a 70Hz lo que ocasiona que la técnica de sincronía con el retrazado del monitor no funcione; necesitamos un mecanismo válido para frecuencias de la pantalla emulada distintas de la emulante. El método de sincronización cronometrada se basa en cronometrar lo que se tarde en emular el procesador y dibujar la pantalla para esperar después hasta que se cumple un período38. Llegado ese momento el ciclo vuelve a empezar.

ciclo de emulación cronometrado

En el gráfico superior se ejemplifica esta situación. Se supone que la emulación del procesador tarda 3ms; es decir, que en 3ms reales pasan ~20ms (50Hz) virtuales; a continuación en 2,5ms se interpreta la memoria de vídeo y se pinta en la pantalla real la imagen. Han transcurrido realmente 5,5ms pero en el sistema emulado ya han pasado 20ms, es necesario esperar sin hacer nada hasta que lleguen realmente esos 20ms. Siguiendo el mismo ejemplo, si se le devuelve el control al sistema operativo durante los 14,5 ms restantes eso significaría que el emulador está ocupando el ordenador un

%5,2710020

5,5 = y el restante 72,5% queda libre para otras tareas.

En el caso de que se emulase una máquina a 50 o 70 Hz bastaría con cambiar el tiempo límite de espera de 16,6ms a 20ms o 14,3ms. Conceptualmente este método es muy sencillo pero a la hora de realizarlo puede ser laborioso según la plataforma de desarrollo ya que el sistema operativo provee habitualmente de medidas del tiempo en unidades de un milisegundo. Para el caso de Windows hay un juego de funciones pensadas para aplicaciones multimedia entre las que se incluyen algunas para sincronización precisa.

38 inversa de la frecuencia de refresco. Para 60Hz el período de emulación es de 16.6 ms


97

La emulación del sonido Pese a que la emulación de los circuitos sonoros no se realizó como parte del proyecto, vamos a disertar en esta sección sobre cómo acometerla. La problemática de la emulación sonora reside en la sincronización: del procesador del juego con el del sonido, de éste con el circuito sonoro y del circuito sonoro emulado con el del ordenador. La idea de fondo es sintetizar una onda en la memoria del ordenador con la salida que generaría el circuito emulado y mandarla al convertidor de digital a analógico del ordenador. Este esquema presenta una serie de retos, todos ellos relacionados con el tiempo: En la realidad, el procesador principal puede mandar en cualquier instante una orden al procesador de sonido para solicitar que una determinada melodía o efecto se reproduzca; éste a su vez transformará esa petición en una cadena de órdenes (notas musicales codificadas) que enviará al circuito sonoro que a su vez generará una señal binaria con la música en formato digital, ésta será convertida a una señal analógica audible por el convertidor. Cada una de estas operaciones se desarrollan en pasos discretos de longitud mínima igual al período del procesador más lento, podemos suponer que ese tiempo es de 1µs (el más lento funcionaría a 1MHz). Para realizar la emulación es necesario simular primero el procesador principal, acto seguido el sonoro, posteriormente el circuito de sonido y para acabar, enviar la señal al convertidor de digital a analógico del ordenador. Todos estos pasos no pueden realizarse en incrementos de 1µs, puesto que supondría una sobrecarga (debida a llamadas y retornos de funciones y a operaciones lentas, como la conversión) que entorpecería toda la emulación. Además, incluso si pudiera efectuarse todo lo anterior a la celeridad adecuada; el sonido no es algo que se lance sin más, cada fragmento de 1µs hay que hilarlo convenientemente con el siguiente, si no el resultado es cacofónico. En la práctica basta escoger un período de tiempo suficientemente largo como para facilitar la unión de un intervalo con el siguiente, sin que esto requiera una sincronización demasiado sensible. Lo habitual es trabajar con períodos del orden de decenas de milisegundos. Un criterio para escoger el período exacto puede ser tomar un múltiplo del período de refresco del monitor, para poder así entremezclar adecuadamente las emulaciones de todas las partes del sistema. Con un monitor a 60Hz, esta cifra estaría en torno a los 16ms. Si la comunicación de los dispositivos es unidireccional: es decir, el procesador principal puede hablarle al sonoro, y éste no puede responder; no es necesario intercalar ciclos de emulación cortos de un procesador y otro, sino que basta con almacenar las órdenes que el procesador principal mandó en una pila e ir introduciéndoselas adecuadamente al procesador de sonido emulado. El mismo principio puede aplicarse con aquellos circuitos sonoros que no envíen señales al procesador director.


98

Descripciones técnicas detalladas de las máquinas emuladas

Ghosts & Goblins

Procesador Cometido Frecuencia (MHz) Memoria ROM (koct)

6809 Juego 1.5 Z80 Sonido 3 32 YM2203 (dos) Sonido

Volcados de las memorias ROM:

Nombre Tamaño (koct)

Descripción

GG1 16 Caracteres GG2 32 Memoria de sonido (Z80) GG3 32 Memoria sin paginar del juego (6809) GG4 16 Los primeros ocho kilo octetos son

memoria paginada del 6809, los siguientes ocho kilo octetos no se paginan.

GG5 32 Memoria paginada del 6809 GG6 16 Juegos 3 y 4 del fondo GG7 16 Juegos 1 y 2 del fondo GG8 16 Juegos 3 y 4 del fondo GG9 16 Juegos 1 y 2 del fondo GG10 16 Juegos 3 y 4 del fondo GG11 16 Juegos 1 y 2 del fondo GG12 16 Animaciones GG13 16 Animaciones GG14 16 Animaciones GG15 16 Animaciones GG16 16 Animaciones GG17 16 Animaciones


99

Paginación y mapa de memoria Existen cinco páginas de 8 koct que se eligen a través de un registro direccionado en la posición 3E00h. El código que define los punteros en el emulador es: paginas[0]=rom39[4]; paginas[1]=rom[4]+8*1024; paginas[2]=rom[4]+8*1024*2; paginas[3]=rom[4]+8*1024*3; paginas[4]=rom[3]; Posición (hexadecimal)

Descripción ROM asociada

0000-1DFF Memoria RAM, 7679 octetos 1E00-1F80 Animaciones, 384 oct. 2000-23FF Objetos, 1 koct. 2400-27FF Atributos de los objetos, 1koct 2800-2BFF Fondos, 1 koct 2C00-2FFF Atributos de los fondos, 1koct 3000 Registro de entrada de monedas 3002 Registro de la palanca 3800-39FF Paleta gráfica 3A00 comunicación con el Z80 3B08 Desplace del fondo horizontal 3B09 Desplace del fondo horizontal, dígito

mayor

3B0A Desplace del fondo vertical 3B0B Desplace del fondo vertical, dígito mayor 3C00 Registro de autoarranque 3E00 Registro de paginación 4000 Programa paginado GG4 y GG5

6000 Programa sin paginar Últimos 8ko de GG4

8000 Programa sin paginar GG3 Los registros se activan a nivel bajo: Descripción Dígito 7 Dígito 6 Dígito 5 Dígito 4 Dígito 3 Dígito 2 Dígito 1 Dígito 0 3000, monedas

2ª moneda, 100 ptas.

1ª moneda, 25 ptas.

Comienzo del 2º jugador

Comienzo del 1er jugador

3002, palanca

Salto Disparo Arriba Abajo Izquierda Derecha

3003, DIP 2 A 3004, DIP 1 A

ver la sección de los microinterruptores

39 Como en C los índices de los vectores empiezan desde cero, rom[4] apunta a gg5


100

Ya en el espacio de memoria del Z8040, el registro de comunicación con la UCP de sonido está en la dirección C800. Hay dos circuitos sonoros YM-2203 cuyos registros ocupan las posiciones desde E000 hasta E003, inclusive.

Codificación de los gráficos en las memorias ROM Los caracteres se componen de bloques de 8x8 puntos con dos dígitos por punto, permitiendo, por tanto, cuatro colores distintos y ocupando 16 octetos. En total hay 512 caracteres cuyo formato en la ROM es: Octeto n Octeto n+1 1er cuarteto 2º cuarteto 1er cuarteto 2º cuarteto Puntos del 1 al 4, primer plano

Puntos del 1 al 4, segundo plano

Puntos del 5 al 8, primer plano

Puntos del 5 al 8, segundo plano

Esto se repite ocho veces, una por cada línea del carácter, al adaptar estos gráficos a los requisitos gráficos de un PC hay que poner cada punto con sus dos planos en un único octeto; pasando a ocupar entonces 8*8=64 octetos cada carácter. Existen cuatro juegos de bloques para formar los fondos del juego, cada uno compuesto por 256 bloques de 16 por 16 puntos y tres dígitos por punto, lo que permite ocho colores. Estos cuadrados están almacenados como rectángulos de 8x16 en la ROM, durante la descodificación se reorganizan los datos en cuadrados de 16x16 octetos. Como sólo se usan tres dígitos por punto, los cinco dígitos superiores de cada octeto están sin utilizar; más adelante se aprovecharán para incorporar sobre ellos la paleta gráfica. Para las animaciones (u objetos) existen tres juegos de 256 bloques de 16x16 puntos cada uno. Los objetos tiene cuatro dígitos por punto, lo que contabiliza 16 posibles colores. La organización en memoria es totalmente lineal, ocupando cada bloque 16x16x2 dígitos seguidos en una ROM (dos planos) y otros 16x16x2 en otra ROM (los restantes dos planos). Cuando se decodifican en el emulador se reorganizan para ocupar 16x16 octetos, en cada octeto sólo se usa el cuarteto inferior.

40 procesador responsable del sonido


101

Funcionamiento del circuito gráfico La circuitería gráfica de G&G permite representar un fondo compuesto por bloques de 16x16 puntos que encajan como un mosaico, un número limitado de objetos sobre cualquier región del fondo y por encima de todo esto; un nuevo mosaico compuesto por caracteres que servirán para dar información sobre la puntuación y desarrollo del juego. Los caracteres no requieren registros de desplace pues se proyectan directamente sobre la pantalla. Además del octeto que indica el número del carácter a pintar hay otro adicional, de atributos cuyo contenido es:

Formato de los octetos de atributos de los caracteres 7 6 5 4 3 2 1 0

sin uso conocido página de ROM

sin uso conocido paleta

Con el dígito quinto puede seleccionarse cualquiera de las dos páginas disponibles, de 256 bloques cada una. Hay dieciséis paletas de cuatro colores disponibles para los caracteres. Tanto los códigos de los fondos como sus atributos se componen de cuatro pantallas que se cierran sobre sí mismas cuando se proyectan a través de la ventana virtual del juego. Es decir, es el funcionamiento básico descrito en la sección de fondos. Cuando se interpreta el contenido de los fondos hay que tener en cuenta que en esta máquina concreta, los fondos internamente se indican –con su código- girados 90º, por lo que cada incremento de un octeto en la memoria de fondo no indica avanzar en las abscisas, sino en las ordenadas.

Formato de los octetos de atributos de los fondos 7 6 5 4 3 2 1 0

página de ROM giro vertical

giro horizontal prioridad paleta

Los dígitos sexto y séptimo indican cuál de los cuatro juegos de fondos disponibles en las memorias ROM se seleccionarán; en total hay cuatro páginas de 256 bloques. Cuando el tercer dígito, de prioridad, está marcado significa que el bloque de fondo se dibuja sobre los objetos. Con los tres dígitos de menor peso pueden seleccionarse ocho paletas, cada una de ocho colores. Los objetos mostrables simultáneamente en pantalla son 96, cada uno requiere cuatro octetos cuyo orden es el siguiente: código del objeto, atributos, abscisa y ordenada.

Formato de los octetos de atributos de los objetos 7 6 5 4 3 2 1 0

página de ROM paleta giro vertical

giro horizontal

sin uso conocido

recorte horizontal


102

Cuando el objeto alcanza el borde izquierdo o derecho de la pantalla el dígito cero se activa y se combina junto con el dígito mayor de la abscisa para seleccionar dos columnas de la pantalla donde el objeto se dibujará con el desplace indicado por los restantes siete dígitos de las abscisas. Con los dígitos quinto y cuarto pueden seleccionarse cuatro paletas de dieciséis colores. Con los dígitos sexto y séptimo se selecciona la página de ROM, en total hay tres páginas con 256 objetos cada una. Al dibujar los objetos la prioridad está invertida: los objetos en las posiciones de memoria mayores han de pintarse antes que los otros. Otra precaución a tomar es que la memoria de objetos lleva un retraso de una imagen con respecto a la de fondos, así que para pintar cada nueva imagen hay que mezclar la información de fondos actual con la previa de objetos.

Paleta La paleta tiene un cuarteto por cada color: es decir, cuatro dígitos para el rojo, cuatro para el azul y cuatro para el verde. En total la paleta suma doce dígitos por entrada, por lo que hay un total de 4096 colores disponibles. La distribución en memoria es como sigue:

Posición Contenido 3800-38FF cada octeto contiene el rojo y el verde 3900-39FF Los cuartetos superiores contienen el azul, los inferiores están a cero

Dentro de cada banda (38xx o 39xx) se encuentran las paletas de cada grupo de gráficos:

Posición Contenido Colores Paletas xx00-xx3F paletas de fondo 8 8 xx40-xx7F paletas de objetos 16 4 xx80-xxBF paletas de caracteres 16 4 xxC0-xxFF duplicado (?)


103

Interruptores DIP Esta máquina tenía dos microinterruptores DIP que permitían configurar algunas de las características del juego.

Uso Acción 1 2 3 4 5 6 7 8 ninguno ninguna X

fácil NO NO normal NO SI difícil SI NO

dificultad

dificilísimo SI SI 20.000,

70.000 y cada 70.000

NO NO

30.000, 80.000 y

cada 80.000

NO SI

sólo a los 20.000 y a los 70.000

SI NO

bonificación

sólo a los 30.000 y a los 80.000

SI SI

mesita NO mueble de pie SI

1 NO NO 2 NO SI 3 SI NO

vidas iniciales

4 SI SI microinterruptor 1A

La bonificación es una vida adicional y por tanto está relacionada con la dificultad del juego. En G&G es habitual haber conseguido 20.000 puntos al terminar la primera fase y obtener los 70.000 al llegar a la tercera fase; de esa forma el jugador obtiene una pequeña recompensa con sus progresos. Alcanzar los 140.000 puntos mínimos necesarios para una tercera vida extra exigía un juego muy orientado a puntuar que era a la par peligroso y aburrido. En el segundo microinterruptor se define si la pantalla se girará vertical y horizontalmente para el caso en que la imagen se vea a través de un reflejo. Hay además un microinterruptor que permite operar el equipo en el modo de pruebas para detectar algunos errores, esto se detallará en el apartado siguiente. Esta máquina sólo permitía utilizar una de las dos entradas de monedas instaladas, para ella se definía la relación entre número de partidas y monedas deseada.


104

Uso Acción 1 2 3 4 5 6 7 8

normal NO pantalla invertida SI normal NO

funcionamiento de pruebas

SI

siempre SI sonido juego NO

primero NO monedero a usar segundo SI

1/1 NO NO NO NO 1/2 NO NO NO SI 1/3 NO NO SI NO 1/4 NO NO SI SI 1/5 NO SI NO NO 1/6 NO SI NO SI 1/7 NO SI SI NO 2/1 NO SI SI SI 2/2 SI NO NO NO 2/5 SI NO NO SI 3/1 SI NO SI NO 3/2 SI NO SI SI 3/4 SI SI NO NO 4/1 SI SI NO SI

monedas /

partidas

4/3 SI SI SI SI microinterruptor 2A


105

El modo de pruebas

modo de pruebas de G&G Cuando el técnico activa el modo de pruebas aparece una pantalla de información que sirve para saber el estado de los microinterruptores y para hacer una pruebas mínimas. Las tablas mostradas en el apartado anterior encuentran su correspondencia aquí y puede verse fácilmente la correspondencia entre los interruptores y este modo. Pese a que existen dos líneas de equivalencias entre monedas y partidas sólo una de ellas es ajustable, como se indicó anteriormente. El acrónimo ATS significa ATraction Sound y hace referencia al interruptor de sonido, su función es si habrá o no sonidos y música cuando no esté jugando nadie; si los hubiese, servirían para atraer clientes. Las columnas de ceros bajos los acrónimos 1P y 2P se tornan en unos cuando la palanca o los botones adecuados se pulsan, de esta forma se puede comprobar su funcionamiento. Bajo Sound Code (código de sonido) se encuentra un número que puede cambiarse usando derecha e izquierda, al pulsar el botón de disparo el sonido se reproduce. Esto sirve para detectar fallos de sonido, el siguiente diagnóstico puede aplicarse: Problema Posible causa Acciones recomendadas No se oye ningún sonido Fallo grave en el

sistema de audio. -Comprobar la conexión de los altavoces -Comprobar la etapa de amplificación -Sustituir el Z80 por otro -Sustituir la ROM por otra -Sustituir el registro por otro -Sustituir la RAM por otra -Sustituir los generadores de FM

Los sonidos se oyen aunque con distorsión

Fallo en la etapa de audio analógica

-Cambiar altavoz -Cambiar el amplificador operacional -Revisar los condensadores -Cambiar los convertidores DAC

Sólo algunos sonidos se oyen

Fallo en el sistema de audio digital

-Cambiar el registro por otro -Cambiar la ROM por otra


106

Miscelánea La comprobación de las memorias que hace la máquina al arrancar puede saltarse, en la versión estadounidense de G&G, evitando la llamada a la rutina mediante la colocación oportuna de tres operaciones nulas nop. El código del mapefer3 que realiza esto es: if (juego == GNG_USA) ram[0x607a] = ram[0x607b] = ram[0x607c] = 0x12; /*nop*/ de esta forma cuando la máquina llega a la posición 607Ah en vez de encontrarse un salto a subrutina no haya más que tres nop, evitando la verificación del sistema y arrancando mucho antes.

pantallas del arranque evitables


107

Gryzor

Contenido de los ficheros ROM

Fichero Tipo de EPROM Lugar en la placa41 Contenido G-1.ROM 27256 - 32kOct P5 Código de sonido G-2.ROM 27512 – 64kOct H2 Código de juego G-3.ROM 27512 – 64kOct J2 Código de juego

G-4.R.ROM OM 27512 – 64kOct A17 Fondo lejano G-5.ROM 27512 – 64kOct C17 Fondo lejano G-6.ROM 27512 – 64kOct D17 Fondo lejano G-7.ROM 27512 – 64kOct F17 Fondo próximo G-8.ROM 27512 – 64kOct H17 Fondo próximo G-9.ROM 27512 – 64kOct J17 Fondo próximo G-10.ROM 27512 – 64kOct K17 Fondo próximo G-11.ROM 27512 – 64kOct L17 Objetos G-12.ROM 27512 – 64kOct M17 Objetos G-13.ROM 27512 – 64kOct P17 Objetos G-14.ROM 27512 – 64kOct Q17 Objetos G-15.ROM 27512 – 64kOct R17 Objetos G-16.ROM 27512 – 64kOct T17 Objetos G-17.ROM 27512 – 64kOct V17 Objetos G-18.ROM 27512 – 64kOct W17 Objetos

La posición que ocupa en la placa está descrita en forma de coordenadas. Es muy habitual nombrar las columnas y las filas en las placas de circuito impreso con letras y números para filas y columnas, a cada componente se le asigna una combinación de ambos y esa referencia se utiliza en las reparaciones cuando se encargan componentes al fabricante.

Paginación y mapa de memoria

Posición (hexadecimal) Descripción 0010 Insertar monedas y comenzar 0011 entrada del 1er jugador 0012 entrada del 2º jugador 0014 DIP 0 0015 DIP 1 0016 DIP 2 0018 Contador de monedas 001A Disparador de interrupciones

41 Estas ROM se volcaron de una placa Gryzor (Contra) japonesa de contrabando etiquetada 712-47, fueron una aportación del australiano [email protected]; que también ayudó durante el proyecto con fotografías e información de primera mano sobre el funcionamiento real del equipo.


108

001E Registro de autoarranque 0C00-0D00 Paleta gráfica 1000-1FFF Memoria RAM, 4 koct 2000-23FF Atributos del fondo 1, líneas 5-25h 2400-27FF Fondo 1, líneas 5-25h 2800-2BFF Atributos del fondo 1, líneas 0-5 2C00-2FFF Fondo 1, líneas 0-5 3000-37FF Objetos 3800-3FFF Objetos, ¿Reflejo de 3000-37FF? 3B31 Desplace del 2º fondo 4000-47FF Fondo 2, atributos 47FF-4800 Fondo 2, bloques 5000-57FF Objetos 5800-5FFF Reflejo de 5000-57FF (?) 7000 Registro de paginación 6000-7FFF Memoria paginada 8000-FFFF 32 koct de ROM, son los superiores de G2.ROM

Se da la extraña circunstancia de que el registro de paginación (de sólo escritura) está mapeado en medio de la memoria ROM paginada (de sólo lectura). Para que esto fuera posible el circuito de selección de memoria tenía que inspeccionar la patilla R/W del procesador. La UCP de sonido:

Posición (hexadecimal) Descripción 0000 Comunicación con la otra UCP 2000 Registro del YM2151, sólo lectura 2001 Datos del YM2151, lectura y escritura 6000-67FF RAM 8000-FFFF ROM


109

Codificación de los gráficos en las memorias ROM42

Caracteres y fondos Los caracteres de Gryzor son bloques de 8x8 puntos con cuatro dígitos por punto, y por lo tanto dieciséis colores posibles por punto. La codificación es muy sencilla puesto que los cuatro dígitos correspondientes a cada punto aparecen en la ROM de forma consecutiva agrupados en cuartetos. Cada octeto tiene, por consiguiente, dos puntos; cada bloque ocupa 32 octetos.

Ejemplo de caracteres de Gryzor Hay dos detalles curiosos con los caracteres de Gryzor:

• Aunque la máquina es capaz de realizar la función de reflejo horizontal y vertical de los caracteres, muchos de ellos aparecen ya girados en la ROM.

• Gryzor era una máquina de monitor vertical, es decir la imagen era más alta que larga, por lo que los caracteres aparecen en la ROM ya girados 90 grados para su presentación en vertical.

Objetos

Los objetos se componen de bloques de 16x16 puntos, pero cada uno de estos bloques se almacena en la ROM como cuatro de 8x8 puntos, cuya codificación es análoga a la de los caracteres. Para formar el bloque de 16x16 a partir de los de 8x8 hay que seguir el siguiente orden: en la memoria ROM los cuatro bloques aparecen como ABCD, si se reconstruyen se puede formar el bloque:

A BC D

Pero éste está girado 90 grados, que es lo que necesitaba la circuitería de Gryzor. Para la emulación necesitamos que el bloque esté horizontal, luego lo giramos 90º quedando:

C AD B

42 Hay que agradecer a Roberto Ventura su colaboración excepcional en el descifrado de los gráficos


110

Objetos de Gryzor, en la imagen puede apreciarse como cada bloque de 16x16 corresponde a una posición del jugador.

Funcionamiento del circuito gráfico

El primer fondo Este el plano más cercano a la acción, está separado en dos partes. La primera son sólo cinco líneas de bloques (40 puntos de altura en total) y la siguiente son 32 líneas (256 puntos de altura). Las primeras líneas van sobre un fondo negro en la parte superior de la pantalla aunque en Grytra hemos preferido montarlas en la parte lateral derecha para que el conjunto quede más ancho que largo y poder así utilizar una resolución menor de vídeo que muestre gráficos proporcionalmente mayores. En las primeras líneas se obtiene el valor del bloque a pintar explorando la memoria 2C00h, 400h por debajo están los atributos de los que se extrae la paleta gráfica a usar. for( x=0x1F; x>=0; x--, explo+=0x20-5 ) for( y=0; y<5; y++,explo++ ) attr = ram[explo-0x400]; color = ((attr)&3); pon_bloque_bruto( fondo[3],ram[explo], x<<3, y<<3,tabla[color]<<4 ); Para la 2ª parte del fondo se examinan la memoria en 2400h. La mecánica es la misma con la salvedad de que ahora es necesario descodificar además los dígitos superiores del número de bloque. Ésta información está en el atributo y se obtiene a través de unas operaciones lógicas:

attr = ram[explo-0x400]; color = ((attr)&3); attr = (attr&0xf8)>>3; b3 = (attr & 0x8)<<1; b2 = (attr & 0x4)<<2; aux = (attr&0x10) >> 4; attr = ((attr<<1)+aux)&0x1f; attr &= 0xf;


111

attr |= (b3^b2); pon_bloque_bruto( fondo[3],ram[explo]+(attr<<8), x<<3, y<<3, tabla[color]<<4 );

El segundo fondo

Éste fondo está en la posición 4400h (4000h para los atributos) y parece utilizar siempre la misma paleta. Ocupa un área de 256x256, en Grytra se pinta de la siguiente manera

attr = (attr&0xf8)>>3; aux = (attr&0x10) >> 4; attr = ((attr<<1)+aux)&0x1f; pon_bloque_bruto( fondo[0], ram[explo]+/*bloque[attr]*/(attr<<8), x<<3, y<<3, 6<<4 );

Los objetos

Los objetos en Gryzor ocupan cuatro zonas de memoria distintas, éstas son: 3000h, 3800h, 5000h y 5800h; sin embargo parece que unas son una imagen de las otras luego basta con pintar dos de ellas. El emulador programado dibuja las zonas 3800h y 5000h. Estas zonas se componen de estructuras de cinco octetos donde el antepenúltimo y el penúltimo son las coordenas; abscisas y ordenadas respectivamente, y los dos primeros los atributos. La posición en la memoria ROM del bloque a dibujar se obtiene a partir de la siguiente fórmula: attr = (ram[explo+1]&0x7)<<8; bloque = (ram[explo]+attr)<<2;

explo es la posición de la estructura de objeto analizada

Además cada pareja de zonas gráficas corresponde a un conjunto de memorias ROM diferente, así que cuando ponemos todas las ROM consecutivas en memoria para hallar el número del bloque hay que sumar 8192 si analizamos las zonas 3x00h:

if ( con_zona<2) bloque+=2048*4; Por último, si el dígito 6 del quinto octeto está activado hay que sumar 4096 al número de bloque:

if ( ram[ explo+4 ] &0x40 ) bloque+=1024*4; Para saber si el bloque ha de invertirse es necesario realizar la ó exclusiva de dos dígitos:

if ( (ram[explo+4]&0x20) ^ ((ram[explo+4]&0x10)<<1) ) Por último Gryzor tiene una peculiaridad: hay un determinado dígito que, caso de estar activo, nos indica que hay que dibujar un objeto no de 16x16 sino de 32x32, en ese caso los números de bloque restantes son consecutivos.

La paleta gráfica Hay ocho paletas gráficas sitas en 0C00h, cada una de 32 octetos de longitud. Cada color está compuesto por tres primarios (rojo, verde y azul) de cinco dígitos cada uno (25*3=2048 colores). Vistos en memoria los colores están escritos en parejas de dos


112

octetos, si situamos primero el que ocupa la posición mayor de memoria se puede leer azul, rojo y verde consecutivamente: aux = ram[con+0xc00+paleta*32]; rgb.r = aux&0x1f; rgb.g = (aux&0xE0)>>5; aux = ram[con+0xc01+paleta*32]; rgb.b = (aux&0x7c)>>2; rgb.g |= (aux&0x3)<<3;

Octeto inferior, ahí están el rojo y parte del verde en el octeto superior están el azul y el resto del verde

Como la paleta de la VGA trabaja con colores de 6 dígitos, es necesario añadir una cifra adicional al color. Lo ideal sería hacer una transformación lineal multiplicando por 63 y dividiendo por 31, pero es más rápido hacer sencillamente un desplazamiento de una posición a la izquierda; el error cometido es muy pequeño y básicamente en la luminancia de la imagen:

rgb.r <<= 1; rgb.g <<= 1; rgb.b <<= 1;


113

Interruptores DIP

Primer microinterruptor

Uso Acción 1 2 3 4 5 6 7 8 1/1 NO NO NO NO ½ NO NO NO SI

1/3 NO NO SI NO 1/4 NO NO SI SI 1/5 NO SI NO NO 1/6 NO SI NO SI 1/7 NO SI SI NO 2/1 NO SI SI SI 2/3 SI NO NO NO 2/5 SI NO NO SI 3/1 SI NO SI NO 3/2 SI NO SI SI 3/4 SI SI NO NO 4/1 SI SI NO SI

primer monedero

4/3 SI SI SI NO precio gratis SI SI SI SI

1/1 NO NO NO NO 1/2 NO NO NO SI 1/3 NO NO SI NO 1/4 NO NO SI SI 1/5 NO SI NO NO 1/6 NO SI NO SI 1/7 NO SI SI NO 2/1 NO SI SI SI 2/3 SI NO NO NO 2/5 SI NO NO SI 3/1 SI NO SI NO 3/2 SI NO SI SI 3/4 SI SI NO NO 4/1 SI SI NO SI

segundo monedero

4/3 SI SI SI NO Sin uso Inválido SI SI SI SI


114

Segundo microinterruptor

Uso Acción 1 2 3 4 5 6 7 8 2 NO NO 3 NO SI 5 SI NO

vidas

7 SI SI a los 30.000 y cada 70.000

NO NO

a los 40.000 y cada 80.000

NO SI

sólo a los 40.000 SI NO

Bonificación

sólo a los 50.000 SI SI fácil NO NO

normal NO SI difícil SI

Dificultad

dificilísimo SI NO NOSonido de

captación SI SI

Tercer microinterruptor

Uso Acción 1 2 3 4 5 6 7 8 normal NO Giro de la pantallainvertido SI normal NO funcionamiento pruebas SI estéreo NO tipo de sonido mono SI

La explicación de estas opciones es la misma que en el caso del G&G. La configuración por defecto del equipo era: una moneda por partida –ambos monederos, tres vidas con bono a los 30.000 y cada 70.000 puntos, dificultad normal, sin girar la pantalla, modo de juego y sonido estéreo43.

43 Datos sacados del manual de servicio de Contra


115

El modo de pruebas Gryzor incluye un modo de pruebas más completo que el de G&G, consta de seis pantallas por las cuales se navega pulsando simultáneamente 1P y 2P.

1. La primera pantalla es similar a la del G&G y permite evaluar si las entradas

funcionan correctamente: el estado de las palancas, botones e interruptores DIP se muestra en pantalla.

2. La siguiente prueba envía pulsos para los contadores de monedas, de esta forma se comprueba si los registros de salida funcionan.

3. A continuación, se muestra el estado de los interruptores DIP no de forma numérica sino conceptual; así se puede programar el comportamiento de la máquina más fácilmente.

4. Para medir si los gradientes aplicados al tubo de rayos catódicos son los adecuados se usa la prueba de ortogonalidad. La máquina muestra una rejilla

1. Prueba de entradas 2. Prueba de contadores 3. Interruptores DIP

4. Ortogonalidad del monitor 5. Prueba de color 6. Prueba de sonido


116

perfecta, el técnico debe ajustar el monitor para que las intersecciones formen ángulos rectos.

5. También relacionada con el monitor, la siguiente pantalla muestra gradientes de colores que sirven para comprobar si alguno de los tubos de color falla, ya sea completamente o por un error de ganancia –que se podrá ajustar. En ocasiones basta desmagnetizar el monitor para solucionar el problema.

6. Finalmente, la prueba de sonido es análoga a la del G&G. Sobre posibles fallos y soluciones consulte la sección del G&G.

Miscelánea Al igual que en el caso de G&G, es posible saltarse las rutinas iniciales de verificación del equipo para acelerar el arranque de la máquina. El código empleado en Grytra es: /* parche para saltarse la comprobación de la RAM/ROM */ ram[ 0x800a] = 0x63; ram[ 0x800b] = 0xe7; y se basa en variar la dirección del salto inicial que hace el sistema.

Imágenes del arranque de Gryzor evitables modificando la ROM


117

Combat School Combat School funcionaba en una placa con dos procesadores: un 6809 para el juego, que funcionaba a 3MHz; y un Z80 para el sonido, a 1’5MHz. El responsable de la música era el integrado de Yamaha YM2203 y el encargado de reproducir las voces digitalizadas era el UPD7759.

Contenido de los ficheros ROM El volcado que se describe en la tabla siguiente procede de una placa pirata de Combat School y es el que utiliza el emulador Escuela de combate. Todos los ficheros pesan 64 koct.

Nombre del fichero Descripción

combat.001 código de la UCP de sonido

combat.002 los 32koct. superiores ocupan la memoria superior del 6809, los 32 koct. inferiores son memoria paginada.

combat.003 páginas, de la 10h a la 17h combat.004 páginas, de la 18h a la 1Fh combat.005 Fondos, segundo grupo combat.006 Fondos, primer grupo combat.007 Fondos, segundo grupo combat.008 Fondos, primer grupo combat.009 Fondos, segundo grupo combat.010 Fondos, primer grupo combat.011 Fondos, segundo grupo combat.012 Fondos, primer grupo combat.013 Objetos, primer grupo combat.014 Objetos, segundo grupo combat.015 Objetos, primer grupo combat.016 Objetos, segundo grupo combat.017 Objetos, primer grupo combat.018 Objetos, segundo grupo combat.019 Objetos, primer grupo combat.020 Objetos, segundo grupo

Codificación de los gráficos en las memorias ROM Los bloques de fondos están separados en cuatro memorias ROM, en cada una de ellas hay uno de los planos de color. De forma que si tomamos únicamente una de las memorias obtenemos un bloque monocromático; combinando dos, cuatricolor; tres, octicolor y al juntar los cuatro, bloques de dieciséis colores. Cada bloque, de 8x8 puntos, ocupa ocho octetos consecutivos de memoria. En cada octeto, cada cifra corresponde a un punto. La codificación es sencilla y directa.


118

Los objetos están almacenados de una forma menos intuitiva. Son bloques de 16x16 puntos, también de cuatro planos (dieciséis colores) pero están codificados como si fuesen de 8x16, de tal forma que uno de 16x16 está guardado como dos de 8x16 seguidos. Los bloques de 8x16 se componen de 16 octetos seguidos que almacenan ocho puntos cada uno.

Paginación y mapa de memoria

Posición Longitud (octetos) Descripción

00C0-00C3 4 Límite de los objetos44 0400 1 Orden de escritura (prioridad) de los gráficos 0500 1 Paginación de la ROM y selección del circuito gráfico 600-6FF 256 Paleta gráfica 0800-1FFF 4608 (?) Memoria RAM 2000-2FFF 4096 Circuitos gráficos, fondos 3000-3FFF 4096 Circuitos gráficos, objetos 4000-7FFF 16384 Memoria paginada, registros de E/S y de vídeo 8000-FFFF 32768 Memoria ROM

En la posición 500h hay un registro de ocho dígitos que controla qué página de ROM está seleccionada y qué circuito gráfico (de los dos disponibles) está seleccionado.

Registro 500h Dígito 7 Dígito 6 Dígito 5 Dígito 4 Dígito 3 Dígito 2 Dígito 1 Dígito 0 Circuito

gráfico Página de ROM seleccionada

La máquina tiene dos circuitos gráficos de 8192 octetos de longitud situados en la posición 2000h, cada uno de ellos es capaz de dibujar fondos y objetos sobre ellos. Las páginas no siguen un orden natural ya que hay una algún tipo de codificación en el número que se escribe en 500h; de hecho, hay 32 posibles páginas según 500h pero sólo 18 de ellas son reales.

Número de página

Fichero ROM

Posición en el fichero

00 Combat.002 0 01 Combat.002 4000h 10 Combat.003 0 12 Combat.003 2000h 14 Combat.003 4000h 16 Combat.003 6000h 18 Combat.004 0 1A Combat.004 2000h 1C Combat.004 4000h 1E Combat.004 6000h

44 Ver la sección de gráficos para una explicación de éste registro


119

1F Combat.002 4000h Los últimos 32 kilo octetos de combat.002 corresponden a la mitad superior de la memoria del 6809 y no están paginados. En ellos reside el código de arranque.

Funcionamiento del circuito gráfico Como ya se ha dicho, hay dos circuitos gráficos idénticos mapeados en 2000h-3FFFh , con el registro 500h se selecciona uno u otro a la hora de realizar operaciones de escritura. En la zona de memoria paginada (4000-7FFF) hay algunos registros de vídeo de sólo lectura. De forma que cuando se accede a esa área para lectura, los datos provienen de la ROM y cuando se escribe en ella, los datos van a los registros de vídeo.

Los fondos El fondo gráfico está compuesto por tres capas, dos de ellas susceptibles de desplazamiento y una última formada por caracteres. Las dos primeras se dividen en 32 bandas horizontales, cada una correspondiente a una altura en la pantalla y con un desplace horizontal diferente de la siguiente. Al conjunto de las 32 filas le corresponde un único valor de desplace vertical. Un fondo puede tapar al otro o viceversa según el valor de un registro de prioridad, situado en la posición 400h, pero la superposición es total: o bien un fondo oculta a otro, o bien el otro al primero; pero no puede ocurrir que una sección tape a otra sin que afecte al resto. No existe una pantalla virtual, como en el caso del Ghosts and Goblins; y el espacio reservado para pintar la imagen es tan sólo de una columna (ocho puntos de ancho). Los registros de desplace horizontal ocupan desde la posición 0x4040 hasta la 0x408F, los primeros 32 (20h) corresponden a un circuito gráfico y los siguientes a otro. En las posiciones 0x4000 y 0x4020 están los registros de desplace vertical, de un octeto cada uno y que se aplican al conjunto de las filas. La razón de este peculiar fondo, compuesto por filas desplazables individualmente está en la primera fase del juego, en ella los dos jugadores compiten en una carrera: la pantalla se divide en dos, la mitad superior corresponde a un jugador y la inferior al otro. Aunque corren en el mismo escenario cada uno puede estar en una zona distinta e incluso muy alejado del otro; además cada uno se mueve a una velocidad. Esta circunstancia requiere que media pantalla se mueva a un ritmo independiente de la otra media y que, por lo tanto, necesite registros de desplace diferentes. ¿Por qué uno para cada fila de la pantalla y no para cada mitad? Seguramente se prefirió un diseño más flexible en caso de que en otro juego que utilizase el mismo integrado pudiera ser útil un control a nivel de fila. En la práctica sólo hay dos ocasiones en el juego en que se utilice esta característica tan peculiar: una es en la presentación de los jugadores donde el movimiento de los rostros se consigue de esta forma, la otra es la mencionada primera fase.


120

Primera fase, emulada con Escuela de

Combate Los retratos están compuestos en el fondo y se

mueven independientemente

Los objetos Los objetos, bloques de 16x16 puntos, están mapeados en la zona 3000-3FFFh. Allí una estructura de cinco octetos de longitud contiene la información sobre qué, dónde y cómo pintarlos.

Octeto 0 Octeto 1 Octeto 2 Octeto 3 Octeto 4 Número de

bloque Abscisa Ordenada Atributos paleta

El número completo del bloque a pintar, una vez colocadas todas las ROM linealmente en memoria se obtiene mezclando la información de los atributos con el número dado en el primer octeto: int pagina = (color & 0x03) | ((atributos & 0x40) >> 4); bloque = ((bloque & 0x02) << 1) | ((bloque & 0x04) >> 1) | (bloque & (~6)); bloque += 256*pagina; Como vemos, es necesario desenredar un cierto galimatías con los dígitos binarios para poder obtener un número de bloque lineal. Las coordenadas requieren también una pequeña transformación antes de ser utilizables:

unsigned x = contador[2] - 71 + (atributos & 0x01)*256; unsigned y = 242 - contador[1];

Las ordenadas se almacenan contando desde abajo, para invertirlas basta restarlas de la altura de la pantalla (242 puntos). Las abscisas también están tomadas al revés, pero además falta el dígito de mayor peso que se obtiene de los atributos. El quinto dígito de los atributos (máscara: 10h) indica si hay que girar horizontalmente el objeto al pintarlo.


121

El modo de pruebas Las pruebas de Combat School son muy parecidas a las de Gryzor, por tanto sólo se explicarán las diferencias, remitimos a la sección sobre Gryzor para una explicación más detallada.

1. Ortogonalidad de la pantalla 2. Prueba de sonido 3. Prueba de color

4. Prueba de las entradas 5. Prueba de los contadores 6. Interruptores DIP Volvemos a encontrarnos con un completo modo de pruebas dividido en seis pantallas. De ellas la novedad es la cuarta, en la que las entradas son algo más complicadas que anteriormente. Esto se debe a que Combat School se distribuía en versiones para palanca y esfera. Cuando se jugaba con la esfera se gozaba de una sensibilidad adicional y en vez de tener el espacio dividido en cuatro direcciones y cuatro diagonales había otras ocho semidiagonales adicionales: dieciséis posiciones posibles en total. El resto de las secciones: ortogonalidad, sonido, color, contadores e interruptores son similares a las de Gryzor.


122

Miscelánea

Conexión de una palanca normal Como ya se ha comentado anteriormente, Combat School funcionaba con una especie de semiesfera que dotaba al jugador de dieciséis direcciones posibles de movimiento frente a las ocho de una palanca normal. El requisito de la semiesfera limitaba el uso de la placa con muebles convencionales (distintos al original de Konami) sin embargo había una forma de utilizar esta placa con una palanca normal.

conexión del 74LS245 para utilizar una palanca normal

Las señales procedentes de la semiesfera llegan al conector jama y de él hasta un integrado a medida. Si sustituimos ese circuito por el juego de búferes normal 74LS245 siguiendo el conexionado indicado podremos utilizar una palanca normal conectada de la forma habitual al jama.

Salto de los retardos iniciales Al comienzo del programa hay unos retardos considerablemente largos que en principio servían para permitir que otros dispositivos más lentos se encendiesen completamente. Como en el juego emulado esos problemas no existen, puede ningunearse la rutina de espera mediante el siguiente código:

pPagina[1][0x6145-0x4000]=0x39; // para evitar la rutina de retardo Donde la página 1 corresponde a los segundos 8 kilo octetos de la ROM combat.002, el número 6145h es la posición en memoria del octeto a cambiar y el 4000h convierte de direcciones de RAM a direcciones en el interior de la página.


123

Los emuladores En este último apartado presentaremos detalladamente el resultado del proyecto: los emuladores de las tres máquinas recreativas estudiadas, Ghosts & Goblins, Gryzor y Combat School.

Mapefer3, emulador de Ghosts & Goblins Este emulador fue el primero que se hizo. La labor de investigación, aunque existente, estuvo muy aminorada, pues pronto apareció un emulador funcional de un italiano, Roberto Ventura. El Sr. Ventura colaboró con información de la máquina recreativa al desarrollo de nuestro emulador, si bien todo el código es íntegramente nuestro y la solución final es más rápida que la codificada por el Sr. Ventura pese a estar la suya codificada totalmente en ensamblador. Este emulador recibió el nombre de mapefer3, en honor a la novia del programador, pues su dirección de correo de la UPV era ésa precisamente. El objetivo de este emulador era conseguir que el juego funcionase fluidamente en un equipo lento: un 486 DX 100 MHz.

Plataforma de desarrollo Se evaluaron varias alternativas: Turbo C, ensamblador 8086, ensamblador 80386, Watcom C/C++, Borland C 4.5 y el gratuito GCC. La decisión final fue GCC y los motivos fueron:

• Turbo C generaba únicamente código de 16 dígitos y permitía acceder sólo a 640 koct. La limitación de memoria era tolerable, pero los 16 dígitos y el modo real planteaban dudas sobre si el rendimiento sería aceptable

• Ensamblador 8086: Era posible optimizar mucho más el código, pero quedaba patente al escribir que las instrucciones del 80386 acelerarían mucho el proceso.

• Ensamblador 80386: Esta posibilidad si se tomó en serio y se hicieron varios conatos de emulación llegando algunos moderadamente lejos. El problema residía en que era muy difícil depurar el código de emulación del procesador, pues era demasiado extenso y repetitivo. A esto había que sumarle el tedio de tener que programar todas las rutinas desde cero.

• Watcom C/C++: se daba el caso de que disponíamos de una copia legal de este compilador por lo que se estudió su posible uso. Era factible generar código de 32 dígitos con facilidad, pero el compilador era incompatible con Windows 95, así que se desestimó su uso.

• Borland C 4.5: No era sencillo generar código de 32 dígitos y no permitía escribir acentos ni eñes entre los comentarios del código, este aspecto aunque tolerable técnicamente era inadmisible lingüísticamente en cuanto que suponía un desprecio de nuestro idioma y de todos los que no son anglófonos.

• Gcc (djgpp): El compilador gratuito de GNU generaba código de 32 dígitos y era legal. Estas dos circunstancias lo alzaron al podio.


124

Gcc, sin embargo, no es más que una utilidad de línea de comandos por lo que había que complementarla con algún entorno de desarrollo más cómodo. Después de buscar entre las alternativas disponibles para Windows45 encontramos RHIDE46,

Pantalla de presentación de RHIDE

La gran ventaja de RHIDE consiste en que la interfaz que presenta está calcada de la del Turbo Pascal y el Turbo C por lo que el uso es inmediato si se tiene experiencia en alguna de las herramientas de Borland. El sistema aún no estaba completo pues si se quería evitar direccionar directamente la memoria de vídeo del PC, con el engorro que ello conlleva, hacía falta una biblioteca gráfica. La elección fue Allegro, biblioteca de 32 dígitos para Gcc, de sencillo manejo y gran versatilidad. Así que Rhide se utilizó para escribir el proyecto, Gcc para compilarlo tanto el código en C como el código de ensamblador incrustado y Allegro como interfaz con el sistema gráfico del PC. El compilador de C gnu en su versión para PC puede descargarse de http://www.delorie.com/djgpp

45 Gcc es mucho más popular en Linux así que casi todos los entornos disponibles son para este sistema operativo. 46 El nombre RHIDE, está formado por las iniciales del autor más el acrónimo IDE (Integrated Development Enviroment, entorno de desarrollo integrado)

http://www.delorie.com/djgpp


125

Diagramas de flujo fundamentales En esta sección vamos a presentar los diagramas de flujo básicos para poder entender con más facilidad el código fuente en la siguiente sección

Función main

Función main El código se separa en dos partes: la lectura de las memorias ROM y descodificación de los gráficos que implica una posibilidad de error, caso de no encontrarse los ficheros; y la emulación propiamente dicha, compuesta de una primera preparación y del bucle de la emulación en sí. Estas dos partes se detallan a continuación.


126

Preparación y bucle de la emulación

Preparación Bucle de la emulación

La preparación consiste en colocar las memorias ROM en las posiciones adecuadas de la memoria virtual del 6809 simulado, realizar la llamada de arranque que precisa la biblioteca gráfica utilizada (Allegro), instalar el temporizador encargado de actualizar cada 20ms la variable ips_ideal de promediado de imágenes, capturar la entrada del teclado y de la palanca de juego y cambiar la resolución del monitor a 256x256 puntos y 256 colores. Se reserva además un área de memoria, denominada fondo virtual donde se compondrá la imagen de fondo según lo explicado anteriormente. El bucle de la emulación responde al modelo ya explicado, aunque aquí está algo más detallado. En el caso de que el jugador haya pausado el juego, el bucle se reduce a dibujar la pantalla y mostrar sobre ella mensajes informativos (tales como el rendimiento, medido en imágenes pintadas por segundo). Si el juego funciona con normalidad, sin la pausa, es preciso emular las instrucciones correspondientes a 20ms y disparar una interrupción del tipo IRQ, a continuación, según lo explicado en el capítulo de sincronización, se dibuja la pantalla si da tiempo a hacerlo y si no se omite este paso. Finalmente se actualizan las variables de promediado y se salvaguarda la memoria de objetos pues en Ghosts & Goblins esta memoria funciona un fotograma adelantada respecto de la de fondo.


127

Explicación del código fuente En esta sección vamos a diseccionar el funcionamiento del emulador tomando porciones del código y explicando sus funciones y cómo se enlazan con toda la teoría vista. Las funciones Ejecuta e irq, pertenecientes a la emulación del procesador se omiten en este análisis, pues ya se han revisado anteriormente. El código se presentará separado por secciones coloreadas y con explicaciones intercaladas con el siguiente formato:

esto es un comentario.

main int main(int argc, char *argv[]) /* variables */ char ant_munecos[96*4]; int error; unsigned scroll_x, scroll_y; int pintadas[2] = 0,0; /* im genes pintadas */ RGB blanco = 63,63,63 ; /* sonidos */ SAMPLE *gng2b; /* programa */ presentacion(); strcpy( directorio,"."); ipi = IPI; /* inicia el vector mostrar */ for(error=0; error < MOSTRAR; error++) con_mostrar[error]=0; /* l¡nea de par metros */ cmdline( argc, argv ); error = carga_rom( rom, directorio ); if ( error == 0 ) error = decodifica_graficos( rom ); if ( error == 0 ) if ( Inicia6809() == 0 ) error = NO_RAM; imprime_error( error ); return -1; prepara_memoria(); allegro_init(); LOCK_VARIABLE( ips_ideal ); LOCK_FUNCTION( temporizador ); install_timer(); install_int( temporizador, 1.0/60*1000 ); prepara_sonido(); install_keyboard(); initialise_joystick(); /* prepara la pantalla*/ if ( set_gfx_mode( GFX_AUTODETECT, res_x,res_y,0,0 ) < 0 ) goto final; set_clip( screen,0,0,0,0 );


128

bmp = create_dígitomap(256, 256); fondo_virtual = create_dígitomap(512,512); clear( fondo_virtual ); fondo_vir = fondo_virtual->line[0]; memoria = bmp->line[0]; reset(); ram[0x3000] = ram[0x3001] = ram[0x3002] = 0xff; set_color( 255,&blanco ); for(;;) if ( pausa ) if ( teclado() ) break; dibuja_pantalla( ant_munecos ); muestra_mensajes( pintadas ); blit(bmp, screen, (SCREEN_H-256)>>1, desplazamiento, 0, 0, 320, 224); continue; ejecuta( ipi ); irq(); if ( ips_real > ips_ideal ) dibuja_pantalla( ant_munecos ); pintadas[0]++; muestra_mensajes( pintadas ); blit(bmp, screen, (SCREEN_H-256)>>1, desplazamiento, 0, 0, 320, 224); if ( teclado() ) break; toca_sonidos(); if ( ips_ideal >= 59 ) ips_ideal=0; ips_media += ips_real; ips_media >>=1; ips_real = 0; pintadas[1] = pintadas[0]; pintadas[0] = 0; if ( ips_real++ >= ips_ideal ) memcpy( ant_munecos, ram+0x1e00, 96*4 );

Bucle de emulación Si el juego está pausado sólo se comprueba el teclado y se redibuja la pantalla. No se avanza la simulación. Se ejecutan IPI (Instrucciones Por Interrupción) instrucciones y se dispara una interrupción después. El control de la velocidad se realiza mediante promediado Se actualizan las variables de promediado Si la siguiente imagen se va a mostrar se copia la memoria de objetos

final: destruye_sonidos(); remove_keyboard(); set_gfx_mode( GFX_TEXT, 256,256,512,256 ); libera_rom( rom ); /* libera la memoria reservada para los gráficos */ free( car ); free( anim ); free( fondo ); despedida(); return 0; else imprime_error( error );

Se pulsó Esc: hay que salir del programa dejando el ordenador impoluto. Se libera toda la memoria reservada y se muestra un mensaje de despedida.


129

else imprime_error( error ); return -1; /* ha habido algún error */

OpIlegal

void ilegalC() printf("Op ilegal = %X",ram[pc-1]); vuelca_regs(); exit( ram[pc-1] );

Esta sencilla función se ejecutará cuando se encuentre una instrucción del 6809 sin emular. En la actualidad, con una emulación del procesador acabada y fiable, está función no es llamada jamás, sin embargo, durante el desarrollo inicial del emulador fue muy útil para detectar errores

Inicia6809 Esta rutina está programada en ensamblador (fichero 6809.s) y su objetivo es preparar las tablas de memoria que se utilizan como índice de salto para las operaciones emuladas. .align 4 _Inicia6809:.globl _Inicia6809 pushl $0x10000 call _malloc add $4,%esp cmpl $0,%eax jne reser ret reser: movl %eax,_ram movl %eax,%edi #Rellena la RAM con ceros movl $0x10000/4,%ecx movl $0,%eax rep stosl # operaciones movl $256,%ecx lea opIlegal,%eax lea _ops,%edi rep stosl .../...

Se reservan 64koct de memoria invocando a la función de C malloc. La memoria reservada será la memoria virtual del 6809. Se inicia a ceros El vector ops contiene las direcciones de las rutinas que emulan las operaciones del procesador. Se inicia con la dirección de la función de operación ilegal.

La rutina continúa rellenando ahora las tablas con los valores de las operaciones emuladas. Los códigos de operación que no estén reconocidos por el programa quedarán con la llamada a opIlegal, establecida por defecto. Cuando todas las tablas están completadas, la emulación del procesador está a punto y puede comenzar a ejecutar instrucciones. Hay más información sobre este proceso en la sección dedicada al procesador.


130

prepara_memoria Está función coloca la ROM fija en la posición que le corresponde en la memoria según sea el juego a emular void prepara_memoria() /* prepara el juego */ ram[ 0x3003 ] = 0xCF; /* DIP 2A */ ram[ 0x3004 ] = 0xFF & ~ 0x20; /* DIP 1A dificultad normal */ memcpy( ram+0x6000, rom[3]+0x2000, 0x2000 ); memcpy( ram+0x8000, rom[2], 32*1024 ); if ( juego == GNG_USA ) /* sonido */ z80_ram = malloc( 64*1024 ); if (!z80_ram ) puts("Faltan 64k de RAM."); exit(1); memset( z80_ram, 32*1024, 32*1024 ); memcpy( z80_ram, rom[1], 0x8000 ); free( rom[1] ); /* la libera pues no la usará más */ if ( juego != DIAMOND ) if (juego == GNG_USA) ram[0x607a] = ram[0x607b] = ram[0x607c] = 0x12; /* nop */ paginas[0]=rom[4]; paginas[1]=rom[4]+8*1024; paginas[2]=rom[4]+8*1024*2; paginas[3]=rom[4]+8*1024*3; paginas[4]=rom[3]; else /* páginas de diamond Run */ paginas[0]=rom[4]+0x4000; paginas[1]=rom[11]; paginas[2]=rom[11] + 2*0x4000; paginas[3]=rom[11] + 3*0x4000; paginas[4]=rom[11] + 4*0x4000;

Configura la dificultad del juego Copia la memoria fija a la posición que le toca Prepara la memoria del procesador de sonido (sin emular) Si el juego es el G&G coloca instrucciones nop para evitar las rutinas de comprobación del sistema del arranque Si el juego a emular es Diamond Run, las páginas que han de usarse son distintas


131

teclado Esta rutina inspecciona las teclas que están pulsadas para actuar en consecuencia. Hay dos tipos de teclas:

• Las que tienen efecto en la máquina simulada: los cursores que mueven el personaje, la tecla 3 que “inserta” monedas

• Las que actúan en el emulador en sí: como la P para pausa y la tecla Esc para salir del programa

Dentro del primer tipo el código es similar al de este ejemplo:

if ( key[0x4d] || joy_right ) ram[0x3001]&=0xfe; ram[0x3002]&=0xfe; else ram[0x3001]|=1; ram[0x3002]|=1; // derecha

Se evalúa el estado de una tecla y de la palanca, si este es el deseado se anula una determinada cifra del octeto de memoria RAM que representa al puerto de entrada de la placa original; si no fuera así, esa misma cifra se coloca a uno. Como ejemplo del segundo grupo veamos la tecla V que sirve para activar o desactivar la sincronización con el retrazo de la pantalla:

if ( key[0x2f] ) while( key[0x2f] ); vsinc = !vsinc; if ( vsinc ) con_mostrar[VSINC_SI] = 60; else con_mostrar[VSINC_NO] = 60;

Si se ha pulsado dicha tecla, se espera primero a que se suelte y a continuación se invierte el valor de la variable vsinc, según el nuevo valor de esta se mostrará un mensaje en pantalla informativo del cambio que prevalecerá durante 60 segundos.

escribe_mensaje Esta función escribe texto informativo sobre la pantalla del juego. Dado que el texto ha de permanecer sólo durante un breve tiempo y que el número de mensajes distintos es muy pequeño se optó por tener un vector de tiempos llamado con_mostrar (contador para mostrar) donde cada entrada indica el número de fotogramas que el mensaje ha de ser visible. En cada llamada a la función ese número se decrementa y si fuese positivo, se muestra el mensaje. Por ejemplo, el código para el texto de pausa es:

if ( con_mostrar[PAUSA] != 0 ) sprintf( frase, "PAUSA" ); textout( bmp, font, frase, 256 - 8*strlen(frase) ,altura, 255 ); altura+=ESPACIO;

La variable altura controla que cada mensaje se escriba sin mezclarse con el anterior.


132

dibuja_pantalla Esta función coordina el dibujado de la pantalla en cuatro pasos: fondo gráfico, objetos, caracteres y paleta. Cuando la rutina termina la pantalla está lista para ser copiada al circuito gráfico y mostrada en el monitor; este paso se realiza fuera de esta rutina, en la función main. void dibuja_pantalla( char *ant_munecos) sx = ram[0x3b08] + ( (ram[0x3b09]&1) <<8); sy = ram[0x3b0a] + ( (ram[0x3b0b]&1) <<8); dibuja_fondo(); Munecos_Color( ant_munecos ); Caracteres_Color( ram ) if ( vsinc ) vsync(); if ( paleta_verdadera ) Paleta(); else PaletaR();

Obtiene las variables de desplace a partir de los registros de la máquina Dibuja el fondo, sobre él los objetos (muñecos) y sobre todos, los caracteres. Espera el retrazado y actualiza la paleta

Código de dibuja_pantalla Existen dos formas de calcular la paleta gráfica del PC a partir de la original. Cada color primario puede tener dieciséis niveles (del 0 al 15) o equivalentemente, cada color está codificado en un cuarteto. Para pasar el color a PC es necesario que ocupe seis dígitos (64 niveles). La función PaletaR (R de rápida) realiza la conversión multiplicando por cuatro el color original desplazando dos dígitos a la izquierda. Esta operación es muy rápida pero tiene el inconveniente de que los resultados son inexactos; por ejemplo el color de máxima intensidad originalmente es el 1111b, tras la conversión éste queda como 111100b que en decimal equivale a 60, un 6’66% menor de lo que debería ser (111111b ó 64). Así todos los colores presentan un pequeño error que sólo puede corregirse escalando el valor adecuadamente: multiplicando por 63 y dividiendo el resultado por 15. Como esta operación es más lenta y el objetivo del emulador era la rapidez se dejó como una opción: el jugador puede elegir qué paleta ver pulsando la tecla espacio. Alternando la paleta durante el juego se puede apreciar la diferencia que es más notable en cuanto a luminancia que en cuanto a crominancia.

Fondo y dibuja_fondo Esta pareja de funciones son las responsables de construir el fondo virtual (Fondo) y de copiar la ventana activa a la pantalla (dibuja_fondo). No vamos a detallar el código de Fondo, pues es demasiado extenso, pero sí vamos a hacer notar su principal optimización. Dado que Fondo ha de construir la imagen virtual formando un mosaico con los bloques de 8x8 que componen los gráficos de la máquina; puede comprobar rápidamente, sin más que comparar el código del bloque ya pintado con el código que la máquina pide en el nuevo fotograma, si ese cuadrado ha cambiado desde la última vez que se pintó. Si no hubiese cambiado no es necesario volver a pintarlo y por lo tanto se ahorra la operación de copiar 64 octetos. En la práctica, la máquina sólo renueva el fondo virtual totalmente al cambiar de nivel; durante el juego el fondo se actualiza muy lentamente y se emplean las variables de desplace para pintar únicamente el área visible que está lista.


133

La función dibuja_fondo ha de copiar una ventana desde el fondo virtual a la pantalla en construcción. Se dan varios casos posibles según el valor de los desplaces, pero el más genérico es aquel en que la imagen ha tenido que formarse a partir de cuatro esquinas del fondo virtual. El código en ese caso es: blit( fondo_virtual,bmp, sx,sy+16,0,16, 512-sx, 512-sy ); blit( fondo_virtual,bmp, 0,sy+16, 512-sx,16, sx-256 ,512-sy ); blit( fondo_virtual,bmp, 0,0, 512-sx,512-sy, sx-256 ,256-512+sy-16 ); blit( fondo_virtual,bmp, sx,0, 0,512-sy, 512-sx ,256-512-16+sy );

sup. izq. sup. der. inf. der. inf. izq.

Código de ejemplo de dibuja_fondo La función blit pertenece a la biblioteca gráfica Allegro y sirve para copiar rectángulos entre imágenes. Esta vez no hemos optado por optimizar la copia. Es posible, una vez más, controlar qué partes de la imagen destino han cambiado desde la última vez y omitirlas del proceso; sin embargo, este caso es bastante más complicado que el anterior:

• El fondo, aun siendo el mismo, ha sido emborronado por los personajes que se mueven sobre él, luego los bloques afectados deberían ser copiados otra vez.

• Cuando la pantalla se desplaza los bloques, pese a ser los mismos, ya no ocupan la misma posición, así que hay que volver a pintarlos.

Si quisiéramos optimizar la copia habría que resolver estos dos problemas. El primero es sencillo y su solución se basa en tener una matriz que indica que bloques han sido afectados por los objetos o caracteres. El segundo problema es más complicado aunque la solución es muy elegante: en las tarjetas gráficas VGA puede reproducirse el mismo esquema de “gran pantalla virtual” y ventana visible. Habría que utilizar toda la memoria gráfica de una VGA convencional (1Moct) para dibujar ahí todo el fondo virtual, luego puede escogerse qué región visualizar a través de unos registros internos de la VGA. Se trata pues, de repetir el enfoque de la máquina original. Esta programación es más complicada que la actual aunque es la que ofrece el mejor rendimiento. No se llegó a realizar porque la velocidad alcanzada por el emulador era ya suficiente.


134

Resumen de las funciones Se presentan a continuación las funciones escritas en lenguaje C y que forman parte del flujo normal del programa. El piélago de rutinas en ensamblador que constituyen la emulación del procesador no se detalla aquí, puesto que su orden de llamada depende de la máquina en sí. Pueden consultarse, de todas formas, en el apartado sobre emulación del procesador.

Nombre Fichero Descripción carga gng_dir.c restaura la memoria RAM para continuar una partida antigua carga_rom gng.c carga en memoria todos los ficheros ROM

cmdline gng_dir.c analiza el contenido de la línea de órdenes

decodifica_graficos gng_dir.c transforma el formato de almacenamiento de los gráficos en uno apropiado para el emulador

despedida gng.c imprime unas líneas al terminar el programa

destruye_sonidos gng.c libera la memoria empleada en los sonidos

dibuja_fondo gng_dir.c según las variables de desplace, copia una ventana desde el fondo virtual al real

dibuja_pantalla gng.c interpreta la memoria gráfica de la máquina para dibujar la pantalla.Sincronización con el trazado vertical

ilegalC 6809c.c se encontró una operación del 6809 ilegal

imprime_error gng.c rutina de gestión centralizada de errores

irq 6809c.c dispara una interrupción libera_rom gng.c libera la memoria empleada en los ficheros ROM

main gng.c arranque del emulador, contiene el bucle de emulación

mensaje gng.c imprime un mensaje usando la circuitería gráfica de la máquina

muestra_mensajes gng.c imprime mensajes sobre la pantalla del videojuego

prepara_memoria gng_dir.c valores iniciales del 6809 para que arranque adecuadamente prepara_sonido gng.c lee los ficheros .wav utilizados para simular el sonido

presentación gng.c imprime unas líneas al arrancar el programa

salva gng_dir.c salva la memoria RAM del juego para poder continuar la partida más tardeteclado gng.c lee el teclado e informa a la máquina

temporizador gng.c ejecutada a 60Hz, aumenta contadores relacionados con el sincronismo

toca_sonidos gng.c reproduce los sonidos

vuelca_regs 6809c.c muestra el contenido de los registros


135

Diamond Run y Makaimura Cuando el emulador de Ghosts & Goblins estaba casi terminado apareció en la interné el volcado de las memorias de otro juego, Diamond Run, que funcionaba en la misma máquina que G&G, sin más que sustituir unas EPROM por otras. En el código del emulador sólo hubo que añadir una opción para cargar unos ficheros en vez de otros y hacer que los punteros de las páginas apuntasen a otras posiciones. Al mismo tiempo se añadió soporte para la versión japonesa de G&G cuya única diferencia es, aparentemente, la portada del juego donde en vez de decir Ghosts&Goblins (Fantasmas

y duendes) dice , que se lee ma-kai-mura. Esta palabra esta compuesta por tres ideogramas: el primero significa “maldad mágica”, el segundo “límite” y el tercero “pueblo”. La combinación de los dos primeros significa “infierno”, luego el título del juego en la versión japonesa es pueblo del infierno. if ( juego != DIAMOND ) if (juego == GNG_USA) ram[0x607a] = ram[0x607b] = ram[0x607c] = 0x12; /*nop se salta las comprobaciones del arranque*/ paginas[0]=rom[4]; paginas[1]=rom[4]+8*1024; paginas[2]=rom[4]+8*1024*2; paginas[3]=rom[4]+8*1024*3; paginas[4]=rom[3]; else /* páginas de diamond Run */ paginas[0]=rom[4]+0x4000; paginas[1]=rom[11]; paginas[2]=rom[11] + 2*0x4000; paginas[3]=rom[11] + 3*0x4000; paginas[4]=rom[11] + 4*0x4000; El truco para saltarse el arranque sólo se aplica en el juego G&G norteamericano porque en los otros el código es ligeramente distinto y habría que buscar la posición de memoria que modificar.

Portada de DR Juego (DR) Makaimura


136

Grytra , emulador de Gryzor y Contra Tras terminar mapefer3 el “bachillerato” de emulación había sido superado y llegaba el momento de hacer un emulador desde cero, realizando toda la investigación e ingeniería inversa por uno mismo. A través de una página de internet localizada en Australia dimos con un volcado de una placa pirata de Gryzor, tras copiar el fichero al ordenador; comenzó la investigación que desembocó en el primer emulador mundial de Gryzor.

Plataforma de desarrollo Dado que este emulador se escribió poco tiempo después de acabar mapefer3, la plataforma escogida fue la misma: el compilador gcc, el entorno Rhide y la biblioteca gráfica Allegro. A ello se unía el ya veterano emulador del 6809 programado para mapefer3. En esta ocasión no había ningún dato sobre el funcionamiento del equipo así que hubo que investigarlo todo. Eso convirtió al emulador en un diseño mixto: analizador y emulador, a la vez que favoreció el desarrollo pero dio lugar a un programa lento e ineficiente para jugar, al contrario que mapefer3 que era rapidísimo.

Explicación del código fuente Grytra está basado en el código de mapefer3 y utiliza el mismo emulador para el procesador. Los diagramas de flujo son idénticos a los ya mostrados y no se repetirán. La única diferencia es que Grytra incluye mucho código adicional para ayudar al desarrollo y depuración del emulador, puesto que éste se programó conforme se iba descubriendo el funcionamiento de la máquina mediante ingeniería inversa. A continuación detallaremos algunas de las funciones usadas durante la investigación, mostrando fragmentos de su código y explicando su finalidad y funcionamiento. Las funciones que cumplen el mismo propósito en ambos emuladores –como la de dibujado de objetos- se omiten en esta explicación, aunque obviamente éstas difieren entre los dos programas, puesto que emulan circuitería diferente. El código de Grytra utiliza compilación condicional; es decir, hay unas macros que seleccionan qué partes del programa se compilarán y enlazarán, éstas son:

• MAPA: Esta versión de Grytra genera un mapa de memoria indicando dónde ha habido lecturas y escrituras. Sirve para localizar puertos de E/S ya que si en una posición de memoria sólo ha habido lecturas o sólo ha habido escrituras ha de tratarse de una región especial. Por ejemplo, de las palancas sólo hay lecturas y del registro de sonido sólo hay escrituras

• DEPURA: Si está habilitada, esta compilación ejecuta el juego en 320x240 para poder mostrar un volcado de la memoria RAM mientras funciona la emulación.

• MUESTRA_SI: Se superpone una línea en la pantalla con el valor de las variables usadas durante la depuración (SI, N y N2)


137

vuelca_ram Dadas las características gráficas de Gryzor, puede utilizarse el modo gráfico de 320x240 para mostrar en un cuadrado de 240x240 el juego a la izquierda y utilizar el rectángulo derecho de 80x240 para mostrar información de depuración, etc. La presente función utiliza ese rectángulo para hacer un volcado hexadecimal de la memoria virtual del 6809. La dirección inicial dependerá del valor de la variable global n, utilizada de forma genérica en todas las rutinas de investigación. Esta variable se modifica utilizando las teclas + y – del teclado numérico mientras se pulsa ALT. El volcado de la memoria virtual es importante porque permite encontrar los registros de E/S del sistema. Así por ejemplo, cuando el desplace de los fondos todavía no estaba programado se pudo encontrar la posición de los registros de desplace gracias a la observación de las escrituras en la memoria de vídeo y las posiciones de memoria que variaban solidariamente. void vuelca_ram() int c1,c2; char frase[255]; int c; c=n; for( c1 = 0; c1 < (SCREEN_H-24)/16; c1++ ) sprintf( frase, "%4X ",c1*16+c ); textout( screen, font, frase, 280, c1*8+24, 255 ); for( c2 = 0; c2 < 0x10; c2++ ) sprintf( frase, "%2X ", ram[c+c1*16+c2]); textout( screen, font, frase, 280+c2*8*3+8*6, c1*8+24, 255 );

muestra_mapa Esta función imprime el vector mapa, que contiene la información sobre las posiciones de memoria que han sido accedidas durante la emulación y sobre el modo del acceso: lectura, escritura o ambas.

salva y carga Estas funciones, también disponibles en mapefer3, vuelcan la memoria virtual a un fichero binario y viceversa. Sirven para almacenar el estado del juego y poder así continuar la partida más tarde.

muestra_muñecos Durante la investigación es preciso descifrar el formato de la memoria de objetos. Esta función vuelca esa memoria para poder evaluarla en un momento dado o ver cómo se modifica durante el transcurso del juego.


138

Escuela de combate, emulador de Combat School Cuando se programó Escuela de combate, los emuladores comenzaban a ser realmente populares y estaban ya disponibles muchos de los juegos de 8 dígitos; sin embargo, aun había lagunas importantes y la emulación de un título tan emblemático de los años 80 como Combat School todavía no había sido acometida. En este emulador colaboraron Cesáreo Gutiérrez y sobre todo Manuel Abadia, ambos estudiantes de la Universidad de Murcia.

Plataforma de desarrollo Para aumentar el interés en la programación se decidió utilizar Microsoft Visual C++ 5.0 comprando una licencia de estudiante por unos 100 euros, dando así el salto a Windows. Esto tuvo grandes repercusiones:

• el antiguo emulador del 6809 dejaba de ser útil, puesto que era difícil ensamblarlo para Win32, se aprovechó para la ocasión un módulo preensamblado llamado A6809.obj y desarrollado por Larry Bank para simular el procesador.

• la biblioteca gráfica usada anteriormente: Allegro, no funcionaba con Windows así que tuvimos que utilizar las aun imberbes DirectX para toda la gestión gráfica. Esto añadía una nueva dificultad, ya que el modelo de programación de DirectX basado en COM47, no nos era familiar en absoluto.

• el mero hecho de programar para Windows hizo sencillo dotar al programa de una interfaz de usuario más amigable, por lo que se invirtió más tiempo en ella que anteriormente.

Visual C++ con el proyecto Escuela de combate

47 COM es una tecnología de Microsoft basada en dotar a los programas de interfaces a través de las cuales se puedan comunicar entre sí. COM es la base de, por ejemplo, los objetos ActiveX, la tecnología OLE, de DirectX y del acceso a datos OLEdB.


139

Al programar en C/C++ para Windows existen dos caminos posibles: las ya comentadas MFC y la API48, se optó por la segunda dada la mayor flexibilidad y velocidad de ésta. Paralelamente al emulador se desarrolló el Analizador, como la prioridad ahí era el desarrollo rápido y no la celeridad de ejecución del ulterior proceso; se prefirieron las MFC.

Explicación del código fuente En esta sección comentaremos brevemente las funciones básicas del emulador.

WinMain Esta función es el punto de entrada de todo programa para el sistema Windows. En ella se realizan dos labores diferenciadas: el proceso de mensajes mediante el acostumbrado bucle y el arranque y apagado de la emulación en sí. while ( GetMessage( &msg, NULL, 0,0 ) ) TranslateMessage( &msg ); /* Se permite el uso del teclado */ DispatchMessage( &msg ); /* devuelve el control a Windows */

Bucle de mensajes if ( Arranca() != 0 ) MessageBox( NULL,"No se encuentran las ROM 1-4","Error fatal",MB_ICONEXCLAMATION | IDOK ); return 0; if ( ArrancaGraficos() != 0 ) MessageBox( NULL,"No se encuentran las ROM 5-20","Error fatal",MB_ICONEXCLAMATION | IDOK ); return 0;

Arranque del equipo emulado Durante el arranque es preciso leer las memorias ROM, proceso que naturalmente puede fallar y cuyo error causa el fin del programa. Estas funciones serán explicadas posteriormente.

Apaga(); ApagaGraficos();

Apagado del equipo Apagar el equipo es realmente liberar la memoria reservada y detener la hebra que procesa la emulación del procesador.

48 Interfaz para el Programador de Aplicaciones. Son las llamadas al sistema de bajo nivel que proveé Windows


140

Arranca El objetivo de esta función es preparar el procesador virtual. Arranca() int iError; Carga las cuatro ROM de procesadores pROM[0] = CargaROM( "roms\\combat.001"); pROM[1] = CargaROM( "roms\\combat.002"); pROM[2] = CargaROM( "roms\\combat.003"); pROM[3] = CargaROM( "roms\\combat.004"); Prepara el mapa de memoria if ( pROM[0] && pROM[1] && pROM[2] && pROM[3] ) int i; pMem6809 = malloc( 64*1024*3 ); /* prepara la memoria del 6809 */ Los circuitos gráficos tienen su propia memoria pVideo0 = malloc( 0x4000 ); pVideo1 = malloc( 0x4000 ); El mapa del procesador hay que especificarlo como aquí se indica, la explicación de este procedimiento se encuentra en la sección del 6809. memset( pMem6809+MEM_FLAGS, 0, 64*1024 ); memset( pMem6809+MEM_RAM, 0xff, 64*1024 ); memset( pMem6809+MEM_FLAGS+0x4000, 2, 0x4000 ); // páginas memset( pMem6809+MEM_FLAGS+0x2000, 3, 0x2000 ); // circuitos gráficos pMem6809[ MEM_FLAGS + 0x500 ] = 4; // registro de selecciones memset( pMem6809+MEM_FLAGS+0x8000, 1, 0x8000 ); // ROM memcpy( pMem6809+MEM_ROM+0x8000, pROM[1]+0x8000,0x8000 ); reinicia el procesador: ARESET6809(pMem6809, &regs6809 ); La paginación de memoria se hace a través de unos vectores de punteros. Su valor correcto se carga en los siguientes bucles for(i=0;i<32;i++ ) pPagina[i] = pROM[1]; // para no provocar ningún error for( i=0;i<2;i++) pPagina[0x0+i] = pROM[1]+i*2*0x2000; for( i=0;i<8;i+=2) pPagina[0x10+i] = pROM[2]+i*0x2000; pPagina[0x18+i] = pROM[3]+i*0x2000; pPagina[1][0x6145-0x4000]=0x39; // para evitar la rutina de retardo pPagina[0x1f] = pPagina[0x1]; /* fin */ iError = 0; else iError = 1; return iError;


141

ArrancaGraficos Esta función descodifica el formato de la máquina y prepara el mapa de puntos que utiliza Windows para visualizar imágenes. int ArrancaGraficos() int i; BITMAPINFOHEADER biInfo; Carga las memorias ROM que contienen gráficos pROM[4]=CargaROM("roms\\combat.005"); …/… pROM[19]=CargaROM("roms\\combat.020"); for ( i = 4; i<20; i++ ) if ( !pROM[i] ) return 1; // error prepara el mapa de puntos con la información adecuada memset( &biInfo, 0, sizeof( BITMAPINFOHEADER ) ); biInfo.biSize = sizeof( BITMAPINFOHEADER ); ancho y alto biInfo.biWidth= 256; biInfo.biHeight = -256; biInfo.biPlanes = 1; biInfo.biBitCount = 8; // 256 colores biInfo.biSizeImage = 256*256; biInfo.biClrUsed = 128; La estructura BITMAPINFO se completa de una forma peculiar, que no está bien documentada por Microsoft: pbiInfo = (BITMAPINFO *) malloc (sizeof(BITMAPINFOHEADER) +(128*sizeof(RGBQUAD)) ); pbiInfo->bmiHeader = biInfo; // copiamos la cabecera pPaleta = (RGBQUAD *) ((char *)pbiInfo+sizeof(BITMAPINFOHEADER) ); memset( pPaleta,PC_NOCOLLAPSE,128*sizeof(RGBQUAD) ); Ahora se hacen llamadas a Decodifica que hace lo propio con los gráficos adaptándolos a un formato manejable por el programa. for(i=0;i<4;i++) Decodifica(i); // 0,1 => caracteres del fondo; 2 y 3 =>objetos memset( pPantalla, 0, 256*256 ); // limpia el fondo return 0; // todo bien.

WindowFunc Esta función maneja el flujo del proceso respondiendo a los eventos de Windows, por claridad se omite parte del código para destacar lo importante. Windows 95 llama a esta función que recibe mensajes de la cola de mensajes. LRESULT CALLBACK WindowFunc( HWND hwnd,UINT message, WPARAM wParam, LPARAM lParam ) .../... (declaración de variables locales) Según el mensaje que llegue: switch( message ) case WM_CREATE: cuando se crea la ventana se inicia la hebra que procesa la emulación del procesador.


142

h6809 = CreateThread( NULL,0,Emula6809,(LPVOID)hwnd,0, &Hebra6809 ); .../... El evento hEmula indica si la hebra del procesador ha de esperarse o puede seguir con su labor hEmula = CreateEvent( NULL, FALSE, TRUE, "Emula" ); .../... ConfiguraTeclado( &cfgTeclas ); /* configura la paleta, esto es diferente con DirectX */ /* Promediado de la velocidad */ ips.tiempo0 = timeGetTime(); ips.pintadas=0; break; case WM_PAINT: Aquí se pinta la pantalla cada 16ms, esto se hace en dos pasos: primero en una imagen virtual y luego copiándola al dispositivo gráfico que el usuario puede ver. hdc = BeginPaint( hwnd, &ps ); PintaPantalla(); if ( SetDIBitsToDevice( hdc, 0,0, // coordenadas destino 255, 240, 0,0, // coordenadas origen 16, 240, // inicio y final de las líneas pPantalla, pbiInfo, DIB_RGB_COLORS ) == 0 ) MessageBox( hwnd, "Error al volcar la pantalla","",IDOK ); PostQuitMessage(1); EndPaint( hwnd, &ps ); El proceso de emulación puede continuar con su trabajo ahora: SetEvent(hEmula); .../... break; Pulsaciones del teclado: case WM_KEYUP: ucTecla[wParam ] = 0; /* activa esa tecla */ Teclado(&cfgTeclas,ucTecla); // gestiona las teclas break; case WM_KEYDOWN: ucTecla[ wParam ] = 1; /* activa esa tecla */ Teclado(&cfgTeclas,ucTecla); // gestiona las teclas break; case WM_DESTROY: /* finalización del programa */ PostQuitMessage(0); break; default: /*Se permite a Windows 95 que procese todos los mensajes no especificados en la anterior sentencia "switch". */ return DefWindowProc( hwnd, message, wParam, lParam); return 0;


143

Emula6809 Esta función ejecuta el número preciso de instrucciones del 6809 entre dos imágenes sin que por ello el bucle de mensajes de Windows se interrumpa; para ello, ha de estar en una hebra separada. La sincronización entre ambas se realiza de forma muy sencilla con un evento:

DWORD WINAPI Emula6809(LPVOID hwnd1) RECT Rect= 0,0,256,256 ; HANDLE hSuceso; HWND hwnd; hSuceso = OpenEvent( EVENT_ALL_ACCESS, FALSE, "Emula" ); hwnd = (HWND) hwnd1; do WaitForSingleObject( hSuceso, INFINITE ); CalculaImagen(); InvalidateRect( hwnd, &Rect, FALSE ); while(1); return 0;

Teclado

El teclado es configurable a través de la estructura STeclas. El código de la tecla leída por Windows se compara con los valores de dicha estructura y la cifra adecuada de la memoria del 6809 se cambia consecuentemente. Para hacer más legible el código se ha utilizado una macro. void Teclado(struct STeclas *sTeclas, unsigned char ucTeclas[256]) static unsigned char uc4400=0xff, uc4401=0xff, uc4402=0xff, uc4403=0xff; #define TECLA( a,b,c ) if( ucTeclas[a] ) b &= ~c; else b |= c; // Echar monedas TECLA( sTeclas->ucMoneda1, uc4400, 8 ); TECLA( sTeclas->ucMoneda2, uc4400, 0x10 ); // Comenzar la partida TECLA( sTeclas->uc1P, uc4400, 4 ); TECLA( sTeclas->uc2P, uc4400, 0x80 ); // controles del primer jugador TECLA( sTeclas->arriba[0], uc4401, 0x80 ); TECLA( sTeclas->abajo[0] , uc4401, 0x40 ); TECLA( sTeclas->izquierda[0], uc4401, 0x20 ); TECLA( sTeclas->derecha[0], uc4401, 0x10 ); TECLA( sTeclas->saltar[0], uc4400, 0x2 ); TECLA( sTeclas->correr[0], uc4400, 0x1 ); // controles del segundo jugador TECLA( sTeclas->arriba[1], uc4401, 0x8 ); TECLA( sTeclas->abajo[1] , uc4401, 0x4 ); TECLA( sTeclas->izquierda[1], uc4401, 0x2 ); TECLA( sTeclas->derecha[1], uc4401, 0x1 ); TECLA( sTeclas->saltar[1], uc4400, 0x40 ); TECLA( sTeclas->correr[1], uc4400, 0x20 ); ucPuerto[0] = uc4400; // asigna el valor ucPuerto[1] = uc4401; ucPuerto[2] = uc4402; ucPuerto[3] = uc4403;


144

Conclusión e investigaciones ulteriores En este proyecto se ha expuesto el funcionamiento de los sistemas de máquinas recreativas y se han desarrollado, con éxito, tres emuladores diferentes de otros tantos sistemas, consiguiéndose resultados plenamente fidedignos a las máquinas originales; que se detallan en la siguiente tabla:

Velocidad (%) Emulador Juego 486DX

100MHz PentiumIII600 MHz

Fidelidad de los

colores

Fondos gráficos

Objetos gráficos

Dispositivosde entrada

Mapefer3 Ghosts&Goblins 100 100 Perfecta

Falta la prioridad

de fondos sobre

objetos

Perfectos

Todos, el usuario

puede elegir la

configuraciónde los DIP

Grytra Gryzor/Contra 60 100 Faltan

algunos parpadeos

Perfectos Perfectos

Palancas bien, sólo son configurables algunos DIP

Escuela de

combate Combat School 100 100

Faltan algunos

parpadeosPerfectos

Las regiones

límites de la pantalla

son mejorables

Palancas bien, sólo son configurables algunos DIP

En cuanto al primer objetivo del proyecto: la documentación; ésta se ha elaborado cubriendo en diversos capítulos: los componentes del sistema, el funcionamiento electrónico de la placa y del circuito sonoro, la descripción del comportamiento de los circuitos gráficos. Se han incluido además extractos de esquemas reales de máquinas recreativas explicando la interconexión de los elementos tanto con dichos esquemas como con diagramas de bloques. El único apartado abandonado ha sido el sonido, pese a que se ha explicado cual sería el enfoque a seguir, no se llegó a desarrollar un emulador del circuito sonoro. En la actualidad esta opción está ya muy investigada y hay códigos fuente de simuladores de sonido disponibles públicamente. En caso de querer incluir el sonido, habría que añadir también la emulación de un segundo procesador; esto complicaría un poco el bucle de la emulación, pero esencialmente seguiría igual. Un campo más interesante es el de las máquinas tridimensionales. Estos equipos tienen una circuitería gráfica basada no en dibujar mosaicos sino triángulos; su funcionamiento es, por lo tanto, muy diferente y presenta además el resto de tratar de emularlos utilizando los recursos que ofrecen las tarjetas aceleradoras 3D de los ordenadores convencionales. Otra área interesante es la recompilación, siendo ésta posible de dos formas: estática y dinámica. Recompilar es el proceso por el que se obtiene código nativo de una


145

máquina a partir del código máquina de otra; para ello es necesario analizar y traducir el programa. Esto proceso necesita un programa especial al efecto: el recompilador. Cada juego tiene una E/S distinta y un circuito gráfico diferente, por lo que estos efectos también han de ser tenidos en cuenta. Si la recompilación es estática ha de recorrerse el programa incluyendo todas las posibles bifurcaciones condicionales y saltos por interrupción; al mismo tiempo se traducen las instrucciones con especial atención a las posiciones de memoria. Finalmente se añade el código de emulación de la circuitería gráfica, sonora y de la E/S y se obtiene un nuevo ejecutable que contiene el juego traducido a la nueva plataforma. La recompilación dinámica es más flexible y pretende convertir en tiempo real las instrucciones primitivas a las del nuevo procesador y ejecutarlas en él de forma nativa. Hace falta tener también un cuidado especial con las direcciones de memoria. Las variables a manejar durante la recompilación dinámica son muchas, puesto que si la operación se hace instrucción a instrucción resulta demasiado lenta y si se hace de largos bloques es difícil mantener la sincronización. Las máquinas virtuales de Java utilizan esta arquitectura hoy en día. La emulación permite rescatar programas antiguos, lúdicos o productivos para su uso en las máquinas modernas. Pese a que es difícil saber si la recreación es plenamente fidedigna al original es posible adoptar soluciones intermedias, que cumplan hasta lo necesario haciendo viable el aprovechamiento de la inmensa cantidad de programas existentes para las plataformas ya desaparecidas.


146

Bibliografía Videogames on Alternative Monitors FAQ, Jonathan Dawes, [email protected] Devastators, Instruction Manual, Konami, 1988 Contra, Instruction Manual, Konami, 1987 YM2151 FM Operator Type-M, Yamaha Corporation, 1991 YM3012 2-Channel Serial Input Floating D/A Converter, Yamaha Corporation, 1992 YM3014B Serial Input Floating D/A Converter, Yamaha Corporation, 1994 Ms Pacman Parts and Operating Manual, Midways/Namco, 1982 Arcade Emulation How-To, Michael Adcock, [email protected]




147

Y|Ç|á vÉÜÉÇtà ÉÑâá

Este documento fue editado durante el verano de 2002, en Límeri (Irlanda) y

se remató en diciembre del mismo año en Valencia (España)

De La Emulación de Las Máquinas Recreativas - JOSÉ TEJADA GÓMEZ - (147Págs)

Documents

Transcript of De La Emulación de Las Máquinas Recreativas - JOSÉ TEJADA GÓMEZ - (147Págs)