La Place des Développeurs Projet Carwar
Reprise du message précédent
Après le chargement d'un fichier depuis la disquette, le jeu se met dans une boucle infini.J'ai essayé de tracer le code ASM, mais je vois pas ce qui se passe.
Mes variables en RAM ne semble pas écrasé par le BLTVD (file2vram copy), mais le flow ne reprend pas normalement.
Au cas ou qq'un peut y jeter œil, voici le code :
carwar_prb_infiniteLoop.zip
On est toujours ignorant avant de savoir.
J'ai regardé vite fait avec le débugueur de BlueMSX.
Le fichier se charge correctement. Après le chargement, le retour se fait au bon endroit, les Slot aussi. Les registres utilisés ne sont pas modifiés (à part IX mais qui est sauvegardé par un push/pop donc pas de problème). Bref, si tes données ne sont pas écrasées non plus, le problème vient d'ailleurs. A part un bug dans ton programme, je ne vois pas trop...
Le fichier se charge correctement. Après le chargement, le retour se fait au bon endroit, les Slot aussi. Les registres utilisés ne sont pas modifiés (à part IX mais qui est sauvegardé par un push/pop donc pas de problème). Bref, si tes données ne sont pas écrasées non plus, le problème vient d'ailleurs. A part un bug dans ton programme, je ne vois pas trop...
C'est très étrange ; surtout que tout marche bien si je charge pas le fichier.
Ceci dit, je pense qu'il y a quand même un écrasement car la 4e voiture n'est pas à sa place (elle se retrouve en [256,0]).
Je vais continuer de creuser.
Ceci dit, je pense qu'il y a quand même un écrasement car la 4e voiture n'est pas à sa place (elle se retrouve en [256,0]).
Je vais continuer de creuser.
On est toujours ignorant avant de savoir.
Au passage, j'arrive pas à charger un fichier de symbole sous BlueMSX (le code ASM pure, j'ai du mal ).
J'ai essayé d'imiter un fichier de symboles asMSX, mais ça marche pas.
Pas trouvé non plus de doc sur le sujet dans le site BlueMSX ; quelqu'un à déjà réussi à utiliser cette fonctionnalité ?
).J'ai essayé d'imiter un fichier de symboles asMSX, mais ça marche pas.
Pas trouvé non plus de doc sur le sujet dans le site BlueMSX ; quelqu'un à déjà réussi à utiliser cette fonctionnalité ?
On est toujours ignorant avant de savoir.
Bon, je laisse tomber pour l'instant ces histoires de chargement depuis un fichier ; j'y reviendrai peut-être quand le reste sera fini.
Sinon, j'avais un soucis de taille de stack (le C en abuse) et j'aimerai l'agrandir. Actuellement, mon code commence avec un :
C'est la façon standard d'initialiser la stack ?
J'ai essaye d'utiliser une adresse que je savais libre, D000h, pour y mettre ma stack, mais mettre directement le registre SP a cette adresse (sans passer par la case mémoire FC4Ah) fait rebooter l'émulateur en boucle.
Y a d'autre chose à faire pour initialiser la stack ?
Edité par
aoineko
Le 18/05/2011 à 13h03
Sinon, j'avais un soucis de taille de stack (le C en abuse) et j'aimerai l'agrandir. Actuellement, mon code commence avec un :
Code ASM :
di ldsp, (#0xFC4A) ei
C'est la façon standard d'initialiser la stack ?
J'ai essaye d'utiliser une adresse que je savais libre, D000h, pour y mettre ma stack, mais mettre directement le registre SP a cette adresse (sans passer par la case mémoire FC4Ah) fait rebooter l'émulateur en boucle.
Y a d'autre chose à faire pour initialiser la stack ?
Edité par
aoineko
Le 18/05/2011 à 13h03
On est toujours ignorant avant de savoir.
Je pense que le problème vient de là mais pour vérifier, il faudrait tracer ton programme.
La pile en général, on la place à un endroit où on est sûr que ça écrasera rien mais ton C en abuse (tout comme IX et IY d'ailleurs). Si tu ne trouves pas le moyen de maitriser au moins la pile, ça va être difficile de faire quelque chose d'évolué. Edité par GDX Le 18/05/2011 à 13h33
La pile en général, on la place à un endroit où on est sûr que ça écrasera rien mais ton C en abuse (tout comme IX et IY d'ailleurs). Si tu ne trouves pas le moyen de maitriser au moins la pile, ça va être difficile de faire quelque chose d'évolué. Edité par GDX Le 18/05/2011 à 13h33
aoineko :
Sinon, j'avais un soucis de taille de stack (le C en abuse) et j'aimerai l'agrandir. Actuellement, mon code commence avec un :
C'est la façon standard d'initialiser la stack ?
Code ASM :
di ld sp, (#0xFC4A) ei
C'est la façon standard d'initialiser la stack ?
Non ... Là, il prend la valeur en $FC4A, qui contient l'adresse libre la plus haute en RAM.
C'est une méthode sure, mais elle n'est valable que lorsque le code assembleur cohabite avec du BASIC.
Dans le cas d'une ROM, tu peux charger directement dans SP la valeur que tu veux.
A toi de voir quelles variables BIOS tu as besoin de conserver ... Et donc l'adresse la plus haute que tu peux prendre.
Rappel important : le stack fonctionne à l'envers, chaque empilage vient décrémenter la valeur de SP, il faut donc le positionner le plus haut possible en RAM.
MSX1: Daewoo DPC-200 / Yamaha CX5M
MSX2: Sony HB-F9P
MSXVR
Vidéo: V9990 (GFX-9)
Audio: MSX-Music (FM-PAC) / MSX-Audio (Audiowave) / OPL4 (Monster Sound FM Blaster) / OPNB (Neotron)
Ok, merci.
D'un point de vue système, la stack a pas de taille limite ?
En fait, j'ai un problème quand je transforme une macro en fonction (ce qui évite d'avoir plusieurs fois le même code en mémoire mais oblige à empiler tous les paramètres sur la pile).
C'est comme si je dépassais une taille critique (alors que la pile est placé à un endroit ou elle à plus de 4Ko de libre).
Une idée ?
D'un point de vue système, la stack a pas de taille limite ?
En fait, j'ai un problème quand je transforme une macro en fonction (ce qui évite d'avoir plusieurs fois le même code en mémoire mais oblige à empiler tous les paramètres sur la pile).
C'est comme si je dépassais une taille critique (alors que la pile est placé à un endroit ou elle à plus de 4Ko de libre).
Une idée ?
On est toujours ignorant avant de savoir.
aoineko :
D'un point de vue système, la stack a pas de taille limite ?
Non, puisqu'il s'agit seulement d'une adresse de stockage que l'on utilise ...
La seule limite est celle de l'interférence avec du code ou des variables.
aoineko :
C'est comme si je dépassais une taille critique (alors que la pile est placé à un endroit ou elle à plus de 4Ko de libre)
On est bien d'accord, quand tu dis que le stack a 4Ko de libre, c'est bien 4Ko de libre AVANT l'adresse d'origine de SP ?
Si c'est bien le cas, soit tu empiles tellement de variables que tu dépasses les 4Ko (c'est possible vu comment ton compilateur C fonctionne), soit tu as du code ou des variables en RAM qui viennent en interférence avec cette zone.
MSX1: Daewoo DPC-200 / Yamaha CX5M
MSX2: Sony HB-F9P
MSXVR
Vidéo: V9990 (GFX-9)
Audio: MSX-Music (FM-PAC) / MSX-Audio (Audiowave) / OPL4 (Monster Sound FM Blaster) / OPNB (Neotron)
Je mis SP à E000, y a presque 4 Ko avant (j'utilise pas bcp de RAM) et 4 Ko après.
Bon, si c'est pas ça, c'est surement un bug de mon compilateur....
Je vais essayer d'analyser le code ASM généré pour la fonction qui pose problème. Edité par aoineko Le 18/05/2011 à 16h57
Bon, si c'est pas ça, c'est surement un bug de mon compilateur....
Je vais essayer d'analyser le code ASM généré pour la fonction qui pose problème. Edité par aoineko Le 18/05/2011 à 16h57
On est toujours ignorant avant de savoir.
Bon, ça se complique (encore).
J'ai tracé le code et tout semble ok...
En fait, mon problème n'apparait que sous BlueMSX ! Sous OpenMSX ou RuMSX, tout marche nickel.
Un bug de BlueMSX ?
Si qq'un peut tester sur un vrai MSX, voici la ROM : carwar_prb_blackScreen.zip
Le début du code est en 4010h et la fonction qui pose problème, se trouve en B326h.
Si je remplace la fonction par une macro (les paramètres sont placé directement dans le buffer sans passer par la pile), alors ça marche bien aussi sur BlueMSX.
Une idée ?
J'ai tracé le code et tout semble ok...
En fait, mon problème n'apparait que sous BlueMSX ! Sous OpenMSX ou RuMSX, tout marche nickel.
Un bug de BlueMSX ?
Si qq'un peut tester sur un vrai MSX, voici la ROM : carwar_prb_blackScreen.zip
Le début du code est en 4010h et la fonction qui pose problème, se trouve en B326h.
Si je remplace la fonction par une macro (les paramètres sont placé directement dans le buffer sans passer par la pile), alors ça marche bien aussi sur BlueMSX.
Une idée ?
On est toujours ignorant avant de savoir.
Je testerai demain soir Aoineko !
Salut Aoineko !
Testé sur GT, ça tourne impec. Il y a juste les "barres rouges" qui sont autour de chaque sprites sinon c'est excellent !!
Cela m'a permis d'apprecier les avancées de ton projet et de découvrir tes nouvelles idées ! (Effet d'ombres qui donnent de la profondeur notamment et tremplin ! Génial !!)
Continues, c'est excellent !
Testé sur GT, ça tourne impec. Il y a juste les "barres rouges" qui sont autour de chaque sprites sinon c'est excellent !!
Cela m'a permis d'apprecier les avancées de ton projet et de découvrir tes nouvelles idées ! (Effet d'ombres qui donnent de la profondeur notamment et tremplin ! Génial !!)
Continues, c'est excellent !
Si ça marche sur un MSX et sur tous les autres émulateurs, c'est certainement un bug BlueMSX. Du coup, j'sui mal... BlueMSX étant mon principal outil de développement.
C-à-d ?
GuillianSeed :
les "barres rouges" qui sont autour de chaque sprites
C-à-d ?
On est toujours ignorant avant de savoir.
Jipe :
ça marche sous BlueMSX si on prend un 2+ avec un MSX2 -> BUG
pour les barres rouges regarde les sprites !!
pour les barres rouges regarde les sprites !!
Surement les sprites d'ombre. Bizarre que passer des paramètres par la pile fasse péter les graphismes.
Et bizarre aussi que ça marche bien avec OpenMSX et RuMSX... (sans les traits rouges)
Une idée d'ou ça pourrait venir ?
Sachant que ma pile est placé en D000h et que je dois pas avoir plus de 512 octets de pris en RAM à partir de C000h.
On est toujours ignorant avant de savoir.
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie