Hardcore Retrogaming

[upsilandre]

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

Tu verra que c'est bien plus facile quand les aliens descendent
http://www.petit-fichier.fr/2014/01/16/siv0-3/

[Hobes]

En effet c'est mieux ! Cela dit s'il y avait eu les bases destructibles je suis pas sûr que j'aurais terminé le deuxième round :crazy:

[upsilandre]

Ajouter les boucliers destructibles (qui t'aident autant qu'ils te gènent) ca va etre un autre truc compliqué, deja ca consome de la memoire (faut memoriser les alterations) et puis je pourrais pas mettre 4 gros bouclier comme en arcade (qui dailleurs prennent vraiment beaucoup de place voir trop)
Par contre je veux pas faire des petits boucliers de 8 pixels comme sur la version 2600 (y a 3 boucliers de 8 pixels de large) qui du coup ressemble pas du tout a la version arcade et font tout juste la largeur du player.
Je veux bien faire un compromis sur le nombre et en mettre moins mais faut qu'il ressemble a la version arcade et pour cela il faut qu'il fasse le double de largeur (16 pixels) du coup il est probable que je puisse en mettre seulement 2. C'est a la fois un probleme d'affichage et de RAM, en RAM je m'en sort mieux que prevu donc faut voir.
Je vois 3 possibilités pour des boucliers de 16 pixels de larges:
-  2 boucliers "low-res" au niveau de la destruction (c'est a dire une taille de pixels destructible qui est doublé) ca serait 8 octets de RAM
- 2 boucliers avec une destruction hires ca donnerait 16 octets de RAM
- 3 boucliers avec une destruction hires ca donnerait 24 octets de RAM

le scenarios 3 boucliers low-res me plairait bien comme compromis mais il me parait pas possible a priori (tout comme le scenarios a 4 boucliers)
Mais vu les belles economies que j'ai reussi a faire sur la gestion des aliens (j'etais mal partie et au final en faisant des choix differents j'ai economisé une quinzaine voir une vingtaine d'octet) je pourais peut etre m'offrir le luxe de dépenser 24 octets dans les boucliers (c'est a peu pret le tiers de la RAM dispo pour le jeu)

Un truc qu'on remarque pas aussi c'est que mon sprite du joueur fait pas 8 pixels de large mais 9 pixels, j'ai grugé en combinant un sprite + un missile collé au sprite pour ajouter un pixel de large (et histoire toujours de compliquer les choses). Tout ca pour mieux coller au proportion du jeu d'arcade et au visuel (tout comme pour les aliens ou je tenais notement a ce que la race la plus haute soit plus petit que les autres, les proportions sont importante pour respecter le jeu original et le gameplay et faire la difference avec la version 2600) donc j'y tiens aussi pour le bouclier, je veux des boucliers de 16 pixels de large.

[upsilandre]

Ca commence a me manquer donc j'ai commencé a feuilleter les documents de développement NES pour changer

une petite doc de base qui resume un peu le hardware


mais c'est plus fort que moi, j'aime pas me contenter des descriptions logiques des systemes, j'ai toujours besoin aussi de decrypter un minimum le shema physique pour faire le lien entre les 2, c'est jamais necessaire mais 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 fais plaisir juste avec ca

Niveau doc ca a l'aire extrement bien fournis, y en a des dizaines. de quoi bouquiner pendant pas mal de temps.
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 assimiler et un mapping memoire asser complexe et pas forcement tres intuitif.
Mais une fois tout ca bien assimilé ca va au final te simplifier la production de jeu par raport a l'equivalent micro-ordinateur.

Quand j'aurais suffisement avancé je vous ferais un petit resumé. Le bute n'etant pas de decrire les specs de la machine dans l'absolu mais plutot de faire une description par comparaison avec l'Atari VCS. Je trouve ca plus interressant d'evoquer justement quelle sont les differences, ce qu'aporte une NES par rapport a une Atari VCS que j'ai deja detaillé et qui sert maintenant de referent zero et ainsi constater comment les choses evoluent de proche en proche, de generation en generation.
C'est ma demarche initial de proceder par comparaison (NES > SNES ensuite) car c'est le seul moyen de mettre vraiment les choses en perspectives.

[upsilandre]

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

[upsilandre]

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.

[upsilandre]

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)

[upsilandre]

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.

[upsilandre]

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?

[upsilandre]

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'origine 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





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 fils 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.

[upsilandre]

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    

[Hobes]

J'ai enfin tout lu. La partie technique sur les différences Nes/Atari VCS, je n'ai pas tout saisi (vraiment trop technique pour moi) par contre très intéressant tout ce qui concerne la Nes et la Master System en France. C'est là qu'on se dit qu'une uniformisation des normes a du bien aider pour sortir les consoles sur certains marchés.

[upsilandre]

c'est bien t'es courageux. mais moi non plus je comprend que la moitié des documents que je lis en général mais j'aime ca.

Dommage quand meme que le RGB n'a jamais ete standard. C'est vrai qu'il y a peu de vrai source RGB, en general les sources sont elle meme plutot composite luminance/chrominance (que ce soit la TV hertzienne, une cassette VHS....) donc ca n'etait effectivement pas tres utile d'avoir du RGB pour la grande majorité des sources video (meme un bluray ca reste encoder en luminance/chrominance parce que le Mpeg aime bien ca)
Mais pour le cas particulier des consoles de jeu si le RGB avait ete un standard universel on y aurait vraiment gagné d'autant que le RGB c'est au final tres simple comme choix technique (c'est le language de l'ecran lui meme) donc c'est dommage

Je savais pas mais le SECAM (invention francaise, notement la ligne de retard pour la chrominance qui est virtuellement repris dans quasiment tous les systemes video aujourd'hui, le format 4:2:2) on a failli en faire un standard en chine et au japon a la place du NTSC.
Imagine si le SECAM avait ete la norme de la france et du japon, on aurait ete des privilegiés

Heureusement aujourd'hui on a le HDMI et on en a finit avec toutes ces histoires. les plus jeunes ne sauront jamais le bordel que ca a ete (devoir attendre une console comme la NES pendant 3 ans et demi pour avoir un truc avec un signal video pourri et en 50hz, ils peuvent pas imaginer toute cette souffrance )

[upsilandre]

Vous etiez plutot des joueurs NES ici?
Moi j'ai pas trop connu la NES a part chez des potes vite fait, c'est un peu triste. J'ai une vieille Famicom chez moi juste pour l'objet

[Hobes]

Master System pour ma part. Mes oncles avaient une NES avec Duck Hunt, Mario et Double Dragon. De bons souvenirs mais assez anecdotiques par rapport à mes journées sur Sonic ou Alex Kidd. Par contre je dois être le seul vu qu'une majorité des joueurs avaient la console de Nintendo (et je sais que c'est le cas de Pippo et Futch entre autre).