ZXUnoPS2 en arduino, fuentes y binario.

Proyectos ajenos al equipo oficial pero desarrollados o promovidos por la comunidad, relacionados con el ZX-UNO / Projects outside the official team but developed or promoted by the community, related to the ZX-UNO
Avatar de Usuario
spark2k06
Mensajes: 1188
Registrado: 12 Feb 2016, 13:58

ZXUnoPS2 en arduino, fuentes y binario.

Mensaje por spark2k06 » 07 Sep 2017, 12:38

Hola,

Abro nuevo hilo para tener localizado en un mismo sitio código y binarios referentes al control del ZXUno mediante teclado desde Arduino, por ejemplo para el ZXGo+ o un teclado externo de spectrum adaptado simplemente con un arduino dentro, para conectar a un ZXUno. Igualmente servirá para centralizar todas las dudas, problemas, revisiones, etc... relativos al mismo.

El proyecto queda en principio dividido en dos ramas, una que la mantiene neuro:

https://github.com/neurorulez/zx1ps2/tr ... /MultiCore

y la mía, fork de la anterior:

https://github.com/spark2k06/zxunops2

Guía de uso, por jsj:

https://github.com/jsanjose/ZXGO-Manual

Partiendo de la base de que no tiene menos funcionalidades que el original y que a día de hoy tampoco le veo inconvenientes respecto al mismo, las ventajas serían las siguientes:

-> Mejora del proceso de interceptación de teclas pulsadas y soltadas por la matriz de teclado, incluyendo la combinacion de CAPS y SYMBOL por cada tecla para facilitar su gestion en modos distintos al de ZXSpectrum. Esta mejora ha permitido eliminar la anterior gestion y simplificarla, evitando asi pausas entre teclas cuando se usan junto con CAPS o SYMBOL.

-> Antighosting de CAPS y SYMBOL en cores distintos al de ZXSpectrum.

-> Posibilidad de ver la version de firmware con CAPS+SYMBOL+V en cualquier modo, incluido el de ZXSpectrum.

-> OPQA mapeado en cursores para el modo PC:

phpBB [media]


-> Posibilidad de ser usado con teclados +2A/+2B/+3:

phpBB [media]


-> Nueva funcion para almacenar el estado actual de modo de teclado en la EEPROM del atmega, y este sea cargado por defecto al conectarlo. Muy util si se quiere dejar durante el arranque del ZXUno un core por defecto distinto al del ZXSpectrum. A esta funcion se accede mediante el combo CAPS+SYMBOL+X.

-> Nuevas funcionalidades para el modo de teclado PCXT:

-------> Funcion tipematica simulada (aunque mejorable mediante interrupciones y tiempos precisos). Necesaria para el core de PCXT y muchos conversores comerciales de PS/2 a USB. Si estos no la necesitan no pasa nada porque sera ignorada por el mismo, ya que los teclados PS/2 convencionales funcionan de esta manera.

-------> Deshabilitacion de escucha de comandos una vez inicializado el teclado. Aunque la escucha permanece activa si se estan recibiendo comandos echos (algunos conversores comerciales de PS/2 a USB lo requieren para su correcto funcionamiento). La escucha activa de comandos es especialmente problematica con el uso simultaneo de otro teclado.

-------> Si se va a usar como teclado externo, es importante haber guardado previamente en la EEPROM el modo de teclado PCXT, ya que sólo este modo dispone de escucha activa temporal hasta la inicializacion del mismo.

-------> Si se va a utilizar un conversor comercial de PS/2 a USB, es importante que sea de tipo activo, ya que los pasivos solo funcionaran con teclados duales (estos en su firmware son capaces de identificar y controlar tanto PS/2 como USB).
Última edición por spark2k06 el 07 Jun 2019, 09:29, editado 12 veces en total.

Avatar de Usuario
neuro_999
Mensajes: 692
Registrado: 06 Oct 2015, 10:14

Re: RE: ZXUnoPS2 en arduino, fuentes y binario.

Mensaje por neuro_999 » 07 Sep 2017, 12:59

spark2k06 escribió:Hola,

Abro nuevo hilo para tener localizado en un mismo sitio código y binarios referentes al control del ZXUno mediante teclado desde Arduino, por ejemplo para el ZXGo+ o un teclado externo de spectrum adaptado simplemente con un arduino dentro, para conectar a un ZXUno. Igualmente servirá para centralizar todas las dudas, problemas, revisiones, etc... relativos al mismo.

El proyecto queda en principio dividido en dos ramas, una que la mantiene neuro:

https://github.com/neurorulez/z ... /MultiCore

y la mía, fork de la anterior:

https://github.com/spark2k06/zx ... r/zxunops2

Siendo la principal diferencia el modo de envío de las teclas especiales. Cada cual tiene sus pros y contras, yo me centraré en ir resolviendo los que mi versión puedan generar, sin embargo estoy seguro que los dos podremos aprovecharnos de ideas y soluciones de cada uno :-)
Totalmente de acuerdo [emoji2] soy el primer interesado de que soluciones los problemas en ese modo y logres que funcione. (yo de esa forma fui incapaz xq tendría que haber cambiado la base de la matriz via array 2d y eso lo descarte).
A ver como te va yendo, y quien sabe, igual en un futuro vuelvo a tener tiempo libre para hacer pruebecillas.
Suerte y sigo de cerca el hilo para ver como evoluciona.

Enviado desde mi ONE A2003 mediante Tapatalk

Avatar de Usuario
spark2k06
Mensajes: 1188
Registrado: 12 Feb 2016, 13:58

Re: ZXUnoPS2 en arduino, fuentes y binario.

Mensaje por spark2k06 » 09 Sep 2017, 06:15

neuro_999 escribió:Las pruebas las hacia principalmente en el de msx que es que que tenia mas simbolos para probar (hasta q se resintetizo el de c64 con pullup claro :)) y los errores vienen cuando usas varias teclas a la vez con symbol o shift y luegos sueltas el aymbol o shift, (creo recordar que de aquello hace meses) y la verdad es que hacer pruebas tmpco puedo xq no tg tiempo (sino habria afinado el mío, que no lo descarto en el futuro).
Seguro que alguien por aqui te hace pruebecillas y lo vas afinando. ;}

Enviado desde mi ONE A2003 mediante Tapatalk
He hecho pruebas en MSX simulando tres teclas, symbol, T y M. los simbolos de T y M en el teclado de un spectrum correspondientes a la combinación con symbol son > y . respectivamente, y estos mismos se consiguen con un mismo scancode combinado con tecla shift o no de un teclado ps/2 convencional respectivamente también, el scancode correspondiente a dicha tecla es el 0x49.

Pues bien, en un uso normal en el core de MSX no observo ningún problema (pasando de uno a otro y manteniendo la tecla symbol apretada), si nos ponemos hacer cosas raras como dejar la T apretada y soltar la tecla symbol (cuando lo normal es soltar T y pasar a otra tecla con symbol apretado, o soltar primero T y después symbol), pues sí, puedes llegar a conseguir la repetición, pero es que este no es un uso normal, y también podría suceder si tratas de hacer eso mismo con un teclado ps/2 convencional.

De todas formas, me vais diciendo con lo que veáis y si lo puedo simular lo haré, por otro lado continuaré realizando pruebas mas complejas ya cuando me llegue la membrana de mi teclado gomas.

Avatar de Usuario
spark2k06
Mensajes: 1188
Registrado: 12 Feb 2016, 13:58

Re: ZXUnoPS2 en arduino, fuentes y binario.

Mensaje por spark2k06 » 09 Sep 2017, 16:58

Si la membrana no va al ZXUno, el ZXUno va a la membrana... probado rápido y funcionando, mañana lo pruebo mejor :-)Imagen

Enviado desde mi Thor mediante Tapatalk

Avatar de Usuario
yombo
Mensajes: 487
Registrado: 05 Oct 2015, 14:10

Re: ZXUnoPS2 en arduino, fuentes y binario.

Mensaje por yombo » 09 Sep 2017, 18:39

Yeah! Ésa es de un plus dos?


Avatar de Usuario
spark2k06
Mensajes: 1188
Registrado: 12 Feb 2016, 13:58

Re: ZXUnoPS2 en arduino, fuentes y binario.

Mensaje por spark2k06 » 10 Sep 2017, 06:33

De momento las pocas pruebas que estoy llevando a cabo están siendo satisfactorias, seguiré con ellas pero tras observar un comportamiento extraño en el arranque del ZXUno me he centrado en el mismo y he tirado del hilo, parece algo relacionado con el propio core (aunque igual es porque tengo una versión antigua del mismo, es la T24).

Si os fijáis, en el primer arranque (al conectarlo a la alimentación) del ZXUno en modo de teclado Spectrum y con el firmware de teclado del GO+ veréis que no podéis entrar en la BIOS, o que si entráis al selector de ROMs no podéis desplazaros por el menú... sin embargo, todo va bien tras el paso del logo del ZXUno e inicio de arranque del Spectrum. A partir de ese momento todo funciona bien, por lo que si hacéis un hard reset ya si podréis entrar a la BIOS y desplazaros por los menus del firmware, sin embargo con un teclado PS/2 convencional funciona todo aparentemente bien desde el primer momento.

Entonces he hecho la siguiente prueba, justo al conectarlo he entrado a la BIOS con un teclado convencional sin dar tiempo a que pase el logo y he ido al test de teclado, pulsando entonces los cursores se observa que se marcan los simbolos 'CAPS' y los numeros correspondientes a los cursores, sin embargo si se hace manualmente, es decir SHIFT + el numero, no va bien, marca 'SYMBOL' + el numero (y si se pulsa SHIFT + 7 sale 'SYMBOL' + V)... pero sí se marca bien si como digo tras la muestra del logo del zxuno y arranque del Spectrum, hago hard reeset y vuelvo a entrar en la BIOS... es como si se inicializara algo necesario para su correcto funcionamiento en el arranque del Spectrum.

A los que tenéis un GO+, a ver si os pasa lo mismo y con alguna versión mas reciente del core... quizá entonces este no sea el hilo mas adecuado para reportar el problema, aunque problema de relativa poca importancia porque tras el arranque del Spectrum va bien y por eso creo que ha podido pasar desapercibido.

Edito: Vale, ya se lo que pasa. Al seleccionar el layout Spectrum en la BIOS, éste no se aplica hasta el arranque del Spectrum, por eso a partir de entonces funciona bien incluso con un master reset, si no está ya solucionado en una versión nueva del core o firmware de la BIOS, creo que el layout debería ser activado justo al principio del inicio de la BIOS, porque de lo contrario, también pasa que al entrar a otro core (por ejemplo MSX o CPC), al hacer hard reset ya no está disponible el layout de Spectrum, y por tanto sucedería lo mismo de no poder entrar con la combinación SHIFT+1 (EDIT), hasta que cargue el spectrum. Pero lo dicho, lo mismo no me he enterado y esto se ha solucionado en nuevas versiones... ya me diréis o probaré. Creo que la solución está mas en el firmware que el core (tengo la 0.59 instalada por cierto).

Avatar de Usuario
Uto
Mensajes: 1394
Registrado: 17 Dic 2015, 16:39

Re: ZXUnoPS2 en arduino, fuentes y binario.

Mensaje por Uto » 10 Sep 2017, 10:32

Yo diría que todo eso está solucionado en la bios, me suena que Antonio lo cambio en la bios 63 o 63, y el firmware del go+ está basado en la 63.

Avatar de Usuario
spark2k06
Mensajes: 1188
Registrado: 12 Feb 2016, 13:58

Re: RE: Re: ZXUnoPS2 en arduino, fuentes y binario.

Mensaje por spark2k06 » 10 Sep 2017, 10:33

Uto escribió:Yo diría que todo eso está solucionado en la bios, me suena que Antonio lo cambio en la bios 63 o 63, y el firmware del go+ está basado en la 63.
Gracias, probaré con la 63 entonces.

Enviado desde mi Thor mediante Tapatalk

Avatar de Usuario
spark2k06
Mensajes: 1188
Registrado: 12 Feb 2016, 13:58

Re: ZXUnoPS2 en arduino, fuentes y binario.

Mensaje por spark2k06 » 10 Sep 2017, 16:20

Probado, con la 0.63 sí funciona bien. A mi por varias pruebas que hago, eso sí haciendo uso normal ... en CPC y en MSX, no me da ningún problema. Si se le trata muy mal, soltando symbol antes de la tecla asociada correspondiente, pues sí, podría llegar a provocar lo de las repeticiones (que se quita tan fácilmente como volver a pulsar la misma tecla), pero dado lo rebuscado de este fallo, que por otro lado se le puede dar una solución si realmente supone un problema grave, guardando un pequeño buffer de teclas especiales pulsadas para luego liberarlas, pero particularmente me parece bastante irrelevante en comparación con las molestas pausas entre teclas que se producen con el otro método, pero quizá sea sólo mi punto de vista.

Si alguien encuentra una forma de provocar este fallo, pero eso sí con un uso normal... implanto el tema del buffer y vemos si mejora.

Dicho lo cual, ahora sí, cada usuario es libre de elegir de cada repositorio de github teniendo en cuenta los pros y contras de cada uno. En principio doy por concluido este asunto, lo próximo en lo que me centraré será en tratar de realizar varias optimizaciones para que sea compatible tanto para un atmega 328p como 168, de menos recursos.

Responder