TO8 buffer video ?

[p0ke]

Bonjour,

J'essaye de comprendre les modes video du TO8. Est-ce que j'ai mal compris ou il est possible de de "swaper" des buffers videos ?
(soyez indulgents !)

merci

[Fool-DupleX]

Tu as bien compris. Il est possible de choisir parmi 4 emplacements dans la RAM où mapper la vidéo, ce qui de facto permet de swapper. Valable sur TO8/8D/9+, MO6 et MO5NR.

[Daniel]

Le principal intérêt est de permettre de préparer un ou plusieurs écrans en RAM et de basculer instantanément de l'un à l'autre en modifiant un seul octet.

[__sam__]

J'essaye de comprendre les modes video du TO8. Est-ce que j'ai mal compris ou il est possible de de "swaper" des buffers videos ?

C'est pas vraiment des buffers vidéos mais des pages de RAM banalisées que l'automate d'affichage peut ... afficher envoyer vers l'écran. Il y a cependant des limites:

• l'automate ne sait accéder qu'aux 4 premières pages de 16ko de RAM physiques alors qu'on peut utiliser les 32 pages depuis le CPU.
• La page 0 c'est celle qui est toujours mappée en $4000-$5FFF (x2). L'afficher revient à utiliser la zone $4000-$5FFF(x2) comme RAM vidéo. C'est le mode standard classique. Ca n'apporte rien.
• La page 1 est toujours mappée en $6000-$9FFF et est utilisée par le système (pile, registres moniteur/extramon etc).

On ne peut donc rien afficher d'intéressant avec les deux premières pages physiques.

Restent les pages physiques 2 et 3 qu'on peut mapper sur l'espace cartouche ($0000-$3FFF) ou l'espace RAM utilisateur ($A000-$DFFF) pour que le processeur y ait accès.

Typiquement on demande à l'automate d'afficher la page 2 et on map la page 3 en espace cartouche ($0000-$3FFF). On dessine alors les sprites dans cet espace, mais on ne voit rien à l'écran (qui affiche la page physique 2). Une fois le dessin fini, on attends la VBL et on demande à l'automate d'afficher la page 3 qui vient d'être préparée. L'image apparait ainsi d'un coup en une fois sans clignotement, puis on map la page 2 anciennement affichée à son tour dans l'espace cartouche pour que le CPU puisse y dessiner une nouvelle image, etc. Ainsi on ne voit pas l'image et les sprites s'afficher à l'écran car l'automate affiche l'autre page, puis on inverse. C'est du double buffering.

[p0ke]

Ah voilà je m'y retrouve un peu mieux, c'est donc du passage suivant qu'il s'agit dans la doc.

- La page affichee par l'automate peut être en même temps affectee a
l'espace "donnees", voir a l'espace "cartouche". De par le principe
enonce, si on veut par exemple afficher la page 2, dans laquelle le
CPU puisse faire une mise a jour, il faudra necessairement affecter la
page 2 a l'espace RAM "donnees" qui sera consideree alors comme la
nouvelle memoire ecran; et demander a l'automate d'afficher la page 2,
en programmant les bits D7 D6 en E7DD respectivement a 1 et 0.

Donc ça veut dire qu'on peut écrire en 0000-3FFF ? (je croyais que c'était rom only ?)

[__sam__]

Non. Contrairement aux machines précédentes, il n'y a pas que l'espace "RAM-utilisateur" ($A000-$DFFF) sur lequel on peut faire du bank-switch. On peut en effet recouvrir l'espace cartouche ($0000-$3FFF) par l'une des 16/32 banques mémoire physique du TO8. On peut même, et c'est un cas particulier pour l'espace cartouche, mettre cette zone en read-only ce qui permet d'émuler très exactement une cartouche ROM avec une banque mémoire.

[p0ke]

woaaaaaa top,
merci pour les explications.

En pratique on fait le setup comme ça alors ?

J'active le bit d4 de E7E7 et que je mets la page que je veux en E7E5
(par exemple l'espace cartouche "2") ce sera ça que le gatearray va afficher à l'écran ?

[__sam__]

Heu non pas exactement. Le PIA système ne s'occupe que du mapping mémoire pour le CPU. L'automate d'affichage est à une autre adresse.

Si tu fais ce que tu dis tu ne fais que mapper l'une des pages physique en $A000 (et en activant le bit 6, et en utilisant $E7E6 tu mapperait une (autre) page physique en espace cartouche $0000). Cependant l'automate d'affichage n'est pas concerné par ces registres du PIA système qui sont juste "pour le cpu". L'automate d'affichage récupère le numéro de page dans les bits 6 à 7 de $E7DD (les bits 0 à 3 servent à définir la couleur du tour écran, les autres ne concernent que le MO5).

A savoir aussi: $E7E7 est write only, mais il y a une copie en $6081 (si j'ai bonne mémoire). Donc quand on met à jour un bit, ne pas oublier de mettre à jour la copie logicielle en $6081.

[Fool-DupleX]

Non. Contrairement aux machines précédentes ...

A noter que ce mécanisme est parfaitement valable aussi sur MO6 et MO5NR, avec l'espace cartouche entre $B000 et $EFFF.

[p0ke]

Et est-ce que cette façon de travailler est compatible avec tous les modes vidéos ? Je vois que les pages écrans sont diviées en deux à chaque fois, ramA et ramB dans la doc, est-ce que ça veut dire qu'on est limité à une contrainte de deux couleurs par GPL comme pour le TO7/70 & MO5 ?

[__sam__]

Ben tous les modes vidéos occupent 2x8ko = 16ko. Donc oui ca marche avec tous les modes écrans. La "ramA" (anciennement forme) sera accessible dans la 1ere tranche de 8ko de la page physique, la "ramB" (anciennement couleur) dans l'autre tranche de 8ko. Avantage: pas besoin de tripatouiller le bit 0 de $E7C3 pour passer de ramA à ramB. Mais par contre c'est pas contigüe: en BM16 tu auras accès aux deux premiers pixels à une adresse, et les deux pixels suivants seront non pas à l'octet d'après, mais 8ko plus loin. Ca complique un peu le codage. Autre complication : l'ordre ramA/ramB est inversé suivant qu'on mappe dans l'espace cartouche ou l'espace ram-utilisateur.

[p0ke]

Bon je dirais ça à la limite c'est pas la mort, sur atari il y a 4 plans je crois pour faire RVB+transparence je crois, ça complique un peu.
le switch de buffer était plus simple il me semble, il fallait juste spécifier l'adresse à laquelle se trouvait l'écran ? (ça remonte je ne suis plus trop sur).

Sinon j'ai trouvé un vieux post ici : http://www.logicielsmoto.com/phpBB/view ... ?f=3&t=648.
Je vais farfouiller sur le forum parceque je ne comprends pas trop les modes vidéos sur TO8 (BM16 tout ça je ne vois pas trop à quoi ça correspond).

[__sam__]

BM16 = 160x200 en 16 couleurs sans contraintes.

Tous les modes sont décrits dans le manuel technique des TO8/TO9/TO9+. Ca vaut le coup d'y jeter un coup d'oeil aussi.

[p0ke]

Oui, je crois que c'est celui la que je lis, (une version web que tu as recopié et annoté non ?)
C'est que malheureusement je ne me pose pas les questions dans le même sens que le sommaire de l'ouvrage.
(pourtant je l'ai lu/survolé plusieurs fois mais il me faut un peu de temps pour comprendre et assimiler certaines choses) !

[__sam__]

Ce bouquin c'est comme la bible: on peut le lire 3 ou 4 fois, et ne pas encore tout comprendre Même les érudits s'y perdent

Après un truc bien pour comprendre: tester par soi même (sur émulateur: c'est plus facile).