ZX-ESPectrum-IDF v1.0 beta5.3

Avatar de Usuario
Eremus
Mensajes: 180
Registrado: 01 May 2022 18:10
Agradecido : 275 veces
Agradecimiento recibido: 431 veces

Re: ZX-ESPectrum-IDF v1.0 beta3

Mensajepor Eremus » 23 Feb 2023 14:21

Último mensaje de la página anterior:

Kyp escribió:Por cierto... sobre ese test de 128... Hace tiempo lo ejecuté en un equipo real y me salía así:
ula128.jpg

No recuerdo ahora que modelo de Spectrum era, probablemente un 128K toastrack español o un +2 gris. Me llamó bastante la atención porque en emuladores y FPGAs el test suele verse 'bien' pero en el equipo real salía mal.


Que curioso!

No sabría que decirte porque, aunque tengo un 128 por aquí en su cajita, hace tiempo que no lo enchufo. Quizá pueda tener que ver con lo mismo que produce el "late timing": ULA sobrecalentada que altera el timing de algún modo.

Sea como sea, seguro que hay alguien que sepa mas que yo que nos puede arrojar algo de luz sobre esto.

Saludos ;)

Avatar de Usuario
Eremus
Mensajes: 180
Registrado: 01 May 2022 18:10
Agradecido : 275 veces
Agradecimiento recibido: 431 veces

Re: ZX-ESPectrum-IDF v1.0 beta3

Mensajepor Eremus » 23 Feb 2023 15:21

Hola!

Otra novedad para la próxima beta 4 (solo diré una cosa si no vais a ver el video: Sidewize -thumbup )

https://youtu.be/_qyYy5E9n88

Saludos!

azesmbog
Mensajes: 58
Registrado: 03 Feb 2023 10:31
Agradecido : 32 veces
Agradecimiento recibido: 79 veces

Re: ZX-ESPectrum-IDF v1.0 beta3

Mensajepor azesmbog » 23 Feb 2023 17:49

Kyp escribió:Por cierto... sobre ese test de 128... Hace tiempo lo ejecuté en un equipo real y me salía así:

Este es el efecto de la nieve.
sin embargo, también está en los modelos zx128.
Probado en modelos reales.

azesmbog
Mensajes: 58
Registrado: 03 Feb 2023 10:31
Agradecido : 32 veces
Agradecimiento recibido: 79 veces

Re: ZX-ESPectrum-IDF v1.0 beta3

Mensajepor azesmbog » 23 Feb 2023 18:34

Eremus escribió:Ya tenemos timings aparentemente correctos para el modo 128K (y +2).

Ahora los tiempos son bastante correctos. Pero no todos :)
siguientes dos pruebas.
scroll17: aquí creo que es necesario arreglar la decodificación del puerto #FE, hacer solo un bit a la vez.
#FE/254 xxxxxxxxxxxxxxx0
FPGA_ula128: aquí es necesario corregir los tiempos de los operandos en el propio procesador, algunos no coinciden.
Adjuntos
test128.zip
(1.91 KiB) Descargado 95 veces

Avatar de Usuario
Eremus
Mensajes: 180
Registrado: 01 May 2022 18:10
Agradecido : 275 veces
Agradecimiento recibido: 431 veces

Re: ZX-ESPectrum-IDF v1.0 beta3

Mensajepor Eremus » 26 Feb 2023 16:33

Hola!

Hay novedades muy interesantes que ya están colgadas en el repo:

- Lo más importante es que el modo 128k ya esta al nivel del modo 48k: timings y memory e i/o contention correctos y floating bus emulation funcionando.
- Con ayuda de David Crespo, se ha podido solucionar un bug con el beeper audio en modo 128k.
- Relacionado con esto, se ha movido parte del procesado de audio al segundo core de la CPU, liberando algo de recursos para la emulación.
- He reescrito el código del objeto Z80ops para hacerlo compatible con ambas arquitecturas, optimizandolo y recuperando así el tremendo boost que habia conseguido con la reescritura de las funciones de dibujo. El emu es más rápido que nunca -thumbup
- He corregido bugs en la carga de ficheros relacionados con el cambio de arquitectura.
- Ahora se muestra, en el menú principal, la arquitectura activa.

Si queréis probar todo esto tendréis que usar el compilador. En el repo está el código al día.

Durante esta semana repasaré y probare bien todo y para el próximo fin de semana lanzaré los binarios de la beta 4.

Ahora, por fin, toca finalizar la emulacion AY. Seguiremos informando -grin

Saludos!

azesmbog
Mensajes: 58
Registrado: 03 Feb 2023 10:31
Agradecido : 32 veces
Agradecimiento recibido: 79 veces

Re: ZX-ESPectrum-IDF v1.0 beta4

Mensajepor azesmbog » 02 Mar 2023 08:35

sí, las pruebas scroll17 y fpga_ula128 funcionan bien ahora.
Habría que corregir el registro R
https://k1.spdns.de/Develop/Projects/zx ... -01-16.tap
bueno, estamos esperando la corrección de sonido en AY - es horrible :)

update:
¡¡¡¡Trabajo fantástico!!!!
Ahora el suegro CASI funciona bien!!
Lo ejecuté en modo zx128; al final, la prueba colgó con hermosos cuadrados, que no deberían ser.
Lanzado en modo zx48: todo está bien. Fue hasta el final y emitió un registro. Pero hay que comprobarlo con otros resultados, ordenadores reales y emuladores correctos.¡El resultado de las pruebas y la comparación es excelente! 100%
Queda por arreglar por qué el modo zx128 está atascado.

spectrum3
Mensajes: 47
Registrado: 12 Feb 2021 22:58
Agradecido : 71 veces
Agradecimiento recibido: 36 veces

Re: ZX-ESPectrum-IDF v1.0 beta3

Mensajepor spectrum3 » 02 Mar 2023 12:32

Yo sobre todo el sonido 128k y ya con eso supongo que el emulador practicamente perfecto.

azesmbog
Mensajes: 58
Registrado: 03 Feb 2023 10:31
Agradecido : 32 veces
Agradecimiento recibido: 79 veces

Re: ZX-ESPectrum-IDF v1.0 beta4

Mensajepor azesmbog » 02 Mar 2023 18:13

azesmbog escribió:Queda por arreglar por qué el modo zx128 está atascado.


Aquí pido disculpas, aquí también funciona correctamente. Olvidé que en el modo zx128 necesito seleccionar "Basic 48" y cargar desde el 48th BASIC, luego todo funciona correctamente.
halt2int también comprobado, funciona correctamente.
Super HALT Invaders Test - también funciona correctamente.
z80_block_flags_test - este no funciona como se esperaba :)
Pero esta prueba es para un aficionado, muchos emuladores ya han aprendido a pasarla, pero no todos.
En FPGA, definitivamente no funciona para nadie. Por lo tanto, si establece un objetivo, hacerlo mejor que en FPGA, entonces puede solucionarlo, de lo contrario, estos son indicadores no documentados y nadie los usa), pero de todos modos hay una prueba para ellos.
z80full - 4 errores, no muchos, pero algo descuidados, doctor (c).
Para la emulación de "nieve", no diré nada, solo unos pocos emuladores pueden emularlo correctamente. Implementado parcialmente en FPGA, en un 78% :))
Calificación general - ¡EXCELENTE!
Estamos esperando la emulación correcta AY

Avatar de Usuario
Eremus
Mensajes: 180
Registrado: 01 May 2022 18:10
Agradecido : 275 veces
Agradecimiento recibido: 431 veces

Re: ZX-ESPectrum-IDF v1.0 beta4

Mensajepor Eremus » 02 Mar 2023 18:38

Hola!

azesmbog escribió:¡¡¡¡Trabajo fantástico!!!!

Muchas gracias! Si la cosa está quedando tan bien es, en gran parte, gracias a los tests que me has ido proponiendo y revisando así que Kudos para ti también ;)

azesmbog escribió:Habría que corregir el registro R

48k.jpg
48k.jpg (29.92 KiB) Visto 1909 veces
128k.jpg
128k.jpg (24.56 KiB) Visto 1909 veces

Esto me ha costado bastante afinarlo asi que me invito a una cerveza para celebrarlo! -drinks

La verdad es que estoy muy satisfecho. Esta semana he conseguido que en todos los test que he probado, en modo 48k y 128k, el emu se comporte prácticamente igual que Fuse, casi igual que Retro Virtual Machine e incluso mejor que SpecEmu en algunos tests.

Además, he conseguido que todo esto no afecte a la velocidad y, tal y como comentaba anteriormente, la beta 4 va a ser la versión mas rápida del ZX-ESPectrum-IDF hasta la fecha. -thumbup

azesmbog escribió:Ahora el suegro CASI funciona bien!!

I'm starting to think we should communicate in English. You've just said: "now the father-in-law WORKS almost fine!!"
(just joking: apart from these funny mistakes your spanish is quite good, probably much better than my english -grin )

azesmbog escribió:bueno, estamos esperando la corrección de sonido en AY - es horrible :)

spectrum3 escribió:Yo sobre todo el sonido 128k y ya con eso supongo que el emulador practicamente perfecto.

Después de la beta 4 voy a por el sonido AY. Ya no hay excusa alguna para posponerlo.

Eso si: mis conocimientos sobre el chip AY son, en este momento, similares a los del Spectrum cuando empece hace unos meses con toda está fiesta así que toda ayuda en forma de información, código o mensajes de animo recordándome lo guapo que soy y el tipo que tengo serán bien recibidos. -grin

Muy pronto la beta 4.

Saludos!

azesmbog
Mensajes: 58
Registrado: 03 Feb 2023 10:31
Agradecido : 32 veces
Agradecimiento recibido: 79 veces

Re: ZX-ESPectrum-IDF v1.0 beta4

Mensajepor azesmbog » 02 Mar 2023 20:28

Eremus escribió: e incluso mejor que SpecEmu en algunos tests.


SpecEmu es ideal entre los emuladores, todos los demás están cerca o atrasados ​​en precisión. Por lo tanto, es casi imposible ser más preciso que el de Woody :) Esto es así, por cierto.
http://www.ym2149.com/ym2149.pdf
Esperamos que esta sea una guía bastante completa sobre el chip de sonido. Sí, es ligeramente diferente de AY, pero para mejor.
La mejor prueba de sonido es AYtest_v0.2
Aunque está diseñado para probar TurboSound, prueba bastante bien un solo chip. Si lo ejecuta, entonces la ausencia de un canal de ruido y envolventes NO es muy audible)
Aquí es donde tienes que empezar.
PD Sé inglés incluso peor que español. El traductor de Google ayuda aquí.
Hay muchos fans de ZX Spectrum en Rusia :)
upd:
https://cpctech.cpc-live.com/docs/ay38912/psgspec.htm
https://github.com/samstyle/Xpeccy/tree ... eccy/sound
tal vez encuentre algo interesante en los códigos fuente en C)
Por cierto, hay otro chip de sonido SAA1099 en el código fuente. En el Spectrum original había y hay una placa de expansión para el conector de borde con este chip.
Varios emuladores lo admiten, y varios emuladores de hierro, hay música y demostraciones para Spectrum, hay alrededor de melodías 600. De repente, hay espacio y tiempo libres, y te interesará))

Avatar de Usuario
ackerman
Mensajes: 482
Registrado: 05 Feb 2019 21:32
Ubicación: Asturias
Agradecido : 224 veces
Agradecimiento recibido: 569 veces
Contactar:

Re: ZX-ESPectrum-IDF v1.0 beta3

Mensajepor ackerman » 05 Mar 2023 15:47

Eremus escribió:- He reescrito el código del objeto Z80ops para hacerlo compatible con ambas arquitecturas, optimizandolo y recuperando así el tremendo boost que habia conseguido con la reescritura de las funciones de dibujo. El emu es más rápido que nunca -thumbup

Enhorabuena por el currele -drinks .
Hay mucho donde se puede rascar, si se aprieta, va saliendo. Pero eso no quiere decir, que sea fácil.

Te paso más trucos:
Hace mucho tiempo, @zx81 (José Luis Sánchez) ya había comentado en los cambios que hice con punteros al readbyte y writebyte de LIN KE FONG, que para lo que me quedaba, que podía meterle un array de 16 KB extra para el primer bloque, sólo para escritura. Esto es lo mismo para el peek8 y poke8 del core de José Luis.

Esto que voy a comentar, te va a ser muy útil, y mejor que una explicación, nada mejor que el propio código.
Aunque me sobra SRAM (framework de Arduino) y puedo hacerlo sin problema, he dejado también la opción sin falta de ello, pero vamos que lo puedes adaptar sin problema como más te convenga a tu caso particular. De hecho, mejor revísalo, no vaya a ser que la haya pringado en algo.
Si miras todo el pragma use_optimice_writebyte y use_optimice_writebyte_min_sram lo puedes ver fácilmente, pero básicamente es tener punteros de lectura y punteros de escritura, de manera que no hay que detectar si es el primer bloque de 16 KB. Esto me permite un pequeño empujón de mínimo 20 fps, que en tu caso debería ser aproximado, dado que toda la parte extra del switch se puede también ir puliendo.
El poke16 suele andar en 800 llamadas, es decir, 1600 llamadas a poke8 en 20 milis. Así mismo un ciclo de 20 ms suelen ser entre 2000 y 3000 llamadas a poke8, dependiendo del juego o aplicación. Para el caso del peek16 suele ser 1800 llamadas, es decir, 3600 llamadas a peek8, mientras que suelen ocurrir 13000 llamadas a peek8 en 20 ms, es decir, que lo ideal es la optimización en lectura frente a escritura. Así mismo si se mejora mucho el peek8, el peek16 en muchos casos no se necesita ni tocar.
De esta forma, puede quedar todo tan simple como:
inline uint8_t peek8(uint16_t address)
{
tstates += 3;
return (gb_real_read_ptr_ram[(address>>14)][(address & 0x3fff)]);
}

inline void poke8(uint16_t address, uint8_t value)
{
tstates += 3;
gb_real_write_ptr_ram[(address>>14)][(address & 0x3fff)] = value;
}

Esto sería el caso más excepcional sin tener el delayContention, que si es inline por debajo quedaría hasta como una función macro define, ahorrándonos incluso el apilamiento. Se consigue una mejora respecto al tradicional.
Para el caso del uso del delayContention sigue consiguiéndose una mejora de rendimiento, de hecho las mediciones siempre las hago con delayContention.

Avatar de Usuario
Eremus
Mensajes: 180
Registrado: 01 May 2022 18:10
Agradecido : 275 veces
Agradecimiento recibido: 431 veces

Re: ZX-ESPectrum-IDF v1.0 beta3

Mensajepor Eremus » 06 Mar 2023 14:18

Hola!

ackerman escribió:Esto que voy a comentar, te va a ser muy útil, ...

Sobre esto ya me hablaste hace un tiempo y como estaba concentrado en mejorar la emulación de video y no me había puesto aun a estudiar la parte de accesos a memoria y demás, me deje nota mental de revisarlo algún día.

El caso es que me lo has venido a recordar en el momento perfecto: justo cuando he optimizado todas esas funciones y tengo ya el tema estudiado. Así que lo que antes me sonaba interesante pero no terminaba de entender ahora lo he visto claro y cristalino.

Me he puesto manos a la obra y, utilizando tus sugerencias, peek8 ha pasado de esto:

Código: Seleccionar todo

uint8_t IRAM_ATTR Z80Ops::peek8(uint16_t address) {
   uint8_t page = address >> 14;
    switch (page) {
    case 0:
        VIDEO::Draw(3);
        return MemESP::rom[MemESP::romInUse][address & 0x3fff];
    case 1:
        VIDEO::Draw(Z80Ops::delayContention(CPU::tstates) + 3);
        return MemESP::ram5[address & 0x3fff];
    case 2:
        VIDEO::Draw(3);
        return MemESP::ram2[address & 0x3fff];
    case 3:
        if (is48)
            VIDEO::Draw(3);
        else
            if (MemESP::bankLatch & 0x01 == 1)
                VIDEO::Draw(Z80Ops::delayContention(CPU::tstates) + 3);
            else
                VIDEO::Draw(3);
        return MemESP::ram[MemESP::bankLatch][address & 0x3fff];
    }
}

a esto:

Código: Seleccionar todo

uint8_t IRAM_ATTR Z80Ops::peek8(uint16_t address) {
    uint8_t page = address >> 14;
    if (MemESP::ramContended[page])
        VIDEO::Draw(Z80Ops::delayContention() + 3);
    else
        VIDEO::Draw(3);
    return MemESP::ramCurrent[page][address & 0x3fff];       
}

De manera análoga, he modificado fetchOpcode, peek16, poke8 y poke16.

También veras que he modificado la detección de si la pagina es "contended" o no mediante un pequeño array que se actualiza solamente cuando se cambian arquitecturas y/o paginas (Creo que lo vi en el código de JSPeccy). Mucho mas eficiente también :)

Hice también una prueba de hacer la función "inline" pero el rendimiento se hundía. Parece que es mucho mejor que no sea inline pero esté en IRAM.

Para poner en perspectiva el resultado, este soy yo mismo en junio de 2022 -grin
Eremus escribió:Los tiempos ahora mismo son bastante buenos. He conseguido que no afecte demasiado a los mejores tiempos que obtuve sin dibujar borde ni selección de aspect ratio:

CPU + VIDEO (360x200 16:9) 19126
CPU + VIDEO (320x240 4:3) 19169

Considerando que esto es en la pantalla inicial de DreamWalker, que debido al motor Nirvana actualiza bastante la pantalla, no esta mal del todo.

Resultados ahora (modo 4:3) -thumbup
Dreamwalker (beta 4).jpg
Dreamwalker (beta 4).jpg (10.25 KiB) Visto 1738 veces

El incremento real respecto a mi ultima versión ha sido de algo mas de un 10% ya que ya había conseguido unos 92 fps. En todo caso, otro 10% es un boost importantísimo :)

Finalmente, solo me queda una dudilla. En las funciones de escritura he tenido que añadir una linea para no escribir en la pagina 0 para que funcionara todo bien:

Código: Seleccionar todo

void IRAM_ATTR Z80Ops::poke8(uint16_t address, uint8_t value) {

    uint8_t page = address >> 14;
    if (page == 0) { VIDEO::Draw(3); return; }   
    if (MemESP::ramContended[page])
        VIDEO::Draw(Z80Ops::delayContention() + 3);
    else
        VIDEO::Draw(3);
    MemESP::ramCurrent[page][address & 0x3fff] = value;
    return;

}

Inicialmente pensé que, con que MemESP::ramCurrent[0] apuntara a un "const uint8_t*" no haría falta chequear nada pero parece que no es tan sencillo.

Entiendo que el truco relativo a esto del que hablas es añadir una pagina de 16k y copiar alli la rom para que poke8 pueda usarla sin alterar la rom real. A expensas, eso si, de usar 16k de ram ¿Lo he entendido bien?

Un saludo y muchas gracias como siempre por tus consejos!

Avatar de Usuario
Eremus
Mensajes: 180
Registrado: 01 May 2022 18:10
Agradecido : 275 veces
Agradecimiento recibido: 431 veces

Re: ZX-ESPectrum-IDF v1.0 beta4

Mensajepor Eremus » 06 Mar 2023 14:24

Hola!

azesmbog escribió:SpecEmu es ideal entre los emuladores, todos los demás están cerca o atrasados ​​en precisión. Por lo tanto, es casi imposible ser más preciso que el de Woody :) Esto es así, por cierto.

Pues tienes toda la razón. Fallo mío -banghead
Estaba usando una versión muy antigua de SpecEmu. En la versión actual, SpecEmu se comporta perfectamente.

Muchas gracias por toda la info sobre el AY, ya estoy estudiándola y preparando la beta 5 :)

Saludos!

Avatar de Usuario
Eremus
Mensajes: 180
Registrado: 01 May 2022 18:10
Agradecido : 275 veces
Agradecimiento recibido: 431 veces

Re: ZX-ESPectrum-IDF v1.0 beta4

Mensajepor Eremus » 06 Mar 2023 15:06

Hola!

Beta 4 publicada. Tenéis los detalles en el primer post del hilo.

A disfrutarla!

Saludos!

Avatar de Usuario
IgnacioMonge
Mensajes: 205
Registrado: 15 Dic 2022 17:54
Ubicación: Jerez de la Frontera, España
Agradecido : 136 veces
Agradecimiento recibido: 129 veces

Re: ZX-ESPectrum-IDF v1.0 beta4

Mensajepor IgnacioMonge » 06 Mar 2023 17:17

Eremus escribió:Hola!

Beta 4 publicada. Tenéis los detalles en el primer post del hilo.

A disfrutarla!

Saludos!


¡Yo ya lo estoy haciendo!
Imagen de WhatsApp 2023-03-06 a las 17.14.39.jpg
Imagen de WhatsApp 2023-03-06 a las 17.14.39.jpg (40.15 KiB) Visto 1687 veces

Imagen de WhatsApp 2023-03-06 a las 17.13.40.jpg
Imagen de WhatsApp 2023-03-06 a las 17.13.40.jpg (36.25 KiB) Visto 1687 veces

Imagen de WhatsApp 2023-03-06 a las 17.13.39.jpg
Imagen de WhatsApp 2023-03-06 a las 17.13.39.jpg (44.03 KiB) Visto 1687 veces




¡Enhorabuena, se ve y funciona genial!
-sp3zy -0r1c -cocbm1 -4mstr4d -m3s3x -j4tar1 -codrg1 -coam1

azesmbog
Mensajes: 58
Registrado: 03 Feb 2023 10:31
Agradecido : 32 veces
Agradecimiento recibido: 79 veces

Re: ZX-ESPectrum-IDF v1.0 beta4

Mensajepor azesmbog » 06 Mar 2023 18:19

Imagen
¿Cómo interpretar correctamente estos números en la parte inferior de la pantalla? ¿Qué artículos deberían ser más grandes y cuáles deberían ser más pequeños? Bueno, a excepción de FPS, esto es más o menos claro)

Avatar de Usuario
ackerman
Mensajes: 482
Registrado: 05 Feb 2019 21:32
Ubicación: Asturias
Agradecido : 224 veces
Agradecimiento recibido: 569 veces
Contactar:

Re: ZX-ESPectrum-IDF v1.0 beta3

Mensajepor ackerman » 06 Mar 2023 18:59

Eremus escribió:Entiendo que el truco relativo a esto del que hablas es añadir una pagina de 16k y copiar alli la rom para que poke8 pueda usarla sin alterar la rom real. A expensas, eso si, de usar 16k de ram ¿Lo he entendido bien?

Tu tranqui, es tu pequeñin, tu adáptalo como mejor te venga.

Lo del array del contended, muy buena idea. -thanks

Exacto, para eso está el array de 4 punteros de lectura (gb_real_read_ptr_ram) y el array de 4 punteros de escritura (gb_real_write_ptr_ram), no hace falta, copiar ROMS ni nada. El de lectura, jamás va a ver el puntero de la ramFast, sólo el puntero de la rom que apunta rom en uso con su banco de rom. Y el de escritura sólo va a ver el puntero que apunta a ramFast (cuando sea 0), pero le da igual, porque nadie la puede leer. El resto de 8 bancos de ram (ram0... ram7) sólo se acceden por cambio de banco. De está forma, la lectura sólo puede leer, en concreto sólo ROM cuando sea la página 0, mientras que la escritura sólo puede escribir, y jamás podrá hacerlo en ROM.

Siguiendo el pragma use_optimice_writebyte se ve los puntos de anclaje de las actualizaciones de gb_real_read_ptr_ram y gb_real_write_ptr_ram. Lo de perder o no 16 KB (0x4000) de RAM para ramFast, se puede arreglar con el truco use_optimice_writebyte_min_sram de declarar ramFast de 1 o 2 bytes y aplicar:

Código: Seleccionar todo

   #ifdef use_optimice_writebyte_min_sram
    gb_real_write_ptr_ram[idRomRam][(idRomRam==0) ? 0 : (address & 0x3fff)] = value;
   #else
    gb_real_write_ptr_ram[idRomRam][(address & 0x3fff)] = value;
   #endif

También se puede declarar un ramFast de 256 bytes y obligar a usar un indireccionamiento de 8 bits (256 posiciones), de forma que por over, al escribir en banco 0, ya nos ahorramos también los 16 KB. La forma inmediata es perder 16 KB, ya que no tiene que chequear nada. Ese bloque de 16 KB no interesa para nada, porque jamás se va a leer de él, es sólo para optimizar la forma de acceso por indireccionamiento, sin falta de chequear si es página 0 ni nada a la hora de escribir.

Las optimizaciones con inline tienen el mayor éxito cuando son fácilmente reemplazables por una macro. Si el código a sustituir puede reutilizar los registros y la caché de la CPU, conseguimos premio, dado que nos ahorramos el apilar los registros al llamar a la rutina. Si la rutina es compleja, y usa muchos registros de CPU, aunque dentro hagamos gotos a otras rutinas, no se consigue premio. De ahí que cuanto más simple y menos lógica tenga la rutina, es decir, se le de todo más masticado, más posibilidades de éxito.

Felicitaciones por la Beta4. A celebrarlo. -drinks -drinks


Volver a “Desarrollo emuladores ESP32”

¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 1 invitado