Space Invaders para iCE40 H1K (en proceso)

[Roland Coeurjoly]

Hola a todos!!

En el siguiente repositorio podéis encontrar el Space Invaders en el que estoy trabajando:

https://github.com/RCoeurjoly/Space-Invaders

El Space Invaders es el último proyecto en la asignatura de Diseño Digital (por lo menos en la UC3M cuando yo la cursé).

Este Space Invaders no está terminado. Falta el movimiento de los invasores, el disparo de la bala y la maquina de estados.

Aunque todavía faltan cosas, yo creo que con los recursos de la FPGA se puede completar el juego. Esto significa que se podría utilizar esta placa de desarrollo en la universidad, eliminando así la necesidad de recurrir a Software privativo a la hora de aprender diseño digital. El único problema es que en Europa se suele enseñar VHDL, que como bien sabéis todavía no está soportado por las herramientas libres de Clifford.

Gracias a David Estévez y Sergio Vilches. Me estoy basando en su diseño: https://github.com/David-Estevez/spaceinvaders/tree/master/src

Lo distribuyo con la GPL version 3.

[Roland Coeurjoly]

[Obijuan]

Hola Roland!

Cómo molaaaaaaaaaaaaaa!!!!  Lo acabo de probar en una icezum Alhambra  y puedo ver las naves!!!  :-D




Por si alguien lo quiere probar también, el conexionado que he usado es el mismo que para el del MonsterLED:



Y el fichero vga.pcf del proyecto de Roland lo he modificado a este:


set_io dclk 21
set_io clr 119
set_io hsync 37
set_io vsync 39
set_io red 38
set_io green 41
set_io blue 43
set_io left 10
set_io right 11


La nave se puede mover con los pulsadores SW1 y SW2 de la Alhambra....

Es una pasada :-)   ¡Gracias por compatir Roland! 

Con este código se pueden aprender muchísimas cosas!!!  :-D


Saludos, Obijuan

[Juanma Rico]

¡¡Genial, gracias Roland!!

Precisamente estaba pensando (en cuanto tuviera hueco) en hacer algo similar pero con el famoso tenis/hockey del AY-3-8500.
Este chip me trae muy buenos recuerdos, tengo una placa antigua original de cuando era niño, que me regalaron con el chip que nunca pude hacer funcionar :((  pero que me animó a ir a la biblioteca para aprender de esto de la electrónica... :)))

Vuestros avances en la conexión con la VGA me había animado a ello, ya estaba pensando como hacer la gráfica... ahora veo que ya está superado el tema de la gráfica VGA, con colores "sprites" y todo.... ¡Bienn!

Mi idea era utilizar el control que Obijuan ya había conseguido con el ADC para conectarle un par de potenciómetros que hicieran de control de las "paletas" del tenis... como en el juego original. :))

Veo que Obijuan ha usado los botones para mover la nave... Juan, tú que has estudiado el código... ¿Sería muy complicado que sustituyeras los botones por el potenciómetro conectado al ADC para mover la nave del Space Invaders de Roland de un lado a otro de la pantalla? :))

Tú que puedes y tienes funcionando el sistema igual lo podrías hacer en unos minutos... lanzado está el reto. :))

Saludos y enhorabuena por los avances.

[Julián Caro Linares]

Es increible Roland. Yo también realicé esa práctica y el proyecto me trae muchísimos recuerdos :)

Espero poder probarlo cuanto antes.

Yo también pensé lo mismo cuando vi fpgas libres como la Icezum Alhambra, que serían unas sustitutas interesantes a ciertas placas entrenadoras  de la uni :)

Un saludo 

[Jose Pico]

fantástico!

Gracias

[Juanma Rico]

Buenas Roland,

Antes de nada, gracias por compartir.

Entre el ejemplo del MonsterLED de Obijuan y el tuyo, me he animado a trastear las posibilidades de la VGA.

He estado estudiando tu código, en especial el bloque de generación de sincronismos para la VGA (vgaSI.v si no me equivoco), la cuestión no es solo que no llego a obtener imagen en mi monitor, sino que ni tan siquiera me salen "las cuentas" en tu código... :(((

Te explico, en este fichero se puede encontrar lo siguiente:

   
   // video structure constants
   parameter activeHvideo = 640;
   parameter activeVvideo = 480;
   parameter hfp = 32;            // horizontal front porch length
   parameter hpulse = 48;         // hsync pulse length
   parameter hbp = 112;           // horizontal back porch length
   parameter vfp = 1;             // vertical front porch length
   parameter vpulse = 3;          // vsync pulse length
   parameter vbp = 25;            // vertical back porch length
   parameter blackH = hfp + hpulse + hbp;
   parameter blackV = vfp + vpulse + vbp;
   parameter hpixels = blackH + activeHvideo;
   parameter vlines = blackV + activeVvideo;

Si tenemos en cuenta todos los tiempos expuestos y calculamos, se obtiene:

• Por línea horizontal: hfp + hpulse + activeHvideo + hbp = 32 + 48 + 640 + 112 = 832 pixels/líneas
• Por vertical: vfp + vpulse + activeVvideo + vbp = 1 + 3 + 480 + 25 = 509 líneas/cuadro
  

Es decir tenemos un cuadro de 832*509 = 423488 pixels/cuadro

Luego si asignamos el reloj del sistema a la entrada del bloque (dclk), como así haces en el fichero vga.pcf (set_io dclk 21), estamos procesando un pixel en cada ciclo de reloj, luego tenemos 12MPixels/segundo (12Mhz), o lo que es lo mismo, la frecuencia de un cuadro de 640x480 (pixels visibles) sería de:

12*1e6 (pixels/segundo) / (423488 pixels/cuadro) = 28,3361 (1/segundo) por cuadro (frame) => 28,3361Hz por cuadro.

En definitiva, le estamos mandando al monitor una señal de 640x480@28,34Hz, cuando el estándar básico es de 640x480@60Hz.

En este caso es normal que mi monitor (que es de frecuencia fija) no admita dicha frecuencia de refresco tan baja... lo que me extraña es que haya monitores que sí lo admitan, el parpadeo en pantalla debe ser evidente. Veo en las imágenes que adjuntas, que el tuyo es un TFT de pocas pulgadas. ¿Tuviste problemas con monitores más grandes?

Igual mis cálculos no son los correctos, pero para mi está claro que 12Mhz para generar las señales de sincronismo de 640x480@60Hz son escasos. ¿Cómo calculaste tú los parámetros que tienes en el código?¿usaste para el cálculo 12Mhz?

Saludos.

[Roland Coeurjoly]

Hola Juanma,

Al principio yo también pensé en implementar un controlador de VGA con refresco de pantalla de 60Hz, pero no lo conseguí.

El problema es que para conseguir un refresco de pantalla de 60Hz con en una pantalla de 640x480 píxeles, necesitamos un reloj de pixel de 25,175MHz:

http://www.tinyvga.com/vga-timing

El proyecto icestorm tiene un programa llamado icepll que te calcula los parámetros del PLL para conseguir cierta frecuencia de salida.
Por defecto la entrada es 12MHz, por lo que su uso es muy sencillo:

icepll -o frecuencia_de_salida

Siendo frecuencia_de_salida los MHz que necesitamos.

Con los valores que nos saca, los introducimos en un módulo del tipo:

https://www.reddit.com/r/yosys/comments/3yrq6d/are_plls_supported_on_the_icestick_hw/

Pues bien, los 25,175MHz que necesitamos no los da con precisión a partir de un reloj de 12MHz.

Elegí una frecuencia de refresco de 85Hz, que necesita un reloj de píxel de 36MHz, que se consigue facilmente con los 12MHz del icestick.

Lo puedes ver en top.v.

Por otra parte, jugué bastante con los valores de front porch y demás pero he visto multitud de tablas que se contradicen entre sí, por lo que he llegado a dudar que exista un estándar.

¿Puedes configurar la frecuencia de tu monitor a 85Hz?

Saludos

[Juanma Rico]

¡¡Hola Roland!!
Gracias por responder tan rápido, el SAV no puede esperar...  :))

El domingo, 17 de septiembre de 2017, 19:18:01 (UTC+2), Roland Coeurjoly escribió:

Hola Juanma,

Al principio yo también pensé en implementar un controlador de VGA con refresco de pantalla de 60Hz, pero no lo conseguí.

El problema es que para conseguir un refresco de pantalla de 60Hz con en una pantalla de 640x480 píxeles, necesitamos un reloj de pixel de 25,175MHz:

Perfecto, ya estaba yo dudando de mis cálculos.. :))

http://www.tinyvga.com/vga-timing

El proyecto icestorm tiene un programa llamado icepll que te calcula los parámetros del PLL para conseguir cierta frecuencia de salida.
Por defecto la entrada es 12MHz, por lo que su uso es muy sencillo:

icepll -o frecuencia_de_salida

Siendo frecuencia_de_salida los MHz que necesitamos.

Perfecto, no sabía que fuera tan fácil... :))

Lo he ejecutado y para 36MHz parece que lo clava.. :)))

juanma@angora:~/Proyectos/FPGA/$ icepll -o 25.175MHz

F_PLLIN:    12.000 MHz (given)
F_PLLOUT:   25.175 MHz (requested)
F_PLLOUT:   25.125 MHz (achieved)

FEEDBACK: SIMPLE
F_PFD:   12.000 MHz
F_VCO:  804.000 MHz

DIVR:  0 (4'b0000)
DIVF: 66 (7'b1000010)
DIVQ:  5 (3'b101)

FILTER_RANGE: 1 (3'b001)

juanma@angora:~/Proyectos/FPGA/icestudio$ icepll -o 36Mhz

F_PLLIN:    12.000 MHz (given)
F_PLLOUT:   36.000 MHz (requested)
F_PLLOUT:   36.000 MHz (achieved)

FEEDBACK: SIMPLE
F_PFD:   12.000 MHz
F_VCO:  576.000 MHz

DIVR:  0 (4'b0000)
DIVF: 47 (7'b0101111)
DIVQ:  4 (3'b100)

FILTER_RANGE: 1 (3'b001)

Tampoco entendía muy bien esta parte del código, ni tan siquiera estaba seguro que el PLL de la iCE40 funcionara.

Así que perfecto, aclaradas ambas cosas, gracias.

Ahora que miro con más detenimiento veo que es cierto que el módulo vgaSI tiene como entrada el dclk  que va a 12Mhz, pero que la condición de disparo en el tratamiento del pixel y de la generación del sincronismo va con el flanco de subida de clk, que proviene del PLL... los cálculos finales no estaban bien entonces por mi parte, tenía que calcular la frecuencia de cuadro multiplicando por 36Mhz... :)))

Con los valores que nos saca, los introducimos en un módulo del tipo:

https://www.reddit.com/r/yosys/comments/3yrq6d/are_plls_supported_on_the_icestick_hw/

Pues bien, los 25,175MHz que necesitamos no los da con precisión a partir de un reloj de 12MHz.

Elegí una frecuencia de refresco de 85Hz, que necesita un reloj de píxel de 36MHz, que se consigue facilmente con los 12MHz del icestick.

Lo puedes ver en top.v.

Por otra parte, jugué bastante con los valores de front porch y demás pero he visto multitud de tablas que se contradicen entre sí, por lo que he llegado a dudar que exista un estándar.

¿Puedes configurar la frecuencia de tu monitor a 85Hz?

 

Lo dudo, es un monitor antiguo y no se entera de nada que no venga a 60Hz... :((

Pero acabo de probar con un televisor de casa que tiene entrada VGA y tampoco... los 85Hz imagino que lo tendrán los mejores monitores (no es el caso de los que yo dispongo.. :-D )

De todas formas ya me quedo más tranquilo sabiendo que los cálculos están bien y que tu controladora trabaja a 85Hz y que no es torpeza mia... cuestión de buscar un monitor que admita una mayor frecuencia.

Saludos

Muchas gracias por aclarar el tema. Seguiré investigando.

Saludos.

 

[Juanma Rico]

Buenas Roland,

Ya sabiendo como funcionaba el asunto y antes de desmontar el "chiringuito", he cambiado los parámetros del PLL para un refresco de pantalla de 60Hz a ver qué pasaba en mi monitor de frecuencia fija... y buenoooooo... no está perfecto (se pierde la imagen a la derecha), pero al menos... ¡¡se pueden ver las naves!! jajajajajaja

Me ha hecho mucha ilusión ver las navecitas y moverla con los botones... ¡¡Genial!! Al menos así se pueden hacer más pruebas... seguiremos el proyecto.

Muchas gracias por todo y un saludo. :)))

[Jesús Arroyo]

Super interesante proyecto!!

Gracias por compartirlo.

Un saludo.

El domingo, 10 de septiembre de 2017, 12:28:17 (UTC+2), Roland Coeurjoly escribió:

[Roland Coeurjoly]

Hola a todas y a todos,

Podeis encontrar una version jugable del juego Space Invaders en el siguiente repositorio:

https://github.com/RCoeurjoly/Space-Invaders

Esta probado sobre una iCEstick. Se necesita para jugar:
-Una pantalla VGA
-4 botones
-iCE40 de 1k (ya sea iCESTICK o cualquier otra placa con el chip)
-cable para el monitor

El cable para el monitor y los botones tiene que estar acompanado de resistencias pull up. Me parece que en la iCEzum Alhambra ya tiene los botones.
Modificad el .pcf porque mi setup es un poco idiosincratico.

Habia grabado un video pero pesa demasiado para adjuntarlo por aqui.

Todavia hay muchas cosas que mejorar y anadir.

Saludos!!

PS: no puedo insertar acentos ni ene de Inigo

[Roland Coeurjoly]

Se me olvidaba, para sintetizarlo, estando en la carpeta:

bash build.sh

[Juanma Rico]

¡Genial!

Loco por encontrar un hueco para probarlo... :))))

Saludos
Juan Manuel Rico

[Roland Coeurjoly]

https://www.youtube.com/watch?v=zD_Xy7i3Ies&feature=youtu.be

Video del resultado

On Sunday, September 10, 2017 at 12:28:17 PM UTC+2, Roland Coeurjoly wrote:

[Juanma Rico]

Buenas Roland,

Era algo que tenía en el "TODO" y además te lo debía... Así que aquí lo tienes...  :)))

Lo he adaptado a la icezum Alhambra y a la frecuencia de mi cutre-monitor (que como sabes no llega a los 85Hz de tu juego). :(((
Así que lo he modificado para que use mi controladora de 640x480@72Hz y lo he hecho funcionar... :)))  Las pruebas...

Para usarlo de forma indeoendiente a la icezum Alhambra le faltan botones integrados... pero unos cablecillos por aquí una resistencia por acá y se puede empezar el juego... :)))

Un par de preguntas que me han surgido al adaptar tu código (sólo por curiosidad)... y un par de consejos (si me lo permites).

¿Qué sentido tiene separar la generación del pixel clock (en tu caso de 36Mhz) del bloque de la controladora? Lo digo porque la generación de sincronismos es muy dependiente de este reloj y no le veo sentido estén por separado, de hecho he modificado el PLL para que generara mi pixel clock a 31.5Mhz, pero claro, los sincronismos no son los mismos, ya que un microsegundo en tu controladora son más píxeles que en la mia... en definitiva, he tenido que modificar los dos ficheros. De todas formas imagino la respuesta... ¿"por aquello de divide y vencerás"?... :)))

¿Para qué haces pasar el color del pixel (rgb) por la propia controladora cuando simplemente le asignas a cada uno de los componentes (red, green, blue) sin modificarlos?¿Es solo para ponerlo a cero si no está activa la señal de vídeo?¿No es mejor hacerlo externamente a la controladora?

Y los consejos... no me lo tomes a mal... sustituye los tabuladores por espacios en el editor que utilices, o bien utiliza siempre tabuladores para separar... sino todo queda descuadrado en el código ante otro tamaño de tabulador y es una locura buscar una línea de código perdida entre tabuladores. :)))

Por otro lado, tu build.sh está muy bien, pero quizás sería más conveniente (si no usas apio) usaras un Makefile para automatizar la síntesis, muchas veces prefieres grabar, otras solo sintetizar y otras limpiar y no repetir procesos completos. No es mucho más difícil de lo que tienes hecho, es simplemente separar las líneas en distintos procesos. :)))

Muchas gracias por tu aportación, a ver si le pones pronto el sonido y suenan esos disparos...jejejejeje
Seguro que Sergio estará encantado de incluirlo como ejemplo en su anunciado MOC sobre juegos basados en "sprites"... jejejejeje :)))

Saludos
Juan Manuel Rico

[Juan Gonzalez Gomez]

Hola Roland!

Muchas gracias por compartirlo! Tu proyecto es muy inspirador! Gracias 

😃

Saludos, Obijuan

--
Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a fpga-wars-explora...@googlegroups.com.
Visita este grupo en https://groups.google.com/group/fpga-wars-explorando-el-lado-libre.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/11b64c24-6d78-49ea-ae09-ad673f88d167%40googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Roland Coeurjoly]

Buenas Juanma,

(Lo siento, no tengo tildes ni ene de Espana).

Primera pregunta:

La separacion del bloque del reloj del resto del diseno tiene una razon muy practica: la simulacion.
El simulador no reconoce la sintaxis de la sintesis del reloj, por lo que da un error. Por lo tanto lo separo y en los scripts de sintesis y simulacion incluyo 2 bloques distintos de reloj.

Segunda pregunta:

Cuando dices la controladora te refieres a vga_controller? En ese caso tengo que pasar el rgb para que siempre que no este activa la zona de video (bordes laterales y superior e inferior) salga negro por el rgb. Es una especificacion del standard VGA.

Sobre las recomendaciones, creo que siempre he utilizado tabuladores pero a lo mejor me equivoco. De todas formas utilizar un estilo homogeneo de codificacion esta en el TODO. Es el punto 11 del TODO en Github.

En cuanto al Makefile, estoy totalmente de acuerdo. Es el punto 2 del TODO en Github.

Este fue mi primer proyecto con las herramientas libres IceStorm y con Verilog y casi el primero con FPGA asi que estoy seguro que hay muchisimas cosas por mejorar. Lo considero como un proyecto para aprender.

Por supuesto toda contribucion es bienvenida!!

Un saludo y gracias.

PS: estoy pensando que el siguiente proyecto podria ser adaptar algun retro-ordenador o consola a las FPGAs libres. Ya hay muchas implementadas. Habria que buscar alguna en Verilog.
https://github.com/mist-devel
Lo unico que falta es tiempo...

[Juanma Rico]

Buenas Roland,

Gracias por saciar mi curiosidad... ;))
Estoy con Obijuan, tu proyecto es muy inspirador y para mi lo fue en su momento, por eso también... ¡gracias!. :)))

Lo de las tildes no te lo puedo perdonar... hoy día que ya hasta Windows permite caracteres kanji, hiragana y katakana japoneses.... en varios tipos de teclados... una "ñ" y unas cuantas tildes seguro que no deben plantearte problemas en tu sistema operativo...  jejejejejeje :P

Y sí, te he de pedir perdón, no vi la lista TODO del readme.md... actualicé el proyecto y me fui directamente al código para probarlo... culpa mia.

Respecto a incluir o no el PLL en la simulación y el Makefile, igual puedes resolver esto rápido y eliminarlo de tu lista si le echas un vistazo al proyecto de Alexandre (uno de los últimos afectados por el "virus de la VGA"... jejejejeje). En este proyecto experimenta con los caracteres y la VGA. Él no usa apio ni icestudio, como tú, pero sí tiene hecho un Makefile y se salta el PLL en la simulación, con lo que mantiene todo en el mismo fichero vga_sync.v (en tu caso en el vga_controller.v).

Respecto a lo de hacer pasar el registro rgb por la controladora... por experiencia te diré que eso al final trae problemas. Es parecido, no digo que sea igual, a esa "realimentación de información" (perdona Unai, pero aún no encontré la palabra correcta) del color del pixel que yo hacía en mis primeros proyectos y que me terminó dando problemas, teniéndolo que desechar. Me limitaba mucho para hacer crecer los proyectos VGA (posiblemente por mi ignorancia en como tratarla correctamente, ahora sé que con un "pipeline" bien construido se puede salvar...).

No digo que tengas que cambiar tu proceso mental; pero, por si tienes curiosidad, yo lo hago fuera de la controladora, simplemente envío una señal desde la controladora de "activevideo" para pasar a cero los píxeles no visibles. Puedes ver el esquema aquí en la adaptación que hice para tu juego.

Visto lo visto te preguntarás qué ventajas tiene esto... al fin y al cabo es lo mismo, en lugar de hacerlo dentro, lo haces fuera del módulo de la controladora... :)))

Bueno, tienes razón, pero para mi tiene una gran ventaja. De esta manera, en proyectos grandes o que impliquen una dinámica independiente de la visualización, puedes actualizar la dinámica en momentos en los que no se esté dibujando en pantalla (cuando no esté activa la señal "activevideo", a la frecuencia del "frame"), con lo que la imagen es más estable y no parpadea (esto me lo enseñó Sergio con su colección iPxs, gracias Sergio... ;)).

Esto el ojo humano no lo detecta, pero al final el cerebro sí y ves algo raro que al final te cansa la vista.

Incluso en la foto que te adjunté puede verse que hay un marciano "fantasma" a la izquierda... se está dibujando, pero ya no estaba allí en el siguiente "frame" (imagino que a 85Hz en tu monitor esto ni se nota, pero a 72Hz se puede incluso fotagrafiar este efecto... curioso al menos ;) )

He estado echando un vistazo (muy rápido) al proyecto MIST, es muy interesante, inconvenientes que le veo: usa como idioma HDL de síntesis VHDL y no Verilog y por otra parte la FPGA que forma parte y es el corazón de la placa MiST es una Altera Cyclone EP3C25, que sospecho que tardará mucho en ser una FPGA que se pueda programar con herramientas libres...

Así que sin tener un GHDL en condiciones y sin la FPGA con la ingeniería inversa hecha... sospecho que el trabajo de traducir a Verilog y adaptarlo a otra placa con características similares a la MiST (que yo sepa aún no está desarrollada), se me antoja un trabajo muy arduo para el poco tiempo que disponemos todos...

Pero... ¡Oye! Si te animas y quieres ser de nuevo una inspiración para el grupo... ¡Adelante! Yo estaré ahí para dejarme inspirar... :)))

Un saludo
Juan Manuel Rico

[Roland Coeurjoly]

Buenas Juanma,

Sobre el MIST, el objetivo sería adaptar los proyectos que están escritos en Verilog (que los hay, como la NES y la GameBoy) a la FPGA de Lattice que ya están soportadas por el proyecto IceStorm. Esta adaptación consiste en adaptar las partes que no son Verilog estandard, como los relojes, la RAM etc.

Hace un tiempo hice unas cuentas rápidas y me parece que en la Lattice 8k cabría el diseño de NES. Eso sí, habría que realizar un cableado para la tarjeta SD y demás.

Un saludo,

Roland

--
Has recibido este mensaje porque estás suscrito a un tema del grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/fpga-wars-explorando-el-lado-libre/ILwpeJ2Qu_Y/unsubscribe.
Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a fpga-wars-explorando-el-lado-libre+unsubscribe@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a fpga-wars-explorando-el-lado-li...@googlegroups.com.

Visita este grupo en https://groups.google.com/group/fpga-wars-explorando-el-lado-libre.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/6b7fb0c5-c79e-4239-8d81-3ef1bf84e239%40googlegroups.com.

[Alexandre Dumont]

Hola Roland,

SObre lo que dices de no poder simular, yo lo he resuelto asi, por si sirve a alguien:

`ifndef SYNTHESIS
	// SIMULATION
	assign px_clk = clk;
	`else
	// SYNTHESIS
	SB_PLL40_CORE #(.FEEDBACK_PATH("SIMPLE"),
	.PLLOUT_SELECT("GENCLK"),
	.DIVR(4'b0000),
	.DIVF(7'b1010011),
	.DIVQ(3'b101),
	.FILTER_RANGE(3'b001)
	)
	uut
	(
	.REFERENCECLK(clk),
	.PLLOUTCORE(px_clk),
	.RESETB(1'b1),
	.BYPASS(1'b0)
	);
	`endif

https://github.com/adumont/fpga-font/blob/master/vga_sync.v#L55 

(En ese caso, se podria poner otro codigo).

[Juanma Rico]

Buenas Roland,

Pues si se necesitan 8k es perfecto para la TinyFPGA-B2 y la futura BX...
Además Luke ha desarrollado una placa con VGA, memoria SRAM, sonido, USB y SDCard...

https://www.tindie.com/products/tinyfpga/tinyfpga-computer-project-board/

Ideal para las pruebas... Así que si te animas con la NES házmelo saber... a ver si te puedo echar una mano... :)))

Saludos
Juan Manuel Rico

[Alexandre Dumont]

Hola Roland,

Te he mandado un pull-request con 3 commits:

- Te he añadido mi Makefile que es bastante generico y permite sintetizar el proyecto, lanzar la simulacion y programar la FPGA, asi como simular submodulos. Si instalas netlistsvg, tambien puedes genera los diagramas svg correspondiente a cada submodulo.

Es muy facil de usar:

# top level/proyecto:

#   make sim|bin|upload

# Submodules:

# make MODULE=moduleName sim|svg

Con eso ya no deberias necesitar los script shells de build/sim.sh que tienes, ni para el top module, ni para los submodules.

Tambien he actualizado el README.md para incluir informacion de como sintetizar/simular/programar todo el proyecto, y como simular un submodulo.

Si quieres probar antes de hacer el Merge del pull-request, lo tienes en el fork que he hecho aqui : https://github.com/adumont/Space-Invaders

Un saludo,

Alex

[Roland Coeurjoly]

Hola Alex,

Muchas gracias. En cuanto pueda lo pruebo y te digo.

--
Has recibido este mensaje porque estás suscrito a un tema del grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/fpga-wars-explorando-el-lado-libre/ILwpeJ2Qu_Y/unsubscribe.

Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a fpga-wars-explora...@googlegroups.com.

Visita este grupo en https://groups.google.com/group/fpga-wars-explorando-el-lado-libre.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/ee998a36-3782-4ae8-b9b6-9e1fad8f7c62%40googlegroups.com.

[Sergio Cuenca]

Hola Roland,

como te comentó Juanma, cuando tengas el diseño completo te animo a que lo adaptes a la librería iPXS, si necesitas ayuda aquí estamos para lo que haga falta. A ver si conseguimos incrementar la comunidad en torno a diseños VGA, eso puede darnos mucha visibilidad.

Saludos

Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a fpga-wars-explorando-el-lado-libre+unsubscribe@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a fpga-wars-explorando-el-lado-li...@googlegroups.com.

[Roland Coeurjoly]

Gracias por el cambio Alexandre.