C'est vers 1992 que j'ai commence a developper un petit noyau multi-tache pour un "certain pocket"
A l'epoque je travaillais sous VxWorks, et j'ai eu envie de realiser moi-meme un scheduler et les services associes. Ne possedant pas de PC, je l'ai developpe sur... mon PC-1500 !
C'etait un peu la pagaille dans les differents WAV que je conservais mais j'ai reussi, grace a mes notes aussi, a "rebatir" un petit noyau fonctionnel
De plus, j'ai decouvert un truc que j'avais oublie: les services du kernel sont accessibles avec une instruction BASIC
, nommee TASK. Ainsi, par exemple, un TASK ARUN demarre le scheduler et "cree" une tache qui n'est autre que le BASIC lui-meme. Et oui, le BASIC sera "schedule" comme les autres 
Dans les services supportes par le noyau, on va trouver:
- Creation (RUN), destruction (END), arret (STOP), reprise (CONT) de tache, suspension sur delai variable (PAUSE),
- Changement de priorite (NEW) de 0 (la plus prioritaire) a 7 (la moins). La "tache BASIC" a une priorite de 3, mais je vais plutot lui assigner 6 ou 7, le BASIC ne se suspendant que tres rarement. Le scheduler donne la main a la (aux) tache(s) de priorite 0 jusqu'a ce que celle(s)-ci se suspende(nt), puis ce sera(ont) les taches de priorite moindre 1, 2, 3..., jusqu'aux taches les moins prioritaires ...6 puis 7. Deux taches de meme priorite seront schedulees l'une apres l'autre. Si une tache de priorite plus elevee devient "eligible", elle prendra la main devant une autre tache moins prioritaire.
- Utilisation de verrous d'exclusion mutuelle (LOCK, LOCK WAIT, UNLOCK),
- Utilisation de semaphores de synchronisation associe aux verrous avec attente (PEEK) et signal (POKE). Dans les "versions legacy", je ne comprenais pas le code que j'ai recupere et... je n'avais de notes sur le sujet. J'ai donc reecris "from scratch" un systeme de synchronisation base sur le "mecanisme mutex/condition" de POSIX.
- Reception (INPUT) et emission (PRINT, PRINT WAIT, PRINT INPUT) de messages synchrones. Certainement a l'epoque un essai de portage des "Rendez-vous" de ADA83. Ce mecanisme est aussi present dans MMPS,
- Reception (READ, READ WAIT) et emission (DATA) de messages asynchrones par mailbox. Bon, la mailbox est limitee a un seul message, mais elle a le merite d'exister. J'ai un autre binaire du multi-tache avec une gestion de FIFO (queues), mais a part provoquer des plantages de toute beaute, je n'arrive pas a tirer grand chose. Cela prefigure quand-meme la gestion des QUEUE et DUPLEX fournis par MMPS,
- Enregistrement d'une routine d'appel (GOTO), activation (ON), deactivation (OFF) d'evenements et envoie d'un evenement (CALL) a une tache. En fait, pour les Unixiens, c'est tout simplement une gestion de signal !
Pour vous amusez (enfin ceux qui ont suivi jusqu'au bout), un petit exemple amusant. Que fait le programme suivant une fois "lance" dans une tache (il faut une priorite importante, prenons par exemple 1) ?
Code : Tout sélectionner
ex6:
LD B,<XREG
LD C,>XREG
LD L,&07
DI
pushXREGloop:
LDI (BC)
PUSH A
DJC pushXREGloop
CALL &E5B4 ; TIME
DEC BC
DEC BC
DEC BC
LDI (BC)
INC BC
STA H
LD L,&07
popXREGloop:
POP A
STD (BC)
DJC popXREGloop
EI
LDA H
BIT 0F
JR NZ,notMM=00
CALL BEEP1
notMM=00:
LD B,&00 ; Delay
LD C,&40
LD D,t?PAUSE ; Enters the mt-kernel for a PAUSE
CALL t?KRNREQ
JR ex6
Du coups, j'ai developpe un OS complet qui s'affranchit du BASIC: MMPS ! Mais la, j'ai ete limite par la memoire 
devrait nous faire marrer un moment et ce ne serait pas pour me deplaire... apres tout ce n'est qu'une question de temps, de motivation et de disponibilite.