Salut haaaa enfin hahaha Super le cours. J ai demand´´e a un prof de ASM ici a Barcelone, il me dit que les variables peuvent uniquement aller dans A et pas dans les autres regitres, c est structurel
Effectivement il n'y a pas d'instruction LD H,(nn) ni LD L,(nn) par contre il y a une instruction LD HL,(nn)... Il doit donc être possible d'utiliser un LD HL,(YOBJET) mais il faudrait inverser l'ordre des DB (mettre YOBJET en premier)... Pour ton deuxième problème c'est sans doute une histoire de ROM basse commutée et donc si on met les données avant l'adresse &4000 c'est cette ROM qui doit être lue au lieu des données en RAM (Je crois que j'avais eu le même genre de soucis avec ma lib pour sdcc)
Énorme, je ne me rappelais pas qu'on pouvais commuter la ROM basse entre &0000 et &3FFF de la RAM. Ça se fait par le registre RMR du Gate-Array, celui qui permet aussi le changement de mode. Exemple : LD BC,&7F88 ; Bit 3 = 1 = ROM haute désactivée. Bit 2 = 0 = ROM basse activée. OUT (C),C
@CopperFrance : Avec ton explication et la précision dans un autre commentaire, je comprends mieux l'astuce pour contourner cette limitation. Merci 🙂 !
Pour le deuxième problème, il s'agit peut-être de la gestion du SYMBOL AFTER du BASIC. Que remonte le vecteur : BBAE TXT_GET_M_TABLE ? A doit contenir la valeur du Symbol After. Si ce n'est pas 240, ca peut poser problème. Si c'est le cas, un appel à BBAB TXT_SET_M_TABLE pour fixer la zone mémoire utilisée par les surcharges des symboles devrait améliorer le point. Sinon, je crois que le Symbol After est fixé à 250 (de mémoire), est-ce que 255 au lieu de 240 corrige le problème ?
Par défault c'est SYMBOL AFTER 240. Utiliser BBAB TXT_SET_M_TABLE serait nécessaire par contre pour définir des caractères avant 240. Et sera indispensable si on fait un RUN d'un .BIN qui semble réinitialiser la table
@@CopperFrance Cela voudrait donc dire que le vecteur BBA8 TXT_SET_MATRIX n'utilise pas du tout la gestion BASIC et permet de mettre un pointeur pour chaque caractère ? Etrange mais possible vu le commentaire sur cpc-power. Je pensais qu'il n'y avait que 2 tables : la table en ROM et la table de redéfinition. Et donc dans ce cas oui : attention car BBA5 est en ROM et pense que les caractères redéfinis sont bien plus proche de la fin de mémoire BASIC, donc adresse de redéfinition > &4000 obligatoire. Ou bien de récupérer l'adresse officielle du caractère 240 via BBAE TXT_GET_M_TABLE pour mettre le caractère 'au bon endroit' directement et ne pas changer son emplacement pour le BASIC.
@@jolletxavier7036 Si il l'utilise mais par contre quand on appelle BBA8 TXT_SET_MATRIX on passe une adresse en RAM pour les données. Sauf qu'au moment ou la routine en ROM a besoin des données si celles-ci sont situées avant l'adresse &4000 il va les lire en ROM au lieu de les lire en RAM c'est pour ça qu'on obtient un caractère bizarre et que ça fonctionne quand on déplace le programme en &4000 (même si déplacer les données du caractère après &4000 serait suffisant).
@@jolletxavier7036Si il l'utilise le problème étant que l'on fourni une adresse au vecteur BBA8 TXT_SET_MATRIX et il doit recopier les données au bon endroit seulement au moment ou cette copie s'effectue la ROM basse est connectée donc si l'on fourni une adresse < &4000 il recopie à partir de la ROM au lieu de la RAM. Ca explique pourquoi on obtient un caractère bizarre si l'adresse est < &4000 et pourquoi cela fonctionne si on fourni une adresse >= &4000. En théorie on doit aussi pouvoir recopier directement les données en utilisant un LDIR vers l'adresse fournie par BBA5 TXT GET MATRIX
@@jolletxavier7036 En fait il faut que la table et les données à mettre dans la table soient situés à partir de &4000... Ici il utilise la table du BASIC dont pas de souci pour l'adresse de celle-ci mais par contre pour les données ce n'était pas le cas sans mettre le ORG à &4000.
merci . Je suis preneur des explications pour percer le mystère... au prochain épisode
Toujours aussi intéressant et bien expliqué, bravo.
Merci à toi 👍
Excellent
Salut
haaaa enfin hahaha
Super le cours. J ai demand´´e a un prof de ASM ici a Barcelone, il me dit que les variables peuvent uniquement aller dans A et pas dans les autres regitres, c est structurel
on peut tricher, inverser les étiquettes
ld hl,(ypos)
ret
ypos db 12
xpos db 20
ainsi, h=20 et l=12 ;)
@LuisDiazuu7xg : super, je me doutais bien. Merci pour cette confirmation.
@@cr5331 : Rhooo oui, joli l'astuce pour contourner cette limitation 🙂.
Effectivement il n'y a pas d'instruction LD H,(nn) ni LD L,(nn) par contre il y a une instruction LD HL,(nn)... Il doit donc être possible d'utiliser un LD HL,(YOBJET) mais il faudrait inverser l'ordre des DB (mettre YOBJET en premier)... Pour ton deuxième problème c'est sans doute une histoire de ROM basse commutée et donc si on met les données avant l'adresse &4000 c'est cette ROM qui doit être lue au lieu des données en RAM (Je crois que j'avais eu le même genre de soucis avec ma lib pour sdcc)
Énorme, je ne me rappelais pas qu'on pouvais commuter la ROM basse entre &0000 et &3FFF de la RAM. Ça se fait par le registre RMR du Gate-Array, celui qui permet aussi le changement de mode. Exemple :
LD BC,&7F88 ; Bit 3 = 1 = ROM haute désactivée. Bit 2 = 0 = ROM basse activée.
OUT (C),C
@CopperFrance : Avec ton explication et la précision dans un autre commentaire, je comprends mieux l'astuce pour contourner cette limitation. Merci 🙂 !
Pour le deuxième problème, il s'agit peut-être de la gestion du SYMBOL AFTER du BASIC.
Que remonte le vecteur : BBAE TXT_GET_M_TABLE ? A doit contenir la valeur du Symbol After. Si ce n'est pas 240, ca peut poser problème.
Si c'est le cas, un appel à BBAB TXT_SET_M_TABLE pour fixer la zone mémoire utilisée par les surcharges des symboles devrait améliorer le point.
Sinon, je crois que le Symbol After est fixé à 250 (de mémoire), est-ce que 255 au lieu de 240 corrige le problème ?
Par défault c'est SYMBOL AFTER 240. Utiliser BBAB TXT_SET_M_TABLE serait nécessaire par contre pour définir des caractères avant 240. Et sera indispensable si on fait un RUN d'un .BIN qui semble réinitialiser la table
@@CopperFrance Cela voudrait donc dire que le vecteur BBA8 TXT_SET_MATRIX n'utilise pas du tout la gestion BASIC et permet de mettre un pointeur pour chaque caractère ? Etrange mais possible vu le commentaire sur cpc-power. Je pensais qu'il n'y avait que 2 tables : la table en ROM et la table de redéfinition.
Et donc dans ce cas oui : attention car BBA5 est en ROM et pense que les caractères redéfinis sont bien plus proche de la fin de mémoire BASIC, donc adresse de redéfinition > &4000 obligatoire.
Ou bien de récupérer l'adresse officielle du caractère 240 via BBAE TXT_GET_M_TABLE pour mettre le caractère 'au bon endroit' directement et ne pas changer son emplacement pour le BASIC.
@@jolletxavier7036 Si il l'utilise mais par contre quand on appelle BBA8 TXT_SET_MATRIX on passe une adresse en RAM pour les données. Sauf qu'au moment ou la routine en ROM a besoin des données si celles-ci sont situées avant l'adresse &4000 il va les lire en ROM au lieu de les lire en RAM c'est pour ça qu'on obtient un caractère bizarre et que ça fonctionne quand on déplace le programme en &4000 (même si déplacer les données du caractère après &4000 serait suffisant).
@@jolletxavier7036Si il l'utilise le problème étant que l'on fourni une adresse au vecteur BBA8 TXT_SET_MATRIX et il doit recopier les données au bon endroit seulement au moment ou cette copie s'effectue la ROM basse est connectée donc si l'on fourni une adresse < &4000 il recopie à partir de la ROM au lieu de la RAM. Ca explique pourquoi on obtient un caractère bizarre si l'adresse est < &4000 et pourquoi cela fonctionne si on fourni une adresse >= &4000. En théorie on doit aussi pouvoir recopier directement les données en utilisant un LDIR vers l'adresse fournie par BBA5 TXT GET MATRIX
@@jolletxavier7036 En fait il faut que la table et les données à mettre dans la table soient situés à partir de &4000... Ici il utilise la table du BASIC dont pas de souci pour l'adresse de celle-ci mais par contre pour les données ce n'était pas le cas sans mettre le ORG à &4000.