[mOved] Pedrom App - Page 2

dommage pour la limite a 64K mais ca reste pas mal.
au fait pour faire plus C standart ca serait mieux main(argc,argv) que _main(argc,argv)

Si tu veux la possibilité d'utiliser TIGCCLIB, mets-toi en contact avec Greg Dietsche, il pense peut-être supprimer l'utilisation de variables globales avec le code afin de pouvoir générer des FlashApps AMS (non signées, à faire signer par TI) avec TIGCC. Vous avez le même problème, donc vous avez intérêt à coopérer.

Je compte pas vraiment utiliser tigcclib... Ou alors seulement des bouts par ci par la.
Mais #include <tigcclib.h> sera interdit pour toute app. Mais ce n'est pas encore ce qui importe.

Je precise que 1 secteur par app, c'est pour eviter les problemes de Garbage Collector.

Que pensez de ce que j'ai fait ? Ca vous convient ? Ou pas ?

est-ce que 64ko ne serait pas un peu petit pour certaines appli ?

Et si tu écrivais "garbage" correctement?

squale: Pas grave, on peut TOUJOURS decouper en plusieurs applications de 64Ko et les faire communiquer entre elles par les tables d'import/export.

ok

Hummm

Ce fonctionnement par evenemetn a l'air d'etre un trs bon début )

Faudrait le "porter" pour les appli kernel standard qu'est-ce tu en pense ??
Sa pourrait etre une immense inovation face au "_nostub"

Sinon g survolé la def, mais sa a l'air plus que correct
(g pas vu qq chose la dessus) mais faudrai pouvoir faire des "event perso" genre on fait une appslib pour faire un system graphique avec fentres/widgest par ex, et envoyer des evenement que PedRom ne gere pas en "natif" et ausi pouvoir ajouter soit meme un evenement dans la pile des evenements qu'attent l'appli

Faudrai pouvoir aussi vider la pile des evenements en attente et, donc, pousser un evenement dans la pile en derniere pos ou en mode "priorité" cad en début de pile d'evenement.

Vala pour mon lot d'id (je précise que g pas tt lu, juste survolé donc ya ptet des choses qui sont déja présentes)

J'explique mes motivations :

Si on a la possibilité d'avoit un system evenementiel evolutif, on peu avoir la possibilité de creer un os "multitache" enfin presque multitache, du genre Win3.1, se qui pour une TI est a mon avis deja pas mal, cela permet aussi de gerer facilement un sous systeme graphique, un peu comme XWindow le fait.

Poru se qui est des suggestions (g un pe plus lu en profondeur) la méthode
void event(event e, eventp ep)
{
switch(e)
{
case A_INIT:
[...]
case A_BOOT:
[...]
default:
[...]
}
}

est bien meilleur que

void A_INIT(eventp ep)
{
[...]
}
void A_BOOT(eventp ep)
{
[...]
}

et surtout plus souple pour l'utilisateur et moins complexe pour l'assembleur/compilateur..

Le moins complexe pour le compilateur, c'est un peu faux.
Plus souple, mouaips.
Ok.

Je précise bien sur que cet avis ne conserne que moi

En effet ca serait vraiment quelque chose de pour le kernel.

ouep,

Qu'est-ce que vous voulez exactement ? Je comprends pas tres bien cette idee de Event Kernel...

ben la meme chose que pour les pedrom app, mais pour les app kernel sur tios

Oué mais les programmes kernels sont pas installes en permanence... Bonjour les problemes...

Oui.
Si vous voulez faire de l'événementiel sous AMS, utilisez EV_hook ou écrivez une application Flash!

	Les applications PedroM seront des fichiers kernels (extension '68kP') dont avec un header kernel avec quelques contraintes. En plus d'avoir le flag ReadOnly mis, la fonction '_exit' est detourne :
	
Good:			
	+ Possibilite d'utiliser les romcalls / ramcalls / bss / libraries comme en kernel.
	+ Possibilite d'importer des libraries en RAM ou en APPS ! C'est transparent.
	+ La section BSS pour les vars globales est autorisé.
	+ Le bloc BSS possedera un numero d'handle FIXE. Lorsque l'application ne s'en sert pas, cet handle est de taille 2 octets. Sinon, il est de la taille de la section BSS.
	
Bad:	
	+ Limite a 64K comme les programmes kernels !
	+ Consomme un secteur entier quelque soit la taille utilisé.
	+ Les vars globales avec le code sont interdites (forcement...), donc la librarie statique Tigcc ne marchera pas pour produire des applications (y'a des vars globales partout !). 
	+ Pas de self modifying code (donc genlib ne marchera pas en APPS...)

FUNCTION EVENT :

long	event(short id asm("d0"), long data asm("d1"));
	Switch (id) :
		+ Idle: Le systeme glande...
		+ Boot: Le systeme boote.
		+ Clean: Commande 'clean' appellée.
		+ CrashExit: L'application a declenche une operation illegale..
		+ StartProgram: Un programme va etre lance (data = HANDLE)
		+ EndProgram: Fin d'un programme
		+ Shell KeyPress
		+ Shell ClrScr
		+ Get Unkown RomCall Ptr.
		+ Get Unkown RamCall Ptr.
		+ Get Unkown Library Ptr.
		+ Install
		+ Uninstall.
		+ ngetchx Key
		+ Calc On / Off 
		+ ViewFile (HANDLE , WINDOW *)
		+ NoticeInstall ?
		
	TO IMPROVE.
	
MAIN Function :
	int _main(int argc, char *argc[])


Les programmes kernels peuvent bien sur importer les fonctions exportees des applications !
Tout comme le contraire :)

Internal Functions :

AppInit
	Recherche des applications installées et reservation des handles.
	Appelle apres FlashCheck.
	
AppInstall(HANDLE h, char *name)
	Installe l'application h qui est en RAM.
	Appelle automatiquement par la procedure de link si elle reconnait une application.
		1. Check taille fichier (< 65536-20).
		2. Check signature (_exit.w, et _exit +6.ll).
		3. Recherche d'un secteur libre ($FFFF).
		4. TailleBss = ReadBssSize(h). WriteBssSize(h) = 2
		5. Rellocation du handle h avec comme destination le secteur trouvé. (Modifie legerement PreOS).
		6. Remet la vrai taille du segment BSS et fixe le counter de reloc a 3.
		7. Write Extra Header (Statut = 0FFFE). Folder : apps.
		8. Write handle h.

AppUninstall(void *addr)
	Desinstalle l'application.
		1. Get sector base.
		2. Check Extra Header
		3. Verifie que le reloc count de l'application est a 3.
			Oui:	3' : Met ce reloc count a 0.
				3'': Appel function event(Uninstall).
		4. Free BSS Handle.
		5. FlashErase(Sector)

AppRun(void *addr, int argc, char *argv[])
	Execute l'application (appelle la fonction _main).
		1. Get sector base.
		2. Check Apps
		3. Saut a main.

AppOpenRessource(void)
	Ouvre le fichier de ressources si necessaire.
	Si le fichier est realloue, il est remplis a 0 !
		1. Pop PC, get sector base.
		2. Get BSS Handle, Check size 
		3. Size == 2
			4. Realloc a sa taille normale.
			5. Locke it.
			6. Clean it.
			7. Realloc des libraries (find_librarie, reloc).
			8. Copie les adresses des fonctions dans la section BSS.
		9. Retourne Ptr or NULL.
	Sinon ne fait qu'un HLock dessus.
	
AppCloseRessource(void)
	Ferme le fichier de ressource.
		1. Pop PC, get sector base.
		2. Get BSS Handle, Check size 
		3. Size != 2
			4. UnRealloc des libraries (unreloc).
			5. UnLocke it.
			6. Realloc a 2.
		8. Retourne Ptr or NULL.


Example:

	#define RESSOURCE "res.h"
	#include <pedrom.h>
	
	long	event(short id asm("d0"), long data asm("d1"), long extra asm("d2"))
	{
		return 0;
	}
	
	int	main(int argc, char *argv[])
	{
		g = ropen();
		printf( "Hello world from Application !\n"
			"Counter: %d", g->counter);
		g->counter++;
		//rclose();	// We don't close the ressource file to keep the globals.
	}

QUESTION:
	* Un evenement est-il reentrant ?
	
IDEE :
Au lieu du point d'entree _exit, utilise _main et ceci :
	rts
	dc.l 'Pedr'
	dc.w 'oM'
	etc

Suivi d'un format type 'Commentaire _nostub' ?
Dans ce cas, on reserverait comme truc :
	* Table d'import de libraries
	* Point d'entree. (main)
	* Evenement (event)
	* Flags (Tableau de bit des evenements supportes)
	* Dialogue ?
	* Noms des extensions de la Console, suivi des points d'entree. ???
	* Nom complet.
	* Numero de version.
	* Auteur.
	* Icone 24x24.
	* Touche APPS ? Faire fusionner les dialogues ?

Fonctions:
typedef	void	*AppId;

	_globals_struct *ropen(void);
		Ouverture des ressources de l'application.
		ie. reallocation de l'handle de la section BSS et importation des libraries.
		Doit etre appelle a l'interieur de l'application.
		Si les ressources sont deja ouvertes, ne fait juste que redeference le pointeur vers ces ressources.
		
	void	rclose(void);
		Fermeture des ressources de l'application.

	AppId	GetAppId(const char *internal_name asm("a0"));
		Retourne l'AppId d'apres le nom interne (exemple: 'xwin').
		Si on passe NULL, retourne l'AppId de soi meme.
		
	EventId	GetBaseEvent(AppId id asm("a0"));
		Possibilite d'envoyer des events perso (>$8000)
		Reservation automatique de 256 evenements pour chaque app :
		La partie haute (127) = AppId / 65536 | $80.
		La partie basse est laissee libre a l'app.
		Pb : les evenements sont determines dynamiquements...
		
	void	*GetFirstAttribut(AppId id asm("a0"), ATTRIBUT attribut asm("d0"));
		Reservation de carac intrinseque Type > $8000.
		Retourne un pointeur vers la premiere donnee interne de l'application
		correspondant au type desire.

	void	*GetNextAttribut(AppId id asm("a0"), ATTRIBUT attribut asm("d0") ,void *previous asm("a1"));
		Retourne un pointeur vers les donnees internes de l'application.
		Saute le pointeur precedent (recherche d'abord ce ptr puis passe au sauivant).
		Fait n'importe quoi si on l'appelle en changeant AppId ou attribut par
		rapport au premier appel a GetFirstAttribut.
		
	AppId	GetFirstApp(void)
		Retourne la premiere application installe ou APP_NULL
		
	AppId	GetNextApp(AppId id asm("a0"))
		Application suivante ou APP_NULL.
	
	void	SendEvent(EventId id asm("d0"), long num asm("d1"), long num2 asm("d2"));
		Envoie un evenement aux applications installees.
		
	void	SendEventToApp(EventId id asm("d0"), long num asm("d1"), long num2 asm("d2"), AppId id asm("a0"));
		Envoie un evenement a l'application selectionnee.
		
	BOOL	GrayOn(void);
	void	GrayOff();
	void	*GrayGetPlane(short plane asm("d0"));
		Looks Tigcc docs.
		
Comment faire un systeme fenetre pour PedroM ?
	Faire une application principale : le gestionnaire de fenetre.
	Exemple : Nom de l'appli 'xwin'.
	(Si c'est trop grand, faire deux applications).
	L'appli boote par le script 'start' (Ne pas utiliser l'evenement boot).
	Elle doit donc exporter une commande console : 'start xwin' par exemple.
	Ca demarre le systeme et lance un systeme de gestion de fenetre.
	Au demarrage :
		+ Recherche des applications avec un numero d'attribut fixe a l'avance.
		=> Ce sont les applications qui nous interressent.
		for(AppId id = GetFirstApp() ; id != APP_NULL ; id = GetNextApp(id))
			if (GetFirstAttribut(id, 0x8001) != NULL)
				AddApp(id);
	
	Ces applications exportent des attributs :
		#define RESSOURCE xapp2
		#include <pedrom.h>
		#include <xwin.h>
		
		ATTRIBUTS
			ATTR_IMPORT_TABLE
			ATTR_EVENT_FUNCTION
			ATTR_XMAIN
			ATTR_END

	Elles accedent aux donnees du serveur graphique par un acces a la librarie (xwin). 
	Fichier: xapp2.res :
		LIBRARY(xwin,4)
			IMPORT(void , (void), EventLoop, 0)
			IMPORT(XWINDOW * , (int, int, int, int), NewWindow, 1)
			...
		GLOBAL(AppId, Counter)
	
	Puis le code :
	 void	xmain(void)
	 	{
		g = ropen();
		...
		XWinAppId = GetAppId("xwin");
		BaseEvent = GetBaseEvent(XWinAppId);
		SendEventToApp(BaseEvent+XW_READY, 0, 0, XWinAppId);
		SendEventToApp(BaseEvent+XW_IDLE, 0, 0, XWinAppId);
		}		
	Note: Le ptr des ressources n'est pas valide lors d'une entree de lib (Utiliser ropen).
	Note: GKeyIn peut installer des applications...
	Note: On ne peut pas exporter des variables mais seulement des fonctions !
	
	ATTR_XMAIN est definie comme suit :
	#define ATTR_XMAIN	DEF_ATTRIBUT(0x8001, xmain)
	
Comment faire un systeme multi-tache pour PedroM ?
	C'est complique... Impossible proprement actuellement.
	Je vais essayer d'arranger cela, mais c'est pas gagne.
	
TODO:	Ameliorer le vocabulaire.

Vous en pensez quoi ?

qu'un txt a télécharger serait plus digeste.
Pour le reste je regarde se soir.

> Limite a 64K comme les programmes kernels
> Consomme un secteur entier quelque soit la taille utilisé
Dommage Pense qd même à prévoir de quoi étendre les apps à + de 64k et faire en sorte qu'elles puissent prendre plus/moins d'un secteur, même si tu ne le fais pas maintenant, ce serait un gros gros désavantage.

Sinon c

Pourquoi elles prennent obligatoirement un secteur ?

Bien plus simple a gerer. Au niveau outils deja, et au niveau Garbesh Collect.

Par contre, peut etre on pourra les faire deborder mais reste le probleme des outils...
De toute facon, avec le systeme de linking de librarie, c'est bon.

Et j'aimerais des critiques meilleures. JE me casse la tete pour trouver un format pas trop chiant, evolutif, ouvert, et personne ne me critique


Qu'est-ce que vous voulez pour les applications ?

de mieux en mieux
Je m'y penche sérieusement dessus et je fait qq critiques

Franchement, j'aimerais pouvoir critiquer, mais je n'ai pas assez d'expérience juger ce que tu fais.

Tu veux des critiques? Déjà, "ressource" ne prend qu'un seul 's' en anglais

Plus sérieusement, à mon avis, GetFirstAttribut & GetFirstApp ne sont pas vraiment nécessaires (mieux vaudrait passer NULL comme dernier arg à GetNextXxx, c'est d'ailleurs plus efficace du point de vue CSE pour un compilo, et on peut faire :

AppID myapp=NULL;
for (;myapp=GetNextApp(myapp);) {
  ... traitement ...
}

)

Euh sinon perso g pas gd chose à rajouter, si ce n'est que je suis pas trop pour le format type commentaire _nostub, et quitte à ce que l'app prenne 64k, autant prendre un truc propre avec des attributs, accessible sans fonction spéciale. Après si tu crois que c'est vraiment nécessaire de pas avoir l'overhead de déclaration des numéros d'attributs, tu peux tjs faire un sys d'accès compressé aux attributs, mais alors le mieux serait de l'intégrer dans la routine qui va chercher les attributs.

Et puis j'en profite pour te demander qd tu vas te décider à intégrer les tables de reloc compressées à PreOS/PedRom (depuis le temps...), parce que ça va vraiment être crucial pour les apps (un gros paquet de relocs).

Franchement je trouve le format de commentaire nostub bien pensé et vu qu'on est obligé d'utiliser 68k la dépense n'est pas exessive, j'ai pas eu le temps de me pencher sur la spécif mais avec le pont qui arrive je vais m'y pencher

1.L'idee d'utiliser NULL pour les fonctions GetNextApp, etc, n'est pas mauvaise. A voir.

2.Sinon on accede tout via des fonctions. Une bonne encapsulation est absolument necessaire.

3. Le probleme des tables de relocs compressees est que je sais pas le faire sans faire planter les vieux kernels

4.Ce n'est pas tout a fait le format de commentaire _nostub. C'est la fonction _main, qui possede un format specifique suivi d'une table d'exportation d'attributs.

5. Ton for est un abus. Uitlise plutot un while.

> "la dépense n'est pas accessible"

"inadamissible" je pense.