Program : Bytes : 48k

Pese a que son ya algo más de dos décadas que nos conocemos, no puedo ocultar cierto nerviosismo cuando hablo con alguien de la importancia de Miguel Ángel, más conocido en el mundo retro como McLeod_Ideafix. Ciertamente, uno intenta medir las palabras y realizar preguntas medianamente coherentes y que no resulten obvias en su respuesta a la vista del entrevistado… Por eso, rebusco entre las últimas noticias y foros, aquellos temas que despierten el interés del protagonista de esta “charla”.

Abusando un “poco mucho” de la amistad que nos une, le propuse días atrás la posibilidad de realizarle una entrevista para hablar de todo un poco y, cómo no, también sobre el proyecto del momento, el ZX-Uno, creado por Antonio Villena y McLeod_Ideafix, con la participación de unos colaboradores de lujo como Quest, Superfo y Hark0.

He de decir que, a veces, uno puede pensar que personas de la relevancia de McLeod son inaccesibles, pero nada más lejos de la realidad, ya que, desde el primer momento, la predisposición y colaboración mostrada fue la nota dominante, y eso es de agradecer.

Y llegó el día. Intentando siempre causar las menos molestias posibles, quedamos en su despacho de la Escuela Politécnica Superior donde es profesor de Arquitectura y Tecnología de Computadores. Pese a las instrucciones precisas que tenía, he de decir que me costó un poco “moverme” entre tantos recovecos y pasillos. Pero, finalmente, dí con la puerta correcta.

Algunos alumnos iban llegando para exponerle sus dudas o preguntar de qué forma encarar los problemas que se van encontrando en sus respectivos proyectos y, entre tutoría y tutoría, vamos hablando o avanzando sobre algunos temas… También, cómo no, echamos la vista atrás recordando los tiempos de cuando coincidimos en la Facultad de Informática… que ya son años, sí. Ni que decir tiene que es especialmente difícil ponerse en “modo entrevistador” cuando tienes en frente a alguien que conoces desde hace tanto tiempo, pero, poco a poco, van saliendo las primeras preguntas y también las primeras respuestas…

Pese a que no había un orden preestablecido en el que tratar los temas que traía preparados, creí que, después de un largo tiempo sin vernos, no podía empezar por otra cosa que no fuese por un “qué tal te va todo”… Sabía que no es muy dado a hablar de temas personales, pero era más una pregunta sincera entre dos amigos que quieren saber el uno del otro más que otra cosa. Y, realmente, no pudo ocultar esa media sonrisa al hablar de lo bien que le va la vida en Jerez, o ese brillo en los ojos cuando habla de su ‘pequeña princesa’ que está en plena “época del no!”. Surgen las primeras risas e intercambiamos anécdotas; yo, que he pasado por ello dos veces, le explicaba gráficamente cómo van cambiando los peques en cuanto a personalidad, y el proceso lento que conlleva el encontrar su propia identidad y ganar en autonomía… pero, quizás, son épocas que uno, como padre, debe ir experimentando y, también es cierto, que es tremendamente reconfortante irlas descubriendo poco a poco en primera persona… por lo que sólo me limito a darle algunas pinceladas y omitirle cruelmente que lo peor está por llegar (jajaja).

Mientras seguimos hablando, noto sutilmente una musiquilla que no para de sonar… Proviene de una ‘demo’ muy colorista para Spectrum 128k que está ejecutándose sobre un prototipo experimental de ZX-UNO que tiene sobre su mesa.

– ¿La música no va muy rápida? – pregunto.

Muchas personas están preguntando eso mismo. Y es que, por defecto, si no dices lo contrario, la VGA trabaja a 60Hz y eso hace que todo vaya más rápido, un 20% más que de costumbre. En mi caso (señalando a su monitor), esta VGA puede trabajar también a 50Hz, con lo cual no tengo ese inconveniente.

Básicamente, el problema es que a 60Hz todo va algo más rápido para seguir manteniendo la sincronización. Por ejemplo, si ejecutamos el “Shock Megademo”, para que todos los efectos sigan funcionando perfectamente todo tiene que estar sincronizado como en el Spectrum original… el scroll suave que se ve en esta demo, este tipo de suavidad, sólo se aprecia bien en un monitor CRT de tubo. Usamos 60Hz por defecto porque es una frecuencia en la que todos los monitores de VGA soportan. Es así para que cuando lo conectes por primera vez a un monitor VGA estándar no tengas problemas de visualización… ya luego puedes ajustar la frecuencia a 50Hz si tu monitor lo soporta para conseguir más fidelidad con el Spectrum real.

– ¿Pero eso significa que hay que hacerle overclocking al Z80 también? ¿El Spectrum va más rápido cuando usamos el modo de 60Hz? (le interrumpo…)

Sí, efectivamente… ahora mismo el Spectrum va a 4.2Mhz, un 20% más rápido para mantener así la sincronización. Todo va más rápido, aunque sigue existiendo el mismo número de ciclos por reloj por frame de pantalla desde la interrupción hasta el comienzo de escritura… Desde el punto de vista del Spectrum, no ha cambiado nada… él no es consciente de que se haya producido cambio alguno.

– Qué bien, tener más potencia de proceso para que los juegos vayan más rápido o que se puedan hacer más complejos…

Bueno, -responde mientras teclea unos comandos tras otros-, no sólo puede ir a la velocidad estándar del Spectrum, también puede ir a 7Mhz e incluso 14Mhz! Imagina qué se puede hacer con 4 veces más proceso que el original…

– Los juegos serían increíbles, más Sprites en pantalla, scroll suave al pixel y con varios planos, etc…

También lo podemos subir algo más, a 28Mhz, aunque he tenido pequeños problemas de estabilidad con la tarjeta SD… así que, de momento, lo máximo aconsejable son 14Mhz. Las velocidades deben ser todas múltiplos de 3.5 porque de lo contrario sería difícil generar los ciclos de reloj adecuados. Internamente, hay un único reloj de referencia que son esos 28Mhz (para gestionar la SD y alguna otra cosa más), y a partir de ahí se generan todos los demás. Los 14Mhz son para la ULA. Ésta tiene dos modos gráficos que son el normal de 256×192 pixels y otro menos conocido que es el de 512×192 pixeles, que lo hereda de los Timex… que es un modo que existía ya en 1983. El dibujado en pantalla es algo más lento porque tiene que ir escribiendo en dos zonas de pantalla independiente, la que empieza en la posición de memoria 16384 y la otra en la 24576. Aquí no hay “color clash”, ya que sólo hay color de fondo y color de primer plano.

– ¿Qué otros modos gráficos podemos ver en el ZX-UNO aparte de los ya vistos?

Pues, por ejemplo, podríamos utilizar otro poco visto que podríamos llamar “color en alta resolución”. Aunque pueda parecer lo contrario, este modo es más sencillo (internamente) que el anterior de alta resolución. Es también de 1983, y los Timex también podían usarlo. Implementarlo ha sido bastante rápido porque implica poquísima circuitería adicional en la ULA por lo que podría hasta haber funcionado en una ULA original de Sinclair y se sabe que por parte de Timex se lo ofreció para que se incluyesen en los modelos de 128K, pero Sinclair se ve que no lo encontró interesante (por decirlo de algún modo). La historia habría sido distinta para estos modelos porque hubiera permitido juegos en hi-color sin apenas sufrir el famoso “color clash”.

Si se hubiese llevado a cabo esa implementación, todos los engines que tratan de meter más de dos colores por celda de 8×8, como el Bifrost o Nirvana no hubieran tenido razón de existir actualmente, ya lo hubiera hecho por sí solo el hardware.

Es una pena que, pese a que existe mucha documentación sobre estos modos gráficos del Timex, apenas se haya desarrollado código para usarlos, ya que no tienen apenas complicación y quedan bastante bien.

Aprovecho para ir sacando algunas fotos de las demos que pone Miguel Ángel en los modos de alta resolución y de “hi-color”. De paso, voy repasando mi “guión” de temas para hablar… Hay un punto que sólo contiene un escueto “Gracias”. Así que, antes de que se me vuelva a olvidar de nuevo, retomo la conversación para felicitar por el éxito que ha sido el proyecto.

– Miguel Ángel, la verdad es que la “escena retro” está más que contenta y agradecida por lo que habéis creado. Por un lado, a nivel tecnológico, es una maravilla, y por otro, el hecho de que se haya llevado el proyecto hasta el final es digno de admiración. A mí me ha encantado… 

Gracias a vosotros por comprarlo y confiar en nosotros. -y cambiando rápidamente de tercio empieza a hablar sobre los cores-. ¿Has probado ya los cores?

– Sólo el de Spectrum -respondo-, el resto aún estoy pendiente de tener algo de tiempo para verlos en detalle. El de Sam Coupé tengo muchas ganas de verlo en acción.

Tenemos bastantes… Spectrum, Sam Coupé, Jupiter Ace, Master System, Atari 800XL y más que vienen de camino… -Arranca el core de Master System y carga el mítico ‘Alex Kid’- El de Master System, por ejemplo, la persona que lo implementó tuvo que añadir el soporte de teclado para que se pudiera jugar con teclas, además del joystick. También, dado que la Master System original no tenía tarjeta SD, para poder cargar juegos, se ha tenido que añadir electrónica y rutinas que simulara un lector de tarjetas para leer las ROMs y posteriormente volcarlas a la RAM de la FPGA.

Por ese mismo motivo, la dificultad de añadir soporte de lectura SD a sistemas que no lo tenían, es por lo que el Sam Coupé sólo tiene, a día de hoy, posibilidad de carga mediante cassettes, porque no existe una Interfaz documentada para realizar lector de tarjetas SD para este sistema o el Jupiter Ace.

– ¿Y ha sido complicado hacer funcionar el core de Master System en el ZX-UNO? ¿Cuál es el proceso para que encaje en la circuitería de la placa?

El core no es más que una descripción de un circuito electrónico, con sus entradas, por ejemplo, un joystick y sus salidas como el puerto de sonido o de vídeo. Nosotros lo que hacemos es enrutar esos puertos a sus correspondientes del ZX-UNO. Aquellas cosas que no estuviesen en el diseño original, como por ejemplo, soporte para teclado, es lo que hace el desarrollador del core, un módulo de soporte de teclado que funcione, en este caso, como un joystick, y que al pulsar ciertas teclas el hardware de la Master System crea que están originadas por el propio joystick.

– Hemos visto muchos cores de Spectrum y otras consolas de 8 bits… ¿Veremos pronto uno de Amstrad?

Estoy en ello  🙂  De momento ando investigando y estudiando…

– Estaría bien ver la demo de Batman Forever en el ZX-UNO… Por cierto, para los profanos de Amstrad, ¿qué es lo que tiene de especial esa demo? Los que somos de otro sistema, al no tener ningún tipo de referencia, se nos hace difícil valorar qué capacidades técnicas explotan…

Vaya por delante que no soy ningún experto en Amstrad y que estoy empezando a estudiarlo… pero sobre lo que me preguntas de la Demo de Batman Forever, una de las cosas que yo destacaría es que está entera hecha en Overscan. Normalmente, el Amstrad, al igual que otros sistemas, usa un borde de pantalla y la acción se desarrolla en el “cuadro” central, pero usando el controlador de pantalla, el CRTC, adecuadamente, puedes decirle en cada momento desde dónde y hasta dónde llega la pantalla (tanto vertical como horizontalmente). Lo primero que hacen en la demo es quitarle el Borde que vemos normalmente, y ponerlo todo a pantalla completa. Esto genera una nueva resolución de pantalla, diferente a las convencionales, extendiendo la resolución más allá de lo imaginable.

También destacaría el uso intensivo que hacen del CRTC para realizar todo tipo de efectos de pantalla, desde ‘splitscreens’ hasta reducir la pantalla lo suficiente como para hacer rotaciones gráficas a mucha velocidad… e incluso “retorcer” la pantalla a base de cambiar, en cada línea del trazado, las dimensiones de la pantalla.

Realmente, consiguen tener más flexibilidad de pantalla que otros muchos sistemas.

– ¿Y esta técnica es nueva o se conocía antes?

Según se supo hace un tiempo, los primeros programadores de videojuegos sí que la conocían, e incluso la usaron… Por ejemplo, en el juego Fred, usan el CRTC para hacer el scroll del juego, que es mucho más rápido que mover el bloque gráfico de la pantalla usando únicamente la memoria. Luego llegó un período en el que el mismo juego salían para Spectrum, Amstrad, MSX… los famosos “ports”. Si se tomaba como base la versión de Spectrum, que por sistema, no podía usar el CRTC, las demás versiones no lo iban a “heredar” y no lo aprovechaban. Si sumamos que había menos usuarios de Amstrad que de Spectrum, pues había poco interés en explotar al máximo las cualidades de cada sistema.

– En cuanto al Spectrum, ¿crees que se ha llegado al límite o aún faltan técnicas o “trucos” por descubrir?

Cada vez que veo la demo del ganador de la Chaos Constructions del año pasado pienso que ESTO es lo más a lo que el se puede llegar en un Spectrum, y al año siguiente sorprenden con otra vuelta de tuerca. De todas formas, creo que poco más se puede conseguir con el Spectrum tal cual está. Si quedaba alguna asignatura pendiente era la generación de gráficos animados en el borde, y eso se ha conseguido con la demo de este año (Across the Edge). Lo que sí da mucho juego y está muy poco explotado son las demos que usen modos como el HiColor o HiRes del Timex, y que están disponibles en el ZX-UNO y otros clones. Si los rusos son capaces de hacer lo que hacen con la limitación de 2 colores por atributo, no quiero imaginarme lo que pueden llegar a hacer si la limitación es sólo en scans de 8×1.

– ¿Hay alguna característica que te haya gustado meter y no cupiese por falta de espacio o de potencia de la FPGA?

¡Muchas! Pero la que más coraje me da es no poder implementar (de forma sencilla) soporte de discos para el +3, en forma de ficheros DSK. Bajo TR DOS tenemos soporte de discos en formato TRD, pero hay cosas como el CP/M, que no están en ese formato, y aunque lo estuvieran, la BIOS del CP/M usa acceso a bajo nivel a la controladora de disco, así que no vale virtualizarla. Para dar soporte hubiera sido muy conveniente tener más memoria RAM disponible. No obstante, no lo descarto, ya que el formato estándar de un DSK son unos 180KB, y eso cabe en la SRAM del ZX-UNO si no se usan cosas como la MMY del Timex (lo que nos da 256KB para jugar). Para otro cores, como el SAM Coupé, echo de menos eso mismo (en el SAM las imágenes son de 880KB).

Otra característica que no está y que me gustaría que estuviese de forma fija es el reproductor de ficheros PZX, y además poder integrarlo en ESXDOS. De esta forma el soporte de carga de cintas estaría mucho más completo. Hay que tener en cuenta no obstante que el hardware del ZX-UNO se pensó para meter un Spectrum dentro, así que prácticamente todo lo que queríamos incluir en él, sí que está. Ni el soporte de discos DSK ni el de PZX es imprescindible para poder disfrutarlo. El primero se puede suplir en parte con el soporte de +3e. El segundo, bueno, con la entrada EAR física que te permite cargar juegos de cinta, desde el PC, desde el móvil o desde cualquier cosa que pueda reproducir el ruido de carga del Spectrum.

– Teniendo en cuenta las características que sí están implementadas, imaginémonos un videojuego que explotase al máximo el ZX-UNO, ¿de qué tipo de juego estaríamos hablando?

Hay algunas limitaciones impuestas por la arquitectura del sistema que hemos diseñado, pero no muchas:
el DAC de color es de 3 bits por componente, lo que nos da un número máximo de 512 colores generables. Claro que si usamos PWM en las señales que alimentan al DAC (uno muy simple con resistencias) podemos pasar sin dificultades a 4096 ó incluso 32768 colores diferentes:

– La resolución permitida de la pantalla está limitada por la memoria que puedas usar y cómo se maneje esta memoria por el resto del sistema aparte del controlador de vídeo. Si tanto el resto del sistema como la controladora de vídeo van a hacer muchos accesos simultáneos, y ambos van a ir muy rápidos, entonces es mejor usar memoria interna de la FPGA que puede configurarse como memoria de doble puerto y así permitir dos accesos simultáneos, pero esta memoria es escasa: 72KB como máximo, lo que va a limitar la resolución disponible (por ejemplo, sería posible una resolución de 320×200 a 256 colores). Si el número de accesos va a ser menor, o éstos pueden estar concentrados en el tiempo de retrazo vertical, o la contienda sistema/controladora de vídeo va a ser escasa por la poca velocidad de alguno de ellos, entonces es posible usar la memoria estática externa (que de todas formas es muy rápida, 10ns de acceso), y de la cual disponemos de 512KB, lo que nos da para mucha más resolución.

– la calidad del sonido que puedes generar también está limitada por la memoria disponible, o por los recursos de la FPGA, o ambos. Todo depende de cómo se genere el sonido. Si se piensa en generación por tabla de ondas, el límite lo tienes en la memoria RAM que pretendas usar para guardar samples. Si se piensa en generación por FM, moduladores en anillo, o virguerías de ese calibre, entonces el límite lo tienes en los recursos para procesado de señal digital (DSP) que tienes dentro de la FPGA.

– la complejidad del sistema que implemente el juego está principalmente limitada por la cantidad de recursos de la FPGA. La LX9 que usamos tiene, como su nombre indica, unos 9000 elementos lógicos. Cada elemento lógico puede hacer un “trocito” de sistema completo. En los cores que hemos implementado, lo que se lleva más cantidad de elementos lógicos es la CPU, que en el caso de un Z80, es una CPU CISC bastante compleja. Si se diseñara una CPU más sencilla pero quizás más versátil, algo tipo RISC con pocas instrucciones y muchos menos registros, usaría menos recursos de la FPGA a costa, seguramente, de necesitar más memoria para implementar el juego. Eso permitiría diseñar un controlador gráfico que tuviera algunas características deseables en un videojuego, como movimiento de sprites grandes, diferentes planos, o scroll por hardware.

Con todo esto, el tipo de juego que me imagino que puede verse en una FPGA como ésta, se parecería a cualquier juego que puedes ver hoy día en una Megadrive o Neo Geo. OJO que no estoy diciendo que una Megadrive o una Neo Geo quepan en la FPGA del ZX-UNO (que no, no caben), pero un juego rediseñado de cero podría caber en un sistema creado ad-hoc para la FPGA. No incluyo juegos en 3D porque no estoy seguro de que un acelerador 3D quepa, y aunque ese fuera el caso, el 3D necesita bastante más memoria que el 2D y de nuevo, la cantidad de SRAM disponible sería un factor importante.

– ¿En qué otros proyectos te vamos a ver a corto o medio plazo? ¿Qué tienes en mente o qué es lo próximo que te gustaría hacer?

Antes de ponerme con el core de Amstrad he estado experimentando con un controlador de tarjetas SD enteramente por harware, que me podría permitir, llegado el caso, a hacer un conversor SD-IDE en la propia FPGA, lo que a su vez me permitiría implementar cosas como el Atom HDD: una solución de almacenamiento masivo para SAM Coupé, con la que podría cargar software sin necesidad de la cinta, y con bastante compatibilidad con el software de SAM existente.

Otra cosa que también he estado investigando es el reescribir desde cero el core del Z80, que funciona muy bien en el Spectrum, pero no tanto en otros cores, como el ya comentado SAM Coupé. Veremos si el core de CPC no me va a obligar a dedicarme a esto también, ya que el SAM y el CPC se sincronizan con la CPU de la misma forma, con la señal WAIT, y ahí es donde el core actual que tenemos para el Z80 no anda muy fino.

A nivel hardware, en cuanto a placas y diseños (aparte del ZX-UNO), tengo aparcado un proyecto para hacer un conversor de teclado, ratón y joystick USB a PS/2 y Atari. De conseguirse, esto permitiría usar una buena cantidad de teclados pequeños inhalámbricos que hay disponibles para sistemas tipo Raspberry o Smart-TV.

Hay otro proyecto, del cual tengo pedidos algunos componentes, para crear una pequeña placa addon para el ZX-UNO con un chip que interpreta eventos MIDI en forma de música. La idea es habilitar en el core de Spectrum la señal MIDI OUT que se genera en el AY-3-8912 cuando se usa el comando PLAY del BASIC de 128K con más de 3 canales. Rutar dicha señal a este chip, que sintetizaría la música suministrada vía MIDI, y el resultado, mezclarlo de nuevo con el resto de fuentes de audio para que se escuchara de forma integrada.

También tengo los componentes y un ‘medio diseño’ de placa para una versión “lite” del Spectranet: una interfaz ethernet para Spectrum, de Dylan Smith.

Aunque, en estos momentos, de algo que no sea el core de Amstrad CPC y que sea hardware, lo que ocupa mi retro-tiempo es montar y configurar el add-on de ZX-EDGE, para dar por fin soporte a periféricos originales de Spectrum en el ZX-UNO.

Llaman a la puerta y aparece un nuevo alumno. Circunstancia que aprovecho para ir despidiéndome y darle las gracias por recibirme…

Muchos proyectos e interesantes. Echando la vista atrás, todo esto tiene la culpa aquel Señor tan agradable llamado Sinclair. Por cierto, ¿qué sentiste cuando viste en el ZX-UNO por primera vez aquello de “(c) 1982 Sinclair Research Ltd“?

Debió ser algo parecido a tener un orgasmo mental. Un subidón tremendo. La prueba definitiva de que “esto igual funciona” (risas…)

Desde aquí darle las gracias a McLeod-Ideafix por todo lo que me ha ayudado en la realización de esta entrevista.

Se quedan muchas preguntas en el tintero, pero esas las dejaremos para una segunda ocasión…