Re: Snes - megadrive - pc engine vs Neo geo

[Stef]

Toy story, est identique sur SNES donc, aucune prouesse .
Si tu parles du chien qui cours ??, je dirai qu'il est fait de tile en utilisant un layer,et non un sprite(mais je me trompe peut être) .

Effectivement sur SNES ce stage est semblable, je pense qu'ils ont utilisé le surplus de vram pour cacher plus de tiles mais ce jeu est hyper impressionnant quelque soit la machine...
Tu vois la difference de perf entre les 2 machines dans le niveau en 3D. Sur SNES la fenetre de vue est beaucoup plus petite que sur MD et les pixels doublés en horizontal...
Le chien est un sprite mais ca n'aurait rien changé si ct un plan car il faut recharger les tiles en vram.

On est d'accord sur ce point, la MD pour les sprites est plus flexible que les 2 autres.
Cependant qui préfèrerait techniquement gynoug à aldynes ???

Ben moi... tu as deja vu tout les niveaux de gynoug ? particulierement le niveau ou t'as l'impression de te balader dans des vaisseaux sanguins. Ca ondule dans tout les sens et les boss sont magnifiquement glauques :)

Mais ça change rien au fait que si tu veux avoir de gros sprites sur MD, tu vas être obligé d'en coupler plusieurs, sachant qu'un sprite MD peut faire max 32*32 .
C'est pour ça que du coup ça fait vide, donc pour un shoot les devs pour afficher plein de sprites à l'écran utilisent des sprites 8*8 avec des 32*32 max(voire 16*16, comme gynoug ??) .

Bien sur et ca t'offre une meilleur granularite sur tes sprites... si tu as un sprite de 48 pixels de long tu utilise un 32 +16 et ainsi tu repousses le clignotement par ligne comparé a un sprite de 64 px.

Bon je sais que c'est pas facile à lire, mais si tu t'arrêtes aux 2 premières page
Par exemple là sur forgoten world : http://www.pcenginefx.com/forums/index.php?topic=6609.165
darius2 : http://www.pcenginefx.com/forums/index.php?topic=6609.180
darius2 boss là c'est ultra flagrant la taille :http://www.pcenginefx.com/forums/index.php?topic=6609.195

Lord of thunder : http://www.pcenginefx.com/forums/index.php?topic=6609.210

Mais vraiment y'a rien d'infaisable sur md... a partir du moment ou la capacite des sprites te permettent de remplir l'ecran complet tu peux faire quasiment ce que tu veux... y'a juste les chevauchements qui peuvent poser probleme et dans ce cas la SGX a un avantage dans certaines cas seulement (gros sprites)...
Pour Darius 2, la version Md est assez misérable, t'as l'impression qu'ils sont parti de la version master system tant elles se ressemblent :p

LOL la mauvaise foi , si à chaque fois que la MD n'est pas à la hauteur c'est la faute aux portage, c'est sur qu'elle ne peut être que la meilleure
Sur le topic que j'ai mis, y'a même un compario d'altered beast, qui est surement mieux converti sur MD que sur nec ,non, et bien là aussi il y a plus d'étapes sur la version PCE .
Et que dire d'after burner 2, un jeu sega, et sega ne baclait surement les conversions de ses jeux.

Franchement oui, les portages arcade de sega sont catastrophiques... et je suis certain quer ct voulu dans un sens... franchement j'aurais tué à l'époque pour un portage du shinobi arcade et sega l'a jamais fait sur MD alors ct techniquement possible :'(

Alors un transfert simple d'un 16 bit sur le 6280 prend 4 cycles(comme le 68000, moins si il est pipé), cependant si tu transfères on va dire 100 octets de RAM -> RAM.
sur le 6280 tu vas utiliser une des 5 instructions de transfert de bloc qui vont prendre .

17 cycles pour l'init, et 6 cycles /octet, soit 617 cycles pour 100 octets, soit un transfert total d'environ 1 193 333 octets/sec ..
Et il fait quoi le 68000 ???
Je pense que ça s'est faux, car tu prends un simple chargement d'un word qui prend 4 cycles, et tu divises la fréquence d'horloge par les 4 cycles .
Ce qui est faux, car tu ne prends ni en compte l'écriture de ce word, ni l'init et l'arrêt du transfert,et comme ça oui,vu que la fréquence du 68000 est supérieure,mais
malheureusement faux comme raisonnement .
Combien de cycles prendrait le CPU pour un transfert en RAM -> RAM, d'un tableau de 100 octets (donc lecture/écriture, init et arrêt) ???
Surement pas ça !!

Je te parlais de lecture, en lecture / ecriture tu divises par 2 soit un peu plus de 1.92 Mo /s ce qui est beaucoup plus que ton 1.19 Mo/s...
En prenant l'instruction movem qui peut transférer jusqu'a 60 octets d'un coup tu caches la pénalité de 4 cycles pour l'instruction et donc tu tends vers 4 cycles/octet comparé a ton 6 cycles/octet (j'imagine que le BUS nécessite 3 cycles pour accéder à la mémoire).
Avec l'instruction move (cas le plus simple) tu consommes 20 cycles pour transferer 4 octets, soit 5 cycles octet mais ça reste toujours moins que 6 cycles/octet et la frequence supérieur du cpu (pas de beaucoup mais tout de même) augmente encore le ratio... de toute manière quand tu veux vraiment optimiser ton transfert mémoire, soit tu utilises movem (pour tendre vers 4 cycles/octet) ou soit tu utilises le DMA qui permet d'atteindre 3.22 Mo/s en période de blank.

Ouai, effectivement c'est assez pourri, je te l'accorde, mais facilement contournable, et le mode 001, est identique à ce que propose la MD, sprite 8*8+32*32 ..

Sur md c'est toutes les combi entre 8x8 et 32x32, pas seulement 8x8 et 32x32 qui doit etre difficilement utilisable... à mon sens le meilleur compromis c'est 16x16 et 32x32, mais du coup tu te retrouves avec une taille identique à celle de la MD... avec des 64x64, t'as interet à bien optimiser tes sprites sinon ça va vite clignoter...

[Invité]

Effectivement sur SNES ce stage est semblable, je pense qu'ils ont utilisé le surplus de vram pour cacher plus de tiles mais ce jeu est hyper impressionnant quelque soit la machine...
Tu vois la difference de perf entre les 2 machines dans le niveau en 3D. Sur SNES la fenetre de vue est beaucoup plus petite que sur MD et les pixels doublés en horizontal...
Le chien est un sprite mais ca n'aurait rien changé si ct un plan car il faut recharger les tiles en vram.

Ok,tu as raison sur le fait qu'il aurait fallu comme les sprites réactualiser les tiles, mais la technique aurai permise de ne pas atteindre la limite/ligne des sprites.

Ben moi... tu as deja vu tout les niveaux de gynoug ? particulierement le niveau ou t'as l'impression de te balader dans des vaisseaux sanguins. Ca ondule dans tout les sens et les boss sont magnifiquement glauques :)

Lol, quand même t'abuse de faire passer une simple interuption hsync sur un layer pour une prouesse ,effet vu et revu je sais plus combien de fois sur tout un tas de machines ..
Rien de plus simple ..

Bien sur et ca t'offre une meilleur granularite sur tes sprites... si tu as un sprite de 48 pixels de long tu utilise un 32 +16 et ainsi tu repousses le clignotement par ligne comparé a un sprite de 64 px.

Oui, mais rien empêche à la PCe ou même la snes de faire de même ..

Mais vraiment y'a rien d'infaisable sur md... a partir du moment ou la capacite des sprites te permettent de remplir l'ecran complet tu peux faire quasiment ce que tu veux... y'a juste les chevauchements qui peuvent poser probleme et dans ce cas la SGX a un avantage dans certaines cas seulement (gros sprites)...
Pour Darius 2, la version Md est assez misérable, t'as l'impression qu'ils sont parti de la version master system tant elles se ressemblent :p

Mais si on écoute tout les fanboys de toutes les machines rien n'est jamais infaisable sur leur machine ..

Franchement oui, les portages arcade de sega sont catastrophiques... et je suis certain quer ct voulu dans un sens... franchement j'aurais tué à l'époque pour un portage du shinobi arcade et sega l'a jamais fait sur MD alors ct techniquement possible :'(

Bah si même sega n'arrive pas à faire des portages corrects de ses jeux d'arcade, sur sa propre console, faut vous rendre à l'évidence, la MD c'est une bouse

Je te parlais de lecture, en lecture / ecriture tu divises par 2 soit un peu plus de 1.92 Mo /s ce qui est beaucoup plus que ton 1.19 Mo/s...

Donc on est à 8 cycles/octet,soit un peu plus de 958 000 octets/s , si on prend en plus le fait que le 68000 tourne à 7,6 mhz contre 7,16 pour le 6280, on peut en déduire qu'il n'est pas plus rapide à frequence égale .

En prenant l'instruction movem qui peut transférer jusqu'a 60 octets d'un coup tu caches la pénalité de 4 cycles pour l'instruction et donc tu tends vers 4 cycles/octet comparé a ton 6 cycles/octet (j'imagine que le BUS nécessite 3 cycles pour accéder à la mémoire).
Avec l'instruction move (cas le plus simple) tu consommes 20 cycles pour transferer 4 octets, soit 5 cycles octet mais ça reste toujours moins que 6 cycles/octet et la frequence supérieur du cpu (pas de beaucoup mais tout de même) augmente encore le ratio... de toute manière quand tu veux vraiment optimiser ton transfert mémoire, soit tu utilises movem (pour tendre vers 4 cycles/octet) ou soit tu utilises le DMA qui permet d'atteindre pas loin de 3 Mo/s en débit de transfert en période de blank.

Oui mais comme d'hab, tu joues avec les chiffres,ton raisonnement est toujours faux ..

ton movem, est du style movem @source,@dest,taille non ??
donc c'est vrai dans le cadre de 60 octets, mais si tu prends les 100 et plus, ton raisonnement n'est plus vrai .
Tu vas être obligé, de gérer les incrémentations de tes adresses sources et destinations tout les 60 octects, découper la taille à transférer en 60 octets, tester si tu es a la fin de ton transfert, tout ça à un coût, et tu n'est plus dans ton 1m92 octets/s ..
et si tu coupes en 20 le constat est pire encore, on peux réduire l'impact si le transfert est toujours de 100 octets, mais si c'est variable, c'est mort ..
Et si tu dois transferer 101 octets, t'es pas dans la moise avec to movem
contrairement aux instructions de transfert de blocs du 6280 qui font tout ça toutes seules, et sur des tailles de 16 bit,elles sont de type DMA..

Par contre j'ai pas saisi les 3 cycles pour l'accés au bus
Sur le 6280, l'instruction prend 6 cycles au total, lecture/écriture comprise, pas de cycles supplémentaires pour l'accés au bus(si c'est ce que tu voulais dire ) ..
le 68000 en a lui ???

Le CPU peut utiliser ces instructions pour faire du RAM->RAM,RAM->VRAM,ROM->RAM,VRAM->RAM,ROM->VRAM,toujours en 6 cycles ..
Pour le DMA, c'est clair que celui de la MD est bien(mieux que celui de la pce en flexibilité), celui de la PCE est très performant, mais il ne fait que du VRAM->VRAM mais @10mhz(mais pas spécialement utile au final) ..
Mais ton DMA il fait pas RAM->RAM non ..

Sur md c'est toutes les combi entre 8x8 et 32x32, pas seulement 8x8 et 32x32 qui doit etre difficilement utilisable... à mon sens le meilleur compromis c'est 16x16 et 32x32, mais du coup tu te retrouves avec une taille identique à celle de la MD... avec des 64x64, t'as interet à bien optimiser tes sprites sinon ça va vite clignoter...

Oui je parlais de ce mode juste pour ton exemple, mais il me semble que la MD à plus de tailles que les classiques 8*8,16*16 ou 32*32 non ??

Pour les cycles movem, j'ai trouvé ca :
http://oldwww.nvg.ntnu.no/amiga/MC680x0_Sections/timmove.HTML

Mais c'est limite indigeste, ça prends combien de cycles concrètement un movem de la RAM vers la RAM ??
Pareil pour le move.w de la ram vers un registre(et non d'un immédiat) ???

[MikeeMike_2008]

Bah si même sega n'arrive pas à faire des portages corrects de ses jeux d'arcade, sur sa propre console, faut vous rendre à l'évidence, la MD c'est une bouse

+1

en tout cas ce n'est pas le cas de nintendo car chez eux ils savent au minimum exploiter leur console dès le début comme pilotwings ou f-zero.... (le minimum syndical)

sega ... non .....magnifique pour des développeurs en arcade

[Stef]

Ok,tu as raison sur le fait qu'il aurait fallu comme les sprites réactualiser les tiles, mais la technique aurai permise de ne pas atteindre la limite/ligne des sprites.

Oui le plan permettrait de ne pas atteindre la limite pas ligne, mais ici ils en ont même pas besoin...

Lol, quand même t'abuse de faire passer une simple interuption hsync sur un layer pour une prouesse ,effet vu et revu je sais plus combien de fois sur tout un tas de machines ..
Rien de plus simple ..

En fait y'a du H scrolling par ligne + du scroll vertical par cell (chose que la PCE n'est pas capable de faire il me semble). En fait tout ces "effets" sont cablés donc même pas besoin du H interrupt pour le faire (tu dois parler de l'effet type super aleste). Mais bon dans Gynoug je trouve que c'est particulièrement bien exploité, et puis de manières général c'est un shoot ou les boss peuvent t'envoyer un paquet de boulettes en vrac, chose qu'on voit plutot dans les shoots arcade mais rarement sur console...

Bien sur et ca t'offre une meilleur granularite sur tes sprites... si tu as un sprite de 48 pixels de long tu utilise un 32 +16 et ainsi tu repousses le clignotement par ligne comparé a un sprite de 64 px.

Oui, mais rien empêche à la PCe ou même la snes de faire de même ..

Heu oui 32 + 16, mais après du coup tu n'as plus accés aux sprites de 64 px ou de 8 px.

Mais si on écoute tout les fanboys de toutes les machines rien n'est jamais infaisable sur leur machine ..

Mais c'est presque vrai parce que tu as toujours des astuces qui font que tu pourras aller plus loin... jusqu'aux limites théoriques, et c'est là que je souligne la supériorité de la MD

Bah si même sega n'arrive pas à faire des portages corrects de ses jeux d'arcade, sur sa propre console, faut vous rendre à l'évidence, la MD c'est une bouse

Ah le vieux troll, mais faut admettre que leurs portages arcade sont dans la majeur partie des cas, décevant...

Donc on est à 8 cycles/octet,soit un peu plus de 958 000 octets/s , si on prend en plus le fait que le 68000 tourne à 7,6 mhz contre 7,16 pour le 6280, on peut en déduire qu'il n'est pas plus rapide à frequence égale .

Heu t'as du mal comprendre
C'est 4 cycles/octet et donc 1 917 500 octets/s...
Le 68000 lit un mot (16 bits) en 4 cycles, pour lire et écrire un mot (16 bits) on met donc 8 cycles, soit 4 cycles pour un octet.

ton movem, est du style movem @source,@dest,taille non ??

Oui plus ou moins, c'est plutot movem reg-list,@dest ou movem @src,reg-list

donc c'est vrai dans le cadre de 60 octets, mais si tu prends les 100 et plus, ton raisonnement n'est plus vrai .
Tu vas être obligé, de gérer les incrémentations de tes adresses sources et destinations tout les 60 octects, découper la taille à transférer en 60 octets, tester si tu es a la fin de ton transfert, tout ça à un coût, et tu n'est plus dans ton 1m92 octets/s ..

La predecremention et post incrémentation sont gratuite dans les mode d'adressage mémoire et fonctionne bien sur sur l'instruction movem, donc pas besoin d'instruction supplémentaire. Et surtout l'instruction movem permet de transférer de 2 octets (pas très util, autant utiliser un simple move) jusqu'à 60 octets donc tu ajuste si tu souhaites transférer que 100 octets...
Normalement tu utilises le movem pour des gros transferts.
Pour de plus petits transferts tu utilises des "move" classiques.

et si tu coupes en 20 le constat est pire encore, on peux réduire l'impact si le transfert est toujours de 100 octets, mais si c'est variable, c'est mort ..
Et si tu dois transferer 101 octets, t'es pas dans la moise avec to movem
contrairement aux instructions de transfert de blocs du 6280 qui font tout ça toutes seules, et sur des tailles de 16 bit,elles sont de type DMA..

Tu sais, normalement tu écris ta fonction memcpy intelligemment :) pour les petits transfert tu auras forcément un moindre rapport mais tu as le meme soucis avec ta pénalité d'init. Et souvent les bottleneck arrivent sur des gros transferts.
Quand tu dis que tes instructions sont de type DMA, tu veux dire que ça monopolise le BUS ? Sur MD il peut y avoir un avantage a ne pas utiliser le DMA qui monopolise le BUS car celui est partagé avec le Z80. Même en utilisant toute la puissance du 68000 pour faire un transfert mémoire (à 1.9 Mo/s) le BUS et la mémoire (RAM comme ROM) sont suffisamment rapide pour donner la main au Z80 quand celui ci le nécessite. Par contre en utilisant le DMA, le Z80 n'a plus accés au BUS et reste bloqué s'il en a besoin le temps du DMA...

Par contre j'ai pas saisi les 3 cycles pour l'accés au bus
Sur le 6280, l'instruction prend 6 cycles au total, lecture/écriture comprise, pas de cycles supplémentaires pour l'accés au bus(si c'est ce que tu voulais dire ) ..
le 68000 en a lui ???

Vu que c'est une instruction optimisée pour le transfert mémoire, j'imagine qu'il n'y a aucun moyen de descendre en dessous de 3 cycles pour un accés mémoire avec le 6280, en gros je me demandais si les 3 cycles était inhérent au CPU ou au BUS mémoire...
Je pensais que les CPU de la famille 6502 faisait un accés à la mémoire en 2 cycles, 3 cycles finalement c'est juste un de moins que le 68000... et un accés 8 bits comparé à l'accés 16 bits du 68000.

Le CPU peut utiliser ces instructions pour faire du RAM->RAM,RAM->VRAM,ROM->RAM,VRAM->RAM,ROM->VRAM,toujours en 6 cycles ..
Pour le DMA, c'est clair que celui de la MD est bien(mieux que celui de la pce en flexibilité), celui de la PCE est très performant, mais il ne fait que du VRAM->VRAM mais @10mhz(mais pas spécialement utile au final) ..
Mais ton DMA il fait pas RAM->RAM non ..

Sur MD la DMA est attaché au VDP, pas au 68000.
Du coup les DMA possibles sont les suivants :
ROM->VRAM, RAM->VRAM, VRAM->VRAM
ROM->CRAM, RAM->CRAM, CRAM->CRAM
ROM->VSRAM, RAM->VSRAM, VSRAM->VSRAM
La CRAM était le mémoire pour la palette et la VSRAM celle du scrolling vertical.
Après le DMA du VDP peut égalment faire du filling (remplir la mémoire d'un valeur donnée) sur la VRAM, CRAM et VSRAM.
Un point interessant du DMA c'est que t'as un pas d'incrementation variable pour la destination, ça permet de faire des conversions de tile plus facilement par exemple.

Oui je parlais de ce mode juste pour ton exemple, mais il me semble que la MD à plus de tailles que les classiques 8*8,16*16 ou 32*32 non ??

en fait tu as toutes les combinaisons entre 8x8 et 32x32 :

8x8, 16x8, 8x16,
24x8, 8x24, 8x32, 32x8,
16x16, 16x24, 24x16,
16x32, 32x16,
24x24, 24x32, 32x24,
32x32

J'en ai tet oublié...

Pour les cycles movem, j'ai trouvé ca :
http://oldwww.nvg.ntnu.no/amiga/MC680x0_Sections/timmove.HTML

Mais c'est limite indigeste, ça prends combien de cycles concrètement un movem de la RAM vers la RAM ??
Pareil pour le move.w de la ram vers un registre(et non d'un immédiat) ???

C'est parce-que t'as pas l'habitude mais c'est très pratique :)
En gros tu fais un premier movem @src+,reg-list suivi d'un movem reg-list,@-dst
Normalement tu utilises ça en rentrée de fonction pour sauvegarder tes registres et les restaurer en fin de fonction.

Plus tu utilises de registres et plus tu caches la pénalité de base de l'instruction un peu comme ton init. Bien sur ça a ses limites et tu n'arrives jamais à 4 cycles / octet

mais par exemple avec ces 3 instructions :

movem.l (a0)+,d0-d7/a2-a6 / 124
movem.l d0-d7/a2-a6,-(a0) / 120
add.l #56, %a0 / 14


Soit 258 cycles pour 56 octets transférés soit 4.6 cycles / octet...
Et réellement tu peux pas descendre beaucoup en dessous car j'avais oublié qu'on doit tout de même incrémenter le registre d'index du fait de la manière dont fonctionne movem :-/
Enfin sur MD ça te permet quand même d'arriver à un débit 1.67 Mo/s avec le CPU.

Avec une séquence plus simple type :

move.l (a0)+,(a1)+ / 20

Tu consommes 20 cycles pour 4 octets transférés soit 5 cycles / octet soit un débit de 1.53 Mo/s.

[philip]

Dans ghouls'n ghost, Arthur peut tirer en haut et en bas, ce qui est bien pratique pour se débarrasser des fripouilles du jeu. :) La version Megadrive est très fidèle à l'arcade pour ce qui est du gameplay. Techniquement et graphiquement, c'est d'un bon niveau, surtout face aux versions micro 16bit. Il faut se replacer dans le contexte de l'époque, avec une quantité de mémoire limité, donc un jeu un peu moins riche mais avec un prix démocratique... 450 francs quand même. Sur NeoGeo, pas de concession bien sûr, avec le clinquant Magician lord, mais vendu bien plus cher et moins kiffant qu'Arthur.

Dans Super ghouls'n ghost, Arthur ne sait plus se battre ! C'est horrible de voir un monstre passer dessous Arthur, sans que ce dernier puisse s'en débarrasser en tirant simplement vers le bas. Il faut reculer et attendre que le monstre se positionne en face du héros... c'est vraiment horripilant.

Faut vraiment ne jamais avoir joué en arcade pour préférer la version SNES... une console taillée pour du Mario et du zelda, mais pas pour l'arcade et des jeux bien péchu comme Mega turrican. Et là, il faut plutôt regarder du côté de la Neo Geo avec le récent Gun Lord pour une comparaison technique qui tiens la route.

D'ailleurs, c'est le sujet de ce post: Snes - Megadrive - PC Engine VS Neo Geo (et non pas Snes VS Megadrive)

[lessthantod]

Complètement d'accord avec toi camarade toulousain , moi aussi j'aime vraiment bcp l'adaptation arcade de GNG sur MD en dépit de ses "quelques" défaults! Aprés le SGNG sur SNES est frustrant mais magnifique, mais frustrant, mais magnifique, mais frustrant!

[Invité]

En fait y'a du H scrolling par ligne + du scroll vertical par cell (chose que la PCE n'est pas capable de faire il me semble). En fait tout ces "effets" sont cablés donc même pas besoin du H interrupt pour le faire (tu dois parler de l'effet type super aleste). Mais bon dans Gynoug je trouve que c'est particulièrement bien exploité, et puis de manières général c'est un shoot ou les boss peuvent t'envoyer un paquet de boulettes en vrac, chose qu'on voit plutot dans les shoots arcade mais rarement sur console...

non en effet, elle peut pas en faire, tout se fait à la ligne sur PCE ..

Heu oui 32 + 16, mais après du coup tu n'as plus accés aux sprites de 64 px ou de 8 px.

Sur snes oui, mais rien ne t'empeche de changer le mode lors des boss .
Sur PCe c'est comme sur Md, tu peux tout mixer ..

Mais c'est presque vrai parce que tu as toujours des astuces qui font que tu pourras aller plus loin... jusqu'aux limites théoriques, et c'est là que je souligne la supériorité de la MD

Lol, n'empêche que j'ai rien vu non plus d'infaisable sur les autres machines ..

Ah le vieux troll,

Oui, oui je confirme

Heu t'as du mal comprendre
C'est 4 cycles/octet et donc 1 917 500 octets/s...
Le 68000 lit un mot (16 bits) en 4 cycles, pour lire et écrire un mot (16 bits) on met donc 8 cycles, soit 4 cycles pour un octet.

Effectivement je comprends pas trop là ..
tu lis un mot en 4 cycles, mais c'est en immédiat, pas en RAM ..
tu mets 8 cycle/word pour lire et écrire en RAM ???
Ou 8 pour lire et 8 autres pour écrire,parce que ca me parait bien peu ..

La predecremention et post incrémentation sont gratuite dans les mode d'adressage mémoire et fonctionne bien sur sur l'instruction movem, donc pas besoin d'instruction supplémentaire. Et surtout l'instruction movem permet de transférer de 2 octets (pas très util, autant utiliser un simple move) jusqu'à 60 octets donc tu ajuste si tu souhaites transférer que 100 octets...
Normalement tu utilises le movem pour des gros transferts.
Pour de plus petits transferts tu utilises des "move" classiques.

Oui c'est pareil pour le 6280 les incrémentations sont gratuite, mais sur le 68000 les transferts sont limités à 60 octets max,donc si tu dois transferer plus faut bien que tu gere ça à la mano, pas avec le CPU de la nec,car la taille à transfèrer est de 16 bit max ..
Et puis movem transfère bien que des word non ???

Tu sais, normalement tu écris ta fonction memcpy intelligemment :) pour les petits transfert tu auras forcément un moindre rapport mais tu as le meme soucis avec ta pénalité d'init. Et souvent les bottleneck arrivent sur des gros transferts.
Quand tu dis que tes instructions sont de type DMA, tu veux dire que ça monopolise le BUS ? Sur MD il peut y avoir un avantage a ne pas utiliser le DMA qui monopolise le BUS car celui est partagé avec le Z80. Même en utilisant toute la puissance du 68000 pour faire un transfert mémoire (à 1.9 Mo/s) le BUS et la mémoire (RAM comme ROM) sont suffisamment rapide pour donner la main au Z80 quand celui ci le nécessite. Par contre en utilisant le DMA, le Z80 n'a plus accés au BUS et reste bloqué s'il en a besoin le temps du DMA...

Oui les transferts de bloc monopolise le bus...
Donc, ne le prend pas mal, mais à chaque fois tu utilises un movem different, donc faut se casser le derche à chaque fois, pour bien agencer ton code ..
Sur le 6280, peut importe le nombre d'octets, et où,c'est toujours 6 cycles ..

Vu que c'est une instruction optimisée pour le transfert mémoire, j'imagine qu'il n'y a aucun moyen de descendre en dessous de 3 cycles pour un accés mémoire avec le 6280, en gros je me demandais si les 3 cycles était inhérent au CPU ou au BUS mémoire...
Je pensais que les CPU de la famille 6502 faisait un accés à la mémoire en 2 cycles, 3 cycles finalement c'est juste un de moins que le 68000... et un accés 8 bits comparé à l'accés 16 bits du 68000.

Non les accés memoire sur les 65x et de 2 types, zero page, et RAM classique ..
Avec 4 cycles pour la zero page (lecture/ecriture),et 5 pour la RAM ..

Sur MD la DMA est attaché au VDP, pas au 68000.
Du coup les DMA possibles sont les suivants :
ROM->VRAM, RAM->VRAM, VRAM->VRAM
ROM->CRAM, RAM->CRAM, CRAM->CRAM
ROM->VSRAM, RAM->VSRAM, VSRAM->VSRAM
La CRAM était le mémoire pour la palette et la VSRAM celle du scrolling vertical.
Après le DMA du VDP peut égalment faire du filling (remplir la mémoire d'un valeur donnée) sur la VRAM, CRAM et VSRAM.
Un point interessant du DMA c'est que t'as un pas d'incrementation variable pour la destination, ça permet de faire des conversions de tile plus facilement par exemple.

Sur le papier le DMA de la MD est vraiment bien foutu, bien mieux que celui de la PCE qui est basique .

en fait tu as toutes les combinaisons entre 8x8 et 32x32 :

8x8, 16x8, 8x16,
24x8, 8x24, 8x32, 32x8,
16x16, 16x24, 24x16,
16x32, 32x16,
24x24, 24x32, 32x24,
32x32

J'en ai tet oublié...

Pour les cycles movem, j'ai trouvé ca :
http://oldwww.nvg.ntnu.no/amiga/MC680x0_Sections/timmove.HTML

Mais c'est limite indigeste, ça prends combien de cycles concrètement un movem de la RAM vers la RAM ??
Pareil pour le move.w de la ram vers un registre(et non d'un immédiat) ???

C'est parce-que t'as pas l'habitude mais c'est très pratique :)
En gros tu fais un premier movem @src+,reg-list suivi d'un movem reg-list,@-dst
Normalement tu utilises ça en rentrée de fonction pour sauvegarder tes registres et les restaurer en fin de fonction.

Plus tu utilises de registres et plus tu caches la pénalité de base de l'instruction un peu comme ton init. Bien sur ça a ses limites et tu n'arrives jamais à 4 cycles / octet

mais par exemple avec ces 3 instructions :

movem.l (a0)+,d0-d7/a2-a6 / 124
movem.l d0-d7/a2-a6,-(a0) / 120
add.l #56, %a0 / 14


Soit 258 cycles pour 56 octets transférés soit 4.6 cycles / octet...
Et réellement tu peux pas descendre beaucoup en dessous car j'avais oublié qu'on doit tout de même incrémenter le registre d'index du fait de la manière dont fonctionne movem :-/
Enfin sur MD ça te permet quand même d'arriver à un débit 1.67 Mo/s avec le CPU.

Avec une séquence plus simple type :

move.l (a0)+,(a1)+ / 20

Tu consommes 20 cycles pour 4 octets transférés soit 5 cycles / octet soit un débit de 1.53 Mo/s.

Merci pour l'explication, mais tu vois que finalement, malgré la fréquence supérieure du 68000 on se rapproche du CPU de la PCE ..
Mais c'est toujours pareil, ton instruction movem.l, n'est valable que pour des multiples de 32 bits, donc pas toujours valables ..
Donc tes exemples sont performants, mais sur des nombre d'octets définis, tu utilises le bon moven qui va bien, mais si ta taille est variable,tu y perds forcement ..
Les instructions de transfert du CPU nec seront toujours aussi performante, peu importe la taille à déplacer, 20,30, 100,101 etc ..
toi tu seras obligé de jongler entre tout tes movem, donc perte de temps, donc de cycles, pour par exemple transférer 101 octets,on se rapproche alors encore plus du CPU nec, je me trompe ???

Et heu j'ai pas compris ta démo, y'a 3 gros sprites avec un seul plan ??
et les sprites ne sont même pas animés !
Je suis en train de faire une petite démo sur MD aussi, elle n'est pas terminé dans le sens ou j'ai besoin de l'optimiser :

Oups dsl, j'avais pas vu cette question ..
si les sprites sont animés,enfin ils se déplacent juste à l'écran, mais cette demo n'avait qu'un seul but, montrer à un possesseur d'une machine risc, qu'une console avec un CPU 8 bit, et des copros pouvait faire mieux, et en utilisant peu de CPU, c'est tout ..
y'a rien d'optimisé dedans, j'ai fais cette demo en environ 1 heure pour le code ..

Sinon pour ta video, j'avais déjà vu, et elle est pas mal,sur pce tu as ça :
https://youtu.be/XqfzSyCCfKs?t=53s

[Stef]

non en effet, elle peut pas en faire, tout se fait à la ligne sur PCE ..

T'as quand même un scrolling horizontal par ligne en hard ? ou tu dois tout faire à la H Int ? ce qui expliquerait pourquoi la démo que tu as faites vanter les 14 parallaxes (sur MD c'est cablé, t'as une table en VRAM contenant le scroll pour chaque scanline).

Sur snes oui, mais rien ne t'empeche de changer le mode lors des boss .
Sur PCe c'est comme sur Md, tu peux tout mixer ..

C'est quand même pas super pratique en condition réel de jeux, 2 tailles de sprites c un facteur limitant...

Effectivement je comprends pas trop là ..
tu lis un mot en 4 cycles, mais c'est en immédiat, pas en RAM ..
tu mets 8 cycle/word pour lire et écrire en RAM ???
Ou 8 pour lire et 8 autres pour écrire,parce que ca me parait bien peu ..

L'opération élémentaire de lecture ou d'écriture d'un mot en mémoire coute 4 cycles sur un 68000. Et quand je dis ça, c'est dans la théorie, en pratique quand tu veux faire un transfert mémoire, comme tu n'as pas d'instruction de transfert ou DMA comme sur le 6820 tu dois utiliser des combinaisons d'instructions et au mieux tu descend à 4.6 cycles par octet transférer.

Si tu prends l'instruction de base pour lire un mot depuis la RAM :
move.w (a0),d0
alors ça consomme 8 cycles.
Pour lire un double mot (32 bits) tu utilises :
move.l (a0),d0
qui consomme 12 cycles.

Et c'est normal car dans le premier cas on cas :
- lecture de l'instruction (qui est codé sur 16 bits) = 4 cycles +
- lecture du mot en mémoire = 4 cycles
total : 8 cycles

Dans le second cas on a :
- lecture de l'instruction (qui est codé sur 16 bits) = 4 cycles +
- lecture du premier mot en mémoire = 4 cycles +
- lecture du second mot en mémoire = 4 cycles
total : 12 cycles

Ensuite tu peux directement faire une copie d'un double mot en mémoire (+post incrémentation) avec l'instruction suivante :
move.l (a0)+,(a1)+
l'instruction consome 20 cycles ! c'est beaucoup mais normal :
- lecture de l'instruction (qui est codé sur 16 bits) = 4 cycles +
- lecture du premier mot en mémoire = 4 cycles +
- lecture du second mot en mémoire = 4 cycles +
- écriture du premier mot en mémoire = 4 cycles +
- écriture du second mot en mémoire = 4 cycles
total : 20 cycles pour lire 4 octets et écrire 4 octets.

Oui c'est pareil pour le 6280 les incrémentations sont gratuite, mais sur le 68000 les transferts sont limités à 60 octets max,donc si tu dois transferer plus faut bien que tu gere ça à la mano, pas avec le CPU de la nec,car la taille à transfèrer est de 16 bit max ..
Et puis movem transfère bien que des word non ???

Oui effectivement sur le 68000 tu n'as pas d'instruction de transfert (come sur le 6820 ou meme le Z80) mais ce n'est pas vraiment génant, je me suis écrit un fonction memcpy qui seulement la taille du transfert va optimiser la copie.
movem peut transférer des word comme des dword.

Oui les transferts de bloc monopolise le bus...
Donc, ne le prend pas mal, mais à chaque fois tu utilises un movem different, donc faut se casser le derche à chaque fois, pour bien agencer ton code ..
Sur le 6280, peut importe le nombre d'octets, et où,c'est toujours 6 cycles ..

C'est tet plus simple à programmer mais du coup tu vois la limite direct, et tu as toujours le temp d'init qui fait que tu dois l'utiliser qu'au dessus de 4/5 octets j'imagine... et comme je disais plus haut sur 68000 tu adaptes ton code selon la taille à transférer.

Non les accés memoire sur les 65x et de 2 types, zero page, et RAM classique ..
Avec 4 cycles pour la zero page (lecture/ecriture),et 5 pour la RAM ..

Ca me parait beaucoup, surtout sachant que vous avez peu de registres sur le CPU et donc probablement beaucoup d'accés en page zero... certes les instructions prennent moins de cycles mais je pense qu'il faut 3 instructions 6820 (ou 6502) là ou une instruction 68000 suffit.

Sur le papier le DMA de la MD est vraiment bien foutu, bien mieux que celui de la PCE qui est basique .

Ben quand tu l'auras essayé tu pourras le confirmer :p

Merci pour l'explication, mais tu vois que finalement, malgré la fréquence supérieure du 68000 on se rapproche du CPU de la PCE ..

Ohlàlà gros racourcis ! déjà au début tu soutenais que le CPU de la PCE était plus rapide et maintenant tu dis qu'ils sont proche malgré la fréquence supérieur de la MD.
Il me semble que la fréquence de la PCE c'est 7.16 c'est ça ? la MD c'est 7.67 donc t'en conviendras la différence n'est pas énorme... et pourtant même à fréquence égale on voit bien que le 68000 garde l'avantage grace à son architecture 16 bits. Je dis pas que c'est toujours le cas, mais dans la majorité des cas il sera plus rapide que le CPU de la PCE... si on s'amuse à comparer à celui de la SNES qui tourne à 3.57 Mhz ça fait mal surtout qu'il tourne souvent à une fréquence plus basse.

Mais c'est toujours pareil, ton instruction movem.l, n'est valable que pour des multiples de 32 bits, donc pas toujours valables ..
Donc tes exemples sont performants, mais sur des nombre d'octets définis, tu utilises le bon moven qui va bien, mais si ta taille est variable,tu y perds forcement ..
Les instructions de transfert du CPU nec seront toujours aussi performante, peu importe la taille à déplacer, 20,30, 100,101 etc ..
toi tu seras obligé de jongler entre tout tes movem, donc perte de temps, donc de cycles, pour par exemple transférer 101 octets,on se rapproche alors encore plus du CPU nec, je me trompe ???

Sur les petites copies en taille variable (< 8 octets) j'utilise un table de jump dans une sequence de move.
en gros ca me fait une penalité de 30 cycles pour l'init mais ensuite la copie est optimisée car seul le dernier byte est copié via un move.b, donc peut être que pour des transferts < 8 bytes le 6820 va plus vite mais le 68000 reprend très vite l'avantage avec un code bien écrit

Oups dsl, j'avais pas vu cette question ..
si
les sprites sont animés,enfin ils se déplacent juste à l'écran, mais
cette demo n'avait qu'un seul but, montrer à un possesseur d'une machine
risc, qu'une console avec un CPU 8 bit, et des copros pouvait faire
mieux, et en utilisant peu de CPU, c'est tout ..
y'a rien d'optimisé dedans, j'ai fais cette demo en environ 1 heure pour le code ..

Ok ok je comprends mieux, forcément quand tu as des capacités hardware ça aide...

Sinon pour ta video, j'avais déjà vu, et elle est pas mal,sur pce tu as ça :
https://youtu.be/XqfzSyCCfKs?t=53s

La vidéo que tu as vu n'est pas ma démo, celle que tu as vu utilises une resolution entrelacée avec des bordure, moi je suis en fullscreen sans entrelacement, mais pas à pleine vitesse (pour le moment).

Pour ta démo, c'est plutot sympa mais le frame rate et la taille de la fenêtre sont assez réduit j'ai l'impression :p

[MikeeMike_2008]

Dans ghouls'n ghost, Arthur peut tirer en haut et en bas, ce qui est bien pratique pour se débarrasser des fripouilles du jeu. :) La version Megadrive est très fidèle à l'arcade pour ce qui est du gameplay. Techniquement et graphiquement, c'est d'un bon niveau, surtout face aux versions micro 16bit. Il faut se replacer dans le contexte de l'époque, avec une quantité de mémoire limité, donc un jeu un peu moins riche mais avec un prix démocratique... 450 francs quand même. Sur NeoGeo, pas de concession bien sûr, avec le clinquant Magician lord, mais vendu bien plus cher et moins kiffant qu'Arthur.

Dans Super ghouls'n ghost, Arthur ne sait plus se battre ! C'est horrible de voir un monstre passer dessous Arthur, sans que ce dernier puisse s'en débarrasser en tirant simplement vers le bas. Il faut reculer et attendre que le monstre se positionne en face du héros... c'est vraiment horripilant.

maintenant joue a la version supergraphx (c'est la version la plus proche de l'arcade)... et oublie la version md :lol:

[Stef]

Dans ghouls'n ghost, Arthur peut tirer en haut et en bas, ce qui est bien pratique pour se débarrasser des fripouilles du jeu. :) La version Megadrive est très fidèle à l'arcade pour ce qui est du gameplay. Techniquement et graphiquement, c'est d'un bon niveau, surtout face aux versions micro 16bit. Il faut se replacer dans le contexte de l'époque, avec une quantité de mémoire limité, donc un jeu un peu moins riche mais avec un prix démocratique... 450 francs quand même. Sur NeoGeo, pas de concession bien sûr, avec le clinquant Magician lord, mais vendu bien plus cher et moins kiffant qu'Arthur.

Pour nuancer quand même mes propos j'ai surtout connu Ghouls'n Goblins
sur arcade, j'ai découvert Ghouls'n Ghost sur megadrive que je trouvais
très décevant comparé au Goblins arcade... après c'est vrai que le Ghost
arcade a aussi des bruitages de merde (mais les graphismes sont bien
mieux que sur MD).
Le truc qui m'a choqué quand même sur MD c'est l'animation des arbres avec le vent, 2 pauvres images avec de la pluie carrément pas crédible... aie aie aie. Le problème c'est qu'à l'époque ils étaient très radin sur la taille des cartouches, 512 ko c'était vraiment pas beaucoup non plus... les animations étaient baclées au possible, et les bruitages aussi, pour moi ça détruisait purement et simplement le jeu.

[MikeeMike_2008]

D'ailleurs, c'est le sujet de ce post: Snes - Megadrive - PC Engine VS Neo Geo (et non pas Snes VS Megadrive)

je suis d'accord mais tu remarqueras il y a 3 consoles 16bits et une 8bits dans ce lot.... bon d'accord faut bien relevé le niveau .... rhhha satané megadrive quel furoncle ...

et tu peux faire comme tu veux, tous les styles de jeux représentés sur neogeo n'a aucun équivant techniquement parlant sur les 3 autres consoles, le fossé est trop grand !!! donc autant s'amuser en débattant avec les trois autres .... c'est plus fun surtout avec la megadrive

[philip]

Le problème c'est qu'à l'époque ils étaient très radin sur la taille des cartouches, 512 ko c'était vraiment pas beaucoup non plus... les animations étaient baclées au possible, et les bruitages aussi, pour moi ça détruisait purement et simplement le jeu.

oui c'est sûr qu'avec le double de mémoire, ils auraient pu mettre plus d'étapes d'animations. C'est en quelque sorte un témoignage sur le coût de la mémoire à l'époque. :)

[MikeeMike_2008]

quand on regarde le coût d'une cartouche neogeo a l'epoque c'est 2000frs, megadrive 500frs, snes 600frs, pc engine 450 et supergraphx 500/600

et quand on regarde la taille des roms utilisés on se rend compte que le meilleur rapport qualité/quantitatif/prix c'est la neo qui l'emporte

résultat sega, nintendo, nec s'en mettent pleins les poches non ??

donc la taille des cartouches est une fausse excuse surtout qu'a la fin de vie de la megadrive et snes les roms prenaient beaucoup plus de place pour un prix similaire

[philip]

[quote="MikeeMike_2008"]

et tu peux faire comme tu veux, tous les styles de jeux représentés sur neogeo n'a aucun équivant techniquement parlant sur les 3 autres consoles, le fossé est trop grand !!! donc autant s'amuser en débattant avec les trois autres .... c'est plus fun surtout avec la megadrive

Techniquement la Megadrive et la Neo Geo sont identiques, dans le sens où le prix des jeux AES sont exorbitant:

1 jeu AES = 5 jeux Megadrive

A chacun de juger.

quand on regarde le coût d'une cartouche neogeo a
l'epoque c'est 2000frs, megadrive 500frs, snes 600frs, pc engine 450 et
supergraphx 500/600

prix de ghoul'n'ghost Megadrive à sa sortie:
450 francs (et dans un magasin spécialisé). Tout les jeux Megadrive n'étaient pas aussi cher.

[MikeeMike_2008]

Techniquement la Megadrive et la Neo Geo sont identiques, dans le sens où le prix des jeux AES sont exorbitant:

Techniquement la Megadrive et la Neo Geo sont identiques ... non la franchement on a pas du jouer aux même consoles

sans déconner d'un côté tu as de l'arcade avec les meilleures réalisations du moment et de l'autre t'as beau avoir 4 cartouches pour le prix d'une mais a chaque fois tu serres les fesses pour éviter la daube, surtout que même ses propre licence sont mal adaptées car une 8bits arrive a un résultat meilleur une fois sur deux.... dur non ?

[philip]

Techniquement la Megadrive et la Neo Geo sont identiques, dans le sens où le prix des jeux AES sont exorbitant:

Techniquement la Megadrive et la Neo Geo sont identiques ... non la franchement on a pas du jouer aux même consoles

sans déconner d'un côté tu as de l'arcade avec les meilleures réalisations du moment et de l'autre t'as beau avoir 4 cartouches

Non, c'est plutôt 5 cartouches.... A moins que tu pense aux jeux 32X ?

[MikeeMike_2008]

prix de ghoul'n'ghost Megadrive à sa sortie:
450 francs (et dans un magasin spécialisé). Tout les jeux Megadrive n'étaient pas aussi cher.

dans ce cas les jeux pc engine c'est 350 pour les plus cher et de 400 a 500 pour la sgx mais bon a 50frs près c'est la même donc pour tes calculs 4 jeux a 512 ca fait 2mo pour 2000 frs et pour ce prix sur neogeo tu as bien plus

le problème c'est le résultat...et surtout par rapport a une 8bits ! (va faire un tour en page 5 de ce topic et tu verras que la pauvre md a bien du mal !!!!) alors imagine face a la neogeo

[philip]

@MikeeMike_2008/ Tu es probablement passé à côté de The Revenge of shinobi, un jeu qui à l'époque m'a scotché avec Ghouls'n ghost. Mais concernant les jeux 8bit, il y a justement le master converter pour la Megadrive. Et c'est une extension plutôt cool avec des jeux comme Choplifer, Y's, et le premier Shinobi. :)
La Megadrive couvre ainsi une très longue époque de l'histoire du jeu vidéo.

En fait, la Megadrive a été vendu sous différentes formes: console de salon à cartouche, PC286, le megaCD pour une excellente restitution des musiques, la technologie 32bit avec le 32X, console avec megaCD intégré (multi-mega) puis portable avec la nomade. Et enfin portable avec jeux intégrés à un prix très faible dans les magasins de jouet. En fait, dans notre pays, et au Brésil aussi, elle a toujours été en vente !

En comparaison, la Neo Geo fut beaucoup moins accessible, ce n'est pas une critique, mais un constat d'un modèle économique différent et exclusif, qui la rendu... inaccessible.

[MikeeMike_2008]

avant la megadrive la pc engine en 1987 était déjà là et même son cd rom (et je précise c'est du 8bits et c'est autre chose que les jeux master sytem tout de même !!!! car depuis deux pages on compare des jeux pce a la md et non sms), lorsque la megadrive arriva en 1989 il y avait déjà pas mal de références sur la pce.... la megadrive était déjà limite has been face aux nec 8bits elle n'apporta quasi rien de plus surtout sur son début et surtout pas le "son" face au cd rom nec !!!, après la snes est venue enfoncer le clou avec tous ses effets et ce n'est surement pas son 32x ou son mega cd qui améliora la qualité des jeux surtout que ca se passe en 1994 lorsque la ps1 sort au japon c'est la loose totale les extentions megadrive

donc en 87/88 si tu possédais déjà la pc engine et son cd rom ca ne servait a rien de se prendre une megadrive en valait mieux attendre la snes en 91

[Invité]

T'as quand même un scrolling horizontal par ligne en hard ? ou tu dois tout faire à la H Int ? ce qui expliquerait pourquoi la démo que tu as faites vanter les 14 parallaxes (sur MD c'est cablé, t'as une table en VRAM contenant le scroll pour chaque scanline).

Sur pce c'est classique, tu scrolles tout l'écran sur X,Y(juste un registre 16 bit pour chaque axes sur le VDC) pour le faire à la ligne il te faut passer par une interruption ..
Mais verticalement tu peux pas le faire à la ligne, ni à la tile,c'est tout l'écran ..

C'est quand même pas super pratique en condition réel de jeux, 2 tailles de sprites c un facteur limitant...

Bien sur que ça l'est pas, mais c'est une solution .

L'opération élémentaire de lecture ou d'écriture d'un mot en mémoire coute 4 cycles sur un 68000. Et quand je dis ça, c'est dans la théorie, en pratique quand tu veux faire un transfert mémoire, comme tu n'as pas d'instruction de transfert ou DMA comme sur le 6820 tu dois utiliser des combinaisons d'instructions et au mieux tu descend à 4.6 cycles par octet transférer.

Si tu prends l'instruction de base pour lire un mot depuis la RAM :
move.w (a0),d0
alors ça consomme 8 cycles.
Pour lire un double mot (32 bits) tu utilises :
move.l (a0),d0
qui consomme 12 cycles.

Et c'est normal car dans le premier cas on cas :
- lecture de l'instruction (qui est codé sur 16 bits) = 4 cycles +
- lecture du mot en mémoire = 4 cycles
total : 8 cycles

Dans le second cas on a :
- lecture de l'instruction (qui est codé sur 16 bits) = 4 cycles +
- lecture du premier mot en mémoire = 4 cycles +
- lecture du second mot en mémoire = 4 cycles
total : 12 cycles

Ensuite tu peux directement faire une copie d'un double mot en mémoire (+post incrémentation) avec l'instruction suivante :
move.l (a0)+,(a1)+
l'instruction consome 20 cycles ! c'est beaucoup mais normal :
- lecture de l'instruction (qui est codé sur 16 bits) = 4 cycles +
- lecture du premier mot en mémoire = 4 cycles +
- lecture du second mot en mémoire = 4 cycles +
- écriture du premier mot en mémoire = 4 cycles +
- écriture du second mot en mémoire = 4 cycles
total : 20 cycles pour lire 4 octets et écrire 4 octets.

AAaaah je comprends mieux là, merci ..
Oui donc au final c'est pareil, sur le 6280, un mot en zero page prend 8 cycles au total, et 10 pour la RAM .
Donc 4 octets à lire sur le 6280 prennent au min 16 cycles,au max 20 .
Et autant en écriture,mais j'ai aucune pénalité par contre ..
Donc le 68000 est plus rapide entre 16bit -> 32 bit ..
le plus, après ton 4 signifie bien que dans certain cas tu as une pénalité, elle est de combien ??
eheh faut la prendre en compte aussi ..

Oui effectivement sur le 68000 tu n'as pas d'instruction de transfert (come sur le 6820 ou meme le Z80) mais ce n'est pas vraiment génant, je me suis écrit un fonction memcpy qui seulement la taille du transfert va optimiser la copie.
movem peut transférer des word comme des dword.

Ok mais là c'est moins efficace que sur le 6280 dés que tu dépasse tes 60 octets , ou que tu termines par un seul octets à transférer .
Rien de dramatique, mais tout ça fait que finalement, malgré sa fréquence supèrieure, il font jeu égal .

C'est tet plus simple à programmer mais du coup tu vois la limite direct, et tu as toujours le temp d'init qui fait que tu dois l'utiliser qu'au dessus de 4/5 octets j'imagine... et comme je disais plus haut sur 68000 tu adaptes ton code selon la taille à transférer.

Oui bien sur, ces instructions sont pratiques pour de gros transfert, pas pour moins d'un long mot ..
Mais si tu le fais de façon classique, via une boucle tu verras que tu consommes bcp,bcp plus ..

Ca me parait beaucoup, surtout sachant que vous avez peu de registres sur le CPU et donc probablement beaucoup d'accés en page zero... certes les instructions prennent moins de cycles mais je pense qu'il faut 3 instructions 6820 (ou 6502) là ou une instruction 68000 suffit.

Bien sur si tu fais de l'immédiat c'est 2 cycles, en plus rentre en compte le pipe du CPU, mais on en tient pas compte dans les calculs.

Ben quand tu l'auras essayé tu pourras le confirmer :p

J'y songe depuis un moment, bien avant la PCE en fait, et puis les circonstance ont fait que ..

Ohlàlà gros racourcis ! déjà au début tu soutenais que le CPU de la PCE était plus rapide et maintenant tu dis qu'ils sont proche malgré la fréquence supérieur de la MD.
Il me semble que la fréquence de la PCE c'est 7.16 c'est ça ? la MD c'est 7.67 donc t'en conviendras la différence n'est pas énorme... et pourtant même à fréquence égale on voit bien que le 68000 garde l'avantage grace à son architecture 16 bits. Je dis pas que c'est toujours le cas, mais dans la majorité des cas il sera plus rapide que le CPU de la PCE... si on s'amuse à comparer à celui de la SNES qui tourne à 3.57 Mhz ça fait mal surtout qu'il tourne souvent à une fréquence plus basse.

Dans certains cas il l'est dans d'autre non, donc au final je pense que malgrè sa fréquence plus faible il fait jeu égal, et d'ailleurs les jeux montre bien que la MD n'est pas supérieure ..
A ce niveau, même pas j'y pense au CPU de la snes, tellement c'est une tortue, mais on sait tout les 2, qu'une console ne se résume pas à son seul CPU .
CF, l'amiga ..

Sur les petites copies en taille variable (< 8 octets) j'utilise un table de jump dans une sequence de move.
en gros ca me fait une penalité de 30 cycles pour l'init mais ensuite la copie est optimisée car seul le dernier byte est copié via un move.b, donc peut être que pour des transferts < 8 bytes le 6820 va plus vite mais le 68000 reprend très vite l'avantage avec un code bien écrit

Voilà, tu vois que tout n'est pas rose, donc sur l'ensemble du code d'un jeu, la fréquence supérieure de la MD ne se voit plus ..

Ok ok je comprends mieux, forcément quand tu as des capacités hardware ça aide...

Bah oui, avoir un super CPU c'est super bien, mais si tu bouffe tout pour faire ce qu'un console 8 bit fait, et mieux, je vois pas trop l'intérêt .
Et donc la personne soutenait qu'un CPU risc @mhz,c'était forcement mieux que des copros, voilà rien de plus ..
Pas que j'étais un super codeur de la mort et que la PCE défonce tout ...

La vidéo que tu as vu n'est pas ma démo, celle que tu as vu utilises une resolution entrelacée avec des bordure, moi je suis en fullscreen sans entrelacement, mais pas à pleine vitesse (pour le moment).

Pour ta démo, c'est plutot sympa mais le frame rate et la taille de la fenêtre sont assez réduit j'ai l'impression :p

Ok, j'avais un peu lu le tread sur le site, tu parlais ç un moment avec un tomaitheous, lui c'est un bon dev PCE, il a fait un lecteur de module XM ,6voix sur PCE, bon ça bouffe 70% de CPU, mais c'est impressionnant .
Sinon oui le frame rate est réduit, et la fenêtre aussi, mais son auteur n'as pas passé le même temps dessus que toi, et en plus elle est en 16 couleurs .
Mais ta demo est une belle prouesse si tu arrives à la finir, félicitations :thumright:

[philip]

avant la megadrive la pc engine en 1987 était déjà là et même son cd rom (et je précise c'est du 8bits et c'est autre chose que les jeux master sytem tout de même !!!! car depuis deux pages on compare des jeux pce a la md et non sms), lorsque la megadrive arriva en 1989 il y avait déjà pas mal de références sur la pce.... la megadrive était déjà limite has been face aux nec 8bits elle n'apporta quasi rien de plus surtout sur son début et surtout pas le "son" face au cd rom nec !!!, après la snes est venue enfoncer le clou avec tous ses effets et ce n'est surement pas son 32x ou son mega cd qui améliora la qualité des jeux surtout que ca se passe en 1994 lorsque la ps1 sort au japon c'est la loose totale les extentions megadrive

donc en 87/88 si tu possédais déjà la pc engine et son cd rom ca ne servait a rien de se prendre une megadrive en valait mieux attendre la snes en 91

Chaque console est intéressante, mais tu semble avoir des aprioris concernant la Megadrive. A l'époque, c'était pour moi impossible de passer à côté de The Revenge of shinobi et ghouls'n'ghost. Pour ce dernier, tu oppose la supergraphx, une console disponible en petite quantité car morte né, et elle n'est pas la pc-engine... tu avais acheté à l'époque la console pc-engine avec son lecteur CD + la console supergraphx ? Je n'ose imaginer le coût de l'ensemble.

Pour info, la playstation et la saturn, française, c'était plutôt 1995. Et une année dans la vie d'un joueur, c'est long. Tu balais d'un revers de main l'extension de la Megadrive, le 32X, alors que la pc-engine avait elle aussi une architecture hardware ouverte... avec donc une extension. Ces consoles sont évolutives, et donc super bien pensé.

[Invité]

HEy vous deux !
Vous devriez unir vos karmas pour nous pondre un Mega Homebrew !
Sachez que je partage vos points de vue sur les portages baclés... Ils auraient pu faire mieux pour certains jeux sur md, et à n'en citer que quelques-uns : Golden Axe, Altered Beast (il manque le ciel gris lors des boss fights, et le vilain ne change pas de taille), Ghouls n ghost le décors de fond du second niveau est "étrange" alors que sur PCE il est vraiment plus fidèle à l'arcade. Forgotten worlds, idem..çà sent la flemme. Pourtant je suis pro MD, et j'en viens à me troller moi-même...Touko déteint sur moi je crois. Même sur mega cd, ils sont restés paresseux, même pas de zoom sur Samourai Showdown...Nan ce n'était pas l'arcade à la maison. Ne parlons pas non plus de la catastrophe graphique du premier Mortal Kombat sur md. Je suis sûr qu'ils auraient pu faire beaucoup mieux.

[philip]

@Touko. Tu aura beau retourner le problème dans tout les sens, mais un 68000 donne plus de possibilité qu'un 6502. La Megadrive et la Neo Geo partage la même résolution, 320x224, et la même famille de cpu, 68000+Z80, c'est ainsi.

Tu balais d'un revers de main le deuxième layer de la megadrive, mais c'est l'architecture arcade de l'époque qui veut ça: deux plans, c'est mieux qu'un seul. Le joueur voit bien quand le jeu défile sur un seul plan sur sa console 8bit, alors qu'en arcade il y en a deux...

[Stef]

Sur pce c'est classique, tu scrolles tout l'écran sur X,Y(juste un registre 16 bit pour chaque axes sur le VDC) pour le faire à la ligne il te faut passer par une interruption ..
Mais verticalement tu peux pas le faire à la ligne, ni à la tile,c'est tout l'écran ..

Ah ouais franchement c hyper rudimentaire comparé à la MD sur ce point, on est au niveau de la NES ou Master System.

La MD propose 3 modes de scrolling en horizontal :
plan / tile / scanline
et 2 modes en vertical :
plan / 2 tiles

A noter que sur SNES le 2e mode vertical fonctionne en tile et non 2 tiles comme sur MD. Mais pour l'époque la MD faisait déjà très fort de proposer ce scrolling vertical 2 tiles, c'est très couteux en performance sur le VDP (ça nécessite une RAM particulière rien que pour ça).

AAaaah je comprends mieux là, merci ..
Oui donc au final c'est pareil, sur le 6280, un mot en zero page prend 8 cycles au total, et 10 pour la RAM .
Donc 4 octets à lire sur le 6280 prennent au min 16 cycles,au max 20 .
Et autant en écriture,mais j'ai aucune pénalité par contre ..
Donc le 68000 est plus rapide entre 16bit -> 32 bit ..
le plus, après ton 4 signifie bien que dans certain cas tu as une pénalité, elle est de combien ??
eheh faut la prendre en compte aussi ..

Non non il n'y a pas de pénalité, les instructions 68000 ont un temps d'execution fixe sur MD car le BUS est plus rapide que le CPU, c'était juste pour symboliser l'addition des différentes étapes.

Ok mais là c'est moins efficace que sur le 6280 dés que tu dépasse tes 60 octets , ou que tu termines par un seul octets à transférer .
Rien de dramatique, mais tout ça fait que finalement, malgré sa fréquence supèrieure, il font jeu égal .

Mais mais non tu lis mal :p je pense que le seul cas ou ça peut être plus rapide sur le 6820 c'est quand tu fais un transfert de petite taille (genre < 16 octets) et si tu ne connais pas la taille du transfert à l'avance, dans tout les autres cas le 68000 est plus rapide, et sur de gros transferts il sera au moins 50% plus rapide, ce qui n'est pas négligeable... avec le DMA ça peut être jusqu'à 3x plus rapide :p

Oui bien sur, ces instructions sont pratiques pour de gros transfert, pas pour moins d'un long mot ..
Mais si tu le fais de façon classique, via une boucle tu verras que tu consommes bcp,bcp plus ..

Bien sur X'D
Mais si t'as besoin de performances, tu optimises ton code, tu vas pas utiliser un simple boucle avec un move.b, dans ce cas tu consommeras 22 cycles / octets et là c la misère... mais faudrait vraiment être un mauvais codeur pour faire ça alors que t'as besoin de transférer de gros blocs de mémoire... Transférer byte/byte sur 68000 c'est de l'hérésie :p

Bien sur si tu fais de l'immédiat c'est 2 cycles, en plus rentre en compte le pipe du CPU, mais on en tient pas compte dans les calculs.

je vois pas comment un immédiat 8 bits pourrait tenir dans 2 cycles car ça nécessite une lecture 8 bits et donc minimum 3 cycles en plus de l'instruction de base. A moins que ton immédiat soit 4 bits (voir 3 bits).
Enfin bon, ca ne change rien sur les copies mémoire...

Dans certains cas il l'est dans d'autre non, donc au final je pense que malgrè sa fréquence plus faible il fait jeu égal, et d'ailleurs les jeux montre bien que la MD n'est pas supérieure ..

Arf il en démord pas, je te démontre par A + B que le 68000 est plus rapide mais tu campes sur tes positions, on reconnait le fanatique :p

Voilà, tu vois que tout n'est pas rose, donc sur l'ensemble du code d'un jeu, la fréquence supérieure de la MD ne se voit plus ..

Ahah ouais dans 10% des cas le 6820 peu être plus rapide :p
Mais globalement le 68000 est plus rapide,et ce, même à fréquence équivalente.

Ok, j'avais un peu lu le tread sur le site, tu parlais ç un moment avec un tomaitheous, lui c'est un bon dev PCE, il a fait un lecteur de module XM ,6voix sur PCE, bon ça bouffe 70% de CPU, mais c'est impressionnant .
Sinon oui le frame rate est réduit, et la fenêtre aussi, mais son auteur n'as pas passé le même temps dessus que toi, et en plus elle est en 16 couleurs .
Mais ta demo est une belle prouesse si tu arrives à la finir, félicitations :thumright:

Oui je crois que j'en ai déjà entendu parler de ce player XM, l'avantage sur PCE c'est que tu peux avoir 6 voix PCM assez facilement, sur MD c'est le Z80 qui doit les mixer car y'a qu'une voix PCM hard.
Merci pour les commentaires sur ma démo, j'espère en arriver à bout quand même

[MikeeMike_2008]

des aprioris concernant la Megadrive

biensur que oui, pourquoi ? comment une console 16 bits peut proposer des "sons" aussi merdique (la nec fait mieux !!), aucun effets de hardware digne de ce nom (rien de plus que la nec !!!), et un jeu sur deux c'est de la daube (voir plus et ce n'est surement pas le cas de la nec lorsque l'on regarde sa logithèque)

tu oppose la supergraphx, une console disponible en petite quantité car morte né, et elle n'est pas la pc-engine

non ce n'est pas la même console que la pce mais elle est compatible 100% pce et améliore même le nombre de sprites de certains jeux et pas besoin d'acheter une extention de merde pour faire passer les jeux de la pce c'est du direct

après rendre évolutif son produit c'est bien mais ce qui n'est pas bien c'est d'attendre la prochaine génération de console pour sortir son produit, résultat son produit est a l'ouest total côté rendu on voit bien qu'il y a une grosse génération d'écart entre un jeu 32x et ps1, ca s'appel "je vous prends pour des pigeons", il n'avait qu'a le sortir en 1992 date charnière dans le jeux video, beaucoup de jeux sur les 16 bits, un an d'implantation de la snes en europe et des ventes bien plus importante que la megadrive lancée en 1989 ca aurais été une bonne riposte a la snes, mais chez sega ils préfèrent les pigeons que veux tu

[chaberlo]

faut pas éxagerer, un jeu comme bar knuckle 2 serait infaisable sur nec (tout comme super nes) c'est un déluge de gros sprites (le mode mania est completement barré...:lol: avec des tonnes d'ennemis à l'écran) animés impecablement... et ce jeu écrase n'importe quel beat sur neo geo (car c'est la référence sur console) faut etre réaliste.

[Invité]

SEGA Fais n'importe quoi !

[Agathon]

biensur que oui, pourquoi ? comment une console 16 bits peut proposer des "sons" aussi merdique (la nec fait mieux !!), aucun effets de hardware digne de ce nom (rien de plus que la nec !!!), et un jeu sur deux c'est de la daube (voir plus et ce n'est surement pas le cas de la nec lorsque l'on regarde sa logithèque)

Tu t'es fais choper en douce derriere un mur par le punk dans la pub SEGA, c'est pas possible d'etre aussi haineux autrement...

SEGA Fais n'importe quoi !

Clairement oui aujourd'hui...mais bon c'est leur politique, c'est eux qui payeront...

[MikeeMike_2008]

et ce jeu écrase n'importe quel beat sur neo geo

Tu t'es fais choper en douce derriere un mur par le punk dans la pub SEGA, c'est pas possible d'etre aussi haineux autrement

c'est ce que sega voulais je te l'accorde mais ca na pas marché, d'ailleur tu remarqueras a chaque fois il se fait niquer le punk

L’éditeur nippon légendaire et interplanétaire, a dévoilé quelques précisions sur sa restructuration… De fait, la fermeture des filiales française, belge, hollandaise, luxembourgeoise, et allemande (et secondairement en Australie), sont annoncées et malheureusement confirmées… L’éditeur prend plutôt cette restructuration comme un nouveau départ, et un moyen de se concentrer sur une nouvelle stratégie. Mouais… On y croit moyen. En tout cas voilà ce que dit le communiqué de presse :

« SEGA entre dans une nouvelle phase excitante de son développement, qui vise à promouvoir et à maximiser les ventes de franchises fortes et équilibrées, comme Sonic, Total War, Football Manager et Aliens. La société va pleinement profiter de ce recentrage clair et d’une stratégie repensée pour nos contenus numériques et nos produits en boîte, et nous pensons que cela nous sera très bénéfique à l’avenir »

voila ce que sega fait en 2012...... magnifique :lol:

[Agathon]

Clairement que de la merde...

Mais je sais pas sil faut en rire. Car c'est quand meme une boite legendaire qui perd pied, ou la créativité était quasiment inégalée.

Bref, dommage que strategiquement, ça na jamais suivi.

[MikeeMike_2008]

oui une boite légendaire en arcade avec son fameux shinobi, after burner 360...

mais dès que l'on passe côté consoles il n'y a guère que la dreamcast qui se démarque le reste