Re: MEGADRIVE vs SUPER NINTENDO : Fight !

[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)

[Invité]

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)

si tu parles pour les sprites oui, car la PCE ne dispose pas de buffer supérieur à 16 sprites, pour le reste non,puisque la PCE le fait aussi sur 512 .
Et je pense qu'en terme de BP VRAM elle est supérieure à la MD .
Les sprites sont fetchés pendant le hblank, et non pendant la scanline comme sur Md,donc avec 2 plans, la PCE aurait encore 2 slots réellement de libres contrairement à la MD, donc non la MD ne winne pas 

Pour les 10x le prix de la SRAM avec la DRAM, je pense pas, sinon la MD aurait coûtée un bras avec ses 64ko, ou alors les autres composants ne valles vraiment pas cher, ce qui m'étonnerait fort .
Donc j'ai déjà une réponse que la RAM sur PCE ne coûtait pas plus cher que sur MD, vu qu'elles ont la même .

[Stef]

Parfois on se demande si tu lis bien :p

La MD utilise en RAM centrale les mêmes chips que ce que la PCE utilise pour la VRAM. La SRAM de la PCE, la MD en utilise uniquement pour la mémoire du Z80 (8 ko également) mais à une fréquence plus faible (pas de gros besoin avec le Z80).

La VRAM de la MD est plus rapide que celle de la PCE, il n'y a aucun doute là dessus. N'oublie pas que même en 512 pixels, tu es loin d'être au niveau de la MD en terme de bande passante. En gros tu as 512 + 256 de sprite (soit 768 pixels) là où sur MD tu as 320 + 320 + 320 soit 960 pixels de sprite, sans compter le mapping suplémentaire pour les sprites sur MD.
La granularité de 16 pixels sur les sprite de la PCE est probablement un avantage pour tirer partie du burst de lecture sur la PSRAM, et je pense que l'unique plan est également un avantage sur ce point (possibilité de fetcher plus de mapping et plus de pattern d'un coup).

[Invité]

La VRAM de la MD est plus rapide que celle de la PCE, il n'y a aucun doute là dessus.

Je suis pas d'accord, plus sollicitée oui, plus rapide non .
elles ont les mêmes types d'accès, soit 1 word / cycles .
je vois pas comment avec une VRAM prévu pour fonctionner à 6.71 mhz serrait plus rapide qu'une à 10.74 ..
Ensuite c'est pas une question de lecture, même de la PSRAM ne devait pas être bcp plus chère que de la SRAM ,c'est du fantasme de croire le contraire,ces mémoires ont un coût à peut près équivalent, même si la SRAM est plus chère,rien de comparable entre la de la sram/psram et dram par exemple ..
et je pense pas que 32 ko de SRAM (qui auraient pu être mis dans la PCE) auraient été plus cher que 64ko de psram,ça fait déjà un facteur de 2 niveau prix, ce qui est largement surestimé . .

En gros tu as 512 + 256 de sprite (soit 768 pixels) là où sur MD tu as 320 + 320 + 320 soit 960 pixels de sprite, sans compter le mapping suplémentaire pour les sprites sur MD.

Tu oublies aussi le reste dispo est qui n'est pas utilisé,et si on prend le nombre de slots totaux, en 512 ils sont plus important qu'en 320, normal quoi .
Ton calcul correspond à ce qui serrait nécessaire comme BP(et encore avec ton calcul, impossible de transférer en VRAM pendant l'affichage), pas ce qui est effectif .

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

Et bon tu parles de lire correctement, et tu me compares de la DRAM alors que je parlais de SRAM  

[upsilandre]

Perso j'ai pas réussis a comprendre ce que tu voulais dire sur les RAM (SRAM, DRAM , PSRAM), doit y avoir un quiproquo, je t'assure que c'est pas compréhensible a la lecture.


Par contre moi j'avais encore une question sur la PCE.
Sachant que les slot CPU c'est pendant l'affichage du background et qu'il y en a aucun pendant le fetch des sprites (soit un quart du temps). Si tu veux lire la VRAM a ce moment la avec le CPU qu'est ce qu'il se passe? le CPU est bloqué et attend?
Ca impliquerait que le debit réel des acces CPU n'est pas le debit théorique. Pour l'ecriture on pourrait imaginer qu'il y ai un cache qui bufferise une quinzaine ou vingtaine de data + adresse pour executer la liste plus tard mais ca me laisse un peu sceptique, j'aurais plutot tendance a imaginer que ca se passe comme en lecture.

[Invité]

Perso j'ai pas réussis a comprendre ce que tu voulais dire sur les RAM (SRAM, DRAM , PSRAM), doit y avoir un quiproquo, je t'assure que c'est pas compréhensible a la lecture.

Depuis le début, sur d'autres posts, stef disait que la PCE n'avait que 8ko de WRAM car la ram nécessaire était chère car elle devait être rapide .
Hors vu que la Md embarque de la mémoire de même type (psram au lieu de sram) en WRAM, la différence niveau prix est pas importante, même si la sram est plus chère, je crois pas que 32 ko de sram coûtaient plus cher que 64ko de psram .

Si tu veux lire la VRAM a ce moment la avec le CPU qu'est ce qu'il se passe? le CPU est bloqué et attend?

Non, il est seulement bloqué que si tu essaies d'accéder à la VRAM pendant le transfert DMA VRAM->SAT.

[upsilandre]

Perso j'ai pas réussis a comprendre ce que tu voulais dire sur les RAM (SRAM, DRAM , PSRAM), doit y avoir un quiproquo, je t'assure que c'est pas compréhensible a la lecture.

Depuis le début, sur d'autres posts, stef disait que la PCE n'avait que 8ko de WRAM car la ram nécessaire était chère car elle devait être rapide .
Hors vu que la Md embarque de la mémoire de même type (psram au lieu de sram) en WRAM, la différence niveau prix est pas importante, même si la sram est plus chère, je crois pas que 32 ko de sram coûtaient plus cher que 64ko de psram .

ok, je pense que le malentendu vient du faite que la PSRAM c'est bien de la DRAM avec juste un controleur interne pour le refresh mais c'est toujours de la DRAM (en plus j'ai verifié c'etait bien une version 150ns dans la premiere MD, pas 100 ni 120). La SRAM reste bien plus chère, 32Ko de SRAM comme dans la Supergrafx c'est claire que c'est sensiblement plus chère que 64Ko de PSRAM (qui est de la DRAM) aucune doute.
Apres vu qu'il y a qu'un seul chip de 8Ko dans la PCE c'est sure que c'est quand meme la PCE qui a la WRAM la moins chère dans l'absolu (au pire ca coute le prix d'un chip de RAM de la MD sauf qu'il y en a 2 dans la MD). c'est evident y en a tellement peu.

[Invité]

La SRAM reste bien plus chère, 32Ko de SRAM comme dans la Supergrafx c'est claire que c'est sensiblement plus chère que 64Ko de PSRAM (qui est de la DRAM) aucune doute.

Dans le datasheet ils parlent de la psram comme de la sram et non de la dram .

[upsilandre]

La SRAM reste bien plus chère, 32Ko de SRAM comme dans la Supergrafx c'est claire que c'est sensiblement plus chère que 64Ko de PSRAM (qui est de la DRAM) aucune doute.

Dans le datasheet ils parlent de la psram comme de la sram et non de la dram .

Non c'est de la DRAM mais qui du point de vu externe est comme un chip de SRAM (au niveau des pins) grace au controleur interne. C'est de la RAM pas chère (par rapport a de la vrai SRAM) et en meme temps pratique a integrer dans une archi, c'est l'interet.

[upsilandre]

Non, il est bloqué que si tu essaies d'accéder à la VRAM pendant le transfert DMA VRAM->SAT.

Mais il se passe quoi si tu veux lire dans la VRAM au debut du fetch des sprites pendant le Hblank puisqu'il y a aucun slot CPU disponible pendant environ une centaine de cycle CPU?

[upsilandre]

Mais il se passe quoi si tu veux lire dans la VRAM au debut du fetch des sprites pendant le Hblank puisqu'il y a aucun slot CPU disponible pendant environ une centaine de cycle CPU?

Tu as full accès, car pendant le fetch, le VDC touche pas à la VRAM puisqu'il travaille avec la SAT qui est une mémoire interne au GPU .

Mais... mais...
Je parle du fetch des patterns de sprite (qui sont dans la VRAM) pendant le Hblank et qui se font en stream sans aucune place pour des slots CPU et dure au moins 86 cycles CPU.
Selon moi les 65 octets par scanline c'est pendant le Vblank, pendant l'affichage ca doit etre au mieux 52 octets par scanline.

[Invité]

Mais il se passe quoi si tu veux lire dans la VRAM au debut du fetch des sprites pendant le Hblank puisqu'il y a aucun slot CPU disponible pendant environ une centaine de cycle CPU?

Il me semble que tu as full accès, car le fetch se fait via la SAT qui est une mémoire interne au VDC, et donc il ne touche pas à la VRAM, mais j'en suis pas sur .

[upsilandre]

Je voyage dans le temps, qui dit mieux?

nan plus serieusement y a un truc qui cloche sur cette histoire. Le CPU peut pas etre full debit pendant l'affichage.

[Invité]

C'est vrai, mais c'est tout comme .
On parle de burst mode quand l'affichage est inactif, là tu peux utiliser tout les slots dispos via le CPU, mais étant donné que son max théorique de transfert est loin de pouvoir tout utiliser tu as bcp de perte en BP .

A MWR setting of $00 gives the CPU the largest amount of access cycles (twice per 8 pixels) which seems to be exactly equal to the amount of accesses available during BURST mode.

Donc si tu utilises la VRAM à sa vitesse max, tu es en quasi burst mode pendant l'affichage .

[upsilandre]

En fait c'est full debit pendant "l'affichage" au sens strict du terme, c'est a dire pendant le balayage de la zone ecran (+ 2 tiles hors champ) mais pas pendant la majorité du Hblank ou la t'es bloqué.
J'ai refais le calcule normalement on doit bien tomber a 52 octet par scanline (c'est toujours mieux que 18) mais ca rajoute un petit interet supplémentaire au Vblank qui reste quand meme une periode privilégié.
Y a pas une page quelque part d'un gars qui fait des test de bande passante?

[Invité]

En fait c'est full debit pendant "l'affichage" au sens strict du terme, c'est a dire pendant le balayage de la zone ecran (+ 2 tiles hors champ) mais pas pendant la majorité du Hblank ou la t'es bloqué.

Je pense que là aussi c'est effectif, puisque le burst mode est actif quand le VDC n'affiche rien, soit pendant le vblank et le hblank.

Y a pas une page quelque part d'un gars qui fait des test de bande passante?

Si, on est à 17 ko /frame avec les instructions de transfert de blocs et aucun coder n'a démenti ces chiffres, c'est pas moi qui les ai sortis je te rassure .
Après ça n'a jamais été testé pendant le hblank .

Si tu veux bcp plus de réponse techniques, tu peux contacter charles mc donalds, il est très connu dans le milieu du hard, aussi bien sur PCE que sur MD ..

[upsilandre]

En fait c'est full debit pendant "l'affichage" au sens strict du terme, c'est a dire pendant le balayage de la zone ecran (+ 2 tiles hors champ) mais pas pendant la majorité du Hblank ou la t'es bloqué.

Je pense que là aussi c'est effectif, puisque le burst mode est actif quand le VDC n'affiche rien, soit pendant le vblank et le hblank.

Mais... mais non
Pendant le Hblank t'as 64 dot clock ou le VDC fetch les patterns des sprites qui se trouve en VRAM en full stream sans laisser aucun slot pour le CPU (il charge 2 sprites tous les 8 dot clock), c'est impossible de pouvoir y acceder a ce moment la.

[Invité]

Pendant le Hblank t'as 64 dot clock ou le VDC fetch les patterns des sprites qui se trouve en VRAM

Non toutes les données des sprites sont dans la SAT , qui est une mémoire de 512 octets interne au VDC, d'où le canal DMA pendant le vblank qui fait le transfert VRAM -> SAT .
La SAT présente en VRAM n'est qu'un buffer temporaire pour le codeur,elle est d'ailleurs appelée SATB .

[upsilandre]

Pendant le Hblank t'as 64 dot clock ou le VDC fetch les patterns des sprites qui se trouve en VRAM

Non toutes les données des sprites sont dans la SAT, qui est une mémoire interne au VDC, d'où le canal DMA pendant le vblank qui fait le transfert VRAM -> SAT .

Mais je parle des PAAATTEEERN de sprite pas des attributs

[Invité]

Mais je parle des PAAATTEEERN de sprite  pas des attributs  

Ah ok,tu parles des données graphiques, putain faut te suivre .. 
Les données sont fetchées pendant le hblank/2 pour la ligne suivante dans un autre buffer du VDC, fixe pour 16 sprites .

[Stef]

Upsilandre> Tu vas vite comprendre sue c'est compliqué de discuter avec touko, déjà il comprend la moitié de ce qu'on écrit mais en plus il a un gros penchant de mauvaise foi :-D

[Stef]

Le coup du prix du psram équivalent au prix de la SRAM est assez flagrant. Affirmer ça sans savoir ...

[upsilandre]

Mais je parle des PAAATTEEERN de sprite  pas des attributs  

Ah ok,tu parles des données graphiques, putain faut te suivre .. 
Les données sont fetchées pendant le hblank/2 pour la ligne suivante dans un autre buffer du VDC, fixe pour 16 sprites .

Oui normal, ce qui ne change rien au probleme, pendant qu'il fetch les patterns a chaque Hblank le CPU est bloqué.

[Invité]

Surement, mais bon arriver à utiliser cette moitié de hblank pour transférer en VRAM relève un peu de l'exploit ..

Upsilandre> Tu vas vite comprendre sue c'est compliqué de discuter avec touko, déjà il comprend la moitié de ce qu'on écrit mais en plus il a un gros penchant de mauvaise foi :-D

On sait tout qu'en plus d'avoir toujours raison, tu sais tout sur tout hein stef, même quand tu te fais reprendre par tes collègues codeurs Md tellement tu trolles sur la snes en vantant la supériorité de la Md   
Ah oui c'est vrai, qu'eux n'y connaissent rien .

tes interventions sur le forum de snesdev, sont toujours un plaisir,et entre nous question mauvaise foi t'as rien à m'envier  .

[Stef]

Effectivement ça ne change rien au problème, je pense effectivement que le CPU est bloqué s'il tente de lire ou écrire la VRAM pendant le HBlank, donc on doit perdre un peu du débit comme au VBlank mais rien de catastrophique. Le plus chiant c'est la perte de cycles CPU pour rien.

[Stef]

Surement, mais bon arriver à utiliser cette moitié de hblank pour transférer en VRAM relève un peu de l'exploit ..

O_o ??? Je saiss pas pour Epsilandre mais décidément je comprend de moins en moins ce que tu racontes

On sait tout qu'en plus d'avoir toujours raison, tu sais tout sur tout hein stef, même quand tu te fais reprendre par tes collègues codeurs Md tellement tu trolles sur la snes en vantant la supériorité de la Md   
Ah oui c'est vrai, qu'eux n'y connaissent rien .

Ah ouais ? Arrêtes tes fantasmes s'il te plait   J'aimerai bien que tu me retrouves ça qu'on rigole... Sur SnesDev, quand tu leur montre que leur machine a plein de défauts il ferme le topic

[upsilandre]

Surement, mais bon arriver à utiliser cette moitié de hblank pour transférer en VRAM relève un peu de l'exploit ..

C'est pas la moitié mais 80% du Hblank et puis je comprend pas ce que tu veux dire, il est pas question d'exploit. Le fait est qu'il y a environ 20% de la scanline ou le CPU n'a pas acces a la VRAM donc ca change quand meme des choses. Ca veut dire qu'on peut pas vraiment dire que l'acces a la VRAM est totalement libre, ca veut dire que c'est pas 65 octets par scanline que tu peux transférer mais 52 octets par scanline et ca change aussi la perception qu'on peut avoir de la periode de Vblank. Pour moi ca fait pas mal de note a modifier

[Invité]

O_o ??? Je saiss pas pour Epsilandre mais décidément je comprend de moins en moins ce que tu racontes 

il parle de savoir si on peut utiliser le hblank pour transférer, donc si on prend le fait que c'est impossible pendant le fetch des sprites, soit la moitié du hblank, donc même si on pouvait le faire ,synchroniser le transfert pendant ce labs de temps est quasi impossible,vu que tu ne comprends que les mots MD >snes/pce, ça ne m'étonne pas 

upsilandre: tu as lut ce que je t'ai posté ??

A MWR setting of $00 gives the CPU the largest amount of access cycles (twice per 8 pixels) which seems to be exactly equal to the amount of accesses available during BURST mode.

Ca veut bien dire que pendant l'affichage c'est la même chose que pendant le burst si le registre $9 du VDC est sur 0, enfin les bits 0 à 3 .

C'est pas la moitié mais 80% du Hblank et puis je comprend pas ce que tu veux dire, il est pas question d'exploit. 

Je te parle d'exploit dans le sens prouesse, et non exploitation de faille .

[upsilandre]

il parle de savoir si on peut utiliser le hblank pour transférer, donc si on prend le fait que c'est impossible pendant le fetch des sprites, soit la moitié du hblank, donc même si on pouvait le faire ,synchroniser le transfert pendant ce labs de temps est quasi impossible,vu que tu ne comprends que les mots MD >snes/pce, ça ne m'étonne pas 

Mais j'ai jamais parlé de ca

J'explique depuis le debut que les transfère CPU/ROM/RAM > VRAM ne peuvent pas se faire a plein debit hors du Vblank a cause de la phase de fetch des pattern de sprite qui bloque l'acces a la VRAM pendant 20% de chaque scanline et que donc on a pas un budget de 65 octets par scanline mais de 52 pendant l'affichage.
Vraiment je comprend pas ou on peut avoir compris autre chose, et tu as tout a fait le droit de dire que t'en sais rien, c'est pas interdit et ca fait gagner du temps

[Invité]

bon j'ai l'impression que tu cites archaic quand ça t'arrange ou quoi ??
Je te quote exactement ce qui est dit dedans à propos des accès à la VRAM pendant l'affichage, que c'est exactement la même chose que pendant le burst mode, CAD pendant le vblank .

Tu as 2 slots CPU tout les 8 pixels,sur un affichage 256 pixels cela fait 64 slots .

[upsilandre]

upsilandre: tu as lut ce que je t'ai posté ??

A MWR setting of $00 gives the CPU the largest amount of access cycles (twice per 8 pixels) which seems to be exactly equal to the amount of accesses available during BURST mode.

Ca veut bien dire que pendant l'affichage c'est la même chose que pendant le burst si le registre $9 du VDC est sur 0, enfin les bits 0 à 3 .

Mais non. quand tu met 0 qui est le mode normal effectivement tu ouvres tous les slot CPU possible... pendant la phase de fetch du bg mais pendant la phase de fetch des sprites la doc est claire, aucun slot CPU pendant cette phase. r$9 sur 0 ou pas.

Ca c'est ce qu'ils se passe niveau VRAM pendant le fetch des 34 tiles de bg, seulement 3 slot sur 8 utilisé par le VDC, logique.


Et ca pendant le fetch des sprites, tout les slot utilisé par le VDC, logique aussi.


Y a aucun slot CPU pendant cette phase, c'est du stream full debit (comme sur les 2 autres consoles) et c'est bien pour ca que le VDC peut fetcher tous les sprites pendant le Hblank.