Generador de imagenes de video con PIC

[SavageChicken]

Hola Valdorre.

Todo aporte es bienvenido, asique a subirlo nomás.....

Salud 

[valdorre]

hola otra vez, aca les dejo un generador de video que baje de la red hace un tiempo, esta bien explicado, espero que sirva
http://rapidshare.com/files/128993338/video_generador_pic.zip

Saludos

Osvaldo

[SavageChicken]

Tiene Mucha ingformación, buenísimo el aporte.....

Salud 

[flacoclau]

Bué recién vuelvo del centro y me compré dos 12f675 por las dudas y como para ir cacharreando, son baratos salen 5,90 pesos argentinos.

[aitopes]

Hola flaco!
Yo tambien los he "adoptado". Siempre tengo alguno a mano.

Valdorre: Bienvenido al "club"! Esta noche voy a mirar el archivo que adjuntaste. Seguro que va a venir bien!

Entre todos vamos a crear algo util e interesante.

Saludos!

[valdorre]

hola gente acá les dejo la dirección http://www.pablin.com.ar/electron/proyecto/decoder/digiman.zip  de donde pueden bajar el archivo del restaurador de video, tiene una cuantas cosas bien explicadas que a lo mejor les sirve...

saludos a todos
Osvaldo

[gera]

Totalmente de acuerdo con respecto a usar un pic pequeño para generar la imagen. Obligados a programarlo en asm. No lo manejo a la perfeccion, pero algo atino y puedo cooperar.
Eso si... tengo una duda existencial... cuando ya tengamos algo mas o menos armado, q haga uno q otro "dibujo" en la tele... se supone q este pequeño pic solamente va a dibujar la imagen... la pregunta es: en q "formato" la recibe? osea, cómo se yo lo q tengo q dibujar?
Ya se q va a venir de otro controlador mas grande... pero habria q quedar de acuerdo en un protocolo o algo por el estilo. Alguna idea con esto?

hola otra vez, aca les dejo un generador de video que baje de la red hace un tiempo, esta bien explicado, espero que sirva
http://rapidshare.com/files/128993338/video_generador_pic.zip

Saludos

Osvaldo

Excelente aporte valdorre!!! ya me voy a poner con una taza de cafe gigante a digerir todo esto jeje. Saludos!!!

[SavageChicken]

tengo una duda existencial... cuando ya tengamos algo mas o menos armado, q haga uno q otro "dibujo" en la tele... se supone q este pequeño pic solamente va a dibujar la imagen... la pregunta es: en q "formato" la recibe? osea, cómo se yo lo q tengo q dibujar?

Vamos por parte dijo Jack el destripador....

   Yo veo que esto hay dos formas de atacarlo, la primera es como sugiere Marioguillote, hacer un generador de sincronismos, ya sea con un pic o con un integrado especializado, y a los sincronismos generados por este integrado sumarle la imagen (basta con sumar con un A.O. las dos señales, es más hasta podría lograrse con algunas resistencia), para ello deberían coordinarse el generador de sincronismos con la CPU del juego de manera que esta última agrege los pixeles en el momento que el primero le indique que es el momento, a esta forma yo le veo un inconveniente bastante grande y es que la CPU debe interrumpir su trabajo para añadir la imagen a los pulsos de sincronismos de video.

   La segunda me parece más práctica, aunque implica mayor trabajo para el PIC generador de sincronismos, sería que la CPU carge los pixeles en una memoria auxiliar, en el momento que más le convenga, y el generador de sicronismos además de hacer el trabajo que le da nombre, leerá esta memoria y añadira a la señal de video los pixeles en donde corresponde.

   De esta manera el PIC que maneja video, leerá lo que haya escrito la CPU y lo mostrará en pantalla sin tener que forzar a esta última a refrescar la imagen en cada cuadro, si la memoria no ha sufrido cambios se volverá a mostrar la misma imagen, y si la CPU cambió algo en la memoria, el chip de video mostrará el cambio, por otro lado también permitirá que la CPU cambie tan solo un bit de la imágen o la imagen completa, sin forzarla en cada cuadro a tener que refrescar.

Espero sus opiniones.
Salud 

[Marioguillote]

Hola Osvaldo, Gera !
Saludos a todos los que no saludé aún !

Más para leer (No me odien  )

 National Television Systems Comittee

 TV Synchronisation

 Basic Characteristics

En ésas tres páginas está todo lo que hay que saber de tiempos para crear una señal de sincronismo compuesto de TV.
Dado que hay mucho número nuevo en ésas páginas, les cuento que "lo importante" al momento de definir la temporización a crear sería:

- La duración de la línea completa
- del pórtico anterior
- del impulso de sincronismo horizontal propiamente dicho
- del pórtico posterior

Teniendo bien claros éstos tiempos, el resto sale sólo. Otro punto importante es la 1/2 línea, la que se usará para crear los impulsos de vertical, la cual sale de los enumerados arriba.

Eso si... tengo una duda existencial... cuando ya tengamos algo mas o menos armado, q haga uno q otro "dibujo" en la tele... se supone q este pequeño pic solamente va a dibujar la imagen... la pregunta es: en q "formato" la recibe? osea, cómo se yo lo q tengo q dibujar?
Ya se q va a venir de otro controlador mas grande... pero habria q quedar de acuerdo en un protocolo o algo por el estilo. Alguna idea con esto?

Imaginate que tenés un jamón entero y lo cortás en 500 "fetas" ...
Cuando se arme la señal de sincronismo compuesto, se colocará dentro de cada línea, una feta de ése jamón en forma apropiada e intercalada cómo podrás leer en las referencias que propongo; y de ésa forma se juntan todas las "fetas" en la imagen recuperada del jamón.
Es decir, el gran reto aquí es ése.
Manipular el mapa de bits que es una imagen, fraccionarla, colocarla en cada línea y obtener la imagen original bien armadita nuevamente.

Respecto a ésta primera etapa, la de armar la señal de sincronismo compuesto, sólo te dará una imagen negra "enclavada" en frecuencia horizontal y vertical de un TV comercial.
Luego se sumará la imagen línea a línea.

Saludos a todos !
Mario

[Marioguillote]

Hola Pollo !

De esta manera el PIC que maneja video, leerá lo que haya escrito la CPU y lo mostrará en pantalla sin tener que forzar a esta última a refrescar la imagen en cada cuadro, si la memoria no ha sufrido cambios se volverá a mostrar la misma imagen, y si la CPU cambió algo en la memoria, el chip de video mostrará el cambio, por otro lado también permitirá que la CPU cambie tan solo un bit de la imágen o la imagen completa, sin forzarla en cada cuadro a tener que refrescar.

Ése concepto parece muy bueno, pero determina que se deba guardar y comparar dos imágenes entre sí (las dos últimas), desaprovechando mucha memoria y el PIC debiera leerla igualmente a toda la memoria para saber cuál pixel ha cambiado y cuál no.

Hay que tener en cuenta que cada imagen completa posee 525 líneas en NTSC, de las cuales sólo 503 son las "visibles", sumado ésto a los tiempos "muertos" que brindan los impulsos de sincronismo, se pueden lograr tiempos muy útiles de refresco de memoria.
Por ejemplo, un sólo pulso de sincronismo horizontal, dura 4,7 a 4,8 microsegundos y si tenemos en cuenta que los tiempos de acceso a una RAM son de pocos nanosegundos, imagínense la cantidad de información que puede refrescarse en la sumatoria de tiempos "no mostrados" de la señal !

Por eso el PIC principal nunca estaría detenido sino que estaría aprovechando el tiempo que no usa, en refrescar la RAM para luego durante la línea leerla y mostrarla en tiempo real.

Espero que se haya entendido lo que quise expresar.

Saludos !
Mario

[gera]

De esta manera el PIC que maneja video, leerá lo que haya escrito la CPU y lo mostrará en pantalla sin tener que forzar a esta última a refrescar la imagen en cada cuadro, si la memoria no ha sufrido cambios se volverá a mostrar la misma imagen, y si la CPU cambió algo en la memoria, el chip de video mostrará el cambio, por otro lado también permitirá que la CPU cambie tan solo un bit de la imágen o la imagen completa, sin forzarla en cada cuadro a tener que refrescar.

Espero sus opiniones.
Salud 

Bien, a eso me referia. Pero todavia predomina una duda: La memoria q sera leida por el pic de video, tiene escrita la informacion tal cual el pic la tiene q escribir? Porq de ser asi, el pic principal (el q contiene el juego) tendria q generar dicha imagen, y consumir ciclos q quizas sean necesarios para procesar el juego.
Yo tenia en mente algo como: el pic principal llama a las funciones (pixel y linea, suponiendo un pong) que generan una matriz, le envia la matriz al pic de video, y el pic de video procede a transformar dicha matriz a formato video, y mostrarlo en el tele.
Estan de acuerdo? o estoy "razonando fuera del recipiente"? (dirian les luthiers)

[SavageChicken]

Hola Mario.

Me queda claro el tema de los tiempos, lo que no entiendo es esta frase, que subrayo,

Ése concepto parece muy bueno, pero determina que se deba guardar y comparar dos imágenes entre sí (las dos últimas), desaprovechando mucha memoria y el PIC debiera leerla igualmente a toda la memoria para saber cuál pixel ha cambiado y cuál no.

El tema es que no creo necesario comparar imágenes, de hecho la idea es que justamente durante los tiempos muertos del sincronismo horizontal, el pic lea los pixeles correspondientes a la próxima línea, y por el momento como trabajaremos solo en blanco y negro y con pixeles encendidos y apagados, y más aún con solo 128 pixeles por línea, bastará con que el pic lea de la memoria 16 bytes, en los que estará la información de los 128 bits a mostrar. Lo que exista en ese momento se mostrará en pantalla, sin importar si hubo cambios, a lo más lo que se puede hacer para evitar que existan cambios entre dos campos, es limitar la escritura a la memoria solo a una vez entre cuadro y cuadro.

Por eso no entiendo el tema de la comparación de imágenes.

Salud 

[Leon Pic]

Porque la frase que te cito Mario, decis que el pic encargado del video, solo actualizará los pixeles a mostrar que son nuevo.

A mi me parece que lo que quisiste decir es que, el pic maestro, solo le enviará a las nuevas pociciones de memoria, los pixeles que se modificaron entre un cuadro y otro.

O aquí puede ser que a lo que se refiere Mario, es que el pic maestro deberá hacer comparaciones de los pixeles que cambiaron, consumiendo tiempo que se necesitará para otra cosa.

También hay que considerar un tema muy importante en el pic encargado del video, y es que necesita un tiempo para que el pic maestro, le pase la información necesaria.

[SavageChicken]

Bien, a eso me referia. Pero todavia predomina una duda: La memoria q sera leida por el pic de video, tiene escrita la informacion tal cual el pic la tiene q escribir? Porq de ser asi, el pic principal (el q contiene el juego) tendria q generar dicha imagen, y consumir ciclos q quizas sean necesarios para procesar el juego.
Yo tenia en mente algo como: el pic principal llama a las funciones (pixel y linea, suponiendo un pong) que generan una matriz, le envia la matriz al pic de video, y el pic de video procede a transformar dicha matriz a formato video, y mostrarlo en el tele.
Estan de acuerdo? o estoy "razonando fuera del recipiente"? (dirian les luthiers)

Hola Gera, ¿cómo estas amigo?

   Aclaremos un par de conceptos, lo primero es que si implementamos una especie de lenguaje para nuestra maquinita de juegos, al programador le bastará con escribir algo así como "line (15,20) to (80,42)" y la CPU del juego se encargará de hacer todo lo demás, pero indiscutiblemente alguien tiene que interpretar ese comando y convertirlo en los pixeles de la imagen. El Pic más pequeñito, el que genera la imagen, ya está trabajando casi al límite de se capacidad, imaginate que tiene que procesar alrededor de 525 líneas con cerca de 648 pixeles cada una y repetir este proceso 30 veces por segundo, usando la calculadora verás que esto lo deja en el límite de su capacidad.

   Por otro lado, en cualquier máquina de juegos, el mayor consumo de recursos está en la parte de video, a eso se dedica justamente, pensemos como ejemplo el caso del pong, procesar el juego como tu dices implica leer el joystick y si el jugador presionó el boton abajo, mover la imagen de la paleta del jugador, y mover permanentemente el dibujo de la pelotita, por ende, ese es justamente el trabajo de la CPU en una máquina de juegos.

   Finalmente, imaginemos que computadores que trabajaban a 1,2,3 y 4 Mhz lo lograban con aceptable calidad (y lo hacían casi todo), y con apenas 16, 48 o 64 KB de ram, asique creo que nuestros microcontroladores (y nuestro ingenio) podremos lograrlo nosotros también.

Salud 

[SavageChicken]

Hola Leon.

Justamente, la idea es que el PIC maestro escriba solo la información que tenga que cambiar.
Por otro lado, ya dijimos que aqui no habría paso de información entre pic y pic, porque eso obligaría al pic maestro a a tener que detener su marcha para darle al pic de video la información que necesita en cada línea.
La idea, como ya mencioné, y como lo sugirió Ariel, es que el PIC maestro escriba en una RAM los pixeles, solo una vez entre cuadro y cuadro, para el sistema N, que es el que queremos implementar, equivaldría a hacerlo 30 veces por segundo (lo que liberaría al PIC maestro de tener que trabajar de más).

Salud