ARCHIVES


Kernel
Universal OS[Archive Ti-Fr v2]
Taille du fichier : 28.726 Ko
Nombre de téléchargements : 744
Nombre de vues : 4306
Description rapide : Un très bon os. Créé par le programmeur de HW2PATCH donc on peut se dire que le programmeur est à la pointe sur ce domaine.
Auteur de l'archive : Julien_Muchembled
Calculatrices concernées : TI-89 TI-92+
Hardware concernés : HW2
ROMs (AMS) supportés : AMS1.00~1.05 AMS2.01~2.05
Langage de programmation utilisé : ASM Kernel
Description Complète : Universal OS 1.30 pour TI 89 et TI92 Plus
Copyright (C) 2000-2001. Tous droits réservés.
Disponible sur www.ticalc.org et www.ti-fr.org
ftp://jm.devel.bourges.net

I) Introduction

Universal OS est un noyau (kernel). Il fonctionne sur toutes les
calculatrices et il est 'entièrement' (cf 'Particularités') compatible
avec DoorsOS II 0.99. Vous pouvez archiver n'importe quelle librairie et
exécuter des programmes de plus de 8 ko directement, même sur les
ROM 2.0x. Les niveaux de gris fonctionnent sur HW1 et HW2 à condition
que le programme utilise une librairie récente pour les gérer :
graphlib, gray4lib, ou gray7lib (les 8 niveaux de gris ne sont pas
supportés sur HW2) par exemple.

Universal OS n'est pas terminé : il reste encore quelques limitations.

Contenu :
- install : pour installer et désinstaller
- kernel : le noyau (non nécessaire à la désinstallation)

Universal OS est un 'freeware'. Sa distribution est encouragée, tant que
les fichiers restent ensembles et non modififiés depuis le moment où ils
ont été initialement distribués.

II) Installation et utilisation

Si vous possédez une HW2 2.0x, vous devez utilisez HW2Patch.

Lancez install. Vous pouvez maintenant utiliser n'importe quel programme
en assembleur. Seul ce programme install peut désinstaller correctement
ce kernel.

NOTES : - kernel doit être dans le même répertoire que install.
- Vous pouvez quitter le programme assembleur en cours à
n'importe quel moment (à moins que le programme en question
ne l'en empêche), en appuyant sur ESC+ON.
- Utilisez ce programme à vos risques. Je ne peux être jugé
responsable des dommages qui pourraient se produire.
- N'INSTALLEZ PAS DoorsOS après avoir installé Universal OS (à
moins que vous l'ayez désinstallé depuis).
- NE DESINSTALLEZ PAS Universal OS avec le programme de
désinstallation livré avec DoorsOS ou un autre kernel.
- Universal OS ne remplace pas automatiquement un ancien kernel,
ceci pour des raisons de sécurité (comment puis-je savoir
comment désinstaller un kernel ! Chacun a sa propre façon de
s'installer, Universal OS y compris).

III) Particularités

- util, userlib, gray4lib, gray7lib (sauf sur HW2), graphlib et linelib
ont été reprogrammées et intégrées (cad dans la variable 'kernel') à
Universal OS.
TOUTE LIBRAIRIE EXTERNE PORTANT L'UN DE CES NOMS NE SERA PAS PRISE EN
COMPTE.
- Vous pouvez lancer le programme nommé 'doors' à l'aide de
[Shift]+[ON]. Seule différence avec DoorsOS : [Shift]+[ON] fonctionne
plus souvent.
- Tout reset est détecté par Universal OS qui affiche alors un menu :
1) réinitialiser
2) éteindre
3) transférer toutes les variables dans une autre calculatrice
Remarques :
- grâce à VTI pour pouvez aussi tous transférer vers un ordinateur
- lorsque vous éteignez la calculatrice, il se peut qu'elle se
rallume toute seule au plus deux secondes après (j'essaierai de
trouver une solution à ce problème étrange; tout ce que je sais pour
le moment, c'est que c'est lié au link).
- ATTENTION ! Cette fonctionnalité ne garantit pas que les variables
transférées ne plantent pas la calculatrice de destination. En
effet, elles peuvent avoir été mal modifiées s'il y a eu plantage.
Le mieux, c'est de sauvegarder le contenu de la calculatrice de
destination.
- Vous pouvez éteindre la calculatrice à tout moment (même quand AMS est
occupé) à l'aide de [2nd]+[ON].

- Universal OS ne récupère pas la mémoire laissée allouée par un
programme : je ne vois vraiment pas comment on peut savoir si un bloc
mémoire est perdu ou est important. D'ailleurs, l'algorithme employé
par DoorsOS est imparfait.
- les fonctions (un)reloc(2) ne sont pas supportées : par exemple,
prosit ne fonctionnera pas. (Je pense que c'est le seul)
- la fonction userlib::exec ne supporte le programmes zippés : c'est la
seule différence avec les librairies de DoorsOS II 0.98.

IV) Notes aux programmeurs

Ces remarques concernent aussi les programmeurs qui utilisent DoorsOS.

* ramcalls :

- Idle equ _RAM_CALL_015 :

void Idle (void); (=> d0-d2/a0-a1 sont détruits)

Soit I le masque d'interruption, Idle retourne dès qu'une interruption
AIn avec n > I se déclenche. Il y a donc une différence notable avec
tios::idle : quel que soit I, tios::idle retourne si n > 1, à moins
qu'une touche est maintenue, auquel cas il retourne aussi si n = 1.

=> Alors que cette fonction permet d'économiser davantage d'énergie,
remplacer bêtement tios::idle par Idle dans un programme augmentera la
consommation ! En fait, Idle permet à userlib/util::idle_loop d'être
plus efficace, notamment lorsque les niveaux de gris sont activés.
Pour utiliser cette fonction de manière efficace, il faudra s'occuper
de I si c'est possible.
=> Idle ne pourra jamais se comporter exactement comme tios::idle
(hormis quand userlib/util::idle_loop l'utilise mais elle a accès à
une variable interne). tios::idle pourra encore être utile si les
niveaux de gris ne sont pas activés.

Contrairement à tios::idle, Idle fonctionne correctement sur VTI. Il
ne s'agit pas de diminuer la consommation (!) mais de respecter les
temps d'exécution.

- Les autres ramcalls sont documentées dans DoorsOS.

* userlib :

- userlib::KbdMgr equ userlib@0012 :

En entrée, elle demande dans a0 l'adresse d'une fonction, qui sera
appelée par KbdMgr avec un paramètre dans d0.l :
- d0.l > 0 : code de la touche qui a été pressée
- d0.l = 0 : temps spécifié écoulé
Cette fonction peut agir en conséquence et doit répondre à travers
d0.l :
- d0.l >= 0 : KbdMgr quitte avec cette valeur
- d0.l < 0 : ~d0.l (~ = not) indique un délai en ms (millisecondes)
Le délai est compté à partir du dernier appel avec d0.l, ce qui
signifie que si lors appui a lieu au bout de 0.1 s d'attente,
retourner ~1000 rendra le contrôle 0.9 s plus tard. La gestion du
clavier ne perturbe donc pas le timer. Si vous voulez quand même que
KbdMgr rende rappelle la fonction 1 s plus tard, il faut d'abord
retourner ~0.
L'APD est supporté. Idle est utilisée. KbdMgr est réentrante. En cas
d'erreur, d0.l < 0.

Registres d1-a6 : KbdMgr n'en détruit aucun, et ils sont passés à la
fonction spécifiée lors de l'appel à KbdMgr.

Tout comme userlib/util::idle_loop, cette fonction repose sur l'AI1 du
tios. D'ailleurs, idle_loop se résume à ceci :

idle_loop:
move.l a0,-(a7)
lea IdleLoopCallBack(pc),a0
jsr KbMgr
move.l (a7)+,a0
rts
IdleLoopCallBack:
tst.w d0
bne.b ILCBret
move.l #$80000000,d0 ; attendre
ILCBret:
rts ; 24j 20h 31min 23.647s :)

Il y a tout de même une différence avec la routine idle_loop
d'Universal OS : voir les remarques sur Idle.

* le point de sortie _exit :

Imaginez ce cas : une librairie A utilise, dans sa section _exit, une
librairie B et de même, B utilise A dans sa section _exit. Si A ou B
a besoin d'une information qu'elle a supprimé auparavant alors il y a un
bogue, aussi sophistiquée la protection Anti Crash puisse être.
Donc n'utilisez pas de librairies à cet endroit.

* Compatibilité

Pour qu'il n'y ait plus de problèmes liés à de nouvelles versions de
ROM, évitez les constantes et préférez les RAM_CALL et les librairies,
PUIS les ROM_CALL.
En effet, TI a changé quelques ROM_CALL avec la ROM 2.xx : par exemple,
_ROM_CALL_15C ne pointe plus sur la routine EM_blockErase mais sur une
variable en rapport avec le clavier.
N'utilisez pas LCD_MEM si le programme est en niveau de gris ! Il existe
des variables et des fonctions adaptées.

Faites en sorte que vos programmes soient compatibles à la fois sur la
TI 89 et la TI92 Plus. Ceci concerne surtout le clavier.

* le fichier d'en-tête DoorsOS.h :

N'utilisez pas :
- doorsos::caddcert equ _ROM_CALL_126
doorsos::cfindcertfield equ _ROM_CALL_129
doorsos::cgetcert equ _ROM_CALL_12C
doorsos::cgetvernum equ _ROM_CALL_131
doorsos::EM_blockErase equ _ROM_CALL_15C
doorsos::EM_blockVerifyErase equ _ROM_CALL_15D
doorsos::EM_delete equ _ROM_CALL_15E
doorsos::EM_open equ _ROM_CALL_163
doorsos::EM_put equ _ROM_CALL_164
doorsos::EM_writeToExtMem equ _ROM_CALL_168
- APD_INIT equ LCD_MEM+$F10
APD_TIMER equ LCD_MEM+$F14
APD_FLAG equ LCD_MEM+$F42
mais les fonctions userlib::get_APD et userlib::set_ADP.
- doorsos::ER_throw macro
dc.w $A000+\1
endm
par sécurité, même si j'ai amélioré la protection Anti Crash pour que
le programme quitte le plus proprement possible.

* les appels à la ROM :

Considérez que toutes les fonctions de tios détruisent D0-D2/A0-A1 :
ceci explique pourquoi Falldown and Tetris ne sauvegardent pas les noms
sur les ROM 2.xx. Donc faites attention avec les macros WriteStr et
WriteStrA.

V) Problèmes connus

Universal OS utilise la pile superviseur pour y sauver des informations
importantes. Mais certains programmes boggués écrivent à cet endroit :
avec d'autres noyaux, ce genre de bogue est invisible puisqu'ils n'y
sauvent rien, mais avec Universal OS, la calculatrice peut se planter.

VI) A faire

- supporte les fonctions reloc
- finir la fonction userlib::exec pour qu'elle puisse exécuter des
programmes zippés.
- empêcher les fonctions graphiques d'écrire en dehors du plan
selectionné si les coordonnées sont mauvaises et reporter le bug par
un message.

VII) Historique

01/05/2001 : Universal OS 1.30
- Support des programmes C qui ont été compilés avant que le support de
exit et de atexit soit corrigé.
- Universal OS détecte s'il est lancé sur VTI.
- VTI HW2 (note : si le boot code est absent, AMS 2.0x considère que
c'est une HW2, mais Universal OS réagit de la même manière que AMS
1.0x et détecte une HW1) :
- Le port $70001D est 'émulé' pour que la routine HW2 de niveaux de
gris fonctionne.
- AMS 2.0x : HW2Patch n'est pas nécessaire à l'installation.
- La barre d'état est redessinée lors de la restauration de l'écran,
pour que il soit synchronisé avec les changements apportés par les
programmes lancés.
- Correction d'un bug dans ReturnValue (_RAM_CALL_00F).
- Pour les programmeurs (cf IV) :
- Ajout de la ramcall Idle : cette fonction a le même but que
tios::idle mais corrige de gros défauts :
- Lorsque les niveaux de gris sont activés, Idle laisse l'AI1 se
déclencher normalement pour éviter le clignotement.
- Sous VTI, le port $600005 est émulé pour éviter les erreurs au
niveau du temps d'exécution.
- Ajout de userlib::KbdMgr. En fait, elle était déjà présente, mais
non documentée et boguée.

20/01/2001 : Universal OS 1.21
- HW2 : Nouveau gestionnaire de niveau de gris, théoriquement parfait.
J'ai abandonné l'implémentation de Johan Eilert
(http://alh.dhs.org/ti89/hw2graypost.html) mais j'ai gardé son idée
(éviter de rafraîchir les lignes qui sont en train d'être affichées,
en utilisant le port $70001D).

11/01/2001 : Universal OS 1.20
- HW2 : Niveaux de gris parfaits ne nécessitant pas de réglage (en fait
si !). adjust est donc retiré et les commandes [<>]+[<] et [<>]+[>]
n'ont plus aucun effet.
La technique utilisée est celle trouvée par Johan Eilert. Toutefois,
je n'ai pas réussi à implémenter sa technique exactement comme il la
décrit à http://alh.dhs.org/ti89/hw2graypost.html.
Merci beaucoup à Thibaut Giesi et à Flavien Racine pour avoir effectué
tous les tests sur 89 et 92+. Cela leur a pris des heures.
- Lorsqu'on éteint la calculatrice avec Universal OS ([2nd]+[ON]),
l'indicateur busy est affiché, comme c'est le cas avec AMS.
Personnellement, je trouve ceci tout à fait inutile mais on me l'a
demandé.
- Correction d'un bug dans kernel:exec.

15/10/2000 : Universal OS 1.14
- Support de la ramcall HW_VERSION.
- Correction d'un bug dans userlib/util:exec.

28/05/2000 : Universal OS 1.13
- HW2 89&92+ : le réglage des niveaux de gris par [<>]+[<] et [<>]+[>]
devrait fonctionner plus souvent.
- La fonction idle_loop ne modifie plus l'indicateur d'activité (il ne
l'efface même pas, contrairement aux librairies de DoorsOS).

25/05/2000 : Universal OS 1.12
- HW2 89&92+ : réglage des niveaux de gris à l'aide de [<>]+[<] et
[<>]+[>] (adjust permet de mieux évaluer la qualité des niveaux de
gris).
- HW2 : correction d'un bogue dans graphlib::gray4.
- L'utilisation de [Shift]+[ON] n'empêche plus le basic depuis un
programme assembleur : il était par exemple impossible d'appeler un
programme basic depuis "doors".

11/05/2000 : Universal OS 1.11
- Amélioration des niveaux de gris sur HW2 89 (merci à Olivier Serres).
- [Shift]+[ON] supporté : cela lance le programme "doors".
- Mise à jour de userlib : ajout de userlib::password.
- Mise à jour des routines de niveaux de gris :
- initialisation des plans de bits.
- gestion du page flipping sous graphlib.
- Tous les problèmes de valeurs de retour sont résolus (c'étaient deux
bugs : un dans AMS 2.0x et un dans Universal OS).
- Universal OS détecte si HW2Patch est nécessaire.
- Sur HW2 : la désinstallation ne réactive plus la limitation matérielle
des 8 ko, si on avait choisi la méthode qui ne modifie pas la ROM.
- Correction de bogues.


27/02/2000 : Universal OS 1.10
- Possibilité de sauvegarder toutes les variables juste avant un reset.
- [2nd]+[ON] fonctionne même lorsque AMS est occupé.
- le fichier kernel peut être archivé.
- Possibilité de ne pas mettre de mot de passe.
- Correction de quelques bogues dans :
- graphlib::clr_scr2 (décidément !)
- les routines de niveaux de gris.
- kernel::exec

08/01/2000 : Universal OS 1.02
- Les librairies peuvent être dans n'importe quel répertoire.
- Correction du bogue dans graphlib::clr_scr2.

03/01/2000 : Universal OS 1.01
- Correction de quelques bogues au niveau de :
- doorsos::kb_globals (_RAM_CALL_010)
- util::clr_scr
- userlib::lockcalc
- checksum de Phoenix

02/01/2000 : Universal OS 1.00

VIII) Comment me contacter

e-mail : <Julien.Muchembled@netcourrier.com>

Reportez tous les bogues que vous trouvez, sans oublier de donner une
description précise du problème.

Remarque à propos du courrier :

Si possible, allez sur le forum de www.ti-fr.org. Ça peut intéresser
tout le monde et je n'aurais plus qu'un seul message à écrire par
problème.
Archive mise en ligne par : Vince
Date de mise en ligne : 15/04/2004 à 14:01:59

- Ti FR v3 - Ce site n'est pas le site officiel de texas instruments. En cas de problèmes techniques sur le site veuillez contacter l'administrateur. Merci de vos visites !
page générée en 242 ms