antoniovillena escribió:Si ponemos los jumpers abajo (dejando el pin sin conectar suelto) seleccionamos la paginación Sinclair (bancos contenidos 1/3/5/7). Hay que puentear los pines 1 y 5 para poder usar la otra configuración, que es poner los 2 jumpers arriba dejando libre el pin de abajo, seleccionando el modo Amstrad (bancos contenidos 0/1/2/3).
A ver... esto en el esquemático (no en la placa), ¿cómo se traduce? J13 es un conector de 4 pines. ¿Qué señales (X0, X1, BANK0, BANK2) hay que unir para activar un modo u otro?
Otra cosa: he añadido un módulo en la simulación para que haga de "frame grabber", es decir, que coja los valores de RGB (8 bits cada uno) que se van generando y me los guarde en un fichero binario. Este fichero después lo interpreto como una imagen bitmap de 448x312 píxeles, a 24 bits de color. En la imagen aparece tanto la parte visible de la pantalla como la parte invisible, donde ocurren las señales de sincronismo. Así, no sólamente tengo el cronograma para ver las señales, sino que también puedo ver el resultado como si el circuito estuviera generando realmente una imagen a color. Puedo simular un frame (20ms) o puedo simular más tiempo, y luego dividir el resultado grabado en frames y componer una animación.
Para la prueba que estoy haciendo (borde de color azul, y leyendo de memoria siempre el patrón 01010101 tanto para bitmaps como para atributos) la imagen que sale es ésta:
La parte de color negro es el intervalo de blanking, durante el cual no se emite nada (el multiplexor del final está en alta impedancia). He marcado en gris oscuro la parte del blanking en la que ocurre el sincronismo horizontal o vertical. En verde brillante, visible justo por debajo del borde inferior, está el intervalo durante el cual la señal INT del procesador está a nivel bajo.
Y aquí precisamente en la señal INT está el asunto: esta señal que veo es muuuuuy larga. En la ULA original, está a nivel bajo durante 32 T-estados de la CPU (64 píxeles). Aquí está a nivel bajo durante 312 píxeles (156 T-estados). Además, creo que ocurre 8 ciclos de pixel antes de lo debido. La cosa es que si en un programa el gestor de interrupción dura menos de estos 156 T-estados, al volver con RETI, la CPU se encontrará que aún está a nivel bajo INT, y volverá a disparar el gestor de interrupción (INT es activa por nivel) provocando probablemente errores en la temporización de algunos juegos (los hay en los que el gestor de interrupción lo único que tiene es un puñado pequeño de instrucciones para bajar o subir el bit 7 del registro R, que sirve al bucle principal del juego para saber cuándo ha ocurrido un retrazo vertical)
