Suite à de nombreuses incompréhensions et mauvaises interprétations, voici comment fonctionne réellement la mémoire du T5.

Le T5 a en réalité 256 Mo de mémoire flash (non-volatile); ces 256 Mo sont répartis en:
-55 Mo de "storage heap", qui conservent l'ensemble des bases "internes" (celles qui sont en RAM sur un palm traditionnel)
-160 Mo qui fonctionnent comme une carte mémoire VFS classique
-41 Mo qui servent à stocker une image compressée de la "ROM" et d'autres fichiers système

En plus de cette mémoire flash, il y a 32 Mo de RAM classique (volatile) qui servent uniquement de mémoire de travail. Cette RAM se divise comme suit:
-10 Mo qui servent de cache pour les bases ou parties de bases du "storage heap" (les fameux 55 Mo)
-6 Mo pour le "dynamic heap" (mémoire de travail utilisée par les programmes)
-16 Mo pour stocker l'image décompressée de la ROM

Etant donné que le processeur ne peut accéder directement qu'à la RAM véritable, chaque fois que l'OS a besoin d'accéder à une base (qui se trouve donc dans les 55 Mo de flash), il doit "monter" cette base (ou la partie accédée) dans les 10 Mo de RAM.
Lorsqu'il n'en n'a plus besoin, il peut libérer la place utilisée, mais s'il s'agit d'un enregistrement de base qui a été modifié, l'OS doit recopier ce morceau de base depuis la RAM vers la flash pour libérer le morceau de RAM...

En fait l'OS passe donc son temps à échanger des morceaux de bases entre la RAM véritable et la flash. En contrepartie, la RAM n'étant qu'un espace de travail, l'ensemble des bases du storage heap se trouve donc à tout moment en flash, à l'abri d'une panne de batterie.

Les problèmes qui peuvent se poser sont de deux ordres:
-si le développeur d'un soft accède à un enregistrement d'une base avec la mauvaise API et qu'il le modifie, même si cela fonctionnait avec un palm traditionnel, sur le T5 il y a un risque que l'enregistrement ne soit pas correctement recopié en flash.
-si un programme essaye d'accéder à une base de plus de 10 Mo, il risque de recevoir un "not enough memory", même si apparemment il reste largement assez de RAM.

(Cet éclairage est largement insipiré d'un article très bien écrit publié par Red-Mercury http://www.red-mercury.com/nvfs.html )

Merci Olivier
Je complèterai avec l'info que tu m'as donnée concernant l'installation de logiciels tiers : quand on installe un logiciel, il va bien dans ces 55 Mo de flash, mais de façon totalement transparente pour l'utilisateur.

Ok, c'est relativement clair.

Toujours est-il que le mécanisme de copie des bases ou programmes de la flash vers la RAM est bien un bricolage à la PiDirect... Et qu'il est notoire que ça ne fonctionne pas toujours parfaitement.

Et pour moi, cela fragilise sérieusement l'architecture du système. Si on cumule ça avec les 2 bases que l'OS essaie de garder synchronisées pour l'agenda et le carnet d'adresses, il n'est pas étonnant que ça pète dans tous les coins.

Evidemment, si les softs étaient toujours écrits "proprement" et que les programmeurs ne faisaient jamais d'erreurs, ça fonctionnerait parfaitement. Mais il faut être réaliste et je pense que palmOne ne l'est pas trop sur ce coup-là.

ces constants recopiages ralentissent-t-ils la machine?
je veux dire sensiblement

Cela fait partie des explications de Red Mercury : eux n'ont pas vu de différence sensible.

Mais tout dépend en réalité de ce qui doit être copié et de la fréquence à laquelle cela se fait (ce qui dépend encore une fois du style du développeur : palmOne a des recommandations à ce sujet mais avec les anciens softs...).

ok, je voulais dire (c'est vrai que je n'ai pas tout lu de chez mercury because of my poor english )
c'est qu'on ne va pas pour autant avoir l'effet carte mémoire avec l'indicateur d'avancement lors du lancement des programmes?

il ne faut pas oublier qu'un des avantages que j'entends régulièrement du palmOS sur les PPC c'est la rapididé, donc....

D'après ce qu'on peut lire (je vais encore me faire engueuler par ceux qui disent "pourquoi t'en causes, t'en a pas"), ce n'est pas là que serait le problème, mais plutôt sur les softs qui ouvrent et ferment les bases de données à haute fréquence.

ok, merci Patrice

En réalité, tant que ton appli reste dans les 10 Mo de cache, il n'y aura pas de ralentissement sensible, la seule différence avec un fonctionnement "tout RAM" étant le temps de chargement initial. C'est ce qui explique les bons résultats des tests Red-Mercury.

Mais je pense comme Patrice que c'est un changement beaucoup moins anodin qu'il n'y parait... on touche là sans le dire à l'essence même de l'architecture du palmOS, et on risque de perdre le bénéfice de l'immense logithèque Palm (qui est toujours un gros point fort par rapport au PPC) en fragilisant les applis existantes et en augmentant les risques d'incompatibilités avec les anciennes applis.

le big problème c'est qu'il y a des chance que le treo 650 soit bati sur les mêmes bases, non ??

Plus que des chances.... c'est d'ailleurs surtout pour les smartphones que ce modèle a été pensé.

Es-tu sur quil s'agit des 55 Mo de flash? D'après ce que je constate, il y a uniquement une copie dans les 10 Mo de RAM quand les bases ou les applis se trouvent dans les 160 Mo de RAM.

Les applis situées dans les 55Mo s'exécutent quasiment instantanément (cela dépend évidemment de la taille de l'appli).

Etant donné que 55Mo suffit largement à l'installation des programmes les plus utiles et les plus importants, je ne pense pas que cette nouvelle structure de la RAM soit pénalisante (n'oublions pas en plus qu'elle apporte des nouvelles fonctionnalités non négligeables).

Par contre c'est vrai que c'est un peu compliqué et que ca peut aboutir des restaurations from crash bizarres (après un essai il manquait certaines bases ..). Bon faut dire que j'avais couplé la derniere version de backupbuddy qui n'est pas encore compatible T5 ... ca a du mettre l'embrouille :?

Sinon j'ai installé pas mal de progs, de mp3 et de divx dans les 55 Mo et les 160 Mo et dans la plupart des cas (90%) je n'ai rencontré aucun problème de fonctionnement (lecture instantanée et parfaite des mp3 et divx ).

En résumé je ne peux pas dire que le fonctionnement de la RAM du T5 me gène vraiment. D'autre part, dès que les mises à jour des applis sortiront, je pense que les petits problèmes d'apprentissage disparaitront très vite !

les 55 Mo sont de la flash : c'est pour ça qu'ils ne sont pas volatiles (le contenu de la RAM est perdu dès qu'il n'y a plus d'alimentation ou que tu fais un hard reset).

Je confirme... n'oublions pas que le processeur ne peut pas exécuter de programme ou lire de données directement dans la flash, c'est ce qui rend le passage par le cache nécessaire.

Beaucoup de terme auxquels je ne comprends pas tout.

Juste une question avec une réponse simple pour pour un néophyte comme moi :

Combien il y a t'il de place non effaçable après extinction de batterie, concerant les programes de bases, ceux ajoutés et leur contenu ?

Si j'ai bien tout compris : 55 mo pour installer les programmes, et 160 mo en tant que "clé USB". Mais peut-être qu'un utilisateur de T5 peut confirmer...

Merçi bien, donc ces mémoires ne sont pas effaçable lorsque la batterrie est déchargée .

N'y a-t-il pas aussi un risque de voir le système (ou un programme) rester dans un état instable en cas de plantage intempestif ?
Le système de fichier de PalmOS pour ce qui concerne la mémoire en VFS est le FAT, si j'en juge à la possibilité d'utiliser les cartes mémoires formatées avec ce système sous Palm.
FAT n'étant pas journalisé, n'y a-t-il donc pas un grand risque d'état instable ? Les utilisateurs de Windows me comprendront...

Damien

Que ce soit journalisé ou pas ne change rien au problème (un journal enregistre aussi les anomalies) !
Et la mémoire non volatile n'est pas en VFS, c'est le lecteur interne, ça.
Quand à la possibilité de rester dans un état instable, c'est rigoureusement la même chose que pour un autre palm, SAUF que tu ne peux pas faire un hard reset aussi simplement.

Est-ce qu'il y aura du changement quant au fait qu'on ne puisse pas charger d'appli de plus de 10Mo

Changement où ?

Et il faut rétablir la vérité : il est faux de dire qu'on ne peut pas charger d'appli de plus de 10Mo !
Le système est prévu pour charger en mémoire les données strictement utiles, dans la mesure où le développeur du soft ne fait pas n'importe quoi (c'est à dire qu'il ne "charge" pas systématiquement toutes les données en mémoire, même s'il n'en a pas besoin).

Le problème apparaît si le programmeur "locke" trop d'enregistrements en mémoire. Un enregistrement "locké" est figé en RAM et ne peut plus bouger, ce qui permet au programme d'y accéder par des pointeurs, mais empêche l'OS de déplacer ce bout de mémoire, ou dans le cas du T5/Treo650 de le remettre dans la flash pour libérer de la RAM.

Donc, si avec un palm classique, il pouvait en locker autant qu'on voulait puisque tout était en RAM, avec les nouveaux palms type T5/Treo650 il ne pourra en locker que jusqu'à concurrence de la véritable RAM dispo, c'est à dire 10 Mo.

Un programme bien %#!§@çu ne locke les enregistrements que le minimum de temps nécessaire pour y accéder, et libère le lock tout de suite après.

En demandant ça, je pensais surtout à ce que j'avais lu quant au problème pour charger les cartes routières.

La réponse est: ça dépend comment c'est programmé... seule la pratique le dira.

Je suis encore obligé d'attendre avant de craquer pour le T5 alors.

bonjour,

je suis en train d'essayer un t5 et je suis supris de voir que dans le menu app launcher-> info, le systeme affiche que le t5 a 63 mo ????

est ce 55 (storage heap)+ 10(cache) ou 55(storage heap)+ +6 (dynamic heap)?

est ce que l'un de vous pourrait m'eclairer?

merci

Intéressant ça ! Il devrait s'agir de storage heap + dynamic heap, mais en l'occurrence ça devrait faire 61...

... et Bienvenue sur PA, toki

merci erwan.

sinon, on pourrait penser que palm se soit tromper sur son appli et a laisse le nombre d'espace memoire total du tungten C (c a dire 64)....

Me voilà de retour dans le monde Palm après être passé quelques temps au Loox 420.

J'ai reçu un T5 ce matin et j'ai du mal à comprendre comme placer des applis dans telle ou telle mémoire (55 ou 164Mo).

Peut-on transférer, depuis le palm, un programme qui se trouve dans les 55Mo vers les 164 Mo ? Et vice-versa ?

Autre question, lors de l'installation d'un programme avec l'installateur rapide PalmOne sous XP, peut-on choisir l'emplacement de ce programme entre les 2 mémoires précitées ?

Merci pour votre aide.

Les 164 Mo de mémoire dont tu parles sont vus exactement comme une carte-mémoire SD ou MS... Donc tout ce que tu peux lire sur "comment placer une application sur carte-mémoire" s'applique à cette partie de la mémoire du T5.

Pour déplacer les applis sur carte-mémoire le plus pratique et le plus simple est probablement Zlauncher (clic long / move to card...) mais des tas d'autres logiciels le font... voir le dossier aprroprié !

Merci je vais regarder ça .

[hs] Logam, il est grand temps de changer ton profil

C'est fait MarieC, je suis rentré dans le droit chemin .

Ahhhhh je préfère ça bravo m'sieu, et merci

Je voudrais apporter une précision sur l'utilisation de la mémoire flash.
Olivier nous dit que les programmes en flash ne peuvent pas s'éxécuter directement depuis la flash et doit passer par la RAM. Cela est vrai par ce que PalmOne a installé de la NAND flash (la NOR flash étant exécutable, elle). Je dis çà car vous pourriez voir un jour des devices avec de la NOR flash sans RAM.

Autre détaille qui a plus d'importance la flash (NAND et NOR) doit être écrite et lue par blocks de taille fixe. Pour le T5 et le Treo 650 cette taille est de 512 octets. Or i'OS n'est pas capable actuellement de mettre plus d'un enregistrement sur un block, donc tous les enregistrements auront une taille multiple de 512 octets. Exemple un mémo avec juste 10 caractères prendra 512 octets au lieu de 10. Un enregistrement du carnet d'adresses avec juste un nom, un prénom, et un numéro de téléphone qui prend environ une trentaine d'octets en moyenne en prendra 512. Si on multiplie çà par le nombre d'entrée dans le carnet d'adresses, on voit la quantité de mémoire perdue.

Ce qui explique pourquoi on lit à gauche et à droite que des enregistrements faits sur cette mémoire sont bien plus grands que la normale :?

Merci Corto pour ces précisions !

J'avais déjà lu quelque chose là-dessus, je crois même qu'on en avait parlé ici aussi: c'était une personne qui racontait que lors de sa migration vers un T5, la taille de certaines de ses bases avait explosé à cause de ce problème d'unité d'allocation à 512 octets...

Je viens juste de découvrir ce topic, il est super !

Mais je ne vois pas l'usage qui est fait du "Dynamic Heap" .

Le lifedrive fonctionne sur le même prinicpe non ?
Sauf qu'en lieu et place de la flash, c'est le disque, ce qui explique les temps de latence lors du chargement, mais la vitesse normale lors de l'exécution.

Mais les 32Mo de vrai RAM sont-il organisé de la même façon sur le LifeDrive ?

Et quid du T|X, similaire non ?

Bonjour et merci pour ce super post!!

Mais j'ai une question, si c'est le meme mode de fonctionnementsur le LD, y a t'il un moyen de faire passer la fausse ram à 256mo au lieu de 64mo en prenant le microdrive et en changant la taille de la ram avec linux?

Ou est ce que palm OS ne le permettrai pas?
Car avoir 256 ou au moin 128 mo de memoire ne me déplairai pas!!!

A+ Thomas