Re: MEGADRIVE vs SUPER NINTENDO : Fight !

par **TotOOntHeMooN** Dim 30 Aoû 2020 - 14:19

Kannagi a écrit:De rien , ça me fait plaisir ,je te ferais d'autre compliment digne de toi

On va optimiser pour gagner du temps : Gardes-les pour toi Mr. Green

Kanagi a écrit:Mais je ne te répondais pas forcément à toi , il faut se clamer un peu

Tu réponds à ce que j'écris, ce qui n'était pas forcément adressé à toi si tu vas par là, mais je ne peux pas y réponde à mon tour... clown

kannagi a écrit:Je dis juste que si on fait des "si" pas mal de machine aurait pu être meilleur, c'est toi qui t’énerve pour un
rien

J'ai juste indiqué que c'était quelque chose d'existant et fonctionnel, utilisé en arcade et que ça n'a rien à voir avec des "SI" de choses inexistantes en l'état. Il semblerait plutôt que je t'agace à indiquer que ton contre-exemple était mal choisi. Razz

par **TotOOntHeMooN** Dim 30 Aoû 2020 - 15:01

upsilandre a écrit:64Ko de SRAM 16bit ca aurait été mieux pour la MD. Mais effectivement il aurait fallu partir la dessus au départ (et pas sur la dual-port), c'est pas un truc que tu peux switcher a la fin effectivement.

Pour 64K, ça aurait été plus simple avec deux circuits SRAM de 32K. Aussi la DPRAM n'existant pas dans cette capacité (multiplexage du bus d'adresse), sinon ça aurait quand même bien simplifié les choses !

upsilandre a écrit:La dual-port c'est l'invention de Texas Instrument. Ensuite c'est comme tout, ces technologies sont a terme licencié a d'autres fondeurs qui peuvent produire les chips et a partir de la on peut se servir chez de multiple fournisseur.

Je n'ai pas vu de référence équivalente chez TI, ni ailleurs. Et aucune Mega Drive et équipée de circuit provenant de TI, pour justifier un partenariat historique qui aurait fait choisir ce type de mémoire.

upsilandre a écrit:“What was the most challenging part of the production process?
Masami Ishikawa: The first was choosing the optimal memory access cycle spec. Sato-san handed me a data sheet for Texas Instruments’ newly released dynamic RAM spec, called Dual-Port Memory, and asked me to somehow find a way to adopt this memory within the Mega Drive. I had a tough time tackling the data sheet of memory — which no one had ever used before — so I decided upon the specs first and then just jotted down any observations or ideas I had. I would spend days just contemplating it”
Je trouve que la on devine un peu l'influence de TI sur Sato puis l'influence du boss Sato sur Masami a qui il refile le dossier sans peut etre lui demander son avis. C'est peut etre pas une décision d'ingénieur au final (meme si Sato en est quand meme un).

Oui, c'est effectivement cela. Il souhaitait une mémoire plus performante et c'est vu présenter cette data sheet concernant la Dual-Port. Mais par habitude de travailler avec TI, je pense que sa "mémoire" lui a joué des tours et qu'il parle plutôt de ça : https://datasheetspdf.com/pdf-file/545214/NECElectronics/UPD41264/1

upsilandre a écrit:Oui c'est un choix qui a probablement été fait assez tot, peut etre avant le choix du CPU 16bit. Donc oui y a plein de chose pour justifier ou excuser le choix c'est certain. Moi je parle de ce qu'aurait pu être la MD idéal après coup. A partir du moment ou l'on sait maintenant qu'il y a un CPU 16bit et 64ko de VRAM alors "après coup" le dual-port semble un mauvais choix comparé a une simple architecture SRAM 16bit 64Ko tel la PCE qui aurait permis a la console d'exprimer tout son potentiel.

Oui, après coup. Il indique bien chercher une mémoire pour augmenter les cycles d'accès et savait très bien que la SRAM était disponible. Aussi, s'il avait su que l'on lui briderait sa techno, j'imagine aussi qu'il ne se serait pas pris la tête. Et si l'on y repense avec le recule tu as raison.

upsilandre a écrit:Surtout pour la rendre futur proof. Le DMA doublé au début ca n'aurait pas beaucoup servit mais sur la fin quand les cartouches sont grosse ca aurait permis a la megadrive d'etre au top en animation mais aussi d'ouvrir des portes sur les extensions de cartouche (y aurait eu plus de potentiel que sur SNES) ou meme l'usage du MCD qui sont tous des truc chaque fois bridé par le DMA trop lent. Et donc encore une fois c'est évidemment plus simple a dire "apres coup" car on sait que la MD a une longue vie.

Je suis bien d'accord et c'est pour ça que je vois plus cette erreur de port d'extension sans bus VRAM (et CRAM) pour assurer l'évolution de la machine avec cartouches plus grosses. Aussi, il y avait un bon paquet de circuit a virer du MegaCD pour faire mieux en gardant ce support de stockage aussi.

par Invité Dim 30 Aoû 2020 - 15:45

Tu réponds à ce que j'écris, ce qui n'était pas forcément adressé à toi si tu vas par là, mais je ne peux pas y réponde à mon tour...

Tu m'avais directement cité , je n'ai cité personne ,je parlais juste de façon général de ce qui aurait été mieux sur la SNES Razz

Sans forcément dénigré la MD , parce que oui , elle aurait pu mieux faire Wink

J'ai juste indiqué que c'était quelque chose d'existant et fonctionnel, utilisé en arcade et que ça n'a rien à voir avec des "SI" de choses inexistantes en l'état. Il semblerait plutôt que je t'agace à indiquer que ton contre-exemple était mal choisi.

Les changement que je dis sont pas de l'ordre de l'impossible ,c'était largement faisable , mais je le redis ,regarde la doc SNES ,c'est plus un choix architectural qu'une vrai contraitre hardware Rolling Eyes

Sinon le seul truc qui m'agace ,c'est le don que tu as pour lancer des débats complètement idiot Mr. Green

par **wiiwii007** Dim 30 Aoû 2020 - 16:04

airdream a écrit:
wiiwii007 a écrit:Le chiptune je n'aime pas ? Bah si, mais quand c'est bien fait

Ghouls 'n' Ghosts sur arcade je n'aime pas les bruitages également si ça peut te consoler

Tu aimeras surement la version PSP, vas y elle elle est bien ! !
Sur PS2 aussi le jeu est en 3D, tu devrait etre comblé, beaucoup plus réaliste et immersif que sur 16 bits, son et couleurs au top ! !
maximo PS2:

Si tu mettait ton coté mélomane de coté 5 min, la discussion serait plus agreable, je sais que t'aimes les jeux 16 bits, mais tu leurs trouve tant de defaut que j'ai souvent du mal a comprendre.

On est d'accord que toutes les OST ne sont pas faramineuses sur MD, SNES ou PCE, mais bon en 1992 quand t'avait entre 6 et 14 ans, t'y voyais que du feu, et ces imperfections font vraiment une force aujourd'hui. (Jamais je n'ai imaginé jouer avec des OST réorchestree genre MSU-1 SNES ou avec une OST MCD pour des jeux MD. (Quand le jeu existe sur les 2 support je favorise la version MD, tel ECCO, Earthworm Jim, Chuck Rock...)

J'irai meme plus loin quand je joue aux jeux Master System (via emulateur) je supprime aussi la fonction "FM" des jeux, (Bon, ca je peux comprendre que je suis pas dans le groupe des majoritaires)

Ca va être très simple : j'aime le son NES, bizarre non ? Je te laisse chercher pourquoi par contre.

Vous mettez tout dans le même plat, voilà pourquoi vous ne comprenez pas les différences de qualité. Je ne vois que ça, sinon vous ne diriez pas ça.

Là je me fais PS2 ben les musiques sont plutôt agréable car les sons ne prennent pas la tête. Il ne faut pas être mélomane pour comprendre ça je te rassure Wink

Sinon les opus G'n'G sur les autres consoles c'est prévu... Et je ne sais pas pourquoi mais je pense que je vais préférer. Et bizarrement, je pense que ça viendra plus du gameplay que de la bande son Razz

par **wiiwii007** Dim 30 Aoû 2020 - 16:09

airdream a écrit:
Kannagi a écrit:
airdream a écrit:
A certain je me demande ce qu'ils font ici sans dec, faut que le retro ressemble au réel, couleurs a foison, son imitant la réalité, des faux retrogamer quoi, autant se tourner vers les 128 bits et +
Il est difficile d'avoir un truc réaliste sur les consoles 16/32 bits effectivement
tu parles des seins triangulaire de Laracroft sur 32 bits? en effet c'est loin de la réalité un sein doit etre en forme de poire

t'as compris que la réalité a tout prix c'est pas le truc du "retro-gamer" quand meme j'espere, c'est là ou je voulais en venir

Je déteste le réaliste dans les JV.

Par contre je déteste encore plus un son qui me prend la tête. Et dans l'ex G'n'G si tu écoutes bien, tu verras que t'as des bruits stridents qui n'ont rien à foutre ici. u changes juste ça avec un autre son pas réaliste et ça change tout !

Donc non, je ne souhaite pas du tout un son réaliste, mais un son moins prise de tête. Et je sais que c'est possible sur MD.

par Stef Dim 30 Aoû 2020 - 16:17

upsilandre a écrit:L'architecture VRAM de la PCE et de la SNES c'est suffisant pour la MD. T'as un bus 16bit (qui profiterait alors au DMA de la MD qui du coup enterrerait la concurrence sur ce point) et de la SRAM qui supporte les fréquences nécessaire pour le VDP (y a juste besoin de lire la SRAM a 6.71mhz, la PCE le fait très bien a 7.16mhz). Et ca évite justement de mettre 128Ko (y a des choses bien plus prioritaire). En plus de peut être simplifier le controleur mémoire (pour laisser de la place a la CRAM, en plus des coupes possible sur la retro SMS, les shadow/highlight et l'entrelacé)

J'ai de plus en plus l'impression que Sega a voulu faire plaisir a leur partenaire historique Texas Instrument (c'est ce qui ressort des interviews je trouve, c'est TI qui semble démarcher Sega sur ce sujet) en trouvant un moyen d'utiliser cette nouvelle RAM dual port de TI dans la MD mais qui en vrai est une RAM conçu pour des machines a base de framebuffer, pas pour des machines au raster comme la MD. La MD arrive a en faire un usage ingénieux tout a fait correct mais c'est quand meme un assez mauvais usage d'une RAM dual port. Et si c'est au prix de faire l'impasse sur l'écriture 16bit dans la VRAM (vu qu'ils ont abandonné les 128Ko) et donc sur toute la force de l'architecture 16bit de la MD ca me parait un semi-echec sur ce point mais je sais que stef n'est pas tout a fait d'accord. Mon avis a pas mal changé au fil de mon intérêt sur cette question de la VRAM. Je pense qu'un jour j'écrirais un billet la dessus mais j'attend d'en savoir toujours plus sur ces choix.

En fait tu as peut être raison, honnêtement je n'ai plus les chiffres en tête mais moi il me semblait qu'avec de la simple SRAM 2x8 bit ça ne passe pas en terme de débit sur la lecture des données. Il faut pas oublier non plus le mapping linéaire de la VRAM de la MD qui est un avantage énorme comparé aux autres machines et qu'on ne veut pas perdre.

Par contre, y'a une chose qui est certaine, c'est que lorsque tu regardes le design du VDP de la MD et aussi avec l'interview de designer, on voit bien que la config initiale c'était de la VRAM avec des écritures 16 bit et 64 Ko de VRAM, ensuite le design a été largement revu pour passer en 16 bit / 128Ko (ce qui donnait déjà un design beaucoup moins élégant avec le bit 16 de certaines tables placées dans des registres à part) pour être finalement recastré en 64 ko à la dernière minute en divisant le BUS par 2 ce qui a abouti à une VRAM accessible en 8 bit seulement... Du coup je me demande vraiment comment était le design original, car visiblement on a l'impression que c'était déjà sur une base de dual port mais peut être que je me trompe.

@Kannagi> je n'y crois pas trop à cette histoire de rétro compatibilté pour expliquer le design bancale du PPU de la SNES, car en réalité très tôt (dés mi-1988) celle-ci a été abandonnée par Nintendo. Visiblement ne serait qu'à cause du port cartouche radicalement différent c'était peine perdu d'avance (trop couteux)... je pense que la différence c'est que sur SNES l'OAM se trouve en intégralité sur le PPU (sur la MD seule une partie est en cache dans le VDP) et donc il faut optimiser sa taille (surtout qu'il y a 128 entrées), ça permet aussi de limiter le besoin en DMA pour la mettre à jour puisque là aussi c'est du 8 bit en transfert (mais sur SNES je dirais que c'est plus logique)

par **TotOOntHeMooN** Dim 30 Aoû 2020 - 16:38

Stef a écrit:Par contre, y'a une chose qui est certaine, c'est que lorsque tu regardes le design du VDP de le MD et aussi avec l'interview de designer, on voit bien que la config initiale c'était de la VRAM avec des écritures 16 bit et 64 Ko de VRAM, ensuite le design a été largement revu pour passer en 16 bit / 128Ko (ce qui donnait déjà un design beaucoup moins élégant déjà avec le 16 bit de certaines tables placées dans des registres à part) pour être finalement recastré en 64 ko à la dernière minute en divisant le BUS par 2 ce qui a abouti à une VRAM accessible en 8 bit seulement... Du coup je me demande vraiment comment était le design original, car visiblement on a l'impression que c'était déjà sur une base de dual port mais peut être que je me trompe.

Je pense que c'était à l'origine en 64K SRAM (2x 32K 8-bit) et que les performances n'étaient pas ce qu'il espérait. Il est donc passé en 128K DPRAM (4x 64K 4-bit) pour au final se voir son design limité à 64K DPRAM (2x 64K 4-bit).

par Stef Dim 30 Aoû 2020 - 16:43

Ce n'est pas ce que laisse entendre l'interview mais c'est possible qu'il y ai quelques erreurs (juste la mémoire qui fait défaut), ça aurait effectivement plus de sens que le design d'origine utilisait simplement de la SRAM.

par upsilandre Dim 30 Aoû 2020 - 18:05

TotOOntHeMooN a écrit:Pour 64K, ça aurait été plus simple avec deux circuits SRAM de 32K. Aussi la DPRAM n'existant pas dans cette capacité (multiplexage du bus d'adresse), sinon ça aurait quand même bien simplifié les choses !

Oui évidement ca serait 2x32ko comme la PCE ou la SNES, (et tout comme pour la DPRAM de la MD) mais au final ca donne une SRAM 64Ko 16bit. Il existe pas de toute facon de SRAM 16bit a cette epoque je pense (ou de RAM 16bit tout court) quand tu voulait élargir le bus en général tu veux aussi plus de capacité du coup ca se fait en multipliant les chips (et du coup les chip reste compatible aussi avec les petit bus). Les chip 16bit c'est venu plus tard (actuellement la toute dernière GDDR6 de la PS5/XSX par exemple c'est seulement 32bit et pourtant c'est de la RAM graphique. La DDR4 des PC ca doit etre du 16bit)

Je n'ai pas vu de référence équivalente chez TI, ni ailleurs. Et aucune Mega Drive et équipée de circuit provenant de TI, pour justifier un partenariat historique qui aurait fait choisir ce type de mémoire.

Quand je parle de partenaire historique je parle de la relation précédente de Sega avec TI puisque les précédentes console de Sega sont intimement lié a la techno TI. Il peut y avoir une relation a la Nintendo-Sharp et donc une influence direct ou indirect.

Oui, c'est effectivement cela. Il souhaitait une mémoire plus performante et c'est vu présenter cette data sheet concernant la Dual-Port. Mais par habitude de travailler avec TI, je pense que sa "mémoire" lui a joué des tours et qu'il parle plutôt de ça : https://datasheetspdf.com/pdf-file/545214/NECElectronics/UPD41264/1

Je ne vais pas remettre en cause les propos de l’ingénieur qui a bosser sur la VRAM de la megadrive sinon effectivement on a pas fini, deja qu'on a pas beaucoup d'information.
Et dans les premières série c'est meme pas la mémoire de NEC mais la dual port d'Hitachi
https://pdf1.alldatasheet.com/datasheet-pdf/view/122826/HITACHI/HM53461ZP-12.html
Puis y a eu celle de Samung
http://www.datasheetcatalog.com/datasheets_pdf/K/M/4/2/KM424C64Z.shtml
et meme Fujitsu
https://datasheetspdf.com/pdf/500355/Fujitsu/MB81461/1

Donc effectivement tout le monde produit des clones de DPRAM. Pourquoi TI aurait contacté Sega a ce sujet, je ne sais pas, ils ont plein de brevet autour de ce type de techno.
https://patents.google.com/patent/US4562435A/en
https://patents.google.com/patent/US4688197A/en
https://patents.google.com/patent/US4347587A/en
https://patents.google.com/patent/US5587962A/en
https://patents.google.com/patent/US5093807A/en
https://patents.google.com/patent/US4891795A/en
https://patents.google.com/patent/US4667313A/en

Et de son coté wiki fait référence a un patent d'IBM (qui lui meme fait référence a des patent de TI)
https://patents.google.com/patent/US4541075

Je vais expliqué plus précisément pourquoi je dis qu'utiliser cette DPRAM dans une MD ca ressemble vraiment a un mauvais usage de la dual-port.
La fonction de cette DPRAM c'est de servir de framebuffer. Si on reste strictement sur la configuration VRAM MD on se retrouverait avec un framebuffer de 64Ko avec des acces 8bit. La force de cette dual-port c'est que le DAC est alors connecté au serial port ce qui implique qu'en un seul acces a la DRAM c'est 2048bit qui sont lu en un seul cycle et chargé dans un gros shift register interne. Donc en imaginant que ce soit un framebufer 8bpp et 256x240 ca veut dire que le DAC ne va solliciter la DRAM qu'un seul cycle par scanline car t'as 256 pixels qui se charge dans le registre interne et qui sont ensuite librement accessible par le DAC en passant par le serial port et qui laisse libre la DRAM pour le second port (random) qui te permet donc d'avoir un full acces a la VRAM (écriture, lecture) comme si le DAC n'avait aucun impact sur la DRAM (moins de 1%, le DAC sollicite la DRAM une fois tout les 340 pixels si on compte le Hblank) alors que c'etait lui a l'époque qui bouffait le plus de ressource VRAM. Donc dans cette situation de framebuffer le Dual-port c'est vraiment génial.

Mais ca c'est parce que un framebuffer c'est des données séquentiel, pas random. Dans une machine au raster comme la MD tu peux pas exploiter ce buffer de 2048bit, au mieux tu peux en exploiter que 32bit sur 2048bit car les tiles sont des données random (et pour ca il a fallu en plus regrouper les attributs de tile par 2, heureusement ca passe meme si ca limite les colonnes de Vscroll). Donc en faisant descendre la granularité de 2048bit a 32bit on se retrouve dans une situation ou la fonction dual-port est perdu (tu peux pas exploiter les 2 port simultané car le port random qui sert aussi de port d'adresse multiplexé est complètement bouffé par les sollicitation du port serial qui ont une cadence bien trop élevé puisque le buffer 2048bit est quasiment pas exploité. Les seules moments ou on peut acceder a la VRAM sur MD pendant l'affichage c'est juste quand le VDP laisse des slot libre mais c'est pas du dual).
Tout l'interet du dual-port est perdu. Tout ce qu'il reste c'est que ca fait une sorte de DRAM 32bit sur un petit bus (avec un controleur mémoire un peu compliqué je pense, car ces 32bit sont multiplexé ensuite en 8bit a haute fréquence). Cette granularité 32bit c'est vraiment l'usage minimum qu'on peut faire de cette DPRAM et c'est deja très discutable (et en dessous de 32bit ca n'aurait plus de sens. Pas exemple sur NES ou meme la SNES pour le mode 7 il te faut une granularité 8bit)
Et la Dual-port c'etait forcement une RAM plus coûteuse que de la DRAM, c'est clairement plus complexe qu'une DRAM et surtout y a une vrai plus-value pour du framebuffer donc ils ont pas du s'en priver du coup car c'est la panacé pour les framebuffers mais cette plus-value est douteuse pour la MD et je suis vraiment sceptique par rapport a 64Ko de SRAM qui dans ce contexte aurait permis d'avoir la meme bande passante en lecture tout en doublant l’écriture, simplifiant le controleur RAM et en ayant une granularité plus fine (ce qui peut servir).

par upsilandre Dim 30 Aoû 2020 - 18:29

Stef a écrit:
En fait tu as peut être raison, honnêtement je n'ai plus les chiffres en tête mais moi il me semblait qu'avec de la simple SRAM 2x8 bit ça ne passe pas en terme de débit sur la lecture des données.

Tu me dis ca a chaque fois mais va bien falloir ressortir la calculatrice un jour Very Happy

C'est simple pour la lecture sur MD ca demande simplement une SRAM 16bit qui supporte du 6.71mhz (un accès tous les 150ns), y a pas de calcule compliqué, c'est l'equivalent des 13.4mhz du port serial 8bit de la DPRAM. La VRAM de la PCE supporte sans broncher les 7.16mhz sur sa SRAM (notamment dans le Hblank quand faut charger les sprite full speed) alors qu'ils auraient bien pu s'en passer donc ca n'a pas l'aire d'avoir été une grosse contrainte sur les coûts de monter jusque la (meme si j'imagine que la VRAM de la PCE c'est quand meme un gros morceau pour 87).

Il faut pas oublier non plus le mapping linéaire de la VRAM de la MD qui est un avantage énorme comparé aux autres machines et qu'on ne veut pas perdre.

A priori ca devrait pas poser de probleme. En fait je pense que c'est plutot l'inverse. C'est plutot cette granularité 32bit qui laisse moins de choix sur MD sur les formats de bitplan plus fin en granularité et a probablement poussé vers ce format. En réduisant la granularité VRAM avec de la SRAM 16bit tu offre juste plus de possibilité, qui peut le plus peut le moins, le mapping linéaire est toujours possible si souhaité.

par **TotOOntHeMooN** Dim 30 Aoû 2020 - 19:08

Je suis septique sur le fait que la MD ait pu utiliser de la DRAM au départ, car cela voulait aussi dire 32K ou 128K en 16-bit, comme pour la DPRAM. Hors, ça va à l'encontre d'une console prévu à l'origine avec 64K de VRAM.

par upsilandre Dim 30 Aoû 2020 - 19:11

TotOOntHeMooN a écrit:Je suis septique sur le fait que la MD ait pu utiliser de la DRAM au départ, car cela voulait aussi dire 32K ou 128K en 16-bit, comme pour la DPRAM. Hors, ça va à l'encontre d'une console prévu à l'origine avec 64K de VRAM.

J'ai pas compris What a Face

.

par Nikeleos Dim 30 Aoû 2020 - 19:54

Plus haut, vous avez parlé capacité d’évolution. J’ai bien compris que c’était impossible vis à vis des palettes de couleurs mais le SVP a bien montré qu’on pouvait booster les perfs d’une autre manière. J’ai toujours pensé que SEGA aurait dû découpler le SVP de la cartouche. Ils auraient vendu ça comme une vrai extension financièrement accessible par le consommateur et potentiellement plus puissante que le SVP qu’on a connu. Est-ce que s’eu été possible de produire un SVP enfichable sur le port d’extension plutôt que par l’intermédiaire du port cartouche ?

par **TotOOntHeMooN** Dim 30 Aoû 2020 - 20:09

@upsilandre : Désolé, j'ai lu et répondu rapidement entre deux trajets sur le fait que si 64K en 16-bit était prévu au départ pour la VRAM de la Mega Drive (comme indiqué dans interview), alors par déduction, cela ne peut-être que de la SRAM car cette configuration mémoire n'est pas possible avec des circuits DRAM/DPRAM.

DRAM:
256B x4bit
1K x4bit
4K x4bit
16K x4bit
64K x4bit

SRAM:
- 8K x8bit
- 32K x8bit
- 128K x8bit
- 512K x8bit

par upsilandre Dim 30 Aoû 2020 - 21:04

Ok je vois. Enfin je vois pas du tout a quel passage d'interview tu fait référence par contre Very Happy

Moi mon scénario (si on exclu donc TI) c'est effectivement au départ de la SRAM puisque c'est la VRAM par défaut quand y a besoin d'un peu de bandwidth, que ce soit dans une NES, une PCE, une SNES ou une Neogeo. Puis Sato tombe sur l'existence de cette nouvelle RAM dédié a la vidéo (la DPRAM qui est en quelque sorte la première véritable VRAM donc ca doit piquer la curiosité) donc il suppose que ca peut etre bien utile pour une console et donc une belle opportunité en terme de timing et donne ca a Masami.
Je pense que Masami voit rapidement que c'est une RAM destiné a du framebuffer et donc pas a une console mais on lui demande de bosser dessus donc il se creuse la tete. Il arrive a faire monter la granularité a 32bit (mode chunky, tile en binome...) et meme si ca permet toujours pas d'utiliser la fonction "dual" de cette VRAM bah ca permet quand meme d'avoir une sorte de DRAM 32bit (c'est la largeur de bus qu'il faudrait pour avoir le bandwidth nécessaire en DRAM) sur un bus 8bit.
Et meme si l'écriture est 4 fois plus lente que la lecture on peut se dire qu'a l'époque la MD n'est pas encore 16bit et que donc ce bus 8bit et ce bandwidth faible en écriture est compatible avec les besoins. Et si en plus cette PDRAM est moins chère que de la SRAM (pas certain) alors banco. Dans tout les cas ca fonctionne en terme de bandwidth dans cette configuration et ca lui évite d'avoir a rembarrer son boss en lui disant que son idée elle tiens pas, voir meme de montrer qu'il relève tout les défi.
Puis BAM arrive le 68000. La du coup ca fou le bordel car cette DPRAM devient problématique dans ce contexte car son faible bandwidth en écriture (puisque ca reste de la DRAM) devient un sérieux handicape (en plus de deja pas pouvoir exploiter le dual). Plutot que de jeter tout le boulot qu'il avait accomplis pour intégrer cette RAM et se désavouer face au boss il commence a bosser sur une implémentation en 128Ko pour que ca redeviennent plus cohérent et exploiter la nouvelle architecture 16bit de la MD. Il tente du coup d'imposer les 128ko a Sato qui finit par refuser car trop coûteux et dispensable et du coup il se retrouve avec un truc bancale. Et qui devient peut etre alors de sa responsabilité en ayant cherché cette solution alternative du 128Ko plutot que de reculer sur la SRAM, il s'est peut etre enfermé dans une impasse et ensuite c'est trop tard et encore plus difficile a admettre.
Je me dis que si Sato n'etait pas tomber sur ce Data sheet de DPRAM, ou 6 mois plus tard, alors forcement on aurait eu 64Ko de SRAM comme dans les autres consoles (PCE, SNES, NeoGeo) et au final on aurait eu ce putain de DMA a 420 octets/scanline (et pas 410 car on gagne aussi les reresh ce qui fait 10 octets en bonus) contre 165 sur SNES!
Fin de ma fiction Very Happy

par **TotOOntHeMooN** Dim 30 Aoû 2020 - 21:15

Nikeleos a écrit:J’ai toujours pensé que SEGA aurait dû découpler le SVP de la cartouche. Ils auraient vendu ça comme une vrai extension financièrement accessible par le consommateur et potentiellement plus puissante que le SVP qu’on a connu. Est-ce que s’eu été possible de produire un SVP enfichable sur le port d’extension plutôt que par l’intermédiaire du port cartouche ?

Ironiquement, le port d'extension est moins riche en signaux que le port cartouche de la Mega Drive. Aussi, il semblerait que HSync soit câblé sur la cartouche de Virtua Racing, hors ce signal n'est pas présent sur le port d'extension.

par **TotOOntHeMooN** Dim 30 Aoû 2020 - 21:19

upsilandre a écrit:Ok je vois. Enfin je vois pas du tout a quel passage d'interview tu fait référence par contre

Je faisais suite à la remarque de Stef qui disait : "Par contre, y'a une chose qui est certaine, c'est que lorsque tu regardes le design du VDP de la MD et aussi avec l'interview de designer, on voit bien que la config initiale c'était de la VRAM avec des écritures 16 bit et 64 Ko".

Encore désolé, je lirai demain tes posts détaillés car là c'est chaud avec ma connexion.

par Stef Dim 30 Aoû 2020 - 21:49

upsilandre a écrit:Ok je vois. Enfin je vois pas du tout a quel passage d'interview tu fait référence par contre

Moi mon scénario (si on exclu donc TI) c'est effectivement au départ de la SRAM puisque c'est la VRAM par défaut quand y a besoin d'un peu de bandwidth, que ce soit dans une NES, une PCE, une SNES ou une Neogeo. Puis Sato tombe sur l'existence de cette nouvelle RAM dédié a la vidéo (la DPRAM qui est en quelque sorte la première véritable VRAM donc ca doit piquer la curiosité) donc il suppose que ca peut etre bien utile pour une console et donc une belle opportunité en terme de timing et donne ca a Masami.
Je pense que Masami voit rapidement que c'est une RAM destiné a du framebuffer et donc pas a une console mais on lui demande de bosser dessus donc il se creuse la tete. Il arrive a faire monter la granularité a 32bit (mode chunky, tile en binome...) et meme si ca permet toujours pas d'utiliser la fonction "dual" de cette VRAM bah ca permet quand meme d'avoir une sorte de DRAM 32bit (c'est la largeur de bus qu'il faudrait pour avoir le bandwidth nécessaire en DRAM) sur un bus 8bit.
Et meme si l'écriture est 4 fois plus lente que la lecture on peut se dire qu'a l'époque la MD n'est pas encore 16bit et que donc ce bus 8bit et ce bandwidth faible en écriture est compatible avec les besoins. Et si en plus cette PDRAM est moins chère que de la SRAM (pas certain) alors banco. Dans tout les cas ca fonctionne en terme de bandwidth dans cette configuration et ca lui évite d'avoir a rembarrer son boss en lui disant que son idée elle tiens pas, voir meme de montrer qu'il relève tout les défi.
Puis BAM arrive le 68000. La du coup ca fou le bordel car cette DPRAM devient problématique dans ce contexte car son faible bandwidth en écriture (puisque ca reste de la DRAM) devient un sérieux handicape (en plus de deja pas pouvoir exploiter le dual). Plutot que de jeter tout le boulot qu'il avait accomplis pour intégrer cette RAM et se désavouer face au boss il commence a bosser sur une implémentation en 128Ko pour que ca redeviennent plus cohérent et exploiter la nouvelle architecture 16bit de la MD. Il tente du coup d'imposer les 128ko a Sato qui finit par refuser car trop coûteux et dispensable et du coup il se retrouve avec un truc bancale. Et qui devient peut etre alors de sa responsabilité en ayant cherché cette solution alternative du 128Ko plutot que de reculer sur la SRAM, il s'est peut etre enfermé dans une impasse et ensuite c'est trop tard et encore plus difficile a admettre.
Je me dis que si Sato n'etait pas tomber sur ce Data sheet de DPRAM, ou 6 mois plus tard, alors forcement on aurait eu 64Ko de SRAM comme dans les autres consoles (PCE, SNES, NeoGeo) et au final on aurait eu ce putain de DMA a 420 octets/scanline (et pas 410 car on gagne aussi les reresh ce qui fait 10 octets en bonus) contre 165 sur SNES!
Fin de ma fiction

Pour les chiffres je te fais confiance, car effectivement ça reste toujours une utilisation en 32 bits sur le VDP de la MD, s'il y avait certain slot en utilisation 64 bit, ça aurait déjà été bien plus rentable mais on voit bien sur le diagramme des accès du VDP MD que chaque accés VRAM est considéré comme un accés 32 bits à un débit 2 fois plus faible (tous les 2 pixels). Mais du coup on se dit que ça n'a pas de sens de partir sur cette DPRAM *sauf* si effectivement il y avait un avantage de cout par rapport à la SRAM (ce que je pensais aussi mais ce n'est même pas certain d'après ce que tu dis). Sinon ta théorie / fiction est interessante mais en tout cas clairement dans l'interview Masami ne dit pas ça, il dit que c'est son boss qu'il lui a demandé de voir si c'était possible d'augmenter la capacité de la VRAM à 128K et qu'il avait du pas mal re-designer la logique à cause de ça (genre c'était dommage)... mais peut être qu'en réalité c'était effectivement aussi pour des raisons techniques (dont le fameux 68000 qui est effectivement arrivé assez tard sur le design de la machine). Malgré tout il dit un moment qu'ils ont laissé tombé la configuration 128 Ko de VRAM car ça n'améliorait pas significativement les performances de la machine par rapport au surcout (alors qu'en réalité si, ça augmente énormément les perfs, mais c'est vrai que le mode 128Ko est moins facilement exploitable que le mode 64Ko).
En fait ce qui est possible, c'est que ce soit Sato qui ai effectivement poussé pour l'utilisation de la PSRAM (pour des histoires de coût ?) à un moment ou l'architecture de la machine n'était pas encore totalement finalisé (sur le CPU) alors que le design d'origine du VDP était bien à base de SRAM .. Et qu'il ai ensuite poussé pour le passage à 128 KB de VRAM quand ils ont decidé de passer au 68000 pour le CPU central car Sato lui-même étant ingénieur il devait savoir que l'utilisation de la PSRAM en config 64Ko n'était pas idéal (ou Masami lui avait dit). Et au final devant le surcout intenable ils sont revenus à 64Ko de VRAM la mort dans l'âme (et un peu à la barbare car il était trop tard pour faire ça proprement)...

En tout cas, si le design d'origine était effectivement à base de SRAM (et que c'était réaliste en terme de cout) alors c'est vraiment dommage car effectivement avec une VRAM de 64Ko / 16 bit la Megadrive aurait été non seulement plus performante mais en plus le VDP en aurait été tellement plus clean (car là on sent que la VRAM 8 bit est un peu bancale, surtout sur la fonction DMA VRAM fill).

par upsilandre Dim 30 Aoû 2020 - 22:33

Oui de toute facon le scénario a 128ko d'ou qu'il vienne c'etait certain qu'il passerait pas la validation final. Faut se remettre dans le contexte. C'est une époque ou les cartouche font 512Ko. Dans ce contexte pourquoi tu exploserais le cout de ta console pour avoir 128Ko de VRAM avec un usage plus complexe. Et puis ok tu double le DMA mais pour quoi faire quand tes cartouches font 512Ko et que tu te retrouve justement avec 128Ko de VRAM? Ca ne semble plus très utile dans ce contexte, doubler le DMA ca parait bien plus utile en 64Ko.

Ce move a 128Ko ca ressemble a un paliatif pour essayer de donner plus de sens a cette DPRAM une fois le 68000 ajouté mais c'était peine perdu. Au final ils se sont sans doute dit que tanpis ce DMA bridé ca sera suffisant, ca changera pas grand chose aux perf dans le contexte d'époque mais apres coup on sait que si, ca aurait été une excellente chose d'avoir ce DMA 16bit (et donc plutot dans une configuration 64Ko SRAM) car aujourd'hui on sait que la MD sera sur la scene pendant au moins 7 ans, qu'il y aura des cartouches de 32Mbit, qu'il y aura le MCD, des procs dans les cartouches et des techniques de gestion dynamique de la VRAM de plus en plus avancé (comme celle utilisé dans Sonic 3D blast qui fait un scrolling en s'affranchissant du tileset VRAM pour avoir un tileset virtuel qui fait la taille de la cartouche https://youtu.be/ZPoz_Jgmh-M avec un DMA a 420 octets/scanline tu peux en faire des délires comme ca couplé a des grosses animations de sprite)

Donc apres coup c'est facile forcement de voir que doubler le DMA ca aurait été un très bon move (et la SRAM si c'est un bus plus gros ca doit quand meme simplifier le controleur RAM, plus de dual port, plus de multiplexage, plus de refresh, c'est très basique une SRAM avec en plus un bus 16bit directement mirroir a l'architecture de la MD) mais a l'époque c'est sur que ca semblait etre peu important. Pas suffisant pour justifier de revoir tout le design au dernier moment et revenir a de la SRAM pour mieux accompagner le 68000.
On peut juste espérer qu'au moins elle était moins coûteuse cette RAM sinon c'est vraiment frustrant .

par Stef Lun 31 Aoû 2020 - 8:05

Même si quand la MD sort on est sur des cartouches à 512 Ko, ils savent que la capacité va augmenter avec le temps (ils ont tout de même l'expérience SG-1000 / SG-3000 / SMS) mais c'est vrai que leurs précédentes machines avaient une durée de vie assez courte. Cela dit, c'est justement dans le but de doubler Nintendo qu'ils décident de dégainer une machine 16 bit en premier donc ils ont du prévoir que celle-ci devait tenir un minimum dans le temps.

Sinon je reste quand même persuadé qu'il y avait un avantage de cout à utiliser le DPRAM par rapport à de la SRAM sinon ça n'avait vraiment aucun sens de partir dessus en complexifiant le design du VDP. Après coup, on se demande si ça n'a pas été une erreur (avec le 68000 et l'architecture full 16 bit) mais pour eux ça devait être effectivement trop tard pour revenir au design initial... dommage.

Ce qui est assez étonnant aussi c'est que la SNES utilise une SRAM pas plus rapide (et même plus lente ?!) que celle de la PCE pour sa mémoire vidéo qui reste à 64 Ko alors qu'elle sort 3 ans après. On se dit qu'elle sort avec des specs bien "dépassées" quelque part (bien sûr elle apporte de la modernité sur le son, le nombre de couleurs et les effets hardware mais je parle en terme de performance).

par **TotOOntHeMooN** Lun 31 Aoû 2020 - 9:00

Stef a écrit:Malgré tout il dit un moment qu'ils ont laissé tombé la configuration 128 Ko de VRAM car ça n'améliorait pas significativement les performances de la machine par rapport au surcout (alors qu'en réalité si, ça augmente énormément les perfs, mais c'est vrai que le mode 128Ko est moins facilement exploitable que le mode 64Ko).

J'avais aussi tiqué sur ça lors de la lecture. Pour moi, il y a des incohérences et il est possible que des coupes dans l'interview (classique), des simplifications dans la traduction ou l'ordre des phrases en soit la cause. Je veux par exemple bien entendre que les performances en 128K (DPRAM) n'apportait pas grand chose par rapport a 64K (SRAM), hormis plus de tiles.

Aussi, pourquoi dire que le passage à 128K serait lié aux rumeurs du projet SNES pour améliorer considérablement les performances, si ce n'est d'être déjà avec de la DPRAM en 64K 8-bit ? Aussi, on-t-il eu vent du "retard" de la SNES (2 ans) pour se dire que finalement 64K en 8-bit c'était moins couteux et ça ferait bien l'affaire ?

par Invité Lun 31 Aoû 2020 - 10:27

Ce qui est assez étonnant aussi c'est que la SNES utilise une SRAM pas plus rapide (et même plus lente ?!) que celle de la PCE pour sa mémoire vidéo qui reste à 64 Ko alors qu'elle sort 3 ans après.

La snes c'est de la 100/120ns sur PCE c'est de la 140 .
Faut savoir que le mode 512 pixels en 10.74 de dotclock requiert de la mémoire à 93ns si 1 accès/cycle .

Le jeu SGX semblait aussi mal exploiter son 2eme plan (ralentissement lors de rapaces sur l'arbre du premier level aurait pu etre évité)

Ce ne sont pas des ralentissements mais des clignotements, qui s'expliquent en grande partie du fait que les devs ont utilisés les accès mémoire en 1 accès/2 cycles au lieu du classique 1 accès/cycle pour cette résolution, ce qui fait que tu perds 2 sprites/ligne sur chaque VDC .

par upsilandre Lun 31 Aoû 2020 - 10:36

Moi j'ai aussi 100/120ns pour la PCE (100 pour la WRAM et 120 pour la VRAM)
Je sais meme pas si ca existe de la SRAM 140ns a cette epoque? Je crois que meme dans les MD on avait trouvé de la SRAM 100ns pour le Z80 (de ce que je me souviens quand on avait regardé)

par **TotOOntHeMooN** Lun 31 Aoû 2020 - 10:44

Alors, il y a peut-être confusion là... Car le Z80 de la MD n'utilise pas de la SRAM mais de la PSRAM (DRAM avec refresh intégré dans un package type SRAM)

par Invité Lun 31 Aoû 2020 - 10:52

Je crois que meme dans les MD on avait trouvé de la SRAM 100ns pour le Z80 (de ce que je me souviens quand on avait regardé)

Oui, c'est ce qui ressort de la RAM du Z80 trouvée sur les CM, je pense que c'est surement du au fait que les modules 8ko ne valaient plus rien en 87/88, parce que de la mémoire aussi rapide pour le Z80 à 3.5 mhz c'est complètement inutile .

Je sais meme pas si ca existe de la SRAM 140ns a cette epoque?

Faut croire que si puisque des CM semblent en avoir .

Alors, il y a peut-être confusion là... Car le Z80 de la MD n'utilise pas de la SRAM mais de la PSRAM (DRAM avec refresh intégré dans un package type SRAM)

Non bcp de révisions(surtout les premières) de CM Md utilisent de la SRAM 100ns,après ça variait en fonction surement du prix et des dispos.
https://segaretro.org/Sega_Mega_Drive/Hardware_revisions

par upsilandre Lun 31 Aoû 2020 - 10:59

TotOOntHeMooN a écrit:Alors, il y a peut-être confusion là... Car le Z80 de la MD n'utilise pas de la SRAM mais de la PSRAM (DRAM avec refresh intégré dans un package type SRAM)

Le tout premier model de Megadrive y a ca pour le Z80. De la SRAM 100ns de Toshiba
https://datasheetspdf.com/pdf/1091843/Toshiba/TMM2063P-10/1

Dans d'autre model on trouve aussi cette SRAM 100ns de Samsung
https://datasheetspdf.com/pdf/1091843/Toshiba/TMM2063P-10/1

Mais t'as aussi de la XRAM de NEC (intermédiaire entre DRAM et PSRAM)

La PSRAM c'est surtout du coté de la partie audio de la SNES.

par Invité Lun 31 Aoû 2020 - 11:02

Ouai c'est le bordel au niveau RAM sur le Z80 de la MD,remarques la PSRAM de la WRAM a aussi variée au fil des révision avec de la 150 au début, et de la 120 et 100 ensuite .

par upsilandre Lun 31 Aoû 2020 - 11:09

Touko a écrit:
Faut croire que si puisque des CM semblent en avoir .

Une source pour les PCE avec VRAM 140ns? parce que tout ce que je trouve contredit ca.
Dans les documentations ils affirment meme que c'est de la 100ns
http://archaicpixels.com/HuC6270

Moi je suis sympa je dis 120ns car quand j'avais cherché j'avais du trouvé sans doute du 120ns dans les premiers models (et 100ns pour la WRAM). 140ns je n'y crois pas.

par Invité Lun 31 Aoû 2020 - 11:12

Une source pour les PCE avec VRAM 140ns?

Je vais pas te mentir, perso j'en suis même pas sur, j'avais lu ça sur un site dev pcengine,moi je suis comme toi j'ai toujours vu les valeurs que tu cites .
Mais je pense que les 140 ont existé, car nec conseillait de passer en 1 accès/2cycles à partir du 7.16 mhz ,hors on est à 140ns dans cette config, soit aux limites(et nec semblait avoir peur des risques de soucis), cela n'aurait pas de sens avec de la 120 .

par **TotOOntHeMooN** Lun 31 Aoû 2020 - 11:14

OK. Sur le schéma de la Mega Drive, il y a la pin-1 qui correspond à un refresh de la mémoire. Mais effectivement, s'ils ont sourcé de la SRAM, pas de raison c'est le même brochage. (le 68000 est apparemment toujours en PSRAM)

Je me disais juste que peut-être à la base c'était de la PSRAM connecté aussi au VDP... Cela pourrait expliquer la recherche de meilleurs performances avec la DPRAM.

par upsilandre Lun 31 Aoû 2020 - 11:33

Touko a écrit:
Une source pour les PCE avec VRAM 140ns?
Je vais pas te mentir, perso j'en suis même pas sur, j'avais lu ça sur un site dev pcengine,moi je suis comme toi j'ai toujours vu les valeurs que tu cites .
Mais je pense que les 140 ont existé, car nec conseillait de passer en 1 accès/2cycles à partir du 7.16 mhz ,hors on est à 140ns dans cette config, soit aux limites(et nec semblait avoir peur des risques de soucis), cela n'aurait pas de sens avec de la 120 .

Vraiment je pense que non, les 140 n'existe pas sur PCE, on avait deja bien cherché.
Et ces déductions sur "ce qu'il serait logique pour tel ou tel timing" on a deja eu l'occasion de constater mille exemple contradictoire. On a pas les compétence pour ca. Vaut mieux eviter ce genre de déduction pour deviner ce qu'il y avait et plutot regarder réellement les PCB (sur lesquels on ne trouve pas de 140ns jusqu'a preuve du contraire).

Ensuite les modification de timing ca ne concerne pas le chargement des sprites pendant le Hblank qui reste full speed meme en 7.16mhz donc quoiqu'ils arrivent faut que la SRAM supporte les 7.16mhz (et en plus il me semble qu'on a deja constaté que de toute facon les jeux 7.16mhz restait full speed meme en dehors du Hblank et n'utilisait pas ces modes dégradés).