Generador de imagenes de video con PIC

[flacoclau]

Hola gente: Por si sirve de algo anoche empecé a escribir el código del sincronismo del 12F675, creo si no me surje algo del laburo esta tarde lo termino.
digo por si sirve de algo ya que en una de esas se pueden hacer los sincronismos con algún integradito especializado en ello, aunque ya con el precio del 12f675
creo que no se conseguirá nada más barato, salvo ya cuando se quiera generar color y demases.
por ahora lo único que realiza este micro es el sincro pero se puede estudiar lo demás
saludos!!

[SavageChicken]

Fantástico Flaco....

[Leon Pic]

Tenés razón SavageChicken, me había olvidado de ese tema. De todas maneras, habrá que diseñar o utilizar un protocolo que cuando un pic está leyendo o escribiendo en la RAM, el otro no esté tratando de acceder a la RAM.

Me parece que el protocolo debería ser así:

. Prioridad al PIC VIDEO
. El PIC VIDEO (2) debería tomar un puñado de info de la RAM y guardarlo en la interna (buffer), yo diría que una línea o dos.
. El PIC MAESTRO (1) guardará información o actualizará la RAM ni bien el PIC VIDEO liberó la RAM, de esta forma nos aseguramos que el PIC MAESTRO tiene menos de dos líneas para actualizar la RAM, digamos que unos 124uS (60uS si e buffer es de una linea)
      . Acá pueden pasar dos cosas, el PIC 1 se encuentra que la RAM está liberada, pero no sabe en que tiempo, deberá esperar al que el PIC 2 lea y deje libre la RAM
      . Acaba de ser liberada la RAM, actualizar datos por un tiempo máximo de 124uS (60uS si el buffer es de una línea)

No recuerdo los tiempo de acceso a la RAM, pero debemos asegurarnos que el PIC 1, sea capaz de actualizar como mínimo, 2 líneas en el tiempo que que el PIC 2 muestre los datos a la TV.

[SavageChicken]

En un principio pense que podíamos hacer cambio entre línea y linea, pero en realidad debe ser entre cuadro y cuadro, para que la imagen se dibuje completa en ese tiempo sin que el PIC maestro haga cambios en el contenido.
Por lo tanto tenemos mucho más tiempo, ya que el permiso sería dado en el tiempo del sincronismo vertical, que dura el equivalente a 6 líneas completas de video (si mal no recuerdo), en ese momento el pic esclavo debería avisarle al maestro que puede escribir la memoria de video.

Salud 

[aitopes]

Hola amigos!
que bien va esto!!!!!!!!!!!

El flaco ya escribiendo codigo, Mario aportando los casi 80 años de experiencia reunida en su trabajo, Valdorre, Leon, Savagechiken, Gera, y hasta Manolo metidos en este proyecto!

Respecto al tema de la memoria "de video" (vamos a tener que empezar a buscar un nombre para cada parte, para que sea mas facil nombrarlas!! ), definiendo algunos pines de cada PIC como "Enable" creo que lo tenemos resuelto....no es tan dificil el sincronizar los accesos entre ellos.

Si tenemos las señales del PIC enano correctamente implementadas, deberiamos hacer que uno de los pines que le quedan libres se ponga en "1" cuando comienza el despliegue de la linea, del cuadro o lo que mas convenga, para que el otro PIc sepa que puede enviar datos a la memoria.....

Todavia es un rompezabezas infernal de partes, pero se me ocurre que estamos cerca de encontrar una solucion, y luego...a implementarla!

Un par de imagenes de la C64, a 16 colores en 320 puntos por 200...pueden servir para imaginar a donde podemos llegar:

(ampliar a 1280 de ancho)

[Leon Pic]

SavageChicken, me parece perfecto. Así tendríamos 384uS para grabar todo un cuadro en la memoria RAM. Si surge un problema, el PIC VIDEO, solo deberá repetir el cuadro anterior y listo. No se notaría la diferencia. Un cuadro completo dura 33600uS en NTCS . El ojo humano, no es capaz de detectarlo.

Se me ocurre que el PIC VIDEO debería tener un pin para que, como dijo Ariel, el PIC VIDEO sepa si se logró con éxito la actualización de la RAM. En caso de que no se alla completado la actualización, el PIC VIDEO deberá repetir el cuadro anterior en su buffer.

¡Qué lindas imágenes! Me encantaría poder llegar a esto.

[flacoclau]

Hola gente: esto se va poniendo lindo, porque se van definiendo cosas, por empezar el código ya está casi listo, esto es porque es bastante simple hecho con un par de subrutinas, el resto es afinar los tiempos de sincronismo y queda listo.
estos tiempos están hechos con rutinas de delay de 1uS y luego ajustados con algunos NOP para las fracciones, el tema es que me faltó contar los tiempos que consumen los saltos y las instrucciones que inicializan los contadores.

Otra cosa: como ya me lo venía venir  hay dos pines que van al MASTER y que indican con un pulso en alto cuando empieza cada cuadro y cuando comienza cada línea horizontal, calculo que no hará falta más ya que no tengo más pines  , sinó hacer alguna combinación binaria con estos dos pines para indicar que es el cuadro par o el impar, aunque creo que no hará falta.

[Leon Pic]

Que bien flacoclau. Esperamos ansiosos el programa. 

[aitopes]

Hola gente: esto se va poniendo lindo, porque se van definiendo cosas, por empezar el código ya está casi listo, esto es porque es bastante simple hecho con un par de subrutinas, el resto es afinar los tiempos de sincronismo y queda listo.

Excelente!!!!
Cuando postees el código voy a intentar comprenderlo, va a ser mi debut con el ASM

Otra cosa: como ya me lo venía venir  hay dos pines que van al MASTER y que indican con un pulso en alto cuando empieza cada cuadro y cuando comienza cada línea horizontal, calculo que no hará falta más ya que no tengo más pines  , sinó hacer alguna convinación binaria con estos dos pines para indicar que es el cuadro par o el impar, aunque creo que no hará falta.

Creo que con esos dos pines estamos bien. En el remoto caso que no sean suficientes, los combinamos. Pero dudo que haga falta más!!!!

[gera]

Hola a todos! Esto ya va tomando forma. Y creo q todas mis dudas han sido resueltas. Por lo tanto, resumiendo y proponiendo un poco:
Lo que se va a hacer aqui, es un modulo completo de video (placa de video digamos). El cual consta de:

• Generador de sincronismos: que seria el pic12 y escribiria directamente en el televisor.
• Generador de imagen: Propongo un controlador intermedio, que tome instrucciones simples del pic maestro, y las traduzca a señales PAL (o lo q sea) y las escriba en un buffer, el cual será leido por el generador de sincronismos.
• El buffer propiamente dicho: una memoria q vaya almacenando lo que el generador de sincronismos tiene q escribir.

Por lo tanto el pic maestro ("la consola"), solamente se limitaria a enviarle instrucciones simples al "generador de imagen", y asi ahorrando recursos. El "generador de imagen" seria el encargado de mantener el buffer lleno, ya sea con una imagen nueva q llega desde la consola, o manteniendo la ultima imagen cargada. Y el generador de sincronismos, tan solo tiene q leer el buffer y escribirlo en la pantalla.
El "generador de imagen" podria estar comunicado con el "generador de sincronismos" para avisarle cuando el buffer esta listo y puede proceder a leerlo... salvo q esten perfectamente sincronizados...

Les parece esta idea? Quizas no esten de acuerdo con el controlador intermedio... pero es lo unico q se me ocurre para solucionar el problema de quien se encarga de generar la señal de video, ya tanto la consola como el generador de sincronismos, estan muy ocupados.

Saludos!!!

EDIT: aca una imagen de lo q tengo en mente

[flacoclau]

Hola acá les dejo el ASM, falta ajustar bien los tiempos, digamos que tengo que ponerme con la calculadora a sumar o quitar  NOP en varias partes.
creo que está mas o menos explicado pero se puede hacer un resumen.

lo que pasa es que hay que estudiar las señales de sincronismo para entenderlo, pero digamos que empieza con el ciclo de preecualización del sincronismo vertical, que son 6 pulsos, luego las señales de sincronismo vertical propiamente, también 6 y luego las señales de postecualización también 6.

el registro contador_ver se encarga de contar los 6 pulsos de cada una de estas señales.

contador_lineas cuenta cada línea horizontal que son 262, pero el contador solo cuenta 252 ya que se utilizaron entre 9 y 10 en el sincronismo vertical.

contador_delay se utiliza en el bucle de retardo.

impar es un flag bit que está en el registro flags.

luego del sincronismo vertical se consulta si el campo es par o impar, ya que si es par se le debe sumar media línea de horizontal, en tiempo al principio del campo, si es impar salta directamente a la rutina de sincronismo horizontal y luego al tiempo de muestra de la imagen que son aproximadamente 52 uSeg,

ah me olvidaba de los pines gpio0 y gpio1 son los pines con los pulsos de referencia que van hacia el microcontrolador principal o de video.

luego de este tiempo se repite el bucle otras 251 veces más , ya de allí se consulta si es el final del campo impar, si es así se le suma la otra media línea que falta y se completa el ciclo.

y como dice Ariel: provisoria, ampliable y cuestionable 
recibo sugerencias...


Edito: lo vuelvo a subir, ya que le corregí un par de errores de sintaxis

[Leon Pic]

Que bien flaco, en cuanto me hago un ratito, lo simulo en el mplab y ahí saco con una exactitud de 100% los retardos. Lo complicado va hacer cuando se monte porque los componentes, tienen una tolerancia. Hay veremos si la tolerancia, nos afecta.

[flacoclau]

ok dale!!   
Con lo de los componentes no te hagas drama ya que los TV´s tienen su tolerancia tambien.

[Leon Pic]

Hola Flaco, estube simulando el soft pero las temporizaciones no concuerdan, de echo ni se le hacerca a mas de una. Antes de decir que está mal, me gustaría que por favor, me confirmes dónde empieza cada rutina de temporización, porque en el programa, hay una o dos (no me acuerdo ahora) que una temporización, utiliza otra para completar el tiempo deseado, una es el tiempo de 29,4uS, que llega a 25 y monedas (no recuerdo bien, porque en la PC que estaba trabajando me quedé sin baterías y ahora no la puedo usar hasta conseguir un enchufe  )

La rutina delay_x1uS, dura mas de 18uS. Son tiempo que están lejos y me da a pensar que yo estoy calculando los tiempos mal. Ya chequee que tubiera bien la frecuencia en 20Mhz.

Cuando mido los tiempos los hago desde el call corrspondiente hasta el return o desde que empieza a cargar el valor a una pocición de memoria hasta la siguiente línea del último decfsz.

[flacoclau]

si está un poco complicado el asunto, el tema está en que esa rutina de delay la hice medio al tuntún, por otro lado hay que ver que el delay de algunas partes hay que sumarle las demás rutinas, la otra ya que el programita es bien corto es hacerlo más lineal ya que nos sobra memoria, dejame que lo estudie un rato y te digo las cosas con más exactitud.