Para que se entienda el motivo del conflicto que se genera con un teclado real conectado al mismo tiempo, paso a explicar resumidamente el funcionamiento del protocolo de comunicación, pero todos los detalles los tenéis
en este artículo.
Para empezar, comentar que sea cual sea la dirección en la comunicación, la señal de reloj siempre la genera el teclado. Dicho lo cual, la trama de comunicación desde un teclado hacia el host, en este caso el ZXUno, sería la siguiente:
Keyboard (Device) -> ZXUno (Host)
Y la comunicación inversa, detallada, es la siguiente:
ZXUno (Host) -> Keyboard (Device)
Al principio pensaba que el motivo del conflicto era el comando 0xF0 que se utiliza en el set 2 de scancodes como primer byte al liberar una tecla, que era interpretado en la escucha activa que todos los teclados reales tienen, pero tras algunas pruebas adicionales he llegado a conclusión de que no es ese exactamente el motivo aunque sí el que lo provoca. Lo que sucede es que como se necesitan dos bytes muy seguidos para liberar la tecla (0xF0 y el scancode correspondiente a la tecla liberada), hay un punto durante el inicio de envío del segundo byte por parte de uno de los teclados (el de arduino por ejemplo) que el otro teclado (el real) al tener activa la escucha interpreta como inicio de comunicación por parte del ZXUno (host), pero no es éste el que se quiere comunicar y el segundo teclado comienza a generar una señal de clock al mismo tiempo para recibir el comando, esto provoca que el segundo byte no sea recibido correctamente por el ZXUno (host), y por tanto no se entere de que se ha liberado la tecla y por eso se mantiene pulsada, esto no pasa siempre, a veces el comando le llega correctamente al ZXUno y la libera. Otro efecto habitual es que otro teclado (el que trata de recibir el comando), tenga errores de paridad y tras intentos de petición de reenvío, al final acabe reiniciándose o bloqueándose.
Este comportamiento es propio del método de escucha y debería ser independiente del teclado (siempre y cuando éste disponga de escucha de comandos claro), yo de hecho ya he probado con cuatro distintos y el efecto sucede. Lo que estamos haciendo poniendo un diodo con el cátodo mirando hacia el teclado real, es que éste no pueda “escuchar” el envío ceros pero sí pueda enviarlos, en definitiva, le estaríamos capando la capacidad de escucha y por tanto de recibir peticiones de cambio de set, inicialización, encendido de leds, y poco más…
El motivo por el cual a la inversa funciona siempre bien con el GO+, es decir, se puede escribir con un teclado real conectado al mismo tiempo desde el teclado real, es porque el código de neuro no tiene activa la escucha de comandos de forma permanente, sólo lo hace cuando se selecciona el modo de teclado PC/XT, para que el core original del mismo pueda llevar a término la inicialización y poder cambiar de set. Por lo tanto, es muy sencillo reproducir este comportamiento (que falle al poco de usar el teclado real externo), solo debéis seleccionar este modo de teclado, y sin ir al core de PC, pulsar algunas teclas del teclado real. Por este motivo, he decidido dejar desactivado por defecto en JOY2PS2 la escucha en la nueva actualización, para tener controlada la parte que se puede manejar sencillamente por software.
He visto en el otro hilo sobre el GO+ que comenta Manu que es debido a interferencias que solo suceden en algunos teclados, si no te supone problema @ManuFerHi, me gustaría ver un vídeo de demostración, no es por nada, sino porque a mí me gusta llegar al fondo del asunto y saber por qué pasan las cosas, si de verdad funciona bien, díme por favor si no te importa qué modelo de teclado externo utilizas, porque estoy perplejo.
La demostración sería muy sencilla, consistiría en lo siguiente. Conectas un teclado en el GO+, y desde el editor de BASIC por ejemplo, pulsas cada poco tiempo la tecla que quieras (pero muy importante, pulsa la tecla desde el teclado del GO+), si te funciona bien durante 30 segundos… prueba superada.
Gracias
