Liste d'endroits saferam - Page 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 ?

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)

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 !

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

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
Il y en a quelques-uns sur TI-68k, mais très rares sont ceux qui les utilisent.

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

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.

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

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.)

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

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.

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

Une ligne a tracer et un RomCall de mémoire

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.

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

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

et puis le kernel c'est encore plus simple, un ramcall a appeler

Ah, lequel ?

Reset!
#loin#

Pas besoin de RAM_CALL pour faire un reset, trap #2 suffit.

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"

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

Concernant la pile, c'est ce qui est souvent utilisé par le compilateur C pour le passage de paramètres à une fonction par exemple

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.

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.

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

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.

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.

Mais link / unlk est plus petit que ton code écrit à la main!

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

Normalement, un stack frame, c'est par fonction, pas par exécutable.

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.