Hardcore Retrogaming

dailleurs la master system avait un bios sur 8Ko de ROM et donc il se passe quelque chose quand t'allume la machine sans jeu alors que sur NES j'ai pas trouvé de Bios donc j'imagine qu'il se passe rien.

Globallement la Master system avait bien plus de chip: la ROM du bios, un DAC externe qui sur NES est integré au PPU, 24Ko de RAM contre 4Ko dans la NES qui misait sur les cartouches, un vrai chip audio independant qui sur NES est integré au CPU.
Donc quand elle est sortie au japon elle devait couter nettement plus chere que la famicom du coup ils ont finit au moins par zapper le chip audio Yamaha qui devait etre asser costaud (notement il embarque des sortes de sample d'instrument facon midi, une quinzaine) et le remplacer par un sound chip integré au GPU, le meme sound chip que Sega utilisait deja pour la SG-1000/MarkI qui elle meme est une sorte de colecovision japonaise sortie en meme temps que la NES.
Donc en 1987 on se retrouve chez nous avec le sound chip de la colecovision de 1982

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 Master System 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.

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.

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 a écrit:

Je me suis amusé a tester des jeux NES qui ne sont sortie qu'en PAL pour voir si certain avait exploité le fait qu'en PAL le Vblank dure 3x plus longtemps qu'en NTSC (et donc plus de temps pour modifier la VRAM)

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.

Donc sur Master System Astérix est animé comme un dessin animé à 25 images par seconde?

Ton projet pour Alex Kid c'est d'adapter tout le jeu sur NES ou seulement le premier niveau ? Je me demande si les véhicules représentent une difficulté particulière.

c'est sur NES Asterix.
Le deplacement du sprite se fait a 50fps mais l'animation du personnage elle est a 10fps, tu peux animer a 50fps y a aucun probleme a ca mais ca donnerait une anim trop rapide car y a pas asser de frame d'animation pour décomposer le mouvement, ca prendrait trop de memoire.


Pour Alex kidd je vise juste le premier level (et sans musique pour l'instant car c'est aussi un gros boulot). Les vehicules ca serait compliqué effectivement a cause du nombre de couleur. Mais le premier level est deja pas mal comme defi car il est asser particulier vu qu'il y a une rupture en plein milieu, on change de type de scrolling (vertical puis horizontal), de gameplay (sous l'eau) et d'environnement/ennemis. c'est un bon condensé et puis c'est celui qui est dans la memoire collective

Aujourd'hui j'ai préparé mes sprites d'alex sous une forme prete a etre integrer dans la table de pattern et finallement j'ai reussis a optimisé plein de truc, au final je peux utiliser mon sprite en 5 couleurs sans que ce soit réelement pénalisant par rapport a la version MS donc je vais pouvoir partir sur cette bonne base d'un bon sprite ce qui pour moi etait le plus important.
Pour le reste par contre faudra faire avec la limite de 3 couleurs donc ca sera moins beau.
Préparer et optimiser les sprites c'est amusant, commencer a programmer (toujours en assembleur pour ma part meme si y a d'autre possibilité) ca sera autre chose, surtout le debut ou tu sais que ca va forcement etre galere le temps de prendre ses marques. Faut deja arrivé a se motiver pour passer cette etape.

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.

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.

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       





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


encore plus drole   

Une question par rapport à la dernière vidéo (rick rolled) : est-ce simplement une question de place (par exemple si on avait des cartouches de la taille d'un CD, ça aurait été possible de faire un jeu avec ce type de musique) ou est-ce aussi une question de puissance (même avec une énorme cartouche, la NES ne pouvait pas sortir ce type de son avec un jeu qui tourne) ?

Qu'aurait apporté à nos consoles (NES, SMS, MD, SNES, PC Engine, Neo Geo) des cartouches de la taille d'un CD (en dehors de jeux plus grands et d'images fixes façon dessin animé) ? Une meilleure exploitation de leur chip sonore (davantage de voix, des voix de meilleure qualité, notamment sur MD) ? Des graphismes plus variés ? De meilleures animations (plus détaillées) ? Plus de possibilités dans les "tricks" utilisables sur console (comme les tricks utilisés par Treasure sur MD pour lui faire afficher des trucs inimaginables à la base ou encore sur des jeux comme Red Zone qui utilisent la Full Motion Video et de la 3D) ? Bref, est-ce que ça aurait fait une véritable différence ?

Et est ce qu'avec la technologie actuelle (PC surpuissants, internet pour échanger des infos), on aurait pu davantage exploiter le potentiel de ces 8 & 16 bits ?

Merci


EDIT : dans le style que le rick rolled de la NES, voici deux vidéos assez impressionnantes montrant ce que peut sortir la MD :

https://www.youtube.com/watch?v=zG1H_88Vmh0

https://www.youtube.com/watch?annotation_id=annotation_2394949877&feature=iv&src_vid=zG1H_88Vmh0&v=h9WzrJ5OyWA

Upsi te répondra précisément là-dessus, mais pour moi c'est à mon avis les 2. Le Rick Rolled prends à mon avis toutes les ressources de la NES. Ensuite la ROM ça coutait un max de blé à l'époque et les samples sonores étaient surement ce qui coutait le plus de place (pour peu que l’échantillonnage ne soit pas trop destructeur

Je me rappel d'un jeu sur SNES qui avait une intro avec des samples de chants pour faire une chanson complete (un "tales of" il me semble) et c'est un jeu sui était sur les plus grosses cartouches.

Terry a écrit:

EDIT : dans le style que le rick rolled de la NES, voici deux vidéos assez impressionnantes montrant ce que peut sortir la MD :

https://www.youtube.com/watch?v=zG1H_88Vmh0

https://www.youtube.com/watch?annotation_id=annotation_2394949877&feature=iv&src_vid=zG1H_88Vmh0&v=h9WzrJ5OyWA

bof ca reste du son mono 8bit, pas tres different de ce que peut sortir la NES
Sur SNES y a des demo de son PCM 16bit en stereo et 32khz donc la c'est quasiment qualité CD mais ca prend aussi autant de place

https://youtu.be/p_60V8UdYEY

Citation :

Une question par rapport à la dernière vidéo (rick rolled) : est-ce simplement une question de place (par exemple si on avait des cartouches de la taille d'un CD, ça aurait été possible de faire un jeu avec ce type de musique) ou est-ce aussi une question de puissance (même avec une énorme cartouche, la NES ne pouvait pas sortir ce type de son avec un jeu qui tourne) ?

le son PCM 16khz qu'on voit dans les demo non on pourait pas le faire ingame
Les sounchip sont basiquement des generateurs d'onde audio et ils générent des ondes aux formes prédéfinies (rectangulaire, triangulaire, bruit aleatoire) et tu va agir seulement sur quelques parametres du coup l'avantage c'est qu'ils sont autonome dans ce type d'utilisation purement soundchip

le PCM ca veut dire jouer un sample audio et donc ca veut dire qu'il faut alimenter constement en données et contrairement au mode DMC plus légé, le mode PCM n'a pas de DMA c'est a dire qu'ils n'est pas capable d'aller s'alimenter tout seul, c'est a toi de l'alimenter sample par sample (environ un sample par ligne affiché pour du 16Khz) avec le CPU et a toi de gérer le timing donc non tu peux pas faire autre chose pendant ce temps la.

par contre la solution elle est simple, au moins sur Famicom, c'est d'ajouter un soundchip tres basique dans la cartouche (plus basique que ce qui existe dans certain mapper) qui serait juste un seul canal PCM 8bit avec donc sa propre ROM et pour jouer une track audio t'aurais juste a lui indiquer dans un port dédié la bank de depart (sur 16bit) et la durée en nombre de bank (sur 8bit) et ensuite t'aurais plus rien a faire et ca serait une qualité encore superieur a ces demos et t'aurais toute la capacité sonore de la NES disponibles juste pour les bruitages du jeu.
Par contre ca prendrait autant de place q'un MP3 donc faut compter quasiment 1Mo la minute, faudrait au moins des grosses cartouches NeoGeo donc la seul contrainte c'est vraiment ca car d'un point de vue technique y a pas de probleme





Mais si on est sur un scenarios de ROM infini, un scenario ou le cout de la ROM serait disont 10 000x inferieur a ce qu'il etait a l'epoque (mais juste la ROM, pas le reste) alors sur NES on aurait meme pu faire de la video full screen 30fps et son top qualité (sur master system c'est plus compliqué).

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é 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'impose)
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 960 tiles differentes a la fois mais par defaut la NES ne peut en gérer que 256 a la fois
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 (un peu comme avec le temporal AA).
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 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, c'est probablement pas tres compliqué 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

Mais en dehors de ca (ajouter de vrai FMV) In game on pourrait pas faire grand chose de plus que ce qui a ete fait sur les meilleur cartouche NES, ca serait pas tres different.

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

LE CPU

Un element tres interressant de cette machine car asser exotique (peut etre pas autant que celui de la channel F) du coup pas facile a cerner en detail mais j'ai quand meme fait l'effort.
C'est donc un CPU de GI, le CP1610 qui semble ne pas avoir servie a grand chose d'autre que l'Intellivision. Une epoque ou on pouvait avoir des CPU un peu exotique car y en avait beaucoup mais rapidement certain se sont imposé notement dans les jeux video ou on a clairement eu 2 ou 3 familles de machine seulement (la famille 6502, la famille Z80 puis plus tardivement la famille 68000)

le CP1610 a une parenté avec le PDP11. Vous savez les PDP sont ces gros ordinateurs/armoires des années 60/70 utilisé dans les universités. Le plus célèbre etant le PDP1 sur lequel a ete crée le premier jeu video, Spacewars.
C'est un vrai CPU 16bit, y a pas d'ambiguité sur ce point. Tous ses registres sont 16bit (et y en a plus que dans le 6502 de la NES et de la VCS), les operations s'executent en 16bit, son bus d'adressage et de donnée est 16bit.
J'ai bien creusé et y a rien a dire, c'est bien un CPU 16bit et donc selon la nomenclature en vigueur l'intellivision est une console 16bits on ne peut pas le réfuter (si vous voulez briller en société)

Le prix a payer c'est dabord une frequence faible. La plus faible a ma connaissance (si on exclus la console portable microvision) avec 0.9Mhz soit la moitié de la frequence du CPU NES (ou meme Channel F) et 25% de moins que la VCS.
L'autre consequence c'est que pour reduire le nombre de pins du chip le bus d'adressage et de donnée sont mutliplexé dans un seul bus. Ils utilisent le meme bus de facon alternative selon des sequences complexe de plusieurs phases que le CPU transmet a tous les composants via 3 signaux complementaire pour syncroniser tout ca ce qui rallonge evidement l'execution des operations.

Mais la ou ca se complique c'est que le CPU est aussi optimisé pour travailler avec des memoires 10bit (un mot de 10bit ils appellent ca un "decle" et pas un octet) car les opcodes du CPU (c'est a dire le codage de ses instructions) se fait sur 10bit sans doute car 8bit n'etait pas asser pour englober le jeu d'instruction du CP1610 (contrairement au 6502 qui s'en contente) mais que 16bit etait du gachie.
Du coup une memoire 10bit est optimal pour stocker le programme et c'est le cas dans l'intellivision notement pour la ROM du Bios qui est une ROM 10bit de 4 KiloDecle (soit 5KiloOctet) et aussi la ROM utilisé pour les cartouches (du coup les fichiers ROM des jeux en emulation ont une taille plus grande que les vrai. un jeu intellivision qui fait 8KiloDecle ca correspond a 10KiloOctet mais le fichier pour l'emulation fera 16Ko car chaque decle sera remplacer par un mot de 16bit. On le voit tout de suite quand on ouvre l'un de ces fichier avec un editeur hexa)

Ca implique aussi lorsque le CPU travaille avec une memoire 10bit et veut malgres tout charger une valeur 16bit (puisque c'est un CPU 16bit) de devoir activer au préalable avec une instruction supplémentaire un flag particulier qui va permetre ensuite de charger une valeur 16bit a partir de 2 acces 10bits consecutif. Vous comprendrez bien que ca ralentie encore un peu plus l'execution (mais des données 8 ou 10bit suffisent certainement dans la grande majorité des cas pour un jeu intellivision donc pas besoin de s'embarrasser de cela systematiquement)
Mais attention, meme si le CPU est capable de s'adapter a une memoire 10bit ca ne l'empeche pas de fonctionner en full 16bit si il est relier a une memoire 16bit et c'est le cas dans l'intellivision ou le CPU a aussi une RAM systeme composé de mot de 16bit (352) dans laquel il va pouvoir lire et ecrire directement en 16bit (principalement pour y ecrire la table de background utilisé par le GPU qui lui fonctionne en 14bit)
a coté de ca y a une second RAM CPU qui elle est 8bit (256 octet) et qui donc nécessitera 2 acces si on veut lire et ecrire en 16bit.

Tout ca fait que les instructions demande pas mal de cycle d'execution avec en plus une frequence deja faible. L'atout de pouvoir executer des operations 16bit est a mon avis une faible contrepartie car ca doit rarement etre utile sur des jeux intellivision (voir parfois un handicape quand par exemple tu veux juste faire une rotation de bit sur un octet) reste certaines instructions plus evolué qui couplé aux registre plus nombreux que le 6502 peuvent etre sympatique (une autre originalité, le registre PC, program counter, est ici un registre comme un autre sur lequel on peut exectuer des operation arithmetique, de quoi donner des truc bizarres...)

Mais globalement je pense que le CPU de l'intellivision doit probablement se faire latter par celui de l'Atari VCS. Mais etant couplé a un vrai GPU 2D qui laisse donc au CPU tout le temps libre pendant l'affichage fait que c'est pas vraiment un probleme.

T'as pensé montrer ça à Richard (google traduction/reverso) ou à le publier quelque part sur B3D? Ce serait dommage que ça reste juste ici, probablement que ce serait quelque chose que les concepteurs voir.

non c'est tres bien ici, c'est juste des informations qu'on trouve ici ou la (mais en francais pas trop)
mais plus je creuse plus je me rend compte quand meme qu'il y a une vrai histoire du jeu video a raconter du point de vue technologique.
Beaucoup de gens aujourd'hui s'interresse a l'histoire du jeu video, ca devient un domaine tres serieux avec des livres et de court d'histoire mais le jeu video ne peut pas etre dissocier de la technologie, c'est aussi une aventure technologique et y a surement plein de chose a raconter de ce coté la et probablement plusieurs facon de le raconter (selon le public) donc probablement des facon qui n'ont pas encore été tenter, a creuser si un jour j'en fais le tour.
Pour l'instant ca m'interresse moi et c'est deja pas mal mais je pourrais me specialiser sur cette aspect de l'histoire videoludique

Je pense qu'il faudrait au moins l'écrire un jour en Français. Surtout que le style que tu as pour raconter l'intellivision a vachement évolué. Tu es prêt, n'aies pas peur   

Je ne fais que balancer les truc comme ca vient (pour les archiver), y a rien d'ecrit, ca demanderait du boulot de vraiment raconter quelque chose a partir de ca, et surtout faudrait avoir une vision globale donc avoir fait le tour de la question pour commencer a vraiment y reflechir ce qui est loin d'etre le cas.

Pour l'instant ce qui m'interresse c'est juste de repondre aux questions que je me suis toujours posé et il se trouve qu'aujourd'hui on a vraiment un acces facile a toutes les informations sur ces machines, y a presque des wikidev sur toutes les machines qui regroupe les documents d'epoque et le travaille de reverse engineering qui a pu etre fait entre temps principalement pour l'emulation

dailleurs si y avait une autre histoire a raconter ca serait bien celle de ces gens qui font des emulateurs. Je pense que les gens ne se rendent pas compte:
- premierement du boulot de dingue que ca represente car les documents d'epoque ne suffisent pas (et encore quand y en a), y a toujours une grosse part de reverse engineering pour faire de bon emulateur , c'est quasiment sans fin comme boulot
- deuxiement a quelle point ces gens ont une importance capital dans la préservation du patrimoine videoludique. C'est vraiment un media particulier et sans se boulot de dingue on perdrait beaucoup. il est important de préserver le materiel et heureusement aujourd'hui on commence a voir des initiative de creation de musée et d'association mais preserver le matos sur des etageres c'est pas suffisant. La meilleur facon de préserver les jeux et de les rendre accessible ca reste l'emulation

Donc a la limite l'histoire technologique du jeux video pourait se raconter sous cette angles, au travers de ces gens qui comme des fourmis font progresser l'emulation chaque jours. On pourait presque leur eriger une stele
j'aurais adoré faire des emulateurs, peut etre encore plus que des jeux

Je pense aussi que ta chronique devrait aussi être ailleurs qu'uniquement sur le Forum. En plus il y a peu de relecture à faire à part des fautes d'ortho par ci par-là, le style est abordable, ce qui est loin d'être le cas bien souvent sur des explications techniques.
Une chronique sur l'évolution des consoles dans leur aspect purement technique avec les choix du tout CPU au CPU+GPU, ou CPU+DSP.

Ca devrait aussi être intéressant de si dès le départ c'est la demande de microproc ou microchip qui fait la production ou si c'est la production qui aiguille le design du hard ou si il y a les 2, à partir de quand le changement s'est fait.
Ex: le 68000 était un proc très flexible, produit en grande quantité et donc s'est retrouvé dans plusieurs consoles et micro ordi, ensuite il y a eu des version spécifiques à certains designer de hard, mais c'était un remaniement bénin d'un schéma global.
Au contraire le CELL n'aurait jamais vu le jour sans la demande et le travail de Sony et Kutaragi.

Je pense que cet aspect historique de l'industrie du micro proce est aussi part intégrante de l'histoire des consoles.


Et du coup, tu en es où pour Alex Kid?

patataboy a écrit:

Et du coup, tu en es où pour Alex Kid?

Tout est pret. J'ai a peu pret compris comment fonctionne le compilateur ASM6, comment fonctionne le debugger de fceux, j'ai trouver aussi comment integrer les label du code source dans le debuger, comment fonctionne aussi notepad++ (dans lequel j'ai entrer a la main tout le jeu d'instruction du 6502 pour qu'il associe a une couleur) et nes screen tool. J'ai préparé mon fichier batch pour compiler, j'ai mon template de depart pour mon programme avec notement a peu pret toute la phase d'initialisation de la NES, je sais comment sortir un fichier au format rom nes, j'ai deja des fichiers pret a l'emploi pour mes sprites. reste plus qu'a commencer vraiment a coder!

mais je le ferais seulement quand j'en aurais vraiment envie donc quand j'en aurais marre de lire des docs mais y a tellement de truc que j'aimerais creuser.
Revenir un peu sur la channel F et son CPU, aller voir du coté de la Colecovision et du C64 2 machines asser impressionnante pour l'epoque, le ZX spectrum me fait bien marrer aussi avec sa gestion des couleurs par tile sur l'ecran c'est exactement comme si t'avais collé des carré de plastiques transparent de couleur sur ta TV (comme on faisait avec l'odyssey pour ajouter des couleurs), c'est asser grotesque comme choix technique, j'aimerais bien creuser.
je voudrais creuser aussi sur le CPU Z80, j'avais commencé pour la master system mais faut creuser un peu plus car ce CPU a equiper des tonnes de machines de jeu, plus que n'importe quelle autre (MSX, Colecovision, Master system, gamegear, gameboy, ZX spectrum, Amstrad CPC, megadrive et neogeo en copro, en arcade) et c'est une philosophie completement inverse de l'autre cpu du moment, la famille 6502 (Atari VCS, NES, SNES, C64, Apple2, PC engine)
C'est un peu la bataille CISC vs RISC (l'equivalent de la bataille PowerPC vs X86 qu'on a eu plus recement), ca merite de creuser mais a premiere vu le 6502 me correspond bien mieux, ca ma conforter que c'est ladessus qu'il fallait aller (VCS, NES) pour se faire plaisir.

et bien sur j'aimerais aussi feuilleter un peu la megadrive, la neogeo et la SNES, j'ai deja jeter un oeil sur la SNES et sur ces dernieres consoles 2D on atteint un haut niveau de complexité, c'est beaucoup plus compliqué qu'une NES, limite je me demande si le passage a la PS1 n'a pas ete une simplification avec son GPU 3D au fonction tres basique d'autant que sur SNES fallait vraiment optimiser ton code vu le CPU un peu vieillot

J'attends qu'upsi arrive à la PS1   

upsilandre a écrit:

sur SNES fallait vraiment optimiser ton code vu le CPU un peu vieillot

Vieillot et sous cadencé
Le nombre de jeux qui rament alors qu'il n'y a pas grand chose, là ou un jeu MD passe comme une lettre à la poste.

Mégadrive :
- Model Number: MK-1601 (r1), MK-1631 (r2).
- CPU: Motorola 68000 at 7.61 MHz
1 MByte (8 Mbit) ROM Area
64 KByte RAM Area
- Co-Processor: Z80 @ 4 MHz (Not Present in MK-1631)
Controls PSG (Programmable Sound Generator) & FM Chips
8 KBytes of dedicated Sound Ram
- Graphics:
64 simultaneous colors of 512 color pallete.
Pixel resolution: 320 x 224
VDP (Video Display Processor)
Dedicated video display processor
Controls playfield & sprites
64 KBytes of dedicated VRAM (Video Ram)
64 x 9-bits of CRAM (Color RAM)
3 Planes: 2 scrolling playfields, 1 sprite plane
- Sound:
PSG (TI 76489 chip)
FM chip (Yamaha YM 2612)
6-channel stereo
8 KBytes RAM
Signal/Noise Ratio: 14dB


S-Nes:
CPU 65816 16-bit (2.68 / 3.58 Mhz) Picture Processing Unit
System RAM 1Mb
Video RAM 0.5Mb
Cart Size 2Mb - 48Mb
Max Resolution 512 x 448
Colours 32,768 colours, 256 at once
Sprites 128 max sprites at once, 64 x 64 max sprite size
Video Output PAL version outputs RF, RGB and S-Video.
Sound 8-bit Sony SPC700, 8 channels
Features 2 controller ports, Ext. port, Mode 7, DSP chips on certain carts



D'ailleurs les composant de la MD et de la Neogeo sont plus proche que la Neo-Geo et la Snes
La différence viens surtout de la taille de la ROM sur la cartouche et de la fréquence

Neo Geo AES/MVS:

- Processor
Main processor: Motorola 68000, often produced by another manufacturer, running at 12 MHz
Co-processor: Zilog Z80 running at 4 MHz. This is also used as an audio controller.

- Memory
Main memory (used directly by 68000): 64 KB
Main video memory : 84 KB
Video memory: 64 KB (32 KB x2)
Palette memory : 16 KB (8 KB x 2)
Fast video RAM : 4 KB (2 KB x 2)
Sound memory (used directly by Z80): 2 KB

- Display
Display resolution: 320×224 (many games only used the centermost 304 pixels)
Color palette: 65,536 (16-bit) (Not RGB565, but RGB666, where the lowest bit of each channel is shared with one bit[8])
Maximum colors on screen: 4,096 (12-bit)
Maximum sprites on screen: 381
Minimum sprite size: 1×2
Maximum sprite size: 16×512
Maximum sprites per scanline: 96
Background layers: 0
Aspect ratio: 4:3
A/V output: RF, composite video, RGB (with separate 21 pin RGB cable FCG-9).

- Sound
Sound chip: Yamaha YM2610
4 FM channels, 4 operators per channel
3 SSG channels
1 Noise channel
7 ADPCM channels
Work RAM (sound): 2KB
Sound ROM 128KB on-board (only less than 32KB used)
up to 512KB sound ROM on cartridges

Bon je termine quand meme l'Intellivision pendant que j'ai les choses en tete avant de passer a une autre machine



LE SOUNDCHIP

Ici le sound chip est un "discrete chip" c'est a dire qu'il n'est pas integré a un autre chip comme c'est souvent le cas dans les consoles de jeu comme la VCS (dans le GPU), la NES (dans le CPU), la master system (dans le GPU sauf pour la MarkIII qui avait un super sound chip yamaha dédié comme j'en ai deja parlé)
C'est donc un chip a part (il integre quand meme la gestion des controlleurs) et c'est encore une fois un chip Général instrument.
On pourait presque dire que l'intellivision est plutot une console General instrument qu'une console Mattel car c'est vraiment eux qui fournissent l'intégralité des composants (CPU, GPU, sound chip, DAC et meme les memoires je crois), c'est peut etre meme unique dans l'histoire des consoles de jeu d'une certaine maniere (faudrait voir avec la PC engine qui doit etre presque intégralement produit par NEC). Une autre particularité qu'on pourrait associer a cette console.

Revenont a nos moutons. Il se trouve que General instrument est connu pour une chose (pas seulement j'y reviendrais) dans le jeu video c'est justement sa celebre famille de sound chip AY-3-8910 qui ont équipés plein de machine comme l'Amstrad CPC, MSX, Vectrex, ZX Spectrum et bien sure l'intellivision, meme Yamaha avait racheté la licence.
Et c'etait le concurent de l'autre sound chip concurent de l'epoque fabriqué par Texas instrument, le SN76489 (Toutes les consoles Sega, la Colecovision, la neogeo pocket)
Donc c'est a peu pret le meme genre de capacité pour toutes ces machines, 3 canaux "square wave" + un canal de bruit donc vraiment pas terrible pour une Master systeme mais tres bien pour une intellivision bien plus vieille.
Bien entendu une master system avec ses capacité RAM, ROM et CPU superieur peut mieux exploiter ce genre de chip que ne peut le faire l'intellivision. Le son c'est toujours aussi un peu une question de quantité de donnée a manipuler.





General Instrument

Je vais faire un petit HS car au debut en regardant le schema de la console et en voyant tous ces chip General instrument chaque fois référencer AY-3-XXXX ca me rappelait quelque chose mais je me souvenais pas quoi donc j'ai ressorti d'autre schéma de console mais rien...
Puis en me renseignant sur le sound chip je me suis dis que c'etait sans doute ca que ca me rapellait, ce sound chip asser connu mais non d'un seul coup ca m'est revenu.

Y a longtemps j'avais creuser l'histoire du pong (j'avais meme racheter le tout premier pong de 1975) et j'avais decouvert la revolution du "pong in a chip" qui avait permis ce raz de marré de "home pong" des années 70. C'est a dire que la revolution des circuits integrés avaient permis de reunir les dizaines et centaines de transistors, diodes ect... qu'il y avait sur une PCB pong Arcade (notement l'affichage du score qui ajoutait un vrai degrés de complexité a la PCB) en un seul chip ce qui permettait d'en faire une version domestique.

Atari a designé un tel chip pour leurs pong mais rapidement d'autres constructeurs ont proposés ce genre de chip dans leur catalogue et comme pour les sound chip c'etait General instrument face a Texas instrument et celui qui a eu le plus de succes c'est le AY-3-8500 de General instrument. C'est lui (et ses variantes) qu'on retrouve dans des centaines de home pong different de divers marques et c'est pour cela que ce code chip me disait quelque chose (PS: Nintendo s'est fait un "pong in a chip" sur mesure comme a son habitude).

Donc General instrument qui m'etait plutot inconnu jusque la a en fait marqué 3 fois l'industrie du jeu video.
- le "pong in a chip" le plus celebre
- un sound chip tres connu qu'on retrouve dans divers consoles
- l'intellivision qu'ils ont integrallement produit jusqu'au CPU

zeydou a écrit:

J'attends qu'upsi arrive à la PS1   

Je vais m'arreter avant. la PS1 c'est une machine dont j'avais deja longuement feuilleté les documents de devellopement a l'epoque donc c'est pas une machine sur laquel je me pose vraiment de question, pareille pour les suivantes que j'ai toujours suivie plus ou moins de pret (moins la saturn).
Ce qui m'interresse c'est vraiment la periode pré-PS1 car soit j'etais trop jeune, soit y avait pas la documentation pour s'informer.

patataboy a écrit:

upsilandre a écrit:

sur SNES fallait vraiment optimiser ton code vu le CPU un peu vieillot

Vieillot et sous cadencé
Le nombre de jeux qui rament alors qu'il n'y a pas grand chose, là ou un jeu MD passe comme une lettre à la poste.

S-Nes:
CPU 65816 16-bit (2.68 / 3.58 Mhz) Picture Processing Unit

D'ailleurs je me souviens qu'une rumeur courait autour de la Super Famicom au sujet de ses ralentissements et de son CPU.

La référence "65816" était pour désigner une famille de proco, en l’occurrence ici le 65816 signifiait "8/16 bit" j'ai un vague souvenir d'un magazine de l'époque qui en avait conclu que c'était un processeur 8 bit, avec un bus à 16.

Il y avait aussi une histoire de "switchage" avec ce CPU par rapport au faite que c'est un CPU 8 bit, mais qu'on est capable de faire bosser en 16 bit, mais la ça m'échappe ...

Par la suite je n'ai plus du tout entendu parlé de cela, et la SFC a toujours été considéré comme une console 16 bit, mais à ce jour ça reste encore un peu flou dans ma tête.

Je me souviens que Nec utilisait aussi des CPU 8 bits dans ses machines que pourtant, une grosse majorité de magazine de l'époque considéraient comme étant des machines 16 bits, en réalité Nec utilisait des coprocesseurs fort sympathique à l'époque qui assistaient bien le CPU, et qui créaient quelque peu "l'illusion" de machines capable de se frotter avec des consoles 16 bits, et c'était le cas dans certaines situations ou les consoles Nec tenaient sans problème tête à la Megadrive et à la SFC.

J'aimais beaucoup Nec pour les bricoles technique qu'ils faisaient sur leurs console de jeux "16-bit" ça aurait plu à Upsi c'est certain.