MSX Village forum

La Place des Développeurs Projet Ambidex

aoineko Membre non connecté

Conseiller Municipal

Rang

Avatar

Groupe : Shoutbox

Inscrit le : 02/01/2011 à 21h17

Messages: 2714

Le 21/01/2011 à 00h14

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. :fou

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 ? :hum Edité par aoineko Le 21/01/2011 à 00h16


On est toujours ignorant avant de savoir.
Github    
aoineko Membre non connecté

Conseiller Municipal

Rang

Avatar

Groupe : Shoutbox

Inscrit le : 02/01/2011 à 21h17

Messages: 2714

Le 21/01/2011 à 00h49
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. :heink

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 ? :moue



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.
Github    
Metalion Membre non connecté

Conseiller Municipal

Rang

Avatar

Inscrit le : 23/12/2009 à 15h32

Messages: 1488

Le 21/01/2011 à 09h20
Après utilisation, le registre 15 doit toujours être remis à zéro.
Je ne sais plus pourquoi, mais c'est comme ça :p
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

Rang

Avatar

Groupe : Shoutbox

Inscrit le : 02/01/2011 à 21h17

Messages: 2714

Le 21/01/2011 à 12h32
Metalion :
Après utilisation, le registre 15 doit toujours être remis à zéro.

Je ne sais plus pourquoi, mais c'est comme ça :p

Dans ton cas, c'est à la sortie de boucle, après avoir réalisé la copie.




Ça marche ! Merci Metalion ! :top




On est toujours ignorant avant de savoir.
Github    
Metalion Membre non connecté

Conseiller Municipal

Rang

Avatar

Inscrit le : 23/12/2009 à 15h32

Messages: 1488

Le 21/01/2011 à 18h49
Metalion :
Après utilisation, le registre 15 doit toujours être remis à zéro.

Je ne sais plus pourquoi, mais c'est comme ça :p


J'ai retrouvé l'explication ... :heink



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 ... :p


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

Rang

Avatar

Groupe : Shoutbox

Inscrit le : 02/01/2011 à 21h17

Messages: 2714

Le 22/01/2011 à 23h57
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 :
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é. :moue

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 ? :hum Edité par aoineko Le 23/01/2011 à 00h09


On est toujours ignorant avant de savoir.
Github    
Metalion Membre non connecté

Conseiller Municipal

Rang

Avatar

Inscrit le : 23/12/2009 à 15h32

Messages: 1488

Le 23/01/2011 à 09h04
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.


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

Rang

Avatar

Groupe : Shoutbox

Inscrit le : 02/01/2011 à 21h17

Messages: 2714

Le 23/01/2011 à 09h31
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 ? :hum



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. :moue


On est toujours ignorant avant de savoir.
Github    
Metalion Membre non connecté

Conseiller Municipal

Rang

Avatar

Inscrit le : 23/12/2009 à 15h32

Messages: 1488

Le 23/01/2011 à 09h54
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. :moue




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

Rang

Avatar

Groupe : Shoutbox

Inscrit le : 02/01/2011 à 21h17

Messages: 2714

Le 23/01/2011 à 11h42
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.




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.




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.
Github    
Metalion Membre non connecté

Conseiller Municipal

Rang

Avatar

Inscrit le : 23/12/2009 à 15h32

Messages: 1488

Le 23/01/2011 à 12h15
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 ?


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

Rang

Avatar

Groupe : Shoutbox

Inscrit le : 02/01/2011 à 21h17

Messages: 2714

Le 23/01/2011 à 14h01
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.
Github    
aoineko Membre non connecté

Conseiller Municipal

Rang

Avatar

Groupe : Shoutbox

Inscrit le : 02/01/2011 à 21h17

Messages: 2714

Le 25/01/2011 à 00h55
Je mets ce projet en stand-by le temps de développer un autre jeu qui me tiens à cœur : Carwar


On est toujours ignorant avant de savoir.
Github    
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie