martes, 23 de diciembre de 2008

Justo ahora, hace 22 años...

Justo ahora hace 22 años, mis padres entraron por la puerta de casa con dos grandes bultos: un ordenador y un pequeño televisor en blanco y negro. Justo ahora hace 22 años comenzó mi afición por la informática con aquel pequeño ordenador que aún hoy sigo teniendo y que funciona como el primer día.

Han sido 22 años en los que se ha visto evolucionar la informática hasta cotas insospechadas. En aquel momento no podíamos imaginar todo lo que tenemos ahora, desde internet hasta las consolas de última generación, cine en casa con altísima calidad, comunicación instantánea con (casi) cualquier persona en el planeta...

Hoy todo esto nos parece normal, pero justo ahora, hace 22 años, aquel regalo me abrió una puerta que jamás volverá a cerrarse...

lunes, 15 de diciembre de 2008

48K lineales en el cartucho flash de Padial

Buenas:

Hace ya unos cuantos años compré una de las versiones del cartucho Flash que fabricó Padial. En este cartucho se pueden cargar ficheros en formato ROM para ser ejecutados en cualquier MSX, siempre y cuando sean de 8K, 16K, 32K o megaroms de hasta 512K con mappers ASCII8 ó ASCII16. Es decir, la flash sitúa rom en las páginas 1 y 2 del Z80 (de $4000 a $BFFF).

Sin embargo, no es posible cargar roms de 48K lineales como "Universe Unknown" ó "The Cure", ya que este tipo de roms se sitúan en las tres primeras páginas del Z80 (de $0000 a $BFFF), dejando la página 3 (de $C000 a $FFFF) con RAM...

¿Seguro que no es posible? Pues sí que lo es.

Primero veamos un poco de teoría sobre cómo funcionan los mappers de cartuchos. Una explicación más detallada y cubriendo más tipos de mappers se encuentra en la siguiente dirección:


Fijémonos en los mappers ASCII8 y ASCII16 (los que utiliza la flash de Padial). De acuerdo a la página anterior, las direcciones para cambiar los bancos en dichos mappers son:

Mapper$4000-$5FFF$6000-$7FFF$8000-$9FFF$A000-$BFFF
ASCII8$6000$6800$7000$7800
ASCII16$6000$7000

Es decir, en modo ASCII8 tenemos cuatro bancos de memoria en los que podemos seleccionar uno de los 64 (512/8) bloques de 8K disponibles, mientras que en modo ASCII16 tenemos dos bancos de memoria en los que podemos seleccionar uno de los 32 (512/16) bloques de 16K disponibles. La selección, en ambos modos, se realiza "pokeando" en las direcciones de memoria designadas el número de bloque a visualizar.

Ahora bien, para que funcionen de entrada las roms de 32K, la flash se inicializa "pokeando" en esas direcciones de memoria los valores 0, 1, 2 y 3 respectivamente, de forma que arrancando en modo ASCII8 tendríamos los cuatro primeros bloques visibles, es decir, los 32K de nuestra rom.

¿Y si arrancamos en modo ASCII16? Pues igual, la inicialización sería la misma, de forma que tendríamos en $4000-$7FFF el bloque 0 y en $8000-$C000 el bloque 2. Por eso no podemos ejecutar juegos de 32K en modo ASCII16, ya que no estarían situados los bloques correspondientes en su sitio (no, no vale eso de "que lo haga la rom", porque las roms de 32K no usan mapper).

Vale, ¿pero y las roms de 48K? Bien, el hecho es que hasta ahora sólo hemos visto el funcionamiento de los mappers y cómo se inicializa la flash. La cuestión clave (la cual conozco gracias a que BiFi se pegó el currazo de cacharrear con la flash) es que esta flash también mapea rom en la página 0 (en el rango $0000-$3FFF) del slot donde esté. ¿Qué hay ahí visible? Pues siempre, invariablemente, el bloque 0 del mapper, independientemente de si estamos en modo ASCII8 ó ASCII16.

Es decir, cuando estamos ejecutando una rom cargada en la flash de Padial, si estamos en modo ASCII8, de $0000 a $1FFF tendremos visibles sus primeros 8K o los primeros 16K (de $0000 a $3FFF) en modo ASCII16. Como las roms que usan mapper no tocan la página 0 de su slot, esto resulta totalmente transparente tanto para nosotros como para el MSX.

Pero ahora mirémoslo desde el punto de vista de los desarrolladores actuales. Si tenemos la posibilidad de visualizar los primeros 16K de nuestra rom en la página 0 del Z80, ¿cómo podríamos aprovechar esto para cargar juegos de 48K?

Obviamente de entrada ya descartamos utilizar el modo ASCII8, ya que con este modo no tendríamos nada en las direcciones de memoria de $2000 a $3FFF. Nos centramos en el modo ASCII16 y vemos que, según la inicialización, tenemos:

Memoria$0000-$3FFF$4000-$7FFF$8000-$BFFF
Bloque002

Nuestro gozo en un pozo. Resulta que tenemos visible el bloque 0 en las páginas 0 y 1 del Z80 y el bloque 2 en la página 2. Pero el bloque 1, donde normalmente se sitúa la cabecera de la rom, no está visible en ningún sitio (y tenía que estar en la página 1). ¿Qué hacemos? Fácil, vamos a crear una segunda cabecera de rom en el bloque 0, de forma que sólo se ejecutará si el bloque 0 se sitúa en la página 1 del Z80.

La cabecera de los cartuchos siempre comienza con los bytes $41 $42, seguidos de la dirección de memoria donde se encuentra la rutina de inicialización del cartucho. Pero la cabecera contiene mucha más información que, en el 90% de los cartuchos, está a 0. Realmente la cabecera tiene 16 bytes de tamaño, aunque haya cartuchos que no respeten el formato al 100%.

La idea será que la cabecera "buena" (es decir, la situada en el bloque 1) deberá respetar el formato y dejar 12 bytes a 0 tras los bytes de identificación y la dirección de memoria de inicio. Por otro lado, la cabecera "falsa" (la que vamos a situar en el bloque 0 para aprovechar la flash de Padial) NO DEBE respetar este formato para no confundir a los emuladores ni a los cargadores, dejando sólo 7 bytes a 0 y usando los 5 bytes restantes en dos instrucciones adicionales. Así, los emuladores y los cargadores de roms (como el ODO) no situarán de forma incorrecta nuestro programa en la memoria.

Veamos, a continuación, el código que he utilizado para estas dos cabeceras en el QBIQS, que es una rom de 48K lineales que funciona en la flash de Padial sin problema alguno (así como en los emuladores y cargada con ODO).

.org $0000
.db $41,$42
.dw PADINIT+$4000
.ds 7
PADINIT:
ld a,1
ld [$6000],a

; AQUI VA EL RESTO DE CÓDIGO/DATOS SITUADO EN LA PÁGINA 0
[...]

.org $4000
.db $41,$42
.dw INIT
.ds 12
INIT:

; Y AQUÍ EL RESTO DEL CÓDIGO SITUADO EN LAS PÁGINAS 1 Y 2
[...]

Veamos cómo funciona el código. Si arrancamos la rom de forma normal (en un emulador, con el ODO o similares, o bien en un cartucho hecho ex-profeso para ello) la BIOS buscará la cabecera completa y la encontrará en $4000. Así que la ejecución llegará a la rutina INIT (situada en $4010 como habréis podido ver) y nuestra rom tomará el control del Z80.

Si ahora arrancamos en la flash de Padial, tendremos que en $4000 se sitúa la cabecera que hemos creado para la flash. La rutina especial de inicialización estará en $400B (correctamente señalada por la cabecera) y consiste, simplemente, en "pokear" un 1 en la dirección de memoria $6000, para así cambiar el bloque visible en el banco 0 y tener visible el bloque 1 en la página 1. Como (según podemos ver en la tabla anterior) ya teníamos el bloque 0 en la página 0 y el 2 en la 2, ya tenemos los 48K de nuestra rom visibles en las tres primeras páginas del Z80 como era nuestra idea.

Tras hacer ese cambio en el banco 0 del mapper, tenemos que el registro PC (el contador de programa del Z80) valdrá $4010 (justo la dirección de la rutina INIT) y que ahora el bloque 1 ocupa dicho banco, por lo que lo siguiente que se ejecutará es, precisamente, la rutina normal de inicialización tras haber situado correctamente los tres bloques de la rom.

Espero que este pequeño artículo os resulte de utilidad a la hora de crear nuevas roms de 48K para MSX, ya que ahora podrán ser cargadas desde la flash de Padial sin ningún problema.

Obviamente, también se puede coger una rom de 48K como Universe Unknown o The Cure (que mencionábamos al principio) y parchearlas de forma que se puedan cargar en este cartucho flash. Por si no os sentís con ánimos de hacerlo por vosotros mismos, BiFi ya se tomó la molestia y en http://ips.tni.nl/rom/flashrom/ podéis encontrar dichos parches en forma de ficheros IPS, así como otros parches expresamente creados para esta flash.

jueves, 4 de diciembre de 2008

Cambio de local para la XXXIV RU de Barcelona

Hola a todos:

Pues eso, que a última hora hay un cambio de local para la próxima RU de Barcelona. Ya no será en la sala l'Altell donde se han celebrado las últimas reuniones, sino que será en la sala de actos 43, que está situada en otro edificio de Les Cotxeres.

El cambio supone, además, que los visitantes no tendrán que pagar los 3 euros de entrada salvo que quieran visitar el resto de la Gamestorming.

A falta de dos días para la RU la lista de stands ha crecido hasta los 10:
  • AAMSX, quienes tendrán a la venta los cartuchos de la MSX Cartridge Shop y un recopilatorio de juegos de Dinamic.
  • AUIC, la Asociación de Usuarios de Informática Clásica nos traerá algunos modelos raros de MSX y presentará sus actividades.
  • Konamito, presentará los juegos del concurso de BASIC y, además, pondrá a la venta diverso material relacionado con el MSX.
  • Kralizec, que nos deleitarán con una demo jugable del Goonies 'R' good enough. En este mismo stand estarán las "sprite girls" quienes nos traen imanes para nevera con personajes de juegos de MSX.
  • One Beer MSX, ya lo sabes: si quieres jugar has de beber y si quieres beber has de jugar.
  • Paxanga Soft, que nos presentará su nuevo juego: Perfect Fit.
  • Sd-Snatcher: nos enseñará todo el software que realiza para InterNestor Lite.
  • Walter, un usuario francés que nos traerá tabletas gráficas y lápices ópticos en funcionamiento.
  • Z80ST-Software, allí estaré con una demo jugable del QBIQS que se podrá probar en un MSX1 con sólo 16K de RAM (configuración mínima para que el juego funcione).
  • Plataforma Invitada: COMMODORE. Álex Martí nos traerá un stand totalmente dedicado a Commodore.
Si os gusta el MSX y estáis este fin de semana por Barcelona, no dejéis de visitarnos en la XXXIV RU de MSX de Barcelona, habrá muchas novedades y sorpresas.

miércoles, 19 de noviembre de 2008

Nueva versión del replayer de PT3

Buenas:

Pues eso mismo. Debido a que una de las nuevas músicas que tengo para el QBIQS utiliza la tabla 1, me he visto en la necesidad de volver al código del replayer de PT3 para solucionarlo.

En un principio probé a comprimir las tablas con el BitBuster pero no se comprimen bien, así que deseché esa idea enseguida. La segunda aproximación fue meter las 4 tablas en ROM y cambiar el código de forma que se pasase la dirección de la tabla buena mediante un puntero. Funciona bien, pero ocupa bastante más (no olvidemos que cada tabla ocupa 192 bytes = 2 bytes/nota * 12 notas/octava * 8 octavas).

Así que he vuelto al código original del replayer, ya que éste crea "on the fly" las tablas según la información que tengamos en el fichero PT3. Así que me he puesto un rato... et voilà, ¡nueva versión del replayer!

Diferencias con la anterior versión:
  • Admite cualquier tabla en lugar de sólo una (por defecto viene la tabla 2 en el código).
  • Ocupa 1548 bytes en ROM en lugar de 1448 bytes (100 bytes extra). La primera versión que publiqué ocupaba 1528 bytes en ROM, pero tras volver al código vi que había datos que no se utilizaban nunca, por eso ahora la versión con tabla fija está optimizada.
  • Necesita 576 bytes en RAM en lugar de 384 (194 bytes extra = tabla en RAM + gancho para parchear código automodificable).
  • Hay que quitar los primeros 99 bytes de los ficheros PT3 en lugar de los primeros 100 bytes (en el byte 99 es, precisamente, donde está la información de la tabla utilizada).
Bueno, hay que puntualizar que aunque el aumento de tamaño en ROM no es significativo (aproximadamente un 7% extra), pero quizá 194 bytes de más en RAM (un 50% extra) resulten problemáticos si andamos algo apuradillos de RAM.

Con respecto al código, he cuidado que esté lo más parecido al programa original y he incluído algunos (no tantos como me gustaría) comentarios en la parte nueva que explican un poco por donde va el proceso.

Podéis descargar el fichero en el enlace que hay en la parte derecha. Ahora es vuestro turno: probadlo, usadlo, comentadme si os es útil... :D

¿Retro música?

¿Para qué sirve hoy en día una disquetera? Obviamente, ¡para hacer música!

Pero los envidiosos de los escaners también se apuntan a esta moda, ¡alucinante!

Y ya para rizar el rizo tenemos aquí a una banda completa interpretando Nude de Radio Head

viernes, 14 de noviembre de 2008

Más noticias de la RU de Barcelona

Pues ya tenemos más noticias de la próxima RU de Barcelona. Podemos leerlas en la web de la Asociación de Amigos del MSX:

  • La RU se celebrará conjuntamente con la Game Storming, que es un evento anual sobre videojuegos. Por este motivo el acceso a la RU no será gratuito, sino que costará tres euros, aunque los stands serán gratuitos.
  • La hora de cierre pasa a ser las 7 de la tarde, lo cual es genial porque habrá más tiempo para disfrutar de nuestro hobby.
  • La propia AAMSX ofrecerá a la venta los cartuchos de la MSX Cartridge Shop: Caos Begins, Majikazo, Operation Wolf y Traffic Jam. A estos cartuchos se unen dos nuevos: el Perfect Fit, del cual ya hablé por aquí hace unos días, y un cartucho recopilatorio sorpresa, en tirada limitada y de venta en exclusiva en la RU. En la primera compra que realicemos en el stand de la AAMSX obtendremos un descuento de 3 euros para compensar el precio de la entrada. Hay que recordar que todos los beneficios de estas ventas irán a la propia AAMSX para organizar más RUs.
  • Se organizará un concurso al juego Fighters Ragnarok y el ganador obtendrá un vale por 20 euros a gastar en los stands de la RU.
  • De momento están confirmados los siguientes stands:
    • AAMSX, con los cartuchos ya mencionados a la venta y el stand de 2ª mano
    • SD-SNATCHER, presentando sus utilidades para InterNestor Lite
    • Z80ST-SOFTWARE, llevaré el QBIQS para mostrar los últimos avances del mismo... y alguna otra cosilla si me da tiempo a terminarla
Y seguro que habrá más sorpresas y stands, de momento se que Konamito tiene la intención de montar un stand, seguro que recibiremos noticias de La SeKTa y otros grupos MSXeros que nos harán disfrutar de una sensacional RU.

lunes, 3 de noviembre de 2008

PONG512 adaptado a Spectrum con interfaz TMS9929

Hola de nuevo:

Hace unos días comentaba que existe una interfaz para Spectrum que incorpora el VDP de los MSX1. Pues bien, tras ponerme en contacto con su autor e intercambiar unos cuantos correos, ya está funcionando el PONG512 sin problema alguno en dicha interfaz con unos ligeros retoques en el código fuente.

El juego ahora ocupa casi 5Kb en lugar de los 1007bytes que ocupa el fichero compilado para MSX, claro que hay que tener en cuenta que se requiere una "bios" adaptada y la fuente de letras del MSX (que ya son 2Kb directamente) para que se vea exactamente igual en ambas máquinas.

Una buena noticia que acerca más estos dos ordenadores :D y seguro que no será la última...

Encuesta RU de Barcelona - Resultados

Pues ya se terminó el mes de octubre y el frío se ha instalado por estos lares. La RU de Barcelona se acerca (estamos a escasamente un mes vista) y la encuesta sobre la misma ha finalizado con los siguientes resultados:

¿Vendrás a la RU de Barcelona?

SI: 8
NO: 4
Aun no lo se: 2

Esperemos que los indecisos se animen finalmente a venir a la RU para así pasarlo bien, ya que cuantos más seamos mejor nos lo pasaremos :D

miércoles, 29 de octubre de 2008

¿VHD en MSX?

No, no me he comido la L... Hablo del VHD o Video High Density, un invento que sacó JVC a finales de los 70 (¡hace unos 30 años!) y que no tuvo mucho éxito.

El caso es que la propia JVC sacó algunos modelos de MSX capaces de controlar un reproductor de VHC, con lo que apareció software en este formato (y mira que los LaserDisc ya eran raros). Podemos ver un vídeo en YouTube del VROOM para MSX en VHC, fijáos en el hecho de que el disco iba metido en un caddy (en eso me recuerda al CDTV de Amiga).

Esto me hace pensar en cuantas cosas que se hicieron para los MSX aún nos quedan por descubrir... y no sólo del MSX sino de todos los ordenadores clásicos de 8bits.

lunes, 13 de octubre de 2008

El VDP de los MSX1 funcionando en un Spectrum

Hola a todos:

En este artículo se comenta un interesante experimento hardware que ha consistido en desarrollar un periférico para Spectrum con el chip de vídeo de los MSX1. Al parecer ha sido todo un éxito y es posible, tras una adaptación cuya complejidad dependerá de los casos, utilizar programas de MSX1 en un Spectrum.

Personalmente me parece una iniciativa muy interesante y me gustaría ver también la contraria, es decir, poder pinchar en el slot del MSX un cartucho con un chip de vídeo que permita emular al Spectrum. Ambas plataformas se beneficiarían de estos cacharritos. Estaré atento a las novedades que surjan con respecto a este nuevo hardware.

viernes, 10 de octubre de 2008

Anunciada la XXXIV RU de Barcelona

Vuelven los últimos meses del año y el regustillo a RU, como ya comentábamos, se palpa en el ambiente. Para celebrar las navidades como se merecen, para volver a sentirnos niños una vez más, para ver a los amigos y pegarnos unas buenas risas... se anuncia la XXXIV RU de Barcelona.

De momento lo que se puede confirmar es la fecha y el lugar:

Fecha: 6 de Diciembre de 2008
Lugar: Cotxeres de Sants, sala l'Altell, en la conocida C/ Sants Nº 79

Por lo pronto no hay más información, pero en breve se actualizará la página de la Asociación de Amigos del MSX con datos sobre expositores, concursos, horarios, celebraciones...

Un número mítico donde los haya, no podéis faltar a la trigesimo cuarta RU de Barcelona, ¡y las que quedan aún!

miércoles, 1 de octubre de 2008

Encuesta: ¿vendrás a la próxima RU de Barcelona?

Ya estamos en octubre y eso significa que después viene noviembre y luego diciembre. Tradicionalmente los primeros días de diciembre tienen sabor a RU de Barcelona y, tras el éxito de las dos últimas ediciones (la 32ª en diciembre de 2007 y la 33ª en junio de este año), la 34ª edición (número mágico donde los haya) promete ser bastante interesante.

Por mi parte estaré allí si nada me lo impide. ¿Y vosotros? ¿Vendréis a la RU de Barcelona de diciembre?

Además comenta por aquí qué esperas encontrar y qué te gustaría que hubiera :P

Encuesta Juegos Autoadaptables - Resultados

Bien, hace unos días preguntábamos si los desarrolladores debían aprovechar algunas de las características propias de la generación de MSX donde se ejecutasen sus juegos aunque no estuvieran específicamente diseñados para ellas. Por ejemplo, si un juego de MSX1 debería hacer uso del 9938 en un MSX2 o superior, si se debería activar el R800 en los TR, etc.

Los resultados han sido:
  • No, debería funcionar igual en todas las máquinas: 0 votos
  • No, es más trabajo para sus creadores: 2 votos
  • Sí, siempre que no añada jugabilidad específica adicional: 5 votos
  • Sí, sin duda alguna: 4 votos
Así que por mayoría (9 a 2) la gente opina que sí, que se deberían aprovechar las características de las generaciones superiores, aunque a condición (5 de los 9) de no añadir jugabilidad extra por ejecutarse en una generación superior.

sábado, 27 de septiembre de 2008

Perfect Fit: Nuevo juego para MSX

Un nuevo juego para MSX siempre es una buena noticia, así que no podía esperar para comentarlo aquí:



Paxanga Software, autores de Parachuteless Joe y Yupipati entre otros, presenta un nuevo juego de puzzles para MSX: Perfect Fit. Este juego no es sino una adaptación del juego homónimo que Akuma no Houkon realizó para la consola portátil GP2X.



En este juego contamos con bloques cuadrados de cuatro colores (rojo, verde, amarillo y azul) que deberemos mover para colocar encima de unos círculos de los mismos colores. También tenemos paredes, que no pueden ser atravesadas. Cuando todas las piezas estén sobre círculos de su mismo color, el nivel se habrá completado. Vale, hasta aquí el juego nos recuerda mucho al Sokoban, pero hay algunos cambios:
  • No tenemos que empujar los bloques por detrás, simplemente situaremos un cursor sobre el bloque a mover e indicaremos hacia dónde moverlo.
  • Una vez que movamos un bloque, éste continuará su movimiento hasta que choque con algún obstáculo (otro bloque o una pared). ¡Ojo! ¡Los círculos de colores no detienen el movimiento de los bloques!
El juego es bastante adictivo, los primeros niveles son sencillos pero se van complicando a medida que vamos avanzando. Eso sí, cada cinco niveles resueltos obtendremos un password que nos permitirá volver al punto donde nos quedamos.

Si al final nos han sabido a poco los 75 niveles del modo normal de juego, siempre podemos cambiar al modo extendido, donde aparte de los bloques de colores y las paredes, nos aparecerán otra serie de piezas con las que deberemos interactuar:
  • Flechas: cambian la dirección de movimiento de un bloque.
  • Paredes movibles: si una pieza impacta contra ellas, se moverán una casilla en el sentido del impacto (si está libre) y se convierten en paredes normales.
  • Paredes traspasables: cuando un bloque las atraviesa por primera vez se convierten en paredes.




He tenido el privilegio de probar el juego como beta-tester y puedo asegurar que el modo de juego extendido es bastante más complejo que el modo normal. Cincuenta niveles nos esperan en este modo, os aseguro que es posible terminarlos :D

El menú principal está bastante cuidado, presentándonos las opciones habituales de comenzar, continuar y elegir el modo de juego. Pero también podemos cambiar los gráficos del set de piezas, elegir si queremos jugar con música o no... y lo más divertido de todo: ¡cargar y editar nuestros propios niveles! Se pueden editar y cargar paquetes de hasta 25 niveles con sus propios passwords, lo que da una nueva dimensión al juego, ya que cualquiera puede crear nuevos retos contra los que enfrentarse.



Un juego divertido, con unos gráficos sencillos pero correctos. Todo ello en una ROM de 32kbs para MSX1 disponible gratuitamente en la web de Paxanga Soft. ¿A qué esperáis para enfrentaros al reto de Perfect Fit?

viernes, 26 de septiembre de 2008

Edita tu cinta de cassette

¡Hola!

Pues navegando por ahí, me he topado con un blog donde comentan una web que te permite editar tu propia cinta de cassette, así que no me he podido resistir y aquí está el resultado:



¿A que queda genial? Pues nada, nada, aquí tenéis la dirección de la página para que os hagáis vuestras propias cintas de cassette o de vídeo, vinilos, posters... http://www.says-it.com/

lunes, 15 de septiembre de 2008

Encuesta: juegos autoadaptables

Abrimos otra encuesta: ¿debe un juego aprovechar algunas de las características de la familia de MSX donde se esté ejecutando? Pongamos algunos ejemplos:
  • Un juego para MSX1 que se ejecuta en un MSX2, ¿debería aprovechar el nuevo procesador de vídeo?
  • ¿Se debería activar el R800 si se ejecuta en un Turbo-R? ¿Y usar el PCM?
Ojo, la cuestión no es si se podría hacer (que, obviamente, se puede). La cuestión es si se debería hacer (entendiéndolo como una obligación para los desarrolladores).

Proponemos las siguientes respuestas:
  • No, debería funcionar igual en todas las máquinas.
  • No, es más trabajo para sus creadores.
  • Sí, siempre que no añada jugabilidad específica adicional.
  • Sí, sin duda alguna.
Esta encuesta estará activa hasta final de mes, así que tenéis 15 días para votar.

Encuesta VSU - Resultados

Preguntábamos en la encuesta si un MSX con VSU seguía teniendo el feeling de un MSX. Bien, 10 personas nos dieron su opinión, dejando como resultado:
  • Si: 3
  • No: 7
Es decir, parece que la sensación que produce esta nueva tarjeta en desarrollo es que ya no estaríamos ante un MSX.

miércoles, 3 de septiembre de 2008

VSU

Bajo estas tres letras se esconde una nueva tarjeta en desarrollo para los MSX, la llamada Video Sound Upgrade que incluye:
  • 4 procesadores de vídeo 9990 (gfx9000)
  • 2 procesadores de vídeo 9958 (msx2+ y turbo-r)
  • 1 procesador de sonido OPL4 (moonsound)
  • 3.25 Mb de RAM para los procesadores de vídeo y sonido
En este link se pueden ver diferentes vídeos de las capacidades gráficas de la tarjeta, siempre controlada desde un MSX, claro está. Los seis procesadores de vídeo están, al parecer, conectados en serie y es posible crear, de forma sencilla, diferentes planos de acción. No queda claro si se puede cambiar la prioridad de los procesadores y si la señal de vídeo del propio procesador interno del MSX se puede mezclar en esta tarjeta teniendo la friolera de 7 procesadores de vídeo (cada uno con su propia memoria).

Con respecto a la memoria asignada a cada procesador, nos podríamos aventurar a considerar la siguiente distribución bastante lógica:

512 Kb para cada 9990 -> 2Mb
128 Kb para cada 9958 -> 0.25 Mb

lo que nos deja 1Mb para el OPL4, que no está nada mal.

A falta de más información técnica sobre la tarjeta (así como información sobre el precio, disponibilidad, etc.) nos tenemos que conformar con los vídeos que nos ofrecen en su página. El de la demo hecha en MSX-Basic es espectacular.

Sin embargo esto plantea una pregunta: ¿un MSX con VSU sigue teniendo el feeling de un MSX? Expresa tu opinión en la encuesta :D

¡NOVEDADES! Al parecer la tarjetita va a costar alrededor de los 400 dólares y, además, viene con un pequeño circuito para desconectar el VDP interno, lo cual obliga a modificar aquellos MSX donde quiera usarse.

jueves, 28 de agosto de 2008

QBIQS (VIII) ¡PARTICIPA EN EL DESARROLLO!

¡Saludos a todos nuevamente!

Ya volví de vacaciones y he estado tomándome unos días para poder aclimatarme de nuevo a la rutina diaria. No quería poner nada en el blog mientras no tuviera nada nuevo que poneros, así que hoy me he puesto a programar un ratillo en JavaScript y he hecho un editor online de puzzles para el QBIQS.

Así que ahora todo aquel que quiera puede participar en el desarrollo del QBIQS utilizando el editor y creando puzzles. Para ello simplemente hay que enviar la línea con los datos del puzzle en hexadecimal al correo electrónico que os indica el editor. Yo iré testeando todos los puzzles que enviéis y los iré metiendo en el QBIQS (si son adecuados, claro).

Pues eso, ¡a hacer puzzles! Muchas gracias por anticipado a todos los que se animen :D

viernes, 25 de julio de 2008

¡¡VACACIONES!!

Pues eso mismo: me voy de vacaciones. En el momento de publicación de esta entrada debemos estar despegando de Barajas, así que durante aproximadamente un mes no esperéis noticias por aquí. Necesito desconectar durante un tiempo para volver con más energías para afrontar la vuelta al trabajo y terminar de programar el QBIQS.

Ya os contaré a mi regreso :D

lunes, 21 de julio de 2008

¡Quarth para PS2! ¡Míoooo!

Pues eso mismo, encontré el Quarth para PS2 en eBay y me lo he comprado. Supongo que me llegará mientras estoy de vacaciones, así que en cuanto vuelva ya le echaré un buen vistazo y os comentaré por aquí :D

sábado, 19 de julio de 2008

¿Quarth para PS2?

Pues sí, cuál no ha sido mi sorpresa al descubrir que existe un port del Quarth para Playstation 2 desde hace un par de años. Rebuscando por YouTube me he encontrado el siguiente vídeo.

Lo cierto es que tiene muy buena pinta, a ver si consigo el juego para mi PS2, ya que no deja de ser un hermano mayor de mi QBIQS :)

¿A que mola?

viernes, 27 de junio de 2008

¡¡FELICIDADES!!


¡¡¡FELIZ 25 ANIVERSARIO, MSX!!!


jueves, 26 de junio de 2008

Más asistentes a la MadriSX 25 aniversario

¡Hola de nuevo!

Me acaban de confirmar que, salvo debacle total de última hora, Matra asistirá a la reunión de este sábado y nos traerá un muestrario de sus productos de MSX que a continuación os listo:

CARTUCHOS:
  • Griel's Quest for the Sangraal
  • Saimazoom
  • Phantomas Saga: Infinity
  • Malaika's Prehistoric Quest
  • Night Driver *novedad*
  • Beepertron
  • Magical Stones
  • Sudoku
  • Jungle Hunt
  • Montezuma's Revenge *novedad*
  • Box Boy *novedad*
  • Ink : Exxon Surfing
DISCOS:
  • Sex Bomb Bunny
  • Ark-a-Noah
CASSETTES:
  • Ink
  • Bloody Paws
Un incentivo más para visitar la MadriSX 25 aniversario de este sábado. ¡No os la podéis perder!

miércoles, 25 de junio de 2008

Demo de "The Goonies are good enough"

¡Buenas!

Nuestros amigos de Kralizec nos enviarán una demo de su juego "Goonies are good enough" para que se muestre en la MadriSX 25 aniversario. Recordemos que este juego (que saldrá a finales de este año) saldrá únicamente en cartucho físico de 4Mbits y SCC y se trata de una adaptación a MSX2 de la película Los Goonies.

Os vuelvo a dejar aquí el vídeo promocional del juego que hay en YouTube... vedlo con una fregona cerca para limpiar el suelo ;)

Ya teneis un motivo más para pasaros por la MadriSX de este sábado: poder ver en vivo y en directo la demo de este juego que será uno de los bombazos del año.

martes, 24 de junio de 2008

Nuevo correo electrónico

Pues eso mismo, estrenamos correo electrónico para que podáis poneros en contacto con nosotros:

z80st (puntito) software (arrobita) gmail (puntaco) com

Para cualquier tema del que queráis charlar, ofrecer colaboración, sugerencias... etc. Nos podéis encontrar en dicho correo electrónico.

lunes, 23 de junio de 2008

Actualización de la MSX Cartridge Shop

Nuestros amigos de la MSX Cartridge Shop han actualizado su inventario y nos ofrecen nuevos productos. Comencemos por los tres nuevos juegos que se añaden al conocido Caos Begins:
  • Majikazo, de Lemonize
  • Operation Wolf, de Toy Box Games
  • Traffic Jam, de Imanok
En el apartado Flash aparece una nueva Mega Flash ROM con mapper ASCII8k que permite cargar cualquier tipo de roms (incluso las de 48kbs) e, incluso, imágenes de disco pasadas a ROM gracias a que su capacidad es de 1024kbs (sí, un Megabyte real). Algo que será de utilidad para todos los desarrolladores.

También aprovecho para comentaros que en la próxima MadriSX 25 aniversario estarán a la venta los productos de la MSX Cartridge Shop en el stand conjunto que montaremos Karoshi y Z80ST. Podréis comprar tanto los juegos como las Mega Flash ROM (modelo SCC y modelo 1MB).

¡Os espero el sábado!

viernes, 20 de junio de 2008

Actividades en la próxima MadriSX 25 aniversario

¡Buenas!

Sólo falta una semana para el 25 aniversario del MSX. Recordad que mañana habrá una reunión en Den Dolder (Holanda) y el 28 es la MadriSX especial 25 aniversario en Madrid. El calendario de actividades de esta última incluye:

  • Zona interactiva con ordenadores MSX conectados.
  • Zona museo, con una exposición de varios modelos, accesorios y curiosidades.
  • La MSX Association nos pondrá al día de todo lo que se mueve en torno al MSX.
  • Concurso de Puyo Puyo.
  • Rastrillo de material MSX.
  • La AUIC ofrecerá información sobre sus actividades.
  • MSX-Dev, donde Karoshi y Z80ST ofrecerán al visitante las últimas novedades de este concurso.
  • Taller de emulación MSX a cargo de DC Iberia
  • Conferencias: 25 aniversario del MSX.
También se celebrará una comida especial 25 aniversario de 15 a 17 horas en la Marisquería la Viguesa o algún otro restaurante cercano al Centro Cultural. Si vais a estar por Madrid no dejéis de visitar la MadriSX 25 aniversario, ¡pasaremos lista!


lunes, 16 de junio de 2008

Celebraciones del 25 aniversario del MSX



La MSX-Association ha abierto una página europea donde irá listando todos los eventos que se organicen con motivo del 25 aniversario del MSX.

De momento ya hay dos:
A buen seguro que a lo largo del año irán apareciendo más eventos en esta lista, habrá que estar atento para no perderse las últimas noticias del mundo del MSX. Nuevamente hago un llamamiento a todos los usuarios de MSX de Madrid y alrededores: os esperamos el 28 de Junio en el Centro Cultural El Greco de 10:30 a 18:00.

viernes, 13 de junio de 2008

MadriSX 25 aniversario


¡Buenas!

Coincidiendo (casi) con el 25 aniversario del MSX (la fecha exacta será el 27 de Junio), en la AUIC se está organizando una reunión especial el día 28 de este mes, que contará con la presencia de integrantes de la MSX-Association de Japón.

Allí podrá verse una exposición de diferentes modelos de MSX (algunos de ellos bastante raros y curiosos), colecciones de revistas sobre el estándar, diverso merchandising, competiciones de juegos, charlas... etc. Así que si os gusta el MSX y estáis el 28 por Madrid, no dejéis de pasaros por el Centro Cultural "El Greco", cerca de la estación de metro de Batán. ¡Os esperamos!

A medida que vaya teniendo más información sobre el evento os iré informando.

martes, 10 de junio de 2008

Impresiones de la 33 RU de Barcelona

Bien, ya han pasado unos cuantos días tras la RU de Barcelona y me gustaría dar mi opinión al respecto. El ambiente que se vivía era genial, parecía como si estuviéramos nuevamente en la época dorada del MSX, había multitud de proyectos que se podían ver en público... otros en privado (me considero afortunado de haber visto unos cuantos de éstos).

La gente no paraba de ir de un lado a otro, con material MSX que había conseguido en la RU, o bien que traía para cambiarlo con otros usuarios. Se vieron revistas antiguas (Input-MSX) y modernas (Call-MSX), cartuchos antiguos (me llevé un Maze of Galious con pegatina buena) y modernos (Traffic Jam, Majikazo, Caos Begins y Operation Wolf). Hardware antiguo (un MSX1 y algún MSX2+ en el stand de segunda mano) y moderno (1chipMSX con el logo ESE-System 3).

Parecía que el tiempo se había detenido y que el MSX apenas tenía 5 años de vida en lugar de 25, parecía que estábamos en el momento álgido del sistema y no unos cuantos años después de su "muerte comercial". Nuevos desarrollos de soft y hard se veían por doquier, recopilatorios musicales, gadgets con el logo de MSX (como posavasos e imanes de nevera)...

¿Quién dijo que el MSX está muerto? La gente sigue ahí, al pie del cañón. Vale que ya no es como antes, ya no hay empresas que respalden el sistema, pero multitud de usuarios lo siguen sosteniendo y hemos llegado al vigesimo quinto aniversario por el cual se brindó con cava en la propia RU.

La MSX Dev ha comenzado, siguen presentándose juegos para el concurso de BASIC organizado por Konamito, hay proyectos interesantes para MSX2 ("Goonies are good enough" de Kralizec, por ejemplo), más gente se interesa en aprender a programar...

Momentos como este levantan el ánimo, pero debemos recordar que esto sigue siendo un hobby y que sólo mientras tengamos tiempo lo podremos dedicar al MSX. Ojalá podamos celebrar el trigésimo aniversario con tan buen ambiente :)

lunes, 9 de junio de 2008

Reproductor de sonidos ayFX

Buenas nuevamente:

Hace unos días programé un reproductor de sonidos compatible con el formato ayFX, para el cual existe un sencillo editor (versión 0.4), que nos permitirá crear fácilmente los efectos especiales para nuestros juegos.

Este reproductor incluye un par de extras interesantes:
  1. Prioridad de sonidos. Igual que los sprites tienen su prioridad, los efectos de sonido también pueden tenerla. Si intentamos inicializar un efecto con número de prioridad más alta que el que esté sonando en ese momento, el replayer no hará nada.
  2. Mezcla dinámica de canales. Ideal para utilizarlo con un replayer de música (por ejemplo el PT3). Es una idea experimental que parece que funciona bastante bien y se basa en el hecho de que el PSG es mono, por lo que los tres canales se mezclan en uno único. La idea es que cada interrupción se mezcla el sonido del stream ayFX en un canal diferente del PSG, con lo que la melodía que está sonando no se interrumpe tanto en un único canal. Además, si se utiliza para reproducir un sonido sin que esté sonando música, se crea un efecto de eco bastante interesante :D
El uso del reproductor de sonido es sencillo. En algún punto de la inicialización bastará con hacer

call ayFX_SETUP

para inicializar los valores del reproductor de sonido. Cuando queramos disparar un sonido bastará con cargar su valor en A y luego llamar a la rutina ayFX_INIT. Esta rutina guarda los valores de BC, DE y HL, pero destruye A, cosa que no es importante.

En el bucle principal hay que llamar al reproductor después de haber llamado al reproductor de músicas, ya que la rutina ayFX_PLAY básicamente se dedica a sobreescribir los datos que ha producido el reproductor de música, con lo que al volcar los datos de RAM al PSG ya se vuelcan directamente música y efecto de sonido. Así, por ejemplo, podríamos tener el siguiente código:

call PT3_PLAY
call ayFX_PLAY


y en la propia interrupción (o tras un HALT) la llamada a volcar los valores adecuados en los registros del PSG:

call PT3_ROUT

El tamaño del reproductor es de 200 bytes en ROM y utiliza 9 bytes en RAM. Como siempre, si tenéis cualquier comentario o sugerencia podéis dejarlo por aquí, espero que os sea útil.

jueves, 5 de junio de 2008

MSXdev08

Pues eso, ya está abierto el plazo para la MSXdev08, la sexta edición de este concurso de juegos para MSX1. Seguro que este año hay juegos muy interesantes... por mi parte ya he inscrito el QBIQS :D

viernes, 30 de mayo de 2008

Arranque del VG8010 en BlueMSX 2.7.1

Pues eso, para que no digáis que no cumplo, aquí tenéis un vídeo del arranque de la BIOS que volcamos del VG8010 en el BlueMSX 2.7.1. Como este emulador no soporta la extraña configuración de matriz de teclado que tiene dicho ordenador (así como su antecesor el VG8000), no hay forma de escribir algo coherente.

El mensaje que "se supone" he escrito es el archiconocidísimo "hello world!" y ya véis qué sale, jejejeje.

miércoles, 28 de mayo de 2008

Una nueva tienda de MSX en internet

Pues sí, cual no sería mi sorpresa cuando, trasteando en eBay, me encontré con el anuncio de la tienda de MSX Calamar. Este grupo de MSX es conocido por crear el PSX2MSX, un adaptador de joysticks de PlayStation a MSX.

Al parecer vuelven con fuerza y estrenan tienda en internet (http://www.msxcalamar.com) no dejéis de visitarles, que seguro que nos traerán muchas sorpresas en breve.

martes, 27 de mayo de 2008

Kralizec Goonies

Alucinante lo que nos están preparando nuestros amigos de Kralizec. Se trata nada más y nada menos que un juego basado en la conocida película de Los Goonies para MSX que promete ser uno de los bombazos de este año. Según sus autores es mucho más fiel a la película que el juego que en su día sacara Konami.

Las características del juego serán:
  • Cartucho físico de 4Mbits (512Kb) con música SCC.
  • Juego para MSX2, con soporte opcional para el VDP 9958 (MSX2+ ó Turbo-R).
Si no sucede nada raro el juego estará disponible a la venta este mismo año a través de la MSX Cartridge Shop, pero mientras tanto podemos disfrutar de un vídeo promocional desde YouTube.

lunes, 26 de mayo de 2008

Aleste 520EX y BIOS del VG8000/VG8010

¡Buenas!

Ayer nos reunimos unos cuantos amigos de Madrid para ver el Aleste 520EX, un curioso ordenador ruso híbrido entre CPC y MSX. Estuvimos probando juegos de ambas plataformas y la verdad es que funcionaban bastante bien, aunque en algunos de MSX (como el Vampire Killer) se veía como se redibujaban algunos trozos de la pantalla, fruto de un VDP que emula el 9938. Aquí podéis ver unos cuantos vídeos del ordenador corriendo diverso software. En esta página, podéis ver las características principales de este ordenador y aquí una página íntegramente dedicada al mismo.

También estuvimos volcando la BIOS de un VG8010, un curioso modelo de MSX hecho por Philips que no tiene puerto de impresora. Como no teníamos la fuente de alimentación de este ordenador, tuvimos que sacar el chip y leerlo con un lector/grabador de eproms. Tras varios intentos lo conseguimos y la probamos en el emulador BlueMSX. Curioso es que los colores de arranque no sean exactamente los mismos que en el resto de los MSX1, pero ya que el teclado esté mapeado de una forma completamente diferente al dictamen del estándar MSX es una locura. A ver si grabo un vídeo del arranque y os lo pongo por aquí.

Fue una mañana divertida para celebrar el día del orgullo friki :D

miércoles, 21 de mayo de 2008

Replayer PT3 en ROM con sintáxis asMSX

Creo que el título lo deja todo claro, ¿no?

Os dejo en la sección de descargas (nuevamente agradezco a La SeKTa el que me hayan proporcionado un espacio en su ftp) el código fuente del replayer de PT3 para MSX, con la particularidad de que esta versión funciona desde ROM (no contiene código automodificable) y ha sido adaptada a la sintáxis del asMSX. La eliminación del código automodificable ha sido obra de MSX-Kun, yo me he limitado a adaptarla al ensamblador que utilizo y a compactar lo más posible el código.

Junto al código del replayer he incluído un pequeño programa de ejemplo que, si tenéis un módulo PT3 a mano, genera una ROM y reproduce la canción desde ROM, gastando apenas 382 bytes de RAM, mientras que el replayer ocupa 1528 bytes en ROM. Esta es la versión que, actualmente, se encuentra funcionando en el QBIQS.

No olvidéis que el replayer original fue programado por Sergey Bulba y puede ser encontrado aquí

¡Espero que os sea útil!

viernes, 16 de mayo de 2008

33ª Reunión de Barcelona

Dentro de tres semanas se celebrará la Trigésimo Tercera Reunión de Usuarios de MSX en Barcelona a la que tengo previsto asistir. Allí pondré un stand donde se podrá probar el QBIQS y, además, llevaré un montón de hojas preparadas para que los visitantes dibujen patrones de piezas para ser incluídos en el juego, con el aliciente de poder probarlos in-situ.

Como ya os dije, no podéis perderos esta RU ya que promete ser muy interesante.


martes, 13 de mayo de 2008

Una rutina elegante

Definiendo el problema

El problema consiste en hacer mirroring de 4 nibbles W X Y Z, situados en dos bytes en ram en la forma WX e YZ. El resultado deben ser dos bytes de la forma ZY y XW, vamos, que los cuatro nibbles se han dado la vuelta por completo.

Normalmente leeríamos los bytes en el registro A, enmascararíamos para quedarnos con el nibble inferior, rotaríamos, leeríamos el nibble superior, guardaríamos los nibbles en variables auxiliares y escribiríamos todo después de haber hecho las rotaciones "a mano". Sin embargo yo quería hacerlo más elegantemente, de manera más rápida y, obviamente, con el menor número de instrucciones posibles.

Resolviendo el problema

Empecé por usar HL y DE como punteros, de forma que HL apuntase al primer byte (el compuesto por los nibbles WX) y DE al segundo byte (compuesto por los nibbles YZ). A continuación empecé a escribir instrucciones en la libreta a ver qué pasaba. La primera fue RLD.

¿Qué hace estra instrucción? Rota a la izquierda 4 bits de un número de 12 bits formado por los 4 bits inferiores del registro A y el byte contenido en la dirección de memoria apuntada por HL... Vale, pongamos un ejemplo :D

Si A vale $7E (en hexadecimal) y la posición de memoria apuntada por HL vale $38, al hacer RLD rotamos el número $E38 cuatro bits hacia la izquierda, resultando el número $38E, que vuelve a situarse en los 4 bits inferiores de A y en la posición de memoria apuntada por HL, es decir A valdrá $73 y la posición de memoria apuntada por HL $8E (ojo, siempre que sea RAM, que si no no variaría).

La solución

A partir de aquí el resto de la rutina salió solo. Como quería ir leyendo y escribiendo del contenido de las posiciones de memoria apuntadas por HL y DE se me ocurrió seguir con EX DE,HL instrucción que intercambia el valor de ambos registros. Así, después de un rato emborronando las páginas de mi libreta mientras iba en el metro, salió la siguiente rutina que realiza el trabajo deseado:

RLD
EX DE,HL
RRD
EX DE,HL
RLD
EX DE,HL
RRD
EX DE,HL
RLD

Donde RRD hace lo mismo que RLD pero desplazando a la derecha en lugar de a la izquierda. El valor que tuviera el registro A al comienzo del algoritmo seguirá siendo el mismo al final, igual que los valores de DE y HL, por lo que para utilizar esta rutina no hace falta salvar el contenido de ningún registro.

Y ahora me diréis "vale pero, ¿para qué sirve esta rutina?". Imaginad que tenéis una tabla formada por nibbles y que queréis darle la vuelta, es decir, obtener la misma tabla pero en sentido inverso. Por ejemplo para obtener la imagen especular de un puzzle del QBIQS... :)

¿A que queda elegante?


lunes, 12 de mayo de 2008

¡Más PONGs!

¡Muy buenas!

Aquí os dejo un enlace a un zip que contiene todas las versiones de PONG presentadas al Let's Pong que organizó Karoshi en verano de 2005, entre las que se encuentra el PONG512.


En total encontraréis seis diferentes versiones del juego PONG en 1k, más un extra de una versión extendida de una de ellas en algo más de 1k. Todas las versiones (salvo BONG) con su código fuente listo para ser estudiado por quienes se inicien en la programación en ensamblador.

Como diría un amigo mío (que se que lee este blog): "este enlace vale su peso en langostinos" ;D

lunes, 5 de mayo de 2008

QBIQS (VII) Nuevo vídeo

Lo prometido es deuda, así que aquí tenéis un nuevo vídeo del QBIQS. ¿Qué principales diferencias se pueden ver entre este vídeo y el de hace un año?
  • Punto de mira funcionando
  • Detección de rectángulos, incluso los formados por más de una pieza (combos)
  • Eliminación de rectángulos
  • Marcadores de puntuación
  • Marcador de nivel
  • Indicador de combos
Sin embargo aún quedan muchas cosas por hacer, ya que seguro que os habéis dado cuenta de que los puzzles siguen siendo los mismos (de hecho el mismo) que hace un año. Lo siguiente que me toca hacer es programar el final de cada nivel y a continuación me meteré con el tema de generar los niveles de forma aleatoria, así que los puzzles cambiarán (por fin) en breve.

Espero que os guste, como siempre dejad vuestros comentarios por aquí.

lunes, 21 de abril de 2008

100 juegos de MSX en 10 minutos

Agarraos a la silla porque la moda de los vídeos de 10 minutos con 100 juegos ha llegado al MSX.

Mi colega paulbrk me ha comentado sobre el vídeo que habían hecho entre unos cuantos y que ahora podréis disfrutar gracias a youtube. Divertíos y estad atentos, ya que, si las cuentas no me fallan, apenas tenéis 6 segundos por juego para identificarlos :D

jueves, 10 de abril de 2008

La AAMSX cabalga de nuevo

Lo cual no quiere decir que hubiera dejado de hacerlo, sino que ahora lo hace con mucho más brío.

Una remozada página, sangre fresca y muchas ganas de mejorar las RUs de Barcelona en que la Asociación de Amigos del MSX sea noticia. La próxima RU será el 7 de Junio de 2008, si os pilla por allí y os gusta el MSX no os la debéis perder.

viernes, 28 de marzo de 2008

Más vídeos

Está claro, ¿no? :D

Simplemente comentar que he añadido un nuevo vídeo al canal (podéis verlo en la página principal del blog), en esta ocasión con una partida al PONG512 para aquellos que aún no hayan probado el juego. Aprovecho para comentar que sigo con el desarrollo del QBIQS y que espero poder subir un nuevo vídeo pronto.

lunes, 10 de marzo de 2008

RetroMadrid 2008: récord de asistencia

¡Buenas!

Pues sí, se batieron todas las previsiones, ya que más de 650 personas visitaron la feria.

Personalmente apenas si tuve tiempo de darme un par de vueltas por los stands, por lo que no soy el más indicado para comentar qué se vió por allí. Sólo decir que en mi stand volaron las copias del "CAOS: BEGINS" que me habían enviado, estuvimos mostrando como funcionaba el 1chipMSX con diverso software como el Manbow 2 o el SymbOS.

También se pudo ver una demo del QBIQS que habíamos terminado de pulir la noche anterior (pfufff, hasta las 2 de la mañana depurando código), aunque surgieron un par de bugs que nos hicieron sacar el portátil y ponernos a corregirlos allí mismo. Tras volver de la cena seguimos programando y ayer por la mañana teníamos el motor de juego completo al 100% a falta de añadir animaciones en los momentos adecuados y continuar con el desarrollo del juego (puzzles, músicas, gráficos...).

En fin, que ha sido una feria muy interesante y concurrida, lástima que apenas tuve ocasión de moverme de mi stand para visitar otros, por lo que pido que aquellos que fuérais dejéis aquí vuestros comentarios.

Un saludo!

miércoles, 5 de marzo de 2008

MSX Cartridge Shop

¿Te gusta el MSX?
¿Estás aburrido de los largos tiempos de carga?
¿Quieres divertirte de verdad con tu MSX?

Entonces visita la MSX Cartridge Shop donde se venden nuevos cartuchos de MSX. Se inaugura con la venta del "CAOS: BEGINS", el cual también estará disponible en mi stand en la próxima RetroMadrid.

martes, 4 de marzo de 2008

Cartuchos en venta

Bueno, pues la sorpresa ya puede ser desvelada: en mi stand de la RetroMadrid se podrán comprar cartuchos del "CAOS: BEGINS", el juego ganador de la MSXdev'07.


En esta imagen se puede ver el resultado final del producto, aunque la foto no hace justicia al cartucho en vivo y en directo. Para aquellos que no conozcan el juego, pondré el juego en un MSX1 donde podréis echaros unas partiditas y disfrutar de esta pequeña joya.

sábado, 1 de marzo de 2008

RetroMadrid 2008, comienza la cuenta atrás

7 días y contando...

Dentro de una semana, el sábado 8 de marzo, a estas horas ya habrá terminado la RetroMadrid, una feria de retroinformática que anualmente reune a mucha gente de este mundillo.

Esta feria tiene sus raices en las reuniones anuales de usuarios de MSX en Madrid (llamadas MadriSX) que se abrieron a más sistemas en el año 2004 (pasando a denominarse MadriSX & Retro). El año pasado se alcanzó la nada desdeñable cifra de 434 visitantes, vamos a ver qué sucede este año, pero se presenta interesante y cargada de novedades.

Yo estaré en la feria con un stand donde se podrá ver y probar el QBIQS, además de alguna que otra sorpresita que, de momento, me reservo. Nuevamente hago un llamamiento a programadores de otras plataformas retro: el código del PONG512 es libre por si alguien quiere portarlo a otra plataforma. Podéis venir a mi stand a hablar de ello.

Más información en la siguiente dirección: http://www.retromadrid.es/

martes, 26 de febrero de 2008

QBIQS (VI) La importancia de un bit

¿Un bit puede ser muy importante?

Pues sí, un bit puede significar la diferencia entre un comportamiento totalmente normal o un programa absolutamente descontrolado. Voy a contaros una historia que me ha sucedido con el QBIQS, espero que la encontréis divertida (aunque hasta que encontré el maldito bit no me reía).


Un programa que se dispara a sí mismo

Cuando he ido a enseñarles el juego a unos compañeros, quienes también me dan consejos y prueban la jugabilidad, han empezado a suceder cosas extrañísimas... la primera de todas que el juego reseteó el MSX. Luego, probándolo más nos dimos cuenta de que la música se desincronizaba, a veces se reseteaba todo, otras veces se quedaba colgado... pero siempre el problema estaba en la rutina de música.

Dicha rutina está basada en el replayer del PT3 originalmente programado por Sergei Bulba para Spectrum y adaptado por Dioniso para MSX. Esta rutina se automodifica para ganar velocidad, con lo que su ejecución debe ser en RAM. Me puse a examinar el código, comparándolo con la salida del ensamblador y me di cuenta de que la rutina de decodificación del PT3 había sido modificada de algún modo por otra parte del programa... concretamente ¡por un impacto de un QBIQ lanzado!

¡Hay que hacer bien las cuentas!

La única posibilidad estaba en el último cambio que había hecho cuando uno de los beta-testers del juego me dijo que los disparos iban algo lentos para su gusto. Había modificado la rutina para, en lugar a 2 pixels por frame, moverlos a 3 pixels por frame. Una vez hecho esto estaba obligado a examinar la rutina de anulación del disparo cuando éste se sale de la pantalla.

Originalmente los disparos se anulaban cuando su coordenada vertical valía -9 y yo estaba convencido de que la coordenada de origen era 179. Así que hice un cálculo rápido 179 - (-9) = 188 que no es divisible por 3, pero 189 sí lo es, así que la nueva coordenada de anulación debe ser -10 (que es $F6 en hexadecimal). Probé el disparo y funcionaba bien, así que anoté el cambio y lo di por bueno.

Sin embargo la coordenada de origen era 159, por lo que 159 - (-10) = 169 no era divisible por 3, de modo que los disparos jamás llegaban a tener la coordenada vertical igual a -10, por lo que no se anulaban. Para acelerar los cálculos existen unas tablas de desplazamiento según la coordenada vertical del disparo, pero esas tablas están pensadas para funcionar hasta el valor -15... valor que sobrepasaban los disparos.

Al aparecer coordenadas verticales para las que no estaba previsto el cálculo, los punteros para la tabla no valían y devolvían unos valores erróneos, situando el punto de impacto en una posición fuera de la zona del scroll... concretamente en el replayer del PT3.

Así que la solución ha sido volver a modificar la coordenada de anulación de los disparos, que nunca debía haber cambiado de -9 (cuyo valor en hexadecimal es $F7).

Esta es la historia de como un simple bit (encima el bit de menos peso de un byte) puede marcar la diferencia entre un comportamiento correcto y el caos.

viernes, 22 de febrero de 2008

QBIQS (V) La luz a través de los QBIQS

¡Por fin!

¡Los QBIQS ya están desapareciendo! La rutina de detección del marco maximal funciona y los QBIQS que bajan ya desaparecen al completar los rectángulos. Obviamente hay que hacer unas cuantas pruebas más, pero es genial poder ver que los QBIQS desaparecen por fin tras un par de años de pensar como detectar los rectángulos rellenos...

En cuanto complete la animación del borrado el motor del juego estará prácticamente terminado... ¡YUJUUUU!

Promete ser un fin de semana interesante en materia de programación :D

Toy contento

jueves, 21 de febrero de 2008

QBIQS (IV) Desesperación...

Pues sí... en menudo embolado me he metido con este juego.

Me he visto obligado a reestructurar todo el bucle de juego para el modo de un jugador porque la rutina de detección de marcos es algo más lenta de lo que esperaba. Eso ha supuesto reescribir un par de rutinas del scroll y crear una nueva rutina de volcado de sprites para este modo, con el curioso efecto de que ahora hay dos rutinas de volcado de sprites en este modo, dependiendo de cuantos sprites queramos volcar.

Al final he logrado distribuir algo más uniformemente el tiempo de CPU a lo largo de dos frames consecutivos (4 centésimas de segundo en PAL y 3,333... en NTSC), con lo que he liberado muchísimo tiempo de CPU para poder analizar los choques de los disparos contra los QBIQS que vienen bajando. La rutina de detección de marcos se realiza en cuatro fases, de las cuales están testeadas ya las tres primeras y la última queda a la espera de ser codificada y comprobada. Visualmente todo es igual. Internamente, el cambio más sustancial consiste en que al acelerar el scroll ya no va pixel a pixel, sino de dos en dos. Cosa que apenas se nota (trampantojos nuevamente).

Con un poco de suerte (y un mucho de esfuerzo programando) este fin de semana los QBIQS se podrán borrar de la pantalla, con lo que el motor de juego estará prácticamente terminado, al menos en el modo de un jugador. Me da miedo mirar qué ha pasado en el modo de dos jugadores tras toquetear todo, aunque no debería haber mucho afectado. Veremos qué puedo llevar a la RetroMadrid...

lunes, 18 de febrero de 2008

QBIQS (III) Estado del desarrollo

Bien, ya he comentado de qué va el juego y un poquito del desarrollo, pero aún no he comentado como va el desarrollo del mismo, así que en este post iré mostrando las diferentes actualizaciones, incluyendo datos del tamaño de los gráficos y músicas...

Gráficos

ConceptoDescomprimidoComprimido
1P-ST00960 bytes373 bytes
1P-ST01864 bytes282 bytes
1P-ST02704 bytes215 bytes
1P-ST03976 bytes331 bytes
1P-Marcadores608 bytes268 bytes
2P768 bytes136 bytes
SCROLL5312 bytes1348 bytes
Naves, disparos816 bytes424 bytes
TOTAL11008 bytes3377 bytes

Música

ConceptoDescomprimidoComprimido
MUSICA003059 bytes1131 bytes
REPLAYER1847 bytes1435 bytes
TOTAL4906 bytes2566 bytes

  • Tamaño real de la ROM: 10173 bytes
  • Memoria RAM utilizada: 12877 bytes
Fecha de los datos: 18 de Febrero de 2008

viernes, 15 de febrero de 2008

QBIQS (II) La historia

La historia es importante

Todo videojuego tiene que tener una historia, bueno, no es obligatorio pero los hace algo más interesantes. QBIQS no iba a ser menos. En el QUARTH la historia nos sitúa en el espacio exterior, desde donde se aproximan unas extrañas piezas que amenazan con bloquear la luz solar que llega a la Tierra. No quería que la historia del QBIQS fuese la misma, así que estuve pensando dónde podía ambientarla y por qué extraños motivos esas piezas amenazaban al pobre jugador.

La historia detrás de la pantalla

Y nunca mejor dicho. Toda la acción se desarrolla no fuera de la Tierra, es más, tampoco fuera de la pantalla del monitor. La acción se desarrolla en el interior del tubo de rayos catódicos de un monitor. Además, esto da la excusa perfecta para la decoración del juego ya que todo está ambientado con mosaicos en rojo, verde y azul (RGB que son, además, las iniciales de los tres protagonistas). Aunque no es definitiva, aquí está la historia que ambienta el juego:

¡Los monitores CRT están en peligro! Unas partículas llamadas QBIQS, que se forman en los tubos de rayos catódicos, impiden que los rayos incidan en la pantalla para formar las imágenes. Sólo tres valientes héroes son capaces de limpiar su camino. Toma el papel de Ray, Glow y Beam y limpia el tubo. ¿Sucumbirás ante el poder de los QBIQS?

jueves, 14 de febrero de 2008

QBIQS (I) Los orígenes

Un proyecto largamente pensado

Para empezar a contar la historia de este juego, permitidme parafrasear a la inmortal Sophia Petrillo: "Madrid, 1990...".

Madrid, 1990, concretamente un tórrido mes de julio de 1990, momento en el que cayó en mis manos el número 65 de la revista MSX-Club. En ese número publicaron unos cromos a color con imágenes del QUARTH para MSX2. Me quedé absolutamente fascinado con aquel juego, de apariencia tan simple y adictiva. En aquellos momentos yo sólo tenía un MSX1, por lo que no podía disfrutar de ese juego, por lo que se me metió en la cabeza la idea de programar una versión para MSX1.

Pero en aquellos momentos mis conocimientos sobre programación y sobre el MSX eran escasos, aparte de no tener los medios necesarios como para acometer semejante tarea. Un año y medio más tarde me compré un Amiga 500, por lo que el proyecto de hacer un QUARTH para MSX1 quedó en el olvido durante más de 15 años.

Una vez más he de agradecer a mi amigo Edu Robsy por idear y organizar la MSX-Dev, ya que me proporcionó la excusa perfecta para retomar este proyecto que siempre había estado rondando por mi memoria.

Comenzando punto por punto

Mi sorpresa fue mayúscula cuando, investigando un poco, descubrí la existencia de una versión del QUARTH para MSX1, llamada Block Hole y publicada por Zemina. Lógicamente el primer paso fue buscarla para ver si merecía la pena el esfuerzo de crear una nueva versión de un juego ya existente. Encontré el juego y lo probé. Me encantó el efecto de las estrellas que se desplazan pixel a pixel por debajo de las piezas, aunque éstas se desplazan carácter a carácter (igual que en la versión de 2 jugadores del QUARTH de Konami).

Sin embargo la jugabilidad de la versión de Zemina no es la del QUARTH ni mucho menos.

Así pues me decidí a rescatar el proyecto de hacer un QUARTH para MSX1 y me planteé la posibilidad de que el scroll de las piezas fuese pixel a pixel, ¿sería posible hacerlo en un MSX1? En el juego original los artistas de Konami aprovechan el registro de scroll vertical por hardware que tienen los MSX2 y superiores. De esta forma consiguen ese efecto, pero a costa de que el decorado también se desplaza junto con las piezas. En MSX1 había que hacerlo de otra manera...


La idea detrás del scroll del QBIQS es bastante simple: todas las piezas del juego se componen de 14 diferentes patrones que se combinan de manera adecuada junto con un decimoquinto patrón (el vacío). Sólo tenía que dibujar las combinaciones verticales de dos cualesquiera de estas piezas desplazándolas pixel a pixel, así tendría todos los posibles casos. Problema: 15 patrones dan 225 combinaciones, que a 8 pixels de altura por patrón dan 1800 posibles gráficos... ¡Pero si sólo tengo 256!

Analizando un poco más el problema me di cuenta de que no todas las combinaciones de patrones son válidas, por lo que calculé (por la cuenta de la vieja) aquellas que sí lo eran y todo se redujo a un total de 183 patrones. Dejé reservados 200 patrones por si (que va a ser que sí) me hacían falta más y me puse manos a la obra para ver aquello moviéndose.

Una vez dibujados los patrones, el siguiente paso fue diseñar una rutina que se encargase de volcarlos de forma adecuada en la tabla de nombres, así conseguiría el efecto visual de un scroll pixel a pixel. La cosa, que parece complicada, no lo es en absoluto, ya que con 8 tablas de 256 bytes el volcado se agiliza un montón. Me llevó toda una tarde el diseñar esas tablas (en depurarlas tardé un poco más de tiempo pues con el paso de las semanas iban saliendo los errorcillos que había), pero mereció la pena porque las piezas ya se desplazaban pixel a pixel y con la suficiente soltura como para que el juego funcione sin problemas a 60hz.

Terminaré esta introducción al QBIQS comentando que en el QUARTH original, las piezas tienen un color diferente en cada nivel, por lo que programé una rutina que permite cambiar los nibbles de una tabla en ram (aquí descubrí lo útiles que resultan para estos menesteres las instrucciones RRD y RLD). Si utilizamos esa rutina sobre una tabla de colores conseguimos el efecto deseado.

Continuará...

lunes, 11 de febrero de 2008

PONG512 (II) El desarrollo

Buenas de nuevo:

A continuación voy a destacar aquellos detalles que considero más interesantes sobre el desarrollo del juego, al mismo tiempo que hago referencias al código fuente del mismo por lo que, si estás interesado en conocer el funcionamiento interno de algunas rutinas, te recomiendo que te descargues el código y leas lo siguiente con el código al lado.

El desarrollo

Al principio todo fue muy rápido, ya que en apenas una semana ya tenía listo el engine de cambio aleatorio de tableros (ver código fuente, etiqueta RANDOM) y las dos paletas moviéndose bajo la acción de los cursores y joysticks (rutinas MOVEPLAYER1 y MOVEPLAYER2).

Hacer que la pelota rebotase contra las paletas también fue sencillo. Tanto las paletas como la pelota son sprites por hardware y, por su movimiento relativo, sólo pueden existir choques entre una paleta y la pelota. El hardware y la BIOS del MSX hacen muy bien el trabajo de detectar colisiones de sprites, dejando en la posición F3E7h el valor del registro de estado del VDP. Si el quinto bit está activo se ha producido un choque con una paleta, momento en el que hay que cambiar el sentido de la velocidad horizontal de la pelota (de esto se encarga la rutina BATREBOUND).

Pero no basta con invertir el sentido de la velocidad horizontal, ya que es en este punto cuando el ángulo de la velocidad cambia, según la posición relativa de la paleta y la pelota en el momento del choque. Aquí debo agradecer a mi amigo WYZ que me cediera amablemente la rutina que él había usado en su propia versión del PONG (el acceso a la tabla de ángulos se encuentra, también, en la rutina BATREBOUND).

Una vez llegados a este punto y con la rutina de movimiento de la pelota (MOVEBALL) que trabaja en aritmética de punto fijo (8 bits de parte entera y 8 de parte decimal para conseguir un movimiento más suave), ya se podía jugar a darle golpes a la pelotita... la cual seguía empeñada en atravesar los muros.

Detección de colisiones con los muros

Esta fue la rutina que más tiempo me llevó, ya que quería que resultara lo más aproximada a la realidad. La versión que está incluída en el juego (bajo la etiqueta WALLREBOUND) es la tercera que intenté, ya que las dos primeras siempre daban problemas en las esquinas.

La idea fundamental consiste en comprobar si se ha de cambiar el signo de alguna de las componentes de la velocidad de la pelota (horizontal y vertical). Para ello se comprueba si el carácter bajo la pelota en ese momento (que se obtiene mediante la rutina GETCHAR) la hace rebotar o no. En el peor de los casos, la pelota puede estar sobre cuatro caracteres diferentes, por lo que se calculan las coordenadas de las cuatro esquinas del sprite que la representa, pero un pixel hacia el interior de la pelota (para así simular que es redonda y no cuadrada). Se obtiene el carácter bajo esa posición y se realizan los cálculos para comprobar si hay que hacer un rebote o no.

La rutina WALLREBOUND, que realiza este trabajo, está dividida en cuatro rutinas bastante similares: @@UL, @@UR, @@LR y @@LL, que comprueban, respectivamente las esquinas superior izquierda, superior derecha, inferior derecha e inferior izquierda. Fue aquí donde eché de menos tener más registros, por lo que tuve que echar mano del conjunto alternativo de registros del Z80, utilizando el par BC' para incrementar o decrementar el signo de las componentes horizontal y vertical de la velocidad de la pelota.

Cada vez que un carácter bajo la pelota forma parte de un muro, se incrementa o decrementa b' y c' para indicar cuál sería la velocidad relativa de la pelota tras chocar contra ese carácter de forma individual. Este cálculo se repite para los cuatro caracteres y al final los signos de b' y c' son, respectivamente, los signos de las componentes horizontal y vertical de la nueva velocidad. Veamos como funciona el algoritmo al extenderlo a más de un carácter:

Si los caracteres que se encuentran bajo la pelota son A, B, C y D (para las esquinas superior izquierda, superior derecha, inferior izquierda e inferior derecha respectivamente), entonces el signo de la velocidad según los choques es el siguiente:

  • Choques contra un único carácter:
    • A -> +x, +y
    • B -> -x, +y
    • C -> +x, -y
    • D -> -x, -y
  • Choques contra dos caracteres:
    • AB -> 0, +2y
    • CD -> 0, -2y
    • AC -> +2x, 0
    • BD -> -2x, 0
  • Choques contra tres caracteres
    • ABC -> +x, +y
    • ABD -> -x, +y
    • ACD -> +x, -y
    • BCD -> -x, -y
Es fácil ver que la extensión del algoritmo funciona cuando la pelota choca contra uno, dos o tres caracteres. Si no chocase contra ninguno, tanto b' como c' serían iguales a 0, lo que significa que no hay que variar la velocidad. Esto también sucede si los cuatro caracteres forman parte de un muro, cosa que, por construcción del tablero y del juego, es imposible. Por lo tanto el algoritmo de detección de choques contra los muros funciona perfectamente.

El resto del programa no tiene mayor complicación, ya que es bastante fácil de seguir. El bucle principal se limita a llamar a las rutinas en orden. La única complicación es seguir el flujo del programa cuando se marca un gol, ya que se llama a una subrutina que se encarga de reinicializar todos los valores para volver a las posiciones iniciales de las paletas y la pelota, para finalmente retornar al bucle principal y continuar la partida.

También la zona de datos puede resultar algo confusa, porque para ahorrar tamaño, muchos de los datos son compartidos por más de un concepto (como es el caso de los tres últimos bytes de la definición del carácter del muro, que también son la definición del muro completo sin agujeros).

Descarga

En breve estará disponible una zona de descargas donde se podrán descargar todos los juegos, utilidades y códigos que vayan apareciendo en el blog... sed pacientes :D

martes, 5 de febrero de 2008

PONG512 (I) La historia

¿Cuánto pueden dar de sí 1024 bytes?

En realidad, 1024 bytes dan para bastante más de lo que se podría pensar en un principio. Esta historia comienza en julio de 2005, cuando a los locos de Karoshi les dió por organizar un concurso para programar un clon del PONG en, como máximo, 1KB (1024 bytes).

Este minijuego es el resultado de mi participación en dicho concurso, así como mi primer juego para MSX (después de todos los que hice de pequeño en BASIC, aunque esos no salieron de mi habitación).

Remontándose a los orígenes

Personalmente guardo muy buenos recuerdos de mi infancia con respecto al PONG, recuerdos que me incluyen a mí y a mi padre jugando en el bar de unos amigos con una de esas maquinitas de PONG que se conectaban a la tele. Como una de mis motivaciones para programar videojuegos es intentar que todo lo relacionado con los juegos clásicos sea heredado por las siguientes generaciones (acostumbradas ya a los chorrocientosmil polígonos texturizados moviéndose al mismo tiempo en la pantalla) me animé a refrescar mis conocimientos del ensamblador del Z80 y a programar un clon del que se considera el pionero de los videojuegos, aunque puede que no lo sea. Veamos un poquito de historia:

Según el criterio que sigamos, podemos encontrar a dos padres de los videojuegos. El verdadero padre se considera que fue Steve Russel, quien programó el primer juego de ordenador, Space Wars, que funcionaba en un PDP-1.

Sin embargo, el padre "legal" de los videojuegos fue Ralph-Baer, un alemán educado en los Estados Unidos. Fue él quien desarrolló y patentó los primeros videojuegos que se podían conectar a un televisor en blanco y negro. Un gran inventor, pero un mal vendedor. Su patente terminó en 1970 y un par de años después Philips convirtió el juguete de Baer en la primera consola doméstica de la historia: la Magnavox Odyssey.

En 1971 Nolan Bushnell hizo una versión del Space Wars, juego que conoció y jugó en su época de estudiante, para ser jugada en lugares públicos. Sin embargo Computer Space no tuvo el éxito esperado y fue reemplazado por un juego mucho más simple, mucho más adictivo y mucho, pero muchísimo más conocido: el PONG.

Cabe mencionar la anécdota que rodea a la primera máquina de PONG de la historia, que fue devuelta desde el bar Andy Capp's porque creían que era defectuosa, cuando en realidad estaba bloqueada pues el monedero se había llenado de monedas y no aceptaba más.

El concepto del juego

Un juego muy simple a la par que adictivo, dos factores que me terminaron de convencer para coger el ensamblador y ponerme a teclear instrucciones como un loco. Pero tras más de 14 años sin haber tocado el ensamblador del Z80 la tarea no iba a ser sencilla.

Una costumbre que tengo (mala o buena, eso aún no está claro) es que no me pongo a tirar una sola línea de código hasta que no tengo muy claro el concepto del programa completo o de alguna parte significativa del mismo. Si no lo hago así luego me toca retocar bastante y ya se sabe que no es fácil controlar los bugs cuando andas cambiando diferentes partes del código.

Ya desde el primer momento se me ocurrió no hacer una versión totalmente fiel a la idea original, puesto que quería añadir algún tipo de funcionalidad extra que le diese una nueva dimensión al juego, sin cambiar por completo el espíritu del mismo. La idea definitiva surgió al recordar alguna versión del PONG que se conectaba a la televisión, concretamente aquellas que venían con varios tableros que se presentaban como juegos diferentes.

Así pues nació la idea de que los tableros no fueran estáticos, sino que pudieran sufrir alteraciones durante el juego. Los muros laterales eran sencillos, ya que aparecerían diversos tipos de barreras que dificultarían la tarea de marcar un gol, pero algo tenía que hacer con los muros superior e inferior. Nada más simple: si sincronizaba ambos muros podía hacer que la pelota desapareciera por arriba para reaparecer por abajo (y viceversa). Había nacido el concepto inicial del PONG512.

¿Qué se esconde tras el nombre?

PONG512 es, ante todo, un PONG, pero al mismo tiempo se ha de distinguir del original por el tema de los tableros cambiantes. Hay cuatro muros que pueden cambiar de forma, aunque como dos de ellos están sincronizados, en realidad podemos contar tres muros que cambian. Si cada uno de ellos tiene 8 posibles formas, en total hay 8x8x8=512 combinaciones de tableros.

Instrucciones

¿Existe alguien que en algún momento de su vida no haya echado una partida al PONG o a alguno de sus derivados? Para jugar a PONG512 hay que seguir el mismo mecanismo: controlar tu paleta moviéndola verticalmente para colarle la pelota al contrario y evitar que él te la cuele a tí. El cambio de tableros se realiza simplemente pulsando el botón, momento en el que alguno de los muros cambiará aleatoriamente... o no... ¡quién sabe!

El jugador 1 puede jugar con los cursores y la barra de espacio o con el joystick en el puerto 1. El jugador 2 jugará siempre con el joystick conectado al puerto 2. Mientras la pelota se encuentra en movimiento se puede salir del juego sin más que pulsar la tecla ESC, lo que nos devolverá al BASIC del MSX.

Continuará...