¡VAPF!


¡Vete al peo, Fede!

Lecturas: Queremos su dinero

Hace algunos meses que estuve en la presentación del libro "Queremos su dinero", y no solo por la amistad que tengo con su autor, Jesús Martínez del Vas, sino porque el tema realmente me interesaba. Así que era cuestión de tiempo que cayera en mis manos para leerlo. Lo tenía en la lista de los Reyes Magos, pero sus majestades no han tenido a bien regalármelo. Así que ha sido mi amigo Miguel quien me lo ha prestado para poder leerlo. Como en los viejos tiempos.

Queremos Su Dinero - Jesús Martínez del Vas
Queremos Su Dinero - Jesús Martínez del Vas

El libro, que se puede leer prácticamente de una sentada, nos cuenta de una manera novelada y, sin entrar en detalles "técnicos", la vida profesional de José Luis Domínguez, durante tres etapas bien diferenciadas: sus primeros pasos profesionales como vendedor, la época Indescomp - Amstrad España y sus negocios después de vender la empresa a Alan Sugar. Todo ello a partir de los testimonios del propio protagonista.

Es cierto que quien se haya interesado por la figura de Domínguez en estos últimos años, este relato no va a descubrir nada que no se haya publicado ya en diferentes entrevistas (1, 2), ya sea en páginas web del ámbito de la retroinformática o en podcasts, como la entrevista que le hicieron en El Mundo Del Spectrum. Sin embargo, me parece muy pertinente la publicación de este libro en cuanto a que, al estar a la venta en librerías y comercios generalistas, puede estar accesible a un público mucho más amplio, que quizás al ver la palabra AMSTRAD en la portada del mismo recuerde aquellos ordenadores o minicadenas de los 80 que se colaron en muchos de nuestros hogares.

Al hilo de la lectura se me ocurren un par de reflexiones. La primera, sobre toda la parte industrial y comercial relacionada con los productos informáticos (y con la venta en general). Todo lo relacionado con importaciones, exportaciones, cadenas de montaje, pruebas, servicio técnico, aranceles, cartas de compra, financiación, marketing, etc. Es un mundo muy complejo donde casi lo de menos es el ordenador en sí. Es lo de siempre, puedes tener un producto genial, que si no eres capaz de hacerlo sostenible y que la gente se entere de que existe y quiera comprarlo, no vale para nada.

Y la segunda, acerca de cómo Domínguez amasó su fortuna. A la vista está que se trata de un esforzado trabajador, que puso su profesion por encima de todo. Y vaya por delante mi reconocimiento a su faceta de vendedor. Vender me parece dificilísimo, especialmente la venta "a puerta fría". Y también por su mentalidad emprendedora; está claro que el que no arriesga no gana. Pero hay que reconocer que en el punto de inflexión de su carrera, el momento en el que le regaló aquellos dos juegos a Alan Sugar con vistas a hacerse en el futuro con la distribución del Amstrad CPC en España, apostó con "dinero" que no era suyo. Porque se comprometió a hacer algo que él no iba a realizar personalmente, y mucho menos en el plazo de tiempo que se autoimpuso para que la apuesta resultase interesante. Él no iba a hacer aquellos juegos en un mes, ni había consultado a quienes iban a hacerlos. Simplemente empujó a aquella gente a la piscina sin saber si había agua.

Obviamente, la cosa salió bien y parece que trató a sus trabajadores de forma muy generosa. Pero él inició ahí su camino para convertirse en multimillonario. Pensemos que es alguien que pudo permitirse más adelante perder 1.000 millones de pesetas en un negocio fallido. Por supuesto, con mucho esfuerzo también por su parte, incluso renunciando a ver crecer a sus hijos (algo que yo directamente ni me plantearía). Pero sin esa apuesta inicial, que como digo hizo con un dinero que no era suyo, la historia no hubiera sido la misma. Supongo que el capitalismo funciona así, y nadie se hace multimillonario exclusivamente de su propio trabajo.


Balance de 2019

El tiempo pasa tan rápido que esta vez ni siquiera he podido escribir estas líneas antes de que acabe 2019. De hecho, lo hago sobre la campana que anuncia el final del mes de enero. En cualquier caso, vamos a realizar un breve balance.

Repasando la lista de propósitos para 2019 veo que —aunque ya lo sabía sin necesidad de leerla— he fracasado miserablemente en su cumplimiento. Más o menos a mitad de año dejé de subir por las escaleras del trabajo y ya no he vuelto a hacerlo salvo en casos muy puntuales cuando hay acumulación de gente esperando por el ascensor. Con lo del móvil, tres cuartas partes de lo mismo. Empecé bien el año pero poco antes del verano volví a caer y creo que ha ido a peor. De eso hablaré luego. Y sobre la compra de juegos... qué decir. Aunque en el tramo final de año sí que me he controlado y no he comprado nada, es cierto que unos cuantos, tanto físicos como digitales, han pasado a engordar mi ya de por sí gran lista de títulos pendientes.

Pero bueno, en realidad me hice a mí mismo un poco de trampa. No por los propósitos en sí, que estaban bien, sino porque estaba obviando lo más importante. En febrero llegó una personita que daría un vuelco a nuestras vidas. Y ante tal acontecimiento, era imposible saber cómo nos íbamos a reorganizar. Y, por qué no decirlo, en ciertos momentos te dejas llevar.

No obstante, y dejando a un lado ese gran e importante apartado de mi vida, me siento orgulloso de haber sido capaz, en el último cuatrimestre del año, de haber portado un juego que hizo Miguel a tres de los ordenadores de 8 bit más usados en los años 80. Orgulloso no tanto por el resultado, sino por haber podido organizarme y sacar tiempo para hacerlo, habiendo aprendido bastantes cosas durante el proceso, cosas que espero volver a aplicar este año. Aunque la mayoría de los detalles técnicos ya los he olvidado, por desgracia.

Uno de los aspectos que tengo que mejorar, quizás el más importante, es la gestión de mi tiempo libre. Para ello, la app Bienestar Digital me ha abierto los ojos. En ella se puede consultar cuánto tiempo le he dedicado al móvil en total y desglosado por aplicaciones. Los resultados no me sorprenden, ya me lo imaginaba: (mal)gasto demasiado tiempo con el móvil. Así que éste pasa a ser el objetivo de este año.

Y básicamente eso. Si lo consigo, debería ser capaz de retomar el deporte, que lo tengo totalmente abandonado. Acabar dos o tres juegos de los largos, para no sentirme tan mal por haber comprado tantos el pasado año. Acabar un proyecto retro que tengo a medias (aunque quizás tenga que volver a empezar después de demasiado tiempo sin tocarlo). Ver si soy capaz de aprender a usar el Logic y componer algo. Y, de paso, volver a tocar algo el piano.

Ya que estamos, comparto mis estadísticas de Strava (este año paupérrimas)

Mi actividad en Strava durante 2019

y de PlayStation.

Mi actividad con la PlayStation durante 2019

Esta vez las estadísticas del blog me las ahorro, que no quiero deprimirme. Pero no me extrañaría que sea el año más pobre desde que empecé a finales de 2004.

Lo dicho: ya veremos dentro de 11 meses qué tal se ha dado. ¡Feliz 2020!


Cómo añadir texto a un PDF escaneado

Hace algunas semanas, hablando con algunos colegas del retro, saltó a la palestra la revista "Código Juego", una publicación del año 1994 en la que se incluían cursos de programación para diferentes lenguajes y plataformas, orientados principalmente, como su título da a entender, al desarrollo de videojuegos. Si buscamos en Internet no encontraremos nada, salvo una entrada en una web de compra/venta de artículos de coleccionista.

El caso es que yo en aquella época ya tenía el gusanillo de programar videojuegos, y compré algunos ejemplares de la revista, en concreto los números 3, 4 y 5, que aún conservo. Así que me he liado la manta a la cabeza para preservarlos.

Un buen sitio hoy día para alojar ese tipo de contenidos es el proyecto archive.org. Así que después de escanearlos, los he subido a mi cuenta. Una vez allí, me he dado cuenta de que se ofrece la posibilidad de descargarlos en PDF con texto. ¿Cómo puede ser eso, si lo que yo subí fueron simples imágenes? Obviamente, tiene que haber alguna manera de automatizarlo, así que me he puesto a investigar.

Tras la clásica búsqueda en Google, he encontrado el proyecto OCRmyPDF, que permite hacer justo lo que estamos comentando. Toma un PDF como entrada y le añade una capa de texto por encima, mediante técnicas de OCR (Optical Character Recognition, o reconocimiento óptico de caracteres).

En la documentación del proyecto tenemos toda la información, en concreto la manera de instalarlo. Yo he optado por usarlo con Docker, que creo que es la manera más cómoda de hacerlo porque no tienes que instalar nada en tu ordenador (salvo Docker, claro, que en mi caso ya lo tenía), y así te ahorras lidiar con problemas de dependencias y cosas por el estilo.

Sí que me ha resultado extraño que la documentación parezca incorrecta, o quizás desactualizada. Me di cuenta al intentar instalar el idioma español para enriquecer la revista (la primera prueba la hice con una revista inglesa). Las instrucciones para instalar un idioma nuevo no funcionan y, además, el español ya viene instalado por defecto, por lo que no es necesario hacer nada más. El método que se indica para usar la entrada y salida estándara tampoco me ha funcionado.

Finalmente, la lista de comandos que he usado para procesar la revista ha sido la siguiente:

docker pull jbarlow83/ocrmypdf
docker tag jbarlow83/ocrmypdf ocrmypdf
docker run --rm -i -v "$(pwd)":/data ocrmypdf -l spa /data/CodigoJuego.pdf /data/CodigoJuegoOCR.pdf

Una vez descubierto este mundo, se me ocurren bastantes aplicaciones. Por ejemplo, de cara a la indexación de contenidos en PDF. Pero ése será un jardín en el que me meta cuando disponga de más tiempo libre, que ahora no es el caso.


Presentación del libro "Queremos su dinero"

Vengo de FNAC Callao de asistir a la presentación del nuevo libro de Jesús Martínez del Vas: "Queremos su dinero". No sé cuándo, pero es un libro que leeré con seguridad. Narra la historia personal de José Luis Domínguez, centrada principalmente (entiendo) en su etapa en Indescomp, que posteriormente se convertiría en Amstrad España.

Ha dado la casualidad de que el evento coincide en día y hora con otro al que también quería acudir, que era la charla de Carlos Buenosvinos en PHPMad. Así que he tenido que elegir y a última hora me he decantado por éste, principalmente porque me apetecía más la temática y, también, porque me pilla más cerca del trabajo para llegar, y de casa para volver. Y menos mal, porque menuda tarde de frío y lluvia que se ha quedado.

Presentación de "Queremos su dinero" en FNAC Callao

La presentación ha sido una charla de algo más de una hora en la que Jesús ha introducido un poco la temática del libro y la motivación de su escritura, y ha dado paso a que José Luis contase algunas anécdotas de su vida, sin llegar a destripar (espero) todo lo que se narra en el libro. Desde luego que es el tipo de persona a la que me tiraría horas escuchándole contar anécdotas. Me ha recordado bastante a mi antiguo jefe José Antonio Martínez Soler, cuando nos contaba sus batallitas. Es gente de la que siempre se puede aprender, y en este caso la moraleja me la llevo de una frase que pronunció más o menos así: "Todo el mundo está dispuesto a triunfar, pero no todo el mundo está dispuesto a pagar el precio". Y es cierto. El propio José Luis ha pedido públicamente "perdón" a sus hijos por haber estado 5 años sin prácticamente verlos, en la época de la vorágine de Amstrad. Y eso es un precio muy alto.

Para variar, he hecho el canelo una vez más. Podía haber comprado el libro antes de la presentación (me daba tiempo) y que me lo firmasen tanto Jesús como José Luis. Pero no lo he hecho, así que me he tenido que conformar con ser testigo de cómo le firmaban el suyo a Miguel.

Para finalizar os dejo un vídeo con la presentación, que Javier Barneo se ha preocupado de grabar, editado por Javier Ortiz. Que lo disfrutéis.


He vuelto a programar en BASIC como en los 80 (III)

Tras haber llevado el juego Dead End_ al Amstrad CPC y al MSX, tocaba el turno de la última plataforma, por descarte: el Commodore 64. Tras haber adquirido experiencia en los dos desarrollos previos, pensaba que este último paso iba a resultar más sencillo, pese a que tenía mis reticencias sobre qué me iba a encontrar en esta plataforma prácticamente desconocida para mí.

El primer paso ha sido, obviamente, localizar un emulador de Commodore 64 para macOS. De entre los disponibles, VirtualC64 fue el que más me ha convencido. Como características interesantes de cara a la tarea a la que me voy a enfrentar, mapea el teclado del Mac de forma automática, lo que permite no tener que recordar (o aprender en mi caso) la distribución de teclas del Commodore. Además permite copiar texto desde el Mac, de forma que lo convierte en pulsaciones de teclas. Esto posibilita, por ejemplo, introducir una línea de BASIC copiándola desde nuestro editor favorito sin tener que teclearla a mano. Por supuesto, permite el manejo de ficheros imagen de disco en varios formatos, e incluso tiene opciones de depuración que, como no voy a programar en ensamblador, no me van a resultar útiles en este momento.

Como herramienta adicional, disponemos de C64List, que nos permite convertir un listado BASIC de un fichero de texto en un fichero imagen de disco que podemos cargar directamente en el emulador. De esta forma, podemos programar en nuestro editor de texto favorito —en mi caso he usado Visual Studio Code, y probarlo en el emulador.

El siguiente paso también fue el lógico: obtener una copia del manual de usuario del ordenador (en este caso no dispongo de una copia física del mismo) desde la web de Commodore Spain, y hacer una lectura por encima para hacerme una idea de cómo funciona el ordenador. También aproveché que había comprado el libro Programación Retro del Commodore 64 para echarle un vistazo.

He optado por dividir la tarea en dos partes. Por un lado, creo que acertadamente, me centré en trasladar el juego entero desde el listado original de Spectrum, basándome en algunas partes de la versión para Amstrad CPC, al Commodore 64, pero obviando la parte gráfica. Para pintar los objetos usé letras. De esa forma, obtuve una versión funcional "relativamente" pronto.

Por otro lado, me puse a investigar cómo funciona el Commodore 64 en su apartado gráfico, examinar los modos de pantalla disponibles y elegir cuál es el que más se adapta a lo que el juego necesita. Adicionalmente, tenía que averiguar cómo redefinir los caracteres gráficos.

Hice algunas pruebas para usar el modo de color extendido, pero no me resolvía la papeleta
Hice algunas pruebas para usar el modo de color extendido, pero no me resolvía la papeleta

Pensaba que iba a tener más rápido la versión funcional. En teoría debería de ser así mezclando código de las versiones de Spectrum y Amstrad, pero no contaba con que, en el BASIC de Commodore 64, no podemos hacer RESTORE de los datos de una línea concreta —el BASIC de Commodore tiene algunas otras carencias, pero ésta era la más relevante hasta el momento. Estuve tiempo investigando cómo sortear este escollo. La dirección de memoria de la línea DATA que se está leyendo se almacena en memoria, pero por algún motivo mis pruebas no funcionaban. Hasta que me di cuenta que, como es lógico, si modificaba mi programa, esos valor cambiaban. Eso me obligaba a reorganizar todo el código para poner las líneas con los datos al principio.

Algo en la recuperación de datos no estaba bien, y eso hacía que las pantallas se dibujasen incorrectamente
Algo en la recuperación de datos no estaba bien, y eso hacía que las pantallas se dibujasen incorrectamente

Y, además, al final no llegué a implementar esa solución, porque me lié más adelante con el tema gráfico y esto lo dejé apartado. Lo que se hace cada vez es leer todos los datos y descartarlos hasta que llegamos a los que nos interesa. Un método que funciona pero que es lento y poco elegante.

Prototipo de Dead End_ sin caracteres gráficos
Prototipo de Dead End_ sin caracteres gráficos

Una vez tuve esa versión funcional, tocaba meterse en harina con el tema gráfico. Aquí no me quedó otro remedio que indagar sobre la arquitectura interna del Commodore 64 y, en concreto, su mapa de memoria. Es algo que quería evitar a toda costa y que habría conseguido en las versiones para los otros ordenadores. Me llevó algo de tiempo, porque no acababa de entender muy bien la información que iba encontrando, montar un prototipo en el que conseguía copiar el juego de caracteres desde la memoria ROM a la memoria RAM y, una vez allí, modificar los que me interesaban para poder generar los gráficos del juego.

La primera vez que conseguí redefinir un carácter gráfico
La primera vez que conseguí redefinir un carácter gráfico

Varios fueron los escollos. Por un lado, entender bien cómo funciona la memoria del Commodore, cómo se mapean las diferentes zonas de ROM, RAM y puertos de entrada/salida, así como la configuración del chip gráfico VIC II. Por otro, me costó bastante darme cuenta de que en la memoria no se almacenan los datos en código PETSCII (el ASCII del Commodore), sino que la codificación es otra. Usé esta tabla para poder obtener la correspondencia. Como algunos códigos coinciden y otros no, me volví loco hasta que lo hice funcionar.

Hasta que me di cuenta de que los códigos de memoria no son PETSCII, me llevó varias horas de pruebas
Hasta que me di cuenta de que los códigos de memoria no son PETSCII, me llevó varias horas de pruebas

El chasco fue mayúsculo al llevarme mi prototipo al código del juego. Y es, que, con la configuración por defecto, que es la que se encuentra en el manual de instrucciones y en casi todos los ejemplos que hay por ahí, el propio programa BASIC terminaba corrompiéndose, sobreescrito por los datos gráficos. Nuevamente, me costó bastante entender qué estaba pasando y cómo tenía que configurar el ordenador para ubicar la memoria RAM de gráficos en la parte alta, para no interferir con el listado.

Además de no hacer ningún tipo de optimización, siguiendo el enfoque de este proyecto, he tenido que renunciar a adaptar los gráficos tal y como están en las otras versiones, debido a la limitación de un único color de fondo (o bien hasta cuatro en uno de los modos gráficos disponibles, a costa de otras restricciones, y que tampoco me solucionaba la papeleta). Así que veréis que el rótulo del menú principal y el gráfico de la salida de cada nivel son algo diferentes. Tampoco he implementado ninguna solución al hecho de que, en el Commodore, no se auto repite la pulsación de teclas, por lo que no basta con dejarla pulsada, sino que hay que apretar cada vez para mover el muñeco a una posición adyacente.

Finalmente he conseguido apañar una versión bastante similar al resto y creo que digna, aunque se podría optimizar bastante, sobre todo teniendo en cuenta la arquitectura de este ordenador y la idiosincrasia de su lenguaje BASIC. Sólo he volcado una versión en imagen de disco, porque no he encontrado la manera de hacerlo con una imagen de cinta. En ese sentido estoy bastante atado a lo que me puedan ofrecer el emulador y las herramientas utilizadas.

Dead End_ (Commodore 64)

Eso sí, en algún momento he llegado a pensar en tirar la toalla, de lo desesperado que estaba de no hacer funcionar las cosas. Eso sí, sacar este proyecto adelante me ha llevado a conocer más en profundidad una máquina que desconocía casi por completo, aunque no era el objetivo.

En próximas fechas haré un resumen de lo que ha supuesto esta "aventura" de llevar un juego en BASIC del ZX Spectrum al resto de plataformas de 8 bit más conocidas. Y, si todo se da bien, seguiremos trabajando en cosas que compartir en este blog.


El final (ahora sí) de una etapa

Hace ya más de tres años y medio que dejé mi trabajo en 20minutos. Sin embargo, de alguna manera, no ha sido hasta hoy que se ha cerrado esa etapa.

Recuerdo mi primera visita a las oficinas (me resisto a llamarla “redacción”, como tienen por costumbre los periodistas) en noviembre de 2004. La ilusión por el proyecto: “tenemos un periódico que es número uno y hay que construir su web que también llegará al número uno”.

Hacía poco que había empezado este blog. Recuerdo llevar mi primer día al trabajo y ver los cinco servidores que iban a alojar el proyecto allí en el suelo. Se habían comprado pero había que instalarlos, configurarlos y llevarlos a su ubicación, que iba a ser en Acens. Para eso se contrató a un consultor, Jan Bruvoll; una de las personas brillantes con las que he tenido el lujo de trabajar estos años. Brillante, sí, pero un poco temerario (o demasiado seguro de sí mismo). El día de la salida se me puso a compilar el PHP (usábamos una distribución Gentoo).

Recuerdo el ambiente pre-navideño de ese diciembre de 2004. A la semana o dos de estar allí me puse malo del estómago. Menuda imagen para ser “el nuevo”. Por ello me perdí la primera cena de navidad de la empresa.

La redacción eran solo cuatro personas: Ricardo Villa (el director), Vanesa Rodríguez, Clara Hernández y Amanda Heredia. Nuestro diseñador era Ismael Viejo, otro excelente compañero con el que, por desgracia, he trabajado menos tiempo del que me gustaría. El equipo técnico era... yo, con el apoyo de mi jefe y el de Jan en la parte de sistemas.

Los primeros días iba armado con mi cuaderno y mi Pilot, me sentaba con Ricardo y me contaba cómo quería que fuera la nueva web y el nuevo gestor de contenidos. Íbamos a construir todo de cero, lo que tiene ser un inconsciente y poco documentado jovenzuelo. La verdad es que en aquella época no conocía ningún framework, sabía Javascript de andar por casa (el navegador que dominaba el mercado era, si mal no recuerdo, Internet Explorer 6), de PHP orientado a objetos lo justo, y también lo justo de control de versiones. Así que lo hicimos todo a lo burro, desde cero. Ni siquiera empecé a usar un IDE hasta muchos (demasiados) años después. Pero tampoco nos equivoquemos; el ecosistema que había en aquellos días no se parecía al de hoy ni por asomo: por seguir el mismo orden, no existían ni Symfony, ni jQuery, ni Git, y PHP 5 llevaba solo un puñado de meses disponible.

Uno de los muchos —de hecho el primero— cuadernos de notas que llené durante aquellos años

Lo increíble de todo aquello es que, tras decidir con qué funcionalidades íbamos a salir, el 1 de marzo de 2005 teníamos online la primera versión operativa de la nueva web y el nuevo gestor de contenidos. Lo pienso y no sé cómo pudimos hacerlo, pero lo hicimos.

La web de 20minutos en febrero de 2005, días antes del lanzamiento oficial

Desde luego, si tuviera que hacerlo ahora, creo que cambiaría casi todas las decisiones. Pero tampoco sería muy justo juzgar aquello con los conocimientos de ahora. Aunque sí que hubo dos o tres decisiones, tomadas por desconocimiento, de las que me estuve arrepintiendo muchos años.

Aquella primera versión tenía hasta comentarios de los usuarios. No sé si algún otro medio de comunicación admitía comentarios por entonces, yo creo que no. En cualquier caso, la mayoría de ellos eran constructivos. Nada que ver con lo que podemos encontrar ahora. Todos éramos más inocentes entonces. No os imagináis la sensación de estar de madrugada, tras haber lanzado la web, y que nos entrase un comentario pidiendo que implementásemos feeds RSS. ¡Dame feeds! ¡Quiero feeds!

Toda esta chapa viene a colación de que, aquellas líneas de código que se empezaron a gestar hace casi 15 años, alimentadas, mantenidas, arregladas, gestionadas por más de una decena de compañeros y compañeras, han quedado atrás. Hoy, el equipo de Henneo ha sustituido aquel gestor de contenidos por uno nuevo. El producto ya no es el mismo, el equipo directivo y humano tampoco. Y aquel vetusto software ya no daba más de sí.

Algunas cosas se han roto. La web de Tiempo y Temperatura ya no muestra las noticias de 20minutos
Algunas cosas se han roto. La web de Tiempo y Temperatura ya no muestra las noticias de 20minutos

No sé si volveré a escribir código que se mantenga tanto tiempo en uso por tanta gente. Pero, desde luego, con todos sus defectos y problemas, me siento muy orgulloso de haber formado parte de ese proyecto. Y, hablando de escribir, algún día debería sacar tiempo y contar las batallitas de aquellos años, antes de que se me olviden.

PS: Aun sigue online la versión de lanzamiento de Tiempo y Temperatura, una web con muchas limitaciones y que se ha quedado visualmente obsoleta, pero a la que tengo mucho cariño por lo que trabajé en ella, y que sigo consultando a diario para saber qué tiempo va a hacer en los próximos días.


He vuelto a programar en BASIC como en los 80 (II)

Después de dar el pistoletazo de salida a mi plan trasladando el juego Dead End_ al Amstrad CPC, toca elegir la siguiente plataforma que voy a visitar. Tengo dos para elegir: Commodore 64 y MSX. Voy a continuar con esta última. En realidad me da más o menos igual una que otra, pero me quedo con el estándar japonés porque creo que es la que más se asemeja a las dos anteriores, Spectrum y Amstrad. Ya veremos al final de todo este proceso si mi intuición ha sido la correcta.

En este caso, MSX no es un único ordenador, sino un estándar. Hubo varios fabricantes que construyeron microordenadores siguiendo esa especificación y, como suele ocurrir, no son todos iguales al 100%. Aunque creo que programando en BASIC no deberíamos tener ningún problema, es posible que nos encontremos alguna sorpresa no muy grata en ese sentido. En principio, la plataforma será un MSX de primera generación, con 64 KB de memoria.

Toda la experiencia adquirida hasta el momento me va a ayudar, no tanto a dar este paso más rápido, sino a tener muy claro cuáles son los puntos que tengo que resolver. Eso sí, antes de empezar a programar nada, tengo que elegir un emulador que me permita trabajar lo más cómodamente posible. Esto es, en el que pueda guardar el estado actual, para continuar más adelante, y que me ofrezca la posibilidad de cargar/guardar el fichero con el programa desde fuera.

Por lo que he visto, la oferta de emuladores para macOS, aunque hay algunos más disponibles, se centra en dos de ellos: openMSX y CocoaMSX —que, a su vez, está basado en BlueMSX (solo para Windows). De todos ellos, el primero parece el más completo y, desde luego, es el que más actualizado está. No obstante, su configuración no es trivial, en tanto en cuanto hay que configurar el ordenador concreto que queremos emular. Tampoco he dedicado mucho tiempo a trastear; quería entrar rápido en harina, asi que me he decantado por el segundo, con el que más o menos me he apañado. Eso sí, he echado mucho de menos no poder usar el genial Retro Virtual Machine para estos menesteres.

Lo siguiente ha sido dar un repaso rápido al manual del MSX para ver por encima qué posibilidades tengo, principalmente en cuanto a modos gráficos, y también para ir familiarizándome con el juego de instrucciones BASIC.

Manuales de BASIC del MSX

En este punto ha sido donde he empleado más tiempo a la hora de sacar adelante este proyecto. Y me temo que lo seguirá siendo si me decido por continuar portando el juego a más ordenadores. Me refiero a comprender el funcionamiento de los modos gráficos del ordenador y su implementación. Una cosa aparentemente tan sencilla, como poder pintar un carácter con un color de tinta y otro de fondo, algo en lo que se basa el código del juego en sus versiones de Spectrum y Amstrad, no es factible en el MSX.

Voy a intentar explicarlo, centrándome en el funcionamiento del Spectrum, que es el que mejor conozco, y tratando de no perderme en los detalles. En un Spectrum, se almacena por un lado la información de los píxeles (tinta/fondo, es decir, encendido/apagado) y, por otro, la información de color. Para cada grupo de 8x8 píxeles, se establece un color de tinta y otro de fondo. El MSX funciona de manera similar a como lo hacen las consolas antiguas. Hay una tabla donde se almacenan bloques (o tiles), y otra tabla donde se almacenan los colores para esos bloques. La pantalla no se compone píxel a píxel, sino que se construye a partir de esos bloques, como si fueran piezas de Lego. Por tanto, no es posible elegir un bloque (una letra por ejemplo, pero podría ser cualquier gráfico de 8x8 que definamos) y sus colores por separado, sino que bloque y color son todo uno.

Para terminar de "complicar" el asunto, en el modo "Screen 1" de MSX, la tabla de colores solo tiene 32 posiciones, por lo que se asignan colores a cada 8 bloques correlativos. Esto me costó entenderlo; después de leer el manual, yo pensaba que los colores se aplicaban a 8 bloques correlativos de la pantalla, lo cual no tenía sentido. Así que tuve que pedír consejo a Jon Cortazar, alma mater de Relevo Videogames, experto en el desarrollo para MSX (además de otras plataformas) y, sobre todo, una gran persona, quien amablemente se molestó en explicarme de forma sencilla cómo funcionaba.

Como nota mental, para próximos proyectos, esta parte del código, la encargada de "pintar cosas en la pantalla", debería estar lo suficientemente aislada para que la transición entre diferentes plataformas sea lo más sencilla posible.

Una vez superado este escollo, me quedaban por repasar los siguientes puntos:

  • Cómo se edita un programa en BASIC. En particular, cómo se edita o elimina una línea.
  • Cómo se ejecuta y se interrumpe un programa BASIC.
  • Cómo se cargan y almacenan programas BASIC.
  • Cómo se gestionan los GDU (Gráficos Definidos por el Usuario).
  • Cómo se ubica el cursor en una posición determinada de la pantalla.

Como en el caso del Amstrad CPC, voy a elegir un modelo de ordenador con disco, en este caso un MSX2 Philips NMS-8250, ya que es lo más cómodo para trabajar. Ya veremos si luego no me llevo una sorpresa al probar el juego en un MSX "pelado". El emulador me permite crear una imagen de disco vacía, que puedo leer y escribir directamente desde macOS renombrando la extensión ".dsk" por ".img". Para Windows se puede usar el programa Disk Manager

Gracias a los consejos de Jon y al trasteo previo, ya tenía claro cómo debía hacer para poner los gráficos en pantalla, así que esta vez, en vez de copiar todo el listado desde cero, lo que hice fue partir de la versión de Spectrum, modificar las palabras clave que son diferentes y, en las partes que no me valían, usar la versión de Amstrad, también copiada. Toda la edición la hice en el PC, usando el emulador solo para probar y retocar alguna cosa. Más o menos se me dio bien, casi acerté a la primera con todo, menos con el dichoso bug del buffer, que me lo volví a comer (porque se me olvidó copiar la solución que ya tenía implementada en el listado de CPC).

Debido a cómo se gestiona la pantalla del MSX, eso sí, algunos detalles no están igual que en la versión de Spectrum. Por ejemplo, el gráfico que conforma la barra inferior que separa los marcadores está invertido. Y el fondo del mensaje que aparece cuando completamos un nivel no es azul, sino negro. Tampoco me molesté mucho en indagar en los comandos de sonido. Puse un "BEEP" sin más y a correr.

Por último, sólo faltaba generar los ficheros de cinta (.cas), disco (.dsk) y cartucho (.rom). Para este último he usado la utilidad MSX-BASIC ROM creator, de José Luis Tur. Enlazo a MSX Blog porque la web original donde se aloja el programa parece que no funciona he localizado la web oficial del programa.

Sobre todo el proceso de desarrollo tenéis más detalles técnicos en el repositorio del proyecto.

A posteriori lamento no haber dedicado más tiempo a aprender a manejar OpenMSX. No sé si es problema de mi ordenador; seguramente que sí, porque si no imagino que alguien más se habría quejado y, aunque el emulador hace bastante que no lo actualizan, imagino que tendrían una issue abierta. El caso es que el teclado no me funciona bien y, cuando estoy editando el listado en BASIC, el cursor se vuelve loco y se borran las líneas enteras. El caso es que, después de finalizar el desarrollo, Miguel me pasó unos ficheros de configuración que, copiados en la ubicación adecuada, permiten disponer de un buen abanico de ordenadores emulados. Y aunque me dio algún problema adicional, y su integración con macOS tampoco es la ideal, parece funcionar mucho mejor. Incluso tiene mapeadas las teclas del teclado del Mac, para no tener que saber/recordar dónde están ubicados los símbolos en el teclado del MSX.

La sensación que me queda os la podéis imaginar. La parte de gestión de vídeo del MSX es bastante diferente a la de los ordenadores de 8 bit que conocía hasta ahora y se me asemeja más a la de una videoconsola. También me queda la impresión, que es una obviedad, de que adaptando el código en vez de copiándolo directamente podría obtener mucho mejores resultados. Desde luego que esta versión no hace honor a lo que se puede conseguir con este ordenador pero, aun a riesgo de repetirme, en esta ocasión el objetivo era otro diferente.

Dead End_ (MSX)

Juegos: Demo eFootbal PES 2020 (PS4)

Otro año más llega el momento de probar la demo de Pro Evolution Soccer, que a partir de esta entrega ha sido renombrado como eFootball PES. Este año también ha sido lanzada en julio, con lo cual la he podido catar antes de irme de vacaciones. No obstante, el partido para el vídeo no lo jugué hasta después de volver. Y este breve comentario, como tres semanas después.

Como es habitual, el juego se siente diferente, ya que el equipo de desarrollo hace pequeños ajustes aquí y allí. Pero tampoco esperemos una gran revolución, por más que nos lo quieran vender. Si acaso el juego da la impresión de ser un poco más "alocado" o "aleatorio".

Visualmente creo que se les ha ido la mano con la saturación de los colores. Por lo demás, noto pocos cambios respecto a la edición del año pasado. Si acaso un lavado de cara a los menús, supongo que más animaciones y pequeños detalles, pero nada impactante, como vuelvo a repetir.

También han retocado las físicas. El balón parece ir un poco más suelto, y los cuerpo a cuerpo de los futbolistas toman más importancia. Podemos usar nuestro cuerpo para proteger el balón, así como cargar al contrario para intentar robar el esférico. La meteorología cambiante (la verdad es que no recuerdo si estaba en anteriores entregas) hace acto de presencia. Por ejemplo, uno de los partidos que he jugado empezó nevando y terminó lloviendo.

En esta demo tenemos la oportunidad de jugar partidos tanto contra la máquina como online con un pequeño conjunto de equipos (imagino que los que tienen contrato con Konami). Lo que me ha sorprendido —para mal— es que el "efecto Konami" se hace más presente que nunca. Que igual es que no sé jugar, pero en el último partido que he echado antes de escribir estas líneas ha sido escandaloso. Desde el primer momento se notaba que el rival me iba a pasar por encima; faltas no pitadas, goles de rebote, etc. Y ya lo terminé de constatar cuando me quedé con Messi solo a portería vacía, hice un tiro colocado y lo mandó fuera.

En cualquier caso, creo que este año puede ser el primero de muchos que no compre la edición anual. ¿La causa? Falta de tiempo. Ya el año pasado jugué menos de lo que pensaba, y este año pinta que todavía lo haré menos, con un buen puñado de juegos pendientes, con algunos interesantes pendientes de salir (Star Wars Fallen Order, Luigi's Mansion 3 y alguno más) y menos tiempo libre para esta afición. De momento, si me apetece jugar algún partido, tiraré de la entrega del año pasado o de esta demo. Y, total, seguro que acaban por sacar la versión free to play en algún momento, que para el uso que le doy me sirve más que de sobra.

No me enrollo más. Aquí tenéis el vídeo de este año: