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

[Pachuquin]

Feliz año a todos y sobre todo a ti rcmolina, gracias por la actualizacion y espero probarla con la nueva placa que me llegara pronto a modo de presentacion.

Un saludo

¿Qué placa es? ¿Vas a probarlo en un ESP8266?

[acf76es]

Seguira siendo arduino atmega 328, la placa es pcb,uuma nueva revision para tzxduino/maxduino.

[rcmolina]

Feliz 2018!

Maxduino 1.25:

+ Implementación básica del RW/FF, de bloques. Se selcciona de un buffer de 8 pasando primero por modo pausa.
De momento no hay una función de búsqueda de los bloques, por lo que hay que recorrerlos primero en modo play, luego quedan guardados en el buffer para utilizarlos.

http://filecloud.io/el4n5dkpj

[acf76es]

saludos, adjunto video de la placa TZXDUINO RELOADED Versión 1.2 diseñado por edu arana y en colaboración de jdilcas.



quería comentar que la versión MAXDUINO 1.23 y 1.25 tiene otra vez problemas de las pausas de bloques (menos de 1 seg), y no cargan bien los juegos, incluidos los de ERBE en la pantalla gráfica que no genera la pausa necesaria. está verificado porque he probado TZXDUINO 1.82b y funciona perfectamente las pausas.

Un saludo.

[rcmolina]

Hola Alfredo,

Pásame un enlace a un juego para que lo pruebe... Recuerda que hay una opción SkipPauses en el menú para cambiar este comportamiento.

Un saludo,

-
Rafa

[acf76es]

Skypauses ? ups, entonces eso no lo he visto.. ya lo miro mañana y te paso por email los ficheros tzx.

Un saludo.

[rcmolina]

@acf76es, Alfredo sigo probando pero a mí me carga bien y no consigo reproducir tu problema. Elimina "&& !pskipMask" en la rutina wave2() y así ya no le hace caso a la configuración del menú.

void wave2() {
//ISR Output routine
//unsigned long fudgeTime = micros(); //fudgeTime is used to reduce length of the next period by the time taken to process the ISR
//word workingPeriod = wbuffer[pos][workingBuffer];

....
{
if(bitRead(workingPeriod, 15) && !pskipMask)

[Spirax]

hola.
gracias por la nueva version.
no he tenido mucho tiempo para prpbarla. solo un par de cargas rapidas y parece que ok.
probe por encima el rebobinada y me hice la pixxx un lio. jejeje
seria bueno buscar un sitio para poner el bloque que se esta reproduciendo. ya que cuando lo pones en pausa y le das adelante o atras realmente no sabes a cual quieres ir y el delay es muy corto y se borra muy rapido el id.
yo reduciria la informacion solo el numero de bloque y usaria la linea 3 del oled.
ya digo que solo lo,probe 10 minutos y no me ha dado tiempo a hacerme una idea.


tengo que buscar mas tiempo o que los dias sean mas largos, jajajaja
y darle una vuelta.
lo dicho, gracias por hacernos la vida mas facil

[rcmolina]

@Spirax, gracias a tí por las pruebas, te cuento un poco más....

Al principio puede que no sea muy intuitivo, pero se le pilla el truquillo...

1.- Te compro lo de mostrar el número de bloque en la tercera línea en pantalla OLED:
2.- La información que se imprime realmente es más completa de lo que hace falta, pero creo que puede ser interesante: número de bloque/ID de bloque/offset en el fichero donde empieza ese bloque.
3.- Lo que quedaría por hacer y es la siguiente fase en la que estoy trabajando es recorrer el archivo antes de hacer el play para poder usar esta información desde el principio y no tener que reproducirlo antes. ¿guardar esta información de forma permanente en la EEPROM?

Lo que sí podría pasar es que en Maxduino que está a tope, tenga que cepillarme el menú (//#define MENU_ON 1) para ganar espacio y seguir trabajando en Maxduino o manejar combinaciones en la compilación al gusto del consumidor.

Hay otra idea, que no sé si Natalia pudo avanzar que es reproducir los ficheros cas con la función writeData4B(), con lo que se podria liberar parte del codigo de casduino para liberar espacio. Hice un ejercicio, y me atasqué un poco en la implementaciín de los silencios. No he hablado con Natalia para ver si le ha dedicado tiempo, pero parece viable.

[Spirax]

Con imprimir solo el numero de bloque me refiero a algo asi......

en el fichero maxprocesing.ino
en void TXZProcess ()

añadir estas lineas despues de adquirir el id

if(currentTask == GETID) {
#ifdef XY
setXY(0,2);
#endif
#ifdef XY2
setXY(8,1);
#endif
utoa(block, PlayBytes, 10);sendStr(PlayBytes);


Al definir letras dobles, bloqueamos las lineas 2 y 3, pero tenemos libre la mitad de la linea 1 con letra simple.

si esta en letras dobles lo escribimos en columnsa 8 en la linea 1, justo debajo del porcentaje

si esta en letras normales lo escribimos en la linea 2, que esta vacia. en la linea 3 estan las opciones del menu.

yo lo he probado con varios tzx super sensibleros que he echo yo con una rutina de carga de alta velocidad en spectrum que al minimo cambio de tiempos me salta r-tape loading error y me funciona bien si solo imprimo el numero de bloque con una unica llamada a sendstr justo en el cambio de bloque, si hago dos llamadas a sendstr para imprimir "b:" y despues el bloque ya si que me da error de lectura aunque solo con estos txz supersensibles en los que hago cambio de bloque sin cabecera y que son pure data.

Nunca he sido capaz de cargar ningun tzx de cargando leches a 6000bps. No se si por limitaciones de mi hardware, por el ampli que uso en el tzxduino, o por alguna otra limitacion software. Lo maximo que he lleguado a cargar con OTLA ha sido a 3000bps y ahi ya se pasa a 6000 y a esta velocidad no me cargan, asi que me modifique la rutina de carga de la rom del spectrum con los parametros de cargando leches calculados para aproximademente unos 4500bps, y me va de vicio. luego ya les he puesto pantallas de carga como los protegidos con alkatraz y se ven espectaculares.

si alguno quiere probar alguno de mis tzx de spectrum acelerado a 4500 bps , que me lo pida
que unque aun lo tengo en fase alfa, puedo soltar alguno en beta,

saludos