Posté le 19/06/2012 à 19:58 Membre depuis le 03/06/2011, 520 messages
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 ?
Posté le 19/06/2012 à 20:03Edité par Zerosquare le 19/06/2012 à 20:04 Membre depuis le 27/04/2006, 60464 messages
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)
avatarZeroblog

« 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
Posté le 19/06/2012 à 20:04 Membre depuis le 10/06/2001, 45102 messages
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 !
Posté le 19/06/2012 à 20:11 Membre depuis le 28/10/2001, 7625 messages
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.
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.
Posté le 19/06/2012 à 20:14 Membre depuis le 10/06/2001, 45102 messages
(OK merci, c'est bien ce que je pensais)
Posté le 19/06/2012 à 20:28 Membre depuis le 18/06/2001, -26082 message
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.
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Posté le 19/06/2012 à 23:33 Membre depuis le 10/06/2001, 45102 messages
bah oui c'est gore, mais bon, c'est la question qui l'est embarrassed
Posté le 19/06/2012 à 23:43 Membre depuis le 10/06/2001, 40262 messages
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.)
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
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é
Posté le 20/06/2012 à 08:17 Membre depuis le 03/06/2011, 520 messages
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
Posté le 20/06/2012 à 11:23 Membre depuis le 10/06/2001, 40262 messages
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.
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
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é
Posté le 20/06/2012 à 12:49 Membre depuis le 18/06/2001, -26082 message
Ca se redessine en moins de 10 octets un écran. Cf source de PreOS.
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Posté le 22/06/2012 à 00:04 Membre depuis le 30/06/2001, 71400 messages
Une ligne a tracer et un RomCall de mémoire
avatarProud to be CAKE©®™
The cake is a lie! - Love your weighted companion cube

->986-Studio's Wonder Project!<-
yN a cassé ma signature :o
Posté le 22/06/2012 à 01:51 Membre depuis le 10/06/2001, 40262 messages
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
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
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é
Posté le 22/06/2012 à 02:22 Membre depuis le 10/06/2001, 45102 messages
(la seule chose de bien dans la sauvegarde de l'écran, c'est qu'on peut la modifier trilove)
Posté le 22/06/2012 à 06:38 Membre depuis le 18/06/2001, -26082 message
(ah oué tiens triso)
Kevin -> Tu peux parler, la sauvegarde de l'écran dans TIGCC est loin d'être optimale embarrassed
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Posté le 22/06/2012 à 10:20 Membre depuis le 30/06/2001, 71400 messages
et puis le kernel c'est encore plus simple, un ramcall a appeler embarrassed
avatarProud to be CAKE©®™
The cake is a lie! - Love your weighted companion cube

->986-Studio's Wonder Project!<-
yN a cassé ma signature :o
Posté le 22/06/2012 à 19:24 Membre depuis le 18/06/2001, -26082 message
Ah, lequel ? cheeky
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Posté le 22/06/2012 à 21:01 Membre depuis le 30/06/2001, 71400 messages
Reset!
#loin#
avatarProud to be CAKE©®™
The cake is a lie! - Love your weighted companion cube

->986-Studio's Wonder Project!<-
yN a cassé ma signature :o
Posté le 22/06/2012 à 22:37 Membre depuis le 18/06/2001, -26082 message
grin
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Posté le 23/06/2012 à 04:30 Membre depuis le 10/06/2001, 40262 messages
Pas besoin de RAM_CALL pour faire un reset, trap #2 suffit. tongue
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
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é
Posté le 26/06/2012 à 08:47 Membre depuis le 03/06/2011, 520 messages
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 :/
Posté le 26/06/2012 à 09:24 Membre depuis le 11/11/2001, 116491 messages
Concernant la pile, c'est ce qui est souvent utilisé par le compilateur C pour le passage de paramètres à une fonction par exemple
avatarWebmaster 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
Posté le 26/06/2012 à 11:40 Membre depuis le 10/06/2001, 40262 messages
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.
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
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é
Posté le 26/06/2012 à 17:26 Membre depuis le 03/06/2011, 520 messages
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.
Posté le 26/06/2012 à 18:55 Membre depuis le 28/10/2001, 7625 messages
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.
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.
Posté le 26/06/2012 à 23:44 Membre depuis le 18/06/2001, -26082 message
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.
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Posté le 26/06/2012 à 23:55 Membre depuis le 10/06/2001, 40262 messages
Mais link / unlk est plus petit que ton code écrit à la main!
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
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é
Posté le 27/06/2012 à 00:14 Membre depuis le 18/06/2001, -26082 message
Bof, je l'unlink rien, le kernel s'occupe de la pile cheeky
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Posté le 27/06/2012 à 02:33 Membre depuis le 10/06/2001, 40262 messages
Normalement, un stack frame, c'est par fonction, pas par exécutable.
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
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é
Posté le 27/06/2012 à 21:19 Membre depuis le 18/06/2001, -26082 message
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.
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !