Discussion :

[ShinobiX1]

Bonjour

J'ai désassemblé une rom de jeu master system qui utilise l'assembleur z80 , mon idée est de créer un jeu master system de SEGA fonctionnant sur émulateur en utilisant l'assembleur z80, et je ne comprends pas bien le résultat obtenu
mes connaissances en asm étant assez faibles

est-ce que vous pouvez m'aider un peu?

apparemment le listing se compose de quatre colonnes
la première doit être l'adresse en mémoire si j'ai bon
je ne sais pas pour la seconde colonne, et pour la troisième, ce sont les mnémoniques du jeu d'instruction, donc je comprends quelques unes
et la dernière colonne, je ne sais pas exactement , je devrais normalement trouver les registres et des donnés

je vous donne un échantillon pour explication

; Disassembly of the file "Ace of Aces (UE) [!]\Ace of Aces (UE) [!].sms"
;
; CPU Type: Z80
;
; Created with dZ80 2.0
;
; on Saturday, 11 of October 2014 at 10:49 AM
;
0000 f3 di
0001 2100c0 ld hl,0c000h
0004 7e ld a,(hl)
0005 e6e0 and 0e0h
0007 f608 or 08h
0009 d33e out (3eh),a
000b 3e0f ld a,0fh
000d d33f out (3fh),a
000f af xor a
0010 3205d6 ld (0d605h),a
0013 77 ld (hl),a
0014 2c inc l
0015 77 ld (hl),a
0016 2c inc l
0017 3601 ld (hl),01h
0019 2c inc l
001a 3602 ld (hl),02h
001c cdb202 call 02b2h
001f f3 di
0020 ed56 im 1
0022 31f0df ld sp,0dff0h
0025 2100c0 ld hl,0c000h
0028 1101c0 ld de,0c001h

si j'arrive à comprendre tout le listing, alors je serais paré pour faire des jeux en asm

[Kannagi]

Je pense que tu t'y prend mal pour faire des jeux master system , je programme sur SNES et pourtant il y a des ressource pour programmer en assembleur.

Tu ne comprendras pas le code sans connaitre l'architecture du système , l'assembleur te permettra de savoir ce que cela fait (calcul)mais pas de comprendre leur signification , a époque pas mal de registre matériel sont en mémoire , si tu ne les connais pas tu n'arrivera jamais vraiment a comprendre ce code (affichage / joypad , son ect) par exemple je viens de voir que le registre a adresse $DC permet de lire le joypad , tu ne l'aurais difficilement deviner en lisant un code désassembler...
Sur les anciennes console c'est toujours pareil , la logique du jeu se fait avec le processeur principal , les registre mémoire permet de piloter le hardware , il y a pas mal de doc sur le net http://www.smstributes.co.uk/view_pa...?articleid=207 et http://www.smstributes.co.uk/images/...ng/richard.txt qui permet de programmer sur master system en assembleur.
Il y a même la doc officiel sur le net (que je conseille toujours de lire ça reste la référence absolu).

[ShinobiX1]

Bonjour Kannagi
j'ai fait un peu de révision sur les registres du z80 donc maintenant je peux trouver les registres comme Af BC DE etc... dans le code
mais il est vrai que je ne sais pas comment on programme les joysticks, et les graphiques

Merci pour les liens, je vais lire ça et est-ce que tu peux me fournir des documents plus précis si tu en connais d'autres?

tu disais que tu programmes sur snes, quel est ton niveau maintenant?
comment as-tu réussis à comprendre la façon de programmer de cette machine?

je serais intéressé de programmer d'autres consoles mais ma connaissance est très faible pour le moment

il me faudrait un gros tutoriel qui explique tout ce que je dois savoir mais je n'en trouve pas , je continue mes recherches

[Kannagi]

Bah disons que connaitre bien le processeur cela facilite.
Au début programmé sur une ancienne console ça peut être déroutant pare que la logique est bien différente de celle qu'on fait de nos jours.
Par exemple il faut souvent regardé les bits pour lire des information , au début je suis passé sur pas mal information a coté parce que pour moi 1 octet = un paramètre , alors que il peut y avoir de 1 a 8 paramètre sur 1 octet.

Mon niveau sur la programmation en assembleur est suffisament bon pour que je fasse un shoot them up en 2 jours :

Je suis en train d'écrire un tutoriel pour la prog SNES pour devellopez.com , c'est en cours de vérification (et ça prend du temps).
Malheureusement tu ne trouvera pas de big tutoriel sur ce genre de console faut mettre les main dans les cambouis , perso je me suis passé sur la Doc Officiel + quelque hello world , et a partir de ça j'ai pu comprendre la machine , c'est pour cela que sur la partie jeux vidéo de developpez.com j'ai lancé un sondage pour ouvrir une section rétro-programming pour que ce savoir ne 'disparait' pas , enfait il disparaitra pas , mais disons que je comprend que passer quelque mois pour bien comprendre (et avec difficulté) la prog console , c'est pas joyeux donc si on pouvait partager nos connaissances ça serait plus facile de switcher sur la prog des différentes console.

Pour la master system tu devra cherché seul , je ne connais pas autre chose , les infos que je t'ai donné sont suffisantes (il y a plusieurs doc et assembleur WLA-DX pour compiler) mais un peu ardu pour celui qui commence.

Bonne chance.

[ShinobiX1]

oui je pense que nous devrions collecter le plus d'informations et de connaissance pour les partager avec la communauté Developpez
je vais me concentrer sur ton site et chercher d'autres documents , si j'arrive à faire un petit jeu, peut-être que j'écrirais un tuto pour ceux qui comme moi débutent dans la programmation

ton jeu est super , ça a du prendre pas mal de temps en deux jours
est-ce qu'il est possible de regarder le code source du jeu?

[Kannagi]

Oui ,bah pour le jeu j'ai pas mal rush a vrai dire , c'était pour évenement codé un jeu en 2 jours.
Sinon un simple programme qui affiche une image est suffisante pour partir la dessus est faire un petit jeu (vu que pour le joypad c'est en général pas bien compliqué , il suffit de lire dans la bonne adresse).

Je t'ai mis le code source de mon shmup

Sur le lien que je t'ai passé , j'ai vu qu'il y a un exemple de code pour un background : http://www.smstributes.co.uk/images/...nd%20Color.asm
Bref largement suffisant pour commencé est le code me semble assez simple.

[Obsidian]

Bonsoir,

je ne sais pas pour la seconde colonne

Ce sont les codes opérations qui correspondent à tes mnémoniques une fois compilés et tels qu'ils vont être interprétés par le processeur.

et la dernière colonne, je ne sais pas exactement , je devrais normalement trouver les registres et des donnés

D'une manière générale, les opérandes des opérations qui en nécessitent, effectivement.
Ensuite, ce sont les commentaires.

je vous donne un échantillon pour explication

C'est plus clair si on met les tabulations adéquates et des espaces entre les codeops :

0000 f3         di
0001 21 00 c0   ld     hl,0c000h
0004 7e         ld     a,(hl)
0005 e6 e0      and    0e0h
0007 f6 08      or     08h
0009 d3 3e      out    (3eh),a
000b 3e 0f      ld     a,0fh
000d d3 3f      out    (3fh),a
000f af         xor    a
0010 32 05 d6   ld     (0d605h),a
0013 77         ld     (hl),a
0014 2c         inc    l
0015 77         ld     (hl),a
0016 2c         inc    l

Par exemple, à l'adresse 0010, on voit que 32 est le code-opération de « LD (xxxx),A », et que « 05 D6 » est l'opérande, soit « D605 » en little endian. On voit également, à observer les adresses, que le programme est formé de ces codes, consécutivement et à l'exclusion de toute autre chose. Il est également intéressant de remarquer que des instructions comme les incrémentations « INC » sont implicites et ne nécessitent aucun opérande.

il me faudrait un gros tutoriel qui explique tout ce que je dois savoir mais je n'en trouve pas , je continue mes recherches

J'avais commencé à faire une petite génèse ici mais je ne sais pas si elle te sera utile :
http://www.developpez.net/forums/d14...r/#post7976453

Quoi qu'il en soit, il est vrai qu'il serait temps d'écrire un vrai tutoriel sur Développez.

Mon niveau sur la programmation en assembleur est suffisament bon pour que je fasse un shoot them up en 2 jours :

C'est remarquable !

En plus, les graphismes et les effets spéciaux sont tout-à-fait dans l'esprit de ce qui se faisait à l'époque.

[ShinobiX1]

@ Kannagi , merci pour le code source
@ Obsidian, je comprends maintenant our la colonne deux, je n'aurais pas deviné !
je regarde ton tuto , au cas où ça pourrait me servir.

j'ai pas mal de lacunes concernant la manière donc les choses fonctionnent avec l'assembleur et la console de jeu
par exemple, si c'était possible, je voudrais savoir comment on affiche le background et les sprites à l'écran, comment on gère le pad, faire les déplacements du personnages et des ennemies , le scrolling, le son bref... c'est beaucoup de choses auquels je dois chercher des documents

si je comprends un peu, la console voit l'écran comme une mosaïques de tuiles de 8x8 pixels qu'il loge dans une mémoire vidéo (vram)


j'ai lu qu'il faut écrire dans le "port" de cette mémoire video, je ne sais pas ce que c'est exactement un port dans le langage assembleur
en cherchant sur google, j'ai trouvé que c'est un nombre qui se rapporte à un périphérique donné mais physiquement c'est quoi ce nombre?

[Kannagi]

Je vais essayer de répondre a tes interrogation , Déjà il faut être un minimum a l'aise avec l'assembleur et le processeur , il faut savoir que le processeur ne fait rien de compliqué addition/soustraction , affectation registre/memoire/valeur immédiate , comparaison saut et quelque autre truc , bref rien de bien compliqué , il n' y a pas instruction qui fera l'affichage ou autre.

Donc les console de époque se base a peu prés tous sur la même logique , des registres en mémoire , qui permet d'afficher , faire du son ect.
Pour les background , la console les voit comme effectivement comme des tuiles 8x8 contrainte obligé , il serait impossible de faire une grosse map avec une grande image.
Il faut après juste lire les documents , et voir quel registre mémoire gère les sprites , la tu aura la possibilité de déplacé en X, Y , changer probablement la palette ect.
Pour le pad je te l'ai deja dit , il y a un registre en mémoire ou les bit sont activé si tel touche sont appuyé.

PORT $DC - Joypad port 1 (read only)
------------------------------------
(This port is also mirrored at $C0, as used by some games).
This is the first port providing input from the two joypads. Each bit
corresponds to a button: 0 for pressed, 1 for released (note that this appears
to be in contradiction to Marat's documentation):

bit 7: Joypad 2 Down
6: Joypad 2 Up
5: Joypad 1 Fire B
4: Joypad 1 Fire A
3: Joypad 1 Right
2: Joypad 1 Left
1: Joypad 1 Down
0: Joypad 1 Up

Donc faut lire cette adresse mémoire ensuite tu fait une comparaison bit a bit pour savoir quel touche est appuyé.

Pour la VRAM , les données des image (et peut être des tuiles) sont en VRAM , il faut trouvé la aussi le registre mémoire qui permet d'y écrire.
Et ça revient a ta question du port , pour le VDP j'imagine qui permet d'y écrire justement en VRAM , c'est un port pour envoyer les données en VRAM , vu que tu peux pas y accédé via le processeur principal (z80) et il y a un port pour envoyer dans le son aussi.
Donc pour écrire dans la VRAM il faut utilisé $BE - VDP data (read/write) et $BF - VDP address / status register (read/write) , en gros VDP address permet de choisir adresse du VDP et ensuite VDP data d'y écrire.

Pour les Sprites c'est différent de la SNES ,alors que la SNES possédait OAM qui permettait de gérè les sprites , la apparemment il faut juste écrire dans la VRAM dans une adresse statique donc si tu écrit sur une adresse en particulier tu modifiera la position X / Y de ton sprite.

Bref tout cela est écrit dans les doc que je t'ai passé , et la partie pratique t’aidera d'y voir plus clair.
Après je met en garde , si tu débute en programmation , ce n'est pas le plus judicieux de faire de la prog console qui était destiné a des professionnel tout de même.

@Obsidian
Merci , ce genre effet est très facile a faire sur d’ancienne console , on a accès a la palette du coup il faut juste changer la palette et faire une animation de palette pour ce genre effet , par contre de nos jours c'est ardu de faire cela par exemple si on utilise la carte graphique faudrait passer sur des shader et puis passer les paramètre de la palette bref assez lourd a codé , sinon la SDL permet de faire cela facilement , elle a un pointeur sur la palette de couleur.

[Obsidian]

j'ai lu qu'il faut écrire dans le "port" de cette mémoire video, je ne sais pas ce que c'est exactement un port dans le langage assembleur
en cherchant sur google, j'ai trouvé que c'est un nombre qui se rapporte à un périphérique donné mais physiquement c'est quoi ce nombre?

Plus généralement, un « port », en informatique, est l'endroit par lequel vont arriver ou repartir les données à destination d'un système tiers, et sont généralement spécialisés autant dans leur fonction que dans leur format. Ils peuvent être physiques, par exemple les ports série et parallèle de ton ordinateur. Si ceux-ci désignent l'interface entière, on a fini, par extension, par donner le même nom aux connecteurs eux-mêmes : le port joystick, le port réseau, etc.

En TCP/IP, le port (port 22, port 80, port 110, etc.) est un numéro associé à l'entête du paquet qui permet de savoir à quelle application il faut délivrer le paquet une fois qu'il est arrivé sur la machine. C'est pour cela que les 1024 premiers sont réservés et que bon nombre de services ont été normalisés depuis. Par exemple, on sait que le port 80 d'une machine reliée au public devra en principe être celui d'un serveur web.

En assembleur et en programmation bas-niveau, un port est généralement un « port d'entrée/sortie » (ou port I/O). Il s'agit du petite partie du plan mémoire qui sert à piloter le matériel. Pour comprendre, il faut se souvenir que vu de l'extérieur, un micro-processeur n'est qu'un circuit intégré, et que les broches de celui-ci ne correspondent, toutes considérations électroniques comme l'alimentation mises à part, qu'à trois choses : un bus d'adresse, un bus de donnée et quelques lignes de contrôle dont au moins R/W (« read or write »). Ça veut dire que logiciellement, ton micro-processeur ne sait faire que trois choses : lire une donnée quelque part en mémoire, appliquer dessus un éventuel traitement arithmétique ou logique (rudimentaire) et réécrire cette donnée ailleurs.

Le terme « bus » signifie que les lignes qui arrivent et repartent du micro-processeur sont distribuées simultanément, en parallèle, à tous les composants capables de dialoguer avec lui. Il est à la charge du composant en question de savoir si on lui parle ou pas, de répondre le cas échéant et de rester en haute impédance dans le cas contraire. Ça veut dire que sur ce bus, tu vas trouver fondamentalement trois choses :

• De la RAM ;
• De la ROM ;
• Les ports d'entrée/sortie des périphériques ;

Quand tu vas lire en RAM ou en ROM, la puce concernée va immédiatement accéder à l'un de ses petits casiers et renvoyer ce qu'elle a dedans. Lorsque tu vas écrire à une adresse consacrée à un périphérique, c'est le périphérique en question qui, électroniquement, va former une donnée qu'il va placer sur le bus. Ainsi, vu du logiciel, l'adresse n'aura aucune différence avec une autre position mémoire mais y lire ou écrire aura une conséquence sur le matériel : par exemple, écrire un octet à une adresse bien précise va faire allumer la LED du lecteur de disquette. De même, cette position ne correspond pas à de la mémoire mais directement au périphérique qui la gère. Ça veut dire qu'il n'est pas garanti que tu pourras relire ce que tu y a écrit, ni même que la donnée en lecture correspondent à la même chose qu'une donnée en écriture.

En général, donc, les ROM et RAM occupent 95% du plan mémoire et les ports d'entrée/sortie une toute petite portion (ne serait-ce que parce que c'est compliqué à gérer). En général, sur des machines huit bits, les périphériques se gèrent sur une plage de 1 à 3 octets par périph, rarement plus de huit. Même s'ils sont très compliqués.

Comme on l'a dit, les ports d'entrée/sortie se situent en général dans le même plan mémoire que la mémoire ordinaire mais plusieurs micro-processeurs — dont le Z80 et les déclinaisons du 8086 qui équipent tous les PC actuels — sont dotés d'instructions IN et OUT qui sont dédiés à cela. Le 6809, par contre, n'en a pas.

Il n'est pas évident de comprendre de prime abord à quoi peuvent servir ces instructions puisque ces données vont au final se retrouver sur le même bus, avec une broche supplémentaire pour indiquer s'il s'agit d'un accès normal ou un IN/OUT. Surtout que s'il y a une broche supplémentaire, elle pourrait avantageusement former un 17ème bit et doubler l'espace mémoire adressable. Côté logiciel, une instruction IN/OUT est au mieux équivalente à un LD, et parfois plus lente et nécessitant des registres dédiés (principalement sur x86).

Parmi les arguments en leur faveur, on peut imaginer ceux-ci : sur le plan physique, c'est un moyen simple d'exploiter cette 17ème broche si elle existe (certaines puces passent par un multiplexage compliqué), car faire des registres 17 bits et concevoir une architecture permettant de les charger serait, pour le coup, extrêmement difficile. Sur le plan logiciel, c'est un moyen simple d'éviter de faire un « trou » dans le plan mémoire. Ça permet non seulement d'utiliser à 100% les plages de mémoire disponibles mais également de garantir que les ports d'entrée/sortie ne seront jamais lus par accident par des instructions ordinaires (spécialement dans les boucles) ni même (surtout) exécutés, car on est sûr, pour le coup, qu'ils ne contiendront jamais d'instructions en langage machine. Ça permet également à l'électronique de sa machine de faire un distingo entre deux plages qui peuvent ne pas du tout avoir la même vitesse. Sur des architectures plus évoluées, ça permet de concilier le logiciel avec l'utilisation d'une MMU, en remappant par exemple l'adressage mémoire d'un processus tout en conservant intact le plan des ports d'entrée/sortie.