Bonjour tout le monde

Je vous poste ici juste mon avancement et là où j'en suis :
J'ai terminé l'exécuteur universel, et le instant GoTo. Le Instant GoTo fait en sorte que quand vous appuyez sur [Alpha][Enter] consécutivement, vous alliez à la fin du programme instantanément sans scroll.
Mais que fais-je maintenant ? Suite à des gros problèmes d'incompréhension de "mais heu, pourquoi ça marche pas"et de plusieurs tests, j'en suis venu à la conclusion que l'OS utilisait une partie de pixelshadow2. J'ai la place mais que pour un seul hook. J'ai donc décidé de faire en vitesse la compatibilité avec Cesium, qui résout aussi ce problème et bien d'autres. Pour cela je dois mettre PHASM dans un group car, apparemment, même si cela m'étonne, ils ne sont pas affectés par le GarbageCollect.
Mon travail, c'est de :
1 - Mettre le plus d'adresses en relatif (donc JR ou lieu de JP), car je ne saurais pas à la compilation où sera le Group. Mettre tout en relatif étant impossible (par exemple pour mettre un nom de variable dans OP1, j'ai besoin d'utiliser LDIR et donc les adresses absolues), PHASM calculera quelques adresses à l'installation du hook.
2 - Faire le programme qui justement, calculera les adresses absolues.
3 - Apprendre comment créer les variables Groups et surtout, comment mettre des programmes à l'interieur. Mais ça au pire, l'user pourra transferer le Group avec les hooks tous prêts dedans.
4 - ça je viens de terminer, bien comprendre comment sont organisés les Group, pour les manipuler afin de changer les adresses absolues (CF avant).
Et comme je n'aime pas ne pas partager ce que j'ai mis tant de temps à découvrir, voici comment sont organisées les variables Groups (désolé, j'ai pas photoshop sous la main, ce sera plus traditionnel

) :
On prend l'exemple d'un Group qui s'appelle "MACHIN" avec le programme "TRUC" dedans :
1-1XXXXXX2MACHINXX3XXXXX4TRUC5-5***********[...]2XXX etc...
LEGENDE :
X : je ne sais pas à quoi ça sert, la plupart doivent être des adresses ou des trucs du genre.
1-1 : Les deux octets qui sont la taille de la variable Group
2 : l'octet qui définit la taille du nom du Group
3 : type de la prochaine variable (05 si programme, 06 si programme protégé etc...)
4 : l'octet qui nous informe de la taille du nom de la prochaine variable
5 : les deux octets qui nous disent la taille du CONTENU de la prochaine variable. C'est-à-dire que contrairement au nombre qu'il y a affiché normalement dans le gestionnaire de mémoire, celui-ci ne compte pas le nom toussa dans la taille. Juste le contenu.
***** : contenu du programme
Bon, ça a surement du être documenté autre part, mais tant pis, je me suis amusé à faire un programme qui m'a permit de me balader dans l'OS, c'était cool

Pour ceux qui seraient intéressés par ce programme (au moins juste pour que vous puissiez visualiser comment j'ai fait) :
- Code: Select all
.nolist
#include "ti83pce.inc"
#macro bcall(x)
call x
#endmacro
.list
.org userMem-2
.db tExtTok,tAsm84CeCmp
start:
ld hl,test2
call _mov9ToOp1
call _clrlcdfull
call _chkFindSym
ret c
ex de,hl
push hl
call _zeroop1
pop hl
inc hl
inc hl
call disp
loop:
push hl
call _getkey
pop hl
push af
cp kLeft
jr nz,notLeft
dec hl
call disp
notLeft:
cp kRight
jr nz,notRight
inc hl
call disp
notRight:
cp kAdd
jr nz,notAdd
inc hl
inc hl
inc hl
inc hl
inc hl
call disp
notAdd:
cp kSub
jr nz,notSub
dec hl
dec hl
dec hl
dec hl
dec hl
call disp
notSub:
pop af
cp kEnter
jr nz,loop
ret
disp:
ld a,0
ld (curcol),a
ld (currow),a
ld de,buffer
ld bc,13
ldir
ld de,13
sbc hl,de
push hl
call _clrlcdfull
ld de,buffer
ld b,13
dispChars:
push bc
ld a,(de)
call _putC
ld a,' '
call _putC
inc de
pop bc
djnz dispChars
ld a,1
ld (currow),a
ld a,7
ld (curcol),a
pop hl
push hl
ld de,7
add hl,de
push hl
ld a,(hl)
ld hl,0
ld l,a
call _disphl
pop hl
ld a,2
ld (currow),a
ld a,14
ld (curcol),a
ld a,(hl)
ld de,0
ld e,a
call _putTokString
pop hl
ret
test2:
.db GroupObj,"COUCOU",0
buffer:
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.end
Voilà, maintenant je passe à la transcription des adresses absolues !