Al final el tema es del cable USB: ha sido usar otro y ya no tengo ruido en la tele de plasma. De hecho las capturas de hoy (menos la última) son en esa tele, y con un cargador de los chinorros.
Pero antes, la nota negativa: me he cargado el conector micro-USB de la placa. Resulta que compré un cable con conector microUSB para no tener que estar andando con el único (y ruidoso) que tengo, y por lo visto éste tiene la clavija de un ancho muy ajustado. Eso significa que al meterlo en el conector micro del ZX-Uno, he tenido que hacer un poco más de fuerza para que entre... y me he llevado el conector y una pista por delante
He podido comprobar que es que el conector microUSB sólo está sujeto a la placa por dos islas de cobre que no son muy grandes, aunque en la huella aparecen cuatro islas. Sugiero conseguir conectores microUSB que tengan mayor superficie de agarre, porque con solo dos puntitos de agarre, la resistencia mecánica a la tracción es bastante menor.
Para mis pruebas, he cambiado a un cable USB blindado, donado por un chisme MIDI-USB que no funciona, y lo he conectado a dos pines del conector de expansión que llevan 5V y GND. A partir de ahí, ya no he tenido problemas con el ruido (ni con el conector
). Muy de vez en cuando el AD724 se ha puesto tonto y he tenido que darle con el dedito, pero han sido las menos.Ahora, a las pruebas con la SRAM: he terminado una versión, que parece funcional, del controlador de memoria que se encarga de multiplexar los accesos a la SRAM de 512KB para que aparezcan para el core del ZX-Uno como una memoria RAM de doble puerto. Esto significa, entre otras cosas, que podrían habilitarse modos de pantalla sin contención.
Como demostración del controlador, he hecho un pequeño core (proyecto test3 en el repositorio) que genera una pantalla de 256x192 píxeles con borde blanco, leyendo el color de cada pixel directamente desde la SRAM (posiciones 0 a 49151). Eso es, un byte por pixel, lo que significa que leo la memoria a 7MHz (el reloj de pixel). Cada byte leído se interpreta de la siguiente manera: bits 7 a 5, verde; bits 4 a 2, rojo, y bits 1 a 0, azul. El color que resulta de esta combinación es el que aparece en pantalla para ese pixel.
Al mismo tiempo que se está generando la pantalla, una pequeña máquina de estados, disparada 16 veces en cada frame, se encarga de ir pokeando en estas mismas direcciones (de la 0 a la 49151) un valor creciente, que va dando lugar a un patrón de gradiente que muestra todos los colores (256) posibles. Como es de suponer, las lecturas de memoria para generar la pantalla y las escrituras a memoria para generar el patrón que se va viendo, se hacen a puertos diferentes, y desde el punto de vista del sistema, ocurren al mismo tiempo. De hecho, este test también vale como demo de un sistema que genera imagen sin incurrir en contención.
Si el test va bien, la imagen en pantalla debe estar estable todo el tiempo, y no parpadear o presentar píxeles que cambien de color sin venir a cuento (píxeles corruptos). Una vez que el proceso "pokeador" ha terminado de llenar la pantalla, ésta debe quedarse quieta, sin que se tenga que observarse movimiento de ningún tipo.
En esta primera instantánea, el patrón se ha empezado a pokear en memoria, pero aún hay un montón de posiciones de memoria con valores aleatorios. La foto está hecha en un TV de plasma.
Aquí el patrón se ha dibujado casi en su totalidad...
Y aquí está ya completo.
A modo de comparación, el mismo patrón visto en un monitor CRT.
En todos los casos, uso la salida de video compuesto. Estoy muy perro para hacerme el conectorcito para RGB, pero ya caerá
Es que tener el JTAG y el RGB a la vez me resulta un poco enfarragoso, y tal como lo tengo ahora, pues uso el conector JTAG/RGB sólo para JTAG, y la salida de video compuesto para ver la imagen. Tiene muy buena calidad, para ser video compuesto, y de momento, nada de ruido (para esas cosas la plasma viene muy bien, porque si la señal de video tiene ruido, canta un montonazo en el pantallón)
