Probando el TZXDuino [y CASDuino, MaxDuino,...]

[Troopa jr]

en el fichero de config donde has descomentado la línea "#define LCDSCREEN16x2 ", asegúrate de tener comentada "//#define OLED1306 "
no sé si será el caso, o si lo habréis hablado ya por aquí, pero recuerdo tener un error parecido cuando lo grabé

espero que sea de utilidad

Hola Troopa jr,

Gracias,

No, es que se han perdido mensajes cuando se cayó el foro estos días. Ya lo soluciné, era algo tan tonto como que en una línea puse

#ifdef LCD16 || LCD20

Cuando debía haber puesto

#if defined(LCD16) || defined(LCD20)

Muchas gracias de todas formas.

ah, genial, me alegro de que esté solucionado
salu2

[Troopa jr]

Buenas,
He montado un arduino nuevo con la última versión del maxduino, y llevo un par de semanas probándolo con spextrum, msx y amstrad.
He notado en el amstrad 464 que algunos juegos en CDT no me cargan bien. El ordenador arranca la carga, identifica el juego, llega a mostrar el mensaje de loading, o el título del juego...y se queda ahí, con el borde de la pantalla cambiando lentamente de color, pero sin llegar a cargar el programa correctamente. Y no me ocurre con todos, solo con algunos (abu simbel, army moves, por ejemplo)
Conecto el maxduino con un adaptador de jack a cinta de estos:

Supongo que no será la mejor forma, porque meterá ruido, pero con este sistema cargo juegos reproduciendo un WAV o MP3 desde móvil sin problema. ¿Sabéis a qué se puede deber?
Lo he probado también en Spectrum (con TAP y TZX) y MSX (TSX y CAS) y me ha funcionado sin problemas todos los juegos que he probado.
Gracias,
Saludos

[Alki]

Buenas,
He montado un arduino nuevo con la última versión del maxduino, y llevo un par de semanas probándolo con spextrum, msx y amstrad.
He notado en el amstrad 464 que algunos juegos en CDT no me cargan bien. El ordenador arranca la carga, identifica el juego, llega a mostrar el mensaje de loading, o el título del juego...y se queda ahí, con el borde de la pantalla cambiando lentamente de color, pero sin llegar a cargar el programa correctamente. Y no me ocurre con todos, solo con algunos (abu simbel, army moves, por ejemplo)
Conecto el maxduino con un adaptador de jack a cinta de estos:

Supongo que no será la mejor forma, porque meterá ruido, pero con este sistema cargo juegos reproduciendo un WAV o MP3 desde móvil sin problema. ¿Sabéis a qué se puede deber?
Lo he probado también en Spectrum (con TAP y TZX) y MSX (TSX y CAS) y me ha funcionado sin problemas todos los juegos que he probado.
Gracias,
Saludos

tienes posibilidad de probarlo con el cable?, ademas del jack de audio, lleva otro para las pausas.. es posible que al cargarlo por audio solo no haga las pausas..

[merlinkv]

Pues puede ser la causa, para que muchos CDT carguen de tirón se necesita la señal de "Motor ON" y el cablecito de turno que la activa/desactiva.

[Troopa jr]

Es cierto, no había caído en el tema de las pausas.
Como al cargar WAVs funcionan bien con el adaptador, pues no había pensado que fuese necesario aquí...
Miraré de hacerle el mod para añadir el conector de audio externo.
Muchas gracias por la ayuda

[javier2112]

Vengo de Retrowiki de comentar una cosa que ha pasado desapercibida, cuando me he dado cuenta que este hilo es el mejor sitio donde ponerlo.

Uso el TZXDuino Nano diseñado por Cracken_Designs (viewtopic.php?p=160181#p160181):


He hecho muchas pruebas probando diferentes conectores y cableados distintos, hasta cambié el jack hembra, pero no acababa de ir fino. Le pregunté y me comentó un detalle que me había pasado desapercibido, y es que en el mismo jack de audio va la señal del motor:


Eso implica que no se puede anular el pin central para conseguir mayor fiabilidad en la conexión.

Un vez resuelto esto, he podido cargar perfectamente en un +3 y en un Zx-Uno, pero con mi harlequin revisión D seguía teniendo un problema: el sonido se oye bien y pilla las cabeceras, pero no el resto de tonos guías. Como tiene fama de cierta sordera, lo achaqué a eso, pero lo cierto es que al extraer ligeramente el jack de tzxduino, la carga funcionaba bien.

Volví a hacer más pruebas hasta que se ha ocurrido intercambiar los pines de audio y masa y con esto lo he solucionado. Resulta curioso que el conector del EAR de mi harlequin vaya cableado al revés, pero más aún que con voltajes negativos el sonido se escuchara correctamente y el ordenador consiguiera detectar las cabeceras.


Saludos.

[TorpedoJavi]

He hecho muchas pruebas probando diferentes conectores y cableados distintos, hasta cambié el jack hembra, pero no acababa de ir fino. Le pregunté y me comentó un detalle que me había pasado desapercibido, y es que en el mismo jack de audio va la señal del motor:
Saludos.

Si el jack lleva 2 señales ¿El cable que le conectas no debería ser un jack de 2 señales a 2 jacks de una señal paras que fuera bien? Esos 2 jacks mono uno sería el audio y el otro el motor.

Saludos.

[javier2112]

He hecho muchas pruebas probando diferentes conectores y cableados distintos, hasta cambié el jack hembra, pero no acababa de ir fino. Le pregunté y me comentó un detalle que me había pasado desapercibido, y es que en el mismo jack de audio va la señal del motor:
Saludos.

Si el jack lleva 2 señales ¿El cable que le conectas no debería ser un jack de 2 señales a 2 jacks de una señal paras que fuera bien? Esos 2 jacks mono uno sería el audio y el otro el motor.

Saludos.

Sí, el cable debería ser como dices. Lo que sucede es que las pruebas las he hecho con Spectrums, que no necesitan la señal, así que simplemente no la uso en el cable.

Lo que quería destacar es que, dado que la señal de audio es simétrica respecto a 0V, a los Spectrums les da igual que se intercambie la señal de audio por la masa, pero no es así en el caso del harlequin rev D, en cuyo caso sólo funciona bien intercambiando dichas señales, por la forma en que tiene implementado el puerto EAR.

Saludos.

[Troopa jr]

Hola,
Voy a instalar un maxduino en un +2, sustituyendo un datacorder averiado.
Como tengo sitio en el hueco que queda, quería poner una pantalla LCD 20x4.
Revisando algún post anterior veo que @merlinkv comentaba que cambiando estas líneas podía funcionar:

Código: Seleccionar todo

---------------------------------------------------------------
  #include "LiquidCrystal_I2C_Soft.h"
  LiquidCrystal_I2C lcd(LCD_I2C_ADDR,16,2); // set the LCD address to 0x27 for a 16 chars and 2 line display
  char indicators[] = {'|', '/', '-',0};
  uint8_t SpecialChar [8]= { 0x00, 0x10, 0x08, 0x04, 0x02, 0x01, 0x00, 0x00 };
  #define SCREENSIZE 16
---------------------------------------------------------------
  #include "LiquidCrystal_I2C_Soft.h"
  LiquidCrystal_I2C lcd(LCD_I2C_ADDR,20,4); // set the LCD address to 0x27 for a 16 chars and 2 line display
  char indicators[] = {'|', '/', '-',0};
  uint8_t SpecialChar [8]= { 0x00, 0x10, 0x08, 0x04, 0x02, 0x01, 0x00, 0x00 };
  #define SCREENSIZE 20
---------------------------------------------------------------

Sin embargo, he hecho ese cambio y mi pantalla de 20x4 dibuja las letras solo en el área de 16x2.
¿Sabéis si tengo que cambiar algo más?
gracias!

[Troopa jr]

bueno,
estoy revisando el código y veo que el tema va más allá de ese cambio, jejeje
parece que hay que actualizar las funciones de escritura en pantalla para que tengan en cuenta los 20 dígitos y las 4 líneas, no sólo ampliar el área de escritura...
pues a trastear se ha dicho