Imagen

Tiny ESP32 CPC (Origen FAQ)

Responder
Avatar de Usuario
ackerman
Mensajes: 499
Registrado: 05 Feb 2019 21:32
Ubicación: Asturias
Contactar:

Tiny ESP32 CPC (Origen FAQ)

Mensaje por ackerman »

Origen
Para no estar explicando una y otra vez lo mismo de manera privada, en donde se pierde información, que mejor que dejar una especie de FAQ, bitácora, etc., pública del proyecto, y así acabar con preguntas tan simples y recurrentes, como pueden ser que tal o cual juego del CPC 6128 no van en el emulador. También se despejan dudas de cara al desarrollo si se quiere aprovechar algo.

https://github.com/rpsubc8/ESP32TinyCPC

El proyecto aunque se hace público en github en 2020/12/02 (4 años), se comenzó en Noviembre del 2020, y se comentó en el foro (2020/11/15) donde nació todo, de retrowiki, gracias a la idea de @ron (está en todos los fregaos) de crear hilo en el foro:

https://retrowiki.es/viewtopic.php?t=200036016&start=64

En el proyecto siempre se quiso lograr un custom emulador del CPC 464, pero a nivel de desarrollador, dado que la parte de lusers (usuarios) siento decirlo, no me interesa mucho. Años atrás, sobre el 2017, en varios foros internacionales, estaban debatiendo teóricamente si sería posible un emulador de CPC con ESP32, y no llegaban a nada claro, de hecho se comentaba, que era imposible, que si se lograba, el rendimiento sería penoso. A la par que el comienzo de este proyecto, estaban con el Odroid-GO ESP32, algo comercial,que consistía en una especie de consola portátil basada en ESP32 con 8 MB de PSRAM y pantalla LCD, bastante cara, que no me atraía para nada.

De manera que lo más práctico fue buscar el candidato ideal, y que mejor que el CPCem de Tom Walker de PC x86, con una antigüedad de 20 años. No me interesaba ni el 6128, ni CPC+, ni GFX4000, etc., sólo quería el CPC 464, porque nunca he sentido vergüenza por el CPC tal y como vino al mundo.
Así que convertí de ALLEGRO a SDL1, quité broza, corregí errores y adapté a lo que necesitaba para el ESP32.



Problemas
A lo largo del código original del x86 se puede ver como el autor (Tom Walker) tenía algunos problemas con la gestión de memoria, es decir, que se sale fuera del rango de la memoria creada, tanto para el video como para la RAM, pero que en x86 no se nota, porque en plataformas PC’s nunca se pide la memoria exacta, sino que se reservan bloques mayores. A la hora de portarlo al ESP32, revienta por todos lados, por lo que se tubo que blindar. Existe también solapes, y más temas más complejos a tratar aquí, de manera que realmente, se requiere pedir 1 MB de RAM para poder evitar fallos en modo 6128 y aún así no estaría el problema solucionado al 100%. Por tanto, llegado a este punto, se opta por soluciones prácticas, dado que el ESP32 en modo framework ARDUINO, no permite bloques de más 114 KB en SRAM, si por encaje tenemos SRAM libre. Con IDF, se permite de hasta 170 KB, pero al ser la SRAM limitada, no nos sirve de mucho. Si se elige la opción de PSRAM, está todo solucionado, pero una vez más, llegamos al punto inicial, yo quería que funcionase en ESP32 pelado, TTGO VGA32 v1.2, que carece de PSRAM.
El truco que se ha usado en el modo 6128, es pasar del último bloque de 16 KB en SRAM, de manera que mientras que no se acceda a él, funcionará más o menos bien.

Las modificaciones que aún no he publicado, permiten usar bloques de memoria de 16 KB, de manera que el 464 queda con 4 bloques de 16 KB, y el 6128 con 8 de 16 KB. De esta forma se soluciona el problema de memoria en SRAM, pero se añade un poco de sobrecarga, al no acceder directamente a toda la RAM de manera lineal.

También quería que funcionará con un sólo core, porque era el modo que más probabilidades tenía de que pudiera funcionar un hipotético modo Brametal, que nunca ha llegado y dudo que llegue, al menos a la familia ESP32 S2 y S3.
Todos estos problemas de RAM, sólo afectan al modo 6128, en 464 de 64 KB, nos da igual. Una vez más, problemas del 6128 que originalmente en x86 estaba en construcción.

Hay mas de 2000 juegos de CPC, de los cuales, no todos son de alta calidad, y lo más importante, no voy a probar todos. Pero un número muy alto funcionan de manera normal, y con pequeños trucos, el resto.
Existen varios hilos para ver los que funcionan, pero el más cómodo:

https://retrowiki.es/viewtopic.php?t=200038387

¿Cual es el principal problema del proyecto al hacerlo público? Pues haber dejado soporte del modo 6128, que a pesar de decir muchas veces que estaba en modo test, parece que se consiguió justo lo contrario, es decir, que todo el mundo fuera directo al 6128, en lugar del 464 o 664.

Por mensajes privados en diferentes medios de comunicación, no siempre, pero la mayoría de las veces, es recurrente, y no tiene que ver con el CPC o emuladores, sino con el desconocimiento del ESP32 o de programación, de manera, que muchas veces terminan pidiendo casi un curso gratuito, que de entrada no debería ser lo correcto, y de salida, debería estar recogido en algún sitio público, como foros para que no fuera siempre el día de la marmota, y así más gente con mismo problema, lo resuelva al mismo tiempo, sin molestar.

Cierto es, que dado que el emulador original x86 ya partía del modo 664 con soporte de disquetera, y nunca ha incorporado el modo cinta, se podía hacer extraño tener un 464 con disquetera, y daba la sensación de ir directo al modo 6128, pero la forma como se resolvía la conmutación de bancos de hace 20 años y la actual no es la misma, de manera que una gran cantidad de juegos del 6128 de la época si funcionan, pero los de homebrew de lo que llamaríamos new oldskool, no van. Y una vez más, esto me da igual, porque el proyecto buscaba la solución a lo clásico de la época.
El core del Z80, le faltan instrucciones y más cosas, que una vez más, para ejecutar juegos de la época clásica le da igual, pero para la new oldskool, falla. El tema de la controladora de discos y dsk’s, lo mismo, el emulador original soportaba el modo básico, que es más que suficiente para mogollón de juegos.
¿Como de bueno es el core?, pues es muy rápido, y se puede hacer aún más rápido, e incluso lo han usado posteriormente para el emulador PALE en ESP32. Pero somos libres de usar el core que más nos guste, esa es la esencia del proyecto, barra libre a todo lo que queramos, sin restricciones de licencia, ni que nos digan lo que podemos o no hacer por exclusividad.



Teclado
Existen muchas formas de leer teclados PS/2, pero en este caso me he quedado con la básica del PS2Kbd sin mapas, como hice con el Tiny ZX Spectrum. Dejé el añadido para teclados Perixx que había realizado David, porque en los inicios, pensé que podía ser útil (igual afectaba a más teclados), pero a la larga va a desaparecer, ya que a estas alturas ya se sabe que teclados funcionan sin problemas, reduciendo recursos, y sobre todo, porque este tipo de teclados con teclas tan planas (estilo portátiles), no me atraen en absoluto. El PS2Kbd quedará reducido, como le sucede al Tiny Galakasija.
La rutina de teclado se gestiona en SDL_keys_poll del CPCem.ino.
No todas las teclas están actualmente mapeadas, sólo las que he necesitado, que son el teclado numérico (0..9), letras (A..Z), shift derecho, borrar, barra espaciadora, enter, comillas, punto, coma, capslock, cursores (arriba, abajo, izquierda, derecha), punto y coma, control.
Para sacar el pipe | se debe usar la tecla F10. No estan mapeadas el resto de F2..F9, así que cualquier tecla que se quiera de más, se debe añadir a esta rutina.
Puede que algún teclado no se inicialice a la primera, nada más conectar la alimentación por usb, debido a que tenga una demora. La solución más sencilla, reiniciar el ESP32 para que lo pille a la segunda o ponerle una espera en el Setup.
Siempre tenía en mente que el teclado desapareciera, para usar un joystick DB9 en un ESP32 pelado o bien un mando de NES directo a los GPIO's del conector de PS/2 en la TTGO VGA32, de ahí que no fuera un tema que me preocupara mucho, pero mientras tanto.



Soporte almacenamiento
A lo largo de todo este tiempo, me he encontrado gente probando discos protegidos que al no estar soportado no van, y en vez de buscar versiones ya desprotegidas, se empeñan en querer que funcione. Este tema, a mi me da igual, dado que opino que lo importante es tener una solución para soporte de almacenamiento, con que tire una, es más que suficiente.
El emulador está preparado para leer dsk's de 42 tracks y 11 sectores. Si se necesita más formatos, es tan fácil, como ponerse a añadir lo que se necesita. Una vez más, yo no necesito más.

El soporte de tarjetas SD, pues dado que la placa TTGO VGA32 v1.2 no tiene conector SD, y la forma de añadirlo es muy molesto, y sobre todo, que el soporte SD, a mi no me convence para nada, pues, al menos para emulación de microordenadores dudo que le añada soporte, y si se lo añado no será con librerías convencionales de ESP32 SD, eso está claro. Tirando por lo bajo, si un emulador ocupa 1 MB de flash, que ni de lejos, siempre ocupará muchísimo menos, nos quedan 3 MB de Flash, que si usamos SNA de 64 KB, nos deja 48 juegos, más que suficiente. Siempre pensé que a estas alturas, el ESP32 ya estaría en 128 MB de flash, pero todos sabemos lo que sucedió a nivel mundial, en 2020. No obstante, 16 MB de flash no suele ser problema de encontrar, al menos en rp2040, y sino, siempre podemos meter una SPI flash externa, que es el camino correcto. También se puede optar por el camino de WIFI, como hice con el Tiny ZX Spectrum, que si en vez de usar https, se usa http (consume menos SRAM) o bien un gateway espnow, se podría incluso usarlo para el modo 6128, pero vamos, que con el 464, se podría de sobra.

El emulador original x86, los DSK’s estaban en memoria, cosa que en un ESP32 pelado, no se puede. La solución más cómoda, tenerlo en Flash, pero para no tener que calcular sectores, pistas y demás y conseguir la máxima velocidad, dejé las imágenes ya desempaquetadas y con los cálculos, de manera que se tiene que usar una tool previa. Esto es algo, que más adelante desaparecerá, dado que tengo CPU libre, pero en los diseños iniciales, se carecía de potencia.
El emulador original, carecía de SNA, dado que en esa época no se había creado ni el formato, y lo dejé sin ello, que permitiría cargar juegos problemáticos con el soporte de disco. Actualmente tengo soporte de SNA, pero quería incluir este cambio junto con las mejoras del bankswitch, el crtc, sonido, etc.



CRTC
Sólo se soporta el CRTC0, que para CPC 464 era de sobra.
Entre las mejoras del crtc, que aún o he añadido, tengo la opción del modo de 32 KB, de utilizar el modo de 2 buffers de 16 KB, que permite que juegos como el Pinball Dreams y el Adios a la Casta se vean bien, pero una vez más, si nos damos cuenta, son juegos para el 6128, así que dicha solución muy fácil en el modo 464 clásico, nos da igual. No estoy seguro, pero juegos o demos que aprovechen los 2 buffers de 16 KB de video en 464, no deben existir.

La imitación del color verde GT65, es muy fácil de realizar, pero existe el problema, que al tener un DAC R2G2B2, de 64 colores fijos, sólo tenemos 11 niveles de verde, con la posibilidad de añadir el negro y el blanco, que nos dejaría 13 valores muy forzados, y aún así no llegamos a los 16 valores. Por eso añadí, la posibilidad de 3 paletas, pero vamos, que no esperéis recrear el GT65 al 100%.



ROMS
Añadí el soporte de cargar juegos de disco preparados para cargar ROMS, que es algo que lleva haciéndose desde hace años, que es empaquetar y comprimir dsk’s en una o varias ROM’s, y con una carga de comando RSX, cargar el juego. El problema del comando RSX, es que no se puede llegar a saber el nombre exacto en todo, por eso, probé varios juegos, saqué el nombre y los dejé en el repositorio. Cree un algoritmo muy simple, de manera que el propio comando de carga era el nombre de archivo ya preparado, de manera que si le damos a cargar en modo AUTO, ya nos tecleaba dicho RSX. Esta preparación, que es algo muy simple, requirió varios días, dado que hay que probarlo en varios emuladores, a ver si realmente funcionaba, y sobre todo unos cuantos juegos, dan mucha grima, y decidí hacer cribado. Si esto que es muy simple, lleva tanto tiempo, el resto de cosas, que son más complejas, ni os cuento.



Video
Para ahorrar SRAM, se utiliza un modo video fake, de manera, que se usa siempre 400x300. Cuando se activa el modo 2 (640x200), se dibuja la mitad de pixels horizontales, es decir, pasa a 320x200 dentro de 400x300. Es cierto, que 400x300 es demasiado, porque tenemos 80 pixels de borde, es decir, 40 para cada lado, así como 100 para vertical. Dejo la opción de quitar borde, es decir, usar 320x200, que para juegos, es pefecto. Más adelante, tenía en mente dejar de usar 400x300, que es demasiado, y dejar el modo real de 640x200, dado que aunque lo haga por interrupción del ESP32, este modo en CPC se uso muy poco y era lentísimo, es decir, es algo que a nivel de Z80 real es muy lento, pero a nivel de host es rápido.
400x300 consume 120000 bytes, mientras que quitando bordes en 320x200 son 64000 bytes. Cuantas más RAM se use, menos queda para el resto de recursos.



VGA
A fecha actual, ningún MCU ni SOC es capaz de generar los tiempos exactos de una señal de video, de ahí que no exista ni un sólo proyecto de radioaficionado que use un ESP32 para osciladores. Esta falta de exactitud, no impide que no puedan generarse tiempos más o menos aproximados, que harán que funcionen en unos determinados monitores.
Para conseguir los tiempos de precisión de VGA, se requiere respetar los tiempos de microsegundos, de manera que hay que hacer entrar al ESP32 en un modo específico, que aunque puede llegar hasta los nanosegundos, en el caso de bitluni o fabgl, no se ha realizado así. En concreto, para liberar consumo de CPU, se deja que los propios pixels marquen los tiempos, quedando el eslabón más débil en la propia frecuencia de trabajo. Es una manera ingeniosa y útil, pero no exacta.

Para ello, se puede probar con la utilidad ModelineStudio de fabgl, o bien con la testvga y ahí anotar todos los posibles resultados para quedarnos con nuestro custom modeline. Por supuesto, los modelines de fabgl han cambiado con el tiempo, y las permutaciones posibles entre ESP32's construidos, monitores, frameworks, etc... harán que uno pueda convertirse en el Dr Strange por un instante.
Los modelines para esta versión publicada son para 320x200 y 400x300 de bitluni. Si existen problemas con ESP32's que tienen bloqueo de PLL, siempre se puede introducir el código del emulador Tiny Galaksija, por ejemplo. Y si se quiere algún modo adicional, pues más de lo mismo.
¿Testear todos los monitores del mundo? No lo veo.

Ejemplos de modeline:

Código: Seleccionar todo

// --------------------------- hf  hs  hb  hpix  vf  vs  vb  vpix  vdiv pixclock  vp hp
const VgaMode vga_mode_320x240(8,  48, 24, 320,  11, 2,  31, 480,  2,   12587500, 1, 1);
Cada parámetro siempre se da en pixels, no en microsegundos, de ahí la desviación, es decir, la problemática que antes comenté.
Si quisieramos traspasar datos de modo de fabgl a nuestro sistema, es tan fácil, como modificar en la librería de fabgl, el swgenerator.cpp situado en devdrivers, añadiendo traza:

Código: Seleccionar todo

void GPIOStream::setupClock(int freq)
{
  APLLParams p = {0, 0, 0, 0};
  double error, out_freq;
  uint8_t a = 1, b = 0;
  APLLCalcParams(freq, &p, &a, &b, &out_freq, &error);

  I2S1.clkm_conf.val          = 0;
  I2S1.clkm_conf.clkm_div_b   = b;
  I2S1.clkm_conf.clkm_div_a   = a;
  I2S1.clkm_conf.clkm_div_num = 2;  // not less than 2
  
  I2S1.sample_rate_conf.tx_bck_div_num = 1; // this makes I2S1O_BCK = I2S1_CLK
  
  Serial.printf("Decimal sdm0:%lu sdm1:%lu sdm2:%lu o_div:%lu %08X %08X %08X %08X\r\n",p.sdm0, p.sdm1, p.sdm2, p.o_div, p.sdm0, p.sdm1, p.sdm2, p.o_div);
  Serial.printf("val:%d clkm_div_num:%d tx_bck_div_num:%d\r\n",I2S1.clkm_conf.val,I2S1.clkm_conf.clkm_div_num, I2S1.sample_rate_conf.tx_bck_div_num);
  Serial.printf("clkm_div_a:%d clkm_div_b:%d\r\n",a,b);
  Serial.printf("Decimal freq:%lu freqout:%f error:%f\r\n",freq,out_freq,error);
  
  rtc_clk_apll_enable(true, p.sdm0, p.sdm1, p.sdm2, p.o_div);
   

  I2S1.clkm_conf.clka_en = 1;
}
Y también en vgabasecontroller.cpp, situada en la carpeta dispdrivers:

Código: Seleccionar todo

bool VGABaseController::convertModelineToTimings(char const * modeline, VGATimings * timings)
{
  float freq;
  int hdisp, hsyncstart, hsyncend, htotal, vdisp, vsyncstart, vsyncend, vtotal;
  char HSyncPol = 0, VSyncPol = 0;
  int pos = 0;

  int count = sscanf(modeline, "\"%[^\"]\" %g %d %d %d %d %d %d %d %d %n", timings->label, &freq, &hdisp, &hsyncstart, &hsyncend, &htotal, &vdisp, &vsyncstart, &vsyncend, &vtotal, &pos);

  if (count == 10 && pos > 0) {

    timings->frequency      = freq * 1000000;
    timings->HVisibleArea   = hdisp;
    timings->HFrontPorch    = hsyncstart - hdisp;
    timings->HSyncPulse     = hsyncend - hsyncstart;
    timings->HBackPorch     = htotal - hsyncend;
    timings->VVisibleArea   = vdisp;
    timings->VFrontPorch    = vsyncstart - vdisp;
    timings->VSyncPulse     = vsyncend - vsyncstart;
    timings->VBackPorch     = vtotal - vsyncend;
    timings->HSyncLogic     = '-';
    timings->VSyncLogic     = '-';
    timings->scanCount      = 1;
    timings->multiScanBlack = 0;
    timings->HStartingBlock = VGAScanStart::VisibleArea;

    Serial.printf("convertModelineToTimings BEGIN\r\n");
    Serial.printf("frequency:%d\r\n",timings->frequency);
    Serial.printf("HVisibleArea:%d\r\n",timings->HVisibleArea);
    Serial.printf("HFrontPorch:%d\r\n",timings->HFrontPorch);
    Serial.printf("HSyncPulse:%d\r\n",timings->HSyncPulse);	
    Serial.printf("HBackPorch:%d\r\n",timings->HBackPorch);
    Serial.printf("VVisibleArea:%d\r\n",timings->VVisibleArea);
    Serial.printf("VFrontPorch:%d\r\n",timings->VFrontPorch);
    Serial.printf("VSyncPulse:%d\r\n",timings->VSyncPulse);
    Serial.printf("VBackPorch:%d\r\n",timings->VBackPorch);
    Serial.printf("HSyncLogic:%c\r\n",timings->HSyncLogic);
    Serial.printf("VSyncLogic:%c\r\n",timings->VSyncLogic);
    Serial.printf("scanCount:%d\r\n",timings->scanCount);
    Serial.printf("multiScanBlack:%d\r\n",timings->multiScanBlack);
    Serial.printf("HStartingBlock:%d\r\n",timings->HStartingBlock);	
	Serial.printf("convertModelineToTimings END\r\n");	

    // actually this checks just the first character
    auto pc  = modeline + pos;
    auto end = pc + strlen(modeline);
    while (*pc && pc < end) {
      switch (*pc) {
        // parse [(+HSync | -HSync) (+VSync | -VSync)]
        case '+':
        case '-':
          if (!HSyncPol)
            timings->HSyncLogic = HSyncPol = *pc;
          else if (!VSyncPol)
            timings->VSyncLogic = VSyncPol = *pc;
          pc += 6;
          break;
        // parse [DoubleScan | QuadScan]
        // DoubleScan
        case 'D':
        case 'd':
          timings->scanCount = 2;
          pc += 10;
          break;
        // QuadScan
        case 'Q':
        case 'q':
          timings->scanCount = 4;
          pc += 8;
          break;
        // parse [FrontPorchBegins | SyncBegins | BackPorchBegins | VisibleBegins] [MultiScanBlank]
        // FrontPorchBegins
        case 'F':
        case 'f':
          timings->HStartingBlock = VGAScanStart::FrontPorch;
          pc += 16;
          break;
        // SyncBegins
        case 'S':
        case 's':
          timings->HStartingBlock = VGAScanStart::Sync;
          pc += 10;
          break;
        // BackPorchBegins
        case 'B':
        case 'b':
          timings->HStartingBlock = VGAScanStart::BackPorch;
          pc += 15;
          break;
        // VisibleBegins
        case 'V':
        case 'v':
          timings->HStartingBlock = VGAScanStart::VisibleArea;
          pc += 13;
          break;
        // MultiScanBlank
        case 'M':
        case 'm':
          timings->multiScanBlack = 1;
          pc += 14;
          break;
        case ' ':
          ++pc;
          break;
        default:
          return false;
      }
    }

    return true;

  }
  return false;
}
Con estas trazas, ya tenemos los parámetros de cada modo de video. Como he comentado, fabgl ha cambiado a lo largo del tiempo, y modo con parámetros que en una versión tenían un valor, ahora tienen otro, así que el que os tire en vuestro monitor, os lo apuntáis.

Con un método como el vga_init del emulador de Tiny Galaksija se puede no sólo especificar un modo de video con los tiempos de pixels, sino que además deja forzar un PLL con los 4 parámetros (sdm0, sdm1, sdm2 y o_div), evitando que se calcule erroneamente. También deja otra opción para evitar el problema del PLL de Espressiff.




CVBS
Si en VGA tenemos permutaciones, si le añadimos un conversor de VGA a cvbs (video compuesto), nos aparecen más multiversos. Además del conversor, tenemos que añadir a la ecuación el TV o la capturadora, así que puede que nos explote la cabeza, al ver que un determinado modeline nos funciona, y a otro no. Afortunadamente, el CVBS tiene más compatibilidad que VGA o HDMI.
¿Testear todos los conversores VGA2CVBS, TV y capturadoras del mundo? No lo veo.



HDMI
Lo mismo que el CVBS, por un lado tenemos el conversor de VGA a HDMI, y por otro el monitor, TV o capturadora. Las combinaciones, son para crear hilos e hilos en un foro.
Así que si a alguien le funciona un modeline específico, enhorabuena, guardalo para ti y no hace falta que lo compartas, porque no vale para mucho.
¿Testear todos los conversores VGA2HDMI, monitores, TV y capturadoras del mundo? No lo veo.



Ratón
Tiene soporte para el ratón (AMX mouse), que en el fondo, no tiene importancia de cara a la época clásica, porque no he visto un ratón en CPC real en la vida, es algo friki que hice por hacer. Se tiene que activar el pragma use_lib_amx_mouse para que funcione.
En las primeras versiones se hizo uso de fabgl, pero posteriormente para reducir recursos se hizo por polling con PS2Mouse.



Sonido
El sonido, el principal problema siempre ha sido que no se ha activado el pragma (use_lib_sound_ay8912). Si no está activo, no va a emular el AY.
Lo que está publicado, es una emulación básica y reducida de 3 canales, sin tener en cuenta el canal de ruido, y sin controlar todos los registros del AY, era algo para tirar millas sin consumo de CPU.
Lo que tengo preparado, que aún no he publicado, tiene un control en el PSG.cpp para que en el caso de que psgmode sea 2, es decir, siempre que los registros de sonido sean de datos, se sincronice con los 79872 ciclos de 20 ms de frame, parando los ms necesarios o saltando, con la relación que existe entre esos ciclos y los milisegundos reales del ESP32. De esta forma, si nos llegan más notas del AY en los 20 ms del frame, se reproducirían todas en el tiempo que corresponde, mientras que si sólo ocurriera una sola nota por frame, saldría en el momento que le corresponde, y no como hasta ahora. De esta forma, suena exageradamente mejor, sobre todo en los juegos con muchas notas por segundo.

El DAC del ESP32, al igual que muchas SOC's y MCU's, es siempre positivo, es decir, no tiene en cuenta la componente negativa, por ir de 0 a 255, lo cual es un gran problema, de ahí que lo ideal es usar un DAC de verdad o añadir un Amplificador operacional con alimentación positiva y negativa. Para la mezcla, se usa valores reducidos para evitar el clipping, y se adapta a 1v, por lo que no llega a 255, sino mucho menos, de ahí que suene bajo, pero suficiente para unos auriculares básicos. Se recomienda conectarlo a un preamplificador de audio. Además se aplica un filtro de recorte, y en la placa TTGO VGA32 ocurren preemphasis en frecuencias por encima de 2000 Hz. Luego está el tema, que yo le añadí un recorte, que a partir de 15000 Hz, se quedará en ese mismo valor.

Hay mucha manía de querer usar lo que se quiere. Por favor, prestad atención a usar:
Visual Studio 1.48.1 PLATFORMIO 2.2.1 Espressif32 v3.3.2
Arduino IDE 1.8.11 Espressif System 1.0.6
Si os empeñáis en usar lo que os de la gana, es vuestra propia aventura.
Se usa la versión reducida de sonido de fabgl que realizó @dcrespo3d (David Crespo Tascón), que usa el DAC interno en I2Sound. Existen problemas ya reconocidos por Espressiff con frameworks específicos, que no dejan usar el DAC, o no dejan usar el DAC interno en modo I2Sound. Si se tiene este problema y os empeñáis en seguir usando las versiones que os da la gana, ya sabéis el motivo.
En un futuro, desaparecerá cualquier residuo de fabgl, incluido para sonido, por algo tan sencillo, como que se va a terminar usando la solución más simple y reducida.



Conclusión
Se ha logrado que todo funcione en un único core ( no exprimido al 100%) con sólo SRAM, quedándonos el segundo core y el mcu ULP libres al 100%. Por tanto, aún queda mucho por apretar y sacar más rendimiento.

¿Cuando añadiré todo lo que falta? Pues francamente, no lo sé, es más, desconozco lo que haré o si haré público algo, lo que si sé, es que no será pronto, dado que mi tiempo libre, es limitado. Como comentaba, la idea original, es tener algo de lo que partir, compartir ideas, sin tener la mente cerrada, y ya cada uno que elija su propia aventura, o haga lo que le brote, sin marcar una única forma de realizar algo y sobre todo sin perder el tiempo. Y eso hasta la fecha, está de sobra conseguido.

Adaptar aplicaciones o juegos para zurdos o diestros, no es algo tan trivial como dejar una opción para unos u otros, ya que cambia también las acciones y la propia dinámica del juego. De esta misma forma, este emulador está pensado para mi, y no para el resto de gente, y esa es la línea principal que siempre se ha seguido y se seguirá.

El emulador de Master System lo tengo funcionando desde el verano pasado y aún así, no lo he publicado, con eso lo digo todo, respecto a prioridades y tiempo libre. En proyectos de tiempo libre, no es bueno estar con un mismo tema constantemente, sino la mente no desconecta.

Que cada uno se sienta libre de hacer el fork o lo que le brote. En este primer post de 2020/08/28 quedaron los objetivos bien reflejados:

https://retrowiki.es/viewtopic.php?t=200036016
mvalder
Mensajes: 841
Registrado: 21 May 2023 02:04

Re: Tiny ESP32 CPC (Origen FAQ)

Mensaje por mvalder »

Muchas gracias por el emulador y las explicaciones, @akerman.

Como dices, es muy conveniente tener este material en un foro en lugar de andarlo explicando -una y otra vez- por Telegram y similares, que son pan para hoy y hambre para mañana.

Saludos y gracias.
Avatar de Usuario
ackerman
Mensajes: 499
Registrado: 05 Feb 2019 21:32
Ubicación: Asturias
Contactar:

Re: Tiny ESP32 CPC (Origen FAQ)

Mensaje por ackerman »

mvalder escribió: 08 Jun 2024 15:22 Como dices, es muy conveniente tener este material en un foro en lugar de andarlo explicando -una y otra vez- por Telegram y similares, que son pan para hoy y hambre para mañana.
Era algo que me daba mucha pereza escribir, y muchas veces quise empezar a crear la FAQ, pero pasaba y pasaba el tiempo, y nunca llegaba el momento. Pero una vez que se da el paso, luego es más fácil añadir cosas.

Actualmente uso el canal personal del youtube, que es de andar por casa, sin intención comercial, para subir previews. Recomiendo tirar de bloqueadores, navegación anónima y demás para evitar cualquier intrusión. Podría usar otros medios, pero eso de subir un video y que uno se lo baje, con posibilidad de virus, en pleno 2024, lo veo muy invasivo. Es lo más práctico, tanto para el que lo ve, como para el que lo sube, sin tener que pagar, y despreocupándose de que al cabo de un determinado tiempo lo borren. Las condiciones de youtube, en un futuro pueden cambiar, dado que nada está escrito, pero será tan sencillo, como pasarse a otra plataforma de stream.

Si miramos atrás, casi todos los proyectos de este estilo técnico, tenían su propio host web, que al cabo de un par de años, se dejaba de pagar, y se perdía todo. Luego llegaron los blogs, y más o menos, lo mismo, en 10 años, todo perdido. En los foros, la fórmula, más o menos va aguantando.

Yo no he creado canal de discord de este proyecto, en realidad lo creó un tal Snake, que no lo conozco en persona. Hasta lo poco que sé, quien administra, está relacionado con la venta de placas de la empresa Agon, entre ellas de ESP32. Ha englobado una gran cantidad de canales relacionados con ESP32 y demás, y dado que lo ha creado, lo he aprovechado.
Prefiero mantenerme lejos de cualquier tema relacionado con dinerito, ventas, compras y chorradas varias.
Discord no es una herramienta que me atraiga mucho, la veo justo como lo contrario, todo lo intenta mezclar, parece como el internet de los 90’s.

No he creado telegram de este proyecto,ni intención que tengo, es más,me he salido de muchos otros canales, por algo tan simple, como saturación de información, que parecían una teletienda y básicamente, que no eran para mí. Pero si me han llegado privados, tanto por telegram, correo, foros, discord, etc.., que a pesar de que siempre termino diciendo, mejor plantear dudas por foro, al final tururú corneta.

Si discord no lo veo, Telegram o wasap para estas cosas, menos aún. Eso no quiere decir, que en un futuro, la tecnología mejore o de un giro, y la cosa cambie.
Avatar de Usuario
cacharreo
Mensajes: 1405
Registrado: 03 Jun 2023 09:37
Ubicación: /home/cacharreo/

Re: Tiny ESP32 CPC (Origen FAQ)

Mensaje por cacharreo »

ackerman escribió: 09 Jun 2024 08:17Actualmente uso el canal personal del youtube, que es de andar por casa, sin intención comercial, para subir previews. Recomiendo tirar de bloqueadores, navegación anónima y demás para evitar cualquier intrusión. Podría usar otros medios, pero eso de subir un video y que uno se lo baje, con posibilidad de virus, en pleno 2024, lo veo muy invasivo.
Comprendo todo esto pero, al final en mi caso, tengo que descargar los vídeos para verlos.
ackerman escribió: 09 Jun 2024 08:17Si miramos atrás, casi todos los proyectos de este estilo técnico, tenían su propio host web, que al cabo de un par de años, se dejaba de pagar, y se perdía todo. Luego llegaron los blogs, y más o menos, lo mismo, en 10 años, todo perdido. En los foros, la fórmula, más o menos va aguantando.
No podía estar más de acuerdo, los foros son el medio natural para este tipo de proyectos.
ackerman escribió: 09 Jun 2024 08:17Prefiero mantenerme lejos de cualquier tema relacionado con dinerito, ventas, compras y chorradas varias.
Muchísimo mejor así. Si no, los problemas aparecen se haga lo que se haga.
ackerman escribió: 09 Jun 2024 08:17Discord no es una herramienta que me atraiga mucho, la veo justo como lo contrario, todo lo intenta mezclar, parece como el internet de los 90’s.
...
Si discord no lo veo, Telegram o wasap para estas cosas, menos aún. Eso no quiere decir, que en un futuro, la tecnología mejore o de un giro, y la cosa cambie.
Todos estos medios no tienen un acceso abierto y gratuito, exigen smartphone, un número de teléfono,... Para algunos estas son condiciones inaceptables.
© cacharreo
Avatar de Usuario
Eremus
Mensajes: 189
Registrado: 01 May 2022 18:10

Re: Tiny ESP32 CPC (Origen FAQ)

Mensaje por Eremus »

Pues muchas gracias por reunir toda la info en un post :)

Como ya sabes, ya estoy en marcha preparando lo que será CPCESP que es el nombre que va a tener la emulación Amstrad en el proyecto ESPectrum y aunque el objetivo es, al igual que con ESPectrum, intentar conseguir una emulación lo más fiel precisa a los CPC 464, 664 y 6128, tu trabajo es una ayuda valiosísima porque me permite tener un punto de partida para poco a poco, y de nuevo al igual que con ESPectrum, ir refinando y mejorando la emulación.

Ya os iré informando de los progresos. A corto plazo, y espero que antes de que acabe el mes, espero tener una versión alpha pero que permita ya hacer ciertas cosas.

Saludos! -grin
mvalder
Mensajes: 841
Registrado: 21 May 2023 02:04

Re: Tiny ESP32 CPC (Origen FAQ)

Mensaje por mvalder »

ackerman escribió: 09 Jun 2024 08:17 No he creado telegram de este proyecto,ni intención que tengo, es más,me he salido de muchos otros canales, por algo tan simple, como saturación de información, que parecían una teletienda y básicamente, que no eran para mí.
Yo me di de alta en Telegram cuando se lanzó la Zx-Tres y sigo -cuando me acuerdo- algunos canales, pero no estoy suscrito a ninguno, precisamente por evitar la saturación de información.

Se agradece tener la información en un foro. Aquí merece la pena hacer una consulta (o responderla), porque va a quedar accesible para quien venga más tarde con el mismo problema. Y quien solo quiera leer no necesita darse de alta y -mucho menos- facilitar un número de teléfono.
Responder

Volver a “Desarrollo emuladores ESP32”