lunes, 22 de marzo de 2021

¿Programación de juegos de 8 bits en 2020?

¿Alguna vez te has preguntado cómo se desarrollaban videojuegos en los años 80? Los ordenadores de la época eran muy diferentes a los que tenemos hoy en día, ¿cómo se harían juegos similares en la actualidad? Acompáñanos en este viaje a los 80 donde trataremos los ordenadores MSX y los lenguajes BASIC y ensamblador del Z-80, además de repasar las limitaciones técnicas de aquel entonces a la hora de desarrollar videojuegos. 

Charla impartida el 18 de diciembre de 2020, en la Facultad de Informática de Murcia y organizada por el Club GameDev. Si te la perdisteis hora tienes la oportunidad de verla.




domingo, 7 de marzo de 2021

Archer10 (Apple II). Submission to the 2021 10-Liner Contest

Some weeks ago I had notice of a retro programming contest, yes through one of these wasap groups, the 10th Edition of BASIC 10 Liner Contest. The main idea is that you develop a game in BASIC with no more than 10 lines of code for 8 bit legacy computers. There are different categories depending on the maximum number of characters per line allowed. Simple, isn't it? I decided to go for a try, and made a MSX-1 program which I submitted to the contest. You can find a detailed description of the program in Archer 10 (MSX). Submission to the 2021 10-Liner Contest. After I finished, I asked myself: why not an Apple II port? Although I developed some programs in the 80s for Apple II, those were mostly CP/M with the Microsoft BASIC. You can find an example in Recuperación de código MBASIC para Apple II desde listados (it is in Spanish, but you can get the idea from the many pictures. Google translate might also be of some help). Anyway, it is never late for learning. And I had the appropriate material for getting into the job:

  • D. Finningan (2012) The New Apple II User's Guide. Mac GUI, Lincoln, IL (book)
  • M.L. Callerey, R. Schwarz (1984) Apple Graphics Tools and Techniques. Prentice-Hall (PDF)
I decided to mimic as much as possible the MSX-1 program mentioned above and develop an AppleSoft BASIC one. I had a gameplay and a sample 10-liner source code. That should be more than enough. I wanted to keep high resolution graphics, colors and sounds, even if those for the MSX were a little bit weird (disclaimer: I am very bad at gaming, coloring and music. The perfect combination :-).


The programming

The first thing I learned is that double high resolution graphics is not available to BASIC. And standard resolution graphics is crazy on coloring, not to mention the small available palette. Anyway, this did not prevented me to going ahead. Because of the small program size, complex sounds are also out of the game. Well, let's go for a simpler and less visually attractive version, but with the same gameplay I decided for the MSX-1 version.

I started to code right from the beginning thinking on a 10 lines program, with the experience of the MSX version. But because there were less graphical possibilities, I tried to enter the PUR-120 category. No way.  I had to reduce even more the visual aspects, and I wanted to support a minimum of them. Thus I ended up in the EXTREME-256 category. In addition to only ten lines of code, each line must not contain more than 256 characters. Overall, the code can not be larger than 2.5 Kb !!! To squeeze the code in this size you play the very old tricks. The BASIC interpreter uses a lexical analyzer that is based on keyword detection and not in delimiters. This basically means that you can write the code without white spaces. Who cares about readability !!! Then you use one-letter variables and single-digit line numbers (after all, remember, you can not use more than 10 :-). 

This was standard stuff in 10-liners. When you have to actually code the gameplay, all of a sudden, you get the headaches. First thing is AppleSoft BASIC does not have ELSE statements. The typical strategy is to leave conditionals at the end of lines, and use ELSEs to better manage decisions (in term of program space and lines usage). Soooo ... you have to decompose decisions and break them apart into different lines. Tricky, isn't it? Let's see.

The code

Lines 0 to 3 initialize the program and do all graphics background drawing and shapes definition. The order in which instructions are performed are related to the available line space. I tried different combinations. One interesting and important thing is that only line 3 is needed to replay, so you can GOTO 3 when the game is finished to start a new one.

Line 9 performs the text updating. It is coded in the form of a subroutine which is called at game initialization and whenever there is a hit or a fail.

Lines 4 to 8 implement the gameplay. They manage arrow and target movement, user input and scoring. The hit or fail of the arrow is checked in lines 6 (hit) and 7 (fail). Line 8 just closes the game loop. Should ELSE statements are available, this single-statement line would not be needed. Line 7 plays a nice trick. When the game is over, the game loop continues but arrow throwing is disabled. Until you press the space key and the game is re-initialized.

Lines 8 to 9 contain DATA definitions for the graphic shapes coded in decimal. These statements are put at the end of actual code, so we can make benefit of characters available in those lines. I tried to get rid of any character which is not ASCII standard. As I develop both on my Mac and on my Apple IIe, doing otherwise would produce me many headaches trying to preserve character coding.

The state of the game is coded using the following variables:
  • Y (Float): vertical position of the target in pixels. Varies in the 34 .. 125 range
  • S (Float): amount in pixels which is added/substracted to Y at each time step. It controls the velocity of the target. Its initial value is 1.0. Each time a hit occurs it is increased by 0.25 
  • X (Integer): horizontal position of the arrow in pixels. Varies in the 200 .. 32 range
  • D (Integer): linear distance between the arrow y position and the target y position
  • G (Integer): total score achieved
  • F (Integer): number of fails
  • H (Integer): score of the last hit, derived from D
  • B (Integer): state variable representing whether the arrow is moving (B=1) or not (B=0)
  • Q (Integer): state variable representing whether the game is active (Q=0) or not (Q=1)
I finally had a code of 1.7 Kb, in 10 lines of BASIC, with standard ASCII character coding. Nice. Goal achieved. You can find the code, a simulator disk file (DSK) and some multimedia materials here:


Instructions

You are a top-notch archer in the "Outdoor Archery World Series. Moving Target". You throw an arrow by pressing the space bar, and cannot throw a new one until it either makes a hit or a fail. The target moves so you have to carefully synchronize the arrow throwing with the target movement. The target speed gets increasing with each hit. You get points for each hit depending of how close the arrow gets to the target center. You are allowed a maximum of 3 failures, in which case the competition finishes and you get your final score. To start a new game press the space bar.



Are you ready? Can you make more than one hundred points? Let's try it.

Download the file archer10.dsk from GitHub and drag&drop it on the Drive 1 icon on the Virtual II emulator (a fantastic application by Gerard Putter, which is worth the price of the paid version). Once the disk is loaded, type the following command in the console and then press INTRO:

RUN ARCHER10.BAS

The game has sound, so remember to enable audio in your computer.

Enjoy playing!!



miércoles, 3 de marzo de 2021

Archer 10. Participación en el 2021 10-liner Contest


Hace algunas semanas tuve noticia de un concurso de programación retro, si, a través de uno de esos grupos de wasap, el 10th Edition of BASIC 10 Liner Contest. La idea principal es que tienes que desarrollar un juego en BASIC que no ocupe más de 10 líneas de código para cualquier ordenador original de 8 bits. Hay diferentes categorías dependiendo del número máximo de caracteres por línea permitidos. Sencillo, ¿verdad?. Decidí darle un tiento. Pensé "vamos, si son sólo 10 líneas de código, esto no puede ser muy complicado". No podía estar más equivocado. En este artículo explicaré qué y cómo he desarrollado mi participación en la edición de este año (2021), que he llamado Archer10.

El juego

Puesto que era la máquina con la que aprendí, decidí ir a por un programa MSX-1. Llamémosle nostalgia. Claro que, además, es la máquina que mejor conozco. Una vez decidido el equipo, la siguiente cuestión es pensar en un juego. Como no soy bueno en los juegos, decidí plagiarme yo mismo. Comencé con algunas ideas prestadas de Barcelona 92, un programa en BASIC que desarrollé cuando tenía 15 años y fue publicado en la revista MSX Club de Programas nº 3-4 (1985).

Después de algunas reflexiones-no-muy-profundas acabé con una idea sencilla de mecánica de juego: un blanco a la izquierda se mueve hacia arriba y hacia abajo. Controlas un arquero en la derecha que lanza flechas que se mueven de derecha a izquierda. Si impactas el blanco consigues puntos dependiendo de cómo cerca del centro lo haga. Tienes permitido un número máximo de fallos, tras los cuales el programa finaliza. Cuanto mayor sea la puntuación, mejor. Bien, bastante sencillo, pero un juego al fin y al cabo. Y presenta varias posibilidades que puedo explotar. Algo que no me gusta de muchos juegos es que son difíciles desde el principio. Como soy muy malo en los juegos, esto no facilita el que los pruebe. Así que decidí que el juego fuera sencillo al principio (el blanco se mueve muy despacio). Pero según se progresa, la dificultad se va incrementando poco a poco (al principio no se aprecia) de forma que tras algunos aciertos se torna realmente difícil. Y la restricción en el número de fallos hace que quieras repetir de nuevo e intentar superarte.

Estupendo. Ya tengo una idea de juego. Ahora a por la parte visual. Quería mostrar algunas de la estupendas características de los ordenadores MSX-1, por lo que decidí incluir gráficos en alta resolución (lo que se conoce como SCREEN 2 en el mundillo MSX), sprites por hardware, y sonido. Con profusión de colores, por supuesto (descargo de responsabilidad: no soy daltónico, pero definitivamente no soy bueno coloreando). Y, cómo no, también sonidos (descargo de responsabilidad: soy tan bueno con la música como con los colores).

La programación

Comencé programando una maqueta del programa sin restricciones, con un montón de líneas, para tenerlo funcionando. Quería asegurarme de que se pudiera jugar como yo quería. Después trabajé los gráficos para evitar la colisión de atributos de color (típico del procesador de vídeo de los MSX) y a la vez mostrar la mayor parte de la paleta de colores disponible. Básicamente tenía unas cien líneas de código y unas 3 Kb de espacio de programa. Definitivamente demasiado para un 10-liner.

Debido a los gráficos tenía claro que requeriría bastante espacio de programa. Además, mostrar texto en una pantalla gráfica requiere de muchas instrucciones que ocupan bastante espacio de programa. Y definitivamente quería texto. Sin compromisos.

De esta forma decidí participar en la categoría EXTREME-256. Además de sólo diez líneas de código, cada línea no debe de contener mas de 256 caracteres. De forma global ¡¡ el programa no puede ocupar más de 2.5 Kb !!. Para encajar el código en este tamaño hay que utilizar todos los viejos trucos. El intérprete BASIC utiliza un analizador léxico que está basado en la detección de palabras clave y no en los delimitadores. Esto significa que puedes escribir todo el código sin espacios. ¡¡¡ A quien le importa la legibilidad !!! Además, hay que usar variables con una sola letra y números de línea de un sólo dígito (después de todo, recordad, no puedes usar mas de diez :-).

Con esto consigues un código BASIC muy compacto, con la menor cantidad de espacio de almacenamiento posible. Esta es la parte fácil. Pero aún hay más, ya que hay que implementar la mecánica del juego que involucra acciones y decisiones. Cuando se programa tendemos a pensar en secuencias lógicas (o al menos eso deberíamos hacer) que acaban plasmándose en el uso de sentencias GOTO, y con el objetivo de mejorar la claridad, también GOSUB. El problema aquí es que debido al reducido número de líneas el uso de GOTOs y GOSUBs es muy limitado. Así que, en lugar de pensar en secuencias lógicas, donde tienes decisiones y acciones claramente aisladas, tienes que intercalar estas en el poco espacio disponible, incluyendo la mayor cantidad posible en una línea de código. Es un ejercicio de programación muy interesante que habitualmente no se practica.

El juego

Si digo que al final acabé con diez líneas de código, esto no debería ser una sorpresa. No hay spoiler. Las líneas 0 a 3 inicializan el programa y hacen todo el pintado del fondo gráfico y la definición de los sprites hardware. El orden en el que se realizan las instrucciones esta relacionado con el espacio disponible en las distintas líneas de código, paro lo que probé distintas combinaciones. Una cuestión interesante es que sólo se necesita la línea 3 para reiniciar el juego, de forma que se puede hacer un GOTO 3 cuando se acaba la partida.

Las líneas 4 a 7 implementan la mecánica del juego. Gestionan el movimiento del blanco y de la flecha, la interacción con el usuario y el puntaje. Tuve bastante suerte y pude implementar una subrutina en la línea 7, que se llama mediante un GOSUB 7 cada vez que la flecha llega a la parte izquierda de la pantalla (ya sea un acierto o un fallo). La línea 6 utiliza un truco muy interesante. Comprueba tanto el final de la partida como la reinicalización del juego (después de pulsar la barra espaciadora). Lo último mediante una llamada a GOTO 6. Esto produce una corrupción del estado del juego, pero como ya ha finalizado, ¡a quien le importa!. Cuando posteriormente se hace un GOTO 3 el estado del juego se inicia correctamente.

Las líneas 8 a 9 contienen las definiciones DATA para los sprites hardware codificados en hexadecimal. Debo señalar que esta NO es la forma más eficiente de almacenar esta información. Se pueden utilizar cadenas de caracteres, pero he sacrificado un poco de almacenamiento de programa (que al final no necesité) por la codificación de caracteres. Puesto que habitualmente desarrollo tanto en mi Mac como en mi Sony HB-F700S la copia entre estos preservando la codificación de caracteres es muchísimo mas simple así.

El estado del juego se codifica por medio de las siguientes variables:
  • Y (Float): posición vertical del blanco en pixeles. Varía en el rango 30 .. 135
  • S (Float): cantidad de pixeles que se le añaden/sustraen en pixeles a la Y en cada instante de tiempo. El valor uncial es 1,0. Cada vez que s produce un acierto se incrementa en 0,25.
  • X (Integer): posición horizontal de la flecha en pixeles. Varía en el rango 200 .. 22
  • G (Integer): puntuación total conseguida
  • F (Integer): número de fallos
  • H (Integer): puntuación del último acierto. Calculada como la distancia lineal entre la posición y de la flecha y la posición y del blanco. 
  • B (Integer): variable de estado que representa si la flecha está en movimiento (B=1) o no (B=0)
Finalmente conseguí un código de 2.1 Kb, en 10 líneas de código BASIC, y codificación de caracteres en ASCII estándar. ¡¡ Estupendo!!. Objetivo conseguido. Puedes descargar el código, un archivo de disco para simulador (DSK) y diverso material multimedia desde:


Instrucciones

Eres un arquero de alto nivel en la "Liga Mundial de Tiro con Arco al Aire Libre. Blanco Móvil". Lanzas flechas pulsando la barra espaciadora, y no puedes volver a lanzar hasta que aciertas el blanco o fallas. El blanco se mueve por lo que tines que sincronizar con cuidado el lanzamiento de la flecha con el movimiento del blanco. La velocidad del blanco se va incrementando con cada acierto. Consigues puntos según lo cerca que queda la flecha con respecto al centro del blanco. Tienes permitido un máximo de 3 fallos, en cuyo caso la competición finaliza y obtines tu puntuación final. Para iniciar un nuevo juego pulsa la barra espaciadora durante más de un segundo.

Estás listo? Puedes conseguir más de cien puntos? Vamos a ello.

Descarga el archivo archer10.dsk de GitHub y arrástralo a la consola azul de WebMSX (una aplicación estupenda de Paulo Augusto Peccin). Aparece una ventana emergente y entonces selecciona Drive A. A partir de ahí el simulador carga la imagen de disco y se queda a la espera de recibir comandos. Teclea el siguiente comando y después pulsa INTRO:

RUN "ARCHER10.BAS"

¿Demasiado complejo?

He preparado una página web que automáticamente carga y ejecuta el programa en WebMSX. Sigue este enlace para jugar en línea.

El juego tiene sonido, así que recuerda habilitar el audio en el ordenador.

¡¡¡ Disfruta jugándolo !!!




sábado, 27 de febrero de 2021

Archer10. Submission to the 2021 10-Liner Contest



Some weeks ago I had notice of a retro programming contest, yes through one of these wasap groups, the 10th Edition of BASIC 10 Liner Contest. The main idea is that you develop a game in BASIC with no more than 10 lines of code for 8 bit legacy computers. There are different categories depending on the maximum number of characters per line allowed. Simple, isn't it? I decided to go for a try. I though "come on, it is only 10 lines of code, it can not be of much pain". I could not have been more wrong. In this post I will explain what and how I developed my submission for this year edition (2021), which I have named Archer10.

The gameplay

Being the machine I learned with I decided to go for a MSX-1 program. Let's call it nostalgia. Well, and it is the machine that I actually know more of. Once the machine is settled, next thing is thinking on a gameplay. I am not good at all with games, so I decided to perform some plagiarism of myself. I started with some ideas borrowed from Barcelona 92, a BASIC program I developed when I was 15 years old and was published in the magazine MSX Club de Programas nº 3-4 (1985).

After some not-too-deep-thinking I came up with a very simple gameplay: a target on the left moves up and down. You control an archer on the right who throws arrows from right to left. If you hit the target you get points depending on how close to the center the arrow impacts. You are allowed a maximum number of fails. Then the program finishes. The larger the final score, the better. Well, quite simple, but definitively a game. And it has some nice features I can exploit. Something I dislike of many games is that they are very hard from the beginning. Being very bad at gaming, this disallows me from trying them. So I decided the game at the beginning was to be very easy (the target moves very slowly). But then, the difficulty gets increasing little by little (you hardly notice the difference at first) so that after some throws it gets really difficult. And the constraint in the number of fails makes you to try again to increase your score.

Good. I had a gameplay. Now the visual part. I wanted to expose some of the very-nice-features of the MSX-1 machines, so I decided to include high resolution graphics (known as SCREEN 2 in MSX jargon), hardware sprites, and sound. With plenty of colors, of course (disclaimer: I am not color impaired, but definitively I am not good at coloring). And weird sounds as well (disclaimer: I am as good at music as I am at coloring).

The programming

I started coding a mock up of the program without constraints, with many lines, to get it up and running. I wanted to make sure the gameplay was as I intended. Then I worked the graphics so to avoid the color attribute clash (typical of the MSX-1 video processor), but at the same time displaying most of the available color palette. I roughly had over a hundred lines of code with some 3 Kb of program space. Definitively too much for a 10-liner.

Because of the graphics I was sure I needed quite a lot program space. In addition having text in a graphics screen is quite a lot program space consuming. And I definitively wanted some text. No compromises allowed. 

Thus I decided to enter the EXTREME-256 category. In addition to only ten lines of code, each line must not contain more than 256 characters. Overall, the code can not be larger than 2.5 Kb !!! To squeeze the code in this size you play the very old tricks. The BASIC interpreter uses a lexical analyzer that is based on keyword detection and not in delimiters. This basically means that you can write the code without white spaces. Who cares about readability !!! Then you use one-letter variables and single-digit line numbers (after all, remember, you can not use more than 10 :-). 

Now you get a very compact BASIC code with the minimum of program storage needed. This is the simple stuff. But there is more than this, you have to actually code the gameplay, which involves actions and decisions. When programming we tend to think on logical sequences (at least, we should do that) which end up coded using control structures with GOTOs and, for the sake of clarity, with GOSUBs. The problem here is that with the reduced number of lines available GOTOs and GOSUBs are of very limited use. So instead thinking on logical sequences, where you have actions and decisions clearly isolated, you have to interleave all of them, fitting as much as posible in a single line of code. It is a very interesting programming exercise that you do not typically practice.

The code

If I say I finished up with 10 lines of code, this should not be of great surprise. No spoiler here. Lines 0 to 3 initialize the program and do all the text and graphics background drawing and hardware sprites definition. The order in which instructions are performed are related to the available line space. I tried different combinations. One interesting thing is that only line 3 is needed to replay, so you can GOTO 3 when the game is finished to start a new one.

Lines 4 to 7 implement the gameplay. They manage arrow and target movement, user input and scoring. I was lucky enough to implement a single subroutine in line 7, with is called as GOSUB 7 each time the arrow reaches the left part of the screen (being it a hit or a fail). Line 6 plays a very nice trick. If checks for both the end of the game and the reinitialization of it (after pressing the space bar). The later issuing a GOTO 6. This corrupts the state of the game, but as it has finished, who cares!!!. When you do GOTO 3 the game state is correctly initialized.

Lines 8 to 9 contain DATA definitions for the hardware sprites coded in hexadecimal. I must say this is NOT the most efficient way of storing this information. You can use string literals, but I sacrificed some program storage (with I finally did not need) for character coding. These literals might (and do) contain characters which are not ASCII standard. As I develop both on my Mac and on my Sony HB-F700S it produced me many headaches while copying to and from and trying to preserve character coding.

The state of the game is coded using the following variables:
  • Y (Float): vertical position of the target in pixels. Varies in the 30 .. 135 range
  • S (Float): amount in pixels which is added/substracted to Y at each time step. It controls the velocity of the target. Its initial value is 1.0. Each time a hit occurs it is increased by 0.25 
  • X (Integer): horizontal position of the arrow in pixels. Varies in the 200 .. 22 range
  • G (Integer): total score achieved
  • F (Integer): number of fails
  • H (Integer): score of the last hit. Computed as a linear distance between the arrow y position and the target y position
  • B (Integer): state variable representing whether the arrow is moving (B=1) or not (B=0)
I finally had a code of 2.1 Kb, in 10 lines of BASIC, with standard ASCII character coding. Nice. Goal achieved. You can find the code, a simulator disk file (DSK) and some multimedia materials here:


Instructions

You are a top-notch archer in the "Outdoor Archery World Series. Moving Target". You throw an arrow by pressing the space bar, and cannot throw a new one until it either makes a hit or a fail. The target moves so you have to carefully synchronize the arrow throwing with the target movement. The target speed gets increasing with each hit. You get points for each hit depending of how close the arrow gets to the target center. You are allowed a maximum of 3 failures, in which case the competition finishes and you get your final score. To start a new game hold the space bar for more than one second.

Are you ready? Can you make more than one hundred points? Let's try it.

Download the file archer10.dsk from GitHub and drag&drop it on the blue console of WebMSX (a nice application by Paulo Augusto Peccin). A pop up window appears and select Drive A. Then the simulator loads the disk and it is ready to accept commands. Type the following command in the console and then press INTRO:

RUN "ARCHER10.BAS"

Too complex? 

I have prepared a web page which automatically loads and executes the program in WebMSX. Follow this link to play online

The game has sound, so remember to enable audio in your computer.

Enjoy playing!!




domingo, 20 de diciembre de 2020

Reparación del cabezal del plotter SONY PRN C-41

De siempre me ha gustado este fantástico plotter, el SONY PRN C-41, y me hacía ilusión conseguir uno. En su día no pude tener uno (se me iba de presupuesto), aunque si que pude hacer alguna cosa a través de conocidos. Uno de mis primeros trabajos era dar clases de CAD, y me encantaban los plotters.

Lo he adquirido recientemente junto con un juego de plumillas originales, con la tinta en perfecto estado, lo cual tiene mérito después de tantos años. Al ponerlo en marcha verifico que todo funcione, y eso parece. Sin embargo al cargarlo con las plumillas estas no llegan al papel, por lo que no pintan. Descargo manuales, observo la cabeza y ... el martillo que baja la plumilla está roto. Es una pieza muy pequeña y el plástico después de tanto años se ha rigidizado en exceso.

Estudio el asunto y decido fabricar uno parecido mediante impresión 3D. Lo primero tomar medidas, darle vueltas en el CAD, imprimir, probar, verificar y vuelta a empezar. A continuación se pueden ver algunos de los intentos.

Después de numerosas pruebas llego a un diseño que es poco práctico, pero es lo mejor que he podido hacer. 

El problema de este diseño es el ajuste con el resto del cabezal: no tengo posibilidad sencilla de hacer un pasador de 0.05 mm de diámetro, ni forma fácil de conseguirlo. Lo soluciono mediante una pequeña chapucilla: pego el martillo al cabezal mediante una notita de cianocrilato, con cuidado de que no rebose y pueda pegar algún elemento del cabezal. El resultado del montaje se muestra a continuación.

¿Y cómo ha funcionado? Pues razonablemente bien. Para probarlo he hecho un sencillo programa en BASIC para probarlo. A continuación se muestra un vídeo del plotter haciendo una prueba de impresión.

Por último, una imagen del resultado en el papel.


El modelo 3D del martillo de la plumilla está disponible de forma gratuita en:

Thingiverse: https://www.thingiverse.com/thing:4691872

domingo, 22 de noviembre de 2020

Recopilación de juegos BASIC en cartucho.

Tras terminar de rescatar todos los listados de programas en BASIC para ordenadores MSX que conservo de los años 80, que son sólo una parte de los que hice, me he planteado hacer una recopilación en cartucho. Esto, que en su día era impensable de forma artesanal, en la actualidad es bastante sencillo y barato debido a las herramientas software y hardware disponibles. Vamos a hacer un repaso de cuales son y cómo funcionan. Lo primero es seleccionar los programas que tenemos disponibles, que están descritos en diversas entradas de este blog:

La idea fundamental es crear un disco con los programas y a partir de él generar una ROM que se almacenará en un cartucho con una FlashRAM. Y ya está. Sencillo, no? Como dijo Jack el Destripador, vamos por partes.

Creación del disco

Necesitamos crear un disco MSX-DOS en el que cargaremos los archivos necesarios para arrancar el sistema operativo, para ejecutar nuestros programas, y, obviamente, los programas que queremos almacenar. 

Comenzamos formateando un disco físico de 3.5" en el propio ordenador MSX, en este caso 2DD (doble cara y doble densidad). Grabamos los archivos de sistema necesarios para que el disco sea autoejecutable:

  • COMMAND.COM
  • MSXDOS.SYS
  • AUTOEXEC.BAT

En este último escribimos el nombre del programa que queremos que se ejecute. En el caso, como el que nos ocupa, de que este programa esté escrito en BASIC el contenido de este archivo será:

BASIC nombre.BAS

Por último grabamos todos los programas y archivos que hemos desarrollado y queremos incluir en nuestra recopilación. Comprobamos que el disco arranca correctamente y que todo funciona bien. En mi caso, he preparado una etiqueta para darle un aire semi-profesional. Este es el aspecto:


Una vez que este paso está superado, copiamos todos los archivos a nuestro ordenador y creamos una imagen de disco. Para ello podemos utilizar una imagen que previamente tengamos (podemos borrar todos los archivos), podemos utilizar un emulador de MSX, o podemos utilizar la herramienta DiskMgr, de Rudolf Lechleitner. Con cualquiera de estos métodos creamos un archivo que llamaremos recopila.dsk.

Una vez creada la imagen de disco, vamos a utilizar la herramienta dsktool, de Ricardo Bittencourt, que es capaz de trabajar con archivos de imagen de disco en formato FAT12. Aunque se podrá hacer también con DiskMgr, yo prefiero esta porque es de línea de comandos y puedo automatizar algunos procesos mediante shell-scripts. Para añadir el primer de los archivos haremos:

dsktool a recopila.dsk COMMAND.COM

Y después repetimos con el resto de los archivos de nuestro disco físico. Llegados a este punto ya tendremos la primera etapa terminada. Para verificar que todo está correcto vemos el contenido de la imagen:

dsktool l recopila.dsk

que nos muestra la siguiente salida por pantalla:

DskTool v1.30 (C) 1998 by Ricardo Bittencourt

Utility to manage MSX DOS 1.0 diskette images (3.5"360/720Kb).

(2010) Updated by Tony Cruise

(2017) Updated by NataliaPC

This file is under GNU GPL, read COPYING for details


Disk image size:  720Kb

Standard format


Name of volume:   SNYJX101


COMMAND.COM      6656 14/10/2020  7:23:04 ----

MSXDOS.SYS       2432 14/10/2020  7:23:04 ----

AUTOEXEC.BAT       21 15/11/2020 12:51:36 ----

EXAMEN.BAS       3775 22/11/2020 11:19:44 ----

LECCION.BAS     22432 22/11/2020 11:23:02 ----

PRESENT.BAS      2044 22/11/2020 11:19:14 ----

BCN92.BAS       11182 21/11/2020 21:57:24 ----

CRAZYP.BAS      14736 22/11/2020 11:26:00 ----

SKRAM.BAS        9175 22/11/2020 11:52:18 ----

RECOPILA.BAS     1087 22/11/2020 11:24:00 ----


652288 bytes free


Ya solo nos queda probar la imagen en un emulador. Yo utilizo OpenMSX que es el que más me gusta. Con esto nos aseguramos que hemos creado la imagen correctamente, y que en el emulador tenemos lo mismo que en el ordenador real. Y con esto terminamos esta etapa.

Creación de un cartucho

Comenzaremos con crear un archivo de imagen ROM a partir de nuestra imagen de disco. Para ello utilizaremos el programa dsk2rom, de Vincent van Dam. El funcionamiento es muy ingenioso. Este programa crea una ROM con un driver virtual para acceder al sistema de ficheros de la imagen un disco almacenado en memoria. Como el tamaño de la imagen de disco es mayor que la memoria máxima direccionable por el Z-80, el propio programa incluye diferentes mappers para esta operación. Además, permite utilizar el compresor Pletter para reducir el tamaño de la imagen.

El funcionamento es muy sencillo. Simplemente lo invocamos con los parámetros adecuados. En este caso utilizaremos el mapper ASCII de 8 bits y el nivel de compresión 2 para Pletter. Estas opciones nos valdrán para la mayoría de casos. Lo invocamos de la forma:

dsk2rom -asfc 2 recopila.dsk RECOPILA.ROM

Lo siguiente es probar la imagen de la ROM en un emulador. La cargamos en el OpenMSX y tras el proceso de arranque de la máquina se muestra la pantalla de inicio del programa. Probamos todas las opciones y comprobamos que la ROM es correcta.


Ya solo nos queda la operación más delicada de todo el proceso, la grabación del cartucho. Esta operación hay que hacerla en el propio ordenador MSX. Debemos de tener algún dispositivo de almacenamiento que nos permita tener tanto el programa de carga como nuestra imagen ROM. Debido al tamaño necesitaremos utilizar por lo menos un disco de 3.5".

Existen diferente modelos y tipos en el mercado, con más o menos memoria, mappers, etc. En general son dispositivos con una FlashRAM donde se almacena la imagen de la ROM, y una electrónica para comunicarse a través del puerto de expiación del MSX. En este caso he optado por un cartucho multimapper de 2Mb distribuido por Carmeloco. Junto con el cartucho nos proporciona el programa cargador de la flash.


Como se puede observar la placa tiene una serie de jumpers. Estos son fundamentales para las distintas operaciones. Comenzaremos cargando la flash. Para ello hay que abrir el puente PRG y cerrar el puente A16. Introducimos el cartucho con el ordenador apagado y lo encendemos. Cuando cargue el dispositivo de almacenamiento donde tenemos la imagen, utilizamos el comando:

FL16 RECOPILA.ROM

El proceso dura unos minutos. La salida del mismo es la siguiente:

Tras los cuales apagamos el ordenador, cerramos el puente PRG, quitamos el puente A16 y cerramos el puente A8. Metemos la placa dentro de la carcasa del cartucho, y lo volvemos a insertar en el ordenador, este apagado.  En mi caso le he añadido una etiqueta y me ha quedado semi-profesional.

Ya solo resta encender y ... voilà, a disfrutar de un cartucho personalizado.



El código fuente y las imágenes de disco y ROM están disponibles en GitHub:

https://github.com/humbertomb/mymsx/tree/master/recopila

domingo, 15 de noviembre de 2020

Anatomía del Aparato Digestivo. Programa didáctico

Este programa escrito en BASIC para ordenadores MSX1 (1985), con una extensión considerable,  Anatomía del Aparato Digestivo, es un programa didáctico con lecciones y test. Lo escribí conjuntamente con dos compañeros de instituto Antonio Alcántara Lapaz y Julian Alcántara Lapaz y fue nuestra participación en el I Concurso de Programas MSX (1985), organizado por Sony España, y cuyo premio se falló en 1986.

Aunque era una buena idea, no teníamos las herramientas (ni probablemente conocimientos) para  hacerlo suficientemente sólido. El problema fundamental que nos encontramos era su extensión. Para poder encajar los diferentes diagramas del aparato digestivo y sus textos explicativos tuvimos que utilizar las 28k disponibles en MSX BASIC. Para ello hubo que simplificar excesivamente la mecánica y, además, no incluir una instrucciones de uso en el programa (que no eran muy evidentes). Dicho lo cual, creo que fue un programa faraónico, con la dificultad de hacerlo por trozos y entre varias personas, y haciendo los gráficos en papel y su posterior digitalización a mano. En mi caso, además, mi ordenador Sony HB-55P sólo tenia 16k de memoria, y me dejaba unas 12k en MSX BASIC, por lo que sólo podía trabajar con fragmentos pequeños. Para poder realizar la integración del programa acomplejo me tuvieron que dejar una ampliación de memoria de 64K.

Como el resto de los programas de la época, no lo conservo en forma digital. Sólo disponía de un listado apergaminado. Al contrario del resto de entradas de este blog, y teniendo en cuanta la extensión del listado, he utilizado una estrategia más profesional. Siguiendo el modelo descrito en Recuperación de código MBASIC he digitalizado y pasado por OCR el listado completo. Una vez en el editor de texto innumerables iteraciones de corrección de código y ejecución, sobre todo dejándome los ojos en los comandos DRAW de los listados. Como no me apetecía recorrer el camino de almacenar el programa en cinta, lo he fragmentado para poder ser ejecutado desde diskette, ya que el MSX DISK BASIC solo deja 24k de memoria libre. Aprovechando esto, he añadido una fundamental pantalla de instrucciones, que es la única diferencia con respecto al programa original. Y ya de paso le he preparado una etiqueta, que le da un aire casi profesional.




Pasemos a hablar del programa. Es un programa didáctico básico, muy sencillo y sobrio de aspecto, pero con una cantidad de información bastante elevada (por ello su tamaño en BASIC). Técnicamente no es muy complejo (no hay ensamblador ni manejo directo del VDP), su gran dificultad el modo en que se desarrolló y su tamaño. El programa está organizado en lecciones sobre la anatomía y funcionamiento del aparato digestivo:
  • Cuerpo entero
  • Boca
  • Dientes
  • Esófago-Estómago
  • Hígado-Páncreas
  • Pared Intestinal
  • Intestino
Al usuario se le presenta la opción de seguir en continuo todas las lecciones de forma secuencia o de forma individual. En cada lección se presenta un diagrama de la parte estudiada, con referencias a las distintas partes de la anatomía, y una o varias pantallas con textos explicativos de las funcionalidades de los elementos. Una vez revisados todos los contenidos, el usuario puede realizar una evaluación tipo test para comprobar su conocimiento de los contenidos. Las preguntas de este test no son nada triviales, y no es fácil superarlo si antes no se han leído bastante bien las explicaciones de las lecciones.






El código está disponible en GitHub:

lunes, 19 de octubre de 2020

Recuperación de código MBASIC para Apple II desde listados

Suele ocurrir que hayamos perdido el material en soporte magnético (ya sean cintas o disquetes) de programas desarrollados en los años 80. Si entonces fuimos algo cuidadosos (cosa habitual, porque era fácil  tener problemas con los soportes y los lectores de la época) es posible que conservemos el código en formato papel, más parecido al pergamino que otra cosa. Llegados a este caso, y si queremos recuperar esas joyas de la historia (o que simplemente les tengamos cierto cariño), no tenemos más remedio que optar por una de dos opciones: a) ponernos como locos a copiar código (tarea nada agradecida, sobre todo con presbicia, que sin duda tendremos si el código de los 80 es nuestro), b) echar mano de la tecnología para automatizar en lo posible el proceso. 

Cuando empece a recuperar el material de los 80 para MSX seguí el camino "a", no por falta de usar tecnología, sino porque en su día no di con la combinación adecuada y de forma fiable. Ahora sí lo he conseguido con la "b", de forma bastante fiable, robusta y práctica. Lo que no quita para que el proceso no sea ni mucho menos automático, pero sí mucho más productivo que la otra opción. 

Para ilustrar el proceso vamos a partir del programa de matriculación de alumnos del I.B. Jiménez de la Espada que desarrollé sobre 1985-1986 en lenguaje MBASIC para el ordenador Apple IIe con sistema operativo CP/M. Fue el primer programa de matriculación que se utilizó en el instituto, y yo debería de tener unos 16 años. De entonces conservo un tocho de papeles que son los listados de los programas, que intuyo que son versiones finales, y lo sabré cuando finalice al 100% el proceso de recuperación. El aspecto de los mismos es el siguiente:


Pues bien, en esta entrega voy a describir el proceso que he seguido para recuperar dichos códigos. Aunque en este ejemplo utilizo código BASIC de un Apple II, el proceso es aplicable a otros sistemas de la época, y lo estoy utilizando también tanto para BASIC y ensamblador Z80 de MSX.

Como se puede observar en la imagen anterior, se trata de una impresión matricial, donde el papel está amarronado (en este caso habiendo estado muy bien conservado, sin que le diera la luz), y con la tinta bastante descolorida. Lo primero antes de nada es tratarlo digitalmente para conseguir un mayor contraste. Para este trabajo he utilizado la herramienta Graphic Converter, que es una especie de Photoshop en pequeño, y cuya herramienta "Niveles Automáticos" produce el siguiente resultado:


El siguiente paso es utilizar un programa OCR para extraer el texto de la imagen. En la actualidad hay OCRs a patadas, muchos de ellos gratuitos y con una calidad de reconocimiento bastante aceptable. El problema que presentan la mayoría es que no están preparados para reconocer este tipo de caracteres, y producen resultados tan malos que no sirven para nada. Y en esas estaba atascado hasta que por casualidad  leí que Google tenía un OCR gratuito integrado en su herramienta. Me pongo a ello. Subo la imagen a una carpeta de mi Drive de Google. La selecciono y la abro con la herramienta Google Docs. Esta detecta automáticamente que es una imagen y extrae de la misma todo el texto en bruto, sin saltos de línea y dejando un único espacio en blanco, produciendo el siguiente resultado:


Ooooooh !!! Pues no es un código directamente ejecutable, pero el texto tiene bastante información para ahorrarnos un trabajado tremendo. Como se puede observar, se han cambiado algunos símbolos, han desaparecido otros, y de vez en cuando alguna letra o número se han alterado. La confusión del cero "0" y la letra "O" es un clásico. También el uno "1" y la letra "I". Llegados a este punto, usar una herramienta simple y adecuada para la edición de código es muy interesante. En este caso utilizo el editor de programación Geany, que incluye coloreado de sintaxis para una gran cantidad de lenguajes de programación. En concreto incluye BASIC, lo que nos va a hacer la tarea más sencilla indicándonos visualmente muchos errores de transcripción. Las palabras clave de BASIC las colorea, por lo que si alguna no sale en color, es que hay un error. Así se cazan las alteraciones de GOTO, por ejemplo, donde una de las letras es un número. Es un BASIC genérico, y no lleva colorización de comandos específicos de MBASIC o AppleSoft BASIC, como VTAB y HTAB, que serán un porcentaje muy pequeño del total de comandos que se usarán. 

Copiamos el texto de Google Docs a Geany, e introducimos un salto de línea antes de cada número de línea de código. Algo que se hace muy rápida y sencillamente a mano. El resultado es el siguiente:


Ya solo nos queda trabajarlo un poquito, verificando con el listado en papel. El trabajo requiere un poco de dedicación, pero la productividad es muy grande. Una vez verificado, el resultado es el siguiente:


Con todo y con eso, todavía tendremos algunos errores, pocos, que se nos habrán escapado, y, además, tenemos que pasarlo a un formato que nos permita cargarlo en un ordenador de esa época. Para esto tenemos alguna alternativa muy tediosa, que incluye tener que hacer toda la depuración en al Apple II, cuyo editor de BASIC es más bien pedestre, o bien utilizar un emulador de la máquina en sí. En este caso decidí usar el emulador Virtual II que es una maravilla. Aunque se puede utilizar de forma gratuita con ciertas limitaciones, la versión completa de pago es fundamental para este trabajo. Sólo con la facilidad y esfuerzo que nos ahorramos se paga sólo. Entre otras opciones permite emular la tarjeta Microsoft SoftCard CP/M, que es necesaria para ejecutar el código MBASIC. El proceso de trabajo es muy sencillo. Cargamos una imagen de disco 5 1/4" con el Sistema Operativo CP/M y el intérprete de MBASIC. Hay un montón de webs para descargar las imágenes. Entre ellas la Apple II CP/M Library y la Apple II Asimov. Aparte de la imagen que necesitamos hay literalmente cientos de imágenes. Ejecutamos el emulador y cargamos la imagen de CP/M. Al arrancar entramos en el intérprete de MBASIC, como se muestra en las siguientes capturas de pantalla del Virtual II:


Tan solo nos queda hacer copia y pega del código desde Geany hasta Virtual II. El pegado se hace simulando la entrada desde teclado, por lo que es equivalente a teclear el mismo código en la interfaz del MBASIC. Este lo entiendo, a todos los efectos, como si lo estuviéramos tecleando. Esto es mu conveniente por dos razones. Por un lado podemos pasar todo el texto de Geany al intérprete de MBASIC de una tacada. Ya solo esto es fundamental, tal y como podemos ver en la siguiente captura:


Pero una vez que lo tenemos copiado, donde verdaderamente podemos alcanzar unas cotas bastante altas de productividad es cuando ejecutamos y depuramos. En lugar de editar en el emulador, editamos en Geany cada vez que detectemos un error, y hacemos copia y pega solamente de las líneas que acabamos de modificar. Verdaderamente cómodo. Después de sucesivas iteraciones con el OCR, con el editor y con el emulador conseguimos recuperar el código sin problemas. ¿Que cómo queda el resultado? Pues un programa de gestión no es muy agradecido, pero bueno, aquí van un par de capturas de pantalla:






jueves, 8 de octubre de 2020

Modernización de un Apple IIc

Después de una temporada sin cacharrear con ordenadores antiguos, ahora le toca el turno a un Apple IIc que tenía guardado, fabricado en 1986. En mi época de bachillerato aprendí a realizar programs de gestión (con bases de datos) en un Apple IIe. Como aún no tengo uno (en su día eran carísimos), pretendo recuperar los programas que hice en su día con el Apple IIc, que los conservo sólo impresos en papel. Para poder recuperarlos es imprescindible (para mi salud) poder interactuar con el Apple IIc y con mi ordenador de trabajo. Buscando en Internet encontré la unidad Floppy Disk Emulator de BMOW (Big Mess 'O Wires), que permite utilizar una memoria SD como almacén de floppys de 5 1/4", que permite ser instalada en un Apple IIc (que no tiene puertos de expansión como el resto de los Apple II).

El dispositivo es muy cuco. Lo compré con su caja, con el adaptador Iic, y con un emulador de sonido (una tarjeta con un relevista que se activa al ir accediendo a los distintos sectores del disco).


Lo recibí a los pocos días de comprarlo, y me puse manos a la obra. Primero desmontar el ordenador. La tapa superior es fácil quitarla, pero hay que llevar mucho cuidado con las pestañas de plástico, que al tener tanto años ya no son tan flexibles. Una vez quitada la tapa accedemos al interior.


Para instalar el adaptador sólo hay que desconectar el cable de la unidad de disco, insertar la placa nueva y conectar el cable original por el otro lado. 



Esta unidad tiene como opción la capacidad de arrancar el ordenador con el floppy original o con el emulador. Para hacer la selección tenemos un cable que hemos de sacar fuera del ordenador. Para ello se  puede utilizar el hueco de la ranura del conector DB del disco. El hueco es pequeño pero suficiente. 



Cerramos la tapa del ordenador. Conectamos la unidad emuladora y el simulador de sonido, configuramos la SD (me venía preconfigurada con el firmware de emulación de disco de Apple II). Una vez listos arrancamos el ordenador, seleccionamos el disco que queremos insertar y ... voilà !!!. El ordenador arrancando con el DOS 3.3 en la unidad D1 (emulada).



Además, podemos utilizar la unidad de 5 1/4" original a la vez, en este caso como unidad D2. Para probarlo inserto un diskette con un pequeño programa BASIC que he recuperado de un listado de 1986. Y así luce casi 35 años después.


miércoles, 12 de junio de 2019

aMazeing. Programa para generar juegos (1)

Después de copiar el listado del juego Cuarta Dimensión (que ya comenté en esta entrada del blog) me quedé con ganas de ver cómo funcionaba originalmente. Faltaba la parte en ensamblador, y los movimientos de los sprites eran muy burdos. Me decidí entonces a hacer una revisión del mismo y hacer un juego simple pero jugable. Sin embargo, me daba mucha pereza hacerlo al estilo ochentero.

La solución que se me ha ocurrido es programar la herramienta aMazeing, para generar automáticamente juegos con scroll horizontal a partir de la definición de los elementos más importantes: pantalla base, juegos de caracteres, y mapa del laberinto o cueva. Para ello he ido desarrollando una aplicación sencilla que está escrita en el leguaje de programación Java.

La aplicación está en un estado muy preliminar, por lo que iré describiendo los avances de la misma en otras entradas del blog. Y cuando esté terminada la subiré a GitHub.

De momento sólo permite especificar la aplicación en SCREEN 1, y podemos definir el juego de caracteres (patrones) así como los colores de los patrones, y definir el mapa del juego, estableciendo los patrones que aparecerán en las distintas posiciones del mapa. Ahora mismo sólo se puede generar código en BASIC.

Lo primero que se hace es ir editando la tabla de patrones, que en el modo de pantalla SCREEN1 tiene 256 caracteres diferentes, cada uno con dos colores: uno para la tinta y otro para el papel. Y los colores de los caracteres se agrupan en bloques de 8, por lo que tenemos como máximo 32 combinaciones de color diferentes. Se puede modificar la paleta estándar de MSX, que está formada por 16 colores distintos.



La edición de cada patrón es muy sencilla. Por un lado se modifican los pixels, indicando si son papel ("0") o tinta ("1"). Después se especifican los colores para la tinta y el papel.


Una vez que tenemos definidos los patrones, editamos el mapa, y situamos en el mismo los patrones que queremos que aparezcan. Todas estas tareas eran muy muy tediosas en su día, y contar con una herramienta para poderlo hacer de forma gráfica es muy conveniente.


Finalmente, generamos el código del juego. Ahora mismo sólo genera código BASIC, bastante optimizado, pero como se puede apreciar, con desplazamiento muy lento.



El código del programa generado está disponible en GitHub:
 https://github.com/humbertomb/mymsx/tree/master/amazeing/DIMENS41.BAS

Cuarta Dimensión. Juego de scroll horizontal

Mi tercer programa con cierta complejidad (1987), Cuarta Dimensión, juego tipo scroll horizontal programado en BASIC y ensamblador Z80 para ordenadores MSX1. No se publicó, y no tuvo ninguna distribución. Fue más que nada una prueba de concepto.

Como el resto de los programas de la época, no lo conservo en forma digital. Sólo he encontrado un listado apergaminado con la parte del programa en BASIC. Y no he encontrado nada de la parte en ensamblador, que es la que realiza los movimientos. Con paciencia lo he ido tecleando en mi Sony HB-700S y he conseguido recuperarlo algunas cosas. La versión del listado no es muy estable, y he te nido que reprogramar el desplazamiento en BASIC.

Pasemos a hablar del juego. Es el típico juego de scroll en una cueva/laberinto, muy sencillo de aspecto y sin un argumento de juego desarrollado, ya que la idea era aprender la técnica para hacer desplazamientos en ensamblador con manejo directo del VDP en el modo SCREEN 1. No tiene música, y el único efecto sonoro son las explosiones. Este juego lo hice con 17 años, cuando estaba aprendiendo a programar en ensamblador, y toda la parte gráfica la hacía pintando primero en una libreta con hojas cuadriculadas.



El código está disponible en GitHub:
 https://github.com/humbertomb/mymsx/tree/master/dimens4