J'ai toujours été étonné de la série Super Mario sur les SNES. Je pense que c'était principalement fait dans l'assemblée Z80. Mais comme il n'y avait pas une horloge en temps réel, comment sur Terre a-t-elle géré tous ces événements chronométrés et animés avec l'assemblage et aucune horloge en temps réel?
merci
4 Réponses :
Le Z80 prend en charge un certain nombre d'interruptions matérielles - il est possible que l'un d'entre eux a été connecté à une minuterie périodique (par exemple, chaque 10 ms). Certaines consoles de jeux anticipés avaient des timing liés à l'actualisation de la numérisation de télévision. Cela peut donc avoir été connecté. Je ne connais pas les SNES, donc je spécule en fonction de la fonctionnalité des autres systèmes contemporains.
Wikipedia dit que le SNES était un système de 16 bits, ce n'était donc pas un Z80, ce qui est 8 bit. En fait, il dit que c'était un 65C816
http://en.wikipedia.org/wiki/super_nintendo_entertainment_system
(La liaison ci-dessus parle des interruptions de synchronisation vidéo, donc je suis probablement sur les bonnes lignes en supposant que vous êtes correct sur l'horloge en temps réel)
Une technique très courante utilisée sur l'ancien matériel était de s'appuyer sur le même matériel de synchronisation utilisé pour afficher des graphiques. L'ancienne matérielle diffuse littéralement des données de son port graphique (vidéo composite ou plus couramment RF) en lisant une valeur de pixel à partir de la mémoire et en la mettant sur le port, ainsi que des signaux «synchronisés», pour contrôler le pistolet à balayage dans la télévision.
Le bit Nice est que le signal de synchronisation verticale, celui qui rend la balançoire du pistolet à partir du bas de l'écran vers le haut, est généralement connecté à une interruption matérielle sur la CPU de la console et à ce moment-là, Ce qui arrive exactement 29,97 fois par seconde (près de 30fps) se produit à un moment où aucune donnée n'est envoyée sur la vidéo du tout, car elle prend un certain temps pour que le faisceau soit «voler» au sommet de l'écran. Les modifications apportées à la mémoire vidéo à ce moment-là seront sans scintiller!
Sur la plupart des systèmes plus anciens, il n'y avait pas de distinction entre champs même et impairs, de sorte que le taux de cadre vidéo était d'environ 60Hz. Il est également intéressant de noter que sur l'Atari 2600, le processeur était responsable de la génération du chronométrage vertical et des taux de châssis pouvaient ainsi être plus élevés ou inférieurs à 60Hz, dans la tolérance d'un téléviseur. L'une des chips (la "émeute") comprenait un compteur en bas avec un Prescalar, qui pourrait être défini avant d'exécuter un morceau de code qui prendrait une quantité de temps incertaine pour exécuter, mais il n'y avait pas d'interruption.
Un concept important à garder à l'esprit est le taux VSYNC. C'est la fréquence à la fréquence du pistolet à électrons dans le téléviseur (ou, l'équivalent dans les téléviseurs modernes), de dessiner l'écran et de parcourir lentement jusqu'au sommet de l'écran.
Parce que cela se produit à un taux constant (60 fois / seconde Dans NTSC, 50 in Pal), la plupart des jeux utilisent cela comme une minuterie, avec code qui est à peu près équivalent à ceci: évidemment, c'est grossièrement simplifié, mais c'est ce qui est continuer. Certains jeux étaient si complexes qu'ils ont pris trop de temps et manquaient la période VSYNC. Dans ce cas, ils attendaient le deuxième VSYNC et fonctionnent ainsi à 30 (/ 25) FPS. Parfois, vous remarquerez ralentir dans les jeux NES (par exemple). C'est à ce moment que la charge de travail est si lourde qu'il manque plusieurs périodes VSYNC dans une seule image d'action. mais oui, c'est l'essentiel de la façon dont la synchronisation a travaillé sur des consoles plus anciennes (en fait, même de nombreuses consoles et Les jeux PC utilisent le même système, pas seulement de vieilles consoles!)
Qu'est-ce que cela "moralement équivalent" que vous continuez à dire? Je ne pense pas que cela signifie ce que vous pensez que cela signifie.
Je l'utilisais de telle sorte que "X soit moralement équivalent à Y", à peu près, "X n'est pas la même chose que Y, et est probablement assez différent, mais sert un but similaire". En faisant des recherches, je me rends compte que je l'utilisais de manière incorrecte, alors je vais le modifier de ma réponse.
Jeux, puis comme maintenant, gérez généralement une boucle de pas de temps fixe (voir la réponse Mike Carons). À l'origine, c'était principalement pour la commodité; Votre rendu a été synchronisé sur la fréquence de rafraîchissement de l'écran de toute façon pour éviter de déchirer, peut-on aussi bien exécuter tout traitement à la fois par image.
De nos jours, la plupart des jeux qui avancent toujours dans des étapes discrètes qui sont multiples de certains tarifs de base, généralement à 50/60 Hz ou quelque chose comme 100 Hz - certains titres ont toujours un timing basé sur VSYNC, mais la plupart utilisent simplement des minuteries régulières pour cela. à présent. De nos jours, nous utilisons des horaires fixes pour des raisons légèrement différentes: premièrement, les jeux ont généralement au moins une certaine quantité de simulation physique, et il est très difficile d'obtenir une simulation physique avec des horodataires variables stables - en particulier dans des applications en temps réel telles que des jeux, où vous Je ne peux pas facilement jeter plus de puissance informatique en utilisant des méthodes d'intégration plus précises et similaires. Deuxièmement, si vous avez tout type en mode multijoueur en réseau, vous devez vous assurer que le jeu reste synchronisé pour tous les joueurs. Ceci est presque impossible à gérer (et à déboguer) si tout le monde est sur une minuterie différente et traite des événements à un tarif différent. Forcer tout le monde à utiliser un pas de temps commun fait le problème plusieurs ordres de grandeur plus faciles à gérer, car vous pouvez supposer en toute sécurité que deux joueurs qui commencent dans un état identique et que les entrées identiques seront toujours dans un état identique 5 secondes plus tard, même si Les joueurs regardent des choses différentes ou ont des machines différentes, qui influent tous le taux de trame réel que le jeu fonctionne à (et donc aussi le taux auquel le jeu peut traiter des événements).
Je ne sais pas ce que vous entendez par "horloge en temps réel", mais les consoles qui s'appuient sur le Z80 en tant que processeur à usage général avaient également du matériel dédié pour animation des sprites et de jouer des sons. Le Z80 ne faisait que nourrir les ordres à ceux-ci.
J'aimerais aussi savoir ça aussi! Je pensais toujours que c'était plus un "quand x est ici, y fait-il cette" chose un peu.
Les anciens jeux sont souvent synchronisés autour du taux de trame de l'écran, ils sont donc de sorte qu'ils mettent à jour leurs sprites une fois par image (I.e 50Hz ou 60Hz en fonction de si c'est un système PAL ou NTSC)
Super Mario sur les SNES: Super Mario World et Yoshi's Island. Aucun de ceux-ci n'est z80. C'était GB (c)
@Kawa - En effet, NES et SNES étaient basés sur des noyaux MOS 65xx personnalisés, le Ricoh 2A03 et 5A22 respectivement. BTW, quel est le gb (c)?
Voter à fermer aussi large.