Hardcore Retrogaming

En tout cas j'ai deja depassé l'etape ou j'en etais avant mon reboot, j'ai maintenant mon paquet de 50 aliens qui s'affiche sans bug quelque soit la combinaison d'aliens vivants et morts et donc quelque soit les cas particuliers et ils se deplacent lateralement et s'animent sans bug en adaptant l'amplitude de deplacement au contexte.
Ca au moins c'est fait et bien fait car le code pour l'instant est tres propre (grace au reboot).

Un petit bilan des ressources que j'utilise a ce point d'avancement:
- 988 octets de ROM (sur les 4Ko), 90% code, 10% data
- 69 octets de RAM (sur 128), 74% pour le Kernel
- 25% du temps CPU de la phase de blanking vertical (c'est a dire or phase d'affichage)

Pour l'instant ca tient la route mais il reste difficile de dire si ca sera suffisant car il reste beaucoup a faire.
Prochaine etape, integrer l'affichage des missiles (dans un premier temps celui du joueur) ce qui peut etre un bon bordel car les missiles vont devoir traverser une douzaine ou quinzaine de Kernels differents (rien que l'affichage des aliens c'est une alternance de different Kernels , les kernels qui affichent les aliens et ceux qui sont entre les lignes d'aliens, va falloir traverser cette succession de 10 Kernel sans bug).
J'ai bien sure deja du y penser en amont car fallait que je prenne cela en compte dans la mise en place de mes Kernels mais j'ai quelques craintes.

Pour ca je vais peut etre dabord commencer par ajouter le sprite du player et son controle (deplacement et tire), ca facilitera ensuite les phases de test de l'affichage du missile que je pourais tester ingame.

Il y a aussi le côté interessant que tu tentes de faire mieux que ce qui avait été fait à l'epoque. En tout cas, c'est passionnant.

upsilandre a écrit:

En tout cas j'ai deja depassé l'etape ou j'en etais avant mon reboot, j'ai maintenant mon paquet de 50 aliens qui s'affiche sans bug quelque soit la combinaison d'aliens vivants et morts et donc quelque soit les cas particuliers et ils se deplacent lateralement et s'animent sans bug en adaptant l'amplitude de deplacement au contexte.
Ca au moins c'est fait et bien fait car le code pour l'instant est tres propre (grace au reboot).

Un petit bilan des ressources que j'utilise a ce point d'avancement:
- 988 octets de ROM (sur les 4Ko), 90% code, 10% data
- 69 octets de RAM (sur 128), 74% pour le Kernel
- 25% du temps CPU de la phase de blanking vertical (c'est a dire or phase d'affichage)

Pour l'instant ca tient la route mais il reste difficile de dire si ca sera suffisant car il reste beaucoup a faire.
Prochaine etape, integrer l'affichage des missiles (dans un premier temps celui du joueur) ce qui peut etre un bon bordel car les missiles vont devoir traverser une douzaine ou quinzaine de Kernels differents (rien que l'affichage des aliens c'est une alternance de different Kernels , les kernels qui affichent les aliens et ceux qui sont entre les lignes d'aliens, va falloir traverser cette succession de 10 Kernel sans bug).
J'ai bien sure deja du y penser en amont car fallait que je prenne cela en compte dans la mise en place de mes Kernels mais j'ai quelques craintes.

Pour ca je vais peut etre dabord commencer par ajouter le sprite du player et son controle (deplacement et tire), ca facilitera ensuite les phases de test de l'affichage du missile que je pourais tester ingame.

Si ca marche faudra le releaser ds la communauté. C'est certains que les fans de l'atari 2600 seront intéressés.
Ca mériterait même un ptit webdoc   

chris1515 a écrit:

Il y a aussi le côté interessant que tu tentes de faire mieux que ce qui avait été fait à l'epoque. En tout cas, c'est passionnant.

d'autant que j'ai fais une petite recherche et ca ne semble pas avoir ete tenté jusqu'a maintenant ou alors je suis passé a coté (je verrais bien a la fin, j'irais le mettre sur atariage la ou est toute la communauté. Vaut mieux pas savoir avant d'avoir terminé), pas evident de trouver un petit defi qui n'a pas deja ete fait ces 35 dernieres années donc j'aimerais bien aller au bout.

L'art de l'alignement du code et des datas

Y a certaines instructions qui ne prennent pas le meme temps d'execution selon le contexte. Sur n'importe quelle machine on s'en fouterait pas mal mais sur 2600 y a tellement souvent des dependances de timing au cycle CPU pret que c'est important a comprendre.

Le cas le plus classic c'est l'instruction de branchement conditionnel, quand la condition est remplis et qu'il y a branchement ca prend 1 cycle de plus que quand y a pas branchement mais ca concerne aussi notement toutes les instructions qui utilisent un adressage indexé.

Par exemple le code lda $FE12,x ca veut dire charger dans l'accumulateur (lda = load A, c'est l'operateur) qui est l'un des registres 8bit du CPU, la valeur qui se trouve a l'adresse $FE12 (l'operande) une adresse 16bit en hexadecimal qui pointe vers la fin de la cartouche a laquel le CPU va ajouter la valeur du registre 8bit X (l'index).
donc si y a 0 dans X on va charger dans A la valeur qui se trouve a l'adresse $FE12. Si y a 1 dans X on va charger l'octet d'a coté ($FE13) ect...
L'adressage indexé on l'utilise tres souvent d'autant que dans le CPU 6502 y a pas de registre 16bit qui pourait servir de pointeur direct qu'on pourait alterer a sa guise donc on passe souvent par ce type d'indexation 8bit.

Mais c'est une indexation de 8bit donc ca permet juste de s'eloigner de 256octets au dela de l'adresse orignel indiqué dans l'operande mais l'avantage aussi c'est que pour le CPU la plus part du temps ca simplifie le traitement, il va juste additionner l'index de 8bit au seul 8bit de poid faible de l'adresse 16bit...
Mais lorsque l'indexation est a cheval entre 2 pages ca implique une retenu lors du calcule d'indexation qu'il va cette fois falloir reporter sur les 8bit de poid fort de l'adresse 16bit ce qui va ajouter un cycle d'execution pour cette instruction et peut donc te poser des problemes un peu imprevisible car ca dependera donc de la facon dont tu as aligné tes datas (faut préciser aussi que par commodité on ne manipule pas directement les adresses en general mais des labels, des mnemoniques, qui sont des mots qu'on choisie et qu'on associe a des zones de code et de data et c'est ensuite au compilateur d'associer des adresses a ces mots donc on ne visualise pas directement ces adresses quand on code).

Je vais prendre l'exemple qui m'est arrivé (y a deja quelques semaines).
Mon kernel qui affiche les aliens doit a chaque nouvelle ligne de balayage charger la ligne du sprite correspondant donc bien sur j'utilise un adressage indexé avec comme operande l'adresse originel du sprite puis comme indexe la ligne du sprite a afficher (0,1,2,3,4,5,6 ou 7).
Il se trouve que j'ai un sprite (8 octets) qui se trouvait pile entre 2 pages, genre il demarre a $F0FC et termine a $F103 donc on passe de la fin de la page $F0xx au debut de la page $F1xx (y a 16 pages sur une cartouche 4k) du coup la seconde moitié de mon sprite s'est retrouvé decalé de 3 pixels (un cycle CPU = 3 pixels de deplacement du canon a electron).
Heureusement c'est asser simple a regler. On peut indiquer au compilateur a quelle endroit de la cartouche on veut placer ceci ou cela , donc j'ai forcé l'alignement de mes datas sur une page precise ($FE00). J'ai pour l'instant reservé juste les 2 dernieres pages de la cartouche pour mes datas.


Mais y a pire, le probleme peut se poser aussi pour du code. J'evoquais les branchements conditionnels qui prennent un cycle de plus quand le branchement doit etre executé mais ils prennent un second cycle de penalité si ce branchement n'est pas sur la meme page (donc un branchement conditionnel classic peut prendre 2,3 ou 4 cycle selon le contexte) pour les meme raison que précedement.
Le branchement conditionnel utilise donc aussi un indexe de seulement 8bit, la seul difference c'est qu'il est signé donc ca permet de faire un branchement jusqu'a 127 octets en avant ou 128 octets en arriere, alors que l'adressage indexé classic c'est 256 octets en avant.

Et il se trouve que j'ai eu aussi ce probleme y a quelques jours, un truc de dinge.
Le branchement d'une routine strategique qui sert justement a  a selectionner un moment precis du balayage horisontal pour ensuite positionner un sprite et qui donc est une routine de timing s'est retrouvé pile entre 2 pages alors que c'est une boucle de seulement 2 instructions! Y avait une instructions a la fin d'une page et l'autre instruction au debut de l'autre et du coup le timing etait faussé et le positionnement du sprite aussi   
C'est asser imprevisible car t'es tout le temps en train de modifier et ajouter du code ce qui deplace tout le code qui suit. Ici je me suis juste contenté d'ajouter du code, vouloir aligner strictement certain bout de code ca serait des contraintes plus qu'autres choses. Faut juste garder a l'esprit que ca peut arriver.

Heureusement dans les 2 cas j'ai vite cerner d'ou venait le probleme et maintenant je suis prevenu.

J'ai integré le joueur toujours en respectant les codes graphiques du jeu d'arcade et j'ai donc ajouté aussi le tire du joueur.
Quand le missile traverse les lignes d'aliens il y a 2 types d'affichages differents (quand il traverse les lignes d'alienes et quand il traverse les lignes intermediaire entre les aliens)
J'ai reussi a bien gérer ces transitions sans que ca se voit mais il a fallu quand meme que je modifie un peu mon ram-kernel, heureusement ca n'a pas ete des modifications lourde de consequence. C'etait ma crainte mais au final j'ai juste eu a remplacer une instruction par une autre et changer l'ordre de certaine instructions, sans consequence.
Et j'ai reussis a le faire en economisant les 5 octets de RAM tampon que j'avais prevu d'utiliser pour l'affichage du missile en zone aliens (grace au faite que j'ai encore du temps CPU dispo entre les lignes aliens)

la ROM V0.1
http://www.petit-fichier.fr/2014/01/14/siv0-1/

J'ai ajouté de facon aleatoire des tires aliens juste pour tester l'affichage de 2 missiles simultanés sur la meme ligne comme ca sera le cas au final. Donc quand le joueur ne tire pas alors les missiles aliens sont affichés normalement mais quand le joueur tire alors les missiles aliens et joueur sont affiché en flickering en alternance comme prevu, ca marche bien et sur mon plasma ou ma vieille TV ca reste discret (comme dans la version officiel 2600).

J'ai continué a ameliorer l'affichage des missiles car sur les 14 kernels que traversent les missiles y avait encore des transitions bugé dans la partie inferieur que j'avais pas bossé (juste au dessus du joueur, au niveau du joueur et en dessous du joueur, et aussi tout en haut de l'ecran) maintenant c'est nickel. Restera a ajouter encore les boucliers et donc encore de nouvelle fragmentation vertical de l'affichage a gérer.

Mais surtout j'ai ajouté les tests de collision avec les aliens et on peut donc maintenant les eliminer et donc commencé a vraiment tester le jeu. J'ai aussi ajouté l'acceleration des aliens au fure et a mesure qu'on les elimine.
J'ai deja commencé aussi a calibré au mieux par raport a la version arcade. Amplitude de deplacement joueur et aliens, vitesse de deplacement, vitesse des missiles.
Ca ressemble deja pas mal a la version arcade.

Pour ceux qui veulent chercher des bugs
ROM V0.2
http://www.petit-fichier.fr/2014/01/15/siv0-2-1/

Ce soir j'ai ajouté le deplacement vertical (avec l'amplitude qui s'adapte aux nombres de ligne de front eliminées comme pour les deplacements horisontaux). L'amplitude vertical comme l'amplitude horisontal est strictement celle du jeu d'arcade

http://www.petit-fichier.fr/2014/01/16/siv0-3/

hey ! tu ne dors jamais ?

la programmation c'est le soir, c'est la regle   

upsilandre a écrit:

Ce soir j'ai ajouté le deplacement vertical (avec l'amplitude qui s'adapte aux nombres de ligne de front eliminées comme pour les deplacements horisontaux). L'amplitude vertical comme l'amplitude horisontal est strictement celle du jeu d'arcade

http://www.petit-fichier.fr/2014/01/16/siv0-3/

C'est déjà fun à jouer

Respect c'est ultra propre quand on sait ce qu'il y a derrière, j'arrive pas à trouver un petit détail qui cloche. (les tirs sont vraiment très clean) En plus avec tes explications j'ai l'impression de comprendre ce qu'il se passe en même temps que je joue 

j'ai la flemme pour l'instant de continuer sur la VCS donc je vais commencer a feuilleter les documents NES pour changer

une petite doc de base qui resume un peu le hardware
http://nesdev.com/NESDoc.pdf

mais c'est plus fort que moi, j'aime pas me contenter des descriptions logiques des systemes, j'ai toujours besoin aussi de decrypter le shema physique pour faire le lien entre les 2, je trouve que ca aide a comprendre les choses (les relations réel entre les composants, le mapping de l'adressage...)
http://nesdev.com/Ntd_8bit.jpg
un petit shema comme ca me suffit pour m'occuper pendant 1 heure, je me regale juste avec ce genre de truc

niveau doc ca a l'aire extrement bien fournis, y en a des dizaines. de quoi bouquiner pendant des semaines avant de sentir le besoin de passer a la pratique a mon avis

Je réitère ce que je t'ai déjà dit, tu est un ingé qui s'ignore... toi t'est passé au travers du système éducatif (en gros pas dans le moule).

Mes premieres impressions sur le hardware en vrac.
L'idée c'est d'evoquer le hardware NES par comparaison a un référant qui est l'atari VCS (2600). Je trouve ca bien plus interressant de procedé par comparaison pour mettre les choses en perspective et c'etait le bute de la demarche depuis le debut. constater comment les choses ont progressé de proche en proche et de generation en generation (ca sera la SNES ensuite)


Deja l'aire de rien le hardware de ce genre de console est plus complexe a appréhender que les equivalents micro qui ne sont au final qu'un CPU couplé a de la RAM. Sur une machine comme la NES y a tout un tas de customisations et fonctions cablés qu'il faut dabord assimiler et un mapping memoire asser complexe et pas tres intuitif.
Mais une fois tout ca bien assimilé le bute est quand meme au final de te simplifier la production de jeu par rapport a l'equivalent micro-ordinateur.


Le premier constat qu'on peut faire sur la NES c'est ce privilege d'avoir pu entierement customiser le CPU. L'atari VCS a juste reprit un cpu existant et les customisations se sont concentré sur le TIA (GPU) et le chip I/O.
La NES est deja une nouvelle etape dans le paradigm consoles puisqu'en plus d'avoir un vrai GPU custom on a un CPU custom.

Le CPU a donc la meme base 6502 que l'atari VCS avec donc ses differences et customisations:
--  La customisation a permis d'integrer le generateur de son dans le CPU (qui etait dans le GPU de la VCS) et il est nettement plus avancé que sur la VCS  
--  les inputs des pads passent aussi directement par le CPU
--  y a une fonction DMA, une sorte de macro-instruction qui permet de copier une page complete de la WRAM (la ram CPU) vers la "sprite-ram" integré au PPU (GPU de la NES). ca permet pas de liberer le CPU (le CPU est inutilisable pendant cette phase DMA) mais par contre ca le fait bien plus vite qu'en le faisait soit meme avec des instructions CPU, j'ai pas fais le calcule précis mais ca doit consommer dans les 5x moins de cycle CPU.
--  le bus d'adressage du 6502 est complet contrairement a celui de la VCS qui etait emputé. celui de la VCS etait limité a 13bit et donc une plage memoire adressable de 8Ko (4Ko de ROM et 4k pour le reste). celui de la NES est full 16bit avec donc une plage adressable de 64Ko qui est le maximum pour le 6502
--  la frequence est 50% superieur a celui de la VCS (1.8mhz vs 1.2mhz) ce qui fait pas beaucoup plus sauf que sur la VCS pendant la phase d'affichage le CPU est busy a 100% ce qui n'est plus le cas sur la NES donc au final en cycle CPU disponible on doit plutot etre a 6 ou 7x
--  le CPU integre une interruption NMI directement cablé sur le signal VBLANK du PPU, donc la fin d'affichage peut lancer directement un sous-programme dans le CPU ce qui peut etre pratique. sur VCS c'etait a toi de compter pour savoir quand demarre le Vblank et c'etait a toi de faire la Vsync (mais a cause de ca t'avais un timer asser cool dans le chip I/O de la VCS, y en a aucun dans la NES)
--  y a aussi un truc en moins, il n'y a plus les instructions BCD (binaire codé decimale) qui permettaient de simplifier la gestion de l'affichage d'un score ou d'un timer en decimale et qui etait present dans le CPU de la VCS. aparement ces instructions impliquaient des droit de brevet particulier donc ca serait un choix economique, un peu dommage.

Voila en gros les differences niveau CPU qui sont quand meme asser nombreuses. avec la NES on est vraiment a 100% dans le paradigm console

Niveau RAM et ROM on a aussi sont lot de difference. Je vais juste evoquer la configuration "standard" car la NES est asser evolutive par l'intermediaire des cartouches pas seulement grace au mapper de plus en plus evolué dans les cartouches mais aussi parce que le port cartouche a ete visiblement pensé pour permetre de faire evoluer le hardware de la console contrairement a la VCS et ca aussi c'est un element important a signaler je pense.

Ici le port cartouche est sensiblement plus complexe (60 pins contre 24 sur VCS) avec un cablage qui anticipe pas mal de scenarios, notement l'ajout de RAM qui est prevu (la ou sur la VCS l'ajout de RAM s'est fait grace aux mapper et a de la bidouille car par exemple le signal R/W du CPU n'est pas cablé sur le port cartouche, c'est embetant), la possibilité de piloter le mirroring de la VRAM a partir de la cartouche pour selectionner le type de scrolling (j'y reviendrais peut etre), meme le son produit par le CPU passe par la cartouche avant de revenir et sortir de la console (avec donc la possibilité j'imagine d'avoir un chip audio custom dans la cartouche). c'est interressant de decortiquer le cablage


Revenons a la RAM (en configuration standard sans extension cartouche)
Dans la NES le CPU et le GPU ont chacun leur chip de RAM 2Ko (c'est le meme chip dailleurs)
donc 2Ko de RAM du coté CPU (contre seulement 256 octets sur VCS) et 2Ko de VRAM du coté PPU (contre rien du tout sur la VCS)
a cela s'ajoute encore 256 octets de RAM integré au PPU pour la gestion des sprites. au total ca fait deja 17x plus de RAM que sur VCS


la VRAM est adressable uniquement par le PPU, le CPU ne peut pas l'adresser directement mais peut quand meme y acceder (et devra le faire) en passant par des registres du PPU qui servent de port.
Du coup comme c'est pas un adressage direct ca demande plusieurs instructions CPU (faut dabord charger le registre d'adresse et en 2x puisque les adresses sont 16bit et le CPU est 8bit) et faut plutot attendre le Vblank pour que le PPU soit au repos.
De la meme facon le CPU peut acceder indirectement a la Sprite-RAM interne au PPU en passant par les registres PPU adequates (mais c'est plus simple car la c'est un adressage seulement 8bit vu que la Sprite RAM fait seulement 256 octets et il y a aussi la fonction DMA dédié dans le CPU pour simplifier encore plus les choses)



Pour ce qui concerne la configuration de la ROM dans la NES la aussi y a des differences asser majeur.
Deja le CPU et le PPU ont chacun leur ROM dédié sur la cartouche (plus tard sur des consoles plus evolué meme le chip audio aura sa propre ROM) on peut dailleur le constater sur le port cartouche ou passe a la fois le bus d'adressage du CPU et celui du PPU.
la ROM connecté au bus CPU se nomme PGR-ROM et la ROM connecté au bus PPU se nomme CHR-ROM.

le CPU peut adresser 32Ko de PGR-ROM. Dailleurs ils disent plutot 2x16Ko. je pense notement parce que les 16Ko les plus haut sont les seuls a etre accessible par le chip audio du CPU donc ils ont pas tout a fait la meme fonction et puis c'est je pense pour prendre l'habitude de diviser l'espace memoire en plusieurs bank car le bank switching sera vite un passage obligé pour etendre l'espace memoire et quand tu fais du bank switching vaut mieux pas tout switcher d'un coup, vaut mieux switcher une bank ou n'est pas le code qui est actuellement en train d'etre executer c'est plus simple donc par convention ca sera souvent des bank de 16Ko (voir 8Ko)
Cette PGR-ROM n'est evidement pas accessible par le PPU


le PPU lui peut adresser seulement 8Ko de CHR-ROM qui sont en faite 4Ko de table de pattern pour les decors (donc tous les tiles 8x8 qui serviront ensuite a composer les decors en les assemblant a sa guise) et 4Ko de table de sprite (des tiles 8x8 qui serviront a composer les sprites)


Donc si on "triche" pas et qu'on utilise le hardware par defaut sans mapper dans la cartouche ont est limité a seulement 40Ko de ROM au total. Soit 10x + que sur VCS mais ca reste quand meme tres peu.
Super Mario utilise ce type de cartouche, 32Ko de PGR-ROM + 8Ko de CHR-RAM (Donkey kong c'est 16Ko de PGR-ROM et 8Ko de CHR-ROM)
On devine bien que les 8Ko de CHR-ROM pour les graphismes deviennent vite etroit. heureusement les mapper dans les cartouches vont permettrent de facilement exploser ces chiffres et la y a 2 ecoles qui se cotoie de facon relativement egale j'ai l'impression.

D'un coté on a la possibilité de faire du bank switching avec le CHR-ROM et donc de cumuler par exemple 16 bank de 8Ko et d'avoir donc 128Ko de CHR-ROM pour les graphismes ou alors l'autre ecole c'est de tout miser sur le PGR-ROM avec donc un gros bank switching sur le PGR-ROM et de remplacer les 8Ko de CHR-ROM par 8Ko de CHR-RAM que le CPU poura alors remplir a sa guise a partir des data du PGR-ROM et avec donc plus de flexibilité dans la facon de composer les tables de pattern et de sprite.
Selon le type de jeu c'est plutot l'un ou l'autre qui sera choisie (un Zelda c'est 128Ko de PGR-ROM et 8Ko de CHR-RAM, un super mario 2 c'est 128Ko de PGR-ROM et 128ko de CHR-ROM. je sais maintenant dechiffrer le header des fichiers ROM donc je peux donner la configuration pour n'importe quelle jeu)

et sachant qu'on peut aussi ajouter 8Ko de WRAM dans la cartouche pour le CPU directement adressable pour completer les 2Ko de WRAM, y a une plage memoire reservé a cette usage mais couplé a une pile elle sert surtout pour les sauvegardes je crois.

Voila en gros la configuration memoire de la NES mais au niveau du mapping c'est encore plus complexe que ca mais ca serait un peu too much de rentrer dans les details.

le PPU lui est donc l'element le plus important, pour le coup c'est un vrai GPU console, vraiment cablé pour faire du scrolling de background et animé des sprites chose que les micro ne pouvait qu'emuler en software, c'etait le principale atout des consoles.

Pour faire l'analogie avec la VCS je dirais que le PPU est un vrai GPU 2D alors que le TIA de l'Atari VCS etait aussi un vrai GPU "console" mais un GPU 1D.
Si on met le CPU en OFF alors le PPU continuera de facon autonome a afficher une image complete a l'ecran (mais statique) alors que sur la VCS si on met le CPU sur OFF le TIA ne sera capable d'afficher qu'une seul ligne qu'il va repeter sur tout l'ecran, d'ou l'appellation de GPU 1D que j'ai trouvé et que j'aime bien pour illustrer cette difference.

le fonctionnement du PPU est asser simple a résumer. le PPU construit une image 256x224 en assemblant des tiles qui sont des petites briques graphiques de 8x8 pixels.
il construit un background a partir de ces tiles et par dessus ca il ajoute les sprites (64 sprites par ecran, 8 par scanline) qui sont eux meme des tiles 8x8

l'endroit ou sont stocker la representation graphique de ces tiles sont les 8ko de CHR-ROM (ou CHR-RAM) qui se trouve sur la cartouche.
4ko pour les 256 tiles des sprites et 4Ko pour les 256 tiles du background qu'on assemble ensuite comme on veut.

Pour indiquer au GPU ou se trouve a l'ecran chacun des 64 sprites et avec quelles attributs y a les 256 octets de SPR-RAM integré au PPU qui sont dédié a cela. (4 octets par sprite, 2 pour les coordonnées x,y sur l'ecran, 1 pour indiquer a quelle tile il est associé et 1 pour ses attributs d'etat)

Mais reste a indiquer au GPU quelle tile afficher a quelle endroit pour construire le background. Ca c'est le role des 2Ko de VRAM qui sont en quelque sorte le framebuffer.
il faut un octet pour pointer l'un des 256 tiles de la bank et donc 1Ko pour decrire un ecran complet qui se compose alors de 32x30 tiles. Comme y a 2Ko on peut stocker 2 ecrans dans la VRAM

En fait le PPU travaille comme si il avait 4Ko de VRAM donc comme si il avait 4 ecrans.
Les 2 premiers Ko de VRAM decrivent 2 ecrans cote a cote a l'horizontal et les 2 suivant sont virtuellement placé en dessous des 2 premiers ce qui donne un espace de 2x2 ecrans dans lequel le GPU peut scroller horizontalement et verticalement. les 4Ko et donc les 4 ecrans se repartissent donc comme cela dans l'espace ecran virtuel
1 2
3 4

Sauf que physiquement il n'y a que les 2 premiers Ko dans la console (donc l'ecran 1 et 2)
Mais quand on regarde de plus pret comment le bus d'adressage du PPU est cablé sur la VRAM on remarque entre autre que la ligne d'adressage 10 et 11 qui sorte du PPU passent dabord par le port cartouche avant de rejoindre la VRAM de la console et donc le cablage de la cartouche va pouvoir intervetir la ligne d'adressage 11 avec la 10 ainsi quand le PPU va vouloir fraire un scroling vertical (donc un scrolling entre l'ecran 1 et 3) et va donc s'adresser au 3eme Ko de sa VRAM (qui physiquement n'existe pas) grace a se cablage il sera rediriger vers le 2eme Ko de la VRAM qui lui existe bien et donc pourra faire un scrolling vertical. Le simple cablage de la cartouche peut alors modifier le mapping memoire du PPU.
Ca veut dire que pour une cartouche basique sans extension ni mapper alors c'est le cablage de la cartouche qui défini si le jeu sera plutot calibré pour du scrolling vertical ou horizontal.

Je me suis dailleurs amuser a deviner a quoi doit ressembler le cablage sur la cartouche (a l'extreme droite du schéma) pour un jeu avec un scrolling vertical




on peut voir aussi en bas le chip U2 qui est le chip qui permet au PPU d'utiliser les memes sorties aussi bien pour faire passer les données que l'adressage memoire (donc en alternance) ce qui simplifie la complexité du PPU en economisant 8 pins.
On le voit intercepter les 8 lignes de données qui sortent du PPU pour les transformer en 8 lignes d'adressages selon ce que le PPU lui dit de faire ou pas (ligne ALE)

le CPU a un bus d'adressage de 16 lignes (16bit) ce qui lui permet d'adresser 64Ko de memoire divers et variées. Mais comment on fait pour placer les 2Ko de RAM dans cette espace memoire alors que le chip de RAM n'est connecté qu'a 10 lignes d'adressage du CPU ou comment placer les 8 octets de registre du PPU qui lui meme n'est connecté qu'a 3 lignes d'adressage du CPU.

Y a un chip intermediaire (U3 sur le schema) qui va servir a definir le mapping memoire de ces composants. C'est lui qui va placer les 2Ko de RAM et les 8 registres du PPU quelque part dans l'espace memoire total de 64Ko du CPU pour cela il va intercepter certaines lignes d'adressages du CPU et les interpreter pour decider quand ca concerne ou pas la RAM ou le PPU (pour que la RAM ou le PPU puissent decider eux meme si ca les concernes il aurait fallu que chacun soit relié au 16 lignes d'adressage du CPU).

et comme apres avoir enlever les 32Ko de ROM il reste encore 32Ko d'espace memoire pour tout le reste (RAM, I/O) et que c'est bien plus que necessaire alors ce chip va simplifier le cablage au minimum en interceptant juste les lignes d'adressages 13, 14 et 15 du CPU pour faire le boulot qu'on lui demdande et c'est cette simplification qui crée les effets miroirs dans l'espace memoire.
Par exemple le fait que les 2Ko de WRAM se répete 4x dans l'espace memoire (de 0 a 8ko). C'est a dire que quand le CPU adresse l'octet 0 ou l'octet 2Ko ou 4Ko il s'adresse en faite au meme octet de RAM, chaque octet de RAM a donc 4 adresses differentes par effet miroir et c'est juste une consequence d'un cablage simplifier car dans le cas present on peut se permettre de gacher de l'adressage memoire pour simplifier le cablage et economiser.
Pareille pour les 8 registres du PPU qui eux occupent au final 8Ko d'espace memoire (entre l'adresse 8Ko et 16Ko) et donc se repete 1000fois d'affilé dans l'espace memoire mais ca a permis de simplifier le cablage.


Du coup connaissant le mapping memoire de la console qui est detaillé dans la doc (c'est a dire a quoi correspond chacun des 64Ko de memoire adressable et comment c'est miroré) je me suis amusé a deviner comment est constitué et cablé le chip U3 pour expliquer la repartition dans l'espace memoire et les effets miroirs tel que decrit. C'est un excercice completement gratuit mais j'aime bien comprendre le mapping memoire (et c'est ce que j'aime dans ces machines encore simple c'est qu'on a encore la possibilité de comprendre leur cablage sans avoir vraiment de connaissance en electronique)

j'ai donc fais un zoom sur le chip U3 pour dessiner ce qu'il devrait y avoir a l'interieur. a priori ca reste un chip tres basique avec juste quelques portes logiques. Les seuls gros chips de la console sont le CPU et le PPU et leur chip de RAM respectif.

Spoiler:

Niveau Audio ca a l'aire quand meme pas mal aussi.
y a 4 canaux de generateur de son 4bit (2 pour des ondes rectangulaire, 1 triangulaire et un de "bruit") avec pas mal de parametrage (y a quand meme 22 registres pour le chip audio. c'est presque plus compliqué a assimiler au premier abord que la partie GPU, faut dire que je m'y interresse moins aussi)
Bien mieux que les 2 canaux avec un generateur de son 1bit basique de la VCS

et surtout j'ai découvert avec surprise qu'il y a aussi un 5eme canal qui est un canal PCM/DMC pour jouer de vrai sample qui se trouve sur la cartouche. alors c'est sure c'est pas du sample 16bit, c'est du sample 7bit mais ca me parait quand meme pas mal. Je savais pas que la NES pouvait jouer des samples audio.
Je me rend pas compte si avec une resolution de 7bit on peut reproduire une voix numerique.
le probleme c'est qu'il faudrait quasiment utiliser une bank PGR-ROM complete juste pour un bon sample donc peu probable dans de vrai jeu j'imagine mais peut etre pour un ecran titre?

Je me suis interressé un peu a la facon dont est produit la palette et le signal video, c'est pas du tout un domaine que je maitrise (c'est de l'electronique pure) mais c'est un domaine interressant a survoler car ca permet de repondre a certaines questions et effectivement apres une petite enquete ca m'a permis d'avoir des reponses sur divers sujet notement au sujet d'une legende concernant la NES et Myamoto et aussi le pourquoi je n'ai pas pu resister a la Master system a l'epoque au lieu de la NES.
Ca m'a permis aussi de realiser a quelle point la france a ete vraiment un pays unique au monde dans le paysage hardware des consoles. Donc beaucoup de chose a evoquer, je vais essayé de pas etre trop confus



Je vous ai deja parlé du cas de l'Atari 2600 francaise, on a eu en france la pire console au monde a cause de la norme SECAM. Apres un jolie bidouillage que je ne vais pas réexpliqué on s'est retrouvé avec une palette de 8 couleurs au lieu de 128 a l'original ce qui nous a donné des jeux avec des couleurs "particuliere". qui a envie de se baigner dans cette eau?






Mais en plus de cumuler la particularité 50hz de la region PAL (d'un poid tres minoritaire face au mastodon US et Jap de l'industrie jeux video de l'epoque), et celle du SECAM, on etait aussi les seuls au monde a imposer la peritel (ou SCART) sur toutes TV et appareils dès 1980. C'etait obligatoire.
Donc ca fait beaucoup de particularités cumulés pour un seul petit pays et ca nous a donné pas mal de console relativement unique.


Revenons a la NES. Le PPU de la NES n'est pas un GPU "RGB" comme celui de la Master system. il produit directement en interne un signal composite NTSC ou PAL (comme une Atari2600)
Mais en france il etait obligatoire de proposer une sortie peritel or a cette epoque la norme peritel etait aparement une norme RGB exclusive.
Plus tard on poura faire passer un signal composite dans une prise peritel (ce qui malheureusement nous vaudra l'heresie d'avoir entre autre des PS2 ou PS3 en composite sur la prise peritel grace a un simple adaptateur) mais pas a cette epoque.

Du coup Nintendo a ete obligé d'ajouter une petite carte dans sa NES qui va créer un signal RGB a partir du signal composite qui sort du PPU et ainsi sortir un signal RGB sur la peritel.
Un signal composite c'est deja tres laid, celui de la NES etant en plus pas top si on en croit la facon dont il est généré, mais devoir le convertir en RGB dans la console (et de facon un peu archaique a priori) a du degrader encore plus le signal meme si la conversion RGB elle finit par se faire dans la TV d'une maniere ou d'une autre.

Du coup il est reconnu que la NES francaise a le pire signal video au monde (comme l'Atari 2600 dans un autre genre)
WahWah avait fait une video interressante sur le sujet car il est possible de moder une NES francaise pour la transformer en full RGB car il existe un PPU RGB, celui du Playchoice qui est la version arcade de la NES




Mais ca demande vraiment d'etre électronicien (faut remplacer le PPU, le CPU et l'horloge). Et ils ont probablement du tenter d'emuler en RGB la palette NTSC particuliere de la NES ce qui doit pas etre si facile, ca serait interressant de savoir comment ce PPU special est concu

https://youtu.be/Gv5IG8GoY8Y



Tout ca pour dire donc que la NES francaise avait un signal video vraiment pourri... alors qu'en face on avait une Master system qui elle avait un GPU vraiment  RGB. C'est a dire que le GPU sortait uniquement un signal RGB et qu'il fallait ensuite un autre composant pour transformer ce signal en composite NTSC ou PAL et c'etait donc le cas... sauf en france car en france la peritel etait obligatoire et donc le RGB sauf que cette fois on a un GPU vraiment RGB donc cette loi qui etait un fleau dans le cas de la NES devient une benediction dans la cas de la Master system car a priori avec un GPU RGB on peut s'attendre a ce que la version francaise récupere directement le signal qui sort du GPU.

Ce qui peut sembler une evidence ne l'ai pas souvent dans ce domaine donc j'ai décidé de verifier par moi meme en demontant ma Master System.
J'aurais pu me contenter de l'inscription au dos "SEGA MASTER SYSTEM POWER BASE RGB FR" qui deja semblait lever le doute sur le faite qu'on avait encore une fois une version unique au monde mais je voulais etre sur (que ce soit pas juste le resultat d'une double conversion)

et effectivement j'ai pu constater par moi meme que l'emplacement reservé au chip qui sert normalement a convertir le signal RGB en composite est désèsperement vide! a la place on a simplement 3 files soudés qui relient les 3 pins RGB du GPU directement a la sortie video. la MS francaise est full RGB, la classe!

Donc a l'inverse de l'Atari2600 francaise et de la NES francaise qui sont les pires au mondes, la MS francaise est la meilleur au monde (en qualité de signal, faut faire abstraction du 50hz)
Ce genre de configuration 100% RGB a l'epoque c'etait l'apanage de l'arcade et la Master System francaise nous offrait ca dans le salon.
Et a l'epoque quand j'ai découvert la Master system fin 1987 avec The ninja c'est justement ca que j'ai ressenti, j'avais l'impression d'avoir l'arcade a la maison!

C'etait sur ce point le grand ecart avec la NES qui en terme de signal video etait a l'autre bout de l'echelle et inconsciement ca a du jouer.
Faut aussi ajouter a cela que la NES a ete tres mal distribué en france, bien plus vieille que la MS elle a reussit a sortir apres cette derniere en france ala suite d'une premier sortie raté et une seconde par Bandai.
De plus a l'epoque y avait cette politique qui consistait a refourguer dabord tous les vieux jeux au lieu de rattraper le retard. Et la qualité technique des jeux NES est tres dependante de la technologie utilisé dans les cartouches, pour rivaliser techniquement avec la Master system fallait les jeux recent.  
Puis y a les parametres completement random (comme le fait que mon cousin avait acheté la Master system dès sa sortie donc mes premiers contact avec les consoles 8 bits c'etait ca, j'ai touché une NES que bien longtemps apres)

Mais y avait quand meme cette image qui a joué, l'image NES me paraissait d'un autre age (et a raison finallement), je me suis laissé envouté par l'image sexy de la Master system et cumulé aux restes des elements cités plus haut c'etait finallement difficile de resister a la MS en france mais c'etait une situation tres locale finallement, tres particuliere a la france.





Je reviens sur la palette de couleur de ces consoles (a titre indicatif c'est quand meme l'Atari 2600 qui a la palette de couleur la plus large des 3) qui etait aussi tres differente a cause de la facon de les générés.
La master system avait une palette RGB de 64 couleurs.
Chaque couleur de sa palette etait défini sur 6bit: 2bit de rouge, 2bit de vert et 2bit de bleu. Chacun servant alors a definir l'intensité de l'onde R,G ou B correspondante et on avait donc 4x4x4 = 64 combinaisons possibles.
on avait donc des couleurs RGB classic tres vivent, saturé/pure. On pouvait avoir un Rouge 100% combiné a un vert et bleu 0%

Sur NES on pouvait pas vraiment avoir de couleur pure/saturé. Les 52 couleurs etaient aussi codé sur 6bit mais cette fois on avait 2bit de luminance et 4bit de chrominance. l'onde du signal video composite etait produite directement a partir de ca. Les 2bit de luminances influencaient sur l'amplitude de l'onde du signal video, et les 4bit de chrominance produisait un déphasage plus ou moins grand de la porteuse (la chrominance d'un signal composite PAL/NTSC est codé par modulation de phase)

De la facon dont sont généré les couleurs il est pas possible d'avoir des couleurs saturées tel qu'avec une palette RGB basique. Tu peux pas avoir un rouge 100% et un vert/bleu 0%, ca demanderait une combinaison luminance/chrominance tres particuliere (alors qu'en RGB c'est un cas tout a fait ordinaire a coder).
A la place on a des couleurs qui sont a peu pret toutes un melange plus ou moins fort des 3 couleurs primaires et donc des choses plus pastel sans couleur RGB pure ce qui n'est pas mal non plus. y a pas forcement de palette ideal mais ca explique la difference (couplé a la difference de qualité de signal). c'etait vraiment 2 images differentes



et c'est la aussi que j'en viens a l'une des legendes autour de la NES et de Myamoto




Moi j'ai souvent lu (et encore dans le livre de Florent Gorges) que la palette de la NES etait particuliere car les couleurs de la palette NES aurait ete sélectionné une a une et pas par un ingenieur mais par un artiste, Myamoto. D'ou ces choix de ton pastelle et de couleurs qui correspondrait mieux au besoin pour représenter un paysage.

Quand on regarde la facon dont est généré l'onde du signal composite de la NES, de facon on ne peut plus basique aparement, avec un signal source 42.96mhz qui va permetre de crée 12 phases differentes (pas une de plus ou de moins) d'une onde NTSC 3.58mhz  (42.96/12 = 3.58) et ces 12 phases équidistantes sont les 12 teintes qui pouront etre selectionner par les 4bit de chrominance de la couleur.
a cela s'ajoute une 13eme teinte qui est l'absence de phase et donc de teinte (le gris) et 4 degrés de luminance (les 2bit) ca donne 13x4= 52 couleurs.

Mais le generateur d'onde qui produit ce signal composite NES ne pouvait pas produire autre chose que ces 52 teintes, y a rien de choisie la dedans, juste le choix d'un generateur d'onde le plus simple possible et qui par defaut donne cette palette (tout comme la palette RGB de la MS qui est aussi une palette par defaut) donc je pense que cette legende est totalement fausse.

Toujours aussi intéressant   

Voila a quoi ressemble ma Master System qu'on pourait qualifier de model "Arcade". Toute la magie est dans ces 3 fils noirs
La france   

Le hardware NES est vraiment sexy. Remis dans le contexte c'est vraiment du bon boulot et dès le debut Nintendo a fait du sur-mesure. Par exemple le CPU etait custom et integrait des features specifiques alors que sur les consoles sega c'etait toujours des CPU standard, la customisation se faisait sur le GPU comme chez les autres aussi (atari, coleco, neogeo...).
Sauf la PC engine qui etait aussi une machine vraiment custom facon NES (en plus les chips graphiques on vraiment ete designé par Hudson Soft si je ne me trompe pas, je crois que c'est justement le devellopement en interne de ces chips qu'ils n'ont pas reussit a revendre a des constructeurs comme nintendo qui les a pousser a faire leur propre console avec NEC, une belle machine)


J'ai jeté un oeil rapide sur la doc Master system. La master system a un fonctionnement asser proche de la NES, 2 pools de 256 tiles de 8x8, 64 sprites par ecran, 8 par scanline, 2 palettes de 16 couleurs affichable (une pour les sprites et une pour le background) donc ca ressemble a la NES mais avec plus de flexibilité sur pas mal de point comme la possibilité de piocher dans les tiles des sprites pour le background ou de piocher dans la palette des sprites pour les tiles du background ou la possibilité de flipper les tiles du background...
Mais le truc qui a mon avis etait le plus gros atout par raport a la NES c'etait d'avoir une palette de 15 couleurs (selectionner parmis les 64) utilisable intégralement par les sprites alors que sur NES t'avais une palette de 12 couleurs pour les sprites mais divisé en 4 palettes de 3 et chaque sprite devait choisir l'une de ces 4 palettes de 3 couleurs et 3 couleurs pour dessiner un sprite c'est vraiment difficile, c'est le plus gros handicape de la NES car tout le reste tiens tres bien la route surtout avec les customisations dans les cartouches.

Mais la Master system avec ses atout avait des graphismes qui pesait plus lourd en taille, tout prenait 2x plus de place (les pattern des tiles, le "frame buffer"...) donc ca pouvait aussi etre un handicape. Les graphismes NES etait tres economique sur ce point (une tile NES c'est 16 octets contre 32 sur master system)
Et notement au niveau du framebuffer en VRAM (on parle plutot de "name table" ici car c'est pas un buffer de pixels mais de tiles) la Master System n'avait la place que pour un seul ecran 256x224 la ou la NES stockait 2 ecrans 256x240 (dans une configuration 512x240 ou 256x480, a l'ecran l'affichage etait 256x224 en NTSC) ce qui offrait certaine commodité.

Pour faire un scrolling on a pas forcement besoin d'un double ecran mais a cause de la gestion par tile il faut au moins avoir une tile de plus (soit 8 pixels) sur le coté et en dessous. Du coup la Master system n'affiche que 192 lignes sur les 224 pour avoir une reserve pour gerer le scrolling vertical et quand tu veux faire un scrolling horizontal alors le GPU cache aussi une bande de une tile de large (8 pixels) sur le coté gauche.
Si vous voulez un bon exemple lancez Alex kid, ca demarre sur un scrolling vertical ou l'on descend puis on tombe dans l'eau et ca passe en scrolling horizontal, le moment ou ca passe en scrolling horizontal vous verrez une bande noir de 8 pixels apparaitre et caché le bord gauche de l'image car la MS va alors utiliser cette espace pour gerer le scrolling a defaut d'avoir un espace memoire plus large. Faite le test c'est marrant de le savoir
Sur NES le trick de cacher une bande de 8 pixels sur la gauche existe aussi (c'est activable) mais est bien plus dispensable vu l'espace framebuffer plus large qu'on peut utiliser en configuration horizontal.

Mais ces sprites MS plein de couleurs avec ce signal RGB pure ca avait quand meme de la gueule comparé a la NES
Niveau audio la NES a l'aire meilleur que la MS (mais la Mark III au japon avait un meilleur chip audio que la MS)

j'ai trouvé quelques details sur la palette du PPU NES version special Arcade et c'est exactement comme je le pensais.
Avec le passage en RGB ils ne pouvaient pas se contenter d'un codage 6bit de la palette comme sur une NES standard ou sur MS car sinon ils auraient eu justement la meme palette RGB que sur Master System et ca n'aurait pas ete vraiment compatible avec les jeux NES existant, il leur fallait passer par un intermediaire.

Donc ce PPU RGB a finalement un codage 9bit de la palette et donc peut générer potentiellement 512 couleurs differentes (comme sur Megadrive ou s'est aussi un codage RGB 9bit) et ainsi il leur est possible de piocher la dedans pour retrouver des teintes proches de celle de la NES standard et reconstituer une table intermediaire de 52 couleurs qui elle sera indexé en 6bit comme pour une NES standard (donc la vrai palette reste limité comme avant).

Mais du coup il se sont fait plaisir et ont constitué 5 palettes differentes de 52 couleurs (voir 64 qui est le vrai potentiel d'un codage 6bit) c'est a dire la palette standard et 4 autres palettes plus vives qui peuvent alors etre selectionner pour remplacer la palette standard au cas par cas.

Si jamais je dois creusé plus loin le hardware NES ca passera forcement par programmer un truc et je me dirigerais probablement vers un portage (partiel) d'un jeu Master system sur NES genre Alex kidd ou The Ninja.

Mais bordel la limite de 3 couleurs pour les sprites NES c'est vraiment une grosse contrainte. J'ai tenté sur le sprite de Alex Kidd qui utilise 7 couleurs et impossible d'en faire une version 3 couleurs. a 5 ca passe bien, a 4 on peut obtenir un truc ressemblant mais 3 couleurs c'est impossible (si vous voulez essayer)

C'est clairement le plus gros handicape de la NES alors que tout le reste est tres bon.
Sans aller jusqu'au 4bpp (4bit par pixel soit 15 couleurs) de la Master system qui est un peu too much au vu de la palette tres limité (dailleurs la Megadrive est resté sur du 4bpp comme la MS, c'etait bien suffisant) mais juste du 3bpp (7 couleurs) pour les sprites ca aurait deja tout changé.
7 couleurs tu peux tout faire, 3 couleurs tu peux rien faire, y a un gouffre entre les 2. C'est domage parce que en 3bpp au lieu de 2bpp la NES aurait ete une tuerie et n'aurais rien eu a envier a la MS mais remis dans le contexte c'etait difficile.

3 couleurs, tu va en chier.
Tu n'aura pas le choix que d'avoir une couleur de contour de sprite qui sera aussi ta couleur la plus sombre, une couleur intermédiaire, pour une partie des fringues et une couleur chair qui pourra aussi être la couleur claire de ta couleur sombre et intermédiaire (pis bon il y a aussi la technique des gradient, mais sur des sprites aussi petits, le résultat n'est pas assuré).
Prend le sprite de mario 3 en exemple pour te donner une idée. Mais bon après ne te fais pas trop chier avec le côté cosmétique, c'est surement pas là que tu vas t'éclater le plus!