Emulación bajo ESP32

[Eremus]

Bueno, pues me he puesto un rato y parece que he solucionado los problemas de carga (aparentemente).

Ole! Ole!

El motivo del problema creo que era el siguiente: ...

Perfectamente explicado

Te puedo confirmar además que, una vez compilada la nueva versión, el Scuba Dive que era el único .tap que SIEMPRE me fallaba, ha cargado perfectamente a la primera. Hare mas pruebas, desde flash y desde SD, y te contaré.

Eso si, hay algunas dudas que me surgen respecto a todo esto:

- Ahora que la temporización es exacta ¿Por qué las rayas azules y amarillas siguen pareciendo demasiado anchas? Supongo que tendrá que ver con la representación gráfica (refresco de video, fps, etc.. )

- ¿A que puede ser debido que a mi casi todo me cargara bien, aun con la temporización imprecisa, y además siempre fuera el mismo .tap (Scuba Dive) y en el mismo punto el que me fallaba? ¿Diferencias en el hardware?

Ahora voy a descansar pero no sin antes a probar el .tap de la Abadía del Crimen a ver si ahora carga

[dcrespo3d]

Ole! Ole!

Qué moñecos más monos. Me los apunto para otra vez que haya que celebrar

- Ahora que la temporización es exacta ¿Por qué las rayas azules y amarillas siguen pareciendo demasiado anchas? Supongo que tendrá que ver con la representación gráfica (refresco de video, fps, etc.. )

Esa parte me extraña un poco, pero no demasiado. El frame de vídeo no se genera como debería para ser un emulador preciso (ciclo a ciclo de CPU), con lo cual cosas como los modos multicolor no funcionan. Ahora me está dando la impresión de que se genera sólo durante una parte del ciclo del frame y por eso son las rayas más gruesas.

Por el contrario, el sonido se genera directamente desde la emulación de CPU y suena bastante bien (tengo buen oído y escuchando lo que genera el beeper he conseguido que el thread de CPU vaya ejecutando instrucciones esperando lo necesario para ir, aproximadamente, en el tiempo correcto.

Este emulador no lo empezé yo (aunque le dí un buen lavado de cara) y algunas cosas todavía no tengo claro al 100% cómo funcionan. El vídeo debería generarse en el thread de CPU para que el borde fuera bien sincronizado y los modos multicolor funcionaran...

- ¿A que puede ser debido que a mi casi todo me cargara bien, aun con la temporización imprecisa, y además siempre fuera el mismo .tap (Scuba Dive) y en el mismo punto el que me fallaba? ¿Diferencias en el hardware?

Tengo una placa lilygo y esa fallaba menos, pero en un devkit wrover que tengo dentro de un teclado ps/2 ha fallado mucho más... diferencias tiene que haber. En cuanto al Scuba, algo raro tiene que haber en ese punto...

Ahora voy a descansar pero no sin antes a probar el .tap de la Abadía del Crimen a ver si ahora carga

A mí me ha dado pereza probar cargar largas... ¿Te funcionó?

[josemrm]

espero no desviar el tema de los ultimos arreglos (.tap) del emu zxspectrum!!! ole, ole, ole (sois unos cracks, esto se va animando, bien hecho por los tres e igual me dejo a alguien mas -el autor original del emu, rampa creo, etc-)

para vuestra informacion: RTC (por soft claro) para los ESP32 (por hard ya estan los RTC y GPS):
Network Time Protocol On The ESP32 | Hackaday
https://hackaday.com/2022/05/16/network ... the-esp32/

[Eremus]

espero no desviar el tema de los ultimos arreglos (.tap) del emu zxspectrum!!!

Al contrario. El que estaba preocupado de monopolizar el hilo con la emulación de Spectrum siendo un hilo general sobre los ESP32 era yo.

para vuestra informacion: RTC (por soft claro) para los ESP32 (por hard ya estan los RTC y GPS):

De hecho, una de las cosas que me preguntaba cuando añadí los múltiples slots para snapshots al emu de David, era como guardar la fecha y hora de la grabación.

Gracias por la info, un saludo.

[Eremus]

Este emulador no lo empezé yo (aunque le dí un buen lavado de cara) y algunas cosas todavía no tengo claro al 100% cómo funcionan. El vídeo debería generarse en el thread de CPU para que el borde fuera bien sincronizado y los modos multicolor funcionaran...

Bueno, en todo caso la cosa funciona muy bien (he cargado varias cosas esta mañana desde RAM y desde SD: cero problemas) y lo de las barras es un pequeño detalle sin demasiada importancia.

Ahora voy a descansar pero no sin antes a probar el .tap de la Abadía del Crimen a ver si ahora carga

A mí me ha dado pereza probar cargar largas... ¿Te funcionó?

Pues no Lo probe con la rom SINCLAIR 48K y con la rom SINCLAIR 128K. En ambos casos llega a un punto en que, sin dar error de lectura, se detiene la carga pero se oye el rumor del .tap todavía en marcha. Investigare el asunto a ver a que puede ser debido.

Saludos

[dondiego]

Segun veo necesita 128 KB. Y wenas.

[drakepirate]

https://www.youtube.com/watch?v=9OMlajsbURs

[ackerman]

Enhorabuena a los auténticos cracks, @Eremus y @dcrespo3d, que son los que se han pegado con la carga. y estas 2 más , para llegar a gatas a casa.
Yo sólo voy hacer un copy paste, si saco un hueco este finde, con todo lo que habéis realizado.

@Eremus, al no depender del timer del ESP32, ahora ya puedes quitar las esperas y cargar a todo trapo para pruebas:

Código: Seleccionar todo

Busca delayMicroseconds(us_to_wait), que está en delay_instruction del CPU.cpp

Dentro del loop de emulación, eres dios, y puedes hacer lo que quieras, de ahi que los TSTATES son sólo marcas en un contador de variable. Como tu controlas la generación y decodificación de tonos por puertos dentro del loop de emulación, ya te da igual la sincronización del timer real del ESP32, ni de RTOS, aunque en realidad estas sincronizando en tiempo TSTATES real, es decir, tienes un timer preciso virtual.

En la página 14 de este mismo hilo, se tratan los problemas de lentitud de las particiones:
http://retrowiki.es/viewtopic.php?f=86&t=200036016&start=208
Como soluciones, está el usar una más liviana que no use pila, como LittleFS o usar una SD. Con un array a FLASH, que es como el PROGMEM de Arduino, no existen problemas de fragmentación ni pilas.

En la página 24 de este mismo hilo tienes explicado la CPU y el video:
http://retrowiki.es/viewtopic.php?f=86&t=200036016&start=368
En el original de @rampa, rellenar 32x24 tiles de video de manera no optimizada, tarda 18 ms, así que se aproximaba a los 20 ms de generación de scanlines reales del spectrum al ser lanzado como hilo. El color de borde se controla con la variable volatil que controla el loop de emulación en el hilo principal, de manera que se lo manda cambiar al hilo de video. Si se genera en menos de esos 20 ms, ganamos en no saturar al ESP32, alejandonos del spectrum real. A mi me quedaba en creo que 2 milis, así que saldrá para arrancarse los ojos, para los puristas. Como yo no soy purista, pues me parece genial, sobre todo para usarlo con un sólo núcleo.

[josemrm]

https://www.youtube.com/watch?v=9OMlajsbURs

¿sobre que va el video?
Contestación:
Apple ][+ Emulator On ESP8266 (en una mini pantalla)
This video shows the performance of an Apple ][+ emulator built on ESP8266. This emulator features a 64K apple II+. The keyboard and display use USB and LCD respectively. It support floppy and HDD images.

[ackerman]

Me he puesto a meter el código de @Eremus y @dcrespo3d en el mio y perfecto, funciona muy bien. Lo he probado en el port de x86.

Probé la abadia, sólo por probar, y tal cual decis, se queda después de la pantalla de carga.
Muchas gracias.

[Eremus]

@Eremus, al no depender del timer del ESP32, ahora ya puedes quitar las esperas y cargar a todo trapo para pruebas:

Código: Seleccionar todo

Busca delayMicroseconds(us_to_wait), que está en delay_instruction del CPU.cpp

...

Si, después del ajuste de David he estado probando la carga con el emulador lo mas "suelto" posible y ha funcionado a la perfección

En la página 14 de este mismo hilo, se tratan los problemas de lentitud de las particiones:
http://retrowiki.es/viewtopic.php?f=86&t=200036016&start=208...
En la página 24 de este mismo hilo tienes explicado la CPU y el video:
http://retrowiki.es/viewtopic.php?f=86&t=200036016&start=368...

Muy interesante todo, ¡muchas gracias!

Por ahora yo me voy a centrar en la emulación de casete. He cambiado la cosa para cargar el fichero en PSRAM y refactorizado y simplificado aun mas el código de la carga de .tap. ( https://github.com/EremusOne/ZX-ESPectr ... ttgo-vga32 ) Lo siguiente será, probablemente, la carga de .tzx

Probé la abadia, sólo por probar, y tal cual decis, se queda después de la pantalla de carga.

Pues si. Pensaba que cargar las cosas desde RAM podría marcar alguna diferencia (alguna interrupción del sistema de archivos que la desestabilizara) pero no ha influido en absoluto. Lo curioso es que si cojo el mismo .tap de la Abadia, lo cargo en Spectaculator y genero un .z80 nada mas terminar la carga, ese .z80 funciona bien en el emulador de David. Solo falla si lo cargo desde el fichero .tap

También me ha llamado la atención que, en el emulador de David, las ROMS Plus3 y Plus3E no arrancan. No se si tendrá algo que ver con los problemas de la carga .tap del Abadía.

[zx81]

Acabo de probar el TAP de la Abadía y no veo que tenga nada especial, debe usar la rutina de carga de la ROM. La versión tzx es otra historia porque usa una rutina de carga lenta, alrededor de un 65% de la velocidad estándar y, de hecho, falla en casi todos los cores de FPGA también.

Como no se trate de algún problema con el puerto de paginación, no veo otra razón para que falle.

[Eremus]

Acabo de probar el TAP de la Abadía y no veo que tenga nada especial, debe usar la rutina de carga de la ROM. La versión tzx es otra historia porque usa una rutina de carga lenta, alrededor de un 65% de la velocidad estándar y, de hecho, falla en casi todos los cores de FPGA también.

Como no se trate de algún problema con el puerto de paginación, no veo otra razón para que falle.

Pues aun no se cual puede ser la causa. Por reunir mas evidencia, he probado con otros .tap de 128K (Starglider y Where time stood still) y no funciona ni uno. En Fuse cargan sin problema. Incluso en JSpeccy.

En todos los casos parece que fallan antes de que termine la cinta. En determinado momento dejan de cargar.

[Eremus]

Hola de nuevo,

Acabo de subir al repo ( https://github.com/EremusOne/ZX-ESPectr ... ttgo-vga32 ) la ultima versión con un añadido interesante para la carga de .TAPs : el botón de Play ahora es Play/Pause. Esto me ha permitido cargar .TAP multinivel como el Pang p.e.

La Abadía del Crimen ya carga correctamente y lo mejor de todo es que no tengo NI P*T* ID** de porqué Estaba optimizando cosillas aquí y allá y, en determinado momento, ha funcionado. Pensando que era por el ultimo ajuste, lo quité para verificar el asunto y seguía cargando bien. Tras probar cuatro o cinco cosas y ver que sigue cargando perfectamente, he decidido no darle mas vueltas y disfrutarlo.

He probado además un montón de archivos .TAP, de 48k y de 128k. En 48k todo lo que he probado ha funcionado perfectamente, desde flash y desde SD. En 128k ha habido de todo pero, en general la cosa ha ido bastante bien y he podido cargar bastantes cosas (Enduro Racer, Moon Strike, Pang, Karnov, Cybernoid II y el citado Abadía del Crimen) sin demasiado problema.

Ya me contais que tal si lo probais

[ackerman]

Enhorabuena @Eremus, si tira, perfecto.
Lo que dice @zx81 del 65%, me da que hay que tenerlo en cuenta. Como suele ser habitual, José Luis no es que acierte mucho, es que lo clava.
Yo he probado ahora rápido con lo del otro día (no con lo de ahora) en el port de x86(puede que haya metido la pata en algo), pero dejando al 65% todas las constantes desde TAPE_SYNC_LEN hasta TAPE_BLK_PAUSELEN, en la ABADIA, carga todo, menos el último bloque. De hecho, termina en el BASIC con los bloques cargados y se puede ver el código de BASIC. Si lo dejaba sin ese ajuste, sólo llegaba hasta el bloque de la pantalla de inicio del monje.

cinta.gif (3.37 KiB) Visto 3325 veces

Ya haré más pruebas con más calma si saco más tiempo y te contaré, pero vamos, está genial.

Lo que has creado tiene muchísimo potencial, dado que genera el tren de pulsos. Pero la forma de generar el tren es constante. Como los .tap es una forma de preservar más en digital (interceptar rutina 0x056B), sin dejar datos de baudios, me da que hay que controlar todas las constantes de TAPE_SYNC_LEN hasta TAPE_BLK_PAUSELEN para cambiarlas en caliente (variables), o sea, para bajar la velocidad de la cinta a mano (desde OSD o teclado). En los tzx, como se tiene datos de baudios, sería más automático.

[zx81]

Lo que tiene guasa del asunto es que, siendo la Abadía un tocho de programa, hicieran la carga más lenta, debieron de llamarla anti-turbo.

Hace muchísimo que no miro el código del emulador para ESP32 y aún cuando lo hice no me quise implicar mucho porque ya sé donde acabaría.. y no quiero, ya tengo bastante con los dos que llevo a las espaldas, a cual de los dos con peor suerte, no vaya a gafar un tercero.

Pero se me ocurre que esos fallos aparentemente aleatorios puedan tener motivo en otra cosa. Un cuadro de Spectrum dura 70908 t-states en el 128k, pero son en tiempo de pantalla, que siempre es exactamente igual. Pero eso no se corresponde con el tiempo de CPU. Habitualmente las emulaciones por software se hacen a nivel de instrucción y no al ciclo y eso significa que cuando al emulador le dices que ejecute 70000 t-states, éste puede ejecutar hasta 70029 ciclos (sin contar contención de memoria que, me parece recordar, que este emulador no tiene). Esos 29 ciclos salen de empezar a ejecutar la instrucción más larga (en tiempo) del Z80 justo en el t-state 69999. Exactamente por este motivo, la señal /INT se mantiene activa durante 32 o 36 t-states, porque la /INT no se comprueba hasta el final de la instrucción.

Empezar el cuadro desde cero descarta muchos "finales de cuadro" que, además, fueron mi pesadilla para la emulación del beeper. Lo ideal es tener una variable contador de t-states y hacer algo como:

do {
...
} while (tstates < 70000);

tstates -= 70000;

y así el siguiente cuadro comienza donde lo dejó el anterior, no desde cero, cosa que no ocurre casi nunca.

Normalmente, las rutinas de carga se autoajustan para cada byte, en realidad para cada bit, pero si muchos errores se acumulan o si se concentran en unos lugares concretos, aumentan las posibilidades de error. Tened en cuenta que la rutina de carga de la ROM es exactamente la misma para el 48k y para los 128k, a pesar de que los 128k van ligeramente más rápidos (3.5 Mhz vs 3.5469 Mhz), y aún así las cargas no se ven afectadas. La ROM del Spectrum es una obra de ingeniería, pero las rutinas de LOAD y SAVE se salen de la escala, IMHO.

En fins, perdonad por el ladrillo...

Saludos