Logicielsmoto.com

Non c'est pas comme ca que ca marche pour E7DD. C'est pas la zone $4000-5FFF qui est modifié. Celle là pointe toujours sur la banque physique fixe. $E7DD lui permet de modifier la bank physique que l'on va afficher. Si c'est 0 on affiche $4000-$5FFF, si c'est 1 on affiche la bank 1, 2 la bank 2, et 3 la bank 3. Ces bank là ne sont pas accessibles en $4000-5FFF. Il faut les mapper dans l'espace RAM en $A000-DFFF ou l'espace ROM en $0000-3FFF.

Ainsi un usage typique de l'organisation mémoire dans un jeu/démo est un truc comme ca:

_________________
Good morning, that's a nice Tnetennba

Oui je me suis mal exprimé! Je voulais dire que l'affichage utilisait effectivelet les banques 0 à 3


Usage typique... mais


Euh, 0, 2 ou 3 plutôt non ? (Manuel technique des TO8 p 120 et 121).
Et en vérité, on peut y mettre n'importe laquelle des banques


Ceci est sensé être l'espace écran!! (Affichage banque 0 à 3 sauf le 1)!! Il n'est accessible en écriture que pour la banque 0 (compatibilité TO7). C'est à dire que quand on travaille sur cet espace, ça n'agira que sur la banque 0.



C'est là que je ne pige pas!!
Il est écrit dans le manuel technique:
«
-Si le CPU veut accéder aux pages 2 et 3 en les considérant comme des écrans, il doit les affecter à son espace 'RAM données' (ie espace A000-DFFF) afin de pouvoir les lire ou les écrire. Dans ce cas, on doit considérer que la mémoire RAMA (point) se trouve aux adresses hautes de la page (ie C000-DFFF), tandis que les adresses basses contiennent les informations RAMB (couleur); en effet, le bit forme traditionnel est inopérant dans l'espace 'données'
»
Page 121 des manuels techniques du TO8.

D'ailleurs, dans le code complet que j'ai mis plus haut, il y a bien une animation sur l'un des 2 espaces travaillés en RAM Données (je ne sais pas si c'est la bank 2 ou 3... en fait la banque 3 n'affiche rien).

Le mieux est sans doute que je mette une vidéo montrant ce qu'il se passe avec mon code... la voici

En fait ion peu mettre n'importe quelle bank RAM (0 à 31), mais les banques qui sont aussi utilisables en affichage (0 à 3) permettent d'accéder à la fois à la partie forme et fond sans passer par $E7C3. Afficher la banque utilisée en $4000 (bank/page 1) a peut d’intérêt car elle est toujours accessible pas loin, donc il n'y a pas un grand intérêt.

Aussi faire attention de lever le bit indiquant qu'on veut pouvoir écrire dans l'espace ROM, sinon ca marche moins bien.


Non $4000-$5FFF contient toujours la même banque physiques, la 1.. En fait la même moitié (8ko). L'autre moitié se trouve aux mêmes adresses en jouant sur le bit 0 de $E7C3.


Oui quel est le problème? Tu peux mettre les banks 2 ou 3 en $A000 (ou $0000), et aussi demander à l'automate d'affichage de les afficher. Il n'affiche pas $A000, mais les bank/pages physiques 2 ou 3 mappées à cette adresse là aussi: le CPU et l'automate d'affichage ont tous les deux accès aux même banques/pages physique.. A noter: que même si le CPU n'a pas mappé 2 ou 3 dans son espace mémoire et n'y a plus accès, l'automate continue d'afficher leur contenu dorénavant non modifiable par le CPU.

Cela permet d'avoir carrément une zone continue de RAM entre $0000 et $DFFF (56Ko) avec une organisation comme celle-ci: affichage bank 2 ou 3, bank N en espace rom: $0000->$3FFF, ancienne ram vidéo (page 0) qui n'est plus affichée et que l'on peut utiliser à loisir entre $4000->$5FFF (+ 8ko de ram cpu bonus à cette adresse via $E7C3), la ram système non commutable $6000->$9FFFF (page 1) et enfin la bank M de son choix (si possible différente des autres utilisées) en $A000->$DFFF. Le cpu dispose alors de la zone $0000->$DFFF d'un bloc pour faire ce qu'il veut sans perturber l'affichage qui lui utilise la bank 2 ou 3 comme demandé. Pas mal comme astuce pour avoir le max de ram, non ? Par contre ca n'est utile qu'en ASM bien entendu.

_________________
Good morning, that's a nice Tnetennba

Samuel on est d'accord sur à peu près tout à part que la banque RAM physique utilisée pour la zone logique 4000-5FFF est BIEN la 0 et pas la 1 (c'est écrit à de multiples reprises dans le manuel technique des TO8), la banque 1 sert pour la zone 6000-9fff.

Le problème n'est pas là, j'ai rajouté une vidéo sur mon post précédent pour voir ce qu'il se passe, la version "sans gate array" et celle "avec gate array" (code perso qui respecte scrupuleusement ce qui est écrit dans le manuel technique).

1/ La page RAM 2 semble défiler normalement pour l'animation pour les positions "paires" du sprite mais avec les mauvaises couleurs et le mauvais sprite (sans doute une mauvaise allocation de RAM pour les sprites et tiles)
2/ La page RAM 3 n'affiche AUCUNE animation (alors que pourtant ça utilise le même algorithme)

Faut-il vider chaque banque RAM avant d'y travailler en RAM écran ? (voir banque 2 et 3 qui ont des trucs bizarres affichés)

Purée j'ai hâte que tout ceci fonctionne. Alors le tryc chiant avec le gate array est que ça suppose un couple de coordonnées pour chaque sprite (celui de RAM 2 et RAM 3). Mais bo c'est nécessaire pour le jeu Double Bubble pour que les sprites qui se croisent n'effacent pas ceux du dessous (comme c'est le cas de nombreuses version, comme celle de la NES, de ZX Spectrum).

Arf oui en $4000 c'est bien la bank 0... faut que change de lunettes (il faut dire que c'est super mal écrit sur le DJVu en plus -- oh l'excuse! )

Au final 0 et 1 sont bloqués. Il ne reste que 2 & 3 pour faire du double-buffer.

Par contre les banques ram 2, 3, etc... contiennent le programme et les données du basic ($A000 de la bank-0-du-basic pointe sur la bank 2, celle de "bank 1" en basic sur la 3.. le fameux décalage dont je parlais). La zone horizontale en haut de l'écran est ton source basic (qui se situe bank-basic-0=bank-physique-2) qui est affiché! Tu peux t'amuser à ajouter plein de lignes au programme basic pour voir cette zone agrandir.

C'est pour ca que je disais ca ne marche bien qu'en ASM. Le basic utilise lui aussi les banks 2, 3 pour son compte. Je n'ai pas connaissance d'un moyen pour mettre source à partir des bank physiques 4 ou plus (c'est l'inverse d'un CLEAR qu'il faudrait).

_________________
Good morning, that's a nice Tnetennba

Ah mince je me suis planté sur ce que je croyais être la zone du BASIC... Je pensais que ça commençait vers $6100 ? Ben du coup on met quoi dans la zone système ? ($6100-9FFF) ? Moi j'y ai mis des sprites (qu'on peut copier d'une banque RAM >=2 ?) et du code binaire (ça me parait difficile de mettre de l'ASM dans une RAM DATA vu qu'on peut les changer)

Bon alors, ce que je vais faire est:
- Vider en ASM la banque 2 et 3 (et du coup utiliser les fameux puls peut-être ?)
- Voir pourquoi ça n'affiche pas les bons sprites tiles en bank ram 2
- Voir pourquoi ça n'affiche rien en banque ram 3

Le code que j'ai créé pour le changement de RALM vidéo est celui ci


Oui en effet il faudrait un CLEAR inversé. Bon, ça suppose que je vide (en mettant du noir), les banques 2 et 3

Pour ce qui est du manuel technique, j'ai la chance de le posséder en format papier, il est plutôt très bien foutu même s'il y a des aspect électronique que je ne pige pas toujours.

Oui mais 32kO bouffé par le buffer d'écran (16kO) de fond ET l'écran (16kO) sur lequel on travaille à un instant T, sans compter qu'il y a le code assembleur... Même si le 6809 a de nombreuses instructions qui permettent de réduire sensiblement la taille du code/ 6502 ou ZX 81 ou même 6800 (comme la fonction mul au lieu de faire n fois une addition sur un seul accumulateur). Et ça peut vite être réduit par des zones de sprites, des tableaux diverses (que les instruction indexés du 6809 permettent grandement de manipuler aisément). Mais pour ce qui est des pile, fat être hyper prudent avec ça pour ne pas dépasser sur des zones "utiles" au logiciel. C'est d'ailleurs un peu aussi le risque avec le langage C d'ailleurs. Mais bon les malloc() et free() sont là... mais on ne sait pas trop où.

Le basic utilise aussi les zones $6100->$9FFF. Ce que je dis c'est que le source en mémoire débute en $a000, avant en on va trouver dans la zone système, en vrac: les pages de l'extra-moniteur, les buffers d'entrée sortie disk, les données internes à l'interpréteur basic, les variables et tableaux du programme, les chaines de caractères, la pile, etc.. Il peut aussi mettre certaines de ces données ailleurs. Bref: il fait un peu ce qu'il veut si on ne réserve pas les zones avec CLEAR.

J'avais aussi le manuel technique au format papier, mais je l'ai prêté dans une autre vie pour numérisation. Je n'ai jamais pu le récupéré. Tant pis, c'est le destin.
Attention, l'écran c'est 2x8ko = 16ko au total. Mais tu parles peut-être du cas avec double buffer, auquel cas oui ca mange 2x16k. Cependant à chaque instant il n'y a qu'un seul de ces buffers dans la zone adressable par le CPU.

_________________
Good morning, that's a nice Tnetennba

Eh non on utilise bien les 32 kO puisqu'il faut faire un transfert de mémoire, dans la RAM logique... SI on a le buffer dans l'espace cartouche qu'on le transfère à partir de l'adresse A000 (T0)

Par contre, je me demande comment sont ajoutés de grands espaces comme dans les jeux "prohibition", "Bob Morane Science Fiction", "Avenger". Pour ce qui est de Slap Fight 1 et 2, ça doit utiliser un Map Data.

En général les jeux ne travaillent pas sur des bitmap, mais sur des tuiles. L'espace de jeu est alors un tableau d'entiers contenant le numéro de tuile à afficher à tel ou tel endroit. Les jeux à scrolls "par tuiles complètes" sont juste un décalade dans le tableau d'entier, et les scrolls par fraction de tuile utilisent une rangée de tuile caché dans le coté qui doit apparaitre et font un scroll physique du bitmap pour faire apparaitre progressivement cette rangée cachée. Le mix scroll physique sur un bitmap + tuiles ne nécessite de recréer la rangée de tuile cachées que lorsque l'ancienne a été totalement démasquée, c'est à dire pas très souvent. C'est donc très efficace si le scroll physique peut être fait en hardware ou en soft rapide.

_________________
Good morning, that's a nice Tnetennba

Après quelques mois de réflexion, je reprend...


J'avoue que c'est brillantissime!!
Et je suis honteux de ne pas avoir trouvé ça moi même, et c'est plutôt embêtant, si j'inclue ce code dans le jeu Bubble Bobble, je serai obligé de te mettre en auteur principal, tu fais tout à ma place!! Je voulais vraiment pondre un jeu moi même de A à Z... Y compris les optim algorithmique... Cependant, cette optimisation est partie de tests avec des NOT et AND que j'avais écrit au départ en BASIC... C'est fou ce que tu as tout optimisé...
Là on passe de 32-39 cycles de transparence (mon code) pour 2 pxl à 33 (j'enlève la dernière ligne, puisque je ne l'ai pas compté dans la partie "transparence" pour le calcul de mon algo, on ne parle ici que de la partie purement "transparence") pour 4 pxl. Autrement dit tu a divisé par 2 le temps d'exécution sur cette partie!

Le hic est que ça demande que le sprite fasse au moins 8 pxl de large (RAMA et RAMB) pour ce qui est des sprites genre missiles ou même des petites balles...
Nous donne tu l'autorisation d'utiliser cet algorithme ?


Mon code d'origine, sans les masques, faisait entre 29 et 35 pour 2 pxl (si on utilise les accès RAM en mode direct).
Par contre je ne vais pas choisir ce code là, d'une part parce que c'est moins optimal, de plus, j'utilise le gate array pour 'laffichjage (et pas le E7C3, sauf pour ce qui va servir de tampon d'image de fond,, finalement, c'est l'espace $4000-$5FFF que j'utilise pour ceci
Vu que je n'ai pas envie d'utiliser l'espace cartouche afin d'accéder aux routine du moniteurs et extramoniteurs, et je crains que le changement dans l'espace cartouche ne permette plus d'y accéder ?

Ya pas de soucis, les algos donnés ici le sont pour être utilisés. En plus je ne donne que les principes, pas l'implémentation finale qui peut évoluer suivant tes besoins.

_________________
Good morning, that's a nice Tnetennba

Ok

Je pense que je vais les utiliser, si ça double la vitesse! J'en ai vraiment besoin pour Buble Bubble qui et avoir 7 Sprites + les Bulles en transparences (je pense que je vais les limiter à 10), si le Thomson peut gérer 20 Sprites en 8x16 en 10 img/s, ça sera déjà pas mal! J'ai regardé les vidéos Bubble Bobble des autres ordis (que j'avais mis en lien précédemment), l'Atari ST lui même ne dépasse pas les 12img/s et le C64 doit en être à 12, en ralentissant la vidéo Youtube à 0.25 vitesse réelle).

En tous cas, tu es d'une aide vraiment précieuse et on sent les années d'expérience derrière toi! La technique de mettre le timer à 2kHz pour l'audio, ça va être génial pour la musique de fond... Je regarde en ce moment un bouquin sur le Traitement Numérique du Signal, et j'essaie de piger comment des nombres (sur 6 bits Thomson) peuvent former les bonnes ondes... Si je ne pige pas ça je ne pourrai pas faire une musique de fond... Ca et puis tes algos musical sur Bubble Bobble.

Apparemment un y aurait une sorte de filtre qui adapte (si on s'en réfère à la théorie de Shannon sur l'échantillonnage, Fech>2Fmax, on peut avoir un Fmax de 1000 et dans ce cas, le Fech peut être de 2100 et donc, pas aux pic (ou aux 0) du signal et reproduire.

Je voulais avoir quelques explications sur ce code
- Pourquoi on démarre U à TABU+128 et pas à TABU+255 ?
- BIT semble faire un ET logique en mettant Z du CC à 1 si le résultat est nul, pour le premier BITA, ça signifie que tous les nombres dont le byte de poids faible sera supérieur à 0 subira un "ORB #$OF" et pour le 2ème cas, c'est tous les nombres dont le poids fort est supérieur à 0, c'est pas ce que je voulais... C'est avec la couleur 15 pas le 0. Simplement parce que le noir ne peut pas être une couleur transparente.
- BNE *+4 ?? L'astérix ,n'est-il pas un commentaire ? A moins que suivi d'une opération ça indique qu'il faille aller 4 octet plus loin ? * serait-il alors le Compter de Programme dans ce cas ?
- Le dernier BNE ? BNE n'oriente que si l'opération précédente est différent de 0, on fait INCA tout le temps, ça signifie qu'après 255, A redevient 0 ?

Parce qu'on utilise un index 8bit signé. Dans la boucle A va de 0 à 255, mais en signé 8 bits A balaie -128..+127 (pas dans le même ordre, mais on s'en fiche), et donc avec U=TABU+128, l'adresse "A,U" balaie TABU...TABU+255: on parcours tout le tableau.Tout cet algorithme repose sur l'usage de 0 comme couleur transparente (c'est ce qui fait gagner plein de cycles.)Il suffit d'inverser les couleurs 0 et 15 dans la palette. Ca ne pose pas de problème sur TO8. Le noir sera en position 15 et ne sera pas transparent. On peut même imaginer une routine qui fasse cela en précalcul sur les images des sprites en ram une seule fois en début de programme si on ne peut modifier le dessin des sprites à la main avec un éditeur externe.Oui dans l'expression c'est l'adresse où ira l'instruction en cours d'assemblage.Oui INCA fait du débordement. Le successeur de 255 c'est 0. Ainsi la boucle fait bien 256 tours, et toutes les valeurs machin-signé-8bits,U sont remplies sans trou.

_________________
Good morning, that's a nice Tnetennba