).
Eremus escribió:Hola!
Por cierto, al nombre del subforo le falta una erre, que así como está parece escrito por el primo Balki (toma referencia retro
Si, fue que se lo pasé mal escrito a @ron. Probe hombre, tiene merecido un altar, que le he dado la chapa para que creara el subforo. jltursan escribió:Ya decía yo que me sonaba...eso emplea Nirvana y por tanto requiere una temporización super precisa, ¿no?
ackerman escribió:Las imágenes adjuntas en los mensajes, si quieres que se vean como preview, si las bajas de resolución, se ven en el propio mensaje.
dcrespo3d escribió:He podido probar tu código, al principio cascaba una y otra vez, menos mal que recordé que mencionaste que lo estabas desarrollando para 16:9, lo puse así y ya lo he podido probar. El multicolor va perfecto y no parpadea nada.
Algunas cosas que estaban cuidadosamente ajustadas dejan de funcionar. Me refiero específicamente a la temporización de los juegos y el sonido del beeper, que ha quedado destrozado. Manic Miner ahora va mucho más rápido, y la música de Arkanoid suena muy sucia.
Pienso que lo que quizás habría que hacer es, instrucción a instrucción, calcular la coordenada (X,Y) del framebuffer ...
...
...
No se si ese framebuffer virtual podría estar en PSRam (en SRAM no nos cabe). Podríamos tener 2 scanlines en SRAM (896 bytes) o en alguna memoria aún más rápida (@ackerman sabe más del tema), e ir volcando scanline a scanline al buffer virtual. Después, en el thread de vídeo, hacer un blit del buffer virtual al framebuffer real. Puede que sea más lento que el caballo del malo... o puede que no.
que parece ser un monstruo en optimización. Lo que comentas de usar un framebuffer virtual quizá pueda acelerar. Si es así, como bien dices, se podría usar otro thread para volcarlo a framebuffer real.Con ese esquema, seguramente funcionaría el banner de letronas del Sentinel (scroll de letras en el borde superior).
Espero que lo que he dicho del sonido no lo veas como una crítica negativa, en realidad agradezco mucho tus aportes. La mayoría de la gente sólo pide funcionalidades sin aportar nada, pero tú te has puesto a picar código y eso se valora muchísimo
Código: Seleccionar todo
inline uint8_t CPU::delayContention(uint32_t currentTstates)
{
...
int modulo = halfpix % 8;
}
Cambiarlo por:
return wait_states[(halfpix & 7)];
).Código: Seleccionar todo
inline uint8_t Mem::readbyte(uint16_t addr) {
uint8_t page = addr >> 14;
switch (page) {
case 0:
return rom[romInUse][addr];
case 1:
return ram5[addr - 0x4000];
case 2:
return ram2[addr - 0x8000];
case 3:
return ram[bankLatch][addr - 0xC000];
}
}
Código: Seleccionar todo
extern "C" inline uint8_t fast_readbyte(uint16_t addr)
{
unsigned char idRomRam = (addr>>14);
if (idRomRam == 0)
{
return (gb_local_cache_rom[rom_in_use][addr]);
}
else
{
return (gb_local_cache_ram[(gb_ptr_IdRomRam[idRomRam])][(addr & 0x3fff)]);
}
Código: Seleccionar todo
inline uint8_t CPU::delayContention(uint32_t currentTstates)
{
static uint8_t wait_states[8] = { 6, 5, 4, 3, 2, 1, 0, 0 }; // sequence of wait states
currentTstates += 1; // delay states one t-state BEFORE the first pixel to be drawn
int line = currentTstates / 224; // each line spans 224 t-states
// only the 192 lines between 64 and 255 have graphic data, the rest is border
if (line < 64 || line >= 256) return 0;
// only the first 128 t-states of each line correspond to a graphic data transfer
// the remaining 96 t-states correspond to border
int halfpix = currentTstates % 224;
//if (halfpix >= 128) return 0; <- ESTA ERA LA LINEA ORIGINAL QUE PIENSO QUE NO ES CORRECTA. AUNQUE BIFROST*2 FUNCIONA.
//if (halfpix < 72 || halfpix >= 200) return 0; <- CON ESTO, QUE CREO MAS CORRECTO, BIFROST*2 TAMBIEN FUNCIONA OK.
if (halfpix < 72 - 53 || halfpix >= 200 - 53) return 0; // ASI BIFROST*2 NO SE VE PERFECTO. NIRVANA SI.
int modulo = halfpix % 8;
return wait_states[modulo];
} 
).dcrespo3d escribió:Otro detalle es que el tstate 0 no corresponde con la esquina superior izquierda del "framebuffer virtual" de 448x312, sino 96 pixels a la derecha, es decir, a la altura del borde izquierdo
Kyp escribió:A nivel de HW, para la ULA, que también tiene un contador horizontal y uno vertical, el 0-0 es el primer pixel de la zona de bitmap.
En horizontal de 0 a 255 son los pixeles, 256 a 319 borde derecho, 320 a 415 blanking (no hay imagen), y 416 a 447 borde izquierdo.
En vertical de 0 a 191 pixeles, 192 a 247 borde inferior, 248 a 255 blanking (no hay imagen), y 256 a 311 borde superior.
Para ser más exactos, esas coordenadas se corresponden a cuando se lee la memoria, pero desde que se lee hasta que se dibujan los pixels en pantalla pasa un tiempo. Si dividimos una línea horizontal en slots de 16 pixeles, la memoria se lee en los instantes 9 y 13 bitmap, y 11 y 15 atributos. Pero hasta el instante 4 del slot siguiente no empieza a pintar los primeros 8 pixeles y en el instante 12 los siguientes, es decir, que la imagen va con 12 pixeles de retraso. Todo este lio es para juntar los accesos a la memoria que hace la ULA lo más posible para que le quede tiempo a la CPU para poder leer también al menos una vez en cada slot sin tener que meter más lógica para arbitrar los accesos.
Los pulsos de sincronismo no tienen ese retraso que si tiene la generación de la imagen.
) de las mejoras al core de @zx81 que @ackerman ha implementado en su fork.zx81 escribió:P.D.: Tras cada modificación es OBLIGATORIO validarla usando test, de corrección y de velocidad. Y tampoco vale hacer 500 modificaciones y probar, hay que validar poco a poco, literalmente tras cada modificación por pequeña que sea. A veces te sorprendes del impacto de pequeños cambios, para bien o para mal. Hay que ser muy metódico para hacer ese trabajo que, además, es aburrido.
Exactamente lo que he estoy viviendo estos últimos días. A veces se me enciende una bombilla, me paso media hora implementado una idea "revolucionaria", después mido tiempos y ná de ná: mi gozo en un pozo. En otras ocasiones, cambias el tipo de una variable en plan "me aburro no sé ya que hacer" e inexplicablemente (al menos para mi): !zas¡ 100 microsegundos mas rápido. Esto de rascar microsegundos está resultando adictivo y desesperante a la vez ackerman escribió:ackerman: Es imposible, pues, que un core de ESP32 pueda ejecutar un ciclo CPU completo y video en 20000 microsegundos.
Eremus escribió:
Las ultimas mediciones tras optimizar aquí y allá ya empiezan a pintar bien
CPU + VIDEO 18166 / CPU 11801 / VIDEO 6365
Cuando implemente el dibujado del borde, los tiempos subirán un poquillo pero creo que no será demasiado ni nada que no se pueda compensar posteriormente con algunas (o todas
Volver a “Desarrollo emuladores ESP32”
Usuarios navegando por este Foro: Eremus y 1 invitado