Re: overdrive 2

[TotOOntHeMooN]

Comme tout jeu de plus de 4 Mo non ?

Je réponds à une personne qui indique que ça ne fonctionne pas avec son Everdrive.
Probablement que c'est la seule raison, oui.

[Tryphon]

J'avais compris, mais ta définition de "cartouche MD standard" est floue. On pourrait croire que la cartouche embarquerait de l'électronique non-standard, là où un simple mapper suffit je suppose (mais pas sûr non plus, d'où ma question au cas où t'en saurais plus).

[Invité]

Ce travail !

C'est clair, le boulot effectué est énorme .

[Stef]

Ils ont mis un document en ligne pour expliquer les astuces utilisées et leurs découvertes :
https://docs.google.com/document/d/1ST9GbFfPnIjLT5loytFCm3pB0kWQ1Oe34DCBBV8saY8/pub

bonne lecture

[Invité]

je comprends pas tout mais le monsieur a l'air d'avoir une ou deux longueurs d'avance concernant la megadrive et ce qu'elle a dans ses tripes

[Invité]

Ils ont mis un document en ligne pour expliquer les astuces utilisées et leurs découvertes :
https://docs.google.com/document/d/1ST9GbFfPnIjLT5loytFCm3pB0kWQ1Oe34DCBBV8saY8/pub

bonne lecture

Déjà posté en page précédente .

je comprends pas tout mais le monsieur a l'air d'avoir une ou deux longueurs d'avance concernant la megadrive et ce qu'elle a dans ses tripes

Ils utilisent surtout bcp de tricks délicats qui rendent les choses compliquées pour tourner sur toutes les MD .

[Invité]

Je suis toujours bluffé par ces personnes soucieuses de tirer aux maximum les possibilités des machines.
C'est impressionnant et j'imagine la chasse aux méchants cycles.
La MD à le vent en poupe décidément !!

[Invité]

Je suis toujours bluffé par ces personnes soucieuses de tirer aux maximum les possibilités des machines.
C'est impressionnant et j'imagine la chasse aux méchants cycles.
La MD à le vent en poupe décidément !!

Le truc c'est que tu as un énorme boulot à l'oscilloscope derrière pour faire ce genre de prouesses .
C'est le niveau N+1 du demomaker .

[TotOOntHeMooN]

J'avais compris, mais ta définition de "cartouche MD standard" est floue. On pourrait croire que la cartouche embarquerait de l'électronique non-standard, là où un simple mapper suffit je suppose (mais pas sûr non plus, d'où ma question au cas où t'en saurais plus).

Tout à fait, c'est le cas. Elle embarque de l'électronique pour gérer 128Meg (16Mo) de ROM et de l'audio PCM (WAV, ...), là où une cartouche standard est limité à 32Meg (4Mo) par le bus d'adresse du port cartouche (A1 à A23). Il y a donc un bank switch pour aller au dela de la capacité prévu sur Megadrive.

[Stef]

Ils ont mis un document en ligne pour expliquer les astuces utilisées et leurs découvertes :
https://docs.google.com/document/d/1ST9GbFfPnIjLT5loytFCm3pB0kWQ1Oe34DCBBV8saY8/pub

bonne lecture

Déjà posté en page précédente .

Oups j'ai été trop lent... J'ai commencé à lire, pour moi le plus intéressant et d'assez loin c'est le fait que le mode VDP 128 KB permet d'effectivement doubler la vitesse du DMA comme on l'a souvent supposé. C'est dingue que Sega ai finalement choisi de castrer cette partie avec 64 KB de VRAM. Si au moins ils l'avaient cablé de telle manière à conserver le DMA 16 bits, 2x fois de bande passante, c'est énorme ! Du coup là en activant le mode 128 KB tu peux activer une lecture 16 bits même si seuls 8 bits seront écrit en VRAM, mais ça permet quand même de moduler le step de DMA d'une nouvelle manière, ce qui peut être utile pour transférer un buffer bitmap (faut que j'y réflechisse) via le DMA

[TotOOntHeMooN]

Il y avait déjà eu une discution à ce sujet il y a 7/8 ans de cela sur SpriteMind avec Tiido si je m'abuse... Mais tu es limité à l'usage lors du VBLANK. De plus, à quoi bon aller 2x plus vite pour ne garder qu'une donnée sur deux. Dans leur cas, ils en ont peut-être tiré un avantage pour certains effets de démo... Mais comme souvant, la majorité des astuces ne sont pas utilisables dans un jeu.

[Orion_]

je pige pas trop, si c'est 2x plus rapide mais que tu transfer que 8bits sur 16, ça reste à la même vitesse au final non ?
tu peu pas utiliser cette technique pour booster un transfer DMA classique à priori

[Invité]

Je capte absolument rienG à tout votre charabia ... Si ce n'est qu'il faut passer par "là", pour réaliser une démo pareille.
Et quand tu parles d'oscilloscope, c'est à dire ?! Les mecs vont mesurer les signaux analogiques sur telles pattes de tels CI/Micro pour ?? 
Euh bon bref .. Tout ça me dépasse ! 

Chacun fait c'qu'il lui plait après tout !

[Stef]

Il y avait déjà eu une discution à ce sujet il y a 7/8 ans de cela sur SpriteMind avec Tiido si je m'abuse... Mais tu es limité à l'usage lors du VBLANK. De plus, à quoi bon aller 2x plus vite pour ne garder qu'une donnée sur deux. Dans leur cas, ils en ont peut-être tiré un avantage pour certains effets de démo... Mais comme souvant, la majorité des astuces ne sont pas utilisables dans un jeu.

Effectivement comme tu as que 64 KB de VRAM (sauf si tu as la chance d'être le possesseur d'un TeraDrive :p) le byte de poids fort n'est pas écrit. A la base le DMA --> VRAM (qui peut être vu comme un slow DMA) même s'il écrit en VRAM 8 bits par 8 bits ne t'offre qu'une granularité de 16 bits sur la lecture/écriture de la donnée en VRAM. Je pense qu'ils ont fait ça pour rester cohérent avec les autres modes DMA (CRAM, VSRAM et donc VRAM 128K) et surtout pour l'écriture dans la tilemap ou la table de sprite.. Mais l'air de rien parfois c'est assez chiant cette granularité de 16 bits car même si tu peux régler le step d'incrément de l'adresse d'écriture tu es quand même bloqué à 16 bits écrits et ensuite tu as l'incrément. Là grâce à ce DMA 128K, tu réduis la granularité d'écriture à 8 bits (le byte haut étant ignoré) et ça ouvre carrément à de nouvelles possibilités de trick (pour faire du bitmap en autre en arrangeant les tilemaps comme il faut) :)
Donc non on ne gagne pas en bande passante (la moitié est perdu) mais ça ajoute des possibilités sur la conversion des buffers par exemple et/ou l'utilisation intelligente des tilemaps :) Et donc là si en plus c'est carrément utilisable in-game.. D'ailleurs je me demande si Gasega ne pourrait pas utiliser cette astuce pour améliorer ses moteurs.
Après le point négatif c'est que pour le moment aucun émulateur n'émule ce genre de chose (mais ça va surement changer).

[Invité]

C'est dingue que Sega ai finalement choisi de castrer cette partie avec 64 KB de VRAM. Si au moins ils l'avaient cablé de telle manière à conserver le DMA 16 bits, 2x fois de bande passante, c'est énorme ! Du coup là en activant le mode 128 KB tu peux activer une lecture 16 bits même si seuls 8 bits seront écrit en VRAM

Ils auraient pu aussi mettre 2x32 ko pour avoir 64ko en 16 bits non ??
Ou le mappage de la VRAM ne permet pas ça ??

Dans leur cas, ils en ont peut-être tiré un avantage pour certains effets de démo

C'est efficace quand les 8 bits poid faible sont identiques et n'ont pas besoins d'être changés (dans certains cas évidemment) .
Vu qu'avec le DMA classique ça ne marche pas .

[Stef]

C'est dingue que Sega ai finalement choisi de castrer cette partie avec 64 KB de VRAM. Si au moins ils l'avaient cablé de telle manière à conserver le DMA 16 bits, 2x fois de bande passante, c'est énorme ! Du coup là en activant le mode 128 KB tu peux activer une lecture 16 bits même si seuls 8 bits seront écrit en VRAM

Ils auraient pu aussi mettre 2x32 ko pour avoir 64ko en 16 bits non ??
Ou le mappage de la VRAM ne permet pas ça ??

Oui effectivement on se demande si avec une configuration de chip différent ils n'auraient pas pu faire cela.
Mais peut être que les chips P-SRAM  qu'ils ont utilisé à l'époque n'autorisaient pas cette configuration, quoiqu'il en soit c'est bien dommage.

[Invité]

Je sais que selon les périodes 1x64 ko pouvait être moins cher que 2x32 car les 32 ko devenaient de moins en moins produites au profit des 64 ou 128 ko .

[Stef]

En fait la mémoire utilisée pour la VRAM est assez spéciale, c'est une espèce de mémoire 4 bits très rapide du coup...selon la taille des chips ils ne pouvaient peut être pas faire les transferts 16 bits avec la configuration 64K, mais c'est dommage, on sent que le VDP a plus était fait pour fonctionner avec 128K... et un peu castré "salement" à la dernière minute.

[philip]

Il y avait déjà eu une discution à ce sujet il y a 7/8 ans de cela sur SpriteMind avec Tiido si je m'abuse... Mais tu es limité à l'usage lors du VBLANK. De plus, à quoi bon aller 2x plus vite pour ne garder qu'une donnée sur deux. Dans leur cas, ils en ont peut-être tiré un avantage pour certains effets de démo... Mais comme souvant, la majorité des astuces ne sont pas utilisables dans un jeu.

Effectivement comme tu as que 64 KB de VRAM (sauf si tu as la chance d'être le possesseur d'un TeraDrive :p) le byte de poids fort n'est pas écrit. A la base le DMA --> VRAM (qui peut être vu comme un slow DMA) même s'il écrit en VRAM 8 bits par 8 bits ne t'offre qu'une granularité de 16 bits sur la lecture/écriture de la donnée en VRAM. Je pense qu'ils ont fait ça pour rester cohérent avec les autres modes DMA (CRAM, VSRAM et donc VRAM 128K) et surtout pour l'écriture dans la tilemap ou la table de sprite.. Mais l'air de rien parfois c'est assez chiant cette granularité de 16 bits car même si tu peux régler le step d'incrément de l'adresse d'écriture tu es quand même bloqué à 16 bits écrits et ensuite tu as l'incrément. Là grâce à ce DMA 128K, tu réduis la granularité d'écriture à 8 bits (le byte haut étant ignoré) et ça ouvre carrément à de nouvelles possibilités de trick (pour faire du bitmap en autre en arrangeant les tilemaps comme il faut) :)
Donc non on ne gagne pas en bande passante (la moitié est perdu) mais ça ajoute des possibilités sur la conversion des buffers par exemple et/ou l'utilisation intelligente des tilemaps :) Et donc là si en plus c'est carrément utilisable in-game.. D'ailleurs je me demande si Gasega ne pourrait pas utiliser cette astuce pour améliorer ses moteurs.
Après le point négatif c'est que pour le moment aucun émulateur n'émule ce genre de chose (mais ça va surement changer).

J'ai tout compris, hum, en lisant ceci : "Writes to VRAM in 64k mode are slow". Ce mode c'est comme la compatibilité master System, soit une jambe de bois.

"vitesse DMA

DMA semble toujours utiliser la même vitesse, peu importe si les données DMA sont lues à partir ROM ou RAM. (Mais j'ai oublié que je l'ai testé modes rapide.)

Il n'y a que deux types de transferts vitesse sages: les lents et rapides. Écrit à VRAM en mode 64k sont lents, tous les autres types de transferts (à CRAM, VSRAM ainsi que VRAM en mode 128k) sont rapides"




Le mode 128K étant celui avec lequel la puce a été imaginé à l'époque... C'est alors le mode avec lequel il faut travailler. 

[Invité]

J'ai tout compris, hum, en lisant ceci : "Writes to VRAM in 64k mode are slow".

Oui ils sont "lent" car sur un bus 8 bits en 64ko, contrairement à la snes/pce .
La snes fait du 16 bits mais à 2.6 mhz,et la pce ne fait que du VRAM->VRAM jusqu'a 10mhz .
La MD fait du 8 bits à 5.37/6.71 mhz .

L'ajout de 64ko supplémentaires fait passer le bus 8 bits en 16, et donc tu doubles les transferts pour le même dot clock .

[TotOOntHeMooN]

Je sais que selon les périodes 1x64 ko pouvait être moins cher que 2x32 car les 32 ko devenaient de moins en moins produites au profit des 64 ou 128 ko .

La MD utilise de la Dual Port RAM pour permettre l'accès aussi bien par la CPU (lecture/écriture en série) que par le VDP (lecture en parallèle). Ce type de mémoire dispose d'un bus de données 4-bit afin de réduire le nombre de pins du package. Il est donc nécessaire d'utiliser deux circuits de 64Kb x 4bit pour obtenir 64Ko. De ce fait, il n'est pas possible d'avoir 32Ko sur un bus et 32Ko sur l'autre car la DPRAM n'existait pas en 8bit.

On peut imaginer que Sega avait réservé cet usage pour l'arcade et non pour la machine de salon.
Par exemple, le System C-2 utilise le même VDP mais avec le maximum de performances :
- 128K de VRAM (full DMA 16-bit)
- CRAM externe (32768 couleurs et 4 palettes par plan)

[Invité]

De ce fait, il n'est pas possible d'avoir 32Ko sur un bus et 32Ko sur l'autre car la DPRAM n'existait pas en 8bit.

Ok, je comprends mieux le choix alors .

[ace76]

C'est pas le bon topic,mais avec ce genre de Démos,la MD enterre définitivement la Snes .
Mais pas l'AMIGA500 qui dispose de Démos inégalables.

[Invité]

C'est pas le bon topic,mais avec ce genre de Démos,la MD enterre définitivement la Snes .
Mais pas l'AMIGA500 qui dispose de Démos inégalables.

Pour le moment vu que ça tourne sur pas bcp de MD, je dirai non 

Et puis, chaque machine sait faire des effets impossibles sur une autre, moi j'irai dans ce sens et non à essayer de singer ce que l'autre fait en +/- hard .
C'est comme faire du mode 7 sur MD (ou autre de même gen), ça serra jamais au niveau du M7 de la snes,tout comme faire de la 3D sur snes dans les mêmes proportions que sur MD .

[TotOOntHeMooN]

On verra bien la prochaine démo de Titan sur SNES...

[Invité]

On verra bien la prochaine démo de Titan sur SNES...

Es ce que le message allait dans ce sens, ou alors poussait ouvertement les codeurs snes à se sortir les doigts du fion,et se mettre enfin à coder autres choses que des FMV !!

[TotOOntHeMooN]

Wet and sea... 

[Invité]

Wet and sea... 

Clair, en tout cas je serrai plié si les mecs de titan sortaient un truc qui déboîte sur snes .
Je pense que tout le forum snesdev migrerait vers sega-16 

[TotOOntHeMooN]

Clair... Ils peuvent se préparer à mon avis. 

[Tryphon]

Sur quelles MD ça ne tourne pas ?

[Invité]

Our tests have shown that around 30% of Model I and 5% of
Model II systems experience issues. This is due to a change
in the manufacturing process of the video chip.

J'ai pas vu bcp de personnes sur sprites mind ou sega-16 ayant réussi à la faire tourner sans soucis .

Un des codeurs à posté ça:

If you can run the demo on real hardware somehow, we'd appreciate if you could help us with our research by posting the following details:

Model number and revision (e.g. MD1 VA4)
Serial number of the console
Picture of the VDP / ASIC (if possible)
Brief description of glitches experienced (if any)

Thanks in advance!

En général on fait plutôt le contraire .