La Place des Développeurs Contourner la limitation mémoire disponible sous Xbasic ? Comment avoir davantage de mémoire disponible sous basic avec Xbasic ?
Bonjour à tous :-)
Ancien utilisateur du standard MSX dans ma jeunesse, je reprends plaisir actuellement à reprogrammer comme je le faisais à l'époque, grâce aux émulateurs.
J'utilise BlueMSX.
Je me remets peu à peu dans le bain de la programmation sous basic ; c'est comme pour le vélo : ça ne s'oublie pas, certes, mais j'avoue avoir perdu pas mal de connaissances.
Mon problème aujourd'hui est le suivant :
Je programme donc en basic, en utilisant xbasic, avec BlueMSX (émulation MSX2). Je suis rapidement confronté au fameux "Out of memory in xxxx" avec mon programme. Pourtant, j'ai "encore" généralement plus de 15000 octets de disponibles (?fre(0)). Je suppose que c'est parce que j'utilise Xbasic... J'ai donc "coupé" mon programme en plusieurs morceaux (avec sauvegarde des données utilisées en vram pour les récupérer dans les autres morceaux) ; finalement c'est vrai c'est plus clair ; mais j'ai un "gros" morceau qui me pose problème, et je ne me vois pas le couper facilement celui-là.
Alors ma question est simple :
Comment peut-on contourner la limitation de mémoire sous basic si on utilise Xbasic (ou avec Nbasic) ?
Merci pour vos éclaicissements :-)
JF.
Ancien utilisateur du standard MSX dans ma jeunesse, je reprends plaisir actuellement à reprogrammer comme je le faisais à l'époque, grâce aux émulateurs.
J'utilise BlueMSX.
Je me remets peu à peu dans le bain de la programmation sous basic ; c'est comme pour le vélo : ça ne s'oublie pas, certes, mais j'avoue avoir perdu pas mal de connaissances.
Mon problème aujourd'hui est le suivant :
Je programme donc en basic, en utilisant xbasic, avec BlueMSX (émulation MSX2). Je suis rapidement confronté au fameux "Out of memory in xxxx" avec mon programme. Pourtant, j'ai "encore" généralement plus de 15000 octets de disponibles (?fre(0)). Je suppose que c'est parce que j'utilise Xbasic... J'ai donc "coupé" mon programme en plusieurs morceaux (avec sauvegarde des données utilisées en vram pour les récupérer dans les autres morceaux) ; finalement c'est vrai c'est plus clair ; mais j'ai un "gros" morceau qui me pose problème, et je ne me vois pas le couper facilement celui-là.
Alors ma question est simple :
Comment peut-on contourner la limitation de mémoire sous basic si on utilise Xbasic (ou avec Nbasic) ?
Merci pour vos éclaicissements :-)
JF.
Salut à toi et bienvenue…
Une petite présentation peut être ?
Le soucis avec Xbasic c'est la taille des blocs "Turbo" que tu crée.
En fonction des variables que ces blocs turbo manipules, tu ne peux pas faire des blocs qui soient plus gros que 10K environs (si j'ai bonne mémoire).
Donc entre un CALL Turbo ON et un CALL turbo off , tu dois optimiser ton code, virer les commentaires et les espaces superflux pour diminuer la taille en mémoire du bloc. Mais parfois ce n'est pas suffisent…. Edité par ericb59 Le 28/05/2014 à 11h21
Une petite présentation peut être ?
Le soucis avec Xbasic c'est la taille des blocs "Turbo" que tu crée.
En fonction des variables que ces blocs turbo manipules, tu ne peux pas faire des blocs qui soient plus gros que 10K environs (si j'ai bonne mémoire).
Donc entre un CALL Turbo ON et un CALL turbo off , tu dois optimiser ton code, virer les commentaires et les espaces superflux pour diminuer la taille en mémoire du bloc. Mais parfois ce n'est pas suffisent…. Edité par ericb59 Le 28/05/2014 à 11h21
Bonjour Ericb59 :-)
Merci de ta réponse.
Oups désolé c'est vrai j'ai zappé les bonnes manières (et peut-être la politique du forum) en ne me présentant pas. Je vais aller le faire de ce pas sur le forum approprié ;-)
C'est intéressant ce que tu dis... donc, si je comprends bien, si je fais plusieurs "blocs" dans mon programme (donc plusieurs parties turboon/turbooff), ça contournerait l'out of memory ?
Ca peut être utile, mais finalement, je vais devoir procéder à une sauvegarde de mes variables utilisées car le call turbo off va effacer celles-ci non ?
Merci de ta réponse.
Oups désolé c'est vrai j'ai zappé les bonnes manières (et peut-être la politique du forum) en ne me présentant pas. Je vais aller le faire de ce pas sur le forum approprié ;-)
C'est intéressant ce que tu dis... donc, si je comprends bien, si je fais plusieurs "blocs" dans mon programme (donc plusieurs parties turboon/turbooff), ça contournerait l'out of memory ?
Ca peut être utile, mais finalement, je vais devoir procéder à une sauvegarde de mes variables utilisées car le call turbo off va effacer celles-ci non ?
oui tout à fait, il faut faire de plus petits blocs…
Tu peux passer des variables numérique dans tes blé turbo
Call turbo (X,Y)
Il faut que tes variables soient préalablement définies dans ton programme basic, et qu'elle ne soit pas vide, sinon tu auras une erreur, et tu pourras chercher longtemps pourquoi ça ne fonctionne pas !
Donc il te faut par exemple
tu ne peux pas passer dans le turbo des variables alphanumériques. ( A$ par exemple).
Si tu utilises NestorBasic, tu peux stocker certaines données ou variables dans des segments de mémoire et les récupérer dans tes blocs turbo. Edité par ericb59 Le 28/05/2014 à 11h46
Tu peux passer des variables numérique dans tes blé turbo
Call turbo (X,Y)
Il faut que tes variables soient préalablement définies dans ton programme basic, et qu'elle ne soit pas vide, sinon tu auras une erreur, et tu pourras chercher longtemps pourquoi ça ne fonctionne pas !
Donc il te faut par exemple
10 X=0:Y=0: DIM T ( 50)
…
30 CALL TURBO ON ( x,y,T())
…
30 CALL TURBO ON ( x,y,T())
tu ne peux pas passer dans le turbo des variables alphanumériques. ( A$ par exemple).
Si tu utilises NestorBasic, tu peux stocker certaines données ou variables dans des segments de mémoire et les récupérer dans tes blocs turbo. Edité par ericb59 Le 28/05/2014 à 11h46
Oki oki, je vais essayer ça. La reprise de quelques variables dans le call turbo on me semble bien :-) et ne m'obligerait pas à fractionner mon programme.
Merci pour ces éclaircissements très intéressants :-) Edité par vilcoyote Le 28/05/2014 à 12h26
Merci pour ces éclaircissements très intéressants :-) Edité par vilcoyote Le 28/05/2014 à 12h26
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie