Inscription : 12 Juin 2008, 20:29 Message(s) : 1726
Hello,
voilà, je me demandai, si cela était possible de faire un scrolling hardware en double buffer en overscan.
Je m'explique :
2 x &4000 pour la première partie de l'écran en overscan 2 x &4000 pour la deuxième partie de l'écran en overscan
par exemple : &0000 - &4000 pour le 1er &8000 - &c000 pour le 2ième
la problématique réside que si on fait cela, même sans le système, on ne peut pas écrire en &038 et &039 (interruption en &38 avec au moins EI RET pour que ça marche). Hors, si je fais un scroll hard (double buffer), je vais écrire surement à cet endroit...ou même cela se verra à l'écran (deux octets non couleur du fond).
de plus, je pense que le code devra être en bank mémoire avec des jumps...avec un minimum de code en mémoire &0000-&ffff pour les permutations... sans parler de la pile qu'il faudra bien faire pointer quelque part (donc pas de call ou push et pop quand on est en mémoire &0000-&ffff hors des banks ?) je pense qu'on doit avoir un peu de place entre les lignes de datas pour les écrans (mais de combien avec un écran large de 96 octets par exemple ?)
Voilà, si vous avez des retours, car j'aimerai savoir si c'est possible sur cpc !?
C'est parfaitement possible de mettre a 0 TOUTE la mémoire (les 64Kb) et donc effectuer un scroll hard 32Kb page-flippé.
Pour &38, ta réponse est : soit tu executes tout ton code avec un DI (pas tres glop, depent du contexte) soit tu regardes autour de IM 2, qui te permet déplacer le saut en &38. Quant au reste, il te faudra utiliser les banks C1, C2 et C3 .. pour placer ton code + pile...
Mais j'ai jamais mis en pratique, et je ne suis clairement pas un expert là-dedans.. Longshot, si tu nous lis ?
Je pense que ce doit être possible en utilisant les 64ko de ram en video + le mode im2... Je suis certain d'avoir déjà vu ça dans une des nombreuses preview s d'over le fou....
Tu balances le code dans les 64ko supplémentaires...
Inscription : 28 Août 2008, 23:41 Message(s) : 270
@megachur Tu n'as pas besoin d'utiliser 4 banques pour afficher 2 images overscan mais 3. Donc les problèmes que tu indiques ne se posent pas. Cela implique une rupture, mais si tu veux faire un scrolling crtc, cela s'imposera
Mais si tu utilisais toute la ram en vidéo, il faudrait bien que ton code soit en banque, donc il te reste les solutions indiquées par norecess: Déplacer l'adresse d'interruption avec le mode IM2 (pour déplacer le vecteur entre C000 et FFFF en supposant que tu laisses la banque 7 connectée en permanence (via C1/C3)) Désactiver les interruptions (DI, ou 1 interruption sans EI)
Théoriquement, tu pourrais t'amuser à remettre les données à afficher en place avant que le CRTC les affiche et remettre juste après le code de l'interruption. C'est un problème qui devient un peu complexe si la ram cycle, car cela suppose que tu modifies la ram à partir de #38 au bon moment (sur l'interruption qui précède l'affichage de la zone) et se synchroniser pour remettre le code de l'interruption avant que la prochaine survienne.
Ceci étant dit, si tu es prêt à mettre un EI/RET, autant enlever les interruptions car elles ne servent à rien. Si tu as besoin d'une synchronisation précise, il suffit de générer ton code en temps fixe.
Inscription : 12 Juin 2008, 20:29 Message(s) : 1726
Merci pour votre aide et vos conseils.
@Longshot : ce que je veux faire, c'est bien un scrolling double buffer en overscan. Pourquoi m'indiques-tu que je n'aurai besoin alors que de 3 écrans ? si je mets 2x&4000 pour le 1er écran, j'ai bien besoin de 2x&4000 pour le deuxième...
Effectivement, l'idée de modifier en &38 au moment où le CRTC y accède pour afficher à l'écran est une bonne idée...mais vu que la RAM cycle (c'est un scrolling) il va falloir coder très précis pour cela (ex : un jump en &38 vers un morceau de code qui fait ld hl,0 ld (&38),hl ei ret et ensuite dans le programme faire un di et avant le ei : ld hl,&c9fb ld (&38),hl après que le CRTC est passé la zone &38 en affichage !
Sinon, ta proposition d'enlever complètement les interruptions semble bonne également... Je devrais juste avoir du code constant en tps machine ou tout simplement me caler après une synchro de vbl...
Donc, si je comprends bien, cela va demander un effort supplémentaire dans tous les cas, je vais voir si mon code en vaut le coup par rapport à l'effort !
Ce que dit totO est juste, effectivement, si tu veux deux double buffer fullscreen, ça fait bien 48k soit 3 pages.
En fait, dans la plupart des démos cpc utilisant des scroll hard, c'est à la bourrin, c'est à dire que le codeur affiche, décale son affichage et laisse boucler le tout sur 16k ce qui n'est absolument pas nécessaire.
en fait il faut juste te contenter de boucler sur la longueur nécessaire, et dans ce cas tu peux préserver la zone 0 si tu as besoin des interruptions.
évidemment c'est un peu plus compliqué et ça implique que tu auras un buffer à cheval sur deux pages...
Mais à vaincre sans péril, on triomphe sans gloire
Pour info (on va encore m'accuser d'être pro-the demo...) si tu examines la phenix part de longshot, tu t'apercevras qu'il n'aurait pas pu faire un scroll hard-> une page de 16k... (je prend cet exemple car ça m'avait beaucoup travaillé à l'époque ou c'est sorti).
Inscription : 28 Août 2008, 23:41 Message(s) : 270
Comme l'indiquent Shap et Toto, pour faire 1 image overscan, tu n'as pas besoin de 32 k Il suffit donc que tu utilises (16k + 8k) x 2 Tu es par contre obligé d'utiliser le cyclage "matériel" de la ram, également pour la banque qui contient les 2 morceaux de 8 k
La méthode qu'évoque shap est le cyclage "logique" de la ram. Pour éviter le cyclage "matériel", il suffit de le gérer "logiquement". Cela sert lorsque 2 fois la taille du buffer video affiché est inférieur à 16 k. Tout dépend donc de la ram que tu veux "sauver". Cela consomme 2 fois la taille du buffer vidéo affiché et il faut gérer 2 fois le rafraichissement des données au lieu d'un (en général, lorsqu'on a calculé les données entrantes il suffit de mettre à jour les 2 "rubans" en même temps). Ainsi c'est le programme qui remet le pointeur vidéo au début du "double" buffer. Tu as donc en permanence 2 fois le même buffer en ram pour pouvoir permuter.
Inscription : 15 Oct 2007, 02:49 Message(s) : 405 Localisation : Les Sucres en Morceaux
Un vrai fullscreen bien plein fait plutôt 26Ko que 24Ko. Mais 24Ko, c'est déjà très bien la plupart du temps. Mais si vraiment tu regrettes l'overscan de 26k, je pense qu'il y a encore une solution.
Tu gères chaque écran sur 2 plages de 16k (donc 32k, comme ton idée de départ) mais réduis le R9 du CRTC à la valeur minimum (donc entre 5 et 6, mettons 6 pour un écran de 28k) et tu cales tes interruptions en mode IM2 dans la zone non affichée de ton choix (les 2 derniers Ko d'une des 4 plages mémoire). La précision du mode IM2 étant de 256 octets (donc 257 occupés), tu ne devrais pas avoir de problème compte tenu qu'il te reste 4x2Ko inutilisés en mémoire centrale.
Sauf si je me trompe, bien sûr ; mon truc, c'est plutôt de colorer les pixels, vous savez...
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 13 invité(s)
Vous ne pouvez pas publier de nouveaux sujets dans ce forum Vous ne pouvez pas répondre aux sujets dans ce forum Vous ne pouvez pas éditer vos messages dans ce forum Vous ne pouvez pas supprimer vos messages dans ce forum Vous ne pouvez pas insérer de pièces jointes dans ce forum
Connexion
Inscription
FAQ
