Radastan escribió:Es que siento curiosidad por como has implementado el teclado y otras cosas.
Tu pregunta... sin problemas....
Resumiendo:
Cpu usando el musashi motorola core.
Driver de video hecho por mí. Es muy fácil, solo dos modos de vídeo, con parpadeo en uno de ellos y actualmente uso misma paleta de colores que Spectrum
Interrupciones: si no recuerdo mal, no las estoy lanzando, ni se bien cómo van en el QL, pero no las echo de menos...
Solo que como puedes ver, el cursor no parpadea y debería hacerlo
No emulo el procesador Intel adicional, sino que simulo su comportamiento... Este es el encargado de gestionar teclado, microdrive y sonido, y se comunica con el Motorola mediante direcciones de memoria (puertos i/o mapeados), es lo que se llama IPC. Hay diferentes comandos IPC, uno de ellos se encarga de leer el teclado.
La comunicación mediante IPC es bit a bit, cada vez el motorola envía una señal de escritura, espera un cambio en el bit 6, y lee el bit del resultado desde el bit 7. Se podría decir que es una comunicación serial de toda la vida con un bit cada vez de espera. Esto es la parte que me ha costado más de entender, la info realmente está ahí, pero no hay ningún ejemplo de ello y claro, si no lo haces exactamente como debe ser, no pasas ni del menú de inicio (F1/F2).
Luego además, el total de 64 teclas se divide en filas y columnas. Si miras la matriz entera, no tiene ninguna ordenación lógica posible, debe ser algún tipo de pesadilla sufrida por algún ingeniero de Sinclair...
Con todo esto, dado que al principio no me funcionaba el teclado, mi meta fue poder saltar el menú de inicio. Para ello, tuve que ver en que momento se leía la tecla y simular el F1 o F2. Ese es uno de los traps a la rom que primero hice, pero que actualmente tengo desactivado en el código fuente, pues ya no hace falta pues el teclado funciona. Para hacer esto, me fue muy útil mi debug y la capacidad de poder ver el código fuente de la rom del QL a medida que desensamblaba.
Después de poder simular el F1 o f2, lo siguiente fue saltar el proceso de boot de microdrive. Como no lo emulo, todos los accesos a microdrive, cuelgan la rom. Y para esto, de nuevo debug y ver cómo saltar esto. Actualmente este trap si que está saltado en el código del emulador
Y después, ya en el prompt del basic, lo siguiente fue intentar devolver algún resultado mediante IPC y que mostrase algún carácter ascii en pantalla. Básicamente se basa en enviar 5 nibbles (20 bits) donde se codifica la fila y columna de la tecla, si se pulsa shift, ctrl o alt, y algún flag más. Como al principio probé con lo que decía la documentación y no funcionaba, luego puse un bucle, con un contador para esos 20 bits, e incrementando y viendo si aparecía algún carácter ascii
Después de probar con el contador, empezaron a aparecer diferentes caracteres.
Me apuntaba el valor de 20 bits junto con su carácter ascii. Así durante bastante rato (quizá 3 o 4 horas) hasta que conseguí sacar la mitad de teclas más o menos. Y de ahí no pude sacar más valores, aparte que dichos valores no parecían tener relación con lo que decía la documentación, pero al menos podía repetir cada tecla, si quería por ejemplo simular una A, enviaba la sentencia de 20 bits que ya tenía... Pero no conseguía sacar más de la mitad de teclas totales.
Después de muchas pruebas se me encendió la bombilla y puse en práctica lo del bit 6 de espera, que estaba documentado y yo ignoraba. A partir de ahí, todo tuvo lógica, todo seguía tal cual estaba documentado, excepto que la ordenación de filas tal cual dice la documentación es al revés (desde el 7 hasta el 0 hacia abajo). Y con eso ya pude sacar todas las teclas...
Básicamente es eso
He estado a punto de tirar la toalla con este tema varias veces, a esto se suma el que he pedido ayuda a varias personas autores de emuladores de QL y las respuestas han sido de tres tipos:
-gente que no me ha contestado
-gente con poca voluntad de ayudar
-y gente que pese a que quería ayudar, no recordaban como lo habían hecho y me remitían a que mirase el código fuente de sus emuladores.
Hubo uno, que no diré quién es, que me dijo que no lo recordaba , pese a que lo había implementado hacia menos de 1 año...Su respuesta en su caso fue del segundo y tercer tipo simultáneamente
Ah incluso aquí se suma otro problema, y es que la mayoría de emuladores de QL están basados en el código del viejo uqlx. Este uqlx usa también varios traps a la rom, también para el teclado. Su autor original no pude contactar con el, creo, pero algunos autores de emuladores más recientes , basados en el código de uqlx, no sabían cómo funcionaba el teclado, pues simplemente se basaron en copiar lo que ya había en uqlx.
Por supuesto que he mirado mucho el código de uqlx pero me ha servido de muy poquito, la parte de teclado no he conseguido saber que hace... es difícil siempre mirar el código ajeno...
Como decía, si quieres más info me puedes preguntar, aunque creo que casi todo está en este post, jeje. Puedes revisar el archivo ql.c de mi código, donde está todo el lío este del teclado
Saludos
Lo de la comunicación serie... pues no se, supongo que alguna ventaja tendría, o quizá era lo habitual en aquella época... Estoy pensando que quizá eso facilita la comunicación por el puerto serie RS del QL....
