1

J'ai récémment commencé à apprendre l'asm 68k pour le ti89 et j'ai écrit un tilemapper très simple pour pratiquer, mais maintenant je voudrais savoir s'il existe une liste d'endroits saferam dont on peut se servir ?

2

La TI-89 a des fonctions pour allouer de la mémoire, il est plus simple et surtout plus sûr de les utiliser à la place.

!call Folco
--- Call : Folco appelé(e) sur ce topic ...
(pour confirmation)
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

3

Salut,
que veut dire saferam ? #noob#

Si c'est de la ram libre non utilisée par le système, il y a un peu de mémoire à droite de l'écran de la 89 (10 octets par ligne ?) et quelques lignes (une trentaine ?) en dessous sur la largeur complète (la RAM est mappée pour un écran de 92/V200, mais tout n'est pas affiché sur la 89)
Mais bon, c'est pas forcément une super idée d'utiliser ça.

En tout cas, je te conseille de travailler avec un Kernel, c'est révolutionnairement awesome !

4

Je confirme, mieux vaut utiliser HeapAlloc/HeapFree et HeapAllocPtr/HeapFreePtr smile

Pen^2: sur les TI-Z80, "saferam" désigne un endroit de la RAM qui n'est pas touché par l'OS, et dans lequel on peut donc stocker des données smile
Il y en a quelques-uns sur TI-68k, mais très rares sont ceux qui les utilisent.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

5

(OK merci, c'est bien ce que je pensais)

6

Pen^2 (./3) :
il y a un peu de mémoire à droite de l'écran de la 89 (10 octets par ligne ?)

C'est gore ^^ Et ça empêche immédiatement d'utiliser ça sur 92, évidemment...
Pen^2 (./3) :
et quelques lignes (une trentaine ?) en dessous sur la largeur complète

128 vs 100
Mais immédiatement en dessous, on est dans le heap. D'ailleurs, PreOS sauvegarde trois ligne à tout hasard en cas de petit débordement de données à l'écran.

Ca reste gore. Il y a des vecteurs inutilisés, mais en zone protégée (cf $600001). Pas la peine de vouloir utiliser ça, on peut pas tourner décemment avec une table de vecteurs déprotégée.
Les fonctions de Alloc.h sont la seule manière fiable et efficace d'utiliser la RAM.

7

bah oui c'est gore, mais bon, c'est la question qui l'est embarrassed

8

Ce qui est pratique avec les lignes utilisées de l'écran sur TI-89, c'est qu'il est permis d'y exécuter du code! La zone 0x5xxx est toujours déprotégée pour l'éxécution parce que c'est là (plus loin dans la zone, pas sur l'écran évidemment) qu'AMS exécute le code d'écriture en FlashROM, qui ne peut pas être en FlashROM pour des raisons techniques.

J'ai notamment utilisé ça dans les bibliothèques de niveaux de gris de TitaniK pour installer le gestionnaire d'interruptions, la zone de 64 KiB déprotégée changeant entre l'espace mémoire du programme principal et celui de chaque bibliothèque au fur et à mesure de l'éxécution du programme, donc seule la zone 0x5xxx restant toujours déprotégée. (TitaniK fonctionne sans HW3Patch! C'était le premier kernel pour la TI-89 Titanium.)
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

9

Merci tout le monde, je crois qu'il faut jouer un peu avec HeapAlloc et HeapAllocPtr. En cherchant un peu j'ai trouvé quelques docs de Kevin (comme ceci) qui expliquent pas mal de choses pour me lancer dans l'asm 68k smile

10

Malheureusement, cette documentation n'est pas vraiment à jour, je n'ai jamais trouvé le temps et le courage de la mettre à jour pour ld-tigcc, qui permet d'utiliser le code de démarrage de TIGCCLIB aussi en assembleur, par exemple pour la sauvegarde de l'écran.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

11

Ca se redessine en moins de 10 octets un écran. Cf source de PreOS.

12

Une ligne a tracer et un RomCall de mémoire
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

13

Mais restaurer une sauvegarde de l'écran est beaucoup plus propre que de le redessiner. Redessiner fait des présuppositions sur l'environnement dans lequel est lancé le programme. De plus, pour la ligne à tracer, les coordonnées dépendent du modèle de calculatrice, je veux voir ton code de détection de modèle qui tient en ces 10 octets. roll
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

14

(la seule chose de bien dans la sauvegarde de l'écran, c'est qu'on peut la modifier trilove)

15

(ah oué tiens triso)
Kevin -> Tu peux parler, la sauvegarde de l'écran dans TIGCC est loin d'être optimale embarrassed

16

et puis le kernel c'est encore plus simple, un ramcall a appeler embarrassed
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

17

Ah, lequel ? cheeky

18

Reset!
#loin#
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

19

grin

20

Pas besoin de RAM_CALL pour faire un reset, trap #2 suffit. tongue
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

21

J'ai encore une question : en lisant le code source de Phoenix, je crois qu'il a mis ses variables dans la pile (ou plutôt dans la mémoire reservée à la pile). Est-il d'usage de faire ça ? J'ai essayé d'utiliser

Je commets beaucoup d'erreurs, partout apparaît ce "Address Error" fou

Et "trap" fait quoi ? Je l'ai cherché dans le programmers manual mais je ne le comprends pas :/

22

Concernant la pile, c'est ce qui est souvent utilisé par le compilateur C pour le passage de paramètres à une fonction par exemple
avatar
Webmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca

23

chickendude (./21) :
J'ai encore une question : en lisant le code source de Phoenix, je crois qu'il a mis ses variables dans la pile (ou plutôt dans la mémoire reservée à la pile). Est-il d'usage de faire ça ?

Ce qui est d'usage, c'est pour des variables locales, de les mettre sur la pile (on décrémente %a7 et on met les contenus dans les adresses supérieures à %a7). Ce que fait Phoenix, en revanche, n'est pas du tout d'usage et on risque de faire des bêtises si on ne sait pas exactement ce qu'on fait: il met des variables à des adresses inférieures à %a7 dans l'espoir de les retrouver à la prochaine exécution. Il est plus sûr d'utiliser des fichiers (des variables de la calculatrice) pour ça.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

24

Ah merci. Ce que j'avais fait c'est:
	lea	-100(a7),a7		; allouer éspace pour variables dans la pile
	lea	(a7),a6			; charger pointeur au commencement des variables à a6

;initialiser variables
	move.b #1,mapX(a6)
	move.b #1,mapY(a6)

;...et puis
	lea     100(a6),a7

Et ce que j'ai voulu écrire avant était que j'avais essayé d'utiliser HeapAlloc, mais puis il m'avait paru plus simple d'utiliser la pile. Beaucoup des autres jeux dont j'ai vu le code source ont mis leurs variables dans le programme même, mais si on a besoin d'un grand bloc de mémoire, s'il s'agit par exemple d'un gbuf (ou deux), je suppose c'est pas vraiment convénient.

25

Pour mettre un frame pointer dans a6 (c'est comme ça que tu utilises ce registre dans ton exemple), tu peux utiliser les instructions link et unlk smile
Beaucoup des autres jeux dont j'ai vu le code source ont mis leurs variables dans le programme même

C'est souvent la façon la plus efficace (en taille, et marginalement en vitesse) de faire, d'autant plus que la taille des variables globales est faible et que le nombre d'accès en lecture aux variables globales est élevé.
mais si on a besoin d'un grand bloc de mémoire, s'il s'agit par exemple d'un gbuf (ou deux), je suppose c'est pas vraiment convénient.

Dans ce cas-là, allouer un bloc de mémoire, et stocker le résultat dans une variable globale pointeur, est souvent assez efficace en taille.

-fomit-frame-pointer + -freg-relative-a(4, 5 ou 6) (à se faire à la main si on fait du pur ASM) peut donner d'excellents résultats, à la fois en taille et en vitesse, car tous les accès (lecture / écriture / exécution) sont des adressages d(an). Pas de vilains adressages xxx.l relogés.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

26

Pas besoin de link/unlk, c'est lent ces instructions. On peut faire plus rapide en asm. [nosmile]

Je fais comme ça en général :
;========================================================
;       2. Create and initialize the stack frame. Musn't use a0/a3  until descriptors are saved
;       CHECKED
;========================================================
        addq.l  #4,sp                                   ; Remove return address, we will use exit()
        move.w  (sp)+,d6                                ; argc
        movea.l (sp),a4                                 ; argv
        lea     -STACK_FRAME_SIZE(sp),sp
        movea.l sp,a6

Avec un header de ce type :
;========================================================
;       CMDLINE
;
;       Type            CMDLINE structure used by pdtlib
;       Initialisation  Initialized by pdtlib::InitCmdline
;       Usage           -/-
;                       A pointer to this structure is passed to functions
;                       of ptdlib which request it.
;                       Never read or modify this structure by hand
;========================================================
CMDLINE			    equ	0

;========================================================
;       FLAGS
;
;       Type            uint32
;       Initialisation  Content of Flags variable, modifiable with config.h.
;       Usage           R/W. Modified by the config file if it exists (system/as).
;                       Modified by the options of the command line passed before
;                       the first source file
;========================================================
FLAGS			    equ	8

;========================================================
;       STDERR
;
;       Type            FILE*
;       Initialisation  pedrom::stderr
;       Usage           R. Given to system functions which need it
;========================================================
STDERR              equ 12

;========================================================
;       PRINTF
;
;       Type            trampoline
;       Initialisation  jmp opcode + pedrom::printf
;       Usage           Executable. Perform a system call
;========================================================
PRINTF              equ 18

;========================================================
;       FPRINTF
;
;       Type            trampoline
;       Initialisation  jmp opcode + pedrom::fprintf
;       Usage           Executable. Perform a system call
;========================================================
FPRINTF             equ 24

...

STACK_FRAME_SIZE	equ 194

Ensuite, ça s'utilise comme ça :
        move.w  d6,ARGC(a6)
        move.w  a4,ARGV(a6)
        move.l  a0,PDTLIB_DESC(a6)                      ; Descriptors
        move.l  a3,SYSLIB_DESC(a6)

...

        lea     StrConfigFileContent(pc),a1
        lea     StrConfigFileSeparators(pc),a2
        lea     NEXT_CHAR(a6),a3
        jsr     COMPARE_STRINGS(a6)

Ca permet de ne pas utiliser de variables en section de code, donc entre autre d'écrire du code PIC, sans relogement, d'exécuter le code en flash et autres joyeusetés. C'est polyvalent et pas plus compliqué que d'utiliser des variables en section de code.

27

Mais link / unlk est plus petit que ton code écrit à la main!
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

28

Bof, je l'unlink rien, le kernel s'occupe de la pile cheeky

29

Normalement, un stack frame, c'est par fonction, pas par exécutable.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

30

Ca remplace avantageusement les variables globales en section de code. Au moins là, c'est séparé. Il y aurait une section réservée pour ça, j'aurais pas à le faire.