Este es el diagrama de bloques de la parte de nuestro sistema que actuará de interfaz con el monitor VGA. Como vemos, consta de dos bloques básicos, que son los que explicaremos a continuación: un bloque de sincronismo y un controlador RGB. La entrada de DATOS corresponde a la salida de la RAM donde se guardan los resultados de la FFT, y el bloque FMS3818 es, entre otras cosas, un DAC para construir las señales R, G y B analógicas que se envían al monitor.

Comenzaremos por el bloque de sincronismo, concretamente con las señales sinc_hor y sinc_ver. Estas son las señales de sincronismo horizontal y vertical, trenes de pulsos rectangulares ambas, cuyo funcionamiento se explica en el apartado del monitor. Lo que ocurre es que ahora nosotros hemos de calcular las características de esas señales en función del monitor que vamos a utilizar. Nuestro monitor tiene una resolución de 640x480 píxeles. Esto hace pensar que el período de un píxel, y por tanto el de esas dos señales, estará relacionado con esos números. Pues bien, esto es incorrecto. En realidad, la pantalla tiene 800 píxeles en horizontal y 525 líneas. La diferencia de píxeles quedará aclarada a continuación al explicar la forma de las señales.

En primer lugar, si queremos una frecuencia de pantalla de 60 pantallas por segundo (para evitar parpadeo) debemos utilizar una tasa de píxel 800x525x 60, que aproximaremos por 25 MHz.

Partiendo de esa base, esta es la forma de la señal sinc_hor:



Como vemos, la señal consta de la parte activa (durante la cual h_activo está a 1), un pórtico delantero (borde derecho), retorno (el haz de electrones vuelve al lado izquierdo) y pórtico trasero (borde izquierdo). Estas tres últimas partes no corresponden a píxeles visibles de la pantalla, por lo que h_activo está desactivada en ese intervalo. Pues bien, como la tasa de píxel es 25 MHz, su inverso será el período de píxel, y este multiplicado por 800 será la duración del barrido temporal. Multiplicando la duración en píxeles de cada intervalo obtenemos la duración temporal. Así sabremos el tiempo que debemos mantener activa sinc_hor (todos los intervalos menos el retorno) y h_activo (solo el intervalo activo).

Por su parte, la señal de sincronismo vertical, es similar, y tiene la siguiente forma:



Los distintos intervalos se deben a lo mismo, correspondiendo el pórtico delantero al borde inferior y el trasero al superior. La duración de cada intervalo ahora se multiplica por el período de píxel y por el número de píxeles de una línea para obtener la duración temporal de cada intervalo.

Solo queda añadir que la señal activo que sale del bloque será resultado de multiplicar h_activo por v_activo, es decir, solo será activa si lo son las dos a la vez.

Las señales pixel_x y pixel_y se corresponderán obviamente con el píxel y línea actuales, de los que tendremos que llevar cuenta.

Como vemos, la implementación del bloque es sencillísima, lo único que tenemos que hacer es construir un período de cada señal a partir de nuestros cálculos y sacar las cuenta de píxeles y líneas, y la señal resultante de hacer un “and” entre h_activo y v_activo.

Vamos ahora con el segundo bloque. No entraremos en mucho detalle por ahora, ya que se trata de una primera aproximación. Digamos que a este bloque entra un dato de 9 bits (entre 0 y 511, pero saturado a 460), y las posiciones de píxel y línea actuales, y la indicación de si el píxel actual es activo.

Pues bien, disponemos de 480 bits para 460 niveles en vertical. Dejando 4 para representar los ejes nos quedan 16 sobrantes, 8 de los cuales quedarán en blanco por arriba de la gráfica, y 8 por debajo. Lo mismo en horizontal: 512 valores a representar en 640 puntos. Dejando 4 para los ejes nos quedan 68, así que dejaremos 34 a cada lado. Pues bien, este bloque debe tomar las siguientes decisiones en función de las entradas. Cuando nos aproximemos al primer píxel representable de cada línea (eliminando de los activos los que dejamos en blanco) solicitaremos el primer dato a la RAM. Si el dato es mayor o igual que la línea en la que nos encontramos, dentro de las representables, pintaremos el píxel en blanco (las tres salidas totalmente a uno) y pediremos el siguiente dato a la RAM (el tiempo de lectura es mucho menor que el período de píxel, así que no habrá problema). Esto se repite durante toda la línea, y en todas las líneas, teniendo en cuenta que hay que eliminar líneas activas también.

Una posible opción sería utilizar un registro de 512 bits para indicar que componentes de la FFT ya son representables en la línea actual (si en una línea la representamos, en todas las líneas por debajo deberemos hacerlo) para no tener que efectuar siempre comprobaciones. Sin embargo, parece mucho más sencilla la otra opción de codificación, que además no conlleva el uso del registro, aunque tenga que estar tomando decisiones continuamente, estas siguen siempre la misma estructura, luego lo que se haga para una línea vale para la siguiente y no ocupa más recursos.

Esta es una primera aproximación al interfaz del monitor. Como vemos, valdrá solo para representar las señales en B/N. Cuando esto funcione, refinaremos el diseño para incluir colores, quizá letras en los ejes y demás matices añadidos. Por ahora nos centraremos en que los bloques funcionen correctamente. También en un segundo lugar nos ocuparemos del bloque FMS3818, cuyo funcionamiento es bastante sencillo.

En principio, nuestra intención es finalizar la semana del 24 de abril el bloque de sincronización y haber comenzado ya el de control de RGB, cuyo funcionamiento básico debe estar terminado a mediados de la semana siguiente, para poder meternos después en el manejo del FMS3818 y los matices gráficos.