1

Des nouvelles de PreOS 0.70:

+ 70% des sources ont changees, donc forcement j'ai besoin de temps pour finaliser un peu (Histoire que ca plante pas trop vite pour les beta testeurs).
+ Nouveau systeme de linkage dynamique, bien plus fiable et sur, en 2 passes.
+ Le lancement des programmes _nostub avec kernel::exec est 100% identique a l'AMS (Support de Retval). On pourra normalement compresser tictex avec kpack, le renommer en shell, et le lancer avec SHIFT+ON (Par exemple).
+ Les libraries ne sont plus cherchees que dans le repertoire courant ou dans le repertoire "$system". Ca evitera j'espere de trouver des libraries bugguees qui trainent au fin fond d'un folder. Et puis c'est plus logique.
+ J'espere abandonner les 2 systemes concurrents de SHIFT+ON pour un systeme homogene (Recherche de "$shell"), grace aux gros efforts de mise a jour de kernel::exec.
+ Peut etre kernel::exec supportera les ppg via ppglib (Mais ca fait une dependance de preos sur une lib) => A discuter.
+ Je compte implanter un decryptage de ce que l'on veut faire au lancement:
action: install, uninstall, update, check, launch [Ce que Preos doit faire].
system: Nom du repertoire system, ou preos va chercher les libraries. "system=toto"
launch: Nom du programme a lancer. "launch=tictex" (Limite aux fichiers reconnus par kernel::exec).
shell: Nom du shell lancable grace a SHIFT+ON.
Ex: preos("launch=cf") pour lancer cf sans installer de kernel (Le kernel est installe, cf est lance, puis le kernel est desinstalle -- mais il reste le probleme de la desinstallation possible de hw2tsr).
Ex: preos("install","shell=einstein","system=zzz")
Ex: preos("install","shell=tictex","system=main")
Par defaut, c'est "install","check" si le systeme est vierge, sinon c'est "update". $shell=shell et $system=system.
+ pas de support du KV6 que je compte abandonner apres reflexion.
+ Corrections de bugs
+ Peut etre homogeneiser le systeme de sauvegarde de l'etat d'AMS... (StartKernel et newTrap0 font deux sauvegardes du systemes.).

Evidemment le prix a payer est clair. Ce nouveau preos sera plus gros (Environ 1K de plus).
Donc il me faudra des beta testeurs. Attention! Il est fort probable que ce nouveau Preos soit temporairement bien moins stable que la 0.67!

Liste des systemes a tester (Max 4 beta testeurs par systeme):

92+ HW1: AMS 1.00:
92+ HW1: AMS 1.01:
92+ HW1: AMS 1.05:
92+ HW1: AMS 2.03:
92+ HW1: AMS 2.04:
92+ HW1: AMS 2.05:
92+ HW1: AMS 2.08:
92+ HW1: AMS 2.09:

92+ HW2: AMS 1.05:
92+ HW2: AMS 2.03:
92+ HW2: AMS 2.04:
92+ HW2: AMS 2.05:
92+ HW2: AMS 2.08: Flanker
92+ HW2: AMS 2.09: Billy Charvet

89 HW1: AMS 1.01:
89 HW1: AMS 1.05:
89 HW1: AMS 2.03:
89 HW1: AMS 2.04:
89 HW1: AMS 2.05: IroS
89 HW1: AMS 2.08:
89 HW1: AMS 2.09:

89 HW2: AMS 1.05:
89 HW2: AMS 2.03:
89 HW2: AMS 2.04:
89 HW2: AMS 2.05: naPO
89 HW2: AMS 2.08: LTK
89 HW2: AMS 2.09:

V200 HW2: AMS 2.07:
V200 HW2: AMS 2.08: GoldenCrystal
V200 HW2: AMS 2.09: Flanker

Pour la 89 Titanium, ca attendra qu'elle sorte et d'avoir un AMS definie.

Ensuite ce qu'il faut tester:
+ Installation.
+ anti-crash sous AMS.
+ Lancement d'un programme kernel vide (Plusieurs fois).
+ Lancement de "doors" avec les libraries en RAM.
+ Lancement de "doors" avec les libraries archivees.
+ Lancement de "doors" avec des libraries archivees, des libraries en RAM et une librarie manquante.
+ Lancement de "shell" avec les libraries en RAM.
+ Lancement de "shell" avec les libraries archivees.
+ Lancement de "shell" avec des libraries archivees, des libraries en RAM et une librarie manquante.
+ Lancement de "doors" avec des libraries archivees, des libraries en RAM et le reste dans "stdlib".
+ Lancement de "shell" avec des libraries archivees, des libraries en RAM et le reste dans "stdlib".
+ Lancement de SMA 0.41.
+ Lancement de CF beta 1.
+ Test de SHIFT+ON avec "shell"
+ Test de SHIFT+ON avec "tictex"
+ Test avec vos programmes et vos propres idees.

Options des tests precedents:
+ Test avec BEAUCOUP de fichiers (> 1000). On refait la meme chose.
+ Test avec peu de memoire.
+ Test avec stdlib archivee / non-archivee / indisponible.
+ Tester l'anti-crash.
+ Test avec HW2Patch / sans.

J'espere envoyer la beta la fin de la semaine prochaine.

2

je suis volontaire :
92+ HW2 hw2patchée 2.08 (mais je peux flasher sans pb)
v200 2.09 xpandée (je peux aussi flasher)
matthieu_gallet @ hotmail
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

3

Je suis volontaire:

92+ HW2 sous 2.09, sans HW2 patch ni rien.
Je suis tel la fleur du lotus.
Bien que naissant de la boue,
aucune boue n'y adhère.

4

PpHd
: + 70% des sources ont changees, donc forcement j'ai besoin de temps pour finaliser un peu (Histoire que ca plante pas trop vite pour les beta testeurs).

Argh, je sens que TitaniK restera basé pour toujours sur PreOs 0.67. Je me vois mal merger avec un code changé à 70% pour des features qui seront de toute façon désactivés dans TitaniK car incompatibles avec la Titanium...
+ Nouveau systeme de linkage dynamique, bien plus fiable et sur, en 2 passes.

Il fonctionne comment exactement, ton système?
+ Les libraries ne sont plus cherchees que dans le repertoire courant ou dans le repertoire "system". Ca evitera j'espere de trouver des libraries bugguees qui trainent au fin fond d'un folder. Et puis c'est plus logique.

Hmmm, perso, je ne suis pas sûr que ce soit une bonne idée...
+ Peut etre kernel::exec supportera les ppg via ppglib (Mais ca fait une dependance de preos sur une lib) => A discuter.

Pourquoi pas mettre le support des PPG en interne dans le kernel?
+ pas de support du KV6 que je compte abandonner apres reflexion.

rage Et on s'est fait ch**r pour rien à implémenter ça dans ld-tigcc? sad
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

5

Pourquoi pas mettre le support des PPG en interne dans le kernel?

ça n'a rien à faire dans un kernel roll
la (dé-) compression doit être assurée par une lib, elle n'a pas être privilégiée par rapport aux autres fonctions
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

6

Et ça prendrait 1ko en plus neutral
avatar
« Quand le dernier arbre sera abattu, la dernière rivière empoisonnée, le dernier poisson capturé, alors vous découvrirez que l'argent ne se mange pas. »

7

Kevin Kofler :
Argh, je sens que TitaniK restera basé pour toujours sur PreOs 0.67. Je me vois mal merger avec un code changé à 70% pour des features qui seront de toute façon désactivés dans TitaniK car incompatibles avec la Titanium...

Oui et non.
Le nouveau design de Preos avec son nouveau moteur "sld" rend les portages style TytaniK plus facile.

Il fonctionne comment exactement, ton système?

Je le dirai lorsque je serai sur qu'il est sur smile
La j'ai un probleme du au fait que kernel::relocation est reentrante, dans le cas ou le programme
principal importe la librarie de compression (ie SMA).

Hmmm, perso, je ne suis pas sûr que ce soit une bonne idée...

Ca me parait plus sain.

Pourquoi pas mettre le support des PPG en interne dans le kernel?

Parce que je kernel est deja gros, et que je ne veux pas favoriser des formats particuliers.

rage Et on s'est fait ch**r pour rien à implémenter ça dans ld-tigcc? sad

Desole sad
Vraiment desole sad
Je peux encore changer d'avis...

8

*+ Les libraries ne sont plus cherchees que dans le repertoire courant ou dans le repertoire "system". Ca evitera j'espere de trouver des libraries bugguees qui trainent au fin fond d'un folder. Et puis c'est plus logique.*

Ah non, déjà j'ai jamais de répertoire 'system' (même pour CF, j'utilise des PreOS plus récents),
et si jamais il devait y avoir un répertoire avec pleins de libs ça devrait être main plutôt.
Et ne pas chercher non plus dans le répertoire courant (ça oblige à mettre tout ensemble,
les exécutables et les libs, alors qu'il est beaucoup mieux pour l'utilisateur de regrouper
les libs et le kernel dans un répertoire et les progs dans le reste de la caltos. Mais encore une
fois pas 'system' mais main !!!)


Kevin:
*Pourquoi pas mettre le support des PPG en interne dans le kernel?*

Naaaaaaaan !!!!
Je suis tel la fleur du lotus.
Bien que naissant de la boue,
aucune boue n'y adhère.

9

1. preos("system=main") fait que le repertoire $system est main.
2. Des executables kernels ont souvent besoin de quelques libraries personnelles (RO Lib ou Lib-on-demand) permettant un grand degree de flexibilite.

10

Ah oki, system est réglable.
Ben dans ce cas, si $system vaut main par défaut je suis tout à fait pour. top
Je suis tel la fleur du lotus.
Bien que naissant de la boue,
aucune boue n'y adhère.

11

Sinon le probleme rencontre est complexe. Mais je pense avoir une solution en fusionnant partiellement les passes et avec quelques variables supplementaires RefCount et un RelocFlag.
Et question deboggage je suis a essayer de faire marcher SMA avec tous les fichiers en RAM.

12

Bon SMA marche parfaitement. Il manque CF, puis tester le SHIFT+ON, puis tester sur d'autres AMS.

Reste aussi a le faire marcher lorsque tous les fichiers (preos, sma, stdlib, gfx, chaos1) sont en RAM.
Ca plante apres le lancement de SMA, mais preos recupere mal le crash.
Je sais, je sais. Je teste des configurations de losers (Au lancement de SMA, il doit lui rester ~8K).

Ajout du message d'erreur "Kernel Panick" grin

13

*Ajout du message d'erreur "Kernel Panick" grin*
Trop tard, je l'ai fait en premier tongue


Tu penses intégrer PreOS 0.70 à PedRom ?
Je suis tel la fleur du lotus.
Bien que naissant de la boue,
aucune boue n'y adhère.

14

Sauf qu'il ne signifie pas que Preos est buggue mais qu'il detecte un bug dans votre systeme de libraries tongue

Tu penses intégrer PreOS 0.70 à PedRom ?

D'apres toi ? (question idiote).

15

Ben, oui, mais si autant de code a changé, ça aurait pu être "pas pour l'instant,
sauf si tu veux transformer ta caltos en grille-pain". triso
Je suis tel la fleur du lotus.
Bien que naissant de la boue,
aucune boue n'y adhère.

16

neutral Le code qui a change ne pourra jamais transforme la calc en grille pain. Au pire on peut pas lancer un prog, c'est tout.

17

C'était une blague cheeky
Ca en est où ? Tu enverras une beta quand ?
Je suis tel la fleur du lotus.
Bien que naissant de la boue,
aucune boue n'y adhère.

18

Quand Preos 0.70 sera sortie.

19

Je suis volontaire pour bêta tester sur ma V200 AMS 2.08 (le mail c mon pseudo en minuscules @free.fr)
avatar
Le scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin.
T'as un problème ? Tu veux un bonbon ?
[CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes

20

SHIFT+ON fonctionne avec tictex, et avec shell.

21

au passage, il faudrait peut-^etre penser à virer la 0.54 des "best downloads" du site... Il n'y a qu'à regarder la partie questions, tout le monde prend cette version dépassée...
Je verrais bien une "latest preOS version" par contre...

Au passage, pour les librairies ça peut ^etre une bonne idée, trop de gens gardent les librairies dooros avant d'installer preOS...
avatar
Maintenant j'ai la flemme de garder une signature à jour sur ce site. Je n'ai même plus ma chaîne Exec sous la main.

22

Je compte faire un effacement sauvage de tout ce qui traine comme lib lors de l'install de Preos tongue

23

moi auusi je suis volontaire TI89 HW1 AMS 2.05

24

Devinez quoi ? Je suis en retard. Aucune raison particuliere, sinon ma flemme.

25

Ah ? Toi aussi ? cheeky
Je suis tel la fleur du lotus.
Bien que naissant de la boue,
aucune boue n'y adhère.

26

Desolé pour le retard.
Mais ca tombe bien vu que je vais devoir repasser sur AMS 2.09 sur ma TI89(j'ai un peu de math a faire en stage) je suis preneur.
Vraiment sympa les nouvelles fonctionnalités.
+ pas de support du KV6 que je compte abandonner apres reflexion.
Heu je me suis perdu dans le compte des version kernel la V6 elle fait quoi?


avatar

27

Relogements compressés. C'était la seule vraie innovation prévue pour PreOs 0.68, et PpHd la laisse tomber. sad Et pourtant, on s'est fatigués à gérer ça dans notre linker. sad Ben tant pis, il faudra programmer en _nostub pour avoir les relogements compressés. tongue
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

28

le _nostub vaincra trivil
avatar
« Quand le dernier arbre sera abattu, la dernière rivière empoisonnée, le dernier poisson capturé, alors vous découvrirez que l'argent ne se mange pas. »

29

Je compte surtout la repousser (Peut etre un KV7 en preparation), car c'est moins important qu'un kernel stable et sur.

30

Enfin, lorsque je dis stable et sur, je me comprends, non ? Aussi stable que possible. Faut pas chercher plus loin.