Civilisation - Page 10

parceque side prend de la place

Au fait, il y a une petite erreur dans mon analyse de la séquence d'appel. Elle ne change rien à l'argumentation, mais je voudrais quand-même la rectifier.
La séquence suivante n'est qu'une des 2 séquences d'appel possibles:
* NG_execute appelle la routine interne EvalESI.
* EvalESI appelle la routine interne EvalASMFUNC.
* EvalASMFUNC appelle kernel::exec des sources de PreOs.
* kernel::exec appelle EX_patch.
* kernel::exec appelle le programme avec un jsr (a5).
Il y a aussi celle-ci:
* L'interpréteur de ligne de commandes la routine interne ShellExecuteCommand.
* ShellExecuteCommand appelle kernel::exec des sources de PreOs.
* kernel::exec appelle EX_patch.
* kernel::exec appelle le programme avec un jsr (a5).
(Ne me demandez pas pourquoi l'interpréteur de ligne de commande n'utilise pas push_parse_text et NG_execute comme il devrait le faire.)
Mais les étapes importantes sont de toute façon les 2 dernières, qui sont les mêmes.

2 ptits truc en passant:

1) l'installation d'un kernel c'est pas la mort quand même! moi kernel ou nostub je m'en fiche totalement: l'essentiel c'est que ça marche... et si ça marche plus a cause des nouvelles versions on en prend une ancienne, point!

2)Kevin m'a l'air toujours au centre des engueulades: lesquelles sont constamment bourées de "cite". c'est bien gentil mais ça fait prendre de la place à la page qui mets plus longtemps à se charger... moi aussi je sais faire des arguments idiots!

un truc: demander à un admin d'ouvir une section (mauvaise foi) à coté de coups de gueule et de la faire gerer par l'ami kevin...
je le répete: l'utilisateur se fiche de la bataille kernel: il veut que ça marche.

srkat, j'aprouve totalement ce que tu dit, je crois que ça peut même être généralisé à pas mal de programmeurs. (de bonne foi)

bah faut quand même pas exagerer. Kevin n'est pas toujours de mauvaises foi mais parfois il va un peu trop loin. et il oublie qu'il ne détient pas la vérité absolue

La mauvaise foi n'est évidemment pas l'atribut de Kevin exclusivement, mais il y a des gens (que je ne citerai pas mais il suffit de regarder si certains posts ont manqué d'objectivité) qui font preuve d'une mauvaise fois caractérisée. La raison pour laquelle Kevin passe le plus pour plein de mauvaise foi est que c'est le seul qui a l'avis opposé de tous les autres détenteurs de mauvaise foi, et pour que le discours soit équilibré, il lui faut autant de mauvaise foi qu'à tous ses detracteurs réunis.
Mais ces tournois de mauvaise foi font parfois aparaitre des arguments relativement interessants dont un exposé objectif eût été fort interressant.

Pour revenir à Civilisation(®?), je viens d'avoir un Pb (première fois que je l'executait vraiement en Nostub:
Quand je veux lancer l'EXE, il me met "error : EXEC or APEC String too long" ou qqch comm ça. (avec une ROM patché HW2, je crois)
Ca veut dire koi (execute_in_ghost_space n'a rien changé)

quel rom ?

sa veux dire que ton executable est trop grand (>8 Ko pour les 2.01/2.02/2.03 et > 24Ko pour les 2.05 et sup


EDIT: Godzil est pas bien reveillé aujourd'hui un OpenNuitBlanche c pas tiptop

24

Oui, compresse le

• TIGCC :: Project > Options > Compress file
ou
• Installe un Kernel qui fera sauter la protection des 8/24ko.

Une solution est mieux qu'une autre.

Je reediterait mon post si il le faut si tu le reédite

[Vertyos] Viens sur IRC ou répond à mon mini message... Tu comprendras pourquoi j'ai édite.

En effet la compression est utile.

N'est-ce pas ?
On est tous d'accord

Ah ouais, ça m'a fait gagner pas mal la compression!
Et je pourrais dépasser les 24 ko en compressé ou il faudra que je remette en kernel ?

Non, tu pourras aller jusqu'à 64Ko

jackiechan
a écrit : Non, tu pourras aller jusqu'à 64Ko

non compressé (faut préciser)

C'est expliqué un peu simplement. La ti a une limitation a 8/24Ko selon l'AMS mais il existe différents moyens de la contourner:
- installer un programme qui la désactive(kernel, certains TSR, autostart)
- lancer ton programme via un lanceur qui la désactivera la protection.

La compression en elle même n'est pas ce qui te permet de casser la limite mais le décompresseur fait aussi la désactivation de la protection.

godzil> Ah bon ?
Remarque, ça me paraît logique en fait

Il y a aussi sstart (FlashApp de Greg Dietsche - son gros défaut est de ne marcher que sur AMS 2.05+ alors qu'elle pourrait parfaitement marcher sous n'importe quel AMS 2.xx, du moins telle qu'elle est actuellement) qui fait (en gros) ttstart + autostart...

> La compression en elle même n'est pas ce qui te permet de casser la limite mais le décompresseur fait aussi la désactivation de la protection.
Oui.

d'ailleur la compression permet de gagner de la place en mémoire archive, et pas en ram (car quand on décompresse on le décompresse en RAM, donc si le prog fait 64Ko non compréssé a l'execution on a au moins 64Ko pris en ram..)

Il fait quoi autostart? il lance automatiquement ttstart ?

non autostart permet de se passer du lanceur de PPG

Mais il se sert effezctivement de ttstart.
C'est pratique ça te permet de lancer le PPG directement.
Et ça permet aussi de ne pas avoir à refermer les parenthèses d'un programme pour pouvoir le lancer (très pratique).

en gros il va remplcer myprog( par ttstart(myprog)

Il y a d'autres solutions que celles mentionnées par Vertyos:
* installer KerNO ou IPR
* utiliser ttstart (éventuellement avec AutoStart)
* utiliser un explorateur comme TICTEX, Einstein, sh'L etc. etc. etc.
* utiliser Super Start
* utiliser PedroM

Mais la compression automatique de TIGCC (merci d'ailleurs à Thomas Nussbaumer de la TICT pour cette contribution) est de loin la plus pratique parce qu'elle crée automatiquement un lanceur qui permet de lancer directement le programme comme si rien n'était, et parce qu'elle économise de la mémoire à travers la compression. Elle se combine d'ailleurs très bien avec ttstart, AutoStart, Super Start, les explorateurs et PedroM (oui, elle intègre elle aussi la décompression des PPGs ExePack!) parce que ces programmes-là permettent de lancer directement le PPG sans avoir besoin du lanceur. Mais inclus quand-même le lanceur personnalisé généré automatiquement par TIGCC avec le programme parce que pas mal de gens trouvent ça pratique.

Oui, c'est ce que je comptais faire. mais j'ai aussi vu que ttsatart est plus gros d'à peine quelques octets, et je l'avais déjà pour d'autres jeux, donc je conseillerai d'utiliser ttstart au lieu du lanceur.
Ce lanceur automatique est très pratique pour tester le programme avec VTI à partir de l'IDE, mais on-calc, je prefère de loin ttstart, vu que les autres bons jeux que j'ai sont en ppg, donc autant avoir ttstart en un seul exemplaire (et pas un par programme).