Programmation ASM sur ST - Page 2

hello,

impec ce lien : http://www.yardley.cc/atari/compendium/atari-compendium-chapter-4-XBIOS.htm

thx

hello,

encore une petite question, je voudrais afficher le contenu d'un registre à l'écran, par ex d0 contient $CC68F
; affiche text move.l #text,-(sp) move.w #9,-(sp) trap #1 ; GEMDOS 9 addq.l #6,sp ; Correct stack ; affiche taille (évidement ça ne marche pas comme ça) move.l #file_size,-(sp) move.w #9,-(sp) trap #1 ; GEMDOS 9 addq.l #6,sp ; Correct stack SECTION DATA text dc.b "toto.txt - ",0 file_size dc.l #$CC68F

J'aimerais avoir comme résultat :
toto.txt - 837263 octets

Ya peut-être un moyen simple de faire ça ?
Autrement que convertir la valeur hexa->decimale->text ?

Non.

Pas besoin de conversion hexa -> decimal, tu as une valeur 32 bits en interne, suivant le traitement que tu en fais, tu obtiendras une "conversion" decimal, hexa, octal, ou autre...

Je crois qu'il veut convertir un nombre en chaîne pour l'afficher. Ça peut être un bon exercice pour commencer à développer

Quelques indices :
- réserver à l'avance suffisamment de mémoire pour afficher le nombre le plus long possible sur 32 bits
- pour afficher en décimal, commencer par le chiffre le plus à droite, utiliser la division par 10 et son reste, ajouter la valeur du caractère ASCII '0'.
- en hexadécimal, c'est pareil, sauf qu'on peut remplacer la division par 16 par un décalage de 4 bits à droite, et le reste par un AND avec $F. Pour convertir de 0 à 15 en '0' à 'F', on peut utiliser une table, ou un saut conditionnel pour gérer séparément chiffres et lettres.

Zerosquare (./34) :
Je crois qu'il veut convertir un nombre en chaîne pour l'afficher. Ça peut être un bon exercice pour commencer à développer

En me relisant je m’aperçois que j'aurais pu être plus clair

Tes indices m'ont aidé :
Mais quelle torture mentale , j'ai commencé par diviser par 10(une bonne heure) puis A.
CC68F / A = 1470E reste 3 1470E / A = 20B4 reste 6 20B4 / A = 345 reste 2 345 / A = 53 reste 7 53 / A = 8 reste 3 8 < A ----------------------> 837263

Le coup de la valeur de '0' je ne suis pas sûr que j'aurais trouvé ça par moi même...

j'ai un peu buggé sur la division 32Bits, divu.l me sortait une erreur de taille.
Après avoir cherché un peu j'ai trouvé qu'on ne pouvait diviser que sur 16bits, pour avoir le résultat sur 32(reste et quotient).

J'ai trouvé aussi que cette instruction marchait sur le 68030, j'ai trouvé l'option dans devpak, j'ai changé 68000 en 68030(après tout j'ai un falcon ^^)
et là ça marche...(on perd le reste mais c'est pas grave)

Du coup mon truc ne va pas marcher sur ST ?

Effectivement. J'avais oublié que la division du 68000 est 32/16 -> 16/16.

Tu as une autre méthode qui n'utilise pas de division : soustraire 1 milliard tant que ton nombre est supérieur ou égal à 1 milliard, en ajoutant 1 à un compteur à chaque fois que ça réussit. À la fin, la valeur du compteur est simplement le chiffre de gauche de ton nombre. Ensuite tu remets le compteur à zéro, et tu répètes la même méthode en utilisant 100 millions, 10 millions, etc.

Tu peux utiliser une table pour stocker les valeurs 1 milliard, 100 millions, 10 millions, etc., sinon tu vas te retrouver avec le même problème de division.

Petit bonus : en fait, tu n'as pas vraiment besoin de comparer ton nombre après avoir soustrait. Indice : regarder comment les instructions sub et cmp fonctionnent, et quel est leur effet sur les flags

Regarde dans les tutos asm, il y a une macro pour afficher.

Le coup de la soustraction expliqué par Zero, tu a le code dans mise en oeuvre du 68000 (Si tu a le livre). Sinon je peux te donner tout cela. Y compris les routines de conversion chiffre->string.


GT En décimal !

j'ai pas cherché les optimisations possibles mais ça marche.
C'est la stricte application de ton post, thx
lea tab,a0 ; tableau dans A0 lea dec_val,a1 ; resultat dans A1 move.l #9,d5 ; D5 = 10 positions move.l hex_val,d0 ; D0 = nbre … convertir position move.l #0,d1 ; D1 = nbre de soustractions move.l d5,d2 ; D2 = index dans tab*4(deplacement en long) mulu.w #4,d2 ; D2 = index dans tab*4(deplacement en long) move.l 0(a0,d2.w),d3 ; D3 = valeur dans tab soustractions cmp.l d0,d3 bgt plusgrand add.w #1,d1 ; incremente d1(nbre de soustractions) sub.l d3,d0 ; soustractions bpl soustractions ; boucle si positif plusgrand add.b #"0",d1 ; Ajout du code de "0" move.b d1,(a1)+ ; sauvegarde le resultat dbra d5,position ; boucle tant que d5 > 0 SECTION DATA hex_val dc.l $CC68F dec_val dc.b "4294967295",0 tab dc.l 1,10,100,1000,10000,100000,1000000,10000000,100000000,1000000000

Amélioration possible: mettre des " " au lieu de "0" au début du résultat.

thx

EDIT :

@GT, je n'ai pas encore de livre mais je vais m'équiper de suite.
Cependant j'aime bien appliquer des théories, j'apprends mieux comme ça.
Par contre c'est sûr que le coup de l'ajout du code de '0' ou encore des décalage au lieu des divisions, ou encore utiliser les flags, ça s'invente pas.

Xcelfr, oui très bon exercice de cherché par soit même.

Oui le coup des flags, c'est super puissant, on peux se passer d'un paquet de comparaisons inutiles.

La première grosse optimisation est le mulu :

une multiplication d'un multiple d'une puissance de 2, c'est un décalage vers la gauche :

donc mulu.w #4,d2 c'est : lsl.w #2,d2 (2² ca donne 4 !)

attention nous somme bien dans le cas du 68000, donc avec des nombres entiers.

pour la division pareil mais vers la droite :

divu.w #4,d2 ca donne lsr.w #2,d2

Après il y a des paquets d'optimisation, mais on va laisser un peu chercher


GT

re
ça fait une semaine que je galère avec le port série.
Voye- vous une raison pour laquelle un byte contenant $11 ne puisse pas être présent dans le buffer de réception?
Je m'explique j'envoie une série d'octets par le port série, disons 16 octets et si l'un d'entre eux est $11, il n'apparait pas dans le buffer de réception ex:

J'envoie sur le port série 11,4B,11,14,00,7C, depuis l'atari, je fais des lectures séquentielles et j'obtiens 4B,14,00,7C( tous les octets sauf les 11..)
J'ai essayé pleins de truc, je n'arrive à comprendre ce qu'il se passe
j'ai essaye 2 méthodes pour lire le port série :
move.w #3,-(sp)
trap #1
addq.l #2,sp

et
move.w #1,-(sp)
move.w #2,-(sp)
trap #13
addq.l #4,sp

J'ai le même résultat, comme si le caractère n'avais même pas été envoyé.
Je sèche, j'ai pensé a aller voir du coté du MFP pour voir si j'avais des erreurs de réception, ce qui m'amène à ma deuxieme question,
Comment on fait pour interroger le MFP ?

J'ai testé une routine du genre

test
AFFICHE #rcv_err
WAIT_KEY
rte

J'ai trouvé que le vecteur était:
* 11 $12C Erreur de réception RS232 *

Mais j'ai pas trouvé comment sa s'utilise, j'ai bien pensé à un
move.w #test,$12C mais n'assemble mme pas

CeL.

Donc dans l'ordre :

Dans le livre du developpeur, pour ton premier appel Gemdos, apparement pas de controle de flux, donc possibilité de perdre des infos. La préconisation est d'utiliser la fonction bios.

Je reviens de suite, je reprends certaines docs developpeurs.

Le fait que ton '11' ne passe pas cela parait vraiment bizzare, je sais pas si c'est spécifique au ST, peut être que Zero a une idée du coté hardware.

Oublie pour l'instant la version Mfp ou je vais voir si je peux vite te codé un truc.


GT Oublié

Désactive le contrôle de flux XON/XOFF côté Atari (ça doit être expliqué dans les docs sur comment configurer le port série). Quand ce mode est activé, les caratères XON ($11) et XOFF ($13) sont interprétés comme des commandes pour mettre en pause ou reprendre l'émission.

EDIT : j'ai pas la doc hardware en tête, mais je doute que ce soit le matos qui gère ça, généralement c'est fait en logiciel.

Ben voila Zero a réglé ton problême !!

Si tu a Xacc, il y a un accessoire qui permet de choisir le controle de flux, acessoire appellé Modem.


GT Sans controle

je viens de tester avec le 13 et effectivement il ne passe pas non plus c'est rassurant, je vais désactiver xon/xoff (j'ai vu ca qque part) et je reviens

merci les gars, c'était bien ça,j'ai d'autres pbs mais je vais encore chercher

voila, ouf, ça marche maintenant, bon c'est juste pour apprendre l'asm parce que franchement vaut mieux passer par le lecteur de disquette
à moins qu'il soit mort ou qu'on ait 5min à perde

https://www.youtube.com/watch?v=lxuX0GsZh1U&feature=youtu.be
le timer(échoue une fois sur deux...)

Ça m'amène à qques questions (encore)

- Le buffer de réception rs232, où peut-on voir/paramétrer sa taille ?
Parce que si j'envoie des plus de 48 octets par "chunk", on perd les caractères au dessus.
- buffer overflow, je n'arrive pas à trouver comment gérer ça.

Sinon niveau bouquin, c'est difficile à trouver.
- Mise en oeuvre du 68000
- Le Livre du développeur sur Atari ST , ya bien 2 tomes ? il vaut le coup ? ou "Mise en oeuvre du 68000" devrait suffire ?

Allez j'vais debugger mon timer

CeL.

xCeLfr (./48) :
- Le buffer de réception rs232, où peut-on voir/paramétrer sa taille ?Parce que si j'envoie des plus de 48 octets par "chunk", on perd les caractères au dessus.

Aucune idée. Regarde dans le Compendium et/ou demande à GT
Si le machin que tu branches sur le port série supporte le contrôle de flux (matériel ou logiciel) c'est un moyen de résoudre le souci.

xCeLfr (./48) :
Sinon niveau bouquin, c'est difficile à trouver.

Hop !
http://devlynx.ti-fr.com/ST/

The link: http://devlynx.ti-fr.com/ST Oo

thx

xCeLfr (./48) :
Sinon niveau bouquin, c'est difficile à trouver.
- Mise en oeuvre du 68000
- Le Livre du développeur sur Atari ST , ya bien 2 tomes ? il vaut le coup ? ou "Mise en oeuvre du 68000" devrait suffire ?

Mise en oeuvre du 68000 est comme son nom l'indique une bible du 68000. Il y a inscrit Mac dessus, mais c'est vraiment pas orienté vers une machine quelconque.

En francais pour ma part, je dirais que c'est le meilleur livre pour les programmeurs (Je peux pas parlé coté hardware, peut etre Zero ou SCPCD). Il explique bien, tu as toutes les instructions, les cycles machines (Pour les fou furieux de l'optimisation bisous a Thadoss !). J'ai plusieurs livres du 68000, mais c'est celui que j'utilise le plus.

Livre du developpeur c'est spécfique a nos machines. Le 2 tome est plus 'leger' et parle de certaines choses et des détails sur le ste.

Moi mes 3 livres que j'ai sur le bureau : mise en oeuvre du 68000, livre du developpeur tome 1 et le compendium (Cadeau de Strider que j'embrasse aussi !)

Ton timer lancé par fonctin xbios ? Xbtimer ?

GT Sous interruption.

J'ai commandé :
- Mise en oeuvre du 68000 et
- livre du developpeur tome 1
comme ça je sur armé
En attendant j'utilise les PDF du lien plus haut, mais j'préfère le papier...

Pour le timer(qui n'en est pas un), je lis l'heure avec Gettime() avant et après envoi et je fais la différence.
Je fais minutes*60+secondes*2 au début de la réception puis le même calcul à la fin.
La différence entre les deux prises devrait représenter le temps du transfert.
J'ai pas encore debuger mais ca devrait le faire.

Il y a un driver pour corriger et augmenter les performances des ports série:
http://serge.lavayssiere.free.fr/sting/hsmodem.htm

Tu peux augmenter la vitesse de transfert jusqu'à 230k baud suivant ta config. Tu peux choisir la taille des buffers de réception / émission (j'ai 16ko pour les deux, mais tu peux mettre plus, ou moins).


Tu as un timer 200Hz en $4ba http://toshyp.atari.org/en/003004.html pour chronométrer avec plus de précision (lecture en superviseur).

J'avais mal compris pour le timer, je pensais une inter utilisé pour le RS232.

Nalfus a règlé ton problème, c'est le même timer qu'il t'a donné qui correspond a la fonction timer du gfa :

t=timer

donc tu fais une premiere lecture de $4ba
tu execute ton code
tu relis $4ba, auquel tu retire ta premiere lecture et tu divises par 200 et voili voila.


GT Chronometré

j'ai un peu pataugé( j'ai échoué ) sur l'install de hsmoden avec les truc acc prx, j'ai rien compris
Je verrai ces trucs là plus tard, je pars de zero sur falcon, j'ai vu un screen avec de jolies icones en couleur, mais plus tard..)

J'vais plutôt fiabiliser et optimiser mon code histoire de finaliser un truc.
j'vais bosser sur le passage en super et la lecture de $4ba.

Sinon pour info je tourne à 900o/s ^^.... bah quoi ça tourne c'est ce qui compte

le test ultime de stabilité :
Fichier joint :

D'ailleurs comment transférer ce fichier autrement vers le DD du falcon ?

Maintenant j'ai envie de jouer avec les sprites, j'me demande encore :
- en C ou ASM
- en compatibilité ST ou Falcon (pour les couleurs)

j'vais encore avancer sur l'asm, pendant qu'il y a des pointures dans le coin

Il y a plusieurs moyens de transférer un fichier.

Mais d'abord joli boulot, c'est quand même plus gratifiant de pouvoir se dire je l'ai fais moi même, c'est de l'artisanal et en asm en plus !!!

Pour les sprites, cela dépend de trop de paramètres :

- nombres de couleurs
- taille
- nombre de sprites que tu a besoin

car par exemple un gros sprite sur un STE, tu peux utiliser le blitter, donc que ce soit en Gfa, C ou asm ca changera pas beaucoup (Ecriture de valeurs dans des registres).

après si tu veux plein de petits sprites (genre 16*16), le faire a la main en asm est la technique la plus rapide. Surtout sur le Falcon, avec le cache il y a moyen de faire des petites merveilles. Et si tu reste en 16 couleurs, cette routine marchera aussi bien sur un ST que sur un Falcon, et si sur Falcon tu voudras le faire en 256 couleurs, tu aura juste a couper coller quelques instructions.

Le top reste le code généré (Voire le super maitre en la matière, notre ami Thadoss ), mais déjà écrire une routine en asm, c'est un sacré boulot, mais ca 'poutre grave'.

Donc regarde déjà si tu a un cahier des charges, ou alors c'est vraiment par 'interressement intellectuel" ?

GT En asm

hello,

J'ai fait pleins de tests, j'ai réussi à installer hsmoden, j'ai viré le paramétrage de la vitesse dans mon code
mais ça n'a pas l'air de changer vraiment grand chose ^^

Par contre rien à faire je n'arrive pas à changer la taille du buffer, j'ai "Cannot set buffers for port Modem2" puis cà :
Fichier joint :

Avec qques optimisations, j'arrive à monter à 1500o/s pas plus
La taille du buffer doit jouer pour beaucoup dans la vitesse.

D’ailleurs d'apres iorec le buffer est de $100, si je mets plus de 52octets dedans ça plante...

Il y a un CPX pour configurer HSMODEM ?

Pour ton Falcon, tu dois avoir DRVIN.PRG et SCC.PRG dans le dossier AUTO, l'ordre est important, DRVIN en premier, tout les autres patch doivent être retirés.

Pour configurer, tu drag & drop les PRG sur SETTER.TTP, plein de question seront posées pour la configuration (dont la taille des buffers à la fin pour SCC.PRG).

J'ai copié DRVIN.PRG et SCC.PRG dans AUTO, ça se charge bien dans l'ordre au démarrage. Mais j'ai rien fait pour.
J'ai pas bien compris ce qui détermine l'ordre d’exécution au démarrage ? c'est juste l'ordre de copie des fichiers dans le répertoire ?

Nalfus (./59) :
Il y a un CPX pour configurer HSMODEM ?

Oui, j'ai trouvé SERIAL.CPX dans l'archive de sting

J'vais tester avec setter.ttp pour voir si c'est mieux