Re: MEGADRIVE vs SUPER NINTENDO : Fight !

[Nextome]

C'est pour faciliter le portage depuis la PCE?

Je pense oui .

Il me semblait que Devil Crush avait été entièrement repensé pour la version MD... et non un simple portage PCE/MD

[Sentenza]

De manière général, la Megadrive à été pensé en grande partie pour accueillir des adaptations notamment du monde arcade.

La médiocrité de beaucoup de jeux (graphismes, animations, univers sonores, etc...) n'est due qu'à la médiocrité des programmeurs et non pas du potentiel de la machine et de ses lacunes qui étaient pourtant facilement contournable en partie.

Une Megadrive, ça se programme dans tout les sens, et c'est flexible comme pas possible pour une machine de l'époque; tu peu facilement vérifier ce que je dis en relisant les propos de programmeurs de l'époque comme Eric Chahi mais aussi à des personne comme Stef ou GASEGA64k qui programme aujourd'hui ou on programmer récemment sur cette machine.

Si tu as un peu de chance tu peu même discuté avec Fonzie, qui est le principal programmeur de Pier Solar et maintenant du Projet Y. La Megadrive est très facile à programmer pour tout ce qui est "basique" mais avec du talent et en poussant ses capacités elle en devient même extraordinaire.

Malheureusement, aujourd'hui bien que la console soit plutôt accessible pour tout ce qui concerne la "routine" elle demande des talents particulier en matière de programmation lorsqu'il s'agit d'exploité à fond ses capacité. Les pixels artiste, et les musiciens de nos jour, ne savent plus programmer ni se servir de la technologie Megadrive. Les progrès ont été tellement vite que tout les talents moderne ne sont pas du tout habituer, et n'ont pas été former pour exploiter ce genre de système obsolète.

Il à fallu d'ailleurs attendre 2005 si je ne me trompe pas, pour que SEGA rende enfin public toutes les spécificité de la Megadrive et ses outils de programmation complètement obsolète. C'est pour ça que le peu de gens qui en sont capable comme Stef, sont sans cesse en train d'en créer de nouveau, et de plus moderne afin de facilité la programmation et de les rendre compatible avec les ordinateurs moderne.

Par exemple pour le Porjet Y et même avant, Fonzie à recréer de A à Z des outils de programmation. Visiblement il ne sont pas publique et ne sont donc pas distribuer librement.

[Invité]

Une Megadrive, ça se programme dans tout les sens, et c'est flexible comme pas possible pour une machine de l'époque; tu peu facilement vérifier ce que je dis en relisant les propos de programmeurs de l'époque comme Eric Chahi mais aussi à des personne comme Stef ou GASEGA64k qui programme aujourd'hui ou on programmer récemment sur cette machine.

C'est bizarre tu cites que des codeurs Md, sauf eric ,mais qui était un codeur 68k ..
C'est sur ils sont vachement impartiaux comme mecs   
Pourquoi tu vas pas sur snesdev et demander ce qu'ils pensent de la snes ??

La médiocrité de beaucoup de jeux (graphismes, animations, univers sonores, etc...) n'est due qu'à la médiocrité des programmeurs et non pas du potentiel de la machine et de ses lacunes qui étaient pourtant facilement contournable en partie.

Critère exactement identique aux autres machines .

[Invité]

La médiocrité de beaucoup de jeux (graphismes, animations, univers sonores, etc...) n'est due qu'à la médiocrité des programmeurs et non pas du potentiel de la machine et de ses lacunes qui étaient pourtant facilement contournable en partie.

C'est bien d'avoir du potentiel, très bien même.

Mais de temps en temps, ça ne suffit pas, et on juge sur ce qui en est mal fait.

[Invité]

Il me semblait que Devil Crush avait été entièrement repensé pour la version MD... et non un simple portage PCE/MD

Si le jeu est bien en 256 et non en 320, je pense pas qu'il soit repensé pour la MD .

[Nextome]

Il me semblait que Devil Crush avait été entièrement repensé pour la version MD... et non un simple portage PCE/MD

Si le jeu est bien en 256 et non en 320, je pense pas qu'il soit repensé pour la MD .

Ok... C'est pour cette raison que la version Megadrive semble allongée (ou étirée) avec une bannière supplémentaire sur la droite ???

[Invité]

Après nous avoir bassinés avec la résolution MD, si c'est pour faire ça... et puis à droite les couleurs... enfin bon. Comme d'hab hein.

[Invité]

Ok... C'est pour cette raison que la version Megadrive semble allongée (ou étirée) avec une bannière supplémentaire sur la droite ???

Exactement, en fait le jeu est en 320, mais garde une surface de jeu en 256(d'où le hud sur la droite), surement pour reprendre les grafs de la version PCE facilement .

[upsilandre]

J'avais envie de faire un petit résumé sur les transfères ROM/RAM > VRAM qui sont stratégique pour savoir si j'ai raté un truc...

- La MD et la SNES ont bien chacune une fonction DMA pour ce type de transfère (et dans les 2 cas pendant un transfère DMA le CPU est inutilisable)
- Dans sa résolution standard la MD a une frequence DMA bien superieur a la SNES (6.67mhz vs 2.68mhz) et aussi un bus 16bit vs 8bit du coup ca fait un avantage x5 pour la MD.
- Sauf que le DMA de la MD est bridé par le bus 8bit de la VRAM et la SNES a 2 bus d'adressage qui lui permet de lire et ecrire en meme temps lors des acces DMA ce qui permet a la SNES de remonter x4. Du coup ca s'equilibre mais la MD garde quand meme l'avantage +25% (de l'ordre de 205 octet/scanline vs 165)
- Mais la MD peut aussi transférer hors du Vblank ce qui n'est pas le cas de la SNES mais a debit faible (dans quelle proportion? 10x moins? ca passe quand meme par le DMA?) donc probablement peu utiliser j'imagine a moins d'etre large niveau ressource CPU.
- Et pour les transfères vers les tables internes (Palette, Vscroll) le débit de la MD est encore 2x plus élevé car pas bridé par le bus VRAM (mais l'interet est limité c'est tres peu de data, d'ailleurs je me demande pourquoi les jeux MD ne joue pas plus de facon dynamique avec les palettes qui sont justement limité, en général je vois jamais les palettes bouger pendant un level, trop compliqué du point de vue graphiste de trouver des solutions dynamiques? y a des exemples de jeu qui en abuse?)

Ensuite un peu a part y a la PCE
- Pas de DMA du coté CPU mais une customisation bienvenu du 6502 pour ajouter quelques instructions plus moderne de copie de bloc type Z80 et sur un bus 8bit.
- Du coup en l'absence de vrai DMA et de CPU/bus 16bit le débit est plus faible (de l'ordre de 66 octet/scanline) mais ce debit faible couplé a une VRAM 16bit a haut debit autorise le CPU a accéder a la VRAM tout le temps a plein debit meme or des Vblank, on a une VRAM vraiment partagé ce qui est pratique. Du coup on peut faire aussi bien que sur les 16bit si on accepte d'y consacrer environ 3x plus de temps CPU.
- Par contre la PCE a un DMA du coté GPU qui permet de déplacer rapidement des bloc d'un coin de la VRAM a un autre. Intéressant meme si l'utilité est a priori sensiblement plus limité (C'est utilisé principalement pour quoi? Pour simplifier les animations de tile en réduisant l'emprunte sur les transfères ROM > VRAM? a condition donc de perdre de l'espace en VRAM)


C'est a peu pret ca?

[Invité]

 Mais la MD peut aussi transférer hors du Vblank ce qui n'est pas le cas de la SNES mais a debit faible (dans quelle proportion? 10x moins? ca passe quand meme par le DMA?) donc probablement peu utiliser j'imagine a moins d'etre large niveau ressource CPU.

Très peu, et il me semble que c'est contraignant et donc jamais utilisé,je crois que tu peux que transférer 16 octets/ligne .

 d'ailleurs je me demande pourquoi les jeux MD ne joue pas plus de facon dynamique avec les palettes qui sont justement limité, en général je vois jamais les palettes bouger pendant un level, trop compliqué du point de vue graphiste de trouver des solutions dynamiques? y a des exemples de jeu qui en abuse?)

Le jeux le font bcp, mais le changement est limité car il faut le faire pendant le hblank, ce qui est difficile à faire et donc limite le nombre de couleurs changeables dans un jeu sinon tu as des artefacts si tu changes quand l'affichage est actif .
Tu peux agrandir le hblank pour changer plus de couleurs en désactivant l'affichage, mais tu perds des sprites au passage.
La snes via le HDMA est mieux lotie pour ce genre d'effet,la PCE fait pas mieux que la MD avec les mêmes effets de bord,mais elle à un avantage si on accèpte de pas jouer en plein écran de pouvoir modifier bcp de couleurs sans perdre de sprites .

Par contre la PCE a un DMA du coté GPU qui permet de déplacer rapidement des bloc d'un coin de la VRAM a un autre. Intéressant meme si l'utilité est a priori sensiblement plus limité (C'est utilisé principalement pour quoi? Pour simplifier les animations de tile en réduisant l'emprunte sur les transfères ROM > VRAM? a condition donc de perdre de l'espace en VRAM)

Oui tu peux faire des animations de tiles, effacement d'écrans ou partie d'écran .
C'est encore plus utile sur SGX avec ses 2x 64ko et ses 2 DMA qui sont très rapides .
170 octets / s en h32 et 340 en h64, et sur chaque VDC .
Bien sur un vrai DMA rom/ram -> VRAM aurait été bien mieux, et surtout bcp plus rapide que via le CPU qui est incapable d'utiliser toute la BP disponible .

[upsilandre]

 d'ailleurs je me demande pourquoi les jeux MD ne joue pas plus de facon dynamique avec les palettes qui sont justement limité, en général je vois jamais les palettes bouger pendant un level, trop compliqué du point de vue graphiste de trouver des solutions dynamiques? y a des exemples de jeu qui en abuse?)

Le jeux le font bcp, mais le changement est limité car il faut le faire pendant le hblank, ce qui est difficile à faire et donc limite le nombre de couleurs changeables dans un jeu sinon tu as des artefacts si tu changes quand l'affichage est actif .
Tu peux agrandir le hblank pour changer plus de couleurs en désactivant l'affichage, mais tu perds des sprites au passage.
La snes via le HDMA est mieux lotie pour ce genre d'effet,la PCE fait pas mieux que la MD avec les mêmes effets de bord,mais elle à un avantage si on accèpte de pas jouer en plein écran de pouvoir modifier bcp de couleurs sans perdre de sprites .

Je pensais pas jusque la, je pensais pas a augmenter le nombre de couleur affichable a l'ecran mais juste utiliser plus de palettes differentes au fil de ton level.  Selon le type d'ennemi et le type de décore, modifier les palettes au cas par cas, avoir des triggers un peu partout dans le level qui déclenche une routine qui recharge l'intégralité des palettes pendant le Vblank (meme si t'as changé que 3 ou 4 couleurs de toute facon sur MD c'est gratuit justement, recharger toutes les palettes ca doit prendre un tiers de scanline sur MD). J'ai l'impression que les jeux MD ne modifie quasiment jamais les palettes pendant un level mais faut dire qu'en général un level c'est un décore et des ennemis qui ne varie quasiment pas, c'est le changement de level qui crée la variation. Mais par exemple meme dans des jeux comme Ghouls'n ghost ou y a une evolution de décore et d'ennemis pendant le level j'ai pas le souvenir de voir de changement de palette (pire, j'ai meme l'impression que ca ne change pas d'un level a l'autre a part celle du décore)
Mais bon d'un autre coté je comprend que pour les graphistes ca ne soit pas forcement possible de mettre ce genre de chose a en place. Y a tellement d'elements qui sont récurent au fil d'un jeu (le personnage, ses armes et pouvoirs, les items, le hud, certain ennemis) que c'est difficile d'avoir une approche contextuel des palettes meme pour le reste c'est difficile de segmenter.

Oui tu peux faire des animations de tiles, effacement d'écrans ou partie d'écran .
C'est encore plus utile sur SGX avec ses 2x 64ko et ses 2 DMA qui sont très rapides .
170 octets / s en h32 et 340 en h64, et sur chaque VDC .
Bien sur un vrai DMA rom/ram -> VRAM aurait été bien mieux, et surtout bcp plus rapide que via le CPU qui est incapable d'utiliser toute la BP disponible .

Par contre on dit que le CPU a tout le temps acces a la VRAM a plein debit mais pourquoi on dit aussi qu'il existe des tricks qui permettent d'augmenter le debit de transfère vers la VRAM si le CPU est deja a plein debit en condition normal?

Et le DMA GPU c'est utilisable n'importe quand ou pendant le Vblank? (pendant le Vblank j'imagine)

[philip]

C'est normal de ne pas changer la ou les palettes pour le personnage joueur. Il y a au moins deux palettes pour les décors, qui elles changent bien sûr pour chaque stage. Modifier pendant un stage est possible, comme l'a expliqué Touko. Et rien n'interdit d'utiliser la palette joueur pour le décors, cela demande une réflexion en amont, un travail artistique sur la mise en couleurs de chaques éléments/tiles composant le décors...

[philip]

Apres tu as aussi des jeux en 320,mais qui ont une surface de jeu en 256 comme raiden, tu as un hud tout moche sur la droite .

Et comme le genialissime Devil's Crush MD.
C'est pour faciliter le portage depuis la PCE?
Quoi que sur ce type de jeu ca gene moins.

Il est possible de l'adapter à la bonne résolution, et avec de meilleurs graphismes, mais cela dépend du choix du programmeur, et du talents des artistes.

[Invité]

Par contre on dit que le CPU a tout le temps acces a la VRAM a plein debit mais pourquoi on dit aussi qu'il existe des tricks qui permettent d'augmenter le debit de transfère vers la VRAM si le CPU est deja a plein debit en condition normal?

Tu as 2 moyens de transférer en vram avec le 6280,via les instructions de transfert de blocs .
tia,tai,tii,tdd,tin .
Ou via 3 instructions d'accès direct aux registres du VDC
st0,st1 et st2

les instructions de transfert de blocs prennent 6 cycles / octets les STx 4 cycles, mais ne transfèrent qu'un octet en immédiat par instruction .
Tu peux intercaler les instructions STx dans tes données graphiques entre chaque octets et exécuter directement le code .
Cela va charger chaque octets en vram automatiquement en 4 cycles, mais va doubler la taille des données .

Exemple ton fichier graphique contient les données en hexa 3E,10,7B,FD ,etc ...
Ca va donner :
st1, 3E , st2, 10 , st1, 7B,st2 , FD (bien sur les STx seront remplacé par leurs opcodes hexa)
On parle de full speed, car le CPU a tout les slots dispos pour éviter des wait states et transférer au max de ses possibilités qui sont inférieures à celles réellement disponibles sur le VDC .

Pour les palettes ,comme le dit philipp c'est assez courant de les changer en plein jeu, toutes les machines le font, mais c'est vrai qu'avec 4 palettes c'est plus difficile de composer .

Avoir plus de palettes te permet aussi de réduire les datas graphiques, exemple sur dragon ninja, les ninjas bleus ,verts,et rouges utilisent la même planche, mais juste des palettes différentes,pas de soucis si il apparaissent pas en même temps, mais comme dans le jeu ils apparaissent en même temps si tu n'as pas assez de palettes tu es obligé de multiplier la planche et les patterns en vram, ou alors sacrifier des couleurs dans tes autres palettes .

Et le DMA GPU c'est utilisable n'importe quand ou pendant le Vblank? (pendant le Vblank j'imagine)

Oui seulement pendant le vblank, et génère une interruption en fin de transfert, utile pour maximiser les transferts .

[Stef]

Le DMA GPU (enfin interne de VRAM --> VRAM) existe aussi sur MD mais c'est très peu utilisé (10 jeux max y ont recours). Ca a quand même l'avantage d'etre gratuit car interne au VDP et ça fonctionne aussi pendant la période active. Même si c'est beaucoup plus lent que pendant le VBlank c'est interessant car tu peux dédier le VBlank aux transfert type ROM/RAM --> VRAM et la période active à un DMA type VRAM fill ou VRAM copy qui sera pour le coup complètement "gratuit"...  pour de l'animation de tile ça peut être pratique quand même.

[upsilandre]

Tu as 2 moyens de transférer en vram avec le 6280,via les instructions de transfert de blocs .
tia,tai,tii,tdd,tin .
Ou via 3 instructions d'accès direct aux registres du VDC
st0,st1 et st2

les instructions de transfert de blocs prennent 6 cycles / octets les STx 4 cycles, mais ne transfèrent qu'un octet en immédiat par instruction .
Tu peux intercaler les instructions STx dans tes données graphiques entre chaque octets et exécuter directement le code .
Cela va charger chaque octets en vram automatiquement en 4 cycles, mais va doubler la taille des données .

Exemple ton fichier graphique contient les données en hexa 3E,10,7B,FD ,etc ...
Ca va donner :
st1, 3E , st2, 10 , st1, 7B,st2 , FD (bien sur les STx seront remplacé par leurs opcodes hexa)
On parle de full speed, car le CPU a tout les slots dispos pour éviter des wait states et transférer au max de ses possibilités qui sont inférieures à celles réellement disponibles sur le VDC .

La je comprend mieux.
Quand j'avais regardé le jeu d'instruction du CPU custom j'avais vu ces instructions ST dédié au GPU, j'avais trouvé ca classe. Mais effectivement je viens de me rendre compte que y a pas different mode d'adressage, c'est juste du mode immédiat avec la valeur direct du coup je comprend ce que tu veux dire. Tu peux pas faire une boucle a base de ST1/2 et alimenter cette boucle avec une table de data, t'es obligé de faire une table de data qui intègre les opcodes et au final tu te contente pas de lire la table, tu l’exécutes. Mais du coup effectivement comme faut intégré les opcodes ca fait une table qui prend 2 fois plus de place (en ROM voir en RAM parce que au depart je pensais que tu voulais dire en VRAM) puisqu'il y a un opcode par data.
Pas mal comme gruge, peut etre plutot pour les jeux CD-ROM du coup.

[Invité]

Tu peux pas faire une boucle a base de ST1/2 et alimenter cette boucle avec une table de data, t'es obligé de faire une table de data qui intègre les opcodes et au final tu te contente pas de lire la table, tu l’exécutes.

Exactement, cependant faire du code auto modifié en RAM avec les instructions STx est très pratique et rapide, je l'utilise notamment pour me créer une liste de transfert DMA .
Bien sur le procédé a ses limites,tu peux pas non plus t'amuser à bouffer ta RAM/ROM avec ça,du moins pas dans un jeu,ou alors avec une grosse hucard, là oui ça deviendrait utile .

Mais du coup effectivement comme faut intégré les opcodes ca fait une table qui prend 2 fois plus de place (en ROM voir en RAM parce que au depart je pensais que tu voulais dire en VRAM) puisqu'il y a un opcode par data.
Pas mal comme gruge, peut etre plutot pour les jeux CD-ROM du coup.

Oui mais même sur scd c'est limité à cause de la taille .
Ca aurait été vraiment utile sur l'AC, mais comme tu peux pas exécuter du code directement sur l'AC ,c'est cuit   
Après pour un jeu SCDrom²+AC tu peux réserver le max des 256 ko de cdram à ça,et utiliser l'AC pour le reste.

[upsilandre]

Le DMA GPU (enfin interne de VRAM --> VRAM) existe aussi sur MD mais c'est très peu utilisé (10 jeux max y ont recours). Ca a quand même l'avantage d'etre gratuit car interne au VDP et ça fonctionne aussi pendant la période active. Même si c'est beaucoup plus lent que pendant le VBlank c'est interessant car tu peux dédier le VBlank aux transfert type ROM/RAM --> VRAM et la période active à un DMA type VRAM fill ou VRAM copy qui sera pour le coup complètement "gratuit"...  pour de l'animation de tile ça peut être pratique quand même.

Je savais pas. Mais effectivement ca parait encore moins intéressant que sur PCE car sur PCE l'intéret du DMA GPU c'est qu'il est bien plus rapide qu'un transfère ROM > VRAM alors qu'ici c'est a priori l'inverse. le DMA VRAM > VRAM sollicite doublement la VRAM donc j'imagine que ca doit tomber a une centaine d'octets/scanline sur MD donc aucun intérêt a utiliser ca pendant le Vblank (surtout si c'est pour bouffer en plus de l'espace VRAM), y a que pendant l'affichage que ca peut avoir un interet (limité)

Je me rend compte surtout que la VRAM PCE a une bande passente de folie! (et surtout sous exploité)
J'avais noté les differences physique dans le choix de VRAM des 3 consoles. La SNES avec une pure DRAM donc a frequence basse (2.68mhz) mais en 16bit pour compenser (et si j'ai bien compris avec des refresh qui bouffe quelques cycles). La MD qui choisie une mémoire hybride optimisé pour la video composé de DRAM couplé a des registres d'entrées qui servent de buffer pour absorber une fréquence plus elevé (6.67mhz) et ainsi faire l'economie d'un bus 16bit (et un refresh plus transparent géré en interne?). Et a coté de ca y a la PCE qui se paye le luxe d'utiliser de la SRAM comme VRAM pour se lacher sur les frequences et comme si ca suffisait pas avec en plus un bus 16bit.

Au depart je m'etais dit que la frequence de cette VRAM PCE devait etre juste la moitié du dot clock car ca donne deja une bande passante plus que suffisante mais en faite je me rend compte que non c'est bien la frequence du dot clock sinon t'obtiendrais pas les chiffres que Touko evoques pour le DMA GPU car pour pouvoir copier a 170 octets/scanline sur un DMA GPU qui sollicite la meme memoire en lecture et ecriture faut en réalité une bande passante effective de 340 octets/scanline et ca c'est juste pour le mode low frequence, ca monte donc jusqu'a 680 octets/scanline en H64 soit 4 fois la bande passante de la SNES (ou 4x celle de la MD en mode H32 alors meme que en mode H64 la PCE a pas besoin de plus de bande passente que la MD en mode H32 car un BG 512 = 2 BG 256 et niveau sprite et OAM c'est equivalent) tout en ayant la meme quantité de VRAM et 4 ans avant?.

Si c'est bien ca ca fait donc beaucoup de bande passante non exploité surtout dans les modes superieurs. On se dit du coup qu'un simple bus 8bit sur cette VRAM PCE aurait largement suffit pour absorber les besoins du GPU (comme le fait la MD pourtant avec 2 BG), y aurait meme encore pas mal de marge, mais j'ai l'impression (faudrait calculer) un poile pas assez je pense pour absorber les acces CPU en full debit pendant l'affichage en mode H32 (le mode standard) surtout si on utilise le trick (et le DMA GPU serait moins intéressant car c'est tres exigent ce type de DMA) donc ils auraient choisie un bus 16bit juste pour ca? pour que tout soit nickel dans le mode standard de la PCE? Et les dot clock superieurs sont je pense presque du bonus qu'ils ont du ajouter juste parce que la SRAM pouvait supporter ces fréquences quite a ce que ce soit du gâchis de bande passante.

[Invité]

La PCE a une VRAM à 93ns (bon 100 en vérité, mais tournant à 93 en H64,dot clock 10,74 mhz) .
Les accès sont à 1 octets/VDC cycle.
Je pense que le chipset de hudson était prévu pour tourner aussi bien avec un CPU 8bits que 16 bits, car le VDC peut être débraillé en full 16bits au lieu de 2x 8bits pour chaque registre.

[upsilandre]

La PCE a une VRAM à 93ns (bon 100 en vérité, mais tournant à 93 en H64,dot clock 10,74 mhz) .
Les accès sont à 1 octets/VDC cycle.

effectivement je me souviens avoir lu quelque part que en mode 10.74mhz on dépassait les limites de la VRAM ca pouvait poser un probleme dans certain cas (mais je me souviens plus a quelle sujet)
En plus je crois que j'ai dis une connerie sur les DMA GPU, ca sollicite 2x plus la VRAM (lecture + ecriture) mais de toute facon les DMA CPU ne la sollicite qu'un cycle sur 2 (a part sur SNES ou y a 2 bus d'adresse) donc le DMA GPU peut fonctionner a la meme cadence que le DMA CPU sur MD (Ce qui veut dire que le DMA GPU de la PCE n'utilise que la moitié des cycles? Ca evite de poser probleme en 10.74mhz?)

Je pense que le chipset de hudson était prévu pour tourner aussi bien avec un CPU 8bits que 16 bits, car le VDC peut être débraillé en full 16bits au lieu de 2x 8bits pour chaque registre.

Y a peut etre une histoire comme ca.

[upsilandre]

J'ai voulu faire un petit calcule et c'est a ce moment la que je me suis rendu compte que j'ai du dire des conneries.
Avec une memoire 16bit sollicité a 2.68mhz pour la SNES et 8bit 6.67mhz pour la MD ca passe pas du tout, il faut bien plus que ca pour loadé a chaque scanline les patterns des BG, sprite, les tilemap... les VRAM supportent forcement une frequence double du DMA.
Donc les frequences que j'ai cité pour la SNES et la MD serait juste les frequences DMA.

Donc pour la VRAM on aurait plutot:
MD 8bit sollicité a 13.34mhz (meme si en interne ca se passe differement sur un bus plus large a basse frequence)
SNES 16bit sollicité a 5.37mhz
Du coup vu comme ca les frequences a laquelle est sollicité la VRAM PCE sont plus credible et logique. Ca serait donc juste l'equivalent de la SNES (ou de la MD en H32) pour le mode standard mais avec moins de besoin il est alors facile de caser les acces CPU (et cette fois sans faire réellement de gachie) et le double de la SNES en mode 10.74mhz.

C'est plus cohérent, ca me convient mieux car y avait un truc pas tres logique dans cette histoire quand meme (ne serait ce que justifier le bus 16bit sur PCE) mais c'est vrai qu'on a tout le temps des informations sur le dot clock ou la frequence DMA mais pas vraiment celle a laquelle est sollicité la VRAM finalement d'ou la confusion.

[Invité]

Bah le dot clock détermine la fréquence de la VRAM ..
La VRAM de la snes tourne plus vite que son DMA,c'est aussi une 100ns il me semble .

[upsilandre]

Bah le dot clock détermine la fréquence de la VRAM ..

En tout cas quand y a un bus 16bit. Pour la MD faut balancer au double du dot clock.

[Invité]

Oui, le bus 8 bits divise les perfs par 2 .
C'est pour ça d'ailleurs qu'en H32 la snes fait quasi aussi bien que la Md niveau transferts DMA .

Ce qui est marrant aussi c'est que bcp de registres (tous ??) du VDP de la MD sont 8bits .

@stef: ya un truc que je comprend pas sur le VDP, comment tu peux afficher 80 sprites, si le link est sur 6 bits, donc 64 sprites ??

[upsilandre]

C'est pour ça d'ailleurs qu'en H32 la snes fait quasi aussi bien que la Md niveau transferts DMA .

Pourquoi "quasi"? en H32 c'est les meme frequences et débits, tu penses au refresh qui serait transparent sur MD?

@stef: ya un truc que je comprend pas sur le VDP, comment tu peux afficher 80 sprites, si le link est sur 6 bits, donc 64 sprites ??

C'est 7 bits le link, t'as du mal lire.


Par contre je comprend pas pourquoi sur MD ils ont rien fait pour supporter le full DMA vers la VRAM. Ok le bus est 8bit mais c'est une fausse excuse, il est au double du dot clock, c'est l'equivalent d'un bus 16bit a la frequence du dot clock.
Pendant l'affichage la VRAM supporte des debits 4 fois superieur au 205 Octets/scanline que propose le DMA, y avait de la marge.
Alors prendre juste un octet sur chaque mot que le DMA récupère a sans doute permis de simplifier la logique interne mais j'ai du mal a croire que c'etait si compliqué d'arriver a faire rentrer les 16bit sur le bus VRAM qui tourne de toute facon bien plus vite que ce que balance le DMA .
En théorie la limite du DMA c'est plutot la RAM et la ROM que la VRAM, si du coté ROM t'arrive a mouliner a 410 octets/scanline le plus dure est fait, c'est vraiment etrange de pas avoir ete capable d'exploiter ca jusqu'a la VRAM qui finalement se tourne les pouces pendant le DMA (seulement 25% de son debit exploité). Ca aurait ete un sacré atout.


Sinon j'ai vérifié et la copy VRAM > VRAM est finalement bien a seulement 102 octets/scanline comme j'avais dit la premiere fois donc interet tres limité. C'est le "fill" VRAM qui lui est bien a 205 octets/scanline.

[Invité]

C'est 7 bits le link, t'as du mal lire.

Oui tu as raison, j'ai oublié de compter le 0, tu as les bits 0->6 (donc bien 7 bits au total)  

Pourquoi "quasi"? en H32 c'est les meme frequences et débits, tu penses au refresh qui serait transparent sur MD? 

Parce qu'il me semblait que la Md était un peut plus rapide, mais rien de transcendant .

Par contre je comprend pas pourquoi sur MD ils ont rien fait pour supporter le full DMA vers la VRAM.

Pour des raisons de coûts, pareil pour relier les interruptions timer du 2612 au Z80, ça coûtait vraiment rien .
Mais même des cents à quelques dollars sur des millions de machines, ça fait bcp d'économies .
Et SEGA devait trouver les débits suffisants par rapport à ce qui se faisait sur la concurrence .
Pour passer en 16 bits ils devaient mettre de la VRAM en dual port, surement bien plus chère .

Sinon j'ai vérifié et la copy VRAM > VRAM est finalement bien a seulement 102 octets/scanline comme j'avais dit la premiere fois donc interet tres limité. C'est le "fill" VRAM qui lui est bien a 205 octets/scanline.

Oui c'est juste la copie VRAM->VRAM sur Md qui est très lente .
La copie RAM/ROM -> VRAM atteint les mêmes débits que la copie VRAM->VRAM de la PCE .

Si la PCE avait eu un VRAI DMA ROM/RAM->VRAM, même limité à 7,16 mhz, elle aurait atomisé la snes/MD .
Pareil pour la Md avec un VRAM dual port, mais bon là ça nécessitait des composants en plus .

[upsilandre]

Parce qu'il me semblait que la Md était un peut plus rapide, mais rien de transcendant .

Les frequences DMA sont calé sur le dot clock (50% dot clock sur SNES mais lecture et écriture dans le meme cycle, 100% dot clock sur MD mais lecture et ecriture sur des cycles alternatif), donc en H32 elles font exactement pareille a priori donc la difference c'est peut etre au niveau de refresh (ou alors peut etre si on parle en terme de data/Vblank les 2 Vblank n'ont peut etre pas le meme nombre de scanline dispo pour le DMA ce qui peut aussi faire varier a la marge)

Pour passer en 16 bits ils devaient mettre de la VRAM en dual port, surement bien plus chère .

Justement je parlais pas de passer sur un bus 16bit, juste mieux exploiter le bus 8bit qui est largement suffisant.
La frequence du DMA de la MD c'est donc le dot clock (6.67mhz) mais lecture/ecriture de facon alternative donc seulement la moitié des cycles utilisé pour la lecture et l'autre moitié pour l’écriture. Si y avait eu par exemple 2 registre 16bit qui bufferise en entré a la lecture y aurait eu moyen en sortie d'utiliser chaque cycle DMA pour ecrire dans la VRAM.
Lire les mots 16bit en ROM a 3.33Mhz comme actuellement mais ecrire les octets 8bit (un coup LSB, un coup MSB) en sortie vers la VRAM a 6.67mhz  qui n'est de toute facon que la moitié de la frequence du bus VRAM pendant l'affichage (13.34mhz) mais qui aurait deja suffit a absorber tout le flux DMA (410 octets/Scanline). La pendant le DMA on a une ecriture VRAM a 3.33mhz alors qu'elle tourne a 13.34mhz pendant l'affichage, la VRAM n'aurait jamais du etre le goulot d'étranglement du DMA.
C'est surement une question de cout pour bien cablé tout ca dans le DMA mais on a l'impression que ca passe a pas grand chose. Mais si c'etait vraiment a pas grand chose y a aurait sans doute d'autre truc moins utile a sacrifier, doit y avoir certainement un truc qui coince qui fait que ca compliquait vraiment les choses niveau design.

Si la PCE avait eu un VRAI DMA ROM/RAM->VRAM, même limité à 7,16 mhz, elle aurait atomisé la snes/MD

Pour revenir sur la PCE je faisais un petit calcul. T'avais evoqué 66 octets/scanline pour les copies de bloc vers la VRAM et que cette instruction c'etait 6 cycles par octets mais avec 6 cycles par octet ca donne plutot 76 octets/scanline.
Mais en regardant la doc ils ont l'aire de dire que l'instruction de copie de bloc est plus lente quand c'est vers le VDC, ils précisent pas mais si c'est 7 cycles au lieux de 6 ca donne effectivement 65 octets/scanline, ca colle mieux?
Donc si c'est 7 cycles par octets ca veut dire que le trick avec les ST1/2 et ses 4 cycles est vraiment intéressant. Ca fait presque 114 octets/scanline, ca commence a etre honnête.

[Stef]

Pour la VRAM sur MD, elle est déjà dual port en fait. Quand Sega a désigné sa MD le choix de la VRAM était vraiment crucial et ils ont choisi un type de mémoire qui était tout nouveau à l'époque (dual port dynamic ram). Sauf erreur il me semble qu'en fait tu as un port série 4 bits (très rapide) ainsi qu'un port parallèle 4 bits (plus lent mais adapté pour le random access) et toute la logique du VDP de la MD a été pensé pour maximiser l'utilisation de ces 2 bus. En regardant le schéma de connexion de la VRAM au VDP, j'ai l'impression qu'en doublant la quantité de VRAM (128 KB) tu doubles directement la largeur du BUS de celui-ci (4+4 bits à 8+8 bits) et donc tu multiplies par 2 les débits, le tout sans rien changer côté VDP (pas de pin supplémentaires) si ce n'est le clock. Le design du VDP a été fait de tel manière à pouvoir gérer 128 KB de mémoire mais je pense que Sega est resté sur 64 KB pour des raisons de cout.
Sinon pour répondre au pourquoi Sega a "volontairement" limité la vitesse du DMA vers la VRAM, je pense que c'est juste lié au fait que la ROM n'aurait de toute manière pas pu suivre (en tout cas au début) ! Quand tu utilises le DMA vers la CRAM / VSRAM tu passes à pleine vitesse mais du coup les premières ROM étaient incapable de tenir un tel débit et tu devais te cantonner à faire ce genre de transferts (heureusement beaucoup moins utile que vers la VRAM) depuis la RAM centrale de la MD, ça aurait été hyper handicapant d'avoir le même soucis pour un transfert vers la VRAM :-/

[upsilandre]

Pour la VRAM sur MD, elle est déjà dual port en fait. Quand Sega a désigné sa MD le choix de la VRAM était vraiment crucial et ils ont choisi un type de mémoire qui était tout nouveau à l'époque (dual port dynamic ram). Sauf erreur il me semble qu'en fait tu as un port série 4 bits (très rapide) ainsi qu'un port parallèle 4 bits (plus lent mais adapté pour le random access) et toute la logique du VDP de la MD a été pensé pour maximiser l'utilisation de ces 2 bus. En regardant le schéma de connexion de la VRAM au VDP, j'ai l'impression qu'en doublant la quantité de VRAM (128 KB) tu doubles directement la largeur du BUS de celui-ci (4+4 bits à 8+8 bits) et donc tu multiplies par 2 les débits, le tout sans rien changer côté VDP (pas de pin supplémentaires) si ce n'est le clock. Le design du VDP a été fait de tel manière à pouvoir gérer 128 KB de mémoire mais je pense que Sega est resté sur 64 KB pour des raisons de cout.

Je regardais aussi les schéma et je pense avoir enfin compris comment fonctionne la VRAM sur MD
Sur chacun des chip memoire y a pas un seul bus de donnée 4bit (x2) mais effectivement 2 port 4bit (et un bus d'adressage 8bit). Un port "random" 4bit (x2 car y a 2 chip) pour des acces aléatoire classique en lecture et ecriture.
Et un second port 4bit (x2) "serial" (mais faut l'entendre dans le sens "streaming", c'est un port pour lire une serie de donnée 4bit contigu) qui ne peut etre utilisé qu'en lecture. il passe par un buffer interne de 1024bit (un registre) qui est automatiquement chargé en interne dès que possible.

Par contre le bus d'adressage est seulement 8bit, il est multiplexé, faut donc 2 cycle pour l'adressage du coup sur le port "random" la frequence de lecture ou d'ecriture est divisé par 2. A l'inverse sur le port "serial" on utilise effectivement 2 cycles au depart (un pour selectionner la page de 1024bit qui va etre chargé dans le registre et un second pour placer un pointeur sur ce registre) mais ensuite y a plus besoin du bus d'adressage, on lit en streaming la page et les suivantes se charge automatiquement du coup la on peut lire a plein debit.

Maintenant quand on regarde comment c'est cablé sur la MD on voit que le port "random" n'est pas cablé au bus de donnée 8bit du VDC mais uniquement sur le bus d'adressage 8bit du VDC (qui lui meme est évidement aussi cablé sur le bus d'adressage 8bit du chip mémoire) et donc le bus d'adressage du VDC est apparemment utilisé ici pas seulement pour multiplexé l'adressage du chip memoire mais multiplexe aussi les data destinées au port random. Du coup faut 2 cycle pour l'adressage + un cycle pour ecrire sur le port random (et peut etre donc un 4eme cycle a vide).
Alors pourquoi ils ont pas cablé le port random sur le bus de donnée du VDC et eviter un multiplexage suplementaire? je sais pas si le port "random" est utilisé uniquement en ecriture ou aussi en lecture (toujours par le bus d'adressage du VDC) mais dans ce second cas ca voudrait dire que le VDC pourrait en lecture cumuler le debit des 2 ports (dans cas ca serait plus vraiment une VRAM 8bit mais 2x8bit).

A coté le port "serial" lui est bien directement connecté au bus de donné 8bit du VDC et par definition il ne peut etre utiliser qu'en lecture (et donc le bus de donnée du VDC du coté VRAM est utilisé uniquement en lecture) mais ce port peut vraiment etre lu a la frequence du bus dans le cas ideal (sauf au moment d'initialiser la page a streamer) donc environ 4x plus vite que pour l'ecriture dans ce contexte du cablage MD.

Et la du coup tout s'explique! y a plus aucun mystere. Si le DMA ne peut ecrire que 205o/s alors que pendant l'affichage le VDC s'alimente bien plus vite c'est pas une histoire de bus de donnée 8bit mais bien parce que l'ecriture est effectivement bien plus lente que la lecture (a cause du multiplexage) et ces 205o/s c'est simplement le max que permet ces chips memoires et ce cablage. Et pareille pour le VRAM > VRAM a 102o/s (qui correspond donc a un debit 102+102) qui est bridé par l'ecriture.

En fait c'est vraiment une configuration de buffer video avec des memoires dédié a cela (la ou sur les autres consoles c'est des mémoires standard) qui donc mise a fond sur la lecture et délaisse l'ecriture qui n'est pas determinant dans ce contexte (juste ce qu'il faut pour faire deja mieux que la concurrence en DMA, pas besoin de plus en ecriture).
Donc au final c'est plutot un choix bien equilibré et efficace car il sagit pas juste de reduire le bus de donnée a 8bit mais aussi le bus d'adressage qui est 8bit. Et puis au final y a donc pas de gachie au niveau du DMA, c'est juste la consequence du choix au niveau VRAM.
Je me sent un peu mieux car je comprenais pas la logique autour de ce DMA MD, la c'est plus claire (mais y aurait sans doute d'autre truc intéressant a creuser)

[Stef]

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) ? il me semblait que oui mais peut être me trompe-je ? En tout cas visiblement le VDP avait été modifié un peu à la dernière minute pour éventuellement supporter 128 KB de VRAM (à la place des 64 KB initiale et finalement maintenu).
Mais il faut admettre que le design du VDP de la MD (qui concentre probablement 80% de la recherche sur ce genre de système) a été remarquablement fait par rapport aux possibilités techniques de l'époque, la VRAM dual port est admirablement exploitée et d'ailleurs ça correspond vraiment à ce qu'on qualifiera comme VRAM plus tard. Dommage qu'ils aient merdé sur les palettes   Le designer a reconnu que le nombre de palette était assez limité mais que les effets highlight / shadow permettaient d'augmenter le nombre de couleurs affichés... mais bon dans la réalité c'est vraiment limité, et 4 palettes de plus ça aurait été simplement incomparable en terme de résultat.
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, perso j'arrive à peine à 800 bytes :
si on prend les 2 plans plus les sprites on a déjà (336*2) + 320 pixels soit 496 bytes à lire de données, ensuite tu as les tilemap (168 bytes = 42*2*2) + les 20 sprites réellement parsés par ligne (une partie des données de la liste complète des 128 sprites étant cachée en interne dans le VDP donc pas besoin d'accés VRAM) soit environ 20*4 bytes à fetcher en plus (80 bytes) et surement quelques bytes en plus pour les scrollings et le reste...
Donc à tout casser on arrive à 496 + 168 + 80 + ~40 = ~784 bytes par scanline à lire depuis la VRAM.
Il doit surement me manquer des choses... sur MD tu as les slots externes autorisés pendant la période active mais ça représente seulement 16 bytes donc ça change pas grand chose.

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