Programmation ASM sur Falcon - Page 1

Bonjour / bonsoir

Je viens enfin de configurer mon falcon pour que tout marche au mieux :
falcon030 (tos 4.02) + 14Mo + microdisk dur 2.5go + lecteur cd scsi + lecteur zip scsi + ..... DEVPAC 3.1

J'ai quelques notions d'asm 68k et j'aimerais bien faire un piti truc sur le volatile

J'en appelle aux programmeurs asm car je cherche un
sourcecode pour afficher une image (320x240x256) : une routine toute simple mais avec les inits nécessaires (interruptions, resolution)
sourcecode pour faire tourner un truc dans la vbl
quelques commentaires et explications seront les bienvenus.

D'avance, un grand merci et à bientôt

Ricco

Tu peux déjà commencer par regarder les sources de la bibliothèque des Reservoir Gods.
Il y peut-être des choses qui pourront te servir ici aussi.

Pour le reste :
!call GT Turbo
--- Call : GT Turbo appelé(e) sur ce topic ...

je vais y jeter un oeil avec attention

merci d'aider l'apprenti neewie que je suis

re

alors où j'en suis... pas très loin à vrai dire

premiere etape, j'ai essayé d'apprendre le fonctionnement de devpac 3 (ah oui, pour l'instant je travaille sur hatari... heureusement )

deuxieme étape, je prends des routines que j'ai faites sur amiga et là... aïe la cata.
il me fallait revoir la syntaxe sous devpac (trashm'one me manque... pas taper moi)
j'ai tapé des petites bricoles et j'ai assemblé
youpiiiii
run
PAF ou plutot BOMBA
aujourdhui ca va mieux et j'ai (normalement) compris comment etait structuré les bitplans, j'arrive à afficher une bricole
donc pour l'instant je programme sur 'equivalent' megaste2

au fait, mieux vaut taper directement dans les registres, utiliser Line A ?

A plus mes gens pour la suite de mes aventures

Ca y est, mon afficheur fonctionne

A+

La line A est à proscrire sur Falcon donc tape dans les registres !
Je ne sais pas ce que tu veux faire avec le Falcon, mais n'oublies pas que le mode True Color est plus rapide que le mode planar pour pas mal de chose ! En plus il est beaucoup plus simple à coder.

slt

je fais le port d'une intro que j'avais faite sur amiga histoire de me familiariser avec devpac et l'atari ste
ensuite, je ferai un autre port sur falcon...
En tout cas merci pour ton intervention ça remonte le moral
j'en etais arrivé à me dire que ce que je faisais n'eveiller aucune curiosité, interet ...

A+

Le Falcon n'est pas très courant, les gens qui codent en assembleur non plus, alors les deux à la fois tu penses bien...

Il y a une pléthore d'article sur les revues STmag, Atari Mag et STart Micro pour pour la programmation.
Tu peux retrouver ces articles sur le célèbre site abandonware-magazines. http://www.abandonware-magazines.org/

Dans le STart Micro numero 26 tu trouveras un article sur la programmation du mode true color(avec Source ASM),et dans
le numéro 27 un article sur l'utilisation du mode planar 256 couleurs (avec source asm également).
Le mode planar 16 couleurs du falcon est identique à celui du stf/e.

Tu trouveras sur ce lien la carte des registres de toute la gammmme atari ! http://deunstg.free.fr/sct1/hardware.htm

j'en etais arrivé à me dire que ce que je faisais n'eveiller aucune curiosité, interet ...

C'est un peu calme en ce moment. Ce qui est certain, c'est que tu auras moult réponses si tu as un problème de code sur Atari!
Il y a de nombreux cadors philanthropes ataristes qui passent sur ce site.

La Line-A sur Falcon est à oublier, par contre généralement tu peux utiliser les fonctions xbios(Sauf certaine si tu veux quelque chose de très très rapide).
Il y a même des fonction xbios pour utiliser le DSP ! ( Seulement le son, pour le reste c'est à la pogne )

changer de résolution proprement (ie qui marche aussi bien avec nvdi qu'avec d'autres softs tels que videl inside, ...) sur Falcon n'est pas si facile
un expert du domaine est stabylo

!call stabylo
--- Call : stabylo appelé(e) sur ce topic ...

si par hasard il est trop occupé pour passer par ici, jette un coup d'oeil aux sources d'Animator (qui sont en GPL), ça devrait contenir pas mal d'info (cf lien vers ce post pour les infos sur Animator et comment récupérer les sources)

sinon, je confirme, la line A est plutôt à éviter

pour mettre quelque chose en VBL, la méthode propre : mettre ta routine en VBL Queue (c'est alors géré par la routine VBL par défaut du système)
la méthode un peu moins propre: remplacer la routine du système (en $70.w) par la tienne

si tu as des questions précises sur la programmation Falcon, je peux essayer d'y répondre, même si ça fait bien longtemps que je n'ai pas programmé sur cette machine... tu ne t'intéresses pas à la Jaguar ?

-

merci pour ces infos

Mon avancement :
- je perds des cheveux
- on devrait toujours commenter ses sources car 16 ans apres j'ai perdu la logique d'un de mes bidules

A ce sujet, comment faites vous (principe, pas source) pour afficher un point à une position précise ? pour x = 0, 6, 8, 12, 16, 20, 31, 32, 33
je recupere bien la valeur du bit à allumer mais je ne vois plus comment (utilisation bset ou or)

Ca m'a été plus facile d'afficher un pavé à une adresse impair qu'un point



A bientot et merci d'avance pour votre aide

bon,

en travaillant par octet j'ai ça

move.w #30,d0
move.w #10*160,d1

move.w d0,d2
asr #3,d2
asl #3,d2
add.w d2,d1
not.w d0
bset d0,(a0,d1.w)

je lance et je perds un cheveux... c'est pas encore ça mais ça affiche un peu mieux...
j'arrete et fais une pause


A+

comment faites vous (principe, pas source)

Pour calculer l'adresse voici la formule (en c):
Adresse=(long)(((x>>1)&65528)+(y*160)+pt_ecr_travail);

pour calculer la valeur du mot:
Val=1<<(15-(x&15));

tu travailles en quel mode graphique?

je note (x,y) les coordonnées

je note w la largeur de l'écran et h la hauteur

- si c'est en bitplane, c'est un peu l'horreur

l'organisation est par blocs de 16 pixels comme ceci (par exemple en 16 couleurs on a 4 plans)
plan1 plan2 plan3 plan4 plan1 plan2 plan3 plan4 ...

le nombre d'octets par ligne (en 16 couleurs) est w / 2 (4 bits par pixels, en supposant que w est multiple de 16)

l'adresse (plus précisément l'offset) du bloc de pixels qui nous intéressent est (x / 16) * 8 + y * w/2

ici, (x / 16) est le quotient de la division entière de x par 16 (on a x / 16 = x >> 4 et et (x / 16) * 8 = (x >> 1) & 0xfff8)
et on a 8 octets = 16 pixels 4 bits

après le numéro du bit à allumer est (puisqu'on est en big endian) = 15 - (x % 16)
(x % 16 = x & 0xf)

le plus simple est probablement d'utiliser un or pour allumer le bit qui t'intéresse
et un and pour éteindre le bit qui t'intéresse

typiquement, tu as 16 masques, numéroté ainsi:

0 = %1000 0000 0000 0000
1 = %0100 0000 0000 0000
2 = %0010 0000 0000 0000
3 = %0001 0000 0000 0000
...
15 = %0000 0000 0000 0001

tu calcules (x % 16) ça te donne le numéro du masque à utiliser
pour allumer un pixel, tu fais simplement or.w masque,(adr)
pour effacer un pixel, tu fais simplement and.w ~masque,(adr)
(où ~masque est la négation binaire du masque: il peut être malin de calculer aussi la négation des masques)

et donc, évidemment, il faut faire ça (allumer/éteindre un bit) autant de fois que de plans et en fonction de la couleur

- si c'est en true color, alors c'est fastoche
l'adresse (l'offset) du point est tout simplement 2* x + y * 2 * w
(2 car 2 octets par pixel) et tu écris direct la couleur


en espérant t'avoir un peu aidé

Orion_ (./11) :
sinon je confirme, changer de resol sur falcon avec nvdi c'est pas hyper stable, j'ai du faire une ruse infâme pour rendre compatible falcon mon petit jeu sky4k

J'ai mis longtemps à le comprendre, mais en fait il faut juste désactiver l'affichage de la souris. Pour ça, les 2 fonctions de la Line A "show mouse" et "hide mouse" sont acceptables. Avec la VDI il faudrait se taper une virtual workstation VDI à ouvrir, et ce serait peine perdue parce que la VDI n'a pas un fonctionnement garanti après un changement de résolution.

C'est la principale différence entre la Vdi/Aes du TOS 4.04 et NVDI : après un changement de résolution, l'affichage da la souris peut sortir de la RAM du Falcon et donc faire des bombes.

ricco59 (./4) :
au fait, mieux vaut taper directement dans les registres, utiliser Line A ?

Ni tout-à-fait l'un ni tout-à-fait l'autre :-)

Beaucoup de codeurs utilisent les nouvelles fonctions de changement de de réso du TOS 4. Mais Vsetmode() a un petit souci : il faut effacer la zone d'arrivée avant sinon ça affiche du blanc tout laid.

Perso j'ai toujours eu un faible pour ce bon vieux Setscreen() qui a été étendu dans le TOS 4. Surtout avec la mode où on met des 0 et ça réalloue tout seul l'écran vidéo.

Pour de la doc système va voir l'Atari Compendium. Wikipendium est un Work In Progress Tu y retrouveras les 2 fonctions dont je parle ici et plein d'autres choses intéressantes

je ne veux pas me montrer borné et je vous remercie de votre aide, mais comme je vais au bout des choses et que là, je suis un peu bloqued voici ce que fait la petite routine (mais je pense que vous l'aurez deja compris)

d0=d2 = 30
asr #3,d2 > d2=03 (30/8=3)
asl #3,d2 > d2=24 (3x8=24)
add.w d2,d1 > d1=10x160+24
not.w d0 > d0=$FFE1
bset d0,(a0,d1.w) > (a0,d1.w)=02 | %00000010 | $02

j'allume donc bien le 6e bit si je compte de 0 à 7

donc si x=30 (et y=10*160), j'allume bien dans le 24e octet le 6e bit donc un pixel en x=30
où est l'erreur, je n'arrive plus à comprendre.

bon, je vais etudier vos methodes

A+ et merci encore

-

ah hem
si je me souviens bien, bset travaille en octet quand la destination est une adresse en mémoire, non?

sinon, je confirme ce que dit Orion_, la principale différence entre Atari et Amiga est que sur Atari les plans sont entrelacés, alors que sur Amiga ils sont les uns à la suite des autres

ok, donc apparemment, tu bosses en 8 bits donc 8 plans

si ça te gave de lire mon baratin, voici du code qui doit marcher à peu près

a0 = adresse de base de l'écran
d0 = X
d1 = Y
d2 = numéro de couleur

je suppose que tu travailles en 320x200

alors allons-y

  mulu.w #320,d1
  lea (a0,d1.l), a0 ; on se place sur la bonne ligne
  move.w d0,d1
  and.w #$fff0,d0
  add.w d0,a0 ; on se place sur le début du bloc de 16 pixels qui correspond à x
  
  and.w #$f,d1
  moveq #15,d0
  sub.w d1,d0 ; on a le numéro du bit (big endian)
  moveq #1,d1
  lsl.w d0,d1 ; calcule le masque

  moveq #8-1,d0 ; 8 bits = 8 plans
.set_pixel:
  lsl.b #1,d2
  bcs.s .pixel_on
.pixel_off:
  not.w d1
  and.w d1,(a0)+
  not.w d1
  dbf d0,.set_pixel
  bra.s .done
.pixel_on:
  or.w d1,(a0)+
  dbf d0,.set_pixel
.done:

-

ricco59 (./7) :
slt

je fais (...) devpac et l'atari ste
ensuite, je ferai un autre port sur falcon...
(...)
A+

desolé les gars, mais apparemment je vous ai conduit sur le mauvais chemin. (Messieurs les modérateurs, pouvez-vs changer ze titeul ? > Port d'une intro sur ste...)

oui je travaillais en octet (bset) et sur ste !
ceci dit je vous remercie et je lis et relis vos interventions avec grand interet

ce qu'il y a de bien c'est qu'il y a toujours plusieurs solutions

-

Orion_ (./24) :

SebRmv (./20) :
si je me souviens bien, bset travaille en octet quand la destination est une adresse en mémoire, non?

mmh, oui peut etre, comme j'utilise jamais bset, je m'en souviens plus

oui, effectivement, ça ne s'utilise pas tous les jours

après vérification dans le Programmers Reference Manual du 68k

la seule taille possible pour bset est .b
sauf quand la destination est un registre de données où alors c'est .l

SebRmv (./25) :

Orion_ (./24) :

SebRmv (./20) :
si je me souviens bien, bset travaille en octet quand la destination est une adresse en mémoire, non?

mmh, oui peut etre, comme j'utilise jamais bset, je m'en souviens plus

oui, effectivement, ça ne s'utilise pas tous les jours

après vérification dans le Programmers Reference Manual du 68k

la seule taille possible pour bset est .b
sauf quand la destination est un registre de données où alors c'est .l

oui d'ailleurs dans mes premiers tests ça m'a induit en erreur...

SebRmv (./15) :
(...)

le plus simple est probablement d'utiliser un or pour allumer le bit qui t'intéresse
et un and pour éteindre le bit qui t'intéresse

typiquement, tu as 16 masques, numéroté ainsi:

0 = %1000 0000 0000 0000
1 = %0100 0000 0000 0000
2 = %0010 0000 0000 0000
3 = %0001 0000 0000 0000
...
15 = %0000 0000 0000 0001

tu calcules (x % 16) ça te donne le numéro du masque à utiliser
pour allumer un pixel, tu fais simplement or.w masque,(adr)
(...)

en espérant t'avoir un peu aidé

Re

voila ce que j'ai fait en m'inspirant de ce que tu as dit juste au dessus et ça marche !
move.w #X,d0
move.w #Y,d1
mulu #160,d1
divs #16,d0
rol #3,d0
add.w d0,d1
add.w d1,a0
swap d0
move.w #%1000000000000000,d2
lsr.w d0,d2
or.w d3,(a0)

merci et stay tuned pour la suite de l'aventure

Un mulu ! un divs !
Va donc vite nous optimiser tout ça, sacripan !

pour le mulu 160, pas de soucis
pour le divs, j'va reflechir un tio peu apres canada/suisse (hockey)

ricco59 (./29) :
pour le mulu 160, pas de soucis
pour le divs, j'va reflechir un tio peu apres canada/suisse (hockey)

divs #16,d0 = lsr #4,d0