Logicielsmoto.com

Nous sommes le 28 Mar 2024, 17:26

Heures au format UTC + 1 heure




Poster un nouveau sujet Répondre au sujet  [ 168 messages ]  Aller à la page Précédente  1 ... 7, 8, 9, 10, 11, 12  Suivante
Auteur Message
MessagePosté: 04 Jan 2021, 21:03 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Citation:
(...) Il est possible que le système, voyant que la banque courante n'est pas 1, fasse tout un processus de changement (...)
Ca il ne faut pas y compter (pensée magique?).

La doc ne mentionne rien là dessus, et surtout tu remarquera que le moniteur n'offre aucune routine de changement de bank mémoire compatible toutes machines. C'est très dommage, et surtout ca signifie que tu es tout seul pour la commutation des banque. Il n'y a rien d'automatique de la part du moniteur dans ce domaine.

Oublie ce que fais le moniteur autour de $6019 ou $E7DC si tu ne sais pas pourquoi il le fait. Il ne fait qu'executer quelque chose que tu tu as programmé volontairement ou involontairement, et pour savoir où, déroules les RTS jusqu'à tomber dans ton code. En l'état le seul endroit où j'imagine que le moniteur efface $6019 c'est dans la routines d'initalisation du boot. Est-ce que tu sautes par là ? Si oui c'est un truc attendu, sinon c'est une conséquence d'un bug dont il faut remonter à la source.

Citation:
BANK2:clear,&h9FFF,,&H71FF:bank1
Ya un truc tout bizarre là!!!

Déjà les zones &H71FF+1->$DFFF et &H9FFF+1->$DFFF se recouvrent, il ne devrait y avoir qu'un seul des deux, le premier qu'il faut mettre à $71FF
Fichier(s) joint(s):
Untitled.gif
Untitled.gif [ 77.14 Kio | Vu 9497 fois ]


Ensuite, tu alloue la zone $A000->$DFFF de la bank 2, mais ensuite tu repasses en bank1 pour le chargement et l'execution, donc tu charges ton prog en bank1 non réservée. Le basic continue à l'utiliser !!!!!

Si tu a besoin d'utiliser la bank 1, tu dois la réserver, et y rester ou aller dans celles au dessus, mais certainement pas au dessous!
Code:
BANK1:CLEAR,&H71FF
Sauf que bien entendu le basic va peut-être se plaindre de manquer de place. Il faudra alors tout décaler d'une banque.

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 05 Jan 2021, 00:11 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
Je résume

Le Basic en lui même (l'interpréteur) est dans les adresses $0000-3FFF, il lit le code source qui se trouve dans les adresse $A000-$DFFF (et continue éventuellement avec les autres banques)

Quand on fait un CLEAR, le 2ème paramètre sert à réserver un espace entre ADR+1 donné (ADR entre 9FFF et DFFE) et DFFF dans la banque courante ainsi que toutes les adresses des banques suivantes.
Le 4ème paramètre réserve de la mémoire entre ADR2+1 (ADR2 entre 6100 et 9FFE) et 9FFF inclus (zone non commutable (donc il n'y a pas chevauchement dans ce que j'ai écrit!!)

Quand une interruption est exécuté (dans mon code, c'est une zone située entre $7100 et $82FF), au retour de cette interruption, si le programme assembleur principal (main) est terminé, ça va exécuter les lignes BASIC, qui doivent normalement, se trouver en Page Banque 1 ou en Page Banque 2 ?

Tu m'as dit lors d'un message précédent que le code source, script BASIC, en court de lecture se trouvait en A000, que ça commençait en A000. Du coup faire un Clear en Banque 1 (Basic), je l'ai essayé et ça m'a mis un truc du genre "Lack of Memory".

La question est de savoir dans quelle endroit se trouve le script BASIC en RAM... Le problème vient de là, quand on fait un retour d'interruption ça fait du n'importe quoi et j'ai l'impression que c'est lié à ce que j'ai écrit dans la banque 2 en ASS (qui contient l'image vidéo avec les Sprites Bubble
J'ai regardé ce qu'il se passait avec la mise eu point DC Moto, en mettant un point d'interruption au premier changement de E7C6 puis j'ai fait du pas à pas... Ca va jusqu'à la fin du programme LM principal et ça retourne au système (par RTS), et là je suis dans les adresse $0nnn à $3nnn, avec parfois des saut (JRS) qui tombent directement sur un RTS ou un JMP... c'est complètement incohérent.

Une bonne nuit de sommeil pour avoir les idées claire...


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 05 Jan 2021, 00:19 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Citation:
Quand on fait un CLEAR, le 2ème paramètre sert à réserver un espace entre ADR+1 donné (ADR entre 9FFF et DFFE) et DFFF dans la banque courante ainsi que toutes les adresses des banques suivantes.

Non pour la partie en rouge. Relis la partie que j'ai surlignée.. ca réserve la partie non commutable, c'est à dire ce que tu veux avant $9FFF et pas après $9FFF. Le dernier paramètre ne sert que pour réserver dans la partie non commutable et ne touche pas aux banques (le basic a plein de ram dans toutes les banks et toi tu lui en pique juste un peu en partie non commutable). C'est un cas extrêmement rare qu'on utilise que pour des utilitaires au basic (genre ajouter des mots clefs) mais pas pour faire des jeux.

Tu ne sembles pas non plus avoir compris le problème avec le bank 1 qui suit: tu charge ton prog hors des zones que tu as réservées (bank 2 et plus). Le basic te les trash alégrement la bank 1 donc ton programme ASM avec ses données!!!!

Au retour d'interruption tu dois aussi absolument restaurer les banks dans l'état avant que tu ne les bascules car le programme interrompu ne sait pas que l'organisation mémoire a été changée par l'interruption et va écrire dans ce qu'il croit être la zone $A000+ qu'il avait juste avant.

Il ne faut pas chercher les explications ailleurs avant d'avoir *RESOLU* ces 3 points pour l'instant.

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 05 Jan 2021, 01:20 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
Pardon d'insister mais c'est bien le 2ème paramètre de CLEAR est pour les partie de A000 et DFFF et le 4ème c'est pour la zone NONcommutable. J'ai le manuel sous les yeux!!


Dernière édition par Neotenien le 05 Jan 2021, 01:56, édité 1 fois.

Haut
 Profil  
Répondre en citant le message  
MessagePosté: 05 Jan 2021, 01:23 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Non, relis bien l'exemple de la partie surlignée. Regarde bien l'adresse du seul argument: &h8FFF et cela réserve de $9000 à $9FFF et toutes les banques $A000->$DFFF à partir de la banque courante.

Et j'insiste qu'il y a 2 autres problèmes de cohérence (en particulier le fait de charger le binaire en bank 1 quand tu as réservé les banques 2,3,4,5,6,...)

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 05 Jan 2021, 01:45 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
Samuel Devulder a écrit:
Non, la partie surlignée est claire. Regarde bien l'adresse du seul argument: &h8FFF réserve de $9000 à $9FFF et toutes les banques $A000->$DFFF à partir de la banque courante.

Et j'insiste qu'il y a 2 autres problèmes de cohérence (en particulier le fait de charger le binaire en bank 1 quand tu as réservé les banques 2,3,4,5,6,...)


Et qu'est ce qu'il y a d'écrit plus haut ? "Le 2ème paramètre (adresse1) permet de réserver une zone mémoire correspondant aux banques de mémoires commutables", donc je pense pour les adresse A000-DFFF ? C'est vraiment pas clair leurs explications, ça se contredit.

C'est quoi une banque de mémoire commutable et une zone non commutable ? Et pourquoi le 4ème paramètre existe dans ce cas ?

Mon exécutable ASSEMBLEUR est dans la zone non commutable ($7000-9FFF). La ZONE A000-DFFF c'est pour les datas. Ce qui est fou est que le code fonctionne pourtant parfaitement si ce n'est que cet E7C6 est remis à la valeur initiale et quelle que soit les modifications faites jusqu'à présent. YA que quand je ne vide pas les banque 2 et 3 que la vitesse est "rapide".

Donc à priori, je dois faire un

BANK 2:CLEAR,&H7000

Avant de le charger puis de faire un

BANK 1

Et j'exécute le binaire alors

Ca sera bon ?


Dernière édition par Neotenien le 05 Jan 2021, 02:04, édité 1 fois.

Haut
 Profil  
Répondre en citant le message  
MessagePosté: 05 Jan 2021, 02:00 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Neotenien a écrit:
Et qu'est ce qu'il y a d'écrit plus haut ? "Le 2ème paramètre (adresse1) permet de réserver une zone mémoire correspondant aux banques de mémoires commutables", donc je pense pour les adresse A000-DFFF ?
ben oui
Citation:
C'est vraiment pas clair leurs explications, ça se contredit.
ben non.
Citation:
C'est quoi une banque de mémoire commutable
$A000->$DFFF
Citation:
et une zone non commutable ?
$6000->$9FFF
Citation:
Et pourquoi le 4ème paramètre existe dans ce cas ?
je l'ai écrit plus haut. Pour allouer entre $6000 et $9FFF et laisser les banks commutables tranquilles. Il est très rarement utilisé et d'ailleurs n'existe pas en basic 1.

Citation:
Mon exécutable est dans la zone non commutable ($7000-9FFF)

Donc à priori, je dois faire un

CLEAR,,,&H7000

Avant de le charger puis de faire un

bank 2 : clear,&H9FFF

Et j'exécute le binaire alors

Ca sera bon ?
Non. Tu veux pouvoir utiliser $7000->$9FFF et (bank 2,3,4...) $A000->$DFFF, tu fais
Code:
BANK 2:CLEAR,&h6FFF
et c'est tout (oublie le 4e param). Tu ne touche plus à bank en basic, durant l'execution de ton prog tu fais ce que tu veux, mais à la sortie tu fais en sorte de revenir dans la bank 2 que le basic attends.

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 05 Jan 2021, 02:20 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
Samuel Devulder a écrit:
Neotenien a écrit:
Code:
BANK 2:CLEAR,&h6FFF
et c'est tout (oublie le 4e param). Tu ne touche plus à bank en basic, durant l'execution de ton prog tu fais ce que tu veux, mais à la sortie tu fais en sorte de revenir dans la bank 2 que le basic attends.



C'est bon j'ai trouvé la solution au problème...

Puisque tu m'as dit que le basic était en bank2 (Page bank Ram 2 je suppose ? ou 3 ?) et que donc, c'était là où j'ai écrit les images écran, le basic a totalement disparu (et donc c'est un code aléatoire dépendant des écrans), j'ai donc fait une boucle dans le programme principal assembleur jusqu'à une variable d'arret du programme.

Je verrai plus tard pour ces correspondances BANK Basic et Banque RAM assembleur...

Problème résolu.


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 05 Jan 2021, 08:46 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Neotenien a écrit:
C'est bon j'ai trouvé la solution au problème...
Tu as corrigé les point rouges ci-dessus ?
Neotenien a écrit:
Puisque tu m'as dit que le basic était en bank2 (Page bank Ram 2 je suppose ? ou 3 ?)
J'ai rien dit de tel dans le message ci-dessus.
Neotenien a écrit:
Problème résolu.
J'ai pas l'impression que tu as compris le problème et que tu as juste un contournement. "Tomber en marche" n'est pas avoir résolu un problème je pense. Enfin c'est toi qui vois. J'ai donné assez d'infos ci-dessus.

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 05 Jan 2021, 10:25 
Hors ligne

Inscription: 13 Juin 2005, 21:50
Messages: 290
Localisation: Planete Zorg (31)
Il y a un truc que je ne pige pas.

Pourquoi utiliser le TIMER pour te synchroniser? La VBL fait parfaitement l'affaire. Non!?


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 05 Jan 2021, 15:57 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
Samuel Devulder a écrit:
Neotenien a écrit:
C'est bon j'ai trouvé la solution au problème...
Tu as corrigé les point rouges ci-dessus ?
Neotenien a écrit:
Puisque tu m'as dit que le basic était en bank2 (Page bank Ram 2 je suppose ? ou 3 ?)
J'ai rien dit de tel dans le message ci-dessus.
Neotenien a écrit:
Problème résolu.
J'ai pas l'impression que tu as compris le problème et que tu as juste un contournement. "Tomber en marche" n'est pas avoir résolu un problème je pense. Enfin c'est toi qui vois. J'ai donné assez d'infos ci-dessus.


Je ne suis pas stupide!!

J'ai trouvé pourquoi yavé des écritures aléatoire, c'était un retour d'interruption sur une page "basic" dans une banque RAM. J'ai donc bouclé la routine assembleur principale... J'ai tout expliqué dans mon message précédent.

Et si le script Basic se fout dans la page banque 2 celle qui sert pour affichage écran, on considère que le retour à ce basic est impossible et à la fin du jeu, je ferai simplement un reboot à chaud.

ADNZ en avait parlé également, on doit tout faire en assembleur. Le jeu "Mission LiftOff" ne retourne pas au basic, il tourne en Boucle. Et d'ailleurs, à ma connaissance, aucun jeu en Assembleur 100% ne retourne au BASIC, on doit rebooter de manière hardware.

Le problème est résolu.


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 05 Jan 2021, 16:06 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
jasz a écrit:
Il y a un truc que je ne pige pas.

Pourquoi utiliser le TIMER pour te synchroniser? La VBL fait parfaitement l'affaire. Non!?


On est sur Thomson ici pas sur Atari ST.

Soit on calcule les cycles d'horloge au cycle près pour synchroniser les actions (dans la limite du possible), soit, pour les TO, on utilise la routine en ROM permettant les interruptions matérielles (du 6809E) avec le timer. Et on a juste qu'à paramétrer la durée du timer en insérant un nombre à 16 bits en $E7C6. ça indique le nombre de 8 cycles d'horloge avant interruption. Ainsi si E7C6 contient 6249, on aura 6249x8 cycles d'horloge (à une fréquence d'1 MHz, donc une interruption toutes les 1/20 s). Si on le met à 2499, ça sera 1 fois toutes les 1/50s

Le Thomson n'a aucune puce DMA pour gérer les écrans!! Même si l'affichage se fait en parallèle aux travaux du 6809, le 6809 doit quand même gérer tous les périphériques lui même (même s'il y a des circuit comme les PIA, ceux ci n'ont pas de DMA, pas de routines de traitement etc).


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 05 Jan 2021, 22:31 
Hors ligne

Inscription: 13 Juin 2005, 21:50
Messages: 290
Localisation: Planete Zorg (31)
Je connais bien l'Atari ST et je fais nullement allusion à ce dernier.

Et puis que vient faire la DMA ici? :eek:

Je parle de la VBL au cas ou tu l'aurais oublié. Et cette dernière est bien présente sur un Thomson et sans que tu le saches, elle sert à quelques trucs comme le clignotement du curseur ou le crayon optique entre autres.

Le spot, une fois arrivé à la fin de l'écran, déclenche une information au registre $E7E7 (si je me souviens bien) qu'il actualise une fois revenu au début de l'écran; c'est la VBL... Quoiqu'il en soit, tu ne pourras pas aller plus vite que la vitesse de rafraichissement de l'écran pour l'affichage.


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 06 Jan 2021, 23:20 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Neotenien a écrit:
Je ne suis pas stupide!!

J'ai trouvé pourquoi yavé des écritures aléatoire, c'était un retour d'interruption sur une page "basic" dans une banque RAM. J'ai donc bouclé la routine assembleur principale... J'ai tout expliqué dans mon message précédent.

C'est juste pas ça :non: . J'insiste.. Tu te réserves toutes les RAM $A000->$DFFF depuis la banque basic n°2, mais charge et execute tout avec la banque basic n°1 active. Ya rien qui te choque là ? D'ailleurs as tu besoin de réserver 13 * 16 = 208 Ko de ram ? C'est quand même énorme.
Citation:
Et si le script Basic se fout dans la page banque 2 celle qui sert pour affichage écran, on considère que le retour à ce basic est impossible et à la fin du jeu, je ferai simplement un reboot à chaud.
Le basic se mets dans les banques que tu lui laisse libre à savoir la banque système n°0 (de $6000->$7xxx que tu lui laisse) et les banques basic n°0 et n°1.. Oui la banque n°1, celle qui est présente quand tu lances ton prog et celle que utilise comme écran (ram système n°2). Note aussi que comme je te l'ai indiqué à plusieurs reprises au début que tu te lançais dans le projet, le basic ne numérote pas les banque par les numéros systèmes. Il y a un décalage de 1 parce que ce que le basic appelle bank c'est la zone commutable de $A000 à $DFFF, pas la banque de ram physique.
Citation:
ADNZ en avait parlé également, on doit tout faire en assembleur.

C'est pas forcé. Ca dépend de ce qu'on veut faire, et de comment on le fait. Tu peux parfaitement déplacer le contenu de la bank système 2 (que tu va utiliser comme écran) dans la banque 15 pendant que ton programme tourne, et restaurer le système dans son état d'origine à la sortie de ton programme. C'est toi qui choisis.
Citation:
Le jeu "Mission LiftOff" ne retourne pas au basic, il tourne en Boucle.

Il utilise *toute* la ram (sans les 31 pages, point d'animation d'intro par exemple). Donc le basic est dégagé pour libérer un max de place
Citation:
Et d'ailleurs, à ma connaissance, aucun jeu en Assembleur 100% ne retourne au BASIC, on doit rebooter de manière hardware.

Si le jeu est en ASM 100%, il se charge même sans utiliser le basic : il est autboot. Donc pour sortir du jeu tu reviens au niveau du menu par le bouton reset de la machine comme cela se faisait à l'époque. Tous les jeux ST/Amiga/CPC/Spectrum font ainsi. C'est pas une surprise.

Par contre sur Thomson ya pas mal de jeux qui sont un mix ASM et BASIC et cela cohabite très bien. Je me souviens particulièrement bien de Coliseum, et de, plus récent, la secte noire à laquelle j'ai participé.
Citation:
Le problème est résolu.
Si tu le dis, mais pour moi tes explications ne sont pas claires dans la mesure où tu ne dis pas si tu as compris les points en rouges plus haut. Mais une chose est sure, en restant dans l'ASM c'est à dire dans un environnement que tu contrôles à 100%, si ca bug, c'est que ca vient de toi et pas de d'un codage ne permettant pas la cohabitation avec le système sous-jacent. Par contre il faudra tout faire à la main, les initialisations de l'extramon, du dos-disk, la gestion de la pile, etc. En particulier il faudra que tu fasses toi-même le chargement du binaire depuis le disk dans les bank mémoire. C'est pas mal de boulot, mais c'est passionnant, et c'est bien ca qui compte au final.

_________________
Good morning, that's a nice Tnetennba


Dernière édition par Samuel Devulder le 06 Jan 2021, 23:37, édité 1 fois.

Haut
 Profil  
Répondre en citant le message  
MessagePosté: 07 Jan 2021, 00:42 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
Pour info (encore une fois)

Au reset du TO8, c'est l'espace physique 2 qui est alloué à l'espace ram DONNEES ($A000-DFFF), puisque pour le double buffer, les allocations de l'espace vidéo sont seulement entre les banques physique 0 à 3, que le 1 est réservé à l'espace $6000-$9000 (espace dans lequel se trouve mon programme assembleur entre $7000 et $8500), que j'ai choisi de travailler avec les banques physique 2 et 3 pour l'alternance de Vidéo Ram (même si j'aurais pu choisir 0 et 3 ce qui aurait laissé l'espace physique 2 de libre), ce qui, fatalement, écrase le script BASIC se trouvant en espace physique 2... On ne peut donc pas revenir à ce BASIC qui a été écrasé COMPLETEMENT par le traitement data servant à l'affichage écran.

On a déjà parlé de ça avant..

La seule solution serait de travailler avec en RAM vidéo sur les banque 0 et 3 placé alternativement dans l'espace RAM data... Puisque la BANK la plus basse du BASIC correspond à la banque physique 2 (cf page 124 du Manuel Technique des TO8), à la rigueur cette solution est envisageable, mais ça risque d'être compliqué pour travailler en mode double buffer puisqu'il me faut 3 espaces de 16 kO!! (Un pour l'image de fond et 2 pour alterner l'affichage du mode vidéo pour éviter l'effet de scintillement des sprites et les effets qu'on voit sur les machines concurrente, même la dernière version sur Amstrad de Bubble Bobble). Donc je suis obligé d'avoir les 3 banques physiques 0, 2 et 3 à travailler comme data et donc le basic à oublier. Pour le PacMan d'ADNZ, il est envisageable de ne travailler que sur 2 espaces de 16kO (sans double buffer juste en alternant les affichages et ne pas avoir d'effet scintillement) mais pas avec Bubble Bobble.

Et je ne veux pas utiliser l'espace cartouche (pour une autre banque >3), parce qu'il y a les routines en ROM bien utiles (comme la fonction Random...Ou alors en alternant l'allocation d'espace cartouche... Entre la ROM (pour le calcul des positions des ennemis avec RND) et un espace buffer ou autre... Sans parler de tous les Sprites (j'ai pas compter mais ça doit bien dépasser les 100, à raison d'au moins 16 par personnages), les niveaux de tableaux (100 tableaux avec plus de 600 octets par tableau soit, au moins 64 kO, soit 4 banques de RAM physique), les paramètres audio... Ca prend de la place tout ça.


Dernière édition par Neotenien le 07 Jan 2021, 16:43, édité 1 fois.

Haut
 Profil  
Répondre en citant le message  
Afficher les messages postés depuis:  Trier par  
Poster un nouveau sujet Répondre au sujet  [ 168 messages ]  Aller à la page Précédente  1 ... 7, 8, 9, 10, 11, 12  Suivante

Heures au format UTC + 1 heure


Qui est en ligne

Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 36 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