La Place des Développeurs Projet Ambidex
aoineko
Membre non connecté
Conseiller Municipal
Reprise du message précédent
Argh, j'ai perdu pas mal de temps à chercher pourquoi le tableau que je construisais ne voulais pas s'initialiser... hum... il était en ROM, donc pas éditable.Bon, une fois trouvé, j'ai commencé à coder la copie RAM -> VRAM (le HMMC) mais je tombe sur os.
L'initialisation des registres 36 à 46 se fait correctement si j'en crois le débogueur de BlueMSX, mais c'est surement dans la boucle de copie qu'il y a un problème (le MSX semble crasher).
Je mets ici le code de la boucle au cas ou quelqu'un comprennes mon erreur ou me donne une piste pour savoir vers ou chercher.
Code ASM :
;// Copie des 63 couleurs restants (sprites de 8x8) di ;// je le laisse la pour l'instant pour plus de clarté SEND_NEXT_COLOR: ;// 3 - envoyer l'octet suivant à mettre en VRAM dans le registre 45 (le premier octet a été traité à l'étape 1) par un OUT du Z80 ;// Send next color lda,#252 ;// couleur en dur pour mes tests out(VDP_ADDR),a ;// VDP_ADDR = 99h lda,VDP_REG(45) ;// VDP_REG(x) = 80h + x out(VDP_ADDR),a WAIT_REG2: ;// 4 - lire le registre d'état 2 (status) ;// Get status ragister #2 lda,#2 out(VDP_ADDR),a lda,VDP_REG(15) out(VDP_ADDR),a ;// 5 - lire le registre d'état du bit CE, si celui-ci est à 0, alors l'instruction est terminée, sinon on passe à l'étape 6 nop ina,(VDP_ADDR) ldb,a ;// backup reg#2 rra ;// send CE bit into Carry jrnc,COLOR_COPY_END ;// 6 - tester l'état du bit TR, si celui-ci se trouve à 0, alors le processeur vidéo n'est pas ;// prêt à recevoir l'octet suivant, recommencer en 4. Si par contre, ce bit est à 1, reprendre toute l'opération au niveau 3 lda,b ;// restore reg#2 rla ;// send TR bit in the Carry jrnc,WAIT_REG2 jpSEND_NEXT_COLOR COLOR_COPY_END: ei
Des idées, conseils ? Edité par aoineko Le 21/01/2011 à 00h16
On est toujours ignorant avant de savoir.
aoineko
Membre non connecté
Conseiller Municipal
aoineko :
3 - envoyer l'octet suivant à mettre en VRAM dans le registre 45 (le premier octet a été traité à l'étape 1) par un OUT du Z80
Il semble y avoir une coquille dans le Pratique du MSX 2 car ça semble être le registre 44 et non le registre 45.
Bon, du coup, mon carré s'affiche correctement à l'écran, par contre, au bout de 2 à 10s, le MSX plante.
Surement un problème synchronisation, mais j'ai aucune d'idée d'ou ça pourrait venir...
Une idée ? Une piste ?
EDIT : J'ai mis mes .bin, .sym et ma rom en pièce jointe au cas ou : carwar.zip. Edité par aoineko Le 21/01/2011 à 00h56
On est toujours ignorant avant de savoir.
Après utilisation, le registre 15 doit toujours être remis à zéro.
Je ne sais plus pourquoi, mais c'est comme ça
Dans ton cas, c'est à la sortie de boucle, après avoir réalisé la copie.
Je ne sais plus pourquoi, mais c'est comme ça
Dans ton cas, c'est à la sortie de boucle, après avoir réalisé la copie.
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)
aoineko
Membre non connecté
Conseiller Municipal
Metalion :
Après utilisation, le registre 15 doit toujours être remis à zéro.
Je ne sais plus pourquoi, mais c'est comme ça
Dans ton cas, c'est à la sortie de boucle, après avoir réalisé la copie.
Je ne sais plus pourquoi, mais c'est comme ça
Dans ton cas, c'est à la sortie de boucle, après avoir réalisé la copie.
Ça marche ! Merci Metalion !
On est toujours ignorant avant de savoir.
Metalion :
Après utilisation, le registre 15 doit toujours être remis à zéro.
Je ne sais plus pourquoi, mais c'est comme ça
Je ne sais plus pourquoi, mais c'est comme ça
J'ai retrouvé l'explication ...
En fait la routine de gestion des interruptions dans le BIOS interroge systématiquement le registre S#0 pour ses besoins propres. Et comme le registre R#15 a comme valeur zéro par défaut, cette routine considère qu'il n'est pas nécessaire de le remettre à zéro. En conclusion, à chaque utilisation du registre R#15, il faut arrêter les interruptions (DI), le remettre à zéro après utilisation et puis autoriser les interruptions (EI).
Sinon, plantage ...
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)
aoineko
Membre non connecté
Conseiller Municipal
Bon, j'ai un soucis, mais c'est certainement lié à mon compilateur C donc je suis pas sur que vous puissiez m'aider.
En gros, j'arrive pas à avoir mon sprite la ou je veux en ROM.
Si je créé mon tableau de façon classique :
Le compilateur me génère l'ASM suivant :
En fait, l'ASM essaye d'initialiser la valeur du tableau au démarrage. Hors, comme le tableau est en ROM, il ne peut être modifié.
Si je déclare mon tableau comme étant constant:
Il est bien écris en dur dans la ROM...
... mais en plein milieu du code ! Il se trouve dans la .area _CODE.
En fait, j'ai un doute sur ce que je suis censé avoir comme résultat. .area _DATA est une zone que je devrais avoir en ROM ou en RAM ? Est-ce normal d'avoir des données en dur au milieu du code ? Comment organisez-vous vos données dans la ROM ? Edité par aoineko Le 23/01/2011 à 00h09
En gros, j'arrive pas à avoir mon sprite la ou je veux en ROM.
Si je créé mon tableau de façon classique :
Code C :
u8 g_Sprite[8*8] = { 1, 2, 3, ... 64 };
Le compilateur me génère l'ASM suivant :
Code ASM :
.area _DATA _g_Sprite:: ;// qui se retrouve bien à l'adresse 0x8000 (pour l'instant je garde 16ko pour le code, 16ko pour les datas) .ds 64 ... .area _OVERLAY .area _HOME .area _GSINIT .area _GSFINAL .area _GSINIT ... ;carwar.c:143: u8 g_Sprite[8*8] = ldhl,#_g_Sprite call__initrleblock .db55 .db0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08 ...
En fait, l'ASM essaye d'initialiser la valeur du tableau au démarrage. Hors, comme le tableau est en ROM, il ne peut être modifié.
Si je déclare mon tableau comme étant constant:
Code C :
const u8 g_Sprite[8*8] = { 1, 2, 3, ... 64 };
Il est bien écris en dur dans la ROM...
Code ASM :
_g_Sprite: .db #0x01 .db #0x02 .db #0x03 .db #0x04 ...
... mais en plein milieu du code ! Il se trouve dans la .area _CODE.
En fait, j'ai un doute sur ce que je suis censé avoir comme résultat. .area _DATA est une zone que je devrais avoir en ROM ou en RAM ? Est-ce normal d'avoir des données en dur au milieu du code ? Comment organisez-vous vos données dans la ROM ? Edité par aoineko Le 23/01/2011 à 00h09
On est toujours ignorant avant de savoir.
Tes datas sont forcément dans la ROM, puisqu'ils font partie des données que tu apportes dans le système avec ta cartouche.
Si tu veux les positionner en RAM, c'est à toi d'écrire le code dans ta ROM pour les transférer lors de l'initialisation.
En ce qui concerne le positionnement des données dans ta ROM, là je ne peux pas t'aider, cela dépend effectivement de ton compilateur C.
Si tu veux les positionner en RAM, c'est à toi d'écrire le code dans ta ROM pour les transférer lors de l'initialisation.
En ce qui concerne le positionnement des données dans ta ROM, là je ne peux pas t'aider, cela dépend effectivement de ton compilateur C.
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)
aoineko
Membre non connecté
Conseiller Municipal
Metalion :
En ce qui concerne le positionnement des données dans ta ROM, là je ne peux pas t'aider, cela dépend effectivement de ton compilateur C.
Mais en général, quand on fait une ROM à partir d'un code ASM, où met on les données ? On les colle juste derrière le code ? On les places à une adresse précise dans la ROM ?
Du coup, je suis plus sur de comprendre la signification de la zone .area _DATA. La description de mon compilateur me dit que c'est la zone en RAM où mettre mes données modifiables, mais si je la set à 0xC000 (ma ROM est sur la page 1 et 2), l'outil Hex2bin dont je me sert pour créer ma ROM, agrandi la ROM pour que la zone .area _DATA (et tous les datas s'y trouvant) y soit inclus. Du coup, je me retrouve avec une ROM de plus de 64Ko.
On est toujours ignorant avant de savoir.
aoineko :
Mais en général, quand on fait une ROM à partir d'un code ASM, où met on les données ? On les colle juste derrière le code ? On les places à une adresse précise dans la ROM ?
On les mets où on veux !!!
Il n'y a pas de règle ... C'est toi qui les positionne en fonction de tes besoins.
Pour des programmes simples, on peut effectivement les coller derrière le code.
aoineko :
Du coup, je suis plus sur de comprendre la signification de la zone .area _DATA. La description de mon compilateur me dit que c'est la zone en RAM où mettre mes données modifiables, mais si je la set à 0xC000 (ma ROM est sur la page 1 et 2), l'outil Hex2bin dont je me sert pour créer ma ROM, agrandi la ROM pour que la zone .area _DATA (et tous les datas s'y trouvant) y soit inclus. Du coup, je me retrouve avec une ROM de plus de 64Ko.
Tu ne peux pas travailler en phase de compilation avec des données en RAM.
Il faut considérer que le seul espace mémoire accessible pour ton code et tes données est $4000-$BFFF. Point.
Après, dans ton code, tu peux utiliser la RAM après $C000 pour stocker des données, mais uniquement dans la phase d'éxecution du code, pas pendant la phase de compilation.
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)
aoineko
Membre non connecté
Conseiller Municipal
Metalion :
On les mets où on veux !!!
Il n'y a pas de règle ... C'est toi qui les positionne en fonction de tes besoins.
Pour des programmes simples, on peut effectivement les coller derrière le code.
Il n'y a pas de règle ... C'est toi qui les positionne en fonction de tes besoins.
Pour des programmes simples, on peut effectivement les coller derrière le code.
Les mettre au milieu du code, ça peut être problématique pour les jump, non ? (ça oblige à utiliser des far jump)
Metalion :
Tu ne peux pas travailler en phase de compilation avec des données en RAM.
Il faut considérer que le seul espace mémoire accessible pour ton code et tes données est $4000-$BFFF. Point.
Après, dans ton code, tu peux utiliser la RAM après $C000 pour stocker des données, mais uniquement dans la phase d'éxecution du code, pas pendant la phase de compilation.
Il faut considérer que le seul espace mémoire accessible pour ton code et tes données est $4000-$BFFF. Point.
Après, dans ton code, tu peux utiliser la RAM après $C000 pour stocker des données, mais uniquement dans la phase d'éxecution du code, pas pendant la phase de compilation.
Oui, je comprends bien, c'est juste la définition de la zone .area _DATA qui n'est pas claire. Est-t'elle censé pointer vers l'espace de travail en RAM comme le laisse penser la doc de mon compilo ou vers une zone en lecture seul dans ma ROM comme semble le suggérer le résultat de Hex2bin.
En gros, à quoi servent les zones .area _DATA et .area _CODE ?
On est toujours ignorant avant de savoir.
aoineko :
Oui, je comprends bien, c'est juste la définition de la zone .area _DATA qui n'est pas claire. Est-t'elle censé pointer vers l'espace de travail en RAM comme le laisse penser la doc de mon compilo ou vers une zone en lecture seul dans ma ROM comme semble le suggérer le résultat de Hex2bin.
En gros, à quoi servent les zones .area _DATA et .area _CODE ?
En gros, à quoi servent les zones .area _DATA et .area _CODE ?
Je ne connait pas ton compilateur C, mais à mon avis, area_DATA pointe vers la zone de stockage données que TU définis pour ton code, et idem pour area_CODE. Est-ce que tu peux forcer la valeur de area_DATA ou bien est-ce que le compilateur la défini tout seul ? Si il la définit tout seul, tu es coincé par sa gestion des zones de données ... Si tu peux forcer la valeur, essaie de la définir dans une zone éloignée de ta ROM, genre $B000, pour voir ce que ça donne.
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)
aoineko
Membre non connecté
Conseiller Municipal
Metalion :
Je ne connait pas ton compilateur C, mais à mon avis, area_DATA pointe vers la zone de stockage données que TU définis pour ton code, et idem pour area_CODE. Est-ce que tu peux forcer la valeur de area_DATA ou bien est-ce que le compilateur la défini tout seul ? Si il la définit tout seul, tu es coincé par sa gestion des zones de données ... Si tu peux forcer la valeur, essaie de la définir dans une zone éloignée de ta ROM, genre $B000, pour voir ce que ça donne.
Oui, je peux définir l'adresse de ces zones. Actuellement, CODE est mit à 0x4010 (pour garder la place pour les 16 bits d'entête de la ROM) et DATA est à 0x8000. Le problème, c'est que mon BIN s'agrandit automatiquement pour inclure toutes les données de la zone DATA ; elles seront donc forcement en ROM. Mais d'un autre coté, toutes les donnés définies dans cette zone ne sont initialisées qu'à l'exécution ; et donc, comme c'est en ROM, l'écriture ne se fait pas.
En gros, si j'ai bien compris, le seul moyen de m'en sortir, c'est de définir la zone DATA à 0xC000 et de n'y mettre aucune données et en définissant mes données directement dans la zone CODE (à la fin de mon programme). C'est pas encore très clair, mais je vais partir sur ce schéma ; on verra bien ou ça me mènera.
Merci pour les infos.
On est toujours ignorant avant de savoir.
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie