Logicielsmoto.com

Nous sommes le 19 Mar 2024, 06:32

Heures au format UTC + 1 heure




Poster un nouveau sujet Répondre au sujet  [ 31 messages ]  Aller à la page 1, 2, 3  Suivante
Auteur Message
 Sujet du message: programmation asm sur mo5
MessagePosté: 26 Juin 2006, 09:26 
Hors ligne

Inscription: 26 Juin 2006, 09:11
Messages: 14
Localisation: Perpignan
Bonjour a tous :)
je sais pas si certain ce souviennent de moi, j'avais posté y'a un an environs sur le forum de dcmoto (ici)

j'avais encore quelque question a l'époque mais je n'arrivais plus à poster, finalement 1 an apres je me remet un peu au mo5 et je m'appercois que le forum avait tout simplement fermé à l'époque, donc tout à fait normal que je ne pouvais plus poster :D

finalement j'ai réussi à transferer des programmes du PC au mo5 avec un moyen tout simple, j'ai utilisé une casette spécial pour autoradio de voiture avec un cable et une prise jack qui depasse, j'ai juste a relier ça a la carte son de mon pc, et ça passe sans soucis, et aucun montage a faire :)
comme je voulais tester mes projet asm sur mon mo5 et que j'ai pas trouver de moyen simple et rapide de convertir un fichier .bin sortant de mon assembleur vers une k7 mo5, je me suis fait un convertisseur qui créer un fichier k7 a partir du .bin

j'ai commencer a faire des experimentation en utilisant le changement de couleur du bord video, d'ailleurs la dessus dcmoto n'emule le changement que par ligne, par contre le calcul des cycles video par instruction est vraiment nikel dans la fenetre mise au point, sur vrai mo5 j'ai un truc parfait :)
mon probleme viens de la synchro a la vbl (ou la hbl) je me suis fier aux registre affiché dans dcmoto, mais j'ai pas l'impression que ça marche :(
déja le registre A7D8 qui semble changer toute les lignes (00 pour ligne pair, 80 ligne impaire), ne change pas sur le vrai mo5 (ça part en boucle infinie) et idem pour le registre A7E7 qui indique l'affichage de la partie visible/non visible, sur vrai mo5 j'ai aussi une boucle infinie des que je test si ce registre est a 80 ou non :(

je voulais donc savoir si je mis prenais mal ou pas, ou si y'avais un autre moyen de pouvoir ce synchroniser sur le balayage video du mo5, merci d'avance.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message: Re: programmation asm sur mo5
MessagePosté: 26 Juin 2006, 14:46 
Hors ligne
M. DCMOTO

Inscription: 06 Juin 2004, 08:23
Messages: 681
Localisation: Provence (France)
Orion_ a écrit:
je voulais donc savoir si je mis prenais mal ou pas, ou si y'avais un autre moyen de pouvoir ce synchroniser sur le balayage video du mo5, merci d'avance.

Pour le MO5, la synchronisation trame est donnée par A7E7 (bit 7) et la synchronisation ligne par A7E6 (bit 6).

DCMOTO renvoie les valeurs suivantes :
- A7E7 = 0x00 hors de la zone affichable, 0x80 à partir du début de la première ligne affichable jusqu'à la fin de la dernière.
- A7E6 = 0x40 pendant la partie "utile" de la ligne, 0x00 pendant le retour du faisceau ou si le spot est dans la bordure de l'écran.

L'émulateur ne reproduit pas fidèlement toutes les subtilités de l'électronique, ce serait beaucoup trop compliqué. Il se contente de permettre le fonctionnement correct des programmes et des démos. En particulier la position exacte à l'intérieur d'une ligne n'est pas directement accessible. On peut seulement détecter le début et la fin de ligne par A7E7. Ensuite il faut compter les cycles pour savoir où est le spot.

DCMOTO affiche chaque ligne d'un seul coup, et la bordure (gauche et droite) ne peut avoir qu'une seule couleur par ligne. Mais, comme je l'ai déjà dit au groupe Puls, si une démo à venir nécessite de faire mieux, c'est tout à fait envisageable. Avec la vitesse des PC modernes, ce qui semblait irréalisable il y a 10 ans devient possible aujourd'hui.

Daniel

PS: je dois avoir écrit tous les convertisseurs possibles de .bin, .bas, .k7, nanoreseau et autres, dans tous les sens, pour MO et pour TO. Il faudra que je rassemble tout ça pour éviter de les réécrire à chaque fois ;)


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 26 Juin 2006, 15:33 
Hors ligne

Inscription: 26 Juin 2006, 09:11
Messages: 14
Localisation: Perpignan
ma technique etait donc mauvaise :)
je pensais qu'on avais uniquement 2 valeurs possible, apres lecture de ta reponse et du manuel technique mo5, sur le vrai mo5 on a un vrai compteur, donc mon BNE/BEQ ne pouvais pas fonctionner, j'ai remplacer par un BPL/BMI et maintenant ça marche :)

je me suis fait une petite routine de raster mais je suis bien déçu, les couleurs sur mon mo5 sont vraiment très très pale on vois quasiment pas le degradé :(
ça rend pas aussi bien que sur dcmoto :/

j'essayerais de tester si on peut faire des effets en changeant la couleur du background pendant le dessin d'une ligne, mais d'apres ce que j'ai pu tester hier c'est pas génial.
l'instruction la plus rapide que j'ai trouver pour faire ça est STA ,Y (4 cycle video) mais bizarrement quand on effectue un changement de couleurs en plein milieu d'une ligne on a un petit morceau de noir entre le changement de couleur :???:

maintenant que j'ai une bonne synchro va falloir que je retest ça ^^


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 26 Juin 2006, 21:52 
Hors ligne
M. DCMOTO

Inscription: 06 Juin 2004, 08:23
Messages: 681
Localisation: Provence (France)
Le nombre limité de couleurs du MO5 rend difficile la création de démos spectaculaires. Malgré une certaine envie et de nombreuses sollicitations, je n'ai jamais eu le courage de m'y lancer. C'est pourquoi j'admire beaucoup toutes les tentatives dans ce domaine, et si je peux apporter de l'aide ce sera avec plaisir :)
Je pense qu'il ne faut pas bidouiller les couleurs pendant l'affichage de la ligne, sinon il y aura toujours des bavures inévitables. Le seul moment propice est la période de retour du balayage, quand le bit 6 de A7E6 est à zéro.

Daniel


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 27 Juin 2006, 00:25 
Hors ligne

Inscription: 06 Juin 2004, 08:23
Messages: 492
Orion_ a écrit:
ma technique etait donc mauvaise :)
je pensais qu'on avais uniquement 2 valeurs possible, apres lecture de ta reponse et du manuel technique mo5, sur le vrai mo5 on a un vrai compteur, donc mon BNE/BEQ ne pouvais pas fonctionner, j'ai remplacer par un BPL/BMI et maintenant ça marche :)


Voila une routine pour attendre que le spot soit dans la zone non visible en haut.

Code:
VBLANK TST $E7E7
               BPL VBLANK
VBLAN0 TST $E7E7
               BMI VBLAN0






Citation:
je me suis fait une petite routine de raster mais je suis bien déçu, les couleurs sur mon mo5 sont vraiment très très pale on vois quasiment pas le degradé :(
ça rend pas aussi bien que sur dcmoto :/


Comme dit Daniel, tu devrais plutot faire sur MO6 au moins (si tu aimes les MO). Tu as 4096 couleurs de palette disponible, c'est ce qu'il faut pour les rasters.

Citation:
j'essayerais de tester si on peut faire des effets en changeant la couleur du background pendant le dessin d'une ligne, mais d'apres ce que j'ai pu tester hier c'est pas génial.

C'est possible, mais des traces parasites vertes vont apparaitre dans la marge et noires au milieu de l'ecran (quand la couleur change). C'est en effet pas genial du tout.

Citation:
l'instruction la plus rapide que j'ai trouver pour faire ça est STA ,Y (4 cycle video) mais bizarrement quand on effectue un changement de couleurs en plein milieu d'une ligne on a un petit morceau de noir entre le changement de couleur :???:

Que veux-tu faire avec ton STA ,Y ?? Un addressage indexe n'est jamais le plus rapide.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 27 Juin 2006, 11:56 
Hors ligne

Inscription: 26 Juin 2006, 09:11
Messages: 14
Localisation: Perpignan
Yoann Riou a écrit:
Voila une routine pour attendre que le spot soit dans la zone non visible en haut.

Code:
VBLANK TST $E7E7
               BPL VBLANK
VBLAN0 TST $E7E7
               BMI VBLAN0

tu est sur de ton code ? c'est pas plutôt A7E7 ?

moi j'ai ça:
Code:
   LDX   #$A7E7

wv1:   LDA   ,X      ; synchro fin d'affichage ecran
   BPL   wv1
wv2:   LDA   ,X
   BMI   wv2   


et ça synchro sur l'affichage de la fin de l'écran "utile", c'est a dire a la ligne 256, apres j'ai un code qui attend un certain nombre de cycle pour arriver au debut de la VBL.

Yoann Riou a écrit:
Comme dit Daniel, tu devrais plutot faire sur MO6 au moins (si tu aimes les MO). Tu as 4096 couleurs de palette disponible, c'est ce qu'il faut pour les rasters.


un mo6 c'est asser rare et je n'en ai pas :(
suis pas fan non plus des mo/to, mais j'ai coder en basic un peu sur mo5 quand j'etais au ce2 (vers 1992) puis fait un exposé sur les vieux ordi avec mon club info au college, dont le mo5, donc c'est plutôt cette machine la qui m'est nostalgique, je pense pas me lancer dans une collec mo/to ^^ (je suis plutôt fan atari ^^)

Yoann Riou a écrit:
Que veux-tu faire avec ton STA ,Y ?? Un addressage indexe n'est jamais le plus rapide.

ben il me semblais que c'etait le plus rapide, un STA $A7C0 fait 5 cycles.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 27 Juin 2006, 14:51 
Hors ligne

Inscription: 06 Juin 2004, 08:23
Messages: 492
Orion_ a écrit:
tu est sur de ton code ? c'est pas plutôt A7E7 ?


Oui, c'est du code pour TO. Il me semble que sur MO, c'est A7C3 (et non A7E7). Daniel ?

Citation:
ben il me semblais que c'etait le plus rapide, un STA $A7C0 fait 5 cycles.


STA ,Y fait 4+ et tu as raison, le + est a 0 (combinaison ,R sans offset) donc ca prend bien 4 cycles.

Sinon, tu peux aussi mettre $A7 dans DP, et faire un STA >$C0. C'est 4 cycles aussi.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 27 Juin 2006, 21:10 
Pour detecter le vertical blank sur MO5, on utilise effectivement la routine suivante :

Code:
VBL0   LDB    >$A7E7
            BPL    VBL0
VBL1   LDB    >$A7E7
            BMI     VBL1


Effectivement aussi, utiliser l'adressage indexé ou direct peut être plus rapide (gain de 1 cycle sur chaque test)

Effectivement encore, la première partie du test (BPL) teste le spot lorsqu'il est dans la partie affichable de l'écran, et la deuxième partie (BMI) lorque le spot est dans les pourtours bas et haut de l'écran affichable. L'inverse (BMI/BPL au lieu de BPL/BMI) attendrait le positionnement du spot sur la première ligne (ou un peu après) de l'écran affichable au lieu de la dernière.

Par contre, si l'on veut agir sur la couleur, il faut attendre un certain nombre de cycles après ce test, à l'endroit où le spot devient totalement invisible :

Code:
              LDX    #$3F0
ATT       LEAX   -1,X
              BNE      ATT


(Plus généralement, la valeur #$200 est utilisée au lieu de #$3F0. Mais bon c'est écrit comme ça dans la ROM MO5)

Maintenant, suivez mon raisonnement :
* Le premier test, quelque soit la position du rayon, attend d'entrer dans la partie affichable de l'écran, s'il n'y est pas déjà. Et cette partie est vaste. Dès qu'il s'y trouve, il laisse la main au deuxième test. Du point de vue du temps d'exécution, c'est donc comme si ce test ne comptait pour rien. Sauf dans les cas rarissimes où le test se ferait pile juste avant le passage hors de l'écran affichable, juste au moment de la dernière chance de sa validation.
* Le branchement du deuxième test n'est pas optimisable.

Donc, seule la ligne du LDB du deuxième test pourrait retenir l'attention en vue d'une optimisation.

Mais ce type de test est principalement utilisé justement dans des programmes dont le temps d'exécution est très variable d'un balayage à l'autre, sans pour autant être tout à fait aléatoire. Il pourrait donc être validé dans sa dernière partie quelques cycles plus tôt ou plus tard en rapport au passage précédent (dans une tranche égale au nombre de cycles machine nécessaires à l'exécution du test), un décalage dû à l'hétérogénéité des codes machine exécutés au préalable.

Donc, à mon avis, de savoir si telle ou telle formulation pour ce type de test est plus ou moins rapide n'est pas prépondérant. Tant que le test ne dure pas trop longtemps...

Et j'irais même plus loin : votre "LDX #$A7E7" utilise trois cycles. Autant de cycles qui vous seront déduits de ceux qu'il vous restera pour le passage suivant. Votre formulation n'est donc pas plus rapide qu'en adressage étendu, puisqu'elle consommerait, en fin de compte, de 1 à 2 cycles de plus ;) Sauf si vous déclarez votre pointeur hors boucle, bien sûr...


Haut
  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 27 Juin 2006, 21:12 
Hors ligne

Inscription: 27 Juin 2006, 19:44
Messages: 1058
Localisation: France (24)
Désolé, j'avais oublié de me loguer :langue:


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 27 Juin 2006, 22:00 
Hors ligne

Inscription: 26 Juin 2006, 09:11
Messages: 14
Localisation: Perpignan
merci beaucoup pour ces precision prehisto :)
j'ai tester ton code d'attente avec 3F0 et 200 mais on arrive respectivement a 70 lignes et 8 lignes apres le debut de la vbl d'apres dcmoto, pour ma part voici mon code de synchro qui est precis a 1 ou 2 cycles videos pres.

Code:
        LDX     #$A7E7

wv1:    LDA     ,X              ; synchro fin d'affichage ecran
        BPL     wv1
wv2:    LDA     ,X
        BMI     wv2             ; ligne 256 ! (sur 312)

                                ; (312-256)*64 cycles - ~10 cycles d'ajustement = 3574 cycles !
        LDA     #210-1  ; 2     ; nombre de cycles a attendre (3574-2) = 3572 / 17 = 210 !
rvbl:   TFR     A,B     ; 6\
        TFR     B,A     ; 6 \
        DECA            ; 2 |-> 17
        BNE     rvbl    ; 3/

        TFR     A,B     ; adjust
        TFR     A,B     ; adjust
        TFR     A,B     ; adjust


Dernière édition par Orion_ le 27 Juin 2006, 22:03, édité 1 fois.

Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 27 Juin 2006, 22:02 
Hors ligne

Inscription: 26 Juin 2006, 09:11
Messages: 14
Localisation: Perpignan
oups erreur, j'ai citer au lieux d'editer, désolé


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 27 Juin 2006, 22:06 
Hors ligne

Inscription: 27 Juin 2006, 19:44
Messages: 1058
Localisation: France (24)
C'est la saison des dérapages...


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 27 Juin 2006, 22:21 
Hors ligne

Inscription: 27 Juin 2006, 19:44
Messages: 1058
Localisation: France (24)
Orion_ a écrit:
merci beaucoup pour ces precision prehisto :)
j'ai tester ton code d'attente avec 3F0 et 200 mais on arrive respectivement a 70 lignes et 8 lignes apres le debut de la vbl d'apres dcmoto, pour ma part voici mon code de synchro qui est precis a 1 ou 2 cycles videos pres.


Bravo. Mais, à mon avis, c'est trop parfait pour un vrai MO ;)


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 27 Juin 2006, 22:35 
Hors ligne

Inscription: 26 Juin 2006, 09:11
Messages: 14
Localisation: Perpignan
j'ai tester sur un vrai mo5 en faisant des rasters qui bouge et ça a l'air pas trop mal :)
evidement je vois pas le haut mais les rasters monte asser haut pour que ça me semble correct.
il faudrat que je test avec des changements de couleurs pendant l'affichage d'une ligne pour voir si je suis vraiment décalé par rapport au debut d'une hbl ou pas.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 28 Juin 2006, 04:02 
Hors ligne

Inscription: 26 Juin 2006, 09:11
Messages: 14
Localisation: Perpignan
je viens de passer 3 ou 4 heures avec une partie qui m'a pris du temps pour ajuster le tout, mais j'y suis finalement arrivé !
voici un petit écran qui montre des rasters sur mo5 :)
a visualiser sur un vrai mo5 et une vrai télé pour un meilleur rendu ^^

à lancer avec RUN"

Rasters (mo5/k7)

(d'ailleurs dcmoto n'affiche pas tout l'ecran du coup on vois pas le raster du haut, et seulement un bout de celui en bas)

j'en profite pour demander, j'ai télécharger des jeux sur ce site, mais ce sont des .k5, comment les convertir en .k7 ? ou alors existe t-il un convertisseur k5 to wav ?


Haut
 Profil  
Répondre en citant le message  
Afficher les messages postés depuis:  Trier par  
Poster un nouveau sujet Répondre au sujet  [ 31 messages ]  Aller à la page 1, 2, 3  Suivante

Heures au format UTC + 1 heure


Qui est en ligne

Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 4 invités


Vous ne pouvez pas poster de nouveaux sujets
Vous ne pouvez pas répondre aux sujets
Vous ne pouvez pas éditer vos messages
Vous ne pouvez pas supprimer vos messages
Vous ne pouvez pas joindre des fichiers

Rechercher:
Aller à:  
cron
Développé par phpBB® Forum Software © phpBB Group
Traduction par phpBB-fr.com