Neo Geo AES+ : pourquoi les craintes autour du 68000 et de l’ASIC sont probablement exagérées

Depuis l’annonce de la Neo Geo AES+, le débat technique s’est emballé très vite. C’est presque inévitable : dès qu’un constructeur promet une réimplémentation matérielle fidèle, les mots ASIC, FPGA, cycle accuracy et compatibilité cartouche surgissent aussitôt. Une partie des critiques s’est cristallisée sur un point très précis, presque obsessionnel : la reproduction du Motorola 68000. L’idée sous-jacente est simple : si ce CPU n’est pas reproduit à l’identique, tout le reste s’écroule. C’est un raccourci séduisant, mais techniquement, il passe à côté de l’essentiel.

Le plus intéressant, dans cette affaire, n’est pas tant la peur elle-même que sa hiérarchie. Oui, un ASIC figé avec une erreur peut devenir un vrai problème. Oui, une communication marketing qui promet une fidélité “silicium” appelle forcément un examen sérieux. Mais non, le 68000 n’est probablement pas la zone la plus risquée du projet. Sur Neo Geo, le point sensible n’est pas le fait de faire tourner un CPU 68k compatible. Le point sensible, c’est de retrouver le comportement d’ensemble : le dialogue entre CPU, logique vidéo, VRAM, ROM cartouche, audio, interruptions, arbitrage de bus et timings de raster.

Autrement dit, la bonne grille de lecture n’est pas “SNK sait-elle refaire un 68000 ?”, mais plutôt “SNK sait-elle industrialiser une architecture Neo Geo cohérente sans casser ce qui fait la personnalité de la machine ?”. C’est là que le débat devient enfin utile, parce qu’on quitte la peur abstraite pour revenir à la vraie question d’ingénierie.

Le faux débat du Motorola 68000

Le Motorola 68000 est souvent décrit comme le cerveau de la Neo Geo. C’est vrai, mais il faut être précis sur ce que cela veut dire. Le 68000 exécute le programme principal, gère la logique de jeu, pilote les registres, synchronise les tâches critiques et orchestre les échanges avec le reste du système. En revanche, il ne fabrique ni la signature visuelle de la machine ni, à lui seul, sa sensation “arcade SNK”. Ce n’est pas parce qu’un composant est central qu’il est mystérieux, ni parce qu’il est important qu’il constitue la partie la plus difficile à reproduire.

La documentation officielle Motorola existe, elle est massive, détaillée et exploitable. Le manuel de référence de la famille M68000 décrit explicitement le modèle de programmation, les registres, le compteur ordinal, le registre d’état, les instructions et leurs différences au sein de la famille. On ne parle donc pas d’un composant documenté par fragments ou à travers quelques notes obscures de maintenance. On parle d’un CPU dont la spécification logicielle est connue depuis des décennies et qui a été disséqué à un niveau très fin par plusieurs générations de développeurs, d’émulateurs et de concepteurs de cores matériels.

Pourquoi le Motorola 68000 est l’un des CPU les mieux maîtrisés de l’histoire

Le 68000 bénéficie d’un cumul rare de facteurs favorables. Il a été très diffusé, il a vécu longtemps, il a servi dans des machines grand public et professionnelles, il a été étudié par des communautés très actives, et son ISA reste relativement lisible. La famille M68000 a aussi laissé derrière elle une énorme quantité d’outillage : assembleurs, débogueurs, désassembleurs, ROM tests, suites de compatibilité, traceurs d’instructions et cœurs de référence. C’est exactement le genre d’écosystème qui transforme un vieux CPU en “problème résolu”.

Le 68000 a en plus l’avantage d’être au croisement de plusieurs mondes. Il a vécu dans les consoles, dans les micro-ordinateurs et dans l’arcade. Cette diversité a une conséquence directe : les comportements bizarres, les cas limites et les écarts entre théorie et pratique ont eu le temps d’être rencontrés, corrigés, catalogués et revalidés. Lorsqu’un cœur 68000 échoue sur un vieux jeu, un benchmark synthétique, une routine de démo Atari ST, un loader Amiga ou un programme de diagnostic Mega Drive, la communauté le voit très vite. C’est l’inverse d’un coprocesseur rare dont les bugs dorment pendant des années faute de corpus suffisant.

On retrouve ce CPU dans des familles de machines qui ont chacune forcé sa compréhension à un niveau différent : Mega Drive côté console, Amiga, Atari ST et Macintosh côté micro, sans oublier une quantité considérable de cartes d’arcade basées 68k. Cette présence transversale compte énormément. Elle veut dire qu’on n’a pas seulement documenté le 68000 “en théorie” ; on l’a observé dans des environnements où il devait cohabiter avec des VDP, des custom chips, des DMA, des ROM bankées, des interruptions vidéo et des contraintes de temps réel bien réelles.

• Consoles : Mega Drive et Neo Geo ont largement exposé le 68k au grand public.
• Ordinateurs : Amiga, Atari ST et Macintosh ont poussé son usage logiciel très loin.
• Arcade : Capcom, Sega et SNK l’ont utilisé dans des environnements à timing strict.
• Documentation : la famille M68000 dispose d’un corpus technique inhabituellement riche.
• Validation : émulateurs, cœurs FPGA et outils de test ont multiplié les recoupements.

Un processeur déjà reproduit dans d’innombrables contextes

Il suffit de regarder l’état de l’émulation et des implémentations matérielles pour comprendre à quel point le 68000 est maîtrisé. Côté logiciel, des cœurs d’émulation existent depuis longtemps. Côté précision, plusieurs projets se sont explicitement fixé l’objectif d’une reproduction cycle exacte. Côté FPGA ou logique compatible, il existe aussi des implémentations bien connues qui ont été confrontées à des bibliothèques de jeux et de tests. Rien de tout cela ne prouve qu’une intégration Neo Geo est automatiquement parfaite, mais tout cela prouve qu’on ne repart pas d’un trou noir technique.

La nuance importante est là : reproduire un CPU n’est pas la même chose que reproduire une console. Un cœur 68000 fidèle existe déjà sous plusieurs formes. Ce qui sépare un “bon 68k” d’une “bonne Neo Geo”, c’est l’environnement matériel dans lequel ce cœur s’insère : latences, accès VRAM, signaux vidéo, arbitres de bus, interruptions et contraintes imposées par les puces SNK. Ce n’est donc pas la difficulté de refaire le 68000 qui doit inquiéter en premier, mais la manière dont on le connecte au reste.

Documentation, reverse engineering et émulation cycle accurate

Le 68000 a aussi un autre avantage décisif : il se prête très bien au reverse engineering comportemental. Même sans disposer des masques d’origine Motorola, on peut tester très précisément sa réponse à des suites d’instructions, ses drapeaux, ses exceptions, ses timings d’accès et son interaction avec le bus. C’est exactement ce qui a permis à des projets modernes d’aboutir à des implémentations très fines. La fidélité ne vient pas seulement des plans d’usine ; elle vient aussi de la validation empirique répétée.

À l’inverse, il existe des blocs rétro nettement plus pénibles à verrouiller complètement : DSP spécialisés, puces de compression ou de décryptage en cartouche, coprocesseurs additionnels, extensions très particulières ou logiques hybrides mêlant CPU, DMA et mapping exotique. C’est précisément pour cela que la reproduction du 68000 inspire finalement moins de crainte que certaines architectures à cartouches intelligentes ou que des sous-systèmes additionnels comme les processeurs auxiliaires de certaines cartouches SNES. Le 68000 n’est pas trivial ; il est surtout connu, borné et déjà très balisé.

La conclusion qui s’impose est assez nette : la reproduction du 68000 n’est plus le verrou principal depuis longtemps. Pas au sens où n’importe quel clone serait automatiquement parfait, mais au sens où le problème n’a plus rien d’expérimental. On sait le documenter, on sait le comparer, on sait l’implémenter, et on sait surtout le confronter à une montagne de logiciels historiques.

La Neo Geo n’est pas mythique grâce au 68000

La Neo Geo n’a jamais fasciné uniquement parce qu’elle embarquait un 68000. D’autres machines l’utilisaient déjà, parfois avec d’excellents résultats. Ce qui rend la Neo Geo immédiatement reconnaissable, c’est la façon dont l’architecture SNK transforme la mémoire cartouche en affichage. Sa personnalité tient à la densité de ses sprites, à la taille de ses assets, à la manière dont ses puces traitent les lignes vidéo et à la richesse brute de ses ROM graphiques. Le CPU orchestre ; il ne crée pas à lui seul ce rendu massif, très “borne d’arcade à domicile”.

C’est là que beaucoup de débats déraillent. On raisonne comme si remplacer un CPU transformait automatiquement la machine en autre chose. En réalité, sur une Neo Geo, l’identité du système vient du pipeline d’affichage, du découpage des données sur cartouche, des puces graphiques et des timings de rendu bien plus que d’une supposée magie interne du 68000. La Neo Geo n’est pas une machine “68000 d’abord”. C’est une machine SNK d’abord.

Même CPU, résultats radicalement différents

Comparer la Neo Geo à d’autres machines 68k est instructif justement parce que la comparaison montre ce que le CPU n’explique pas. La Mega Drive, par exemple, organise clairement son affichage autour de plans de scrolling, de tiles et de sprites via son VDP. La Neo Geo, elle, repose sur une logique beaucoup plus frontale : un fix layer et une gigantesque machinerie à sprites qui va chercher ses données directement dans des ROM graphiques dédiées. Même si les deux mondes peuvent partager un 68k, le rendu et les contraintes ne jouent pas dans la même catégorie.

On peut dire la même chose en comparant avec l’Amiga ou l’Atari ST. Ces machines ont elles aussi un 68000, mais leur architecture vidéo, leurs puces auxiliaires, leur rapport à la mémoire et leur philosophie logicielle n’ont rien de commun avec la Neo Geo. Le CPU est un socle commun. Le résultat visuel, la sensation de bande passante et la structure du rendu viennent du reste.

Le vrai cœur de la Neo Geo : le système graphique

Ce qui fait la signature visuelle de la Neo Geo, c’est sa capacité à pousser énormément de grands sprites avec une sensation de richesse immédiate. Sur cette machine, les sprites ne sont pas de simples petits objets mobiles superposés à un décor statique. Ils peuvent être assemblés pour former de vastes structures verticales et horizontales, ce qui permet des personnages immenses, des boss multi-segments, des véhicules imposants et des scènes extrêmement chargées.

Pipeline sprite : une machine pensée scanline par scanline

La logique de rendu Neo Geo est bien plus raffinée qu’on pourrait le croire. Le LSPC, au cœur du mécanisme vidéo sur les systèmes cartouche, travaille avec des buffers de ligne. L’idée générale est simple : pendant qu’une ligne est envoyée vers la sortie vidéo, la suivante est déjà en préparation. Cette alternance permanente permet de gérer un affichage riche sans bloquer la cadence. C’est un détail fondamental, parce qu’il explique pourquoi la fidélité des timings vidéo compte davantage que la seule compatibilité du CPU.

Le fonctionnement simplifié peut se résumer ainsi : la Neo Geo prépare les sprites utiles à une ligne donnée, remplit une liste active, puis rend cette ligne au moment opportun. Toute erreur dans cette séquence peut provoquer des artefacts subtils : mauvaise priorité, sprites manquants sur une ligne, clignotement ponctuel ou effet qui n’apparaît pas exactement au bon moment.

LSPC, scanlines et gestion des sprites

Le rôle du LSPC dépasse largement une simple conversion de données en pixels. Il participe à la sélection des sprites actifs, à leur traitement selon la ligne en cours, à la composition des couches visibles et à la sortie vidéo finale. C’est une logique profondément liée au rythme d’affichage. C’est aussi l’une des raisons pour lesquelles une Neo Geo ne se juge pas seulement sur sa capacité à démarrer un jeu, mais sur sa capacité à se comporter correctement à chaque instant, sur chaque scanline significative.

La machine doit en permanence arbitrer quels sprites méritent d’être dessinés, dans quel ordre, avec quelles priorités et dans quel budget de temps. Sur une scène légère, cela peut sembler trivial. Sur un Metal Slug ou un Blazing Star en plein chaos visuel, c’est tout l’inverse. C’est là que la différence entre une reproduction simplement “fonctionnelle” et une reproduction réellement convaincante se voit.

Bus cartouche séparés et ROM graphiques massives

L’architecture cartouche de la Neo Geo est capitale pour comprendre son rendu. Les données ne sont pas rassemblées dans un bloc uniforme. Le système sépare le programme principal, les samples audio, les données graphiques, le fix layer et le code sonore. Cette séparation change complètement la façon dont la machine exploite les cartouches. Le 68000 voit le programme et pilote l’ensemble, mais il ne lit pas les énormes banques graphiques comme une mémoire linéaire classique. La logique vidéo va y puiser directement ce dont elle a besoin.

C’est précisément ce découplage qui permet à la Neo Geo d’afficher des quantités massives de graphismes détaillés sans faire porter tout l’effort au CPU. Le 68000 commande. Le matériel spécialisé exécute la partie la plus lourde de la mise en image. Cette logique explique aussi pourquoi la machine garde une identité si distincte malgré l’usage d’un CPU partagé avec d’autres plateformes.

Pourquoi ce rendu reste-t-il unique ? Parce que la Neo Geo dépense sa bande passante là où le joueur la voit immédiatement : grands sprites, animations abondantes, cartouches énormes, données graphiques brutes et pipeline vidéo taillé pour l’arcade. Là où d’autres systèmes s’appuient davantage sur des plans de fond sophistiqués, des tricks de scrolling ou des compromis de mémoire, la Neo Geo assume une stratégie presque brutale : charger énormément d’assets et les pousser à l’écran avec régularité.

Pourquoi la Neo Geo ne ressemble ni à la SNES ni à la Mega Drive

La comparaison avec la Super Nintendo et la Mega Drive est éclairante, à condition de rester technique. La SNES mise largement sur des tilemaps, des modes d’affichage variés, des plans de fond complexes et une orchestration différente des effets. La Mega Drive, de son côté, s’appuie sur un VDP plus classique dans sa philosophie, avec des scroll planes bien identifiés et des sprites gérés selon une logique différente. La Neo Geo adopte une voie plus directe, plus coûteuse en données, mais redoutablement efficace pour produire un rendu “arcade premium”.

Le joueur le ressent intuitivement : sprites plus grands, animation plus généreuse, impression de richesse visuelle immédiate. L’ingénieur, lui, le lit dans l’architecture : ROMs dédiées, logique sprite omniprésente, pipeline scanline pensé pour des objets massifs, bande passante allouée à l’essentiel. Le mythe visuel Neo Geo ne vient pas d’un 68000 plus magique qu’un autre. Il vient d’une architecture SNK très cohérente avec son objectif.

Le vrai défi : les timings, pas le CPU

Dans une Neo Geo crédible, le vrai défi est moins l’instruction MOVE ou ADD que le moment exact où tout se passe. Quand le CPU peut-il écrire ? Quand la logique vidéo lit-elle la VRAM ? Quand les buffers basculent-ils ? Quand la logique audio voit-elle ses données ? Quand une cartouche répond-elle sur le bon bus ? Toute la machine vit sur des fenêtres d’accès très précises, avec des créneaux rapides et lents, des accès concurrents et un rythme imposé par l’affichage ligne par ligne.

Une erreur de timing peut produire des bugs que le grand public identifiera comme “graphiques” alors que leur cause est plus profonde. Un sprite peut clignoter, perdre sa priorité, afficher une mauvaise tuile pendant une seule ligne ou déclencher un effet avec un décalage minime. Un jeu peut sembler correct pendant des heures et échouer uniquement sur un boss, une transition ou une séquence saturée en objets animés.

Latence mémoire et synchronisation CPU / vidéo / audio

La latence mémoire est un point critique. Si la VRAM ou les accès cartouche répondent un peu trop tard, ou un peu trop tôt, tout le reste peut se décaler. Les systèmes rétro ne disposent pas de la souplesse et des couches d’abstraction des machines modernes. Ils reposent sur des comportements stables, souvent serrés, parfois très proches du matériel nu. Un écart léger peut suffire à altérer une animation, un effet sonore ou une priorité de rendu.

Le son n’échappe pas à cette logique. La Neo Geo s’appuie sur un Z80 pour la gestion sonore et sur le YM2610 pour la synthèse et les samples. Là encore, la fidélité ne tient pas seulement au fait d’avoir “un Z80 compatible” ou “une puce audio qui sonne presque pareil”. Elle tient à la façon dont le 68k, le Z80, les interruptions et les données audio se synchronisent sans casser le rythme du jeu ou les déclenchements sonores attendus au quart de tour.

Exemples concrets de problèmes possibles

• Latence mémoire : une réponse trop lente peut casser un affichage sensible sur une ligne précise.
• Arbitrage de bus : un accès CPU mal placé peut perturber la logique vidéo.
• Synchronisation audio : un léger décalage entre 68k et Z80 peut produire des effets sonores en retard.
• Accès cartouche : une réponse imparfaite des ROMs peut provoquer une lecture erronée de données.
• Interruptions : un mauvais calage peut dérégler des routines qui attendent un instant très précis.

C’est exactement pour cette raison que la question la plus sérieuse n’est pas “le CPU exécute-t-il les bonnes instructions ?” mais “la machine entière respire-t-elle au bon rythme ?”. Sur Neo Geo, la fidélité est autant une question de temps qu’une question de logique.

ASIC contre FPGA : un risque réel, mais à relativiser

Le débat ASIC vs FPGA mérite mieux qu’un réflexe de camp. Un FPGA a un avantage énorme : il se met à jour. Si un bug est découvert, le cœur peut évoluer. Pour un projet vivant, pour une scène de préservation ou pour une plateforme expérimentale, c’est un atout immense. Mais le raisonnement inverse — “ASIC donc forcément moins fidèle” — ne tient pas techniquement. Un ASIC n’est pas une version dégradée par nature ; c’est une forme d’industrialisation d’une logique donnée.

Ce qui compte, ce n’est pas le support final seul. Ce qui compte, c’est la maturité de la logique avant figement. Graver un design immature est dangereux. Graver un design déjà longuement vérifié, confronté à des jeux réels et nettoyé par itérations successives, c’est une tout autre histoire. Le FPGA est donc supérieur quand on explore, quand on corrige encore, quand on veut laisser une porte ouverte à l’ajustement. L’ASIC devient cohérent quand le comportement ciblé est déjà solidement verrouillé.

Différences réelles entre FPGA et ASIC

Sur le plan logique, les deux approches peuvent viser un même résultat fonctionnel. Sur le plan pratique, elles ne vivent pas de la même manière. Le FPGA implémente une logique configurable dans une structure programmable. L’ASIC, lui, implémente cette logique de manière dédiée. Cela change la façon dont on ajuste un design, dont on corrige un bug, dont on gère les marges temporelles et dont on maîtrise certains comportements physiques.

Sur la question du timing, un FPGA peut parfois demander plus de soin pour garantir que le design se comporte exactement comme prévu à grande échelle, selon la cible choisie. Un ASIC, une fois bien conçu, peut offrir une meilleure stabilité de production. Sur la question du comportement électrique, l’ASIC peut aussi être plus homogène, avec une consommation et un profil de signaux plus prévisibles. Rien de tout cela n’en fait automatiquement une solution supérieure. Cela montre simplement que le duel “ASIC mauvais / FPGA bon” est beaucoup trop simpliste.

Pourquoi ASIC n’est pas forcément moins fidèle

La fidélité n’est pas un argument moral ; c’est un résultat. Un ASIC bien conçu peut offrir une latence stable, une intégration propre, une production homogène et un comportement électrique plus constant à grande échelle. Pour un produit grand public, cela peut même être un avantage pratique. La question pertinente n’est pas “peut-on corriger après coup ?”, mais “combien a-t-on corrigé avant la gravure ?”. Si l’AES+ repose réellement sur une logique déjà très mûre, l’ASIC n’est plus une roulette russe ; c’est une étape de mise en production.

Dans quels cas le FPGA reste supérieur

Le FPGA garde un avantage évident pour tout ce qui touche aux edge cases : flashcarts atypiques, multicarts capricieuses, homebrews agressifs, tests de validation tardifs, variantes de comportement découvertes par la communauté. Sur ce terrain, la reconfigurabilité est reine. C’est pour cela qu’un FPGA reste l’outil idéal de recherche et qu’un ASIC peut devenir l’outil idéal de diffusion — à condition que le premier ait bien préparé le second.

Le rôle de Furrtek change fortement l’équation

Le nom de Furrtek compte parce qu’il ne renvoie pas à un simple discours d’opinion. Il renvoie à un travail de longue haleine sur la programmation Neo Geo, la cartographie mémoire, les rôles des ROMs, les interfaces entre sous-systèmes et, surtout, à une volonté explicite de transcrire le fonctionnement de la machine en définition logique. C’est un point capital, parce qu’il change entièrement la nature du risque.

On ne part pas de zéro. Même sans entrer dans les détails confidentiels d’un projet commercial, l’écosystème public autour de la Neo Geo est déjà bien plus mature que sur beaucoup d’autres machines. Reverse engineering, analyses de cartes, compréhension des bus, documentation des ROMs, études du rendu, expérimentation FPGA : tout cela existe déjà, publiquement, et réduit énormément le risque d’une reproduction “à l’aveugle”.

Reverse engineering et validation terrain

Le reverse engineering utile n’est pas une simple curiosité d’archiviste. C’est un travail qui permet de comparer des comportements réels, de valider des hypothèses, de reconstruire des chaînes logiques et de tester ces chaînes face à la réalité du matériel. Plus un design a été confronté à des cartouches originales, à des jeux connus pour poser des problèmes, à des timings sensibles et à des outils de développement, plus il gagne en maturité.

Quand une logique a déjà été confrontée à un vrai corpus de jeux, à des routines sensibles et à des utilisateurs pointilleux, elle n’a plus le même statut. Elle cesse d’être une hypothèse élégante pour devenir un design éprouvé. C’est pour cela que l’idée d’un passage FPGA vers ASIC n’a rien de choquant en soi. Ce qui serait inquiétant, ce serait une gravure précoce, sans base solide ni antécédents de validation. Le contexte Neo Geo actuel ne ressemble pas à ça.

Un core mûr, pas un prototype jetable

Il y a une différence énorme entre figer en ASIC un brouillon et industrialiser un cœur déjà longuement testé. Dans le premier cas, on grave des approximations. Dans le second, on transforme un savoir accumulé en produit fini. C’est précisément ce qui rend le débat actuel plus nuancé qu’il n’en a l’air : le support choisi compte, mais la maturité du design compte bien davantage.

Un catalogue limité, donc testable presque intégralement

Un point rassurant revient trop peu souvent : le catalogue Neo Geo est fini, relativement contenu, et donc vérifiable dans des conditions réalistes. On parle d’un ensemble d’environ 150 à 160 jeux officiels selon la manière de compter les variantes. C’est immense pour un joueur, mais c’est parfaitement abordable pour une campagne de validation sérieuse. Cela change complètement la nature du risque. On ne parle pas d’un écosystème infini, incontrôlable, avec des milliers de cartouches aux comportements imprévisibles.

Pourquoi cette validation par le catalogue est crédible

Encore faut-il tester intelligemment. La bonne méthode n’est pas de faire un simple lancement rapide sur chaque jeu ; il faut viser les séquences qui poussent réellement la machine. Les gros titres SNK ne sont pas seulement célèbres : ils servent aussi de stress tests naturels. Ils mobilisent massivement les sprites, le son, les transitions, la bande passante cartouche et les timings d’affichage.

• Metal Slug : explosions, sprites énormes, abondance d’objets et scènes saturées.
• Blazing Star : projectiles multiples, densité visuelle élevée, défilement exigeant.
• Pulstar : excellent révélateur de stabilité graphique et de cohérence temporelle.
• Garou: Mark of the Wolves : animation riche, gros assets et transitions sensibles.
• The Last Blade : effets visuels raffinés, rythme d’affichage à surveiller.
• KOF 98 / KOF 2002 : volume d’animation élevé et routines variées.
• Samurai Shodown II : grands personnages, effets d’impact et enchaînements rapides.

Le bénéfice d’un catalogue borné est simple : si les gros jeux critiques passent proprement, la confiance monte très vite. Ce n’est pas une garantie métaphysique, mais c’est une validation bien plus solide que sur des machines où le nombre de titres, de mappers ou de coprocesseurs rend l’exhaustivité quasi impossible.

Il faut aussi ajouter un point pratique : les futurs jeux développés officiellement pour l’écosystème AES+ ne seront pas conçus dans le vide. Ils seront testés sur AES originale et sur AES+. Cela tend naturellement à lisser les comportements ciblés et à réduire le risque de créations modernes qui dépendraient d’un cas matériel exotique sans intérêt réel pour la majorité des joueurs.

Les limites réelles à garder en tête

Dire que la peur du 68000 est exagérée ne revient pas à nier les zones de risque. Elles existent. Elles sont simplement ailleurs. La première, c’est la finesse des timings. La deuxième, c’est la compatibilité électrique avec des cartouches originales parfois fatiguées, des adaptateurs ou des périphériques atypiques. La troisième, c’est tout ce qui dépasse la cible principale : flashcarts, multicarts, conversions, homebrew agressif et autres usages qui testent les coins du système plutôt que son cœur officiel.

Flashcarts, multicarts et homebrew

Une multicart moderne ou une flashcart peut exploiter des comportements que la machine d’origine n’a jamais eu à encaisser dans le même cadre. Certaines cartes font du bankswitching d’une manière très spécifique, d’autres jouent avec des protections, d’autres encore exposent des habitudes d’écriture moins propres que les cartouches officielles. C’est précisément là qu’un FPGA garde une souplesse supérieure et qu’un ASIC peut se retrouver face à des cas non prioritaires pour le constructeur.

Le homebrew pose une autre question. Un développeur moderne peut chercher volontairement à pousser une architecture dans ses retranchements, parfois au-delà de ce que les jeux commerciaux de l’époque faisaient réellement. Ce n’est pas un problème en soi ; c’est même passionnant. Mais cela ne constitue pas forcément le bon critère principal pour juger une console pensée avant tout pour reproduire correctement le comportement historique du catalogue officiel.

Edge cases hardware et périmètre réel du produit

Il faut rester honnête sur le périmètre utilisateur. Le cœur de cible d’une AES+ n’est pas forcément le collectionneur qui branche trois convertisseurs exotiques, une cartouche borderline et un accessoire modifié de trente ans d’âge. Le cœur de cible, c’est d’abord la lecture fiable du catalogue officiel et des productions modernes conçues pour viser la compatibilité la plus large possible. Les edge cases comptent, mais ils ne définissent pas à eux seuls la réussite du projet.

En clair, une incompatibilité sur une multicart douteuse ou sur un accessoire marginal n’aurait pas le même poids qu’un problème sur Garou, Metal Slug ou KOF 98. Il faut juger la machine d’abord sur son terrain principal.

Pourquoi la peur du 68000 détourne du vrai sujet

Le problème du débat actuel, au fond, est surtout méthodologique. Il attire toute l’attention vers un composant dont la reproduction est déjà bien balisée, alors que la vraie difficulté d’une Neo Geo se situe dans son architecture globale. Une Neo Geo, ce n’est pas “un 68000 avec une sortie vidéo”. C’est un ensemble précis : 68k, Z80, YM2610, VRAM, LSPC, listes actives, bus cartouche séparés, ROMs spécialisées, palettes, fix layer, buffers de ligne et arbitrage temporel serré.

Autrement dit, la bonne question n’est pas “le 68000 est-il original ?”. La bonne question est “le comportement Neo Geo complet est-il là ?”. Si oui, alors l’AES+ peut être extrêmement convaincante même sans mythologie inutile autour du CPU. Si non, même un 68000 irréprochable ne suffira pas à sauver une reproduction trop approximative de la machine SNK.

Conclusion : la vraie question, c’est l’architecture SNK, pas le 68000

Les inquiétudes autour de la Neo Geo AES+ méritent d’être prises au sérieux, mais elles doivent être rangées dans le bon ordre. Non, la reproduction du Motorola 68000 n’est probablement pas le maillon le plus fragile. C’est l’un des CPU rétro les mieux documentés, les plus étudiés et les plus réimplémentés qui soient. Les outils existent, les cœurs existent, les méthodes de validation existent. Sur ce point précis, on est très loin d’un saut dans le vide.

Oui, le vrai enjeu est ailleurs : dans la fidélité du système graphique, des timings, des bus cartouche, de la logique de rendu scanline et de la synchronisation globale entre tous les blocs SNK. C’est là que se joue la crédibilité d’une AES+ matérielle. Mais c’est aussi là qu’il y a des raisons d’être moins alarmiste que certains discours le laissent entendre : la machine est bien étudiée, son catalogue est testable, et l’état public du reverse engineering Neo Geo montre une maturité qui n’a rien d’embryonnaire.

La formule la plus juste, aujourd’hui, est sans doute celle-ci : l’AES+ ressemble beaucoup plus à une industrialisation qu’à une expérimentation. Ce n’est pas une promesse de perfection absolue. C’est une façon plus saine de poser le débat. On peut surveiller les timings, les cartouches atypiques et les cas limites sans transformer le 68000 en faux épouvantail.

Au fond, la vraie question n’est donc pas : “SNK peut-elle reproduire un 68000 ?”

La vraie question est : “La Neo Geo AES+ reproduit-elle fidèlement l’architecture complète qui faisait la force de la machine originale ?”

Si la réponse est oui, alors l’AES+ pourra être lue pour ce qu’elle est probablement : une industrialisation d’un hardware Neo Geo déjà longuement compris, testé et validé, pas une expérimentation hasardeuse.

FAQ technique sur la Neo Geo AES+

La Neo Geo AES+ a-t-elle vraiment besoin des plans originaux du 68000 ?

Pas nécessairement. Pour obtenir un comportement compatible, on peut s’appuyer sur la documentation officielle, le reverse engineering comportemental, les suites de tests et les implémentations déjà existantes. Les masques d’origine seraient un atout historique, pas une condition indispensable pour retrouver un 68k fidèle.

Pourquoi dit-on que le 68000 n’est pas le vrai sujet ?

Parce que la Neo Geo tire sa personnalité de sa logique vidéo, de ses ROMs séparées, du LSPC et des timings. Le CPU principal orchestre le système, mais la “saveur” Neo Geo naît surtout du rendu sprite et du comportement global de la machine.

Un ASIC est-il forcément moins bon qu’un FPGA pour refaire une console rétro ?

Non. Un FPGA est meilleur pour corriger et itérer. Un ASIC peut être excellent si la logique a déjà été suffisamment validée avant gravure. Le support ne remplace pas la qualité du design.

Quels jeux seraient les meilleurs tests de compatibilité ?

Les jeux très chargés en sprites et en animation sont les plus révélateurs : Metal Slug, Blazing Star, Pulstar, Garou ou certains KOF. Ce sont eux qui exposent le plus vite un problème de priorité, de bande passante ou de timing vidéo.

Les flashcarts et multicarts sont-elles un bon indicateur de fidélité ?

Oui et non. Elles peuvent révéler des cas limites utiles, mais elles ne représentent pas toujours la cible principale d’un produit commercial. Une machine peut être excellente sur le catalogue officiel et plus discutable sur des cartes modernes très atypiques.

Que change concrètement le travail de reverse engineering déjà effectué autour de la Neo Geo ?

Il change le niveau de départ. Une grande partie de l’architecture Neo Geo a déjà été étudiée, décrite et transformée en base logique exploitable. Cela réduit fortement le risque de repartir d’une compréhension partielle ou approximative.

{« @context »: »https://schema.org », »@type »: »WebPage », »about »:{« @type »: »Thing », »name »: »Neo Geo AES+, ASIC, FPGA et architecture SNK »}, »keywords »:[« Neo Geo AES+ », »Motorola 68000″, »ASIC vs FPGA », »architecture SNK », »Neo Geo hardware »]}

{« @context »: »https://schema.org », »@type »: »Article », »headline »: »Neo Geo AES+ : pourquoi les craintes autour du 68000 et de l’ASIC sont probablement exagérées », »description »: »Analyse technique de la Neo Geo AES+ : 68000, ASIC, FPGA, LSPC, bus cartouche, timings et architecture SNK. Le vrai enjeu est la fidélité globale de la machine. », »keywords »:[« Neo Geo AES+ », »68000″, »ASIC », »FPGA », »architecture SNK »], »mainEntity »:{« @type »: »FAQPage », »mainEntity »:[{« @type »: »Question », »name »: »La Neo Geo AES+ a-t-elle vraiment besoin des plans originaux du 68000 ? », »acceptedAnswer »:{« @type »: »Answer », »text »: »Pas nécessairement. Une reproduction fidèle peut s’appuyer sur la documentation officielle, les suites de tests, le reverse engineering comportemental et des implémentations déjà éprouvées. »}},{« @type »: »Question », »name »: »Pourquoi dit-on que le 68000 n’est pas le vrai sujet ? », »acceptedAnswer »:{« @type »: »Answer », »text »: »Parce que la personnalité de la Neo Geo dépend surtout de sa logique vidéo, de ses ROMs séparées, du LSPC et des timings de l’architecture SNK. »}},{« @type »: »Question », »name »: »Un ASIC est-il forcément moins bon qu’un FPGA pour refaire une console rétro ? », »acceptedAnswer »:{« @type »: »Answer », »text »: »Non. Le FPGA est supérieur pour itérer et corriger, mais un ASIC peut être excellent si la logique a été suffisamment validée avant gravure. »}},{« @type »: »Question », »name »: »Quels jeux seraient les meilleurs tests de compatibilité ? », »acceptedAnswer »:{« @type »: »Answer », »text »: »Des jeux comme Metal Slug, Blazing Star, Pulstar, Garou ou certains KOF sont de très bons stress tests pour vérifier sprites, timings et comportement audiovisuel. »}},{« @type »: »Question », »name »: »Les flashcarts et multicarts sont-elles un bon indicateur de fidélité ? », »acceptedAnswer »:{« @type »: »Answer », »text »: »Elles peuvent révéler des cas limites utiles, mais elles ne définissent pas à elles seules la réussite d’un produit principalement destiné au catalogue officiel. »}},{« @type »: »Question », »name »: »Que change concrètement le travail de reverse engineering déjà effectué autour de la Neo Geo ? », »acceptedAnswer »:{« @type »: »Answer », »text »: »Il montre qu’une part importante de l’architecture Neo Geo a déjà été étudiée, décrite et transformée en base logique mûre pour une reproduction moderne. »}}]}}