Anthologie Super Nintendo - Geeks-Line

Et le BG3 qui est un petit plus non négligeable.

Je dirai même un gros plus, tu peux faire pas mal de choses avec .

Les 20% ça serait dommage que le chipset sonore ne peut pas accéder a la ROM :p

Oui ça c'est une belle erreur, ne pas avoir au moins prévu un mécanisme plus simple et rapide que l'actuel .
Certains utilisent le HDMA pour envoyer des données dans la RAM audio, mais je sais pas dans quelles proportions c'est applicable pour un jeu(si ça l'est) .

Après tu dis que tu t'acharne pas sur la SNES ? lol
Je code dessus et une ligne me suffirait , c'est l'OAM en 16 bits 80% des soucis résolu
Les 20% ça serait dommage que le chipset sonore ne peut pas accéder a la ROM :p

Quand tu as pas mal codé sur MD et que tu arrives sur SNES, qui est quand même censé être une machine bien plus performante car 2 ans plus récente ben tu réalises qu'il y a tromperie sur la marchandise si j'ose dire.
Je te demandais pas quels sont les défauts qui te gênent sur SNES, moi perso dans ce cas sur MD, y'a juste les 4 palettes qui m'embêtent, le reste me va très bien...

Car là par exemple, tu ne parles pas du memory map pourri (c'est pas toi qui parlais de la limite des 8Ko de RAM ?), tu ne parles pas non plus de la limite des sprites carrés avec seulement 2 tailles possible, ni de la limite des 16KB... alors peut être que toi, ce sont des problèmes qui ne t'ont pas touché pour l'instant mais selon le style de jeu que tu veux développer (et surtout quand tu as pas mal touché à la MD avant) ben tu risques d'être vraiment limiter avec ces contraintes à un moment donné. l'OAM pour moi au final, c'est plutot une épine mais pas tant une contrainte.

LA SNES peut faire les mul et division beaucoup plus rapidement que la MD ! (et pour le mul ça peut être assez utilise dans certain cas avons le ^^)

Franchement je trouve que c'est un sacré raccourci de dire ça...
Je t'invite à lire ce topic où on a déjà pas mal débattu de la multiplication / division des 2 machines :
https://forums.nesdev.com/viewtopic.php?f=12&t=10957&start=105

Déjà que je trouve que la multiplication 16x16=32 et la division 32:16=16.16 du 68000 t limite pas mal alors une multiplication / division 8 bit :-/
Vu que tu dois set/get les registres sur SNES et vu les contraintes de taille des registres, à l'usage tu es très souvent plus rapide avec le 68000 (au moins sur la multiplication, et je ne parle pas en nombre de cycles mais globalement bien sur).

Le SPC700 possède aussi un mul en 9 cycles et un div en 12 cycles. (tu va me dire que pour un proc sonore osef , mais je pense que bien utilisé cela peut être utile).

Au contraire, je trouve ça tout à fait pertinent d'avoir ça sur le proc sonore :) côté "traitement" sonore, il y a pas photo, la SNES balaie la MD (tu ne fais pas grand chose de ce côté avec le Z80) ! Mais le problème, c'est cette fichue limite sur la mémoire de travail. Et je dirais que pour le coup, c'est une contrainte bien plus forte et pénalisante que l'apport des effets spéciaux sur le son (qui est toujours appréciable bien sur).

Et le BG3 qui est un petit plus non négligeable.

Ca je suis d'accord, surtout pour les HUD je trouve...
Mais là encore, à choisir, je pense que je préfère le 320x224 de la MD avec son ratio 4:3 correct

Après y'a plein de trucs sympa sur SNES, les effets de transparence, le mode 7, le HDMA... on va pas lui enlever ça non plus 

Mais ce qui me gène, c'est qu'en sortant 2 ans plus tard cette machine aurait du être quasiment en tout point supérieur à la MD et c'est très loin le cas.
Par exemple quand tu compares la PCE et la MD, il y a 1 an qui les sépare et excepté sur le nombre de palette (largement en faveur de la PCE il faut le dire), la MD lui est en tout point supérieure, en plus il me semble que les 2 machines étaient vendues au même prix.

Ca je suis d'accord, surtout pour les HUD je trouve...
Mais là encore, à choisir, je pense que je préfère le 320x224 de la MD avec son ratio 4:3 correct 

Perso non, le 3ieme plan est une feature bien plus utile que le 320 pour moi, son apport est qd même bien plus agréable au niveau codeur(hud, profondeur de scrolling, ou autre comme TMNT4) ainsi que visuel (tout les jeux dispos sur les 2 machines et utilisant ce plan sur snes montre un visuel bien plus flateur et agréable),alors que le 320 qui est dispensable et seulement préférable à du 256 rien de plus .

Mais ce qui me gène, c'est qu'en sortant 2 ans plus tard cette machine aurait du être quasiment en tout point supérieur à la MD et c'est très loin le cas.

Je suis d'accord, mais tu sais pertinement comme moi, qu'aucune machine ne peut être parfaite, même la NG ne l'est pas .
Et tu crois que 4 palettes, pas d'interruptions sur le YAM, le banking catastrophique de la Md ne pouvait pas être évité, alors que la PCE sortie avant faisait ça proprement ??
Ce sont des choix des fois de merde, pour on ne sait quelle raison.
Le tout est de savoir, que peut on faire de mieux avec le hardware à disposition ??, et là chaque machine aura son domaine de prédilection .

la MD lui est en tout point supérieure, en plus il me semble que les 2 machines étaient vendues au même prix.

Mais n'importe quoi,encore une foi, ce n'est pas vrai,il faut encore qu'on débâte là dessus ou quoi ??
Donc la supergrafx est meilleure en tout point à la MD .

Touko a écrit:La MD lui est en tout point supérieure, en plus il me semble que les 2 machines étaient vendues au même prix.
Mais n'importe quoi,encore une foi, ce n'est pas vrai,il faut encore qu'on débâte là dessus ou quoi ??
Donc la supergrafx est meilleure en tout point à la MD .

Heu... objectivement Touko, à part sur le nombre de palette je veux bien que tu me dises un seul point où la PCE est supérieur à la MD (techniquement je veux dire).

Mode stef ON:
Cpu, transferts VRAM(si tu gardes un écran de 224),et pas limité au vblank, résolution, flexibilité du VDC,sprites, même si sur PCE tu est limité à 64 leur taille jusqu'à 32x64 est un plus,hardware bien mieux conçu y'a rien de tordu, SAT mieux foutue, puce son plus flexible, et qualité audio bien meilleure, samples bien plus facile à faire, sur SGX je crache du 32khz avec 5% de CPU,tu peux faire du sample simple 5bits, 10 bits en utilisant 2 voix, ou mixer 2/4 voix 8 bits sans perte (en utilisant aussi 2 voix),interruptions .

La Md est meilleure sur les tailles intermédiaires des sprites, avec la taille min de 8 pixels, 2 nd bckgnd, et affichage chunky si tu fais de la 3D,et le vscroll à la tile est une bonne idée,priorité à la tile, flip X/Y des tiles .
Franchement la partie audio est un blague, avec un Z80 à la ramasse tellement il est bridé,le hscroll est une astuce pour palier la lenteur des interruptions du 68k, et pas flexible pour un sou .

Master palette sur 9 bits, donc identique sur les 2 .
Mode stef OFF:

Donc avis en toute objectivité .

Touko a écrit:Cpu, transferts VRAM(si tu gardes un écran de 224),et pas limité au vblank, résolution, flexibilité du VDC,sprites, même si sur PCE tu est limité à 64 leur taille jusqu'à 32x64 est un plus,hardware bien mieux conçu y'a rien de tordu, SAT mieux foutue, puce son plus flexible, et qualité audio bien meilleure, samples bien plus facile à faire, sur SGX je crache du 32khz avec 5% de CPU,interruptions .

La Md est meilleure sur les tailles intermédiaires des sprites, avec la taille min de 8 pixels, 2 nd bckgnd, et affichage chunky si tu fais de la 3D,et le vscroll à la tile est une bonne idée .
Franchement la partie audio est un blague, avec un Z80 à la ramasse tellement il est bridé,le hscroll est une astuce pour palier la lenteur des interruptions du 68k, et pas flexible pour un sou .

Master palette sur 9 bits, donc identique sur les 2 .

Non mais c'est du flan tout ça tu abuses
Le CPU de la PCE est performant c'est sur, mais ça reste un CPU 8 bits bien moins confortable à coder que le 68000.
Et à part la résolution où tu peux monter en 512 effectivement (mais bon tu es hors specs et les sprites ne s'y prêtent pas vraiment), pour tout le reste c'est juste du super subjectif sérieux ! La MD a un CPU dédié pour le son, le 32 Khz c'est 0% de CPU...

"CPU, transferts VRAM...SAT mieux foutue, puce son plus flexible, meilleur qualité audio..." .. non mais arrête, c'est ridicule
Je regrette de t'avoir lancé là dessus, déjà avec la SNES tu exagérais mais alors là tu es no limit 

Stef a écrit:

Après tu dis que tu t'acharne pas sur la SNES ? lol
Je code dessus et une ligne me suffirait , c'est l'OAM en 16 bits 80% des soucis résolu
Les 20% ça serait dommage que le chipset sonore ne peut pas accéder a la ROM :p

Car là par exemple, tu ne parles pas du memory map pourri (c'est pas toi qui parlais de la limite des 8Ko de RAM ?), tu ne parles pas non plus de la limite des sprites carrés avec seulement 2 tailles possible, ni de la limite des 16KB... alors peut être que toi, ce sont des problèmes qui ne t'ont pas touché pour l'instant mais selon le style de jeu que tu veux développer (et surtout quand tu as pas mal touché à la MD avant) ben tu risques d'être vraiment limiter avec ces contraintes à un moment donné. l'OAM pour moi au final, c'est plutot une épine mais pas tant une contrainte.

Je l'avais déjà dit mais je vais me répéter
L'OAM 8 bits à plusieurs conséquence , la première , vu le nombre limité de bits limité cela réduit à 16kb les données adressable , de même que pour les 2 tailles possible de taille carré parce que ben il y'a seulement un bit dédié pour ça...
donc si OAM était en 16 bit on pourrait avoir 64kb adressable , plusieurs taille possible et la position x demanderai moins de calcul

La memory map est pourri certe mais je m'y fais , t'imagine bien que avec le nombre de console que je me suis tapé la SNES est pas ce qui me gene le plus , les 8kb directement c'est un peu gênant , mais pas le plus gros défaut de la console.


La multiplication plus longue sur SNES ? lol
Euh voila  une partie de mon code pour le ring menu :

Code:

 lda s_menu+_ringi ; 3 cycle
 sta WRMPYA ; 3 cycle
 
 
 lda MEM_TEMPFUNC+2 ; 3 cycle
 sta WRMPYB ; 3 cycle
 nop ;2 cycle
 nop ;2 cycle
 nop ;2 cycle
 nop ;2 cycle
 ldy RDMPYL ; 3 cycle+1 (16 bits)
 sty MEM_TEMPFUNC+2 ; 3 cycle+1 (16 bits)
 ; total 28 cycle

Rappelle moi combien de cycle c'est pour la MD + Load/Store ?
(Et encore les nop tu peux faire un petit calcul pour pas attendre bêtement)

Le CPU de la PCE est performant c'est sur, mais ça reste un CPU 8 bits bien moins confortable à coder que le 68000.

Ca dépend, pour certaines choses oui, n'oublions pas qu'on parle de console, et pas d'un ordi, là oui le 68k est royal, mais gérer 64ko de RAM pour une console est facile (du moins sur PCE) car son mapper est simple à utiliser,et franchement l'ASM dessus est simple(tu n'es absolument pas aussi frustré que tu pourrais l'être sur un 6502,sauf pour un codeur 68k), même si le C est très confortable sur le 68k .
Et j'ai jamais dit que le 68k était un CPU chiant à coder,juste que perso, je le trouve pas spécialement adapté(par rapport au CPU de la PCE/SNES) à un système limité comme une console de jeu .

Et à part la résolution où tu peux monter en 512 effectivement (mais bon tu es hors specs et les sprites ne s'y prêtent pas vraiment),

Ah bon, et le 344 ??, y'a pas mal de jeux qui l'utilisent, même si la limite de 256 pixels sprites peut faire clignoter d'avantage les sprites ,elle est qd même bien utilisable, le 512 aussi, t'as bcp de jeux qui ne poseraient aucun problème .

La MD a un CPU dédié pour le son, le 32 Khz c'est 0% de CPU... 

Mais oui, le soucis c'est que tu peux pas dépasser les 26 khz 

"CPU, transferts VRAM...SAT mieux foutue, puce son plus flexible, meilleur qualité audio..." .. non mais arrête, c'est ridicule 

Non, non ,c'est factuel pas besoin d'exagérer,ça te fait juste mal au derche de l'admettre .

Pour le fun :
Organisation de la SAT sur MD :
http://md.squee.co/VDP#Sprites

Sur PCE:

Code:


          +---------------------------------------------------------------+
          |15 |14 |13 |12 |11 |10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
          +-----------------------+---------------------------------------+
          |                       |             y coordinate              |
          +-----------------------+---------------------------------------+
          |                       |             x coordinate              |
          +-------------------+---+---------------------------------------+
          |                   |              pattern address              |
          +---+---+-------+---+-------+---+---+-----------+---------------+
          | Y |   |  CGY  | X |       |CGX|PRI|           | palette index |
          +---+---+-------+---+-------+---+---+-----------+---------------+

Je regrette de t'avoir lancé là dessus, déjà avec la SNES tu exagérais mais alors là tu es no limit  

Enfin je suis qd même loin de ton objectivité légendaire .

Kannagi a écrit:La multiplication plus longue sur SNES ? lol
Euh voila  une partie de mon code pour le ring menu :

Code:

 lda s_menu+_ringi ; 3 cycle
 sta WRMPYA ; 3 cycle
 
 
 lda MEM_TEMPFUNC+2 ; 3 cycle
 sta WRMPYB ; 3 cycle
 nop ;2 cycle
 nop ;2 cycle
 nop ;2 cycle
 nop ;2 cycle
 ldy RDMPYL ; 3 cycle+1 (16 bits)
 sty MEM_TEMPFUNC+2 ; 3 cycle+1 (16 bits)
 ; total 28 cycle

Rappelle moi combien de cycle c'est pour la MD + Load/Store ?
(Et encore les nop tu peux faire un petit calcul pour pas attendre bêtement)

Ca marche comment en fait ? Y'a une puce dédiée ?

8 ou 16 bits les multiplications ?

Sinon, pourquoi stocker sur 68000 ? Y'a largement assez de registres

Kannagi a écrit:Je l'avais déjà dit mais je vais me répéter
L'OAM 8 bits à plusieurs conséquence , la première , vu le nombre limité de bits limité cela réduit à 16kb les données adressable , de même que pour les 2 tailles possible de taille carré parce que ben il y'a seulement un bit dédié pour ça...
donc si OAM était en 16 bit on pourrait avoir 64kb adressable , plusieurs taille possible et la position x demanderai moins de calcul

Autant pour moi, quand tu disais OAM 16 bits, je pensais aux coordonnées X/Y (car c'est souvent la position X splitté qu'on reproche). Tu cachais un peu tout "les problèmes des sprites" en une petite phrase subtile

La memory map est pourri certe mais je m'y fais , t'imagine bien que avec le nombre de console que je me suis tapé la SNES est pas ce qui me gene le plus , les 8kb directement c'est un peu gênant , mais pas le plus gros défaut de la console.

Dans mon cas, je ne parlais pas que de la fenêtre des 8 Ko de RAM mais de la complexité du memory map en général..
Sur MD c'est tellement plus simple avec un adressage sans système de bank (qu'on trouve plutot sur les machines 8 bits normalement).

La multiplication plus longue sur SNES ? lol
Euh voila  une partie de mon code pour le ring menu :

Code:

        lda s_menu+_ringi ; 3 cycle
 sta WRMPYA ; 3 cycle
 
 
 lda MEM_TEMPFUNC+2 ; 3 cycle
 sta WRMPYB ; 3 cycle
 nop ;2 cycle
 nop ;2 cycle
 nop ;2 cycle
 nop ;2 cycle
 ldy RDMPYL ; 3 cycle+1 (16 bits)
 sty MEM_TEMPFUNC+2 ; 3 cycle+1 (16 bits)
 ; total 28 cycle

Rappelle moi combien de cycle c'est pour la MD + Load/Store ?
(Et encore les nop tu peux faire un petit calcul pour pas attendre bêtement)

Mais là tu me parles d'une multiplication 8x8=16 là  
Le nombre de cycle sur la multiplication du 68000 est variable et dépend de la taille de ton opérande (ou plutot du nombre de bits à 1). Une multiplication 16x16=32 prend entre 38 et 72 cycles sur 68000, si tu te limites à du 8x8=16 alors tu ne prendras que 54 cycles max.

Les load et store coute 8+4 mais n'oublie pas que le 68000 a des registres là ou le CPU e la SNES ne te laisse pas le choix. Donc même si tu prends le worst case sur 68000, on a 54 + 12 = 66 cycles contre 28 cycles sur SNES.
L'unité de multiplication S-CPU est côté des registres $4000 et donc en slow access (1.79 Mhz).
Donc au final, même dans ce cas ça ira un peu plus vite sur le 68000 (qui tourne à 7.7 Mhz comparé au 65816 qui sera ~2.5 Mhz max à cause des slow access).. désolé

Et là je suis gentil car je considère ton best case, en réalité tu as souvent besoin de multiplications 16x16=32 et qui peuvent être signées et dans ce cas le 68000 prends largement l'avantage.

Ah oui, tu peux effectivement essayer de cacher la latence de l'unité de multiplication en placant du code à la place des nop mais franchement bonne chance pour faire ça sans y perdre avec un CPU qui a si peu de registres.

Touko a écrit:

Le CPU de la PCE est performant c'est sur, mais ça reste un CPU 8 bits bien moins confortable à coder que le 68000.

Ca dépend, pour certaines choses oui, n'oublions pas qu'on parle de console, et pas d'un ordi, là oui le 68k est royal, mais gérer 64ko de RAM pour une console est facile (du moins sur PCE) car son mapper est simple à utiliser,et franchement l'ASM dessus est simple(tu n'es absolument pas aussi frustré que tu pourrais l'être sur un 6502,sauf pour un codeur 68k), même si le C est très confortable sur le 68k .
Et j'ai jamais dit que le 68k était un CPU chiant à coder,juste que perso, je le trouve pas spécialement adapté(par rapport au CPU de la PCE/SNES) à un système limité comme une console de jeu 8 bits.

En corrigeant ta phrase, je suis d'accord avec toi

C'est tellement pratique, un CPU à 3 registres avec un adressage minimal, que toutes les machines postérieures à la MD en proposaient...

Ah tiens non, y'a que la SNES (et la SGX mais c'est particulier).

Stef a écrit:

Kannagi a écrit:Je l'avais déjà dit mais je vais me répéter
L'OAM 8 bits à plusieurs conséquence , la première , vu le nombre limité de bits limité cela réduit à 16kb les données adressable , de même que pour les 2 tailles possible de taille carré parce que ben il y'a seulement un bit dédié pour ça...
donc si OAM était en 16 bit on pourrait avoir 64kb adressable , plusieurs taille possible et la position x demanderai moins de calcul

Autant pour moi, quand tu disais OAM 16 bits, je pensais aux coordonnées X/Y (car c'est souvent la position X splitté qu'on reproche). Tu cachais un peu tout "les problèmes des sprites" en une petite phrase subtile

Hé hé oui subtile en effet

Pour la multiplication la SNES pour ma part à l'avantage pour le 8 bits.
Et pour le 8x16 semblable a la MD (vu qu'il faudrait juste changé WRMPYB et additionné vers la fin donc je dirait que ça ferait en 8x16 60 cycles).
Et plus longue pour le 16x16 :)

@Tryphon
La multiplication est hardware , comment ça marche bonne question , je vois mal une puce dédié pour ça mais pourquoi pas ! x)
Sinon pour les 3 registres c'est une question d'habitude , l’accès a la RAM n'est pas problématique sur une telle machine comparé au génération suivante où on commence à avoir une mémoire cache à cause de l’accès à la RAM de plus en plus lente.

NT: Sinon j'ai fait de 68000 sur MD et Neo Geo (et un peu sur Atari ST ) donc inutile de me l'apprendre

Ca dépend, pour certaines choses oui, n'oublions pas qu'on parle de console, et pas d'un ordi, là oui le 68k est royal, mais gérer 64ko de RAM pour une console est facile (du moins sur PCE) car son mapper est simple à utiliser,et franchement l'ASM dessus est simple(tu n'es absolument pas aussi frustré que tu pourrais l'être sur un 6502,sauf pour un codeur 68k), même si le C est très confortable sur le 68k .
Et j'ai jamais dit que le 68k était un CPU chiant à coder,juste que perso, je le trouve pas spécialement adapté(par rapport au CPU de la PCE/SNES) à un système limité comme une console de jeu .

Non mais là vraiment je ne peux rien dire quoi  
Tu préfère coder avec un CPU 8 bits avec accés par bank, sans multiplication... qu'un CPU 16 bit qui t'offre un adressage 24 bits et des opérations 32 bits et qui tu permet aussi de coder en C et d'avoir de bonne performance.
Bon franchement non quoi, ne défends pas ça s'il te plait  
Autant je reconnais qu'en performance le CPU de la PCE est surement équivalent au 68000 (ça va dépendre des cas on va dire) mais sur le reste bon..

Ah bon, et le 344 ??, y'a pas mal de jeux qui l'utilisent, même si la limite de 256 pixels sprites peut faire clignoter d'avantage les sprites ,elle est qd même bien utilisable, le 512 aussi, t'as bcp de jeux qui ne poseraient aucun problème.

Pour moi le 344 c'est un peu l'équivalent du 320 (tu as 24 pixels de plus bon heu...) c'est pour ça que j'en parlais pas, alors que 512 c'est vraiment au dela.

Mais oui, le soucis c'est que tu peux pas dépasser les 26 khz 

Alors d'une part sur ce genre de machine je dirais "la belle affaire" mais en plus c'est faux, alors arrête de répéter cette erreur car tu aimerais que ce soit vrai   Je l'ai toujours dit et aujourd'hui on sait que j'avais raison (lis donc le topic YM2612 sur spritemind et les dernières découvertes par rapport au DAC). Il n'y a avait aucune raison que le DAC fonctionne à la moitié de la fréquence du YM et j'avais bien observé que ce n'était effectivement pas le cas... bref, on a du donc du 53 Khz max, mais réellement encore une fois, on s'en fout de ça car tu vas jamais utiliser de sample à 53 Khz...

Non, non ,c'est factuel pas besoin d'exagérer,ça te fait juste mal au derche de l'admettre .

Non mais sérieux tu veux vraiment qu'on discute de ça ??
Il n'y a pas de DMA sur la ta machine, en étant sérieux, tu transfert combien max réellement par frame sur PCE sachant qu'il faut garder du CPU pour le jeu ? C'est ridicule cet argument pour le coup. Certes tu peux transférer à plein vitesse pendant la frame mais sans DMA je dirais que tu n'as pas vraiment le choix non plus. Et sur MD *tu peux* transférer pendant la frame (beaucoup plus lentement mais c'est possible, on est pas sur SNES :p).

Ensuite par rapport à la SAT, en quoi elle est mieux sur PCE ?? Il y a juste moins de choses dedans mais les données sont très bien organisées sur MD..

C'est tellement pratique, un CPU à 3 registres avec un adressage minimal, que toutes les machines postérieures à la MD en proposaient...

Ce que j'aime c'est ta façon de schématiser, déjà tu utilises pas un 65xx comme un 68k, tu as ce qu'on appelle la zero page qui est un espace en RAM accessible en 3 cycles et qui te sert de registres si tu en as besoin,donc c'est bcp moins impactant/gênant que tu peux le penser .
Ensuite limiter la réflexion au nombre de registres, et qd même bien basique comme façon de penser .

Non mais sérieux tu veux vraiment qu'on discute de ça ??
Il n'y a pas de DMA sur la ta machine, en étant sérieux, tu transfert combien max réellement par frame sur PCE sachant qu'il faut garder du CPU pour le jeu ?

8ko .
Je parle pour un gros jeu, après tu peux adapter en fonction des besoins, donc monter plus haut, ou descendre bien sur .

Et sur MD *tu peux* transférer pendant la frame (beaucoup plus lentement mais c'est possible, on est pas sur SNES :p).

Mais oui, c'est tellement génial et simple, que tout le monde le fait .

Alors d'une part sur ce genre de machine je dirais "la belle affaire" mais en plus c'est faux

Ah bon, c'est marant mais tu l'as affirmé y'a pas très longtemps encore dans le snes vs Md .
Sinon petite quote de l'équipe titan :

I tried to account for both in my music routine to keep jitter down to an inaudible or at least barely audible level. And beware of the music routine in general, I developed it from scratch to support 26 kHz sample playback with nearly no jitter, and for that used every available trick. Also it reads the VDP’s V counter, make sure your emulator supports this when there are music issues.

C'est assez explicite non ??,c'est la limite max sans artefacts,et en même temps c'est pas comme si ce fait n'était déjà pas connu des autres codeurs TMEE/sik pour ne citer qu'eux .

Ensuite par rapport à la SAT, en quoi elle est mieux sur PCE ?? Il y a juste moins de choses dedans mais les données sont très bien organisées sur MD..

Quoi tu dis que j'abuse et tu es pas capable de faire toi même l'analyse ??

Ensuite par rapport à la SAT, en quoi elle est mieux sur PCE ?? Il y a juste moins de choses dedans mais les données sont très bien organisées sur MD..

C'est pas le bordel non plus ,mais c'est clairement pas aussi propre que sur PCe, et encore je parle pas du bordel pour adresser le VDP par rapport au VDC de la pcengine .

Kannagi a écrit:Pour la multiplication la SNES pour ma part à l'avantage pour le 8 bits.
Et pour le 8x16 semblable a la MD (vu qu'il faudrait juste changé WRMPYB et additionné vers la fin donc je dirait que ça ferait en 8x16 60 cycles).
Et plus longue pour le 16x16 :)

Pourtant en réalité même pour une multiplication 8 bit tu n'es pas plus rapide sur SNES (j'ai donné les chiffres plus haut). Si tu veux faire on peut benchmarker les 2 pour s'en assurer. Je pense que pour le 8 bits la MD a déjà l'avantage (petit certes) mais qui se creuse largement pour le 16 bit ou plus.

Stef a écrit:

Kannagi a écrit:Pour la multiplication la SNES pour ma part à l'avantage pour le 8 bits.
Et pour le 8x16 semblable a la MD (vu qu'il faudrait juste changé WRMPYB et additionné vers la fin donc je dirait que ça ferait en 8x16 60 cycles).
Et plus longue pour le 16x16 :)

Pourtant en réalité même pour une multiplication 8 bit tu n'es pas plus rapide sur SNES (j'ai donné les chiffres plus haut). Si tu veux faire on peut benchmarker les 2 pour s'en assurer. Je pense que pour le 8 bits la MD a déjà l'avantage (petit certes) mais qui se creuse largement pour le 16 bit ou plus.

Fait donc sachant que sur SNES la multiplication est entre 20-28 cycle (tu peux très bien mettre du code entre encore heureux , sinon ça serait impossible à optimiser le SH4 ) , ça demande juste un peu de d'organisation du code , sur mon ring menu pour les nop je peux par exemple faire un lda + pha par exemple :)

Non mais sérieux tu veux vraiment qu'on discute de ça ??
Il n'y a pas de DMA sur la ta machine, en étant sérieux, tu transfert combien max réellement par frame sur PCE sachant qu'il faut garder du CPU pour le jeu ?

8ko .

La MD c'est 7.3 KB de base et tu passes assez facilement à 10 KB en blankant quelques lignes.
Ensuite, montre moi des jeux PCE qui envoie 8 ko par frame régulièrement car perso j'en vois pas  :)
Sachant que 8Ko c'est 50000 cycles soit à peu près 40% de ton budget CPU si mes calculs sont bons.

I tried to account for both in my music routine to keep jitter down to an inaudible or at least barely audible level. And beware of the music routine in general, I developed it from scratch to support 26 kHz sample playback with nearly no jitter, and for that used every available trick. Also it reads the VDP’s V counter, make sure your emulator supports this when there are music issues.

Et ??? le gars dit qu'il a développé un driver pour avoir un playback à 26 Khz, où c'est écrit que c'est le max ?? Et limite osef, *on sait* que ça supporte 53 Khz, alors arrête de prétendre le contraire car tu aimerais que ça soit le cas, c'est pénible cette désinformation

Kannagi a écrit:

Fait donc sachant que sur SNES la multiplication est entre 20-28 cycle (tu peux très bien mettre du code entre encore heureux , sinon ça serait impossible à optimiser le SH4 ) , ça demande juste un peu de d'organisation du code , sur mon ring menu pour les nop je peux par exemple faire un lda + pha par exemple :)

Franchement si tu arrives à placer du code sans perte dans les nop, bravo :p  Surtout qu'il y a quoi, 8 cycles à remplir ? Vu que tu es obligé de travailler n'importe quelle donnée depuis la mémoire, le gain est tout de suite perdu...
Aussi le SH4 a pléthore de registre donc c'est beaucoup plus simple...

La MD c'est 7.3 KB de base et tu passes assez facilement à 10 KB en blankant quelques lignes.

C'est ce que j'ai dis, sans toucher à l'affichage .

Ensuite, montre moi des jeux PCE qui envoie 8 ko par frame régulièrement car perso j'en vois pas  :)

Ecoutes j'ai pas envie de passer mon temps avec ça, si tu es sceptique, pas de soucis .

Sachant que 8Ko c'est 50000 cycles soit à peu près 40% de ton budget CPU si mes calculs sont bons.

Oui et ??, le jeu air zonk qui est un shmup claque 30/35 % de CPu rien que pour son driver PCM, il est où le problème ??
C'est pas comme si la console n'était pas connue pour la qualité de ses animations .
Et dans tes 7.3ko, faut que tu vires le transfert de la SAT, hscroll, vscroll, donc on tombe à 6ko .

Et ??? le gars dit qu'il a développé un driver pour avoir un playback à 26 Khz, où c'est écrit que c'est le max ?? Et limite osef, *on sait* que ça supporte 53 Khz, alors arrête de prétendre le contraire car tu aimerais que ça soit le cas, c'est pénible cette désinformation 

Ahahaha, montres moi un PCM 53 khz ??,tu sais aussi bien que moi que c'est impossible à atteindre .
26khz est le max admis par la scène MD, sauf toi .
Ensuite qu'est ce que je m'en fou, sur PCE tu dépasses les 100khz, franchement ça me fait ni chaud ni froid .

Touko a écrit:Oui et ??, le jeu air zonk qui est un shmup claque 30/35 % de CPu rien que pour son driver PCM, il est où le problème ??
C'est pas comme si la console n'était pas connue pour la qualité de ses animations .

Mais justement je dirais, le CPU a en plus le son a gérer, donc tu ne vas pas gâcher 40% juste pour transférer des datas. Ca reste possible cela dit, mais bon sur MD tu as beaucoup d'astuce pour pousser aussi... Et juste pour 8Ko, tu peux déborder un peu sur la frame, ça rentrera sans soucis si j'ose dire.
Alors oui tu peux transférer à pleine vitesse pendant la frame sur PCE comparé à la MD mais pour moi c'est juste que c'est vital puisque tu n'as pas de DMA, j'ai du mal à voir ça comme un réel avantage de ce fait.

Touko a écrit:

C'est tellement pratique, un CPU à 3 registres avec un adressage minimal, que toutes les machines postérieures à la MD en proposaient...

Ce que j'aime c'est ta façon de schématiser, déjà tu utilises pas un 65xx comme un 68k,

Ah mais je suis d'accord : tu l'utilises comme un 8 bits

tu as ce qu'on appelle la zero page qui est un espace en RAM accessible en 3 cycles et qui te sert de registres

8 bits

si tu en as besoin,donc c'est bcp moins impactant/gênant que tu peux le penser .

Ensuite limiter la réflexion au nombre de registres, et qd même bien basique comme façon de penser .

Tu sais, tous les CPU sont des machines de Turing : tu peux tout faire avec n'importe lequel. Donc si je suis ta logique, un 4004 à 500 Mhz aurait largement suffi pour la SNES...

Mais justement je dirais, le CPU a en plus le son a gérer, donc tu ne vas pas gâcher 40% juste pour transférer des datas.

tu fais exprès de pas comprendre ou quoi ??
Je te dis qu'un shmup dépense presque la même chose qu'un transfert de 8ko,juste dans un driver PCM en bois,je compte pas la musique la dedans,c'est que le driver PCM.
Même celui de SF2 fait 20/25% mais pour 2 voix.
Remplaces les 30/35 % pris inutilement par le PCM, et affectes les aux transferts,donc avec 8ko de transfert tu fais encore facilement tourner un shmup derrière .

8 bits

tu sais, 2x8 bits = 16   ,et l'avantage d'être découpée en 2 parties est aussi de pouvoir optimiser les accès, tu touches pas à la partie high (ou low) de ta valeur si tu n'en as pas besoin .
J'avais donné l'exemple de l'incrément d'un pattern d'un sprite 32x32, tu incrémentes ton adresse de 256 soit $100 .

Tu sais, tous les CPU sont des machines de Turing : tu peux tout faire avec n'importe lequel. Donc si je suis ta logique, un 4004 à 500 Mhz aurait largement suffi pour la SNES...

Bonne idée, essayes, car c'est dommage que ce soit pas ma logique, mais bon, si tu veux le croire,et puis j'adore l'exemple de l'extrême 

Touko a écrit:Ahahaha, montres moi un PCM 53 khz ??,tu sais aussi bien que moi que c'est impossible à atteindre .
26khz est le max admis par la scène MD, sauf toi .
Ensuite qu'est ce que je m'en fou, sur PCE tu dépasses les 100khz, franchement ça me fait ni chaud ni froid .

Purée mais tu n'en démords pas c'est dingue quoi. Le 26 Khz il vient de Tiido, qui avait dit ça il y a fort longtemps.. et ça a été repris effectivement. J'avais discuté avec lui à ce sujet car moi je n'avais pas observé cette limite.
Aujourd'hui on sait qu'il avait tord, mais toi tu t'entêtes à répéter ça car ça t'arrange (on a des images du die qui confirme que le registre du DAC est bien refresh à chaque cycle, de toute façon ce 26 Khz n'avait aucun sens). Et perso dans le fond je m'en fous moi qu'on puisse faire du 53 Khz car encore une fois ça ne sert à rien (et les filtres de base de la machine vont de tout façon virer toutes les fréquences au dessus de 14/15 Khz donc à moins d'avoir un mod CCAM tu n'entendras pas la différence de toute façon).
Ce qui me gène par contre, c'est que tu répandes cette fausse information et tu insistes avec comme à ton habitude, ça a le don de m'énerver car c'est à cause de gars comme toi (que beaucoup prenne comme expert) qu'on peut lire autant de connerie sur le net. On a le droit de se tromper mais quand on sait qu'on a tord on rectifie... si ça entretient la désinformation.

Tiens sinon un morceau à 32 Khz sur MD, et tu peux essayer sur ta MD tu verras qu'elle n'explose pas ou qu'il n'y a pas de bug du YM (car j'ai déjà lu ça aussi, si on envoie trop vite dans le DAC ça plante ) :
https://www.dropbox.com/s/yg8lz4vomapzu7m/draculax-snd.bin?dl=0

et en même temps c'est pas comme si ce fait n'était déjà pas connu des autres codeurs TMEE/sik pour ne citer qu'eux

Merci mais je code aussi sur MD    Et je pense que je n'ai plus à faire mes preuves de ce côté... Tmee ou Sik n'ont pas toujours raison mais bien sur quand ça va dans ton sens, ça t'arrange   Mais eux contrairement à toi, ils savent reconnaitre quand ils avaient tord (poses leur de nouveau la question par rapport au 26 Khz).

Si tu cherches l'information par rapport au DAC, tu peux la trouver là dedans :
http://gendev.spritesmind.net/forum/viewtopic.php?f=24&t=386&start=840

Tmee ou Sik n'ont pas toujours raison mais bien sur quand ça va dans ton sens, ça t'arrange 

Tu peux me repprocher bcp de chose, mais pas de travestir, je te l'ai dit je me suis tapé tout le topic sur le 2612 de sprites mind, et je vois rien dedans qui contredit les 26khz ou la possibilité du 53khz (car il est impossible de synchroniser parfaitement l'envoie de samples),ni personne qui remet cette valeur en question,maintenant si tu as un topic ou les 32khz sont approuvés, je veux bien le lire ..
En tout cas une chose est sure, le 53khz, même pas en rêve .

Peut être qu'un de ces 4 quelqu'un montrera que c'est possible, mais pour le moment non .

Touko a écrit:

Tmee ou Sik n'ont pas toujours raison mais bien sur quand ça va dans ton sens, ça t'arrange 

Tu peux me repprocher bcp de chose, mais pas de travestir, je te l'ai dit je me suis tapé tout le topic sur le 2612 de sprites mind, et je vois rien dedans qui contredit les 26khz ou l'impossibilité du 53khz (car il est impossible de synchroniser parfaitement l'envoie de samples),ni personne qui remet cette valeur en question,maintenant si tu as un topic ou les 32khz sont approuvés, je veux bien le lire ..
En tout cas une chose est sure, le 53khz, même pas en rêve .

Peut être qu'un de ces 4 quelqu'un montrera que c'est possible, mais pour le moment non .

Est-ce que tu as bien lu le topic ? Le truc de la synchro c'est du obvious (comme Sauraen l'a fait remarqué, n'importe quel guignol qui fait un peu de son connait ça). En gros ils disent que si tu joues à 44 Khz alors ça fait de l'aliasing... sans blague  
En étant à 26 Khz tu es plus ou moins à la moitié de 53 Khz donc oui c'est mieux car tu évites l'aliasing (ou y'en a moins). Mais ça n'empêche pas de faire du 32 / 44 / 50 Khz.. c'est juste qu'il faut que tu saches que derrière ça sera envoyé à 53 Khz c'est tout... Et en réalité, si tu t'attaches à faire du pur PCM, tu peux passer le YM en mode full DAC, en gros tu connectes directement le DAC à la sortie du YM, y'a plus rien d'autre... et là tu es no limit en terme de sampling rate (mais ça n'a aucun intérêt puisque tu perds la partie FM )

et là tu es no limit en terme de sampling rate (mais ça n'a aucun intérêt puisque tu perds la partie FM )

Ca c'est comment marche la puce de la PCE actuellement en mode DDA pour chacune de ses voix, sans trick,et tu as en plus le volume et le panning,et sans perdre la partie son classique.

D'ailleurs je vois que tu as relancé le débat le 22 novembre, et la réponse est pour moi celle que j'ai donné, à savoir l'impossibilité de faire de la synchro parfaite avec le DAC .
Le problème ne se poserait pas avec un DAC externe dédié au PCM, mais là la fenêtre d'accès au DAC étant assez réduite(merci le 2612+ multiplexage), c'est mission impossible, ça termine en write miss,d'où les problèmes de distorsion .

SIK a écrit:PCM data straight up can't be faster than ～26KHz (i.e. half the sample rate at which FM updates), writing faster than that outright results in missed samples. It may be slower than you think.

In fact it'd be probably a good idea seeing how fast each of the $2x registers is. They by-pass the shifter (as they're global) which at first may make it look like they may work faster, but after some issues I've had some time ago and the key-on thing (not to mention the well known slowness of the PCM output) I'm starting to think they may be slower in general (probably depends on each particular register, so that's gonna need a lot more of testing).

TMEE a écrit:t is possible to update DAC once every sample if you have cycle synchronity to the YM. I did some tests where YM and Z80 were made to share the clock in MD and I could get unique samples out every 144 cycles. Doing rates between full and half sample rate are very ugly though due to the "resampling" effect, leading to pretty nasty sound (which is why I originally thought samples get missed). Unfortunately YM and Z80 don't share clock in YM and it is not possible to maintain any cycle level synchronity with the YM, especially when any ROM access is being done which adds uncertain amount of latency to the operation.

Réponse de jotego à TMEE:

I agree. An update of exactly 144 cycles (that is to say 24 FM ticks) will work. By the way, any PCM rate that is not an integer multiple of 24 FM ticks will eventually have sound artifacts. I don't know if software developers were aware of this. Probably not.
For instance, if you update at 36 FM ticks half your samples will take two output slots (48 ticks) and the other half only one (24 ticks) so on average you do have (48+24)/2 = 36 ticks per sample but they will not be evenly output to the DAC so there will be very noticeable distortion.

Tu es le seul à soutenir ça,donc faire du >26khz avec un son pourri, bof .

Tu es le seul à soutenir ça,donc faire du >26khz avec un son pourri, bof .

Oui super, merci et au revoir :-)

De rien,c'était avec plaisir . 

Je crois que ça montre bien le problème :-)
J'avais raison et maintenant tu essaies de noyer le poisson.. j'arrête de discuter avec toi.

 génial .

Touko a écrit:tu sais, 2x8 bits = 16   ,et l'avantage d'être découpée en 2 parties est aussi de pouvoir optimiser les accès, tu touches pas à la partie high (ou low) de ta valeur si tu n'en as pas besoin .
J'avais donné l'exemple de l'incrément d'un pattern d'un sprite 32x32, tu incrémentes ton adresse de 256 soit $100 .

Tu sais, tous les CPU sont des machines de Turing : tu peux tout faire avec n'importe lequel. Donc si je suis ta logique, un 4004 à 500 Mhz aurait largement suffi pour la SNES...

Bonne idée, essayes, car c'est dommage que ce soit pas ma logique, mais bon, si tu veux le croire,et puis j'adore l'exemple de l'extrême 

Ce qui est génial, c'est que tes deux parties se répondent

Je n'ai fait que forcer le trait, mais tu continues à utiliser le 65816 comme un CPU... 8 bits

T'imagines, s'il était 4 bits, tu pourrais additionner 16, 256, ou 4O96, plein de valeurs hyper-intéressantes, en touchant seulement un quartet