raffi3438 a écrit:

Ah ouais, j'avais pas pensé à un raspberry :), mais est ce que tu penses que c'est assez rapide pour appliquer plusieurs filtres audio en même temps? Est ce que c'est sur (ca risque pas de boguer)? Et ca risque pas d'être compliqué pour ajouter une entrée jack ou un simple CAN suffit?

Merci

Fais une maquette de ton code sur PC, estime les besoin en puissance... sinon t'y vas à l'aveugle...

Merci

Bon je vais mettre mon projet de pedale conenctée de côté. Je viens de commander un fpga (Altera DE1 Board) pour bien apprendre le verilog (et peut-etre le vhdl un peu plus tard). j'essayerais peut-etre d'implementer un filtre pour guitare sur ce fpga mais on verra plus tard.

En tout cas merci beaucoup pour votre aide

Au fait, en attendant de recevoir mon fpga (car je l'ai acheté sur ebay US), est ce que vous connaisez un logiciel qui permet de simuler du verilog et d'utliliser des entrées/sorties par exemple d'utiliser des boutons en entrées et un afficheur en output du "fpga simulé"? (un peu comme dans logisim http://www.youtube.com/watch?v=NTRNczisCWU )

Merci 

raffi3438 a écrit:

Je viens de commander un fpga (Altera DE1 Board) pour bien apprendre le verilog (et peut-etre le vhdl un peu plus tard).

J’aurais conseillé le contraire mais bon, fais comme tu veux.

est ce que vous connaisez un logiciel qui permet de simuler du verilog

Modelsim est très bien pour ça.

et d'utliliser des entrées/sorties par exemple d'utiliser des boutons en entrées et un afficheur en output du "fpga simulé"?

Le simulateur en lui même ne permet pas ça, tu veux un environnement de test, peut être que Altera t’en fourni un avec la carte DE1 je ne sais pas.

Honnêtement je vois mal comment tu vas réussir à t’en sortir sans quelqu’un pour t’aider sur place parce que apprendre de front et en autodidacte le design numérique, un HDL (peu importe lequel), l’utilisation de modelsim et l’utilisation de Quartus II ça me parait tendu. Bon après je connais pas ton parcours, tu a peut être touché à (ou en train de voir) ce genre de chose dans ta formation auquel cas ça devrait aller.

Ben pour ce qui est de la partie "design numérique", si tu veux parler de la logique, je me débrouille un peu http://www.youtube.com/watch?v=Wr2wRu28alU&list=LL8N9FuCAw5hxJvFtbL7cJvw http://www.youtube.com/watch?v=NTRNczisCWU&list=LL8N9FuCAw5hxJvFtbL7cJvw&feature=mh_lolz bon c'est loin d'être parfait mais ca fonctionne

Pour ce qui est d'apprendre un HDL, je suis un super cours sur Internet http://comelec.enst.fr/hdl/index.html j'en suis à la fin du verilog et je pense avoir plutôt bien compris la base. Après il faudra prendre en main le kit de dev (DE1 board), mais bon je pense pas que ca soit super dur, en plus j'ai l'habite de lire des datasheets (j'avais fait des projets sur des µC PIC à l'iut). Après si ca m'interesse bien, faudra que je trouve un cours plus complet ou bien un livre pour bien approfondir un HDL, mais bon ca on verra plus tard

Et puis si j'amais je n'y arrive vraiment pas, je crois que j'ai un TP d'initation au VHDL sur fpga au 2nd semestre (je suis étudiant en télécoms à l'insa)

Voila voila, au pire si je n'y arrive pas c'est pas grave, mais bon si ca m'interesse et que je m'investie y'a pas de raison

Effectivement, ça devrait aller alors. N'hésite pas a venir poser des questions sur le forum au besoin.

Merci

Je viendrais sur le forum si besoin, mais je pense pas commecer à tester mon fpga avant les vacs d'autonne....

Bonjour! et oui me revoila

J'ai reçu mon altera DE1 la semaine derniere et j'aimerais faire un pong

J'ai fait une bonne partie des modules métiers (on dit comme ca en orienté objet mais je sais pas comment on le dit en HDL ^^) puis pour prendre en main ma carte j'ai fait un petit module qui affiche des couleurs sur la sortie vga. Seulement j'hésite à la maniere de faire le lien entre mes modules dédiés au jeu et mon module qui envoie le signal vidéo sur la sortie VGA...

Est ce qu'il faut faire un module intermedaire qui determine une matrice (représentant les pixels) en fonction des valeurs de jeu (ex : position de la balle, des joueurs, ...) et alors le module qui envoie le signal vga à juste à utiliser cette matrice pour determiner le signal vga à envoyer.

Ou alors est ce que c'est le module qui envoie le signal vga qui doit determiner la valeur de chaque pixels en fonction des données du jeu (interet : pas de matrice intermediaire)?

Merci :) 

Tu peux suivre l'historique du jeu vidéo

Il y a eu les sprites purs, donc pas de frame buffer pour stocker l'image, c'est assez simple : à chaque fois que l'interface vidéo envoie un pixel au moniteur, elle compare la position du pixel courant aux positions des divers sprites (raquette, balle, etc) et sort la bonne couleur. Une version plus évoluée (type borne d'arcade) gère beaucoup de sprites graphiques, superposés à un frame buffer. Chaque sprite peut avoir sa propre palette, ou pas. C'est des sprites hard (car gérés directement par le hard).

Pour un affichage texte style PC qui boote, c'est la même chose, la mémoire vidéo contient des caractères, et les valeurs des pixels sont chopés dans une mémoire qui contient la police de caractères, lors du balayage.

Après il y a le framebuffer, donc une mémoire vidéo qui contient la couleur de chaque pixel affiché, soit sous forme de code qui indexe une palette (genre 16 ou 256 couleurs) soit directement la couleur (genre 16 ou 24 bits)...

Pour faire des animations avec un framebuffer, il faut un blitter, c'est du hard qui va copier/coller rapidement un bout de graphique (on va appeler ça un sprite soft) quelque part dans le frame buffer, par en gérant la transparence, etc. Après il y a le problème de l'image suivante quand le sprite bouge, soit on restaure le fond qui était derrière, soit on recopie le fond en entier et on re-blit tout.

Par exemple, un méga classique :

http://www.youtube.com/watch?v=QQshLOXWiGM#t=3m

Le matos de l'époque :

un peu de technique :

http://cgfm2.emuviews.com/txt/s16tech.txt

Ce genre de hard essaie de sortir les graphismes les plus impressionnants possibles en tenant compte des limitations de l'époque... Ça date de 1986 ! Il y a très peu de RAM et le CPU est peu puissant, c'est similaire à ton FPGA en fait, mis à part la fréquence...

V'là les specs :

• Main CPU : MC68000 @ 10 MHz
• Sound CPU : Z80 @ 4 MHz
• Video resolution : 320 x 224 (vertical)
• Colours : 4096
• Board composition : CPU board + Video board
• Hardware Features : 128 Sprites on screen at one time, 2 tile layers, 1 text layer, 1 sprite layer with hardware sprite zooming, translucent shadows

En gros, il n'y a pas de frame buffer. 

Tu as 2 couches de tiles, des blocs de 16x16 (je crois) qui sont gérées comme l'affichage texte sur un PC. On a une RAM qui contient les N° de blocs, qui indexent une ROM qui contient les graphismes des blocs. Une couleur est transparente, pour superposer les 2 plans de tiles (d'où le scrolling sur 2 plans).

1 couche de texte, même système.

Par-dessus tu as une montagne de sprites hard. En gros tout ce que le cpu a à faire pour afficher un sprite est de positionner dans les registres du hard, la position, la taille, et l'adresse des données graphiques ... c'est tout. Il n'y a pas de copie des données du sprite.

De nos jours les débits mémoire sont tellement énormes qu'on utilise des sprites soft, qui sont copié.

Mais comment ils faisaient en 1988 pour mettre 1000 boulettes à l'écran avec du hard qui gère que "128" sprites ? Facile, on trie les boulettes suivant la coordonnée Y, et on a une interruption cpu (ou du hard) qui met à jour les données des sprites au fur et à mesure de l'affichage pour "recycler" le hard qui affiche les sprites et l'utiliser plusieurs fois par image...

Le hard peut aussi gérer les collisions : puisque le hard qui affiche les sprites "sait" pour chaque pixel, tous les sprites qui se superposent sur ce pixel, la collision au pixel près de tous les sprites affichés est quasiment gratuite (il faut juste définir des groupes susceptibles d'entrer en collision, genre tirs des 2 joueurs, 2 joueurs, ennemis, boulettes).

-
Edité par Lord Casque Noir 18 octobre 2013 à 12:15:32

Super, encore merci pour cette très bonne explication

Bon je crois que je vais faire un truc à base de spirit hard car de toute facon j'ai pas de processeur (je vais faire mon jeu uniquement en hard comme mon space invaders sur logisim http://www.youtube.com/watch?v=NTRNczisCWU)

Par contre je suis pas sur d'avoir compris le role du blitter... le processeur calcul la valeur des pixels (ou au moins la position des objets) et les stockes au fur et à mesure dans la ram, et régulierement le blitter vient recuperer ces informations dans la ram pour les mettres dans le framebuffer et le signal video aura juste à "envoyer" les valeurs du framebuffer?

Merci 

http://en.wikipedia.org/wiki/Blitter

Mettons que tu as un framebuffer (contient l'image à afficher) et un circuit vidéo qui le lit 60 fois par seconde et envoie les pixels au moniteur...

Le processeur calcule la position du sprite à afficher, puis règle les registres du blitter (adresse source, position où copier dans le framebuffer, taille, etc), le blitter (en passant par une DMA) copie le sprite dans le framebuffer, pendant que le processeur fait autre chose. Quand le blitter a fini de copier, il peut déclencher une interruption pour que le cpu lui envoie un nouveau bloc à copier, ou se servir dans une liste.

Avantage du blitter : circuit assez simple, il n'y en a qu'un qui sert pour tous les sprites, copie plus rapide que le cpu, pas de gaspillage de cpu pour copier des pixels. Si ton framebuffer est structuré d'une façon assez compliquée (genre 16 couleurs, 4 bits par pixels, au lieu de 1 octet) copier des sprites au cpu est très lent (il faut faire des décalages de bits, et pas simplement une copie) donc avantage au hard. Un blitter peut aussi tracer des lignes, etc.

Inconvénients : gros consommateur de bande passante mémoire (les données doivent être lues puis écrites), déplacer un sprite suppose de l'effacer à son ancienne position, les scrollings différentiels imposent de copier l'écran en entier, il faut 2 framebuffers, l'un est affiché pendant qu'on travaille sur l'autre, etc.

Pour un space invaders sur fpga, des sprites hard sont bien plus avantageux...

Si tu as besoin d'un petit cpu, tu peux trouver du core 68000, Z80 ou autres fossiles sur opencores.

Merci beaucoup :), je vais donc rester sur des sprites hard

Je pense faire (en tout cas bien commencer) mon pong sur fpga demain, mais cette semaine j'ai améliorer mon space invaders sur logisim... http://www.youtube.com/watch?v=D767mPUx0sw le jeu reste encore perfectible (notamment ennemies mobiles), mais j'ai, entre autre, ajouté un menu graphique au jeu et je suis assez content du résultat

-
Edité par far38 25 octobre 2013 à 14:26:54

Salut, je viens de finir mon pong sur fpga :) http://www.youtube.com/watch?v=f3UjWUVamL4

<p "><span ">Bon il est loin d'être parfait, mais c'est mon premier dev en verilog et je l'ai fait en 24h 

En tout cas merci pour votre aide depuis le debut de ce topic

Pas mal !

Un gars bien à fond a recréé un pong à partir du schéma "vintage" :

http://imgur.com/a/TUGto/layout/blog

schéma en PDF : http://atarihq.com/danb/Pong.shtml

impressionnant mais bon, le FPGA est tout de même moins fatigant !

Ah ouais enorme! avant de m'acheter un fpga je voulais faire ca : faire un shema sur logisim et le réaliser "en vrai" avec de vraies portes portes logiques mais bon je m'y connais pas trop en PCB et acheter plusieurs breadboard revient vite assez chers...

en plus bon, 50 circuits logiques sur une grosse plaque, c'est pas le truc le plus évolutif ni le plus facile à debugger...