Bienvenue sur le forum de Grospixels : [ S'Enregistrer ] Déjà inscrit ? [ Connexion ] |
|||
|
Index du Forum » » Micros et consoles » » Motorola 68000 |
Auteur | Motorola 68000 | |||
Gamerphil Gros pixel Inscrit : Aug 25, 2002 Messages : 1926 De : Nord Hors ligne | Posté le: 2006-08-16 14:53 Les contraintes fixes, c'est vrai qu'on les a encore sur consoles. D'ailleurs le meilleur exemple reste Shadow of the Colloseus sur Péhaisse deux, qui a sorti les tripes de cette machine. Il s'est même dit que la Péhaisse deux était "insuffisante" pour rendre ce jeu comme les développeurs le voulaient. Le seul souci est que l'on n'a pas vu exactement la même chose pour les autres machines de même génération que sont la X-Box ou la Gamecube. La vitrine de cette dernière est sans conteste Resident Evil 4, mais je me dis qu'elle n'a peut-être pas encore assez vécu pour avoir pu nous dévoiler le maximum de son potentiel (enfin, ce n'est que mon avis). Ce qui n'enlève rien à ce Resident Evil 4 qui est réellement magnifique.
Je suis par contre à peu près certain qu'aucun jeu n'a réussi à faire cracher les tripes de la X-Box, première du nom, et ça c'est assez regrettable. | |||
Tramboi Pixel de bonne taille Score au grosquiz
0003696
pts.
Joue à Wizardry 8 Inscrit : Nov 29, 2005 Messages : 360 De : Paris By Night Hors ligne | Posté le: 2006-08-16 15:48 Bien d'accord pour la XBox et la NGC qui n'ont pas tout livré, mais la faute à qui?
De par son image hardcore chez les codeurs ET chez les publishers et son marché énorme, la PS2 a sans doute bénéficié des efforts platform-spécifiques plus que les autres. Personne ne voulait investir autant de temps sur ces deux belles machines pourtant plus puissantes et plus simples à programmer, et puis il faut avouer que la contrepartie des libs et des docs indigentes de Sony, ce sont les docs hardware qui ont permis aux plus motivés de faire des chouettes trucs, quand même. Par contre, si ils refont le coup avec la PS3, pas sûr que ça passe... | |||
Gamerphil Gros pixel Inscrit : Aug 25, 2002 Messages : 1926 De : Nord Hors ligne | Posté le: 2006-08-16 16:25 Citation :
Le 2006-08-16 15:48, Tramboi a écrit: Bien d'accord pour la XBox et la NGC qui n'ont pas tout livré, mais la faute à qui? De par son image hardcore chez les codeurs ET chez les publishers et son marché énorme, la PS2 a sans doute bénéficié des efforts platform-spécifiques plus que les autres. Personne ne voulait investir autant de temps sur ces deux belles machines pourtant plus puissantes et plus simples à programmer, et puis il faut avouer que la contrepartie des libs et des docs indigentes de Sony, ce sont les docs hardware qui ont permis aux plus motivés de faire des chouettes trucs, quand même. Par contre, si ils refont le coup avec la PS3, pas sûr que ça passe... Très honnetement, je ne sais pas du tout ce qui va se passer en ce qui concerne les portages sur les next-gen. Etant donné que les architectures des deux machines sont radicalement différentes, les portages ne seront absolument pas facilités. Si la Péhaisse trois balaie tout le marché, comme l'ont fait ses prédécesseurs (ce qui est loin d'être aussi évident, au passage !), encore une fois, les jeux seront plus spécifiquement développés pour son architecture. Les portages sur les autres consoles seraient donc certainement bâclées, à mon avis, puisque ce ne sera pas rentable de tout refaire pour une version qui se vendra trois fois moins. Par contre, que se passerait-il si les trois consoles se partageaient équitablement le gateau ?! Le même genre de guerre qu'il y a eu pendant la période 16 bits ?! Ce serait assez chouette ça, bien que ça reste vachement utopique ! [ Ce Message a été édité par: Gamerphil le 2006-08-16 16:27 ] | |||
dante2002 Déterreur de topics Score au grosquiz
0002009
pts.
Joue à Le GamePass sur la Serie X Inscrit : Feb 10, 2003 Messages : 5365 De : METZ Hors ligne | Posté le: 2006-08-16 19:47 Citation :
Le 2006-08-16 14:53, Gamerphil a écrit: Les contraintes fixes, c'est vrai qu'on les a encore sur consoles. D'ailleurs le meilleur exemple reste Shadow of the Colloseus sur Péhaisse deux, qui a sorti les tripes de cette machine. Il s'est même dit que la Péhaisse deux était "insuffisante" pour rendre ce jeu comme les développeurs le voulaient. Le seul souci est que l'on n'a pas vu exactement la même chose pour les autres machines de même génération que sont la X-Box ou la Gamecube. La vitrine de cette dernière est sans conteste Resident Evil 4, mais je me dis qu'elle n'a peut-être pas encore assez vécu pour avoir pu nous dévoiler le maximum de son potentiel (enfin, ce n'est que mon avis). Ce qui n'enlève rien à ce Resident Evil 4 qui est réellement magnifique. Je suis par contre à peu près certain qu'aucun jeu n'a réussi à faire cracher les tripes de la X-Box, première du nom, et ça c'est assez regrettable. [ Ce Message a été édité par: Gamerphil le 2006-08-16 14:55 ] Si il y en a un, qui lui fait cracher littéralement ces trippes (je vous ai déjà dit que depuis que j'ai la xbox j'ai acheté une vingtaine de jeux, en 6 mois ) Ce jeu est aussi beau que de la next gen _________________ | |||
Thezis Pixel visible depuis la Lune Joue à Far Cry 3 Inscrit : Jul 19, 2002 Messages : 8910 De : Bruxelles Hors ligne | Posté le: 2006-08-16 23:13 Ce topic est un train de devenir un article à lui tout seul .
_________________ Dans la vie, il y a 3 catégorie des personnes : ceux qui savent compter et ceux qui ne savent pas compter. (Anonyme)
| |||
Lyle Camarade grospixelien Inscrit : Mar 12, 2002 Messages : 3722 Hors ligne | Posté le: 2006-09-12 22:50 Up pour en rajouter encore sur l'universalité du 68000. Sous MAME, j'ai été dans la rubrique CPU => 68000 pour voir le nombre de titres qui utilisent ce proc. Résultats : 2417 roms, soit presque la moitié du romset. Je pensais pas qu'il y en avait autant. Juste en dessous, il y a deux autres processeur, 68010 et 68020. Ont-ils un lien avec le 68000 ? (je crois qu'on peut aussi les sélectionner sous WinUAE).
Autre question, le 68000 était-il "modulable" comme le sont les processeurs de PC ? D'après system16.com, le 68000 du CPS est cadencé à 10Mhz, celui du CPS2 à 11,8Mhz. Je sais pas si la différence est significative pour les performances. Il est certain par contre que le CPS2 pouvaient animer sensiblement plus de choses que le CPS. Mais je sais pas si c'est le seul fait du proc. [edit] - Je viens de voir dans les pages précédentes que le 68000 de la MD est 7,6Mhz. Donc oui, c'est TRES modulable. Si quelqu'un veut bien improviser un petit cours sur comment fonctionne l'horloge d'un proc, je suis preneur. | |||
Kimuji Pixel monstrueux Joue à Pillars of Eternity Inscrit : Jul 04, 2005 Messages : 4372 Hors ligne | Posté le: 2006-09-13 01:23 Les 68010 et 68020 sont des proc motorola comme le 68000, ce sont des évolutions de celui-ci.
http://fr.wikipedia.org/wiki/68000 La fréquence d'un processeur exprimée en Hz représente le nombre de cycle par seconde qu'il est capable d'effectuer. Physiquement, si je dis pas de conneries, en gros c'est le nombre de fois par seconde que le processeur est traversé par un signal électrique. Donc plus la fréquence est élevée plus le nombre de cycle par seconde est important et par conséquent le nombre d'instructions traité. La fréquence n'est pas le seul facteur déterminant pour les performances, le nombre d'instructions que peut réaliser un proc en un seul cycle est aussi primordial. En shématisant à outrance (et en disant peut etre une grosse connerie) le rendement basique d'un proc se calcule en multipliant sa fréquence par le nombre d'opérations par cycle qu'il peut effectuer. Il n'y a rien de bien sorcier à changer la fréquence d'un proc, tout est question des propriétes du courant qui l'alimente, tu peux même faire tourner une architecture 68000 à 1Ghz si tu trouve un moyen de refroidir la bête pour éviter que les composants ne crament, ou bien à l'inverse le coller à 1 Mhz. Si les cartes mères le permettaient on pourrait même s'amuser à mettre un P4 à 7 Mhz pour voir si à fréquence égale le M68000 d'une MD tient la route Sinon pour la différence entre le CPS et le CPS 2, bien que je ne sois pas un pro de ces architectures, 1,8 Mhz c'est pas ca qui change radicalement la donne, à mon avis ca tient plus dans les coprocesseurs et la vitesse à laquelle les composants échangent les données entre eux que dans le proc central. Le proc central est loin d'etre le seul facteur déterminant en terme de performances d'un systeme de jeu vidéo. Par exemple un Pc avec un proc monstrueux et une carte graphique bas de gamme va donner de tres mauvais résultats. Pour les consoles c'est pareil, le proc central de la MD est largement plus performant que celui de la SFC (un M68000 à 7,6 Mhz vs un 65c816 à 3.6 Mhz), seulement les coprocesseurs graphiques et sonores font toute la différence. | |||
Z Pixel imposant Inscrit : Feb 18, 2006 Messages : 636 De : Courbevoie, 92 Hors ligne | Posté le: 2006-09-13 22:37 > Les 68010 et 68020 sont des proc motorola comme le 68000, > ce sont des évolutions de celui-ci. Le 68020 corrige une des (rares) limitations du 68000 à savoir l'incapacité d'écrire à des adresses impaires dans la mémoire, ce qui obligeait à décaler d'un octet certaines valeurs ou ligne de code (dans le cas de code auto modifié). > tu peux même faire tourner une architecture 68000 à 1Ghz si tu trouve un moyen > de refroidir la bête pour éviter que les composants ne crament, ou bien à l'inverse > le coller à 1 Mhz. Non. Ni l'un ni l'autre en fait. Pour des problèmes de synchronization interne, la fréquence d'un processeur ne peut pas être de n'importe quelle valeur. Changer le quartz externe (qui délivre la fréquence) par un 10 fois plus rapide fera planter le processeur. La plage de travail du 68000 se situe entre 6 Mhz et 20 Mhz. Les 68030 peuvent monter plus haut mais le 66 Mhz n'est pas envisageable (même dans un congélateur). Il existe des circuits (notamment les PIC) qui peuvent fonctionner sur une plage très large (de 32 Khz à plus de 20 Mhz). Les data sheets sont disponibles chez microchip.com. > le proc central de la MD est largement plus performant que celui de la SFC > (un M68000 à 7,6 Mhz vs un 65c816 à 3.6 Mhz), seulement les coprocesseurs > graphiques et sonores font toute la différence. Un peu comme pour l'amiga, la choix de ne pas aller jusqu'à 8Mhz sur la megadrive est lié à la volonté d'être synchro avec le signal vidéo (les ST, eux, vont jusqu'à 8 Mhz). Attention lors de la comparaison du 68000 à 8 Mhz et du 65c816 à 3,6 Mhz. Les proc sont si différents que les comparer en se basant sur leur fréquence ne veut pas dire grand chose. D'un côté, le choix du 65c816 s'explique par sa compatibilité native avec le 6502 (qui équipe la NES), de l'autre le choix du 68000 par Sega vient de son utilisation sur les cartes d'arcade du System 16 (Shinobi, Out Run, Space Harrier...). Alors, quelles sont les forces en présences ? Le 65c816 est un processeur 8/16/24 bit : - bus de données de 8 bit ! - registre de 16 bits (A, X, Y, SP, ...) - adressage sur 24 bit (16 Mo de ram d'adressable) - 1 seul niveau d'interruption Il effectue la plupart de ses opérations en 3 cycles (en moyenne). Il dispose de fonctions cablée pour déplacer de gros blocs mémoire. Il ne possède ni la multiplication ni la division ! Le 68000 est un processeur très puissant et moderne : - Registres sur 32 bits mais bus de données sur 16 bit (on parle de 16/32 bit) - Multiplication & Division cablée - Une moyenne de 8 cycles par instruction (jusqu'à 72 cycles pour la division !!!) - Mode superviseur, plusieurs niveau d'interruption... Si on part sur un nb d'instruction par sec, le 65c816 va donc 2 fois plus lentement (3,6 Mhz par rapport à 7,6), mais ses instructions demandent moins de cycle. Donc, globablement match nul sur le nombre d'instruction possibles. Comme celles du 68000 sont plus puissantes, le 68000 conserve l'avantage, mais de peu. Comme tu le soulignais, le gros du travail étant réalisé par les circuits graphiques, le facteur processeur n'était pas aussi déterminant que sur les ordi de l'époque, pour lesquels le processeur était le seul à tout faire. Il est fort probable que l'expérience du 68000 était déjà acquise chez la plupart des développeurs, et qu'ils ont eu moins de mal à tirer partie du 68000 que du 65c816. Olivier pour info, on retrouve le 65c816 dans l'Apple IIgs et dans la Lynx II (je crois). Sa fréquence maximale est de 20 Mhz (2.8 Mhz dans le IIgs). | |||
Thezis Pixel visible depuis la Lune Joue à Far Cry 3 Inscrit : Jul 19, 2002 Messages : 8910 De : Bruxelles Hors ligne | Posté le: 2006-09-13 23:21 Passionnants Z et Kimuji. Qui se dévoue pour faire un article de ce topic?
PS : Faut que j'ajoute à mes fiertés de joueur d'avoir créer ce topic (voler la gloire des autres? Nonon...) _________________ Dans la vie, il y a 3 catégorie des personnes : ceux qui savent compter et ceux qui ne savent pas compter. (Anonyme)
| |||
RainMakeR Chef de Rubrique Nécrologique Score au grosquiz
1035015
pts.
Joue à Exoprimal, Ghostwire Tokyo Inscrit : Apr 01, 2003 Messages : 32902 De : Toulouse Hors ligne | Posté le: 2006-09-13 23:26 comment ca il pouvait pas ecrire dans les adresses impaires ? ca veut dire qu'elles etaient perdues ?
_________________ | |||
NesLP Pixel de bonne taille Inscrit : Jan 18, 2005 Messages : 407 De : max-16-bits-land Hors ligne | Posté le: 2006-09-13 23:51 Citation :
Le 2006-09-13 23:26, RainMakeR a écrit: comment ca il pouvait pas ecrire dans les adresses impaires ? ca veut dire qu'elles etaient perdues ? HAHAHA ! Tu veux une explication hein ? T'es sur ??? HOHOHOHO fallait pas me chercher ! Copier/coller de mon cours de programmation 68K que je vendais par correspondance (il y a... houlà, trop d'années) : Les puristes sont priés de rester calme, j'avais 15 ans qd j'ai écris ça (et c'est un cours, donc forcément j'essaye de vulgariser, càd schématiser).
| |||
Thezis Pixel visible depuis la Lune Joue à Far Cry 3 Inscrit : Jul 19, 2002 Messages : 8910 De : Bruxelles Hors ligne | Posté le: 2006-09-14 00:10 Tu donnais des cours à 15 ans!? Ouah... Et que fais-tu comme métier maintenant?
_________________ Dans la vie, il y a 3 catégorie des personnes : ceux qui savent compter et ceux qui ne savent pas compter. (Anonyme)
| |||
NesLP Pixel de bonne taille Inscrit : Jan 18, 2005 Messages : 407 De : max-16-bits-land Hors ligne | Posté le: 2006-09-14 00:15 Citation :
Le 2006-09-14 00:10, Thezis a écrit: Tu donnais des cours à 15 ans!? Ouah... Et que fais-tu comme métier maintenant? Je vends des serveurs telco (un peu long et barbant à détailler), c'est mon 6 ou 7ème boulot dans l'informatique, j'ai commencé codeur C puis C++. Je code encore un peu, pour le fun, en java (comme un pied certainment, mais comme c'est plus un boulot pour moi). _________________ OldGamesClub.com | |||
Soreal Pixel monstrueux Score au grosquiz
0015129
pts.
Joue à The Darkest Dungeon (PC) Inscrit : Mar 06, 2002 Messages : 3229 De : l'Alti-ligérie ! Hors ligne | Posté le: 2006-09-14 02:08 Super intéressant ce topic, et ça fait plaisir de lire un gars comme Z, qui s'y connait beaucoup mais arrive à vulgariser toutes ses infos pour que chacun puisse comprendre, chapeau Monsieur, c'est rare pour être souligné. Vlà une sujet qui me cause en section rétro, merci GP!
_________________ www.cyrilauvity.fr | |||
Z Pixel imposant Inscrit : Feb 18, 2006 Messages : 636 De : Courbevoie, 92 Hors ligne | Posté le: 2006-09-14 08:57 > comment ca il pouvait pas ecrire dans les adresses impaires ?
> ca veut dire qu'elles etaient perdues ? Le 68000 peut écrire 3 sortes de données : - Les BYTE (8 bit) = 1 octet - Les WORD (16 bits) = 2 octets - Les DWORD (32 bits) = 4 octets Il peut écrire un BYTE n'importe où, mais s'il veut écrire un WORD ou un DWORD, il doit forcément les écrire à une adresse paire de la mémoire. Donc, à ce niveau deux possibilités : - Soit on décale les adresses pour que ca tombe toujours sur du paire (adresse d'une variable, d'une table...), notamment en ajoutant du padding (1 octet qui ne sert à rien en début de table mais qui fait que la table commence à une adresse paire). - Soit on utilise plusieurs fois l'instruction permettant de copier un BYTE (copier un WORD revient à recopier 2 BYTE). Pour une question de performance, il vaut mieux utiliser 1 instruction déplaçant 1 WORD plutot que 2 déplaçant un BYTE. Le 65c816 ne sait écrire que des BYTE ou des WORD (ses registres sont en 16 bits), mais il peut les écrire n'importe où, et la vitesse d'écriture dépend de la zone mémoire où il va écrire (dans Page 0, dans la pile, dans le même bank de 64 Ko, ou n'importe où dans les 16 Mo qu'il peut adresser). Cette différence de vitesse entre ces différentes instructions autorise l'optimisation du code de manière très importante. D'où de grosses différences entre quelqu'un qui maitrise le processeur et quelqu'un qui débute. Avec le temps, on arrive a trouver de plus en plus de moyen d'optimiser et d'accéler les traitements. Cela explique notamment l'améliorations des programmes sur ces environnement au cours des années de vie des machines ayant hébergées de tels processeurs. Savoir lire les specs d'un processeur (tables des instructions avec leur nombre de cycle respectifs) est déterminant pour obtenir le meilleur d'un processeur. cela ne s'applique évidemment qu'aux personnes programmant en assembleur. Olivier [ Ce Message a été édité par: Z le 2006-09-14 09:00 ] | |||
Lyle Camarade grospixelien Inscrit : Mar 12, 2002 Messages : 3722 Hors ligne | Posté le: 2006-09-14 11:54 Et bien, je voulais des précisions techniques, je suis servi.
| |||
RainMakeR Chef de Rubrique Nécrologique Score au grosquiz
1035015
pts.
Joue à Exoprimal, Ghostwire Tokyo Inscrit : Apr 01, 2003 Messages : 32902 De : Toulouse Hors ligne | Posté le: 2006-09-14 21:29 j'ai toujours pas compris. Si on peut ecrire un byte n'importe ou pourquoi c'est pas possible alors ?
_________________ | |||
Panda Gros pixel Score au grosquiz
0002250
pts.
Joue à C'est compliqué Inscrit : Jan 27, 2004 Messages : 1431 De : Paris Hors ligne | Posté le: 2006-09-14 22:58 Citation :
Il peut écrire un BYTE n'importe où, mais s'il veut écrire un WORD ou un DWORD, il doit forcément les écrire à une adresse paire de la mémoire. Sauf erreur de ma part, le x86 traine (trainait) une contrainte un peu similaire. Lors qu'on manipule un mot ou un double mot sur une adresse impaire, en interne, il n'y a pas un mais plusieurs accès pour récupérer l'information. Pour le programmeur, c'est transparent en terme de code, mais par contre, ça se payait en cycles supplémentaires. | |||
Z Pixel imposant Inscrit : Feb 18, 2006 Messages : 636 De : Courbevoie, 92 Hors ligne | Posté le: 2006-09-14 23:16 > j'ai toujours pas compris. Si on peut ecrire un byte n'importe ou pourquoi c'est pas possible alors ? Ok, je reprend. Pour déplacer des blocs de mémoire, le 68000 peut le faire soit en déplaçant 1 octet, 2 octets ou 4 octets à la fois. On dispose de 3 suffixes qui sont B (BYTE = 1 octet), W (WORD = 2 octets) ou L (LONG WORD = 4 octets) : MOVE.B : permet de déplacer 1 octet MOVE.W : permet de déplacer 2 octets d'un coup MOVE.L : permet de déplacer 4 octets d'un coup On pourrait faire une analogie avec un tas de sable qu'il faut charger dans une brouette pour l'ammener plus loin. Le 68000 dispose de 3 brouettes de taille différentes (B, W et L). Pour déplacer le tas de sable, tu feras plus de voyages avec une brouette de taille B qu'avec une brouette de taille L (4 fois plus grande). Les instructions MOVE.W et MOVE.L paraissent donc plus séduidantes que la MOVE.B si on doit déplacer des éléments faisant plus d'un octet de taille. Pour avoir un ordre d'idée, un octet, ca correspond à 1 point sur un écran affichant 256 couleurs (2 points en 16 couleurs). Donc, pour afficher un sprite de 32*32, il va en falloir des copies. Généralement, on préfère copier 4 octets par 4 octets que 1 octet par 1 octet. Là où le bas blaisse, c'est que le MOVE.W et le MOVE.L ne peuvent pas copier les données à des adresses impaires dans la mémoire. Il faut utiliser le pauvre MOVE.B si on veut absolument écrire à une adresse fixe qui est à une position impaire. Pour les sprites, ca donne quoi tout ça ? Imaginons pour simplifier qu'on soit en 256 couleurs à l'écran (VGA de base), chaque point de l'écran 'pèse' donc 1 octet. Si je veux bouger mon sprite de 1 cran vers la droite, je vais donc devoir écrire à une adresse A. Si je le bouge encore d'un cran vers la droite, je me retrouve en A+1. Donc forcément, A ou A+1 est impaire. Ce qui veut dire que pour un sprite devant se déplacer très finement sur l'écran (un curseur de souris), je ne pourrais pas toujours utiliser des MOVE.L, mais qu'il faudra jongler entre les MOVE.L et les MOVE.B (generalement les MOVE.L pour le milieu du sprite et les MOVE.B pour les extrémités). C'est pour cela, que les sprites sont généralement de taille multiple de 8 (4 octets en 16 couleurs = LONG WORD) et que leur déplacement se fait tous les 2 pixels et non tous les pixels, afin d'éviter de les écrites sur des adresses impaires. Ce genre de petits compromis permet de faire gagner un temps fou. Et les joueurs n'y voyent que du feu. Olivier | |||
NesLP Pixel de bonne taille Inscrit : Jan 18, 2005 Messages : 407 De : max-16-bits-land Hors ligne | Posté le: 2006-09-14 23:26 Citation :
Le 2006-09-14 21:29, RainMakeR a écrit: j'ai toujours pas compris. Si on peut ecrire un byte n'importe ou pourquoi c'est pas possible alors ? (EDIT : légère redite au début par rapport à Z, nos posts se sont croisés) Byte (octet) : oui, adresse paire ou impaire Word (2 octets) / Long Word (4 octets) : seulement adresse paire. Pourquoi ? Parce que lavabo (je pense, mais faudrait vérifier ) en tout cas, ça génère une exception et fait planter l'ordi (un ST en tout cas, erreur de BUS, les fameuses bombes sur l'écran...). On distingue en RAM : - L'espace "programme", qui contient les instructions des programmes codées en binaire après compilation. - L'espace données, qui contient des données "statiques" (pré-déclarées) du prg (la zone DATA) et les zones de la mémoire que vous réservez pour stocker des données "dynamiquement" (la zone BSS). Après, c'est pas pour autant qu'on peut mettre n'importe quoi n'importe où en mémoire. Voici pour exemple la structure la mémoire des ST. $0000000 : SP après un RESET $0000004 : PC après un RESET à $0000008 de $00003FF : Les VECTEURS d'EXCEPTION à $0000400 : Les VARIABLES SYSTEME à $00007FF de $001FFFF : La RAM à $007FFFF fin de la RAM pour les 520 ST à $00FFFFF fin de la RAM pour les 1040 ST à $01FFFFF fin de la RAM pour les MEGA 2 ST en $0FA0000 : début ROM de 128 Ko en $0FEFFFF : ROM de 192 Ko du système d'exploitation en $0FF8000 : Registres internes en $0FF8200 : Registres vidéo en $0FF8600 : Registres DMA et FCD (disque) en $0FF8800 : Registres AY3-8910 (sons) en $0FFFA00 : Registres MFP (Multi Fonction Peripheral) en $0FFFC00 : Registres des ACIA (Clavier et Midi) (à copier 100 fois et apprendre par coeur svp). Mais le plus intéressant après (ouais, parce que je soupçonne que vous avez pas tout lu juste avant là), c'est de s'attarder sur les MODES d'ADRESSAGE, càd les manières dont on peut accéder à des données en mémoire. C'est un peu comme les différents manières dont on pourrait expliquer à quelqu'un comment se rendre à une adresse précise (directement en donnant toutes les références, par rapport à un lieu x et expliquer à partir de ce lieu x, etc...). En 68K on peut citer : l'adressage numérique, symbolique, indirect simple, avec post-décrémentation, pré-décrémentation, indirect avec déplacement, avec index et déplacement, relatif au PC avec déplacement, relatif au PC avec index et déplacement, absolu long ou court... C'est d'ailleurs une des spéalité du 68000 d'avoir autant de modes d'adressages différents. Tous ne sont pas super utiles, et pour schématiser, un pro me corrigera ou complètera, les évolutions de ce proc lui ont fait perdre certains modes d'adressage de mémoire, histoire de gagner en efficacité quitte à ce qu'un programme en assembleur soit un peu plus "brut" et perde en expressivité. Bien choisir ses instructions, pour obtenir les meilleurs "perfs" dans son programme, c'était tout un art. Un programme "joliment codé" n'était pas forcément "rapide". Z a bien restanscrit ça dans son post d'avant. Je vous explique même pas quand il fallait faire des calculs de cycles d'horloge CPU de ses algorithmes pour les effets spéciaux de type overscan ou 512 couleurs simultanées à l'écran (qui nécessitaient de coder très "sioux" pour à la fois faire tourner son programme "vite" et en synchronisme avec des évènements comme le rafraîchissement de l'écran). Tout cela n'avait du sens et n'était possible que grâce à l'uniformité des machines et périphériques. Ensuite, on devrait aussi évoquer les registres de données (les "variables" à la assembleur pour super schématiser), avec aussi le PC (non, pas le parti), le SP (la fameuse pile système : rien à voir avec un truc qui se vide et qui polue l'environnement )... etc etc. Super vaaaaste sujet. Vaut mieux arrêter là et se diriger vers les bons sites/forums (http://www.atari-forum.com/viewforum.php?f=16 ...) |
Index du Forum » » Micros et consoles » » Motorola 68000 |
|
Forum www.grospixels.com (© 2011-2019 Grospixels)