Re: Snes - megadrive - pc engine vs Neo geo

[Lesarthois]

Ca veut dire quoi "vraie 16 bits?" une console ou tous les composants sont 16 bits et les instructions aussi?

[vorakain]

ouaip exacte a tout niveau ! et pour les portable ?

[Lesarthois]

Bin à bien regarder, aucune console ne peut se dire vraiment 16 bits pure...
Mégadrive et Neo Geo contiennent un proc 16/32 bits (bien que je pense que la partie 32 bits n'est pas utilisée?) et un Zilog Z80 qui est donc un 8 bits.
La puce sonore de la Super Nintendo contient une partie 8 bits :!: et son port d'extension est en 8 bits aussi...

Le CD-i contient un 68000 donc un 16/32 bits... La Super A'Can est basée autour d'un 68000 aussi.
Bref pas de "pure" 16 bits si on considère que tous les procs utilisés sont des 16/32 bits (sauf celui de la Super NES).

[Stef]

Le 68000, s'il peut effectuer des opérations directement sur 32 bits est intérieurement un cpu 16 bits, son bus de données est 16 bits, son ALU est 16 bits... Je pense qu'on peut qualifier le 68000 de 16 bits dans le sens ou il est aussi rapide pour effectuer une opération 16 bits qu'une opération 8 bits, ce qui n'est, bien entendu, pas le cas des CPU 8 bits qui vont prendre beaucoup plus de temps pour faire une opération 16 bits.

[vorakain]

en gros pas de difference colossal entre une très bonne architecture 16 bits et 8 bits ?

[Stef]

Un processeur 16 bits sera forcément plus véloce qu'un CPU 8 bits (à moins d'une grosse différence de fréquence en faveur du 8 bits) et ce n'est pas négligeable quand il s'agit de donner vie au jeu (richesse des animations, des effets...) mais effectivement le CPU ne fait pas tout. C'est les processeurs vidéo et sonore qui touchent nos sens en premier

[Lesarthois]

Grossièrement, à architecture et fréquence égale, un 16 bits traite deux fois plus de données qu'un 8 bits.

La différence entre par exemple un bi-processeur 8 bits ou un processeur 8 bits 2 mégahetz contre un processeur 16 bits 1 Mhtz va être l'architecture :
Si tous les autres composants sont 16 bits, la transmission des données va être fluide, là ou le 8 bits boosté sera toujours limité par l'architecture 8 bits.

En gros, pour faire une comparaison, c'est comme une autoroute à 8 voies et une autoroute 16 voies :
Sur la 8 voies, pour augmenter la quantité de données, il faut faire circuler les voitures (informations) plus vite que sur la 16 voies. Or la moindre sortie (composant tel que RAM, puce vidéo) doit être à la même fréquence que le processeur pour garder une circulation fluide.
Ce n'est jamais le cas, donc "bouchons"
En 16 bits, plus de place et moins rapide, donc tout est plus "lent" mais plus de données en même temps; si ralentissement, moins d'impact sur l'exécution des données.

Autrement dit, pour la même tâche, l'archi 8 bits à intérêt d'être calculée au poil, performante pour égaler l'archi 16 bits.

C'est pour cela que les consoles ont filé vers le 64 bits et le 128 bits alors que les ordinateurs restaient au 32 bits : cela permettait de faire circuler beaucoup de données à des fréquences basses, ce qui est moins cher que la solution PC de faire circuler des données à haute fréquence en 32 bits.

[vorakain]

donc en définitive aucune différence d'architecture notable avec un proco de pc. par contre je ne comprend toujours pas pourquoi la pc engine est considéré comme une 16 bits !

[Lesarthois]

Bah, la PC engine a été vendue comme une 16 bits, parce que sortir une 8 bits alors que Sega sortait une 16 bits avec écrit en gros 16 bits dessus, ça le faisait pas.
Et puis la PC Engine possède un processeur 8 bits et une puce graphique 16 bits.

C'est un peu comme la Neo Geo qui était parfois appelée une 24 bits parce qu'elle avait un proc 16 et un proc 8 bits

Pour la différence avec un proco de PC, bah, une console, ce n'est jamais qu'un "ordinateur bas de gamme".
Y'a un proco, une puce graphique, de la RAM, une ROM, etc...
La différence dans les années 80 était même très mince, vu que par exemple pour les consoles 8 bits on prenait volontiers du Zilog Z80 qui était dans quasi tous les ordis 8 bits!
(Game Boy, Master System, Colecovision). On peut même ajouter la Mégadrive et la Neo Geo qui possèdent aussi un Z80 en proco sonore.
Pour les 16 bits alors là tout le monde est d'accord, c'est le Motorola 68000 le roi, il est PARTOUT sauf dans la Super Nintendo, pour le reste : Apple II, Atari ST, Mégadrive, Neo Geo, Philips CD-i, Amiga, tout ce beau monde a un 68000 en processeur principal...

Et aujourd'hui, les consoles tournent avec des proco PowerPC. Ouais, nos consoles sont des MacIntosh déguisées La Xbox360 est d'ailleurs un Mac Pro G5 modifié.

[vorakain]

et la jaguar une fausse 64 bit aussi hein :/ bref cette histoire de bits est aussi parlant que la fréquence d'horloge des processeurs... ca ne veut rien dire ..

par contre il serait intéressant de faire un historique entre la puissance des consoles et des pc de bureau. dans le but de voir la différence de puissance entre chacune des nouvelles générations sorties et les pc . je m'écarte du sujet la

[Lesarthois]

En fait, il faut au minimum mettre côte à côte la fréquence ET les bits.
Mais même là ça n'indique pas grand chose.
Un truc plus fiable c'est de regarder la RAM.
PS3 : 256mo de RAM, Xbox360 : 512Mo de RAM, Wii U : 1 Go de RAM (en fait 2 go mais 1Go pris par le système).

On comprends pourquoi le même jeu sur PS3 et Xbox360 sera en général mieux sur Xbox360. :)

Pour les PC, faut voir, parce que entre ce qui sortait et ce qui était vraiment courant, ca fait un peu un Alienware et un PC Lidl côte à côte...

[ZE NEO GEEK]

Bien constructif !
Instructif et tout !
C'est vrai que le Bit était roi....le mégabit aussi.....8 16....24.....32.....64.....128.....(un mur ce 128 bits en fait,inutile en plus).
A l'epoque.....dire que je révais devant les photos de la 3do....de la jaguar.....(mais,j'ai gardé ma 24 bits snk.).

[Lesarthois]

ah le mégabit, la grosse arnaque
D'ailleurs ça devrait être interdit.

En Français (et dans d'autres langues, même en anglais Européen :
bit : unité de base informatique
octet : 8 bits.
En anglais Américain :
bit : unité de base
byte : 8 bits.

Et quasiment TOUT ce qui existait en console était mesuré en mégabits...
Alors que le standard était le mégaOctet ou megabyte.
Par exemple la "Mega cartridge" de la Master System est appelée comme ça parce qu'elle fait 1méga.
Mais pas un Mégaoctet, un mégabit, soit 128 kilo octets

Pareil, exemple récent, Beggar Prince sur mégadrive, le site annonce "amazing 64Mb cartridge!" ce qui est énorme, car 64 Mo c'était plutôt les cartouches Nintendo 64.
Et en fait c'est 64 mégabits, soit 16 mégaoctets, ce qui était la taille standard des cartouches mégadrive...


Et aujourd"hui... Avec la fibre, on peut avoir une connexion 100 mégas.
100 mégabits, hein, pas 100 Mégaoctets.

[Stef]

Pour les 64 MB megadrive, c'est Pier Solar et surtout ça représente 8 Mo, ce qui est tout de même le double de la plus grosse capacité officielle des cartouches megadrive (4Mo si on met de côté l'exception SSF2 avec ses 5 Mo).

Pour parler de la NEC, seul son CPU est 8 bits et sa fréquence est très rapide (7.1 Mhz), technologiquement elle est clairement plus dans la génération 16 bits.

Si la mégadrive était sortie avec un Z80 à 20 Mhz plutot qu'un 68000 à 7.7 Mhz, la megadrive aurait pu être une 8 bits avec les mêmes performances que le modèle 16 bits. Les bits ne font pas tout :o

[vorakain]

a la non je ne peu pas laisser dire que la 360 est plus perf que la ps3 ! ce n'est ni la même ram, ni la même distribution.256 mo pour en principal et 256 en vidéo soit 512........ C'est sans compter les différences de perfs du proco video de Nvidia et de l'ati... Il suffit de voir les jeux dev en exclu sur ps3 ils sont bien plus beau que les jeux 360. ( the last of us )

quand au proco et bien le cell contre le power pc... ce qui est certain c'est que le cell est plus puissant ca ne fait pas de doute. la deuxième certitude c'est que c'a m'a l'air d’être une sacrée merde de dev un jeu dessus.

dans tout les cas sur cette gen les jeux ont été dev sur 360 puis hop ,portage sur ps3. Quand a la wii u, oui 1 go de ram, mais cette dernière est très lente donc inutile ... c'est un peut comme l'arnaque des 7750 avec 2 go de ddr3 ... inutile, mieux vaut avoir 1 go de ddr5.




autrement ton dernier post me rappel l'arnaque des télécom... 100 méga.... le jour ou nous auront 100 méga ... il aurat couler de l'eau sous les ponts ! et le pire c'est qu'il ne faut pas en parler au client.... ne rien lui dire ... toujours dire oui .... c'est le top ... bref .. coup de gueule .

[Invité]

Un processeur 16 bits sera forcément plus véloce qu'un CPU 8 bits (à moins d'une grosse différence de fréquence en faveur du 8 bits) et ce n'est pas négligeable quand il s'agit de donner vie au jeu (richesse des animations, des effets...)

C'est faux, et on en à déjà parlé ..
Tout est question de cycle pour exécuter les instructions rien de plus ..
Par exemple, charger une valeur 16 bit sur le CPU de la NEC prend autant de cycles le le 68000 de la MD ..
Les sauts à des routines/adresses sont bien plus rapides sur le 6280 que sur le 68000 .
Donc non le 68000 ne traite pas 2x plus vites une valeur 16 bit que le 6280 .

On gagnera même du temps dans les opérations sur 8 bits,qui dans la gen 8/16 bit fait partie des variables les plus utilisées,sans se faire chier à organiser les variables comme sur le 68000, pour rester efficace en op 8bit .

Dans l'ensemble le CPU de la nec fait jeu égal avec le 68000 de la MD, je pense que les jeux le montrent non ??

quand au proco et bien le cell contre le power pc... ce qui est certain c'est que le cell est plus puissant ca ne fait pas de doute. la deuxième certitude c'est que c'a m'a l'air d’être une sacrée merde de dev un jeu dessus.

A ce niveau, le CPU ne fait pas tout, une grosse partie est faite par le compilo, et là les compilo powerPC sont largement devant les compilos Cell .
Puis vient aussi les outils de dev, là aussi je pense que Ms à une sacrée longueur d'avance sur sony .

[ZE NEO GEEK]

Hahhh....ces bits......on c'est bien fait prendre a l'époque....avec les 64 bits de la jaguar...ou encore la 3do.....
Beaucoup revendèrent leur neo-geo....pour une play...ou même une 3do....

Lorsque la dreamcast est sortie,avec ces 128 bits....on imaginait une 256....
(Ca n'a jamais été fait?)

[Stef]

C'est faux, et on en à déjà parlé ..
Tout est question de cycle pour exécuter les instructions rien de plus ..
Par exemple, charger une valeur 16 bit sur le CPU de la NEC prend autant de cycles le le 68000 de la MD ..
Les sauts à des routines/adresses sont bien plus rapide sur le 6280 que sur le 68000 .
Donc non le 68000 ne traite pas 2x plus vites une valeur 16 bit que le 6280 .
...

Chaque CPU a ses spécificités, je parlais de manière générale.
Et puis effectivement on a déjà pas mal débattu sur le sujet et je t'ai déjà montré que "globalement" la megadrive est plus puissante :p justement grace au fait que le CPU soit un vrai 16 bits, ce qui comble le faible ratio cycles/instruction du 68000.
Sur des cas particuliers le 6280 peut être plus rapide, globalement le 68000 sera le plus rapide. Pas la peine de débattre plus longtemps là dessus

[Invité]

Non, tu m'as juste démontré que les transferts de blocs était plus rapide sur le 68000,c'est tout ..
Dans certains cas il est meilleurs dans d'autre c'est le 6280 ..
Je te l'ai montrer sur des variables,et les branchement conditionnels par exemple ..

8 cycles pour un byte en immédiat, tu trouves ça rapide ??

N'en fait pas des généralités ..
Dans l'ensemble,ils font jeu égal ..

C'est sur si tu prends un Z80 pour la comparaison,je te l'accorde, le 68000 est bien meilleurs .

[Stef]

Non, tu m'as juste démontré que les transferts de blocs était plus rapide sur le 68000,c'est tout ..
Dans certains cas il est meilleurs dans d'autre c'est le 6280 ..
Je te l'ai montrer sur des variables,et les branchement conditionnels par exemple ..

8 cycles pour un byte en immédiat, tu trouves ça rapide ??

Tu es trop dans la logique 6280... tu ne fais quasiment jamais de byte immédiat en 68000. Comme je t'ai dit un 68000 a une grande marge d'optimisation quand tu veux vraiment aller vite. Typiquement le unrolling pour limiter les branchements... C'est pour ça que ce CPU est autant apprécié.

N'en fait pas des généralités ..
Dans l'ensemble,ils font jeu égal ..

Je vais pas t'empêcher de penser ça
Le 6280 grâce à sa fréquence élevée est relativement puissant et proche
du 68000, malgré tout un peu en dessous pour moi.

C'est sur si tu prends un Z80 pour la comparaison,je te l'accorde, le 68000 est bien meilleurs .

Certes, mais je pense qu'il faut pas sous estimer le Z80 Bien sur il est moins rapide qu'un 68000 mais il n'est pas si mauvais qu'on peut le prétendre (face à un 6502 par exemple) :o

[Invité]

Tu es trop dans la logique 6280... tu ne fais quasiment jamais de byte immédiat en 68000. Comme je t'ai dit un 68000 a une grande marge d'optimisation quand tu veux vraiment aller vite. Typiquement le unrolling pour limiter les branchements... C'est pour ça que ce CPU est autant apprécié.

Peu être que tu l'utilises pas bcp, mais même en travaillant avec les registres tu restes à 4 cycles, soit comme le 6280 (ou 6502) quand on travaille avec la ram (en ZP) .
Et puis en 8 bit tu fais facilement des optimisation pour des traitements en 16 bit .
Donc tu gagnes rien .
Le unrolling est une technique de démo, applicable essentiellement à la demo, dans un jeu tu peux quasiment pas t'en servir, ça bouffe trop de place ..
Et puis s'amuser à copier des centaines voire des milliers de ligne pour éviter une boucle, c'est pas réaliste dans un jeu .

Je vais pas t'empêcher de penser ça
Le 6280 grâce à sa fréquence élevée est relativement puissant et proche
du 68000, malgré tout un peu en dessous pour moi.

Dans certains cas, et même en étant un peu au dessus, n'en fait pas un cpu 2x plus rapide .
Bien sur je ne parle qu'en terme de machines de jeu, et pour le jeu ...
Le 68000 est bien plus polyvalent que le CPU de la NEC .

Certes, mais je pense qu'il faut pas sous estimer le Z80 Bien sur il est moins rapide qu'un 68000 mais il n'est pas si mauvais qu'on peut le prétendre (face à un 6502 par exemple) :o

Je ne dis pas que le Z80 est mauvais, mais à frequence egale au 6502, il se fait manger .
Voir le C64 est son 6510 à 0,930 mhz, qui arrive à faire aussi bien qu'un CPC/Spectrum et leur z80 à 3,5 mhz .

Par contre pour des compilos de haut niveau style C, la famille 65xx est pas géniale .

[Stef]

Peu être que tu l'utilises pas bcp, mais même en travaillant avec les registres tu restes à 4 cycles, soit comme le 6280 (ou 6502) quand on travaille avec la ram (en ZP) .

Oui c'est vrai, 4 cycles c'est le minimum, d'ailleurs tout à l'heure j'ai pas relevé, mais un immédiate byte c'est 4 cycles sur 68000 avec l'instruction "moveq".
Cette instruction te permet de charger un 8 bits immédiat signé (avec sign extension sur 32 bits) dans un registre en 4 cycles.
Tu as également l'instruction move.b #imm,d0 qui charge en effet un immédiat 8 bits dans la partie basse du registre d0 en 8 cycles mais autant dire que tu ne l'utilises quasiment jamais avec le moveq.
Et 4 cycles par instruction, sachant que tu travailles aussi bien en 16 bits qu'en 8 bits, c'est pas tant que ça

Le unrolling est une technique de démo, applicable essentiellement à la demo, dans un jeu tu peux quasiment pas t'en servir, ça bouffe trop de place ..
Et puis s'amuser à copier des centaines voire des milliers de ligne pour éviter une boucle, c'est pas réaliste dans un jeu .

Pour les copies ou les traitements simples ça ne prend pas tant de place, c'est l'avantage des instructions "complexes" du 68000...
Et franchement je le fais *très* souvent, tu unrolles au moins sur un facteur de 8 pour cacher le branchement (quand c possible bien sure). Mais même sur un 6280 ou un 6502 tu fais ça, le unroll c'est une optimisation de base, les bons compilateurs C s'en servent très souvent.

Dans certains cas, et même en étant un peu au dessus, n'en fait pas un cpu 2x plus rapide .
Bien sur je ne parle qu'en terme de machines de jeu, et pour le jeu ...
Le 68000 est bien plus polyvalent que le CPU de la NEC .

Non je dis pas que le 68000 est 2x plus rapide que le 6280 et puis c'est très difficile à mesurer... Par contre j'ai déjà du dire qu'il était 2x fois plus puissant que le CPU de la SNES (grace à l'architecture de la SNES assez foireuse).

Je ne dis pas que le Z80 est mauvais, mais à frequence egale au 6502, il se fait manger .

Bien sur, mais le Z80 est fait pour tourner plus rapidement.

Voir le C64 est son 6510 à 0,930 mhz, qui arrive à faire aussi bien qu'un CPC/Spectrum et leur z80 à 3,5 mhz .

Je pense que les assistances de C64 y sont pour beaucoup quand même, je pense qu'un 6510 à 1 Mhz doit valoir un Z80 à 2.5 Mhz, si le CPC était équipé comme l'est le C64 il ferait surement mieux.

[Invité]

Oui c'est vrai, 4 cycles c'est le minimum, d'ailleurs tout à l'heure j'ai pas relevé, mais un immédiate byte c'est 4 cycles sur 68000 avec l'instruction "moveq".
Cette instruction te permet de charger un 8 bits immédiat signé (avec sign extension sur 32 bits) dans un registre en 4 cycles.
Tu as également l'instruction move.b #imm,d0 qui charge en effet un immédiat 8 bits dans la partie basse du registre d0 en 8 cycles mais autant dire que tu ne l'utilises quasiment jamais avec le moveq.
Et 4 cycles par instruction, sachant que tu travailles aussi bien en 16 bits qu'en 8 bits, c'est pas tant que ça

Non, à part que sur 65xx le chargement d'un byte dans un registre en immédiat c'est 2 cycles ..

Pour les copies ou les traitements simples ça ne prend pas tant de place, c'est l'avantage des instructions "complexes" du 68000...
Et franchement je le fais *très* souvent, tu unrolles au moins sur un facteur de 8 pour cacher le branchement (quand c possible bien sure). Mais même sur un 6280 ou un 6502 tu fais ça, le unroll c'est une optimisation de base, les bons compilateurs C s'en servent très souvent.

Sur 65xx, sur un facteur de 8 tu gagnes pas grand chose, un branchement conditionnel prend 2 cycles,si le branchement n'est pas pris, et 1 cycle de plus si il est pris ..
Pas de quoi faire du unroll pour si peu ..

Non je dis pas que le 68000 est 2x plus rapide que le 6280 et puis c'est très difficile à mesurer... Par contre j'ai déjà du dire qu'il était 2x fois plus puissant que le CPU de la SNES (grace à l'architecture de la SNES assez foireuse).

Mouai là on pourrai dire que quasiment oui, si on prend la frequence du CPU de la MD, qui est presque 2x plus grande .
Mais un cpu ne fait pas tout non plus .

Bien sur, mais le Z80 est fait pour tourner plus rapidement.

Oui c'était un P4 avant l'heure, ça mouline vite, mais calcule lentement ..
Parce que si à 3,5 mhz il vaut un 6502 à 1 mhz, ca pique un peu non ??

Je pense que les assistances de C64 y sont pour beaucoup quand même, je pense qu'un 6510 à 1 Mhz doit valoir un Z80 à 2.5 Mhz, si le CPC était équipé comme l'est le C64 il ferait surement mieux.

Oui, mais comme le snes vs Md, le Z80 est pourtant cadencé 3,5 fois plus, les assistances ne permettent pas de combler un tel écart ..
Donc même un écart de 2,5 fois est énorme .

[Stef]

Non, à part que sur 65xx le chargement d'un byte dans un registre en immédiat c'est 2 cycles ..

Je sais bien :p
Tiens sinon je viens de coder un petit truc qui à mon avis est dans le genre "worst case" pour le 68000 là ou un CPU 8 bits comme un 6502 ferait bien mieux.

Je veux faire l'opération suivante une seule fois lors d'un cas particulier :
*buf = (*buf & 0xF0) | (col & 0x0F);

en assembleur de base 68000 tu fais comme ça ("a0" pointe sur buf, "d2" contient col) :

Code:


    move.b (%a0),%d0      // 8
    and.b  #0xF0,%d0      // 8
    move.b %d2,%d1        // 4
    and.b  #0x0F,%d1      // 8
    or.b  %d1,%d0          // 4
    move.b %d0,(%a0)    // 8


cout de l'opération : 40 cycles !
je pense qu'on peut faire facilement 2 ou 3x moins avec un 6502 (si t'as le courage de mettre un bout de code).

Bon après réellement tu peux optimiser le code pour mieux s'adapter au 68000, genre tu stockes la couleur masquée et le masque dans des registres (ce que j'ai fait) :

Code:


    move.b (%a0),%d0      // 8
    and.b  %d1,%d0        // 4
    or.b    %d2,%d0        // 4
    move.b %d0,(%a0)    // 8


soit 24 cycles... mais ca reste pas terrible, car on manipule du byte, là ou le 68000 pourrait manipuler du word à la même vitesse.

Malgré tout ce genre de cas n'est pas vraiment un problème en soit, car ce genre de traitement ne représente pas les bottlenecks. Si c'est le cas c'est que tu as probablement une possibilité de modifier l'algo pour tirer partie d'un traitement en 16 bits ou 32 bits. Dans mon cas je fais le traitement décrit plus haut occasionnellement, ce qui représente un temps insignifiant comparé au reste de mon algo où je peux utiliser efficacement l'architecture 16 bits du 68000.

Sur 65xx, sur un facteur de 8 tu gagnes pas grand chose, un branchement conditionnel prend 2 cycles,si le branchement n'est pas pris, et 1 cycle de plus si il est pris ..
Pas de quoi faire du unroll pour si peu ..

Faut compter aussi le coup du test, bien souvent tu décrémentes un compteur et tu fais le branchement derrière à moins que tu as une instruction qui fait les 2 (comme sur le 68000 avec le dbxx). Dans tout les cas, même si tu gagnes disons 5/6 cycles c'est déjà pas mal car bien sur le unrolling s'applique sur un traitement très simple qui dépasse rarement les 3/4 instructions (sur 68000 en tout cas)..

[Invité]

oups

[Invité]

sur 65xx tu fais ça:

Code:


lda #$0F    // 2
and [buf]  // 7
tax            // 2
lda    <col    // 4
and    #$0F    // 2
sta    <col    // 4
txa            // 2
and <col    // 4
sta    [buf]  // 7


Soit 34 cycles, mais moi je compte le chargement de buf et col dedans toi non ..
De plus c'est un des cas qui prend le plus de cycles sur 65xx, on peu réduire le nombre de cycles, tout dépend sur quoi pointe *buf .
Tu pars du principe que tout tes registres sont déjà chargés dans tes 24 cycles ..
Ce qui est moins le cas avec le 40 cycles (sauf buf et col) ..
C'est sur si tu zappes ce qui consomme bcp de cycles ..

Faut
compter aussi le coup du test, bien souvent tu décrémentes un compteur
et tu fais le branchement derrière à moins que tu as une instruction qui
fait les 2 (comme sur le 68000 avec le dbxx). Dans tout les cas, même
si tu gagnes disons 5/6 cycles c'est déjà pas mal car bien sur le
unrolling s'applique sur un traitement très simple qui dépasse rarement
les 3/4 instructions (sur 68000 en tout cas)..

Perso dans un jeu, 5/6 cycles, c'est bien moins important que la perte de tout les octets du unrolling ..
En demo, c'est vraiment utile ..
Après c'est un choix perso ..

[skraj]

même la neogeo x ne rivalise pas...

[Sejakun]

Oulààà j'ai lu juste le 1er post et en répondant j'ai survolé les derniers posts qui contiennent des lignes de codes, je ne sais pas si vous êtes encore dans le sujet ou pas, mais moi je réponds direct à la question (désolé hein si j'interromps un débat).

Alors une adaptation neogeo supérieure à l'original, à chaud comme ça je ne sais pas. Cependant, dans la version d'Art of fighting 2 sur SNES, y'avait un code pour jouer avec Geese alors que dans la version Neo, on pouvait pas. Et ça, ça avait bien fait chier mon pote qui avait une Neo à l'époque

[Stef]

sur 65xx tu fais ça:

Code:


....


Soit 34 cycles, mais moi je compte le chargement de buf et col dedans toi non ..
De plus c'est un des cas qui prend le plus de cycles sur 65xx, on peu réduire le nombre de cycles, tout dépend sur quoi pointe *buf .

Dans mon cas buf est juste un buffer de données que je vais traiter et le bout de code que je t'ai montré s'applique un fois au début du traitement et une fois à la fin (en gros).
Je charge donc "buf" en amont dans un registre qui pointe dessus, j'imagine que tu peux en faire autant sur le 6502, comme lorsque tu veux traiter un large buffer de donnée.
Donc évidement il serait plus logique que tu utilise un logique d'index (X ou Y ?) préchargé pour ça.

Sinon voici le code sans rien préchargé à la dure :

Code:


    move.b buf,%d0        // 12
    and.b  #0xF0,%d0      // 8
    move.b col,%d1        // 12
    and.b  #0x0F,%d1      // 8
    or.b  %d1,%d0          // 4
    move.b %d0,buf        // 12


56 cycles...

Ton code me semble bien compliqué cela dit, par exemple tu stocke le resultat de l'opération (col & 0x0F) dans col or on s'en fiche, le but c'est de modifier buf.
Edit: bon en fait j'ai voulu faire un code 6502 plus optimisé mais je me rend compte que c difficilement possible, c'est quoi ce CPU incapable de faire une opération entre 2 registres X'D
J'ai vraiment pas l'habitude de ça et je trouve ça insupportable mais j'imagine que c'est juste une histoire d'habitude ^^ Enfin du coup, heureusement que le nombre de cycles / instruction est réduit ! Voilà le nombre d'instruction nécessaires pour faire une bête opération !

Tu pars du principe que tout tes registres sont déjà chargés dans tes 24 cycles ..
Ce qui est moins le cas avec le 40 cycles (sauf buf et col) ..
C'est sur si tu zappes ce qui consomme bcp de cycles ..

Mais oui mais l'idée c'est de montrer en pratique comment on peut optimiser le code. Je sais que je vais executer plusieurs fois mon morceau de code donc forcément je "précalcule" certaines choses ! Bien sur tu le fais selon les registres que tu as à disposition et un des grands avantages du 68000 est qu'il en possède un bon paquet (en gros 8 pour le traitement et 8 pour les accès mémoire).
Je me rend compte que cette notion d'optimisation par "cache" ou "précalcul" est totalement absente sur 6502 car tu n'as aucun registre de stockage ! tu dois toujours travailler avec la mémoire et faire des aller/retour avec lda/sta, je trouve ça terriblement pas optimal comme manière de programmer, ça te génère un code long et très répétitif au possible...
Enfin bon c'est ce qui a permis de rendre ce CPU si bon marché.

Perso dans un jeu, 5/6 cycles, c'est bien moins important que la perte de tout les octets du unrolling ..

5/6 cycles x2000 par frame (par exemple) je pense que c'est plus important que 128 octets Dans un jeu comme dans une démo...

[Stef]

Oulààà j'ai lu juste le 1er post et en répondant j'ai survolé les derniers posts qui contiennent des lignes de codes, je ne sais pas si vous êtes encore dans le sujet ou pas, mais moi je réponds direct à la question (désolé hein si j'interromps un débat).

Alors une adaptation neogeo supérieure à l'original, à chaud comme ça je ne sais pas. Cependant, dans la version d'Art of fighting 2 sur SNES, y'avait un code pour jouer avec Geese alors que dans la version Neo, on pouvait pas. Et ça, ça avait bien fait chier mon pote qui avait une Neo à l'époque

Désolé pour le pourrissage de topic, en plus je ne voulais pas y revenir... mais c plus fort que moi :-(
Sinon je trouve que comparer la NeoGeo aux autres 16 bits c'est quand même un peu gonflé :p Ne serait ce que par la taille des cartouches les productions NeoGeo sont hors normes, avec des cartouches équivalentes sur les autres machines on aurait pu voir des jeux bien impressionnants en terme d'animation.

[Invité]

Dans mon cas buf est juste un buffer de données que je vais traiter et le bout de code que je t'ai montré s'applique un fois au début du traitement et une fois à la fin (en gros).
Je charge donc "buf" en amont dans un registre qui pointe dessus, j'imagine que tu peux en faire autant sur le 6502, comme lorsque tu veux traiter un large buffer de donnée.
Donc évidement il serait plus logique que tu utilise un logique d'index (X ou Y ?) préchargé pour ça.

C'est pour ca que je précise "tout dépend de ce que représente *buf" ..
Effectivement si c'est un pointeur vers un tableau j'utiliserai un index X,Y qui du coup me ferait gagner des cycles .
La j'ai volontairement pris un cas général, ou *buf peut pointer sur n'importe quoi .

Sinon voici le code sans rien préchargé à la dure :

Code:


    move.b buf,%d0        // 12
    and.b  #0xF0,%d0      // 8
    move.b col,%d1        // 12
    and.b  #0x0F,%d1      // 8
    or.b  %d1,%d0          // 4
    move.b %d0,buf        // 12


56 cycles...

Déjà mieux

Ton code me semble bien compliqué cela dit, par exemple tu stocke le resultat de l'opération (col & 0x0F) dans col or on s'en fiche, le but c'est de modifier buf.
Edit: bon en fait j'ai voulu faire un code 6502 plus optimisé mais je me rend compte que c difficilement possible, c'est quoi ce CPU incapable de faire une opération entre 2 registres X'D
J'ai vraiment pas l'habitude de ça et je trouve ça insupportable mais j'imagine que c'est juste une histoire d'habitude ^^ Enfin du coup, heureusement que le nombre de cycles / instruction est réduit ! Voilà le nombre d'instruction nécessaires pour faire une bête opération !

Les 65xx ne peuvent faire des opérations que dans l'accumulateur (reg A), ou la mémoire .
X et Y, ne servent en général que d'index,donc je suis obligé de stocker le calcul de col quelque part .
C'est une architecture rapide (en ASM), et peu coûteuse, qui a évidemment pas que des avantages .
Donc tu comprends bien pourquoi j'insiste, sur le fait que tu dois compter la mise en mémoire, sinon c'est pas du jeu
Si tu trouves ça pas optimal, c'est normal, l'archi du 68000 ou du Z80 est complètement différente, mais tu auras le même sentiment que les personnes qui viennent du 65xx vers le 68000/z80 ..
Moi je trouve justement que ça simplicité malgré tout est sa force, les instructions que j'ai utilisé sont somme toutes basiques ..

Peux tu me donner le nombre d'octets que prend ta version 56 cycles stp ??
Juste pour voir ..

Mais oui mais l'idée c'est de montrer en pratique comment on peut optimiser le code. Je sais que je vais executer plusieurs fois mon morceau de code donc forcément je "précalcule" certaines choses ! Bien sur tu le fais selon les registres que tu as à disposition et un des grands avantages du 68000 est qu'il en possède un bon paquet (en gros 8 pour le traitement et 8 pour les accès mémoire).
Je me rend compte que cette notion d'optimisation par "cache" ou "précalcul" est totalement absente sur 6502 car tu n'as aucun registre de stockage ! tu dois toujours travailler avec la mémoire et faire des aller/retour avec lda/sta, je trouve ça terriblement pas optimal comme manière de programmer, ça te génère un code long et très répétitif au possible...
Enfin bon c'est ce qui a permis de rendre ce CPU si bon marché.

Je suis d'accord, mais ça biaise les résultats, car on compare 2 archi ,totalement différentes .
Le 68000 fonctionne un peu comme le Z80, c'est a dire qu'il faut utiliser le plus les registres pour être éfficace .
les 65xx, n'ont que 3 registres, dont 1 seul qui peut faire des opérations, du coup on utilise les 256 premier octet de la mémoire(la zero page), comme registres .
Avec un 4 cycles de lecture/écriture par byte .
Donc tu disposes virtuellement de 256 registres, mais moins rapides que de vrais .

5/6 cycles x2000 par frame (par exemple) je pense que c'est plus important que 128 octets Dans un jeu comme dans une démo...

Pourquoi x2000 ??
Tu t'amuses à unroller toutes tes boucles dans un jeu ???
Je te dis pas la place que tu perds .
et 1200 cycles, sur plus de 100 000, c'est pas la mort, faut vraiment en avoir besoin .
Ca peut être utile dans des interruptions, notamment hsync pointilleuses, ou TIMER, mais sinon ..

Et n'oublies pas que le unrolling, n'est pas réservé qu'au 68000