Logicielsmoto.com

Nous sommes le 29 Mar 2024, 14:53

Heures au format UTC + 1 heure




Poster un nouveau sujet Répondre au sujet  [ 41 messages ]  Aller à la page Précédente  1, 2, 3
Auteur Message
 Sujet du message:
MessagePosté: 13 Sep 2006, 10:49 
Hors ligne
M. DCMOTO

Inscription: 06 Juin 2004, 08:23
Messages: 681
Localisation: Provence (France)
sinus a écrit:
Code:
*AFFICHAGE PAGE 3  (ORA #$C0 en $E7DD)

L'erreur est probablement là : on ne peut pas lire directement $E7DD.
Le registre $E7DD est en écriture. On peut lire partiellement son contenu en $E7E4, après avoir écrit le bit 0 de $E7E4 à zéro.

Daniel


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 13 Sep 2006, 16:06 
Hors ligne

Inscription: 27 Mai 2006, 03:09
Messages: 58
Daniel Coulom a écrit:
$E7E7 est initialisé à $54 (ou $D4 pour un contrôleur de disquette externe). La valeur d'initialisation de $E7E7 est aussi copiée en $6081, mais je ne sais pas si on peut s'y fier.
Si on utilise le contrôleur interne, on peut écrire $54 en $E7E7 pour positionner le bit D4, sans aucun risque de planter le système.


Merci pour ces nouveaux indices, Daniel. J'ai pu procéder à la correction de mes routines par élimination. La bonne nouvelle, c'est que mes routines sont débuguées!

Code:
*PASSAGE EN MODE BITMAP16  (Moniteur)
= Un RTS mal placé me maintenait en mode Bavures16 au lieu de Bitmap16

*AFFICHAGE PAGE 3  (ORA #$C0 en $E7DD)
= j'avais bien pensé à 0 avant lecture en $E7E4 comme tu me l'avais conseillé plus haut, MAIS...

*AUTORISATION D’ECRITURE EN RAM DONNEES (registre ‘système 1’ D4=1)
(voir plus bas)

*PERMETTRE L’ECRITURE DANS LA PAGE DONNEES/VIDEO 3 (ANDA $03 en $E7E5)
= ... c'est LA que j'ai de nouveau commis l'erreur avec $E7E5 en lecture alors que je n'aurais pas dû! Ca bloquait tout! 

*TEST ECRITURE: remplir toute la page $A000 à $DFFF avec 1 couleur (au pif: $FF dans chaque octet (=2 pixels d'un coup, chaque pixel couleur 1111 dans équivalents RAM A = adresses hautes ET B = adresses basses)


J'ai remarqué que l'initialisation du moniteur ici ne semblait servir à rien. Pire, quand j'initialise, j'arrive à lancer le programme 1 fois, mais la 2ème fois le système plante.
Code:
INIMON   CLRB
               JSR   $EC0C

J'ai donc viré l'initialisation moniteur...

La mise à 1 de D4 en $E7E7 me posait en effet problème. J'ai testé tes 2 méthodes et elles marchent toutes les deux:

Code:
POSSIBILITE 1 : testée = OK :

SYS1   EQU   $E7E7
            LDA    #$54 imposer les valeurs 01010100 en $E7E7 (système 1) si contrôleur interne   
            STA    SYS1

Ca va, l'ordinateur ne semble pas souffrir de troubles de la personnalité...


et

Code:
POSSIBILITE 2 : testée = OK:
SYS1       EQU     $E7E7
SYS1CF   EQU     $6081     lecture des valeurs initiales de $E7E7 dans $6081
                LDA     SYS1CF 
                ORA    #$10         met D4 à 1 (écriture autorisée en RAM données)
                STA     SYS1


C'est cette 2ème méthode que je retiendrai par souci de compatibilité avec les autres machines (imaginons que Thomson ne ressortent des machines un jour :lol: ... je plaisante... :D )

Par ailleurs, je suis très heureux de retomber sur cette adresse $6081!

C'est l'espace "RAM système", qui est réputé inaccessible en écriture... Yoann utilise pourtant $6081 et $616D en écriture :eek: et $6181 en lecture dans ses routines PULS/"vector balls" ( http://www.pulsdemos.com/chinese/vector ... lls02.html ).

J'avais cherché des docs partout sur ces adresses et je n'avais jamais rien trouvé! Ca s'éclaircit un peu, du coup. :sol:

Bon, ça va, on commence à y voir plus clair!
Merci encore, je vais pouvoir avancer de nouveau. :p
Arnaud


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 15 Sep 2006, 21:09 
Hors ligne

Inscription: 27 Mai 2006, 03:09
Messages: 58
jasz a écrit:
J'avais oublié. Préhisto avait donnée une solution pour l'overscreen ou l'on se sert du bit 5 du registre $E7E7 en écriture.

Merci Jasz! Intéressant, en effet! :)
A.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 17 Déc 2006, 05:21 
Hors ligne

Inscription: 27 Mai 2006, 03:09
Messages: 58
Je reviens (après un certain temps...) avec 2 nouvelles questions:

Question 1 - Je crois comprendre qu'il n'est pas possible de transferer des données d'une page commutable à l'autre, n'est-ce pas? Il faudrait alors passer par un espace intermédiaire qui ne peut-être que page 0 et une partie de page 1, quelqu'un peut-il me confirmer ça? Est-ce la seule démarche que l'on peut suivre?

la copie devrait donc obligatoirement se faire comme ça:
PAGE SOURCE (commutable) -> PAGE 0 ou 1 (non affichées) -> [commutation SOURCE/CIBLE] -> PAGE CIBLE (2 ou 3 = affichées à l'écran)

Question 2 - En admettant que les pages 2 et 3 soient consacrées à l'affichage, que reste-t-il comme espace RAM utilisable pour mettre en "réserve" des objets (personnages / meubles / décors etc...).

Dans mon cas: la page 0 est utilisée pour stocker les mouvements des personnages du tableau en cours d'affichage.

La 1ere partie de la page 1 est réservée au système. Comme cela se fait dans les programmes d'exemples de manuels, je me sers donc de la partie $9000-$9FFF comme RAM fixe pour y mettre le corps de mon programme et les variables. Mais c'est étroit...

Est-il possibile de descendre plus basdans les adresses, sans que ça ne crée de bug dans le système? (j'expérimente, mais il y a sans doute des bugs que je ne vois pas)

J'ai encore quelques meubles, objets de décors 'animés' et autres personnages à stocker... l'accès à ces données doit être rapide pour assurer un minimum de fluidité dans l'animation. D'où ma recherche d'espaces RAM qui permettent une copie directe de données jusqu'aux pages 2 et 3 (écran).

Quelqu'un aurait-il des conseils là-dessus? Ou des lectures à me conseiller?

merci! ;)

Sinus


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 17 Déc 2006, 07:57 
Hors ligne
M. DCMOTO

Inscription: 06 Juin 2004, 08:23
Messages: 681
Localisation: Provence (France)
Pour passer des données d'une banque à l'autre, il n'est pas nécessaire d'utiliser la ram non paginée : on peut stocker dans des registres, commuter, écrire les registres, commuter, etc.
On peut aussi passer par la pile système, mais ça revient à utiliser la ram non paginée.
Il faut choisir en fonction des performances. La commutation de pages est, je pense, moins longue qu'une écriture+lecture en ram, donc le passage par les registres est probablement la meilleure méthode.

L'espace disponible en mémoire non paginée dépend essentiellement de l'utilisation ou non du Basic. Si le Basic est utilisé, il ne faut pas écraser ses zones de travail. Sinon elles sont disponibles.

Daniel


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 24 Déc 2006, 06:32 
Hors ligne

Inscription: 27 Mai 2006, 03:09
Messages: 58
Merci Daniel,

je pars donc sur la piste que tu m'indiques. Je n'avais pas fait le calcul du TM total pour la commutation de pages, c'est juste qu'à vue de nez ça paraissait gonflé de faire une commutation à chaque GPL copié ou un truc du genre. Mais avec un moteur efficace ça paraît jouabe.

Je vais me servir des pages 0 et 1 comme 'tampon' pour les animations les plus rapides (personnages) et des pages commutables pour ce qui est plus statique (décors) + états des personnages mis en réserve. On verra bien si j'arrive à quelque chose. C'est vrai qu'avec 256Ko en standard ou 512Ko on est gâtés, il y a de la marge.

Une autre chose: pas de plan sur l'émulation de l'extension MIDI Thomson dans DCMOTO ou tout autre emulateur à tout hasard?

Pendant qu'on y est: joyeux noël à tous! :lol:

Sinus


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 24 Déc 2006, 11:08 
Hors ligne

Inscription: 27 Juin 2006, 19:44
Messages: 1061
Localisation: France (24)
sinus a écrit:
Quelqu'un aurait-il des conseils là-dessus? Ou des lectures à me conseiller?


La méthode qui te coutera le moins, en espace est en temps, est de commuter simultanément la page RAM (source) et l'espace cartouche (destination), puis de transférer tes données. Il suffit de savoir:

- que les deux moitiés de RAM ($A000-$BFFF/$C000-$DFFF) sont inversées quand elles sont "affichées" dans l'espace cartouche ($0000-$3FFF)
- la commutation d'une RAM dans l'espace cartouche nécessite généralement que le bit 5 (page RAM dans espace cartouche) et le bit 6 (écriture possible) soient mis à 1pour $E7E6.
- que l'état de $E7E6 soit restitué avant le retour au système... à moins que la sortie du programme se fasse par un reset, bien sûr ;)

Code:
* Commute espace RAM et cartouche
          LDB      #$02               !  Page RAM source (2)
          STB     $E7E5              !  dans l'espace RAM
          LDB      $E7E6                !  Préserve l'état de
          PSHS    B                       !  l'espace cartouche
          LDB     #$63                !  Page RAM destination (3) dans l'espace cartouche
          STB     $E7E6              !  avec "page RAM" et "écriture" à 1 ($60)
 * Copie les deux pages RAM
          LDX     #$A000           Adresse source
          LDU     #$2000            Adresse destination
          BSR    COPYR             Copie la première moitié de RAM
          LDU     #$0000            Adresse destination (l'adresse source est à $C000)
          BSR    COPYR             Copie la deuxième moitié de RAM
* Restitution de l'état de l'espace cartouche
          PULS   B
          STB     $E7E6
          ....

* Sous-propgramme de copie de RAM
COPYR
         LDY     #$2000/2      Taille à copier
COPYR0
         LDD      ,X++             ! Copie des deux
         STD      ,U++             ! RAMs
         LEAY    -1,Y            !
         BNE      COPYR0      !
         RTS


PS: le code a été écrit à main levée sans être testé. Si il y a un problème... :)


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 24 Déc 2006, 11:17 
Hors ligne

Inscription: 27 Juin 2006, 19:44
Messages: 1061
Localisation: France (24)
sinus a écrit:
Code:
POSSIBILITE 2 : testée = OK:
SYS1       EQU     $E7E7
SYS1CF   EQU     $6081     lecture des valeurs initiales de $E7E7 dans $6081
                LDA     SYS1CF 
                ORA    #$10         met D4 à 1 (écriture autorisée en RAM données)
                STA     SYS1


Je te suggère de faire plutôt:

Code:
                LDA      $6081
                ORA     #$10
                STA      $6081
                STA      $E7E7

... $6081 étant l' "image lisible" de $E7E7, et de laisser dans $6081 une représentation valide de l'état de $E7E7. Autant faire les choses proprement :cool:


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 24 Déc 2006, 19:25 
Hors ligne
M. DCMOTO

Inscription: 06 Juin 2004, 08:23
Messages: 681
Localisation: Provence (France)
sinus a écrit:
pas de plan sur l'émulation de l'extension MIDI Thomson dans DCMOTO ou tout autre emulateur à tout hasard?

Rien dans dcmoto v9.5, diffusé ce soir sur le site officiel. Mais c'est une bonne idée pour les prochaines versions.
Joyeux Noël à tous les thomsonistes :)

Daniel


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 31 Déc 2006, 19:57 
Hors ligne

Inscription: 27 Mai 2006, 03:09
Messages: 58
Prehisto a écrit:
PS: le code a été écrit à main levée sans être testé. Si il y a un problème... :)


C'est très sympa d'avoir pris le temps de le tapoter, en tout cas. Ces précieuses précisions me font changer d'orientation dans la programmation (laborieuse :L ) de mes routines mais mieux vaut ça.

Daniel Coulom a écrit:
Rien dans dcmoto v9.5, diffusé ce soir sur le site officiel.


Merci pour le cadeau de noel Daniel!
Oui, pour faire suite à cette histoire de carte son sur Thomson (discutée dans le forum 'matériel'), le MIDI resterait un moyen sympa de mettre un peu de musique dans tout ça, le convertisseur restant de toutes façons un bon petit canal PCM. Côté quincaillerie je pars dans l'idée de refaire une extension d'après les plans (encore que je cherche MIDI à 14 heures :lol: en cherchant à grouper plusieurs cartes en une sur le principe du mégabus, mais je vais laisser tomber cette idée...).

Par ailleurs, pour le développement, le MIDI sous émulateur c'est vrai que ce serait chouette. J'avoue que moi, sans zic, il y a comme un vide... :oops:

Bon réveillon à tous et bonne année 2007!

Sin.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 01 Jan 2007, 02:34 
Hors ligne

Inscription: 13 Juin 2005, 21:50
Messages: 290
Localisation: Planete Zorg (31)
sinus a écrit:
J'avoue que moi, sans zic, il y a comme un vide... :oops:

Rassure toi, on y travaille. ;)

Peut-être que ce sera l'évènement 2007 :love:

En attendant... Bonne année à tous Image


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

Heures au format UTC + 1 heure


Qui est en ligne

Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 52 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 à:  
Développé par phpBB® Forum Software © phpBB Group
Traduction par phpBB-fr.com