Un projet etrange - Page 2

meow>un jeux un peu similaire, c'est de ralentir un peu la calc à chaque fois que tu perd

je n'irai pas jusqu'au terme d'intégrsite

mais l'idée y est



(tant que Kevin est pas là, profitons-en ) (je plaisante ! ce n'est pas mon style que de profiter de l'abscence de quelqu'un pr frapper)

MacIntoc : ça existe déjà ! il s'appelle Tibo Casio Emulator

heurf, je blague, c pas vrai (enfin, je c pas si c pas vrai ... mais je pense enfin .. )

Tu parles de quoi là

c pas pareil, il s'agit de ralentir, pas d'immobiliser

Le Tibo Casio Emulator ralentit, il ne bloque pas

Pour l'idée de programme du post 1, p-ê mettre plusieurs mode de jeu:
1- Entraînement -> aucune conséquance, c pr tester le jeu
2- Normal -> ralentissement
3- tête brûlée -> effet "virus"

Thibaut>au niveau de la casio, y a pas de grande différence (ou alors, c ton emu qui emule mal la casio)

ftp83>bonne idée

merci

Je ne critique pas les programmeurs des kernels qui sont, je l'ai déjà dit, bien plus compétents que moi dans ce domaine.
Je ne vois pas par quel bout prendre le boulot pour faire un kernel (en vérité, je n'ai jamais réfléchi à la question plus d'une seconde, car de toute façon, mon but n'est pas de faire des programmes incompatibles avec certaines calculettes).
Parce que c'est bien le fait de faire des programmes sous kernel, qui nécessitent un kernel installé (donc qui ne marchent pas sur toutes les machines à la sortie d'usine, au contraire des _nostub qui marchent sans programmes additionnels), que je critique...
Je dis bien que les _nostub marchent sans programmes additionnels, car ceux qui ont des fichiers trop gros n'ont qu'à les compresser et faire des lanceurs, comme la compression ppg le propose depuis des années maintenant. ttstart est juste le lanceur générique pour ceux qui ne veulent pas avoir un grand nombre de lanceurs sur leur calculette...

Les RAM_CALLS permettent au programmeur de ne pas s'occuper autant du source que s'il faisait tout lui-même, certes (au même titre que les BSS blocks qui sont eux aussi pratiques pour ceux qui les utilisent), mais ça nécessite un kernel (donc ça ne marche pas sur toutes les machines à la sortie d'usine). Est-ce que les RAM_CALLS sont parfaitement optimisés (le call ne prend-il pas plus de temps que la fonction elle-même, notamment) ?

Comme je l'ai déjà dit: un kernel est un programme _nostub (et c'est parce que c'est un kernel que je ne l'utilise pas, bien que ce soit une espèce de programme _nostub).


Par contre, je pense que nous sommes d'accord sur au moins un point: si TI avait mieux documenté, mieux programmé et moins bridé ses calculettes, et mieux écouté les programmeurs qui ne sont pas de chez eux, il y aurait moins eu besoin de kernels (il aurait peut-être pu y en avoir pour ajouter des fonctions auxquelles les programmeurs de TI n'auraient peut-être pas pensé). Mais on ne refait pas le passé !

Mais c trés bien les kernel. Ca empèche les progs _nostub de planter

MacIntoc> Exact
(du moins, c vrai pour PreOS qui est le seul Kernel actuellement mis à jour)

Par contre, je pense que nous sommes d'accord sur au moins un point: si TI avait mieux documenté, mieux programmé et moins bridé ses calculettes, et mieux écouté les programmeurs qui ne sont pas de chez eux, il y aurait moins eu besoin de kernels

Tant que tu ne retires pas le "moins" à la fin de la phrase, je suis d'accord avec toi.
Si TI avait mis un anticrash à l'origine, plutôt qu'un affichage de plantage, les kernels perdraient un peu d'intéret pour moi. (un peu seulement !)

squale92 a écrit :
(du moins, c'est vrai pour PreOS qui est le seul Kernel actuellement mis à jour)

On dirait du Kevin tout craché

> Mais c trés bien les kernel. Ca empèche les progs _nostub de planter !
Et KerNO, qui n'est pas un kernel au sens où vous l'entendez, que fait-il ?
Les _nostub bien programmés ne plantent pas beaucoup, pour ne pas dire pas. Qui peut me dire qu'il a fait planter TI-Chess par la faute de TI-Chess ? (Je m'explique: nous avons reçu des mails de gens qui râlent que certains programmes de TICT font planter leur calculette. En fait, ce sont d'autres programmes buggés lancés avant TI-Chess qui provoquent le crash... D'ailleurs, ce sont des gens qui ne savent pas se servir de leur calculette: ils ont souvent DoorsOS).

Il n'y a pas que l'anticrash qui manque au système: il manque le support de fonctions avancées, du genre PIC/PID; il manque beaucoup de fonctions facilement accessibles pour avoir plein de trucs de bas niveau. Les BSS ne sont pas, à mon sens, indispensables (les fonctions du genre HeapAlloc suffisent).
Si TI réécrivait une ROM complète (et refaisait par la même occasion un hardware propre, on peut toujours rêver...) en écoutant les programmeurs, je serais pour !


Je voudrais une réponse à 'Est-ce que les RAM_CALLS sont parfaitement optimisés (le call ne prend-il pas plus de temps que la fonction elle-même, notamment) ?', car je n'ai pas accès aux binaries (et encore moins au source) du dernier kernel top-secret, donc je ne peux pas le savoir moi-même...

Et KerNo fout plus le bordel qu'autre chose qu'en il est installer par-dessus un vrai kernel

Tu installes KerNO par-dessus un kernel, toi ?!

Et je n'ai toujours pas de réponse à ma question... Vous n'êtes pas logiques: vous me détruisez, assez souvent à juste titre je le reconnais, quand je critique les kernels; mais quand j'essaie d'en savoir plus, vous ne répondez pas ! Ou alors vous n'avez pas vu le message, mais j'ai peine à le croire...
squale, Thibaut, TiMad, PpHd... ?

[pub]
Bon sang, mais comment vous l'expliquer !!!

Il n'y a pas forcement besoin d'un kernel si vous voulez seulement un AntiCrash pour vos programme _NOSTUB !!!

Il existe (au moins 1) programme qui fait anticrash, il s'apelle Ti-Guard !

Et qui en plus est OpenSource !
[/pub]

désolé pour G Dietsche, qui a fait des bons trucs, mais KerNO, pr moi, c pas terrible terrible : tu installe un prog (de la même façon que tu installe un kernel !), mais celui-ci (le prog KerNO) ne t'offre que quelques uns des posssiblités des kernels récents...
=> installer un prog nommé NOKernel (en gros), ou un Kernel, ça revient à unstaller un programme, alors, autant installer un kernel (puisque c'est ce qui offre le plus de fonctionnalités)

Avoir DoorsOS ne signifie pas forcément ne pas savoir utiliser sa TI !

Si TI réécrivait une ROM complète (et refaisait par la même occasion un hardware propre, on peut toujours rêver...) en écoutant les programmeurs, je serais pour !

Tu crois que bcp de monde serait contre ?

J'aimerai bien répondre à ta question concernant les RAM_CALL, mais je n'ai pas les connaissances nécessaires pour le faire, désolé : je ne connais quasiment rine à l'ASM (et PreOS est programmé en ASM)
Mais PreOS est open-source, il me semble (du moins, il me semble ! pas sûr pour les versions distribuées)

godzil> mais est-ce que l'anti-crash de TI-Guard est aussi performant que celui de PreOS ?
(si tu as fait ton anti-crash de la même façon que je m'étais amusé à en faire un, juste en détournant les vecteurs d'interruptions qui provoquent des crashs, ça doit pas être aussi performant que preOS, qui fait pas mal de trucs en plus)

Squale> mon Anti Crash est pas terminé (d'ou le Beta), aufinal je compte en faire une véritable plateforme de débugage (mais bon j'prend mon temps pour le continuer lol)

Sinon a pars permettre le ESC-ON, je vois pas se que tu peut vraiment faire de plus que détourner les Int fautives de zoli barres noires, ha si, on pourrait detecter les prog qui se mette en boucle.. hum... si le prog desactive les int, c pas possible, a moins de le ralentire notablement... heu sinon non j'vois pas.

Enfin si vous avez des idées auquel je n'ai pas pensé, faite moi le savoir, TiGuard n'est la que pour evoluer, et avoir les amélioration demandé pas les users

détecter les ints, mais faire bcp pr les redirigeer
(par exemple, restauration des TSR, et autres fonctionnalités proposées par PreOS )

(et oué, shift+ON marche pas (normalement) si l'AUTO_INT_6 est désactivée)

XDanger >> 'Est-ce que les RAM_CALLS sont parfaitement optimisés (le call ne prend-il pas plus de temps que la fonction elle-même, notamment) ?
Oui, un RAM_CALL est parfaitement "optimisé" en vitesse vu que ce n'est rien d'autre qu'une variable dont la valeur est initialisée par le kernel, de la même manière que les adresses absolues sont initialisées lors du relogement du programme !

>> Et je n'ai toujours pas de réponse à ma question...
Laisse-nous le temps de voir ce topic ! on n'est pas là 24H/24H

> Oui, un RAM_CALL est parfaitement "optimisé" en vitesse vu que ce n'est rien d'autre qu'une variable dont la valeur est initialisée par le kernel, de la même manière que les adresses absolues sont initialisées lors du relogement du programme !
OK. Si c'est fait au relogement ça va. Je savais qu'un RAM_CALL était une variable initialisée par le kernel...

> Laisse-nous le temps de voir ce topic ! on n'est pas là 24H/24H
Certes, mais au bout de deux jours, alors que vous avez fréquenté beaucoup d'autres topics, ça me paraissait étonnant que vous n'ayiez pas vu celui-ci...

post#46>Il a pas été conçus entre-autre pour ça ?

Par contre, je pense que nous sommes d'accord sur au moins un point: si TI avait mieux documenté, mieux programmé et moins bridé ses calculettes, et mieux écouté les programmeurs qui ne sont pas de chez eux, il y aurait moins eu besoin de kernels (il aurait peut-être pu y en avoir pour ajouter des fonctions auxquelles les programmeurs de TI n'auraient peut-être pas pensé). Mais on ne refait pas le passé !

Faut pas rêver. Le capitalisme, c pas ca !!! Cherche du coté de O²

> Faut pas rêver. Le capitalisme, c pas ca !!!
Si, mais quand y a de la concurrence sérieuse TI n'a pas (plus?) de concurrents, donc forcément ils sont partisans du moindre effort

Ouais c pas faux ca

Sans vouloir être méchant, je pense que l'O² n'aura que peu de succès (limitée à quelques frenchies qui ont des sous, des compétences en électronique)... En plus, aussi puissante qu'elle soit, elle est largement dépassée par les Palm 68k clockés bien plus vite, par exemple...

C'est en effet dommage que TI n'ait plus de concurrents...

a la différence que les palm ne sont pas des calculatrice

Au fait, le prbm du clavier et de la coque est régler grace à Vince

Floodeurs repérés... Fire in the hole !

Je crois que j'aurais pas trop de mal, mais je sais
pas quel genre de jeu inclure. Je pensais à du Picross,
mais je viens de remarquer que quelqu'un en a sorti
une beta