Toujours un petit problème de ROM CALL (toujours elles)! - Page 2

Oui mais moi, mon problème j'aime pas trop se qui est pas nosub, alors tu vois, des libs, je m'en balance un peut

Même si pour avantage de simplifier quelque peut ton code et de moin te prendre la tête, je préfère le NOSUB!

D'ailleur, j'utilise CC, donc le problème du SUB ou du NOSUB est trés vite réglé
Donc en ce qui concerne mon (petit) problème

Voici ou j'en suis de mon enquête:

GrayAdjust(x): à l'adresse 0x600013 on mais 128-x et c bon

SetPlane(x) correspond à PortSet(GetPlane(x), 240,128)
Seul problème, GetPlane(x) revoie une adresse selon x: Plan 0 et 1
Je veux c adresses

Le seul truc que j'arrive pas à trouver, c l'équivalent de GrayOn et GrayOff

jsr graphlib::gray4

Il n'y a pas de ROM_CALLs pour les niveaux de gris.
Le seul moyen d'utiliser les niveaux de gris avec CC est de convertir une routine de niveaux de gris (celle de TIGCCLIB par exemple - cf. gray.s des sources de TIGCC) en assembleur inline CC.

Oui mais alors c quoi le code (même en ASM j'm'en fou) pour l'équivalent de GrayOn et GrayOff, c bien des fonction de la 89 tout de même, on aurai pas pu inventer un truc comme ça!

et _D_plane et _L_plane correspondent à koi en valeur

PpHd a écrit :
jsr graphlib::gray4

Ça ne marche pas avec CC, donc tu fais de la publicité pour rien!

forcement, avec CC on fait que du NOSUB, et c pas plus mal
Bien sur, se serait le top si on pouvait faire avec kernel aussi enfin bon, on peut pas tout avoir dans la vie...

guigui17
a écrit : Oui mais alors c quoi le code (même en ASM j'm'en fou) pour l'équivalent de GrayOn et GrayOff, c bien des fonction de la 89 tout de même, on aurai pas pu inventer un truc comme ça!

Tu télécharges les sources de TIGCC et tu vas voir dans archivegray.s dans le ZIP.

CRIC jsr graphlib::gray4 J'insiste
Parse Error beforegraphlib.

Tou simplement c pas focement trés catholique, vais ca nous fait de l'entrainement!

Je vais voir ça tout de suite

Tu vas bien aujourd'hui PpHd ?

Tu doutes de ma sante mentale Pas gentil ca

Docteur, PpHd délire !

Elle est ENORME la source de TIGCC

Oué. Surtout compare a un jsr graphlib::gray4

Elle n'est pas plus grosse que la routine de graphlib (du moins pas de manière significative - je n'ai pas comparé la taille à l'octet près).

N'est-ce pas Kevin ?

Mais compare a la place que prend un jsr graphlib::gray4, si. Pardonnez mon obstination stupide

La librairie dynamique existe aussi, donc elle fait aussi partie de la taille!!!

Et il faut d'ailleurs compter la taille de graphlib tout entière (même des fonctions qui ne font que réécrire les routines de AMS), vu que les librairies dynamiques sont un concept suffisamment primitif pour gaspiller de la place pour les routines que personne n'utilise.

Non, c'est la ton erreur.

Non, c'est là ton erreur!
La taille totale d'un programme est la mémoire de stockage prise par celui-ci. C'est donc ici la taille de tout ce qu'il faut envoyer à la calculatrice pour l'utiliser. graphlib en fait partie! Le "kernel" aussi, d'ailleurs.

Non, tu dois differencier le systeme (uitlisable par plusieurs programmes) et le programme lui meme.
L'equation de place (simplifiee) est la suivante :
Middle:
Taille_systeme + Sum(taille_prog)
_ams:
sum(taille_prog)
Et pas :
Middle:
Sum(taille_prog + Taile_Systeme)
Depuis le debut tu fais l'erreur (ou fais semblant de la faire).

Tu présumes toujours:
- que l'utilisateur utilise plusieurs programmes en assembleur ou C. (Qui te dit ça?)
- que tous les programmes en assembleur ou C utilisés par l'utilisateur utilisent les mêmes librairies dynamiques. (Là encore: qui te dit ça?)

Et arrête d'appeler la taille des librairies dynamiques et du "kernel" "taille système"! Le système, c'est AMS!!!

Mettons uqe l'utilisatuer ne possede qu'un prog asm. Ok c bon, la t'ás gagne.
Mais s'il y en a plusieurs, c NON.
Et j'appelle system parce que j'ai pas trouve mieux, encore.

PpHd
a écrit : Mais s'il y en a plusieurs, c NON.

Sauf si les ensembles des routines de librairies utilisées par les programmes sont disjoints.

Comment peux-tu en etre sûr ? Il est fort probable que leur intersection dans l'ensemble des fonctions soit non nulles (gris, detection calc, rom, etc).

lol il me fais marrer PpHd a parler en langage mathématique

C'est moi qui ai commencé avec le langage mathématique.

PpHd
a écrit : Comment peux-tu en etre sûr ? Il est fort probable que leur intersection dans l'ensemble des fonctions soit non nulles (gris, detection calc, rom, etc).

C'est évidemment une approximation, mais elle est bien meilleure que la tienne: toi, tu ne comptes pas du tout la taille de la librairie. Donc dans ton approximation, il y a une infinité de programmes qui utilisent tous exactement les mêmes routines. Cette approximation est beaucoup plus loin de la réalité que la mienne.

Si, je tiens compte de la taille des libs. Mais c'est à l'utilisateur final de la calculer en fonction de ses programmes.
Je n'ai pas besoin de faire tendre vers l'infini le nombre de programme pour que l'intersection dans l'ensemble des fonctions produise un sous-ensemble hautement connexe qui possède une taille finie. Il ne faut compter ce sous-ensemble qu'une seule fois, pour l'ensemble des programmes, et pas plusieurs fois. Mais ce sous-ensemble depend de la discretisation precise des programmes dans l'ensemble stocke dans la calculatrice. On ne peut donc pas le calculer precisement, puisqu'il depend de l'ensemble et non d'un seul. C'est pourquoi je ne le compte pas dans mes calculs, et il faut le rajouter a la fin.

Mais crois-tu vraiment que c'est une comparaison de taille objective avec les librairies statiques de négliger entièrement la taille des librairies dynamiques???
Parce que je trouve que ce n'est pas du tout le cas! C'est très "biased" comme comparaison!