[mOved] PedroM 0.75 - Page 3

nEUrOO
: L'utilisation d'une autre pile ? (idée hasardeuse)

C'est ce que je fais, mais il y a bien plus que ça comme contexte à sauvegarder. (Et il y a d'ailleurs 3 piles, pas une seule.) Regarde mes sources.

Voilà mon contexte de processus:

typedef struct {
 unsigned long D0, D1, D2, D3, D4, D5, D6, D7; 
 void *A0, *A1, *A2, *A3, *A4, *A5, *A6, *SSP, *USP; 
} process_regs;
[...]
 typedef struct {
  int terminated;
  // constant:
  HANDLE h;
  void *cptr;
  void *userstack, *supervisorstack;
  ESI bottomestack;
  // variable:
  process_regs registers;
  INT_HANDLER aihandlers[5]; // save only AIs 1-5
  unsigned long ngcontrol; 
  ESI topestack;
  SymPG_S psympg;
  SCR_STATE scrstate;
  LCD_BUFFER scrbuffer;
  struct ErrorFrameStruct *errorframe;
  unsigned char ai5freq1,ai5freq2; // 0x600015, 0x600017
  void *evhandler,*evhook;
  void *line1111;
  unsigned short kbdmask; // 0x600018
 } process_context;

Théoriquement, il y a aussi 0x600010 (port LCD HW1) qui devrait en faire partie, mais comme ce port ne fonctionne pas en lecture, je le réinitialise à LCD_MEM (LCD_MEM/8 en fait) à chaque switch (pour que les programmes noir&blanc coopèrent avec les programmes en niveaux de gris), ce qui fait fonctionner les programmes noir&blanc et ne dérange pas les programmes en gris (déjà parce qu'il y a leur plan foncé sur LCD_MEM s'ils utilisent de bonnes routines de gris, et puis parce qu'ils vont de toute façon remodifier 0x600010 à la prochaine auto-int 1 ou 5).

PS: Les entrées sous "constant" sont règlées une seule fois à l'initialisation. Les entrées sous "variable" sont sauvegardées à chaque switch. L'entrée "terminated" est un cas à part. (Je pense qu'elle ne nécessite pas d'explication. )

Je reexplique puisque ca a ete mal compris:

Ca ne switche que si le programme appelle de lui-meme le Task Switcher et respecte les contraintes imposees.
Actuellement, seule la ligne de commande et side le supporte bien

Comme aucun programme actuel ne le supporte, j'ai mis des options qui permettent d'autoriser le switchage dans certains cas MAIS ne garantis pas son fonctionnement:
+ Si dans la fonction ngetchx/GKeyIn, on fait un [2nd] + [APPS].
+ Si le programme fait un appel a un trap #4 (Au lieu d'eteindre la calc, on fait un switch de task). Assez pratique car le trap #4 n'est appele en general que dans des conditions saines (Handles en general lockes).

Evidemment on ne peut pas switcher quand on veut.... Donc c'est moins pratique que celui de Kevin... mais plus sur a mon avis.

Quant a la consommation memoire, en general elle est de 5kb par tache.
(Sachant que l'on ne peut pas switcher en mode superviseur).
Je sauvegarde les variables systemes, la pile (de usp a $4400), et si on le demande, les ports io, l'ecran lcd, les vecteurs.

Mais il reste le gros probleme des variables...
Comment eviter les bidouilles du genre: je lance sf2t, je demarre un nouveau script, puis j'efface sf2t.
Et la commande clean:
1. Doit elle detruire tous les process ?
2. Doit-elle ne rien faire en cas de process en cours ?
Sachant que c'est soit l'un soit l'autre.

Et d'autres SMA/CF font tourner la sauvegarde a 12Kb.

Mon defi: SMA et Cf fonctionnant en meme temps. (Le boeuf).

SMA et CF en même temps ?
Heu, combien de RAM nécessitent-ils chacun (une partie sera commune aux deux, notamment GenLib, je suppose) ?
Et quelle place en Flash exactement prennent ces deux programmes réunis (c'est une des justifications de l'introduction de PedroM, mais ça veut peut-être dire que nos TI-68k ne sont pas vraiment faites pour le jeu, contrairement à la GBA ou d'autres consoles de poche) ?

Cf 150Kb, SMA 150Kb. Donc 300 Kb normalement. Bon j'ai du boulot

PpHd :
Et la commande clean:
1. Doit elle detruire tous les process ?
2. Doit-elle ne rien faire en cas de process en cours ? Sachant que c'est soit l'un soit l'autre.

Pourquoi pas mettre le bit in-use (hidden) aux fichiers en cours d'exécution et refuser d'effacer les fichiers in-use (cachés)?

PpHd :
Cf 150Kb, SMA 150Kb. Donc 300 Kb normalement. Bon j'ai du boulot

Espérons que ça t'amènera à réduire la consommation en RAM de tes jeux...

En clair, il te manque un peu moins de 100 KO... Il y a du boulot pour y arriver, oui...

Un truc relativement simple serait d'utiliser l'archive comme espace de stockage temporaire pour les trucs qui ne servent pas trop souvent et/ou qui ne sont pas trop utilisés. Ou peut-être, faire en sorte que CF et SMA utilisent chacun une PedroM App qui ne fait pas grand chose, mais qui réserve un espace de presque 64 KB pour l'utiliser comme stockage temporaire
Note: je n'ai pas lu les spécifications des PedroM Apps, donc il se peut très bien que ce que je suggère soit impossible...

Il devrait plutôt utiliser FL_write comme Corridor, ça marche aussi avec AMS.

En effet, oui, ça serait aussi une excellente occasion de réduire la consommation en RAM de SMA et de CF... Accessoirement, ça serait même plus propre, et n'ajouterait pas d'incompatibilité avec AMS.

Posts croisés...
La solution "PedroM App" était évidemment proposée pour dire n'importe quoi, et "utiliser FL_write comme Corridor, ça marche aussi avec AMS." était ce à quoi je faisais référence par "d'utiliser l'archive comme espace de stockage temporaire".

>Pourquoi pas mettre le bit in-use (hidden) aux fichiers en cours d'exécution et refuser d'effacer les fichiers in-use (cachés)?
Le but de la commande clean est justement de nettoyer le systeme pour eviter d'avoir des fichiers non-refermes.

Par contre, evidemment que les fichiers en cours d'execution seront In-Use (contre l'effacement, le deplacement, etc).

>Espérons que ça t'amènera à réduire la consommation en RAM de tes jeux...
C'est pas autant que Corridor

>Un truc relativement simple serait d'utiliser l'archive comme espace de stockage temporaire pour les trucs qui ne servent pas trop souvent et/ou qui ne sont pas trop utilisés. Ou peut-être, faire en sorte que CF et SMA utilisent chacun une PedroM App qui ne fait pas grand chose, mais qui réserve un espace de presque 64 KB pour l'utiliser comme stockage temporaire
Pas si simple... Mais y'a de l'idee. Le probleme est qu'un HeapDeref permet d'acceder a la memoire sans la locke... Mais ca merite reflexion. Si je trouve un moyen propre, je ferais une swap pour que HeapAlloc depasse les 220Kb et utilise l'archive comme swap...
Trop pur si j'y arrive.

> Si je trouve un moyen propre, je ferais une swap pour que HeapAlloc depasse les 220Kb et utilise l'archive comme swap...
Heu, ce que j'ai suggéré était destiné à être stupide, pas à te faire penser que tu pourrais peut-être ajouter quelque chose qui soit encore plus incompatible avec AMS...

Et je ne vois vraiment pas de moyen propre pour le faire...

Moi non plus !

XDanger et l'ironie ...

L'ironie, je sais l'utiliser, cf #68, mais je ne sais pas la reconnaître s'il n'y a pas de smiley... Je n'avais vraiment pas pris la fin du post de PpHd pour de l'ironie...

Ben si j'y arrive ca sera pas de l'ironie. Sinon ca en sera.

Moi je parlais de l'ironie de XDanger, qui t'as en fait donné une bonne idée pour Pedrom

C'est une mauvaise idée. Pourquoi utiliser une App PedroM pour le stockage? FL_write est là pour ça!

Si je le fais ca sera built-in au systeme.

-

Il fonctionne chez moi et chez TRgenius...
Mais j'ai bien mis un avertissement: "WARNING: THIS IS A DEMO, IT DOES _NO_ ERROR CHECKING WHATSOEVER! IT _WILL_ CRASH YOUR CALCULATOR! USE THIS AT YOUR OWN RISK!!!" Par exemple, il n'y a aucune vérification des résultats de malloc.
Et aussi: "Compile with GCC 3.3-pre7 or later (because it uses nested functions)". Si tu utilises le compilateur livré avec TIGCC 0.94 SP4, ça ne marchera pas sur HW2, et c'est normal.
Mais une "Privilege Violation" n'est pas normale, donc il faudra que tu me donnes plus de détails (et là-bas s'il te plaît, ici c'est totalement hors-sujet!).

Ah oui, j'ai oublié de préciser un truc: mon task switcher ne fonctionne pas avec les programmes pour kernel (je ne sais pas exactement pourquoi). Ça aussi, c'est dit dans le topic.

En effet, c'est une mauvaise idée... Je ne pensais pas que PpHd s'amuserait à la trouver bonne, vu que FL_write est parfaitement standard et marche très bien sur AMS et PedroM.

-

Tu testes l'octet à 0x45, soit le 2^ème octet de ça:

$44.l:	adress of the unreloc2 function
	input:
		a6.l : the adress to the very first instruction of the prog (the beginning of the file)
	destroy:
		a0/d0

Ça ne marchera pas sur TI-89/V200 (parce que la ROM est en 0x200000-0x3FFFFF, pas en 0x400000-0x5FFFFF), et ça risque aussi de ne plus marcher sur des versions futures de PedroM si la fonction est déplacée.

En fait ça passe si cet octet est égal à 0x21, c'est ça?

-

Xdanger: C'est pas gagne d'y arriver./