La Place des Développeurs Coder en C avec SDCC
ericb59
Membre non connecté
Conseiller Municipal
Reprise du message précédent
aoineko :
Je galère à essayer de compiler/build ton code.
En tout cas, je vois aucune raison pour laquelle ld hl,#_BitmapFont+5 ne fonctionnerait pas.
Tu as débuggé avec OpenMSX pour voir la valeur que prends HL ?
A mon avis, ton problème est ailleurs.
En tout cas, je vois aucune raison pour laquelle ld hl,#_BitmapFont+5 ne fonctionnerait pas.
Tu as débuggé avec OpenMSX pour voir la valeur que prends HL ?
A mon avis, ton problème est ailleurs.
Ben ? Pourquoi tu galère ? Y a rien de spécial dans mon code !
Je crois que je me suis mal fait comprendre ...
ld hl,#_BitmapFont+5, Fonctionne.
Ce que je veux, c’est me passer de cet appel à une variable,
Mais faire en sorte que HL pointe vers les données en ayant stockée l’adresse dans VDPcmd.adress
(Le fait d’avoir un nom de variable fixé dans mon code ASM, n’est pas assez généraliste pour fusion-c.)
aoineko
Membre non connecté
Conseiller Municipal
ericb59 :
Ben ? Pourquoi tu galère ? Y a rien de spécial dans mon code !
Il a des dépendances avec les libs standards (que je n'utilise pas et que je n'ai pas spécialement envi de passer du temps à brancher ).
ericb59 :
Je crois que je me suis mal fait comprendre ...
ld hl,#_BitmapFont+5, Fonctionne.
Ce que je veux, c’est me passer de cet appel à une variable,
Mais faire en sorte que HL pointe vers les données en ayant stockée l’adresse dans VDPcmd.adress
(Le fait d’avoir un nom de variable fixé dans mon code ASM, n’est pas assez généraliste pour fusion-c.)
ld hl,#_BitmapFont+5, Fonctionne.
Ce que je veux, c’est me passer de cet appel à une variable,
Mais faire en sorte que HL pointe vers les données en ayant stockée l’adresse dans VDPcmd.adress
(Le fait d’avoir un nom de variable fixé dans mon code ASM, n’est pas assez généraliste pour fusion-c.)
OK, c'est plus clair effectivement.
Et oui, normalement HL contient bien l'adresse FastVDP.address après la série de outi.
Par contre, ce qui t'intéresse, c'est pas la valeur de cette adresse, mais la valeur pointée par cette address.
Il faut donc que tu mettes (HL) dans HL et ça devrait être bon.
On est toujours ignorant avant de savoir.
ericb59
Membre non connecté
Conseiller Municipal
Citation :
Il faut donc que tu mettes (HL) dans HL et ça devrait être bon.
ha oui... Ca parait logique...
Mais comment je fais ça ?
ld HL,(HL) ca n'existe pas, et je ne n'arrive pas à trouver une solution, je ne suis pas du tout bon en ASM
ericb59 :
Mais comment je fais ça ?
ld HL,(HL) ca n'existe pas, et je ne n'arrive pas à trouver une solution, je ne suis pas du tout bon en ASM
ld HL,(HL) ca n'existe pas, et je ne n'arrive pas à trouver une solution, je ne suis pas du tout bon en ASM
Code :
ld a,(hl)
inc hl
ld h,(hl)
ld l,a
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)
ericb59
Membre non connecté
Conseiller Municipal
Metalion :
ericb59 :
Mais comment je fais ça ?
ld HL,(HL) ca n'existe pas, et je ne n'arrive pas à trouver une solution, je ne suis pas du tout bon en ASM
ld HL,(HL) ca n'existe pas, et je ne n'arrive pas à trouver une solution, je ne suis pas du tout bon en ASM
Code :
ld a,(hl)
inc hl
ld h,(hl)
ld l,a
Rhaaa Merci Metalion.
C'est quand j'ai vu le code que j'ai compris
Je restais bloqué sur le fait que A est un registre 8bits !
Mais qu'il suffisait de faire un INC HL pour obtenir l'autre partie de mon adresse 16 bits...
L'ASM ca fait des noeuds dans ma tête !
aoineko
Membre non connecté
Conseiller Municipal
Faudrait que Metalion confirme que mes DI/LI sont bien placés (j'ai confiance qu'à 90% ).
Si c'est bien le cas, c'est que tu as un soucis ailleurs.
Si c'est bien le cas, c'est que tu as un soucis ailleurs.
On est toujours ignorant avant de savoir.
Ci-dessous code de Grauw testé et approuvé.
Si celui là ne marche pas, c'est que ton problème est ailleurs.
Si celui là ne marche pas, c'est que ton problème est ailleurs.
Code :
;
; Fast DoCopy, by Grauw
; In: HL = pointer to 15-byte VDP command data
; Out: HL = updated
;
DoCopy:
ld a,32
di
out (#99),a
ld a,17 + 128
out (#99),a
ld c,#9B
VDPready:
ld a,2
di
out (#99),a ; select s#2
ld a,15 + 128
out (#99),a
in a,(#99)
rra
ld a,0 ; back to s#0, enable ints
out (#99),a
ld a,15 + 128
ei
out (#99),a ; loop if vdp not ready (CE)
jp c,VDPready
outi ; 15x OUTI
outi ; (faster than OTIR)
outi
outi
outi
outi
outi
outi
outi
outi
outi
outi
outi
outi
outi
ret
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)
JIPEMSX :
@Metalion : MSXVR tu l'as ou pas ?
Non, pas encore ... Prévu en livraison pour le mois prochain.
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)
ericb59
Membre non connecté
Conseiller Municipal
Est-ce que la remise à zero à la fin de l'appel à la commande VDP est obligatoire ? ou pas toujours ?
Code ASM :
exit xor a out (#0x99),a ld a,#0x8f ei out (#0x99),a
ericb59 :
Est-ce que la remise à zero à la fin de l'appel à la commande VDP est obligatoire ? ou pas toujours ?
La remise à zéro du registre de statut est obligatoire, elle est nécessaire à la bonne gestion des interruptions par le BIOS.
Tu as essayé avec la routine DoCopy de Grauw ?
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
A noter que si tes utilisateurs font des accès incrémentaux aux registres du VDP dans les hooks H.KEYI ou H.TIMI, la version de Grauw va générer des bugs.
Si tu veux garder une approche "généraliste", tu devrais protéger aussi les outi.
Si tu veux garder une approche "généraliste", tu devrais protéger aussi les outi.
On est toujours ignorant avant de savoir.
aoineko :
A noter que si tes utilisateurs font des accès incrémentaux aux registres du VDP dans les hooks H.KEYI ou H.TIMI, la version de Grauw va générer des bugs.
Si tu veux garder une approche "généraliste", tu devrais protéger aussi les outi.
Si tu veux garder une approche "généraliste", tu devrais protéger aussi les outi.
Je ne savais pas que ce code avait une utilisation "généraliste". Mais si il faut envisager des cas où les routines appelées en interruptions peuvent utiliser aussi les commandes VDP, alors effectivement, il faut protéger par DI/EI tout le code, jusqu'au dernier OUTI.
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
C'est à EricB de voir, mais vu qu'il semble souhaiter une lib "clef-en-main", ça me semblerait dangereux de proposer du code qui ne gère pas ce genre de cas.
Après, on peut aussi considérer que jouer avec le VDP dans les hook est une utilisation trop "avancé" pour nécessité d'être supporté par Fusion-C.
Ca se discute.
Après, on peut aussi considérer que jouer avec le VDP dans les hook est une utilisation trop "avancé" pour nécessité d'être supporté par Fusion-C.
Ca se discute.
On est toujours ignorant avant de savoir.
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie