Ouais. De mémoire j'étais aussi cycle-accurate sur mon ému Game Boy. Bref tout ce qui était 8 bits (et 16) les jeux essoraient tellement toutes les capacités des machines qu'il n'y avait pas moyen de vraiment s'en sortir sans être cycle-accurate et aussi supporter les "bugs" et autres bizarreries du chipset. C'était fun

On peut tout à fait coder un ému cycle accurate, la boucle principale va juste passer un delta (combien de cycles il s'est passé depuis le dernier appel), dans le cas non-optimisé c'est juste 1 (on appelle la boucle pour chaque cycle d'horloge principale), et appeler une fonction pour chaque composant, où on soustrait le delta au "temps avant le prochain événement" qu'il a calculé, et s'il est <= 0, on exécute l'événement (instruction CPU, DMA, chargement du buffer de sprites dans le VDP, génération d'un sample audio, etc.) puis on calcule quand sera le prochain. Comme chaque composant sait le nombre de cycles où il ne fait rien (qui n'ait un effet de bord sur le logiciel de jeu), on peut généralement brûler un certain nombre de cycles gratuitement, ou alors les passer dans une toute petite boucle qui n'exécute que le ou les processeurs principaux (qui eux n'ont jamais vraiment de pause).

C'est en gros une machine d'état où on s'occupe de chaque composant un à un à chaque cycle d'horloge maître, mais optimisée avec bon sens pour le chipset que tu émules.

Zerosquare (./22) :
Sur la console, tout est cadencé par une unique horloge à 26.6 MHz ; il y a juste le 68000 qui a un facteur de division de 2.

Puis de 4 en interne