Meilleurs algo d'un test par bouding box

En fait tu écris (avec ton CPU) dans des emplacements mémoires particuliers qui représentent les ports des différents périphériques (processeur video, sonore...). Bien sur tu as toujours une doc pour t'expliquer comment programmer les différents périphériques.

si comprends bien tu appelles les fonctions des périphériques utilisés a travers le 68000?

Tu "programmes" les périphériques via le 68000, c'est pour ça que le CPU est quand même très important dans une machine

Pour la megadrive, tu as ce document (d'un certain Fonzie) pour te donner une idée : www.genny4ever.net/g4e_modules2/download.php?file=sega_md_prog_intro

ok je comprends mieux.

Autant le basic c'était les doigts dans le nez, mais là, pour de l'ASM c'est juste insurmontable pour moi. Franchement c'est quand même impressionnant de voir des gars, programmer en ASM pour le plaisir 

merci 

PS: Merci pour le liens 

Au fait si le ZP prend 1 cycle en plus sur le 6280, kel interet de l'utiliser alors ? du coup t'es a 4 cycles comme un acces memoire normal ? ou le normal prend 5 cycles sur pce ?

Exact le normal prend 5 cycles, mais par contre l'indexé n'ajoute aucune pénalité, et j'ai pas les pénalités en cas de franchissement de page .

J'ai commencé en début d'année (pas le PCE) et je dois reconnaitre qu'avoir un VDP te facilite grandement les choses.

Ca permet de faire des effets sympas, et aussi de pas dépenser son énergie à faire des sprites/scrollings soft .

Autant le basic c'était les doigts dans le nez, mais là, pour de l'ASM c'est juste insurmontable pour moi. Franchement c'est quand même impressionnant de voir des gars, programmer en ASM pour le plaisir 

C'est ce qu'on se dit tous au début je pense ..

Comme j'ai dit au doc l'idéal est de commencer avec un langage que tu connais et qui te permet d'insérer de l'assembleur, là la transition se ferra en douceur et naturellement .
Un foi que tu es à l'aise avec l'ASM, je te garanti que le basic t'y toucheras plus .

Une console avec un z80 ou tu changes de cpu ?

Il avait parlé de SMS un peu plus haut, donc c'est surement ça ..

@stef: comment marche la window sur MD, j'ai du mal à comprendre  

Exact le normal prend 5 cycles, mais par contre l'indexé n'ajoute aucune pénalité, et j'ai pas les pénalités en cas de franchissement de page .

Ah donc à la place des 76 cycles tu aurais 16 cycles en plus sur le 6280 (1 sur l'accés en ZP mais également 1 sur l'accés normal) soit 92 cycles à la place des 76.
Je pense que ces pénalités sur les accés mémoires sont la raison pour laquelle le CPU de la PCE peut aller si vite. Il est moins éprouvant qu'un 6502 sur les accés mémoire random... mais du coup j'imagine que tu ne codes pas toujours de la même manière entre un 6280 et un 6502, surtout que le 6280 ajoute de nouvelles instructions.

TOUKO a écrit:Ca permet de faire des effets sympas, et aussi de pas dépenser son énergie à faire des sprites/scrollings soft .

Oui, un système graphique avancé est très rapidement dévellopé (15 jours) contrairement au CPC où tu peux mettre plusieurs mois pour le concevoir (celui de R-Type a pris facile 3 mois, celui de notre prochain projet au moins 6 mois)

TOUKO a écrit:Il avait parlé de SMS un peu plus haut, donc c'est surement ça ..

Rendez vous dans quelques semaines pour une (grosse) surprise   

TOUKO a écrit:@stef: comment marche la window sur MD, j'ai du mal à comprendre  

En gros c'est une matrice comme les deux autres sauf qu'elle a pas de scroll.A ce que j'ai compris tu peux choisir d'afficher ou pas les cellules.Par contre, elles sont censées être opaques mais j'ai vu des jeux où il semble qu'il y a une couleur transparente donc il y a peu être un trick à ce niveau.

fanoplusplus64K a écrit:En gros c'est une matrice comme les deux autres sauf qu'elle a pas de scroll.A ce que j'ai compris tu peux choisir d'afficher ou pas les cellules.Par contre, elles sont censées être opaques mais j'ai vu des jeux où il semble qu'il y a une couleur transparente donc il y a peu être un trick à ce niveau.

Elle peut être transparente mais en général tu ne le fais pas car la window est juste une partie du plan A qui est figé (en interne), du coup le plan A ne s'affiche pas là ou se trouve la window. Pas mal de jeux préfèrent utiliser des sprites pour le HUD ainsi tu conserves les 2 plans full screen.

Je dois avouer que cette window me fait poser beaucoup de questions car il y a certains jeux MD qui semblent utiliser des sprites pour le HUD mais bizarrement le compte de sprites à l'écran à l'air de dépasser le max du VDP.Il est possible de faire du multiplexing avec le VDP de la MD ?

stef j'ai un peu modifier ta routine de test de collisions

Code:

struct box
{
; // déclarées en tant que tableaux en ZP
   xmin_low:    .ds  30
   xmax_high:   .ds  30
   ymin_low:    .ds  30
   ymax_high:   .ds  30
};

3     ldy <numEnemies
2     ldx #0
5

.loop

// TEST on X coordinates

3     lda   <player.xmax_low
4     cmp   <enemies.xmin_low,X
3     lda   <player.xmax_high
4     sbc   <enemies.xmin_high,X
2     bcc   .no_collid_cc
16

3     lda   <player.xmin_low
4     cmp   <enemies.xmax_low,X
3     lda   <player.xmin_high
4     sbc   <enemies.xmax_high,X
2     bcs   .no_collid_cs
16

// TEST on Y coordinates

3     lda   <player.ymax_low
4     cmp   <enemies.ymin_low,X
3     lda   <player.ymax_high
4     sbc   <enemies.ymin_high,X
2     bcc   .no_collid_cc
16

3     lda   <player.ymin_low
4     cmp   <enemies.ymax_low,X
3     lda   <player.ymin_high
4     sbc   <enemies.ymax_high,X
2     bcs   .no_collid_cs
16

.collid
2+1   lda  #1
7     rts
9

.no_collid_cc
.no_collid_cs
2+1     inx
2     dey
3     bne .loop
12

2-1   lda  #0
7     rts
8

j'ai réorganiser les tableaux en données 8 bit plutôt que 16 ,et maximisé la taille du code (un peu) .
tu gagnes 4 cycles/boucles .

La syntaxe de la déclaration est foireuse mais c'est juste pour la compréhension .

Ah donc à la place des 76 cycles tu aurais 16 cycles en plus sur le 6280 (1 sur l'accés en ZP mais également 1 sur l'accés normal) soit 92 cycles à la place des 76.
Je pense que ces pénalités sur les accés mémoires sont la raison pour laquelle le CPU de la PCE peut aller si vite. Il est moins éprouvant qu'un 6502 sur les accés mémoire random... mais du coup j'imagine que tu ne codes pas toujours de la même manière entre un 6280 et un 6502, surtout que le 6280 ajoute de nouvelles instructions.

Non juste 9,les indexés en ZP prennent pareil,et les pénalités sont dues au MMU intégré au CPU .
Exact, tu n'as pas toujours la même approche, en grande partie grâce aux nouvelles instructions et mode d'adressage .
En fait ce serrait comme un 65c02 .

Oui, un système graphique avancé est très rapidement dévellopé (15 jours) contrairement au CPC où tu peux mettre plusieurs mois pour le concevoir (celui de R-Type a pris facile 3 mois, celui de notre prochain projet au moins 6 mois)

Le prochain c'est confidentiel ??  

Rendez vous dans quelques semaines pour une (grosse) surprise  

LOL, tu vas refaire une version de RTYPE pour C64 ??  

Elle peut être transparente mais en général tu ne le fais pas car la window est juste une partie du plan A qui est figé (en interne), du coup le plan A ne s'affiche pas là ou se trouve la window. Pas mal de jeux préfèrent utiliser des sprites pour le HUD ainsi tu conserves les 2 plans full screen.

D'accord, je pense que j'avais compris comme fano, CAD un layer fixe mais indépendant,et du coup je comprenais pas pk il valais mieux que les tiles soient opaques ..

TOUKO a écrit:
Le prochain c'est confidentiel ??  

Bien sur sinon ça serait pas amusant   

TOUKO a écrit:
LOL, tu vas refaire une version de RTYPE pour C64 ??  

Oh le bon gros troll, arrête où tu vas reveiller youki   
Après , pourquoi pas , j'ai rien contre le C64, il a des sacrés ressources le bougre.

Bien sur sinon ça serait pas amusant   

Merde lol, mais je suis sur que ça a fuité sur cpcrulez   

Oh le bon gros troll, arrête où tu vas reveiller youki   

Le troll c'est pour amuser les vieux cons comme nous, mais au fond on aime bien ça ..  

Après , pourquoi pas , j'ai rien contre le C64, il a des sacrés ressources le bougre.

Vu le monde qui bosse encore dessus, c'est peut être normal aussi d'arriver à l'essorer jusqu'à la moelle ..

TOUKO a écrit:stef j'ai un peu modifier ta routine de test de collisions

Code:

struct box
{
; // déclarées en tant que tableaux en ZP
   xmin_low:    .ds  30
   xmax_high:   .ds  30
   ymin_low:    .ds  30
   ymax_high:   .ds  30
};

3     ldy <numEnemies
2     ldx #0
5

.loop

// TEST on X coordinates

3     lda   <player.xmax_low
4     cmp   <enemies.xmin_low,X
3     lda   <player.xmax_high
4     sbc   <enemies.xmin_high,X
2     bcc   .no_collid_cc
16

3     lda   <player.xmin_low
4     cmp   <enemies.xmax_low,X
3     lda   <player.xmin_high
4     sbc   <enemies.xmax_high,X
2     bcs   .no_collid_cs
16

// TEST on Y coordinates

3     lda   <player.ymax_low
4     cmp   <enemies.ymin_low,X
3     lda   <player.ymax_high
4     sbc   <enemies.ymin_high,X
2     bcc   .no_collid_cc
16

3     lda   <player.ymin_low
4     cmp   <enemies.ymax_low,X
3     lda   <player.ymin_high
4     sbc   <enemies.ymax_high,X
2     bcs   .no_collid_cs
16

.collid
2+1   lda  #1
7     rts
9

.no_collid_cc
.no_collid_cs
2+1  inx
2     dey
3     bne .loop
12

2-1   lda  #0
7     rts
8

j'ai réorganiser les tableaux en données 8 bit plutôt que 16 ,et maximisé la taille du code (un peu) .
tu gagnes 4 cycles/boucles .

Ah ouais mais là l'organisation des tables box est assez complexe :p
Tu vas perdre pas mal de temps pour les remplir et tu dois connaitre le nombre de sprites visibles pour calculer l'offset entre elles. Ca reste possible cela dit mais là faut voir vraiment si tu y gagnes à la fin Mais c'est bien vu quand même, ça réduit encore le nombre de cycle pour la collision :p

Non juste 9,les indexés en ZP prennent pareil,et les pénalités sont dues au MMU intégré au CPU .
Exact, tu n'as pas toujours la même approche, en grande partie grâce aux nouvelles instructions et mode d'adressage .
En fait ce serrait comme un 65c02 .

J'ai du mal à comprendre, tu me dis que les accés en page zero font 4 cycles et maintenant tu me dis que c'est pareil ? il faudrait savoir :p ? c'est 3 ou 4 cycles pour un accés classique en ZP ?

Ah ouais mais là l'organisation des tables box est assez complexe :p
Tu vas perdre pas mal de temps pour les remplir et tu dois connaitre le nombre de sprites visibles pour calculer l'offset entre elles. Ca reste possible cela dit mais là faut voir vraiment si tu y gagnes à la fin  Mais c'est bien vu quand même, ça réduit encore le nombre de cycle pour la collision :p

Non du tout, pour les remplir tu fais pareil que pour les lire, vu que tu fonctionnes en 8 bit, ça pose aucun soucis .
Ces données ne sont séparées que par un label, si tu écris dans xmin_low+30, serra pareil que d'écrire dans xmin_high .
N'oublies pas non plus que t'as pas de malloc pour allouer dynamiquement tes structures .
Là grosso modo j'ai alloué de l'espace pour 30 sprites(ennemis + bullets) soit 120 octets ..
La ZP est de 256 octets, donc ça va .
Mais ton ancien algo faisait la même chose mais pas organisé pareil .

J'ai du mal à comprendre, tu me dis que les accés en page zero font 4 cycles et maintenant tu me dis que c'est pareil ? il faudrait savoir :p ? c'est 3 ou 4 cycles pour un accés classique en ZP ?

alors ça va être plus clair comme ça :
un lda/sta ZP sur 6502 c'est 3 cycles
un lda/sta ZP sur 6280 c'est 4 cycles

un lda/sta ZP , X (Y) sur 6502 c'est 4 cycles
un lda/sta ZP , X (Y) sur 6280 c'est 4 cycles
 

En gros dans ton algo, tu rajoutes 1 cycles à tout tes instructions à 3 cycles .

Ah oui mais moi je n'utilisais la ZP que pour la box du player, pas celle des ennemis car les 256 octets sont trop limitant pour ça. Une box c'est 8 octets (car 4*16 bits), pour 30 ennemies ça fait déjà 240 octets. C'est pour ça que je ne coprenais pas tes calculs de cycles ;)Après pourquoi pas mais alors ça veut dire que tu dois traiter que 30 ennemies max, ça ne marchera plus au dessus car tu ne peux plus précalculer une seule fois les boxes pour toutes les collisions :-/

Ah ok, mais en asm 65xx un "<"variable, indique la ZP .
Pour la ram classique c'est soit variable tout court ou _variable, ça permet de facilement faire la différence entre les 2.

Une box c'est 8 octets (car 4*16 bits), pour 30 ennemies ça fait déjà 240 octets

Ah oui effectivement ..
Je suis partie dans ta logique, mais en pensant juste aux valeurs à ajouter pour créer les tableaux   , donc effectivement ça colle pas .

Il faut faire
NB_ENNEMIS    .equ      30

; // Allocation dans la RAM
.bss
_xmin1_low:   .ds  NB_ENNEMIS 
_xmin1_high:  .ds  NB_ENNEMIS 
_xmin2_low:   .ds  NB_ENNEMIS 
_xmin2_high:  .ds  NB_ENNEMIS 

_ymin1_low:   .ds  NB_ENNEMIS 
_ymin1_high:  .ds  NB_ENNEMIS 
_ymin2_low:   .ds  NB_ENNEMIS 
_ymin2_high:  .ds  NB_ENNEMIS 

; // Pareil qu'en faisant la déclaration comme ça 
_xmin1_low:   .ds  NB_ENNEMIS * 8
.code

Donc pour la lecture/écriture dans la ram c'est :

lda/sta  absolute 6502 c'est 4 cycles
lda/sta  absolute 6280 c'est 5 cycles

lda/sta  absolute , X (Y) 6502 c'est 4+ cycles
lda/sta  absolute , X (Y) 6280 c'est 5 cycles

Donc là oui j'aurait au max 17 cycles en plus sur le 6280, tout dépend si ton x franchit une (ou plusieurs) pages ou pas en indexant les tabs .
Donc un 15/16 en plus me parait juste .

Donc du coup si dans ton algo tu pensais à la ram, les cycles ne sont plus bons pour les tableaux des ennemis .

Ah oui effectivement ..
Je suis partie dans ta logique, mais en pensant juste aux valeurs à ajouter pour créer les tableaux   , donc effectivement ça colle pas .

Il faut faire
NB_ENNEMIS    .equ      30

; // Allocation dans la RAM
.bss
_xmin1_low:   .ds  NB_ENNEMIS 
_xmin1_high:  .ds  NB_ENNEMIS 
_xmin2_low:   .ds  NB_ENNEMIS 
_xmin2_high:  .ds  NB_ENNEMIS 

_ymin1_low:   .ds  NB_ENNEMIS 
_ymin1_high:  .ds  NB_ENNEMIS 
_ymin2_low:   .ds  NB_ENNEMIS 
_ymin2_high:  .ds  NB_ENNEMIS 

; // Pareil qu'en faisant la déclaration comme ça 
_xmin1_low:   .ds  NB_ENNEMIS * 8
.code

Oui voilà, mais c'est pour ça que tout mettre en zero page c'est contraignant.
Ca l'est beaucoup moins quand tu mets en mémoire classique, surtout avec ton arrangement mémoire... y'aura juste une pénalité de temps en temps sur le 6502.

Donc là oui j'aurait au max 17 cycles en plus sur le 6280, tout dépend si ton x franchit une (ou plusieurs) pages ou pas en indexant les tabs .
Donc un 15/16 en plus me parait juste .

Ok je comprends mieux =)

Donc du coup si dans ton algo tu pensais à la ram, les cycles ne sont plus bons pour les tableaux des ennemis.

Pourquoi ils ne sont plus bons ? c'est bien 4 cycles sur 6502 ??
Sauf en cas de cross bank où t'as un cycle de pénalité ?

Ah ok, mais en asm 65xx un "<"variable, indique la ZP .
Pour la ram classique c'est soit variable tout court ou _variable, ça permet de facilement faire la différence entre les 2.

Ah ok désolé je n'avais pas compris cette subtilité dans la syntaxe :p

Oui voilà, mais c'est pour ça que tout mettre en zero page c'est contraignant.
Ca l'est beaucoup moins quand tu mets en mémoire classique, surtout avec ton arrangement mémoire... y'aura juste une pénalité de temps en temps sur le 6502.

Exact la ZP, n'est pas faite pour avoir bcp de données en général .
On la garde pour les pointeurs et les accès critiques,notamment pour les traitements dans les interruptions .
Bien sur le but et de l'utiliser au maximum, mais dans un cas comme celui là c'est pas possible .

Ce type d'arrangement quand tu as l'habitude, t'évite de faire des inx ou iny sans arrêt entre chaque accès, un seul suffit à la fin .
Comme toi tu dois faire sur 68000 quand tu crées tes données, tu dois surement les organiser directement pour qu'elles soient les plus efficaces possibles lors des traitements .

Ok je comprends mieux =)

Oui du coup comme je lisais que des accès en ZP dans ton algo je comprenais pas ..  

Pourquoi ils ne sont plus bons ? c'est bien 4 cycles sur 6502 ??
Sauf en cas de cross bank où t'as un cycle de pénalité ?

Oui t'inquiètes, car au final tu mets les box du joueur  en ZP et les données ennemis en RAM .
Donc oui c'est bon ..

ah ok désolé je n'avais pas compris cette subtilité dans la syntaxe :p

Pas de soucis, je comprends que c'est pas en faisant 4 lignes de code sur un CPU que tu connais pas, que tu peux tout maîtriser .
D'où mon incompréhension sur le nombre de cycles, avec mon habitude de la notation et les cycles du 6280, c'est pas toujours évident de compter les cycles sur le 6502 .

je viens de trouver ça dans une doc officielle des 65xx,sur le système de pipe du CPU .

Code:

Pipelining
The 65x microprocessors have the capability of doing two things at once: the 6502 can be carrying on
an internal activity (like an arithmetic or logical operation) even as it’s getting the next instruction byte from the
instruction stream or accessing data in memory.
A processor is driven by a clock signal which synchronizes events within the processor with memory
accesses. A cycle is a basic unit of time within which a single step of an operation can be performed. The
speed with which an instruction can be executed is expressed in the number of cycles required to complete it.
The actual speed of execution is a function both of the number of cycles required for completion and the
number of timing signals provided by the clock every second. Typical clock values for 65x processors start at
one million cycles per second and go up from there.
As a result of the 6502’s capability of performing two different but overlapping phases of a task within
a single cycle, which is called pipelining, the 65x processors are much faster than non- pipelined processors.
Take the addition of a constant to the 6502’s eight-bit accumulator as an example.This requires five
distinct steps:
Step 1: Fetch the instruction opcode ADC.
Step 2: Interpret the opcode to be ADC of a constant.
Step 3: Fetch the operand, the constant to be added.
Step 4: Add the constant to the accumulator contents.
Step 5: Store the result back to the accumulator.
Pipelining allows the 6502 to execute steps two and three in a single cycle: after getting an opcode, it
increments the program counter, puts the new program address onto the address bus, and gets the next program
byte, while simultaneously interpreting the opcode. The completion of steps four and five overlaps the next
instruction’s step one, eliminating the need for two additional cycles.
So the 6502’s pipelining reduces the operation of adding a constant from five cycles to two!
The clock speed of a microprocessor has often been incorrectly presumed to be the sole determinant of
its speed. What is most significant, however, is the memory cycle time. The 68000, for example, which
typically operates at 6 to 12 megahertz (MHz, or millions of cycles per second) requires four clock periods to
read or write data to and from memory. The 65x processors require only one clock period. Because the 6502
requires fewer machine cycles to perform the same functions, a one-megahertz 6502 has a throughput unmatched
by the 8080 and Z80 processors until their clock rates are up to about four MHz.
The true measure of the relative speeds of various microprocessors can only be made by comparing
how long each takes, in its own machine code, to complete the same operation.

Effectivement très intéressant ce processus parallèle, c'est très ingénieux.

Bon fano, laisse le z80 de côté, et mets toi à la PCE   

lol ça a failli car j'ai touché ma duo en début d'année mais j'ai eu comme qui dirait une interruption avec une proposition de projet très intéressant sur une console mal exploitée  

C'est une super machine la PCE mais je lui reproche deux choses :
- Le format hucard est très singulier et je ne sais pas si il est possible de produire des jeux en hucard
- C'est une console qui a été bien exploitée à mon gout (quand je vois R-Type (et encore c'est pas le mieux) qui explose les versions 16 bits (pas dur tu me diras   ))

Ceci dit , c'est console idéale (avec la MD?) pour faire un jour le shmup de mes rêves

 Le format hucard est très singulier et je ne sais pas si il est possible de produire des jeux en hucard

Si mais c'est pas aussi simple qu'avec des cartouches standards,il vaut mieux les faire sur CD-ROM, plus simple et pratique à produire en qualité pros .
La difficulté ce n'est pas la prod de la cartouche en elle même, c'est de conserver le format carte de crédit qui est chiant .
Tu peux faire facilement des roms pour les mettre sur une flash card par contre .

C'est une console qui a été bien exploitée à mon gout (quand je vois R-Type (et encore c'est pas le mieux) qui explose les versions 16 bits (pas dur tu me diras   ))

Ceci dit , c'est console idéale (avec la MD?) pour faire un jour le shmup de mes rêves

Effectivement, ces 2 consoles sont simples à programmer, de plus avec la PCE, tu peux même partir ensuite vers la Supergrafx, qui est grosso modo une PCE avec un second VDC et 32 ko de ram .

En shoot PCE, la référence c'est ça : https://www.youtube.com/watch?v=q3bOjMekDCY

Cependant que ce soit la MD ou la PCE/SGX, tu pourras facilement le faire, reste à savoir avec quelle architecture tu serras le plus à l'aise  

mais j'ai eu comme qui dirait une interruption avec une proposition de projet très intéressant sur une console mal exploitée  

La GX4000  

La pauvre GX , ce bon vieux mouton à trois pattes    (sorti avec au moins 4 ans de retard   )

Je suis surtout interessé par le support hucard car il permet de profiter dès la pc-engine de "base".Le support CD c'était surtout pour pouvoir jouer à R-Type PCE et Castelvania en "vrai"   

Par contre, je dois avouer que j'ai du mal à trouver de la doc de "qualité" pour la pce (genre la doc officielle SEGA) et pour le hu6280 , tu sais où je peux trouver ça ?

Raaah castlevania une tuerie ce jeu ..

Pour la doc, je peux t'envoyer tout ce que j'ai ..
C'est en vrac mais mieux que rien, pas de doc officielle hélas  

Sinon le support Cd est très courant su PCE, c'est pas comme le MCD de sega ..
D'ailleurs tout les homebrew sortent en CD sur nec .

ça serait gentil , je t'envoie mon mail par mp  

Ok ,c'est en cours d'upload  

PS: putin je viens de me rendre compte que la doc sur le CPU, je me l'étais envoyé à moi même, et non dans ta boite   
Bon c'pas grave elle est dans la doc complète .

TOUKO a écrit:PS: putin je viens de me rendre compte que la doc sur le CPU, je me l'étais envoyé à moi même, et non dans ta boite   

J'espère que tu l'as bien reçue 

 
Niquel,on est jamais mieux servi que par soit meme lol .
Depuis le temps que je la cherchais cette doc  

TOUKO a écrit:Bon fano, laisse le z80 de côté, et mets toi à la PCE   

Le pipeline comme tu l'appelles existe sur quasi tout les CPU, sur Z80, sur 68000... je dois admettre que je suis étonné cependant qu'il y ait autant de niveau sur le 6502 vu la simplicité de celui ci, je vois mal comment tu peux faire rentrer 5 stages de pipeline dans un CPU qui contient 3000 transistors tout compris.
Et puis pour le rapport de 1/4 comparé au Z80, ils y sont allé un peu fort non  


J'ai trouvé ça, tiré du site C= Hacking (une vrai bible pour tout développeur) et donc par des pro du 6502 :

The 6502 CPU was designed to be a low cost 8 bit CPU. It is fairly
cheap to interface to and will quickly access cheap "slow" memory. It
is also very quick and responsive to interrupts. It can perform 8 bit
binary and BCD addition with carry. The Z80 CPU was designed to be the
ultimate 8 bit CPU. It has several 8 bit internal registers which can
be used in 16 bit pairs. It has a full instruction set that includes
some nibble oriented instructions and a 16 bit add. On average a 1 Mhz
6502 is about as effective as a 2 Mhz Z80, and Z80s are generally
available in faster speeds. The C128 has a Z80 CPU that could be used
for numerical work, but it was poorly integrated into the C128 and
offers us no advantage over the 6502 (other than executing CP/M and
other Z80 code). Neither CPU has a multiply instruction. The fastest
way to multiply with a Z80 is with the simple binary shift and add
method. However, this is not true with the 6502! The fastest way to do
math on a 6502 is by using table look ups. This opens the door for
creative programming solutions.