Je me pose des questions sur la manière dont les systèmes GNU/Linux
(ou BSD...) gère l'affichage graphique. La couche basse est
le serveur Xorg mais qu'elle est son role?
Après il y a un gestionnaire de fenêtre? Puis de bureau
(KDE, Gnome)? Ou se situe Compiz la dedans? J'utlise
gnome (car je n'ai pas réussi à avoir une barre
de tache par écran sous KDE et j'ai deux écrans).
J'utlise souvent des programmes KDE (Dolphin & K3B)
qui marche bien sous gnome...
Si vous avez une référence sur la la manière dont
sont organisées ces différentes couches...
Dans le genre: ça ne sert à rien mais c'est marrant
j'ai lancé la lecture de 3 divx avec mplayer: 1 sur
chaqu'un des deux écrans du bureau un et un autre sur un des écrans
du bureau deux. Quand on fait tourner le cube de compiz
(un cube par écran) les trois restent fluides... On peut
faire ça avec windows?
Tanguy Briançon , dans le message <4f1c3d54$0$6544$, a écrit :
J'ai deux écrans physique mais je n'ai qu'une une fenetre racine?
Oui. Sauf si tu utilises le mode Zaphod, mais il n'est plus supporté par la plupart des drivers.
Non je ne pense pas: il n'est pas dans mon xorg.conf. J'utilise le driver proprio Nvidia.
(je peux mettre des fenetres à cheval sur deux écrans: sans interet mais bon).
Tu ne pourrais pas s'il y avait une fenêtre racine par écran.
C'est bien ce que je pensais. Par contre c'est le gestionnaire de fenêtre qui sait que j'ai deux écran et que quand je maximise une fenêtre il maximise sur un seul écran?
Sans doute mais je crois qu'une fois toutes les décos avait disparus: j'avais un écran noir et toutes les fenetres avaient perdus leurs décos.
Si des décorations qui étaient présentes ont disparu, c'est bizarre, parce que la session devrait se terminer avec le crash du WM.
J'avoue ne plus me souvenir assez précisément du bug... Je ne sais plus si j'avais fait un ctrl-alt-F1 pour me logguer en texte et taper halt ou bien si j'avais utiliser une méthode plus bourrin (bouton on/off).
On 22/01/2012 19:17, Nicolas George wrote:
Tanguy Briançon , dans le message
<4f1c3d54$0$6544$426a74cc@news.free.fr>, a écrit :
J'ai deux écrans physique mais je n'ai qu'une une fenetre racine?
Oui. Sauf si tu utilises le mode Zaphod, mais il n'est plus supporté par la
plupart des drivers.
Non je ne pense pas: il n'est pas dans mon xorg.conf.
J'utilise le driver proprio Nvidia.
(je peux mettre des fenetres à cheval sur deux écrans: sans interet
mais bon).
Tu ne pourrais pas s'il y avait une fenêtre racine par écran.
C'est bien ce que je pensais. Par contre c'est le gestionnaire de
fenêtre qui sait que j'ai deux écran et que quand je maximise une
fenêtre il maximise sur un seul écran?
Sans doute mais je crois qu'une fois toutes les décos avait disparus:
j'avais un écran noir et toutes les fenetres avaient perdus leurs
décos.
Si des décorations qui étaient présentes ont disparu, c'est bizarre, parce
que la session devrait se terminer avec le crash du WM.
J'avoue ne plus me souvenir assez précisément du bug... Je ne sais
plus si j'avais fait un ctrl-alt-F1 pour me logguer en texte et taper
halt ou bien si j'avais utiliser une méthode plus bourrin (bouton
on/off).
Tanguy Briançon , dans le message <4f1c3d54$0$6544$, a écrit :
J'ai deux écrans physique mais je n'ai qu'une une fenetre racine?
Oui. Sauf si tu utilises le mode Zaphod, mais il n'est plus supporté par la plupart des drivers.
Non je ne pense pas: il n'est pas dans mon xorg.conf. J'utilise le driver proprio Nvidia.
(je peux mettre des fenetres à cheval sur deux écrans: sans interet mais bon).
Tu ne pourrais pas s'il y avait une fenêtre racine par écran.
C'est bien ce que je pensais. Par contre c'est le gestionnaire de fenêtre qui sait que j'ai deux écran et que quand je maximise une fenêtre il maximise sur un seul écran?
Sans doute mais je crois qu'une fois toutes les décos avait disparus: j'avais un écran noir et toutes les fenetres avaient perdus leurs décos.
Si des décorations qui étaient présentes ont disparu, c'est bizarre, parce que la session devrait se terminer avec le crash du WM.
J'avoue ne plus me souvenir assez précisément du bug... Je ne sais plus si j'avais fait un ctrl-alt-F1 pour me logguer en texte et taper halt ou bien si j'avais utiliser une méthode plus bourrin (bouton on/off).
Tanguy Briançon
On 22/01/2012 19:18, Nicolas George wrote:
Tanguy Briançon , dans le message <4f1c446e$0$3683$, a écrit :
Hélas il n'existe pas je crois d'émulateur hp49g+/50.
Alors il faudra te bricoler ton propre environnement d'émulation : tu ne peux pas espérer tester des application prévues pour un environnement aussi étranger directement.
J'ai peur que cela dépasse largement mes (maigres...) compétances informatiques. Il faudrait d'abord un programme qui émule un processeur ARM sur x86 (cela doit exister...) puis ensuite il faut faire tourner dessus les programmes HP (proprio...). Ou alors je n'ai besoin que de choses très basiques: - creer fenêtre - tracer droite/cercle - copier coller d'une fenêtre vers une autre Si mon programme bug si une fenêtre lui passe dessus: ce n'est pas grave. Le but n'est pas une appli linux. Donc je peux me contenter d'un prog qui marche "tout seul". Mais si j'ai bien compris c'est impossible.
Finalement je vais continuer comme avant: programmer sur le PC puis tester sur la hp. Mais c'est un peu lourd.
Pour moi programmer est un hobbie donc je vais voir si j'arrive à faire quelque chose avec gtk+. (Je viens de télécharger un tuto!). En tout cas merçi pour tes réponses.
On peut avoir des discussions intelligentes sur f.c.o.l.d!
On 22/01/2012 19:18, Nicolas George wrote:
Tanguy Briançon , dans le message
<4f1c446e$0$3683$426a34cc@news.free.fr>, a écrit :
Hélas il n'existe pas je crois d'émulateur hp49g+/50.
Alors il faudra te bricoler ton propre environnement d'émulation : tu ne
peux pas espérer tester des application prévues pour un environnement aussi
étranger directement.
J'ai peur que cela dépasse largement mes (maigres...) compétances
informatiques. Il faudrait d'abord un programme qui émule un processeur
ARM sur x86 (cela doit exister...) puis ensuite il faut faire tourner
dessus les programmes HP (proprio...).
Ou alors je n'ai besoin que de choses très basiques:
- creer fenêtre
- tracer droite/cercle
- copier coller d'une fenêtre vers une autre
Si mon programme bug si une fenêtre lui passe dessus: ce n'est
pas grave. Le but n'est pas une appli linux. Donc je peux me contenter
d'un prog qui marche "tout seul". Mais si j'ai bien compris c'est
impossible.
Finalement je vais continuer comme avant:
programmer sur le PC puis tester sur la hp. Mais c'est un peu
lourd.
Pour moi programmer est un hobbie donc je vais voir si j'arrive
à faire quelque chose avec gtk+. (Je viens de télécharger un tuto!).
En tout cas merçi pour tes réponses.
On peut avoir des discussions intelligentes sur f.c.o.l.d!
Tanguy Briançon , dans le message <4f1c446e$0$3683$, a écrit :
Hélas il n'existe pas je crois d'émulateur hp49g+/50.
Alors il faudra te bricoler ton propre environnement d'émulation : tu ne peux pas espérer tester des application prévues pour un environnement aussi étranger directement.
J'ai peur que cela dépasse largement mes (maigres...) compétances informatiques. Il faudrait d'abord un programme qui émule un processeur ARM sur x86 (cela doit exister...) puis ensuite il faut faire tourner dessus les programmes HP (proprio...). Ou alors je n'ai besoin que de choses très basiques: - creer fenêtre - tracer droite/cercle - copier coller d'une fenêtre vers une autre Si mon programme bug si une fenêtre lui passe dessus: ce n'est pas grave. Le but n'est pas une appli linux. Donc je peux me contenter d'un prog qui marche "tout seul". Mais si j'ai bien compris c'est impossible.
Finalement je vais continuer comme avant: programmer sur le PC puis tester sur la hp. Mais c'est un peu lourd.
Pour moi programmer est un hobbie donc je vais voir si j'arrive à faire quelque chose avec gtk+. (Je viens de télécharger un tuto!). En tout cas merçi pour tes réponses.
On peut avoir des discussions intelligentes sur f.c.o.l.d!
Tonton Th
On 01/22/2012 10:15 AM, Tanguy Briançon wrote:
Ce n'est pas aussi compliqué au sens où tu as des toolkits qui combinent tout ça dans une interface plus facile à utiliser. Je conseille vivement Gtk+ pour ça.
Je suis d'accord, et même prendre le temps de jeter un oeil sur la couche en dessous : gdk.
Mon but n'est pas vraiment de porter mes applis sous gnu/linux (il existe déja de très bon logiciels pour cela). Mais plutot de pouvoir tester et debugger avant le transfert vers la hp. Donc je ne veux (peux) pas utiliser des librairies trop sophistiqués...
Tu peux aussi regarder http://www.libsdl.org/ qui pourrait bien être adapté à ton cas d'utilisation.
--
Nous vivons dans un monde étrange/ http://foo.bar.quux.over-blog.com/
On 01/22/2012 10:15 AM, Tanguy Briançon wrote:
Ce n'est pas aussi compliqué au sens où tu as des toolkits qui combinent
tout ça dans une interface plus facile à utiliser. Je conseille vivement
Gtk+ pour ça.
Je suis d'accord, et même prendre le temps de jeter un
oeil sur la couche en dessous : gdk.
Mon but n'est pas vraiment de porter mes applis sous gnu/linux
(il existe déja de très bon logiciels pour cela). Mais plutot
de pouvoir tester et debugger avant le transfert vers la hp. Donc
je ne veux (peux) pas utiliser des librairies trop sophistiqués...
Tu peux aussi regarder http://www.libsdl.org/ qui pourrait
bien être adapté à ton cas d'utilisation.
--
Nous vivons dans un monde étrange/
http://foo.bar.quux.over-blog.com/
Ce n'est pas aussi compliqué au sens où tu as des toolkits qui combinent tout ça dans une interface plus facile à utiliser. Je conseille vivement Gtk+ pour ça.
Je suis d'accord, et même prendre le temps de jeter un oeil sur la couche en dessous : gdk.
Mon but n'est pas vraiment de porter mes applis sous gnu/linux (il existe déja de très bon logiciels pour cela). Mais plutot de pouvoir tester et debugger avant le transfert vers la hp. Donc je ne veux (peux) pas utiliser des librairies trop sophistiqués...
Tu peux aussi regarder http://www.libsdl.org/ qui pourrait bien être adapté à ton cas d'utilisation.
--
Nous vivons dans un monde étrange/ http://foo.bar.quux.over-blog.com/
Tonton Th
On 01/22/2012 08:22 PM, Tanguy Briançon wrote:
Pour moi programmer est un hobbie donc je vais voir si j'arrive à faire quelque chose avec gtk+. (Je viens de télécharger un tuto!). En tout cas merçi pour tes réponses.
Et ce serait bien kw0l si tu publiait les résultats de tes expérimentations. Je suppose que nous ne sommes pas les seuls à avoir eu envie de faire ça un jour.
--
Nous vivons dans un monde étrange/ http://foo.bar.quux.over-blog.com/
On 01/22/2012 08:22 PM, Tanguy Briançon wrote:
Pour moi programmer est un hobbie donc je vais voir si j'arrive
à faire quelque chose avec gtk+. (Je viens de télécharger un tuto!).
En tout cas merçi pour tes réponses.
Et ce serait bien kw0l si tu publiait les résultats de
tes expérimentations. Je suppose que nous ne sommes pas
les seuls à avoir eu envie de faire ça un jour.
--
Nous vivons dans un monde étrange/
http://foo.bar.quux.over-blog.com/
Pour moi programmer est un hobbie donc je vais voir si j'arrive à faire quelque chose avec gtk+. (Je viens de télécharger un tuto!). En tout cas merçi pour tes réponses.
Et ce serait bien kw0l si tu publiait les résultats de tes expérimentations. Je suppose que nous ne sommes pas les seuls à avoir eu envie de faire ça un jour.
--
Nous vivons dans un monde étrange/ http://foo.bar.quux.over-blog.com/
Tanguy Briançon
On 22/01/2012 20:42, Tonton Th wrot> On 01/22/2012 10:15 AM, Tanguy Briançon wrote:
Ce n'est pas aussi compliqué au sens où tu as des toolkits qui combinent tout ça dans une interface plus facile à utiliser. Je conseille vivement Gtk+ pour ça.
Je suis d'accord, et même prendre le temps de jeter un oeil sur la couche en dessous : gdk.
Je vais voir aussi (mais je bosse donc je n'ai pas un temps infinie...)
Mon but n'est pas vraiment de porter mes applis sous gnu/linux (il existe déja de très bon logiciels pour cela). Mais plutot de pouvoir tester et debugger avant le transfert vers la hp. Donc je ne veux (peux) pas utiliser des librairies trop sophistiqués...
Tu peux aussi regarder http://www.libsdl.org/ qui pourrait bien être adapté à ton cas d'utilisation.
Même remarque que ci-dessus je vais aller voir. J'ai fait des programmes pour Apple 2e et hp48/49/49G en basic puis en assembleur (y compris en assemblant à la main!).
On 22/01/2012 20:42, Tonton Th wrot> On 01/22/2012 10:15 AM, Tanguy
Briançon wrote:
Ce n'est pas aussi compliqué au sens où tu as des toolkits qui combinent
tout ça dans une interface plus facile à utiliser. Je conseille vivement
Gtk+ pour ça.
Je suis d'accord, et même prendre le temps de jeter un
oeil sur la couche en dessous : gdk.
Je vais voir aussi (mais je bosse donc je n'ai pas un temps
infinie...)
Mon but n'est pas vraiment de porter mes applis sous gnu/linux
(il existe déja de très bon logiciels pour cela). Mais plutot
de pouvoir tester et debugger avant le transfert vers la hp. Donc
je ne veux (peux) pas utiliser des librairies trop sophistiqués...
Tu peux aussi regarder http://www.libsdl.org/ qui pourrait
bien être adapté à ton cas d'utilisation.
Même remarque que ci-dessus je vais aller voir.
J'ai fait des programmes pour Apple 2e et hp48/49/49G en basic
puis en assembleur (y compris en assemblant à la main!).
On 22/01/2012 20:42, Tonton Th wrot> On 01/22/2012 10:15 AM, Tanguy Briançon wrote:
Ce n'est pas aussi compliqué au sens où tu as des toolkits qui combinent tout ça dans une interface plus facile à utiliser. Je conseille vivement Gtk+ pour ça.
Je suis d'accord, et même prendre le temps de jeter un oeil sur la couche en dessous : gdk.
Je vais voir aussi (mais je bosse donc je n'ai pas un temps infinie...)
Mon but n'est pas vraiment de porter mes applis sous gnu/linux (il existe déja de très bon logiciels pour cela). Mais plutot de pouvoir tester et debugger avant le transfert vers la hp. Donc je ne veux (peux) pas utiliser des librairies trop sophistiqués...
Tu peux aussi regarder http://www.libsdl.org/ qui pourrait bien être adapté à ton cas d'utilisation.
Même remarque que ci-dessus je vais aller voir. J'ai fait des programmes pour Apple 2e et hp48/49/49G en basic puis en assembleur (y compris en assemblant à la main!).
Nicolas George
Tanguy Briançon , dans le message <4f1c573f$0$6179$, a écrit :
C'est bien ce que je pensais. Par contre c'est le gestionnaire de fenêtre qui sait que j'ai deux écran et que quand je maximise une fenêtre il maximise sur un seul écran?
Oui. Mais ça se limite à une fonction qui lui indique les coordonnées des divers rectangles de la fenêtre qui sont représentés par chaque écran.
Tanguy Briançon , dans le message
<4f1c573f$0$6179$426a34cc@news.free.fr>, a écrit :
C'est bien ce que je pensais. Par contre c'est le gestionnaire de
fenêtre qui sait que j'ai deux écran et que quand je maximise une
fenêtre il maximise sur un seul écran?
Oui. Mais ça se limite à une fonction qui lui indique les coordonnées des
divers rectangles de la fenêtre qui sont représentés par chaque écran.
Tanguy Briançon , dans le message <4f1c573f$0$6179$, a écrit :
C'est bien ce que je pensais. Par contre c'est le gestionnaire de fenêtre qui sait que j'ai deux écran et que quand je maximise une fenêtre il maximise sur un seul écran?
Oui. Mais ça se limite à une fonction qui lui indique les coordonnées des divers rectangles de la fenêtre qui sont représentés par chaque écran.
nshag
On 22 jan, 19:22, Tanguy Briançon wrote:
On peut avoir des discussions intelligentes sur f.c.o.l.d!
certes mais c'est pas fait pour ça, t'es completement off-topics :]
On 22 jan, 19:22, Tanguy Briançon <briancon_tan...@yahoo.fr> wrote:
On peut avoir des discussions intelligentes sur f.c.o.l.d!
certes mais c'est pas fait pour ça,
t'es completement off-topics :]
Tu peux aussi regarder http://www.libsdl.org/ qui pourrait bien être adapté à ton cas d'utilisation.
et encore un truc : http://g2.sourceforge.net/
--
Nous vivons dans un monde étrange/ http://foo.bar.quux.over-blog.com/
Nicolas George
Tanguy Briançon , dans le message <4f1c623c$0$30996$, a écrit :
J'ai peur que cela dépasse largement mes (maigres...) compétances informatiques. Il faudrait d'abord un programme qui émule un processeur ARM sur x86 (cela doit exister...) puis ensuite il faut faire tourner dessus les programmes HP (proprio...).
Je ne pense pas que tu aies besoin de tout ça pour développer tes programmes. Si tu programmes en C proprement, tu n'as même pas besoin d'émuler le processeur, le compilateur se chargera du boulot.
Je n'ai programmé sur HP qu'il y a longtemps et pas de manière très approfondie, mais il me semble que sur ce genre d'appareil, la manière normale de programmer efficacement est de taper directement dans la mémoire vidéo et les registres des périphériques.
Dans ces conditions, ce dont tu as besoin pour tester tes programmes, c'est d'une sorte de serveur d'écran de HP : un programme qui propose un segment de mémoire partagée représentant la mémoire vidéo et qui se charge de l'afficher périodiquement sur X11. Et dans l'autre sens, qui transmette les touches clavier, en les traduisant en des codes similaires à ceux de la calculatrice ; ce n'est pas très grave si tu utilises une fonction de lecture de touche différente entre les deux environnements.
En bonus, si ça fonctionne comme serveur, tu peux faire tourner le programme à tester sous Valgrind en permanence, ce qui a deux bonus : tu augmentes les chances qu'il soit en C assez portable pour tourner sur ARM, et le coût de Valgrind en vitesse doit faire approcher de la vitesse de l'ARM.
Tanguy Briançon , dans le message
<4f1c623c$0$30996$426a74cc@news.free.fr>, a écrit :
J'ai peur que cela dépasse largement mes (maigres...) compétances
informatiques. Il faudrait d'abord un programme qui émule un processeur
ARM sur x86 (cela doit exister...) puis ensuite il faut faire tourner
dessus les programmes HP (proprio...).
Je ne pense pas que tu aies besoin de tout ça pour développer tes
programmes. Si tu programmes en C proprement, tu n'as même pas besoin
d'émuler le processeur, le compilateur se chargera du boulot.
Je n'ai programmé sur HP qu'il y a longtemps et pas de manière très
approfondie, mais il me semble que sur ce genre d'appareil, la manière
normale de programmer efficacement est de taper directement dans la mémoire
vidéo et les registres des périphériques.
Dans ces conditions, ce dont tu as besoin pour tester tes programmes, c'est
d'une sorte de serveur d'écran de HP : un programme qui propose un segment
de mémoire partagée représentant la mémoire vidéo et qui se charge de
l'afficher périodiquement sur X11. Et dans l'autre sens, qui transmette les
touches clavier, en les traduisant en des codes similaires à ceux de la
calculatrice ; ce n'est pas très grave si tu utilises une fonction de
lecture de touche différente entre les deux environnements.
En bonus, si ça fonctionne comme serveur, tu peux faire tourner le programme
à tester sous Valgrind en permanence, ce qui a deux bonus : tu augmentes les
chances qu'il soit en C assez portable pour tourner sur ARM, et le coût de
Valgrind en vitesse doit faire approcher de la vitesse de l'ARM.
Tanguy Briançon , dans le message <4f1c623c$0$30996$, a écrit :
J'ai peur que cela dépasse largement mes (maigres...) compétances informatiques. Il faudrait d'abord un programme qui émule un processeur ARM sur x86 (cela doit exister...) puis ensuite il faut faire tourner dessus les programmes HP (proprio...).
Je ne pense pas que tu aies besoin de tout ça pour développer tes programmes. Si tu programmes en C proprement, tu n'as même pas besoin d'émuler le processeur, le compilateur se chargera du boulot.
Je n'ai programmé sur HP qu'il y a longtemps et pas de manière très approfondie, mais il me semble que sur ce genre d'appareil, la manière normale de programmer efficacement est de taper directement dans la mémoire vidéo et les registres des périphériques.
Dans ces conditions, ce dont tu as besoin pour tester tes programmes, c'est d'une sorte de serveur d'écran de HP : un programme qui propose un segment de mémoire partagée représentant la mémoire vidéo et qui se charge de l'afficher périodiquement sur X11. Et dans l'autre sens, qui transmette les touches clavier, en les traduisant en des codes similaires à ceux de la calculatrice ; ce n'est pas très grave si tu utilises une fonction de lecture de touche différente entre les deux environnements.
En bonus, si ça fonctionne comme serveur, tu peux faire tourner le programme à tester sous Valgrind en permanence, ce qui a deux bonus : tu augmentes les chances qu'il soit en C assez portable pour tourner sur ARM, et le coût de Valgrind en vitesse doit faire approcher de la vitesse de l'ARM.
Tanguy Briançon
On 23/01/2012 12:03, Nicolas George wrote:
Tanguy Briançon , dans le message <4f1c623c$0$30996$, a écrit :
J'ai peur que cela dépasse largement mes (maigres...) compétances informatiques. Il faudrait d'abord un programme qui émule un processeur ARM sur x86 (cela doit exister...) puis ensuite il faut faire tourner dessus les programmes HP (proprio...).
Je ne pense pas que tu aies besoin de tout ça pour développer tes programmes. Si tu programmes en C proprement, tu n'as même pas besoin d'émuler le processeur, le compilateur se chargera du boulot.
Oui c'est ce que je pense depuis le début...
Je n'ai programmé sur HP qu'il y a longtemps et pas de manière très approfondie, mais il me semble que sur ce genre d'appareil, la manière normale de programmer efficacement est de taper directement dans la mémoire vidéo et les registres des périphérique
C'est un peu le "taper dans la mémoire vidéo" qui pose problème. Sur les hp ancien modèle (28 ?,48s(x),g(x),49g). Il n'y avait pas de mémoire vidéo dédié: elle était commune avec la mémoire centrale. On allouait une partie de la mémoire pour creer une "zone video" de taille quelconque. Des addresses dans une partie spéciale de la ram indiquait le début de la zone et des marges gauches et droites. L'écran faisait 131*64 pixels. On pouvait allouait la place pour une image de 300*400 (ou plus) et décider quels portions de 131*64 était affichés. Cette dernière opération ce faisait en quelques cycles. Quand on voulait tracer quelques choses il fallait connaitre la taille (en octet) d'une ligne pour passer à la ligne d'en dessus ou d'en dessous.
Sur les nouveaux modèles (49g+/50) je dispose de fonctions pour reserver des zones de mémoires pour la vidéo de taille arbitraire (qui sont affichés ou pas). En pratique (en C) ce sont de simple pointeurs vers des entiers (32 bits) avec la taille d'une ligne. J'ai un pointeur vers l'écran et des routines pour coller (ou OR,XOR etc...) très rapides entre une zone graphique virtuel et l'écran réel. J'utilise la librairie ggl pour ça.
Le problème est que la partie ARM des hp49g+/50 n'est pas (par HP) ou mal documenté (par les autres)...
Dans ces conditions, ce dont tu as besoin pour tester tes programmes, c'est d'une sorte de serveur d'écran de HP : un programme qui propose un segment de mémoire partagée représentant la mémoire vidéo et qui se charge de l'afficher périodiquement sur X11.
J'ai aussi de besoin de ces segments de mémoires virtuels qui représente des graphiques (et sur lesquel on peut tracer des choses via des commandes du type draw_segment(x_0,x_1,y_0,y_1,&ecran_virtuel) et de copier/coller entre ces zones (de préférence avec gestion du clipping...).
Et dans l'autre sens, qui transmette les
touches clavier, en les traduisant en des codes similaires à ceux de la calculatrice ; ce n'est pas très grave si tu utilises une fonction de lecture de touche différente entre les deux environnements.
Non: j'imagine qu'il suffit de mettre les deux fonctions et de commenter l'une des deux. Cela soulève une autre question: sous hp je fais des commandes du genre - attends un touche et donne la moi (et ne fais rien pendant ce temps!). Dans un environement multitache si je ferme une fenêtre, X11 se souvient de la fenêtre en dessous ou il faut tout redessiner?
En bonus, si ça fonctionne comme serveur, tu peux faire tourner le programme à tester sous Valgrind en permanence, ce qui a deux bonus : tu augmentes les chances qu'il soit en C assez portable pour tourner sur ARM, et le coût de Valgrind en vitesse doit faire approcher de la vitesse de l'ARM.
Je ne connais pas Valgrind mais cela semble intéréssant dans la chasse au bugs. Pour la vitesse ce n'est pas un problème. Par contre le vrai problème se situe au niveau de la mémoire: une hp50g c'est (au maximum) 256+128 Ko de ram. Il faut donc ruser et économiser...
Le plus triste dans cette histoire est la conclusion: HP a sortie les hp49g+/50 avec un processeur ARM. Des hackers ont mis au point des manières de programmer en C dessus. J'ai "appris" le C (les bases) à cette occasion faire deux programmes qui sont très supérieurs (voir exclusifs) sur beaucoup de points à ceux fournis par Hp mais plein de bogues. Ce n'est pas mon métier...
Hp doit avoir des programmeurs de qualités, et à qui toutes les données sur le matos sont dispos. Résultats ils n'en font rien!
Ils ne fournissent même pas de documentations dignes...
Bref la mort des calculatrices HP/RPN: quelle tristesse!
Tanguy
On 23/01/2012 12:03, Nicolas George wrote:
Tanguy Briançon , dans le message
<4f1c623c$0$30996$426a74cc@news.free.fr>, a écrit :
J'ai peur que cela dépasse largement mes (maigres...) compétances
informatiques. Il faudrait d'abord un programme qui émule un processeur
ARM sur x86 (cela doit exister...) puis ensuite il faut faire tourner
dessus les programmes HP (proprio...).
Je ne pense pas que tu aies besoin de tout ça pour développer tes
programmes. Si tu programmes en C proprement, tu n'as même pas besoin
d'émuler le processeur, le compilateur se chargera du boulot.
Oui c'est ce que je pense depuis le début...
Je n'ai programmé sur HP qu'il y a longtemps et pas de manière très
approfondie, mais il me semble que sur ce genre d'appareil, la manière
normale de programmer efficacement est de taper directement dans la mémoire
vidéo et les registres des périphérique
C'est un peu le "taper dans la mémoire vidéo" qui pose problème.
Sur les hp ancien modèle (28 ?,48s(x),g(x),49g). Il n'y avait pas
de mémoire vidéo dédié: elle était commune avec la mémoire centrale.
On allouait une partie de la mémoire pour creer une "zone video" de
taille quelconque. Des addresses dans une partie spéciale de la
ram indiquait le début de la zone et des marges gauches et droites.
L'écran faisait 131*64 pixels. On pouvait allouait la place pour
une image de 300*400 (ou plus) et décider quels portions de 131*64 était
affichés. Cette dernière opération ce faisait en quelques
cycles. Quand on voulait tracer quelques choses il fallait
connaitre la taille (en octet) d'une ligne pour passer à la ligne d'en
dessus ou d'en dessous.
Sur les nouveaux modèles (49g+/50) je dispose de fonctions pour
reserver des zones de mémoires pour la vidéo de taille arbitraire
(qui sont affichés ou pas). En pratique (en C) ce sont de simple
pointeurs vers des entiers (32 bits) avec la taille
d'une ligne. J'ai un pointeur vers l'écran et des routines pour coller
(ou OR,XOR etc...) très rapides entre une zone graphique virtuel et
l'écran réel. J'utilise la librairie ggl pour ça.
Le problème est que la partie ARM des hp49g+/50 n'est pas (par HP)
ou mal documenté (par les autres)...
Dans ces conditions, ce dont tu as besoin pour tester tes programmes, c'est
d'une sorte de serveur d'écran de HP : un programme qui propose un segment
de mémoire partagée représentant la mémoire vidéo et qui se charge de
l'afficher périodiquement sur X11.
J'ai aussi de besoin de ces segments de mémoires virtuels qui
représente des graphiques (et sur lesquel on peut tracer des choses
via des commandes du type draw_segment(x_0,x_1,y_0,y_1,&ecran_virtuel)
et de copier/coller entre ces zones (de préférence avec gestion du
clipping...).
Et dans l'autre sens, qui transmette les
touches clavier, en les traduisant en des codes similaires à ceux de la
calculatrice ; ce n'est pas très grave si tu utilises une fonction de
lecture de touche différente entre les deux environnements.
Non: j'imagine qu'il suffit de mettre les deux fonctions et de
commenter l'une des deux. Cela soulève une autre question:
sous hp je fais des commandes du genre
- attends un touche et donne la moi (et ne fais rien pendant ce temps!).
Dans un environement multitache si je ferme une fenêtre, X11 se
souvient de la fenêtre en dessous ou il faut tout redessiner?
En bonus, si ça fonctionne comme serveur, tu peux faire tourner le programme
à tester sous Valgrind en permanence, ce qui a deux bonus : tu augmentes les
chances qu'il soit en C assez portable pour tourner sur ARM, et le coût de
Valgrind en vitesse doit faire approcher de la vitesse de l'ARM.
Je ne connais pas Valgrind mais cela semble intéréssant dans la
chasse au bugs. Pour la vitesse ce n'est pas un problème. Par
contre le vrai problème se situe au niveau de la mémoire: une hp50g
c'est (au maximum) 256+128 Ko de ram. Il faut donc ruser et économiser...
Le plus triste dans cette histoire est la conclusion: HP a sortie
les hp49g+/50 avec un processeur ARM. Des hackers ont mis au point
des manières de programmer en C dessus. J'ai "appris" le C (les
bases) à cette occasion faire deux programmes qui sont très supérieurs
(voir exclusifs) sur beaucoup de points à ceux fournis par Hp mais
plein de bogues. Ce n'est pas mon métier...
Hp doit avoir des programmeurs de qualités, et à qui toutes
les données sur le matos sont dispos. Résultats ils n'en font rien!
Ils ne fournissent même pas de documentations dignes...
Bref la mort des calculatrices HP/RPN: quelle tristesse!
Tanguy Briançon , dans le message <4f1c623c$0$30996$, a écrit :
J'ai peur que cela dépasse largement mes (maigres...) compétances informatiques. Il faudrait d'abord un programme qui émule un processeur ARM sur x86 (cela doit exister...) puis ensuite il faut faire tourner dessus les programmes HP (proprio...).
Je ne pense pas que tu aies besoin de tout ça pour développer tes programmes. Si tu programmes en C proprement, tu n'as même pas besoin d'émuler le processeur, le compilateur se chargera du boulot.
Oui c'est ce que je pense depuis le début...
Je n'ai programmé sur HP qu'il y a longtemps et pas de manière très approfondie, mais il me semble que sur ce genre d'appareil, la manière normale de programmer efficacement est de taper directement dans la mémoire vidéo et les registres des périphérique
C'est un peu le "taper dans la mémoire vidéo" qui pose problème. Sur les hp ancien modèle (28 ?,48s(x),g(x),49g). Il n'y avait pas de mémoire vidéo dédié: elle était commune avec la mémoire centrale. On allouait une partie de la mémoire pour creer une "zone video" de taille quelconque. Des addresses dans une partie spéciale de la ram indiquait le début de la zone et des marges gauches et droites. L'écran faisait 131*64 pixels. On pouvait allouait la place pour une image de 300*400 (ou plus) et décider quels portions de 131*64 était affichés. Cette dernière opération ce faisait en quelques cycles. Quand on voulait tracer quelques choses il fallait connaitre la taille (en octet) d'une ligne pour passer à la ligne d'en dessus ou d'en dessous.
Sur les nouveaux modèles (49g+/50) je dispose de fonctions pour reserver des zones de mémoires pour la vidéo de taille arbitraire (qui sont affichés ou pas). En pratique (en C) ce sont de simple pointeurs vers des entiers (32 bits) avec la taille d'une ligne. J'ai un pointeur vers l'écran et des routines pour coller (ou OR,XOR etc...) très rapides entre une zone graphique virtuel et l'écran réel. J'utilise la librairie ggl pour ça.
Le problème est que la partie ARM des hp49g+/50 n'est pas (par HP) ou mal documenté (par les autres)...
Dans ces conditions, ce dont tu as besoin pour tester tes programmes, c'est d'une sorte de serveur d'écran de HP : un programme qui propose un segment de mémoire partagée représentant la mémoire vidéo et qui se charge de l'afficher périodiquement sur X11.
J'ai aussi de besoin de ces segments de mémoires virtuels qui représente des graphiques (et sur lesquel on peut tracer des choses via des commandes du type draw_segment(x_0,x_1,y_0,y_1,&ecran_virtuel) et de copier/coller entre ces zones (de préférence avec gestion du clipping...).
Et dans l'autre sens, qui transmette les
touches clavier, en les traduisant en des codes similaires à ceux de la calculatrice ; ce n'est pas très grave si tu utilises une fonction de lecture de touche différente entre les deux environnements.
Non: j'imagine qu'il suffit de mettre les deux fonctions et de commenter l'une des deux. Cela soulève une autre question: sous hp je fais des commandes du genre - attends un touche et donne la moi (et ne fais rien pendant ce temps!). Dans un environement multitache si je ferme une fenêtre, X11 se souvient de la fenêtre en dessous ou il faut tout redessiner?
En bonus, si ça fonctionne comme serveur, tu peux faire tourner le programme à tester sous Valgrind en permanence, ce qui a deux bonus : tu augmentes les chances qu'il soit en C assez portable pour tourner sur ARM, et le coût de Valgrind en vitesse doit faire approcher de la vitesse de l'ARM.
Je ne connais pas Valgrind mais cela semble intéréssant dans la chasse au bugs. Pour la vitesse ce n'est pas un problème. Par contre le vrai problème se situe au niveau de la mémoire: une hp50g c'est (au maximum) 256+128 Ko de ram. Il faut donc ruser et économiser...
Le plus triste dans cette histoire est la conclusion: HP a sortie les hp49g+/50 avec un processeur ARM. Des hackers ont mis au point des manières de programmer en C dessus. J'ai "appris" le C (les bases) à cette occasion faire deux programmes qui sont très supérieurs (voir exclusifs) sur beaucoup de points à ceux fournis par Hp mais plein de bogues. Ce n'est pas mon métier...
Hp doit avoir des programmeurs de qualités, et à qui toutes les données sur le matos sont dispos. Résultats ils n'en font rien!
Ils ne fournissent même pas de documentations dignes...
Bref la mort des calculatrices HP/RPN: quelle tristesse!
