gratifiant > comp.sys.* > comp.sys.atari

ol.google (05/10/2019, 17h48)
Bonjour

nouvelle version de myhatari, la config multitâche avec Mint et MyAES directement sur le système de fichier hôte sans disque virtuel.

La mise à jours porte sur MyAES qui apportes plusieurs corrections de bugs et surtout de nouvelles fonctionnalités les principales sont:

- Un mode de fonctionnement une application par écran (via mot clef smartphone_gui = true ou false (par défaut false))
- Un mode d'isolement d'applications qui s'accaparent un peu l'écran avec menu à la TOS non rétractables (configurable via mot clef APP_SINGLE nomdelapplication)
- Cyclage des applications via CTRL+ALT+n ou sur un vrai Atari CTRL+ALT+TAB

Corrections de bugs:
-Réécriture du gestionnaire de Focus bien plus rapide et fiable maintenant
-Amélioration gestion curseur dans champs éditables (fix pour Qeden acceptant une extension de Magic)
-Taille mémoire copie écran trop petit si écran non multiplede 16 en pixels en largeur (configuration assez rare!)
-Correction possible non réception MU_M1 MU_M2 suivant évènements attendus.

Version compilée sous Atari avec GCC 7

Voilà toujours au même endroit

Olivier
ol.google (09/10/2019, 23h58)
Le samedi 5 octobre 2019 17:48:02 UTC+2, ol.g...@lutece.net a écrit :
[..]
> Version compilée sous Atari avec GCC 7
> Voilà toujours au même endroit
> Olivier


Mise à jours pour corriger quelques gros bugs et accélérer, je crois que je vais me calmer sur les mises à jours maintenant pour avancer sur les fonctionnalités.
Francois LE COAT (10/10/2019, 18h02)
Salut,

ol écrit :
> Mise à jours pour corriger quelques gros bugs et accélérer, je crois que je vais me calmer sur les mises à jours maintenant pour avancersur les fonctionnalités.


Eurêka 2.12 fonctionne mieux avec la bonne option "APP_SINGLE EUREKA",
mais il ne fonctionne pas parfaitement, car il me semble qu'il perd le
focus en permanence. Voir la vidéo <http://eureka.atari.org/myaes.mp4>

J'espère que ça peut aider ...
Francois LE COAT (10/10/2019, 22h38)
Salut,

ol écrit :
> Eurêka 2.12 fonctionne mieux avec la bonne option "APP_SINGLE EUREKA",
> mais il ne fonctionne pas parfaitement, car il me semble qu'il perd le
> focus en permanence. Voir la vidéo <http://eureka.atari.org/myaes.mp4>
> J'espère que ça peut aider ...


Pour comprendre la vidéo, voila ce qui devrait se passer :

<http://www.youtube.com/watch?v=9eVht_EDXSk>

C'est à dire que le fichier d'évènements "EUREKA.REC" est chargé et
rejoué, avec l'accessoire "RECORD.ACC". C'est une chose que l'on peut
faire sur toutes les machines ATARI, et aussi avec MagiC. Mais ça ne
marche pas avec EmuTOS, qui n'implémente pas cette fonctionnalité.
Vincent Rivière (11/10/2019, 21h27)
Le 10/10/2019 à 22:38, Francois LE COAT a écrit :
> C'est à dire que le fichier d'évènements "EUREKA.REC" est chargé et
> rejoué, avec l'accessoire "RECORD.ACC". C'est une chose que l'on peut
> faire sur toutes les machines ATARI, et aussi avec MagiC. Mais ça ne
> marche pas avec EmuTOS, qui n'implémente pas cette fonctionnalité.


Les fonctions appl_trecord() et appl_tplay() ont été corrigées dans EmuTOS
0.9.10 qui est sorti fin 2018.

Concernant RECORD.ACC: il apparait que les touches du clavier utilisées pour
déclencher le démarrage et l'arrêt de l'enregistrement fonctionnent très mal
avec EmuTOS. Il a sans aucun doute un bug quelque part. L'équipe de
développement d'EmuTOS va mener l'enquête, et si le bug se situe dans
EmuTOS, il sera corrigé.

Il ne faut pas hésiter à rapporter les problèmes concernant EmuTOS, car nous
faisons tout ce qui est possible pour corriger ses bugs.
Francois LE COAT (11/10/2019, 22h15)
Salut,

Vincent écrit :
> Francois écrit :
> Les fonctions appl_trecord() et appl_tplay() ont été corrigées dans
> EmuTOS 0.9.10 qui est sorti fin 2018.
> Concernant RECORD.ACC: il apparait que les touches du clavier utilisées
> pour déclencher le démarrage et l'arrêt de l'enregistrement fonctionnent
> très mal avec EmuTOS. Il a sans aucun doute un bug quelque part.
> L'équipe de développement d'EmuTOS va mener l'enquête, et si le bug se
> situe dans EmuTOS, il sera corrigé.
> Il ne faut pas hésiter à rapporter les problèmes concernant EmuTOS, car
> nous faisons tout ce qui est possible pour corriger ses bugs.


Ce genre de problème, ça fait des dizaines d'années que j'en parle ...

Ici, en 2003 :

<https://mikro.naprvyraz.sk/mint/200304/msg00059.html>

Il me semble avoir affaire à des gens qui ne comprennent pas. Parce
que même si EmuTOS implémente maintenant ces fonctions, à quoi ça
sert, puisque XaAES ne les implémente pas ? La plupart des gens qui
développent, ne connaissent que très peu l'usage des machines ATARI.
Et moi, qui les ai pas mal utilisées, personne ne le comprend.

Il y a un gros problème actuel avec les développements ATARI. Les
machines physiques et les gens compétents ne se rencontrent plus.

ATARIstiquement vôtre =)
pehache (12/10/2019, 07h57)
Le 11/10/2019 à 22:15, Francois LE COAT a écrit :

> Il me semble avoir affaire à des gens qui ne comprennent pas.


Tu es vraiment imbuvable...
Arachide (12/10/2019, 09h41)
Le 11/10/2019 à 22:15, Francois LE COAT a écrit :

> Il me semble avoir affaire à des gens qui ne comprennent pas. Parce
> que même si EmuTOS implémente maintenant ces fonctions, à quoi ça
> sert, puisque XaAES ne les implémente pas ? La plupart des gens qui
> développent, ne connaissent que très peu l'usage des machines ATARI.
> Et moi, qui les ai pas mal utilisées, personne ne le comprend.
> Il y a un gros problème actuel avec les développements ATARI. Les
> machines physiques et les gens compétents ne se rencontrent plus.
> ATARIstiquement vôtre =)


Avec un doctorat, 30 ans de langage "C" et de développement Atari, tu
devrais pouvoir débugger les sources d'EmuTOS.
Si tu ne le fais pas, comment veux tu que les gens compétents
rencontrent les machines physiques?

Guillaume.
Simon (12/10/2019, 10h08)
Le 11/10/2019 22:15, Francois LE COAT a écrit :
>> Il ne faut pas hésiter à rapporter les problèmes concernant EmuTOS,
>> car nous faisons tout ce qui est possible pour corriger ses bugs.

> Ce genre de problème, ça fait des dizaines d'années que j'en parle
> ...


Et des dizaines d'années que tu te plains, que ça te gêne, mais que tu
ne fais rien.
Et donc cela fait des dizaines d'années que plus personne ne te prend au
sérieux, avec tes contribution se résumant à des vidéos de tarte à la
crème, des consoles de jeu sans rapport, et des délires parano haineux
ou méprisants quotidiens, envers tel programme, telle personne, tel
matériel ou tel site web.

> Il me semble avoir affaire à des gens qui ne comprennent pas.


Délire parano haineux ou méprisant quotidien, cqfd.

> Parce que même si EmuTOS implémente maintenant ces fonctions, à quoi
> ça sert, puisque XaAES ne les implémente pas ? La plupart des gens
> qui développent, ne connaissent que très peu l'usage des machines
> ATARI. Et moi, qui les ai pas mal utilisées, personne ne le comprend.


Ta dernière phrase est mal écrite. Donc effectivement, tu t'exprimes
tellement mal, que ça doit être difficile de comprendre ce que tu remontes.
Tout en sachant qu'on va ensuite se prendre un délire méprisant dans la
tronche.

> Il y a un gros problème actuel avec les développements ATARI. Les
> machines physiques et les gens compétents ne se rencontrent plus.


Délire méprisant, cqfd bis.
Francois LE COAT (12/10/2019, 10h15)
Salut,

Arachide écrit :
> Avec un doctorat, 30 ans de langage "C" et de développement Atari, tu
> devrais pouvoir débugger les sources d'EmuTOS.
> Si tu ne le fais pas, comment veux tu que les gens compétents
> rencontrent les machines physiques?
> Guillaume.


EmuTOS implémente les appels appl_trecord() et appl_tplay(), c'est ce
que dit Vincent. C'est très bien, car cela est conforme au TOS et à
MagiC. La preuve, c'est que la même chose fonctionne ...

sous STonX/TOS : <https://www.youtube.com/watch?v=qt68Mm3P9QM>
sous Hatari/TOS : <https://www.youtube.com/watch?v=VLRjQ4wAatM>
sous ARAnyM/TOS : <https://www.youtube.com/watch?v=CN0X0s8O_mI>
sous MagiC/AtariX : <https://www.youtube.com/watch?v=9eVht_EDXSk>

Le problème actuel que je constate, et dont je parle (depuis des
dizaines d'années), c'est que ni XaAES, ni MyAES ne le gèrent.
Pour MyAES, nous n'en sommes vraiment pas loin. Mais Olivier avec
qui je discute de cela depuis 20 ans, ne m'a pas encore compris.

Et moi, j'aimerais bien que cela fonctionne ... Mais ma compétence,
ce sont les applications ATARI. Je ne suis pas compétent avec la
programmation du système. J'ai une certaine expérience de l'usage
des machines, je les utilise et je les programme, mais je ne les
conçois pas. C'est un savoir faire différent.

Alors, j'essaye de me faire comprendre des gens qui conçoivent le
système ... Mais j'ai du mal. C'est un savoir-faire perdu ... ?
ol.google (12/10/2019, 14h29)
Le samedi 12 octobre 2019 10:15:12 UTC+2, Francois LE COAT a écrit :
[..]
> conçois pas. C'est un savoir faire différent.
> Alors, j'essaye de me faire comprendre des gens qui conçoivent le
> système ... Mais j'ai du mal. C'est un savoir-faire perdu ... ?


Bon on va être précis, parce que ta mémoire flanche, le replay dans MyAES a fonctionné parfaitement il y a très longtemps, tuas oublié, c'était avant que l'on soit faché, quand tu m'appelais chez moi pour me reporter tous les soucis que tu avais avec Eureka que j'ai corrigé patiemment à l'époque alors que j'avais d'autres bugs bien plus importants à corriger. Le record n'a jamais fonctionné correctement à cause de l'enregistrement des clicks mais boncorrigeable. Si aujourd'hui cela ne fonctionne pas c'est tout bonnement car ces 10 dernières années je n'ai pas testé appl_tplay, car à part Eureka je ne connais aucun soft qui l'utilise! et que j'ai toutchangé dans le noyau depuis et que cela ne peut plus bien fonctionneret je ne sais fichtrement pas si j'arriverais à corriger sans risquerd'introduire de gros bugs dans le noyau qui est bien plus complexe que dans le passé. Maintenant si les sources de l'accessoire étaient disponibles on aurait peut être plus facilement comprendre même si je pense que à part faire un appl_tplay() pour la relecture il ne doit pas faire grand chose d'autre à moins que je me trompe je n'ai pas tracé j'avoue.

Sinon pour expliquer ce système est totalement inadapté, ce n'estpas de ta faute mais bien celui de ceux qui l'ont construit, plutôt que d'avoir un système de script certes plus complexe mais qui serait pérenne dans le temps appl_tplay() n'est qu'une suite de mouvement de souris, de clicks souris et de timer, il n'y a rien d'autre et ce concept est inepte, un truc peu gourmand en développement et on peut comprendre le choix pour le TOS, seulement voilà l'informatique a beaucoup évolué et cela ne correspond plus à l'évolution hardware. Explications:
Pour que cela fonctionne cela suppose plusieurs choses:
- que l'application se considère comme toute seule (sous TOS c'est le cas et Eureka y croit dur comme fer à grand coups de wind_update(MCTRL), bref plus de système multitâche. Ce n'est pas une erreur de programmation de ta part mais une erreur de conception du système qui n'a pas prévu le multitache multi application. Cela déjà psychologiquement pour les programmeurs qui font un AES pour un environnement multitâche c'est difficile à avaler, NAES ne le supporte pas (cela a été pourtant l'AES phare pour Mint), XaAES ne le supporte pas non plus, MyAES a maintenant des soucis avec (en fait juste avec les clicks sur les menus déroulants), Oaesis ne supporte pas, reste le cas Magic et Multitos j'ai vérifié cela fonctionne (mais bon dieu qu'il estlent celui là). Bon sur ce point on peut trouver des artifices, l'option que j'ai ajouté est une solution mais il y a encore une petite modif à faire car j'ai introduit un bug stupide.
- La seconde raison bien plus importante est un problème de pérennité de la solution, elle n'est pas viable à long terme car pour que cela marche elle suppose que les objets aient exactement la même taille à la même position, mais ils n'ont pas forcément la même taille et la même position, ce second point tu le gères,mais la taille tu ne peux strictement rien y faire parce que les ressources sont enregistrés en format indépendant ou on ne donne pas la taille en pixels mais en taille de cellule et cette taille de cellule est calculée par l'AES en fonction de la résolution écran et pourquoi pas dans quelques temps en fonction de l'utilisateur, et cela est très intelligent comme façon de faire sinon il n'aurait jamais été possible d'avoir des résolution en STLow et STMed avec AES comparé à la STHigh car la police de la STHigh aurait été trop grosse pour les basses résolutions pour pouvoir afficher quoi que ce soit et inversement la police de la STLow aurait été illisibleen STHigh. Aujourd'hui tous les AES se basent sur la police de la STHigh la densité de pixels n'a pas tant varié depuis l'époque, il ya plus de pixels mais les écran ont grandi, ceci dit quand on voit ladensité de pixels des nouveaux smartphone, la 4K voir la 8K, la donneest en train de changer on sera à plus ou moins long terme obligé de changer la taille de police et par la mème la taille des objets.. Tout cela pour dire qu'un script n'est pas portable par principe d'une machine à l'autre malgré tous les efforts que l'on pourra faire.
On voit dans tes démos la limite du système, par exemple pour le sélecteur de fichier tu le commandes au clavier, normal d'un sélecteur à l'autre il n'a pas le même format et les données surle disque pourraient varier, le système est plein de limites comme cela. La seule chose qui pourrait être assuré c'est que l'on puisseenregistrer et relire les évènements dans une même configuration au delà cela marche par similitude mais pas plus. Dans le cas deMyAES le soucis n'est pas là le problème est interne je ne le nie pas, mais trouver des bonnes âmes pour modifier un AES comme XaAES pour un seul gars, un seul soft, il n'y a qu'une personne que cela pourrait motiver je pense c'est toi, il y a 15 ans je te disais déjà cela!Le système appl_tplay est ultra simple par contre l'implémentation dans le noyau d'un AES multitâche cela peut se révéler compliqué, car un noyau d'AES cela ne pense qu'a une chose quand on y touche c'est de ne plus fonctionner!

J'espère avoir bien décrit la situation technique, ce n'est pas un problème de savoir perdu.

OL
ol.google (12/10/2019, 23h33)
Finalement j'aurais eu la peau au soucis de clicks dans appl_tplay cela marche comme il se doit.
Reste une incompatibilité avec le sélecteur de fichier (externe j'y toucherais pas, mais celui interne qui ressemble à m'original il n'y a juste que la gestion du '.' qui ne fonctionne pas.
3D.rec passe entièrement n'utilisant pas le sélecteur passe entièrement.

Toujours un petit soucis de focus au tout départ pour demander à Eureka de charger le .rec via la touche 'L' après avoir sélectionner l'accessoire "record.acc" curieux pas le soucis sous Aranym et soucis sous Hatari, un soucis de timing.
Restera à corriger l'appl_trecord si j'ai un peu de courage un jours.
Pas de mise à jours publique, je t'ai envoyé une version, je ne l'ai pas testé beaucoup, je suis absent plusieurs jours et je vais être beaucoup plus pris dans les semaines à venir.

OL
ol.google (13/10/2019, 08h35)
Tiens en le faisant fonctionner il y a un truc quand même assez extraordinaire dans l'histoire, si l'implémentation n'est pas foireuse, appl_tplay et appl_trecord sont bels et biens bloquants, je me trompe ? Ce qui est stupide sous TOS vu qu'il n'est pas multitâche multithread, tu as contourné le problème en utilisant un accessoire, ce qui est sensé, je ne vois pas comment on pourrait faire autrement. Atari aurait dû fournir ce genre d'accessoire pour accompagner sinon c'est inutilisable, on comprend mieux pourquoi cela n'a pas été utilisé.

Si on en revient à Eureka, du coup tu as créé un accessoire pour toi, sous TOS le nombre d'accessoire est très limité, sur système moderne on s'en fout mais je ne vois pas pourquoi j'installeraisun accessoire spécifique pour un logiciel unique, qui je pense même si on avait l'utilisation ne pourrait fonctionner que pour Eureka, ceci dit si tu voulais faire un truc sans doute qui ne sera pas utilisé mais tout de même utile dès fois que, tu pourrais très bien je pense fournir le protocole de discussion avec l'accessoire et le rendre si ce n'est pas déjà fait non spécifique à Eureka. Voilà une bonne oeuvre.
Autre point d'amélioration si l'accessoire n'est pas présent tu pourrais tout simplement le faire charger par le système et à la fin lui demander de quitter, c'est très simple à faire sur un AES moderne et sur le TOS cela n'aura aucun effet suffit de faire:
Pour charger : shel_write(SWM_LAUNCHACC,..,..,"reccord.acc",..... .)
Pour décharger : appl_write() avec un message AP_TERM que ton accessoire supportera.

OL
Francois LE COAT (13/10/2019, 11h40)
Salut,

ol écrit :
> Finalement j'aurais eu la peau au soucis de clicks dans appl_tplay celamarche comme il se doit.
> Reste une incompatibilité avec le sélecteur de fichier (externe j'ytoucherais pas, mais celui interne qui ressemble à m'original il n'y ajuste que la gestion du '.' qui ne fonctionne pas.
> 3D.rec passe entièrement n'utilisant pas le sélecteur passe entièrement.
> Toujours un petit soucis de focus au tout départ pour demander à Eureka de charger le .rec via la touche 'L' après avoir sélectionner l'accessoire "record.acc" curieux pas le soucis sous Aranym et soucis sous Hatari, un soucis de timing.
> Restera à corriger l'appl_trecord si j'ai un peu de courage un jours.
> Pas de mise à jours publique, je t'ai envoyé une version, je ne l'ai pas testé beaucoup, je suis absent plusieurs jours et je vais être beaucoup plus pris dans les semaines à venir.
> OL


C'est super :-)

Merci,
Francois LE COAT (14/10/2019, 18h45)
Salut,

ol écrit :
> C'est super :-)


Alors, il y a deux problèmes majeurs avec le test de myHatari, tel que
je l'ai testé, avec la mise à jour de "myaes68k.prg".

Pour le fichier d'évènements "eureka.rec" le sélecteur de fichier de
Eric Reboux n'est pas conforme au fonctionnement de celui du TOS, et
lorsque je le désactive, celui par défaut ne l'est pas non plus. J'ai
essayé d'installer Boxkite, dans le dossier "AUTO", en le lançant en TSR
à partir de "myaes.cnf", ou sans la commande TSR, mais ça ne marche pas.

Pour le fichier d'évènement "3d.rec", comme j'utilise avec myHatari un
Falcon030 boosté, la machine émulée n'est pas assez rapide, et les
évènements se déroulent trop rapidement par rapport à la cadence CPU.

Il aurait fallu que je teste dans une configuration similaire, avec
ARAnyM qui est beaucoup plus rapide. Tu as sans doute testé toi-même ?

Enfin, le rejeu de séquences qui ont été enregistrées sur mon Falcon030
n'est pas concluant. Il faudrait sans doute enregistrer une séquence,
et la rejouer dans les mêmes conditions, ça serait plus concluant ...?

En tous cas, merci. Si tu arrives après appl_tplay(), à ce que
appl_trecord() fonctionne, je pourrai sans doute mettre au point une
séquence de rejeu qui puisse fonctionner avec ta configuration myHatari.

À voir ...

Discussions similaires