Lo interesante de este documento es que nos lleva de la mano a través del desarrollo de un Bomb Jack para MSX usando la librería FUSION-C empezando desde cero y explicando todos los aspectos involucrados en el proyecto, desde la planificación del trabajo, la instalación de los programas auxiliares necesarios y el análisis de los resultados.

Sin duda, este tutorial hace honor a su nombre pues creo que es un estupendo trabajo que puede servir para aprender sobre cómo funciona un MSX y cómo se puede programar usando un lenguaje de alto nivel.

Enlace relacionado: Repositorio institucional de la UPV

En esta parte del tutorial vamos a retomar el código de la 6ª entrega y añadiremos una rutina y unas
modificaciones para que veáis como se puede paliar un poco la regla del 5º sprite.

Lógicamente hemos de procurar al realizar un juego no situar más de 5 sprites en la misma línea, pero
si esto se produce de manera momentánea con 5 o más sprites con una rutina de Flickering (parpadeo)
lograremos que se vea un ligero parpadeo en los sprites, pero evitaremos que dejen de verse éstos.

Después de ocho años de espera y después de preguntarnos si Pepe Vila continuaría su tutorial sobre programación en ensamblador, llega hasta nosotros la séptima entrega. Espero que todos aquellos que la estábais esperando desde hace mucho tiempo lo disfrutéis mucho.

Aprovecharé en estos días para unir en un solo PDF todos los capítulos y subirlos al servidor. Mientras tanto, podéis descargar esta séptima entrega desde la propia web de Pepe.

Enlace relacionado: Dimension Z

¡Ya no tenemos disculpa para tener los cartuchos de nuestra colección sueltos!

Interesante tutorial y bastante sencillo de seguir para conseguir que un pad de Nintendo NES funcione en nuestros MSX cambiando la distribución de los pines. El artículo es obra de Pypo y fue publicado en la web de La SeKTa. Yo lo he pasado a PDF para una lectura más cómoda.

Tenía pendiente traducir al español ese fantástico tutorial y el otro día me puse después de tanto tiempo «en la recámara».

Aquí queda para quien le pueda servir.

Tutorial de iniciación al 1chipMSX

]]> https://www.msxblog.es/tutorial-de-iniciacion-al-one-chip-msx/feed/ 4 https://www.msxblog.es/tutorial-de-megaflasrom-sccsd-en-msx-mania/ https://www.msxblog.es/tutorial-de-megaflasrom-sccsd-en-msx-mania/#respond Sun, 21 Sep 2014 23:07:02 +0000 http://www.msxblog.es/?p=20048

MSX Mania ha publicado un interesante artículo sobre cómo sacarle partido al fantástico hardware MegaFlashROM SCC+ SD de Manuel Pazos. El tutorial viene acompañado de tres vídeos y está recomentado para los que aún no se han decidido a comprarlo o aquellos que lo han adquirido recientemente.

Enlace relacionado: MSX Mania

Iniciación a la programación en ensamblador (Pepe Vila)

El tutorial está orientado hacia los más novatos ya que explica qué es el SCC y cómo funciona para posteriormente centrarse en el manejo del programa. Visto por mí, un auténtico lego en la materia, creo que este tutorial de Gryzor87 puede ser el empujón definitivo para experimentar con el sonido polifónico del potente chip de Konami.

Además, ayer también se lanzó la versión 0.8.0 del programa.

Yes we can with TriloTracker!

Enlace relacionado: Gryzor87.

http://www.msxpro.com/disquete_de_limpeza.html

Un tutorial sobre el formato BCD

En este documento se da por supuesto que el lector entiende bien el funcionamiento de los números decimales (base 10), binarios (base 2) y su representación en forma hexadecimal (base 16).

Los números son siempre almacenados en formato binario dentro de la memoria del ordenador, cuyos bits sólo pueden estar en dos estados eléctricos, alto o encendido, que equivaldría a uno, y bajo o apagado, que equivaldría a cero. El problema es que la notación binaria no es la más conveniente para los seres humanos, y que su conversión a notación decimal requiere operaciones largas y complicadas desde el punto de vista de su implementación en ensamblador, como pueden ser la división o el operador módulo.

Por ejemplo, para convertir 11111111b, es decir, FFh o 255 en decimal, habría que tomar el número original, dividirlo entre 100 (decimal) y almacenar el dígito de las centenas, dividir el resto entre 10 y almacenar el cociente como dígito de las decenas, y tomar el último resto como dígito para las unidades. Esto envuelve dos divisiones, y estamos en un caso relativamente sencillo, en el que el data original sólo ocupa un byte (8 bits).

Estas dificultades hacen que resulte más conveniente emplear lo que se ha dado en llamar números en formato BCD, binary coded decimals. El concepto subyacente es bastante sencillo: representar cada dígito decimal en cuatro bits (un nibble), de forma que así, en cada byte, se pueden guardar dos dígitos decimales. Este formato en concreto, en el que se almacenan dos dígitos por byte, se llama packed BCD. Culturilla general, hay que llamar a las cosas por su nombre. La ventaja de este formato es que el valor del byte se escribe utilizando los números decimales e indicando que es un valor hexadecimal. Es decir, para almacenar el número 27 en BCD en una posición de memoria, lo que haríamos sería poner en esa posición el valor 27h (la “h”, como no, indica formato hexadecimal). Esto es así porque cada dígito en hexadecimal representa un nibble. Vamos bien: para indicar ahora un número decimal en formato BCD empaquetado basta con escribirlo en formato decimal y añadir la “h” que indica formato hexadecimal.

Ahora los más listos dirán que esto es desaprovechar espacio, y así es. Estamos gastando espacio para ganar velocidad. Como se puede averiguar muy fácilmente, con cuatro bits es posible representar valores entre 0 y 15, así que nos sobran 6 valores en total, porque sólo representaremos valores entre 0 y 9. Parece ahora que es bastante complicado manejar todo esto, pero en realidad no, porque el procesador Z80 tiene una instrucción, y sólo una, para manejar los números BCD, pero es bastante potente.

Veamos un ejemplo a mano. Así podremos identificar los problemas.

Queremos calcular 23 + 45, expresando tanto los sumandos como la suma en BCD. A ver qué sucede:

23 + 45 = 68, haciendo el cálculo en decimal no hay problemas. Ahora hagamos la operación en hexadecimal: 23h + 45h = 68h . De nuevo, en formato BCD, no hay problemas.

¿Y si los sumandos fueran, por ejemplo, 17 y 26? Ahora sí que va a haber alguna pega. 17 + 26 = 43. Por supuesto, la aritmética decimal no nos engaña. En hexadecimal, empleando la notación BCD vista, ¿qué pasa?

17h + 26h = 3Dh . Mal asunto. La D no es un dígito decimal demasiado habitual que digamos. Necesitamos corregir la operación. Esto sería algo muy tedioso para hacer a mano, pero el comando DAA del Z80 lo hace por nosotros.

Vamos a ver un poco de código:

ld a,17h

add 26h ; asi tenemos en el registro A el valor 3Dh calculado arriba.

daa ; tras ejecutar este comando, el valor en A pasa a ser 43h. Correcto!

¿Cómo funciona la instrucción DAA? Pues bueno, emplea un bit especial del registro F (flags o banderas, es decir, el registro de estado del Z80) que recoge el bit de acarreo entre los nibbles, así que puede usarlo para corregir los resultados de las operaciones.

Antes de seguir, una nota importante: la instrucción DAA funciona bien después de ejecutar instrucciones aritméticas del tipo ADD, ADC, SUB, SBC de 8 bits. Ni se os ocurra usarla después de instrucciones del tipo INC o DEC, porque entonces el comando DAA no funciona en absoluto. Cuidadin, muchachos. Tampoco sería una buena idea usar DAA después de operaciones de 16 bits, porque el resultado puede ser cualquier cosa menos correcto.

Ahora, si me habéis seguido hasta aquí, estaréis pensando, ¿y de qué me sirve poder utilizar sólo dos dígitos decimales? Pues tenéis toda la razón del mundo, pero es que el bit de acareo (carry) funciona bien. Es decir, para sumar los números 2358 y 750 haríais lo siguiente:

; Guardamos los valores en los registros de 16 bits BC y DE ld bc,2358h

ld de,0750h ; Sumamos el byte bajo

ld a,c

add e ; Corregimos con DAA y almacenamos en L

daa

ld l,a ; Sumamos el byte alto – usamos aquí ADC, que usa el acarreo anterior

ld a,b

adc d ; Corregimos y almacenamos en H

daa

ld h,a ; El valor final, que debería ser 3108h, estará almacenado en el registro HL

Bien. Ahora se puede ver que se pueden hacer sumas y operaciones con múltiples bytes, representando muchos dígitos, de una forma fácil y, lo que es más importante, exacta.

Entonces, si habéis entendido todo esto, hay que ver para qué pueden servir estos metafísicos números en formato BCD. Desde luego, no sirven para guardar las coordenadas de pantalla, ni para hacer búsquedas en tablas, ni nada parecido. Es decir, son números incómodos para operar con ellos, pero, sin embargo, muy prácticos a la hora de presentar información numérica para humanos. Así, en el ámbito de los video- juegos, los números en formato BCD se suelen emplear para puntuaciones y marcadores. A continuación voy a transcribir unas cuantas rutinas muy prácticas, aunque no especialmente optimizadas, para realizar estos menesteres.

BCD2CHR: ; Esta rutina convierte un byte en BCD a dos bytes en ASCII ; Entrada: A=byte en BCD ; HL=posición en la que almacenar el resultado ; Almacena byte

ld c,a ; Mueve el nibble alto al nibble bajo

srl a srl a srl a srl a

; Convierte en ASCII add 48

; Almacena ld [hl],a

inc hl ; Recupera byte ld a,c

; Obtiene el nibble bajo and 0Fh

add 48 ; Almacena

ld [hl],a inc hl ret

BCD2TXT: ; Rutina que complementa la anterior y convierte números BCD de extensión

variable ; Entrada: ; ; ; Bucle de @@BUCLE:

B=numero de bytes a tratar DE=dirección del último byte del número BCD HL=dirección de inicio de la cadena de texto a crear

copia

ld a,[de] dec de call BCD2CHR djnz @@BUCLE

; Termina ret

Para utilizar esta última rutina debe tenerse en cuenta que el número BCD se almacena en memoria guardando primero los bytes menos significativos. Como ejemplo, si queremos almacenar a partir de la posición 9000h el valor 245349 en BCD, el contenido de memoria quedaría así:

9000h: 49h

9001h: 53h

9002h: 24h

Con las rutinas anteriores, podríamos hacer lo siguiente:

; Convertir de BCD a ASCII ld hl,9800h ld de,9002h

ld b,3

call BCD2TXT ; Imprimir el texto

ld de,NAMTBL ld hl,9800h ld bc,6 call LDIRVM

Esto debería ser suficiente para dejar claro el funcionamiento de los números en BCD. Su uso, aunque limitado, permite representar valores decimales de una forma rápida y precisa, con el tamaño que se requiera, y sin implicar operaciones aritméticas complejas. Por último, voy a incluir una rutina de suma de un valor BCD de 8 bits a otro valor BCD de extension variable.

; SUMABCD:

; Suma un valor BCD a un número BCD de varios bytes

; Entrada:

A=valor BCD a sumar

B=número de bytes usados en el valor BCD (mínimo 2 bytes, 4 dígitos)

HL=dirección de inicio del número en BCD

; Corrige el contador

 dec b

; Suma del primer byte

add [hl]

daa

ld [hl],a

inc hl

; Bucle de suma

@@BUCLE:

ld a,[hl]

adc 0

daa ld [hl],a

inc hl

djnz @@BUCLE

; Finaliza

ret

Y creo que con esto tenéis todo lo que necesitáis para crear vuestros marcadores de puntos y récords en cualquier tipo de video-juego. Otro de los trucos que conviene tener en cuenta es que en la mayoría de los juegos, la última cifra es siempre un cero, con lo que se emplean contadores de 7 cifras, en la que la última es siempre 0, por lo que basta con emplear 6 dígitos BCD, que pueden almacenarse en sólo 3 bytes. Otras aplicaciones se os pueden ocurrir, y el código presentado sólo es un ejemplo, no pretende ser óptimo ni universal. Es una base para que empecéis a trabajar e investigar por vuestra cuenta las posibilidades del formato BCD y de la versátil instrucción DAA.

© Eduardo Robsy Petrus, 2005

9 de Febrero de 2005

http://www.robsy.net

Enlace relacionado: [download id=»321″] (PDF).

Actualización: A continuación tenéis en enlace a la descarga completa del tutorial con todos los capítulos unidos en un solo PDF para una lectura más cómoda. A medida que Pepe publique nuevos capítulos actualizaré el documento.

Iniciación a la programación en ensamblador (Pepe Vila)

Con este capítulo se cierra el apartado dedicado a los gráficos (tercera parte). Se explica la manera de mostrar los gráficos de una manera que emplea menos código y bytes, la que el propio Pepe ha usado en los menús de JumpinG. También se explica cómo importar las imágenes al programa nMSXtiles y posteriormente trabajar con ellas. Si estáis siguiendo el tutorial, este capítulo os será de provecho y seguro que os dejará con ganas de más. Y habrá más, Pepe promete volver pronto con los sprites. Hasta entonces tenemos cosas que «estudiar».

Actualización: A continuación tenéis en enlace a la descarga completa del tutorial con todos los capítulos unidos en un solo PDF para una lectura más cómoda. A medida que Pepe publique nuevos capítulos actualizaré el documento.

Iniciación a la programación en ensamblador (Pepe Vila)

En concreto este cuarto capítulo continúa la labor comenzada en el anterior, los gráficos. Más concretamente dando color a un conjunto de gráficos y creando un logotipo. El tutorial hace referencia a los capítulos anteriores por lo que es recomendable darles un repaso.

Yo ya los tengo todos impresos y los he colocado provisionalmente en una carpeta listos para anillar y de esa manera ser mi obra de consulta y referencia esencial.

Actualización: A continuación tenéis en enlace a la descarga completa del tutorial con todos los capítulos unidos en un solo PDF para una lectura más cómoda. A medida que Pepe publique nuevos capítulos actualizaré el documento.

Iniciación a la programación en ensamblador (Pepe Vila)

En esta última entrega vamos a aprender a programar los distintos movimientos de nuestro personaje.

Hay que tener en cuenta que esta es la parte más compleja del programa, y a su vez la que más va a afectar al rendimiento del ordenador. Se han añadido nuevas rutinas y se han modificado otras para optimizar el funcionamiento del programa.

RUTINA DE CARGA DE LOS GRÁFICOS DE WILLY

Lo primero que hay que hacer es cargar los gráficos del protagonista del juego.

En esta versión he utilizado dos animaciones de Willy de 16×16 pixels para cada dirección.

La rutina comienza en la línea 8000 y acaba en la 8270.

Como en las anteriores cargas de gráficos, leemos los valores de las líneas DATA y las metemos en la VRAM, en la zona reservada a los SPRITES.

En la línea 7090, dentro de la rutina de activar el modo SCREEN 1, hacemos el GOSUB a esta rutina. Solo se ejecuta una vez.

MOVIMIENTO DE WILLY

En un principio empecé a programar el movimiento de Willy con una velocidad de 2 pixels. Esto le proporcionaba un movimiento muy suave, pero al activar las partes del código que controlan si Willy toca algún objeto, el rendimiento cayo totalmente. Así que no he tenido más remedio que hacer que Willy se mueva de 8 en 8 pixels. Explico el porque.

Si Willy se mueve a 8 pixels, en todo momento esta encima, debajo y delante o detrás de 2 gráficos y el código de detección de contacto con el escenario se simplifica.
Si Willy se mueve a 1, 2 ó 4 pixels, cuando su posición es múltiplo de 8 está en contacto con 2 gráficos, pero en el resto de casos Willy está en contacto con 3 gráficos. Esto hace que la detección de contacto se complique y en consecuencia, caiga el rendimiento.

La parte de código que se encarga de mover a Willy se compone de varias subrutinas. Vamos a ver cuales son:

• – Línea 2000: Rutina de control principal.
• – Línea 2100: ¿Caída?
• – Línea 2200: Movimiento a la derecha.
• – Línea 2300: Movimiento a la izquierda.
• – Línea 2400: Control de salto.
• – Línea 2600: ¿Hay pared?
• – Línea 2800: ¿Que toca?

Variables implicadas en el movimiento de Willy

• WX – Posición horizontal de Willy.
• WY – Posición vertical de Willy.
• WS – Si es mayor de 0, Willy está saltando.
• WC – Si es igual a 1, Willy está cayendo.
• WM – Indica en que dirección se está moviendo Willy cuando anda o salta. Hacia la derecha vale 3 y hacia la izquierda 8.
• WD – En condiciones normales está a 0. Contiene un 1 si Willy ha muerto y un 2 si Willy ha de pasar la pantalla.
• WA – Control de la animación de Willy. 16 ó 20 hacia la derecha y 24 ó 28 hacia la izquierda.
• WP – Indica sobre que carácter esta la parte superior izquierda de Willy. Con ella evitamos tenerlo que calcular a cada movimiento.

Funcionamiento de las rutinas

La entrada al control del movimiento empieza en la línea 2000. A esta línea se llega una vez que acaba la rutina que controla a los enemigos, en la línea 1000. Así nos ahorramos un GOSUB.

Rutina de control principal

Aquí controlamos que ha de hacer Willy: saltar, caer, moverse o estar quieto.

• 2000 – Comprueba si Willy está saltando (variable WS). Si salta va a la línea 2400.
• 2010 – Comprueba si Willy está cayendo (variable WC). Si cae va a la línea 2100.
• 2020 – Si se pulsa la barra espaciadora se pone la variable de salto WS a 1.
• 2030 – Guardamos en la variable WM si se ha pulsado la tecla cursora derecha o izquierda.
• 2040 – Si WM es 3 vamos a la rutina que se encarga de mover a Willy a la derecha, en la línea 2200.
• 2050 – Si WM es 7 vamos a la rutina que se encarga de mover a Willy a la izquierda, en la línea 2300.
• 2060 – Volvemos al nudo principal de desarrollo.

¿Caída?

Control que comprueba si hay suelo bajo los pies de Willy, o si ya está cayendo.

• 2100 – Mueve a Willy 8 pixels hacia abajo y actualiza el valor de WP. Esta línea solo se ejecuta cuando Willy ya está cayendo.
• 2110 – Al igual que en la rutina de salto vamos a hacer un barrido de los gráficos que hay bajo los pies de Willy para ver si ha de caer o no. Ponemos WC a 1, VP con el primer carácter a explorar y en M el siguiente.
• 2120 – Inicio de un bucle que se encarga de comprobar que hay bajo los pies de Willy.
• 2130 – En la variable C guardamos el carácter que está tocando Willy. Si no hay nada evitamos ejecutar la rutina de comprobación.
• 2140 – Si hay suelo, desactivamos la rutina de caída poniendo WC a 0.
• 2150 – Comprobamos que estamos pisando.
• 2160 – Final del bucle.
• 2170 – Retorno de la rutina de caída.

Movimiento a la derecha:

Rutina de control del movimiento a la derecha

• 2200 – A partir de la animación del personaje veremos si mira a la derecha. Este valor se almacena en la variable WA.
• 2210 – Si Willy tiene una pared a la derecha no se permite el movimiento. Ponemos la posición del Willy en la variable VP, llamamos a la rutina de 2600 y si al volver WW vale 0 no se permite el movimiento.
• 2220 – Hacemos avanzar a Willy 8 pixels, actualizamos el valor de WP y cambiamos su animación.
• 2230 – Actualizamos la animación del SPRITE con el valor de la variable WA.
• 2240 – Si Willy no está saltando vamos a la rutina de 2110, que comprueba si hay suelo bajo sus pies.
• 2250 – Con este RETURN volvemos al nudo principal de desarrollo.

Movimiento a la izquierda:

Rutina de control del movimiento a la izquierda

• 2300 – A partir de la animación del personaje veremos si mira a la izquierda. Este valor se almacena en la variable WA.
• 2310 – Si Willy tiene una pared a la izquierda no se permite el movimiento. Ponemos la posición del Willy en la variable VP, llamamos a la rutina de 2600 y si al volver WW vale 0 no se permite el movimiento.
• 2320 – Hacemos retroceder a Willy 8 pixels, actualizamos el valor de WP y cambiamos su animación.
• 2330 – Actualizamos la animación del SPRITE con el valor de la variable WA.
• 2340 – Si Willy no está saltando vamos a la rutina de 2110, que comprueba si hay suelo bajo sus pies.
• 2350 – Con este RETURN volvemos al nudo principal de desarrollo.

Control de salto:

Rutina del estado del salto

• 2400 – Si el contador de salto WS es inferior a 4, Willy sube 8 pixels y se actualiza el valor de WP.
• 2410 – Si el contador de salto WS es mayor de 4, Willy baja 8 pixels y se actualiza el valor de WP.
• 2420 – Si el contador de salto WS es inferior a 5, se incrementa en 1. En caso contrario se desactiva el salto.
• 2430 – En la variable VP ponemos la posición en la VRAM del caracter sobre el que está Willy, y en M la siguiente.
• 2440 – Inicio de un bucle que se encarga de comprobar que hay sobre la cabeza de Willy.
• 2450 – En la variable C guardamos el carácter que está tocando Willy. Si es diferente de un espacio vamos saltamos a la línea 2800 donde hay una lista de los objetos a tratar y que hacer en cada caso.
• 2460 – Final del bucle.
• 2470 – Si al saltar estábamos moviendo a Willy a la derecha, salta a 2200 para moverlo en esa dirección.
• 2480 – Si al saltar estábamos moviendo a Willy a la izquierda, salta a 2300 para moverlo en esa dirección.
• 2490 – Retorno de la rutina de salto.

¿Hay pared?

Antes de mover a Willy comprobamos si lo puede hacer.

• 2600 – En la variable M guardamos el valor máximo que hemos de comprobar, y en WW guardamos si Willy puede caminar.
• 2610 – Inicio del bucle de comprobación.
• 2620 – En la variable C guardamos el carácter que hay al lado de Willy. Si hay algo, vamos a la rutina de comprobación.
• 2630 – Final del bucle.
• 2640 – Retorno de la rutina.

¿Qué toca?

Al saltar, caer o moverse Willy comprueba que está tocando, y actúa en consecuencia.

• 2800 – Si toca la pared de ladrillo pone la variable WW a 0. Esto indica que no se puede mover.
• 2810 – Si toca una llave, la borra de pantalla, suma 100 puntos, imprime el marcador de puntos y resta una llave.
• 2820 – Si toca una planta o una estalactita pone la variable WD a 1, que indica que Willy ha muerto.
• 2830 – Si toca un gráfico de la puerta de salida pone la variable WD a 2, que indica que Willy ha superado la pantalla.
• 2840 – Fin de la rutina de comprobación.

Choque de SPRITES

El MSX permite controlar automáticamente si dos SPRITES colisionan. Esto lo indicamos en las líneas 20 y 30.

En caso de colisión, simplemente el control del programa salta a la línea 2900 y pone la variable WD a 1, y vuelve.

CAMBIOS VARIOS
Hay varias partes del código que se han modificado para acabar el programa o mejorar el rendimiento.

• 20 – Se activa la detección automática de colisión de SPRITES.
• 30 – Si hay una colisión, salta a la línea 2900.
• 220 – Se actualiza la posición horizontal y vertical del SPRITE de Willy.
• 410 – Si Willy ha cogido todas las llaves (variable K) salta a la presentación.
• 6280 – Se utiliza la función STRING$ para imprimir las plataformas horizontales de la pantalla. La pantalla se imprime mucho más rápidamente.
• 6650 – Leemos del DATA la posición inicial de Willy. Orden: posición horizontal, vertical y número de llaves de la pantalla.
• 6660 – Calculamos el valor de la variable WP a partir de la posición de la VRAM donde el modo SCREEN 1 guarda la pantalla.
• 6670 – Calculamos la posición inicial de Willy en pixels.
• 6680 – Ponemos el SPRITE de Willy en pantalla.
• 6690 – Activamos la animación inicial de Willy y su color.
• 6700 – Guardamos la animación inicial en WA, y indicamos que Willy no salta (WS=0), no cae (WC=0) y no está muerto (WD=0).
• 9010 a 9014 – Se han modificado algunos valores de la configuración de pantalla para adaptarla a las posibilidades del juego. Hay que tener en cuenta que a diferencia del juego original, aquí el suelo no se hunde, con lo que hay que hacer algún agujero en la plataforma superior. También se ha eliminado alguna planta.
• 9026 – DATA donde se indica el nombre de la pantalla, posición de la puerta, posición inicial de Willy y el número de llaves de la pantalla.

¿QUE MÁS QUEDA?

Bueno, pues aquí es donde entra vuestra creatividad.

El código que se presenta es totalmente funcional, y el rendimiento es lo suficientemente bueno como para permitir que en una pantalla puedan haber hasta 3 enemigos simultáneamente. Así que se podrían incluir nuevos gráficos y diseños de pantallas para incorporar algún nivel más. Faltaría una pequeña rutina que en función del número de pantalla posicionara el RESTORE de la línea 6000 en el DATA correspondiente.

En el juego original se hunde el suelo y hay cintas que mueven al personaje, pero aquí se ha eliminado por temas de rendimiento.

El personaje se controla con los cursores y la tecla espacio. Se podría activar el uso del joystick.

Se podría crear una pantalla de presentación más completa.

Y como no, falta el sonido y la música de fondo.

EL LISTADO DEFINITIVO

Pues a continuación os presento el listado definitivo.

Y como siempre…

Para terminar, todo este desarrollo se ha programado en un MSX-2 Philips VG-8235 y se ha probado en un Toshiba HX-10. El listado se ha impreso en una impresora matricial Brother M-1109. A lo retro, como dios manda.

En esta entrega vamos a ver como montar el nudo de desarrollo y como se controlan los enemigos del juego.

Algunas rutinas han sufrido algún cambio para optimizar el código, que a su vez, incrementa su velocidad. Algunas pierden en claridad pero ganan en velocidad y reducen la memoria que ocupa el juego.

Como veremos, las principales rutinas se han puesto al principio del programa, ya que el intérprete BASIC las encuentra más rápidamente al hacer un GOTO o un GOSUB, y por consiguiente aumenta la velocidad.

NUDO PRINCIPAL DE DESARROLLO

Desde la línea 10 hasta la 600 se ha montado el nudo principal de desarrollo, que es el lugar desde donde iremos llamando al resto de rutinas.

Funcionamiento del nudo

• 010 – Matriz de información de los enemigos. Esta línea solo se ejecuta una vez.
• 100 – Llamada a la subrutina (7000) que activa el SCREEN 1 y cambia los atributos de color de las letras y números.
• 110 – Llama a la subrutina (3000) que muestra la pantalla de instrucciones e inicializa algunas variables del juego, como el número de vidas o los puntos.
• 190 – Llama a la subrutina (7400) que imprime los marcadores de récord y puntos.
• 200 – Llama a las subrutinas que se encargan de cargar los gráficos del nivel (6000), sus atributos de color (6100), los gráficos de los enemigos (6200), su posición (6400) y la posición de la puerta de salida y el nombre de la pantalla (6600).
• 210 – Llama a la rutina (1000) que se encarga de mover a los enemigos.
• 220 – Resta el tiempo disponible para acabar el nivel. Si se acaba salta a la línea 400.
• 230 – Se borra el punto correspondiente en la barra de tiempo.
• 300 – Si se pulsa la tecla «Escape» sale del juego, saltando a la línea 500.
• 310 – Cierra el bucle principal volviendo a la línea 210.
• 400 – Se resta una vida (variable W), se reinicia el tiempo y si quedan vidas se salta a 200 para volver a cargar el nivel.
• 430 – Si no quedan vidas, se hace un bucle que se encarga de esconder a los SPRITES poniendo su posición vertical a 209.
• 460 – Final de la partida. Salta a 110 para volver a mostrar la pantalla de presentación.
• 500 – Aquí se llega al pulsar la tecla «Escape» y se llama a la subrutina (7200) que vuelve al modo texto en SCREEN 0.
• 600 – Para el programa en BASIC.

RUTINA DE PANTALLA DE PRESENTACIÓN

En la línea 3000 comienza la rutina que se encarga de mostrar la pantalla de presentación e inicializar algunas variables del juego. Como se puede ver, se ha puesto una simple, de ejemplo.

Las variables usadas son

• P – Puntos del juego.
• S – Record del juego.
• L – Nivel actual.
• T – Tiempo restante.
• W – Número de vidas de Willy.

RUTINA DE LOS MARCADORES

Esta rutina está ubicada en la línea 7400 y se encarga de mostrar el marcador de los puntos.

RUTINA DE CARGA DE ENEMIGOS

El MSX permite controlar hasta 32 SPRITES simultáneamente en pantalla.

Por un lado, en la VRAM hay una zona de 2048 bytes, comprendida entre la posición 14336 y la 16384, donde se pueden almacenar hasta 256 gráficos de 8×8 para ser usados en los SPRITES.

Por otro lado hay otra zona de 128 bytes, desde la posición 6912 a la 7039, donde se guarda la información de los 32 SPRITES, agrupando los bytes de 4 en 4. En ellos se va guardando la posición vertical, horizontal, gráfico del SPRITE y color.

Si el SPRITE es de 16×16, cada 4 gráficos consecutivos se considerarán un único gráfico, empezando por el superior izquierdo, inferior izquierdo, superior derecho y inferior derecho.

Codificación de los datos

Entre las línea 9015 y la 9022 se han introducido los gráficos del enemigo del primer nivel. Cada dos líneas contienen un gráfico de 16×16 con una de sus animaciones.

En la línea 9024 se ha introducido el número de enemigos y sus datos correspondientes, en grupos de 7 valores en el DATA.

Formato de la codificación

Controlar cada enemigo requiere 7 valores, con el siguiente formato:

1º- Color del enemigo.
2º- Posición inicial horizontal, en pixels.
3º- Posición inicial vertical, en pixels. Una forma de calcular el valor es: posición en caracteres * 8 – 1.
4º- Velocidad del enemigo en pixels. Se recomienda los valores 1, 2, 4, 8. Si el movimiento inicial es hacia la izquierda, el valor debe ser negativo.
5º- Posición mínima horizontal. Al llegar a este valor cambia su dirección hacia la derecha.
6º- Posición máxima horizontal. Al llegar a este valor cambia su dirección hacia la izquierda.
7º- Primera animación al aparecer. 0 si va a la izquierda y 8 si va a la derecha. Este parámetro se podría obviar.

Funcionamiento de la rutina

Esta rutina está ubicada en la línea 6400, y está preparada para mover a los enemigos horizontalmente. Cada enemigo dispone de cuatro animaciones, dos hacia la derecha y dos hacia la izquierda.

Los enemigos tienen un tamaño de 16×16 pixels, con lo que cada animación ocupa 32 bytes. Las cuatro ocupan un total de 128 bytes y se almacenan consecutivamente a partir de la posición 14336 de la VRAM.

En 6440, una vez cargados los gráficos, se lee de una línea DATA la cantidad de enemigos que se han de mostrar, y se almacena en la variable N, y a continuación va leyendo tantos grupos de 7 valores del DATA como indica N, y los va guardando en la matriz E. Al acabar coloca a los enemigos en su posición correspondiente pasando los valores a la VRAM.

Como ya tenemos los datos de los enemigos cargados, ahora toca moverlos.

RUTINA DE MOVIMIENTO DE ENEMIGOS

Si el MSX no tiene problemas para controlar hasta 32 SPRITES mediante programas en código máquina, al usar BASIC el número decae considerablemente. Así pues, en este programa el número máximo de enemigos a mover lo limita el tamaño de la matriz E, que debe ser un múltiple de 7. Ahora es 21, con lo que permite almacenar hasta 3 SPRITES. De todas formas, el BASIC no permite grandes alegrías, e intentar mover más producirá una perdida de rendimiento fatal.

Funcionamiento de la rutina

La rutina empieza en la línea 1000 y ocupa solo 13 líneas de código.

Vamos a ver como funciona:

• 1000 – Ponemos en la variable D el valor de VRAM donde está el primer SPRITE a controlar, y en la variable A el primer valor en la matriz E.
• 1010 – Inicio de un bucle que se repetirá tantas veces como enemigos marque la variable N.
• 1020 – Para evitar repetir sumas varias veces posteriormente, cargamos los resultados en varias variables. O – Dirección/Velocidad del enemigo, X – Posición horizontal, G – Animación actual. Para terminar, modificamos la posición horizontal del enemigo.
• 1030 – Si el enemigo se dirige a la izquierda, salta a 1060.
• 1040 – Si el enemigo llega a la posición horizontal máxima, invierte el valor de O, y en lugar de sumar, restará. Modifica la orientación de la animación (variable M).
• 1050 – Salta a 1070.
• 1060 – Si el enemigo llega a la posición horizontal mínima, invierte el valor de O, y en lugar de restar, sumará. Modifica la orientación de la animación (variable M).
• 1070 – Pone en el valor del SPRITE correspondiente la nueva posición horizontal.
• 1080 – Cambia la animación.
• 1090 – Pone en el valor del SPRITE correspondiente el gráfico a presentar. Con esto conseguimos la animación.
• 1100- Sumamos 4 a la variable D para apuntar al siguiente SPRITE, y sumamos 7 a la variable A para apuntar a los siguientes valores de la matriz E.
• 1110 – Si quedan más enemigos a mover, vuelve a la línea 1020.
• 1120 – Sale de la rutina y vuelve al nudo principal de desarrollo.

En la rutina, ciertas variables se tratan como valores enteros, poniendo un %, para acelerar los cálculos, ya que se realizan más rápidamente con números enteros que con números reales.

Ahora mismo solo aparece un enemigo en pantalla, como en el juego real, pero si sustituimos el valor 1 de la línea 9024 por un 2 y añadimos 7 valores, aparecerán dos enemigos.

Por ejemplo:

 9024 DATA 2,11,93,55,2,71,127,9,4,93,23,1,71,127,9

Aparece un nuevo enemigo por encima del anterior moviéndose más lentamente.

RESUMEN Y COMENTARIOS

En este nuevo listado se han realizado algunos cambios destinados a mejorar el rendimiento del programa, como puede ser agrupar varias instrucciones en una misma línea, o a usar variables enteras en lugar de valores reales.

La rutina de movimiento ha sido depurada para conseguir el mejor rendimiento posible. Cronometro en mano, conseguí reducir de 10 segundos a 7 segundos el ciclo de recorrido de un enemigo.

Hasta ahora, tanto el aspecto gráfico como la velocidad del juego es igual al «Manic Miner» original. Queda la parte más compleja, tanto a nivel de programación como de rendimiento, que es la que corresponde a Willy, el protagonista. Esto lo veremos en la siguiente entrega.

Olvidé decir que por algún motivo que desconozco, pero comprobado en varios MSX, al usar el modo SCREEN 1 y ponerlo a 32 columnas, la de más a la izquierda queda recortada. Así, solo utilizo 31, con lo que el juego es 8 pixels más estrecho que el original.

El listado, provisional, de todo este montaje queda así.

Para terminar, todo este desarrollo se ha programado en un MSX-2 Philips VG-8235 y se ha probado en un Toshiba HX-10. El listado se ha impreso en una impresora matricial Brother M-1109. A lo retro, como dios manda.

El objetivo de este tutorial consiste en aprender a programar una versión del juego Manic Miner y descubrir distintas técnicas de programación para optimizar el código. He seleccionado este juego porque es un auténtico clásico, con pocas pantallas y gráficos. Esto nos permitirá generar un código muy compacto, ya que en los juegos, la mayor parte de la memoria se dedica a los gráficos y a los datos de las pantallas.

Quiero dejar claro que ignoro como se ha programado el juego original, y que lo que voy a hacer es reproducirlo según mis métodos de programación. Por otro lado, no vamos a programar el juego completo, pero lo que hagamos será totalmente funcional. El objetivo es explicar como se puede hacer, y el que quiera que lo complete o modifique a su gusto.

El programa está escrito en BASIC para MSX, pero las técnicas empleadas son completamente válidas para cualquier microordenador con unas características similares. Una vez el programa funcione, podremos empezar a reprogramar algunas partes del código en ensamblador para descubrir que el programa se ejecuta mucho más rápidamente y que la cantidad de memoria necesaria se reduce considerablemente.

Inicialmente, el tutorial se divide en 7 partes:

1. Rutina de presentación de la pantalla de juego.
2. Rutina de carga de los gráficos y colores.
3. Nudo principal de desarrollo.
4. Rutinas de control de enemigos.
5. Rutinas de control de Willy, el protagonista.
6. Rutinas de control de marcadores, inicio y final de partida.
7. Adaptación a código máquina de algunas rutinas del juego.

Y si alguien se quiere entretener a adaptar el código a otros sistemas, encantado. Lo he diseñado para que sea bastante simple.

RUTINA DE PRESENTACIÓN DE LA PANTALLA DE JUEGO

Todos los elementos que configuran las distintas pantallas han sido codificados para conseguir que funcione con muy pocos datos. Con esto, conseguimos que ocupe poca memoria, se reduzca el tamaño del código y se ejecute más rápidamente.

Codificación de los datos

A partir de la línea 9010 se han introducido los datos de la primera pantalla, en varias líneas DATA.

Formato de la codificación

La rutina está preparada para poner un gráfico en una posición concreta de la pantalla, o una tira de ellos vertical o horizontalmente. Cada 4 o 5 valores representan un gráfico o una tira de ellos, según el siguiente formato:

1. Acción a realizar: «1» Tira horizontal, «2» Tira vertical, «3» un único carácter y «255» fin datos de la pantalla.
2. Posición inicial horizontal.
3. Posición inicial vertical.
4. Posición máxima en repeticiones. Si la acción es tipo «3» no hay que introducir este valor.
5. Carácter a imprimir.

Por ejemplo: La secuencia «2, 0, 0, 15, 1» indica que hay que poner una tira de caracteres tipo «1» (ladrillos) a partir de la posición 0,0 hasta la posición 0,15. Esto dibuja la pared de ladrillos de la izquierda.

La secuencia «3, 24, 4, 5» coloca la llave (carácter 5) que hay en el suelo, entre las dos plantas.

Los códigos de los gráficos tienen la siguiente relación:

1. Ladrillos.
2. Suelo.
3. Cinta transportadora.
4. Suelo que se deshace.
5. Llave.
6. Estalactita.
7. Planta.

En otras pantallas veremos como se añaden nuevos códigos.

En cada pantalla cambiaremos los gráficos, pero la función de cada uno de estos códigos será exactamente el mismo.

Funcionamiento de la rutina

La rutina está ubicada a partir de la línea 6200.

Con el READ de la línea 6210 empezamos a leer los valores del DATA de la línea 9010. El primer valor lo ponemos en «D», que es el código de la acción que hemos de realizar.

Si la acción es «1» o «2», leemos los siguientes 4 valores de DATA y los ponemos en las variables «H», «V», «R» y «G», y ejecutamos un bucle que repite la impresión hasta llegar a la posición indicada en «R».

Si la acción es «3», leemos los siguientes 3 valores de DATA y ponemos un único carácter en la posición indicada.

Si la acción es «255» damos por finalizada la impresión de la pantalla y salimos de esta rutina.

Así, la variable «D» contiene la acción, «V» la posición vertical, «H» la posición horizontal, «G» el gráfico elegido, y opcionalmente, en «R» la posición máxima cuando la acción es «1» o «2».

Por ahora, los códigos de los caracteres van del 1 al 7, pero en realidad no usamos estos, sino que en la línea 6240 lo pasamos al valor ASCII correcto. Se han seleccionado unos valores más simples para que sea más fácil recordarlos.

Como podéis ver, tanto el código de la rutina como de los datos es muy pequeño. Sólo 21 líneas.

Si ejecutamos el programa veremos que aparece la pantalla, pero en lugar de los gráficos aparecen distintos caracteres ASCII. Esto quiere decir que queda por redefinir el juego de caracteres con los gráficos del juego.

Vamos a ver como se hace.

RUTINA DE CARGA DE LOS GRÁFICOS

En el MSX el juego de caracteres está almacenado en la ROM, pero al iniciar el sistema se vuelcan en la memoria de video VRAM, y allí es donde los tendremos que modificar.

Codificación de los gráficos

A partir de la línea 9000 se han introducido los datos de los gráficos en líneas DATA.

Formato de la codificación

La rutina está preparada para redefinir los caracteres indicados. Así, el primer valor del DATA indica el carácter a redefinir, y los siguientes 8 valores corresponden a los datos del gráfico, con un tamaño de 8×8 pixels.

Funcionamiento de la rutina

La rutina está ubicada a partir de la línea 6000.

Mediante el RESTORE de la línea 6000 nos situaremos en la línea DATA que contiene los datos de los gráficos de la pantalla correspondiente.

Con el READ de la línea 6010 leemos el primer valor y lo ponemos en «D», que es el código del carácter a redefinir. Si este valor es «0», dejamos de redefinir más caracteres. En caso contrario, un bucle leer los siguientes 8 valores del DATA y los mete en la posición de memoria de la VRAM donde está almacenado ese carácter. El primer carácter está en la posición 0 de la VRAM. Con el cálculo de la línea 6025 sabremos a partir de que posición hemos de volcar los datos de ese carácter.

Si ejecutamos el programa, veremos que ya aparecen los gráficos en la pantalla pero en blanco sobre negro. Esto quiere decir que queda por redefinir los atributos de los caracteres del juego.

Un último esfuerzo y ya está.

RUTINA DE CARGAS DE LOS COLORES

El modo SCREEN 1 del MSX es una pantalla de texto con posibilidad de usar SPRITES. En este modo la forma de trabajar con los colores es un poco peculiar. En otros sistemas, un byte en la memoria de video indica un carácter en una posición de pantalla, y otro byte indica el atributo de color de esa posición. En el MSX la cosa es más simple y limitada. Cada 8 caracteres consecutivos de la tabla ASCII pueden tener un único atributo de color compartido. Así, «@ABCDEFG» han de tener el mismo color y la «HIJKLMNO» pueden tener otro distinto. De esta forma, con solo 32 bytes en la memoria de video controlamos los colores de los 256 caracteres. Una forma realmente original, pero poco práctica. Por un lado, al poner una letra en pantalla ya sale con el color asignado, cosa que hace que sea más rápido, pero por otro lado no te permite poner un texto en pantalla con distintos colores. Para ello deberíamos usar el modo SCREEN 2, que ya es totalmente gráfico, pero más complejo de gestionar.

Codificación de los colores

A partir de la línea 9007 se han introducido los datos de los colores en una línea DATA.

Formato de la codificación

Los colores se han almacenado en 10 valores. Se cambian los atributos de color desde el carácter 128 hasta el 207. En principio es más que suficiente para los pocos gráficos que hemos de usar.

Funcionamiento de la rutina

La rutina está ubicada a partir de la línea 6100. Simplemente leemos los 10 valores de la línea DATA y vamos haciendo un VPOKE en la dirección de la VRAM correspondiente. Este valor se indica en la línea 6100.

Misión cumplida.

NUDO PRINCIPAL

En la línea 100 comienza el nudo principal de desarrollo, que es el lugar desde donde iremos llamando al resto de rutinas.

Ahora mismo:

• Activa el modo SCREEN 1 haciendo un GOSUB 7000
• Carga los gráficos de la pantalla con un GOSUB 6000
• Queda en pausa hasta que se pulse una tecla, con el INKEY$ de la línea 300
• Activa el modo SCREEN 0 para volver al editor BASIC.

Estas líneas irán cambiando a lo largo del tutorial para ir recogiendo los sucesivos cambios que se produzcan.

RUTINA DE ACTIVACION DEL MODO GRAFICO

En la línea 7000 comienza una subrutina que desactiva la línea inferior del BASIC donde se muestran los valores de las teclas de función, activa el modo SCREEN 1, pone el ancho en 31 caracteres y configura los colores por defecto.

RUTINA DE ACTIVACION DEL MODO TEXTO

En la línea 7100 comienza una subrutina que activa el modo SCREEN 0, vuelve a configurar los colores normales y activa la línea inferior del BASIC y nos devuelve al editor.

RESUMEN Y COMENTARIOS

En las líneas DATA no es obligatorio seguir la numeración que he indicado. Lo único importante es que los datos estén introducidos con el formato y orden indicado: datos de los gráficos, datos de los atributos de color y datos de la pantalla de juego. Es recomendable no mezclar los valores en una misma línea para que sea más fácil una posterior identificación y modificación.

Algunos partes se podrían haber optimizado para ganar algo de velocidad, pero las he dejado como están para que sea más fácil y comprensible por si alguien quiere adaptarlo a otro sistema.

El nudo principal de desarrollo lo he puesto en las primeras líneas, ya que en esta zona el BASIC es más rápido.

Toda la explicación de este tutorial la he realizado al revés de como funciona el programa, ya que como se puede apreciar en el listado, lo primero que se hace es redefinir los gráficos, asignar sus atributos de color e imprimir la pantalla. Esto se ha hecho así para comprender mejor las distintas etapas del proceso.

El listado de todo este montaje queda así.

Para terminar, todo este desarrollo se ha realizado en un MSX-2 Philips VG-8235 y el listado se ha impreso en una impresora matricial Brother M-1109. A lo retro, como dios manda.

Introducción

Es curioso cómo ciertas formas de arte se encuentran en lugares y momentos muy específicos. El movimiento grunge tuvo su apogeo en la ciudad de Seattle en los años 90, y los cómics de superhéroes tenían como escenario la Nueva York de 1940. Lo mismo ocurrió con los videojuegos que andaban por Japón durante los años 80.

Sin embargo, estando Japón típicamente orientado hacia el mercado interno, muy poco de lo hecho allí en aquella época llegó a occidente. Por cada Mario y Zelda que llegó hasta aquí,¡ otros diez juegos igualmente buenos permanecieron allá completamente desconocidos para nosotros!

Hoy en día todos estos juegos se pueden encontrar fácilmente en Internet. Sin embargo, todavía no pueden ser apreciados por los jugadores occidentales, debido a la barrera del idioma. Por lo general estos juegos están escritos totalmente en japonés, sin ninguna versión escrita en otro idioma.

La solución para esto es la traducción de los juegos. En noviembre de 2001, comencé la traducción del juego Shalom, de Konami, y actualmente está casi terminado. Sin embargo, ¡todavía hay muchos juegos que merecen ser traducidos!

El objetivo de este tutorial es enseñar a todos los trucos y técnicas necesarias para traducir un juego. ¡De esta manera espero hacer estas perlas desconocidas para el público de habla portuguesa!

En lugar de simplemente hacer una página con consejos y trucos de traducción, me decidí a hacer este tutorial en forma de blog. Por lo tanto, los aspirantes a traductor pueden seguir paso a paso el proceso de traducción, sin perderse ningún detalle.

Antes de comenzar este tutorial, hay que hacer algunas advertencias. Traducir un juego no es fácil. Es laborioso, tedioso y requiere una serie de habilidades que no todos podrían tener.

Como los juegos originales están en japonés, tenéis que saber japonés antes que nada. Y el hecho de saber el idioma puede no ser suficiente: para los chistes y los juegos de palabras puede ser necesario tener un conocimiento bastante avanzado de las estructuras gramaticales, el vocabulario, las costumbres y la historia de Japón.

Además, en algún momento tenéis que que entender cómo funciona el programa, o al menos parte de él. Y si entender el código C de otras personas, incluso comentado, es difícil; entonces, créeme, que entender el código ensamblador sin comentarios lo es aún más.

Además de los requisitos anteriores, tendréis que tener un buen conocimiento general de programación. En el camino, pueden surgir problemas de compresión de datos, conversión de caracteres, falta de memoria, y muchos otros. En estos casos, sólo la experiencia puede ayudar al programador.

Teniendo en cuenta todos los peros mencionados anteriormente, ¡huid mientras podáis! ¡El botón atrás de vuestro navegador os llevará a los rincones más seguros de la web! ¡Esto de de la traducción es algo de locos!

De acuerdo, sois conscientes de las dificultades y habéis decidido continuar con la lectura. Esto es bueno. Las traducciones requieren una buena dosis de coraje. A pesar de que todos los problemas mencionados anteriormente no son reales, no es necesario atacarlos a todos. Si hay algo que no entendéis buscad a alguien que sepa. Nadie dijo que la traducción fuera una tarea solitaria. Incluso, si no no sabéis nada de las áreas comentadas más arriba, aún podéis ayudar en un proyecto de traducción, como beta-tester. No dejando pasar ninguno de los errores cometidos por los programadores y traductores.

Terminada la introducción, ¡en la próxima lección explicaré el primer desafío al que debe enfrentarse el traductor!

La elección

Uno de las tareas más difíciles al traducir un juego, por increíble que pueda parecer, es elegir el juego. El proceso de traducción es largo, duro y agotador, por lo que es bueno tener en mente qué juego será vuestro compañero durante meses o incluso años. Por eso, la primera lección es: hay traducir un juego que os guste. No tiene mucho sentido traducir un juego sólo porque está de moda, u otro motivo igualmente vano. Si no os gusta lo que estáis haciendo, las posibilidades de que abandonéis son muy grandes.

Para este tutorial, tuve que elegir un juego que me gustaba, y acabé decidiéndome por Labyrinth, de Pack-in-Video, juego basado en la película homónima de Jim Henson. Las razones por las que soy un fan de esta película son demasiado largas para comentarlas aquí (un día acabaré haciendo una página sobre ellas). Para mí traducir un juego basado en Labyrinth es un honor. Como juego, Labyrinth solamente tiene sonido MSX-Audio pero sonido en FM, ¡y esto ya lo convierte en un juego único! Además, Labyrinth es un juego de rol, así que es casi imposible jugarlo sin saber japonés por lo que esto lo coloca en la categoría de juego inédito (al menos en occidente).

Para la primera lección, ¡hablaré un poco sobre vuestros compañeros de trabajo!

Las herramientas de trabajo

Una de las características más extrañas de la lengua japonesa es la ausencia de «Rebelos». Rebelo fue un político brasileño que quiso prohibir el uso de palabras inglesas dentro de la lengua portuguesa. Por lo general, los japoneses no tienen ningún reparo en aprovecharse de otros idiomas apropiarse de todo lo que les falta en el suyo.

Esto puede ser demostrado históricamente. En un principio el japonés era estrictamente un lenguaje oral. Cuando la forma escrita fue necesaria, alrededor del siglo V, los caracteres (kanji) fueron importados de China. En el siglo XV, Japón entró en contacto con las civilizaciones occidentales, que en esa época estaban en expansión debido a las grandes navegaciones. Por eso algunas palabras que representan los nuevos conceptos fueron tomadas directamente de la lengua de los navegantes portugueses, como pan (パン=pan) y jabón ((シャボン=shabon).

Hoy en día, la fuente de conceptos nuevos son los Estados Unidos. Así que una gran cantidad de palabras se copian directamente del inglés, como ordenador (コンピュータ = konpyuuta) y juego (ゲーム = geemu). Por esta motivo, es muy común encontrar las palabras, frases y fragmentos enteros, incluso textos escritos en inglés, en un juego hecho en Japón.

Por otro lado, si los japoneses no se cortan en tomar adaptar palabras y tomar prestados los verbos, tampoco se preocupan de adoptar la ortografía correcta. Incluso en algunos casos, ¡el significado original se conserva! Un ejemplo sencillo es la palabra vestido, que en Japón se ha convertido en ワンピース = wanpiisu, del inglés one piece.

Así que si os encontráis cualquier texto en inglés en un juego que japonés, recuerdad este consejo importante: no importa lo que está escrito, sino lo que el autor quería escribir. Como dijo sabiamente un amigo mío japonés: «no es inglés… es japonés inglés!»

Pero dejemos la introducción y vayamos a lo que nos interesa. Aplicando directamente lo que escrito más anteriormente, podemos observar que en la pantalla de créditos de Labyrinth hay una parte que dice «CODE FOR MSX CONPUTER». obviando lo que está escrito,nos damos cuenta de que el autor realmente quiso escribir «CODE FOR MSX COMPUTER». Una buena traducción pasaría todo este texto a portugués (español en nuestro caso) pero la corrección ortográfica es un buen ejercicio para practicar el uso de las herramientas.

La primera herramienta que necesitáis para traducir es un buen emulador. En el caso de Labyrinth, un juego para MSX2, yo usaría BrMSX como emulador. Ser el autor de BrMSX ayuda un poco a elegir, por supuesto, pero al final siempre se puede optar por cualquier opción que ayude a traducir. Pero la verdadera razón de esta elección es que tiene un excelente debugger (depurador) para el código fuente. Por pura comodidad, yo uso, además de BrMSX, tambiénParaMSX, muy bieno a la hora de realizar capturas de pantalla.

Comprobando que la ROM original funciona en el emulador, podemos comenzar a corregir la ortografía. Para ello, usamos una segunda herramienta, un editor hexadecimal. Hay muchas disponibles pero yo os recomiendo usar UltraEdit. Además de la edición hexadecimal sí mismo, esta plaicación tiene también un editor de texto Unicode muy adecuado para editar textos en japonés, y un sistema de plug-in con el que se puede poner en el emulador así como también herramientas de extracción de scripts. ¡Y todo esto por sólo 35 dólares!

Antes de hacer una corrección (parche) una pequeña observación. Esto es algo que ya debería haber hecho, pero nunca está de más recordar: hay que hacer una copia de seguridad de la ROM original antes de realizar cualquier cambio.

Para hacer la modificación, sólo tenéis que cargar la ROM en el UltraEdit. Se debe abrir directamente en modo hexadecimal, si esto no sucede, sólo tenéis que pulsar CTRL + H. Usando ALT + F3, introducís la cadena a buscar en nuestro caso CONPUTER y el programa nos recuerda que se trata de una búsqueda de texto, así que hay que hacer click en Find ASCII. Ahora basta con escribir M encima de la N original y guardar la ROM para probar en el emulador.

Si todo va bien, ahora deberíais tener una ROM ya corregida y que funciona correctamente en el emulador. ¡Felicidades, habéis tenido suerte! Y muy buena suerte, porque a pesar de ser un procedimiento simple, muchas cosas podrían haber fallado.

Entre las cosas que podrían haber ocurrido están las siguientes:

• Fallo al buscar el texto CONPUTER: el texto usa una codificación diferente a ASCII.
• Fallo al buscar el texto CONPUTER: el texto está comprimido dentro de la ROM.
• Fallo al buscar el texto CONPUTER: la pantalla de créditos es un gráfico en lugar de texto.
• La modificación del texto podría dar fallo si la ROM tuviese checksum o tuviera protección antipiratería.
• Un meteorito podría caer en vuestra cabeza (esto no está directamente relacionado con la traducción, ¡pero podría ocurrir! ¡Sois unos tipos con suerte!)

En este tercer artículo Pepe se centra en la generación de gráficos en SCREEN 2. Como siempre, el artículo viene cargado de ejemplos, imágenes y textos que explican al detalle cada uno de los ejercicios con lo que entender este aspecto de la programación en ensamblador es muy sencillo para los más legos en la materia (como yo).

A mí me está sirviendo de ayuda para comenzar a dar mis primeros pasos en el oscuro mundo del ensamblador.

Actualización: A continuación tenéis en enlace a la descarga completa del tutorial con todos los capítulos unidos en un solo PDF para una lectura más cómoda. A medida que Pepe publique nuevos capítulos actualizaré el documento.

Iniciación a la programación en ensamblador (Pepe Vila)

Puedes cambiar fácilmente la unidad de disco de un Philips NMS-8250/55/80 por otra de PC. La única modificación necesaria es colocar un jumper sobre los pines 33 y 34 del conector de la segunda unidad de disco que se encuentra en la placa principal. El pin 33 es tierra y el 34 es RDY, la señal ready, que las unidades de PC no tienen. Al conectar los pines le estamos diciendo al MSX que la unidad siempre está preparada (ready) y con la DiskROM no hay ningún problema.

Para la numeración de los pines, echadle un vistazo a este enlace a MSX FAQ (connector section).

Resolución de problemas

• La unidad no funciona y el LED se queda encendido: pusiste el conector al revés. Cambia la posición e inténtalo de nuevo.
• La unidad de disco solamente funciona cuando accedo a ella como unidad B: (por ejemplo escribiendo FILES "B:"). Comprueba primero si la unidad de disco tiene un jumper Drive Select (DS). Algunas unidades de disco no tienen jumpers y en cambio tienen soldado un resistor SMD. Asegúrate que DS=0 para la unidad A y que DS=1 para la unidad B. Si no hay jumper, o bien no puedes soldar una resistor SMD, aún es posible solucionar el problema. Desconecta el cable plano de la unidad de disco . Con un cuchillo afilado puedes dividirlo entre los cables 9-10 y entre 12-13 (a una longitud de aproximadamente 4 centímetros). Si giras estos tres paquetes de cables 180 grados y lo conectas de nuevo a la unidad, DS0 y DS1 estarán intercambiados y debería funcionar.
• Aparecen errores cuando se usa un disco duro: no puedes usar la unidad de disco como disco duro. Así que usa solamente disquetes formateados a doble densidad. A veces, necesitarás colocar un trozo de cinta adhesiva en el agujero de alta densidad (HD) que tiene el disquete para que funcione. Aunque es mejor cortar el sensor de la disquetera que comprueba el agujero de alta densidad.

Ten en cuenta que es posible poner dos unidades conectadas al mismo cable, mientras una fucione como DS0 y la otra como DS1.

Aunque ya tiene tiempo el tutorial de que os voy a hablar, me tropecé el otro día con él gracias a una pista de xgipe en los foros de Karoshi MSX Community y tras echarle una buena lectura he creído que sería interesante enlazarlo desde aquí para conocimiento general.

El tutorial se titula «Programando un Manic Miner» y fue escrito por dancresp en tres partes. A lo largo del texto su autor nos enseña las ideas básicas a la hora de programar un juego de corte clásico con enemigos y plataformas, que como punto de partida no está nada mal. El lenguaje de programación usado es el MSX-BASIC aunque usa ciertas rutinas en ensamblador para optimizar su funcionamiento.

Si os animáis a seguirlo seguramente aprenderéis técnicas y conocimientos que os valdrán para ir luego a por algo más complicado.

¡100% recomendado!

Enlace relacionado: Retrowiki.es.

Artículo traducido y adaptado por Konamito.

De nuevo nos reunimos todos para otra sesión de hazlo tú mismo; esta vez, intentaremos resolver el problema de los cartuchos sueltos, necesitamos vestirlos adecuadamente. Hubo un tiempo en el que era un apasionado coleccionista, y esperando pacientemente por alguna rara perla (especialmente de Konami) en su caja, pero muchos de nuestros juegos preferidos se venden demasiado a menudo con el cartucho suelto, completamente desnudos, snif.

Mirad este cartucho, qué mal aspecto tiene, solo en una esquina, como una Barbie sin su vestido de princesa.

Continuamos esta sección de Taller con una reparación muy sencilla: Arreglar el cuentavueltas de un reproductor de cassetes, una avería (si se puede llamar avería) muy común en estos aparatos. En este caso se trata del reproductor Sony Bit-Corder SDC-600S.

Necesitamos lo siguiente:

• El reproductor propiamente dicho al que no le funcione el cuentavueltas:

• Una goma elástica negra, de las que usamos para las disketeras o para los cassetes de nuestros «aparatos»:

Éstas son fáciles de encontrar y bastante baratas. Por 4 euros he conseguido todas las que se ven en la foto. He puesto una moneda de un euro para que se vea el tamaño de las que son apropiadas para este arreglo. El diámetro será de unos 3 centímetros más o menos (conviene que la goma se quede tensa una vez puesta).

Lo primero de todo es abrir el reproductor, en este caso el Bit-Corder lleva 3 tornillos en la parte trasera que procedemos a quitar, dejando así a la vista «las tripas» del cacharro:

Ahora tenemos que separar el mecanismo completo de la carcasa. Tenemos que localizar dos tornillos de color cobre, uno en la parte inferior izquierda y otro en la superior derecha. Los quitamos y buscamos otros 2 tornillos que se encuentran en la parte de abajo de la carcasa, una vez suelto todo, procedemos a sacar todo el interior (ojo, con cuidado de no tirar demasiado, que hay cables conectados al frontal):

Una forma fácil de sacar todo el interior es pulsando todas las teclas del reproductor, cosa que hace que todo quede libre y podamos tirar de él hacia atrás.

Bien, ahora nos fijamos en el cuentavueltas y en su parte trasera localizamos la polea que hace que los dígitos den vueltas. Cuidado si hay restos de la anterior goma porque si los tocáis os pondréis las manos perdidas de negro y luego no salta (yo tuve que utlizar desengrasante para quitármelo, je). También miramos al rodillo de la cinta que nos queda cerca del cuentavueltas (es el del Play) y vemos que tiene una muesca o polea también:

Pues vamos a poner la goma elástica. Para colocarla en la polea del cuentavueltas tiraremos un poquito del cuentavueltas hacia afuera (sólo un poquito) para que podamos introducir la goma por detrás de la polea y ponerla correctamente. La otra punta es más fácil ponerla ya que sólo tenemos que encajarla en la muesca del rodillo. Una vez puesta, quedaría así:

Fácil, ¿verdad?. Debe de quedar algo tensa si no queremos que se suelte de su sitio con el tiempo. Bueno una cosa que me gusta hacer a mí después de arreglar algo es probarlo antes de cerrar el aparato, que más de una vez he tenido que volver a abrirlo todo al no funcionar la chapuza. Lo conectamos a la corriente (cuidado de no tocar nada del mecanismo interno que puede hacer «pupa» si hay algún cable por ahí suelto) y le damos al Play para ver su funcionamiento:

¡¡Ahí está nuestro cuentavueltas marchando a la perfección!!, ya marca 33 vueltas, jeje. Tras ver nuestro éxito, desenchufamos el reproductor y volvemos a montarlo siguiendo nuestros pasos hacia atrás y ya lo tenemos montado de nuevo. Como última prueba lo volvemos a probar una vez cerrado por si las moscas:

¡Perfecto! Ya tenemos nuestro reproductor operativo al 100%. Ya sabremos por qué vuelta va la cinta y no tendremos que pararla «a ojo» cuando haya que hacerlo.

El arreglo de otro tipo de reproductores supongo que será exactamente igual. Lo único que cambiará será la forma de liberar todo el mecanismo para dejarlo suelto y poder trabajar con total libertad.

Aquí termino, espero que haya sido útil este mini-tutorial y ahora ¡a reparar vuestros cuentavueltas!. Es fácil y rápido de hacer.

Este procedimiento ha sido realizado sobre un MSX modelo Philips VG-8020.

Pasos a seguir:

• Quitar los 2 tornillos de la parte trasera del MSX.
• Presionar sobre la carcasa inferior, exactamente en los puntos señalados de color azul en la imagen.

• Una vez hayamos quitado la tapa, tenemos que quitar también el teclado. Para ello levantamos un poco y con cuidado el teclado para descubrir tres conectores en la parte inferior, dos cintas y un cable azul unido a un conector. Presionamos hacia arriba las piezas de plástico blanco de protección del conector de la membrana del teclado y el conector suavemente hacia arriba.
• Colocamos el teclado orientado hacia la izquierda y boca abajo y nos fijamos en que en la parte superior izquierda hay un cable más que une se une al teclado. Tiramos de él y sale.

• Esto es lo que se ve una vez quitado el teclado. Ahora hay que desconectar la fuente de alimentación y 3 tornillos: uno en la parte inferior derecha de la placa base, y otros dos que sujetan la pequeña placa que está a la izquierda en la placa base (no sé qué es, así que si alguien lo sabe que complete este tutorial, no soy un gurú del hardware, solamente me apaño).
• Hecho esto ya solamente queda tirar hacia arriba y hacia atrás de la placa base y ya la tenemos en las manos.

• Ahora toca soldar el puerto de joystick que está fallando. Como se puede ver en la fotografía, el estaño de los conectores está, efectivamente, roto.

• Este punto de soldadura se ve claramente que está roto, además se mueve.

• Así que nada, soldador calentándose y estaño preparado junto con la pastita para soldar. Antes de comenzar a soldar, he limpiado la zona con alcohol y he secado con papel. También con un pincel he repasado los contactos con pasta para soldar. No he quitado la soldadura antigua, seguramente para los más expertos hubiera sido lo mejor pero en mi caso no me arriesgué y solamente añadí puntitos de estaño a la vez que acercaba el soldador.
• Así quedó después de soldar.

• No es la menor soldadura que he visto pero ya no se mueve y parece robusta. Ya está todo listo.
• Ahora toca volver a montar el MSX y dejarlo todo como estaba.
• Aquí está el resultado final.

• Ahora ya puedo vicarme a The Maze of Galious que compré en eBay por 17€ y que para mí no tiene precio. Ahora mi joystick QuickShot 2 funciona perfectamente.

Bueno amigos espero os haya sido útil mi primer articulo o por lo menos entretenido. Un saludo y hasta la próxima.

¡Viva el MSX!

Seguramente no os suene demasiado (o sí) el nombre de Gryzor87. Estamos hablando del músico que acompaña a locomalito en sus producciones recientes: Hydorah y L’Abbaye des Morts. Ahora Gryzor87 acaba de publicar un extenso manual-tutorial de uso del programa Pxtone.

Incluso el autor de pxtone ha escrito el prólogo del manual. Merece la pena echarle un vistazo y aprender a cómo domar las notas musicales en nuestras producciones. Las explicaciones están orientadas al amplio espectro de generaciones de videojuegos, desde los más sencillos 8 bits hasta los juegos actuales con grandes súper producciones musicales.

El manual está disponible en español o inglés en formato PDF y con gran cantidad de imágenes explicativas. Todo condensado en nada menos que 96 páginas. Se nota que hay mucho trabajo y esfuerzo detrás de esta obra. Si queréis aprender o mejorar vuestras técnicas no dudéis en echarle un vistazo. El paquete de descarga incluye además del manual, el programa Pxtone y ejemplos.

Recomendado 100%

Enlace relacionado: Manual Pxtone.