Re: Anthologie Super Nintendo - Geeks-Line

[tyler-durden76]

Dois je préciser que j'ai commandé mon exemplaire de Paprium sur megadrive en mai 2017... Faut vraiment que j'arrête de me faire plumer.

[mysato]

si la bible pix t as déplu à ce point alors n achete pas celle de geeks line.

Peux-tu me dire pour quelles raisons ? C'est encore moins bon ?
 
De mon côté, à la FNAC chez moi ils n’ont pas reçu le livre. D’habitude ils en ont au moins un exemplaire pour que l'on regarde. Mais là rien du tout.

[Mastergurt]

Je préfère le packaging de l' edition Pix.
 C est dommage ils ont balance le master de cette version à la va-vite, pas de relecture exhaustive, sûrement faute de temps. 
Sont là pour se faire du pognon sur la vague rétro. On sent une volonte de bien faire mais au final il reste toujours ce sentiment de travail bouclé à l' arrache.

[Stef]

J'ai acheté la partie hardware uniquement car j'avoue ne pas être intéressé par le reste.
Ils détaillent effectivement pas mal certains aspects hardware de la machine (ce qui n'est pas souvent le cas ou jamais à ce point dans un magazine) et il y a aussi quelques informations intéressantes aussi sur la retro compatibilité abandonnée de la NES (notamment le fait que ça a été abandonné plus pour des raisons de cout que des raisons technique).

Par contre bon c'est un peu dommage d'avoir mis tant de subjectivité sur la partie hardware (et particulièrement à propos du CPU), on a l'impression que c'est Touko qui a écrit certaines parties
Et c'est dommage car parfois on y lit vraiment de la fausse information et des erreurs, on sent qu'il y a de vraie lacunes techniques parfois de la part des auteurs qui ont été récupérer les infos ici et là (et notamment sur le forum NesDev). Et ils vont même jusqu'à se contredire sur certains points ce qui rend la lecture un peu confuse... Par exemple ils laissent clairement entendre que le CPU de la SNES est mieux adapté aux développement des jeux que celui de la MD et qu'il est même plus performant car il effectue plus d'instructions / seconde... vraiment quand tu lis au final tu as l'impression que le CPU de la SNES est plus performant malgré sa faible fréquence. Et plus tard ils te disent que "la SNES n'en mène pas large face à la MD ou la NeoGeo"... ça tombe comme ça un peu comme un cheveu sur la soupe.
On sent qu'ils s’emmêlent un peu les pieds dans leurs explications et dans leurs arguments pour essayer de défendre le CPU sur cette machine (et plus particulièrement le choix de Nintendo).
C'est vraiment dommage car ils auraient pu faire une vraie analyse du CPU avec ses avantages et ses inconvénients mais à la place ils nous ont fait du Touko-isme (bon désolé Touko mais c'est vraiment un peu leur syndrome dans un sens), comme s'il fallait plaire aux lecteurs (qui doivent être des fans de la machine en grande partie).
Un autre exemple, ils vont affirmer que le CPU est vraiment 16 bits car il y une ALU 16 bits mais ils omettent complètement le fait que le CPU utilisent un BUS de données 8 bits (alors que c'est limite une information plus pertinente sur la performance du CPU), ce qui fait qu'il prend plus de temps pour faire une opération 16 bits que 8 bits au final quoiqu'il arrive... et comme le CPU ne peut pas avoir de BUS de donnée 16 bits (il faudrait revoir tout le design du CPU) alors on ne peut décemment pas dire qu'il s'agit là d'un vrai CPU 16 bits (au mieux un hybride 8/16 bits). Enfin bref, allez avoue Touko, c'est un ami à toi qui a écrit ce livre

Enfin c'est sûr, ça ravira les fans

[Invité]

on a l'impression que c'est Touko qui a écrit certaines parties 

Et après tu viens faire ton caliméro, putain ça me saoule  ..
Après si ce livre te fait enfin comprendre toutes les conneries que tu sors depuis des années, moi je dis 

[Stef]

Prends le pas comme ça.. c'était pour expliquer rapidement la tournure des choses dans ce livre. Et je dois admettre que par rapport à avant tu es plus modéré et objectif... Mais tu devrais le lire à l'occasion, je suis sûr qu'il te plaira

[tyler-durden76]

Bon apparemment tout le monde à reçu son exemplaire de l'anthologie. Visiblement j'ai précommandé l'édition DTC. Le service client est inexistant chez Geeks Line. 4 message envoyés et toujours pas de réponse. Je precise que j'ai précommandé mon exemplaire en octobre 2017. Foutage de gueule royale. Je pollue maintenant leur page Facebook et ils ne répondent pas plus.

[mysato]

Merci Stef pour ton retour. Ce genre d'avis m'a convaincu de prendre ce bouquin.

Après étant un grand lecteur de multiples forums/commentaires depuis des années, je sais que tu as pour habitude d'utiliser ton expérience sur la megadrive pour asseoir tes arguments. Ce qui te donne un aplomb pas toujours justifié à mon sens, puisque tu n'es pas neutre dans les débats au vu de ta passion aveuglante pour la megadrive.

Cela dit, ces remarques venant d'un programmeur passionné de megadrive et critiquant un ouvrage sur la super nintendo qui parle de technique me fait dire que la lecture du livre risque d'être bien sympathique. J'achète, je le lis et je reviens vous dire ce qu'il en est.

[Stef]

Justement j'allais revenir par rapport à ce que j'ai dit plus haut.
Je n'avais pas terminé la lecture du livre et au final mon avis (après l'avoir fini) est plus modéré
En fait après la description hardware tu as une partie "les faiblesses de la machine" et dans cette partie, ils abordent quelques défauts de la machine qu'ils ont, du coup, probablement volontairement occultés de la partie "description hardware" pour en parler dans cette section.

Je trouve ça un peu génant car si tu ne lis que la partie hardware (CPU / graphique / sonore) c'est franchement un peu incomplet sur certains aspects, et je dirais même que il y a des choses fausses sur la partie CPU (surtout lorsqu'ils tentent de le comparer au 68000 par exemple). Si tu ne connais pas grand chose dans le domaine alors tu vas vraiment en ressortir avec une mauvaise vision de la réalité. Mais je dois admettre qu'ils se rattrapent dans la partie "faiblesse" (il est donc important de tout lire) même si encore une fois, il y a beaucoup de simplifications qui amènent parfois à quelques flous voire de véritables erreurs d'interprétations (par ex quand ils parlent des différents BUS de la SNES et notamment son BUS principal sur lequel ils rejettent toute la responsabilité des faibles performances de la machine).
Ils expliquent assez mal aussi le problème avec les sprites sur SNES (en disant simplement que l'utilisation de gros sprites tels que 32x32 ou 64x64 gachent de la VRAM sans bien expliquer pourquoi) alors que le vrai problème n'est pas vraiment là.. je pense qu'ils auraient du faire une comparaison avec les autres machines (PCE et MD) pour bien faire comprendre les forces et faiblesses de chaque machine sur cet aspect en particulier (mais pas seulement). Ils s'acharnent aussi pas mal sur le mode high res de la SNES et tentent d'expliquer pourquoi il n'a pas (ou si peu) été utilisé et là pareil, y'a de sacrées erreurs (quand ils parlent de l'affichage de sprites dans ce mode par exemple, clairement ils ont mal les specs ou ne les ont pas bien comprises) :-/

En fait je suis un peu partagé sur ce livre, par exemple j'ai été agréablement surpris par la description technique sur la partie sonore, ils expliquent pas mal de choses intéressantes sur le chip sonore de la SNES et là pour le coup ils sont plutot assez critique à son encontre (notamment à cause de la faible mémoire allouée à cette partie et les problèmes que ça pose). Ils vont assez loin dans les détails techniques mais encore une fois, je trouve qu'il y a beaucoup de flous et d'approximations. On sent qu'ils ne maitrisent pas tous ces éléments techniques (bon c'est normal aussi) mais du coup parfois ils se prennent un peu les pieds dans le tapis en expliquant certaines choses, c'est un peu dommage. Perso je ne me risquerai pas à essayer d'expliquer quelque chose que je ne maitrise pas (surtout quand ça a vocation à être publié dans un livre).

[TotOOntHeMooN]

C'est ce qui me dérange dans les ouvrages qui se disent parfois "bible" d'un machine.
Ils devaient totalement occulter la partie technique faute de maitriser le sujet.

[mysato]

Merci Stef, c'est sympa d'avoir ce genre de retour détaillé. Même si je ne peux rien dire pour l'instant sur ce que tu nous racontes, le fait même que tu parles de bus, de taille de sprite, d'ALU finit de me convaincre que c'est bien plus approfondi que ce que j'ai déjà lu en format papier.

C'est ce qui me dérange dans les ouvrages qui se disent parfois "bible" d'un machine.
Ils devaient totalement occulter la partie technique faute de maitriser le sujet.

Ouaip, sauf que là, par rapport à ce que dit Stef, au-delà de ce qu'il critique, ça semble largement plus fournis que dans tout ce que j'ai pu lire des éditeurs "les plus connus" qui justement bâclent la partie hardware en y écrivant d'énormes bêtises. Par exemple, le dernier qui est mal passé est l’anthologie neogeo c'était la catastrophe. Les seuls qui tiennent la route sur le hardware pour moi c'est coté gamer.

[Stef]

Hmm j'espère que tu en attends pas trop quand même sinon tu risques d'être déçu Ayant l'habitude de lire que des énormités qu'on pouvait lire dans les magazines de l'époque et des trucs qui ne vont jamais bien loin, là je trouve qu'ils ont quand même cherché à se renseigner (mais pas toujours où il faut hélas ^^) et à creuser certaines choses (en même temps c'est quand même un bouquin dédié au hardware de la SNES, c'est d'ailleurs la raison pour laquelle je l'ai acheté).

[TotOOntHeMooN]

Après, nous vivons une autre époque... Entre la bible de l'Amiga de Micro Application et celle de Pix'N Love... On a plus du tout le même lectorat ! 

[Stef]

Je suis un néophyte sur l'amiga mais tout ce que je peux dire c'est que j'ai un seul livre de Micro Application (Le meilleur - Programmation jeux 3D) et c'est une tuerie ^^ Je l'avais payé cher à l'époque (je me souviens j'étais au lycée) mais je pense que c'est le livre que j'ai le plus rentabilisé Aujourd'hui bien sur il est complètement dépassé mais je le garderai toute ma vie comme souvenir de cette bonne époque


Edit: Je me rend compte que j'ai aussi la bible PC de MA (truc de dingue aussi) du coup je me dis que leur bible Amiga ça devait être quelque chose

[TotOOntHeMooN]

Je me rend compte que j'ai aussi la bible PC de MA (truc de dingue aussi) du coup je me dis que leur bible Amiga ça devait être quelque chose

Oui, j'ai eu les deux et c'est très comparable en terme de contenu effectivement. 

[Lagi]

Hmm j'espère que tu en attends pas trop quand même sinon tu risques d'être déçu Ayant l'habitude de lire que des énormités qu'on pouvait lire dans les magazines de l'époque et des trucs qui ne vont jamais bien loin, là je trouve qu'ils ont quand même cherché à se renseigner (mais pas toujours où il faut hélas ^^) et à creuser certaines choses (en même temps c'est quand même un bouquin dédié au hardware de la SNES, c'est d'ailleurs la raison pour laquelle je l'ai acheté).

Salut Stef,

Je suis un des auteurs de la partie Hardware (Accessoires) et c'est mon collègue qui a écrit tout le reste de la partie Hardware. Un autre auteur s'est chargé de la partie Histoire.

Merci pour tes interventions et tes critiques constructives concernant l'ouvrage.

A la lecture de ton commentaire il y a quelques temps comme quoi tu achèterais l'ouvrage Hardware, nous avions hâte que tu le lises pour que nous ayons ton avis. Le tien, ainsi que les autres spécialistes qui fourmillent / ont fourmillé sur Gamopat. J'avoue, je suis un noob sur ce forum. J'ai toujours plus traîné sur Gamekult, mais il n'y a que les idiots qui ne changent pas d'avis, n'est-ce pas ? Pour dire vrai, nous ne sommes pas déçus de la pertinence de tes remarques mais nous nous y attendions. Et mon co-auteur savait que s'il y en avait un qui tiquerait à la lecture de l'ouvrage (cf divergence d'opinion avec Touko, réactualisée dans ce topic), ce serait bien toi. :-)

Pour notre défense, car il y en a bien une, malgré nos insistances de garder des passages du livre, il y a eu des coupes et l'intégration du 65c816 dans la SNES avait été beaucoup plus développée que ce qui est apparu sur le livre. On a voulu "parler" aux spécialistes mais l'éditeur a jugé des parties inutiles qui pourtant avaient tout leur sens au vu de l'argumentation qu'on essayait de développer. En les enlevant, on trouvait que le chapitre tombait à plat... Il y a eu des négociations, parfois musclées verbalement, pour garder l'intégralité de nos écrits. Malheureusement, les coupes ont eu lieu, la maquette et ses contraintes (nombre de pages, accessibilité aux lecteurs, cohérence de l'ensemble, ...) sont reines...

Idem, toute la partie sur le homebrew de la SNES qu'on avait faite est passée à la trappe. Quelles ont été ou quelles sont les intentions de l'éditeur ? Je n'en sais rien, mais on peut faire toutes les hypothèses qu'on veut.

P.65 : Là où tu ne vois que les photos des puces, on avait mis en plus l'emplacement en rouge de ces processeurs en fonction de leur intégration. Et on le dit bien sur cette page aussi : "Chacune de ces puces a un bus de données qui lui est propre sans avoir besoin de passer par le microprocesseur de la machine. C'est ce qui fait la force de la console mais aussi ses faiblesses. Une photo aussi a été virée : la version kingsize du 6502 où on peut voir en temps réel les tâches qu'il effectue.

Sur la double page suivante, un encadré était consacré à l'évolution du 68000 à travers les machines sur lesquelles il a été intégré par rapport au 6502. C'est sur la différence d'intégration des deux processeurs sur chaque console (68000 au format DIP sur Mega Drive, Atari ST, standard JAMMA, Amiga 1000, et les deux 68000 au format QFP sur parties Mega Drive et Mega-CD sur Multi-Mega, ainsi que le format QFP du 68000 sur Jaguar !)  que nous mettions l'accent et ça a été sabré et pourtant, ça aurait pu répondre en partie à ce que tu étais en droit d'attendre par rapport au comparatif que tu demandais avec d'autres machines... C'est quand même un ouvrage sur la SNES, donc déjà, on parlait du 68000 à travers ses machines, mais on comparait son intégration avec les machines équipées du 6502, modifié ou non pour elles (version modifiée pour l'Atari 2600, version de base pour l'APPLE II, base de 6502 pour la PC-Engine avec de nombreux ajustements dont la gestion du son au même titre que la NES, 2a03 qui est une version extrêmement modifiée du 6502 pour la NES et qui va donc jusqu'à intégrer la gestion du son, le 65c816 de la SNES est donc une version modifiée qui intègre des capacités supplémentaires par rapport au 6502 de base). Le but était vraiment de comparer les deux intégrations du 68000 et du 6502 dans les machines à travers le temps, photos pron électroniques à l'appui. D'ailleurs, rien qu'en le réécrivant, mes yeux saignent de leur absence...

Pour ce que tu qualifies d'erreurs d'interprétation de notre part, je ne vais pas me mouiller, n'étant pas l'auteur de cette partie. Mais je n'hésiterai pas à lui faire part de tes remarques pour qu'on prépare une réponse en bonne et due forme. A l'heure où j'écris ces lignes, il n'a pas encore reçu son ouvrage. Il va déjà en prendre connaissance pour voir les points positifs et négatifs de l'édition définitive. Ensuite, il épluchera ce qui a été modifié ou tronqué dans les propos... car c'est arrivé de temps à autre...

Bonne soirée à tous.

Au prochain post.

[TotOOntHeMooN]

Salut Lagi,

Merci pour ton post.

Je fais une petite parenthèse, compte tenu du fait que le message est adressé avant tout à Stef, pour indiquer que malheureusement l'aspect très technique sur les machines qui primait dans les ouvrages des années 80/90 a beaucoup disparu des ouvrages actuels par manque d'intérêt / compréhension du lectorat... De plus, des media comme wikipedia n'aident en rien, car ils sont truffés d'erreurs et j'imagine que Stef aprouvera le fait que je dise que ce n'est pas faute de vouloir participer pour ajuster le contenu... (une base de fans surveillant les moindres modifications qui pourraient porter préjudice concernant leurs machines de coeur, pour les invalider) Il reste donc difficile de trouver des informations pertinentes hormis sur des sites spécialités plus techniques. Je pense pourtant qu'il serait pertinant d'avoir ce genre de contenu "pages noires" en fin d'ouvrage, voir en lecture inversée pour débuter l'ouvrage dans l'autre sens ! 

Quand aux "homebrews / indé", il est important de parler ne serait-ce de ceux qui font dans la continuité avec un niveau de qualité comparable, sans distinction de genre, hormis la date de parution, afin de les noyer dans la masse et les accepter à juste titre et non de vouloir traiter à part quelque chose qui sera de ce fait refoulé par éditeurs et lecteurs.

A+

[Invité]

base de 6502 pour la PC-Engine 

Déjà, ça c'est pas tout à fait juste, c'est un 65C02 

le 65c816 de la SNES est donc une version modifiée qui intègre des capacités supplémentaires par rapport au 6502 de base)

Le 65816 est un CPU à part, qui bien que 100% compatible 6502, n'est pas un 6502 .

[TotOOntHeMooN]

Le 65816 est un CPU à part, qui bien que 100% compatible 6502, n'est pas un 6502 .

65816 ou 65C816 ?   (la différence étant le fait qu'ils soient produit en NMOS ou en CMOS nop ?)

[Invité]

65816 ou 65C816 ?  

Là c'est de la chipotagation 

Sinon je pense que pour avoir des infos fiables sur la snes, faut demander à kannagi ..

[Stef]

Salut Stef,

Je suis un des auteurs de la partie Hardware (Accessoires) et c'est mon collègue qui a écrit tout le reste de la partie Hardware. Un autre auteur s'est chargé de la partie Histoire.

Merci pour tes interventions et tes critiques constructives concernant l'ouvrage.

Salut Lagi,

Je trouve ça vraiment super que tu postes directement ici pour répondre à ma critique
C'est très transparent, surtout que j'ai essayé de vous contacter (les auteurs du livre) car j'avais de réelles interrogations (sur vos sources notamment) mais je n'ai pas réussi à trouver de bonnes informations sur qui à écrit quoi donc difficile de savoir à qui s'adresser :-/

Alors déjà ma critique est assez dure mais je l'ai faite comme je la pensais. J'ai essayé d'être honnête dans mon ressenti en lisant ce livre. Après tout le monde connait un peu mon avis sur l'hardware de la SNES malgré tout je ne suis pas sûr que ça rentre tellement en compte ici (bon peut être un petit peu ).

A la lecture de ton commentaire il y a quelques temps comme quoi tu achèterais l'ouvrage Hardware, nous avions hâte que tu le lises pour que nous ayons ton avis. Le tien, ainsi que les autres spécialistes qui fourmillent / ont fourmillé sur Gamopat. J'avoue, je suis un noob sur ce forum. J'ai toujours plus traîné sur Gamekult, mais il n'y a que les idiots qui ne changent pas d'avis, n'est-ce pas ? Pour dire vrai, nous ne sommes pas déçus de la pertinence de tes remarques mais nous nous y attendions. Et mon co-auteur savait que s'il y en avait un qui tiquerait à la lecture de l'ouvrage (cf divergence d'opinion avec Touko, réactualisée dans ce topic), ce serait bien toi. :-)

Pour notre défense, car il y en a bien une, malgré nos insistances de garder des passages du livre, il y a eu des coupes et l'intégration du 65c816 dans la SNES avait été beaucoup plus développée que ce qui est apparu sur le livre. On a voulu "parler" aux spécialistes mais l'éditeur a jugé des parties inutiles qui pourtant avaient tout leur sens au vu de l'argumentation qu'on essayait de développer. En les enlevant, on trouvait que le chapitre tombait à plat... Il y a eu des négociations, parfois musclées verbalement, pour garder l'intégralité de nos écrits. Malheureusement, les coupes ont eu lieu, la maquette et ses contraintes (nombre de pages, accessibilité aux lecteurs, cohérence de l'ensemble, ...) sont reines...

Alors oui c'est vrai que la partie sur le CPU m'a un peu laissé sur ma faim et vraiment par moment (mais il faudrait que je revienne sur les parties en question) j'ai vraiment cru lire des paroles de "fan" qu'on peut trouver sur NesDev par exemple. Je prends l'exemple sur le "vrai faux" côté 16 bits du 65816, clairement sur ce point je trouve qu'il y a beaucoup de chose à redire.. la réalité c'est qu'il n'existe pas une définition exacte de nombre de bit d'un CPU, c'est un tout... mais se contenter d'affirmer que le CPU est 16 bits car il a une ALU 16 bit (c'est quasiment ce qu'on lit en introduction et "en réponse aux détracteurs de ce CPU" dans le livre) ça fait vraiment un peu "parti pris". Donc affirmer ça, c'est un sacré raccourci et c'est même en fait faux (le Z80 a une ALU 4 bit, ce n'est pas un CPU 4 bit pour autant). Une définition plus logique (mais somme toute subjective quand même) serait que le CPU soit capable de traiter une information 16 bit aussi vite qu'une information 8 bit, comme c'est le cas pour un 8086 ou un 68000. Or le 65816 en est incapable, car son bus de donnée est 8 bits (et cela fait parti de son design interne, un bus 16 bit demanderait de lourdes modifications) et son architecture fait qu'il doit impérativement opérer avec une valeur en mémoire. De ce fait, le CPU traite plus lentement une opération 16 bit que 8 bit...

On peut aussi se contenter de la definition wikipedia (mais même là c'est un peu flou):
https://fr.wikipedia.org/wiki/Architecture_8_bits

Aussi, les processeurs 8 bits architecture ALU sont ceux qui sont fondés sur des registres, des bus d'adresse, ou des bus de données de cette taille. « 8 bits » est aussi un terme donné à une génération de calculateurs dans lesquels les processeurs 8 bits étaient la norme.

Au final on présente souvent ce CPU comme un hybride 8/16 bit... Enfin on ne va pas débattre là dessus des heures
Surtout qu'au final le nombre de bit on s'en fiche un peu, ce qui est important c'est de bien comprendre comment fonctionne le CPU.
Mais c'est clair que cet aspect un peu parti pris m'a gêné, moi ce que j'attends de ce genre de livre, c'est de l'information pointue et objective, même si je comprends qu'on veut aussi plaire aux fans :)

Après tu me dis qu'une bonne partie de la description du CPU a été coupé, je dois admettre que je trouve ça assez incompréhensible   C'est un livre qui est censé parlait du hardware de la machine et je dirais que plus il y en a, mieux c'est (en tout cas pour les lecteurs), est-ce pour des raisons de cout (trop de pages) ? car pour ce qui est de la cohérence, moi je trouvais que justement sur la partie CPU parfois ça en manquait un peu... par exemple quand vous expliquez que le CPU de la SNES est adapté à la machine (ok, c'est une puce customisée pour les besoins), qu'il traite plus d'instructions qu'un 68000 par seconde (ce qui est vrai aussi, mais vous omettez de dire, sur le moment en tout cas, qu'il faut plus d'instructions sur le 65816 que sur le 68000 pour faire la même chose)... bref, quand on lit ce passage on a l'impression qu'au final le CPU de la SNES est plus rapide et plus puissant que le 68000 pour la tâche qui lui incombe (ce qui est faux). Or plus tard vous vous contredisez là dessus... et du coup on a de mal à comprendre.

Idem, toute la partie sur le homebrew de la SNES qu'on avait faite est passée à la trappe. Quelles ont été ou quelles sont les intentions de l'éditeur ? Je n'en sais rien, mais on peut faire toutes les hypothèses qu'on veut.

Vraiment dommage, ça m'aurait intéressé mais j’imagine que ça ne faisait pas partie du livre "hardware" non ?

P.65 : Là où tu ne vois que les photos des puces, on avait mis en plus l'emplacement en rouge de ces processeurs en fonction de leur intégration. Et on le dit bien sur cette page aussi : "Chacune de ces puces a un bus de données qui lui est propre sans avoir besoin de passer par le microprocesseur de la machine. C'est ce qui fait la force de la console mais aussi ses faiblesses. Une photo aussi a été virée : la version kingsize du 6502 où on peut voir en temps réel les tâches qu'il effectue.

Sur la double page suivante, un encadré était consacré à l'évolution du 68000 à travers les machines sur lesquelles il a été intégré par rapport au 6502. C'est sur la différence d'intégration des deux processeurs sur chaque console (68000 au format DIP sur Mega Drive, Atari ST, standard JAMMA, Amiga 1000, et les deux 68000 au format QFP sur parties Mega Drive et Mega-CD sur Multi-Mega, ainsi que le format QFP du 68000 sur Jaguar !)  que nous mettions l'accent et ça a été sabré et pourtant, ça aurait pu répondre en partie à ce que tu étais en droit d'attendre par rapport au comparatif que tu demandais avec d'autres machines... C'est quand même un ouvrage sur la SNES, donc déjà, on parlait du 68000 à travers ses machines, mais on comparait son intégration avec les machines équipées du 6502, modifié ou non pour elles (version modifiée pour l'Atari 2600, version de base pour l'APPLE II, base de 6502 pour la PC-Engine avec de nombreux ajustements dont la gestion du son au même titre que la NES, 2a03 qui est une version extrêmement modifiée du 6502 pour la NES et qui va donc jusqu'à intégrer la gestion du son, le 65c816 de la SNES est donc une version modifiée qui intègre des capacités supplémentaires par rapport au 6502 de base). Le but était vraiment de comparer les deux intégrations du 68000 et du 6502 dans les machines à travers le temps, photos pron électroniques à l'appui. D'ailleurs, rien qu'en le réécrivant, mes yeux saignent de leur absence...

La partie sonore est complètement isolée, ensuite le(s) PPU(s) sont connectées au BUS central comme le 65816.
Ce qui me génait dans cette partie c'est que vous expliquez que toute la lenteur de la machine (du moins c'est comme ça que je l'ai compris) venait de ce bus 8 bit car c'est un goulot d'étranglement par lequel toutes les données doivent passer.
Mais en réalité, c'est pas vraiment ce BUS le problème, c'est le design global... Le CPU (le fameux 65816) fonctionne avec un BUS 8 bit, on ne peut pas lui greffer un bus 16 bit comme ça, soit on change le CPU ou soit on le modifie largement (à mon sens autant en refaire un de zero), et pareil pour le PPU, son inter connexion avec la VRAM ne lui permet pas de bénéficier d'un BUS 16 bits, ça n'aurait rien changé à ce niveau là... alors qu'en lisant on a l'impression qu'il suffisait de mettre un BUS 16 bit pour que tout roule, alors qu'en réalité pas vraiment. Il y a d'autres problèmes (il y a aussi cette OAM qui ne facilite pas le travail du CPU alors qu'il est déjà bien limite par exemple).

Sinon quand je parlais de la comparaison avec les autres machines, c'était juste pour mettre en exergue ses faiblesses, typiquement sur les sprites il y a *énormément* à dire. Quand on lit les specs "bruts" de la SNES on a l'impression qu'elle est largement supérieur à sa rivale (la MD donc) avec ses 128 sprites en 64x64 max (comparé au 80 en 32x32 max sur MD), pourtant dans les faits, la MD est la plus performante sur ce point. Le but n'est pas non plus de forcément rabaisser la SNES à tout prix, par exemple elle a un petit avantage sur les sprites que la MD ne possède pas (les sprites hors écran ne sont pas "consommés" dans le budget/ ligne contrairement à la MD, du coup sur cette dernière il est préférable de déplacer ces sprites hors limite "Y" pour optimiser le budget sprite / ligne et ca peut consommer un peu de temps CPU selon le type de jeu).

Pour ce que tu qualifies d'erreurs d'interprétation de notre part, je ne vais pas me mouiller, n'étant pas l'auteur de cette partie. Mais je n'hésiterai pas à lui faire part de tes remarques pour qu'on prépare une réponse en bonne et due forme. A l'heure où j'écris ces lignes, il n'a pas encore reçu son ouvrage. Il va déjà en prendre connaissance pour voir les points positifs et négatifs de l'édition définitive. Ensuite, il épluchera ce qui a été modifié ou tronqué dans les propos... car c'est arrivé de temps à autre...

Encore une fois j'ai été très critique parce-que j'aime avoir des informations assez complètes et précises. Mais il y a aussi beaucoup de très bonnes choses dans "votre" livre, j'ai été assez étonné par le nombre de pages que vous avez consacré à la partie sonore, et là pour le coup vous avez été assez loin dans les détails et vraiment j'ai beaucoup apprécié. C'est dommage qu'il y ait eu des coupes très certainement, je pense que ça aurait rendu le livre plus cohérent sur certains points. Mais bon soyons honnête, par rapport à tout ce qui existe dans le domaine, vous êtes largement au dessus du lot, c'est la première fois que je vois un livre qui rentre autant dans les détails hardware d'une machine (surtout la SNES qui n'est pas simple) et rien que pour ça bravo :)

[Invité]

Bon pour cette histoire de bus 8 bits sur SNES , je viens de tester  sur une vrai SNES , ça prend entre 15-20% de plus que les opérations 8 bits  , voilà et si on fait tout en 16 bits

Et ayant codé sur différente CPU (que ça soit le 68000 , le 6502 ou autre) , je me suis pas encore amusé à comparé le nombre d’instruction qu'il faut pour chaque truc mais il est vrai qu'il faut faire plus de gymnastique pour avoir un code rapide que sur le 68000.

Le souci de la SNES n'est pas le CPU (même si ça aurait était un plus si il était plus puissant ).
Effectivement avec tout ça , si on parle de codé en C , oui la console est vraiment pas faite pour parce que aucun compilo optimiserai au petit oignon le 65816 , alors que sur MD le 68000 s'accorde assez bien avec un langage haut niveau.

Le souci de la SNES c'est certain choix architecturaux qui plomb la console , pas son CPU (qui est suffisamment puissant pour faire un jeu 16 bits).

[Invité]

Bon je vais aussi décrire des faiblesse de la MD .
Le 68K est lent, ici dans un jeu sur un système 16 bits,tu passe principalement le temps CPU à :
* Gérer des variables surtout 8bits et 16 bits
* Faire des branchements
* Bcp d'appels de fonctions
* gestions d'interruptions .
Donc des taches qui sont assez lentes pour le 68k par rapport au 65816 et hu6280 .
L'avantage d'avoir des instructions simples est justement d'avoir plus de possibilités d'optimisations .
Exemple simple, un incrément de $100 sur un nombre  16 bits, avec les 65xxx, il suffit juste de faire
inc $ma_val_16_bit  + 1

1 instruction 5/6 cycles,et directement en mémoire .

Donc si on prend en compte les fréquences, oui un 68k a 7.67 mhz est plus rapide que le CPU de la snes a 2.58mhz, mais pas autant que ce que l'écart de fréquence pourrait laisser penser .
Le 68k a l'avantage de pouvoir gérer la mémoire de façon linéaire,et de permettre de coder en C plus facilement et efficacement.

Ensuite partie audio :
Le YAM de la MD est lent, donc le 68k perdrait bcp de cycles à le piloter pour la musique, et comme rien n'est mis en place côté yamaha pour pouvoir synchroniser l'envoie de samples dans le DAC, c'est quasi impossible de jouer des samples in-game avec le 68K.
Donc, c'est là que le Z80 trouve son utilité, cependant, lui aussi a les mêmes soucis que le 68k avec le yamaha, cependant étant donnée qu'il peut être affecté totalement au son ça soulage le 68K qui s'occupe entièrement de la logique du jeu,et pose moins de soucis avec le Z80 qui peut utiliser tout ses cycles à cette tache.
Ensuite, les problèmes, pour jouer des samples+piloter la partie FM/PSG, il faut intercaler le code du player de samples entre celui pour la partie FM/PSG, et donc compter les cycles, c'est fastidieux, imprécis et cause de la distorsion dans les samples, car il est impossible de synchroniser parfaitement l'envoie de samples dans le DAC.
Ensuite effectivement le Z80 peut accéder à la ROM pour charger des données, mais avec un système de banking très lent (il faut envoyer le numéro de la bank dans le mapper, bit/bit) et dispose de seulement 8ko pour faire rentrer le driver+la musiques+le(s) sample(s), .
Ensuite vient un autre soucis, c'est que pendant les transferts DMA, le bus est utilisé, donc le Z80 ne peut pas avoir accès aux données sur la ROM,il faut donc créer un buffer pour stocker les données des samples avant le vblank(dans les 8ko de ram), pour ne pas avoir à toucher au bus pendant les transferts DMA (soit pendant le vblank) .
Les driver de stef montre ce fait avec un décalage de 4 frames assez perceptible .
Le yamaha, n'a aucun réglage fin du panning, c'est soit droite/gauche/centre, ni de réglage précis du volume.

Ensuite oui le moteur de sprites hardware de la MD est meilleurs, mais montre ses limites du à la limite de taille des sprites dés que tu veux faire un pseudo background/gros boss en sprites .
Un exemple, faire le boss de shinobi mandara est impossible à faire en sprites sur Md car on boufferait 72 sprites rien que pour la partie des statues,et il resterait 8 sprites pour tout le reste .

Bien sur a ça on peut rajouter la limite des 4 palettes, qui est bien chiante, là ou la snes en a 16 et la PCE 32. .

Voilà c'est assez facile de trouver des défauts à une machine,car aucune n'est parfaite,chacune avec ses avantages,maintenant faire passer les défauts de la Md comme insignifiants, c'est juste de la mauvaise foi .

serait que le CPU soit capable de traiter une information 16 bit aussi vite qu'une information 8 bit, comme c'est le cas pour un 8086 ou un 68000. Or le 65816 en est incapable, car son bus de donnée est 8 bits (et cela fait parti de son design interne, un bus 16 bit 

C'est faux(vu comme tu le présentes),car ce n'est seulement valable pour les accès en RAM, et non pour les registres,seulement la pénalité n'est que d'un cycle par rapport à une instruction 8 bit,cependant si tu traites du 16 bits,c'est qu'en 8 bit tu aurais besoins de 2 instructions, donc 2x4 cycles (accès 8 bits) vs 1x5 cycles pour 1 accès 16 bits, lequel est le plus rapide ??,et donc en terme de cycles le 65816 est plus rapide en 16bits que le 68k .

Ensuite prenons les 68008 (un 68000 sur bus 8bits), quel sont les pénalités pour un accès 16 bits via son bus 8 bits ??
Bah juste x2 .

Le but n'est pas non plus de forcément rabaisser la SNES à tout prix

Peut être mais tu t'y emploies bien qd même .

[Stef]

Le 68K est lent, ici dans un jeu sur un système 16 bits,tu passe principalement le temps CPU à :
* Gérer des variables surtout 8bits et 16 bits

Non.. tu essais de faire ça quand tu as des contraintes de performance comme sur le 65816.. et encore, Kannagi reste en 16 bits car c'est quand même autrement plus pratique (et je pense que j'en ferai autant si je devais coder sur ce CPU car le système de switch entre 8/16 bit est terriblement bug prone). Les variables 8 bits, c'est bien pour la gestion des boolean, pour stocker des petites valeurs, pour tout les calculs qui prennent du temps (déplacements, collisions etc..) tu n'es *jamais* en 8 bits, au mieux en 16 bits (pour les collisions c'est suffisant) mais plus souvent sur du 24 ou 32 bits.

L'avantage d'avoir des instructions simples est justement d'avoir plus de possibilités d'optimisations .
Exemple simple, un incrément de $100 sur un nombre  16 bits, avec les 65xxx, il suffit juste de faire
inc $ma_val_16_bit  + 1

Faux, et là vraiment c'est débile de sortir ça... plus tu as d'instructions et de registres, et automatiquement plus tu as de possibilités d'optimisation. Ton exemple (simpliste disons le) s'applique au 68000 pour additionner $10000 sur une variable 24/32 bits... pour moi ce n'est même pas une optimisation, enfin passons.

Donc si on prend en compte les fréquences, oui un 68k a 7.67 mhz est plus rapide que le CPU de la snes a 2.58mhz, mais pas autant que ce que l'écart de fréquence pourrait laisser penser .

Bien sur que non car ces CPU ne fonctionnent pas du tout de la même manière (on l'a déjà beaucoup répété dans le topic VS), l'un accède à la mémoire à chaque cycle, et l'autre 1 cycle sur 4. En terme de fréquence externe le 68000 fonctionne à seulement 1.92 Mhz, mais son architecture est tellement plus avancée et efficace qu'il conserve largement l'avantage face à un 65816 à 2.58 Mhz (déjà de par son BUS 16 bit face au BUS 8 bit, mais pas que..).

Ensuite, les problèmes, pour jouer des samples+piloter la partie FM/PSG, il faut intercaler le code du player de samples entre celui pour la partie FM/PSG, et donc compter les cycles, c'est fastidieux, imprécis et cause de la distorsion dans les samples, car il est impossible de synchroniser parfaitement l'envoie de samples dans le DAC.

En utilisant le comptage de cycle, tu es plus performant mais tu n'es pas obligé de faire ça, tu as les timers du YM aussi, d'ailleurs c'est la voie que je choisirai pour mon prochain driver... ça va grandement simplifier mon code.

Les driver de stef montre ce fait avec un décalage de 4 frames assez perceptible .

Soit précis car là les gens vont penser que tout à 4 frames de retard dans mon driver c'est jute pour les SFX (et c'est plutot 3 frames en réalité) et parce-que j'ai utilisé un buffering particulièrement long (chose que je vais modifier dans mon prochain driver et que j'avais fait pour mon patch sur SF2 par ex).

Ensuite oui le moteur de sprites hardware de la MD est meilleurs, mais montre ses limites du à la limite de taille des sprites dés que tu veux faire un pseudo background/gros boss en sprites .
Un exemple, faire le boss de shinobi mandara est impossible à faire en sprites sur Md car on boufferait 72 sprites rien que pour la partie des statues,et il resterait 8 sprites pour tout le reste .

O_o ?? Non seulement avec les sprites tu recouvres l'intégralité de l'écran sans soucis (c'est la limite par ligne qui s'applique) mais en plus dans ce genre de cas (quasiment créer un plan avec des sprites) tu pourrais utiliser le multiplexage de sprites (qui n'est pas possible sur SNES) pour dépasser la limite des 80.

Voilà c'est assez facile de trouver des défauts à une machine,car aucune n'est parfaite,chacune avec ses avantages,maintenant faire passer les défauts de la Md comme insignifiants, c'est juste de la mauvaise foi .

Bien sur, on n'a jamais dit le contraire... mais là tu vois, tu t'es vraiment appliqué à essayer de déballer tout les défauts de la MD, en en rajoutant même un peu (confère mes commentaires plus haut).
Si je devais énumérer tout les défauts de la SNES je pense que 10 pages ne me suffiraient pas. J'exagère un peu mais vraiment la MD, si elle est loin d'être parfaite (ses 4 palettes étant de loin sa grosse faiblesse), elle est quand même autrement mieux fichue que la SNES

[polton]

pffffuuuuuiii
heureusement que vous n avez pas écrit le livre
j aurai lâché au bout de 2 pages

[Stef]

Bah le livre est censé parler hardware... du coup ta reflexion m'amène une question, sincère : qu'est ce que tu attends de ce genre de livre ? car je suis surement pas le lecteur type du coup...

[polton]

Bah le livre est censé parler hardware... du coup ta reflexion m'amène une question, sincère : qu'est ce que tu attends de ce genre de livre ? car je suis surement pas le lecteur type du coup...

une banalisation et des raccourcis me vont bien .
je ne pense pas que beaucoup soient pret a intégrer un tel niveau de détail.
dans le bouquin hardware il y a la partie " collection " qui est sympathique aussi.
mais je comprends tout à fait votre position.

[Stef]

C'est faux(vu comme tu le présentes),car ce n'est seulement valable pour les accès en RAM, et non pour les registres,seulement la pénalité n'est que d'un cycle par rapport à une instruction 8 bit,cependant si tu traites du 16 bits,c'est qu'en 8 bit tu aurais besoins de 2 instructions, donc 2x4 cycles (accès 8 bits) vs 1x5 cycles pour 1 accès 16 bits, lequel est le plus rapide ??,et donc en terme de cycles le 65816 est plus rapide en 16bits que le 68k .

Ensuite prenons les 68008 (un 68000 sur bus 8bits), quel sont les pénalités pour un accès 16 bits via son bus 8 bits ??
Bah juste x2 .

Je dis pas que le 65816 est un CPU 8 bit, je dis que c'est un hybride entre le 2. Effectivement il ne traite pas une opération 16 bit 2x plus lentement qu'une opération 8 bit (et heureusement ^^).
Ensuite le nombre de cycle, tu sais très bien qu'on en a rien à cirer... ce qui compte c'est l'efficacité du CPU avec l'architecture globale de la machine. La belle affaire d'avoir un CPU à 3 Mhz plus rapide qu'un autre à 8 Mhz si tu ne peux pas l'utiliser car la mémoire ne suit pas.
Le cas du 68008 et du 8088 c'est carrément différent, car justement ce sont des "vrais" CPU 16 bits à la base et donc pensé pour avoir un BUS 16 bit, quand tu leur colles un BUS 8 bit (pour des raisons de cout) le CPU est réellement castré. le 65816 est désigné pour fonctionner avec un BUS 8 bit...

[Stef]

une banalisation et des raccourcis me vont bien .
je ne pense pas que beaucoup soient pret a intégrer un tel niveau de détail.
dans le bouquin hardware il y a la partie " collection " qui est sympathique aussi.
mais je comprends tout à fait votre position.

Dans ce cas le livre devrait te plaire. Il y a quand même des parties bien techniques...

[Invité]

Technique sur SNES je met mes registre X,Y en 16 bits , et l'accu je le change en cours de toute suivant mes besoin (et j’évite les switch le plus possible).

Si je devais énumérer tout les défauts de la SNES je pense que 10 pages ne me suffiraient pas. J'exagère un peu mais vraiment la MD, si elle est loin d'être parfaite (ses 4 palettes étant de loin sa grosse faiblesse), elle est quand même autrement mieux fichue que la SNES

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

Je rajouterai notamment deux chose que la SNES a de plus que la MD
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 ^^)
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).

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

[Invité]

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) .