Re: Megadrive et Super Nintendo : parlons technique !

[Tryphon]

Si l'un d'entre vous peut m'expliquer exactement sur quoi porte le nœud de l'argument, je vous serai extrêmement reconnaissant

Je n'y connais pas grand chose en technique, mais ça m'intéresse

Sur ce, je retourne écouter en boucle l'OST de Super Aleste, pour me punir d'avoir pensé que celle de MUSHA était excellente

[TotOOntHeMooN]

- on dégage la rétro compatibilité SMS
- on vire le highlight / shadow
- exit le mode entrelacé 448/480 qui doit consommer de précieux transistors pour un apport mineur
- 4 + 4 palettes
- RGB444
- ajout d'un step adresse source pour le DMA (pratique pour faire des opérations de type conversion bitmap / tile), et ça doit rien couter ^^
- 128K VRAM mais idéalement et si c'est moins couteux je me contente des 64K mais avec DMA VRAM 16 bits

et optionnellement :
- connexion des timers YM sur les interruptions du Z80.

Voilà, je ne suis pas gourmand et je pense que c’était assez faisable en terme de coût (en supprimant ce que j'ai indiqué). Mais bon bien sûr en connaissant le futur c'est plus facile :p

Je pense que c'est une base qui fait l'affaire de tout le monde car c'est ce qu'on aurait dû avoir dès sa sortie.

Concernant les 64K en 16bit, c'est cocasse, mais j'avais déjà indiqué qu'on ne pouvait pas avec les circuits DRAM de l'époque. 
Je ne vais pas repartir à la recherche du post, mais c'est une histoire de combinaisons de puces qui ne va pas, sinon j'imagine que Sega aurait câblé ainsi.

[Tryphon]

Je suis d'ailleurs toujours intéressé par une version de Gens avec des palettes découplées et une palette 12 bits ! Juste pour voir ce que ça peut donner

[TotOOntHeMooN]

Je suis d'ailleurs toujours intéressé par une version de Gens avec des palettes découplées et une palette 12 bits ! Juste pour voir ce que ça peut donner

+ 4096

[Stef]

Je suis d'ailleurs toujours intéressé par une version de Gens avec des palettes découplées et une palette 12 bits ! Juste pour voir ce que ça peut donner

Le problème c'est qu'après il faut patcher les jeux pour l'utiliser :p

[Tryphon]

Ça, ça va, je sais faire

[Tryphon]

Je suis d'ailleurs toujours intéressé par une version de Gens avec des palettes découplées et une palette 12 bits ! Juste pour voir ce que ça peut donner

+ 4096

Il y a 10 types de personnes sur Terre...

[TotOOntHeMooN]

Il y a 10 types de personnes sur Terre...

Hum... Ceux qui connaissent le binaire, et les autres. 

[Stef]

Je pense que c'est une base qui fait l'affaire de tout le monde car c'est ce qu'on aurait dû avoir dès sa sortie.

Concernant les 64K en 16bit, c'est cocasse, mais j'avais déjà indiqué qu'on ne pouvait pas avec les circuits DRAM de l'époque. 
Je ne vais pas repartir à la recherche du post, mais c'est une histoire de combinaisons de puces qui ne va pas, sinon j'imagine que Sega aurait câblé ainsi.

Oui je me souviens tu m'avais expliqué, c'est pour ça que j'ai précisé "si ça revenait moins cher" sinon on reste sur les 128K. Mais pour moi le 128K n'est pas le design original du VDP, on le voit quand même... l'implémentation la plus propre et logique quand tu scrutes un peu à l'intérieur c'est du 64K avec VRAM 16 bit, donc c'est assez étrange.
On voit qu'il y a eu :
- un premier design à 64K (mais pas complètement finalisé)
- puis un passage à 128K (plus ou moins bien intégré)
- un rollback de dernière minute en 64K mais clairement fait à l'arrache (et avec des comportements un peu bizarres sur le DMA FILL notamment à cause de l'écriture VRAM 8 bit)

[TotOOntHeMooN]

Je pensais que le design 128K en 16bit était présent dès le début et qu'ils avaient juste arbitrairement divisé par deux pour n'avoir que 2 circuits sur la carte mère au lieu de 4 ... Et faire des économies en fonction car au final c'est quand même pas dégueu pour une console sortie fin 88.

Pourquoi avoir fait un second design de la sorte du coup !?
Au passage, je n'ai pas souvenir du bus de données 16-bit sur le VDP pour câbler une telle VRAM ?

[Stef]

Non le design en 128K est arrivé en cours de route, on peut le voir dans une interview du concepteur de la MD... En gros c'est son boss qui lui a dit "Bon il faudrait passer à 128K de VRAM pour contrer la future SNES", le concepteur disait même que ce passage en 128K lui avait couté pas mal de temps car il ne l'avait pas anticipé et qu'il avait du revoir pas mal de choses. Et plus tard il disait être finalement revenu en 64K à la fin pour des raisons économique et parce-que le 128K n'apporterait pas tant que ça (ce qui est plutot faux, je pense surtout qu'ils savaient que la SNES ne ferait pas mieux sur ce point).

[TotOOntHeMooN]

J'imagine qu'il avait prévu d'adresser la mémoire sur 16bit, donc 128K c'est un bank switch ? En tout cas, je suis déçu car d'après le pinout du VDP présent sur les schémas que j'ai pu trouver, on ne peut pas interfacer la mémoire en 16bit, que se soit 64K ou 128K.

[upsilandre]

J'imagine qu'il avait prévu d'adresser la mémoire sur 16bit, donc 128K c'est un bank switch ? En tout cas, je suis déçu car d'après le pinout du VDP présent sur les schémas que j'ai pu trouver, on ne peut pas interfacer la mémoire en 16bit, que se soit 64K ou 128K.

En fait y a pas besoin de passer le port VDP en 16bit. La VRAM de la MD est un peu particulière, c'est une DRAM classique (dont les accès ici ne dépasseront pas les 3.35mhz) couplé a un controleur complexe "dual port" (un serial port et un random port) et un buffer interne de 2048bit. Le bute c'est d'utiliser un petit bus mais a haute fréquence grace au buffer.
Le VDP a 2 ports VRAM qui sont 8bit mais qui sont a 13.4mhz. L'un des 2 ports du VDP est connecté au serial port de la VRAM (c'est le port qui passe par le buffer interne 2048bit et qui permet alors de streamer un paquet de data a la fréquence qu'on veut pourvu que les données soit contigu) et ce port est réservé par le VDP uniquement pour lire la VRAM pendant l'affichage et construire l'image ce qui autorise donc un flux 8bit a 13.4mhz (mais qui au final se comporte comme un flux 32bit a 3.35mhz car la granularité est au minimum de 32bit, les fameux slot, tu ne peux pas adresser ni remplir le buffer interne a une vitesse superieur a 3.35mhz).
Le second port 8bit du VDP est connecté a la fois au random port de la VRAM et a son bus d'adressage. Le port random permet des acces aléatoires a la VRAM et c'est celui qui est utilisé pour tout les accès externe a la VRAM (par le DMA ou le CPU). Ce port fonctionne selon une phase en 4 cycles, c'est du multiplexage. les 2 premiers cycle qui servent pour l'adressage (que ce soit pour des acces par le random port ou par le serial port), ensuite y a un 3eme cycle qui sert pour lire ou écrire de facon random (par le DMA ou le CPU) et , c'est la que c'est intéressant, un 4eme cycle qui n'est pas utilisé car par le port random on ne peut pas faire des acces a 13.4mhz ni meme 6.7mhz, la DRAM reste une DRAM calibré pour du 3.35mhz. Du coup on se retrouve bridé a un flux 8bit a 3.35mhz par se port et avec un cycle inutilisé dans le multiplexage.
Mais ce cycle inutilisé pourrait l'etre pour un second cycle d’écriture/lecture (et donc avoir cette fois l’équivalent d'un flux 16bit a 3.35mhz pour le DMA) si on pouvait ajouter un second set de chip VRAM en parallèle que tu controles en alternance (les 2 premiers cycle tu ON les 2 sets de VRAM pour adresser tous les chips, le second cycle tu ON le premier set et OFF le second pour faire une premiere ecriture dans le premier set de VRAM, le 4eme cycle tu OFF le premier set et ON le second pour faire une seconde écriture dans le second set) mais pour ca faut 4 chips, avec 2 c'est pas possible.

[TotOOntHeMooN]

En fait y a pas besoin de passer le port VDP en 16bit.

OK, donc en fait quand vous parlez de DMA en 16-bit pour les accès VRAM, c'est 2x8bit. Je pensais vraiment qu'il n'y avait que 8bit de câblé par commodité, tout comme la CRAM externe n'est pas câblée par exemple.

 La VRAM de la MD est un peu particulière, c'est une DRAM classique (dont les accès ici ne dépasseront pas les 3.35mhz) couplé a un controleur complexe "dual port" (un serial port et un random port) et un buffer interne de 2048bit. Le bute c'est d'utiliser un petit bus mais a haute fréquence grace au buffer.
Le VDP a 2 ports VRAM qui sont 8bit mais qui sont a 13.4mhz. L'un des 2 ports du VDP est connecté au serial port de la VRAM (c'est le port qui passe par le buffer interne 2048bit et qui permet alors de streamer un paquet de data a la fréquence qu'on veut pourvu que les données soit contigu) et ce port est réservé par le VDP uniquement pour lire la VRAM pendant l'affichage et construire l'image ce qui autorise donc un flux 8bit a 13.4mhz (mais qui au final se comporte comme un flux 32bit a 3.35mhz car la granularité est au minimum de 32bit, les fameux slot, tu ne peux pas adresser ni remplir le buffer interne a une vitesse superieur a 3.35mhz). Le second port 8bit du VDP est connecté a la fois au random port de la VRAM et a son bus d'adressage. Le port random permet des acces aléatoires a la VRAM et c'est celui qui est utilisé pour tout les accès externe a la VRAM (par le DMA ou le CPU). Ce port fonctionne selon une phase en 4 cycles, c'est du multiplexage. les 2 premiers cycle qui servent pour l'adressage (que ce soit pour des acces par le random port ou par le serial port), ensuite y a un 3eme cycle qui sert pour lire ou écrire de facon random (par le DMA ou le CPU)

Oui, ça OK. Normal. Et je vois ou tu veux en venir...

et , c'est la que c'est intéressant, un 4eme cycle qui n'est pas utilisé car par le port random on ne peut pas faire des acces a 13.4mhz ni meme 6.7mhz, la DRAM reste une DRAM calibré pour du 3.35mhz. Du coup on se retrouve bridé a un flux 8bit a 3.35mhz par se port et avec un cycle inutilisé dans le multiplexage.

... tu pourrais avoir un second flux 8-bit sur le 4ème cycle, effectivement.

Mais ce cycle inutilisé pourrait l'etre pour un second cycle d’écriture/lecture (et donc avoir cette fois l’équivalent d'un flux 16bit a 3.35mhz pour le DMA) si on pouvait ajouter un second set de chip VRAM en parallèle que tu controles en alternance (les 2 premiers cycle tu ON les 2 sets de VRAM pour adresser tous les chips, le second cycle tu ON le premier set et OFF le second pour faire une premiere ecriture dans le premier set de VRAM, le 4eme cycle tu OFF le premier set et ON le second pour faire une seconde écriture dans le second set) mais pour ca faut 4 chips, avec 2 c'est pas possible.

Oui, exactement. Et bien, des personnes ont déjà essayé de prototyper cela ?
Je jeux dire, avec un hack sur une vrai MD, sans refaire la PCB, ça doit être jouable.

[upsilandre]

A mon avis il manquerait des truc dans le VDP pour pouvoir le faire. Je pense pas que ce qu'il reste du mode 128k réponde vraiment a ca. Peut etre meme que Sega n'a jamais envisagé d'avoir un vrai DMA 16bit et qu'il trouvait cette situation suffisante (mais c'est un peu triste quand justement t'as une vrai console 16bit)

[sengoku 2]

Y a vraiment aucun lien entre le VDP de la MD et le System 16. Le system 16 a de vrai particularité singulière du coté affichage, de vrai signature, on retrouve aucune de celle ci dans la MD tout comme les singularité du VDP ne se retrouve pas dans le system 16. Je sais meme pas si on pouvait faire plus différent.

Voilà une remarque qui mérite développement, ça serait intéressant que tu t'attardes dessus, ça mettra en perspective le challenge qu'a Tryphon en adaptant Shinobi sur MD.

[TotOOntHeMooN]

A mon avis il manquerait des truc dans le VDP pour pouvoir le faire. Je pense pas que ce qu'il reste du mode 128k réponde vraiment a ca. Peut etre meme que Sega n'a jamais envisagé d'avoir un vrai DMA 16bit et qu'il trouvait cette situation suffisante (mais c'est un peu triste quand justement t'as une vrai console 16bit)

OK. Sincèrement, j'en entendais parler mais je pensais que c'était factuel et qu'il état possible dune façon ou d'une autre de le mettre en place via un décodage externe par exemple. Après, c'était effectivement suffisant mais regrétable.

[upsilandre]

Tout ce que je te dis la c'est juste ce que j'ai déduit des datasheet de la VRAM (et des schematics de la MD). Y a ce cycle libre dans le multiplexage qu'on pourrait probablement exploiter dans une configuration 4 chips. Mais j'ai jamais rien vu sur ce sujet donc difficile de savoir si c'est faisable.

[TotOOntHeMooN]

Tout ce que je te dis la c'est juste ce que j'ai déduit des datasheet de la VRAM (et des schematics de la MD). Y a ce cycle libre dans le multiplexage qu'on pourrait probablement exploiter dans une configuration 4 chips. Mais j'ai jamais rien vu sur ce sujet donc difficile de savoir si c'est faisable.

J'ai entendu d'autres personnes en parler sur différents forums, c'est tout. Je regarderai aussi de mon coté si j'ai un peut de temps.

[upsilandre]

Y a vraiment aucun lien entre le VDP de la MD et le System 16. Le system 16 a de vrai particularité singulière du coté affichage, de vrai signature, on retrouve aucune de celle ci dans la MD tout comme les singularité du VDP ne se retrouve pas dans le system 16. Je sais meme pas si on pouvait faire plus différent.

Voilà une remarque qui mérite développement, ça serait intéressant que tu t'attardes dessus, ça mettra en perspective le challenge qu'a Tryphon en adaptant Shinobi sur MD.

On aurait pu déduire une filiation si par exemple sur MD on avait eu du background en 3bpp ou si on avait eu des sprites avec le meme format hybride sans tiles ou si on avait une table de scrolling dans le System 16 mais y a rien de tout ca. Et puis l'affichage du System 16 c'est plein de petit chip spécialisé pour chaque fonction (probablement de type "gate arrays") la ou le VDP de la MD est un gros ASIC et encore lié a celui de Texas Instrument.
Y a plus de ressemblance je trouve avec le CPS de Capcom qu'avec le System 16.

[upsilandre]

Tout ce que je te dis la c'est juste ce que j'ai déduit des datasheet de la VRAM (et des schematics de la MD). Y a ce cycle libre dans le multiplexage qu'on pourrait probablement exploiter dans une configuration 4 chips. Mais j'ai jamais rien vu sur ce sujet donc difficile de savoir si c'est faisable.

J'ai entendu d'autres personnes en parler sur différents forums, c'est tout. Je regarderai aussi de mon coté si j'ai un peut de temps.

ah oui je serais curieux de lire d'autre allusion dans ce sens. Ca peut etre intéressant.

[TotOOntHeMooN]

J'avais pas du regarder sur la "bonne" version du VDP, mais... Le chip select, write enable et les 8 bits de data de la seconde banque mémoire pour porter à 16 bits la VRAM, ça ne serait pas ce qui reste vierge (9, 14, 18-25) ici :



EDIT : Ca aurait bien plus de sens pour avoir une vrai interface mémoire en 16-bit quand même.
En plus, il me semble que ça me parle et que j'ai déjà vu ça il y a quelques années sur spriteminds...

[upsilandre]

C'est ce qu'on voit sur d'autre schema. Ca voudrait dire qu'il ne pouvait donc pas exploiter le cycle libre sinon aucune raison d'ajouter encore un autre port redondant (surtout que sur les cycles d'adressage ca doit etre un mirroir de l'autre port, ca fait un peu gachie) c'est sur que c'est plus simple.
Mais dans cette configuration on comprend moins bien l’intérêt de ce choix de VRAM.

[TotOOntHeMooN]

Dans cette configuration on comprend moins bien l’intérêt de ce choix de VRAM.

Parce que le port série permet de ne pas bloquer la lecture lors de l'écriture.
Ca reste moins cher que de la vrai mémoire dual-port et avec moins de pins donc un package réduit. Le concepteur de la MD avait éxpliqué qu'il était le premier à utiliser ce nouveau type de mémoire NEC et que ça apportait des performances  significatives.

[upsilandre]

Quand le VDP lit la VRAM il solicite la DRAM au maximum de sa capacité (a cause de la granularité 32bit, avec une granularité plus grossière genre 64 ou 128bit par slot la oui y aurait eu de la place), y a plus de cycle disponible pour le port random et donc pour l'ecriture, tu peux pas faire les 2 en meme temps.
C'est une mémoire dual port mais qui se partage quand meme la meme DRAM.

[TotOOntHeMooN]

Quand le VDP lit la VRAM il solicite la DRAM au maximum de sa capacité (a cause de la granularité 32bit, avec une granularité plus grossière genre 64 ou 128bit par slot la oui y aurait eu de la place), y a plus de cycle disponible pour le port random et donc pour l'ecriture, tu peux pas faire les 2 en meme temps.
C'est une mémoire dual port mais qui se partage quand meme la meme DRAM.

J'imagine que le port random est utilisé par le proceseur hote pour lire et écrire les données, alors que le port série est utilisé uniquement pour l'affichage. Ca évite un accès concurent du bus et donc des cycles d'attentes.

[upsilandre]

Sur la Megadrive actuel l'interet de cette mémoire c'est que ca permet effectivement d'atteindre un debit en lecture superieur a ce qu'on peut obtenir avec une DRAM ordinaire surtout avec un bus 8bit et seulement 2 chip mais a partir du moment ou tu doubles les chip et que tu passe en 16bit y a d'autre solution plus intéressante je pense.

[Hpman]

On peut effectivement monter les 2 ram supplémentaires avec le pinout dispo sur le VDP de base pour avoir les 128K en 16bits

[ob1]

@upsilandre> Je vois que je ne suis pas le seul à avoir du mal à discuter technique avec Touko :p

Sinon puisqu'on en est à parler de la MD idéale, je trouve que la tienne s'éloigne quand même pas mal de l'originale même si je dois admettre être assez friand du mode 8bpp :p
et je m'interroge aussi sur le cout de grossir / doubler les bus d'adresses sur le VDP pour utiliser d'autre type de RAM. Je trouve que la PSRAM avait justement cet intérêt... et c'est vraiment ce choix technique qui avait permis d'obtenir une telle performance en lecture pour un cout raisonnable (moyennant de la recherche sur le design du VDP).

Perso pour moi pas beaucoup de changements :
- on dégage la rétro compatibilité SMS
- on vire le highlight / shadow
- exit le mode entrelacé 448/480 qui doit consommer de précieux transistors pour un apport mineur
- 4 + 4 palettes
- RGB444
- ajout d'un step adresse source pour le DMA (pratique pour faire des opérations de type conversion bitmap / tile), et ça doit rien couter ^^
- 128K VRAM mais idéalement et si c'est moins couteux je me contente des 64K mais avec DMA VRAM 16 bits

et optionnellement :
- connexion des timers YM sur les interruptions du Z80.

Voilà, je ne suis pas gourmand et je pense que c’était assez faisable en terme de coût (en supprimant ce que j'ai indiqué). Mais bon bien sûr en connaissant le futur c'est plus facile :p

J’ai suggéré le RGB44R à Analogue.

[TotOOntHeMooN]

J’ai suggéré le RGB444 à Analogue.

Un projet en cours ?
le RGB444 c'est un peut la première chose à laquelle on pense quand on souhaite refaire une MD, non ?

Sachant que la CRAM interne code le pixel ainsi : ---- -bbb -ggg -rrr 
On peut limite se douter qu'à la base ils avaient : ---- bbbb gggg rrrr
Sur System C2 le codage sur 15bit est fait ainsi : -bgr bbbb gggg rrrr
A la place, j'aurai trouvé plus intéressant d'avoir : aaaa bbbb gggg rrrr

[Tryphon]

Sur Game Gear je crois que c'est ---- bbbb gggg rrrr

Concernant l'alpha, certes c'est intéressant, mais je suppose que ça nécessite une architecture beaucoup plus complexe pour être implémenté non ?