Hardcore Retrogaming

[upsilandre]

le PPU est optimisé et calibré au poil de cul
le PPU a besoin de 2 cycles pour acceder a un octet en VRAM
y a 340 cycles PPU pendant une scanline (donc pendant le balayage d'une ligne ecran)
Ca veut donc dire que le PPU peut lire 170 octets en VRAM pendant le tracage d'une ligne et quand on fait le calcule entre les acces a la "name table", la table d'attribut, les tables de pattern (backround et sprite) il y a besoin de lire 168 octets par scanline pour avoir toutes les données nécessaires.
Donc la VRAM est occupé a 99% pendant le tracage des lignes (ca inclut meme les blanking horizontaux, c'est a dire le moment entre 2 ligne ou y a rien a tracé et ou le PPU prepare quand meme la suite notement les sprites) pas la peine d'essayer d'y acceder.
Et heureusement que le PPU a aussi une petite memoire interne (qui n'est donc pas en VRAM) pour la table des sprites et donc y acceder et la trier pour evaluer quelle sont les 8 sprites affichables la ligne suivante et ainsi pouvoir le faire simultanement au tracage de la ligne en cours (la Master system elle gere tout dans une unique memoire donc forcement avec des acces plus rapide)


Donc pendant le tracage le PPU et la VRAM sont vraiment busy.
C'est pour ca qu'on ne peut acceder a la VRAM (pour modifier ce qui est affiché) que pendant le VBlank, ce moment entre 2 frames ou le PPU est au repos et qui en NTSC ne dure que le temps de 20 ligne sur 262

Finallement en NTSC la NES affiche bien 240 lignes, c'est du 256x240. Je pensais que ca ne concernait que l'ecran virtuel mais c'est bien aussi ce qu'elle affiche réllement sauf qu'on considere que la zone vraiment exploitable c'est 224 lignes et que le reste est dans l'overscan hors de l'ecran. Mais alors je comprend pas pourquoi ne pas avoir éteint le PPU audela de 224 lignes et ainsi laisser la VRAM accessible?
Ca aurait permis d'avoir un Vblank de 36 lignes au lieu de seulement 20, j'imagine que c'est pas du luxe pour avoir le temps d'utiliser certain tricks (sur la master system tu peux te contenter de 192 lignes affichable) d'autant qu'avoir 16 lignes non affiché c'est utile aussi dans certain cas de scrolling pour cacher certain glitch (qui le sont par l'overscan en theorie mais quand meme). Mais non y a apparemment rien dans les registres PPU qui permet de reduire l'affichage a 224 lignes, vraiment curieux. (si ton jeu est a scrolling horizontal rien ne t'empeche de mettre des tiles noirs en haut et en bas et de gerer l'affichage en 224 lignes mais ca n'empechera pas que le GPU sera occupé et non disponible pendant l'affichage de ses lignes noirs, ton VBlank restera limité a 20 lignes)

Pour l'instant ce choix de 240 lignes affiché est un mystere pour moi et le seul truc que je trouve mal fichu.
Du coup en PAL ca affiche aussi 240 lignes (mais qui ont toute les chances d'etre visibles a l'ecran cette fois) mais le Vblank dure 70 lignes donc une situation bien plus confortable. Y a pas de jeux NES sortie seulement en PAL?

[Leonfr24]

Mr.Gimmick-SCN-PAL-B ONLY
Super Turrican-ESP-FRG-PAL-B ONLY
Hammerin' Harry-ESP-FRG-PAL-B ONLY
Banana Prince-FRG-PAL-B ONLY
Asterix-FRG-PAL-B ONLY
Over Horizon-NOE-PAL-B Only
Mario/Tetris/World Cup 3-1-ESP-PAL-B ONLY
Beauty and the Beast-NOE-PAL-B ONLY

Encore merci pour ton topic si instructif ^^

[upsilandre]

merci, j'irais jeté un oeil voir si ils ont des particularités qui profite du Vblank bien plus long (tu peux en gros faire 3x plus de modifications de la VRAM entre chaque frame qu'en NTSC)


purée le gouffre entre le sound chip de la Mark 3 (MS japonaise) et de notre master system 
la Mark 3 avait un super sound chip superieur a la NES et au final nous on se retrouve avec un sound chip (integré au GPU il me semble) inferieur a celui de la NES

[upsilandre]

Mr.Gimmick-SCN-PAL-B ONLY
Super Turrican-ESP-FRG-PAL-B ONLY
Hammerin' Harry-ESP-FRG-PAL-B ONLY
Banana Prince-FRG-PAL-B ONLY
Asterix-FRG-PAL-B ONLY
Over Horizon-NOE-PAL-B Only
Mario/Tetris/World Cup 3-1-ESP-PAL-B ONLY
Beauty and the Beast-NOE-PAL-B ONLY

Encore merci pour ton topic si instructif ^^

j'ai testé Super Turrican mais rien vu de particulier

Par contre ensuite j'ai testé Asterix et la on constate qu'ils ont effectivement exploité le Vblank plus long du PAL dans le superbe sprite d'Asterix.
Deja on constate que c'est un gros "sprite" composé de 12 sprites (3x4) et tres bien animé.
Pour animer le sprite d'un personnage (par exemple animer le mouvement de marche) la solution ordinaire c'est de stocker toutes les versions differentes des tiles qui compose le sprite dans toutes les positions et donc de switcher entre ces differents sprites pour changer l'apparence du sprite du personnage et ca consiste juste a modifier la table de sprite (la liste des sprite affiché a l'ecran) ce qui n'est pas couteux. Mais comme y a seulement 256 tiles dans la table de pattern pour stocker toutes les tiles de tous les sprites c'est compliqué de faire de belle animation.

Dans Asterix ils ont utilisé une autre solution qui consiste a n'avoir qu'un seul set de tile, une seul etape d'animation stocker dans la table de pattern (donc seulement 12 tiles pour representer Asterix dans une seul position, comme si il n'etait pas animé) et de modifier directement la table de pattern entre 2 frames pour remplacer ces 12 tiles par 12 autres qui represente une autre etape d'animation.
C'est une methode que j'ai deja vu utilisé pour ajouter des petites animes dans le décor (par exemple animer les vaguelettes a la surface de l'eau) mais ca se limite en general a 2 tiles car modifier une seul tile dans la table de pattern ca veut dire modifier 16 octets de VRAM ce qui est deja pas mal.

Ici dans Asterix il faut donc modifier 12 tiles d'asterix + 2 tiles du decors (car y a de l'animation aussi dans le decor) entre 2 frame donc pendant le blanking.
14 tiles ca veut dire modifier 224 octets de VRAM pendant le blanking! J'ai calculé que ca prendrait minimum 1100 cycle CPU soit l'equivalent de 19 lignes de balayages NTSC alors que le blanking en NTSC dure 20 lignes et qu'il y a d'autre chose a faire (comme mettre a jour la table de sprite qui prend minimum 5 lignes)  donc ca ne passerait pas. Heureusement en PAL y a 70 lignes de Vblank

Donc on peut dire que Asterix ne pourait pas tourner en l'etat en NTSC (mais avec un mapper asser evolué y a un autre moyen je pense qui consisterait a utiliser un bank switching pour la CHR-ROM avec une granularité tres fine de 1ko et de switcher juste 1ko de la table de pattern ou se trouve le sprite d'Asterix pour l'animer, le bank switching c'est instantané, ca prend a peine quelques cycles CPU mais par contre ca oblige a switcher minimum 64 tiles de sprite et pas juste 14. C'est surement utiliser dans quelques jeux)

Si vous avez un emulateur sous la main jeter un oeil dessus, le sprite est asser chouette pour de la NES.
Infogramme a toujours fait cette effort technique sur l'esthetique des jeux a défaut d'autre chose.

[upsilandre]

[upsilandre]

Je suis pas un expert des emulateurs NES mais j'ai pas l'impression qu'il y a mieux que fceux
http://www.fceux.com/web/home.html
Non seulement il marche tres bien mais surtout il est bien equipé en outils de debuguage (et de TAS). J'ai pas l'impression qu'il y ai beaucoup d'autre choix.

J'ai pas encore beaucoup creusé mais pour l'instant j'ai l'impression que la communauté homebrew NES est moins active que celle de la VCS. je pensais que la communauté NES serait de loin la plus active mais la communauté homebrew VCS de ce que j'ai pu en voir quand je m'y suis mis c'est vraiment enorme, c'est peut etre finalement la plus active et la mieux documenté (ou alors peut etre SNES?).

Dailleurs j'ai meme pas trouvé ne serait ce qu'une intention de portage d'Alex kidd sur NES en homebrew. C'est quand meme étonnant. si vous trouvez trace sur le web d'un projet alex kidd faite le moi savoir. Sinon ca pourrait etre ma base de travaille pour tester la programmation NES

[komboloy]

Super Topic, vraiment !
J'adore ton initiative Upsilandre, je veux faire ce genre d'exercice depuis environs 2 ans mais faute de temps, je dois toujours lâcher l'affaire au bout de 2-3 semaines pour raisons professionnelles.

Je viens de lire tout ton post avec intérêt et franchement, bravo. Tu fais exactement le genre d'exercices que j'aurai voulu entreprendre...Je suis limite jaloux là...

Bref continue, j'adore

[upsilandre]

Merci
C'est le probleme c'est que t'as jamais le temps pour finir un truc ni meme le temps de commencer en general.
Mais ma demarche c'est pas de créer des jeux (sinon je le ferais sur PC avec des outils modernes) mais juste de comprendre ces vieilles machines donc ca me dérange pas trop de démarrer un truc sans le terminer vu que ce qui compte c'est ce que j'en aurais appris jusque la.





Pour revenir a la NES et la Master system que j'ai creusé un peu plus aussi
J'ai pas mal evoqué le cas des sprites, les meme capacité sur les 2 consoles (64 sprites par ecran, 8 sprites par scanline) mais le fait d'etre limité a des palettes de 3 couleurs sur NES (4 palettes de 3 couleurs) contre 15 couleurs par sprite sur MS change au final beaucoup de chose, cette limite de 3 couleurs est une grosse contrainte.

Mais j'ai pas trop evoqué le cas du background qui a aussi ses differences entre NES et MS.
Dans les 2 cas ca reste un assemblage de tile 8x8 comme pour les psrites. Ces tiles (que ce soit celle du background ou des sprites) sont stocké dans une memoire, la table de pattern, qui se trouve dans la VRAM de la console pour la Master system mais sur la cartouche pour la NES (sous forme de ROM ou de RAM) car la NES a tres peu de VRAM embarqué dans la console (2Ko + 256octet conte 16Ko de VRAM pour la master system qui donc integre directement la table de pattern. La NES mise beaucoup sur les cartouches)

Sur les 2 consoles c'est a peu pret le meme nombre de tiles disponible pour le background (256 avec la possibilité pour la MS d'aller piocher aussi dans les tiles de sprite pour le background)
Donc la difference va se faire encore une fois sur les palettes. sur NES va falloir encore se limiter a choisir une palette de 3 couleurs parmis 4 palettes. sur MS on a encore une fois une palette de 15 couleurs et on peut aussi utiliser la palette des sprite (donc le choix entre 2 palettes de 15 couleurs au lieu de 4 palettes de 3 couleurs)

Donc grosso modo c'est la meme situation que pour les sprites mais etre limité a 3 couleurs je pense que c'est + contraignant pour les sprites qui necessitent du detail si on veut représenter un personnage que pour le background sauf que la NES ajoute une autre contrainte pour les tiles du background:
Tu ne peux pas choisir une palette pour chaque tile (contrairement aux sprites). Le choix de la palette de chaque tile du backrgound se fait dans une autre table appelé table d'attribut et il faut choisir une palette (de 3 couleurs) pour un ensemble de 4 tiles (2x2) donc pour un bloc 16x16.

Donc au final le background sur NES se construit plutot par bloc de 16x16 au lieu de 8x8 contrairement a la Master system ou t'as pas de contrainte de ce coté mais d'un autre coté meme sur MS les test de collision se font en general plutot a une echelle de bloc 16x16 je pense car c'est plutot une bonne echelle pour gerer les interactions (c'est en gros la taille d'un petit personnage ou d'un petit ennemi) donc les bloc de 16x16 sont plutot un type de bloc standard pour le background d'un jeu 8bit

Mais cette table d'attribut ajoute une autre contrainte car chaque octet de la table regroupe l'index de 4 tablettes (car suffit de 2bit pour indexer une tablette parmis 4) donc chaque octet indique les palettes pour un ensemble de 2x2 bloc de 2x2 tiles soit au final un bloc de 32x32 pixels (ou chaque bloc de 16x16 aura sa palette) et comme on manipule plutot les données par octet complet ca veut dire que lorsqu'on manipule le background (quand on fait scroller) il est mieux de le faire par bloc de 32x32 sur NES plutot que par bloc de 8x8 ou 16x16.
Ca implique notement que quand tu fais par exemple un scrolling horizontal sur NES il sera préférable de mettre a jour l'affichage du decor par bloc de 32 pixels de large et donc prevoir un espace hors de l'ecran qui fasse au moins 32 pixels pour qu'on ne voit pas a l'ecran les glitch causé par la mise a jour du décor alors que sur Master system tu peux mettre a jour le decor par colonne de seulement 8 pixels de large (donc par tile) et donc tu n'as alors que ces 8 pixels a cacher hors champ



Ceci peut expliquer pourquoi la master system se contente de gérer un ecran virtuel de 256x224 pour un affichage en 256x192 (ou 248x192 selon ce qu'on choisie).
Les 16 pixels verticaux supplémentaire lui suffisent pour gérer la mise a jour du scrolling vertical (8 suffirait) et les 8 pixels que l'on peut cacher sur la gauche suffisent aussi a gérer le scrolling horizontal (sur un emulateur Master system vous pouvez constater cette petit bande noir vertical sur la gauche lorsqu'il y a un scrolling horizontal)

De son coté la NES gére un ecran virtuel plus large,  512x240 ou 256x480 selon le jeu (notement car ses données graphiques occupent 2x moins de place que sur Master system, c'est l'avantage d'avoir des palettes pauvres) pour un affichage en 256x240 (ou 248x240) donc largement de quoi cacher les 32 pixels de marge dont elle a besoin pour gérer tranquillement le scrolling. C'est un peu plus compliqué si on veut faire un scrolling multidirectionnel (vertical et horizontal a la fois) sans aucun glitch apparent sur les bords mais pas insurmontable.





Voila donc quelques differences pour la gestion du background
J'ajouterais aussi 2 autres fonctions cablées en hard sur Master system qui sont bien utile et qui n'existe pas sur NES
Sur master system vous pouvez déclarer une zone de 16 pixels en haut de l'ecran ou 64 pixels sur la gauche qui ne subiront pas les effets du scrolling du background. Tres utile pour faire un HUD et afficher des informations qui ne doivent donc pas scroller (par contre on peut pas choisir la taille de cette zone, c'est prédéfinie). Sur NES y a pas ca

Et sur Master system tu peux aussi mettre en place des interruptions CPU lié au balayage horizontal de l'ecran. C'est a dire demander au GPU d'interrompre le CPU et donc lancé un sous-programme lorsque l'ecran balaye la 64eme ligne par exemple, ou toutes les 32 lignes. Ca peut etre utile pour certain trick graphique.
La NES n'a pas non plus cette fonction bien utile mais heureusement certain mapper dans les cartouches offres cette possibilités de pouvoir activer une interruption au moment de l'affichage de tel ou tel ligne et c'est dailleurs ca qui sera utilisé sur NES pour par exemple réserver une zone en haut de l'ecran qui ne scroll pas et faire un HUD puisqu'elle ne sait pas le faire en hard.



Dailleurs cette capacité de ce mapper NES a pouvoir faire ca m'avait intrigué car ca implique que le mapper dans la cartouche soit capable de compter les lignes affichées et interrompre le CPU en fonction de cela.
Or si sur le shema de cablage de la console on peut voir effectivement que la pin d'IRQ (interruption) du CPU est bien connecté au port cartouche (donc la possibilité pour la cartouche d'enclencher une interruption) mais le signal Vblank du GPU lui ne passe pas du tout par le port cartouche (et le signal Hsync reste interne au GPU) donc difficile pour le mapper de savoir ou s'en trouve l'affichage.

Et finallement ils utilisent une solution ingénieuse. Le mapper exploite simplement la ligne d'adresse A13 du GPU (donc la ligne de poid la plus elevé de l'espace memoire GPU) qui evidement passe elle bien par le port cartouche vu que le GPU utilise directement la ROM/RAM dans les cartouches.
Et il se trouve que quand le GPU s'occupe de l'affichage il switch constamment entre la "name table" qui est dans la VRAM de la console (pour savoir quelle tile il doit afficher a cette endroit de l'ecran) et la table de pattern qui est sur la cartouche (pour aller chercher la pattern de la tile en question) et ce qui différencie l'acces a ces 2 espaces memoire c'est justement la ligne A13.
Quand elle est sous tension elle permet de s'adresser au 8ko de poid fort qui sont ceux de la table de pattern dans la cartouche, et éteint elle sert alors a s'adresser aux 8Ko de poid faible qui sont la VRAM dans la console (physiquement 2ko seulement mirroré 4 fois) et donc le GPU switch 42 fois entre ces 2 memoires pendant l'affichage de chaque ligne comme un metronome.
Le mapper utilise donc ce metronome pour compte les lignes affichées et déclencher une interruption au moment que l'on a choisie ce qui permettra ensuite plein de trick.


Je reviendrais sur les mapper dans les prochains jours, c'est un élément important de la NES, probablement plus que pour n'importe quelle console de ce que j'en constate.

[upsilandre]

Je commence a regarder un peu du coté des outils.

Pour l'assembleur 6502 j'aurais bien repris DASM que j'ai deja utilisé pour programmer sur VCS vu que c'est le meme CPU mais de ce que j'en lis DASM est quand meme tres vieux (c'est le tout premier compilateur 6502), donc j'ai fais un peu le tri parmis les assembleurs 6502 et mon dévolu ce porte sur ASM6 qui a l'aire d'etre le meilleur choix pour moi.

Pour l'emulateur ca sera Fceux. Fceux + ASM6 ca a l'aire d'etre le combo gagnant

Pour l'editeur de texte j'ai pris notepad++ histoire de pas repartir sur le basic notepad Windows que j'ai utilisé pour programmer la VCS

J'ai pris un petit soft japonais appelé YYCHR qui sert pour dessiner des patterns. dedans y a des trucs un peu obscure, a creuser.

[upsilandre]

Un truc que j'ai oublié d'evoquer aussi au sujet des backgrounds sur Master system c'est que tu peux appliquer un flip vertical ou horizontal sur les tiles du background comme pour les sprites chose que tu ne peux pas faire sur les tiles du background avec la NES. Pouvoir flipper les tiles ca permet de faire des économies en utilisant un meme tile pour des elements gauche et droit.
Par exemple sur Alex kidd quand on désactive le flip sur le background ca donne ca



Sur NES je serais obligé d'utiliser des tiles differents pour les versions gauche et droite, une contrainte supplementaire (car y a pas beaucoup de place dans la table de pattern)





Un autre truc que j'ai oublié d'evoquer aussi pour les sprites et qu'il est intéressant de savoir pour briller en societé.
Le phénomene de clignotement des sprites asser symptomatique de l'epoque n'est pas un glitch hardware, c'est le programmeur du jeu qui volontairement fait clignoter ses sprites, je pense que peu de joueurs le savent.

Par defaut les sprites excédent (audela de 8 sur la meme ligne) ne sont tout simplement pas affiché par le PPU et donc certain ennemis ou projectiles pourraient alors etre tout simplement invisible (ou en tout cas une partie du sprite) ce qui est embetant. Du coup le programmeur alterne volontairement l'affichage des sprites pour que tous soit visibles.

Y a une notion de priorité dans les sprites. Pendant l'affichage de chaque ligne le PPU refait une lecture integrale de la table des sprites (qui en contient 64) pour identifier les sprites qui seront présent sur la prochaine ligne mais ne pouvant en afficher que 8 le PPU va selectionner les 8 premiers. L'ordre de priorité des sprites est donc juste celui de lecture de la table de sprite (c'est valable aussi pour savoir lequel s'affiche par dessus l'autre quand plusieurs sprites sont au meme endroit)

Du coup quand y a plus de 8 sprites a afficher sur la ligne alors ceux en excedent ne seront pas affichés. Pour alterner l'affichage entre ceux qui sont affichés et ceux qui ne le sont pas j'imagine qu'il suffit d'inverser une frame sur 2 la construction de ta table de sprite pour quelle soit lu par la fin et donc inverser les priorités ce qui permettra alors de rendre visible 16 sprites en alternance et donc avec un clignotement.

[upsilandre]

C'est marrant d'optimiser tes sprites.
Quand tu decomposes tes metasprites (le sprite du personnage qui est lui meme composé de plusieurs sprites) en tile de 8x8 tu te rend vite compte que certain tile se ressemble comme 2 goutes d'eau avec genre juste un pixel de difference ou un decalage de coordonée d'un pixel donc tu peux facilement tricher et gagner des tiles.

Pour tous ses mouvements (marcher, repos, accroupi, saut, frapper, nager) Alex utilise 10 metasprites et si j'additionne bettement les tiles qui les composent ca me donne 75 tiles (d'autant que la bidouille des 5 couleurs impose un surcout de sprites) mais une fois optimisé en recyclant certain tile je tombe a seulement 33 et sans degradation visible.
C'est probablement une optimisation qui ne me sera pas forcement utile mais c'est tentant.

Sinon j'ai toujours pas vraiment compris la facon d'utiliser YY-CHR du coup j'utilise "NES screen tool" 2.03 pour faire mes patterns, y a pas photos, c'est bien plus intuitif, ca correspond a ce que je cherchais (tout l'inverse de YY-CHR qui a plutot l'aire de s'adresser a ceux qui veulent modifier les patterns de jeu existant).

Mon tile set complet pour Alex (mais sans les couleurs puisque ce sont les sprites qui selectionne la palette a associé au tile)



il me reste pas mal de place (la surface du carré représente l'integralité de la pattern dédié aux sprites soit 4ko pour 256 tiles)

l'interet de NST c'est qu'il te sort aussi le fichier binaire de la pattern complete de 4ko que tu peux ensuite integrer dans ton programme assembleur et donc dans ton fichier ROM.
il peut aussi te sortir un fichier binaire pour la palette, la name table, la table d'attribut, la liste de sprite de tes metasprites mais c'est surtout pour le CHR-ROM de 4ko qu'il est indispensable car c'est difficile de sortir ca a la main octets par octets (voir peut etre pour la name table, a voir).
Mais c'est toujours a toi ensuite de savoir comment exploiter ce fichier et quoi en faire, il te sort juste les data brute.

[upsilandre]

Meme si j'ai un peu la flemme faut que j'écrive un truc sur les mappers car c'est quand meme un element important a comprendre dans l'histoire de ces consoles.



LES MAPPERS

Le mapper c'est un chip qui se trouve sur la cartouche et qui va venir s'interposer entre la ROM de la cartouche (la ou se trouve le jeu) et la console pour interpréter et modifier ce qui passe par la.

Principalement sa fonction ca va etre d'étendre virtuellement le bus d'adressage du CPU qui passe par le port cartouche et donc par la meme occasion etendre virtuellement la quantité de ROM adressable (et donc la taille du jeu)
Car en effet sur ces vieilles console on a de vieux CPU (6502, Z80) avec des bus d'adressage seulement 16bit ce qui implique de pouvoir adresser seulement 64Ko tout compris (ROM, RAM, BIOS, registre/port des differents composants) donc en general on coupe en 2 (plus facile en terme de cablage et de mapping memoire), une moitié pour la ROM et l'autre moitié pour tout le reste du systeme.

Sur NES le CPU pourra donc adresser seulement 32Ko de ROM (+ 8Ko de ROM graphique par le PPU qui a son propre bus d'adressage mais 14bit donc 4x plus faible que le CPU) ce qui est sensiblement plus que sur la VCS (4Ko) mais reste trop faible pour etre a la hauteur de ses ambitions vis a vis de cette revolution du scrolling qui a tendance a ouvrir une porte vers un monde "infini" et d'un seul coup ca devient quand meme couteux en données malgres les optimisations (gestion par tiles).

Donc sur NES si vous voulez vous faire une idée de ce que la console a dans le bide sans mapper (donc des jeux limités a 40ko) alors la réponse c'est Super Mario bros, c'est probablement ce qu'on peut faire de mieux avec juste la console nue. Ca reste asser limité



L'ABONDANCE

Donc rapidement les mapper vont arrivés et de facon asser anarchiques. Ca a permis notement d'avoir une gamme de jeu extrement large qui s'etend de 24Ko a 1024Ko (+ d'autre features)
La NES est probablement la plus extreme dans l'usage des mappers, y a environ 200 mappers differents. Chaque editeur faisait son mapper parfois specifiquement pour un jeu.

Je crois pas qu'il y ai d'autres consoles qui aient subit autant de mappers differents. Ca a l'aire quand meme symptomatique de la NES.
La VCS avait par defaut des ressources (4ko, 128octet de RAM) asser raccord avec ses specs donc le mapper n'etait pas un passage obligé, y en a juste eu quelques uns notement pour doubler la taille des cartouche.

Sur Master system qui est aussi asser limité par defaut (48Ko de ROM adressable par le CPU et rien adressable par le GPU) a integré la notion de mapper dès le depart puisque les jeux MS ont debuté a 128Ko (si on fait exception des jeux sur carte de 32Ko qui elles n'integrent pas de mapper, d'ou le format carte) du coup ca semble avoir ete standarisé par Sega dès le depart.
La gamme offerte (de 128ko a 512Ko) et la gestion du bankswitching est completement standarisé et le mapper doit etre fournis par Sega je pense du coup aucun bordel.
D'autant plus que le cablage du port cartouche de la Master System est plus simple (44 pins contre 60 pour la famicom et 72 pour la NES) et se limite en gros au bus d'adressage et bus de donné du CPU contrairement a la NES ou le PPU a aussi acces a la cartouche (et meme le son passe par la cartouche et peut donc etre modifier mais exclusivement sur Famicom, par sur NES)
du coup y a moins de customisation possible sur Master system au travers du mapper contrairement a la NES ou on peut customiser pas mal de chose (du faite surtout que le PPU est connecté a la cartouche qui est la grosse difference avec la Master system)

Sur les consoles 16bits je connais moins bien mais deja la Megadrive utilise un 68000 qui est un CPU avec un bus d'adressage 24bit ce qui offre une plage memoire de 16Mo, bien plus que necessaire pour la megadrive (ou les plus gros jeux doivent pas depasser les 3 ou 4Mo) donc doit pas exister grand chose comme mapper sur Megadrive, peut etre aucun.
La SNES j'ai pas etudié, je sais qu'elle a aussi un bus 24bit donc plus que nécessaire et qui rend la fonction premiere du mapper (etendre la memoire adressable) inutile donc en dehors des mappers avec des chip pour etendre les capacités de la console type super FX y a pas du y en avoir des dizaines et on ne peut pas vraiment appeler ca un mapper.

Donc la NES semble bien quand meme etre un cas extreme dans l'histoire des mappers. Ca longue durée de vie a sans doute beaucoup contribué a cela aussi.
Dailleurs quand on voit comment le port cartouche est bien cablé pour de futur evolutions au travers des mappers je trouve que ca met a mal une autre legende comme quoi la NES aurait ete au depart concu comme un jouet éphémère qui passe de mode rapidement. Je pense que les 3 ans visé etait probablement leur seuil de rentabilité pour que le projet soit viable mais le hardware donne plutot l'impression qu'ils visaient clairement plus loin dès le depart.



L'EMULATION

Ce nombre incroyable de mapper a surtout rendu l'emulation tres complexe car il ne faut pas juste emuler la console mais aussi emuler tous les mappers qui sont aussi du hardware.
Franchement bravo aux gars qui font des emulateurs NES car ca doit etre un sacré casse tete (et on ne remerciera jamais asser ceux qui créent les emulateurs, je pense qu'un jour on realisera a quelle point ils ont ete determinant dans la préservation du patrimoine de ce media tres complexe a préserver)
Au point dailleurs que les ROMs NES qu'on utilise en emulation ne sont pas une simple image de la ROM d'origine comme c'est le cas en général mais contiennent un header de 16 octets (qui se trouve donc au tout debut du fichier) qui est destiné aux emulateurs pour donner des information sur ce qu'est censé contenir la cartouche et pouvoir ainsi emuler le mapper. Un consensus a donc du émerger sur la facon de coder cette information et standariser l'emulation, c'etait indispensable.

Dailleurs vous pouvez remarquer que les ROM NES ont une taille singuliere. En general une cartouche de 128ko donne un fichier ROM de 128Ko. L'equivalent NES vous sera indiqué a 129Ko par l'explorateur winbows (ou 257Ko au lieu de 256Ko ect...) car c'est 128Ko + les 16 octets de header et c'est donc arrondie a 129Ko. une particularité des ROM NES que l'on doit a cette folie des mappers



CONCRETEMENT

Maintenant pour etre plus concret sur NES y a eu quand meme des mappers "officiels" soutenu par nintendo et qui sont donc utilisés dans beaucoup de jeu.
Y en a surtout 2 qui emerge du lot chacun utilisé dans plusieurs centaines de jeux c'est le MMC1 (Zelda, Metroid, Megaman 2...) et plus tard a partir du debut des année 90 le MMC3 (tous les Megaman suivant le 2, les super mario suivant...)

le MMC1 offre deja l'opportunité d'augmenter la quantité de ROM (aussi bien PGR-ROM que CHR-ROM) presque autant qu'on veut et aussi la possibilité de gérer le mirroring de la VRAM qui influe sur les methode de scrolling et qui normalement est fixe mais qui avec un MMC1 peut etre modifié en court de jeu.
Il permet aussi d'ajouter de la RAM qui combiné a une pile va servir aux sauvegarde.

le MMC3 va ameliorer ca et offrir une meilleur granularité dans la gestion du bank-switching (au lieu de switcher la CHR-ROM par bloc de 8Ko on va pouvoir switcher juste 1Ko pour par exemple juste changer le sprite de 2 ou 3 ennemis plutot que tous le set de tile et toujours de facon instantané, c'est presque un avantage sur la master system)
et cette fonction bien utile qui manque a la NES qui est la possibilité de générer une interruption selon la ligne d'affichage que l'on a décidé et donc pouvoir agir sur l'affichage (notement diviser l'ecran en 2 parties, le jeu et le hud)
En gros le MMC3 embarque a peu pret tout ce qu'on a besoin.

Mais y a quand meme eu un MMC5 tres peu utilisé mais pousse vraiment au max les possibilités avec l'intégration d'un soundchip pour upgrader l'audio (mais apriori uniquement valable sur Famicom vu que la NES est cablé differement) et une gestion de la VRAM bien tordu qui permet certain trick asser surprenant comme la possibilité d'etendre la table d'attribut et pouvoir associer une palette pour chaque tile du background comme sur Master system (au lieu d'etre limité a un bloc 16x16)
et encore plus fort, la possibilité de coder la name table sur 14bit au lieu de 8bit et donc pouvoir adresser directement une table de 16384 tiles au lieu de 256 ce qui veut dire plus besoin de faire de bank-switching pour la CHR-ROM, t'as un acces direct a toutes la CHR-ROM dispo sur la cartouche (la ou meme une master systeme est limité a 448 tiles a la fois).
et meme la possibilité de splitté l'ecran verticalement.
On atteint alors des sommets de bidouillage et donc de customisation de la console.



CONCLUSION

Donc voila en gros l'histoire des mappers de la NES.
C'est peut etre la partie que j'aime le moins dans la NES car au final les contours du hardware de la NES sont flou contrairement a d'autres consoles. On ne peut pas vraiment dissocier la NES de ses mappers et donc on peut difficilement donner une description fermé du hardware de la NES (meme si y a beaucoup de chose qui ne change pas comme les 3 couleurs par sprite ou les 8 sprites par scanline) ce qui m'embete un peu. Les contours sont dilués.

[upsilandre]

Je vous avais dit qu'en lisant les documents j'avais decouvert que la NES etait capable de jouer des samples audio PCM 7bit.
Connaissant pas bien les jeux NES je savais pas si c'etait exploité dans des jeux ce qui est a priori difficile. Effectivement on trouve quelques jeux qui utilise des voix samplés mais vu le peut de place c'est plutot du DMC et pas au mieux de ce qu'il est possible.

Mais moi je voulais quand meme entendre ce que ca pouvait donner au max de ses capacités et j'ai trouvé cette exemple homebrew d'un sample complet de musique PCM 7bit 16khz jouer sur NES et ca rend carrement bien... Sauf que pour 1mn35 de musique il a fallu 256 bank de 16Ko de ROM (4Mo), une pour le programme et 255 pour le sample.

En regardant cette video gardez a l'esprit que Super Mario Bros c'est au total 2 banks pour le jeu entier (et Donkey kong une seul bank) et regarder le chiffre des banks en train de switché qui défile en haut a gauche, chaque fois que ca switch c'est l'equivalent d'un jeu Donkey ou d'un demi Mario. Il consome l'equivalent en ROM de plus d'un jeu super mario par seconde  :roll: :lol:





Voila pourquoi ce n'est pas utilisé (meme si y a pas besoin de cette exemple pour le deviner)


encore plus drole

[upsilandre]

Sur SNES y a aussi des demos de son PCM 16bit en stereo et 32khz donc la c'est quasiment qualité CD (et ca prend aussi autant de place)





Mais deja sur la NES on a vu qu'on pouvait faire un sampling de qualité viable et avoir de vrai track audio de musique/dialogue
Sur un scénarios de ROM infini, un scénarios ou le cout de la ROM serait disont 10 000x inferieur a ce qu'il etait a l'epoque alors sur NES on aurait meme pu faire de la video full screen 30fps (sur master system ca me parait compliqué) et donc avec le son adequate.

Ce qui coute en perf pour la video et l'audio c'est surtout les modes de compressions pour economiser de la place mais si on se fiche de la place occupé et donc sans compression alors c'est jamais tres compliqué, c'est juste du deplacement de donnée et dans le cas de la NES y aurait meme pas a deplacer les données vu que le PPU est directement connecté a la cartouche (contrairement a la MS) un simple bank switching permet de changer l'image affiché a l'ecran et donc a cout quasi nulle (juste quelques instructions CPU)

Reste la question de comment afficher un bitmap fullscreen sur l'ecran (c'est a dire une image dont on a le controle individuel de chaque pixel plutot qu'une gestion par tile tel que ces consoles l'imposent)
Et encore une fois le cablage du PPU permet de tricker cela avec un mapper adequate.
Pour afficher une bitmap full screen faudrait pouvoir gerer un total de 960 tiles a la fois pour que toutes les tiles affichées a l'ecran soit unique (et servent alors a composer un bitmap) mais par defaut la NES ne peut en gérer que 256 a la fois (voir 512 avec un trick mid-frame)
Mais un mapper comme le MMC5 permet lui d'etendre la name table de 8bit a 14bit et donc de gérer 16384 tiles a la fois donc plus que necessaire.

Pour un mapper optimisé pour la video suffirait d'un mapper plus simple que le MMC5 capable juste d'etendre la name table de 8bit a 10bit et on pourait alors gérer 1024 tiles a la fois et donc afficher des bitmap full screen 256x240.
Chaque bank de 16Ko de CHR-ROM contiendrait alors un bitmap 256x240 complet et suffirait alors de faire du bank switching pour changer de frame d'autant que la name table elle n'a pas besoin d'etre modifier, c'est les tiles qui change.

par contre ca serait du bitmap 2bpp soit 4 couleurs et 4 couleurs c'est trop peu pour faire de la video mais comme on affiche a 60fps sans probleme (vu que ca coute rien en ressource) on peut combiner 2 frames successivent pour simuler de facon temporel du 4bpp.
Y aurait un peu de flickering mais on aurait alors de la video Full screen en 16 couleurs et 30fps (et sans artefact de compression puisqu'il n'y en a pas) et ca rendrait sans doute pas trop mal.

Le MMC5 integre aussi un soundchip donc on pourait le modifier pour qu'il soit dédié PCM avec un seul canal mais cette fois 16bit 32khz tant qu'a faire et on aurait un son nickel pour accompagner la video full screen et tout ca sans que ca coute rien en ressource pour la NES (elle se tournera les pouces pendant les FMV). 

par contre ca nous donne donc par seconde 60 banks 16Ko pour la video + 4 bank 16ko pour l'audio soit exactement 1Mo par seconde (a peu pret comme un film DVD poussé a sa qualité max) donc faudrait des cartouches avec des ROMs de la taille d'un DVD pour pouvoir faire des jeux NES ponctué de FMV full screen soit 10 000x plus qu'a l'epoque

[upsilandre]

PROLOGUE

J'ai bien décortiqué les docs de devs de l'intellivision de Mattel, sortie en 1979/1980 (dabord de facon confidentiel fin 1979 pour tester le marché US comme ca se faisait souvent a l'epoque puis de facon national l'année suivante) soit 2 ans apres l'Atari VCS et 4 ans avant la Famicom.
C'etait le premier vrai concurrent de la VCS donc une machine qui historiquement a marqué et s'est vendu a 3 millions d'exemplaire. Obligé de s'y intéresser.

J'ai trouvé une machine qui dans le fond (le hardware) ressemble plus a une NES qu'a une VCS alors que dans la forme (le visuel des jeux) elle fait plutot penser a une VCS du a ses limitations techniques de l'epoque.
C'est un peu le chainon manquant que je cherchais dans ma chronologie. La ou la VCS etait la premiere console avec un vrai GPU mais un GPU 1D. L'intellivision est la premiere avec un vrai GPU 2D ou l'on retrouve les mecanismes qu'on retrouvera ensuite dans toutes les consoles 2D, des tiles 8x8, une table de background, des vrai sprites 2D, un debut de réflexion sur le scrolling...

A l'intérieur beaucoup de composant, une douzaine de chip principalement fournit par Général instrument (l'un de ces nombreux pionniers des semi-conducteurs des années 70 qui n'ont pas tous pu survivre ensuite sans fusionner) on est loin de la parcimonie de consoles comme la VCS (principalement 3 chips) ou la NES (principalement 4 chips) qui ont sans doute fait leur succes en maitrisant au mieux le rapport cout/perf.
Ici le sound chip n'est pas intégré a un autre chip, ni le DAC video et y a beaucoup de pool memoire different avec plein de chip de ROM et de RAM. un vrai GPU plutot chouette pour l'époque et un CPU exotique (de GI aussi) qui est un vrai CPU 16bit (et oui l'Intellivision est une console 16bit, c'est dire l'absurdité de cette nomenclature des joueurs consoles si il etait besoin de le rappeler).
Le contrôleur ressemble a rien et y a eu aussi un accessoire generateur de voix "Intellivoice".






LE GPU

Le GPU (de GI aussi) a un petit nom et j'aime bien quand les GPU ont un petit nom (TIA ou Stella pour la VCS, PPU pour la NES). On le nomme le STIC. Le STIC utilise un pool de tiles 8x8 pixels pour construire son background et ses sprites tel que sur NES et les consoles suivantes.
Le STIC a donc une VRAM de 2x256 octets qui lui est dédié pour stocker 64 tiles utilisable pour le background et les sprites (sur NES c'est 256 tiles pour le background et 256 tiles pour les sprites) mais a coté de ca y a aussi une ROM de 2Ko qui contient +200 tiles prédéfini, la moitié c'est du code ASCII donc pour ecrire du texte dans les jeux sans gaché de la place sur la cartouche ou en VRAM et l'autre moitié c'est des blocs graphiques qui peuvent servir. Mais principalement c'est le pool de 64 tiles en VRAM qui va te servir a faire ton jeu.
Les tiles sont cette fois des tiles 1bpp donc monochrome (+ la couleur de background) contre 2bpp pour la NES (3 couleurs) et 4bpp pour la Master system (15 couleurs)


Pour afficher le BACKGROUND le STIC utilise une backtable (table de background, l'equivalent de la name table sur NES) qui se trouve dans une autre RAM system partagé avec le CPU et qui va donc contenir principalement la table de tiles a afficher pour composer le background.
Le background est composé de 240 tiles (20x12) pour produire donc un background d'une resolution 160x96 pixels (a peu pret le quart de la resolution NES) ou l'on peut choisir individuellement la couleur pour chaque tile (ainsi que celle du background de chaque tile selon le mode video).

Y a un debut de reflexion sur le scrolling, on a pas encore un vrai scrolling cablé comme sur NES (c'est a dire faire boucler la VRAM de la backtable et pouvoir placer le pointeur de debut n'importe ou) par contre ils ont prevu la possibilité d'ajouter un offset au background. C'est a dire la possibilité de décaler l'affichage du background de plusieurs pixels (jusqu'a 7) a la vertical ou l'horizontal. Donc tu peux faire scroller le background pixel par pixel et quand t'arrive a 7 alors il suffit de déplacer tous les tiles de la backtable d'une case et remettre l'offset a 0 puis recommencer et on a un scrolling au pixel.
Comme le CPU a toujours acces a la RAM ou est stocké la backtable meme quand le GPU l'utilise ca laisse un peu de temps pour décaler toute la backtable pendant l'affichage meme si c'est probablement pas asser pour tout déplacer en une seul frame et donc faire un scrolling propre sans tearing.

Voila le seul exemple de jeu a scrolling que j'ai trouvé et ca fonctionne (meme si y a du tearing). en plus le sprite de la voiture est en 3 couleurs comme sur NES (donc ici ca necessite de superposer 3 sprites). Donc un jeu plutot impressionnant pour la machine mais arrivé en fin de vie.




Pour le background il existe un dernier mode video qui est une sorte de mode Bitmap ou on a donc le contrôle individuel de chaque pixel mais de tres gros pixel puisque dans ce cas la resolution est de 40x24 (soit des pixels qui font a peu pret la taille d'un tile NES)


Passons aux SPRITES.
Le STIC peut gerer seulement 8 sprites a l'ecran (contre 64 sur NES et MS) a l'aide de registre interne mais par contre il peut afficher les 8 sprites sur la meme scanline, c'est a dire autant que la NES ou la MS ce qui est plutot impressionnant.
Ces sprites sont des tiles piocher dans la VRAM de 64 tiles utilsié aussi pour le background. Ils peuvent aussi etre au format 8x16 comme sur NES/MS et dans ce cas ils sont composé de 2 tiles successive.

On peut afficher les sprites avec une resolution vertical 2x superieur au background (donc sur une base de 192 lignes au lieu de 96) dans ce cas un sprite 8x16 prend la meme place qu'un tile 8x8 du background mais c'est pas obligatoire car on a des fonction de zoom vertical et horizontal des sprites (x2 sur le horizontal et x2,x4,x8 sur la vertical)
et on a aussi des fonctions de flip vertical et horizontal des sprites donc tout ce qui fait une vrai gestion de sprite.
Ensuite reste plus qu'a indiquer les coordonnés ecran X,Y de chaque sprite et le STIC se chargera d'afficher ca comme il faut

Y a aussi une fonction suplémentaire qu'on ne retouve pas vraiment sur les consoles modernes NES/MS c'est une gestion hardware des collisions des sprites entre eux et avec le background. Un registre pour chaque sprite t'indique avec quelle élement (sprite ou background) le sprite en question est en collision (c'est a dire affiché au meme endroit) et ca c'est plutot cool pour economiser des ressources CPU. La VCS le faisait avec ses sprites 1D, la NES le fait mais juste pour tester une collision entre le sprite 0 (donc un seul sprite sur les 64) et le background ce qui sert juste pour identifier une phase de l'affichage.


Le STIC a une PALETTE de 16 couleurs, toute accessible par les sprites ou le background. C'est pas beaucoup, la VCS avec ses 128 couleurs reste loin devant (meme devant la NES et la MS) mais on avait peut de controle sur VCS (par exemple une seul couleur pour toute l'image background a moins d'utiliser des tricks) alors que sur l'intellivision on a un contrôle individuel total de la couleur (foreground et background) de chaque tile, plus meme que sur NES/MS du au peu de couleur de la palette.



la suite (CPU, memoires, Soudchip) plus tard...