Discussion:
Problème KBSHIFT en superviseur....
(trop ancien pour répondre)
Arachide
2020-01-04 11:17:32 UTC
Permalink
Coucou,

FreeMint semble bloquer la mise à jour de la variable KBSHIFT (celle qui
contient l'état des touches spéciales: Shift, Control, Alt, Caps Lock)
lorsqu'on est en superviseur.

J'ai donc écrit un petit programme TOS qui reste 10 secondes en mode
USER, vous pouvez alors actionner la touche CONTROL et son état doit
s'afficher à l'écran.

Puis le programme bascule pendant 10 secondes en mode superviseur et
affiche encore l'état de la touche CONTROL.

Sous TOS de base, pas de soucis, tout fonctionne.

Sous FreeMint, les touches ne sont plus détectées en mode superviseur!
Voilà pourquoi M_PLAYER ne peut plus arrêter en cours de Replay sous
FreeMint (car il utilise CONTROL pour sortir prématurément).

Sous FreeMint,, j'ai copié CONTROL.TOS sur C:\ et j'ajoute dans MINT.CNF
la ligne suivante:

exec C:\control.tos

(fatalement, car sous FreeMINT + un AES quelconque, les programmes TOS
sont redirigés avec des appels AES pour leur affichage. Et on sait que
l'AES reste muet en Superviseur. Donc je fais le test pendant la phase
de boot).

Voici ce que j'obtiens:

Loading Image...

Et rien ne se passe en superviseur malgré mes appuis frénétiques sur
CONTROL.

Voici le petit programme TOS à tester si certains peuvent confirmer
cette horrible fonctionnement qui perturbe mon M_PLAYER adoré :

https://gtello.pagesperso-orange.fr/temp/control.zip

Guillaume.
Francois LE COAT
2020-01-04 11:40:57 UTC
Permalink
Salut,
Post by Arachide
FreeMint semble bloquer la mise à jour de la variable KBSHIFT (celle qui
contient l'état des touches spéciales: Shift, Control, Alt, Caps Lock)
lorsqu'on est en superviseur.
J'ai donc écrit un petit programme TOS qui reste 10 secondes en mode
USER, vous pouvez alors actionner la touche CONTROL et son état doit
s'afficher à l'écran.
Puis le programme bascule pendant 10 secondes en mode superviseur et
affiche encore l'état de la touche CONTROL.
Sous TOS de base, pas de soucis, tout fonctionne.
Sous FreeMint, les touches ne sont plus détectées en mode superviseur!
Voilà pourquoi M_PLAYER ne peut plus arrêter en cours de Replay sous
FreeMint (car il utilise CONTROL pour sortir prématurément).
Sous FreeMint,, j'ai copié CONTROL.TOS sur C:\ et j'ajoute dans MINT.CNF
exec C:\control.tos
(fatalement, car sous FreeMINT + un AES quelconque, les programmes TOS
sont redirigés avec des appels AES pour leur affichage. Et on sait que
l'AES reste muet en Superviseur. Donc je fais le test pendant la phase
de boot).
https://gtello.pagesperso-orange.fr/temp/control.jpg
Et rien ne se passe en superviseur malgré mes appuis frénétiques sur
CONTROL.
Voici le petit programme TOS à tester si certains peuvent confirmer
https://gtello.pagesperso-orange.fr/temp/control.zip
Guillaume.
Avec le programme MPEG2dec, qui est un décodeur vidéo MPEG I/II,
j'utilise aussi la touche <CTRL> pour arrêter le décodage en boucle.
Je ne m'étais pas rendu compte du problème de KBSHIFT. Est-ce que ça
n'est pas causé par une version expérimentale de freeMiNT ? Parce que
j'utilise moi la version stable 1.18.0 ... Je vais tester ton soft ...
--
François LE COAT
Auteur de Eurêka 2.12 (Grapheur 2D, Modeleur 3D)
http://eureka.atari.org/
Arachide
2020-01-05 09:11:04 UTC
Permalink
Post by Francois LE COAT
Avec le programme MPEG2dec, qui est un décodeur vidéo MPEG I/II,
j'utilise aussi la touche <CTRL> pour arrêter le décodage en boucle.
Je ne m'étais pas rendu compte du problème de KBSHIFT. Est-ce que ça
n'est pas causé par une version expérimentale de freeMiNT ? Parce que
j'utilise moi la version stable 1.18.0 ... Je vais tester ton soft ...
J'avais déjà remarqué le soucis avec des Freemint plus anciens que le
1.19 installé actuellement.
Donc je pense que c'est récurrent.

Guillaume.
o***@lutece.net
2020-01-04 12:06:23 UTC
Permalink
Oups j'ai dérapé sur une touche!

Bonjour Guillaume

Malheureusement je pense que c'est une limitation de toujours de Mint (je pense que sous Magic ce n'est pas pareil).

Tel que je pense que cela se passer:

Mint n'ininterromp jamais un process en cours en superviseur, il n'y a que les IT qui tombent encore, et je pense que cette fonctionnalité hérité du TOS est émulée par Mint mais qu'il le fait quand il y a le temps et vu que tu ne lui laisse pas le temps cela ne se fait pas. Le multitâche de Mint reste assez limité par exemple on n'est pas sensé appeler gemdos d'une IT (le Bios ok) et même sur un signal pas question d'appeler GEMDOS!


Je ne vois que 3 solutions du plus simple au plus compliqué:
-De temps en en temps faire appel à la fonction gemdos Syield() qui donnera un instant la main à Mint et aux autre process, par exemple tous les 20ms voir plus et après tu peux contrôler ta variable (pour un multitâche fluide 10ms c'est très bien!).
-De temps en temps tu appelle event_multi() mais là cela va prendre sensiblement plus de temps ! :-(
-Ne plus être en superviseur ! Bon c'est plus compliqué et tu vas perdre en perf un peu c'est sur mais ça c'est cool pour le système.

Olivier
Post by Arachide
Coucou,
FreeMint semble bloquer la mise à jour de la variable KBSHIFT (celle qui
contient l'état des touches spéciales: Shift, Control, Alt, Caps Lock)
lorsqu'on est en superviseur.
J'ai donc écrit un petit programme TOS qui reste 10 secondes en mode
USER, vous pouvez alors actionner la touche CONTROL et son état doit
s'afficher à l'écran.
Puis le programme bascule pendant 10 secondes en mode superviseur et
affiche encore l'état de la touche CONTROL.
Sous TOS de base, pas de soucis, tout fonctionne.
Sous FreeMint, les touches ne sont plus détectées en mode superviseur!
Voilà pourquoi M_PLAYER ne peut plus arrêter en cours de Replay sous
FreeMint (car il utilise CONTROL pour sortir prématurément).
Sous FreeMint,, j'ai copié CONTROL.TOS sur C:\ et j'ajoute dans MINT.CNF
exec C:\control.tos
(fatalement, car sous FreeMINT + un AES quelconque, les programmes TOS
sont redirigés avec des appels AES pour leur affichage. Et on sait que
l'AES reste muet en Superviseur. Donc je fais le test pendant la phase
de boot).
https://gtello.pagesperso-orange.fr/temp/control.jpg
Et rien ne se passe en superviseur malgré mes appuis frénétiques sur
CONTROL.
Voici le petit programme TOS à tester si certains peuvent confirmer
https://gtello.pagesperso-orange.fr/temp/control.zip
Guillaume.
Francois LE COAT
2020-01-05 17:30:08 UTC
Permalink
Salut,
Post by o***@lutece.net
Malheureusement je pense que c'est une limitation de toujours de Mint (je pense que sous Magic ce n'est pas pareil).
J'ai un programme MPEG2dec qui teste la touche <CTRL> pour l'arrêt du
décodage vidéo MPEG I/II à l'écran, qui utilise "screen.ldg" pour
l'affichage, et ça ne pose aucun problème. Ça ne pose aucun problème
sous freeMiNT aussi bien que sous MagiC. Mais le soft qu'a proposé
Guillaume ne fonctionne pas bien avec freeMiNT 1.18.0. Je n'obtiens
pas vraiment le même affichage que celui dans la copie d'écran. En
fait, le programme est exécuté intégralement, et il n'affiche quelque
chose dans la console, qu'une fois qu'il est terminé. Donc il n'y a
pas d'effet démonstratif du passage en mode superviseur. Il ne faut
pas demander à freeMiNT de fonctionner normalement si une application
prend tous les droits, et que le fonctionnement en multitâche n'est
plus possible. Avec freeMiNT on n'a pas les mêmes libertés qu'avec le
TOS, du fait du fonctionnement en multitâche et multi-utilisateurs.
--
François LE COAT
Auteur de Eurêka 2.12 (Grapheur 2D, Modeleur 3D)
http://eureka.atari.org/
Arachide
2020-01-05 21:10:01 UTC
Permalink
Post by Francois LE COAT
Salut,
Post by o***@lutece.net
Malheureusement je pense que c'est une limitation de toujours de Mint
(je pense que sous Magic ce n'est pas pareil).
J'ai un programme MPEG2dec qui teste la touche <CTRL> pour l'arrêt du
décodage vidéo MPEG I/II à l'écran, qui utilise "screen.ldg" pour
l'affichage, et ça ne pose aucun problème. Ça ne pose aucun problème
sous freeMiNT aussi bien que sous MagiC. Mais le soft qu'a proposé
Guillaume ne fonctionne pas bien avec freeMiNT 1.18.0. Je n'obtiens
pas vraiment le même affichage que celui dans la copie d'écran. En
fait, le programme est exécuté intégralement, et il n'affiche quelque
chose dans la console, qu'une fois qu'il est terminé. Donc il n'y a
pas d'effet démonstratif du passage en mode superviseur. Il ne faut
pas demander à freeMiNT de fonctionner normalement si une application
prend tous les droits, et que le fonctionnement en multitâche n'est
plus possible. Avec freeMiNT on n'a pas les mêmes libertés qu'avec le
TOS, du fait du fonctionnement en multitâche et multi-utilisateurs.
Tout à fait!
Il faut l'exécuter pendant le boot de Mint en ajoutant à MINT.CNF une ligne:

exec C:\control.tos

C'est ce que j'ai dit dans mon premier message sur ce sujet.
Sinon, on passe sous le contrôle de l'AES pour les sorties TOS.

Guillaume.
o***@lutece.net
2020-01-06 17:44:05 UTC
Permalink
Post by Francois LE COAT
Salut,
Post by o***@lutece.net
Malheureusement je pense que c'est une limitation de toujours de Mint (je pense que sous Magic ce n'est pas pareil).
J'ai un programme MPEG2dec qui teste la touche <CTRL> pour l'arrêt du
décodage vidéo MPEG I/II à l'écran, qui utilise "screen.ldg" pour
l'affichage, et ça ne pose aucun problème. Ça ne pose aucun problème
sous freeMiNT aussi bien que sous MagiC. Mais le soft qu'a proposé
Guillaume ne fonctionne pas bien avec freeMiNT 1.18.0. Je n'obtiens
pas vraiment le même affichage que celui dans la copie d'écran. En
fait, le programme est exécuté intégralement, et il n'affiche quelque
chose dans la console, qu'une fois qu'il est terminé. Donc il n'y a
pas d'effet démonstratif du passage en mode superviseur. Il ne faut
pas demander à freeMiNT de fonctionner normalement si une application
prend tous les droits, et que le fonctionnement en multitâche n'est
plus possible. Avec freeMiNT on n'a pas les mêmes libertés qu'avec le
TOS, du fait du fonctionnement en multitâche et multi-utilisateurs.
--
François LE COAT
Auteur de Eurêka 2.12 (Grapheur 2D, Modeleur 3D)
http://eureka.atari.org/
Pourquoi tu réponds cela ? Ton Mpeg2dec est en mode utilisateur, il n'est pas en superviseur comme on l'a précisé. Je pense que Vincent à donné une réponse bien plus technique que je ne l'ai donné et qui confirme que sous Mint le clavier n'est pas géré, donc pas possible de gérer le clavier si l'application est toujours en superviseur sous Mint quelque version que ce soit (ce qui est assez peu habituel et recommandé). je me demande si le coup du Syield() fonctionne.

Ol
Francois LE COAT
2020-01-06 18:30:27 UTC
Permalink
Salut,
Post by o***@lutece.net
Post by Francois LE COAT
Post by o***@lutece.net
Malheureusement je pense que c'est une limitation de toujours de Mint (je pense que sous Magic ce n'est pas pareil).
J'ai un programme MPEG2dec qui teste la touche <CTRL> pour l'arrêt du
décodage vidéo MPEG I/II à l'écran, qui utilise "screen.ldg" pour
l'affichage, et ça ne pose aucun problème. Ça ne pose aucun problème
sous freeMiNT aussi bien que sous MagiC. Mais le soft qu'a proposé
Guillaume ne fonctionne pas bien avec freeMiNT 1.18.0. Je n'obtiens
pas vraiment le même affichage que celui dans la copie d'écran. En
fait, le programme est exécuté intégralement, et il n'affiche quelque
chose dans la console, qu'une fois qu'il est terminé. Donc il n'y a
pas d'effet démonstratif du passage en mode superviseur. Il ne faut
pas demander à freeMiNT de fonctionner normalement si une application
prend tous les droits, et que le fonctionnement en multitâche n'est
plus possible. Avec freeMiNT on n'a pas les mêmes libertés qu'avec le
TOS, du fait du fonctionnement en multitâche et multi-utilisateurs.
Pourquoi tu réponds cela ? Ton Mpeg2dec est en mode utilisateur, il n'est pas en superviseur comme on l'a précisé. Je pense que Vincent à donné une réponse bien plus technique que je ne l'ai donné et qui confirme que sous Mint le clavier n'est pas géré, donc pas possible de gérer le clavier si l'application est toujours en superviseur sous Mint quelque version que ce soit (ce qui est assez peu habituel et recommandé). je me demande si le coup du Syield() fonctionne.
Je réponds cela, parce que très souvent Olivier, tu as tendance à parler
de problèmes avec freeMiNT, avec ARAnyM etc. Mais le problème ne vient
pas de là, mais de la façon de programmer de Guillaume ... Pourquoi
faire un décodage vidéo entièrement en superviseur, en testant <CTRL>
pour quitter ? Si Guillaume procède de cette manière, son soft ne sera
pas compatible avec freeMiNT. Les libertés que l'on peut s'autoriser
sous TOS, ne sont pas recommandées avec freeMiNT. De même on ne peut pas
faire n'importe quoi avec ARAnyM. Mais ça ne sont pas des problèmes de
ces systèmes. C'est que le programmeur n'écrit pas de façon "clean".

Le mode superviseur, il vaut mieux se restreindre plutôt que de
l'utiliser inutilement. Le problème n'est pas une limitation de
freeMiNT, mais une méconnaissance du mode de fonctionnement d'un
ordinateur, qui n'offre pas toutes les libertés, surtout lorsqu'il
gère énormément de processus en parallèle, et éventuellement même
plusieurs utilisateurs.

Est-ce que tu te rappelles de Emmanuel, qui criait au bug de freeMiNT,
parce que son soft n'y avait jamais été compatible. En fait le problème
venait simplement d'un double appel à la fonction appl_init(). Ah c'est
certain que la plupart des jeux ne fonctionnent pas sous ARAnyM, et
encore moins freeMiNT. Mais ça n'est pas dû à des limitations de ceux-ci
mais au fait que les programmeurs écrivent n'importe quoi.

Alors, ça n'est pas dommage que l'on ne puisse pas tester l'état du
clavier en mode superviseur. La vraie réponse à faire est de savoir
pourquoi Guillaume veut passer en superviseur pour le décodage vidéo ?
S'il veut lancer son logiciel sous freeMiNT, ça n'est pas recommandé !
Et même s'il a une bonne raison, elle n'est vraiment pas admissible.
--
François LE COAT
Auteur de Eurêka 2.12 (Grapheur 2D, Modeleur 3D)
http://eureka.atari.org/
Arachide
2020-01-07 06:14:37 UTC
Permalink
Post by Francois LE COAT
Je réponds cela, parce que très souvent Olivier, tu as tendance à parler
de problèmes avec freeMiNT, avec ARAnyM etc. Mais le problème ne vient
pas de là, mais de la façon de programmer de Guillaume ... Pourquoi
faire un décodage vidéo entièrement en superviseur, en testant <CTRL>
pour quitter ?
Parce que c'est mon bon plaisir.
Et que c'est la manière optimale pour M_PLAYER sur un Atari physique.
Superviseur car j'ai besoin d'accéder à:
- $4BA (le compteur du Timer C pour la synchro)
- $FFFF8901 (l'état du son DMA pour savoir si c'est fini ou pas)

CONTROL car ce n'est qu'un seul bit à tester dans une variable.

Si j'étais en mode utilisateur:
- appel à XBIOS 38 pour chaque lecture du Timer
- appel à XBIOS 38 pour chaque lecture de l'état DMA
- appel à KBSHIFT() pour la lecture de l'état des touches spéciales

Je te garantis que trois appels système à chaque image et on perd
nettement en efficacité.
Tu en sais quelque chose avec la lenteur d'Euréka.
Post by Francois LE COAT
Le mode superviseur, [leçon sur le multitâche]
Est-ce que tu te rappelles de Emmanuel, [critique gratuite d'un programmeur]
Alors, ça n'est pas dommage que l'on ne puisse pas tester l'état du
clavier en mode superviseur. La vraie réponse à faire est de savoir
pourquoi Guillaume veut passer en superviseur pour le décodage vidéo ?
Question à poser avant de faire toutes tes critiques hautaines.
Post by Francois LE COAT
S'il veut lancer son logiciel sous freeMiNT, ça n'est pas recommandé !
Et même s'il a une bonne raison, elle n'est vraiment pas admissible.
Une bonne raison n'est pas admissible?
C'est vrai que ton logiciel est un modèle de programmation.
Publie les sources! Qu'on s'en inspire.

Guillaume.
Francois LE COAT
2020-01-07 11:18:16 UTC
Permalink
Salut,
Post by Arachide
- $4BA (le compteur du Timer C pour la synchro)
- $FFFF8901 (l'état du son DMA pour savoir si c'est fini ou pas)
Tout le monde fait la même chose, moi aussi, Didier Méquignon aussi, et
pourtant il n'est pas besoin de rester en mode superviseur. Tu as été
habitué à des machines ATARI lentes, où il fallait optimiser la moindre
instruction assembleur. Mais avec une machine ARAnyM sous freeMiNT, on
peut faire la même chose en mode utilisateur. Et il faut nécessairement
évoluer, car un superbe logiciel comme Aniplayer commence à ne plus
fonctionner correctement sur une machine rapide, et c'est un paradoxe !

Tu peux faire les tests en mode superviseur, et revenir de ce mode,
pour laisser la place au système freeMiNT, et aux autres applications.
La programmation d'une machine rapide ne pose pas les mêmes contraintes
que celles d'une machine rapide. Ça ne sont pas les mêmes optimisations.
--
François LE COAT
Auteur de Eurêka 2.12 (Grapheur 2D, Modeleur 3D)
http://eureka.atari.org/
Arachide
2020-01-07 13:49:41 UTC
Permalink
Post by Francois LE COAT
Salut,
Post by Arachide
- $4BA (le compteur du Timer C pour la synchro)
- $FFFF8901 (l'état du son DMA pour savoir si c'est fini ou pas)
Tout le monde fait la même chose, moi aussi, Didier Méquignon aussi, et
pourtant il n'est pas besoin de rester en mode superviseur.
Si!

Tu as été
Post by Francois LE COAT
habitué à des machines ATARI lentes, où il fallait optimiser la moindre
instruction assembleur.
C'est uniquement ce que j'ai. Des machines Atari.

Mais avec une machine ARAnyM sous freeMiNT, on
Post by Francois LE COAT
peut faire la même chose en mode utilisateur.
C'est un émulateur, pas une machine. Ca ne m'intéresse pas.

Et il faut nécessairement
Post by Francois LE COAT
évoluer, car un superbe logiciel comme Aniplayer commence à ne plus
fonctionner correctement sur une machine rapide, et c'est un paradoxe !
Tu peux faire les tests en mode superviseur, et revenir de ce mode,
pour laisser la place au système freeMiNT, et aux autres applications.
La programmation d'une machine rapide ne pose pas les mêmes contraintes
que celles d'une machine rapide. Ça ne sont pas les mêmes optimisations.
J'ai trouvé une parade. Il faut juste du temps pour modifier tout le
source, mais déjà l'AVI fonctionne en mode Utilisateur sans perte de temps.

Guillaume.
Simon
2020-01-07 16:39:52 UTC
Permalink
Post by Arachide
Tu as été habitué à des machines ATARI lentes, où il fallait
optimiser la moindre instruction assembleur.
C'est uniquement ce que j'ai. Des machines Atari.
Mais avec une machine ARAnyM sous freeMiNT, on peut faire la même
chose en mode utilisateur.
C'est un émulateur, pas une machine. Ca ne m'intéresse pas.
Heureusement qu'il reste des gens qui ont le souci (ou le goût)
d'optimiser pour toute les machines, et qui contrairement à
FLC n'ont pas basculé adepte de la pensée Microsoft selon laquelle peu
importe l'optimisation, le hard devra compenser.
Francois LE COAT
2020-01-07 17:30:06 UTC
Permalink
Salut,
Post by Simon
Post by Arachide
Tu as été habitué à des machines ATARI lentes, où il fallait
optimiser la moindre instruction assembleur.
C'est uniquement ce que j'ai. Des machines Atari.
Mais avec une machine ARAnyM sous freeMiNT, on peut faire la même
chose en mode utilisateur.
C'est un émulateur, pas une machine. Ca ne m'intéresse pas.
Heureusement qu'il reste des gens qui ont le souci (ou le goût)
d'optimiser pour toute les machines, et qui contrairement à
FLC n'ont pas basculé adepte de la pensée Microsoft selon laquelle peu
importe l'optimisation, le hard devra compenser.
N'empêche que les machines ATARI sont de plus en plus rapides. Et il
faut en tenir compte dans les optimisations, sinon on se retrouve
avec des softs qui marchent aux petits oignons sur les machines lentes,
et qui se mettent à dysfonctionner sur les machines rapides. J'essaye
moi de faire des softs qui sont corrects sur toutes les machines,
mais c'est un exercice difficile. Sur un 520ST d'il y a 35 ans on
voit se tracer la fonction, alors que sur une machine actuelle on
ne voit pas le tracé, qui se fait en un éclair. De cette manière on
peut comprendre que l'on a affaire à un ordinateur de course. Et
heureusement que depuis 35 ans, il y a eu des progrès spectaculaires !

C'est normal de pouvoir constater les améliorations techniques du
matériel. Et Guillaume a bien compris cela, parce qu'il a trouvé une
solution. C'est ce qui garanti la pérennité des logiciels dans le temps.
J'ai un logiciel ATARI qui fonctionne aussi bien sur un 520ST de 1985,
que sur les MegaST, Falcon030, TT030, Hadès060 et enfin ARAnyM, quel
que soit le TOS, EmuTOS, freeMiNT, les AES, les cartes graphiques etc.

Bon, enfin personne ne m'a jamais dit que ça ne marche pas. On m'a
fait des remarques sur la lenteur, l'interface graphique très fruste.
Mais personne ne s'est plaint d'un plantage quelconque. J'y veille !

ATARIstiquement vôtre =)
--
François LE COAT
Auteur de Eurêka 2.12 (Grapheur 2D, Modeleur 3D)
http://eureka.atari.org/
Arachide
2020-01-07 17:50:40 UTC
Permalink
Post by Francois LE COAT
N'empêche que les machines ATARI sont de plus en plus rapides.
Non, les machines Atari sont les mêmes qu'avant. Falcon, TT, STE...
Les émulateurs sont rapides car les PC qui les font tourner sont rapides.
Post by Francois LE COAT
Et il
faut en tenir compte dans les optimisations, sinon on se retrouve
avec des softs qui marchent aux petits oignons sur les machines lentes,
et qui se mettent à dysfonctionner sur les machines rapides.
Mon problème n'est pas une question de vitesse en soi. C'est juste que
FreeMint ne fonctionne plus comme le TOS pour la gestion du clavier.

Et puisque tu te moques de ma "méconnaissance du mode de fonctionnement d'un
ordinateur, qui n'offre pas toutes les libertés, surtout lorsqu'il
gère énormément de processus en parallèle, et éventuellement même
plusieurs utilisateurs." (citation textuelle) pourrais-tu me donner le
lien vers la doc de Freemint qui spécifie que le clavier n'est plus géré
en superviseur ?
Je pourrais mettre ça dans mes favoris.

Car vu ta réaction, je pense que toi, tu le savais depuis longtemps que
le clavier était bloqué en superviseur sous FreeMint.


Guillaume.
Francois LE COAT
2020-01-07 18:39:25 UTC
Permalink
Salut,
Post by Arachide
Post by Francois LE COAT
N'empêche que les machines ATARI sont de plus en plus rapides.
Non, les machines Atari sont les mêmes qu'avant. Falcon, TT, STE...
Les émulateurs sont rapides car les PC qui les font tourner sont rapides.
Post by Francois LE COAT
Et il
faut en tenir compte dans les optimisations, sinon on se retrouve
avec des softs qui marchent aux petits oignons sur les machines lentes,
et qui se mettent à dysfonctionner sur les machines rapides.
Mon problème n'est pas une question de vitesse en soi. C'est juste que
FreeMint ne fonctionne plus comme le TOS pour la gestion du clavier.
Et puisque tu te moques de ma "méconnaissance du mode de fonctionnement d'un
ordinateur, qui n'offre pas toutes les libertés, surtout lorsqu'il
gère énormément de processus en parallèle, et éventuellement même
plusieurs utilisateurs." (citation textuelle) pourrais-tu me donner le
lien vers la doc de Freemint qui spécifie que le clavier n'est plus géré
en superviseur ?
Je pourrais mettre ça dans mes favoris.
Car vu ta réaction, je pense que toi, tu le savais depuis longtemps que
le clavier était bloqué en superviseur sous FreeMint.
Tu remarqueras que je ne t'ai pas répondu directement sur la gestion du
clavier en mode superviseur, ce que je n'ai pas testé, mais sur la
monopolisation des ressources, par un usage abusif du mode superviseur.

Je sais depuis toujours, que si l'on abuse de l'usage du superviseur,
le système risque de dysfonctionner. D'ailleurs en mode superviseur,
il y a une pile très courte, et beaucoup de chances de planter la
machine ATARI. Je n'ai lu ça dans aucune documentation, c'est du bon
sens. C'est pourquoi je ne passe en superviseur qu'exceptionnellement,
et j'en sort le plus rapidement possible.

N'importe quel logiciel, même très ancien, doit pouvoir fonctionner
aussi bien sous TOS, que sous freeMiNT, pourvu qu'il ne soit pas
trop mal écrit. freeMiNT a été conçu pour cela, pour faire fonctionner
toutes les applications ATARI. Ça n'est pas très difficile d'écrire un
soft qui soit compatible avec freeMiNT. Mais il a des règles de bon
sens à respecter. L'usage modéré du superviseur fait partie des règles.

Bon, après cela, sous freeMiNT il y a des astuces pour adapter le
fonctionnement en multitâche. J'ai pris la liberté d'occuper tout
l'écran, parce que j'estime que l'affichage des courbes en vaut la
peine. Mais en même temps, j'ai rendu mes boites de dialogue non-
péhemptives, parce que c'est plus sympa de ne pas bloquer tout le
fonctionnement à l'écran, lorsque mon logiciel dialogue avec
l'utilisateur. Mais je n'ai fait que très peu de concessions au
fonctionnement en multitâche. Normalement en respectant des
règles de bon sens, n'importe quel logiciel devrait fonctionner !

Les gens qui développent encore freeMiNT devraient y veiller =)
--
François LE COAT
Auteur de Eurêka 2.12 (Grapheur 2D, Modeleur 3D)
http://eureka.atari.org/
Arachide
2020-01-07 18:48:56 UTC
Permalink
Post by Francois LE COAT
Tu remarqueras que je ne t'ai pas répondu directement sur la gestion du
clavier en mode superviseur, ce que je n'ai pas testé, mais sur la
monopolisation des ressources, par un usage abusif du mode superviseur.
Le superviseur monopolise des ressources? lesquelles?
Il donne juste accès aux zones mémoire protégées et à certaines
instructions privilégiées.
Post by Francois LE COAT
Je sais depuis toujours, que si l'on abuse de l'usage du superviseur,
le système risque de dysfonctionner. D'ailleurs en mode superviseur,
il y a une pile très courte, et beaucoup de chances de planter la
machine ATARI.
Quelle pile?
Et puis M_PLAYER ne fait pas d'appels système pendant qu'il est en
superviseur, donc il ne risque pas de le planter. D'ailleurs M_Player ne
plante pas sous FreeMint.


Guillaume.
Francois LE COAT
2020-01-07 19:15:03 UTC
Permalink
Salut,
Post by Arachide
Post by Francois LE COAT
Tu remarqueras que je ne t'ai pas répondu directement sur la gestion du
clavier en mode superviseur, ce que je n'ai pas testé, mais sur la
monopolisation des ressources, par un usage abusif du mode superviseur.
Le superviseur monopolise des ressources? lesquelles?
Il donne juste accès aux zones mémoire protégées et à certaines
instructions privilégiées.
Post by Francois LE COAT
Je sais depuis toujours, que si l'on abuse de l'usage du superviseur,
le système risque de dysfonctionner. D'ailleurs en mode superviseur,
il y a une pile très courte, et beaucoup de chances de planter la
machine ATARI.
Quelle pile?
Et puis M_PLAYER ne fait pas d'appels système pendant qu'il est en
superviseur, donc il ne risque pas de le planter. D'ailleurs M_Player ne
plante pas sous FreeMint.
Guillaume.
freeMiNT utilise le mode superviseur pour créer l’ordonnancement des
tâches, pour répartir le partage du temps CPU entre les applications.

Lorsque tu passes en mode superviseur, le pointeur de pile (SP) change
d'adresse, vers une zone mémoire bien moins grande que la pile
utilisateur. Lorsque tu passes en mode superviseur, le pointeur de
pile a toutes les chances d'atteindre une zone mémoire non-autorisée.
A chaque appel à une fonction, il y a un empilement des paramètres,
et la pile superviseur, qui n'est pas celle de l'utilisateur, risque
de dépasser la zone allouée. C'est une cause de plantage assurée.

Ce qui fait que lorsque tu monopolises le mode superviseur non seulement
le multitâche ne fonctionne plus normalement, mais en plus la taille de
la pile superviseur peut être dépassée rapidement, et la machine ATARI
plante ou devient instable.

Donc, pour que le logiciel ATARI fonctionne sous freeMiNT, il faut
faire un usage très parcimonieux du mode de fonctionnement superviseur.
--
François LE COAT
Auteur de Eurêka 2.12 (Grapheur 2D, Modeleur 3D)
http://eureka.atari.org/
Arachide
2020-01-07 19:52:11 UTC
Permalink
Post by Francois LE COAT
Lorsque tu passes en mode superviseur, le pointeur de pile (SP) change
d'adresse, vers une zone mémoire bien moins grande que la pile
utilisateur. Lorsque tu passes en mode superviseur, le pointeur de
pile a toutes les chances d'atteindre une zone mémoire non-autorisée.
A chaque appel à une fonction, il y a un empilement des paramètres,
Oui mais comme je te disais, M_PLAYER ne fait aucun appel système
pendant qu'il est en Superviseur.
Et si M_PLAYER est en superviseur, les autres applications (en
multitaches) restent en utilisateur, donc pas de danger.

Mais tu disais que ça monopolise des ressources..?
Francois LE COAT
2020-01-07 20:12:02 UTC
Permalink
Salut,
Post by Arachide
Post by Francois LE COAT
Lorsque tu passes en mode superviseur, le pointeur de pile (SP) change
d'adresse, vers une zone mémoire bien moins grande que la pile
utilisateur. Lorsque tu passes en mode superviseur, le pointeur de
pile a toutes les chances d'atteindre une zone mémoire non-autorisée.
A chaque appel à une fonction, il y a un empilement des paramètres,
Oui mais comme je te disais, M_PLAYER ne fait aucun appel système
pendant qu'il est en Superviseur.
N'importe quel appel à une fonction, pas seulement une fonction système,
fait usage de la pile. Autant la pile utilisateur est grande, et
paramétrable pour chaque application. Autant la pile superviseur est
petite, paramétrée une fois pour toute par freeMiNT. Donc c'est une
mauvaise idée de fonctionner en mode superviseur. Qu'on se le dise.
Post by Arachide
Et si M_PLAYER est en superviseur, les autres applications (en
multitaches) restent en utilisateur, donc pas de danger.
Si.
Post by Arachide
Mais tu disais que ça monopolise des ressources..?
La ressource CPU en particulier. L'ordonnancement des tâches ne se
fait plus, et tu monopolises le temps CPU de manière dangereuse pour
l'intégrité du fonctionnement du système freeMiNT.

Je le répète, l'usage du mode superviseur est à minimiser absolument.
Tu ne vois peut-être aucun effet immédiat, mais l'usage de ce genre
d'applications non fiables sera à bannir, par respect pour les autres.
--
François LE COAT
Auteur de Eurêka 2.12 (Grapheur 2D, Modeleur 3D)
http://eureka.atari.org/
o***@lutece.net
2020-01-07 20:23:55 UTC
Permalink
Post by Francois LE COAT
Salut,
Post by Arachide
Post by Francois LE COAT
Lorsque tu passes en mode superviseur, le pointeur de pile (SP) change
d'adresse, vers une zone mémoire bien moins grande que la pile
utilisateur. Lorsque tu passes en mode superviseur, le pointeur de
pile a toutes les chances d'atteindre une zone mémoire non-autorisée.
A chaque appel à une fonction, il y a un empilement des paramètres,
Oui mais comme je te disais, M_PLAYER ne fait aucun appel système
pendant qu'il est en Superviseur.
N'importe quel appel à une fonction, pas seulement une fonction système,
fait usage de la pile. Autant la pile utilisateur est grande, et
paramétrable pour chaque application. Autant la pile superviseur est
petite, paramétrée une fois pour toute par freeMiNT. Donc c'est une
mauvaise idée de fonctionner en mode superviseur. Qu'on se le dise.
Bah non qu'on ne se le dise pas, c'est faux, n'importe quel programme peut modifier sa pile superviseur et mettre ce dont il a besoin, Guillaume vu son niveau en assembleur te le fait en 1 minute. MyAES modifie la pile immédiatement pour son besoin sinon cela planterait lamentablement.
Post by Francois LE COAT
Post by Arachide
Et si M_PLAYER est en superviseur, les autres applications (en
multitaches) restent en utilisateur, donc pas de danger.
Si.
Post by Arachide
Mais tu disais que ça monopolise des ressources..?
La ressource CPU en particulier. L'ordonnancement des tâches ne se
fait plus, et tu monopolises le temps CPU de manière dangereuse pour
l'intégrité du fonctionnement du système freeMiNT.
C'est que ce n'est pas cool pour freemint et c'est vrai que de passer son temps à passer en superviseur pour lire le timer 200hz cela fini par prendre beaucoup de temps. Ceci dit je ne suis pas sur que cela se passe comme cela sous Magic!
Post by Francois LE COAT
Je le répète, l'usage du mode superviseur est à minimiser absolument.
Tu ne vois peut-être aucun effet immédiat, mais l'usage de ce genre
d'applications non fiables sera à bannir, par respect pour les autres.
Oui et non, tu es assez mal placé pour dire cela avec Eureka, vu que toi si ce n'est pas le système que tu monopolises mais l'écran alors est ce plus sympa dans le principe, sans doute pour le système mais pour les autres applications le résultat est le même.

OL
Francois LE COAT
2020-01-07 20:41:34 UTC
Permalink
Salut,
Post by o***@lutece.net
Post by Francois LE COAT
Post by Arachide
Post by Francois LE COAT
Lorsque tu passes en mode superviseur, le pointeur de pile (SP) change
d'adresse, vers une zone mémoire bien moins grande que la pile
utilisateur. Lorsque tu passes en mode superviseur, le pointeur de
pile a toutes les chances d'atteindre une zone mémoire non-autorisée.
A chaque appel à une fonction, il y a un empilement des paramètres,
Oui mais comme je te disais, M_PLAYER ne fait aucun appel système
pendant qu'il est en Superviseur.
N'importe quel appel à une fonction, pas seulement une fonction système,
fait usage de la pile. Autant la pile utilisateur est grande, et
paramétrable pour chaque application. Autant la pile superviseur est
petite, paramétrée une fois pour toute par freeMiNT. Donc c'est une
mauvaise idée de fonctionner en mode superviseur. Qu'on se le dise.
Bah non qu'on ne se le dise pas, c'est faux, n'importe quel programme peut modifier sa pile superviseur et mettre ce dont il a besoin, Guillaume vu son niveau en assembleur te le fait en 1 minute. MyAES modifie la pile immédiatement pour son besoin sinon cela planterait lamentablement.
Post by Francois LE COAT
Post by Arachide
Et si M_PLAYER est en superviseur, les autres applications (en
multitaches) restent en utilisateur, donc pas de danger.
Si.
Post by Arachide
Mais tu disais que ça monopolise des ressources..?
La ressource CPU en particulier. L'ordonnancement des tâches ne se
fait plus, et tu monopolises le temps CPU de manière dangereuse pour
l'intégrité du fonctionnement du système freeMiNT.
C'est que ce n'est pas cool pour freemint et c'est vrai que de passer son temps à passer en superviseur pour lire le timer 200hz cela fini par prendre beaucoup de temps. Ceci dit je ne suis pas sur que cela se passe comme cela sous Magic!
Post by Francois LE COAT
Je le répète, l'usage du mode superviseur est à minimiser absolument.
Tu ne vois peut-être aucun effet immédiat, mais l'usage de ce genre
d'applications non fiables sera à bannir, par respect pour les autres.
Oui et non, tu es assez mal placé pour dire cela avec Eureka, vu que toi si ce n'est pas le système que tu monopolises mais l'écran alors est ce plus sympa dans le principe, sans doute pour le système mais pour les autres applications le résultat est le même.
Le problème pour toi Olivier, comme pour Guillaume, est que vous êtes
des autodidactes. Personne ne vous a appris à programmer, et vous
découvrez les problèmes au fur et à mesure qu'ils se présentent.

Tu ne connais pas macOS, qui depuis un certain nombre de versions
autorise les applications à fonctionner en plein écran, par
simplicité. Et moi, si j'utilise tout l'écran, c'est parce que
c'était autorisé avec le TOS, et que ça le reste avec freeMiNT.

Maintenant, tu dis cela, car tu as une dent contre moi, et contre
Eurêka 2.12, pour des raisons que je ne me suis jamais expliquées.
Tu as donc un avis négatif à propos de tout ce que je fais, qui
n'a rien à voir avec un avis objectif. Cela explique aussi que toi
comme un certain nombre de gens ici s'en prennent à moi, de manière
tout à fait inconvenante, et pas justifiable, si ce n'est pour harceler.

Lorsque je dis quelque chose, c'est bien souvent parce que je l'ai
appris, et pas seulement par moi-même, comme toi Olivier et Guillaume.

ATARIstiquement vôtre =)
--
François LE COAT
Auteur de Eurêka 2.12 (Grapheur 2D, Modeleur 3D)
http://eureka.atari.org/
o***@lutece.net
2020-01-07 22:27:43 UTC
Permalink
Post by Francois LE COAT
Post by o***@lutece.net
Oui et non, tu es assez mal placé pour dire cela avec Eureka, vu que toi si ce n'est pas le système que tu monopolises mais l'écran alors est ce plus sympa dans le principe, sans doute pour le système mais pour les autres applications le résultat est le même.
Le problème pour toi Olivier, comme pour Guillaume, est que vous êtes
des autodidactes. Personne ne vous a appris à programmer, et vous
découvrez les problèmes au fur et à mesure qu'ils se présentent.
Le problème pour toi François, c'est tu es extrèmement imbu de ta personne et
que tu traites les autres comme de la merde en te prétendant supérieur à tout le
monde. Tu réponds a tout et à 99% à côté de la question en essayant de faire
croire que tu as un grand coeur alors que ce n'est que pour rabaisser les
autres. Alors faut pas pleurer lorsque l'on t'en mets une tu ne la ramenerait
pas tout le temps cela n'arriverait pas.

Qu'est ce que tu sais de ce que j'ai appris ou pas ? J'ai probablement appris
autant que toi parce que de mémoire tu n'as pas une formation en informatique,
alors on a du en faire à peu près autant à l'université, j'en ai même sans doute
fait un peu plus. Je te dirais aussi que j'ai au cours de ma carrière réalisé
sans doute largement plus d'application industrielles que tu n'en feras jamais.
Et même si je suis un autodidacte comme tu le dis et pour ce qui est du système
c'est vrai que c'est plutôt le cas, c'est mieux que de ne rien y connaitre que
par des on dit comme toi, et même si pour une fois je n'étais pas complètement
en désaccord de principe avec toi sur l'utilisation abusive du superviseur j'ai
eu il y a bien longtemps une discussion avec Guillaume sur le sujet qui est
resté amicale. Si le mode superviseur pose soucis à freemint, c'est que freemint
est limité, ce n'est pas si catastrophique que cela, moi en tant que système
cela me fait suer j'ai passé des années à rendre l'AES le plus multitâche
possible, comme Eureka fait suer à monopoliser l'écran de manière violente comme
il fait et raconter que MacOS permet le plein écran, je ne suis pas idiot,
Windows aussi et avec un peu d'imagination sous GEM non plus et il suffit de
voir ma petite video de MyAES 0.97 pour voir que Doom en version GEM peut passer
en plein écran et être tout à fait à l'aise avec les autres applications sans
rien mobiliser du tout, donc ton baratin c'est juste pour masquer que tu ne sais
tout bonnement pas faire.
Post by Francois LE COAT
Tu ne connais pas macOS, qui depuis un certain nombre de versions
autorise les applications à fonctionner en plein écran, par
simplicité. Et moi, si j'utilise tout l'écran, c'est parce que
c'était autorisé avec le TOS, et que ça le reste avec freeMiNT.
freemint n'a rien à voir avec cela cela n'a à voir qu'avec l'AES.
Post by Francois LE COAT
Maintenant, tu dis cela, car tu as une dent contre moi, et contre
Eurêka 2.12, pour des raisons que je ne me suis jamais expliquées.
Tu as donc un avis négatif à propos de tout ce que je fais, qui
n'a rien à voir avec un avis objectif. Cela explique aussi que toi
comme un certain nombre de gens ici s'en prennent à moi, de manière
tout à fait inconvenante, et pas justifiable, si ce n'est pour harceler.
C'est toi qui harcèle à tout bout de champs et fait déraper les messages, c'est
toi qui écrit plus de la moitié des messages de ce groupe à rabaisser tout le
monde de ta supériorité de pacotille.
Post by Francois LE COAT
Lorsque je dis quelque chose, c'est bien souvent parce que je l'ai
appris, et pas seulement par moi-même, comme toi Olivier et Guillaume.
Tu as tout appris de travers et retenu des trucs super basique, parce que si
l'on revient sur le sujet, la pile superviseur du système est effectivement très
petite mais ce que tu n'as pas compris c'est qu'une application pouvait sans
difficulté modifier cette pile donc si la pile est trop petite il est très
simple pour qui sait faire un peu d'assembleur 68000 de la corriger (un
architecte electro informaticien avec 10 Atari à la maison et 40 ans
d'expérience devrait savoir cela).

Travailler en superviseur n'est pas quelque chose de recommandé et cela pose
soucis à freemint il est vrai je n'ai rien à redire à cela, mais en profiter
pour rabaisser Guillaume au lieu de donner une explication technique plutôt
qu'un truc que tu as lu dans un bouquin un jours qui ne fait en rien avancer le
problème, et pour ta gouverne sur les machines Atari dans 90% du temps au moins
le processeur est en superviseur si tu ne l'avais pas compris, c'est sans doute
plus un problème qu'une bonne solution mais le système a été fait ainsi, pour la
simple et bonne raison que l'immense majorité du temps les applications GEM
attendent dans l'AES et donc en superviseur, c'est quand même cocasse comme
situation. En fait ce n'est pas bien pire d'être en superviseur que de réserver
violemment l'écran comme tu le fais, c'est juste un gros problème parce que mint
est par sa conception limité sur ce point.

Maintenant je vais revenir sur le côté autodidacte qui en son temps ta bien
servi il me semble, alors je vais raconter l'histoire de comment j'ai fait ta
connaissance et ce que j'ai fait à cette époque pour toi.

Il fut un jours sur FCSA un certain FLC a posté son habituel à l'époque pub pour
Eureka dont déjà il se vantait qu'il tournait sur toutes les machines et système
possibles. J'ai eu un jours la curiosité de tester à l'époque sur mon MacIISi et
le superbe MagicMac, bien sur ce qui devait arriver est arrivé, Eureka planté au
demarrage, même pas le temps de voir le menu (je ment?), je ne vais pas jeter la
pierre mes propres développements fonctionnaient de travers lorsque je suis
passé sous MagicMac, je n'avais jamais eu qu'un ST sous TOS avant!

J'ai donc contacté l'auteur de ce merveilleux soft que je voulais voir tourner
sur ma machine, je n'ai pas eu de réponse à l'époque, puis environ 1an et demi
plus tard j'ai renvoyé à nouveau un message et j'ai eu une réponse, tu avais
envi à l'époque de progresser, on a donc discuté où était le plantage, bien sur
tu ne comprenais pas pourquoi, je ne sais plus qui des 2 a eu l'idée qu'il ne
fallait peut être pas dessiner directement à l'écran (je pense que c'est moi
mais je n'en suis pas sur) mais déjà tu n'étais pas de ceux qui font beaucoup
d'effort c'est sûr c'est mieux quand les autres travaillent pour toi, ceci dit
moi le sujet me plaisait bien et donc j'ai créé un petit test pour vérifier si
l'accès écran était possible ou pas, la réponse a été rapide c'était le
problème, ensuite tu as corrigé ton soft et globalement Eureka a fonctionné
correctement. Je me demande vraiment pourquoi à l'époque, toi qui a tout lu, tu
as put laisser passer cela et curieusement c'est bien en prenant un problème
après l'autre et en expérimentant que l'on progresse, car on se rend compte avec
l'age que pas grand chose de nos croyances ne tiennent avec le temps et surtout
dans ce que créé l'Homme. Refuser ce principe c'est comme être congelé, être
incapable de progresser, ne servir à rien alors cela ne me gène pas que tu me
traites d'autodidacte c'est plutôt de mon point de vu un très beau compliment
même si dans ta bouche c'est extrêmement péjoratif.


OL
Francois LE COAT
2020-01-07 22:53:16 UTC
Permalink
Salut,
Post by o***@lutece.net
alors cela ne me gène pas que tu me
traites d'autodidacte c'est plutôt de mon point de vu un très beau compliment
même si dans ta bouche c'est extrêmement péjoratif.
Pas exactement. Jack Tramiel était un autodidacte parfait et pourtant ...



Mais il me semble que l'on apprend plus grand chose d'un Motorola 68k ?

ATARIstiquement vôtre =)
--
François LE COAT
Auteur de Eurêka 2.12 (Grapheur 2D, Modeleur 3D)
http://eureka.atari.org/
Simon
2020-01-08 15:49:14 UTC
Permalink
Post by o***@lutece.net
Le problème pour toi François, c'est tu es extrèmement imbu de ta personne et
que tu traites les autres comme de la merde en te prétendant supérieur à tout le
monde. Tu réponds a tout et à 99% à côté de la question en essayant de faire
croire que tu as un grand coeur alors que ce n'est que pour rabaisser les
autres.
Dans le monde, il y a les positifs qui sortent du lot par leur
motivation et leur capacité à produire des choses, et les nuisibles
incapables qui s'imaginent qu'il vont faire illusion s'ils réussissent à
rabaisser tous les autres.

On voit tout de suite où se situe FLC, après 35 ans sur Atari:
- un seul soft
- des milliers de messages depuis 20 ans pour cracher sur tous les
développeurs
pehache
2020-01-11 13:33:27 UTC
Permalink
Post by Francois LE COAT
Le problème pour toi Olivier, comme pour Guillaume, est que vous êtes
des autodidactes. Personne ne vous a appris à programmer, et vous
découvrez les problèmes au fur et à mesure qu'ils se présentent.
Tu ne connais pas macOS, qui depuis un certain nombre de versions
autorise les applications à fonctionner en plein écran, par
simplicité. Et moi, si j'utilise tout l'écran, c'est parce que
c'était autorisé avec le TOS, et que ça le reste avec freeMiNT.
Et toi tu profites du fait que les gens ici ne connaissent pas forcément
macOS pour essayer de les enfumer.

macOS autorise depuis toujours les applis à passer en plein écran, sauf
qu'à part les jeux (pour des raisons évidentes) très peu d'applis le
faisaient.

Ce qui a été introduit depuis quelques versions c'est la *possibilité*
de mettre n'importe quelle appli en plein écran. Mais c'est un choix
*offert* à l'utilisateur, on ne lui impose rien : il peut passer du mode
plein écran au mode fenêtré à loisir.

Sur un interface nativement multifenêtrée, imposer à l'utilisateur un
passage en plein écran comme tu le fais est une grossièreté sans nom.
Post by Francois LE COAT
Maintenant, tu dis cela, car tu as une dent contre moi, et contre
Eurêka 2.12, pour des raisons que je ne me suis jamais expliquées.
Tu as donc un avis négatif à propos de tout ce que je fais, qui
n'a rien à voir avec un avis objectif. Cela explique aussi que toi
comme un certain nombre de gens ici s'en prennent à moi, de manière
tout à fait inconvenante, et pas justifiable, si ce n'est pour harceler.
Lorsque je dis quelque chose, c'est bien souvent parce que je l'ai
appris, et pas seulement par moi-même, comme toi Olivier et Guillaume.
Vu le nombre de conneries que tu profères en permanence, tu as
visiblement du mal avec l'apprentissage.
--
"...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
même sens que les tiennes.", ST sur fr.bio.medecine
Arachide
2020-01-08 12:27:51 UTC
Permalink
Post by Francois LE COAT
Post by Arachide
Oui mais comme je te disais, M_PLAYER ne fait aucun appel système
pendant qu'il est en Superviseur.
N'importe quel appel à une fonction, pas seulement une fonction système,
fait usage de la pile. Autant la pile utilisateur est grande, et
paramétrable pour chaque application. Autant la pile superviseur est
petite, paramétrée une fois pour toute par freeMiNT. Donc c'est une
mauvaise idée de fonctionner en mode superviseur. Qu'on se le dise.
Quelle MECONNAISSANCE du fonctionnement d'un ordinateur !
Tu m'étonnes que tu ne sois pas autodidacte, tu répètes bêtement sans
comprendre et sans essayer.

Quand mon programme passe en superviseur, il travaille toujours sur sa
propre pile. Mon pointeur A7 ou (SP) est toujours le même. De ce fait,
dans mes fonctions internes à M_PLAYER, je n'ai aucune soucis de
dépassement de pile, en tout cas pas plus qu'en mode Utilisateur.

Petite preuve, j'ai écrit un programme qui affiche sa BasePage et son
pointeur de pile SP dans les deux modes différents... et c'est
exactement la même valeur !

Loading Image...

Comment peut-on à ce point méconnaître le fonctionnement d'un
ordinateur, et en particulier en multitâches..?

Je suis effaré !

Guillaume.
Francois LE COAT
2020-01-08 18:01:06 UTC
Permalink
Salut,
Post by Arachide
Post by Francois LE COAT
Post by Arachide
Oui mais comme je te disais, M_PLAYER ne fait aucun appel système
pendant qu'il est en Superviseur.
N'importe quel appel à une fonction, pas seulement une fonction système,
fait usage de la pile. Autant la pile utilisateur est grande, et
paramétrable pour chaque application. Autant la pile superviseur est
petite, paramétrée une fois pour toute par freeMiNT. Donc c'est une
mauvaise idée de fonctionner en mode superviseur. Qu'on se le dise.
Quand mon programme passe en superviseur, il travaille toujours sur sa
propre pile. Mon pointeur A7 ou (SP) est toujours le même. De ce fait,
dans mes fonctions internes à M_PLAYER, je n'ai aucune soucis de
dépassement de pile, en tout cas pas plus qu'en mode Utilisateur.
Petite preuve, j'ai écrit un programme qui affiche sa BasePage et son
pointeur de pile SP dans les deux modes différents... et c'est
exactement la même valeur !
https://gtello.pagesperso-orange.fr/temp/stack.jpg
Tu ne me crois pas hein ? Pourtant les informations à ce sujet se
trouvent dans n'importe quel livre sur le 68000. J'ai moi le livre
officiel de Motorola, le manuel de la famille de processeurs 68k.
Ça peut aussi se trouver là :

<http://eaglesystem.free.fr/68000.html>
"
En interne, il existe en fait deux pointeurs différents l'USP ( User
Stack Pointer ) en mode utilisateur et le SSP ( Supervisor Stack
Pointer ) en mode superviseur.

Il s'agit toujours du registre A7, le 68000 utilisant implicitement
l'un ou l'autre en fonction de son mode de fonctionnement.
"
Donc, si tu vas lire deux fois dans le même registre, c'est pareil.
Les pointeurs de pile utilisateur et superviseur, ont toutes les
chances de pointer vers une zone mémoire différente, car sinon,
comment les différents modes feraient pour retrouver le contexte ?
Il y a un contexte utilisateur, et un contexte superviseur, ce
dernier permettant sous freeMiNT de gérer le partage de tâches.

On ne te l'as peut-être pas appris à l'école, mais moi oui. J'ai
eu des cours sur le 68000, et j'ai aussi réalisé un système minimum,
travaillé avec un pod d'émulation 68000, avec un analyseur numérique.
Enfin, je connaissais le C, l'assembleur 68000 et ses périphériques
dès 1986, et c'est pourquoi j'ai acheté un ATARI 1040STf. Je n'ai pas
appris "sur le tas".

Tu es tellement sûr de ce que tu as pratiqué depuis toujours, sans
que l'on te dise que c'est pas "clean", que tu ne veux pas l'admettre.
Pourtant tu as tort, je te le dis, et tu ferais bien de l'admettre.

Le mode superviseur, sous un système multitâche comme freeMiNT doit
n'être utilisé que très exceptionnellement. Sinon, tu ne respectes
pas l'intégrité du système, et le bon fonctionnement pour les autres.
Ne te cherches pas des excuses pour programmer salement, tu as tort.

ATARIstiquement vôtre =)
--
François LE COAT
Auteur de Eurêka 2.12 (Grapheur 2D, Modeleur 3D)
http://eureka.atari.org/
Arachide
2020-01-08 18:36:55 UTC
Permalink
Post by Francois LE COAT
Tu ne me crois pas hein ? Pourtant les informations à ce sujet se
trouvent dans n'importe quel livre sur le 68000. J'ai moi le livre
officiel de Motorola, le manuel de la famille de processeurs 68k.
    <http://eaglesystem.free.fr/68000.html>
Bravo pour la recherche ! Pour une fois tu as une source non fantasmée.
Merci pour le reste de l'explication que je connais.

Mais alors...
Comment expliques tu que mon pointeur A7 ait la même valeur en
superviseur qu'en utilisateur? (J'utilise l'appel SUPER() du GEMDOS)

Hein ?

J'ai mon idée.

Mais si tu n'as pas confiance en mon programme, écris-en un toi même et
vérifie ce que je dis.

Guillaume.
Post by Francois LE COAT
Tu es tellement sûr de ce que tu as pratiqué depuis toujours, sans
que l'on te dise que c'est pas "clean", que tu ne veux pas l'admettre.
Pourtant tu as tort, je te le dis, et tu ferais bien de l'admettre.
Je n'ai jamais dit que je programmais sous Mint. Mon système de
prédilection est le TOS de base.
Post by Francois LE COAT
Le mode superviseur, sous un système multitâche comme freeMiNT doit
n'être utilisé que très exceptionnellement. Sinon, tu ne respectes
pas l'intégrité du système, et le bon fonctionnement pour les autres.
Ne te cherches pas des excuses pour programmer salement, tu as tort.
Prouve le ! Fais un programme qui utilise SUPER() et qui t'affiche un
pointeur de pile différent. Là je te croirais.
Moi j'ai écrit un programme qui montre que les pointeurs sont égaux. Et
en plus dans ma zone programme (au delà de ma BasePage.)
Francois LE COAT
2020-01-08 19:40:06 UTC
Permalink
Salut,
Post by Arachide
Je n'ai jamais dit que je programmais sous Mint. Mon système de
prédilection est le TOS de base.
Mais tu as posé la question de savoir comment lire l'état du clavier,
en mode superviseur, sous freeMiNT. La preuve peut être simple. Le
programme que tu as réalisé, grâce à ton savoir faire, tu n'as qu'à
le lancer sous freeMiNT. Tu as bien réalisé un petit soft que j'ai
testé, que tu as lancé sous freeMiNT. Vincent Rivière t'as répondu.
Tu verras sous freeMiNT qu'il existe deux contextes, et que c'est
pas propre de donner à une application les privilèges de l'OS. Si tu
veux que tes softs tournent aussi sous freeMiNT, il faut le savoir.

Ça ne correspond pas à un problème avec freeMiNT, parce que simplement
le mode de fonctionnement superviseur lui est réservé. Si l'on marche
sur les plates-bandes du système, il devient instable. Comme tous les
Unices, il est pourtant conçu pour fonctionner infailliblement.

Il y a plein de manières de planter les systèmes, parce qu'ils ont
tous leurs failles. Là tu as trouvé comment le bloquer, en empêchant
l’ordonnancement des tâches. Normalement, lorsque l'on écrit un soft,
c'est dans le but qu'il tourne. Ou alors, c'est un malware ... Ne me
dis pas que tu en écris sans le savoir, comme M. Jourdain faisait de
la prose. Tu sais que l'usage du mode superviseur immobilise freeMiNT ?
--
François LE COAT
Auteur de Eurêka 2.12 (Grapheur 2D, Modeleur 3D)
http://eureka.atari.org/
Arachide
2020-01-08 19:46:56 UTC
Permalink
Post by Francois LE COAT
Salut,
Post by Arachide
Je n'ai jamais dit que je programmais sous Mint. Mon système de
prédilection est le TOS de base.
Mais tu as posé [bla bla bla] immobilise freeMiNT ?
Mon programme ne plante pas FreeMint.
Il ne peut simplement pas accéder à la touche Control.

Mais je l'ai modifié pour que ça marche sans perte de puissance.

Mais le fait que M_player bloque les autres processus ne me gène pas du
tout. Au contraire, c'est un effet positif.

Utiliser M_PLAYER sur un Atari sans avoir toute la puissance de la
machine est bête car la vidéo sera mal rejouée.

Guillaume.
Francois LE COAT
2020-01-08 20:25:07 UTC
Permalink
Salut,
Post by Arachide
Post by Arachide
Je n'ai jamais dit que je programmais sous Mint. Mon système de
prédilection est le TOS de base.
Mais tu as posé [bla bla bla]  immobilise freeMiNT ?
Mon programme ne plante pas FreeMint.
Il ne peut simplement pas accéder à la touche Control.
Mais je l'ai modifié pour que ça marche sans perte de puissance.
Mais le fait que M_player bloque les autres processus ne me gène pas du
tout. Au contraire, c'est un effet positif.
Utiliser M_PLAYER sur un Atari sans avoir toute la puissance de la
machine est bête car la vidéo sera mal rejouée.
Guillaume.
Pour mon programme Eurêka 2.12, j'aurais aussi pu faire le choix que
ça fonctionne avec l'intégralité de la puissance de l'ATARI. J'ai
choisi de respecter les conventions, comme devraient le faire tous
les logiciels qui fonctionnent sous GEM. Pourquoi ça fonctionne
lentement ? Parce que le système s'attribue beaucoup de temps.

Oui mais, le jour où faisant fi de la compatibilité avec l'histoire
du système, Olivier décide de réduire au minimum les délais, mon
logiciel Eurêka 2.12 se met à tracer à une vitesse incroyable.

Morale : il vaut mieux choisir la compatibilité. Il sera toujours
temps de rendre le système plus performant, et le soft tournera
impeccablement. Si les optimisations se font au dépend du système,
il y a de grandes chances pour que ça ne fonctionne plus dans ce cas.

Avec la rapidité des machines actuelles, les optimisations et les
benchmarks ne me soucient plus. J'ai vraiment tout fait pour ne pas
gâcher la puissance de mes machines ATARI. Aujourd'hui je me rends
compte que mes efforts étaient payants. Je n'aurais pas eu besoin
de faire des entourloupes pour gagner des broutilles en vitesse.
--
François LE COAT
Auteur de Eurêka 2.12 (Grapheur 2D, Modeleur 3D)
http://eureka.atari.org/
Arachide
2020-01-08 21:21:16 UTC
Permalink
Post by Francois LE COAT
. Aujourd'hui je me rends
compte que mes efforts étaient payants. Je n'aurais pas eu besoin
de faire des entourloupes pour gagner des broutilles en vitesse.
Ne rien faire et attendre? Tu appelles ça des efforts?
N'oublie pas de faire grève demain, va pas te fouler un neurone.

Guillaume.
Arachide
2020-01-09 10:26:33 UTC
Permalink
Post by Francois LE COAT
Pour mon programme Eurêka 2.12, j'aurais aussi pu faire le choix que
ça fonctionne avec l'intégralité de la puissance de l'ATARI. J'ai
choisi de respecter les conventions,
Un accueil avec des boites d'alertes, ce n'est pas la convention.

La sortie Quitter qui n'est pas dans le menu Fichier n'est pas une
convention.

comme devraient le faire tous
Post by Francois LE COAT
les logiciels qui fonctionnent sous GEM. Pourquoi ça fonctionne
lentement ? Parce que le système s'attribue beaucoup de temps.
Perce que tu n'as pas optimisé.
Post by Francois LE COAT
Oui mais, le jour où faisant fi de la compatibilité avec l'histoire
du système, Olivier décide de réduire au minimum les délais, mon
logiciel Eurêka 2.12 se met à tracer à une vitesse incroyable.
Olivier que tu insultes depuis des années, dont tu n'écoutes pas les
conseils pour améliorer ton soft.

Et au lieu de t'y mettre toi, tu le laisses faire lui (car il en est
capable) qui réussit à contourner ta programmation pour accélérer ton
programme.

Et soudain, tu t'en attribues le mérite!
Post by Francois LE COAT
Je n'aurais pas eu besoin
de faire des entourloupes pour gagner des broutilles en vitesse.
Des broutilles?
Si ça se trouve, en étant vraiment mieux programmé, ton logiciel serait
capable de faire des surface en 3D animées en temps réel.
Au lieu de tracer juste une fonction étonnament vite à ta grande
surprise d'ailleurs.

Guillaume.
Francois LE COAT
2020-01-09 11:22:19 UTC
Permalink
Salut,
Post by Arachide
Post by Francois LE COAT
Pour mon programme Eurêka 2.12, j'aurais aussi pu faire le choix que
ça fonctionne avec l'intégralité de la puissance de l'ATARI. J'ai
choisi de respecter les conventions,
Un accueil avec des boites d'alertes, ce n'est pas la convention.
La sortie Quitter qui n'est pas dans le menu Fichier n'est pas une
convention.
A la date où j'ai défini l'interface de Eurêka 2.12, en 1987, les
conventions dont tu parles n'existaient pas. Je te rappelle que
mon soft a 33 ans, et que si tu as la possibilité de faire
fonctionner des logiciels de cette époque, ils ne respectent
aucune des conventions que tu énonces. Toi qui a des machines et
des logiciels anciens, tes remarques me surprennent beaucoup.
Post by Arachide
comme devraient le faire tous
Post by Francois LE COAT
les logiciels qui fonctionnent sous GEM. Pourquoi ça fonctionne
lentement ? Parce que le système s'attribue beaucoup de temps.
Perce que tu n'as pas optimisé.
Si les optimisations consistent à court-circuiter le système, parce
que celui-ci ralentit tout, ce ne sont pas des optimisations. Les
applications mal-programmées font cela, et ne fonctionnent plus
avec les évolutions du système, notamment les jeux.
Post by Arachide
Post by Francois LE COAT
Oui mais, le jour où faisant fi de la compatibilité avec l'histoire
du système, Olivier décide de réduire au minimum les délais, mon
logiciel Eurêka 2.12 se met à tracer à une vitesse incroyable.
Olivier que tu insultes depuis des années, dont tu n'écoutes pas les
conseils pour améliorer ton soft.
Tu renverses les rôles. C'est le contraire.
Post by Arachide
Et au lieu de t'y mettre toi, tu le laisses faire lui (car il en est
capable) qui réussit à contourner ta programmation pour accélérer ton
programme.
Et les tiens, Guillaume, par le même principe. Si le système est plus
performant, tous les logiciels, dont les tiens, sont plus rapides.
Post by Arachide
Et soudain, tu t'en attribues le mérite!
Et toi non, bien sûr ... Les optimisations bénéficient à tout le monde.
Post by Arachide
Post by Francois LE COAT
 Je n'aurais pas eu besoin
de faire des entourloupes pour gagner des broutilles en vitesse.
Des broutilles?
Si ça se trouve, en étant vraiment mieux programmé, ton logiciel serait
capable de faire des surface en 3D animées en temps réel.
Au lieu de tracer juste une fonction étonnament vite à ta grande
surprise d'ailleurs.
Si tu ne connais pas les softs actuels qui font cela, je te conseille
MathMod <https://www.facebook.com/parisolab/>. Les moyens qui sont
utilisés par ce soft actuel, n'ont rien de commun avec les technologies
d'il y a 35 ans. Les progrès de l'informatique sont spectaculaires !
--
François LE COAT
Auteur de Eurêka 2.12 (Grapheur 2D, Modeleur 3D)
http://eureka.atari.org/
Arachide
2020-01-09 12:16:38 UTC
Permalink
Post by Francois LE COAT
A la date où j'ai défini l'interface de Eurêka 2.12, en 1987, les
conventions dont tu parles n'existaient pas. Je te rappelle que
mon soft a 33 ans, et que si tu as la possibilité de faire
fonctionner des logiciels de cette époque, ils ne respectent
aucune des conventions que tu énonces. Toi qui a des machines et
des logiciels anciens, tes remarques me surprennent beaucoup.
Et depuis 33 ans, tu n'as pas eu le temps de modifier la position de
"Quitter" dans tes menus?
Francois LE COAT
2020-01-09 12:51:16 UTC
Permalink
Salut,
Post by Arachide
Post by Francois LE COAT
A la date où j'ai défini l'interface de Eurêka 2.12, en 1987, les
conventions dont tu parles n'existaient pas. Je te rappelle que
mon soft a 33 ans, et que si tu as la possibilité de faire
fonctionner des logiciels de cette époque, ils ne respectent
aucune des conventions que tu énonces. Toi qui a des machines et
des logiciels anciens, tes remarques me surprennent beaucoup.
Et depuis 33 ans, tu n'as pas eu le temps de modifier la position de
"Quitter" dans tes menus?
C'est un soft qui a 33 ans, et modifier cela consiste à réécrire
l'histoire. Si tu veux t'amuser avec un logiciel actuel, tu peux
par exemple choisir MathMod <https://www.facebook.com/parisolab/>
Il est très bien, et répond à toutes les conventions actuelles.
--
François LE COAT
Auteur de Eurêka 2.12 (Grapheur 2D, Modeleur 3D)
http://eureka.atari.org/
Arachide
2020-01-09 13:11:44 UTC
Permalink
Post by Francois LE COAT
C'est un soft qui a 33 ans, et modifier cela consiste à réécrire
l'histoire.
Rien que ça...

Je croyais que tu programmais depuis 33 ans. Mais non. Tu as programmé
il y a 33 ans.

Guillaume.
Francois LE COAT
2020-01-09 13:25:52 UTC
Permalink
Salut,
Post by Arachide
C'est un soft qui a 33 ans, et modifier cela consiste à réécrire l'histoire.
Rien que ça...
Oui, Eurêka 2.12 fonctionne sur un ATARI ST qui a 35 ans, avec TOS 1.0.



Je le sais, parce que j'ai testé mon logiciel sur une telle machine =)
--
François LE COAT
Auteur de Eurêka 2.12 (Grapheur 2D, Modeleur 3D)
http://eureka.atari.org/
pehache
2020-01-11 13:52:03 UTC
Permalink
Post by Francois LE COAT
Salut,
Post by Arachide
C'est un soft qui a 33 ans, et modifier cela consiste à réécrire l'histoire.
Rien que ça...
Oui, Eurêka 2.12 fonctionne sur un ATARI ST qui a 35 ans, avec TOS 1.0.
http://youtu.be/Mhz3IhLuIa0
Je le sais, parce que j'ai testé mon logiciel sur une telle machine =)
Et il est tellement lent qu'il en est inutilisable, même suivant les
standards de performances de l'époque.
--
"...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
même sens que les tiennes.", ST sur fr.bio.medecine
pehache
2020-01-11 13:51:05 UTC
Permalink
Post by Francois LE COAT
Salut,
Post by Arachide
Post by Francois LE COAT
A la date où j'ai défini l'interface de Eurêka 2.12, en 1987, les
conventions dont tu parles n'existaient pas. Je te rappelle que
mon soft a 33 ans, et que si tu as la possibilité de faire
fonctionner des logiciels de cette époque, ils ne respectent
aucune des conventions que tu énonces. Toi qui a des machines et
des logiciels anciens, tes remarques me surprennent beaucoup.
Et depuis 33 ans, tu n'as pas eu le temps de modifier la position de
"Quitter" dans tes menus?
C'est un soft qui a 33 ans, et modifier cela consiste à réécrire
l'histoire.
Je suppose que tu portes encore des couches comme il y a environ 50 ans
peu après ta naissance, histoire de ne pas réécrire ton histoire ?
--
"...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
même sens que les tiennes.", ST sur fr.bio.medecine
pehache
2020-01-11 13:44:23 UTC
Permalink
Post by Francois LE COAT
Post by Arachide
Perce que tu n'as pas optimisé.
Si les optimisations consistent à court-circuiter le système, parce
que celui-ci ralentit tout, ce ne sont pas des optimisations. Les
applications mal-programmées font cela, et ne fonctionnent plus
avec les évolutions du système, notamment les jeux.
C'est sûr que c'est mieux d'avoir un truc inutilisable tellement c'est lent.
--
"...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
même sens que les tiennes.", ST sur fr.bio.medecine
pehache
2020-01-11 13:41:09 UTC
Permalink
Post by Francois LE COAT
Salut,
Post by Arachide
Post by Arachide
Je n'ai jamais dit que je programmais sous Mint. Mon système de
prédilection est le TOS de base.
Mais tu as posé [bla bla bla]  immobilise freeMiNT ?
Mon programme ne plante pas FreeMint.
Il ne peut simplement pas accéder à la touche Control.
Mais je l'ai modifié pour que ça marche sans perte de puissance.
Mais le fait que M_player bloque les autres processus ne me gène pas
du tout. Au contraire, c'est un effet positif.
Utiliser M_PLAYER sur un Atari sans avoir toute la puissance de la
machine est bête car la vidéo sera mal rejouée.
Guillaume.
Pour mon programme Eurêka 2.12, j'aurais aussi pu faire le choix que
ça fonctionne avec l'intégralité de la puissance de l'ATARI. J'ai
choisi de respecter les conventions, comme devraient le faire tous
les logiciels qui fonctionnent sous GEM. Pourquoi ça fonctionne > lentement ? Parce que le système s'attribue beaucoup de temps.
J'ai utilisé un grapheur sur Mac Plus (68000) à la fin des années 80, et
ce n'était en rien aussi lent que Eureka.
Post by Francois LE COAT
Oui mais, le jour où faisant fi de la compatibilité avec l'histoire
du système, Olivier décide de réduire au minimum les délais, mon
logiciel Eurêka 2.12 se met à tracer à une vitesse incroyable.
Morale : il vaut mieux choisir la compatibilité. Il sera toujours
temps de rendre le système plus performant, et le soft tournera
impeccablement. Si les optimisations se font au dépend du système,
il y a de grandes chances pour que ça ne fonctionne plus dans ce cas.
Avec la rapidité des machines actuelles, les optimisations et les
benchmarks ne me soucient plus. J'ai vraiment tout fait pour ne pas
gâcher la puissance de mes machines ATARI. Aujourd'hui je me rends
compte que mes efforts étaient payants. Je n'aurais pas eu besoin
de faire des entourloupes pour gagner des broutilles en vitesse.
*tes efforts* ??? C'est beau tellement ta prétention n'a aucune limite.

Si il y a un truc qui a été payant, c'est au contraire ton absence
d'effort pour optimiser ton code : tu as juste attendu que les machines
soient plus puissantes. Tu parles d'un développeur !!!

Depuis 33 ans tu aurais pu optimiser ton code pour les vieilles
machines, qui à conserver le code normal pour les machines plus
récentes. N'importe quel développeur qui aime peaufiner son code
l'aurait fait en fait. La conclusion serait donc que tu ne sais pas
faire et que tu fais passer ça pour une vertu de compatibilité.
--
"...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
même sens que les tiennes.", ST sur fr.bio.medecine
Arachide
2020-01-08 19:16:27 UTC
Permalink
Coucou,

Comme tu es habitué à ce qu'on te mâche le travail, voici pour toi:

https://gtello.pagesperso-orange.fr/temp/sources.zip

Tu y trouves le source d'un programme qui compare les deux piles.
J'ai aussi fait le binaire pour pas que tu aies à assembler tout seul.

Comme tu as étudié l'assembleur 68000, tu m'expliqueras pourquoi mon
programme affiche "pareil" et non " différent".

Le petit source copié ici:

Bonne lecture !

Guillaume.

PS: moi je sais pourquoi c'est égal.


; démarrage TOS

OUTPUT "super.prg"

XBIOS MACRO ; fn,pile
move #\1,-(sp)
trap #14
if \2<=8
addq.l #\2,sp
else
add.w #\2,sp
endif
ENDM

BIOS MACRO ; fn,pile
move #\1,-(sp)
trap #13
if \2<=8
addq.l #\2,sp
else
add.w #\2,sp
endif
ENDM

GEMDOS MACRO ; fn,pile
move #\1,-(sp)
trap #1
if \2<=8
addq.l #\2,sp
else
add.w #\2,sp
endif
ENDM

move.l 4(sp),a0
move.l $18(a0),a1
add.l $1c(a0),a1
add.l #$200,a1
move.l a1,sp
sub.l a0,a1
move.l a1,-(sp)
move.l a0,-(sp)
clr.w -(sp)
GEMDOS $4a,12 ; MSHRINK, réduit l'espace

move.l a7,d7 ; pile actuelle UTILISATEUR

clr.l -(sp)
GEMDOS 32,6 ; bascule en superviseur !

move.l a7,d6 ; pile actuelle

move.l d0,-(sp) ; revient en utilisateur
GEMDOS 32,6

lea titre1(pc),a0
cmp.l d6,d7 ; choisit le texte selon que D6=D7 ou non
beq.s affiche

lea titre2(pc),a0

affiche:
move.l a0,-(sp) ; et affiche le résultat
GEMDOS 9,6

move.l #$20002,-(sp) ; attend une touche.
trap #13
addq.l #4,sp

clr -(sp)
trap #1

data

titre1: dc.b 27,"EPareil !",13,10,10,0
titre2: dc.b 27,"EDifférent !",13,10,10,0


bss
even
ds.l 1000

end
Francois LE COAT
2020-01-09 19:33:06 UTC
Permalink
Salut,
Post by Arachide
https://gtello.pagesperso-orange.fr/temp/sources.zip
Tu y trouves le source d'un programme qui compare les deux piles.
J'ai aussi fait le binaire pour pas que tu aies à assembler tout seul.
Comme tu as étudié l'assembleur 68000, tu m'expliqueras pourquoi mon
programme affiche "pareil" et non " différent".
Bonne lecture !
Guillaume.
PS: moi je sais pourquoi c'est égal.
Il y a un problème avec ton programme, parce que Olivier a expliqué
qu'il a changé le pointeur de pile superviseur avec MyAES, or lorsque
je lance ton programme, il affiche que les pointeurs sont les mêmes.
Donc j'en déduis que ton programme ne compare pas les pointeurs de
piles utilisateur et superviseur. Il ne teste que la pile utilisateur.
--
François LE COAT
Auteur de Eurêka 2.12 (Grapheur 2D, Modeleur 3D)
http://eureka.atari.org/
o***@lutece.net
2020-01-09 19:41:05 UTC
Permalink
Post by Francois LE COAT
Salut,
Post by Arachide
https://gtello.pagesperso-orange.fr/temp/sources.zip
Tu y trouves le source d'un programme qui compare les deux piles.
J'ai aussi fait le binaire pour pas que tu aies à assembler tout seul.
Comme tu as étudié l'assembleur 68000, tu m'expliqueras pourquoi mon
programme affiche "pareil" et non " différent".
Bonne lecture !
Guillaume.
PS: moi je sais pourquoi c'est égal.
Il y a un problème avec ton programme, parce que Olivier a expliqué
qu'il a changé le pointeur de pile superviseur avec MyAES, or lorsque
je lance ton programme, il affiche que les pointeurs sont les mêmes.
Donc j'en déduis que ton programme ne compare pas les pointeurs de
piles utilisateur et superviseur. Il ne teste que la pile utilisateur.
Tu n'as pas bien compris mon propos, je change la pile lorsque l'application rentre dans l'AES et je lui restitue sa pile en sortant.

OL
Arachide
2020-01-09 19:48:56 UTC
Permalink
Post by Francois LE COAT
Salut,
Post by Arachide
https://gtello.pagesperso-orange.fr/temp/sources.zip
Tu y trouves le source d'un programme qui compare les deux piles.
J'ai aussi fait le binaire pour pas que tu aies à assembler tout seul.
Comme tu as étudié l'assembleur 68000, tu m'expliqueras pourquoi mon
programme affiche "pareil" et non " différent".
Bonne lecture !
Guillaume.
PS: moi je sais pourquoi c'est égal.
Il y a un problème avec ton programme, parce que Olivier a expliqué
qu'il a changé le pointeur de pile superviseur avec MyAES, or lorsque
je lance ton programme, il affiche que les pointeurs sont les mêmes.
Donc j'en déduis que ton programme ne compare pas les pointeurs de
piles utilisateur et superviseur. Il ne teste que la pile utilisateur.
Tu ne veux simplement pas admettre que les pointeurs sont les mêmes donc
tu cherches à biaiser.

Je te dis que quand un programme appelle SUPER() et se retrouve en
superviseur, il conserve son pointeur de pile à lui. Donc si j'ai réglé
assez de place sur ma pile, je ne suis pas dérangé par le fait d'être en
superviseur.

Et si tu savais lire l'assembleur, tu aurais compris que je compare bien
A7 pris à deux moments différents (User et Superviseur)

Guillaume.
Francois LE COAT
2020-01-09 19:55:26 UTC
Permalink
Salut,
Post by Arachide
Post by Francois LE COAT
Post by Arachide
https://gtello.pagesperso-orange.fr/temp/sources.zip
Tu y trouves le source d'un programme qui compare les deux piles.
J'ai aussi fait le binaire pour pas que tu aies à assembler tout seul.
Comme tu as étudié l'assembleur 68000, tu m'expliqueras pourquoi mon
programme affiche "pareil" et non " différent".
Bonne lecture !
Guillaume.
PS: moi je sais pourquoi c'est égal.
Il y a un problème avec ton programme, parce que Olivier a expliqué
qu'il a changé le pointeur de pile superviseur avec MyAES, or lorsque
je lance ton programme, il affiche que les pointeurs sont les mêmes.
Donc j'en déduis que ton programme ne compare pas les pointeurs de
piles utilisateur et superviseur. Il ne teste que la pile utilisateur.
Tu ne veux simplement pas admettre que les pointeurs sont les mêmes donc
tu cherches à biaiser.
Je te dis que quand un programme appelle SUPER() et se retrouve en
superviseur, il conserve son pointeur de pile à lui. Donc si j'ai réglé
assez de place sur ma pile, je ne suis pas dérangé par le fait d'être en
superviseur.
Et si tu savais lire l'assembleur, tu aurais compris que je compare bien
A7 pris à deux moments différents (User et Superviseur)
Guillaume.
J'ai très bien compris ce que fait ton programme. Mais il ne marche pas.
Pourquoi y aurait-il deux registres USP et SSP, s'ils ne pointaient
systématiquement que sur la même adresse ? Tu as lu la documentation
du 68000 comme moi, hein ? Donc ton programme est faux, et il ne teste
pas ce à quoi tu t'attendais. Il ne faut pas s'y prendre comme cela ...
--
François LE COAT
Auteur de Eurêka 2.12 (Grapheur 2D, Modeleur 3D)
http://eureka.atari.org/
Arachide
2020-01-09 20:43:48 UTC
Permalink
Post by Francois LE COAT
J'ai très bien compris ce que fait ton programme. Mais il ne marche pas.
Pourquoi y aurait-il deux registres USP et SSP, s'ils ne pointaient
systématiquement que sur la même adresse ?
je n'ai pas dit que USP et SSP poitaient sur la même adresse.
Je dis qu'au retour de SUPER(), même en mode Superviseur, je récupère
mon propre pointeur de pile.



Tu as lu la documentation
Post by Francois LE COAT
du 68000 comme moi, hein ? Donc ton programme est faux, et il ne teste
pas ce à quoi tu t'attendais. Il ne faut pas s'y prendre comme cela ...
Si tu es si malin, dis moi comment!
Francois LE COAT
2020-01-09 21:55:25 UTC
Permalink
Salut,
Post by Arachide
Post by Francois LE COAT
J'ai très bien compris ce que fait ton programme. Mais il ne marche pas.
Pourquoi y aurait-il deux registres USP et SSP, s'ils ne pointaient
systématiquement que sur la même adresse ?
je n'ai pas dit que USP et SSP poitaient sur la même adresse.
Je dis qu'au retour de SUPER(), même en mode Superviseur, je récupère
mon propre pointeur de pile.
 Tu as lu la documentation
Post by Francois LE COAT
du 68000 comme moi, hein ? Donc ton programme est faux, et il ne teste
pas ce à quoi tu t'attendais. Il ne faut pas s'y prendre comme cela ...
Si tu es si malin, dis moi comment!
Bien il faut admettre que tu ne sais pas tout, et que moi non plus.
Maintenant je t'ai dit ce que j'ai appris sur les modes utilisateur
et superviseur du 68000. Moi ça me suffit pour programmer correctement.
Parce que toi tu as tendance à effondrer le système freeMiNT dans un
premier temps, et à le rendre instable ensuite. Ta façon de faire n'est
pas correcte, par respect du système, et des autres logiciels qui
fonctionnent en multitâche, ainsi que pour les autres utilisateurs.
--
François LE COAT
Auteur de Eurêka 2.12 (Grapheur 2D, Modeleur 3D)
http://eureka.atari.org/
Arachide
2020-01-10 08:16:58 UTC
Permalink
Post by Francois LE COAT
Bien il faut admettre que tu ne sais pas tout, et que moi non plus.
Maintenant je t'ai dit ce que j'ai appris sur les modes utilisateur
et superviseur du 68000. Moi ça me suffit pour programmer correctement.
Parce que toi tu as tendance à effondrer le système freeMiNT dans un
premier temps,
Montre moi l'effondrement du système. Je suis curieux.

et à le rendre instable ensuite.

Il est devenu instable? Tu ne m'en as jamais parlé avant.

Ta façon de faire n'est
Post by Francois LE COAT
pas correcte, par respect du système, et des autres logiciels qui
fonctionnent en multitâche, ainsi que pour les autres utilisateurs.
Je pense surtout que tu es une quiche en assembleur et que tu n'as pas
compris ce programme, au demeurant très simple.

Pour la suite, je te rappelle que ton langage a tendance à basculer dans
le jugement de valeur (pas correct, respect..) alors qu'on parle d'une
machine. Il faut se calmer. Le jour où un Atari affiche 2 bombes, ce
n'est pas un attentat.

Guillaume.
o***@lutece.net
2020-01-10 17:24:56 UTC
Permalink
Post by Francois LE COAT
Salut,
Post by Arachide
Post by Francois LE COAT
Post by Arachide
https://gtello.pagesperso-orange.fr/temp/sources.zip
Tu y trouves le source d'un programme qui compare les deux piles.
J'ai aussi fait le binaire pour pas que tu aies à assembler tout seul.
Comme tu as étudié l'assembleur 68000, tu m'expliqueras pourquoi mon
programme affiche "pareil" et non " différent".
Bonne lecture !
Guillaume.
PS: moi je sais pourquoi c'est égal.
Il y a un problème avec ton programme, parce que Olivier a expliqué
qu'il a changé le pointeur de pile superviseur avec MyAES, or lorsque
je lance ton programme, il affiche que les pointeurs sont les mêmes.
Donc j'en déduis que ton programme ne compare pas les pointeurs de
piles utilisateur et superviseur. Il ne teste que la pile utilisateur.
Tu ne veux simplement pas admettre que les pointeurs sont les mêmes donc
tu cherches à biaiser.
Je te dis que quand un programme appelle SUPER() et se retrouve en
superviseur, il conserve son pointeur de pile à lui. Donc si j'ai réglé
assez de place sur ma pile, je ne suis pas dérangé par le fait d'être en
superviseur.
Et si tu savais lire l'assembleur, tu aurais compris que je compare bien
A7 pris à deux moments différents (User et Superviseur)
Guillaume.
J'ai très bien compris ce que fait ton programme. Mais il ne marche pas.
Pourquoi y aurait-il deux registres USP et SSP, s'ils ne pointaient
systématiquement que sur la même adresse ? Tu as lu la documentation
du 68000 comme moi, hein ? Donc ton programme est faux, et il ne teste
pas ce à quoi tu t'attendais. Il ne faut pas s'y prendre comme cela ...
Guillaume à je pense raison
Voilà sans regarder les sources de Mint ou de Emutos, mais avec un certain
raisonnement comment cela se produit:

-Il y a trap (Super)
-le processeur passe sur la pile superviseur défini par le système
Cette pile est nécessaire pour que le système s'affranchisse des soucis de
définition de pile qu'il ne peut maîtriser sans cela qui pourrait se révéler trop
petite et aussi parce que le 68000 c'est comme cela.
- Le système bricole je ne sais pas quoi pour que le processeur reste en
superviseur en retour de trap, mais au retour de trap il est obligé que le retour
se fasse sur la pile utilisateur sinon cela planterait!

Donc pour conclure l'appel Super me semble un peu bricolage et il semble tout à
fait logique que l'on revienne sur la pile utilisateur.

Je ne sais pas comment cela se fait lors de l'appel de Supexec() cela pourrait être bien différent, il n'y a plus de contrainte de retour de la pile user vu que
l'on ne sort pas du trap.

Il y a un cas où sur où l'on peut avoir un problème de pile superviseur à coup
sur et c'est sans doute pour cela que tu as entendu parlé de pile réduite à juste
titre, c'est lors de l'appel de la fonction de redessin des USERDEF qui a elle la
pile défini par le système (tout au moins par l'AES)

Je pense que tout s'explique et que l'on en découvre tous les jours si l'on veut
même en 68000!

OL
Arachide
2020-01-10 19:19:54 UTC
Permalink
Post by o***@lutece.net
-Il y a trap (Super)
-le processeur passe sur la pile superviseur défini par le système
Cette pile est nécessaire pour que le système s'affranchisse des soucis de
définition de pile qu'il ne peut maîtriser sans cela qui pourrait se révéler trop
petite et aussi parce que le 68000 c'est comme cela.
- Le système bricole je ne sais pas quoi pour que le processeur reste en
superviseur en retour de trap, mais au retour de trap il est obligé que le retour
se fasse sur la pile utilisateur sinon cela planterait!
Donc pour conclure l'appel Super me semble un peu bricolage et il semble tout à
fait logique que l'on revienne sur la pile utilisateur.
C'est ce que j'ai trouvé en désassemblant la routine SUPER().
On l'appelle en mode Utilisateur et le système conserve donc USP dans A0
pour aller chercher notre paramètre.

En sortie, il bricole un retour de trap (RTE) en remplissant lui même la
pile.
Il remet notre adresse retour, il ajoute le bit SUPERVISEUR au
StatusRegister sur la pile et fait un magnifique:

move.l A0,A7

Pour nous redonner notre USP avant le RTE.


On retrouve bien notre pile perso et on se trouve en superviseur.

Guillaume.
pehache
2020-01-11 13:25:10 UTC
Permalink
Post by Francois LE COAT
Bon, après cela, sous freeMiNT il y a des astuces pour adapter le
fonctionnement en multitâche. J'ai pris la liberté d'occuper tout
l'écran, parce que j'estime que l'affichage des courbes en vaut la
peine.
Tu as pris la liberté d'occuper tout l'écran parce que c'était plus
facile, c'est tout. Si tu te préoccupais de l'utilisateur tu lui aurais
offert la possibilité de passer en plain écran, sans lui imposer.
--
"...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
même sens que les tiennes.", ST sur fr.bio.medecine
pascal WIJSBROEK
2020-01-07 18:27:56 UTC
Permalink
Post by Francois LE COAT
N'empêche que les machines ATARI sont de plus en plus rapides.
Oui mais sur terre Atari n'a pas sorti de nouvelles machines. C'est sans doute pour ça que tu te méprends.
Post by Francois LE COAT
Et il faut en tenir compte dans les optimisations
Autrement dit "les optimisations ne servent à rien, il suffit d'attendre que le matos soit rapide".
Post by Francois LE COAT
J'essaye
moi de faire des softs qui sont corrects sur toutes les machines
Des softs ? Tu as recommencé à coder ?
Post by Francois LE COAT
mais c'est un exercice difficile. Sur un 520ST d'il y a 35 ans on
voit se tracer la fonction, alors que sur une machine actuelle on
ne voit pas le tracé, qui se fait en un éclair.
Si l'idée c'est de privilégier la puissance des ordinateurs, je ne vois pas bien pourquoi tu te cantonne à Atari. Ton vieux Mac tout pourri ferait bien mieux sans aucune couche d'émulation.
Post by Francois LE COAT
Et heureusement que depuis 35 ans, il y a eu des progrès spectaculaires !
Tu devrais discuter avec FLC, il considère au contraire que depuis la fin du 68000 il n'y a eu aucun progrès.
Post by Francois LE COAT
J'ai un logiciel ATARI qui fonctionne aussi bien sur un 520ST de 1985,
que sur les MegaST, Falcon030, TT030, Hadès060 et enfin ARAnyM, quel
que soit le TOS, EmuTOS, freeMiNT, les AES, les cartes graphiques etc.
Ah. Un soft. Lequel ? C'est pour pouvoir comparer avec Eureka.
Post by Francois LE COAT
Bon, enfin personne ne m'a jamais dit que ça ne marche pas. On m'a
fait des remarques sur la lenteur, l'interface graphique très fruste.
Mais personne ne s'est plaint d'un plantage quelconque. J'y veille !
Et de la meilleure des façons : en ne changeant pas une seule ligne de code.
pehache
2020-01-11 13:21:03 UTC
Permalink
Post by Francois LE COAT
Salut,
Post by Simon
Post by Arachide
Tu as été habitué à des machines ATARI lentes, où il fallait
optimiser la moindre instruction assembleur.
C'est uniquement ce que j'ai. Des machines Atari.
Mais avec une machine ARAnyM sous freeMiNT, on peut faire la même
chose en mode utilisateur.
C'est un émulateur, pas une machine. Ca ne m'intéresse pas.
Heureusement qu'il reste des gens qui ont le souci (ou le goût)
d'optimiser pour toute les machines, et qui contrairement à
FLC n'ont pas basculé adepte de la pensée Microsoft selon laquelle peu
importe l'optimisation, le hard devra compenser.
N'empêche que les machines ATARI sont de plus en plus rapides.
Atari ne fabrique plus de machines depuis plus de 20 ans, mais bon.
Post by Francois LE COAT
Et il
faut en tenir compte dans les optimisations,
Ce qui veut dire dans pour toi : "on peut en profiter pour ne faire
aucun effort d'optimisation"
Post by Francois LE COAT
sinon on se retrouve
avec des softs qui marchent aux petits oignons sur les machines lentes,
et qui se mettent à dysfonctionner sur les machines rapides.
J'ai peut-être raté un truc, mais Arachide a semble-t-il trouvé une
solution à son problème, donc non ça ne dysfonctionne pas.
Post by Francois LE COAT
J'essaye
moi de faire des softs
s/des softs/un soft
Post by Francois LE COAT
qui sont corrects sur toutes les machines,
mais c'est un exercice difficile. Sur un 520ST d'il y a 35 ans on
voit se tracer la fonction, alors que sur une machine actuelle on
ne voit pas le tracé, qui se fait en un éclair. De cette manière on
peut comprendre que l'on a affaire à un ordinateur de course. Et
heureusement que depuis 35 ans, il y a eu des progrès spectaculaires !
C'est normal de pouvoir constater les améliorations techniques du
matériel. Et Guillaume a bien compris cela, parce qu'il a trouvé une
solution. C'est ce qui garanti la pérennité des logiciels dans le temps.
J'ai un logiciel ATARI qui fonctionne aussi bien sur un 520ST de 1985,
que sur les MegaST, Falcon030, TT030, Hadès060 et enfin ARAnyM, quel
que soit le TOS, EmuTOS, freeMiNT, les AES, les cartes graphiques etc.
Bon, enfin personne ne m'a jamais dit que ça ne marche pas. On m'a
fait des remarques sur la lenteur, l'interface graphique très fruste.
Mais personne ne s'est plaint d'un plantage quelconque. J'y veille !
Tu peux expliquer avec des mots simples et sans insulter personne quel
est l'intérêt de maintenir une compatibilité avec un 520 ST, si c'est au
prix d'une lenteur telle que c'est proche d'être inutilisable en pratique ??

Ton code pourrait par exemple détecter la machine sur laquelle il tourne
pour activer certaines optimisations uniquement si besoin. Ou bien pour
ne pas alourdir le binaire avec du code dupliqué avec/sans optimisation
tu pourrais faire de la compilation conditionnelle en fonction de la
cible (mode superviseur uniquement pour le TOS par exemple).

Bref, les solutions potentielles ne manquent pas pour optimiser pour les
vieilles machines et sans rien casser pour les moins vieilles. Mais ça
requiert d'écrire du nouveau code, et là...
--
"...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
même sens que les tiennes.", ST sur fr.bio.medecine
pehache
2020-01-11 13:04:55 UTC
Permalink
Post by Francois LE COAT
Salut,
Post by Arachide
- $4BA (le compteur du Timer C pour la synchro)
- $FFFF8901 (l'état du son DMA pour savoir si c'est fini ou pas)
Tout le monde fait la même chose, moi aussi, Didier Méquignon aussi, et
pourtant il n'est pas besoin de rester en mode superviseur. Tu as été
habitué à des machines ATARI lentes, où il fallait optimiser la moindre
instruction assembleur. Mais avec une machine ARAnyM sous freeMiNT, on
peut faire la même chose en mode utilisateur. Et il faut nécessairement
évoluer, car un superbe logiciel comme Aniplayer commence à ne plus
fonctionner correctement sur une machine rapide, et c'est un paradoxe !
C'est toi qui dit qu'il faut évoluer ? Alors que par ailleurs tu
justifies de ne pas déplacer un item de menu sous prétexte c'était comme
ça il y a 33 ans ?

Tu répètes un numéro de clown, c'est ça ?
--
"...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
même sens que les tiennes.", ST sur fr.bio.medecine
Arachide
2020-01-07 06:33:34 UTC
Permalink
Post by Francois LE COAT
Le mode superviseur, il vaut mieux se restreindre plutôt que de
l'utiliser inutilement. Le problème n'est pas une limitation de
freeMiNT, mais une méconnaissance du mode de fonctionnement d'un
ordinateur, qui n'offre pas toutes les libertés, surtout lorsqu'il
gère énormément de processus en parallèle, et éventuellement même
plusieurs utilisateurs.
Je te rappelle que le BIOS/XBIOS/GEMDOS est appelable en Superviseur,
c'est documenté et autorisé.
Alors pourquoi aucun appel clavier ne serait satisfait dans ce cas?

Et le multitâche ne justifie rien :Qu'on soit en mutlitache superviseur
ou utilisateur, gérer le clavier demande la même ressource.
Post by Francois LE COAT
Est-ce que tu te rappelles de Emmanuel, qui criait au bug de freeMiNT,
parce que son soft n'y avait jamais été compatible. En fait le problème
venait simplement d'un double appel à la fonction appl_init(). Ah c'est
certain que la plupart des jeux ne fonctionnent pas sous ARAnyM, et
encore moins freeMiNT. Mais ça n'est pas dû à des limitations de ceux-ci
mais au fait que les programmeurs écrivent n'importe quoi.
Tu méprises donc les programmeurs de jeux? (jeux que tu encenses par
ailleurs).
Post by Francois LE COAT
Alors, ça n'est pas dommage que l'on ne puisse pas tester l'état du
clavier en mode superviseur.
Si c'est vraiment dommage.

Guillaume.
o***@lutece.net
2020-01-07 20:49:56 UTC
Permalink
Post by Francois LE COAT
Je réponds cela, parce que très souvent Olivier, tu as tendance à parler
de problèmes avec freeMiNT, avec ARAnyM etc. Mais le problème ne vient
pas de là, mais de la façon de programmer de Guillaume ... Pourquoi
faire un décodage vidéo entièrement en superviseur, en testant <CTRL>
pour quitter ? Si Guillaume procède de cette manière, son soft ne sera
pas compatible avec freeMiNT. Les libertés que l'on peut s'autoriser
sous TOS, ne sont pas recommandées avec freeMiNT. De même on ne peut pas
faire n'importe quoi avec ARAnyM. Mais ça ne sont pas des problèmes de
ces systèmes. C'est que le programmeur n'écrit pas de façon "clean".
1 encore une fois tu es assez mal placé pour parler de freemint ou de Aranym en tous les cas moins bien que moi, tu n'as jamais écrit une seule ligne de code ou de correction dans le code de ces logiciels, et si je me le permet c'est que de mon côté je l'ai fait à plusieurs reprises même si je ne suis pas un programmeur majeur et le plus à même à comprendre ces logiciels j'y ai quand même contribué.

Pour Aranym pour véritablement sont port sous Windows (pas seulement un configure - make), des accélérations, un problème de gestion timer et quelques bricoles.
Pour freemint j'ai été le premier à le rendre compilable sous GCC 4 alors qu'il ne l'était que sous 2.95.3, cela a été déjà un petit boulot pas si tranquille, puis sa compilation en mode natif coldfire et là non plus cela n'a pas été une mince affaire à cause tient d'un problème de gestion de pile superviseur, je m'y suis arraché les cheveux pendant 1 semaine ou 2 parce que les problèmes de pile c'est une galère pas possible et freemint franchement comme c'est fait c'est très très basic et à mon avis un des points qui fait que freemint à certaines limitations que n'a pas Magic comme ne pas pouvoir appeler une fonction gemdos sous un signal Unix alors que cela marche à la perfection sous Magic. Donc oui j'ai un peu un oeil critique.
Post by Francois LE COAT
Le mode superviseur, il vaut mieux se restreindre plutôt que de
l'utiliser inutilement. Le problème n'est pas une limitation de
freeMiNT, mais une méconnaissance du mode de fonctionnement d'un
ordinateur, qui n'offre pas toutes les libertés, surtout lorsqu'il
gère énormément de processus en parallèle, et éventuellement même
plusieurs utilisateurs.
Il est vrai que d'utiliser le mode user est préférable, tout bonnement parce que cela est une protection du système, après si dans ce cas une variable n'est pas mise à jours en mode superviseur, c'est juste une limite de freemint et cela n'a que peu de lien avec multitâche ou pas.
Post by Francois LE COAT
Est-ce que tu te rappelles de Emmanuel, qui criait au bug de freeMiNT,
parce que son soft n'y avait jamais été compatible. En fait le problème
venait simplement d'un double appel à la fonction appl_init(). Ah c'est
certain que la plupart des jeux ne fonctionnent pas sous ARAnyM, et
encore moins freeMiNT. Mais ça n'est pas dû à des limitations de ceux-ci
mais au fait que les programmeurs écrivent n'importe quoi.
Alors, ça n'est pas dommage que l'on ne puisse pas tester l'état du
clavier en mode superviseur. La vraie réponse à faire est de savoir
pourquoi Guillaume veut passer en superviseur pour le décodage vidéo ?
C'est simple pour avoir accès au timer 200hz qui ne peut être accéder qu'en superviseur (c'est une grosse connerie système que Mint devrait corriger si c'est possible (sais pas!)) et pourquoi il a besoin du 200 hz ? pour la simple raison qu'il a besoin de caler l'affichage des images à la bonne fréquence si c'est possible! Ce n'est pas un logiciel de math qui se fout si c'est rapide ou lent et le soucis c'est qu'il n'y a rien dans le système pour afficher des séquences vidéo (c'est un gros manque) comme il y a pour jouer un son. imagines ton soft comme un lecteur vidéo en gros il ne fonctionnerait jamais à la bonne vitesse!

En fait dans le temps sous on faisait il me semble l'affichage grâce à l'interruption VBL, l'autre solution c'est d'utiliser l'IT 200hz en y plaçant la sienne. Ces 2 façons de faire fonctionnent encore mais par expérience c'est très limite dans le principe car si l'application qui ajoute sa routine plante alors tout le système plante. Il n'y a pas de bonnes solutions actuellement je ne le craint.
Post by Francois LE COAT
S'il veut lancer son logiciel sous freeMiNT, ça n'est pas recommandé !
Et même s'il a une bonne raison, elle n'est vraiment pas admissible.
On peut appeler Syield() de temps en temps toutes les 10ms le multitâche sera préservé normalement.

OL
Vincent Rivière
2020-01-05 20:58:48 UTC
Permalink
Post by Arachide
FreeMint semble bloquer la mise à jour de la variable KBSHIFT (celle qui
contient l'état des touches spéciales: Shift, Control, Alt, Caps Lock)
lorsqu'on est en superviseur.
FreeMiNT ignore toutes les frappes au clavier quand on est en mode
superviseur. C'est particulièrement gênant quand on utilise GEM=ROM :
impossible de créer un dossier depuis le bureau.

En fait, FreeMiNT a besoin du multitâche pour gérer le clavier. Mais le
multitâche est désactivé en mode superviseur. Donc en pratique, le clavier
ne fonctionne pas en mode superviseur. C'est un choix assez déplorable. Je
pense que le seul intérêt de ce comportement est d'éviter de planter le
système si le programme qui est en mode superviseur a une pile trop petite
pour appeler le gestionnaire d'interruption clavier de FreeMiNT. J'ai déjà
essayé de modifier FreeMiNT pour qu'il appelle sa routine de gestion du
clavier directement, sans passer par le multitâche. Dans ce cas le clavier
marche très bien, même avec GEM=ROM. Je pense que ça devrait être le
comportement par défaut. Ou au moins, être configurable.
--
Vincent Rivière
Arachide
2020-01-05 21:11:00 UTC
Permalink
Post by Vincent Rivière
Post by Arachide
FreeMint semble bloquer la mise à jour de la variable KBSHIFT (celle
qui contient l'état des touches spéciales: Shift, Control, Alt, Caps
Lock) lorsqu'on est en superviseur.
FreeMiNT ignore toutes les frappes au clavier quand on est en mode
impossible de créer un dossier depuis le bureau.
En fait, FreeMiNT a besoin du multitâche pour gérer le clavier. Mais le
multitâche est désactivé en mode superviseur. Donc en pratique, le
clavier ne fonctionne pas en mode superviseur. C'est un choix assez
déplorable. Je pense que le seul intérêt de ce comportement est d'éviter
de planter le système si le programme qui est en mode superviseur a une
pile trop petite pour appeler le gestionnaire d'interruption clavier de
FreeMiNT. J'ai déjà essayé de modifier FreeMiNT pour qu'il appelle sa
routine de gestion du clavier directement, sans passer par le
multitâche. Dans ce cas le clavier marche très bien, même avec GEM=ROM.
Je pense que ça devrait être le comportement par défaut. Ou au moins,
être configurable.
Suis très d'accord avec toi.

Dommage vraiment.

Guillaume.
Loading...