UniJoystiCle + mouse/paddles

[riq]

Voy poniendo aca info que fuimos discutiendo con @Maniako

- Descripción de como funciona el mouse 1351:
http://www.zimmers.net/anonftp/pub/cbm/documents/projects/interfaces/mouse/Mouse.html
(similar a los que sugirió @pastbytes en el otro hilo)

- Emulador de paddles de Leif Loomquist:
https://github.com/LeifBloomquist/JoystickEmulator/blob/master/Arduino/PaddleEmulator/PaddleEmulator.ino

(ya me dió el Ok para que usemos su código en caso que lo necesitemos... lo vi y creo que es lo que necesitamos más/menos algunas cosillas).


Y aca, estuvo haciendo pruebas con el osciloscopio con los pot-x / pot-y del joy#1 de una C128D NTSC:



Tiene un período de 500ms. La documentación dice que el período es de "512 CPU cycles" lo cual es coherente ya que en NTSC un CPU cycle es 1.022727hz


512 /  1.02272 = 500.625... lo cual es muy parecido a 500us.

Debería hacer la prueba en un PAL, pero en teoría el período debería de ser de:
512 / 0.985248 =  519.666 us... o sea unos 20 ms más lento, y es algo a tener en cuenta cuando se emula el mouse... pero según lo leido no debería afectar mucho.

Lo bueno, también, es que ambos POTs (pox y poty) estan sincronizados, y no me extrañaría que los 4 pots (x,y del joy#1 y #2) este también sincronizados. y eso simplificaría el código y circuito un poco.


Bueno, esto es solo el comienzo, invito al que quiera a contribuir/participar/probar/etc...

La idea es hacer que el unijoysticle soporte mouse/paddles/etc.

[riq]

Probado en 3 máquinas más:

C64C PAL: Período de 520us.  Max V: 1.5V


C64 Drean: Período de 500us. Max V: 150mv


C64 NTSC: Período de 500us. Max V: 150mv



La C64C PAL, que es "C", tiene el mismo voltage que la c128d ntsc. Va de 0 a 1.5V aprox.
Pero la C64 NTSC y la Drean van de 0 a 150mv. No creo que sea un problema (bah... yo que se), pero es para tener en cuenta cuando se lea.

La otra cosa que noté, es que en las 4 máquinas que probe, no tengo ningun valor del puerto 2. No creo que las 4 máquinas justo tenga roto los dos pots del puerto 2. Y probé cambiando los cables y demás, y no hubo caso.
Por lo que me llevaría a pensar que no es posible usar un mouse 1351 (pero si paddles) en el puerto 2.

[josepzin]

Según creo desde el puerto 1 se sacan los dos spinners/paddles, o al menos eso recuerdo de cuando estuve mirando el tema.

A ver si estoy haciendo el sinver

[josepzin]

Efectivamente, he dicho una tontería

https://www.c64-wiki.com/index.php/Control_Port

Pero no sé porqué pensaba que desde el P1 se podía sacar los dos spinners.

[riq]

Efectivamente, he dicho una tontería

no, el que dijo un tontería fui yo parece.
tengo que habilitar el port #2 para que use el mouse.


 $DC00/56320/CIA1+0:   Data Port A (Keyboard, Joystick, Paddles)

   +----------+---------------------------------------------------+
   | Bits 7-0 |   Write Keyboard Column Values for Keyboard Scan  |
   | Bits 7-6 |   Paddles on: 01 = Port A, 10 = Port B       

por default, esta habilitado el port #1

mañana sigo probando... no se que pasará si uso "%11"... supongo que habilitará ambos ports. y si hago %00 supongo que apagará ambos ports.

[pastbytes]

Esa habilitacion va directo a los 4016/4066 (nunca me acuerdo cual de los dos usa) para seleccionar entre los dos puertos de joystick, el SID solo lee 2 potenciometros, si vos activas los dos a la vez supongo que leeras una mezcla de todo porque van a estar dos potenciometros en paralelo descargando el capacitor, pero ya no tiene que ver con el SID, es un circuito externo.
Recomiendan esperar un tiempo desde que cambias de puerto hasta que empezas a hacer una lectura.

[riq]

@pastbytes gracias. buen dato. claro, ahora me va cerrando un poco más la info que fui leyendo.

seguí haciendo pruebas, y al menos, los POTs del joystick se "activan" (reciben voltage para la sincronización) con los bits 6-7 del $DC00.

Con un valor de 64 (joy 1 activado se ve):


Con un valor de 128 (joy 2 activado se ve):


Con un valor de 0 (ambos joys desactivados):


Con un valor de 192 (ambos joys activados):


como hice las pruebas en BASIC, se ve también los POTs de abajo (joy #1) estan prendidos casi todo el tiempo. lo más probable es que el BASIC lo prenda para la lectura del teclado o yo que se.

Amarillo/celeste: POTX/POTY joy #2
Rosa/Azul: POTX/POTY joy #1


¿y que saco de todo esto?
- que el SYNC (falling) puede ser de 150mv a 0v ó de 1.5V a 0v
- que me tengo que colgar tanto el joy#1 y joy#2 para la sync ya que no se de que puerto puede venir.
- pero solo de un pot: ó POTX ó POTY pero no hace falta ambos.
- que en PAL el período es 20us más largo que en NTSC/Drean. Aunque no debería afectar mucho esto.

[pastbytes]

En realidad si podes saber de que puerto viene, mirando las lineas que activan las llaves, lo que pasa es que esta todo compartido, las 16 lineas de lectura del teclado, 8 de salida (en el puerto 2 de joystick) y las 8 de entrada (en el puerto 1) cambian todo el tiempo, y las señales para activar las llaves de los potenciometros cambian al menos 50/60 veces por segundo cada vez que se lee el teclado.
Pero supongo que te referis a que externamente (para el unijoysticle) no podes saber cual puerto esta seleccionado, pero en realidad si vas a emular deberias hacerlo tal como lo haria un mouse o paddle en la realidad, empezar a contar apenas recibe el pulso de sincronizacion, no interesa si el pulso no es valido, se supone que el soft ya sabe que sale basura por el puerto cuando lee el teclado, asi que no va a tomar como valido lo que el unijoysticle envia, y te va a dejar pasar el pulso como corresponde antes de pedirte una lectura valida.

[riq]

Pero supongo que te referis a que externamente (para el unijoysticle) no podes saber cual puerto esta seleccionado, pero en realidad si vas a emular deberias hacerlo tal como lo haria un mouse o paddle en la realidad, empezar a contar apenas recibe el pulso de sincronizacion, no interesa si el pulso no es valido, se supone que el soft ya sabe que sale basura por el puerto cuando lee el teclado, asi que no va a tomar como valido lo que el unijoysticle envia, y te va a dejar pasar el pulso como corresponde antes de pedirte una lectura valida.

si, eso mismo. ni bien reciba el pulso de sync (ya sea del puerto 1 ó 2), conecto los 5V con los distintos POTs durante los nano-segundos que sean necesarios para poder simular el valor correcto.
y en caso que no tenga ningún pulso de sync, no pasa nada, ya que entonces la c64 no estaría esperando nada por los POTs.

[riq]

progreso:



que significa eso?

amarillo: la señal enviada por la c64
celeste: el MCU subiendo/bajando un GPIO de acuerdo a la señal de la c64.

estan sincronizadas como ven y eso es bueno... tengo suficiente CPU como para poder sincronizarlas. Lo que tengo que hacer, es depende de cierto valor, alargar o achicar la señal de "arriba".

pero por ahora no estoy haciendo nada con el WiFi... no se si cuando me ponga a parsear paquetes no tenga suficiente CPU.

en ese caso tendré que saltearme algunos frames... todavía tengo que hacer muuuuchas pruebas más.

estoy usando el ESP32 que tiene dos cores... asi que veré si es posible parsear los paquetes en un core, y en el otro manejar los GPIOs que van a la c64.


código:
https://github.com/ricardoquesada/unijoysticle/blob/master/firmware/esp32/main/main.c

estoy usando la API de Espressif directamente, y no la Arduino porque:

- la API Ardunio para ESP32 no funciona bien
- quiero estar lo más cerca posible del "metal" para poder sincronizar bien la cosa.

Y la otra cosa, es que antes había dicho que la c128/c64pal median 1.5v y las c64 NTSC/Drean median 150mv... bueno, lo más probable es que haya tenido mal las sondas / osciloscopio. seguro que alguna estaba en 10x y el otro en 1x o viceversa ya que estuve tocandolos mientras media.

[riq]

progreso:

https://youtu.be/DCLmAfhAoH4


puedo controlar al menos un pot por wifi sin que se desincronice... bueno, lo que tengo que hacer es enviar varios paquetes para ver que sucede.

pero es un progreso interesante... al menos pareciera que es factible hacerlo con el esp32.

[riq]

hice la prueba conectando todo en la c64, y midiendo el valor del POT desde la c64 y puede tener un valor estable entre 68 y 255.

pero no pude leer valores entre 0 y 68 ya que la interrupción Raising me llega unos ciclos tarde.
La solución es usar Falling (como el ejemplo de Leif Bloomquist). Pero el problema es que la interrupción "Falling" tiene un bug al parecer (o yo estoy usando mal la API) y se dispara tanto en Raising como Falling.

La cosa es que no puedo seguir hasta que no se arregle este bug (o encuentre un workaround) que lo documenté aca:
https://github.com/espressif/esp-idf/issues/199

ah... otra cosa... perdí algunos paquetes UDP. no es bueno eso. tengo que revisar el código.

[danytoon]

Riq estás leyendo en Lemon lo que ha hecho este tipo?

http://www.lemon64.com/forum/viewtopic.php?t=63027&highlight=

[riq]

no lo había visto.  no vi mucha documentación técnica, pero parece bueno lo que hace.

[riq]

le agregué un inversor lógico (un 7404) entre la señal del POT y la entrada al ESP32. Lo hice pensando en:

- Si la señal "falling" no anda, entonces la invierto y leo la señal "rising".
- Como "beneficio" adicional convierte la señal analógica del POT en una digital.

la cosa es que al agregarle el 7404 ahora puedo leer tanto la "falling" como la "rising" sin problemas. Lo que es buenisimo! (asi que el ESP32 tiene un bug al detectar el "falling" de la señal del POT). Pero si la señal es más o menos cuadrado ("digital"), no hay problemas.

asi que ahora todo funciona como quería, salvo que por alguna extraña razón no puedo hacer el condensador del POT cargue cuando quiero... según el osciloscopio estoy haciendo todo bien.
Peroobviamente estoy haciendo mal. hice esta prueba anoche, asi que puede haber puesto algun cable mal o algo.