Re: Mr ToutLeMonde et la programmation NES...

[vingazole]

Ô mon Dieu, mais ce processeur est possédé du Démon !  

Je me doutais qu'il fallait mettre la carry à zéro pour avoir le bon résultat d'une addition avec ADC, mais je n'aurais jamais imaginé mettre C=1 pour avoir une soustraction normale avec SBC (j'aurais pensé que ça calculait A-B-1).

A COMP B
branchement si A = B
branchement si A > B
sinon A < B

Mais non, sur un z80 tu fais une comparaison et un seul branchement aussi, simplement au lieu de brancher sur > tu branches sur >= (et respectivement au lieu de brancher sur <= tu branches sur <), la différence étant que la carry est à zéro quand tu compares deux nombres identiques...

[Invité]

clc n'est pas obligé, si tu sais qu'elle est à 0 avant de faire ton adc, ou si tu veux justement ajouter une éventuelle carry, pareil pour le sbc ..

sur Z80 ou 68000 vous avez surement des addition/soustraction sans carry, mais elles prennent combien de cycles ??
Car je suppose qu'elles font le sec/clc directement et quoi qu'il arrive ..

Donc là selon le cas tu peux gagner 2 cycles contrairement à vos add et adc à vous .

[vingazole]

Sur z80 ADD, SUB, ADC et SBC prennent le même nombre de cycles, 4, ce qui est le minimum pour les opcodes de ce CPU.

[Stef]

Bah non, ça te permet avec un seul opcode de tester 2 conditions, sinon sans ça, si tu veux brancher si supérieur ou égal tu es obligé de faire 2 tests,là avec juste bcs, tu sais si tu est supérieur ou égal .
et avec bcc, tu sais que tu n'est pas égal .
....
lol si c'est le cas, pas étonnant que vos CPU soient des veaux morts niveau instructions / cycle  

Non je crois que tu n'as pas compris, c'est que que là tu nous parles du C et du Z uniquement, dans les autres CPU (et le 6502 aussi j'espère quand même) tu as aussi le flag N (ou S pour sign) et V pour l'overflow.
Avec ces 4 flags tu peux tester tout les cas de figure (du moins sur 68000, sur Z80 y'a des cas chiants de mémoire).
A mon avis sur 6502 tu n'es même pas au niveau du Z80 en terme de test possible :p

@stef:
tu fais comme ça pour une soustraction:
sec (met la carry à 1)
sbc #xx

Quoi O_o ???
Pourquoi tu set le flag pour la soustraction ?
En fait je viens de comprendre en lisant la doc de l'instruction SBC sur le 6502 :
A - d - (1- C)

Non mais vraiment le CPU mal foutu, jamais vu ça  
Puis surtout quand tu es habitué aux autres CPU, tu vas droit dans le mur ^^

Normalement tu as la soustraction classique :
A - d
et le SBC :
A - (d + C)
comme le ADC :
A + (d + C)

Franchement ça sent l'économie de transistor une logique foireuse pareille  

[vingazole]

En même temps c'est un peu normal, le 65xx étant "tout câblé" contrairement aux z80, 8086, 68000 microprogrammés (enfin je crois ?).

[Stef]

clc n'est pas obligé, si tu sais qu'elle est à 0 avant de faire ton adc, ou si tu veux justement ajouter une éventuelle carry, pareil pour le sbc ..

sur Z80 ou 68000 vous avez surement des addition/soustraction sans carry, mais elles prennent combien de cycles ??
Car je suppose qu'elles font le sec/clc directement et quoi qu'il arrive ..

Donc là selon le cas tu peux gagner 2 cycles contrairement à vos add et adc à vous .

Tu devrais coder sur d'autres CPU aussi car le 6502 te donne une vision vraiment erronée d'un CPU et d'un assembleur classique
le manque de add et sub du 6502 n'est qu'une histoire d'économie, la nécessité d'utiliser le clc / sec avant une addition / soustraction est une perte de temps :-/ Sur les autres CPU un add est au moins aussi rapide qu'un adc (et idem pour le sub). Je dirais même que souvent le ADC et SBC prennent plus de cycles car ce sont des instructions secondaires que tu utilises rarement (à partir des CPU 16 bits notamment et surtout sur un 68000 qui supporte déjà les opérations sur 32 bits en natif).

[Stef]

En même temps c'est un peu normal, le 65xx étant "tout câblé" contrairement aux z80, 8086, 68000 microprogrammés (enfin je crois ?).

Oui c'est vrai, puis surtout le nombre de transistor est quand même hyper réduit, c'est même une performance d'avoir un CPU 8 bits fonctionnel avec si peu de transistor, mais en contre partie l'instruction set est un peu bancale.

[Invité]

e manque de add et sub du 6502 n'est qu'une histoire d'économie, le clc et le sec est une pure perte de temps :-/ Sur les autres CPU un add est au moins aussi rapide qu'un adc (idem pour le sub). Je dirais même que souvent le ADC et SBC prennent plus de cycles car ce sont des instructions secondaires que tu utilises très rarement (à partir des CPU 16 bits et surtout sur un 68000 qui supporte déjà les opérations sur 32 bits en natif).

un ADC/SBC prend
2/3/4 cycles (pour les adressages les plus courants,IMM/ZP/ABSOLU) sur le 6502, plus 2 si tu dois faire un CLC/SEC (optionnels),franchement ça gène que vous... 

mais en contre partie l'instruction set est un peu bancale.

N'importe quoi ..
C'est bien beau d'avoir plein d'instructions dont chacune fait 50 choses en même temps, mais si tu n'as besoin que des 25 première, bah nada tu te tapes quand même les 25 autres, quand tu auras compris ça stef, on aura fait un grand pas .
ok le 6502 est très simple, mais c'est justement ce qui fait ça force et son niveau d'optimisation, et forcement le revers de la médaille, c'est un code moins lisible, et d'avoir l'impression de bcp de code pour pas grand choses, mais l'efficacité est là .

[Stef]

un ADC/SBC prend
2/3/4 cycles (pour les adressages les plus courants,IMM/ZP/ABSOLU) sur le 6502, plus 2 si tu dois faire un CLC/SEC (optionnels),franchement ça gène que vous... 

Soit 4 cycles au mieux quand tu ne connais pas l'état de C (ce qui est très souvent le cas)... 4 cycles, c'est autant qu'un Z80 qui tourne en général 2 ou 3 fois plus vite. Donc si c'est quand même génant non ?

mais en contre partie l'instruction set est un peu bancale.

N'importe quoi ..

Le jour où tu programmeras sur un vrai CPU, tu comprendras :p
entre le add/sub manquant, le SBC qui fonctionne de manière étrange, le C flag qui est positionné sur une égalité, certaines instructions de décalage manquant (à cause d'un bug dans le CPU il me semble), désolé mais y'a quand même mal de truc bizarre dans ce cpu :p

le 6502 est très simple, mais c'est justement ce qui fait ça force et son niveau d'optimisation,

Non définitivement non ! C'est fou car en te lisant je me rend que tu ne connais pas du tout les autres CPU... comment pourrais tu donc juger des optimisations possibles des autres CPU ? Le code assembleur en général a une grosse marge d'optimisation, quelque soit le cpu... car tu peux utiliser beaucoup de tricks entre les LUT, l'auto modification de code et autre instruction non documentée.

[Invité]

Soit 4 cycles au mieux 

Ah bon dans le 2/3/4 tu lis 4 cycles au mieux ??   

La vache !!!

4 cycles, c'est autant qu'un Z80 qui tourne en général 2 ou 3 fois plus vite. Donc si c'est quand même génant non ?

tu sais qu'il n'y a pas que le 6502 dans la vie ??
le 6280 de la PCE est bpc plus puissant que le 6502 et il tourne à 7,16 mhz ..

le C flag qui est positionné sur une égalité,

ah bon, je viens de t'expliquer 3 posts plus haut que ça permet de faire 2 tests avec 1 seul opcode, et tu comprends toujours pas l'utilité ??, sérieux stef  !!!

Le code assembleur en général a une grosse marge d'optimisation, quelque soit le cpu

Plus les 65xxx justement du fait que leurs opcodes ne fassent pas 50 choses,ça peut paraitre pénible à première vu, ou pour quelqu'un qui code sur Z80 ou 68000, mais c'est très efficace en réalité, après ça n'a pas que des avantages, mais si la perf est la raison principale ce type de CPU est le bon choix .

[Stef]

Soit 4 cycles au mieux 

Ah bon dans le 2/3/4 tu lis 4 cycles au mieux ??   

La vache !!!

Si tu avais lu tu aurais vu que je disais bien quand tu connais pas l'état de C (soit... 80% des cas ?).

le 6280 de la PCE est bpc plus puissant que le 6502 et il tourne à 7,16 mhz ..

Tu sais qu'il y a des Z80 qui tourne à 40 Mhz ? Je ne comprend pas ton argument (ou j'ai pas envie de le comprendre car il est à côté de la plaque)

ah bon, je viens de t'expliquer 3 posts plus haut que ça permet de faire 2 tests avec 1 seul opcode, et tu comprends toujours pas l'utilité ??, sérieux stef  !!!

Mais c'est toi qui ne comprends pas...
Le fait qu'il soit à 1 en cas d'égalité c'est juste incorrect, et ça n'aide en rien sur les tests bordel...
Imagines si tu avais:
   
A-B > 0  -->  C=0 Z=0
A-B = 0  -->  C=0 Z=1
A-B < 0  -->  C=1 Z=0

Qu'est-ce qui t'empêche d'avoir une instruction qui teste C ^ Z  pour savoir si A-B <= 0 ? c'est ce que font beaucoup de CPU (dont le 68000).
Encore une fois t'as une vue très limitée avec ton 6502 :p

[Invité]

Tu sais qu'il y a des Z80 qui tourne à 40 Mhz ? Je ne comprend pas ton argument (ou j'ai pas envie de le comprendre car il est à côté de la plaque)

Mais oui, en 87 y'en avait partout des Z80 à 40 mhz ..
Aujourd'hui qu'est ce qu'on s'en fou des ces CPU, on des 8 cores à 4ghz    

Je te parle à l'époque des sms/pce/md et compagnie ..

Mais c'est toi qui ne comprends pas...
Le fait qu'il soit à 1 en cas d'égalité c'est juste incorrect, et ça n'aide en rien sur les tests bordel...
Imagines si tu avais:
   
A-B > 0  -->  C=0 Z=0
A-B = 0  -->  C=0 Z=1
A-B < 0  -->  C=1 Z=0

Qu'est-ce qui t'empêche d'avoir une instruction qui teste C ^ Z  pour savoir si A-B <= 0 ? c'est ce que font beaucoup de CPU (dont le 68000).
Encore une fois t'as une vue très limitée avec ton 6502 :p

Ok, combien prend de cycles l'instruction <= sur 68000 ??, je sais même pas si elle existe sur le Z80..

[Stef]

Tu sais qu'il y a des Z80 qui tourne à 40 Mhz ? Je ne comprend pas ton argument (ou j'ai pas envie de le comprendre car il est à côté de la plaque)

Mais oui, en 87 y'en avait partout des Z80 à 40 mhz ..
Aujourd'hui qu'est ce qu'on s'en fou des ces CPU, on des 8 cores à 4ghz    

Je te parle à l'époque des sms/pce/md et compagnie ..

Des 6502 à 7 Mhz en 87 c'est vrai qu'on en voyait partout
A cette époque c'est la mémoire qui bridait la vitesse des cpu et la PCE reste un cas particulier (avec un cpu un peu différent aussi).
Dis toi qu'à la place de ton 6280 à 7.1 Mhz tu aurais pu avoir un Z80 à 20 Mhz sans changer la RAM (et je pense qu'à cette époque on pouvait déjà en trouver des Z80 à cette fréquence). Tu pense pas que ça aurait été autrement plus puissant que ton 6280 à 7.1 Mhz ? Bien évidemment ça n'aurait pas été le même cout...

[Invité]

A cette époque c'est la mémoire qui bridait la vitesse des cpu et la PCE reste un cas spécial (avec un cpu un peu différent aussi). 

Cas spécial ou pas, ça existait,et sur une console de jeu en plus, il m'en faut pas plus, réponds juste à ma question sur l'instruction <= du 68000,combien de cycles ?? 10/12/20 ??  

[Stef]

réponds juste à ma question sur l'instruction <= du 68000,combien de cycles ??  

C'est 8/10 cycles selon que le branchement est pris ou pas en déplacement 8 bits et 12/10 cycles en 16 bits.
Voici toutes les instructions pour les jump conditionnels :

Code:

CMP A,B         signed          unsigned
-------         ------          --------
B < A           BLT             BLO (or BCS)
B <= A          BLE             BLS
B = A           BEQ             BEQ
B <> A          BNE             BNE
B > A           BGT             BHI
B >= A          BGE             BHS (or BCC)

TST A            signed          unsigned
-------          ------          --------
A <  0           BLT (or BMI)    NOP
A <= 0           BLE             BZ (or BEQ)
A =  0           BZ (or BEQ)     BZ (or BEQ)
A <> 0           BNZ (or BNE)    BNZ (or BNE)
A >  0           BGT             BNZ (or BNE)
A >= 0           BGE (or BPL)    BRA


Heureuse ?  
Montre moi donc comment tu gères les mêmes cas avec ton 6502  

[Invité]

le 65xxx sait gérer tout les cas sauf le <=, et > mais bon vu le temps qu'il prend sur 68000 je pense que c'est pas pénalisant de rajouter une condition de plus .

B=A beq
b<=A bne+bcc
b=a beq
b<>A BNE
B > A bne+bcs 
B >= A bcs

A<0  bmi
A<= beq+bmi
a = 0 beq
a<>0 bne
a>0 bpl
a >= 0 bne+bpl

Maintenant donne moi les cycles du 68000 qu'on rigole ..
Sans oublier que sur les 65xxx je suis pas toujours obligé de faire un cmp
par exemple pour savoir si A=0, >0, <0
lda A
beq a_est_a_zero
bmi a_est_negatif
bpl a_est_positif

Il fait ça le 68000 ??? 

Au final c'est bien beau d'avoir un CPU qui fait tout, mais si il le fait lentement ,aucun intérêt 
Surtout que je vois pas vraiment l'avantage d'un CPU qui coûtait 3x le prix d'un 6502 .. 

[Stef]

le 65xxx sait gérer tout les cas sauf le <=, et > mais bon vu le temps qu'il prend sur 68000 je pense que c'est pas pénalisant de rajouter une condition de plus .

B=A beq
b<=A bne+bcc
b=a beq
b<>A BNE
B > A bne+bcs 
B >= A bcs

A<0  bmi
A<= beq+bmi
a = 0 beq
a<>0 bne
a>0 bpl
a >= 0 bne+bpl

Et les tests pour les nombres signés ?
Je t'ai mis les cycles, sinon comment tu gères les sauts conditionnels > 8 bits en déplacement ?

Sans oublier que sur les 65xxx je suis pas toujours obligé de faire un cmp
par exemple pour savoir si A=0, >0, <0
lda A
beq a_est_a_zero
bmi a_est_negatif
bpl a_est_positif

Il fait ça le 68000 ??? 

Ouais ça marche aussi sur 68000, le MOVE positionne les flags Z et C, pas de chance pour toi
C'est le Z80 qui ne le fait pas (ce qui a ses avantages et ses inconvénients).

[Invité]

Je t'ai mis les cycles, sinon comment tu gères les sauts conditionnels > 8 bits en déplacement ?

là il faut utiliser un jmp en plus, mais en général tu t'arranges pour que ça arrive le moins souvent possible, et tu y arrives, sinon c'est 4 cycles en plus, mais évidemment c'est que quand tu n'as pas le choix .

les cycles sur 65xxx c'est 2 si branchement non pris et 3 si pris, le 6502 à 1 cycles pénalité si une page est franchie, pas le 6280,donc 6/7 cycles si 16 bits (ce qui est rare pour ma part) le 8 bits étant le plus fréquent et de loin ..
Donc on voit bien l'avantage du 8 bit, toi ton CPU 16 bit est quasiment pareil que se soit un saut de 8 ou 16 bits.
Tandis que moi je suis même plus rapide que toi en 16 bits 

PS: je te répondrai demain pour les signés, je vais me coucher, A+ stef 

Ouais ça marche aussi sur 68000, le MOVE positionne les flags Z et C, pas de chance pour toi  

Combien de cycles ??

C'est le Z80 qui ne le fait pas (ce qui a ses avantages et ses inconvénients).

Ah tient quand ça t'arrange c'est aussi un avantage 

[Stef]

Le branchement est rapide sur 6502 (dans le cas idéal) c'est sur, c'est l'avantage de son architecture simple (pour le coup). Sur 68000 les branchements ou jump cassent le prefetch ce qui engendre des cycles supplémentaires (car en terme d'accès mémoire, un saut 8 bits c'est 1 seul accés donc théoriquement l'instruction pourrait s’exécuter en 4 cycles).

[Invité]

En plus je me suis trompé, le jmp c'est 4 cycles et non 7
ca donne 2 cycles si non branchement à 7 cycles pour branchement 16 bits.
Donc même dans un cas qui arrive peut, je suis plus rapide en 16 bits que toi en 8 bits 

Et bon puisque les contextes qui nous intéressent ce sont les consoles de jeux, la majorités des instructions du 68000 sont inutiles .
dev/mul aucun intérêt, et de toutes façons elles sont tellement lente que personne les utilisent .
les calcul sur 32 bits, perso j'en ai jamais eu besoin, et je pense que vingazole s'en sors très bien sans.
les test sur des nombres signés, pareil j'en ai pas eu besoin pour le moment, et c'est pas les 20 tests le jour où qui changeront le donnes par rapport à la masse de test classiques avec déplacements 8 bits que comporte un jeu .
Enfin il y en a encore plein comme ça .
Perso je trouve bien plus utile dans une console un cpu qui réagit vite à la prise d'interruptions que des opcodes de mul/div ou des opérations sur 32 bits par  exemple .

Tu dois utiliser entre 40 et 60% des intructions du 68000, entre celles qui sont inutilles , et celles qui sont trop lentes pour un jeux finalement un 65xxx à peu d'instructions, mais elles sont bien choisies, et rapides .

[Invité]

Bah le 68000 n'est pas fait spécialement pour le jeux vidéo hein , il faisait tourner pas mal OS a l'époque et il montait facilement en CPU , donc même le mul/div est pas dérangeant sur un PC et puis quel processeur ne possède pas des instructions peu utilisé ce n'est ni le premier ni le dernier.
Sinon oui le 6502 a sa sortie ne coutait vraiment pas cher donc pour ma part certain choix ont du être plus pour les cout de fabrication que un choix purement arbitraire.
Ensuite pour ma part j'aime bien tout ces processeurs le z80,68000 et 6502.
Même si sur ces 3 la le 6502 est idéal pour un débutant vu qu'il assez simple comme proc.
Après en terme de cycle certes le 68000 il est plus que les autres ,mais il faut avouer que c'est celui ou on est le plus a l'aise a programmer.

[Invité]

Bah le 68000 n'est pas fait spécialement pour le jeux vidéo hein , il faisait tourner pas mal OS a l'époque et il montait facilement en CPU , donc même le mul/div est pas dérangeant sur un PC et puis quel processeur ne possède pas des instructions peu utilisé ce n'est ni le premier ni le dernier.

Voilà, c'est ce que je dis à stef, c'est un CPU fait pour les serveurs/workstation, où tu t'en care d'avoir des prises d'interruptions de 70 cycles, ou des mul/div lentes, ce qui compte c'est la facilité de prog,et de pouvoir adresser bcp de mémoire, et là tout l'instruction SET du 68000 fait la différence .
Dans ce domaine le 65xxx n'est pas du tout adapté puisque son domaine c'est les petits systèmes avec peu de ressources à faible coût comme des consoles de jeux ou de petits ordis personnels, mais qui ont besoins de puissance, là le 65xxx est intouchable .

Et ici on parle bien de consoles non ??

[Stef]

Perso je n'aime pas trop le Z80, plus j'en fais et plus je me dis que malgré son instruction set assez riche et son nombre de registre ce cpu n'est pas très efficace :-/ Je pense que c'est moi qui n'arrive pas à m'y faire surement.. le truc génant avec le Z80 c'est que son grand nombre de registre (enfin relativement pour un cpu 8 bits) te laisse penser qu'il faut manipuler au max dans les registres, pourtant chaque opération avec l'ALU se passe avec l'accumulateur et c'est là où j'ai souvent du mal à m'en sortir car du coup tu perds le temps gagné avec les registres à transférer vers A :-/
Puis on a aussi les accès mémoire via HL qui sont rapide et puissant (en terme d'opérations supportées)... du coup le bon équilibre n'est pas toujours simple à trouver.

Le 6502 je le connais pas assez (enfin j'ai jamais vraiment codé sérieusement dessus) mais il est évident que je serais hyper frustré avec
Je dirais même pour un débutant il doit être un peu rebutant genre les registres d'index 8 bits... tu te dis, mais c'est quoi ce bordel ?

[Invité]

la différence étant que la carry est à zéro quand tu compares deux nombres identiques...

Je sais, mais à force de rajouter des instructions qui ne sont pas forcement utiles à part pour faire jolies,ça complexifie forcement le CPU, donc augmente son coût ..
Même si je suis d'accord avec toi dans la logique, dans la pratique c'est absolument pas gênant ni pénalisant dans les perfs ..
C'est le même principe que les add, adc, la différence c'est qu'au pire tu as les même perfs que le Z80, au mieux tu divises le nombre de cycles /2, donc gain de cycles et de place sur le die du CPU .

Le 6502 je le connais pas assez (enfin j'ai jamais vraiment codé sérieusement dessus) mais il est évident que je serais hyper frustré avec 

Je peux pas t'en vouloir, tu es habitué à une logique avec plein de registre et d'instructions qui font 50 choses, et à toucher la RAM le moins possible, et passer sur un CPU où tu dois penser complètement à l'inverse n'est pas évident du tout .
J'ai le même sentiment envers le Z80 et le 68000, ou tu es bloqué par la complexité des instructions, un add.w ferra toujours le même nombre de cycles, même si tu n'as que la partie LOW à modifier 80% du temps .
Donc optimisations au niveau des instructions = 0 .
Exemple simple: un incrément de 256 sur un 16 bit,ce qui correspond à un changement de pattern pour un sprite de 32x32 pixels ..

[Stef]

Dans ce domaine le 65xxx n'est pas du tout adapté puisque son domaine c'est les petits systèmes avec peu de ressources à faible coût comme des consoles de jeux ou de petits ordis personnels, mais qui ont besoins de puissance, là le 65xxx est intouchable .

C'est cette affirmation qui n'a aucun sens, tu décris le 6502 comme un CPU puissant, ce qu'il n'est pas... c'est un cpu simple et économique mais  puissant certainement pas ! J'ai l'impression que pour toi le seul ratio instruction / cycle est un facteur de puissance mais ce n'est pas ça la réalité... La vraie mesure de performance d'un CPU c'est son efficacité sur une architecture donnée. Par exemple la PCE avec sa RAM très rapide pourrait au moins accueillir un 68008 à 20 Mhz. Un 68008 je peux te dire que c'est vraiment un modèle castré du 68000 car il utilise un BUS 8 bits ce qui le rend grosso modo 2x plus lent. Pour autant le 68008 à 20 Mhz sera bien plus puissant que ton 6280 à 7 Mhz.
Pour ça que je ne comprends pas comment tu peux qualifier le 6502 de puissant, il n'a rien de puissant du tout, bien au contraire !
Et je peux te dire que sur SNES le manque de vraie division et multiplication énerve plus d'un développeur (c'est un sujet qui revient souvent sur NesDev).

En fait quand tu designes ta machine, le 6502 pouvait être interessant grace à son tarif. En gros si tu avais un budget de 100$ pour réaliser ta machine, tu mettais 10$ sur le CPU 6502), 40$ sur la mémoire centrale (mémoire rapide) et 50$ pour le reste (video / son / controller). Bien sur ces chiffres sont fictifs mais c'est pour donner une idée... Alors effectivement en allouant plus de budget à la mémoire tu pouvais choisir de la mémoire plus rapide ce qui permettait d'y greffer un 6502 qui va vite. Pour autant si tu cherches vraiment la meilleure performance et que tu as un budget large, le 6502 n'est pas interessant car tu peux le remplacer par un Z80 plus rapide (fréquence x3) ou un 68008 (fréquence x4).
Après en terme de design c'est déjà mal foutu de base je pense... Il vaut mieux choisir une mémoire 16 bits plus lente qu'une mémoire 8 bits 2 fois plus rapide :p

[Invité]

C'est cette affirmation qui n'a aucun sens, tu décris le 6502 comme un CPU puissant, ce qu'il n'est pas... c'est un cpu simple et économique mais puissant certainement pas

Déjà on à pas la même définition de puissant, pour moi puissant est d'avoir un bon rapport instructions/cycles ce que le 68000 ou le z80 n'ont pas, ensuite faudra qd même que tu arrêtes de penser seul 6502, quand je parle de 65xxx, ça englobe tout les CPU du 6502 jusqu'au 65816,le 6280 de la PCE, n'est pas un 6502, il est compatible, mais dispose de bpc plus d'instructions et de mode d'adressage et surtout tourne à 7,16 mhz ..

Pour autant le 68008 à 20 Mhz sera bien plus puissant que ton 6280 à 7 Mhz.

On est d'accord, mais un 65816 @20 mhz comme le super CPU l'explose et explose aussi un 68000 à la même fréquence, en 90 il y avait Z80 3,5/5mhz 6502 1/1,79 mhz, 65816 2,68/3,58 mhz 6280 7,16 mhz et 68000 8mhz maxi (atari ST) pour le grand public ..
Que je sache la MD n'a pas un 68008 à 20 mhz non ???,ni aucune console grand public ??

Le problème stef c'est que dans le débat console, tu mets une utilisation généraliste des CPU, en parlant de fréquence de 20 mhz, d'instructions set hyper vaste et varié, mais qu'en réalité que seulement 40% des instructions sont utilisées dans une console,etc ...

Et je peux te dire que sur SNES le manque de vraie division et multiplication énerve plus d'un développeur (c'est un sujet qui revient souvent sur NesDev).

C'est pour ça que personne ne les utilisent sur le 68000 car trop lentes ???
Expliques moi à quoi ça sert de les avoir ???, et leurs utilités réelles et prouvées (CAD utilisées) dans un jeu ??
Le truc est de savoir qu'es ce qui pénalise dans une machine de jeu un CPU par rapport à un autre, pas de dire l'un fait ça et pas l'autre alors que c'est jamais utilisé dans un jeu, ou vraiment rarement,alors que l'autre avec ses instructions,plus simples mais plus rapides c'est 80% d'utilisation.

[Stef]

Déjà on à pas la même définition de puissant, pour moi puissant est d'avoir un bon rapport instructions/cycles ce que le 68000 ou le z80 n'ont pas, ensuite faudra qd même que tu arrêtes de penser seul 6502, quand je parle de 65xxx, ça englobe tout les CPU du 6502 jusqu'au 65816 ..

Ouais non mais c'est exactement ce que je disais plus haut... tu es toujours bloqué à cette vision simpliste d'un cpu puissant.
Dans ce cas ouais, le 68000 c'est une merde quoi  

On est d'accord, mais un 65816 @20 mhz comme le super CPU l'explose, en 90 il y avait Z80 3,5/5mhz 6502 1/1,79 mhz, 65816 2,68/3,58 mhz 6280 7,16 mhz et 68000 8mhz maxi (atari ST) pour le grand public ..
Que je sache la MD n'a pas un 68008 à 20 mhz non ???,ni aucune console grand public ??

Le 68000 à 8 Mhz existait dés sa sortie 1979. L'atari et l'amiga sont sortis en 1985 ne l'oublie pas... Sega aurait très bien pu mettre un 68000 à 12 Mhz voir 16 Mhz dans la mégadrive mais il fallait également maintenir les couts. Tout de même la Megadrive est sortie à un prix hyper compétitif quand tu vois tout ce qu'elle embarque et surtout comparativement à la PCE ou la SNES.
Et c'est quoi ton délire de 65816 à 20 Mhz ? En 1990 (date à laquelle est sorti la SNES) WDC avait déjà beaucoup de difficulté à produire des 65816 à 12 Mhz et puis quel intérêt ? puisque tu n'aurais pas pu mettre de mémoire avec...

D'ailleurs :
http://members.optusnet.com.au/spacetaxi64/SPEED-UP-CARTS/SPEED-C64-CPU.htm

Ca montre quoi ce lien ? Ca montre qu'en 1990 ils étaient limités à 4 Mhz pour le 6502 / 65816 pourtant accompagné de high speed RAM (64 ko soit la quantité présent sur MD et la moitié de ce que la SNES embarque).
En 1992 on passe à 8 Mhz, et ton super CPU ... 1998 !    (qui tourne à 14 Mhz de base).
Bref en 1998 un 65816 à 20 Mz c'était juste ridicule, je pense qu'il n'y rien à ajouter :p

Et donc tu vois bien que la SNES, avec son 65816 à 3.58 Mhz est tout à fait dans les limites de l'époque si on veut y adjoindre une quantité de RAM raisonnable. Voilà pourquoi ce CPU est tout pourri, point barre, débat clos

C'est pour ça que personne ne les utilisent sur le 68000 car trop lentes ???
Expliques moi à quoi ça sert de les avoir ???, et leurs utilités réelles et prouvées (CAD utilisées) dans un jeu ??

Ah bon on les utilise pas ?
Si un shift suffit il est évident que tu ne vas pas utiliser une division à la place, mais quand t'as besoin d'une division ben heu... tu l'utilises X'D
Dans tout les jeux qui font intervenir des calculs un peu plus complexe pour leur physique la division est la bienvenue.
Tant que tu en abuses pas (genre moins de 100 divisions par frame), ça ne va pas impacter significativement ton frame rate.
Et puis c'est quoi ton argument vraiment, qui peut le plus peut le moins... y'a pas besoin d'aller plus loin.

[Invité]

Si un shift suffit il est évident que tu ne vas pas utiliser une division à la place, mais quand t'as besoin d'une division ben heu... tu l'utilises X'D

Surtout qu'avec des LUT c'est autrement plus rapide, et bon faut en avoir besoin d'une div dans un jeu 2D, et c'est pas gagné 

Dans tout les jeux qui font intervenir des calculs un peu plus complexe pour leur physique la division est la bienvenue.

Mais oui, en général se sont de simples shift qui suffisent amplement et de la physique un peu complexe dans un jeu, à part en 3D, et d'ailleurs je suis même pas sur que tu l'utilise pour ton starfox MD 

Et puis c'est quoi ton argument vraiment, qui peut le plus peut le moins... y'a pas besoin d'aller plus loin.

Non stef je dis pas ça, je dis que d'avoir un CPU avec un set d'instructions énorme ne sert à rien si dans le système sur lequel il est utilisé en utilise juste une petite partie, ça va juste faire mettre un CPU qui va être trop complexe, donc cher pour rien .
Un 68000 donc un ordinateur, ok pas de soucis l'utilité est là, dans une console de jeu, bcp moins,les perfs associées au coûts sont plus indispensables ..

Le 68000 à 8 Mhz existait dés sa sortie 1979. L'atari et l'amiga sont sortis en 1985 ne l'oublie pas... Sega aurait très bien pu mettre un 68000 à 12 Mhz voir 16 Mhz

En 87 apple aurait pu mettre un 65816 @10 mhz(wdc venait de le valider), le CPU existait, ils ne l'on pas fait d'après ce qu'on peu lire sur le net, pour pas que le 2 GS fasse de l'ombre au mac et à son 68000,de la bouche même de wozniak (tu sais l'ingé qui a fondé apple,un rigolo surement  ) un 65816 @7mhz équivaut un 68000 @14.On est quand même un peu loin des 4x plus rapide pour le 68000 que tu avançais ..
Je te dis pas que ça existait pas, je te dis que dans des machines grand public consoles/ordis on dépassait pas les 8 mhz,pas parce que ça n'existait pas, mais parce que c'était trop cher .
En 90/91 nintendo aurait bien pu mettre aussi un 65816 à 5/10 mhz, comme sega aurait pu mettre un 68000 plus rapide, tout est question de coûts,et le 68000 n'était pas du tout un CPU bon marché.

Et en 87 celui de la PCE était à 7,16, donc rien n'empêchait de sortir un 6502,ou un 65816 à cette fréquence avec les mêmes timings que le 6280,nintendo avait bien plus les moyens que nec pour ça .
Donc ton lien montre rien du tout, car de toutes façons la MD n'a qu'un 68000 à 7,67 et non 10/12/16 ou 20 mhz, donc ça change rien à l'histoire,ni aucune consoles de l'époque avec un 68008 à 20 mhz .
Et même un 65816 à une fréquence réelle de 4mhz aurait bien dopé la snes .
Par contre la PCE a bien un 6280 à 7,16 elle 

En 89 nec sort la supergrafx, 32 ko de ram 140 ms, 128 ko de vram 100 ms ..

[Stef]

Mais oui, en général se sont de simples shift qui suffisent amplement et de la physique un peu complexe dans un jeu, à part en 3D, et d'ailleurs je suis même pas sur que tu l'utilise pour ton starfox MD 

Je t'invite à regarder le code source pour les transformations 3D, tu verras si la multiplication et la division ne sont pas utilisées :
https://sgdk.googlecode.com/svn/trunk/src/maths3D_a.s

Les LUT ça marche pour le 8 bits (8x8=16 bits) et c'est insuffisant pour faire de l'affichage 3D, minimum il te faut du 16 bits fixed point (ce que j'utilise) et dans ce cas tu dois enchainer plusieurs opérations avec tes luts.
Pour transformer un coordonné 3D j'utilise 9 multiplications 16x16=32 bits ensuite pour la projection j'utilise encore 2 multiplications + 1 division.
Au total 11 multiplications 16x16=32 + 1 division 32:16 = 16 pour chaque vertex.
Avec tes luts 8 bits tu passeras au mieux par des opérations type 16x16=24 ou 24:16=16 mais ça sera prendra bien plus de cycles que la multiplication ou division du 68000.

En benchmark j'ai calculé que je pouvais transformer environ 10000 vertex (coordonnées 3D en 16 bits fixed point) par seconde, ce n'est pas si pas mal pour un CPU avec une division et multiplication lente :p  Je te souhaite bon courage pour faire mieux avec le 65816 ou le 6280

En 87 apple aurait pu mettre un 65816 @10 mhz(wdc venait de le valider), le CPU existait, ils ne l'on pas fait d'après ce qu'on peu lire sur le net, pour pas que le 2 GS fasse de l'ombre au mac et à son 68000,de la bouche même de wozniak (tu sais l'ingé qui a fondé apple,un rigolo surement  ) un 65816 @7mhz équivaut un 68000 @14.On est quand même un peu loin des 4x plus rapide pour le 68000 que tu avançais ..

Mais oui bien sur, et la marmotte  
http://www.1000bit.it/support/articoli/apple/a2gs/interview_woz.asp

Non mais franchement ça c'est les rumeurs des gros fanatiques, si tu vas sur des sites sérieux avec des gens qui s'y connaissent un minimum tu verras bien qu'il était totalement impossible d'avoir un 65816 à cette fréquence, déjà parce-que WDC n'arrivait pas à les produire (beaucoup de rejets...) et ensuite tout simplement parce-qu'il n'y avait pas de mémoire capable de suivre le CPU.
Et wozniak qui a dit que le 65816 à 7 Mhz est aussi performant qu'un 68000 à 14 Mhz, ben franchement j'aimerai retrouvé le discours exact. Là encore ça sent les fanatiques qui ont sorti ça du contexte, genre il a comparé avec les perfs des macintoshs qui avaient une gestion de l'affichage graphique lente et catastrophique... enfin bref, le belle affaire.

Y'a des tonnes de topic sur le sujet, et encore une fois j'ai déjà tenté x fois de t'expliquer cette contrainte sur la mémoire qui fait que tout tes arguments ne tiennent pas :
http://arstechnica.com/civis/viewtopic.php?t=1191855
http://www.brutaldeluxe.fr/products/crossdevtools/mrspritetech/

Je t'ai déjà posté ces liens, mais vraiment pour une fois essai de lire et comprendre ce qui s'y dit :p
Le deuxième est hyper interessant d'ailleurs avec une routine d'affichage de sprite sur 65816 qui est optimale (impossible de faire plus rapide je pense).

Et en 87 celui de la PCE était à 7,16, donc rien n'empêchait de sortir un 6502,ou un 65816 à cette fréquence avec les mêmes timings que le  6280,nintendo avait bien plus les moyens que nec pour ça .

Encore une fois, la PCE est un cas particulier, pourquoi crois tu que c'est la seule machine avec un 65xx aussi rapide à cette époque ?
Ils produisaient leur propre chip, la quantité de RAM était vraiment faible et la machine était quand même relativement cher pour ce que c'était !
Jamais Nintendo n'aurait pu opter pour le même genre de solution.

En 89 nec sort la supergrafx, 32 ko de ram 140 ms, 128 ko de vram 100 ms ..

Oui, et combien valait cette machine ? quasiment le double de la megadrive alors qu'elle sort 1 an après tout en étant technologiquement à peine à son niveau (et toujours 2x moins de RAM)... interessant

[Invité]

Oui, et combien valait cette machine ?

Elle était pas donnée c'est clair, mais elle avait entre autre 2 VDC + 1 VPC en plus, c'est pas gratos .
Donc si on prend ça comme ref, avoir 32/64 ko de ram rapide ou même à 200 ms pour un CPU à 5mhz, ça compense largement les 64 ko de VRAM supplémentaire à 100 ms et les 64ko de WRAM en moins pour la snes.

 quasiment le double de la megadrive alors qu'elle sort 1 an après tout en étant technologiquement à peine à son niveau (et toujours 2x moins de RAM)... interessant 

LOL, t'as bossé chez big N toi non ??   
Tu me fais du marketing ??, ok elle a 32 ko de RAM en moins, mais elle a 2 x plus de VRAM, 128 sprites, 512 pixel sprites /ligne, la Md elle est pas au niveau ..
Et surtout elle peut utiliser ses 2 résos type supplémentaires, le 344x240 et 512x240 sans soucis.

Tu parles de PCE comme cas unique, ça n'a rien à voir, le CPU est modifié pour ça, si hudson qui n'a pas les finances de Nintendo a pu le faire nintendo aussi,surtout 3 ans après, mais comme tu veux pas entendre raison que la snes est rushée, bah parle d'impossibilité technique comme raison .
et les 8ko de ram de la PCE, faut pas oublier qu'elle concurrençait la nes/sms et pas les 16 bits, 8 ko c'était largement suffisant, surtout que comme la PCE peut écrire n'importe quand dans sa VRAM avoir plus de ram devient moins utile .
même si nec fabriquait les puces, nintendo avec les quantités devait arriver à des prix proche, et surtout avec des mémoire 200 ms (contre 140 pour nec) pour un CPU à 5mhz, les prix auraient été largement moins cher, surtout 3 ans après .

Enfin stef crois ce que tu veux,et la légende de wozniak comme tu dis ce sont pas les pros 65816 qui le disent, mais les pros apple qui s'en branlaient du 65816 ou du motorola, eux tout ce qu'ils voyaient c'est qu'un 65816 à 2,6 mhz atomisait un 68000 à 8  

Encore une fois, la PCE est un cas particulier, pourquoi crois tu que c'est la seule machine avec un 65xx aussi rapide à cette époque ?

Parce que les 65xxx c'était fini, le 65816 est sorti bcp trop tard en plus de ne pas être un vrai 16 bits par rapport au 68000 qui s'est implanté faute de concurrence dans la gamme de prix, et nintendo l'a choisi seulement pour des raisons de coût et de compatibilité, un 68000 dans la console aurait coûté trop cher .

Wozniak: In the beginning, a bunch of us sat down with a basic concept—to build a very simple, very fast machine with this new processor

Tout es dit 

http://arstechnica.com/civis/viewtopic.php?t=1191855

 
Ca montre quoi ??
Qu'un créateur d'émulateur pcengine (exophase) justement montre combien le 65816 et surtout le 6280 sont plus efficaces que le 68000,surtout quand il à fait les tests avec un autre mec qui lui faisait un emulateur MD et à testé les mips moyens du 68000 de la Md dans les jeux, c'est édifiant tellement le rendement de ce CPU est mauvais .
Amuses toi à les lire: http://exophase.devzero.co.uk/profiles.zip

Look at 68k CPI listings here. None of them are below 10 and many are in the high teens, 20s, or even 30s. Far cry from nearly every instruction taking 4 cycles. Some of it is exaggerated by games with slow idle loops, but I'm informed that some of these games don't even have idle loops at all.

I don't have numbers for 65816, but I can tell you that Hu6280 (PC-Engine) games used around 4 cycles per instruction on average (did a PC-Engine emulator). This CPU was a little slower than a vanilla 6502 because it performed memory translation. 65816 is basically 6502 timing but with an extra cycle where you need an extra instruction byte over the 6502 instructions.

Amusant 

Come on, let's be realistic.. yes you would try to avoid memory accesses as much as possible but these weren't magic CPUs with huge register files. I don't think the typical instruction type distribution in programs then is going to be much different from programs now, which dictate anywhere from 30-50% of instructions accessing memory and 10-20% branches. Those are all going to be 8+ cycles. Yes, addq/subq/movq were only 4 cycles, but those were with tiny 3-bit immediates, surely not going to be useful everywhere.

choisis mieux tes liens stef 

[Stef]

Ouais mais si tu lisais tout tu verrais que les quotes que tu prends viennent de gars comme toi qui en restent au rapport instruction / cycle et qui ne veulent pas comprendre... Tu verras les réponses qui tentent de leur expliquer en quoi ils se plantent, tout comme je fais avec toi en ce moment mais vraiment c'est du temps de perdu. On a déjà eu exactement la même conversation et tu es borné de chez borné ou simplement je te surestimais :p