Re: Megadrive et Super Nintendo : parlons technique !

[Zarnal]

J'ai une question technique : la vitesse (en Mhz) et les timings pour un processeur ce sont 2 facteurs différents ou bien l'un est-il lié à l'autre ?

[Tryphon]

Chaque instruction d'un processeur prend un certain nombre de cycles : c'est le timing.

Le nombre de cycles par secondes, c'est la fréquence.

Par exemple, tous les 68000 ont leurs instructions avec le même timing, mais on trouve des 68000 à des fréquences différentes (par exemple, celui de la NeoGeo est un poil plus rapide que celui de la MD).

[Invité]

Pour ma part quand je parle de timing , c'est plus pour les I/O.

Exécuter au cycle près sur ces processeurs c'est pas bien complexe , les instructions en un taux de cycle assez fixe (et d’après mes test le taux de cycle pour les instructions est assez bien respecter pour les émulateurs SNES ou ZNES par exemple).

[Zarnal]

Chaque instruction d'un processeur prend un certain nombre de cycles : c'est le timing.

Le nombre de cycles par secondes, c'est la fréquence.

Par exemple, tous les 68000 ont leurs instructions avec le même timing, mais on trouve des 68000 à des fréquences différentes (par exemple, celui de la NeoGeo est un poil plus rapide que celui de la MD).

Merci.

[Invité]

J'ai trouvé ça sur snesdev:

I've also found some info about why the 65c816 might not have been clocked faster than ~3.58MHz: "REP and SEP had timing problems, possibly due to layout (rather than, say, logical design, or a pipelining mistake)". They "take 250ns to operate so you have to put a NOP after each one OR you have to stretch the clock [...] WDC has admitted that this is caused by very long signal lines".

250ns would be 4MHz; using 5 instead of 6 master clock cycles in the SNES would increase the CPU speed to 4.29{54}MHz.

"apparently another usenet post 'claims WDC fixed the REP/SEP timing issues in 1992'". I don't know when WDC switched to 14MHz - but the first games with the SA1 (10.74MHz) hit the shelves in 1995.

http://forum.6502.org/viewtopic.php?f=4&t=5196

[Tryphon]

Ça explique pourquoi le 65816 de la SNES est lent ?

Ça tourne à combien au max un 65816 ?

[Invité]

Ça explique pourquoi le 65816 de la SNES est lent ?

Ça tourne à combien au max un 65816 ?

Aujourd'hui ?? (car le CPU est tjrs en prod)

[Tryphon]

Oui

[Invité]

18 mhz c'est sur (en 1995), mais sur 6502.org ils parlaient dans un topic de 200 mhz aujourd'hui, mais je peux pas confirmer l'info,ni si c'est du fpga ou pas .

[upsilandre]

Avant de se demander comment augmenter la fréquence du CPU il aurait deja fallu trouver un moyen de supporter au moins la fréquence actuel de 3.6mhz du coté des mémoires ou du DMA ce qui est loin d'etre le cas donc au final peu importe les contraintes imposé sur la fréquence CPU, elle était déjà trop élevé pour le system apparemment donc ca aurait pas été tres utile de l'augmenter.

[Invité]

Pourtant celui de la PC-Engine fait du 7 Mhz !

@Tryphon
La lenteur est relative , comparé à un M68000 à 8 Mhz c'est certes plus lent , mais la dif est pas énorme non plus.

[Invité]

Il semble que c'est justement le bug de ces 2 instructions qui ont limité la montée en fréquence du CPU,et rien empêchait de mettre des WS sur les accès RAM/ROM .

il semble bien qu'il y ait une couille dans le design du CPU(qui semble avoir été fixé en 92):

The project I am building now will require wait states on the DRAM, not because the DRAM is too slow, but because the WDC chip's timing margins are very bad. (For a 4 mhz WDC chip you need 8 mhz'able parts, and WDC's timing margins are forcing me to (a) make my timing generator a lot more complex or (b) add a wait state. I decided to make the best of it and perform a hidden refresh during the wait state.)

Ce qui peut facilement expliquer pk le 2Gs et la snes ont un CPU à la même fréquence,alors que le 2GS était à la base sensé avoir un CPU à 8mhz .

AE released the TransWarp GS in the winter of 1988. The board came stock at 7MHz and 8k cache. They also offered an upgraded board to 8MHz and 32k cache board. The limiting factor to speed at the time was the "buggy" 816 CPU die. Later Western Design Center (WDC) worked with Sanyo to redesign the die, and the CPU speeds easily reached 10MHz. By this time however AE was out of business.

https://wiki.reactivemicro.com/TransWarp_GS

Edit: Tryphon, celui du super CPU tournait à 20mhz en 96 avec extension de RAM en DRAM 70ns .

[Stef]

Comme le dit Upsilandre, le problème dans le cas de la SNES ce n'est pas la fréquence du CPU c'est surtout que ce qu'il y a autour ne peut pas suivre.

@Kannagi> Oui mais à quel prix ? Déjà il y a un MMU pour moins stresser la mémoire autour (qui entraine un cycle de pénalité à chaque accés mémoire) mais en plus cela a nécessité pour y arriver de la mémoire assez rapide (et donc couteuse), avec l'impact que ça a pu avoir sur la taille / cout des HuCard et la faible quantité de mémoire RAM de la machine.

[Invité]

Comme le dit Upsilandre, le problème dans le cas de la SNES ce n'est pas la fréquence du CPU c'est surtout que ce qu'il y a autour ne peut pas suivre.

Comme dit plus haut tu peux au pire mettre des WS, ou il y avait la solution d'hudson,tu doubles la fréquence, sans rien changer.
D'ailleurs le SA-1, n'utilise pas de la ROM à 20mhz, et heureusement je dirai .

Déjà il y a un MMU pour moins stresser la mémoire autour (qui entraine un cycle de pénalité à chaque accés mémoire)

Et alors ??, vaut mieux pas 1 cycle @7,16 qu'un CPU @3,5 sans ??,ça fait une perte de 15% pour 100% de fréquence en plus .

avec l'impact que ça a pu avoir sur la taille

La taille des hucard est liée au format même des Hucard, non à cause des ROMS .

cout des HuCard et la faible quantité de mémoire RAM de la machine.

Ce qui est chiant,c'est que tu t'obstines tjrs avec ça, alors qu'on en a discuter des 10 aines de fois, c'est chiant à la fin .
La RAM a tjrs été prévue pour être de 8ko, la seule chose qui était prévue dès le départ et coupée pour des raisons de coût est la VRAM, donc je vois pas en quoi rajouter 64ko de SRAM 100ns était moins coûteux que de la SRAM @120 .

[Stef]

Comme le dit Upsilandre, le problème dans le cas de la SNES ce n'est pas la fréquence du CPU c'est surtout que ce qu'il y a autour ne peut pas suivre.

Comme dit plus haut tu peux au pire mettre des WS, ou il y avait la solution d'hudson,tu doubles la fréquence, sans rien changer.
D'ailleurs le SA-1, n'utilise pas de la ROM à 20mhz, et heureusement je dirai .

Déjà il y a un MMU pour moins stresser la mémoire autour (qui entraine un cycle de pénalité à chaque accés mémoire)

Et alors ??, vaut mieux pas 1 cycle @7,16 qu'un CPU @3,5 sans ??.

Bah oui mais sur SNES, d'une part même avec la "config" de la PCE tu ne peux pas monter à 7.16 Mhz... et d'autre part 1 cycle de pénalité à chaque accès ça fait encore plus mal avec le 65816 (car forcément tu as beaucoup plus de lecture/écriture 16 bit).
Les 2 Ko de mémoire du SA-1 sont effectivement 4x plus rapide que la mémoire de la SNES (j'ai lu des histoires de BUS 16 bits aussi mais je ne trouve pas de détails dessus), ce qui permet au SA-1 de travailler à full speed depuis cette mémoire (et beaucoup plus lentement sinon). Vu la quantité et l'époque à laquelle le SA-1 est sortie, c'était économiquement possible.

[Invité]

et d'autre part 1 cycle de pénalité à chaque accès ça fait encore plus mal avec le 65816 (car forcément tu as beaucoup plus de lecture/écriture 16 bit).

Ah, bah tu vas nous expliquer ça alors,nous montrer qu'il vaut mieux rester à 2,68 que doubler la fréquence et avoir 50% (je vois large ) de pénalité dans les cas d'accès à la RAM en 16bits !!   
Parce que chez moi 2 accès 8 bits avec 1 cycle de pénalité, c'est pareil qu'un accès 16bits avec 2 cycles .

Les 2 Ko de mémoire du SA-1 sont effectivement 4x plus rapide que la mémoire de la SNES, ce qui permet au SA-1 de travailler à full speed depuis cette mémoire (et beaucoup plus lentement sinon). Vu la quantité et l'époque à laquelle le SA-1 est sortie, c'était économiquement possible.

Oui, sur la cache, mais en ROM ??
Tiens un mec à fait un prog de test pour connaitres les vitesses d'accès par le SA-1.


Donc comme tu peux le voir, on a un SA-1 @10Mhz avec une LoROM, même si bien sur les accès ne sont pas en full speed .

Je penses vraiment qu'avoir un CPU avec 2ko de cache, et moins de WRAM,ou toutes autres solutions, étaient largement faisables, mais c'est une évidence que nintendo n'était pas intéressé .

[Stef]

Ces chiffres montrent juste la manière dont les CPU se partagent les BUS, t'imagine bien que le SA-1 ne peut pas accéder la slow ROM à 10 Mhz en full speed (sans wait state), donc la fréquence ici n'est pas représentative de la vitesse de traitement...

[Invité]

Ces chiffres montrent juste la manière dont les CPU se partagent les BUS, t'imagine bien que le SA-1 ne peut pas accéder la slow ROM à 10 Mhz en full speed (sans wait state), donc la ici n'est pas représentative...

Tu as lu au moins ce que j'ai posté ??
Sinon tu aurais pu voir que j'ai jamais écris que le SA-1 accédait à la rom en full speed, c'est une évidence .
Donc il y a des WS, et avec une slowROM, donc des roms classiques,on pouvait donc mettre un CPU bien plus rapide, en gardant le hard de départ, et foutre des WS, les perfs auraient éclatées celles de la snes de base sans WS .
Et que peut être ce fameux bug a jouer dans le fait que le CPU est resté tel quel, ou nintendo s'en foutait car il savait qu'il pourrait ajouter des puces facilement au besoin .
C'est là où je veux en venir .

[Stef]

Ces chiffres montrent juste la manière dont les CPU se partagent les BUS, t'imagine bien que le SA-1 ne peut pas accéder la slow ROM à 10 Mhz en full speed (sans wait state), donc la ici n'est pas représentative...

Tu as lu au moins ce que j'ai posté ??
Sinon tu aurais pu voir que j'ai jamais écris que le SA-1 accédait à la rom en full speed, c'est une évidence .
Donc il y a des WS, et avec une slowROM, donc des roms classiques,on pouvait donc mettre un CPU bien plus rapide, en gardant le hard de départ, et foutre des WS, les perfs auraient éclatées celles de la snes de base sans WS .
Et que peut être ce fameux bug a jouer dans le fait que le CPU est resté tel quel, ou nintendo s'en foutait car il savait qu'il pourrait ajouter des puces facilement au besoin .
C'est là où je veux en venir .

Mais la gestion des wait states n'est pas "gratuite" non plus, ça complexifie le hardware.. franchement c'est facile de faire des hypothèses comme ça, avec des si on fait beaucoup de choses Et surtout le fameux CPU en question ne montait certainement pas à 10 Mhz quand la SNES a été désigné. déjà là on voit bien qu'ils ont tenté quelque chose puisque le CPU tourne à 3.58 Mhz alors que la mémoire centrale n'est qu'à 2.78 Mhz.
Ah puis aussi je ne pense pas qu'un CPU à 10 Mhz avec des WS aurait apporté un gain énorme en perf (c'est bien là le problème de ce CPU)...

[Invité]

Ah puis aussi je ne pense pas qu'un CPU à 10 Mhz avec des WS aurait apporté un gain énorme en perf (c'est bien là le problème de ce CPU)...

il suffit de voir les hacks de SMW qui utilisent un peu le SA-1(juste la partie CPU) pour voir que si, et de bcp même .

Sans SA-1:


Le même avec:

[Hpman]

Quelqu'un à déjà tenté, via émulation, une expérience de savant fou type snes equipée d'un 68k?

[Stef]

Ah puis aussi je ne pense pas qu'un CPU à 10 Mhz avec des WS aurait apporté un gain énorme en perf (c'est bien là le problème de ce CPU)...

il suffit de voir les hacks de SMW qui utilisent un peu le SA-1(juste la partie CPU) pour voir que si, et de bcp même .

Oui, en plaçant probablement du code dans la I-RAM su SA-1   Dans ce cas oui, c'est *beaucoup* plus performant...

[Invité]

Que la PCE à 8ko je trouve pas cela très problématique vu que la SNES à d'une certaine façon la même taille de mémoire , vu qu'on à que 8ko d’accès 'direct' sur le 65816 , les adresses sur 24 bits sont long en cycle et plus limité en instruction , du coup cela me sert de buffer (et il 'y en à pas mal vu que tout les transferts se font pendant le VBlank) + si on rajoute que le buffer sert pour décompresser les maps.
Bref ce qui y joue comme d'hab sur PCe c'est la faible taille de la ROM , le CD résout un peu ce souci là !

Apparemment même à cette époque le souci de la vitesse RAM est un problème lol
Pour la résolution du 65xxx cela reste trop tard et pas suffisant vu qu'il se font complètement dépassé (le M68 compris )par les processeur MIPS , SH de la gen suivant :p

Quelqu'un à déjà tenté, via émulation, une expérience de savant fou type snes equipée d'un 68k?

On te laisse faire ça !
(mais a part pour les débats sans importance comme cela ,j'en vois pas l’intérêt perso lol)

[Invité]

Quelqu'un à déjà tenté, via émulation, une expérience de savant fou type snes equipée d'un 68k?

Ca serrait marrant ça effectivement.

Que la PCE à 8ko je trouve pas cela très problématique

Non, ça devient gênant en fait si tu dois faire de la grosse décompression avant le début du level, ou garder une grosse map en RAM,au pire y'a la VRAM  .
Sinon la décompression peut être faite directement en VRAM vu que tu y as accès même pendant l'affichage.
Par contre les ROMS c'est clair que 1mo, c'est trop vite rempli .

[thetricker24]

Je parlais la derniere fois de la possibilité de porter/creer des manic shooter sur megadrive et on m'a parlé de omega blast.
Après l'avoir dosé hier soir et ce soir sur du vrai hardware puis l'avoir clear en normal et hard je suis tout bonnement subjugué ! C'est une veritable tuerie... level design, gameplay, visuels... etc.
Si quelqu'un créé un jour un jeu de ce type complet sur 5 niveau... le rêve

[Stef]

Que la PCE à 8ko je trouve pas cela très problématique vu que la SNES à d'une certaine façon la même taille de mémoire , vu qu'on à que 8ko d’accès 'direct' sur le 65816 , les adresses sur 24 bits sont long en cycle et plus limité en instruction , du coup cela me sert de buffer (et il 'y en à pas mal vu que tout les transferts se font pendant le VBlank) + si on rajoute que le buffer sert pour décompresser les maps.
Bref ce qui y joue comme d'hab sur PCe c'est la faible taille de la ROM , le CD résout un peu ce souci là !

Apparemment même à cette époque le souci de la vitesse RAM est un problème lol
Pour la résolution du 65xxx cela reste trop tard et pas suffisant vu qu'il se font complètement dépassé (le M68 compris )par les processeur MIPS , SH de la gen suivant :p

La fenêtre de 8ko de mémoire sur SNES s'explique par le fait, qu'à la base, elle a été désignée avec 8 ko de RAM (comme la PCE) et ils ont successivement augmenté à 32K puis 128K (probablement pour des raisons de gros chiffres face à la concurrence ).
8 Ko je suis d'accord pour dire que ça suffit pas mal de type de jeux, mais comme Touko l'indique, dés que tu fais intervenir de la compression (notamment sur les map) alors tu as très vite limité quand même. 64K (voire 128K) c'est quand même beaucoup plus confort et ça te permet de faire des jeux de style de Sim City, Dune 2 qui sont impossible à faire sur PCE sans extension mémoire.
C'est vrai que cette fenêtre de 8 Ko de RAM visible en adressable 16 bits c'est, pour moi, un autre défaut de la SNES, son memory map est super tordu :-/ j'imagine que pas mal de jeux se limitent volontairement à 8 ko de RAM pour des raisons de performances.

[Stef]

Quelqu'un à déjà tenté, via émulation, une expérience de savant fou type snes equipée d'un 68k?

Le truc c'est que dans ce cas autant tout re designer :p
Le fait d'y mettre un 68K signifie que tu y adjoins également un BUS 16 bits et donc des ports 16 bits pour les différents chips où ça s'y prêtent bien (ça serait malheureux de devoir faire 2 accès 8 bits aux PPU avec un 68k).

Je parlais la derniere fois de la possibilité de porter/creer des manic shooter sur megadrive et on m'a parlé de omega blast.
Après l'avoir dosé hier soir et ce soir sur du vrai hardware puis l'avoir clear en normal et hard je suis tout bonnement subjugué ! C'est une veritable tuerie... level design, gameplay, visuels... etc.
Si quelqu'un créé un jour un jeu de ce type complet sur 5 niveau... le rêve

Faut admettre que pour un jeu amateur il est super bien soigné. Déjà il envoie pas mal (quand tu vois le nombre de sprites à gérer avec les collisions..) surtout quand tu penses que le jeu est codé en C, mais en plus il est super bien équilibré. La progression est lente mais plaisante, tu as envie d'y revenir tout de suite. Après je pense que c'est difficile de procurer ça sur la durée, il a du déjà y passer beaucoup de temps pour désigner 1 level avec autant d'intensité, ça serait beaucoup beaucoup de travail pour faire un vrai jeu de cet intensité (qui tient au moins 20mn), surtout pour une personne seule... Mais c'est vrai que même dans l'état, j'aurai pu acheter son jeu (à petit prix quand même genre 5e ou 10e pour la ROM).

[TotOOntHeMooN]

ils ont successivement augmenté à 32K puis 128K [...] j'imagine que pas mal de jeux se limitent volontairement à 8 ko de RAM pour des raisons de performances.

Avec 16 bit d'adresse, une vrai page de 32K aurait été probablement un meilleur compromis en terme de taille/performance.

Le fait d'y mettre un 68K signifie que tu y adjoins également un BUS 16 bits et donc des ports 16 bits pour les différents chips où ça s'y prêtent bien (ça serait malheureux de devoir faire 2 accès 8 bits aux PPU avec un 68k).

Un bus 16 bit c'est en même temps la moindre des choses pour une console 16-bit ... Après, des ports sur 8 bit, même 4 bit, peut suffir sur une console pour adresser les différents "périphériques" internes ou externes.

[Stef]

ils ont successivement augmenté à 32K puis 128K [...] j'imagine que pas mal de jeux se limitent volontairement à 8 ko de RAM pour des raisons de performances.

Avec 16 bit d'adresse, une vrai page de 32K aurait été probablement un meilleur compromis en terme de taille/performance.

Oui je pense aussi, je suis assez surpris que le design initial était seulement avec 8 Ko de RAM (on peut retrouver ces informations sur les premières infos divulguées dans les magasines de l'époque). 32K aurait été bien plus logique... en même temps, ils partaient de la NES qui n'avait que 2 Ko.

Un bus 16 bit c'est en même temps la moindre des choses pour une console 16-bit ... Après, des ports sur 8 bit, même 4 bit, peut suffir sur une console pour adresser les différents "périphériques" internes ou externes.

Oui certes (d'ailleurs pas mal de periph ont un port 8 bit sur MD) mais au moins pour le processeur video où tu envoies pas mal de data, un port 16 bits était le bienvenue... de toute façon le bus 16 bit ça demande un sacré re design à la base (et ça augmente beaucoup le cout de la machine) :-/

[Invité]

En faite c'est surtout a cause de cette "fausse" compatibilité Nes !
Sur Nes l'adresse 0x0000 à 0x07FF c'est la RAM et le reste est un miroir jusqu'à 0x2000) , sur SNES ils ont viré le miroir pour mettre la RAM.
Et pour la ROM pareil l'adresse sur SNES et NES sont identique l'adresse est de 0x8000-0xFFFF , s'il fallait mettre de la RAM ça serait par logique a cet endroit

[Stef]

En faite c'est surtout a cause de cette "fausse" compatibilité Nes !
Sur Nes l'adresse 0x0000 à 0x07FF c'est la RAM et le reste est un miroir jusqu'à 0x2000) , sur SNES ils ont viré le miroir pour mettre la RAM.
Et pour la ROM pareil l'adresse sur SNES et NES sont identique l'adresse est de 0x8000-0xFFFF , s'il fallait mettre de la RAM ça serait par logique a cet endroit

C'est sur ils sont parti de ça, mais dés 1988 ils savaient que ça ne marcherait pas donc ils aurait du, au moins, reprendre les specs "retro compatiblité" les plus contraignantes pour s'en abstraire. Et dans un sens leur vision de la rétrocompatibilité n'était pas très judicieuse dés le début... Sur MD c'est le second CPU (le Z80 donc) qui l'assure ce qui limite les problèmes... Sur SNES ils ont tenté de faire ça avec le CPU principal ce qui est une erreur je pense. Un 6502 dédié au son (proche de ce qu'on a dans le SPC700 en fait) mais avec une ouverture sur le BUS principal aurait permis d'assurer la retro compatibilité de la même manière que Sega (et en prenant moins de risque sur le coeur de la machine).