| 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, The Chants, Kamiwaza Way of the Thief
Inscrit : Apr 01, 2003
Messages : 32842
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).
Code:
|
...
- On admettra que la mémoire est une suite de nombres codés en BINaire.
Nous savons maintenant que ces nombres peuvent ètres regrouppés en
OCTETS,MOTS,LONGS-MOTS.
- La programmation en assembleur permet de changer le contenu
de la mémoire.
La mémoire est changée quand l'ordinateur effectue une tàche (un calcul,
une recherche quelconque...).
La mémoire de l'ordi. peut aussi être changée par l'utilisateur
La conséquence en est un état prévu (programmé)
de la mémoire.
Ceci est possible en utilisant des instructions propres au langage uti-
lisé ou en modifiant directement une portion de la mémoire. Cette derni-
ère opération s'effectue très facilement en ASSembleur et avec une pré-
cision de l'ordre du BIT.
On peut donc Déplacer un OCTET,un MOT, un L-M (qu'on aura pu définir)
dans la mémoire (là où c'est possible...)
Pour se repérer dans la vaste mémoire de notre ordi. , on a découpé la
mémoire et on a nommé chaque portion de la mémoire par une ADRESSE (com-
me pour des Adresses dans une rue...)
Théoriquement, il serait possible de mettre un BIT,OCTET,MOT ou L-M à
n'importe quelle ADRESSE, mais en réalité ceci n'est pas possible.
- L'utilisateur n'a accès qu'à une partie de la mémoire.
(nous verrons laquelle)
- Il faut tenir compte de la parité et de l'imparité des ADRESSES:
On ne peut pas mettre n'importe quoi à n'importe quelle adresse.
EN EFFET: Si on SCHÉMATISE la structure de la mémoire, celle-ci ressemble
-------- à une bande de longueur limitée (début et fin) et d'une LAR-
GEUR de 16 BITS, dont les différentes parties sont numérotées
ADRESSÉES) tout les 8 BITS. (à chaque OCTET)
etc...
bits: 15 7 0
----- .| | |
x-2|--------|--------|
| x|10001011|--------| OCTET :10001011 à l'adresse x
| x+2|--------|10001101| OCTET :10001101 en x+3 octets
| x+4|--------|--------|
| x+6|00101100|10110011| MOT :0010110010110011
| .|--------|--------| en x+6 octets
|/ .|--------|--------|
' x+12|11011111|01110100| L-M :110111110111010001011011-
SENS des .|01011011|01110100| 01110100
adresses .|--------|--------| en x+12 octets
CROISSANTES .|--------|--------|
----------- x+20|--------|-------1| BIT :1 à l'adresse x+21 octets
| .|--------|--------|
| .|OCT FORT| FAIBLE |
|/ .|--------| ------ |
' 15 7 0
ETC...
+-------+
|MÉMOIRE| : ( Exemple d'organisation )
+-------+
- Observez bien cet exemple, il est très simple à comprendre et ce schéma
devra être dans votre tète à chaque fois que vous programmerez en ASM.
- Vous pouvez constater que:
* La mémoire est adressable au niveau de l'octet *
----------------------------------------------
* :Entre 2 adresses différentes X et X+1 ou X-1, il y a *
* 8 BITS ou un OCTET. *
bits n° 7 6 5 4 3 2 1 0
X-1 ---------->
[ ][ ][ ][ ][ ][ ][ ][ ]
X ---------->
[ ][ ][ ][ ][ ][ ][ ][ ]
X+1 ---------->
[ ][ ][ ][ ][ ][ ][ ][ ]
* La mémoire peut ètre représentée comme un PUITS dans lequel on
JETTE des données:BITS,OCTET,MOTS,L-M:
La largeur de ce puit est d'un MOT (soit 16 Bits)
La profondeur dépend de la taille de la mémoire.
Le but du jeu: Jetter nos données dans le puit sans déformer
les données.
c.à.d: Si vous y jettez un MOT: 1010101110110110 (=2 octets,1 de
poids fort (à droite) et un de poids faible (à gauche) ) à
une adresse x paire.
1010101110110110
|
|/
|--------|--------|
ADRESSES PAIRES |--------|--------| ADRESSES IMPAIRES
--------------- |--------|--------| -----------------
bit nr° 15 7 0
vous obtenez:
ADRESSES PAIRES x|10101011|10110110| ADRESSES IMPAIRES
---------------x+2|--------|--------| -----------------
|--------|--------|
bit nr° 15 7 0
- Le MOT a été posé à l'adresse x (PAIRE)
. L'Oct de poids FORT est à l'adresse x (PAIRE)
. L'Oct de poids FAIBLE à l'adresse x+1 (IMPAIRE)
par contre, si vous jetez ce mot à une adresse impaire:
10101011
10110110
|
|/
|--------|--------|
ADRESSES PAIRES |--------|--------| ADRESSES IMPAIRES
--------------- |--------|--------| -----------------
bit nr° 15 7 0
vous obtenez:
x-3|--------|--------|
ADRESSES PAIRES x-1|--------|10101011|x ADRESSES IMPAIRES
--------------- |10110110|--------|x+2 -----------------
|--------|--------|
bit nr° 15 7 0
- Le MOT a été posé à l'adresse x (IMPAIRE)
. L'Oct de poids FORT est à une adresse IMPAIRE :x
. L'Oct de poids FAIBLE à une adresse PAIRE :x+1
Dans ce cas, on ne respecte plus les règles de notre 'jeu'
Si on devait jeter un autre MOT à l'adresse x-3 dans notre
puits, son Oct FORT ne pourrait pas se maintenir et dégrin-
golerait en x-1!
!!!! ATTENTION, en réalité ceci ne se produirait pas, Je simplifie
seulement mon explication, j'illustre... !!!!
En fait, pour pouvoir déplacer (poser) des MOTS dans la mémoire, il
faut veiller à ce que l'adresse de destination soit PAIRE!
Pour notre exemple, il faut donc poser le MOT sous cette
forme dans la mémoire (dans notre 'puits')
+----------------+
|1010101110110110|
+----------------+
|
|/
|--------|--------|
ADRESSES PAIRES x|10101011|10110110|x+1 ADRESSES IMPAIRES
--------------- |--------|--------| -----------------
bit nr° 15 7 0
.L'Oct de poids FORT (10101011) est à l'adresse x
qui est PAIRE
.L'Oct de poids FAIBLE (10110110) est à l'adresse x+1
qui est IMPAIRE
* Il en est de mème lorsqu'il s'agit d'un L-M:
--------------------------------------------
Voilà comment poser un L-M, là aussi il faut que l'adresse de
destination soit PAIRE, pour éviter les mémes complications
que dans notre exemple précédent.
+-----------------+
|1110001001100100-|
|1010110011010001 |
+-----------------+
|
|/
|--------|--------|
ADRESSES PAIRES |--------|--------| ADRESSES IMPAIRES
--------------- |--------|--------| -----------------
x|11100010|01100100|x+1
x+2|10101100|11010001|x+3
|--------|--------|
bit nr° 15 7 0
.Le MOT de poids FORT (1110001001100100) est à
l'adresse x ,qui est PAIRE
.Le MOT de poids FAIBLE (1010110011010001) est à
l'adresse x+2 ,qui est PAIRE
* Pour un OCTET ou un BIT
-----------------------
- La parité n'a plus d'importance!
Ainsi, pour un Octet: on a:
--------------
01000110
|
|/
|--------|--------|
ADRESSES PAIRES x|01000110|--------|x+1 ADRESSES IMPAIRES
--------------- |--------|--------| -----------------
bit nr° 15 7 0
.L'Oct (01000110) est à une adresse x ,PAIRE
OU:
--
01000110
|
|/
|--------|--------|
ADRESSES PAIRES x-1|--------|01000110|x ADRESSES IMPAIRES
--------------- |--------|--------| -----------------
bit nr° 15 7 0
.L'Oct (01000110) est à une adresse x ,IMPAIRE
Pour un BIT: on a
------------
0
|
|/
|--------|--------|
ADRESSES PAIRES x|-------0|--------|x+1 ADRESSES IMPAIRES
--------------- |--------|--------| -----------------
bit nr° 15 7 0
.Le BIT (0) est à une adresse x ,PAIRE
OU:
---
0
|
|/
|--------|--------|
ADRESSES PAIRES x-1| -------|-------0|x ADRESSES IMPAIRES
--------------- |--------|--------| -----------------
bit nr° 15 7 0
.Le BIT (0) est à une adresse x ,IMPAIRE
*** RÉCAPITULATION ***
----------------------
* Un BIT peut ètre, soit à une adresse PAIRE, soit à une adresse IMPAIRE
--- ----- -------
* Un OCTET peut ètre, soit à une adresse PAIRE, soit une adresse IMPAIRE
----- ----- -------
* Un MOT est toujours situé à une adresse PAIRE en mémoire
--- -----
* Un L-M est toujours situé à une adresse PAIRE en mémoire
--- -----
( Le non respect de cette règle entraine un 'plantage' de l'ordi ! )
* STRUCTURE de la MÉMOIRE:
--------
etc...
bits: 15 7 0
----- .| | |
x-2|--------|--------|x-1
| x|00001011|--------| OCTET :00001011 à l'adresse x
| x+2|--------|10110010| OCTET :10110010 en x+3 octets
| x+4|--------|--------| (impaire)
| x+6|10001011|10110110| MOT :1000101110110110
| .|--------|--------| en x+6 octets (paire)
|/ .|--------|--------|
' x+12|01101100|00000000| L-M :011011000000000010111010-
SENS des .|10111010|01110111| 01110111
adresses .|--------|--------| en x+12 octets (paire)
CROISSANTES .|--------|--------|
----------- x+20|--------|-------1| BIT :1 à l'adresse x+21 octets
| .|--------|--------| (impaire)
| .|oct FORT| FAIBLE |
|/ .|--------| ------ |
' 15 7 0
| etc... |
Adresses PAIRES | | | Adresses IMPAIRES
--------------- -----------------
+-------+
|MÉMOIRE|
+-------+
Exemple d'organisation de la mémoire.
-------------------------------------
(Octets,Mots,L-M,Bits fictifs)
|
|
|
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
Le club des amoureux des vieux jeux vidéo
|
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, The Chants, Kamiwaza Way of the Thief
Inscrit : Apr 01, 2003
Messages : 32842
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 ...)
|
