No soy yo... ¡Eres tú!

En algunos post anteriores, debrayé un poco sobre el protocolo de comunicación del control de Playstation y algunas de sus características, así como la evidente lentitud de dicho protocolo.

En estos días estuve experimentando un poco con otro tipo de controles, que usan un protocolo de comunicación muy simple (inclusive más simple que el utilizado por el control de SNES) en el banco de pruebas, haciendo adaptadores USB de dichos controles. En esta ocasión las víctimas de los experimentos fueron un stick de seis botones para Sega Genesis y un control de Sega Saturn.

Ambos controles basan su funcionamiento en un multiplexor, en el cual el estado de la terminal de selección determina cuáles botones serán puestos en las líneas de datos. El control de Genesis tiene una sola línea de selección y seis líneas de datos, por lo que la lectura de los estados de todos los botones es muy rápida. El control de Saturn funciona de forma similar, sólo que en éste caso se tienen dos líneas de selección y cuatro líneas de datos.

En la computadora, ambos controles funcionaron bien. Sin embargo, al tratar de probar los controles en su plataforma destino ahí fue donde todo valió... ¡Un momento! ¡Eso ya lo he escrito antes X_x!

Aquí ya todo comenzó a verse muy sospechoso. Las desconexiones que sufría la interfaz con el control de Playstation las atribuí a las demoras en la entrega de datos del control, sin embargo, cuando el problema persistió en otros controles que son mucho más rápidos fue cuando comprendí que el problema residía en otra parte. Hice unas pruebas de lectura de puerto... y ahí salió el culpable.

La interfaz para el MapleBus hecha con un ATTINY25 funcionó muy bien, pues aunque en ocasiones había errores en la recepción de bits, unas rutinas de reconstrucción de datos muy básicas permitían leer de forma consistente el bus. Para conectar al Maplebus los controles de Playstation, de Genesis y de Saturn es necesario utilizar un microcontrolador con más pines que los ocho que tiene el ATTINY25. Mi elección fue el ATTINY2313.

Para mantener la sincronía con el MapleBus, el ATTINY25 funciona a una frecuencia de 16MHz. La señal de reloj es generada por el oscilador interno (que funciona a 1MHz) y un PLL (Phase-Locked Loop) que escala esa frecuencia hasta 64MHz. El microcontrolador divide internamente la frecuencia del PLL entre cuatro, lo que da como resultado la señal de reloj de 16MHz. Esta señal de reloj es muy inestable y varía mucho su valor.

El ATTINY2313 no cuenta con un PLL, por lo que la señal de reloj es provista por un cristal de cuarzo de 16MHz. El cristal genera una señal de reloj muy estable.

Al portar el programa del ATTINY25 al ATTINY2313, uno esperaría que ambos circuitos funcionaran de forma similar, o inclusive, que el ATTINY2313 fuese capaz de mantener la sincronía con el bus de una forma más efectiva que el ATTINY25, ya que su señal de reloj es mucho más estable. Sin embargo, el resultado fue completamente opuesto, el ATTINY2313 entregaba demasiados errores de lectura.

Con unas modificaciones en el firmware, pude conectar de forma satisfactoria el control de Saturn al MapleBus, aunque el adaptador provoca tres errores relativamente graves. El primero es que al ser conectado, el adaptador no siempre funciona, así que es necesario intentar la conexión un par de veces. El segundo problema es que al iniciar algún juego, la interfaz se desconecta. La tercera es que los botones C y Z no son reconocidos dentro de las opciones de los juegos, aunque misteriosamente ambos botones funcionan correctamente al ser pulsados. Una vez que la interfaz es reconocida por el juego, no sufre desconexiones.

Resta hacer pruebas con la interfaz modificada y el control de Playstation, sin embargo he llegado a la conclusión que se necesita de otro tipo de circuitos para realizar una interfaz que responda de forma más confiable y que permita añadir soporte para periféricos. El microcontrolador es una herramienta muy útil, aunque en la interfaz con el MapleBus es necesario utilizar muchos trucos para establecer la comunicación. Debido a la arquitectura del MapleBus, al parecer es más conveniente realizar la interfaz con un CPLD (Complex Programmable Logic Device), que sea capaz de responder a los cambios de nivel en la señal y mantenga la sincronía en todo momento con la interfaz.