Re: Meilleurs algo d'un test par bouding box

[Stef]

Routine normale sans précalc 16/8
...
239 cycles max
90 Min (65 si je teste y en premier)

On peut encore descendre de 10/15 cycles je pense dans le max si je remplace les pointeurs par des tableaux indexés .
Je peux aussi gratter pas mal de cycles si on considère l'écran < 512 ..

C'est assez marrant de voir que le 6502 (ou dérivé) est plus lent quand on utilise des pointeurs plutot que des tableaux indexés là où la logique attend plutot le contraire O_o...
Enfin du coup, comment tu fais pour traiter un tableau le plus rapidement possible ? T'es bien obligé d'utiliser un pointeur quand même ?

Bon sinon 68000 win  

[Invité]

Enfin du coup, comment tu fais pour traiter un tableau le plus rapidement possible ? T'es bien obligé d'utiliser un pointeur quand même ?

Non tu utilises un reg d'index .
lda _tab , X = 4 cycles ..
lda [ptr].x (pas reg x) = 9 cycles

Les pointeurs sont considérés comme de l'indirect donc plus lents .

Non pas 68000 win, sur la routine classique, la première tu perds, sur celle où on precalc les box tu perds,car ta routine est tellement instable que j'aimerai bien qu'on fasse une simul pour voir ..

Et l'autre je suis pas convaincu, faut que tu m'expliques comment tu organises ta liste de sprites à tester, parce que pour moi tu fais un tri à part pour générer ta liste, donc ça revient au même que de déporter les calculs des box .

[Stef]

Non tu utilises un reg d'index .
lda _tab , X = 4 cycles ..
lda [ptr].x (pas reg x) = 9 cycles

Les pointeurs sont considérés comme de l'indirect donc plus lents .

Oui je voulais juste dire de l'indirect au final, mais là tu m'as pas mis la bonne instruction.
En gros comment tu fais une simple copie tableau (genre quelque chose comme ça) :
lda [x]
inc x
sta [y]
inc y

et combien de cycle ça prend ? c'est juste pour m'aider à comprendre la vitesse réel pour ce genre d'accès car tes 9 cycles me semble bien trop !

Non pas 68000 win, sur la routine classique, la première tu perds, sur celle où on precalc les box tu perds,car ta routine est tellement instable que j'aimerai bien qu'on fasse une simul pour voir ..

   je crois qu'il n'y a rien à répondre devant autant de mauvaise foi !
Mais avec toi, je ne devrais même pas être surpris... enfin là quand même c'est fort, même devant le fait accompli tu ne peux pas le reconnaitre.
"instable"...  non mais  

[Invité]

instable dans le sens ou les cycles varient énormément selon les cas, contrairement aux notres ou les cycles c'est du constant ..

et 93 cycles très variable en hausse, vs 105 constant, je suis pas sur que ce soit mieux .
Aucune mauvaise foi de ma part, car je suis quand même satisfait de ce que j'ai fait .
J'aurai juste aimé voir ce qu'un bon codeur 65xx aurait pu faire .

lda [x]
inc x
sta [y]
inc y
et combien de cycle ça prend ? c'est juste pour m'aider à comprendre la vitesse réel pour ce genre d'accès car tes 9 cycles me semble bien trop !

je fais tii source , dest , taille   17+ 6*nombre d'octets à copier

Ou si moins de 4 octets max (car plus lent)
lda [x] ,X 4 cycles chaque
sta [y],Y

lda [x]+1,X
sta [y]+1,Y

lda [x]+2,X
sta [y]+2,Y

lda [x]+3,X
sta [y]+3,Y

Un code style lda [ptr] prend 7 cycles
un lda [ptr].2 par exemple est codé par le compilo

ldy #2
lda [ptr],Y
soit 2 + 7 = 9 cycles

[Stef]

et 93 cycles très variable en hausse, vs 105 constant, je suis pas sur que ce soit mieux .
Aucune mauvaise foi de ma part, car je suis quand même satisfait de ce que j'ai fait .
J'aurai juste aimé voir ce qu'un bon codeur 65xx aurait pu faire .

Je ne suis pas un guru du 68000 non plus... mais force est d'admettre que quasiment dans tout les cas le 68000 est devant quand on compare les différents codes.

je fais tii source , dest , taille   17+ 6*nombre d'octets à copier

Ouais ça je connais mais je voulais la version 6502 :p

Ou si moins de 4 octets max (car plus lent)
lda [x] ,X 4 cycles chaque
sta [y],Y

lda [x]+1,X
sta [y]+1,Y

lda [x]+2,X
sta [y]+2,Y

lda [x]+3,X
sta [y]+3,Y

Merci :) mais heu... qu'est ce que c'est que cette syntaxe ??
Pourquoi tu mets 2 fois X ??
j'aurai plutot vu un lda [x] et sta [y] par exemple. Là je ne comprends pas la signification du ,X... et ca coute combien l'incrémentation de x ou y ? Edit: ah c 2 cycles pour l'incrémentation apparement sur un 6502.

[Invité]

Je ne suis pas un guru du 68000 non plus... mais force est d'admettre que quasiment dans tout les cas le 68000 est devant quand on compare les différents codes.

Ya peut être juste un cas seulement,faut d'abord que tu m'expliques comment tu fait ta liste de sprites à tester, pour les autres non ..
La première c'esr niet, sauf si tu parviens à optimiser, celle là si tu fais mieux je te déclare vaincoeur sans problème, car on à tous pris celle là comme ref .

Merci :) mais heu... qu'est ce que c'est que cette syntaxe ??
Pourquoi tu mets 2 fois X ??
j'aurai plutot vu un lda [x] et sta [y] par exemple. Là je ne comprends pas la signification du ,X... et ca coute combien l'incrémentation de x ou y ? Edit: ah c 2 cycles pour l'incrémentation apparement sur un 6502.

Bah c'est la syntaxe normale lol .
je mets x parce que tu as mis x et y 
mais en fait ce sont les noms de tabs,faut bien indiquer l'adresse à indexer .

lda tab1 , X      4 cycles chaque
sta tab2 , Y

lda tab1+1 , X
sta tab2+1  ,Y

lda tab1+2 , X
sta tab2+2 , Y

lda tab1+3 , X
sta tab2+3 , Y    TOTAL 32 cycles


EDIT: j'ai corrigé, car un tableau indexé, c'est sans crochet, sinon c'est un pointeur .
Les +1 +2 +3, ça t'évite de faire des inx,iny qui coûtent.
C'est "adresse_de_tab1 +1 , X" par exemple

Là je ne comprends pas la signification du ,X... e

je met grand X pour bien spécifier (pour la lecture) que c'est le REG X, pareil pour Y   
si X = 1
tab1 , X donne adresse_de_tab1 + 1
tab1+1 , X donne donne adresse_de_tab1 + 2 (X vaut toujours 1)

combien l'incrémentation de x ou y ? Edit: ah c 2 cycles pour l'incrémentation apparement sur un 6502.

Oui, pour ça c'est pareil que sur le 6502 .

[Stef]

En fait je comprends, les registres X et Y sont 8 bits (dans ma tête ils étaient 16 bits), du coup tu dois toujours spécifier une adresse avec ! Cela dit ça aurait marcher en page zero !
je suis surpris que ce mode d'adressage n'existe pas par défaut, ou même un l'adresse haute + X pour l'indexation pour gagner un octet de lecture. Vraiment les modes d'adressage du 6502 sont très étranges et pas hyper efficace du coup :-/

[Stef]

Ya peut être juste un cas seulement,faut d'abord que tu m'expliques comment tu fait ta liste de sprites à tester, pour les autres non ..
La première c'esr niet, sauf si tu parviens à optimiser, celle là si tu fais mieux je te déclare vaincoeur sans problème, car on à tous pris celle là comme ref .

Ok, tu parles de la première méthode ?? La toute simple sans boucle ? Je l'ai pas faite car je l'a trouve vraiment pas représentative du cas critique mais je peux la faire mais ça changera pas grand chose.

Bah c'est la syntaxe normale lol .
je mets x parce que tu as mis x et y 
mais en fait ce sont les noms de tabs,faut bien indiquer l'adresse à indexer .

lda [tab1] ,X 4 cycles chaque
sta [tab2],Y

lda [tab1]+1,X
sta [tab2]+1,Y

lda [tab1]+2,X
sta [tab2]+2,Y

lda [tab1]+3,X
sta [tab2]+3,Y

Non mais oui, je n'avais pas compris que X et Y étaient 8 bits (dommage pour des registres d'index) car oui, par X je parlais du registre :p

Je vais essayer de convertir ma routine en code 6502 "avec ma logique" voir pourquoi toi tu ne fais pas pareil     (je sens que je vais galérer)

[Invité]

En fait je comprends, les registres X et Y sont 8 bits (dans ma tête ils étaient 16 bits), du coup tu dois toujours spécifier une adresse avec ! Cela dit ça aurait marcher en page zero !
je suis surpris que ce mode d'adressage n'existe pas par défaut, ou même un l'adresse haute + X pour l'indexation pour gagner un octet de lecture. Vraiment les modes d'adressage du 6502 sont très étranges et pas hyper efficace du coup :-/

Ah oui c'est du 8 bit là , et oui ça marche aussi en page 0, et tu gagne 1 cycles par accès  
Attention l'adresse de tab1 est 16 bit elle si c'est ça que tu entendais par haute .

Ok, tu parles de la première méthode ?? La toute simple sans boucle ? Je l'ai pas faite car je l'a trouve vraiment pas représentative du cas critique mais je peux la faire mais ça changera pas grand chose.

bah c'est pourtant la méthode générique, elle est aucunement pensée pour une arch en particulier, c'est pour ça que je l'ai prise .

Je vais essayer de convertir ma routine en code 6502 "avec ma logique" voir pourquoi toi tu ne fais pas pareil

Tu sera jamais aussi efficace que sur 68000 .
Tu vois dans la copie de bloc, là je te dis clairement que je fais pas le poid, je me console juste que moi ça prend 1 instruction, et toi plein   
C'est toi le 6502 dans ce cas, mais là ton traitement par lot, rien à dire .

EDIT: tu voulais que je convertisse la routine en 68000 avec ma logique c'est ça ???
LOL ça pourrait être marrant .

Au passage je suis surpris de ce que fano et vingazole sont arrivés à faire .

[fanoplusplus64K]

Merci pour eux , je pense qu'on a bien défendu le Z80  
Surtout si tu replaces dans le contexte de l'époque où le Z80 et le 6502 étaient prévus pour tourner à des fréquences typiques respectives de 2,5mhz et 1mhz (bizarrement on retrouve un ratio de 2,5 amusant non ?).

[Stef]

Voici ma version 6502 (attention j'ai pris les cycles du 6502).
J'ai mis la player box dans la page zero ainsi que le nombre d'ennemi, le reste étant en mémoire classique. C'est la version avec les boxes précalculées et en full 16 bits.
Désolé pour la syntax de mon assembleur surement foireuse, je suis carrément pas habitué.

Code:

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     bvc   .ns1

2+1   eor   #$80

.ns1
2     bmi   .no_collid
18/21

3     lda   <player.xmin_low
4     cmp   <enemies.xmax_low,X
3     lda   <player.xmin_high
4     sbc   <enemies.xmax_high,X
2     bvc   .ns2

2+1   eor   #$80

.ns2
2     bpl   .no_collid
18/21

// 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     bvc   .ns3

2+1   eor   #$80

.ns3
2     bmi   .no_collid
18/21

3     lda   <player.ymin_low
4     cmp   <enemies.ymax_low,X
3     lda   <player.ymin_high
4     sbc   <enemies.ymax_high,X
2     bvc   .ns4

2+1   eor   #$80

.ns4
2     bpl   .no_collid
18/21

.collid
2     lda  #1
7     rts
9

.no_collid
2+1   txa
2     clc
2     adc #8
2     tax
2     dey
3     bne .loop
14

2-1   lda  #1
7     rts
8

Et j'arrive à ça :

init: 5
loop min: 18/21
loop moyen: 36/42
loop max: 72/84
loop total: 86/98
end: 8/9

J'ai repris le même algo que pour le 68000... je me suis planté quelque part dans mes instructions ? je fais quelque chose d'impossible ? Parce que à première vue ça me semble correcte et au moins on traite une liste de collision ce qui est quand même plus réaliste :p
Après y'a des grosses contraintes, genre le tableau "enemies" ne peut pas faire plus de 256 octets (soit 32 collisions max) et encore il doit être aligné sur une adresse multiple de 256 pour autoriser les 32 sprites max. C'est chiant dés que tu veux dépasser ces limites 8 bits le code devient tout de suite bien plus complexe.

[Invité]

Merci pour eux , je pense qu'on a bien défendu le Z80  
Surtout si tu replaces dans le contexte de l'époque où le Z80 et le 6502 étaient prévus pour tourner à des fréquences typiques respectives de 2,5mhz et 1mhz (bizarrement on retrouve un ratio de 2,5 amusant non ?).

Tu sais c'est ce qui est souvent dit, je sais que les 65xx on les instructions pipelinées qui peut diviser / 2 le nombre de cycles .
Perso dans aucune doc j'ai vu une référence a ca explicitement ..
Et tout les pros se base sur ça pour faire le ratio 2/3 ,je suis assez sceptique sur ça quand même ..

@stef: y'a de l'idée, et c'est pas mal pour un début . 

normalement on fait clx plutôt que ldx #0
c'est pareil en cycle, mais prend un octet de moins .
bmi c'est si le résultat  est compris entre 128 et 255 et non inférieur .
bpl c'est compris entre 0 et 127
quand on compare 2 valeurs on utilise plutôt .
bne (non egal)
bcc (inférieur)
bcs (supérieur ou egal)

les cycles des intructions de branchements c'est 2 cycles si le branchement n'est pas pris, et 3 si il l'est .

Pk txa tu mets 2+1, c'est 2 cycles .
Pourquoi faire X+8 ?? si les tableaux contiennent des int, c'est 2
donc faire
 inx
 inx
plutôt que
txa
 clc
 adc #8
 tax

je posterait un code 68000 demain, j'aurai plus le temps d'y réfléchir correctement .
Mais j'ai un peut l'habitude des macros en word du compilo 6280
, surement inspirées des instructions du 68K car proche de celles de ton code comme cmpw .

C'est bien du 68000 que je devais faire ?? pas du 6502 ??

[vingazole]

Tu sais c'est ce qui est souvent dit, je sais que les 65xx on les instruction pipelinées qui peut diviser / 2 le nombre de cycles .
Perso dans aucune doc j'ai vu une référence à ca explicitement ..
Et tout les pros se base sur ça pour faire le ratio 2/3 ..

The 6502 does not have a deep pipeline. Instructions never overlap by more than one clock. The pipelining it does have allows the next byte in the program, whether instruction or operand, to be getting fetched while the processor's instruction-decoding logic is still in the process of figuring out what that next byte will even be for, or whether it is needed for the current instruction or not. Even with its single 8-bit ALU, the 6502 is able to keep the bus busy with a different read or write in almost every clock (or T-state, as it is called on some processors).

source: http://forum.6502.org/viewtopic.php?t=744

 

[fanoplusplus64K]

Merci pour eux , je pense qu'on a bien défendu le Z80  
Surtout si tu replaces dans le contexte de l'époque où le Z80 et le 6502 étaient prévus pour tourner à des fréquences typiques respectives de 2,5mhz et 1mhz (bizarrement on retrouve un ratio de 2,5 amusant non ?).

Tu sais c'est ce qui est souvent dit, je sais que les 65xx on les instruction pipelinées qui peut diviser / 2 le nombre de cycles .
Perso dans aucune doc j'ai vu une référence à ca explicitement ..
Et tout les pros se base sur ça pour faire le ratio 2/3 ..

En fait quand tu regardes les architectures du 6502 et du Z80, c'est logique.Je suis loin d'être un spécialiste mais le 65xx semble avoir un pipeline long, l'instruction s'éxécute de bout en bout sans interruption.C'est efficace mais ça a comme défaut d'obliger avoir une fréquence plus lente, pour que le process ait le temps de se finir avant le prochaine 'tick' de l'horloge.De ce fait, les instructions doivent aussi être courtes.
A l'inverse , sur le Z80, le process d'exécution est divisé en morceaux plus courts, on peut donc avoir des instructions qui se déroulent sans souci sur plusieurs 'tick' de l'horloge.En plus , le Z80 procède à 2 cycles de rafraîchissement pour la dram sur chaque lecture d'instruction (fetch) et à 1 cycle d'attente (pour être sur que la ram suive à l'époque)
D'ailleurs si tu regardes bien, les descendants des 65xx et Z80 ont le même genre de ratio de fréquence.C'est d'ailleurs un peu idiot de comparer à fréquence égale car de par sa conception le 65xx n'est pas capable d'atteindre des fréquences comparables au Z80.
Bref , tout ça pour dire que je pense que les deux CPU sont assez proche en terme de performance au final, ce sont juste deux approches différentes.
Désolé de faire long mais vous avez attisé ma curiosité avec tout ce code, j'ai pas pu m'empêcher de passer du temps à me documenter du coup (et grace à vous j'ai découvert de merveilleux clones du Z80 qu'on retrouvera peut être dans un CPC,un MSX , une SMS ou autre lol)

[Stef]

@stef: y'a de l'idée, et c'est pas mal pour un début . 

normalement on fait clx plutôt que ldx #0
c'est pareil en cycle, mais prend un octet de moins .
bmi c'est si le résultat  est compris entre 128 et 255 et non inférieur .
bpl c'est compris entre 0 et 127
quand on compare 2 valeurs on utilise plutôt .
bne (non egal)
bcc (inférieur)
bcs (supérieur ou egal)

Le clx n'existe pas sur le 6502 (ou je n'ai pas trouvé) et pour les branchements je connais bien, c'est à peu près le même système partout :p  Le truc c'est que j'ai l'habitude de souvent tester en signé avec le 68000 alors qu'ici seul le test du high byte doit être signé et le low byte non signé. Je vais corriger... tu me dis que c'est un bon début mais pourquoi, le reste est faux ? car si c'est bon pour le reste c'est bien mieux que tes routines que j'ai jamais vraiment comprises :p

[Stef]

...
C'est d'ailleurs un peu idiot de comparer à fréquence égale car de par sa conception le 65xx n'est pas capable d'atteindre des fréquences comparables au Z80.

Tiens ça me rappelle quelque chose
C'est exactement ce que j'avais dit à Touko, qu'on ne pouvait pas comparer à fréquence équivalente. Par contre on peut essayer de trouver un ratio d'équivalence...
Perso j'étais tenté de dire 2:1 mais je pense qu'un ration de 2.5:1 est plus réaliste.

[Invité]

c'est possible fano, mais le truc est tellement vaseux que dans les fait à part le dire ..
Je veux dire que dans les cycles des opcodes t'as aucune ref à ça .

ex sur 6502 une lecture/ecriture en ZP est donnée pour 3 cycles, mais on te dis pas si le pipeline à une influence ou pas comme les T-STATES par exemple .

@vingazole: c'est ça que je saisi pas, parce que nulle part dans les opcodes  je vois d'instructions 6502 pour 1 cycles .
C'est probable que certaines version soient comme ça .

C'est d'ailleurs un peu idiot de comparer à fréquence égale car de par sa conception le 65xx n'est pas capable d'atteindre des fréquences comparables au Z80.

bah si le 6280   , 7.16 mhz
Après vous avez parfaitement raison, dans le sens où si tu compares 2 CPU qui respectent le ratio ça sera pareil ..

@stef:
si tu as
lda #10
cmp #240

et si tu fais
un bmi .toto tu auras un truc surprenant  
Le 6502 considère en comparaison les valeurs 128 à 255 comme negative donc +10 ne peut pas être inf à -15
je me suis fait avoir aussi au début .

tu as un simulateur 6502 en ligne ici : http://skilldrick.github.io/easy6502/

[fanoplusplus64K]

c'est possible fano, mais le truc est tellement vaseux que dans les fait à part le dire ..

Suffit simplement de regarder les datasheets des CPU en question, les fréquences nominales des équivalents aux différentes époques.Le 6502 et le Z80 étaient concurrents , tu te doutes bien que si il avait été techniquement possible de faire un 6502 capable de tourner à la même vitesse qu'un Z80, ils l'auraient fait et le 6502 aurait été le leader naturel du marché , imagine , un CPU moins cher (car le 6502 était bon marché) et 2 à 3 fois plus rapide que son concurrent direct.

[Stef]

les cycles des intructions de branchements c'est 2 cycles si le branchement n'est pas pris, et 3 si il l'est .

Pk txa tu mets 2+1, c'est 2 cycles .

Justement... je met +1 car le précédent branchement aura généré un cycle supplémentaire, et c'est la raison pour laquelle j'ai gardé tout les branchements à 2 par défaut (je compte le +1 que lorsqu'il arrive).

Pourquoi faire X+8 ?? si les tableaux contiennent des int, c'est 2
donc faire
 inx
 inx
plutôt que
txa
 clc
 adc #8
 tax

Déjà d'une part je profite de l'offset gratuit dans mes accès à enemy (.xmin, .xmax... faut voir ça comme des +1, +3 etc...) et surtout je dois incrémenter l'index uniquement en fin de loop.
Je passe à la box de l'ennemie suivant donc +8 (4x2), et pour un +8, c'est la sequence la plus rapide que j'ai trouvé.

je posterait un code 68000 demain, j'aurai plus le temps d'y réfléchir correctement .
Mais j'ai un peut l'habitude des macros en word du compilo 6280
, surement inspirées des instructions du 68K car proche de celles de ton code comme cmpw .

C'est bien du 68000 que je devais faire ?? pas du 6502 ??

Heu non non du tout, c'est juste moi qui voulait juste essayer mon algo sur le 6502, pour voir en quoi c'était pas possible (vu que tu n'utilisais pas le même). Alors j'ai encore un peu de mal à savoir si mon algo est ok, mais il a l'air de l'être et tout en étant plus rapide et plus pratique à utiliser (car fonctionne sur une liste). Mais après je me suis peut être planté quelque part.

[Stef]

c'est possible fano, mais le truc est tellement vaseux que dans les fait à part le dire ..

Suffit simplement de regarder les datasheets des CPU en question, les fréquences nominales des équivalents aux différentes époques.Le 6502 et le Z80 étaient concurrents , tu te doutes bien que si il avait été techniquement possible de faire un 6502 capable de tourner à la même vitesse qu'un Z80, ils l'auraient fait et le 6502 aurait été le leader naturel du marché , imagine , un CPU moins cher (car le 6502 était bon marché) et 2 à 3 fois plus rapide que son concurrent direct.

C'était plus du à un problème de mémoire... Le 6502, même s'il ne doit pas monter aussi haut qu'un Z80 doit pouvoir tenir une fréquence supérieur. Le problème, c'est plutot la mémoire qui elle ne suit plus, on en a beaucoup parlé sur le topic SNES vs MD. Le 6502 a besoin d'une mémoire très rapide. En gros avec une mémoire de même vitesse tu peux connecter un Z80 à 4 fois la fréquence d'un 6502.

[fanoplusplus64K]

Effectivement , la possibilité d'accéder à la ram à chaque cycle est aussi un facteur de vitesse.

[Invité]

ustement... je met +1 car le précédent branchement aura généré un cycle supplémentaire, et c'est la raison pour laquelle j'ai gardé tout les branchements à 2 par défaut (je compte le +1 que lorsqu'il arrive).

ah ok ..

Déjà d'une part je profite de l'offset gratuit dans mes accès à enemy (.xmin, .xmax... faut voir ça comme des +1, +3 etc...) et surtout je dois incrémenter l'index uniquement en fin de loop.
Je passe à la box de l'ennemie suivant donc +8 (4x2), et pour un +8, c'est la sequence la plus rapide que j'ai trouvé.

Ah ouai, mais pour la compréhension faut pas faire comme ça, un nom différent indique un tableau différent, il vaux mieux faire comme ça ,séparer les low des high
x_low .db 1,4,5
x_high .db 8,9,2

car avec un même indice tu choppes les valeurs de chaque tableau et un simple inx change d'index .
Si tu mets tout dans le même tableau ,il faut incrémenter de 2 à chaque foi .
Ou 1 foi à chaque accès .

C'était plus du à un problème de mémoire... Le 6502, même s'il ne doit pas monter aussi haut qu'un Z80 doit pouvoir tenir une fréquence supérieur. Le problème, c'est plutot la mémoire qui elle ne suit plus, on en a beaucoup parlé sur le topic SNES vs MD. Le 6502 a besoin d'une mémoire très rapide. En gros avec une mémoire de même vitesse tu peux connecter un Z80 à 4 fois la fréquence d'un 6502.

C'est vrai, mais n'oublies pas non plus que les CPU ne montent pas en fréquence à volonté .
Tu es confronté et à la chauffe, et aux limites de la finesse de gravure, augmentation du pipe interne .
voir le P4 d'intel, un CPU qui montait haut en fréquence, mais très lent .
en 87 le 6280 était à plus de 7 mhz, donc c'était possible .
Le soucis de mos technologie est qu'il se sont fait racheter par commodore, et on sombrés avec, et n'ont jamais sortie de vrai CPU 16 bit, le 6502 devenait vieillisant .
Aujourd'hui intel comme AMd favorisent la vitesse / instructions plutôt que la fréquence .

Heu non non du tout, c'est juste moi qui voulait juste essayer mon algo sur le 6502, pour voir en quoi c'était pas possible (vu que tu n'utilisais pas le même). Alors j'ai encore un peu de mal à savoir si mon algo est ok, mais il a l'air de l'être et tout en étant plus rapide et plus pratique à utiliser (car fonctionne sur une liste). Mais après je me suis peut être planté quelque part.

J'ai pas dit pas possible, juste moins efficace qu'une approche non bouclé, car tu peux eviter de lancer la routine pour rien ..
Et par rapport au 68000 ce style de boucle n'est pas spécialement efficace .

[Stef]

@stef:
si tu as
lda #10
cmp #240

et tu fais
un bmi .toto tu auras un truc surprenant  
Le 6502 considère en comparaison les valeurs 128 à 255 comme negative donc +10 ne peut pas être inf à -10
je me suis fait avoir aussi au début .

tu as un simulateur 6502 en ligne ici : http://skilldrick.github.io/easy6502/

Vraiment je connais bien ses histoires de signe Touko   Ce qui me gène le plus c'est d manipuler des 16 bits avec le 6502, je trouve ça très hardu en fait !
Le Z80 au moins contient quelques instructions 16 bits, mais là du coup j'ai l'impression que tu es obligé de tester les 2 cas pour t'en sortir, ce qui expliquerait que ton code était plus complexe que le mien. Je vais quand même tacher de corriger mon code pour faire fonctionne ma version 6502.

[Invité]

Vraiment je connais bien ses histoires de signe Touko   Ce qui me gène le plus c'est de manipuler des 16 bits avec le 6502, je trouve ça très hardu en fait !

Comme tu veux, si je te dis que ça marche pas comme ça   
quand tu fais une comparaison le 6502 utilise la retenue pour dire si c'est supérieur ou inf, et pas le flag N ..

bcc branche si c'est inférieur
bcs branche si c'est sup ou égal .

C'est sur que des instructions 16 bit auraient été bien mais bon faut faire sans, c'est chiant, mais vraiment bien quand tu peux optimiser des op 16 bit en travaillant sur l'octet, comme la routine de collision en 16/8 .

[Stef]

Ah ouai, mais pour la compréhension faut pas faire comme ça, un nom différent indique un tableau différent, il vaux mieux faire comme ça ,séparer les low des high
x_low .db 1,4,5
x_high .db 8,9,2

car avec un même indice tu choppes les valeurs de chaque tableau et un simple inx change d'index .
Si tu mets tout dans le même tableau ,il faut incrémenter de 2 à chaque foi .
Ou 1 foi à chaque accès .

J'ai du mal à comprendre, pour moi c'est juste de l'écriture. Je voulais juste utiliser l'adresse absolu indexé, genre LDA $1000+0,X ou LDA  $1000+5,X   pour accéder à mes différentes variables de ma structure "enemy_box" et quand j'ai terminé les collisions pour cet ennemi je passe au suivant.
En faisant ton INC X à chaque fois, déjà c'est plus long mais en plus en fonction des saut je suis plus au bon endroit dans mon tableau.

C'est vrai, mais n'oublies pas non plus que les CPU ne montent pas en fréquence à volonté .
Tu es confronté et à la chauffe, et aux limites de la finesse de gravure, augmentation du pipe interne .
voir le P4 d'intel, un CPU qui montait haut en fréquence, mais très lent .
en 87 le 6280 était à plus de 7 mhz, donc c'était possible .
Le soucis de mos technologie est qu'il se sont fait racheter par commodore, et on sombrés avec, et n'ont jamais sortie de vrai CPU 16 bit, le 6502 devenait vieillisant .
Aujourd'hui intel comme AMd favorisent la vitesse / instructions plutôt que la fréquence .

A l'époque de nos vieilles consoles, c'était la mémoire le frein, tu pouvais aisément overclocker les CPU (sur MD le 68000 peut prendre 100% en overclocke mais c'est la mémoire qui ne suit plus au delà de 13 Mhz). Sur pas mal de vieilles machines en fait tu peux pousser le CPU mais la mémoire lachera avant.

J'ai pas dit pas possible, juste moins efficace qu'une approche non bouclé, car tu peux eviter de lancer la routine pour rien ..
Et par rapport au 68000 ce style de boucle n'est pas spécialement efficace .

Surtout je vois que t'es limité par ces registres d'index 8 bits en fait, sinon ça serait tout à fait possible. Je trouve que le 6502 te pousse à programmer comme un bourrin du fait de ces limitations. Le Z80 est quand même beaucoup plus permissif et élégant sur sa manière de coder !

[Invité]

Ok alors faut utiliser le même nom ou faire
player_posx_low
player_posx_high

player_posy_low
player_posy_high
tu fais pareil pour ennemi .
Donc on est d'accord avec ça,CAD tu scindes tes valeurs en octets  .

ldx #1

lda player_posx_low , x
lda player_posx_high , x

etc ..
pour passer à la valeur suivante, un simple inx suffit ..

A l'époque de nos vieilles consoles, c'était la mémoire le frein, tu pouvais aisément overclocker les CPU (sur MD le 68000 peut prendre 100% en overclocke mais c'est la mémoire qui ne suit plus au delà de 13 Mhz). Sur pas mal de vieilles machines en fait tu peux pousser le CPU mais la mémoire lachera avant.

Oui mais pas que, quand tu overclocke la master clock c'est tout le système que tu booste, c'est probable que le VDC n'aime pas .
A moins que tu puisses juste ovck le CPU sans toucher la MC ..

Surtout je vois que t'es limité par ces registres d'index 8 bits en fait, sinon ça serait tout à fait possible. Je trouve que le 6502 te pousse à programmer comme un bourrin du fait de ces limitations. Le Z80 est quand même beaucoup plus permissif et élégant sur sa manière de coder !

Exact, je connais pas le Z80, mais perso mis à part certains trucs chiant le 65xx est vraiment simple, mais comme tu viens du 68000 je comprends que ca soit pénible, mais pourtant ça l'est pas du tout ..
Perso j'adore sa simplicité, et à part de rares cas (du moins sur 6280) une instruction prend tant de cycles et puis basta, c'est hyper simple à calculer .
Avec l'habitude c'est un CPU très plaisant,simple et efficace, mais pas parfait   
Youki qui code sur les 2, n'aime pas du tout le Z80 ..

[Stef]

Vraiment je connais bien ses histoires de signe Touko   Ce qui me gène le plus c'est de manipuler des 16 bits avec le 6502, je trouve ça très hardu en fait !

Comme tu veux, si je te dis que ça marche pas comme ça   
quand tu fais une comparaison le 6502 utilise la retenue pour dire si c'est supérieur ou inf, et pas le flag N ..

bcc branche si c'est inférieur
bcs branche si c'est sup ou égal .

C'est sur que des instructions 16 bit auraient été bien mais bon faut faire sans, c'est chiant, mais vraiment bien quand tu peux optimiser des op 16 bit en travaillant sur l'octet, comme la routine de collision en 16/8 .

Non mais je sais quoi X'D  bpl et bmi c'est juste des tests "plus" et "minus" (à utiliser pour les nombres signés) alors que bcs et bcc c'est inférieur et supérieur réservé à la comparaison des nombres non signés, c'est la seule différence. Si tu considères tes nombres 8 bits comme signés, tu dois utiliser bpl et bmi.
Le truc chiant c'est qu'en 16 bits, tu ne peux pas juste te dire tu compares les 2 bytes et c'est réglé, c'est un peu plus compliqué que ça si tu considère un 16 bits signé.
Je vais modifier mon code, et tu verras que ça marchera bien *et* en signé :p

[Invité]

J'avais compris ton truc, mais dans ton algo ça marche pas car tu fais juste un cmp avant suivi du bmi
Ca branchera jamais comme tu veux .
où alors tu organise tes comparaisons en conséquence, mais du coup le code ne devient plus vraiment lisible pour un habitué du 6502 ..

avec:
lda   player.ymin_high
 cmp enemies.ymax_high,X
bpl


Moi j'ai compris que tu comparais A à enemies.ymax_high,X, et que tu voulais brancher si A était supérieur .

[Stef]

Je l'ai corrigé, maintenant la boucle principale fait entre 86 et 98 cycles, mais ça reste ce qu'il y a de plus rapide et ça gère en full 16 bits et signé sans erreur normalement, donc je ne vois pas en quoi c'est pas efficace.

[Stef]

avec:
lda   player.ymin_high
 cmp enemies.ymax_high,X
bpl


Moi j'ai compris que tu comparais A à enemies.ymax_high,X, et que tu branchais si A était supérieur .

C'était exactement ça ! Sauf que effectivement au début c'était faux cette comparaison 8 bits signé mais je l'ai vite corrigé. Maintenant ça doit prendre le 16 bits signé correctement en compte.

[Invité]

Parce que c'est du 6502 donc moins de cycles que moi, et aussi parce que tu fais pas tout les tests j'ai l'impression .

tu dois tester x1 avec x2 et X'2, x'1 avec x2 et X'2 et pareil pour Y  donc 4 test 16 bit par coordonnée et pas 2    .
je pense que tu peux multiplier tes 98 cycles x2 ..

C'était exactement ça ! Sauf que effectivement au début c'était faux cette comparaison 8 bits signé mais je l'ai vite corrigé. Maintenant ça doit prendre le 16 bits signé correctement en compte.

Si je te le dis, vu que je me suis fait bezouille aussi