Haz una pregunta
  Foros de Electrónica » Diseño digital » Microcontroladores y sistemas embebidos
Foros Registrarse ¿Olvidaste tu contraseña?

Temas similares

28/07/2008 #21

Avatar de Meta

Si ya te gustan los textos de Resident Evil 5 http://www.gametrailers.com/player/36581.html

También podrías usar un PIC32 de 80 MHz, lo más rápido que hay en el mercado.

Es broma.
28/07/2008 #22


Un video y nos vamos

YouTube - micro bitman Video NTSC usando un PIC16F88
28/07/2008 #23
Moderador

Avatar de Chico3001

Siempre me ha gustado este tema... incluso presente un proyecto generador de TV en blanco y negro para NTSC usando un PIC16F84 a 4MHz solo que como el ciclo de reloj era tan lento solo podia generar barras gruesas en vez de lineas delgadas en el horizontal...

Pero proponer micros cada vez mas rapidos se me hace una solucion poco practica y un poco cara por una razon.... el ATARI2600 que todos conocemos fue inventado a finales de los 70s y usaba procesadores arcaicos de 1MHz, sin embargo podia manejar 128 colores y graficos y sonido bastante buenos para la epoca....

Como es posible que teniendo a nuestra disposicion micros mas grandes y potentes (lease un PIC a 4MHz) no podamos generar las mismas graficas?

Creo que con la electronica actual a nuestra disposicion deberiamos ser capaces de lograr algo similar.... pero por mas que investigo no encuentro como lo hicieron, posiblemente ustedes sepan o hayan visto algo por alli en internet....
28/07/2008 #24

Avatar de gzaloprgm

La velocidad del pic es 4MIPS (a 12MHz), la del atari2600 era 1MIPS (supongo) pero tenía un procesador de video analógico aparte, que seguramente corría mucho más rapido y leia de una memoria de video compartida entre ambos.

Si podemos conseguir procesadores de videos podríamos dedicar el pic unicamente a manejar la memoria, por lo que se podrían crear cosas más complejas sin depender de las sincronizaciones correctas y la lógica para escribir en la pantalla, dejando unicamente una rutina de acceso a una memoria vram.

Además, para generar gráficos en color necesitaríamos un DAC con más resistencias y mucho más código, para obtener 256 colores harían falta usar 8 bits del micro con 8 resistencias.

Acá encontré un sitio donde usan un pic16f628a a 20mhz y generan un juego estilo space invaders en color! pero usan conexión RGB SCART, no composite: http://www.quinapalus.com/picsi.html

Saludos,
Gonzalo
28/07/2008 #25
Moderador

Avatar de Chico3001

gzaloprgm dijo:
La velocidad del pic es 4MIPS (a 12MHz), la del atari2600 era 1MIPS (supongo) pero tenía un procesador de video analógico aparte, que seguramente corría mucho más rapido y leia de una memoria de video compartida entre ambos.

Si podemos conseguir procesadores de videos podríamos dedicar el pic unicamente a manejar la memoria, por lo que se podrían crear cosas más complejas sin depender de las sincronizaciones correctas y la lógica para escribir en la pantalla, dejando unicamente una rutina de acceso a una memoria vram.

Además, para generar gráficos en color necesitaríamos un DAC con más resistencias y mucho más código, para obtener 256 colores harían falta usar 8 bits del micro con 8 resistencias.

Saludos,
Gonzalo
Efectivamente.... el atari usaba un un 6507 a 1.2MHz lo que le daba alrededor de 1MIPS, y como coprocesador de video aparentemente usaba un PLD (?) Xilinx, ambas tecnologias son superobsoletas al dia de hoy...

Para generar color necesitamos mas bits, pero en un procesador de 8 bits no es problema, para generar la señal NTSC o PAL se puede usar un convertidor RGB a NTSC (AD723 de analog) y resolvemos el problema facilmente, pero la parte donde ando atascado es en la programacion del CPLD para generar una memora RAM de doble puerto con un secuenciador automatico que envie los datos al AD723

Resolviendo esa parte el pic (en mi caso un AVR) solo se dedicaria a generar las graficas y sonidos necesarios.....
29/07/2008 #27

Avatar de gzaloprgm

Bastante rápido lo renderiza, no sabía que calcular 136 senos y cosenos con un micro de 8 bits a 16 MIPS tardara tan poco
29/07/2008 #28

Avatar de Meta

Muy interesante los vídeos.

Insisto que para solventar problemas, mejor usar un PIC con 48 MHz y asunto solucionado. Por ejemplo el PIC 18F2550. Pruébalo.
29/07/2008 #29


Vaya, en el video que puso torresdelamora usan 5 microcontroladores atmega.

Chico3001 tiene razón, la solución no tiene por que ser usar micros más grandes o más rápidos (aunque claro que eso si ayudaría bastante), yo creo que la solución es utilizar al menos dos microcontroladores, uno que funcione como GPU y otro como CPU de modo que uno esté dedicado exclusivamente a generar los gráficos y el otro que realice cualquier otra tarea que se tenga que hacer.

Con el mismo hardware (esos 5 microcontroladores) el del video anterior también hizo este pacman que es bastante impresionante:
YouTube - Pacman running on my homemade console

Pero también hay alguien que hizo un pacman (con menos resolución y blanco y negro) con un sólo atmega8:
YouTube - Pacman AVR by Duch
29/07/2008 #30

Avatar de Meta

Muy curioso. Me la juego que alguien hará algo de eso con un PIC32. Con ese si que no hay problemas de limitaciones.
29/07/2008 #31


Antes de nada quiero "quejarme" del termino NTSC, si no se utiliza la modulacion de color no se puede llamar NTSC sino señal de blanco y negro (sincronismo + luminancia).
La diferencia esta en la complejidad, mucho se hablo,pero creo que el unico que lo consiguio fue con la gama SX, una especie de pic tuneados a 50Mhz.



Por impresionante esta "DEMO" con SONIDO guapisimo.
Hay algunos puntos que me hacen sospechar parece tener mucha resolucion...?

El sonido y la preimagen las generan en los tiempos muertos del refresco.

Lo que me tiene intrigado es la entrada MOSI (canal serie).

En su dia pense que era una señal interesante(SPI/I2C), le tiras el dato y va saliendo bit a bit como si fuera un registro de desplazamiento, esto permitira ganar 7ciclos libres y ganar velocidad

Creo que es interesante estudiar si es factible utilizar el spi para enviar información a la pantalla mediante interrupciones.


Otra forma de plantearlo seria utilizando una memoria RAM y un contador tipo 74hct4040, pero esto ya se complica un poco
29/07/2008 #32


Soy yo el que sigue llamando NTSC a la señal de video, eso lo hago para dejar claro que la imágen se ve en un televisor compatible con el estándar NTSC, debería usar el termino RS170 pero NTSC suena más claro
29/07/2008 #33

Avatar de Meta

tiopepe123 dijo:
Antes de nada quiero "quejarme" del termino NTSC, si no se utiliza la modulacion de color no se puede llamar NTSC sino señal de blanco y negro (sincronismo + luminancia).
La diferencia esta en la complejidad, mucho se hablo,pero creo que el unico que lo consiguio fue con la gama SX, una especie de pic tuneados a 50Mhz.



Por impresionante esta "DEMO" con SONIDO guapisimo.
Hay algunos puntos que me hacen sospechar parece tener mucha resolucion...?

El sonido y la preimagen las generan en los tiempos muertos del refresco.

Lo que me tiene intrigado es la entrada MOSI (canal serie).

En su dia pense que era una señal interesante(SPI/I2C), le tiras el dato y va saliendo bit a bit como si fuera un registro de desplazamiento, esto permitira ganar 7ciclos libres y ganar velocidad

Creo que es interesante estudiar si es factible utilizar el spi para enviar información a la pantalla mediante interrupciones.


Otra forma de plantearlo seria utilizando una memoria RAM y un contador tipo 74hct4040, pero esto ya se complica un poco
Sigo diciendo que si no quieres limitaciones, usen el PIC32, se nota que nadie por el momento sabe manejarlo y menos en ASM. Tiene 80 MHz, nadie se puede quejar. Quizás aumente ya que antes eran de 72MHz y ahora 80.
29/07/2008 #34

Avatar de Meta

Vaya, hasta Mario sale en microcontroladores.

YouTube - Mario Bros on Atmega 64 micro controller
29/07/2008 #35


Bonito trabajo muchachos.
Los felicito. En unos días me uno con algo que pienso implementar, un entrenador para monitores y TVs.

Saludos:
29/07/2008 #36

Avatar de gzaloprgm

Estoy implementando algo parecido pero en PAL y a 20MHz.

Las líneas horizontales y sincro horizontal ya se ven perfectas, el problema es que no tengo idea de cómo hacer el sincronismo vertical. Ya busqué en internet y no logro entender cuándo hay que mandar los pulsos, de que tamaño son, de que niveles, etc.

Alguien me podría ayudar ?

Gracias,
Gonzalo
29/07/2008 #37

Avatar de Meta

Aquí hay uno que lo logró. A ver si con el tiempo hace un pequeño tutorial parte por parte del código para entenderlo.
29/07/2008 #38


Autocita:

pic-man dijo:
La resolución vertical la hice gracias a un diagrama de la página de PIC Breakout, consiste en pulsos de sincronización alternados que duran 9 líneas horizontales:
- Primero pulsos de sincronización cortos: 30us de Negro seguidos de 2us de Sincronización. Se repite 3 veces.
- Luego pulsos de sincronización largos: 30us de Sincronización seguidos de 2us de Negro. Se repite 3 veces
- Por último pulsos de sincronización cortos de nuevo: 30us de Negro seguidos de 2us de Sincronización. Se repite 3 veces.

Con eso se logra la sincronización vertical!
Es decir ocupas generar una señal que sea:
30us de Negro -- 2us de Sync -- 30us de Negro -- 2us de Sync -- 30us de Negro -- 2us de Sync
30us de Sync -- 2us de Negro -- 30us de Sync -- 2us de Negro -- 30us de Sync -- 2 us de Negro
30us de Negro -- 2us de Sync -- 30us de Negro -- 2us de Sync -- 30us de Negro -- 2us de Sync

Esa parte fue la que mas tiempo me llevó porque tambien yo buscaba información pero en ningún lado lo veía claro.
29/07/2008 #39
Moderador

Avatar de Chico3001

La idea de generacion de las sincronias es muy simple... simplemente se ponen contadores en cascada para ir contando los tiempos requeridos de sincronia horizontal y vertical

para cada pulso de sincronia horzontal esperas 64uS, y para cada vertical 14mS, durante el tiempo de sincronia la señal de video debe estar en un cero logico (que es el nivel de voltaje requerido para sincronia), para un negro la señal es de 0.3V y para un blanco de 1V

El proyecto que hice tiene unos 8 años y mis documentos se han ido perdiendo con el paso del tiempo... pero si tengo el codigo que use en un PIC16F84 a 4MHz, se los dejo para que entre todos lo estudiemos y veamos que demonios quise hacer por que el diagrama del circuito lo tengo extraviado, recuerdo que el pic daba salida en 2 pines.. uno para sincronia y otro para señal.. ambos pines se "sumaban" por medio de 2 transistores para poder generar la señal compuesta

Código:
	LIST p=16F84
	#include P16F84.inc
	
SGEN	EQU	H'0C'		;REGISTRO DE ESTADO
CONT	EQU	H'10'		;CONTADOR GENERAL
CONTV	EQU	H'11'		;CONTADOR VERTICAL
CONTH	EQU H'12'		;CONTADOR HORIZONTAL

CONTS	EQU H'13'		;CONTADOR SEGUNDOS

BAND	EQU 7			;BIT DE BANDERA

SINC	EQU 0			;BIT DE SINCRONIA
INF		EQU 1			;BIT DE INFORMACION



		ORG H'0000'

		BSF 	STATUS,RP0		;PAGINA 1
		MOVLW	B'00000000'		;
		MOVWF	OPTION_REG		;CONFIGURA OPTION
		MOVLW	B'00000000'		;
		MOVWF	TRISA			;CONFIGURA PUERTO A
		MOVLW	B'00000000'		;
		MOVWF	TRISB			;CONFIGURA PUERTO B
		BCF		STATUS,RP0		;PAGINA 0

;++++++++++ FIGURA 1 +++++++++++++++

		MOVLW	D'170'			;CONTADOR SEGUNDOS
		MOVWF	CONTS			;
FIG1	MOVLW	D'229'			;CONTADOR 14mS
		MOVWF	CONTV			;
HOR1	MOVLW	D'18'			;CONTADOR 64uS
		MOVWF	CONTH			;
		
		NOP						;
		NOP						;
		BSF		PORTB,SINC		;PULSO SINCRONIA
		NOP						;
		NOP						;
		BCF		PORTB,SINC		;

SAL1	DECFSZ	CONTH,F			;64uS?
		GOTO	SAL1			;NO, CONTINUA ESPERANDO

		DECFSZ	CONTV,F			;14mS?
		GOTO	HOR1			;NO, GENERA SINC HORIZONTAL

		MOVLW	D'166'			;SI, GENERA PULSO 2mS
		MOVWF	CONTH			;
		MOVLW	D'03'			;
		MOVWF	CONTV			;

		BSF		PORTB,SINC		;PULSO EN ALTO

SAL2	DECFSZ	CONTH,F			;RETARDO DE 2mS
		GOTO	SAL2			;
		DECFSZ	CONTV,F			;
		GOTO	SAL2			;
		
		DECFSZ	CONTS,F			;TIEMPO DE PANTALLA TERMINADO?
		GOTO	FIG1			;NO, VUELVE A GENERAR FIG 1


;++++++++++ FIGURA 2 +++++++++++++++

		MOVLW	D'170'			;CONTADOR SEGUNDOS
		MOVWF	CONTS			;
FIG2	MOVLW	D'229'			;CONTADOR 14mS
		MOVWF	CONTV			;
HOR2	MOVLW	D'10'			;CONTADOR 32uS
		MOVWF	CONTH			;
		
		NOP						;
		NOP						;
		BSF		PORTB,SINC		;PULSO SINCRONIA
		NOP						;
		NOP						;
		BCF		PORTB,SINC		;

SAL3	DECFSZ	CONTH,F			;32uS?
		GOTO	SAL3			;NO, CONTINUA ESPERANDO

		BSF		PORTB,INF		;DIBUJA LINEA
		BCF		PORTB,INF		;

		MOVLW	D'07'			;RESTO DE LA ESPERA
		MOVWF	CONTH			;
		
SAL4	DECFSZ	CONTH,F			;32uS?
		GOTO	SAL4			;NO, CONTINUA ESPERANDO

		DECFSZ	CONTV,F			;14mS?
		GOTO	HOR2			;NO, GENERA SINC HORIZONTAL

		MOVLW	D'166'			;SI, GENERA PULSO 2mS
		MOVWF	CONTH			;
		MOVLW	D'03'			;
		MOVWF	CONTV			;

		BSF		PORTB,SINC		;PULSO EN ALTO

SAL5	DECFSZ	CONTH,F			;RETARDO DE 2mS
		GOTO	SAL5			;
		DECFSZ	CONTV,F			;
		GOTO	SAL5			;
		
		DECFSZ	CONTS,F			;TIEMPO DE PANTALLA TERMINADO?
		GOTO	FIG2			;NO, VUELVE A GENERAR FIG 1

		GOTO	FIG1			;REPITE SECUENCIA
								;HASTA EL CANSANCIO
	
		END
Como pueden observar el codigo esta hecho para compensar incluso los saltos del pic asi que si quieren usar este codigo en un pic mas rapido van a tener que recalcular todos los contadores y los nops que vean

Aqui se generan 2 pantallas... la primera es completamente negra y dura unos 3 segundos, la segunda es una raya (o mejor dicho barra) en el centro de la pantalla y tambien dura 3 segundos... despues se repite la secuencia....
29/07/2008 #40

Avatar de gzaloprgm

Gracias, lo había leído, pero pensé que era solo para ntsc. ops:

Por otro lado, hice un código que se podría poner en las scanlines y me da que con 20MHz se pueden hacer 231 pixeles y los pixeles múltiplos de nueve son iguales a los de la izquierda.

Voy a ver si implemento VSYNC y hago alguna animación sencilla.

En tu video, los cuadrados se ven separados, es por algo en particular? o es a propósito?

Saludos,
Gonzalo
¿Tienes una mejor respuesta a este tema? ¿Quieres hacerle una pregunta a nuestra comunidad y sus expertos? Registrate

Foros de Electrónica » Diseño digital » Microcontroladores y sistemas embebidos

Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Search Engine Optimization by vBSEO ©2011, Crawlability, Inc.