Bregalad

Je ne comprends pas bien ta question, mais la SNES est capable de gérer jusqu'à 128 sprites à la fois donc tu ne devrais pas avoir de problèmes de ce côté là. Il te faut juste préparer les données à envoyer dans l'OAM (il y a un buffer de 256 bytes (2 par sprites) et un deuxième buffer de 32 bytes (2 bits par sprite)) et l'envoyer par DMA au momment du VBlank dans ta routine de NMI. Je te conseille de faire une routine qui s'appelle un truc du genre "DrawSprite" qui va le rajouter dans la file des objets à envoyer à l'OAM et augmenter l'index pour le prochain sprite. Lors du VBlank tu envoie toutes les donées dans l'OAM par DMA et remet l'index à 0. Le jour ou tu fais un jeu plus compliqué ou la priorité entre les sprites est important il faudra en tenir compte. Ah aussi "sprite" et "objet" c'est exactement là même chose, même si deux termes sont confus et pourraient désigner de nombreuses choses différentes dans le moteur de jeu.

Cool comme idée mais tu sembles oublier qu'il serait impossible d'émuler ceci sans fabriquer son propre émulateur. De plus le Super FX est suffisament puissant, la seule limitation est la vitesse du DMA de la SNES qui ne permet par exemple pas au Super FX de faire tout l'écran en 256 couleurs ! Ce dernier en serait capable, mais il faudrait presque 1/3 de seconde pour rafraîchir l'écran.

Oui j'ai déjà lu cela plusieurs fois et honnêtement je n'ai pas tout compris mais c'est pas grave, j'ai déjà quelques meilleures idées sur le fonctionnement global du chip. Quand à faire un super jeu homebrew qui l'utilise honnêtement ça serait cool mais pas pour demain !! Il me faut déjà en faire sur NES et sur SNES "standard". D'après ce que j'ai compris, les jeux s'arrangent pour que ente la ROM et la RAM présentes sur la cartouche, le CPU de la SNES utilise l'un pendant que le Super-FX utilise l'autre et il n'y a jamais confit mais je ne suis pas sur. Ca me semble logique de télécharger le programme du Super FX (qui consiste que en parties de communications et des routines faisant des calculs graphiques) dans la SRAM et de garder le programme principal (beaucoup plus conséquent) en ROM. Après bien entendu si le jeu lague il peut devenir intéressant d'utiliser le Super FX pour accélérer le moteur du jeu mais bon ça doit pas être trivial à faire. (Et il y a encore le SPC700 en plus de tout ça).

HDMA power ;) Tu as utilisé les photos pour les graphismes ? Idée intéressente ! Honnêtement le rendu n'est pas terrible mais il faudait avoir la photo originelle pour pouvoir vraiment dire. Et ouais cette démo Walker c'est la base de tout quand même pour essayer les possibilités de la SNES en un clin d'oeil rien de tel.

Il y a déjà un autre jeux qui à été dumpé avec le même mapper ? Si non tu peux dumper le jeu mais aucunne chance qu'un émulateur puisse le faire fonctionner sans que tu reverse-engineere le mapper, lui attribue un numéro officiel et convainc les auteurs d'émulateur à l'implémenter.

La foto n'est pas de bonne qualité alors je ne vois pas grand chose, mais en il semble il y avoir 3 grosses ROMs ?

OK donc a ce que je vois le Super FX est un processeur normal qui fonctionne en parallèle tout simplement. Il peut exectuer des programmes depuis la ROM et la RAM de la cartouche et sa propre RAM cache (mais comment peut-il executer un programme depuis la ROM et la RAM alors que la SNES l'utilise déjà ? Technique de bus partagé et accès entrelacé ou il y a une ROM dans le chip lui-même ? mystère total). Il a une puissance de calcul élevée, et à des instructions "COLOR" et "PLOT" qui permettent de créer un bitmap très rapidement, qui est convertit automatiquement en tiles 2BP, 4BP ou 8BP, et une fois fait le bitmap est envoyé à la SNES par DMA. Star Fox réduit la taille de l'écran verticalement pour pouvoir faire plus de DMA et rafraichir l'entier des tiles de l'écran le plus rapidement possible. Il ne fait donc rien d'autre que d'accélérer ce que le CPU de la SNES pourrait faire tout seul : En effet pour appliquer des transformations linéraire genre mode 7 sur les sprites, j'ai fait un test sur NES il faut genre 2 secondes (100 frames) pour calculer un sprite de 643x64 pixels (sans trop optimiser mon code cependant). La SNES étant que 3 fois plus rapide que la NES, il faudrait environ 30 frames pour calculer une telle image, alors que dans Yoshi's Island le super FX le fait en quelques fractions de secondes, permettant d'avoir de nombreux sprites "genre mode 7" comme la GBA. En reprogrammant tout ça pour un RPG on pourrait avoir un jeu avec des graphiques genre Golden Sun sur la SNES ce qui serait formidable !!

Pour le format iNES, il te faut mettre 16 bytes de header, les donées dans le PRG-ROM puis à la suite s'il y en a les données dans le CHR-ROM.

Dans l'absolu il n'y a pas besoin de la déssouder s'il n'y a que la/les ROM sur le PCB. Tu peux toujours souder des fils par dessus les pins et les planter dans ton programmeur en lui faisant croire que tu as mis une EPROM normale. Par contre s'il y a d'autres circuits pour le bankswitching (ce qui est le cas à coup sur) ça ne peux pas fonctionner comme ça.

Pour les brevets (enfin le brevet car il me semble que c'est 3 fois le même) c'est pas vraiment des explications très limpides mais bon au pire c'est déjà ça. Le debugger est cool c'est une bonne trouvaille. Sinon oui ça serait intéressant de voir les sources de SNES9x et/ou de ZSNES si elles sont commentées.

Je suis curieux de savoir comment ce processeur fonctionne. Simplement voilà après de très nombreuses recherches sur internet je ne trouve que des informations non-technique (comme "Le super FX permet à la SNES de faire des graphiques 3D pleins de polygones") ou des information peu techniques (comme "Le super FX tourne à 20Mhz ce qui est énorme et permet aux jeux d'avoir des graphiques plus perfectionnés par exemple utiliser des polygones faire des graphiques 3D"). Mais ceci ne m'intéresse pas, ce qui m'intéresse c'est de savoir comment il fonctionne qu'est ce qu'il y a dans ce chip, comment celui ci prépare des graphiques étendus et comment la Super NES utilise ceux-ci. En fin de compte je me demande s'il existe une démo amateur démontrant les capacités du circuit, ou tout du moins de savoir comment en faire une. Mais là encore zero information sur ce circuit (il y a cependant des infos respectables sur le DSP-1 et le Cx4 ce qui est déjà ça). D'après ce que j'ai compris : - Le super FX est un processeur RISC (un peu comme un PIC) qui a de la mémoire cache et des DMA. - Il est possible pour la SNES d'adresser directement une partie de la mémoire partagée avec le Super FX ce qui lui permet de faire des DMA directement du super FX dans la VRAM - Le super FX ne permet en aucun cas d'accroitre les possibilités graphiques de la NES d'un point de vue technique. Il permet simplement de faire des calculs beaucoup plus rapidement et, utilisé pour les graphiques, il permet à la SNES de redéfinir son tileset intégralement chaque frame. Comme un background permet l'utilisation de 1024 tiles à la fois et que l'écran fait 1024 tiles, ceci permet de simuler un mode "bitmap". Maintenant ce que je suis nettement moins sur : - Il est possible d'écrire son propre programme pour le Super FX ?? - Il y a déjà des fonctions écrites dans le chip pour l'accélération graphique ?? - Le temps de VBLank de la SNES ne permet que de faire 6ko de DMA, ce qui correspond à 192 tiles en 4BP. Il faudrait alors 6 frames pour rafraichir tout l'écran ? Encore une fois il y a zéro info dispo à part la doc "officielle" de Nintendo qui est extrèmement peu précise et floue donc tout plus serait le bienvenu.

C'est marrant moi des walker demo j'en ai fait une chiée de versions différentes pour essayer le mode 7 et des boites de dialogues de toutes sortes. Je pensait faire des jeux homebrew SNES un jour mais d'abord en faire sur NES (et je n'avance pas beaucoup malheureusement). Pendant qu'on y est je poste le lien si ça intéresse quelqu'un. http://jonathan.microclub.ch/dummy/test.fig http://jonathan.microclub.ch/dummy/test2.fig http://jonathan.microclub.ch/dummy/test3.fig http://jonathan.microclub.ch/dummy/top.fig http://jonathan.microclub.ch/dummy/top2.fig http://jonathan.microclub.ch/dummy/top3.fig http://jonathan.microclub.ch/dummy/top4.fig

J'ai essayé de dumper Adventure Island une fois et ça n'a pas marché j'ai pu dumper que la moitié de la ROM. Il a 32k de PRG et 32k de CHR, et les EPROMs sont des pinouts standard, et comme je les avais de toutes façons désoudées pour me faire une cartouche reprogrammable et que les 2 chips étaient encore dans un état plus ou moins fonctionnel, j'ai essayé de les dumper avec mon super-programmateur mais j'ai eu un peu de peine à faire que il reconnaisse les ROMs. Pour finir j'ai pu dumper les derniers 16k pour les 2 je crois. Pour un jeu plus large il te faudrait souder des fils à chaque patte de la ROM, et les insérer dans le programmeur dans le bon ordre pour que ça corresponde à l'EPROM standard de la même taille. Bien entendu si le jeu est fait avec des bulles d'epoxy tu peux directement oublier.

Pas vraiment à mon avis... Il n'y a jamais besoin de plus que 2 EPROMs, qui sont toujours de taille raisonnable et très commodes à trouver, et il y a rarement plus que 3 fils a ajouter + 3 traces à couper (il suffit de ne pas se planter). Le seul problème est que pour pourvoir développer avec un mapper rare il faut le jeu original qui a un mapper rare à sacrifier. Ce n'est pas vraiment une "difficulté", mais plutôt une contrainte facheuse.

Voici plus de détails : http://nesdev.parodius.com/bbs/viewtopic.php?t=4652

Pour les cartouches NROM qui n'ont aucun mapper le pinout des ROM est standard il ne faut donc faire aucunne modif (c'est le cas pour toutes les ROMs <64ko faites par Nintendo également même s'il y a un mappeur).

OK il faudra que j'essaye le truc de la gomme et de voir ce que ça donne. Si ça marche 9 fois sur 10 ça découle déjà du miracle (en général c'est plutot 1 fois sur 10).

Oui le jeu ressemble au seul jeu famicom que j'ai donc il a l'air assez authentique. Mais on ne peut même pas télécharger la ROM donc c'est assez nul... J'ai entendu dire qu'il distribuent les sources et qu'elles ont été brouillées exprès pour que ce ne soit pas possible de recompiler.

Tu est sérieux ? Le coup de la gomme j'ai jamais essayé car je me suis dit que ça devait être pour les gens qui n'ont vraiment pas de matériel a disposition et ça ne m'a pas l'air sérieux car la gomme laisse facilement des petits chenits qui pourrait empirer la connexion. J'ai aussi entendu dire que c'est pas une bonne idée de souffler mais si tu fais attention de ne pas cracher d'eau dessus ça devrait aller... pour moi c'est ce qui fonctionne le mieux (j'ai aussi un dé-oxidant pour contacts électrique qui fait des merveilles). Le papier de verre honnêtement je pense que c'est le meilleur moyen de détruire les cartouches ! Les contacts sont en cuivre plaqué or. L'or soxyde peu, mais si tu le gratte avec du papier de verre il ne restra plus que le cuivre qui fait bon contact dans un premier temps mais après quelque temps ça devient du vert-de-gris et alors là ça ne doit vraiment pas être terrible. Pour moi une NES ou on peut planter les jeux dedans, on allume et ça marche du premier coup découle de la science-fiction. Peut-être que les NES2 ont une meilleure mécanique, mais elle n'est pas sortie en europe je crois.

Si la LED clignote c'est à cause du CIC qui fait un reset toutes les secondes s'il n'y a pas une cartouche intérée avec un autre CIC (ou si il y a mauvais contact). Ne t'inquiète pas ta NES fonctionne certainement encore mais le connecteur est vraiment horrible, même avec un NES en parfait état que j'utilise règulièrement et ou j'ai reserré toutes les broches pour qu'elles griffent mieux les cartouche il me faut essayer chaque jeu en moyenne 16 fois avant que ça fonctionne et après encore 10 fois pour qu'il n'y ait plus de bugs à l'écran. Tu peux essayer de souffler sur les cartouches, l'alcool, etc... mais il n'y a rien à faire c'est toujours comme ça.

Intéressant... Je pense qu'il est très probable que les jeux de Koei (Romance of the 3 Kingdoms, etc...) n'ont pas été codés en assembleur. Ils sont très complexes au niveau du CPU et sont portés sur un grand nombre de plateformes indépendamment. Sinon oui c'est bien possible que tous les jeux SNES soient fait en assembleur même si ce n'est ni le plus pratique ni le plus rapide au développement c'est le plus optimisé.

Oui c'est plus ou moins normal jusqu'à un certain point. Le pire c'est que la plie du C est adressée en mode indirect (par example sta [stack],Y), et le pointeur "Stack" est constamment ajusté ainsi que Y pour lire toutes les variables locales, c'est très lent et inneficace, mais ça permet d'avoir des variables locales ce que l'assembleur ne permet pas. J'ai du tracer de très nombreux bugs dus à des conflits de variables en programmant sur NES et c'est vraiment pénible à trouver et a corriger. Il serait surement possible d'optimiser un compilateur pour faire du code plus rapide et compact, mais ce serait une tâche hardue. Qu'en sais-tu, as obtenu un kit officiel de Nintendo ?

C'est vrai tu as essayé ? Je pense que les routines importantes comme les interruptions, le moteur graphique et le moteur son doivent de toutes façons être codées en assembleur pour être optimal et ne pas être top lentes, mais pour le moteur du jeu et tout il serait peut être préférable de le faire en C pour plus de portabilité et un maintien facilité du projet. J'aurais voulu étudier s'il serait faisable de modifier CC65 pour qu'il puisse adresser la pile du C en mode indexé (lda Pile,X) au lieu de indirect (lda [stackPtr],Y) ce qui est terriblement lent et inoptimal. Bien sur la pile serait limitée à 256 bytes pour le 6502, mais pas pour le 65816 si X est en mode 16-bits.

Ah c'est bon à savoir qu'il à été fait en C. C'est probablement une des raisons pourquoi le projet a fonctionné... Il est possible de programmer la SNES en C (j'ai vu ça quelque part), et même la NES aussi mais il faut d'abord trouver quelqu'un qui puisse refaire entièrement les librairies de CC65 pour NES et qui modifie les sources du compilateur pour les rendre plus efficaces sur NES.

C'est que j'ai pas vraiment la place pour une console de plus, surtout pour un seul jeu. Vous devriez faire un port sur NES ou Super NES à mon avis, ça touchera beaucoup plus de monde ;) (moi parmi de nombreux autres)