source assembleur nostub pour apprendre - Page 7

MM.Flanker & Sasume, à propos du système des fichiers, on peut créer un data ou une matrice en asm, le ou la remplir, le ou la modifier, le ou la trier rapidement (+ rapidement que sortA) et le ou la consulter en basic ?

M.Sasume, à propos de ton post 154, moi j'ai cherché de nombreuses heures sur la toile pour trouver des tutos nostub intéressants, je n'en ai trouvé que 2 !!!! Et sans être péjoratif par rapport à leur auteur que je respecte, je les ai trouvé maigre compte tenu des possibilité colossales qu'offre l'asm. C'est pareil pour les progs nostub...ils sont rares ceux qui sont fournis avec leur source. Ou alors je n'ai pas les bons links !!!

si tu sais afficher un pixel, tu comprendras ce qui ne va pas dans ton sprite

si on raisonne sur un octet :
d3.b = #%00010010
qui correspondra au premier octet de ton sprite qui fait 8 pixels de large (on va commencer soft ^^)

tu veux l'afficher en (2,4) (ligne 2, colonne 4) on a d0 = 4, d1 = 2

la mémoire ressemble à ça :

00000000 00000000 00000000 00000000 ... 00000000 00000000 00000000 (30octets)
00000000 00000000 00000000 00000000 ... 00000000 00000000 00000000 (30octets)
00010010 00010010 00000000 00000000 ... 00000000 00000000 00000000 (30octets)
00000000 00000000 00000000 00000000 ... 00000000 00000000 00000000 (30octets)
00000000 00000000 00000000 00000000 ... 00000000 00000000 00000000 (30octets)
00000000 00000000 00000000 00000000 ... 00000000 00000000 00000000 (30octets)
00000000 00000000 00000000 00000000 ... 00000000 00000000 00000000 (30octets)

si tu fais move.l #LCD_MEM, a0 , a0 va pointer vers le truc en rouge
si tu fais mulu #30,d1 add.l d1,a0
et si tu fais move.b d3,(a0) tu vas avoir le truc en bleu
puis si tu fais addq.l #1,a0
et si tu fais move.b d3,(a0) tu vas avoir le truc en verts

or tu veux avoir

00000000 00000000 00000000 00000000 ... 00000000 00000000 00000000 (30octets)
00000000 00000000 00000000 00000000 ... 00000000 00000000 00000000 (30octets)
00000001 00100000 00000000 00000000 ... 00000000 00000000 00000000 (30octets)
00000000 00000000 00000000 00000000 ... 00000000 00000000 00000000 (30octets)
00000000 00000000 00000000 00000000 ... 00000000 00000000 00000000 (30octets)
00000000 00000000 00000000 00000000 ... 00000000 00000000 00000000 (30octets)
00000000 00000000 00000000 00000000 ... 00000000 00000000 00000000 (30octets)

en gros, tu veux mettre d3 à cheval sur 2 octets

comme tu ne peux pas écrire en mémoire de cette façon, il faut couper d3 = #%0001 0010 en deux parties #%0000 0001 et #%0010 000

à ton avis, comment on peut faire ça avec uniquement
* des rotations (lsr et lsl)
* des and et des or

Bonsoir M.Flanker, j'essaye de suivre le raisonnement mais je ne vois pas les couleurs, tout est blanc!!

j'ai édité, ça doit venir de ça

zegoo :
M.Sasume, à propos de ton post 154, moi j'ai cherché de nombreuses heures sur la toile pour trouver des tutos nostub intéressants, je n'en ai trouvé que 2 !!!! Et sans être péjoratif par rapport à leur auteur que je respecte, je les ai trouvé maigre compte tenu des possibilité colossales qu'offre l'asm. C'est pareil pour les progs nostub...ils sont rares ceux qui sont fournis avec leur source. Ou alors je n'ai pas les bons links !!!

encore une fois, arrête de te focaliser sur le nostub/kernel : pour comprendre comment fonctionne la memoire video et ce genre de choses, ça n'a aucune importance.

J' AI COMPRIS !!! Oh merci M.Flanker ! Mais la mise en oeuvre va être plus compliquée !

zegoo :
J' AI COMPRIS !!! Oh merci M.Flanker ! Mais la mise en oeuvre va être plus compliquée !

nan, ce n'est pas dur, juste un peu chiant car il faut le faire soigneusement
mais il faut impérativement faire tout plein de dessins de ce type

M.Pen^2, évidemment si je codais en kernel je n'aurais qu'à faire put_sprite ou un truc dans le genre, sans rien comprendre puisque je n'ai pas les sources. Y-aurait-il un intérêt à coder en asm si c'est pour ne pas voir comment fonctionne une librairie.
Je ne focalise pas sur kernel/nostub, je focalise sur nostub !

Bon ben c'est simple : ne focalise plus sur rien.

En gros le plus important en asm, c'est pas de savoir coder en kernel ou nostub (ce qui veut rien dire en soit), c'est de savoir donner directement les instructions au processeur (et les bonnes !!!!). Donc t'es obligé d'en passer par là (tot ou tard).

La principale difference entre nostub et kernel d'un point de vue "codeur" (je pense que tout le monde partage a peu pres cet avis), c'est que :
- En nostub tu te demmerde pour utiliser ce que fournit l'OS de la TI (TIOS) et ton lot d'instructions asm68k.
- Le kernel lui te "pré-mâche" certaines taches de la programmation (exemple les detections d'HW, calc etc...) et te fournit quelques outils (comme le support des librairies par exemple) mais tout ca est entre-coupé d'asm !!

Donc, que ce soit en kernel ou nostub il te faut connaitre l'asm
Le choix kernel/nostub, c'est toi qui verra ca apres ! (Si tu prefere le support des libs dynamiques, ou pas, par exemple)
Encore une fois ne perd pas courage, l'asm c'est dur a avaler au début mais apres c'est un regal ^^

zegoo :
Y-aurait-il un intérêt à coder en asm si c'est pour ne pas voir comment fonctionne une librairie.

Oui, il y en a un. Avant parce qu'il n'y a avait pas de compilateur C sur TI68k, aujourd'hui parce que certains programmes ou certaines portions de programmes sont plus faciles à coder en asm qu'en C (en gros, on fait pas de l'asm uniquement "pour le fun" ou par curiosité, si c'est l'image que tu en avais).

(comme les TSR, par exemple)

Voire complètement impossible en C ^^

Messieurs, je n'ai pas du bien me faire comprendre, je crois.. Je n'ai rien contre le kernel; je pense mêmê qu'un jour je coderais en kernel pour des questions de pré-mâchage comme le disais si bien M.Dude. Je n'imagine pas non plus, M. Martial Demolins, que tout devient facile avec l'usage d'un kernel...d'ailleurs "hacks" !! késako ?? Ce que je sais, et je me suis présenté comme cela, c'est que je n'y connais strictement rien à l'asm ! Alors, si c'est pour apprendre convenablement, autant ne pas passer par l'usage d'un kernel, autant avancer pas à pas même s'il faut presque réinventer la roue ! Peut être suis-je le seul à aborder l'asm de cette manière là, peut être qu'il ne s'agit pas de la meilleure manière, en tout cas si je fais des erreurs dans mes démarches, je m'en apercevrais, je suivrais les conseils qui me sont donnés si ceux ceux-ci s'averrent primordiaux pour avancer correctement..
J'accepte les critiques uniquement lorsqu'elles sont constructives; pour certains merci, voire grands mercis, pour d'autre comme celle de M. pen^2, je m'en cogne !
Pour apprendre il est bon de lire certaines sources ! Comment peut-on apprendre le ba-ba en lisant des sources écrites en kernel qui utilisent des librairies dont on a pas les sources ???
M.Extended, existent-il vraiment des personnes qui codent en asm pour le fun ou la curiosité ? En tout cas je n'en ferais pas partie ! J'ai un projet bien précis, pas de temps à perdre en fun ou curiosité et surtout une revanche à prendre !
Je n'ai posté pour relancer la guerre entre le nostub et les kernels, j'ai posté parceque je compte sur vous, sur la solidarité entre codeurs, sur le partage qui sert la Communauté !

zegoo :
Messieurs, je n'ai pas du bien me faire comprendre, je crois.. Je n'ai rien contre le kernel; je pense mêmê qu'un jour je coderais en kernel pour des questions de pré-mâchage comme le disais si bien M.Dude.

c'est une excellente raison

Je n'imagine pas non plus, M. Martial Demolins, que tout devient facile avec l'usage d'un kernel...d'ailleurs "hacks" !! késako ??

c'est des contournements pas beaux de certaines limitations de la calculette : par exemple, regader le code de l'AMS pour y trouver l'adresse de certaines variables.
Ce n'est pas très fiable, et comme le code peut changer d'une versiond e l'ams à l'autre, il peut changer

Ce que je sais, et je me suis présenté comme cela, c'est que je n'y connais strictement rien à l'asm ! Alors, si c'est pour apprendre convenablement, autant ne pas passer par l'usage d'un kernel, autant avancer pas à pas même s'il faut presque réinventer la roue !

je truove que c'est la bonne méthode. mais il faut être conscient que quelque soit ton premier projet, il aura très certainement besoin d'être recodé quand tu l'auras fini. mais tu le referas beaucoup plus vite, et nettement plus proprement

Peut être suis-je le seul à aborder l'asm de cette manière là,

M.Extended, existent-il vraiment des personnes qui codent en asm pour le fun ou la curiosité ?

En tout cas je n'en ferais pas partie ! J'ai un projet bien précis, pas de temps à perdre en fun ou curiosité et surtout une revanche à prendre !
Je n'ai posté pour relancer la guerre entre le nostub et les kernels, j'ai posté parceque je compte sur vous, sur la solidarité entre codeurs, sur le partage qui sert la Communauté !

la "guerre" kernel-nostub est bien plus ancienne que tu ne le penses je crois

zegoo
: M.Extended, existent-il vraiment des personnes qui codent en asm pour le fun ou la curiosité ?

Ah oui J'ai codé Punkoe en ASM pour le fun (mais c'est un tout petit projet).

zegoo
: En tout cas je n'en ferais pas partie ! J'ai un projet bien précis, pas de temps à perdre en fun ou curiosité et surtout une revanche à prendre !

Dans ce cas as-tu étudié la possiblité de le faire plutôt en C ? Si tu ne le connais pas non plus, je ne pense que la "learning curve" soit plus raide (ne me réponds pas "parce l'asm a l'air plus marrant", sinon tu n'est plus cohérent).

M.Extended, je ne veux coder en C pour l'instant, je n'y viendrais peut être jamais d'ailleurs !
Revenons-en à nos moutons, où trouver des infos pour créer des variables dans un code asm qui soient consultables ou modifiables sous TIOS ?

M.Extended, je ne veux coder en C pour l'instant, je n'y viendrais peut être jamais d'ailleurs !

C'est marrant comme tu as des idées arrêtées sur des trucs que tu ne connais pas

Pourquoi le C ne t'attire pas ?

Pour gérer les fichiers du TIOS, il faut utiliser les fonctions du style SymAdd, SymFind, ...
Tu auras aussi affaire à de l'allocation dynamique avec des HeapAlloc.
Mais le plus important est que tu respectes le format des variables du TIOS, celui-ci est décrit dans le sdk de TI.

M.Spectras, j'ai ecris:
M.Extended, je ne veux *pas coder en C pour l'instant, je n'y viendrais peut être jamais d'ailleurs !

Où sont donc mes idées arrêtées dans mes propos ?

Ben dans la formulation ça peut suggérer deux choses. Soit que tu t'estimes trop bête pour faire du C, soit que tu ne comptes jamais y venir parce que tu trouves que c'est "inférieur" à l'assembleur.

Dans tous les cas il y a un point clef à ne jamais oublier : "the right tool for the right job". Il n'y a pas un langage supérieur à un autre. Chacun a des forces et des lacunes, le tout est de les connaitre pour choisir à bon escient quel langage utiliser, au cas par cas (voire d'utiliser plusieurs langages dans le même programme).

C'est vrai aussi pour ce qui se disait plus haut (kernel et nostub). L'un n'est pas meilleur que l'autre dans l'absolu. Leurs forces et faiblesses sont différentes voilà tout.

Comme dit la fameuse citation, quand on ne sait manier que le marteau, tout problème ressemble à un clou. (traduction libre).

Et l'envie tu connais ??
Moi je n'ai pas envie de coder en C pas parceque je me sens trop bête, ni parceque je trouve qu'il s'agit d'un langage inférieur à un autre, bien au contraire.
J'ai juste envie de coder en asm nostub ! Attention, pas comme une envie de pisser !
Tu as entièrement raison à propos de kernel-nostub, enfin un bon compromis !

Quant à ta citation, je rajouterais "tous les chemins mènent à Rome !", plus long, plus court, peu importe quelque soit le choix fait par le codeur.

zegoo> C'est un peu bidon ce que tu dis sur l'envie de vouloir coder en tel ou tel langage. Parce que l'envie est suscitée par différents facteurs extérieurs...
Donc en disant ça tu ne réponds pas vraiment à la question "pourquoi pas le C ?".

C'est incroyable çà ! A te lire on ne peux pas avoir juste l'envie de coder en asm ! C'est dingue çà et le libre arbitre alors ? Le C ne m'attire pas, c'est tout !

Arrivé là je pourrais rééditer : "C'est marrant comme tu as des idées arrêtées sur des trucs que tu ne connais pas "
Mais ça donnerait l'impression qu'on tourne en rond, alors je vais m'abstenir.

C'est de la mauvaise foi çà ! Je n'ai rien contre le C, je n'ai pas d'idées arrêtées sur le C, je veux juste coder en asm nostub, est-ce vraiment un crime ???

Bon arretez là
Il a envie de coder en asm c'est son choix laissez-le faire

Juste qu'il faut que tu comprenne bien que l'asm c'est juste des instructions proco! (cf. A68kGuide.)
De plus le TIOS est là, donc autant l'utiliser, alors pour ca, regarde les protos de tigcclib (qui sont en C et c'est peut-etre pour ca que certains te poussent a apprendre le C plutot que l'asm) mais facilement comprehensibles en asm. Sachant que tout ca t'es accessible en asm !!
Et vu que tu veux te mettre au nostub, ce sera ta meilleure bibliotheque de fonctions

zegoo :
J'accepte les critiques uniquement lorsqu'elles sont constructives; pour certains merci, voire grands mercis, pour d'autre comme celle de M. pen^2, je m'en cogne !

1. je ne vois pas en quoi ce n'est pas constructif de te dire de ne pas te focaliser sur un mode de programmation ou un autre, m'enfin bon..
2. quoi qu'il en soit, tu pourrais rester correct... Tu as beau être limite obséquieux en mettant des "M." devant les pseudos et des majuscules à la "Communauté", si tu es grossier à coté ça fait pas très crédible...

zegoo :
M.Pen^2, évidemment si je codais en kernel je n'aurais qu'à faire put_sprite ou un truc dans le genre, sans rien comprendre puisque je n'ai pas les sources. Y-aurait-il un intérêt à coder en asm si c'est pour ne pas voir comment fonctionne une librairie.
Je ne focalise pas sur kernel/nostub, je focalise sur nostub !

3. je ne vois pas le rapport, les bibliothèques tu peux aussi en utiliser en nostub...
4. la majorité des bibliothèques sont open source

Dude :
De plus le TIOS est là, donc autant l'utiliser, alors pour ca, regarde les protos de tigcclib
[...]
Et vu que tu veux te mettre au nostub, ce sera ta meilleure bibliotheque de fonctions

s'il ne veut pas utiliser des bibliotèques open sources codées en ASM sous le pretexte qu'il n'a pas accès au code, ça n'est pas pour utiliser des fonctions codées plus ou moins à l'arrache en C, dont les sources ne sont pas disponibles, et compilées par un mauvais compilo...