Re: MEGADRIVE vs SUPER NINTENDO : Fight !

[Agathon]

Hyper intéressant, merci à vous trois.
Du coup je me pose une question:
N'y avait il pas moyen pour sega d'augmenter le nombre de palette avec une puce intégré directement dans les jeux?

[Invité]

Oui dans la doc,la copie vers le vdc prend 7 cycles,mais il me semble que c est marque nulle part dans la doc officiele.
Sinon ce serrait le cas pour toutes les instructions qui ecrivent dans le vdc.
Un sta par exemple.

[lessthantod]

Hyper intéressant, merci à vous trois.

C'est clair que c'est intéressant, plus intéressant que "la MD c'est pour les sourds/aveugles" et "la SNES c'est pour les petites filles" ... mais du coup, c'est moins drôle aussi!

[Invité]

Hyper intéressant, merci à vous trois.
Du coup je me pose une question:
N'y avait il pas moyen pour sega d'augmenter le nombre de palette avec une puce intégré directement dans les jeux?

Houla, attention, quand Nintendo fait ça dans ses cartouches c'est scandaleux il paraît.

[upsilandre]

Je vois que tu as bien creusé la chose, j'avoue ne pas avoir autant regardé en détail. Mais du coup, est-il vraiment possible de doubler le débit en utilisant 128 KB de VRAM (et donc en doublant le nombre de chip) ?

La franchement je vois pas trop comment.
Je suis presque sur que les 2 ports sont deja utilisé sur MD (et au mieux) sinon je vois pas l’intérêt d'avoir cablé le port "random" sur le bus d'adressage du VDC plutot que sur le bus de donnée si ce n'est pour simuler un second bus de donnée (en multiplexage) et donc pouvoir l'utiliser en simultané.
Et puis quand on dit simultané c'est un bien grand mot, le port random est effectivement dispo tant que tu fait vraiment du streaming sur le buffer du port "serial", dès que le port "serial" a besoin d'acceder a une nouvelle donnée ailleurs (donc de facon random) il bloque l'autre port et finalement dans le cas de la MD y a pas trop d'occasion de vraiment streamer sur de gros bloc.
Si c'etait pour un double framebuffer bitmap le DAC pourrait effectivement s'alimenter en streaming sur le port "serial" et laisser le port random quasiment tout le temps libre (y a 256 octets de dispo dans le buffer donc en toute autonomie et ca se charge en un coup, c'est comme si t'avais un bus 2048bit en interne) mais dans le cas du type d'affichage console y a pas tellement d'occasion de streamer, le cas le plus classique c'est le chargement des patterns qui sont des paquets de seulement 4 octets random (mais c'est quand meme 4 octets successive, c'est deja ca).

J'ai du mal a definir exactement les cycles car la mémoire est tres complexe, mais ca doit etre quelque chose comme 3 cycles pour charger le premier octet sur le port "serial" puis ensuite 1 cycle pour chaque octet suivant en streaming (donc 3 cycles supplémentaire si c'est un paquet de 4 octets) et ensuite on recommence (donc peut etre 6 cycles pour 4 octets dans ce cas, dans cette exemple ca voudrait dire un port "serial" utilisé seulement au 2 tiers de ses capacités max ce qui du coup a lui tout seul serait pas suffisant sauf peut etre si on est au triple du dot clock) et pendant ces 3 cycles de streaming il est fort possible a mon avis que le VDC insère un acces a l'autre port "random" pour charger un octet supplémentaire utilisé pour autre chose que les patterns . Je vois bien une sorte de danse de ce type avec chaque fois 4 octets lu sur le port "serial" + 1 octets lu sur l'autre port en simultané pendant la courte phase de streaming. (dans mon exemple avec une frequence double du dot clock ca ferait 707 octet/scanline, c'est peut etre pas encore assez a mon avis mais y a peut etre un ou deux phase de streaming plus efficace que des paquets de 4 octets pendant la scanline pour augmenter un peu ce chiffre)

Tout ca pour dire que le second port peut etre un soutient mais il est pas la pour doubler le debit pour repondre a ta question (et de toute facon certainement deja utilisé sur MD)

Je suis d'ailleurs presque sure que pour les acces manuel a la VRAM par le CPU ou les acces DMA tout passe par le port "random" (et donc par la aussi que passe les 18 octets qu'on peut insérer pendant l'affichage). Le port "serial" limité a la lecture est l'exclusivité du VDC je pense.
le port "serial" a vraiment un cycle tres court quand il est en streaming (puisqu'il tape dans un registre) c'est apparemment 40ns, alors que le port "random" (qui est le port DRAM en quelque sorte) lui est au moins 3x plus lent (et de toute facon imposé par le multiplexage qui nécessite 3 cycles par acces, la question c'est plutot de savoir si ils en utilisent aussi un 4eme mais je pense pas).
Du coup je commence a me demander si la frequence de la mémoire est pas plutot 3x le dot clock (20mhz). Ca serait vraiment intéressant de connaitre la clock entre le VDC et la VRAM parce que sans ca on restera dans le flou. (y a une master clock a 20mhz quelque part?)

Le truc a retenir au moins c'est que la lecture se fait dans tout les cas bien plus rapidement que l'ecriture. C'est pas du tout symetrique, je dirais que c'est la principale caractéristique a retenir sur la VRAM de la MD. (et qu'il est peut etre galvauder de parler de VRAM 8bit, c'est plus complexe que ca, y a probablement un second bus de donnée 8bit caché dans le multiplexage du bus d'adresse. Donc on le voit pas sur le cablage mais il est la)

Sinon je lis souvent que pour son affichage le VDP de la MD doit faire un peu plus de 1000 accès (byte) à la VRAM

Ca ca m'intéresse aussi de savoir, ca donnerait des pistes pour bien mieux estimer la VRAM.

perso j'arrive à presque 2x moins (~600 bytes), si on prend les 2 plans plus les sprites on a déjà 336 + 320 pixels soit 328 bytes

Je pense que tu t'es emmêlé les pinceaux sur ton calcule des 2 plans (en gros t'en a oublié un)
Pour moi c'est 656 + 320 = 488 octets

ensuite tu as les tilemap (160 bytes = 40*2*2) + les 20 sprites parsés par ligne (les autres sont en cache en interne dans le VDP) soit envion 20*4 bytes à fetcher en plus (80 bytes) et surement quelques bytes en plus pour les scrollings et autres trucs dans le genre, on arrive à 328 + 160 + 80 + ~40 = ~600 bytes par scanline à lire depuis la VRAM.
Ou est mon erreur ?

La question que moi je me posais c'est surtout le chargement des Y de tout l'OAM pour préparer l'affichage des sprites et qui boufferait beaucoup de bande passante mais t'as l'aire de dire qu'il y a un buffer interne (donc probablement remplit juste avant la premiere ligne) ce qui me paraîtrait logique car sinon c'est compliqué (d'autant que les Y ne sont pas stocké dans une table continu indépendante en VRAM qui pourrait profiter du streaming du port "serial", ils sont dispersés et des paquets de 2 octets ca serait pas rapide a lire, ils auraient au moins fait l'effort de réunir les Y en VRAM). Ca fait une table qui fait la taille de celle du Vscroll (meme 80bit de moins) donc c'est gérable.

Donc dans ce cas oui ca ferait dans les 750 octets, les 1000 octets me paraissent difficile a atteindre, tu sais ou tu a lu ca?
En tout ca un port "serial" a 13.34mhz (double du dot clock) ca donnerait max environ 830 octets mais comme on est quand meme loin du cas d'un streaming pure ca serait plutot dans les 600 octets au mieux, dans ce cas ca serait l'aide du second port (dans mon exemple on voyait qu'il pouvait complété de 25% soit ici 150 octets) qui permettrait peut etre d'atteindre le bon chiffre.
Ou alors on a une fréquence triple de 20mhz et la on serait a l'aise. Connaitre la fréquence permettrait vraiment de mieux trancher sur les differents scénarios.




PS: En fait si je suis un peu pointilleux sur tout ca c'est que j'ai pris l'habitude de prendre des notes sur toutes les machines sur lesquelles je m'informe depuis la channel F + divers autres remarque et recherche. J'ai deja environ 250 000 caractères de notes condensés mais quand j'y ajoute un chiffre je veux etre sure de ce chiffre et ne pas avoir ultérieurement a en douter quand je relis les notes et que je ne me rappel plus trop de la démarche pour y arriver sinon je préfere ne pas l'ajouter a mes notes. Donc j'aime bien aller jusqu'au bout tant que je suis a chaud sur le sujet pour en garder quelque chose dans mes notes car c'est le genre de chose sur lequel j'ai peu de chance de revenir ensuite.

[upsilandre]

Hyper intéressant, merci à vous trois.
Du coup je me pose une question:
N'y avait il pas moyen pour sega d'augmenter le nombre de palette avec une puce intégré directement dans les jeux?

Les palettes ce sont des données qui doivent etre intimement lié au GPU car ca demande beaucoup d'acces donc en général elle sont a l'interieur du GPU (pour la PCE elles sont dans le DAC) et elles ont de toute facon un cablage dédié (sur NeoGeo elles sont dans un chip externe si je me souviens bien mais cablé de facon spécifique sur le GPU ou le DAC), on peut pas les court-circuité en en ajoutant d'autres palettes quelques part sur le bus CPU (cartouche) + trouver un moyen de contourner la limitation de 2bit dans les attributs tile et sprite qui selectionne la palette.
Donc je dirais non, c'est trop intimement lié a l'architecture de la machine, y a des choses au niveau affichage qu'on ne peut pas customiser du tout (c'est comme vouloir contourner le 2bpp de la NES qui est sa principale limitation, quoique tu mettent dans les cartouches t'en fera pas une machine 4bpp)

[upsilandre]

Oui dans la doc,la copie vers le vdc prend 7 cycles,mais il me semble que c est marque nulle part dans la doc officiele.
Sinon ce serrait le cas pour toutes les instructions qui ecrivent dans le vdc.
Un sta par exemple.

ok donc on est bien sur un rapport 7 cycles vs 4 cycles pour le trick ST0/1?

[Stef]

Oui dans la doc,la copie vers le vdc prend 7 cycles,mais il me semble que c est marque nulle part dans la doc officiele.
Sinon ce serrait le cas pour toutes les instructions qui ecrivent dans le vdc.
Un sta par exemple.

Tu as déjà vraiment essayé de benchmarker sur le real hardware ? car si c'est écrit 7 cycles c'est peut-être qu'il y a effectivement une penalité lors de l'écriture de ce port. Malgré tout avec le STA tu dois pouvoir aller plus vite (peut être 5 cycles).

[Invité]

Non j'ai pas testé sur le vrai hard .
Oui STA fait du 5 cycles mais en RAM(ou 4 en ZP), tout comme les instructions Txx font 6 cycles en ram .
Donc je pense que tu dois avoir là aussi une pénalité (ce qui serait logique) .

ok donc on est bien sur un rapport 7 cycles vs 4 cycles pour le trick ST0/1?

Pareil que les txx, certaines docs les donnent pour 5 cycles quand tu écris en VRAM, la doc officielle donne 4 cycles sans pénalité .

[ace76]

putain,j'y comprends que dalle.................

[Invité]

putain,j'y comprends que dalle.................

Je te fais un résumé.

Snes > MD. Pas besoin de chiffres, juste besoin de jouer.

[upsilandre]

Non j'ai pas testé sur le vrai hard .
Oui STA fait du 5 cycles mais en RAM(ou 4 en ZP), tout comme les instructions Txx font 6 cycles en ram .
Donc je pense que tu dois avoir là aussi une pénalité (ce qui serait logique) .

ok donc on est bien sur un rapport 7 cycles vs 4 cycles pour le trick ST0/1?

Pareil que les txx, certaines docs les donnent pour 5 cycles quand tu écris en VRAM, la doc officielle donne 4 cycles sans pénalité .

ok j'avais pas compris, tu voulais dire qu'il y a probablement pénalité sur les 2 types d'instructions.
Effectivement je viens de voir sur la doc archaicpixel que c'est 5 cycles pour le ST0/1/2.
Ca donnerait donc plutot 65o/s vs 91o/s, soit un gain +40% ce qui me parait plus credible que l'autre scénarios a +75% (114o/s) qui aurait probablement bien plus incité a utiliser ce trick qu'il ne l'est.

[Agathon]

Hyper intéressant, merci à vous trois.
Du coup je me pose une question:
N'y avait il pas moyen pour sega d'augmenter le nombre de palette avec une puce intégré directement dans les jeux?

Les palettes ce sont des données qui doivent etre intimement lié au GPU car ca demande beaucoup d'acces donc en général elle sont a l'interieur du GPU (pour la PCE elles sont dans le DAC) et elles ont de toute facon un cablage dédié (sur NeoGeo elles sont dans un chip externe si je me souviens bien mais cablé de facon spécifique sur le GPU ou le DAC), on peut pas les court-circuité en en ajoutant d'autres palettes quelques part sur le bus CPU (cartouche) + trouver un moyen de contourner la limitation de 2bit dans les attributs tile et sprite qui selectionne la palette.
Donc je dirais non, c'est trop intimement lié a l'architecture de la machine, y a des choses au niveau affichage qu'on ne peut pas customiser du tout (c'est comme vouloir contourner le 2bpp de la NES qui est sa principale limitation, quoique tu mettent dans les cartouches t'en fera pas une machine 4bpp)

Ok, mais alors comment fonctionne le 32x? C'est une console a part qui utilise seulement l'alimentation de la megadrive?

[upsilandre]

Hyper intéressant, merci à vous trois.
Du coup je me pose une question:
N'y avait il pas moyen pour sega d'augmenter le nombre de palette avec une puce intégré directement dans les jeux?

Les palettes ce sont des données qui doivent etre intimement lié au GPU car ca demande beaucoup d'acces donc en général elle sont a l'interieur du GPU (pour la PCE elles sont dans le DAC) et elles ont de toute facon un cablage dédié (sur NeoGeo elles sont dans un chip externe si je me souviens bien mais cablé de facon spécifique sur le GPU ou le DAC), on peut pas les court-circuité en en ajoutant d'autres palettes quelques part sur le bus CPU (cartouche) + trouver un moyen de contourner la limitation de 2bit dans les attributs tile et sprite qui selectionne la palette.
Donc je dirais non, c'est trop intimement lié a l'architecture de la machine, y a des choses au niveau affichage qu'on ne peut pas customiser du tout (c'est comme vouloir contourner le 2bpp de la NES qui est sa principale limitation, quoique tu mettent dans les cartouches t'en fera pas une machine 4bpp)

Ok, mais alors comment fonctionne le 32x? C'est une console a part qui utilise seulement l'alimentation de la megadrive?

Faut demander a stef moi je connais pas le 32x mais si je me souviens ce qu'il a deja dit c'est que le VDP de la megadrive a la possibilité de pouvoir mixer son signal video avec un autre signal donc oui le 32x est probablement une console entière indépendante qui va mixer sont signal video avec celui de la Megarive.
Effectivement dans ce cas (d'une console qui peut mixer 2 signaux video) les possibilités de customisations sont infinis. Mais bon au final c'est juste une autre console que t'achetes.

edit: ou alors c'est peut etre l'inverse, c'est le 32x qui récupère le signal de la MD. Je sais meme pas comment les 2 sont connectés ni meme si la 32x a sa propre sortie video.

[Stef]

La franchement je vois pas trop comment.
Je suis presque sur que les 2 ports sont deja utilisé sur MD (et au mieux) sinon je vois pas l’intérêt d'avoir cablé le port "random" sur le bus d'adressage du VDC plutot que sur le bus de donnée si ce n'est pour simuler un second bus de donnée (en multiplexage) et donc pouvoir l'utiliser en simultané.

Il me semblait qu'en mettant en parallèle sur le bus les autres chips mémoire c'était le cas mais j'ai surement du mal regarder la manière dont c'était cablé.

Et puis quand on dit simultané c'est un bien grand mot, le port random est effectivement dispo tant que tu fait vraiment du streaming sur le buffer du port "serial", dès que le port "serial" a besoin d'acceder a une nouvelle donnée ailleurs (donc de facon random) il bloque l'autre port et finalement dans le cas de la MD y a pas trop d'occasion de vraiment streamer sur de gros bloc.
Si c'etait pour un double framebuffer bitmap le DAC pourrait effectivement s'alimenter en streaming sur le port "serial" et laisser le port random quasiment tout le temps libre (y a 256 octets de dispo dans le buffer donc en toute autonomie et ca se charge en un coup, c'est comme si t'avais un bus 2048bit en interne) mais dans le cas du type d'affichage console y a pas tellement d'occasion de streamer, le cas le plus classique c'est le chargement des patterns qui sont des paquets de seulement 4 octets random (mais c'est quand meme 4 octets successive, c'est deja ca).

En fait tu as quand meme des possibilité de streamer quelques accés, genre pour les tilemap tout est lue par paquet de 4 octets (2 cells à la fois), et ensuite effectivement chaque ligne de pattern (4 octets). Mais sinon effectivement tu as des pertes forcément vu comment les données sont un peu éparpillées.
Nemesis avait fait un bon travail là dessus :

J'ai du mal a definir exactement les cycles car la mémoire est tres complexe, mais ca doit etre quelque chose comme 3 cycles pour charger le premier octet sur le port "serial" puis ensuite 1 cycle pour chaque octet suivant en streaming (donc 3 cycles supplémentaire si c'est un paquet de 4 octets) et ensuite on recommence (donc peut etre 6 cycles pour 4 octets dans ce cas, dans cette exemple ca voudrait dire un port "serial" utilisé seulement au 2 tiers de ses capacités max ce qui du coup a lui tout seul serait pas suffisant sauf peut etre si on est au triple du dot clock) et pendant ces 3 cycles de streaming il est fort possible a mon avis que le VDC insère un acces a l'autre port "random" pour charger un octet supplémentaire utilisé pour autre chose que les patterns . Je vois bien une sorte de danse de ce type avec chaque fois 4 octets lu sur le port "serial" + 1 octets lu sur l'autre port en simultané pendant la courte phase de streaming. (dans mon exemple avec une frequence double du dot clock ca ferait 707 octet/scanline, c'est peut etre pas encore assez a mon avis mais y a peut etre un ou deux phase de streaming plus efficace que des paquets de 4 octets pendant la scanline pour augmenter un peu ce chiffre)
...

Le truc a retenir au moins c'est que la lecture se fait dans tout les cas bien plus rapidement que l'ecriture. C'est pas du tout symetrique, je dirais que c'est la principale caractéristique a retenir sur la VRAM de la MD. (et qu'il est peut etre galvauder de parler de VRAM 8bit, c'est plus complexe que ca, y a probablement un second bus de donnée 8bit caché dans le multiplexage du bus d'adresse. Donc on le voit pas sur le cablage mais il est la)

Effectivement le détail sur la manière dont fonctionne le serial port (et à quel vitesse) est un peut obscure pour moi, en gros j'ai l'impression que tu peux espérer récupérer environ 4 bytes en lecture quand tu as 1 byte en écriture, mais après savoir la latence du premier accès etc... aucune idée. Sinon la clock de base du VDP c'est ~53.7 Mhz, c'est assez haut (pour l'époque), y'a surement une bonne raison à ça quand même.

Je pense que tu t'es emmêlé les pinceaux sur ton calcule des 2 plans (en gros t'en a oublié un)
Pour moi c'est 656 + 320 = 488 octets

Effectivement j'ai posté un peu rapidement, j'ai corrigé mon post depuis, mais même en étant large, j'arrive à 800 bytes à tout casser, alors que plusieurs fois j'ai vu un peu pus de 1000 voir 1100.

La question que moi je me posais c'est surtout le chargement des Y de tout l'OAM pour préparer l'affichage des sprites et qui boufferait beaucoup de bande passante mais t'as l'aire de dire qu'il y a un buffer interne (donc probablement remplit juste avant la premiere ligne) ce qui me paraîtrait logique car sinon c'est compliqué (d'autant que les Y ne sont pas stocké dans une table continu indépendante en VRAM qui pourrait profiter du streaming du port "serial", ils sont dispersés et des paquets de 2 octets ca serait pas rapide a lire, ils auraient au moins fait l'effort de réunir les Y en VRAM). Ca fait une table qui fait la taille de celle du Vscroll (meme 80bit de moins) donc c'est gérable.

Effectivement une partie de l'OAM est cachée en interne dans le VDP car ça consommerait bien trop de bande passante VRAM pour lire les données des 80 sprites pendant un scanline ! La valeur Y (16 bits qui plus est) est effectivement cachée pour cette raison (ainsi que d'autre champ comme la taille) pour savoir si le sprite est visible avant d'aller fetcher le reste des datas en VRAM.

edit: ou alors c'est peut etre l'inverse, c'est le 32x qui récupère le signal de la MD. Je sais meme pas comment les 2 sont connectés ni meme si la 32x a sa propre sortie video.

C'est exactement ça, en fait il récupère le signal vidéo de la MD directement depuis le sortie vidéo de la MD (tu as un cable dédié), le 32X mix son signal vidéo avec celui de la MD et ressort le tout dans sa propre sortie vidéo.

[upsilandre]

En fait tu as quand meme des possibilité de streamer quelques accés, genre pour les tilemap tout est lue par paquet de 4 octets (2 cells à la fois), et ensuite effectivement chaque ligne de pattern (4 octets). Mais sinon effectivement tu as des pertes forcément vu comment les données sont un peu éparpillées.
Nemesis avait fait un bon travail là dessus :

oui la on voit clairement que tous les acces se font par paquet de 4 octets, ce qu'ils nomment les slots (chaque case) d'ou le fait de traiter 2 tiles simultané pour les tilemap (les attribut des sprites aussi par 4 octets) ce qui fait sens puisque c'est le minimum pour pouvoir bien exploiter le port "serial".
D'ailleurs il a l'aire d'indiquer la frequence du port "serial" au double du dot clock (13.34mhz) comme suposé au depart mais dans ce cas ca voudrait dire que le debit en streaming est tout le temps au maximum théorique donc soit y a un mecanisme au niveau de la VRAM qui permet de préparer le prochain acces random du port "serial" pendant le stream des 4 octets et d'enchainer les slots sans perdre un seul cycle (mais ca me parait difficile mais pourquoi pas) soit c'est 3 octets port "serial" + un octet port "random" pendant le stream pour obtenir les 4 octets en 4 cycles.
On voit aussi les 18 slots d'acces externe et qui se limite donc chacun a un seul octet au lieu de 4 et puisqu'on peut aussi ecrire pendant ces acces externe c'est forcement le port "random" donc peut etre un signe que les 2 port sont bien utilisé en meme temps pendant les autres slots aussi.
Mais il reste quand meme toujours une possibilité d'un scenarios ou le "random" port est utilisé uniquement en ecriture et le "serial" port uniquement en lecture (avec donc la possibilité de cacher les acces random a partir du moment ou t'as un stream d'au moins 4 octets). Difficile de trancher.

Par rapport au shema si on enleve les 18 slots d'acces externe et les 5 slot de refresh on obtient 187 slot par scanline soit 748 octets utilisé par le VDC pendant l'affichage (j'avais estimé a 750   )  donc oui c'est loin des 1100.

Et du coup les 205 octets/scanline pour le DMA sont claire aussi sur le shema. un slot complet pour ecrire juste un octet par le port "random", y a 210 slot - 5 slot de refresh = 205 octets. C'est le maximum qui etait possible.


EDIT: Sur le shematic de la mémoire je viens de voir qu'il y a un "data transfer gate" qui semble etre une sorte de second registre 1024bit intermediaire entre la DRAM et le registre utilisé par le "serial" port pour le streaming du coup y a peut etre vraiment moyen de pouvoir préparer le prochain acces random du "serial" port pendant le stream des 4 octets et donc de pouvoir enchainer les slots au max du debit théorique uniquement avec le port "serial" (mais le port "random" est alors inutilisable mais on s'en fou dans ce cas).
Je pense qu'on est plutot sur ce scénarios qui me parait moins tordu. Le port "serial" est donc dédié a la lecture et le port "random" uniquement a l'ecriture (du coup c'est pas galvauder de dire que la VRAM est 8bit, juste que les bus de donnée en ecriture et lecture ne sont pas les meme). Et ca veut dire aussi que la DRAM est donc dans ce cas sollicité a seulement 3.33mhz (dans l'autre scénarios ou le 2 port serait combiné en lecture ca impliquait de stresser la DRAM a 6.67mhz ce qui me parait trop pour de la DRAM) ce qui est plutot intéressant en terme d'efficacité, en fait c'est comme si la DRAM etait cablé sur un bus 32bit (donc répéter que c'est de la memoire en 8bit si c'est pas faux c'est sans doute pas pertinent du tout).

Je pense que pour mes notes je vais rester sur ce scénario, ca semble etre le bon. Lecture a 13.34mhz par le port "serial" (qui ne solicite la DRAM qu'a 3.33mhz) et ecriture a 3.33mhz par le "port" random, un scénarios finalement simple.
Par contre je pense qu'il faut oublier cette idée de pouvoir doubler la bande passante en doublant les chips, y a a priori aucune raison.

Effectivement le détail sur la manière dont fonctionne le serial port (et à quel vitesse) est un peut obscure pour moi, en gros j'ai l'impression que tu peux espérer récupérer environ 4 bytes en lecture quand tu as 1 byte en écriture, mais après savoir la latence du premier accès etc... aucune idée.

oui c'est ce qu'il faut retenir

Sinon la clock de base du VDP c'est ~53.7 Mhz, c'est assez haut (pour l'époque), y'a surement une bonne raison à ça quand même.

53.7 / 7 on obtient la frequence CPU mais /8 on obtient pas tout a fait le dotclock, c'est curieux.

[upsilandre]

Pour résumer la VRAM de la MD en ecriture c'est exactement comme une DRAM 8bit a 3.33mhz et en lecture c'est comme une DRAM 32bit a 3.33mhz et tout ca en utilisant juste un bus de donnée 8bit et un bus d'adressage 8bit sur le VDP. Donc c'est plutot bien joué (faut voir le coup supplémentaire de ce genre de RAM custom)

[Invité]

Snes > MD. Pas besoin de chiffres, juste besoin de jouer.

C'est un peu ça .. 

ok j'avais pas compris, tu voulais dire qu'il y a probablement pénalité sur les 2 types d'instructions.

Oui,logiquement toutes les instructions qui permettent de lire ou écrire dans le VDC ..

Ca donnerait donc plutot 65o/s vs 91o/s, soit un gain +40% ce qui me parait plus credible que l'autre scénarios a +75% (114o/s) qui aurait probablement bien plus incité a utiliser ce trick qu'il ne l'est.

Après faut pas non plus oublier qu'a l'époque tu pouvais pas te permettre de consommer 2x fois plus de place en ROM pour un trick .

EDIT: d'après charles Mc donalds, il semble que ce soit le CPU qui génère le +1 cycle de délai lors de l'écriture en VRAM .

[upsilandre]

Après faut pas non plus oublier qu'a l'époque tu pouvais pas te permettre de consommer 2x fois plus de place en ROM pour un trick .

Quand je vois par exemple Rare utiliser 64x plus de data que nécessaire pour le fond du background du level 4 de Battletoad sur NES juste pour un trick d'effet de parallaxe multidirectionnel alors le x2 ca me choque pas.
Tu fais pas tout ton jeu comme ca mais ca peut permettre de différencier un level en faisant un effet visuel different des autres donc c'est toujours bon a connaitre mais +40% c'est sans doute trop peu pour que ca soit intéressant juste pour un FX ponctuel.

[Stef]

oui la on voit clairement que tous les acces se font par paquet de 4 octets, ce qu'ils nomment les slots (chaque case) d'ou le fait de traiter 2 tiles simultané pour les tilemap (les attribut des sprites aussi par 4 octets) ce qui fait sens puisque c'est le minimum pour pouvoir bien exploiter le port "serial".
D'ailleurs il a l'aire d'indiquer la frequence du port "serial" au double du dot clock (13.34mhz) comme suposé au depart mais dans ce cas ca voudrait dire que le debit en streaming est tout le temps au maximum théorique donc soit y a un mecanisme au niveau de la VRAM qui permet de préparer le prochain acces random du port "serial" pendant le stream des 4 octets et d'enchainer les slots sans perdre un seul cycle (mais ca me parait difficile mais pourquoi pas) soit c'est 3 octets port "serial" + un octet port "random" pendant le stream pour obtenir les 4 octets en 4 cycles.
On voit aussi les 18 slots d'acces externe et qui se limite donc chacun a un seul octet au lieu de 4 et puisqu'on peut aussi ecrire pendant ces acces externe c'est forcement le port "random" donc peut etre un signe que les 2 port sont bien utilisé en meme temps pendant les autres slots aussi.
Mais il reste quand meme toujours une possibilité d'un scenarios ou le "random" port est utilisé uniquement en ecriture et le "serial" port uniquement en lecture (avec donc la possibilité de cacher les acces random a partir du moment ou t'as un stream d'au moins 4 octets). Difficile de trancher.

Perso je pensais vraiment que les 2 ports étaient exploités à fond, du coup 3 octets sur le serial + 1 sur le parallèle, ce qui expliquerait pourquoi on a pas d'accès externe pendant la lecture des datas.

Par rapport au shema si on enleve les 18 slots d'acces externe et les 5 slot de refresh on obtient 187 slot par scanline soit 748 octets utilisé par le VDC pendant l'affichage (j'avais estimé a 750   )  donc oui c'est loin des 1100.

Et du coup les 205 octets/scanline pour le DMA sont claire aussi sur le shema. un slot complet pour ecrire juste un octet par le port "random", y a 210 slot - 5 slot de refresh = 205 octets. C'est le maximum qui etait possible.

Oui j'avais donné ~800 mais en comptant les externes mais effectivement visiblement on y est même pas.

EDIT: Sur le shematic de la mémoire je viens de voir qu'il y a un "data transfer gate" qui semble etre une sorte de second registre 1024bit intermediaire entre la DRAM et le registre utilisé par le "serial" port pour le streaming du coup y a peut etre vraiment moyen de pouvoir préparer le prochain acces random du "serial" port pendant le stream des 4 octets et donc de pouvoir enchainer les slots au max du debit théorique uniquement avec le port "serial" (mais le port "random" est alors inutilisable mais on s'en fou dans ce cas).
Je pense qu'on est plutot sur ce scénarios qui me parait moins tordu. Le port "serial" est donc dédié a la lecture et le port "random" uniquement a l'ecriture (du coup c'est pas galvauder de dire que la VRAM est 8bit, juste que les bus de donnée en ecriture et lecture ne sont pas les meme). Et ca veut dire aussi que la DRAM est donc dans ce cas sollicité a seulement 3.33mhz (dans l'autre scénarios ou le 2 port serait combiné en lecture ca impliquait de stresser la DRAM a 6.67mhz ce qui me parait trop pour de la DRAM) ce qui est plutot intéressant en terme d'efficacité, en fait c'est comme si la DRAM etait cablé sur un bus 32bit (donc répéter que c'est de la memoire en 8bit si c'est pas faux c'est sans doute pas pertinent du tout).

Ok, c'est effectivement plus cohérent, du coup pendant un slot tu utilises soit le serial (à fond de ses capacités) ou soit le parallèle qui peut lui lire ou écrire (un external slot peut se faire en lecture en fait).

Je pense que pour mes notes je vais rester sur ce scénario, ca semble etre le bon. Lecture a 13.34mhz par le port "serial" (qui ne solicite la DRAM qu'a 3.33mhz) et ecriture a 3.33mhz par le "port" random, un scénarios finalement simple.
Par contre je pense qu'il faut oublier cette idée de pouvoir doubler la bande passante en doublant les chips, y a a priori aucune raison.

Voilà, je pense qu'on peut résumer globalement comme ça =) Simple débit à 3.33 Mhz en écriture contre un débit à 13.34 Mhz en lecture streamé :) Mais encore une fois, je trouve que c'est une super solution technique pour l'époque... Plus complexe à mettre en oeuvre qu'un simple DRAM mais qui offre surement un très bon rapport performance / prix.

53.7 / 7 on obtient la frequence CPU mais /8 on obtient pas tout a fait le dotclock, c'est curieux.

Il me semble que si non ? J'ai souvent lu que le dot clock H40 (6.71 Mhz) de la MD était généré à partir du dot clock H32 (qui correspond au master clock / 10), soit dot clock H40 = dot clock H32 * 5/4. Mais après ça correspond exactement au master clock /8 donc je ne vois pas pourquoi ça fonctionnerait ainsi...

[upsilandre]

Perso je pensais vraiment que les 2 ports étaient exploités à fond, du coup 3 octets sur le serial + 1 sur le parallèle, ce qui expliquerait pourquoi on a pas d'accès externe pendant la lecture des datas.

En fait quand tu utilises le port "serial" en stream sur des petits paquets de 4 octets c'est comme si tu utilisais les 2 port a fond car pendant que le port serial stream sur le registre, la VRAM piloté par le VDP a juste le temps de faire un nouvel acces random a la DRAM pour préparer la prochaine charge du registre du port serial donc tous les acces random a la DRAM normalement utilisé par l'autre port sont deja utilisés ici par le port serial de toute facon. Y a plus de place pour lui, le port "random" ne peut pas etre utilisé dans ce contexte donc c'est normal.

Voilà, je pense qu'on peut résumer globalement comme ça =) Simple débit à 3.33 Mhz en écriture contre un débit à 13.34 Mhz en lecture streamé :)

Oui c'est ca du point de vue du bus de donnée et si on se place du point de vue de la DRAM c'est comme du 8bit a 3.33mhz en ecriture et du 32bit a 3.33mhz en lecture (plutot que du 8bit a 13.34mhz). La DRAM n'est jamais trop stressé et c'est ca aussi l'avantage de cette solution qu'il faut souligner.
L'equilibre entre ecriture et lecture est parfaite pour les besoins. Et la granularité forcé a 4 octets (contre 2 sur PCE et SNES) colle aussi parfaitement aux besoins de cette génération, pas besoin d'une granularité plus fine (par contre 8 octets ca aurait ete compliqué, ca aurait ete bon seulement si t'es obligé d'utiliser des tiles et sprites de 16 pxiels ou pour du 8bpp)

Il me semble que si non ? J'ai souvent lu que le dot clock H40 (6.71 Mhz) de la MD était généré à partir du dot clock H32 (qui correspond au master clock / 10), soit dot clock H40 = dot clock H32 * 5/4. Mais après ça correspond exactement au master clock /8 donc je ne vois pas pourquoi ça fonctionnerait ainsi...

La premiere fois j'ai lu que c'etait 6.67mhz le dot clock et j'ai toujours cru que c'etait ca. Je l'ai meme ecrit ici des dizaines de fois (et toutes ses variantes 13.34mhz, 3.33mhz) sans que personne corrige
Du coup 6.71mhz (6.7052) c'est plus logique (et donc les bons chiffres c'est 3.35mhz et 13.41mhz)

[Invité]

Quand je vois par exemple Rare utiliser 64x plus de data que nécessaire pour le fond du background du level 4 de Battletoad sur NES juste pour un trick d'effet de parallaxe multidirectionnel alors le x2 ca me choque pas.
Tu fais pas tout ton jeu comme ca mais ca peut permettre de différencier un level en faisant un effet visuel different des autres donc c'est toujours bon a connaitre mais +40% c'est sans doute trop peu pour que ca soit intéressant juste pour un FX ponctuel.

Oui mais faut prendre en compte la quantité, 64x pour quelques tiles c'est pas énorme surtout en 2BPP, par contre 2x sur une simple planche d'un sprite (ou le trick STx serrait utile) 32x32 en 4bpp c'est plus la même chose .

[Stef]

En fait quand tu utilises le port "serial" en stream sur des petits paquets de 4 octets c'est comme si tu utilisais les 2 port a fond car pendant que le port serial stream sur le registre, la VRAM piloté par le VDP a juste le temps de faire un nouvel acces random a la DRAM pour préparer la prochaine charge du registre du port serial donc tous les acces random a la DRAM normalement utilisé par l'autre port sont deja utilisés ici par le port serial de toute facon. Y a plus de place pour lui, le port "random" ne peut pas etre utilisé dans ce contexte donc c'est normal.

Oui je comprends, en quelque sorte tu lances le prochain accès random pour remplir le tampon stream, donc au final tu es déjà à fond des capacités.

Oui c'est ca du point de vue du bus de donnée et si on se place du point de vue de la DRAM c'est comme du 8bit a 3.33mhz en ecriture et du 32bit a 3.33mhz en lecture (plutot que du 8bit a 13.34mhz). La DRAM n'est jamais trop stressé et c'est ca aussi l'avantage de cette solution qu'il faut souligner.
L'equilibre entre ecriture et lecture est parfaite pour les besoins. Et la granularité forcé a 4 octets (contre 2 sur PCE et SNES) colle aussi parfaitement aux besoins de cette génération, pas besoin d'une granularité plus fine (par contre 8 octets ca aurait ete compliqué, ca aurait ete bon seulement si t'es obligé d'utiliser des tiles et sprites de 16 pxiels ou pour du 8bpp)

Oui et c'est plutot pas mal comme solution, pour l'époque ça a permis d'avoir une grosse bande passante en lecture (2 plans en 4bpp + 1 plan de sprite) et une souplesse énorme dans la mapping des différents élements (tilemap / pattern / OAM..). Par comparaison sur SNES il me semble que la VRAM tourne à 5.36 Mhz avec 2 bus 8 bits (un par chip) ce qui explique l'arrangement mémoire "contraint" et aussi le mode bitplan. Avec une telle fréquence, le PPU peut faire 340 accés mémoire par scanline, x2 car 2 bus donc 680 bytes / scanline max là où la MD en autorise quasiment 800.
Après la SNES fetches les mapping de sprites dans une RAM dédiée ce qui lui permet d'alléger la charge sur la VRAM, mais ce qui explique là encore les contraintes sur le mapping sprite (plus que la retro compatibilité il s'agissait d'économiser la taille de la mémoire utilisée). Ah décidément, les ingénieurs de chez Sega qui ont désigné le processeur vidéo ont fait du bien meilleur boulot que ceux de Nintendo :p

[Invité]

Le VDC de la nec fonctionne aussi comme ça, la SAT est dans une mémoire interne au VDC, ce qui lui permet de parser les 64 sprites pendant le hblank (la moitié est nécessaire en fait) .
Cependant comme elle est fixe (512 octets) l'augmentation de fréquence n'augmente pas le nombre de sprites dispo du coup .

[Stef]

Le VDC de la nec fonctionne aussi comme ça, la SAT est dans une mémoire interne au VDC, ce qui lui permet de parser les 64 sprites pendant le hblank (la moitié est nécessaire en fait) .
Cependant comme elle est fixe (512 octets) l'augmentation de fréquence n'augmente pas le nombre de sprites dispo du coup .

En fait je pense que pas mal de machine type console fonctionne ainsi, c'est plus pratique à de nombreux niveaux.
Sur MD en réalité tu as aussi un OAM interne au VDP, mais il s'agit d'un cache de l'OAM en VRAM. Le cache est mis à jour quand tu écris l'OAM en VRAM (l'écriture est alors dupliquée en interne). L'air de rien c'est, je trouve, une solution assez complexe à mettre en oeuvre : à chaque écriture en VRAM (même pendant un DMA) le VDP détecte si l'écriture se fait dans l'OAM (dont l'adresse est configurable) et si c'est le cas, selon les champs écris, l'écriture sera dupliquée dans un cache interne au VDP. En plus ce cache doit avoir une taille assez conséquente car tu dois au moins cacher la position Y, la taille et le sprite link (liste chainée), soit 4 octets par sprite en optimisant la mémoire, hors la sprite list comporte 128 entrées (possible via le sprite link) soit 512 octets bouffés uniquement par le cache de sprite (quasiment la taille de l'OAM complète sur SNES) ! C'est énorme quand tu penses que ces 512 octets sont directement pris sur le die du VDP, ça représente plus que la taille de la CRAM par exemple...

[Invité]

C'est clair, mais bon d'un côté ça permet aussi de bcp accélérer les accès qui n'utilisent pas le bus de la vram .

[upsilandre]

Oui je comprends, en quelque sorte tu lances le prochain accès random pour remplir le tampon stream, donc au final tu es déjà à fond des capacités.

Ouai c'est ca.
L'aire de rien la VRAM est capable de charger 256 octets (128x2) dans le buffer en un seul acces DRAM (elle deplace une row complete de DRAM simultanément) donc si tu faisais du pure streaming le port serial n'aurait besoin d'acceder a la DRAM qu' a une frequence de 0.052mhz et donc dans ce ca la ton port random serait completement dispo. Mais la sur des slots de 4 octets il a besoin d'acceder a la DRAM a 3.35mhz, il prend tous les cycles de DRAM et du controleur mais c'est un peu le bute dans ce contexte.

Oui et c'est plutot pas mal comme solution, pour l'époque ça a permis d'avoir une grosse bande passante en lecture (2 plans en 4bpp + 1 plan de sprite) et une souplesse énorme dans la mapping des différents élements (tilemap / pattern / OAM..). Par comparaison sur SNES il me semble que la VRAM tourne à 5.36 Mhz avec 2 bus 8 bits (un par chip) ce qui explique l'arrangement mémoire "contraint" et aussi le mode bitplan. Avec une telle fréquence, le PPU peut faire 340 accés mémoire par scanline, x2 car 2 bus donc 680 bytes / scanline max là où la MD en autorise quasiment 800.

Oui ca lui a permit en tout cas de supporter un dot clock superieur tout en ayant une DRAM moins véloce.
A dot clock equivalent c'est la meme bande passante théorique pour les 3 consoles (modulo le refresh que n'a pas la PCE) sauf que dans ce cas la DRAM de la MD fait la meme chose avec une frequence 2x plus faible (2.18mhz), un bus de donnée 2x plus faible (8bit), un bus d'adresse 2x plus faible (8bit). Mais un controleur dans le VDP qui doit etre rapide et des chips plus complexes.
Et chacune exploite cette meme bande passante (en 5.37mhz) différemment. La PCE avec son unique background libère de la bande passante pour un partage total de sa VRAM avec le CPU tandis que la SNES en faisant l'économie des attributs de sprites et en occupant tous les slots VRAM ce permet de faire entrer au chausse pied un 3eme plan 2bpp.

[upsilandre]

Le VDC de la nec fonctionne aussi comme ça, la SAT est dans une mémoire interne au VDC, ce qui lui permet de parser les 64 sprites pendant le hblank (la moitié est nécessaire en fait) .
Cependant comme elle est fixe (512 octets) l'augmentation de fréquence n'augmente pas le nombre de sprites dispo du coup .

C'est pas plutot comme la MD justement? (a moins que ce soit le sens de ta phrase?)
La SAT sur PCE se trouve bien en VRAM? et ensuite c'est le VDC qui tout seul va s'alimenter dedans et probablement bufferiser en interne au moins les attributs sensibles comme sur MD?

Sinon un exemple de console qui a sa SAT vraiment interne au GPU comme la SNES c'est la NES (et avec une customisation du CPU pour intégrer une fonction DMA dédié uniquement a la SAT ce qui du coup permet a la NES de transférer la SAT RAM > PPU bien plus vite que la SMS RAM > VRAM)

[Invité]

Oui ca lui a permit en tout cas de supporter un dot clock superieur tout en ayant une DRAM moins véloce.
A dot clock equivalent c'est la meme bande passante théorique pour les 3 consoles (modulo le refresh que n'a pas la PCE) sauf que dans ce cas la DRAM de la MD fait la meme chose avec une frequence 2x plus faible (2.18mhz), un bus de donnée 2x plus faible (8bit), un bus d'adresse 2x plus faible (8bit). Mais un controleur dans le VDP qui doit etre rapide et des chips plus complexes.

Euh non, du moins pas dans le cas de la PCE, car n'oublies pas qu'on compare 2 choses différentes à savoir 167 octets / seconde en copie ram/rom -> VRAM pour la Md et 170 octets/seconde en copie VRAM->VRAM pour le même dot clock (H32), c'est pas du tout pareil .
du côté MD on est à 2 cycles par lecture/écriture pour chaque octets et du côté PCE on est à 1 .

C'est pas plutot comme la MD justement? (a moins que ce soit le sens de ta phrase?)
La SAT sur PCE se trouve bien en VRAM? et ensuite c'est le VDC qui tout seul va s'alimenter dedans et probablement bufferiser en interne au moins les attributs sensibles comme sur MD?

Oui, mais la Md c'est une partie seulement de la SAT, la PCE c'est la SAT complète .
Elle est copiée de la VRAM (qui est un buffer) à chaque vblank via un canal DMA dédié automatiquement dés que l'interruption VBLANK claque .

[upsilandre]

Oui ca lui a permit en tout cas de supporter un dot clock superieur tout en ayant une DRAM moins véloce.
A dot clock equivalent c'est la meme bande passante théorique pour les 3 consoles (modulo le refresh que n'a pas la PCE) sauf que dans ce cas la DRAM de la MD fait la meme chose avec une frequence 2x plus faible (2.18mhz), un bus de donnée 2x plus faible (8bit), un bus d'adresse 2x plus faible (8bit). Mais un controleur dans le VDP qui doit etre rapide et des chips plus complexes.

Euh non, du moins pas dans le cas de la PCE, car n'oublies pas qu'on compare 2 choses différentes à savoir 167 octets / seconde en copie ram/rom -> VRAM pour la Md et 170 octets/seconde en copie VRAM->VRAM pour le même dot clock (H32), c'est pas du tout pareil .
du côté MD on est à 2 cycles par lecture/écriture pour chaque octets et du côté PCE on est à 1 .

Je sais pas a quelle passage exactement tu repondais, je parlais pas de DMA je parlais de la relation VRAM > GPU. sur PCE c'est un bus de donnée 16bit entre la VRAM et le VDC comme sur SNES (8bit sur MD), 16bit d'adressage comme sur SNES (8bit sur MD), une mémoire solicité a la frequence du dot clock (dot clock/2 sur MD) mais la meme bande passante VRAM théorique que sur MD/SNES a dot clock equivalent (avec 20 octets de plus par scanline car pas de refresh)

Oui, mais la Md c'est une partie seulement de la SAT, la PCE c'est la SAT complète .
Elle est copiée de la VRAM (qui est un buffer) à chaque vblank via un canal DMA dédié automatiquement dés que l'interruption VBLANK claque .

Du coup c'est quoi l'interet d'etre obligé de charger la SAT en VRAM plutot que directement dans le VDC comme sur NES et SNES a part bouffer de la VRAM? J'imagine peut etre dans le bute de pouvoir loader la SAT n'importe quand sans attendre le Vblank et réserver le Vblank au reste.
en tout cas la PCE avait suffisamment de bande passante pour faire comme sur MD et reduire le buffer interne pour la SAT mais en l'absence de véritable DMA j'imagine que la priorité est a l’allègement de la phase de Vblank, c'est logique.

[Invité]

Du coup c'est quoi l'interet d'etre obligé de charger la SAT en VRAM plutot que directement dans le VDC comme sur NES et SNES? J'imagine peut etre dans le bute de pouvoir loader la SAT n'importe quand sans attendre le Vblank et réserver le Vblank pour des choses plus importante.

Parce que tu peux pas   
Bon en fait c'est aussi pour que tu puisses modifier la sat en vram pendant l'affichage sans soucis de corrompre tes sprites .