[mOved] Pedrom App - Page 3

> 3. Le probleme des tables de relocs compressees est que je sais pas le faire sans faire planter les vieux kernels
De toutes façons les vieux kernels seront incapables d'exécuter un prog avec tables de reloc compressées (sinon il faudrait mettre 2 tables et ce serait un peu ), donc il suffit de commencer tes relocs compressées par $0000 comme ça les vieux kernels ne font rien, ensuite tu trouves un endroit pour mettre un flag qui dit que les relocs sont compressées et enfin tu mets par exemple un 'rts' à la place de _main (ou un bra vers le même msg d'erreur que si PreOS n'est pas là), et si le kernel est PreOS, il remplace ce rts ou bra par un nop (et il sauvegarde le contenu du bra pour la dé-relocation si tu choisis la solution bra), comme ça le programme s'exécute comme prévu.

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.
OK. Ce que je voulais dire est qu'il faut à tout prix éviter un format optimisé mémoire et avec des manières exotiques d'accéder aux divers attributs.

5. Ton for est un abus. Uitlise plutot un while.
Oui je sais D'ailleurs je suis plutôt du genre à abuser des while et ne faire jamais de for (il y a 30 for pour 350 while dans GTC, et les for ne viennent pas de moi )

Bref on bidouille grave. Sauf que c'est insuffisant : La seconde partie des headers kernels est continue : pour acceder a la table des romcalls, faut passer la table des librairies, etc, etc.
Une solution simple est d'utiliser un autre vecteur d'entree de programme (autre que $34.l), est de changer le format (Pas trop pour conserver du code, mais suffisament).
Ca doit etre faisable... Mais j'ai pas le temps Bon... je vais essayer.

Meme si le format est simple, l'application ne doit y acceder que par l'appi exportee.

Oui oui on est d'accord.

> Bon... je vais essayer

j'ai corrigé je devais penser a autre chose quand j'ai écris ce post

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

Mets un flag dans l'octet de poids le plus fort du compte des relogements. Les anciens kernels rejetteront ce programme immédiatement.

Je ne comprends pas tres bien. Qu'appelles-tu le compte de relogements ?
Les relogements du programme ?

D'abord je vois que tu as fait des fonction en C. on pourra programmer en C des APPS? TIGCC ne va pas poser de problèmes avec ton format?

>Good: [...]
que du bon

>Bad: [...]
Le seul truc que je vais regreter c'est d'etre contraint de faire une appli de 64ko.

>FUNCTION EVENT [...]
Un evenement redessiner l'écran pourrait peut-être être utile

>MAIN Function [...]
un "int main(int argc,char *argv[])" ferait peut-être plus classe(bon OK je chipote)

>AppInit [...]
>AppInstall(HANDLE h, char *name) [...]
>AppUninstall(void *addr) [...]
>AppRun(void *addr, int argc, char *argv[]) [...]
Rien a signaler

>AppOpenRessource(void) [...]
>AppCloseRessource(void) [...]


>IDEE : [...]
a mon avis elle est bonne mais pourquoi ne pas tout simplement reprendre les types de données des commentaires nostub(sans reprendre l'implémentation): un peu de compatibilité ca ferait pas de mal.
Et surtout des icones de 24*24. Sur 92+ peut-être, mais sur TI89 c'est vraiment TROP gros. et incompatible avec sh'l, Einstein et TIM
Je ne comprend pas vraiment ce que tu appelle "dialogue"

>Fonctions: [...]
que du bonheur il faudrait juste peut-être une fonction inverse de GetAppId

>Comment faire un systeme fenetre pour PedroM ?[...]
Je suis pas vraiment convaincu de l'efficacité d'un systeme de fenetres sur TI vu la taille de l'écran et l'absence de dispositif de pointage en plus de la difficulté que ca représente.

>Comment faire un systeme multi-tache pour PedroM ?[...]
En faisant ca, ca signifie qu'on aurra plus accès aux interruptions(enfin de vois pas d'autre moyen). Il faudrait que tu rajoute alors pas mal de fonctions et d'évenements internes pour que l'on puisse s'en passer.

>Proposition
Sans doute impossible mais comme je connais rien au fonctionnement de la flash je tente quand même au cas ou. Serait-il possible d'avoir accès a la zone vide du secteur flash pour y stoquer les sauvegardes d'un jeux, les parametrages d'une application...

> Je suis pas vraiment convaincu de l'efficacité d'un systeme de fenetres sur TI vu la taille de l'écran et l'absence de dispositif de pointage en plus de la difficulté que ca représente.
Entièrement d'accord.

> Serait-il possible d'avoir accès a la zone vide du secteur flash pour y stoquer les sauvegardes d'un jeux, les parametrages d'une application...
Ca commence à devenir gore

je comprend pas tout, mais en tant qu'utilisateur "potentiel", et p-e programmeur :
- c'est vraiment dommage de bouffer 64k pour un APP... si tu peux pas faire autrement, ou si ca te prendrait trop de temps, faudrait se laisser une chance de pouvoir le faire plus tard, garder un "compatibilité" (je sais pas comment il faut interpréter compatibilité... je sais pas comment c'est fait...)
- le systeme de fenetre et le multitache : je repete moi aussi ce qui est dis : vu la taille de l'ecran, la vitesse du proc, je doute que se soit utile. Franchement, je vois pas ce que l'on pourrai vouloir faire tourner en même temps sur une Ti...

bah la vitesse du proc n'est pas le problème principal: c'est pas ce qui prends le plus de ressources, le multi tache est possible mêm si ca reste un problème complexe.
Le multi fenetre c'est un autre problème encore plus complexe et ca ne serait pas adapté a la TI.

et puis il faut assi voir ce qu'il attends par multi-tache : temps partagé(style UNIX, windows95 et +) ou juste la possibilité de passer d'une appli a l'autre en n'executant qe l'appli active (style Windows 3.11 et -).

à mon avis il veut parler de multi-tâche préemptif

bref, vitesse de proc ou pas (comme quoi, je suis pas tres calé pour parlé de ca), en tant qu'utilisateur potentiel, je ne vois pas l'interet sur Ti de faire du multi-tache, partagé ou style Win3.11.
le préemptif est le Win3.11 ?

1. C'est pas moi qui ferait le systeme de fenetre ou de multi-tache. C'est juste des exempleS.
2. Pour 64Ko par application, je crois pas que je vais changer. Ca simplifie enormement la gestion et evite d'user trop la flash par des installs/uninstalls successifs.

> evite d'user trop la flash par des installs/uninstalls successifs.
lol ne cherche pas des prétextes vaseux, tu sais très bien que le TIOS passe son temps à écrire sur le secteur de garbage (10 fois par GC...), donc l'utilisation de la flash, pouet pouet

PpHd a écrit :
Je ne comprends pas tres bien. Qu'appelles-tu le compte de relogements ? Les relogements du programme ?

LOL, je connais le format kernel mieux que toi.

Extrait de ProgFormat.txt de DoorsOS II:

Offset	Size	Desc
--------------------
$0	4	Bsr to the loader code
$4	4	68k ASM Signature "68kP" or "68kL"
[b]$8	2	Reloc count[/b]

Extrait de ProgFormat.txt de PreOs:

Label		Offset	Size	Desc
--------------------------------------------------------------------
Origin		$0000	4	Bsr to the loader code
					+ Library : $4E754E75
					+ Program : $61000000 + (stubCode-Origin-2)
Signa		$0004	4	Signature of the Kernel Format	
					+ Library : '68kL'
					+ Program : '68kP'
[b]EFlags		$0008	1	Extra-Flags
					$00 (Always 0)[/b]
Reloc		$0009	1	Reloc count
					$00 (Used by the kernel itself)

C'est de cet octet-là que je parle!

> LOL, je connais le format kernel mieux que toi.
Tu connais le vocabulaire du document de spécification du format kernel mieux que lui

Oué mais c'est moi qui l'ai ecrit ;(
Et son idee seule fera plante le programme.

Les anciens kernels sont donc suffisamment idiots pour essayer d'exécuter un programme avec un "reloc count" non nul???

Les programmes kernels sont reentrables.

>Proposition
Sans doute impossible mais comme je connais rien au fonctionnement de la flash je tente quand même au cas ou. Serait-il possible d'avoir accès a la zone vide du secteur flash pour y stoquer les sauvegardes d'un jeux, les parametrages d'une application...

J'ai fait un truc qui s'appelle certificate :
C'est la zone qui se trouve a la fin de l'application.
On aura un nombre limite d'ecriture dedans.
Utile pour stocker des infos non changeantes.

PpHd
a écrit : J'ai fait un truc qui s'appelle certificate :

S'il te plaît, ne réutilise pas les termes utilisés par AMS pour décrire quelque chose de radicalement différent!

Ben tu proposes quoi alors ?

Euh... "long-term storage area"???

Et les autres ?

hummm

Non Volatile Storage Area


PS: non c pas top en fait

la limite c'est x fois par lancement d'application ou x fois maximum. parceque si c'est le deuxième cas, ca peut devenir problématique.
Pour le nom "Storage" tout cours suffira. Même si l'idée de Kevin est claire ca fait un peu long.

Tu disposes de (64Kb - La taille de ton application).
Tu peux ecrire tant qu'il y a de la place.