Re: [SNES] Projet A-RPG

[Stef]

Je dois admettre avoir du mal à comprendre comment on peut ne pas apprécier l'assembleur du 68000 ?
Perso j'ai fait pas mal d'assembleur (entre le 6502, 6809, Z80, x86, 68000, ARM Thumb, SH-X, custom DSP etc... et même certaines bizarreries comme le processeur Saturn de la HP-48) et vraiment l'assembleur 68000 est l'un de mes préférés (si ce n'est mon préféré)... effectivement il est très orthogonal (ce qui signifie que les fonctionnalités "se cumulent", en gros les différents modes d’adressage et opérations sont accessibles sur la plupart des instructions / registres) mais de manière générale c'est surtout que son instruction set est bien pensé, facile à comprendre, pas frustrant (comme un certain 6502) et le nombre de registre fait qu'on peut produire des algos vraiment rapide quand on arrive à tout conserver en registre... Il n'est pas parfait pour autant (j'aurai bien vu quelques instructions supplémentaires comme le switch nibble / byte sur un registre) mais il est déjà pas mal comme il est, surtout pour un CPU sorti en 1978/1979 !
Le x86 j'en ai pas mal bouffé et excepté les modes d'adressage puissants et rapide (à partir du 386 surtout) j'ai toujours trouvé ce CPU assez chiant à programmer. Le Z80 idem, je ne l'aime pas trop, je le trouve pas très efficace... passer par un unique registre pour toutes les opérations ALU c'est vraiment contraignant, le GB80 (qui est une version custom du Z80 qu'on trouve dans la GameBoy) est bien plus interessant pour moi en terme de simplicité / efficacité.
Au final je trouve que les ARM, SH-X et 68000 sont les plus plaisants à programmer de manière générale... ils ont tous un grand nombre de registre et un instruction set orthogonal, ça doit avoir un rapport :p

[Invité]

Il parait que le nec v810 est un réel plaisir a coder en asm, efficace et bien foutu .

[vingazole]

Je dois admettre avoir du mal à comprendre comment on peut ne pas apprécier l'assembleur du 68000 ?

J'ai bien précisé que je n'aime pas la syntaxe de l'ASM du 68000 (mais bon c'est juste une question de goût perso; dans le même genre, je déteste la notation de l'héxadécimal en C : 0xCACA) 

En ce qui concerne l'orthogonalité je suis bien d'accord : c'est beaucoup plus pratique/efficace à programmer, mais c'est le manque d'orthogonalité du z80 et ses petites bizarreries/trucs à connaître qui me le rendent éminemment sympathique

[Stef]

J'ai bien précisé que je n'aime pas la syntaxe de l'ASM du 68000 (mais bon c'est juste une question de goût perso; dans le même genre, je déteste la notation de l'héxadécimal en C : 0xCACA) 

En ce qui concerne l'orthogonalité je suis bien d'accord : c'est beaucoup plus pratique/efficace à programmer, mais c'est le manque d'orthogonalité du z80 et ses petites bizarreries/trucs à connaître qui me le rendent éminemment sympathique

Ahh la syntaxe désolé, j'ai lu un peu vite :p
Bon oui la syntaxe vaut ce qu'elle vaut mais je dois admettre que pour moi c'est juste une histoire d'habitude
Pour le Z80 ce qui est frustrant c'est que le CPU en lui-même est plutot pas mal pour un CPU 8 bits: pas mal de registre globalement, un 2eme set des registres principaux ce qui est assez original, des operations 16 bits, des copies de bloc... mais à côté de ça, t'as l'impression qu'il est vraiment difficile d'utiliser efficacement tout ça. genre les registres IX et IY, je les trouve totalement inutile. Ils ne servent qu'à simplifier l'écriture du code mais pour l'efficacité du code tu dois t'en passer car trop lent... d'ailleurs le custom Z80 de la GameBoy ne les a pas, ce qui est une bonne chose pour moi :p

[Stef]

Il parait que le nec v810 est un réel plaisir a coder en asm, efficace et bien foutu .

32 registres 32 bits, bon 6 ou 7 sont réservés mais quand même, c'est clair que c'est un bon début

[Invité]

Il parait que le nec v810 est un réel plaisir a coder en asm, efficace et bien foutu .

32 registres 32 bits, bon 6 ou 7 sont réservés mais quand même, c'est clair que c'est un bon début

Il faut voir la machine derrière aussi
nec v10 c'est pour la PC-FX non ? Une console morte né , elle aurait fait de la 3D pas trop dégueux et elle aurait mieux marché

Pour la syntaxe du moment que c'est pas du AT&T moi ça me va

(mais bon c'est juste une question de goût perso; dans le même genre, je déteste la notation de l'héxadécimal en C : 0xCACA)

Ben a force de faire de l'assembleur je fais par inadvertance mes commentaire avec ; et de l'hexa avec $ en C

Je trouve cela dommage que chaqu'un n’apprécie pas trop les autres processeur la on a les trois :
Touko : 6502
stef :68000
vingazole : z80
Apres je sais pas si touko aime bien le 68000 et le z80 , et vingazole ce qu'il en pense du 6502
Pour ma part comme je l'ai dit je peux passer de l'un a l'autre sans soucis , juste de ne pas faire de lda en 68000 et pas de move en 6502

[Invité]

Il faut voir la machine derrière aussi 
nec v10 c'est pour la PC-FX non ? Une console morte né , elle aurait fait de la 3D pas trop dégueux et elle aurait mieux marché 

Oui si tu prends une console c'est la Fx, mais le V810 heureusement n'est pas né pour cette machine,et d'ailleurs il n'était pas prévu à la base dans la PCFX, mais un CPU risc de chez hudson .
Le V810 lui a été préféré par nec, bcp plus puissant bcp d'instructions se font en 1 cycles (registres).

Touko : 6502

Oui, enfin Hu6280, c'est plus un 65c02+, qu'un 6502 .

Apres je sais pas si touko aime bien le 68000 et le z80

Ce sont tous de bons CPU, après tout dépend ce a quoi on les destine .
Pour moi L'arm2 est le meilleurs CPU de fin d'années 80,il cumule les avantages du 68K/Z80(bcp de registres), et les perfs des 65xxx,ça donne un CPU bien meilleurs que ces derniers dans leurs domaines respectifs.

[vingazole]

genre les registres IX et IY, je les trouve totalement inutile. Ils ne servent qu'à simplifier l'écriture du code mais pour l'efficacité du code tu dois t'en passer car trop lent... d'ailleurs le custom Z80 de la GameBoy ne les a pas, ce qui est une bonne chose pour moi :p

Oui, il vaut mieux éviter de les utiliser pour l'adressage indexé car il sont très coûteux en cycles (("ld c,(ix+4)" : 19 cycles   ), mais n'oublie pas que les undocumented opcodes te permettent d'avoir 4 registres 8 bits (ixL, ixH, iyL et iyH) supplémentaires...  Et puis faire un "jp(ix)" au lieu d'un "jp ****"  (saut vers une adresse absolue 16 bits) c'est 2 cycles de gagnés

Apres je sais pas si touko aime bien le 68000 et le z80 , et vingazole ce qu'il en pense du 6502

Le premier microprocesseur sur lequel j'ai programmé c'était le 6809 (sur TRS-80 "CoCo 2" puis sur Thomson MO6), le 6502 me paraît très proche en termes de registres et de syntaxe...

[Stef]

Oui, il vaut mieux éviter de les utiliser pour l'adressage indexé car il sont très coûteux en cycles (("ld c,(ix+4)" : 19 cycles   ), mais n'oublie pas que les undocumented opcodes te permettent d'avoir 4 registres 8 bits (ixL, ixH, iyL et iyH) supplémentaires...  Et puis faire un "jp(ix)" au lieu d'un "jp ****"  (saut vers une adresse absolue 16 bits) c'est 2 cycles de gagnés 

Oui les registres 8 bits supplémentaires c'est la seule utilité que j'ai pu en avoir mais ça reste des registres 8 bits lents donc même pour ça leur utilisation est limitée :-/ Pour le jp(ix), c'est là encore seulement 2 cycles de gagné (à cause du foutu prefix) et ça marche que pour 1 ou 2 jp critiques, enfin ça peut être toujours ça de pris mais c'est triste de devoir réduire leur utilisation a ça alors qu'à la base ils ajoutent un mode d'adressage puissant mais hélas trop lent pour être réellement interessant :-/

Le premier microprocesseur sur lequel j'ai programmé c'était le 6809 (sur TRS-80 "CoCo 2" puis sur Thomson MO6), le 6502 me paraît très proche en termes de registres

J'ai fait pas mal de 6809 (sur to8) et vraiment ce processeur est bien plus évolué que le 6502 ! C'est même un très bon CPU 8 bits je trouve (il a même une instruction de multiplication !), il a 2 accumulateurs qui peuvent être combinés en 1 registre 16 bits et ses 2 registres d'index sont 16 bits, ce qui fait déjà une différence de taille ! Vraiment c'est quand même assez différent du 6502 même si la syntaxe est similaire puisqu'ils dérivent tout les 2 du 6800.

[Invité]

Le premier microprocesseur sur lequel j'ai programmé c'était le 6809 (sur TRS-80 "CoCo 2" puis sur Thomson MO6), le 6502 me paraît très proche en termes de registres et de syntaxe...

Oui c'est pareil, même si le 6809 est un peu mieux niveau instructions .
Sinon c'est clair qu'avec un second accumulateur les perfs sont bien meilleures, c'est ce qui manque aux 65xxx ..

[Invité]

ça sent que beaucoup de personne ici on commencé grâce a l'informatique pour tous.

[Invité]

Les thomson clavier gomme 

[vingazole]

Le MO6 avait un clavier mécanique (+ lecteur de K7 intégré, s'il vous plait...)

Je suis trop vieux pour avoir "bénéficié" du plan informatique pout tous, c'est juste que mon cousin a eu un MO6 (ça ne devait pas être trop cher comme ordi à l'époque, j'imagine ).

[Stef]

ça sent que beaucoup de personne ici on commencé grâce a l'informatique pour tous.

Bof, on faisait du logo, ça m'amusait mais je trouvais ça assez frustrant car trop limité dans ce que tu pouvais faire :p Mon père avait acheté un MO6 à la même époque mais j'y comprenais pas grand chose au basic (j'avais 9/10 ans), je m'amusais surtout à modifier des programmes existants qu'on pouvait trouver dans des magasines et j'essayais de comprendre comment ça marchait mais j'étais incapable de créer un programme de moi-même.

L'assembleur sur TO8 j'y suis venu bien plus tard (quand j'avais 17/18 ans), j'ai racheté un TO8 et j'ai commencé à bidouiller un peu avec, j'avais même racheté une cartouche assembleur qui permettait de coder facilement en assembleur, c'était le pied :)
En fait j'ai découvert l'assembleur un peu plus tot sur VIC20 (sic, c'est vraiment l'un des pires micro 8 bits) et à l'époque je commençais à entrevoir les possibilités de ce langage, qui offrait des performances complètement surréelles comparé à ce qu'on pouvait faire en basic. Je me souviens même de mon premier programme en assembleur que j'avais fait avec mon frère, ça permettait juste de faire défiler un caractère à l'écran du gauche à droite ligne par ligne mais c'était tellement rapide qu'on voyait même pas le caractère passer ! Le caractère se retrouvait en bas de l'écran quasiment instantanément alors qu'il fallait au moins 30 ou 40 secondes avec le basic ! On était vraiment excité comme des malades devant de telles performances X'D
Bon le problème c'est que le VIC20 en lui même était trop pourri, pas de mode bitmap... c'est pour ça qu'on est passé au TO8

[vingazole]

Héhé, pareil, quand j'ai commencé à intégrer des routines en langage-machine dans mes programmes en BASIC, il a fallu que je rajoute des grosses boucles de tempo sans quoi ça allait beaucoup, mais BEAUCOUP trop vite

[Invité]

Pas mal ton histoire stef , j'aime bien
Quand on découvre/réussi un truc on est toujours surexcité ^^
C'est sur que a une époque l'asm était le seul langage fiable.
Je remarque que le Basic était un langage incontournable dans les année 80-90 xD

Pour ma part c'est moins intéressant j'ai commencé la prog a mes 20 ans avec l'actionscript 2 (le langage pour Flash).
Mais après vu mon cursus scolaire (fac) quand j'avais 21 ans , j'ai fait du C bref en gros j'ai commencé la prog très tard comparé a certain.
Ensuite j'ai étudié pas mal d'autre langage (C++ et Java) et l'asm j'avais touché que sur du x86 et je trouvais ça très peu interessant , je me suis mis sérieusement à l'asm  grâce a la SNES

[ichigobankai]

en même temps t'a 15 ans de moins que Vingazole et 10 de moins que Stef, donc normal que t'y sois mis plus tard ^^

[Stef]

Pas mal ton histoire stef , j'aime bien
Quand on découvre/réussi un truc on est toujours surexcité ^^

Ah ouais mais t'imagines même pas à quel point :-p Vraiment la différence de performance était juste dingue, un facteur x100, faut dire que le basic du VIC20 devait être particulièrement poussif mais tu entrais vraiment dans une autre dimension. Après clairement c'était coton de coder en ASM de base, à l'époque on faisait ça avec du DATA et du poke. En gros on traduisait les mnémonics asm en hexa et on foutait ça en mémoire puis on faisait un exec dessus en priant pour que ça ne crashe pas la machine (ce qui arrivait dans 95% des cas)  :p  La cartouche ASM qu'on a eu sur TO8 c'était une petite révolution à côté et pourtant qu'est ce que c'était rudimentaire comme éditeur ^^

C'est sur que a une époque l'asm était le seul langage fiable.
Je remarque que le Basic était un langage incontournable dans les année 80-90 xD

En fait tout les micro-ordinateurs 8 bits étaient vendu avec ça. Tu démarrais l'ordi, tu avais juste le basic de base pour t'amuser avec.
Je me souviens quand j'avais un nouveau jeu, je regardais tout le temps si y'avait du code basic dedans ou pas. Quand le jeu était 100% basic (ce qui était rare heureusement) en général le jeu ne cassait pas 3 pattes à un canard, par contre les jeux full ASM (avec un .bin) était souvent techniquement intéressant (pas toujours mais souvent).

Ensuite j'ai étudié pas mal d'autre langage (C++ et Java) et l'asm j'avais touché que sur du x86 et je trouvais ça très peu interessant , je me suis mis sérieusement à l'asm  grâce a la SNES

Tu n'as pas commencé par le plus simple :p

[Invité]

Tu n'as pas commencé par le plus simple :p

L'ASM est simple, la console bcp moins .

[Stef]

Je trouve que c'est vraiment pas le plus straightforward, avec son registre pour changer la taille de l'accu ou des registres d'index :-/ en plus je trouve qu'il peut te donner des mauvaises habitudes (a cause de ses spécificités)... Et ne pas avoir de multiplication ou division ça peut être aussi vu comme une difficulté pour commencer l'assembleur.

[Invité]

Exact , le 6502 est sympa autant le 65816 est assez mauvais pour le 8/16 bits , de plus le compilateur(ou l'assembleur comme vous voulez) , a une limite dans la vérification de la taille du registre par exemple :

Code:

rep #$20

jsr mafonction

sep #$20

La fonction sera écrit en 8 bit , alors que on s'est mis en 16 bits (pour l'accumulateur) , du coup ça plante au lancement

L'assembleur n'a aucun moyen de savoir que 'mafonction' est en 16 bits du coup c'est au programmeur de faire attention

Ah ouais mais t'imagines même pas à quel point :-p Vraiment la différence de performance était juste dingue, un facteur x100, faut dire que le basic du VIC20 devait être particulièrement poussif mais tu entrais vraiment dans une autre dimension. Après clairement c'était coton de coder en ASM de base, à l'époque on faisait ça avec du DATA et du poke. En gros on traduisait les mnémonics asm en hexa et on foutait ça en mémoire puis on faisait un exec dessus en priant pour que ça ne crashe pas la machine (ce qui arrivait dans 95% des cas)  :p  La cartouche ASM qu'on a eu sur TO8 c'était une petite révolution à côté et pourtant qu'est ce que c'était rudimentaire comme éditeur ^^

A ce point , un facteur x100 , j'imagine pas lol , alors que de nos jours l'asm ça rapporte quoi comme perf ? x)
Après le Basic n'était pas 'compilé' ou il interpréter ? , si il interprete cela me semble plus normal , si il compilé le compilo devait être vraiment merdique ^^
Pour les asm , c'est clair que avant ça devait de la m**** , je suis bien content que de nos jours ont est des IDE , et des assembleurs vachement puissant (macro , label temporaire ect) ,sinon chaud de sortir quoique ce soit seul.
Enfin après je sais que par exemple que SNK développer leur jeux Neo Geo sur PC-88/98 , a mon avis il devait existé des asm assez correct dessus.
Ceux qui ont fait Star Fox ont développer le jeux sur MS-Dos (mais il me semble que le kit de la SNES de base était sur MS-Dos aussi).
Et Capcom devait j'imagine développer sur X68000 leur jeux CPS1 et CPS2 (c'est la machine que je rêverais d'avoir si j’étais dev a la belle époque ) , enfin faut le prendre au seconde degrer hein , en 1990 j'avais 2 ans quand même




@ichigobankai
oui mais je parlait de l'age , j'ai l'impression que la plupart ont touché a la prog avant leur 18 ans c qui n'est pas mon cas.

[firestqr]

Assez ouf O.o je suivrai le projet de près ^^

[vingazole]

@ichigobankai
oui mais je parlait de l'age , j'ai l'impression que la plupart ont touché a la prog avant leur 18 ans c qui n'est pas mon cas.

Oui, j'ai commencé vers 10/11 ans en BASIC (et c'était bien un BASIC interprété...)

[Stef]

Exact , le 6502 est sympa autant le 65816 est assez mauvais pour le 8/16 bits , de plus le compilateur(ou l'assembleur comme vous voulez) , a une limite dans la vérification de la taille du registre par exemple :

Code:

rep #$20

jsr mafonction

sep #$20

La fonction sera écrit en 8 bit , alors que on s'est mis en 16 bits (pour l'accumulateur) , du coup ça plante au lancement

L'assembleur n'a aucun moyen de savoir que 'mafonction' est en 16 bits du coup c'est au programmeur de faire attention

Oui la spécificité de ce CPU fait que l'assembleur peut pas deviner certaine choses, c'est à toi de faire gaffe, bref c'est un design un peu bizarre au final... ils ont fait ça pour conserver la retro compatibilité avec le 6502 mais ça aurait pu être fait différemment je pense (comme sur x86 avec le mode réel et mode protégé).

A ce point , un facteur x100 , j'imagine pas lol , alors que de nos jours l'asm ça rapporte quoi comme perf ? x)
Après le Basic n'était pas 'compilé' ou il interpréter ? , si il interprete cela me semble plus normal , si il compilé le compilo devait être vraiment merdique ^^

Ah oui à l'époque c'était interprété bien sur ce qui explique que les basic étaient particulièrement lents...
Les compilateurs étaient très rares (compilateur fortran ou C mais sur de plus grosses machines).
C'est vrai qu'un basic compilé à l'époque ça aurait tout déchiré mais surement que la faible mémoire vive de ces vieilles machines ne le permettaient pas, au mieux tu avais un assembleur (ce qui était déjà pas mal)

Pour les asm , c'est clair que avant ça devait de la m**** , je suis bien content que de nos jours ont est des IDE , et des assembleurs vachement puissant (macro , label temporaire ect) ,sinon chaud de sortir quoique ce soit seul.
Enfin après je sais que par exemple que SNK développer leur jeux Neo Geo sur PC-88/98 , a mon avis il devait existé des asm assez correct dessus.

Oui tu avais quand même des outils "utilisables", l'assembleur que j'ai utilisé sur TO8 était vraiment pas mal, il assemblait assez vite et l'éditeur n'était pas si mal... pour l'époque
Edit: Purée j'ai retrouvé des images de l'assembleur que j'utilisais 





Franchement c'est génial non ? :)

A partir du 68000 on a commencé à avoir des compilateurs C pas trop mal, du coup ça devenait bien plus simple de faire des programmes complexes et qui restent performants...

Ceux qui ont fait Star Fox ont développer le jeux sur MS-Dos (mais il me semble que le kit de la SNES de base était sur MS-Dos aussi).

Vu que Starfox était le premier jeu à utiliser le SFX, il est évident que les outils devaient être assez rudimentaire :p Avec un espèce de macro assembleur pour le SFX. Après ce DSP est assez haut niveau, tu ne le programmes pas exactement comme un CPU classique (il a des instructions avancées style "plot"), donc ça devait se faire assez bien quand même.

oui mais je parlait de l'age , j'ai l'impression que la plupart ont touché a la prog avant leur 18 ans c qui n'est pas mon cas.

En fait ca m'a toujours fasciné le fait de pouvoir créer quelque chose avec du code mais j'ai réellement commencé à programmer quand j'étais au collège (sur calculatrice) vers 14 ans je pense... mais pendant longtemps c'est resté de la programmation en auto-dictat et donc pas mal foireuse !
Même à l'IUT informatique je codais encore comme un naze, j'ai été long à apprendre je trouve

[Invité]

Aucun CPU n'est parfait, le 68K par exemple, les branchements (conditionnels ou non) sont lents, les appels de fonctions sont lents, les interruptions sont lentes comme la mort,on peu facilement trouver des défauts à chaque CPU .
Y'a pas de bons ou mauvais CPU, cela dépend fortement de ce que l'on doit faire,du système dans lequel le CPU évolue, et le résultat final à l'écran pour un système orienté jeux.

y'a qu'a voir ce que les mecs arrive à tirer d'un C64 avec un 6502 à tout juste 1 mhz .

Même à l'IUT informatique je codais encore comme un naze, j'ai été long à apprendre je trouve 

Pareil, je pense que j'ai vraiment pris conscience de la structure du code et de l'optimisation depuis que je code sur PCE, sur des systèmes aussi limités tu es obligé d'avoir ce genre de réflexion,de plus l'ASM aide bcp je trouve à être le plus rigoureux possible .

[Stef]

Aucun CPU n'est parfait, le 68K par exemple, les branchements (conditionnels ou non) sont lents, les appels de fonctions sont lents, les interruptions sont lentes comme la mort,on peu facilement trouver des défauts à chaque CPU .
Y'a pas de bons ou mauvais CPU, cela dépend fortement de ce que l'on doit faire,du système dans lequel le CPU évolue, et le résultat final à l'écran pour un système orienté jeux.

y'a qu'a voir ce que les mecs arrive à tirer d'un C64 avec un 6502 à tout juste 1 mhz .

Quand tu ramènes à la fréquence mémoire, les branchements ne sont pas "si lent" : 10 cycles soit 2.5 cycle en cycle mémoire, 1 pour lire l'instruction, 1 pour lire l'offset et un demi pour la fin du maj du prefetch, c'est raisonnable (tu peux faire un JMP en 8 cycles en utilisant un registre si t'as vraiment besoin). Sur le 65xx j'imagine que c'est 3 cycles minimum non ? ce qui, ramené à la fréquence mémoire, n'est pas mieux... La différence c'est qu'un branchement 8 ou 16 bits ne sera pas plus lent sur 68000.
Après oui les interruptions sont lentes, ca c'est vrai... mais c'est que le mécanisme d'interruption du 68000 est autrement plus complexe.
Le C64 c'est plutot le reste de son architecture qu'il faut remercier surtout je trouve... Sinon dans ce cas, regarde ce qu'un Amiga peut faire avec un 68000 à 7 Mhz (soit 1.75 Mhz sur le BUS), d'ailleurs c'est grace à la sobriété du 68000 sur l'utilisation du BUS mémoire que l'amiga peut faire tant de chose au final car les autres chips peuvent partager la mémoire avec lui. Dans les mêmes conditions, il aurait fallu mettre un 65816 à 1.75 Mhz et je pense que l'amiga n'aurait probablement pas autant brillé :p

[Invité]

Oui quand on compare des CPU de fréquence différente, mais on parle d'archi là, donc on compare comme si les CPU était à fréquence égale donc pas un snes vs Md, mais PCe vs Md .
Parce qu'a ce rythme là tu peux comparer avec le CPU du C64 vs un 68K à 16 mhz, et dire que rapporté à la fréquence, le 68k n'est pas lent .

Sur le 65xx j'imagine que c'est 3 cycles minimum non 

Sur PCe c'est 4 cycles(en 8 ou 16 bits) donc bien plus rapide que sur MD 

La différence c'est qu'un branchement 8 ou 16 bits ne sera pas plus lent sur 68000.

justement étant donnée que les branchements 8 bits sont les plus fréquents tu optimises rien sur 68K, et même si y'a une différence sur 65xxx ,les branchement 16 bits restent plus rapides que sur 68K(quasiment 2x) .

d'ailleurs c'est grace à la sobriété du 68000 sur l'utilisation du BUS mémoire que l'amiga peut faire tant de chose au final car les autres chips peuvent partager la mémoire avec lui. Dans les mêmes conditions, il aurait fallu mettre un 65816 à 1.75 Mhz et je pense que l'amiga n'aurait probablement pas autant brillé :p

Non je te l'ai déjà dit, l'amiga utilise très mal le 68K, tout est copro sur cette machine, le 68K a la priorité la plus basse sur les accès mémoire(chipram)donc ça montre bien que c'est en aucun cas la puce prioritaire dans la machine, tu n'as qu'a voir ce que peut faire un ST en 2D avec juste son 68000, cad pas grand chose, surtout quand tu compares avec un 2gs et son 65816 à 2,68 mhz .
D'ailleurs si tu utilises juste le CPU comme sur ST (et non le hardware), en terme de jeu l'amiga est à la ramasse .

D'ailleurs le 68000 à été choisi justement pour ses accès à la RAM en 4 cycles, ce qui a permis d'utiliser le blitter sur les cycles non utilisés par le CPU pour le faire tourner en parallèle .

[Invité]

@firestqr
Merci pour ton intérêt , j'essayerai de faire un maj prochainement :)

@Stef ouais il claque comme éditeur lol

cad pas grand chose, surtout quand tu compares avec un 2gs et son 65816 à 2,68 mhz .

Comme la SNES lol
Franchement je trouve ça trop faiblard du 2.68 mhz , tu test mon jeu il tourne a 25-36% du cpu (et 50% si tu fait des magies a tout les ennemis).
En ville je crois que le jeu tourne a 55-60% du cpu avec 11 perso a l'écran x)
Et ça c'est parce que j'ai optimisé le code , ma première démo devait a mon avis tourné plus a du 80% de cpu (mais l'envoie au VBlank était mal gérer  du coup ça marchais que bien en PAL lol)...

[Invité]

Comme la SNES lol
Franchement je trouve ça trop faiblard du 2.68 mhz

Mais sur ça je suis d'accord, c'est pour ça que je me prends la tête avec stef parce qu'il critique le 65816 et pas sa fréquence  .
Bien sur que 2,68 c'est pourri, surtout en comptant l'archi hardware de la snes complètement chaotique, et encore plus si tu codes comme un porc dessus .

Mais si tu regardes randering ranger RR² sur snes, franchement manfred trenz montre que quand tu code bien sur ce CPU, même à 2,68 c'est pas mal du tout ..
@5/6 mhz manfred aurait tout éclaté avec son jeu .

[Stef]

Oui quand on compare des CPU de fréquence différente, mais on parle d'archi là, donc on compare comme si les CPU était à fréquence égale donc pas un snes vs Md, mais PCe vs Md .
Parce qu'a ce rythme là tu peux comparer avec le CPU du C64 vs un 68K à 16 mhz, et dire que rapporté à la fréquence, le 68k n'est pas lent .

Mais non Touko ! C'est fou on en a déjà débattu 100x et tu reviens toujours au raisonnement simpliste et débile de comparer des CPU sur leur fréquence :-/ Tu sais pertinemment que ça a aucun intérêt quand les CPU ont été fait pour tourner à des fréquences différentes. Ce qui est important c'est l'efficacité du CPU, à quelle fréquence tu peux le mettre dans telle ou telle architecture.
Ca ne vaut même pas le coup de répondre au reste de ton post où tu te contentes de comparer à la fréquence interne du CPU alors qu'il faut comparer à fréquence externe... Pourquoi le 6502 du C64 tourne si lentement alors que le Z80 ne tourne jamais en dessous de 3.58 Mhz même dans des micro plus vieux ? bon on va pas relancer la discussion là dessus. Au final ce qui faut considérer c'est la performance final du système point.

Non je te l'ai déjà dit, l'amiga utilise très mal le 68K, tout est copro sur cette machine, le 68K a la priorité la plus basse sur les accès mémoire(chipram)donc ça montre bien que c'est en aucun cas la puce prioritaire dans la machine, tu n'as qu'a voir ce que peut faire un ST en 2D avec juste son 68000, cad pas grand chose, surtout quand tu compares avec un 2gs et son 65816 à 2,68 mhz .
D'ailleurs si tu utilises juste le CPU comme sur ST (et non le hardware), en terme de jeu l'amiga est à la ramasse .

Mais n'importe nawak O_o ?? C'est un choix de design (et un bon choix), c'est justement parce-que le 68k a peu besoin du BUS et qui laisse les autres composants en profiter que l'amiga est aussi puissant. Le 2GS est complètement à la ramasse à cause de son CPU, tout le reste de la machine est excellent. Un 68000 à la place du 65816 dans le 2GS aurait tout défoncé...  ce n'est pas pour rien que cette machine n'a connu qu'un succés mitigé.

D'ailleurs le 68000 à été choisi justement pour ses accès à la RAM en 4 cycles, ce qui a permis d'utiliser le blitter sur les cycles non utilisés par le CPU pour le faire tourner en parallèle .

Sans blague... c'est exactement ce que je disais plus tot :p  D'où l'interêt du 68000 qu'ils ont du réduire à 7 Mhz pour laisser suffisamment de cycles pour le reste. Avec un 65816, tu aurais du cadencer le CPU à 1.75 Mhz pour libérer autant de cycle, autant dire que ça aurait été la cata.

Mais sur ça je suis d'accord, c'est pour ça que je me prends la tête avec stef parce qu'il critique le 65816 et pas sa fréquence  .
Bien sur que 2,68 c'est pourri, surtout en comptant l'archi hardware de la snes complètement chaotique, et encore plus si tu codes comme un porc dessus .

Mais si tu regardes randering ranger RR² sur snes, franchement manfred trenz montre que quand tu code bien sur ce CPU, même à 2,68 c'est pas mal du tout ..
@5/6 mhz manfred aurait tout éclaté avec son jeu .

Mais je critique le 65816 pour son architecture simpliste et inefficient qui t'empêche de le cadencer rapidement. Là où tu as un 65816 à 2 Mhz, tu as un 68000 à 8 Mhz... c'est aussi simple que ça. Et un 65816 à 2Mhz versus un 68000 à 8 Mhz y'a pas photo
Si tu dis que dans la SNES ils auraient du mettre un 65816 à 5 Mhz, dans ce cas je vais rétorquer qu'ils auraient du mettre un 68000 à 16 Mhz dans la MD... c'est aussi stupide :p  Même s'ils avaient pu utiliser de la RAM plus rapide (en réduisant la quantité) ils auraient toujours eu le soucis de la ROM (qu'ils ont tenté de gérer comme ils pouvaient en prévoyant la fast-rom).

[Invité]

Mais n'importe nawak O_o ?? C'est un choix de design (et un bon choix), c'est justement parce-que le 68k a peu besoin du BUS et qui laisse les autres composants en profiter que l'amiga est aussi puissant.

Ah bon ??
Sais tu au moins comment fonctionne l'amiga ??, je pense que non ..
D'ailleurs tu te contredis, du choix du 68K pour ses perfs, on passe à c'est car il laisse des cycles aux autres composants(ce qui est vrai).
Et je persiste, les perfs de l'amiga sont liées a son chipset, pas au 68K,tu peux demander à ninja_SCX ici qui fait partie du groupe scoopex .

Dsl, mais sérieux j'ai pas envie de répondre sur des sujets débattus 1000x déjà .

Tu parles encore de roms alors que tu sais pertinemment que la Md a besoin de rom à 150 ns (soit aussi rapides que sur PCE) a cause de son DMA, même si le CPU peut se contenter de bcp moins .

Je te l'avais dit, sur spritesminds ils te l'ont dit aussi,tu peux te contenter de roms lentes sur Md, à la seule condition de ne pas utiliser le DMA ce qui est fortement improbable même dans les premiers jeux .

Si tu considère le 65816 pourri, tu considères aussi le CPU de la PCE pourri, malgré qu'il tourne à 7,16 mhz, et là on est plus dans la même cours,et je considère le 68k comme lent,et il l'est,c'est un CPU pas du tout adapté a une console en terme d'efficacité, point barre .

Un CPU qui génère un code lourd qui met 3 plombes à faire un saut conditionné,appel/retour de fonctions,interrutpions, accès mémoire, j'appelle pas ça un CPU efficace dans un système limité qui à besoins surtout d'efficacité comme une console de jeu .
Bon je vais arrêter parce que de toutes façons ça ne mène à rien,avec toi le débat a toujours été impossible à part dire que tout ce qui sort de l'univers SEGA c'est de la merde .