1

Coucou a tous,

Pour eviter de polluer le tuto assembleur, j'ouvre ici un petit sujet. Le temps que Folco puisse trouver un peu de temps pour corriger le tuto suivant.

Vous voulez vous mettre a l'assembleur mais pour quel raison ? Ou surtout pour developpez quoi ?


GT octopus
avatar
je sais pas depuis que Fadest nous mets de la zik partout dans ses jeux l'univers a été ebranlé (LordKraken)

2

Bonsoir,

J'en profite pour saluer l'initiative. (GT très content).

Personnellement, par curiosité et fierté personnelle. Connaitre le principe de base (et un peu plus si possible) de l'assembleur.

Après tout dépend du temps que nous pouvons y consacrer. Mais développé un petit utilitaire, un jeu (de logique un peu comme "Catch Me if you can")...

D'autres langages sont peut-être plus adaptés pour tel ou tel finalité. Mais coder en 68k, cela doit friser un peu le poil.

Voilà.

Ccarl84
Ccarl

3

Oui d'autres langages sont parfois 'plus efficaces'. Mais l'assembleur est et sera toujours le premier sur 2 points, toujours le programme le plus court et le plus rapide a l'éxécution.

C'était pour savoir si on se tourne plus vers de la programmation 'systeme', utilitaire ou vers du jeu, démo (programmation pas super propre (Même si on peux faire du jeu en programmant proprement (Bisous A Rajah (Maitre en la matière) même si il a toujours son tapis de souris miga wink ).

On pourra faire un peu des deux, mais essayez de dev une application est toujours le seul vrai moyen d'avoir un paquet de situation.

Je crois qu'en plus les personnes qui suivent utilisent un peu de tout les types d'Atari (ST, TT, Falcon, Falcon boosté).


GT Curieux
avatar
je sais pas depuis que Fadest nous mets de la zik partout dans ses jeux l'univers a été ebranlé (LordKraken)

4

L'initiative vient surtout grace (Ou a cause wink ) d'Huggy one, qui en avait fait la réquete.


GT octopus
avatar
je sais pas depuis que Fadest nous mets de la zik partout dans ses jeux l'univers a été ebranlé (LordKraken)

5

Perso, peut-être faire des routines utilisables dans du code GFA voir même des programmes entièrement en assembler.
avatar
ATARI Belgique toujours actif

http://gfa-basic.forumactif.com/

6

L'interfaçage asm-gfa est une bonne idée, il y en a d'autres qui aimerait ?


GT Pour le GFA (Pour moi le basic qui a révolutionné le basic grin )
avatar
je sais pas depuis que Fadest nous mets de la zik partout dans ses jeux l'univers a été ebranlé (LordKraken)

7

Développer des drivers dehors

8

oui intégration asm en gfa ça me botterais bien aussi smile
---------------------------------
Cooper / Paradize
STf/Mega ST/STe/F030/Lynx
---------------------------------
Compilations de groupes ataristes français : https://www.youtube.com/channel/UCEBFi9nRczTRjRSvmy-QF8g

9

Nalfus (./7) :
Développer des drivers dehors


GT ................................................. grin

Nalfus on l'entend jamais mais il suit toujours les bétises que fait GT.... Pas une bonne idée smile


GT octopus
avatar
je sais pas depuis que Fadest nous mets de la zik partout dans ses jeux l'univers a été ebranlé (LordKraken)

10

Moi j'ai appris l'assembleur 68k juste pour pouvoir taquiner GT avec ses bugs tongue

dehors
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

11

C'était surtout pour pouvoir mettre 'connaissance d'un vrai assembleur sur ton C.V. (S.D.) wink


GT Taquin calin
avatar
je sais pas depuis que Fadest nous mets de la zik partout dans ses jeux l'univers a été ebranlé (LordKraken)

12

grin
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

13

Bon sur mon post-it que j'ai pas collé sur l'écran (Pas collé du tout d'ailleurs grin )

- tuto sur l'interfacage asm -gfa (C'est super simple si vous connaissez le pc-relatif)

Je pensais a l'utilisation du Gem (Vdi et Aes) cela interresse des personnes ? En gros la gestion des menus, fenetres, etc....




GT Pour l'ASM
avatar
je sais pas depuis que Fadest nous mets de la zik partout dans ses jeux l'univers a été ebranlé (LordKraken)

14

GT Turbo (./13) :
Bon sur mon post-it que j'ai pas collé sur l'écran (Pas collé du tout d'ailleurs grin )

- tuto sur l'interfacage asm -gfa (C'est super simple si vous connaissez le pc-relatif)

Je pensais a l'utilisation du Gem (Vdi et Aes) cela interresse des personnes ? En gros la gestion des menus, fenetres, etc....




GT Pour l'ASM


Oui, c'est pas trop complexe ?
Ccarl

15

Les appels non pas plus que le C j'ai toute une librairie écrite, et ci certains veulent aller plus loin, je peux fournir un gestionnaire complet, qui gere les menus (Avec les raccourcis clavier en automatique), la gestion des formulaires en fenetres et pleins d'autres trucs marrants. Menu Pop up (Routine écrite artisanalement, compatible STF-STE et pas de raison TT aussi)

GT octopus
avatar
je sais pas depuis que Fadest nous mets de la zik partout dans ses jeux l'univers a été ebranlé (LordKraken)

16

Salut,

moi j'aimerais bien pouvoir un jour pouvoir fournir un multitache coopératif dans MyAES multiapplication pour pouvoir tourner directement sous TOS (ce qui marche déjà mais avec une seule appli à la fois sans même d'accessoire).

Enfin bon là c'est sans doute un peu trop fou.

Olivier

17

Intéressant tout ça GT.
avatar
ATARI Belgique toujours actif

http://gfa-basic.forumactif.com/

18

OL (./16) :
Salut,

moi j'aimerais bien pouvoir un jour pouvoir fournir un multitache coopératif dans MyAES multiapplication pour pouvoir tourner directement sous TOS (ce qui marche déjà mais avec une seule appli à la fois sans même d'accessoire).

Enfin bon là c'est sans doute un peu trop fou.

Olivier


Un noyau 68000 multitâches je pourrais t'écrire, mais juste le noyau.

GT Multitaches
avatar
je sais pas depuis que Fadest nous mets de la zik partout dans ses jeux l'univers a été ebranlé (LordKraken)

19

GT Turbo (./18) :
OL (./16) :
Salut,

moi j'aimerais bien pouvoir un jour pouvoir fournir un multitache coopératif dans MyAES multiapplication pour pouvoir tourner directement sous TOS (ce qui marche déjà mais avec une seule appli à la fois sans même d'accessoire).

Enfin bon là c'est sans doute un peu trop fou.

Olivier


Un noyau 68000 multitâches je pourrais t'écrire, mais juste le noyau.

GT Multitaches


Ca serait très cool mais je pense que ce serait bien si cela permettait a tous d'appréhender le fonctionnement du 68K, j'ai déjà trouvé des sources de noyau mais tous sont en mode utilisateur alors que je suis en superviseur déjà dans un trap, tous font appel a une IT pour swapper les taches alors que là je ne cherche pas à faire un multitache préemptif mais coopératif (donc de ce point de vu c'est plus simple par contre le TOS est pas prévu pour mais pour cela j'ai quelques idées je devrais pouvoir progresser seul) et enfin c'est toujours à partir d'une liste de fonctions prédéfinies alors que j'aurais besoin d'un équivalent du fork et une routine de swap de processus tout cela appelable si possible à partir du C (mais sinon je pourrais toujours utiliser à partir de la routine ASM de gestion du trap il y a quand même quelques ligne d'assembleur dans MyAES!). Je pense que ce serait un tuto assez ardu, mais là c'est le genre de routine qu'aucun autre langage ne peut réaliser!
Olivier

20

Bon pour faire tenir un code utiliser en superviseur, il y a
avatar
je sais pas depuis que Fadest nous mets de la zik partout dans ses jeux l'univers a été ebranlé (LordKraken)

21

Bon si un modo pouvait effacer mon poste pas complet juste au dessus, car apparement je pense que Firefox délire un peu, merci smile

Faire tourner un code utilisateur en superviseur, a par la pile, je pense pas qu'il y ait de grand changements a faire.

Par contre pour le 'fork' je connais pas trop je viens de regarder sur le net mais bon. (Mon O.S. le plus utilisé est le TOS wink car Windows a chaque mise a jour, tu est pas sur que le PC rédemarre) et j'ai un train de retard sur les O.S. actuels. Donc si tu pouvais me donner quelques détails dessus.

Tu voudrais plutot faire tourner plusieurs taches dans un programme même ? Après pour un appel depuis le C, je suis nul dans ce langage, mais je pense pas qu'on est trop de problème pour l'interfacage, sinon on détourne un trap pour en faire une fonction système grin



GT octopus
avatar
je sais pas depuis que Fadest nous mets de la zik partout dans ses jeux l'univers a été ebranlé (LordKraken)

22

OL (./19) :
GT Turbo (./18) :
OL (./16) :
Salut,

moi j'aimerais bien pouvoir un jour pouvoir fournir un multitache coopératif dans MyAES multiapplication pour pouvoir tourner directement sous TOS (ce qui marche déjà mais avec une seule appli à la fois sans même d'accessoire).

Enfin bon là c'est sans doute un peu trop fou.

Olivier


Un noyau 68000 multitâches je pourrais t'écrire, mais juste le noyau.

GT Multitaches


Ca serait très cool mais je pense que ce serait bien si cela permettait a tous d'appréhender le fonctionnement du 68K, j'ai déjà trouvé des sources de noyau mais tous sont en mode utilisateur alors que je suis en superviseur déjà dans un trap, tous font appel a une IT pour swapper les taches alors que là je ne cherche pas à faire un multitache préemptif mais coopératif (donc de ce point de vu c'est plus simple par contre le TOS est pas prévu pour mais pour cela j'ai quelques idées je devrais pouvoir progresser seul) et enfin c'est toujours à partir d'une liste de fonctions prédéfinies alors que j'aurais besoin d'un équivalent du fork et une routine de swap de processus tout cela appelable si possible à partir du C (mais sinon je pourrais toujours utiliser à partir de la routine ASM de gestion du trap il y a quand même quelques ligne d'assembleur dans MyAES!). Je pense que ce serait un tuto assez ardu, mais là c'est le genre de routine qu'aucun autre langage ne peut réaliser!
Olivier


Peut-être que ma mémoire me fait défaut, mais dans mes souvenirs le TOS est bien multitâche coopératif, tu peux avoir une horloge en accéssoire qui tourne en même temps que l'application. Ce que le TOS/AES ne peut pas faire, c'est exécuter plusieurs applications principales. Mais peut-être que je me trompe, çà commence à remonter loin l'utilisation du ST triso


GT Turbo (./21) :
Faire tourner un code utilisateur en superviseur, a par la pile, je pense pas qu'il y ait de grand changements a faire.
[...]
Tu voudrais plutot faire tourner plusieurs taches dans un programme même ? Après pour un appel depuis le C, je suis nul dans ce langage, mais je pense pas qu'on est trop de problème pour l'interfacage, sinon on détourne un trap pour en faire une fonction système grin

GT octopus



Éviter les bugs, en superviseur çà pardonne pas grin

Il voudrait faire tourner plusieurs applis sous TOS, il a donc besoin d'un gestionnaire de tache ( création d'une tache au lancement d'un nouveau programme, un switcheur entre les taches quand l'AES le demande (multitâche coopératif), et un killeur de tache)


Comme pour le GFA, le C peut passer les paramètres par la Pile.


En tout cas bon courage GT, çà m'a l'air terriblement complexe à réaliser et si çà sert de tuto, je suivrais l'aventure oui

Il y a un article dans un ST mag qui parle d'un noyau multitache avec le code en listing, reste à savoir quel numéro...

23

GT Turbo (./21) :
Bon si un modo pouvait effacer mon poste pas complet juste au dessus, car apparement je pense que Firefox délire un peu, merci smile

Faire tourner un code utilisateur en superviseur, a par la pile, je pense pas qu'il y ait de grand changements a faire.

Par contre pour le 'fork' je connais pas trop je viens de regarder sur le net mais bon. (Mon O.S. le plus utilisé est le TOS wink car Windows a chaque mise a jour, tu est pas sur que le PC rédemarre) et j'ai un train de retard sur les O.S. actuels. Donc si tu pouvais me donner quelques détails dessus.

Tu voudrais plutot faire tourner plusieurs taches dans un programme même ? Après pour un appel depuis le C, je suis nul dans ce langage, mais je pense pas qu'on est trop de problème pour l'interfacage, sinon on détourne un trap pour en faire une fonction système grin



GT octopus


Salut GT,

Fork, c'est simple, c'est une fonction que tu appelles pour créer un nouveau processus, en retour tu as l'ID du processus fils qui a été créé pour le parent ou 0 pour le nouveau process
exemple

retour = fork()
si(retour!=0)
{
je suis dans le thread qui appelé le fork
}
sinon
{
je suis dans le nouveau processus!
}

en fait lors du nouveau processus je vais faire un Pexec() pour lancer un nouveau programme (c'est là que cela se gate avec le TOS surtout coté gestion mémoire mais je pense pouvoir n'en sortir), mais un accessoire déjà ce sera le premier pas parce que l'accessoire cela ne quitte jamais et c'est pour cela que cela marche avec le TOS!

En indiquant cela il va me falloir aussi une routine pour quitter le processus (typiquement après le Pexec() je pourais l'appeler)
et un routine pour connaitre l'ID du processus en cours (bon ca c'est simple!)

Olivier

24

25

OL (./23) :
Fork, c'est simple, c'est une fonction que tu appelles pour créer un nouveau processus
Euh, c'est plus complexe que ça quand même grin

Fork crée un clone du processus appelant (code, données en mémoire, fichiers ouverts etc.). Une fois créé, les deux processus conservent leur lien de parenté mais s'exécutent chacun de leur côté : chacun peut modifier ses variables sans affecter l'autre processus, etc.
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

26

Zerosquare (./25) :
OL (./23) :
Fork, c'est simple, c'est une fonction que tu appelles pour créer un nouveau processus
Euh, c'est plus complexe que ça quand même grin

Fork crée un clone du processus appelant (code, données en mémoire, fichiers ouverts etc.). Une fois créé, les deux processus conservent leur lien de parenté mais s'exécutent chacun de leur côté : chacun peut modifier ses variables sans affecter l'autre processus, etc.


J'en demande pas tant, cela ne me gêne nullement que les variables soient partagées bien au contraire, j'ai même besoin de tout confondre, donc c'est un peu plus simple! Les fichiers ouverts etc ca c'est dans le TOS on n'a pas besoin de s'en occuper sinon c'est réécrire Mint (moi je veux bien mais dans 10 ans on y est encore!), pour les accessoires pas de soucis pour plus j'aurais peut être appris assez en assembleur pour voir un peu plus loin!

Olivier

27

Alors c'est pas un fork ton truc ^^

Et partager les variables de deux processus indépendants, c'est quelque chose qui a de lourdes répercussions, c'est pas un choix technologique à faire à la légère.
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

28

Zerosquare (./27) :
Alors c'est pas un fork ton truc ^^

Et partager les variables de deux processus indépendants, c'est quelque chose qui a de lourdes répercussions, c'est pas un choix technologique à faire à la légère.


Ca serait plutôt un clone() effectivement qui s'appelerait comme un fork()!

La gestion des variables n'est pas un soucis du tout c'est déjà géré sinon MyAES ne pourrait pas tourner en multitache préemptif!

Olivier

29

Nalfus (./22) :
OL (./19) :
GT Turbo (./18) :
OL (./16) :
Salut,

moi j'aimerais bien pouvoir un jour pouvoir fournir un multitache coopératif dans MyAES multiapplication pour pouvoir tourner directement sous TOS (ce qui marche déjà mais avec une seule appli à la fois sans même d'accessoire).

Enfin bon là c'est sans doute un peu trop fou.

Olivier


Un noyau 68000 multitâches je pourrais t'écrire, mais juste le noyau.

GT Multitaches


Ca serait très cool mais je pense que ce serait bien si cela permettait a tous d'appréhender le fonctionnement du 68K, j'ai déjà trouvé des sources de noyau mais tous sont en mode utilisateur alors que je suis en superviseur déjà dans un trap, tous font appel a une IT pour swapper les taches alors que là je ne cherche pas à faire un multitache préemptif mais coopératif (donc de ce point de vu c'est plus simple par contre le TOS est pas prévu pour mais pour cela j'ai quelques idées je devrais pouvoir progresser seul) et enfin c'est toujours à partir d'une liste de fonctions prédéfinies alors que j'aurais besoin d'un équivalent du fork et une routine de swap de processus tout cela appelable si possible à partir du C (mais sinon je pourrais toujours utiliser à partir de la routine ASM de gestion du trap il y a quand même quelques ligne d'assembleur dans MyAES!). Je pense que ce serait un tuto assez ardu, mais là c'est le genre de routine qu'aucun autre langage ne peut réaliser!
Olivier


Peut-être que ma mémoire me fait défaut, mais dans mes souvenirs le TOS est bien multitâche coopératif, tu peux avoir une horloge en accéssoire qui tourne en même temps que l'application. Ce que le TOS/AES ne peut pas faire, c'est exécuter plusieurs applications principales. Mais peut-être que je me trompe, çà commence à remonter loin l'utilisation du ST triso


GT Turbo (./21) :
Faire tourner un code utilisateur en superviseur, a par la pile, je pense pas qu'il y ait de grand changements a faire.
[...]
Tu voudrais plutot faire tourner plusieurs taches dans un programme même ? Après pour un appel depuis le C, je suis nul dans ce langage, mais je pense pas qu'on est trop de problème pour l'interfacage, sinon on détourne un trap pour en faire une fonction système grin

GT octopus



Éviter les bugs, en superviseur çà pardonne pas grin

Il voudrait faire tourner plusieurs applis sous TOS, il a donc besoin d'un gestionnaire de tache ( création d'une tache au lancement d'un nouveau programme, un switcheur entre les taches quand l'AES le demande (multitâche coopératif), et un killeur de tache)


Comme pour le GFA, le C peut passer les paramètres par la Pile.


En tout cas bon courage GT, çà m'a l'air terriblement complexe à réaliser et si çà sert de tuto, je suivrais l'aventure oui

Il y a un article dans un ST mag qui parle d'un noyau multitache avec le code en listing, reste à savoir quel numéro...

Le TOS est rien du tout, le multitache est dans l'AES et comme je remplace l'AES...!

Olivier

30

Nalfus oui, tu peux avoir du 'vrai multitache' sur un ST, dans la gestion des evenements (AES) on a un evnt-timer qui permet d'appeller une routine toutes les x millisecondes.

après effectivement un accessoire est deja en mémoire et le reste, ce qui simplifie une partie du travail.

Pour le Pexec on peux le réecrire car en gros on a quoi comme probleme :

- la gestion de la ram
- la relocation du programme

Car en lancement d'un programme, le TOS reserve toute la ram dispo c'est au prog de rendre la ram non utilisé (Mshrinkl).

En gros réecrire un Pexec ne presente pas a premiere vue de probleme particulier.

J'ai juste un probleme, un lien entre un prog et son 'fils', mais concretement cela est representé comment ?

Si on tu le 'pere' faut aussi 'tuer' le fils je suppose ? Mais il y a que cela ?

Nalfus, merci pour les infos et les liens.

Pour infos un bug a GT en superviseur ou utilisateur ca change rien, ca crash quand même !!

Ca serait donc surtout le 'switch', car killer une tache, en gros, on la retire de notre liste des 'process' et on restitue la ram.

Donc est ce que cela pourrait se 'resumer' comme cela :

avoir un Pexec 'AES', qui permet de charger une application et renverrai un ID.

ensuite lancer ou 'switcher' a cette application avec une autre 'fonction AES'.

Vous m'excuserez si je parle a voix 'haute' mais cela me permet de mieux 'voir' et de poser le problême.

OL est ce que tu vois cela autrement ? Si oui pourrait tu donner ta vision plus 'physique' de la chose ?


GT smile
avatar
je sais pas depuis que Fadest nous mets de la zik partout dans ses jeux l'univers a été ebranlé (LordKraken)