Le 68000 et moi ...

[Invité]

Bonjour à tous,

Bon je ne vais pas me présenter pour la nième fois, vous me connaissez au travers des jeux que je partage avec vous.
Depuis quelque temps, je travaille sur le portage de Papi Commando sur Megadrive.
Pour cela j'utilise Bex, un puissant Basic - Assembleur.

J'ai pris gout à cette plateforme et aussi au "monstre" qui se cache derrière, le puissant 68000.
Je ne vais pas sortir les caractéristiques de la bête, ce n'est pas le but de ce post.

Je vais plutot vous faire partager mes bouts de code, mes essais, mes questions et mes problèmes afin de faire connaitre à chacun ce fabuleux mais obscur ( mais pas tant que ça ... ) Assembleur ( ou ASM ).

Pour se faire, j'utilise BEX qui permet de combiner du code Basic et du code Assembleur.
Par contre, il y a quelques limitations : les registres d'adresse de a3 à a7 sont reservés à BEX ... Ceci va amener ce premier exemple et une première erreur de l'émulateur : STACK UNDERRUN.

Code:

'=======================
 '= Petit TD de 68000   =
 '= Manipulation de     =
 '=   variables         =
 '=======================
 
 dim a as integer
 dim b as integer
 dim c as integer
 a=256
 b=256
 
 asm:
    move.w #$FFFF,d0
    move.w #$AAAA,d1
    move.w #$AAAA,a0
    bsr  @AJOUT
    move.w #0,d0
    move.w d1,$FF0050
@AJOUT:
       move.l #$FF00,d2
       add.l d2,d1
       rts
            
 end asm

Et oui, l'appel de la routine @Ajout renvoie à jongler avec deux modes : Utilisateur et Superviseur, afin de gérer le bon usage de la pile ( ou Stack en anglais ) en A7 ( et A7' pour le mode Superviseur ).
Or A7 est utilisé par BEX ... Donc exit l'usage des Subroutines.
D'ailleurs, sur ce sujet, si un "Pro" lit ce post, pourrait il me conseiller un programme avec Debugger, Interface, ..., bref le minimum pour bosser en ASM 68000 ?! Merci !

Bref, je peux quand même expliquer un peu le programme au dessus pour les curieux.
( Je rappelle que j'apprend aussi en même temps que vous ! )

En premier lieu, je déclare 3 variables de type Integer a,b et c.
Qui dit Integer dit une occupation sur 2 bytes pour chaque variable. Voici le Mappage des variables :



Voila qui est plus clair !

Voila qui donne un peu plus de simplicité pour le listing en ASM qui suit :

Code:

   move.w #$FFFF,d0      ; On stocke $FFFFF ( 65535 ) dans le registre de donnée d0, .w : word 16 bits
    move.w #$AAAA,d1      ; On stocke $AAAAA dans le registre de donnée d1
    move.w #$AAAA,a0      ; On stocke $AAAAA dans le registre d'adresse a0
    bsr  @AJOUT           ; Saut au sous programme @AJOUT
    move.w #0,d0          ; Après le saut, on stocke 0 dans d0 ( on perd l'ancienne valeur )
    move.w d1,$FF0050     ; On stocke le contenu de d1 dans $FF0050 ( variable c )
@AJOUT:
       move.l #$FF00,d2   ; On stocke $FF dans d2
       add.l d2,d1        ; On additionne d2 avec d1, le résultat reste stocké dans d1
       rts                ; Fin du sou programme AJOUT

Simple non ?!
Remarque, quand on veut attribuer une valeur sur un registre on met "#" avant ( #$FFFFF )
Si on laisse $xxxxx ( $FF0050 ), cela correspondra à une adresse.

Pour le moment, je n'ai appris que ces concepts de manipulation de registre.
On peut déjà faire pas mal de chose !
Dommage que BEX nous laisse que 4 registres d'adresse ( a0 - a3 )
Il y aussi des subtilités entre les registres d'adresse & données ( a0 - a7 et d0 - d7 )
On préférera les registres d'adresse pour sauvegarder des adresses, variables et les registres de données pour effectuer des opérations. Enfin, c'est mon ressenti en l'état ...

Voila un aperçu de ce que je vous propose au travers ce sujet.
Peut être, si j'y arrive, j'y mettrai mes premières routines pour Papi Commando qui sait ! ^^

A bientôt.

[Invité]

Bonsoir,

J'en appelle aux spécialistes car j'ai un petit problème sur le code suivant :

Code:

'=======================
 '= Petit TD de 68000   =
 '= Manipulation de     =
 '=   variables         =
 '=======================
 
 dim a as integer
 dim b as integer
 dim c as integer
 a=256
 b=256
 
 asm:
    move.w #$FFFFF,d0     ; On place 65535 dans d0
    move.w d0,(a0)    
    move.w (a0),$FF0050        
 end asm
 
 print "c:"+str$(c)
 



Bon, dans la première ligne, je stocke $FFFF sur d0.
La deuxième ligne, normalement, je dois stocker à la valeur d'adresse a0, le contenu de d0.
Dans la 3ème ligne, le contenu de l'adresse a0, je le transfère à l'adresse $$FF0050 ( soit C )

Et quand je vérifie le contenu de C, je me trouve avec une valeur autre que $FFFFF ( 65535 ), 14952 !
Y a donc un truc que je ne pige pas trop ... Si une personne peut m'expliquer, merci !!

[iwillbeback]

Par curiosité, pourrais-tu vérifié le contenu de a0 avant d'y déposer le contenu de d0 ?

[Invité]

Bien vu !

Move.w (a0),d0
Move d0,$ff0050

Me donne bien 14592 !
Donc il y a bien quelque chose au dedépart à cette adresse.
Reste donc à l'initialiser ... Mais je ne connais pas encore l'OP ... CLR a0 ? CLR (a0) ??

[iwillbeback]

Aucune idée.. va falloir chercher.
En tout cas, je viens de tomber sur les instructions PUSH et POP de gestion de la pile. c'est assez intéressant sur le principe.

Sinon, tu as bien fait d'initialiser a & b sur 2 bytes vue que tu leurs a donné la valeur de 256.
Sur 1 byte, ça ne serait pas passé..  car le 0 compte (0 -> 255).

[tfdi]

a0 pointe sur quoi, tu l'initialises nulle part !?....

Normalement, tu dois initialiser ton registre a0 pour qu'il "pointe" sur une zone mémoire.

Je ne connais pas BEX, mais en asm68k sous Atari, ca donnerai un truc dans ce genre :

Code:


move #$ffff,d0
lea var,a0
move d0,(a0)
move (a0),$ff0050

section bss
var ds.w 1




Je ne sais pas là ce que contient ton registre A0, mais si t'écris dans la zone mémoire pointée par A0 sans savoir "où" pointe ton A0, t'as de grande chance de finir en "Erreur de bus". Je ne sais pas si BEX l'initialise lui même, mais si ce n'est pas le cas, il peut pointer sur n'importe quelle zone mémoire, ce qui fini forcément par un plantage :)

Concernant ton petit programme, t'as pas besoin dans ton cas de passer par d0 ni par a0, tu peux directement faire un move #$ffff,$ff0050

Je parle de l'asm 68k en général, je ne connais pas du tout Bex, ni les adresses spécifiques de la MD 

[Invité]

Aahhhhhh Tfdi mon sauveur ...
LEA

L'opcode qu'il me manquait !!
Merciiiiiii !
Je ne savais pas comment initialiser le pointeur d'adresse, le tuto que je consulte ( un vieux cours de 68000 sur ST ) ne le spécifiait pas encore ...
Je comprend mieux la subtilité. Ça s'apparente au C et les pointeurs.
Merci encore !

[tfdi]

C'est ca, c'est comme le C et les pointeurs 

[Invité]

Bonsoir à tous,

Après quelques heures de pratiques diverses sur les registres, les pointeurs d'adresse ( merci encore à Tfdi ! ), j'ai attaqué la fameuse pile .. le Stack Pointer SP, le fameux a7 !!

Voici donc mon code source de la soirée dument commenté :

Code:

 '=======================
 '= Petit TD de 68000  =
 '= Manipulation de    =
 '=  variables        =
 '=======================
 
 ' L'emploi de la Pile, dépilage, mémorisation avec SP : Stack Pointer, le fameux registre a7 !
 
 dim a as integer
 dim b as integer
 dim c as integer
 
 a=83
 
 asm
  lea (__integer_c),a0      ; On attribue le pointeur d'adresse a0 avec c
  move.w #$2233,d1          ; On attribue $2233 à d1
  move.w d1,(a0)            ; On transfère le contenu de d1 au pointeur d'adresse a0, c'est à dire : C !!
  move.w (__integer_a),d0  ; On stocke a dans d0
  move.w d0,-(SP)          ; On ajoute d0 dans SP
  move.b #$FF,d0            ; On stocke FF dans d0, d0 perd donc son ancienne valeur.
  move.w d0,(__integer_b)  ; b prend la valeur de d0 : $FF soit 255
  move.w d0,(SP)+          ; Magiquuueeeeee !! On restitue la valeur d'origine de d0 en dépilant SP, soit d0 = 83 !
 end asm

 print a
 print b
 print c


Le code devient un peu plus complexe ( enfin pour moi ! ^^ ) et le listing plus long.
Avant de poster ce nouveau petit TD, j'ai pratiqué, essayé, pendant quelques heures avant d'arriver à ce résultat propre et démonstratif.
Le plus important, c'est de comprendre ce que j'ai fait, j'y vais vraiment piano piano !

Je garde toujours dans un coin de ma tête ce que je pourrai faire dans le cadre de mon projet Papi Commando ?! Je pense qu'il est trop tôt pour ça ... Il me manque encore trop de paramètres quant aux subtilités de l'ASM !
Mais ça devrait le faire !

A bientôt.

[Invité]

Avant de dodo, j'ai trouvé un super outil simulant l'environnement du 68000, avec compilateur, debugger, etc ...

Easy68K

C'est l'environnement rêvé pour apprendre et se faire la main avec le 68000 !!
BEX est bien, mais reste un environnement sous tutelle.
Avec Easy68K, on a l'oeil sur ses registres, on peut executer le code ne mode Pas/pas, etc ... Génial !

[tfdi]

Vetea:Ah ben voilà un truc bien propre et bien écrit ...

Je ne te conseille pas d'utiliser le pointeur de pile (sp) pour stocker des valeurs, ca sert déjà pour plein d'autres choses.

Stocker des valeurs sur le pointeur de pile, c'est bon pour l'asm sur PC, ou t'as pas beaucoup de registres de données, en asm68k, t'en as 8, c'est largement suffisant. Il vaut mieux stocker tes valeurs là dedans .

Pour info, au lieu de mettre move.w d0,-(sp), tu peux mettre directement move.w d0,-(a7). Ca ne change rien, si ce n'est que si un jour tu fais du reverse engineering en asm68k, tu verras A7, pas SP ...

En passant, merci pour le lien Easy68k, je connaissais pas, j'ai testé, y a un truc qui me plait vraiment, il indique le nombre de cycles pour chaque ligne de code, c'est tout simplement génial ... . Ca peut permettre de tester du code quand on a pas Steem (l'émulateur Atari)sous la main, extrêment simple à utiliser, très bon outils pour faire de l'asm68k sous Windows

Ca me servira .. merci

[drfloyd]

il faut quand meme s'accrocher pour apprendre l'assembleur je trouve. J'ai soir j'ai trouvé sur le web et suivi un cours pour archi débutants tres bien fait, c'est quand meme tres chaud.

Mais il est certain que c'est fantastique et pas forcement complexe dès qu'on maitrise.

les génies se sont ceux qui mettent au point ces langages en fait

[Invité]

Tfdi : merci !!
Ravi que ces outils te plaisent, ils sont géniaux !!
Par contre, il y a truc que j'ai pas compris, c'est BSR.
C'est un appel de sous routine, OK.
Mais en plein milieu d'un code, sous easy68k, en mode pas/pas, quand j'arrive à une ligne BSR RoutineX, je devrais aller à RoutineX et après RTS je devrais aller a la ligne suivante de BSR, hors non, le code se poursuit sans tenir compte de ce saut ... Normal ??

Doc : C'est pas si compliqué, mais c'est beaucoup moins souple que le basic ...

[tfdi]

Vetea:Fais une copie de ton code ici stp :)

[Invité]

Le voici :

Code:

  lea (__integer_c),a0      ; On attribue le pointeur d'adresse a0 avec c
  move.w #$2233,d1          ; On attribue $2233 à d1
  bsr Addition              ; Appel du Sub Addition : On aditionne d'1 bit d1
  move.w d1,(a0)            ; On transfère le contenu de d1 au pointeur d'adresse a0, c'est à dire : C !!
  move.w (__integer_a),d0  ; On stocke a dans d0
  move.w d0,-(SP)          ; On ajoute d0 dans SP
  move.b #$FF,d0            ; On stocke FF dans d0, d0 perd donc son ancienne valeur.
  move.w d0,(__integer_b)  ; b prend la valeur de d0 : $FF soit 255
  move.w d0,(SP)+          ; Magiquuueeeeee !! On restitue la valeur d'origine de d0 en dépilant SP, soit d0 = 83 !
 
Addition add.b #1,d1
        rts 

Donc, comme je le disais, à l'appel du sub Addition, le programme devrait se caler sur Addition et près rts, se reboucler à la suite : move.w d1,(a0)
Mais avec eay68k, non le code se poursuit sans tenir compte de l'appel Bsr ...

De plus, sous Bex, j'ai un message d'erreur avec l'émulateur : Stack Underrun ! Kezako ?! Un problème de pile ?!
Je sais que le 68000 lors d'un appel de ce genre, va stocker l'adresse pour pouvoir se reboucler après le rts.
Bref, c'est encore un peu flou pour moi !

[tfdi]

Chez moi ca fonctionne sans problème ... :)

Essaye ca:

Code:

 lea var_c,a0      ; On attribue le pointeur d'adresse a0 avec c
  move.w #$2233,d1          ; On attribue $2233 à d1
  bsr Addition              ; Appel du Sub Addition : On aditionne d'1 bit d1
  move.w d1,(a0)            ; On transfère le contenu de d1 au pointeur d'adresse a0, c'est à dire : C !!
  move.w var_a,d0  ; On stocke a dans d0
  move.w d0,-(SP)          ; On ajoute d0 dans SP
  move.b #$FF,d0            ; On stocke FF dans d0, d0 perd donc son ancienne valeur.
  move.w d0,var_b  ; b prend la valeur de d0 : $FF soit 255
  move.w d0,(SP)+          ; Magiquuueeeeee !! On restitue la valeur d'origine de d0 en dépilant SP, soit d0 = 83 !
  
Addition add.b #1,d1
        rts  

var_c dc.w 0
var_a dc.w 0
var_b dc.w 0


Par contre, que tu ais une erreur sous l'émulateur ne m'étonne pas plus que ca. Essaye cette modif:

Code:

lea (__integer_c),a0      ; On attribue le pointeur d'adresse a0 avec c
   move.w #$2233,d1          ; On attribue $2233 à d1
   bsr Addition              ; Appel du Sub Addition : On aditionne d'1 bit d1
   move.w d1,(a0)            ; On transfère le contenu de d1 au pointeur d'adresse a0, c'est à dire : C !!
   move.w (__integer_a),d0   ; On stocke a dans d0
   move.w d0,-(SP)           ; On ajoute d0 dans SP
   move.b #$FF,d0            ; On stocke FF dans d0, d0 perd donc son ancienne valeur.
   move.w d0,(__integer_b)   ; b prend la valeur de d0 : $FF soit 255
   move.w d0,(SP)+           ; Magiquuueeeeee !! On restitue la valeur d'origine de d0 en dépilant SP, soit d0 = 83 !
   jmp    fin

Addition add.b #1,d1
         rts 

fin

L'idée ici c'est qu'il n'execute pas ton Addition après le move.w d0,(a7)+ ... parce que là le RTS ca ne le fait pas du tout .... ^^

[Invité]

Merci beaucoup Tfdi !
Je potasse tout ca dès mon retour chez moi.
Ton aide est précieuse en tout cas.

[tfdi]

Normalement, en gros t'as un schéma comme ca :

Debut prog
...
Fin prog

func1
..
rts

func2
..
rts

var1 dc.w 0
var2 dc.w 0

buffer1 ds.w 200
buffer2 ds.l 100

Bon là sous BEX, je t'ai mis le jmp fin pour qu'il "saute" la partie des func1 ... RTS ... il y a sûrement autre chose à faire, mais comme je ne connais pas BEX, le plus simple c'est un petit jmp (un goto quoi .... )

[Invité]

Enfin de retour chez moi !
Bon j'ai essayé le code sous Bex, en effet, le jmp Fin fut bien judicieux !
Merci pour l'architecture du code aussi, j'ai toujours eu tendance à déclarer d'abord mes variables.

Après, j'ai une autre petite question, j'ai voulu testé l'OPcode trap #1 - 15, mais sous bex, il semble que ça pose problème. Sans doute l'hardware de la MD qui ne permet pas l'usage des routines en mode superviseur ... Sans compter que la MD à aussi ses spécificités et zones mémoires réservées !

C'est assez troublant d'apprendre le 68000 sur un tuto pour Atari ST en ayant en tête de l'utiliser pour une Megadrive.

Sinon, j'ai hâte d'utiliser les premiers branchements conditionnels, base de tout bon algorithme et routines.

[tfdi]

Les Trap #1, #13 et #14 que tu as sont spécifiques à l'Atari ST, il s'agit du Gemdos, Bios et Xbios. Ca ne fonctionnera pas sur la Megadrive.

Pareil pour la programmation des exceptions, HBL, VBL, Timers, Etc .. il faut la doc developpeur de la Megadrive, c'est là que ca risque de se compliquer un peu, il faut la trouver :s

[Invité]

J'ai trouvé d'excellents sites de référence sur la MD !
Sinon je vais faire une pause et laisser macerer tout ce que j'ai appris.
J'ai découvert et compris beaucoup de chose, mais de la à synthétiser mes idées en asm, j'ai encore beaucoup à faire !
Je vais reprendre un peu le fil du projet avec dans un coin de ma tête, mes travaux en 68000.

[Invité]

Tu commences à y prendre goût on dirait 

[Invité]

Tu commences à y prendre goût on dirait 

J'avoue ...

[Invité]

En tout cas n abandonnes pas,l investissement en vaut rėellement la chandelle 

[TJMK]

il faut quand meme s'accrocher pour apprendre l'assembleur je trouve. J'ai soir j'ai trouvé sur le web et suivi un cours pour archi débutants tres bien fait, c'est quand meme tres chaud.

Rien de complexe là dedans, juste une sorte de philosophie qui diffère de la programmation haut niveau à laquelle on est habitué de nos jours.

Ayant fait de l'assembleur x86, il y a des concepts assez abstrait à maitriser et à intégrer. C'est sûr faut passer par une étape très rébarbatif qui est la théorie , mais après ça roule !

Pour rebondir sur le sujet, il n'y a aucun kit développeur MD qui soit disponible de nos jours ? On sort et/ou trouve des kits de développement GC, DC à la vente sur des sites d'enchères, mais rien pour nos consoles 16 bits ?

Je trouve ça aberrent qu'il faille bricoler avec des kits de développement "homebrew" de nos jours. Ils font comment les mecs de WaterMelon ?

[Stef]

Tu parles de kit officiels ? tu peux en trouver aux enchères aussi mais la réalité c'est qu'ils sont souvent pas très utile car il faut l'hardware qui va avec... Les gars de WaterMelon ont leurs propres outils.
Moi même j'ai développé ma propre librairie pour développer sur MD : SGDK car lorsque j'ai commencé les outils dispos n'étaient vraiment pas terrible...

[TJMK]

Oui, je parle de kit officiel. Mais je parlais aussi du matériel spécifique qui le fait tourner. Donc apparemment c'est assez compliqué.

Et dans ton cas, comment as-tu développé ton kit ? Grâce à une doc technique officielle?

[Invité]

Oui, je parle de kit officiel. Mais je parlais aussi du matériel spécifique qui le fait tourner. Donc apparemment c'est assez compliqué.

Et dans ton cas, comment as-tu développé ton kit ? Grâce à une doc technique officielle?

Compliqué je pense pas (pas plus qu'une everdrive), c'est une histoire de sous .
Le mec qui va créer le matos va être obligé aussi de créer les outils qui vont avec, et surtout de les maintenir, tu vois un peu le boulot, et donc si il le vend, le prix en plus de toucher une minorité,risque de refroidir les autres .
Sur Md tu as UMDK par exemple qui existe :
http://gendev.spritesmind.net/forum/viewforum.php?f=20&sid=65e48f3f105ee9fdbefb5983d97bf098

Grâce à une doc technique officielle?

La doc officielle (SEGA) de la MD existe, tu as aussi un wiki technique dessus, je me rappelle plus de l'adresse.

[Ninja_SCX]

En tout cas chapeau pour t'être mis à l'assembleur 68000 !
Le jeu en vaut la chandelle.
Ce microprocesseur est vraiment génial une fois maîtrisé.
Ca fait 15 ans que je n'ai plus fait d'ASM 68000 (sur Amiga), mais tes lignes de code m'ont remémoré plein de souvenirs...

[Invité]

Ca fait 15 ans que je n'ai plus fait d'ASM 68000 (sur Amiga), mais tes lignes de code m'ont remémoré plein de souvenirs... 

Tu t'es mis toi aussi au C64 ??