Re: MEGADRIVE vs SUPER NINTENDO : Fight !

[upsilandre]

Si c'était le cas on serrait bien au dessus des 7% de plus avec de la vram seulement à 120ns réel comme tu le pense

C'est pas ce que je "pense" c'est juste ce qu'il y a ecrit sur le chip, j'y peux rien, j'ai l'impression que tu fais une confiance aveugle a ce document (moi aussi je serais tenté car le document est tres bon mais le fait est que ca colle pas bien ici, et pourquoi il ecrit aussi que c'est de la SRAM? en fait c'est comme si il avait confondu avec la WRAM qui est comme par hasard de la SRAM 100ns justement).

Non le VDC est prévu pour utiliser des mémoires plus lentes si besoin, donc tu as un accès en 2bp, ou la possibilité d'avoir un refresh avec l'utilisation de DRAM .C'est pas utilisé, car ça sert à rien tout simplement .

Ca aussi c'est mot pour mot ce qui a ecrit dans le document mais on peut tenter quand meme d'y faire un peu abstraction, chaque document a ses approximations. Moi je vois ce parametrage supplémentaire aussi comme un mode parfaitement pensé pour le dot clock 10.745mhz

Si t'as fait un flappy bird en 512 c'est génial ca veut dire que tu peux tester ca facilement. j'imagine que dans ton registre 09 (VDC) les 4 premiers bit sont donc a 0 , si tu pouvais modifier et mettre 5 et voir ce que ca donne ca serait cool. Normalement (si tu utilises pas de trick farfelu pendant l'affichage) ca devrait toujours fonctionner aussi bien sauf que la VRAM est alors sollicité a 5.37mhz au lieu de 10.74mhz (meme si comme tu dis ca passe quand meme en 10.74mhz ca me paraîtrait plus judicieux d'utiliser ce mode en 10.74mhz si ca marche, ca serait intéressant de savoir par curiosité).

[Invité]

C'est pas ce que je "pense" c'est juste ce qu'il y a ecrit sur le chip, j'y peux rien, j'ai l'impression que tu fais une confiance aveugle a ce document (moi aussi je serais tenté car le document est tres bon mais le fait est que ca colle pas bien ici, et pourquoi il ecrit aussi que c'est de la SRAM? en fait c'est comme si il avait confondu avec la WRAM qui est comme par hasard de la SRAM 100ns justement). 

C'est bizarre ça colle pas du tout, pk avoir mis de la WRAM à 100, alors que de la 140 suffit ??
je sais que les puces de VRAM se sont des HSRM20256LM12, mais j'arrive pas à trouver quel type de mémoire c'est .

EDIT: je viens de trouver c'est bien de la psram de chez sharp, mais qui fonctionne comme de la SRAM tout en coûtant moins cher .
Elles sont données pour 100ns/120ns .
Et la RAM est une SRAM 100 ns ..
Bizarre quand même,faudrait que je fasse des tests plus poussés en 10.74 pour voir si y'a vraiment pas de soucis ..

Si t'as fait un flappy bird en 512 c'est génial ca veut dire que tu peux tester ca facilement. j'imagine que dans ton registre 09 (VDC) les 4 premiers bit sont donc a 0 , si tu pouvais modifier et mettre 5 et voir ce que ca donne ca serait cool. 

J'ai pas encore les moyens de tester par moi même, j'ai toujours pas de flash card 
Mais si tu mets à 5, tu passes en mode 2BP pour les sprites et le bckgnd avec juste les BP 1 et 2 qui sont lus .
Avec une valeur de 10, c'est pareil, mais seul les BP 3 et 4 sont lus.
Donc oui ça marche, mais tu passes de 16 couleurs à 4, et en fonction des bits, ça touche soit les sprites soit le fond, ou les 2  .

[upsilandre]

C'est bizarre ça colle pas du tout, pk avoir mis de la WRAM à 100, alors que de la 140 suffit ??

Dans tous les autres exemple c'est aussi le cas, y a chaque fois une grosse marge. Au moins t'es sur de pas planter la machine meme si ca chauffe. Ca me choque pas du tout d'avoir de la marge sur de la WRAM qui est un element critique, c'est plutot logique c'est pas de la VRAM justement. (et de toute facon tu choisie pas forcement a la carte).

je sais que les puce de VRAM se sont des HSRM20256LM12, mais j'arrive pas à trouver quel type de mémoire c'est .

De ce que j'ai constaté c'est chaque fois le meme type de référencement pour toutes ces RAM, les 2 derniers chiffres donne toujours la performance des acces time, 12 pour 120ns. Tous les datasheet que j'ai lu c'etait comme ca donc c'est deja un bon moyen de se faire une idée.
A priori c'est le meme type de RAM que celle ci:
http://console5.com/techwiki/images/3/37/LH5P832.pdf
Et a la derniere page t'as la nomenclature.

Sinon y a ce wiki qui est tres bien.
http://console5.com/wiki/Category:Console

Je poserai la question, mais pour moi ça n'a aucun intérêt tant la marge d'erreur devient alors grande .

Le truc c'est que meme a 120ns a mon avis ca peut effectivement encore passer et les glitch générés sont a mon avis tres difficiles a voir (surtout si jamais t'as testé que 2 minutes) car en plus la PCE utilise la bande passante de facon tres superficiel (contrairement a la SNES qui utilise chaque cycle VRAM). Deja a priori ca glitchera pas sur le background car les acces bg sont pas en flux tendu mais sporadique car y a trop de bande passante, y a que les patterns de sprites qui peuvent stresser mais voir un flickering d'une ligne de sprite sur un seul sprite et pendant une seul frame c'est chaud, ou alors faudrait que ca glitch vraiment beaucoup et a chaque frame (ce qui peut finir par etre le cas si c'est vraiment trop borderline).

Mais si tu mets à 5, tu passes en mode 2BP pour les sprites et le bckgnd avec juste les BP 1 et 2 qui sont lus .
Avec une valeur de 10, c'est pareil, mais seul les BP 3 et 4 sont lus.
Donc oui ça marche, mais tu passes de 16 couleurs à 4, et en fonction des bits, ça touche soit les sprites soit le fond, ou les 2  .

C'est pas ce que je lis. Le mode qui force le 2bpp c'est le 3eme mode. Celui qui divise la frequence VRAM par 4 (et pas par 2) la oui c'est logique, y a plus que 2 slot par tile (donc un seul acces 16bit pour la pattern). mais le second mode y a pas de probleme, t'as encore 4 slot par tile dont toujours 3 slot pour le bg comme dans le mode normal (un slot pour la tilemap et 2 pour les patterns), pareille pour les sprites, c'est juste les slots vide et les slot cpu superflu qui sont sacrifié car y avait de la marge, reste plus qu'un seul slot cpu (soit 66 par scanline).
Essaye voir au moins en emulation (si l'emulateur prend) en mettant 5. Pour moi le second mode de timing VRAM est clairement un mode pour le 10.74mhz.

[upsilandre]

EDIT: je viens de trouver c'est bien de la psram de chez sharp, mais qui fonctionne comme de la SRAM tout en coûtant moins cher .
Elles sont données pour 100ns/120ns .
Et la RAM est une SRAM 100 ns ..
Bizarre quand même,faudrait que je fasse des tests plus poussés en 10.74 pour voir si y'a vraiment pas de soucis ..

oui c'est ca. Je pense vraiment que dans le doc le gars a confondu la VRAM et la WRAM sur ce calcule en tout cas (un calcule qui de toute facon est anecdotique dans le doc, juste a titre indicatif). La WRAM est effectivement de la SRAM a 100ns comme il dit dans son calcule pour la VRAM sauf que la VRAM est de la PSRAM a 120ns.

[Stef]

A mon avis, on peut pas seulement se fier aux timings écrits sur les chips (100ns ou 120ns) car ce n'est là qu'un temps d'accès "moyen" et selon le type de RAM ça change beaucoup. Sur une SRAM, tu as la garantie de toujours avoir le même temps d'accés mais ce n'est pas le cas des autres types de RAM (genre DRAM). Et surtout sur ces machines, la VRAM est toujours l'un des composants les plus couteux (avec le VDP bien sur) car elle doit offrir une bande passante énorme comparé à la main RAM. Sur MD ou sur SNES, je suis sur que la main RAM est incapable de tenir 100ns en random, c'est juste pour de l’accès continu ce qui n'arrive pas avec un CPU.
Sur PCE c'est particulier, ils ont du avoir recours à un SRAM très rapide pour alimenter le CPU mais du coup la quantité est très faible.

[Invité]

Dans tous les autres exemple c'est aussi le cas, y a chaque fois une grosse marge. Au moins t'es sur de pas planter la machine meme si ca chauffe. Ca me choque pas du tout d'avoir de la marge sur de la WRAM qui est un element critique, c'est plutot logique c'est pas de la VRAM justement. (et de toute facon tu choisie pas forcement a la carte).

C'est pas faux .

De ce que j'ai constaté c'est chaque fois le meme type de référencement pour toutes ces RAM, les 2 derniers chiffres donne toujours la performance des acces time, 12 pour 120ns. Tous les datasheet que j'ai lu c'etait comme ca donc c'est deja un bon moyen de se faire une idée.
A priori c'est le meme type de RAM que celle ci:
http://console5.com/techwiki/images/3/37/LH5P832.pdf
Et a la derniere page t'as la nomenclature.

Sinon y a ce wiki qui est tres bien.
http://console5.com/wiki/Category:Console

C'est là que je viens de trouver les infos, mais merci quand même 

Le truc c'est que meme a 120ns a mon avis ca peut effectivement encore passer et les glitch générés sont a mon avis tres difficiles a voir (surtout si jamais t'as testé que 2 minutes) car en plus la PCE utilise la bande passante de facon tres superficiel (contrairement a la SNES qui utilise chaque cycle VRAM). Deja a priori ca glitchera pas sur le background car les acces bg sont pas en flux tendu mais sporadique car y a trop de bande passante, y a que les patterns de sprites qui peuvent stresser mais voir un flickering d'une ligne de sprite sur un seul sprite et pendant une seul frame c'est chaud, ou alors faudrait que ca glitch vraiment beaucoup et a chaque frame (ce qui peut finir par etre le cas si c'est vraiment trop borderline). 

Faudra que je teste de façon poussée sur le vrai hard, et que je commande mon evedrive aussi  .

C'est pas ce que je lis. Le mode qui force le 2bpp c'est le 3eme mode. Celui qui divise la frequence VRAM par 4 (et pas par 2) la oui c'est logique, y a plus que 2 slot par tile (donc un seul acces 16bit pour la pattern). mais le second mode y a pas de probleme, t'as toujours autant de slot pour le bg (un slot pour la tilemap et 2 pour les patterns), pareille pour les sprites, c'est juste les slots vide et les slot cpu superflu qui sont sacrifié car y avait de la marge, reste plus qu'un seul slot cpu (soit 66 par scanline).
Essaye voir au moins en emulation (si l'emulateur prend) en mettant 5.

Effectivement,c'est le bit 7 qui te fait passer en mode 2bp .
Ca serrait peut être pas mal de tester ça, et si ça réduit les slot, et fait passer le CPU à 66 octets / ligne, ça correspond aux 7 cycles / bytes en transfert classique, donc ça pourrait être effectivement une solution en cas de problème à 10,74 mhz .
J'ai jamais utilisé le mode 2bp non plus donc je me suis jamais posé la question sur ce registre .

[upsilandre]

D'ailleurs c'est pas 5 qu'il faut mettre mais 9 pour reduire aussi le stress des sprites.
Ouai ca me parait vraiment bien adapté au mode 10.74mhz

[Invité]

Par contre si problèmes il doit y avoir, en faisant du DMA VRAM->VRAM à 10.74 on devrait avoir des soucis alors .

Un valeur de 2 ou 3 sur le sprite dot period fait passer le mode 2bp pour les sprites par contre .
le CG est lui présent dans la SAT (bit 0 des patterns).

[upsilandre]

Par contre si problèmes il doit y avoir, en faisant du DMA VRAM->VRAM à 10.74 on devrait avoir des soucis alors .

Oui c'est le meilleur moyen a priori de stresser au mieux la VRAM et voir aussi si quand on utilise le second mode de timing VRAM ca influence le DMA qui passerait alors peut etre en 5.37mhz (Ca se trouve le DMA switch automatiquement en 5.37 quand t'es en 10.74, peut etre que personne n'a fait de test de debit?)

[Invité]

Oui c'est le meilleur moyen a priori de stresser au mieux la VRAM et voir aussi si quand on utilise le second mode de timing VRAM ca influence le DMA qui passerait alors peut etre en 5.37mhz (Ca se trouve le DMA switch automatiquement en 5.37 quand t'es en 10.74, peut etre que personne n'a fait de test de debit?)

Non, les tests ont été fait jusqu'au dotclock 7.16 .

[Stef]

Bon effectivement en lisant les références des chips mémoire MD je trouve qu'ils ont mis de la pseudo static RAM pour la mémoire centrale à 100ns...
On peut trouver le datasheet ici :
http://www.alldatasheet.com/datasheet-pdf/pdf/113668/TOSHIBA/TC51832SPL-10.html

Et en regardant dans les timings on se rend compte qu'un acces random va prendre 160ns (sur le chip -10) au minimum. On est loin d'une vrai static RAM mais au moins le refresh est géré en interne.
J'imagine qu'on a le même genre de RAM sur SNES en WRAM.

[Invité]

Il me semble que c'est de la DRAM sur snes .

[upsilandre]

Un valeur de 2 ou 3 sur le sprite dot period fait passer le mode 2bp pour les sprites par contre .

non avec 2 on passe simplement d'un chargement de 2 sprites tout les 8 dot clock a 1 seul sprite tout les 8 dot clock ce qui n'a pas de consequence puisque t'as 2 fois plus de dot clock pendant le Hblank en mode 10.74 (de toute facon c'est logique a comprendre, la charge sprite est toujours la meme donc rester sur des acces VRAM a 5.37mhz n'a pas de consequence, pas besoin d'acces a 10.74).
C'est encore une fois simplement le 3 qui lui force le 2bpp car la tu charge un seul sprite tous les 16 dot clock.

[Invité]

non avec 2 on passe simplement d'un chargement de 2 sprites tout les 8 dot clock a 1 seul sprite tout les 8 dot clock ce qui n'a pas de consequence puisque t'as 2 fois plus de dot clock pendant le Hblank en mode 10.74 (de toute facon c'est logique a comprendre, la charge sprite est toujours la meme donc rester sur des acces VRAM a 5.37mhz n'a pas de consequence, pas besoin d'acces a 10.74).
C'est encore une fois simplement le 3 qui lui force le 2bpp car la tu charge un seul sprite tous les 16 dot clock.

Donc la doc comporte des erreurs là aussi .. 

The CG mode bit is only valid when the sprite dot width field of the MWR
register is set to 2 or 3. When clear, bitplanes 0 and 1 are read, 2 and 3
are treated as zero. When set, bitplanes 2 and 3 are read, 0 and 1 are
treated as zero.

[upsilandre]

Il me semble que c'est de la DRAM sur snes .

oui a priori car t'as une interuption externe du CPU et DMA a cause du refresh de la WRAM.

[upsilandre]

Bon effectivement en lisant les références des chips mémoire MD je trouve qu'ils ont mis de la pseudo static RAM pour la mémoire centrale à 100ns...
On peut trouver le datasheet ici :
http://www.alldatasheet.com/datasheet-pdf/pdf/113668/TOSHIBA/TC51832SPL-10.html

Et en regardant dans les timings on se rend compte qu'un acces random va prendre 160ns (sur le chip -10) au minimum. On est loin d'une vrai static RAM mais au moins le refresh est géré en interne.

Sur la reference c'est effectivement juste "l'acces time" qu'ils mettent en exergue mais les cycles complets sont toujours plus grand. Je sais pas dans quelle mesure il faut considérer plutot ceci ou cela. Mais a priori ce qu'on peut deja dire c'est qu'elle est dans la categorie au dessus de ce qui est utilisé pour la VRAM PCE qui est du meme type mais en 12 (120ns acces time) et qui pourtant doit supporter des frequences bien plus élevé. On voit bien la que les considérations pour la WRAM et la VRAM ne sont pas les memes et qu'au final la WRAM ne sont pas forcement moins chère que la VRAM.

edit: Dans les premieres MD c'etait plutot du 12 aussi voir peut etre du 15 dans le premier model jap ce qui serait un peu plus cohérent.

[upsilandre]

Donc la doc comporte des erreurs là aussi .. 

The CG mode bit is only valid when the sprite dot width field of the MWR
register is set to 2 or 3. When clear, bitplanes 0 and 1 are read, 2 and 3
are treated as zero. When set, bitplanes 2 and 3 are read, 0 and 1 are
treated as zero.

Oui la il s'est planté a priori car c'est pas logique, et d'ailleurs c'est pas ce qu'il dit plus haut sur le regsitre 09 ou il elude un peu les sprites
ici c'est un peu plus détaillé
http://archaicpixels.com/HuC6270

Bit 0 of the pattern code field of each sprite entry specifies which bitplanes are read for a sprite pixel width setting of 11b. It can be 0= SP0,SP1 or 1= SP2,SP3. The unused bitplanes are forced to zero so that the colors used out of a 16-color palette are 0,1,2,3 when SP0,SP1 are read, or 0,4,8,C when SP2,SP3 are read.

La il parle bien uniquement pour le cas du dot width field a 11b (et pas 10b) comme pour le bg ce qui est parfaitement logique.
Donc si tu met 1010b ou 1001b au lieu de 0000b normalement ca passe, ca devrait rien changer a ton flappy mais tu divises par 2 la frequence d'acces a la VRAM.

[Doc_Skunkovitch]

Ce que vous voulez, perso l'idée c'est de préserver des données intéressantes et leur donner plus de visibilité.

Mwé.. Tu veux surtout troller tranquille oui petit canaillou !

Ceci dis c'est vrai en ce moment quand je lis , meme si c'est tres interressant , je suis plutot souvent comme ça

[Invité]

Mwé.. Tu veux surtout troller tranquille oui petit canaillou !

Le beurre, l'argent du beurre, et une crèmerie multinationale.

[Tibob]

Ouais c'est pas faux...

[Invité]

Bon effectivement en lisant les références des chips mémoire MD je trouve qu'ils ont mis de la pseudo static RAM pour la mémoire centrale à 100ns... 

Donc tu vois bien que ton argumentations sur le prix de la RAM plus coûteuse sur snes/pce tombe à l'eau, car même si le 68k se contente de ram -> 300 ns, le DMA pour faire du RAM -> CRAM/VSRAM non,et finalement on se retrouve avec la même RAM sur MD et PCE .
Par contre le fait de recourir à une RAM bcp plus rapide que nécessaire est étrange, peut être que la SRAM 140/160 ns n'existait pas ou plus , ou alors en faible quantité car la 100/120 était devenue la norme et donc moins chère, voire au même prix ?? .

[upsilandre]

Donc tu vois bien que ton argumentations sur le prix de la RAM plus coûteuse sur snes/pce tombe à l'eau, car même si le 68k se contente de ram -> 300 ns, le DMA pour faire du RAM -> CRAM/VSRAM non,et finalement on se retrouve avec la même RAM sur MD et PCE .

Par contre je crois que dans la premiere megadrive jap c'etait des chip PSRAM NEC 150ns si j'en crois le schematic qui doit dater de cette epoque, donc c'est quand meme la megadrive qui semble avoir la ram la plus lente tout confondu (cpu, GPU)

Par contre le fait de recourir à une RAM bcp plus rapide que nécessaire est étrange, peut être que la SRAM 140/160 ns n'existait pas ou plus , ou alors en faible quantité car la 100/120 était devenue la norme et donc moins chère, voire au même prix ?? .

Si j'en crois ce datasheet de chip equivalent
http://console5.com/techwiki/images/c/c3/LC3564Q.pdf

la 100ns est la plus lente (sinon c'est 85ns et 70ns) mais ce datasheet peut tres bien ne pas etre de la meme epoque donc ca veut pas forcement dire grand chose.
Ce qu'on n'a pas dit aussi c'est que les valeurs dependents du voltage, les valeurs données sont toujours pour du 5v, alors c'est effectivement ce qu'utilise les 3 consoles (j'ai verifié) mais on remarque quand meme sur le datasheet que la 100ns semble tres sensible au voltage, elle passe a 500ns en 3v (bizarre mais bon) donc malgres que la mémoire PC-Engine c'est bien du 5v t'es pas a l'abris de quelque variation. Donc encore une fois pour moi 100ns ca me parait pas du tout excessif comme marge (les 100ns dans la MD la oui mais a priori c'etait pas le cas au depart)

[tilou]

je viens de me trouver un super pang en broc
finalement la conversion de l'arcade s'en sort pas mal
j'aurais été curieux de voir ce qu'il aurait donné sur megadrive

[Stef]

Bon effectivement en lisant les références des chips mémoire MD je trouve qu'ils ont mis de la pseudo static RAM pour la mémoire centrale à 100ns... 

Donc tu vois bien que ton argumentations sur le prix de la RAM plus coûteuse sur snes/pce tombe à l'eau, car même si le 68k se contente de ram -> 300 ns, le DMA pour faire du RAM -> CRAM/VSRAM non,et finalement on se retrouve avec la même RAM sur MD et PCE .
Par contre le fait de recourir à une RAM bcp plus rapide que nécessaire est étrange, peut être que la SRAM 140/160 ns n'existait pas ou plus , ou alors en faible quantité car la 100/120 était devenue la norme et donc moins chère, voire au même prix ?? .

tut tut... La RAM centrale de la PCE c'est de la SRAM, rien à voir, c'est bien plus couteux que la PSRAM utilisée sur la MD ou la DRAM de la SNES.

[Invité]

tut tut... La RAM centrale de la PCE c'est de la SRAM, rien à voir, c'est bien plus couteux que la PSRAM utilisée sur la MD ou la DRAM de la SNES.

Raaah la mauvaise foi, même si elle est plus chère, ça justifie pas 64ko vs 8   .
La différence de prix doit quand même pas dépasser les 20% .

[Agathon]

Oui mais 20% sur les millions de consoles, ça fait beaucoup.

[Invité]

Oui mais 20% sur les millions de consoles, ça fait beaucoup.

Oui si le chiffre de 20% est exact.
Et donc dans le cas de la snes, nintendo aurait largement pu mettre 64ko de psram plutôt que la vielle merde de DRAM qu'ils ont mis sur la snes,et faire que le CPU tourne en full 3,58 mhz avec de la fast rom .

[Stef]

tut tut... La RAM centrale de la PCE c'est de la SRAM, rien à voir, c'est bien plus couteux que la PSRAM utilisée sur la MD ou la DRAM de la SNES.

Raaah la mauvaise foi, même si elle est plus chère, ça justifie pas 64ko vs 8   .
La différence de prix doit quand même pas dépasser les 20% .

20% entre de la SRAM et de la DRAM/PSRAM ? je crois que tu ne réalises pas ^^ Je pense que la SRAM est *au moins* 2 fois plus chère ! On utilise la SRAM souvent pour faire un petit cache mais jamais en grosse quantité car ça prend beaucoup de place (sur le die).
http://www.differencebetween.net/technology/difference-between-sram-and-dram/

Et donc dans le cas de la snes, nintendo aurait largement pu mettre 64ko de psram plutôt que la vielle merde de DRAM qu'ils ont mis sur la snes,et faire que le CPU tourne en full 3,58 mhz avec de la fast rom .

Si j'ai bien compris la PSRAM n'est pas vraiment plus rapide en terme d'accès que la DRAM (ou très peu), la grosse différence c'est que le refresh se fait en interne, mais il existe toujours...
Sinon pour la SNES, il faut voir ce que ça coutait réellement de mettre une RAM qui assure les 3.58 Mhz mais je pense que 64 Ko à 3.58 Mhz c'était réalisable... après une RAM à 3.58 Mhz n'aurait pas beaucoup amélioré le problème, la ROM elle serait restée à 2.68 Mhz pour commencer.

[upsilandre]

2x c'est vraiment le minimum (j'ai lu 6 a 10x par rapport a de la simple DRAM mais dans un document des années 90, pas la meme epoque, mais au pif je dirais peut etre 4x de la DRAM et 3x de la PSRAM)

Sinon pour la PSRAM je sais pas comment est fait le refresh en interne mais y a des moyens de le caché a priori (c'est plus ou moins sous entendu dans le datasheet), ca doit dépendre du contexte mais apparemment en l'utilisant comme VRAM ils arrivent a cacher le refresh puisque sur la SNES c'est claire que le refresh est invisible, tous les slot sont utilisé par le PPU, y a aucun moment libre ni moment d’interruption. Mais c'est peut etre pour ca aussi qu'ils utilisent une memoire plus rapide que nécessaire.

[upsilandre]

Pour se détendre je fais un petit résumé sur les VRAMs et leurs relations avec le GPU mais en prenant l'angle plutot des similitudes que celle des différences pour éclaircir un peu et simplifier.

Premier point elles ont toutes les 3 la meme quantité de VRAM, c'est pas rien. Y en a une qui aurait pu se détacher car ca devient quand meme vite un avantage d'avoir plus de VRAM mais non, toutes a egalités.

Elles partagent aussi un dot clock en commun a 5.37mhz, le fameux dot clock imposé je crois par Texas Instrument dans leur TMS9918 et qu'on retrouvera dans la Colecovision, SG1000, NES, Master system... le fameux 256 pixels a l'ecran qui permet probablement d'optimisé 2-3 truc dans l’électronique interne des vieilles machines. Utilisé surtout par la SNES et la PCE, pas tellement par la MD.

Les 3 machines ont aussi la meme relation avec cette VRAM. Pour les 3 ca consiste en un acces 16bit pour chaque dot clock (la MD c'est plutot un slot 32bit tout les 2 pixels mais ca revient au meme) et c'est avec ca qu'il va falloir bosser pour construire l'image, backgrounds + sprites.

Maintenant c'est intéressant de comparer ce qu'il se passe pendant une scanline. La aussi on a quand meme des similitudes fortes qui permettent d'y voir bien plus claire. Pour les 3 consoles ca se divise grosso-modo en 2 phases.
Une phase de chargement des patterns des sprites affichés sur la scanline (ou la prochaine) et qui sur les 3 consoles se fait en flux tendu les un derrières les autres en utilisant tous les slots et donc cette phase dure a peu pret le meme temps sur les 3 consoles (a peu pret le quart de la scanline) car parmis les similitudes y a aussi celle d'avoir a peu pret la meme charge de sprite par scanline au moins si on reste sur le meme dot clock.

La seconde phase c'est celle qui concerne le background. Chacune ajoute la meme marge de 2 tiles en supplément de celle contenu par l'ecran et chacune a le meme budget de 8 slots de 16bit par tile de 8 pixels mais la facon d'utiliser ces 8 slots est cette fois differente, c'est meme la que se situe une grande partie de leurs differences.
-- La PCE ne va utiliser que 3 slots sur les 8 car elle n'a qu'un seul plan (2 slot pour la pattern, un slot pour la tilemap) le reste est a la disposition du CPU, bien plus qu'il ne peut en utiliser, et qui donc peut acceder a la VRAM librement.
-- La MD avec ses 2 plans va donc utiliser 6 slots (2x3) sur 8 ce qui laisse 2 slots en rab. Le 7eme slot est utilisé pour les attributs des sprites de la prochaine scanline que la MD va donc pouvoir se permettre de ne pas stocker dans le VDP et le 8eme est a dispo du CPU/DMA en alternance avec le refresh de la VRAM (donc un refresh qui n'a d'impacte que sur les acces CPU)
-- La SNES n'a pas besoin de charger des attributs de sprite deja a dispo en interne, ni besoin de refresh et n'est pas partageur avec le CPU du coup les 2 slots que la MD avait en rab vont servir ici a ajouter un 3eme plan mais comme un slot est utilisé pour la tilemap il ne reste qu'un slot pour la pattern donc ca sera un plan 2bpp.


Est ce que c'est un peu plus claire?

[Stef]

Bon résumé
Mais au final, là ou la PCE et la SNES font ça sur 256 pixels, la MD le pousse sur 320 pixels (soit 25% de bande passante en plus nécessaire). MD win (encore une fois)