Re: Mr ToutLeMonde et la programmation NES...

[upsilandre]

nan jamais testé. T'es partie sur une configuration MMC3?

[vincent2105]

Disons que j'avais suivi des tutos pour le MMC1, mais j'étais curieux de voir comment pouvait fonctionner un scrolling avec parallaxes donc j'avais bifurqué vers le MMC3 juste pour ça.

[upsilandre]

De toute facon IRQ ou pas il faut miser sur le MMC3 je pense, notamment pour sa granularité au niveau du bank switching de la CHR-ROM.
Le MMC3 peut bank switcher des bank de 1Ko de CHR-ROM alors que le MMC1 c'est 4Ko (donc un tileset complet) et ca change tout (je parle dans le cas d'une configuration CHR-ROM) car avec cette granularité de 1Ko tu peux alors utiliser le bank switching de la CHR-ROM pour modeler ton tileset selon tes besoins (par exemple modifier seulement une partie du tileset des sprites pour remplacer un ennemi par un autre sans pour autant devoir aussi switcher le tileset de ton perso qui lui reste toujours le meme) donc t'as un bien meilleur controle sur ton tileset, pas autant qu'avec de la CHR-RAM qui permet de construire ton tileset sur mesure, mais bien plus rapidement (puisque les modifications du tileset sont alors instantané grace au bank switching) du coup ca permet aussi de faire tres facilement des animations de background ou des animations de sprites plus riche et ainsi exploiter l'un des plus gros atout de la NES.
Avec une granularité de 4Ko t'as aucun controle sur ton tileset (tu changes tout ou rien, y a pas d’intermédiaire) , Tu peux pas le découper en plusieurs morceau independant. Du coup l'utilisation de CHR-ROM devient un mauvais choix qui implique énormément de gachie.

Y a beaucoup de configuration de cartouches sur NES mais en gros t'as 2 configurations assez typique, les plus frequentes.
-- Les configurations 128Ko PGR-ROM + 8Ko CHR-RAM et un mapper MMC1 (ou UNROM)
-- Les configuration 128Ko PGR-ROM + 128Ko CHR-ROM et MMC3
La configuration CHR-ROM + MMC1 est une mauvaise combinaison (mais qui a quand meme ete utilisé parfois).

Sur NES y a eu une premiere phase avant les mappers ou les cartouches etaient alors exclusivement avec de la CHR-ROM.
Puis une seconde phase avec les mappers type UNROM et MMC1 ou la les cartouches sont passer presque essentiellement a une configuration CHR-RAM.
Et une troisième phase avec l'arrivé du MMC3 ou la CHR-ROM est alors revenu en force (sans pour autant eclipser totalement la configuration CHR-RAM qui a d'autre avantage mais presque).

[vincent2105]

Merci pour toutes ces infos   
Effectivement, y'a pas photo... Juste une petite rectif, d'après le Wiki c'est 2*2K et 4*1K.  Mais ça laisse quand même entrevoir un tas de trucs sympas ! Et j'imagine qu'utiliser les 4*1K pour la gestion des sprites, ca doit bien faciliter les choses... En fait, banswitcher les frames d'animation, c'est une chose à laquelle je ne pensais pas...
Bref, ca veut aussi dire qu'il va falloir que je scinde mes tilesets, donc un mini script en python à prévoir. 
C'est de bon augure tout ça  

[upsilandre]

Oui c'est ca.
La granularité 1K est quasiment tout le temps utilisé sur le tileset des sprites. C'est quasiment indispensable pour gérer le tileset des sprites, c'est vraiment la que la granularité 4k du MMC1 pose de gros probleme.
Généralement c'est 1k réservé pour le sprite du joueur avec bank switching dynamique pour étendre a plusieurs ko le sprite du joueur sans bouffer tout le tileset (il sagit pas tant d'utiliser le bank switching pour l'animation des frames du perso, ca va etre plutot: une bank pour les animations du perso quand il est debout, une bank pour les animations du perso quand il est en l'aire, une bank pour les animation du perso quand il est accroupi ou accroché au décors...). 1k pour les differents projectiles/pouvoir/bonus et qui est fixe et la meme bank durant tous le jeu (pas de switching) puis les 2 derniers Ko pour stocker chacun un ennemi (une seul bank 1k par ennemi qui contient toutes ses animations) et qu'on switch chaque fois qu'on a besoin de remplacer un ennemi par un autre.

Du coté background le tileset est donc en général divisé en 2. 2Ko propre a chaque level (qui switch entre chaque level) qui lui donne son identité visuel puis un second pool 2Ko qui lui contient une bibliothèque de tiles animés (en général en 4 frames donc 4 bank successive de 2ko) et qui va etre partagé par plusieurs levels (voir partagé par tout le jeu mais en général t'as pas plus de 2 ou 3 pools de ce genre dans les jeux les plus gourmand en tiles animés), le jeu pioche dans cette bibliothèque globale d'objet animé selon ses besoins (Et en utilisant des frequences de bank switching differente selon l'objet animé utilisé).

[vincent2105]

Effectivement, ca parait plus logique de bankswitcher en fonction de l'état du perso. Merci encore pour toutes ces explications.
Du coup , j'ai une question, pour le bankswitch de PRG ROM, j'imagine que tu as pu dégager une tendance quant aux différentes utilisations non ? On a une bank fixe de 16Ko et 2 de switchables de 8Ko c'est ça ?

[upsilandre]

Effectivement, ca parait plus logique de bankswitcher en fonction de l'état du perso.

Dans Batman Joker ils utilisent le bank switching quasiment pour chaque frame d'animation mais c'est parce que le sprite est exceptionnellement gros (jusqu'a 28 tiles ou 14 sprites 8x16) et que le jeu utilise le bank switching a l'extreme meme sur le décors.

Du coup , j'ai une question, pour le bankswitch de PRG ROM, j'imagine que tu as pu dégager une tendance quant aux différentes utilisations non ? On a une bank fixe de 16Ko et 2 de switchables de 8Ko c'est ça ?

Ca c'est la configuration MMC3 mais les tendances d'usage je sais pas, c'est beaucoup moins visible que le switching du CHR-ROM que tu peux pas rater. Du flagrant delit de bank switching c'est beau.

[vincent2105]

Whaou ca pulse !!!  Terrible !

[vincent2105]

Avec le PPU viewer ouvert à côté de l'émulateur, on découvre vraiment le jeu avec un autre regard... 
La je suis sur Batman, au passage j'ai compris uniquement grâce au PPU viewer que certains sprites étaient composés de tiles de background, et donc que les sprites étaient en 8*16... C'est très instructif et ludique d'une certaine façon :p 

Je ne connais pas bien la ludothèque de la NES, tu connais des jeux  qui exploitent à fond le bankswitching de CHR' et qui pourrait coller avec un univers médiéval ? (Histoire de pouvoir repomper des anims de tiles si je devais me lancer plus tard dans quelquechose d'un peu plus approfondi).

[upsilandre]

En medieval y a les 3 Wizzards&Warriors mais c'est chaque fois de la CHR-RAM.
Sinon y a Sword Master (CHR-ROM + MMC3) ou ils utilisent le bank switching pour simuler un second plan



Sur Batman ca sert aussi bien a animé le decors que pour faire des effets de parallaxe mais caché derriere un decors et donc impossible a faire avec du H-scroll

Et ici c'est deja du bank switching a frequence elevé (30hz)


Sur Metal Storm ils utilisent carrement des animations de tiles sur des cycles de 32 frames (le max que je connaisse) et sur 2 bank donc 128 tiles (soit 64Ko de CHR-ROM dédié uniquement au animation de tiles, c'est enorme) et ce long cycle de 32 frames leur permet de simuler un second plan (voir 3 plans) sur des patterns assez grosse (32x32), sur ce jeu ils ont eu cette obsession de simuler plusieurs plans, c'est le gimmick du jeu (qui n'empeche pas le jeu d'avoir un gameplay particulièrement soigné). Et la aussi c'est de la haut frequence de switching (45hz)





Sur Crisis Force ils en utilisent beaucoup aussi principalement pour simuler des parallaxes verticales (impossible autrement) ou un second plan et avec du bank switching jusqu'a 60hz cette fois (j'en connais pas d'autre). Comme pour Metal Storm ils y consacrent 2 bank (128 tiles) mais des cycles de "seulement" 16 frames (ce qui est beaucoup) donc 32Ko de budget de CH-ROM pour ces animes (mais y a aussi 2x moins de CHR-ROM que Metal Storm donc ca reste proportionnellement le meme budget). J'aime bien ce shooot, on dirait du shoot PCE et du scrolling vertical en full screen comme ca c'est parfait sur NES avec ses 240 lignes.



Mais classiquement le bank switching est utilisé plutot de cette facon, pour rendre le decors moins statique en animant quelques elements

Tres bon usage, sans excès.


Mais faut pas croire que le bank switching de CHR-ROM c'est la panacé. Y a des truc que tu ne peux faire qu'avec une configuration CHR-RAM. Mon exemple préféré c'est Battletoads.

Ils simulent un second plan avec une grosse pattern 32x32 exactement comme pour Metal Storm sauf qu'eux le font en scrolling multidirectionnel ce qui du coup n'implique pas 32 versions de la meme pattern mais 32x32= 1024 versions et comme le bank switching a une granularité de 1Ko au mieux ca veut dire 1024 bank soit 1Mo de CHR-ROM pour pouvoir faire cette effet sur un scrolling multidirectionnel du coup c'est impossible avec cette methode.
Leur solution c'est de ne pas utiliser de pattern pré-shifter mais de shifter les patterns en temps réel en RAM avec le CPU et ensuite d'aller les placer au bon endroit dans le bon ordre dans la CHR-RAM. Et faire ca sur 16 tiles, bravo.


Micromachine reprend ce principe de shift en temps réel mais avec seulement 2 tiles (et sur un seul bitplan puisque c'est du monochrome, en plus la pattern checkboard permet peut etre des astuces) mais ca suffit a donner quelque chose de tres chouette avec peu de ressource. Ca serait absurde de vouloir faire la meme chose en CHR-ROM.

[Invité]

Super intéressant Upsilandre !


Et comme c'est toujours enrichissant de suivre tes avancées Vincent !
Merci à vous deux.

[vincent2105]

Merci pour ton soutien Vetea, ca fait toujours plaisir à entendre

@upsilandre, quand tu parles de frequence de bankswitching, je suis pas sur de comprendre... 
à 30Hz, c'est 1 frame sur 2 donc 30 fois/seconde
à 60Hz, c'est à chaque frame donc 60 fois/seconde
c'est ça ? Ca me parait énorme, j'arrive pas à réaliser... Ca concerne quel élément du background ?

J'aurais surement d'autres questions concernant ton post. Dans tous les cas, je suis bien content d'avoir croisé ton chemin :)

[upsilandre]

@upsilandre, quand tu parles de frequence de bankswitching, je suis pas sur de comprendre... 
à 30Hz, c'est 1 frame sur 2 donc 30 fois/seconde
à 60Hz, c'est à chaque frame donc 60 fois/seconde
c'est ça ? Ca me parait énorme, j'arrive pas à réaliser... Ca concerne quel élément du background ?

Oui c'est ca. Pour les sprites ou animer les elements de décors c'est sur que 10 ou 15fps ca suffit, mais quand il sagit d'utiliser le bank switching pour simuler du scrolling alors ca demande des frequences plus elevé. Par exemple sur Crisis Force on voit un background qui scroll a 2 pixels/frames donc pour simuler une parallaxe vertical plus lente a 1 pixels/frames tu vas faire une animation de tile qui simule un scrolling a 1 pixels/frames en sens inverse (2 - 1 = 1). et la t'as pas le choix, faut faire ton bank switching a 60fps pour que ce soit propre mais de toute facon bank switcher a 2hz ou 60hz c'est pareille, c'est gratuit.

[upsilandre]

Super intéressant Upsilandre !

J'ai surtout la passion du gif
Je trouve ca dommage d'ailleurs que ce soit pas plus utilisé sur les forums retro. Le gif c'est parfait pour le retrogaming. La resolution des jeux retro est parfaitement adapté aux gifs et permet de préserver la resolution native, la contrainte de 256 couleurs est aussi tres bien adapté et c'est une compression lossless sans perte et surtout on peut animer a 60fps (plutot 50fps puisque l'unité est en centiemme de seconde) et meme si aujourd'hui le 60fps en video devient plus courant ca n'a pas toujours ete le cas et surtout la compression video detruit pas mal d'information quand les changement sont trop rapide, notamment certain effet de flickering qui passe pas, en gif y a pas de compression de l'animation, on perd aucune information.
Le gif permet d'avoir de vrai petit echantillon de jeu animé de facon totalement pixel perfect (que ce soit au niveau de l'image ou de l'animation). Et c'est tout un art (ludique) de chercher parfois des cycles pour faire un beau gif (ce que permet pas mal aussi le jeu retro)




Sinon en bank switching de CHR-ROM il existe aussi le bank switching de tilemap grace a Sunsoft qui avait fait un mapper dédié pour After Burner. Le cablage particulier du port cartouche de la NES et de sa VRAM (notemment pour permetre a la cartouche de gérer le mirroring de la VRAM et donc la configuration de la tilemap en double screen  vertical ou horizontal) a permit cette bidouille et proposer alors une cartouche avec 128Ko de tilemap directement en CHR-ROM et le PPU va directement se servir dans la CHR-ROM autant pour le tileset que pour la tilemap (mais du coup elle sont brute, on peut pas les compresser, meme pas au format metatile ce qui n'est pas tres optimal)
Ca permet ca:

[Invité]

énorme pour de la nes 

dans le meme genre j'avais particulierement apprécié 3D WORLD RUNNER.

(a 23 minutes) le trick de jouer sur les hauteurs de certains objets pour amplifier l'impression de relief, c'est de toute beauté


sorry si c'est un peu offtopic, mais quels sont selon toi les 10 jeux nes qui défoncent le plus techniquement?

[upsilandre]

Ce que j'aime bien dans Worldrunner c'est que tu peux en plus activer la 3D stereoscopic en appuyant sur select, ca marche avec des lunettes anaglyphe en carton.
une video 60fps rend plus honneur au jeu.
https://youtu.be/XMJe9g_iTeE

Pour les effet de perspective en line-scroll comme celui la ou comme Rade racer (le meme studio) la NES c'etait cool car sa tilemap qui fait 2 screens de large ca aide (sur SMS tu scroll sur une tilemap mono-screen) les effets de perspective de Space Harrier ou Outrun sur SMS sont moins bien reussit, moins fin et fluide, meme si on peut sans doute faire mieux.

[vincent2105]

Sinon en bank switching de CHR-ROM il existe aussi le bank switching de tilemap grace a Sunsoft qui avait fait un mapper dédié pour After Burner. Le cablage particulier du port cartouche de la NES et de sa VRAM (notemment pour permetre a la cartouche de gérer le mirroring de la VRAM et donc la configuration de la tilemap en double screen  vertical ou horizontal) a permit cette bidouille et proposer alors une cartouche avec 128Ko de tilemap directement en CHR-ROM et le PPU va directement se servir dans la CHR-ROM autant pour le tileset que pour la tilemap

Là, je saisi pas non plus du premier coup.
Il y a 128 Ko de CHR ROM, ok, mais c'est à répartir à la fois pour le tileset et la tilemap non ? Si on utilise 128Ko pour la tilemap, il ne reste rien pour le tileset.

[upsilandre]

After Burner c'est 256Ko de CHR-ROM donc moite-moite.
Du coup comme pour le tileset ca rend les tilemap facile a trouver et identifier. Rien qu'en ouvrant la ROM dans un un editeur hexa (reglé sur 32 octet de large) tu reconnais les tilemap.






Ensuite un simple bank switching permet de changer 2Ko de tilemap (c'est principalement des tilemap double-screen) instantanément.
La force de la NES c'est ce cablage du port cartouche qui fait passer les bus du PPU. En jouant juste sur le mapping mémoire ca permet plein de bidouille comme transformer la tilemap horizontale en tilemap verticale (le mirroring) ou carrement avoir une tilemap 4-screens si t'ajoute 2Ko de RAM dans la cartouche (Gauntlet, rad racer 2) ou avoir 2 tilemap mono-screen indépendante et pouvoir switcher de l'une a l'autre pendant l'affichage (utile pour pas mal d'effet ou simplement avoir un HUD en bandeau + un scrolling vertical) et bien sure le bank switching de tileset (et de tilemap meme si ca concerne qu'un seul jeu). Tu peux pas faire ces choses la sur SMS car le cablage du port cartouche ne concerne que les bus CPU.

Le seul defaut du cablage du port cartouche c'est a mon avis de pas avoir penser a faire passer aussi le signal de Vsync du PPU, du coup les mapper comme le MMC3 qui ajoute un compteur de scanline ont du ruser. La sequence d'affichage d'une scanline est une séquence reglé comme une horloge (le PPU va fetcher en alternance des patterns et des attribut de la tilemap, ce va et vient entre ces 2 sources fait switcher 42 fois par scanline la derniere pins d'adressages du PPU.) et qui se repete a chaque ligne, le mapper reconnait la sequence. Et donc encore une fois c'est grace au passage du bus PPU dans le port cartouche qu'on peut ajouter cette fonction.

[vincent2105]

Je deviens boulimique de toutes ces infos ! Mais va falloir que je trouve le temps de pratiquer...
J'ai un regret, c'est qu'un programme utilisant ce "mapper 068" ne fonctionnera pas sur mon everdrive, et voir mon programme tourner sur ma NES c'est la cerise sur le gateau. Il a l'air sympa ce mapper pourtant
Juste par curiosité, t'as déjà fait quelque chose niveau hardware ?

[upsilandre]

Non je touche a rien niveau hardware, je suis zero en electronique mais par contre j'aime bien parfois m'interesser un minimum aux shematics des machines en amateur.
Celui de la NES je l'avais bien decortiqué car c'est justement une machine tres simple et optimisé tout en parcimonie et avec un peu d'effort on peut facilement comprendre le cablage sans avoir besoin de connaissance et comprendre a quoi sert chaque petit composant (y en a pas beaucoup) et surtout j'aime bien comprendre le mapping mémoire. Si tu programmes sur NES (ou n'importe quelle machine) le premier truc que t'apprend c'est le mapping mémoire de la machine, qu'est ce qu'il y a tel ou tel adresse, les mirroring, mais c'est tres abstrait alors que ca devient tres concret quand tu regarde le cablage de la machine. Je trouve ca intéressant de mettre un peu de concret la dedans et de voir physiquement a quoi ca correspond.

D'ailleurs pour en revenir a ce que permet le cablage du port cartouche et du PPU on peut meme faire une cartouche qui contient ni CHR-ROM ni CHR-RAM et donc juste une PGR-ROM comme une cartouche Master System. Suffit de cabler la cartouche de facon a ce que le Ko superieur de la VRAM (sur lequel tu as un control individuel, tu peux couper la VRAM en 2 bank de 1Ko et les mapper differement grace au cablage) se retrouve mapper a l'adresse du tileset.
Du coup tu te retrouve avec 1Ko de la VRAM de la console qui sert pour la tilemap (donc limité en mono-screen comme sur SMS) et le second Ko qui sert pour le tileset (limité donc a 64 tuiles et qui se répète j'imagine en mirroring pour qu'ils apparaissent aussi bien du coté sprite que background)
Donc on se retrouve vraiment dans une configuration Master System mais avec seulement 2Ko de VRAM au lieu de 16Ko donc c'est tres limité comme usage, tu fais rien avec 64 tuiles (c'etait deja dure les 2 ou 3 première années de la Famicom en etant limité a 512 tuiles). Ca n'a jamais ete utilisé officiellement, juste en homebrew pour le fun avec un mini jeu (genre jeu d'echec je crois). Mais on voit toute la flexibilité du truc.

Par contre le mapper 68 pour faire du bank switching de tilemap c'est une curiosité amusante a connaitre mais je pense pas que ca soit quelque chose d'intéressant a pratiquer. Pas de regret a avoir. Un MMC3 c'est tres bien (et sinon pour partir loin dans les delires y a le MMC5 mais j'aime pas trop, je trouve qu'on s'eloigne du simple mapper et on se rapproche vraiment de la cartouche custom facon SNES mais la tu peux vraiment faire beaucoup de chose)

[upsilandre]

Mes 2 derniers gif, j'avais oublié de gifer les effets triples plan de Metal Storm, c'est réparé



Ce qui me fait rire c'est que les gars sont tellement obsedé par leur gimmick de faire des plans mutliples sur NES qu'ils n'en ont plus rien a secouer que ca n'est aucun sens d'avoir une parallaxe vertical sur un mouvement horizontal pourvu que l'effet soit réussit (et c'est vrai il est pas mal réussit celui la). Y en avait un 3eme mais qui lui etait plutot bugé au niveau du cycle.
La on est vraiment sur le genre de truc qui utilise a fond le bank switching de CHR-ROM.

[vincent2105]

Ce qui me fait rire c'est que les gars sont tellement obsedé par leur gimmick de faire des plans mutliples sur NES qu'ils n'en ont plus rien a secouer que ca n'est aucun sens d'avoir une parallaxe vertical sur un mouvement horizontal pourvu que l'effet soit réussit  

Le hardware de la NES je l'avais bien decortiqué car c'est justement une machine tres simple et optimisé tout en parcimonie et avec un peu d'effort on peut facilement comprendre le cablage sans avoir besoin de connaissance et comprendre a quoi sert chaque petit composant (y en a pas beaucoup) et surtout j'aime bien comprendre le mapping mémoire. Si tu programmes sur NES (ou n'importe quelle machine) le premier truc que t'apprend c'est le mapping mémoire de la machine, qu'est ce qu'il y a tel ou tel adresse, les mirroring, mais c'est tres abstrait alors que ca devient tres concret quand tu regarde le cablage de la machine. Je trouve ca intéressant de mettre un peu de concret la dedans et de voir physiquement a quoi ca correspond.

Pour ma part, ca me parait intéressant et surement très instructif, mais la, ca nécessite encore plus de temps et d'efforts  ... Quand je serai à la retraite peut-être 

Bon sinon, je suis en train de me pencher sur le MMC3. 

Pas de bankswitching pour l'instant, j'ai juste mis quelques banks en place, afin d'afficher un background et déjà, je m'apercois que je ne peux pas le faire n'importe comment : la bank de PRG RAM de 8ko doit être placée à la fin de la "liste" de banks et pas en début. J'ai mis un moment ...et encore, j'ai même pas compris pourquoi ca fonctionnait comme ça(mon assembleur peut-être ?).

Prochaine étape initialiser le registre à $8000 qui doit me permettre de banswitcher. Et là, après une première lecture, je trouve le wiki plutôt obscur :/ http://wiki.nesdev.com/w/index.php/MMC3

Edit : en voulant ajouter une paire de banks de (8Ko chacune) à $A000 et $8000, je me suis retrouvé avec le même problème, j'ai donc rajouté une autre paire pour arriver à un total de 4 banks de 16Ko et la ca fonctionne, apparemment, il faut que le nombre de banks soit pair. Y'a un truc qui me chagrine, c'est ma bank de PRG RAM de 8 ko que j'ai placé à la fin du programme, je pense pas qu'elle soit opérationnelle.

[upsilandre]

pourquoi tu te prend la tete avec l'extension de PGR-RAM? Tant que t'as pas saturer la RAM de la console t'as pas besoin de t'en occuper et puis la PGR-RAM elle n'existe pas dans ton fichier (contrairement a la ROM), c'est de la RAM, elle existe seulement si ton code CPU va ecrire dans cette plage d'adressage (et donc c'est seulement si tu veux declarer des variables et des labels dans cette zone d'adressage que t'as besoin d'en informer le compilateur pour qu'il fasse les bons calcules d'adressages).

C'est vrai que c'est bien de comprendre comment fonctionne son compilateur, les compilateurs assembleurs c'est des truc tres basique au final, son principale boulot ca va etre de remplacer les labels/variables par la bonne adresse et donc tout ce que tu déclare est juste la pour l'aider a bien interpreter et calculer les adresses.

[vincent2105]

pourquoi tu te prend la tete avec l'extension de PGR-RAM? Tant que t'as pas saturé la RAM de la console t'as pas besoin de t'en occuper et puis la PGR-RAM elle n'existe pas dans ton fichier (contrairement a la ROM), c'est de la RAM, elle existe seulement si ton code CPU va ecrire dans cette plage d'adressage (et donc c'est seulement si tu veux declarer des variables et des labels dans cette zone d'adressage que t'as besoin d'en informer le compilateur pour qu'il fasse les bons calcules d'adressages).

Ah bah j'ai bien fait d'en parler, la c'est beaucoup plus clair.

Je retourne sur le wiki, afin de comprendre comme initialiser puis bankswitcher. J'imagine qu'en 10 lignes c'est réglé. Mais mon utilisation du MMC1 et du bankswitching remonte a un moment maintenant, et j'avais pratiqué mais pas assez visiblement (j'avais réussi à bankswitcher des backgrounds dans une "map" de 8*8 nametables)... Autrement dit : je suis un peu à la rue

[vincent2105]

Je suis toujours sur le wiki : http://wiki.nesdev.com/w/index.php/MMC3 et je ne comprends décidément pas les 2 tableaux suivants... 
Quelqu'un pourrait il me donner une piste pour les comprendre s'il vous plait ?

[upsilandre]

J'avoue je me demande si ils pouvaient faire pire.

Pour choisir ta bank t'as 2 registres, un qui sert a selectionner la bank du PPU ou CPU concerné et la configuration (en ecrivant a l'adresse $8000), et le second registre pour indiquer le numeros de bank de ta ROM que tu va placer a cette endroit (en ecrivant a l'adresse $8001).

Sur le tableau il t'explique comment s'utilise le registre $8000 de selection.
Dans le tableau CHR le "is 0" et "is #$80" c'est juste leur facon maladroite de distinguer le cas ou le dernier bit du registre $8000 est activé ou pas (bit qui sert a definir le type de granularité de la CHR-ROM, soit d'abord 4x1k puis 2x2k ou l'inverse)
Et les R0,R1,R2...R7 c'est juste leur facon maladroite de parler de la configuration des 3 premiers bit du registre $8000 (R0 = 000, R1 = 001 ... R7 = 111)
Le "AND $FE" et "OR 1" c'est juste une autre facon maladroite de dire que quand la granularité est sur 2ko et bien la premiere bank selectionner est forcement pair (operation logique AND $FE appliquer sur la valeur du registre $8001 pour que si tu as balancer une valeur impair sur $8001 elle devienne pair) ou impair (OR 1 appliquer sur la valeur du registre $8001)

En gros ces tableaux sont juste une manière maladroite de repeter le tableau qu'il y avait juste avant et qui détaillait bien plus clairement l'usage de chaque bit du registre $8000

Pour donner une exemple concret. si tu balance la valeur nulle #$00 dans le registre $8000 ca veut dire que tu selectionnes la premiere bank du PPU (car les 3 premier bit sont 0) et qu'elle est en configuration 2ko (puisque le dernier bit est 0 aussi)
Et ensuite il te faut balancer une valeur a l'adresse $8001 pour indiquer au mapper quelle bank de la ROM tu va placer dans la premier bank du PPU.
Si tu balance #$F0 a $8001 ca veut dire que t'indique au mapper que la 17eme bank de la CHR-ROM (donc le 17eme Ko car la CHR-ROM est decoupé en bank de 1ko) va occuper le premier ko du tileset et automatiquement le 18eme Ko de la CHR-ROM (d'ou le "OR 1", $F0 or $01 = $F1) occupera le second Ko du tileset car t'es en mode 2Ko de granularité.
Si jamais t'avais balancer la valeur #$F1 (donc une valeur impair) alors que t'es en mode 2Ko alors le mapper va forcement arrondir a #$F0 (une valeur pair, d'ou le "AND $FE", $F1 and $FE = $F0) pour le premiere Ko du tileset et a nouveau #$F1 ($F1 or $01 = toujours $F1) pour le second.

[vincent2105]

C'est déjà bcp plus clair ! Faut juste que je me penche un peu plus sur tes 2 derniers paragraphes et que je fasse quelques essais mais quand j'aurai un peu de temps "calme" (dans ton exemple, tu parles de 17eme bank, mais j'ai pas compris d'où "ca sortait", faut que je relise)
Encore merci pour les explications

[vincent2105]

Bon ca y est, j'ai réussi à choisir la bank PRG_ROM de mon choix juste après le reset. Je sais pas si on peut appeler ca du bankswitching, mais c'est déjà ça... :)
Prochaine  étape : faire la même chose avec les banks de CHR_ROM...

[vincent2105]

Je crois que c'est bon... J'ai scindé un tileset de super mario bros en fichiers : 2 de 2ko et 4 d'1ko, et j'arrive la aussi à envoyer un de ces fichiers à l'emplacement de mon choix en écrivant à $8001...
Allez c'est pas mal pour aujourd'hui :) 
Merci upsilandre pour tes éclaircissements 

[upsilandre]

Tres bien.
Et je vois que t'as modifier certaines tiles du tileset de Super Mario, je le connais bien et t'as virer les "fausses" tile en bas a gauche

[vincent2105]

Oui, c'était pour voir si tu suivais :p

Pour le bankswitching, je pense avoir compris, j'y reviendrai en temps voulu, j'ai un peu la flemme de faire des tests "pour rien", faut quand même bien reflechir et concevoir les tiles pour avoir un effet sympa.

Je pense que je vais revenir à mon apprentissage du scrolling. Je voulais un scrolling à la Super Mario Bros 2... J'en étais pas loin je pense. Par moment j'écrivais une colonne alors qu'il ne le fallait pas (grosso modo quand le joueur changeait de direction plusieurs fois "au même endroit"). Par contre, je vais tout reprendre depuis le début, je préfère partir sur du propre.

Niveau scrolling, t'as deja fait des trucs ? multidirectionnel peut-être ?