Re: Z80 Vs 6502, FIGHT !

[youki]

Le compte est bon!!!

[Invité]

LOL, ok merci pour l'info ..

PS: qu'il est con ce youki

[vingazole]

Déjà avec le 8086 je n'utilisais jamais le BCD, j'aime pô^^

Je me suis contenté d'un tableau de 8 octets codant chaque chiffre du score, du coup l'affichage à l'écran est trivial (mes tiles de chiffres sont stockées dans l'ordre à partir de $186):

Code:

aff_nombre:    ld c,$19    ; $19 (%00011001 : attribut opaque, 2eme palette, tile $1xx)
                ld b,8
 
      afn0:    ld a,(de)
                inc de

                add a,$86  ; $[1]86 : symbole '0'
                ld (hl),a
                inc hl
                ld (hl),c
                inc hl
 
                djnz afn0
                ret


[Invité]

Et pourtant, en mode BCD c'est bcp plus rapide .

Code:


 ; // Le reg A contient la partie basse du score, et le reg X la partie haute
                        sed                        ; // Active le mode décimal
         clc         
         adc    _score               ; // Unites & dixaines
         sta    _score
         txa
         adc      _score + 1            ; // Centaine & milliers         
         sta    _score + 1
         cla    
         adc    _score + 2            ; // 10 aine de millier & 100 aine de millier
         sta    _score + 2
         cla    
         adc    _score + 3            ; // 10 aine de millier & 100 aine de millier
         sta    _score + 3
         cla    
         adc    _score + 4            ; // 10 aine de millier & 100 aine de millier
         sta    _score + 4
         cld                        ; // Désactive le mode décimal   

Soit 54 cycles,moins si utilisation de la zero page(44 cycles) pour un score sur 10 chiffres ..

Tu fais combien avec ta méthode à l'ancienne

[vingazole]

Oui, je me doute que s'"ils" ont permis de faire du BCD c'est que c'est plus efficace !

Mais de toutes façons ce que tu gagnes sur l'addition tu dois le perdre sur l'affichage (masquage avec $0F pour avoir le chiffre des "unités" et 4 décalages pour avoir celui des "dizaines")...

[Invité]

Effectivement, mais je suis sur que je reste gagnant au final, et surement de bcp .
Car avec ta boucle tu es obligé de gérer manuellement le compteur, et c'est assez gourmand en cycles .

[vingazole]

Peut-être, je n'ai pas l'intention d'optimiser pour gagner quelques cycles sur des événements aussi sporadiques

[Invité]

C'est sur mais tu dis ça à chaque fois, bientôt tu n'auras plus assez de cycles pour faire tourner ton jeu

[vingazole]

ça c'est ma hantise, d'autant qu'il me reste encore un gros morceau à ajouter : la musique et les bruitages

[Invité]

C'est pour ça que perso, j'essaye d'optimiser directement en créant la fonction, au moins c'est fait .
C'est vrai que souvent c'est tentant de dire "bon elle marche, j'optimiserai plus tard" ..

[fzu2801]

Le compte est bon!!!

Moi j'ai que 127 ...

[vingazole]

C'est pour ça que perso, j'essaye d'optimiser directement en créant la fonction, au moins c'est fait .
C'est vrai que souvent c'est tentant de dire "bon elle marche, j'optimiserai plus tard" ..

Oui, moi aussi j'essaie d'optimiser au maximum "en écrivant", mais bon sur tout ce qui n'est pas dans la boucle principale in-game ou ce qui n'est pas critique à mes yeux je me relâche !

Par contre je m'efforce de bien réfléchir à mes structures de données pour être efficace et ne pas avoir à y revenir, d'autant que le z80 n'offre pas beaucoup de modes d'adressage (on a un adressage indexé à peine potable et pas grand chose au-delà), je crois que le 6502 est pareil de ce point de vue, non ?

[Invité]

Y'a pas foule non plus, mais l'indexé fait partie des atouts du 6502 ..

[vingazole]

Il me semble avoir lu que sur 6502 tu pouvais faire de l'indexé par rapport à un registre 16 bits, or X et Y sont bien des registres 8 bits !?

[65c02]

tu peux faire adresse 16 bits + index 8 bits ou (adresse 16 bits) + index 8 bits
tu peux aussi faire adresse 8 bits + index 8 bits (c'est ça la page zéro qui va plus vite en accès)

[Invité]

J'ai toujours pas compris comment les mecs pouvaient pas aimer le 6502, franchement ces CPU sont d'une simplicité ...

En comparaison quand tu regardes le tableau d'instructions du Z80, c'est limite encore plus incompréhensible que celui du 68000 .

[youki]

Ouais, moi aussi... mais bon apparrment il y en qui aime bien la complexité, et aussi compliqué les trucs simple.... y'en a meme qui en on fait leur boulot... ya qu'a voir dans ma boite...

Ils partent de principe que plus c'est compliqué plus ca a l'air intelligent.

[65c02]

Oui... :)
Et puis le nombre d'instructions d'un Z80...
C'est juste hallucinant.
Si tu regarde juste les opcodes documentés, entre ceux qui tiennent sur un octet, ceux qui commencent par $cb, $dd, $fd, $de, $ddcb, ou par $fdcb
Ca en fait un paquet d'instructions. Facile plus de 1000 (je n'ai même pas envie de compter :) )

Alors que même sur les derniers 6502 on ne dépasse pas les 256 instructions (illégal opcodes compris)

Et puis le timing des opcodes en Z80 c'est que du par coeur
sur 6502 c'est juste quelques règles logiques.

bref, le 6502 c'est hyper simple et fluide.

[Invité]

Oui c'est ça, sans être partisan de quoi que ce soit, sur 65xxx t'as un opcode -> tant de cycles, et basta ..

Sur z80 (ou 68000), tu as la force du vent, et l'age du capitaine à prendre aussi en compte lol ..
Après je pense qu'avoir 1000 opcodes doit rassurer, mais c'est hyper chiant a t'y retrouver .

Avant de m'y mettre à l'asm 65xxx, j'avais l'a priori de ce que pas mal de devs disaient sur ces CPU (en fait des habitués du Z80),
Et qu'il était complexe, que trop peu de registres etc ..

Je pense que si ton soucis est de faire un truc qui marche facilement, et que le nombre de cycles tu t'en fou, le z80 est peut être plus simple .

J'aime bien les explications là dedans : http://members.multimania.nl/rubynl/tuts/optimus/6510-z80.htm

Je pense qu'elles sont très explicite de la différence des 2 archis .

[65c02]

Mais bon, si on a autant d'instructions sur Z80, c'est pour pouvoir grappiller des cycles de ci de à
Du genre : les instructions LDI et LDIR

Chacune de ces instructions prend le contenu pointé par HL pour le mettre à l'adresse pointé par DE et décrémente BC
Sauf que LDI le fait une fois et LDIR le fait jusqu'à ce que BC soit = 0 (une sorte de memcpy)
Et en regardant le nombre de cycle LDIR fait 5 cycles par itération (4 pour la dernière) et LDI en fait 4 cycles.
En gros, grâce à LDIR on a un JR NZ pour 1 cycle au lieu de 3.

Mais du coup, on a deux instructions qui ne sont pas utile de la même façon.

Si on veut faire un memcpy simple il vaut mieux un LDIR
Si on veut de la vitesse pure, il vaut mieux dérouler les LDI.

C'est sympa, c'est compact, c'est magique, ça demande de l'expérience, ça mérite un vrai salaire, c'est du Z80.

Alors que sur 6502 faut tout faire soit même

LDX nb_to_copy
loop
LDA (adRead),X
STA (adWrite),X
DEX
BNE loop

Et pis c'est tout (et encore la je ne copie pas plus de 256 octets, sinon faut faire une autre boucle par dessus)

(Oui, j'aime bien le Z80 aussi :) )

[Invité]

Je pense aussi que le z80 est un bon CPU, mais je le trouve juste plus complexe .

Tu viens surement de souligner un des manques des 65xx, CAD les transferts de blocs ..
Même si la méthode reste très simple, elle semble moins performante, mais pas de bcp (??)

[65c02]

Même si la méthode reste très simple, elle semble moins performante, mais pas de bcp (??)

bah pour le coup, si
le Z80 fait en 4 cycles copie, changement des pointeurs et décrémenter le compteur
sur 6502 ça prend
4 cycles * 2 pour lire/écrire en page zéro ou 5 * 2 ailleurs
2 cycles pour décrémenter le compteur
3 cycles pour boucler

Ça fait déjà entre 12 et 15 cycles pour une copie de max 256 octets.
Après, y a surement des ruses de sioux en code auto-modifié pour aller plus vite.
Mais on quitte le code générique pour entrer dans le spécifique.

C'est un peu ça en fait la différence entre le 6502 et le z80.
Un code 6502 va très vite être dédié à sa tache.
On ne fait pas un copie de data en générale, on fait la copie du buffer bidule parce qu'on sait qu'il est de cette taille et qu'on a choisit exprès de le mettre à telle adresse pour utiliser une bidouille qui fait économiser quelques cycles sur ce coup là.

[Invité]

Ah oui quand même ...

Pour le code automodif, je suis pas sur que tu y gagnes .

Sinon tu as cette solution (je l'ai jamais utilisée)

Code:


Set T Flag (SET)

Function The T flag in the status register is set to 1. The T flag is called the "Memory Operation Flag;",
when this flag is set all the instructions that normally use the A register act differently,
 I don't know exactly if all the instructions are affected but I'm sure for AND, EOR, OR & ADC.
 In place of using the A register the instruction use the memory location in ZP pointed by the X register,
 so for example if you use SET followed by ADC #10, the CPU will do ZP[X] = ZP[X] + 10.

Adressing Modes & Opcodes Addressing Mode Syntax Opcode # of bytes # of cycles
Implied SET F4 1 2


Flags Affected N V T B D I Z C
- - 1 - - - - -

Et je sais pas si cette instruction existe sur un 6502 .

EDIT: non elle existe que sur le 6280

[vingazole]

le Z80 fait en 4 cycles copie, changement des pointeurs et décrémenter le compteur

Attention l'instruction LDI qui fait (DE)← (HL), DE ← DE + 1, HL ← HL + 1, BC ← BC - 1 prend effectivement 4 cycles machine, mais avec le z80 on compte plutôt les T-states (correspondant aux cycles d'horloge), et là ça nous fait 16 cycles !

[65c02]

le Z80 fait en 4 cycles copie, changement des pointeurs et décrémenter le compteur

Attention l'instruction LDI qui fait (DE)← (HL), DE ← DE + 1, HL ← HL + 1, BC ← BC - 1 prend effectivement 4 cycles machine, mais avec le z80 on compte plutôt les T-states (correspondant aux cycles d'horloge), et là ça nous fait 16 cycles !

oups, tu as raison ce n'est pas une bonne comparaison.
mea culpa.
Je me disais aussi. C'est un peu fort comme claque.
Remarque le T state aussi n'est pas suffisant pour être comparable, vu que les processeurs ont des fréquences différentes.
Pour bien faire faudrait tout passer en unité de temps en se basant sur la fréquence max.

[youki]

Par curiosité , je viens de dumper le code de Chuck No Rice sur PC Engine de Touko.
Impressionnant , ca donne ca :
$80,
$80,
$80,
$80,
$80,
$80,
$80,
$80,
$80,
$80,
$80,
$80,











$80,
$80,
$80,
$80,
$80,
$80,
$80,
$80,
$80,
$80,
$80,
$80,












$80,
$80,
$80,
$80,
$80,
$80,
$80,
$80,
$80,
$80,
$80,
$80,












$80,
$80,
$80,
$80,
$80,
$80,
$80,
$80,
$80,
$80,
$80,
$80,












$80,
$80,
$80,
$80,
$80,
$80,
$80,
$80,
$80,
$80,
$80,
$80,












$80,
$80,
$80,
$80,
$80,
$80,
$80,
$80,
$80,
$80,
$80,
$80,












$80,
$80,
$80,
$80,
$80,
$80,
$80,
$80,
$80,
$80,
$80,
$80,












..etc..

[65c02]

ahahahah

[vingazole]

Remarque le T state aussi n'est pas suffisant pour être comparable, vu que les processeurs ont des fréquences différentes.
Pour bien faire faudrait tout passer en unité de temps en se basant sur la fréquence max.

Oui, c'est ce qu'on a essayé de faire p.7 de ce topic, on arrivait à la conclusion qu'un 6502 à 1 MHz fait aussi bien qu'un z80 à ~3,5 MHz pour une comparaison sur 16 bits.

[MacDeath]

Je sais que ce sous forum est orienté Micro, mais sur les bornes d'arcade, quels sont les états de service de chacun de ces CPU?

le Z80 était très souvent couplé avec un 68000 pour servir de co-CPU-sonore... à la manière de la Mégadrive.

Pour les bornes un peu plus vieilles (début-milieux des 80's), pas mal de jeux avaient des Z80 en double voire triple.

http://www.system16.com/list.php?type=h&search=Z80

le SNK triple Z80 notament...

peut être moins de constructeurs en 6502 :
http://www.system16.com/list.php?type=h&search=6502

le 6809 à l'air pas trop mal aussi :
http://www.system16.com/list.php?type=h&search=6809

[AndrewC128 (Xorion)]

coucou MacDeath ! c'est toi qui dit que le CPC est superieur au C64 ?
t'es un sacré comique dis donc
enchanté lol

[jimpqfly]

Nonon moi aussi.