Interfaz Ratón PC - Super Nintendo (2)

Cómo usar un ratón de ordenador ps2 en una Super Nintendo.

Si te interesa entender el funcionamiento de un ratón ps2 de ordenador, no dejes de leer la primera parte de este artículo.

INTRODUCCIÓN

Después de hacer el circuito anterior, decidí intentar algo con más interés práctico.

Primero pensé en hacer un circuito que se controlara con el ratón.

Después se me ocurrió algo mucho más difícil pero que decidí intentar, con muy buenos resultados, después de más de 3 semanas de trabajo.

La Super Nintendo es una videoconsola de mediados de los 90, que tuvo mucho éxito, y que disponía de un ratón para jugar a ciertos juegos que requerían algo más que un pad o joystick.

Este ratón, como es lógico, no se vende desde el año 1997, tal vez antes, y como en su época la Super Nintendo era una videoconsola que me gustaba, decidí intentar hacer un adaptador para usar un ratón PS2, algo que nadie ha hecho nunca.

 

Para ello he tenido que investigar mucho en internet sobre la arquitectura y el hardware interno de la consola, e ir haciendo pruebas de ingeniería inversa con el analizador lógico, combinado con otras técnicas software indirectas, cargando en la consola programas escritos en ensamblador escritos por mi. Por ello, también tuve que aprender el juego de instrucciones de la CPU 65c816, una CPU de 16 bits, usada como procesador principal en la consola, y el mapa de memoria y puertos para comunicarse con los procesadores auxiliares de video.

PROTOCOLO DEL LADO DE LA SUPER NINTENDO 

El protocolo que usan los mandos de control para conectarse a la Super Nintendo es relativamente sencillo de sacar, si se tiene experiencia y equipo adecuado. Relativo es relativo. No es una tarea fácil para la mayoría.

Una señal de latch es generada por la videoconsola cada refresco de pantalla (50 veces por segundo en un televisor PAL), que indica a un registro interno del mando, que almacene 16 bits del estado de los botones pulsados.

Acto seguido, una señal de reloj , también generada por la consola, es mandada al mando. Se mandan 16 pulsos, y en cada uno se envía un bit por una línea de datos . Por tanto, el cable del mando está formado por 5 cables (latch, datos, reloj, 5V y tierra).

El pulso de match es de 12us

Cada bit de datos es mantenido durante 12us también

El reloj es el doble de rápido. Cada nivel es mantenido 6us (166 KHz).

En cada flanco de subida de reloj, el registro interno del mando, de 16 bits de desplazamiento, rota un bit hacia la línea de datos, y la videoconsola lee el dato en el flanco de bajada.

Cuando se usa el ratón en lugar del mando, el protocolo es el mismo para transmitir los botones pulsados. De los 16 bits, 2 de ellos mandan información del estado de los 2 botones presentes, en el noveno y décimo pulso de reloj.

EL PROBLEMA CON EL DESPLAZAMIENTO DEL RATÓN.

Pero la información del desplazamiento puede llegar a ser terriblemente difícil de averiguar. Me llevó al borde de la desesperación.

Primeramente porque el reloj cambia completamente mientras se envía esta información; aparenta tener una frecuencia mucho mayor, porque el duty cycle es muy bajo. El reloj está bajo únicamente 0.5us, y alto durante 8us.

El segundo problema es averiguar cómo decidió Nintendo codificar la magnitud del movimiento. Se envían 16 bits siguiendo la temporización que acabo de comentar. Así que supuse que se dedicarían 8 bits para codificar cada eje X e Y.

Después de mucho esfuerzo y muchas pruebas, descubrí que estaba codificado en magnitud y signo. Luego tendría otro problema al hace el interfaz con el ratón PS2 de ordenador, que lo codifica en complemento a 2 y bit de overflow. Al final comentaré cómo lo hice.

Tercer problema , y muy serio, era que 0.5us era un tiempo muy difícil de manejar por un PIC. Cuando el reloj bajase, tenía que mandar el bit adecuado por la línea de datos, y antes de que volviera a subir, porque sería entonces cuando la consola lo leería. Y 0.5us para detectarlo, y enviar el bit, es un tiempo brevísimo. Tuve que pensar durante horas sobre papel para encontrar la solución. La solución fue usar un contador de 4 bits, el 74LS90, para aumentar el duty cycle del reloj al 50%. Cada pulso breve de 0.5us, conectado a la entrada de reloj del 74LS90, hacía avanzar el contador. Y tomando como reloj la salida del bit menos significativo, obtenía un reloj de la mitad de frecuencia y de duty cycle 50%. Ahora tendría que programar al PIC para no actuar en un flanco de reloj, sino en cuanto cambiara el estado del reloj.

También tuve que usar un reloj de 8MHz con el PIC, porque 4MHz no era suficiente. Comprobado. Así que decidí overclockear un poco el PIC. Consulté en foros, y hablando con el autor de un circuito de seguimiento para monturas de telescopios, controlado por un 16F84A, me comentó que él usaba relojes de 20MHz con PICs etiquetados a 4MHz durante meses sin problemas, y permaneciendo encendidos durante horas sin descanso.

Mis pruebas caseras confirmaron el hecho. El PIC funcionaba a 8MHz con absoluta fiabilidad.

Mi teoría que es Microchip fabrica todos los 16F84A iguales, y tras alguna prueba los clasifica por calidad, etiquetando los menos overclockeables a 4MHz, y a 20MHz los mejores. No es de extrañar, ya que durante años, los grandes fabricantes de CPUs del mercado de los PCs, Intel y AMD, han venido haciendo estas cosas.

DISEÑO FINAL Y PCB 

Fui montando todo en una placa de prototipos.

Después de mucho esfuerzo, conseguí que funcionara. Dos de los juegos que probé funcionaban perfectamente con el ratón de ordenador. Un juego daba problemas, y tuve un poco más de paciencia para depurar con el analizador lógico, y corregir un poco el código del PIC. No era problema mío, sino del juego que parecía usar un protocolo un poco distinto, pero que conseguí adaptar, programando el PIC para autodetectar el protocolo usado por el juego (basado en esperar de tiempo delicadamente temporizado en ciertos momentos), para detectar los patrones de cada protocolo (básicamente, el nuevo protocolo sólo enviaba datos de desplazamiento la mitad de las veces que debería).

Como me sentí muy orgulloso del gran esfuerzo y los resultados obtenidos, decidí pasar a PCB el circuito. Diseñé el fotolito en el ordenador, e impreso, lo insolé de forma casera en casa, sobre una placa fotosensible positiva, revelada en metasilicato, y atacada en cloruro férrico. Yo había hecho placas con anterioridad, pero rudimentarias, nunca por métodos de insolación.

Otro problema fue conseguir el conector de la Super Nintendo. No es estándar, y es imposible conseguirlo. Al final encontré en una subasta de Internet una alargadera de mandos, de segunda mano, que compré, y que tras cortarla, me permitió obtener el conector.

A continuación adjunto diagramas de tiempo del filtrado del ratón, es decir, del PIC traduciendo el protocolo del ratón, y emulando a la perfección el ratón nativo de la Super Nintendo en el hardware real.

Aquí se ve como hago para aumentar el duty cycle del reloj de la Super Nintendo cuando entra en fase “rápida”. Uso como reloj el LSB del contador 74LS90, como expliqué.

El diagrama muestra 140us.

Aquí se ve como el PIC pide el estado de los botones y el desplazamiento al ratón (primer paquete), y la respuesta de reconocimiento del ratón (segundo paquete).

La secuencia dura 3.5ms

(como puede verse, el protocolo PIC-ratón es más lento que el de la consola)

Después de recibir los 3 paquetes de datos, se espera a que la consola nos mande el latch, pidiendo el refreso del estado del ratón nativo. Nosotros le damos la información procesada y traducida del ratón PS2 y listo!

El diagrama dura 200us.

El esquemático del circuito es el siguiente:

DIAGRAMA DE TIEMPOS DE UN CICLO COMPLETO

Un ciclo completo es compuesto por la siguientes fases:

A) Mandar el estado de los botones a la Super Nintendo
La consola nos manda un latch, y mandamos el estado almacenado en el PIC del último paquete de datos recibido del ratón. En este momento sólo mandamos el estado de los 2 botones.

B) Mandar el desplazamiento del ratón a la Super Nintendo.
El reloj de la consola cambia, y es cuando uso el truco del 74LS90 para adaptar el duty cycle y conseguir que el PIC a 8MHz sea capaz de mandar en el momento adecuado los bits con información sobre el desplazamiento.

C) Pedir nuevo paquete de datos al ratón.
El PIC pide un nuevo paquete de datos para refrescar su información sobre los botones y el desplazamiento, y procesarlo de manera que esté listo para cuando la Super Nintendo nos mande un nuevo latch. Recibimos un paquete de reconocimiento del ratón.

D) Esperamos a que el ratón nos mande los 3 paquetes de datos.
Este tiempo de proceso varía de un ratón a otro. He podido comprobar que hay ratones mucho más rápidos, que responde a todo con mayor velocidad, y tuve que retocar el código del PIC para hacerlo compatible con alguno de ellos. En principio, el protocolo deja un cierto grado de libertad en este aspecto.

E) Recibir y almacenar el estado del ratón.
Tal y como ya expliqué. Recordando que el valor de 9 bits en complemento a 2 del desplazamiento hay que pasarlo a magnitud y signo, de 8 bits, por tanto hay que descartar un bit, y yo elegí ignorar el menos significativo. Hacer eso sólo me haría perder un poco de sensibilidad/precisión, mientras que descartar el más significativo podría provocar desbordamientos en movimientos rápidos. Por tanto, al mantener el más significativo, decidí simplemente ignorar el bit de overflow. La cosa fue muy bien en las pruebas, y no se detecto movimiento errático, ni posibles overflows no detectados, en ningún momento. Es una cuestión de diseño, podría haberse elegido otra solución.