@toto Disons qu'il est difficile de parfois d'affranchir des habitudes.. Mais pour certains, mon article va sembler "évident et amateur", alors que pour d'autres, cela risque d'être la "révélation"... donc, qui sait?
Dernière édition par norecess le 04 Mars 2011, 21:29, édité 1 fois.
les 12ko inutilsés sont... perdu, ou difficilement addressable ?
la réponse est dans ta question. Les 12Kb restants sont de la RAM classique (non affiché) dans lequel tu peux y etre du data, du code, ..
Merci pour la réponse éclaire.
En fait ma question porte aussi sur le mode d'adressage de l'écran qui semble changer de logique et déborder des 20ko dans lesquels je le croyais bien cloisonné.
Quand je remplis la mémoire avec des &FF (à partir &8000 et sur 20480 octets consécutifs), l'écran deviens bien tout rouge jusqu'à 16ko, et passé ce cap, seules 2 lignes sur 8 sont remplies. J'imagine que pour remplir le reste il faut dépasser les 20ko que j'ai réservé, et que du coup ca deviens la misère pour addresser le surplus de 12ko ? A moins qu je me soit trompé quelque part...
Je met mon code (c'est du à l'arrache), si jamais j'ai fait le boulet et que je me creuse pour rien :
Code :
org &4000
di
ld BC, &BC07 out (C), C ld BC, &BD22 out (C), C ; ecran en haut
ld BC, &BC06 out (C), C ld BC, &BD20 out (C), C ; 32 * 8 = 256 lignes ; = 20ko ld BC, &BC0C out (C), C ld BC, &BD2C out (C), C ; ecran 32ko@&8000
ld BC, &5000 ld HL, &8000 _rempli ld A, &FF ld (HL), A inc HL dec BC xor A cp B jp NZ, _rempli cp C jp NZ, _rempli
_loop jr _loop
Dernière édition par dentifiant le 04 Mars 2011, 21:46, édité 1 fois.
OK je comprends. Rappelle-toi que sur CPC, la RAM n'est pas linéaire. Donc oui, ton 1er 16Kb de RAM va correctement remplir les 8 lignes-caractere de ton écran, et les 4Kb restant va remplir les 2 1eres lignes.. logique. À noter que ce "problème" intervient également avec un écran simple de 16Kb, si tu remplis uniquement les 4 premiers Kb tu auras le meme comportement.
Truc et astuce d'un overscan facile (corrigez-moi si je me trompes) : - fais-toi une routine générique qui ira, en fonction de tes paramètres CRTC, te créer une table contenant l'adresse-écran de toutes tes lignes écran à gauche - trouves-toi une résolution dont le "split" entre tes 2 écrans s'effectue si possible dans le "border" (ou bien aligné à l'horizontale en début de ligne), cela te sera plus facile plus tard pour gérer tes déplacements
OK je comprends. Rappelle-toi que sur CPC, la RAM n'est pas linéaire. Donc oui, ton 1er 16Kb de RAM va correctement remplir les 8 lignes-caractere de ton écran, et les 4Kb restant va remplir les 2 1eres lignes.. logique. À noter que ce "problème" intervient également avec un écran simple de 16Kb, si tu remplis uniquement les 4 premiers Kb tu auras le meme comportement.
Truc et astuce d'un overscan facile (corrigez-moi si je me trompes) : - fais-toi une routine générique qui ira, en fonction de tes paramètres CRTC, te créer une table contenant l'adresse-écran de toutes tes lignes écran à gauche - trouves-toi une résolution dont le "split" entre tes 2 écrans s'effectue si possible dans le "border" (ou bien aligné à l'horizontale en début de ligne), cela te sera plus facile plus tard pour gérer tes déplacements
Courage!
Merci. Oui je crois comprendre le truc, en fait faut que je fasse comme si je revenais au début de l'écran, en plein milieu. Pratique . Mais bon, me déplacer dans ce nouvel écran est pas mon plus gros stress en fait, j'arriverais bien a me demerder (merci pour l'astuce des tables d'adressage, vais voir ce que ça donne). C'est surtout les 12ko tout entralcés la dedans qui me parraissent difficilement utilisables, du coup
Je te suggère cependant de bien te familiariser avec un écran 16Kb (cf. écris une routine générique capable d'afficher un point à n'importe quelle position X/Y) avant de te lancer dans l'overscan.
Je suis déjà un peu rodé pour ça. En tout cas en restant à l'échelle de l'octet. J'ai écrit une routine qui recupère des sprites 4x16 sur une page écran pour en faire un fichier, et une autre qui le charge et affiche les cases suivant un tableau en mémoire. J'en étais à bouger un sprite la dessus suivant un chemin, quand j'ai eu l'idée de m'interesser un peu à l'overscan histoire de savoir comment organiser ma mémoire et pour voir si c'était envisageable tout en restant dans 64k. Semblerait que ça le soit pas, pour le moment. Tant pis.
Tu sembles vouloir faire un jeu. Je te suggère en effet de te concentrer plutôt sur la manipulation au pixel (et non à l'octet), cf. faire des masks etc.
Je vais y venir c'est certain. Mais pour le moment je regle le pathing des monstres, regarder l'overscan etait juste un petit break pour prendre un peu de recul la dessus. Les petites routines que j'ai bricolé sont rudimentaires mais répondent bien à mes besoins du moment. Après ça je regarderais les masks pour que tout s'affiche proprement sans bavure, promis
Inscription : 15 Août 2008, 13:00 Message(s) : 968 Localisation : Troyes, France
norecess a écrit :
Truc et astuce d'un overscan facile (corrigez-moi si je me trompes) : - fais-toi une routine générique qui ira, en fonction de tes paramètres CRTC, te créer une table contenant l'adresse-écran de toutes tes lignes écran à gauche - trouves-toi une résolution dont le "split" entre tes 2 écrans s'effectue si possible dans le "border" (ou bien aligné à l'horizontale en début de ligne), cela te sera plus facile plus tard pour gérer tes déplacements
J'ajouterai , gérer ta mémoire écran comme un ensemble de caractères c'est pas mal aussi : tous les 1024 caractères on saute de page de 16K (16K avec R9 à 7 bien sur)
_________________ "NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)
Inscription : 28 Août 2008, 23:41 Message(s) : 270
Citer :
Ce qui m'étonne, c'est de connaitre l'existence de &C0, &C5, &C6, &C7 et de ne pas avoir été curieux de voir comment se comportait &C1, &C2, &C3 !
La gestion de la mémoire était le truc le moins documenté lors de la sortie du 6128 car seul le CP/M+ l'utilisait. Il m'avait fallu désassembler le CP/M pour piger ce qui se passait. Mais en 1991, tout était dit (https://cpcrulez.fr/coding_logon40-gerer_vos_banks.htm)
Citer :
C'est un peut comme cette histoire d'adressage mémoire ou "tout le monde" pensait que le CPC supportait au max 512K de RAM et que les 3 bits restants étaient inutilisés ... Jusqu'à ce que quelqu'un fabrique une extension de 4Mo.
Tu te trompes. Si tu lis l'article plus haut tu verras que les bits 0.1.2. indiquent la configuration mémoire des 128 k dans les 64 k pour la 1ère page de 64 additionnelle Les bits 3.4.5 indiquent la page de 64 additionnelle. Soit 8 x 64 = 512 + 64 (ram centrale) = 576 k qui est la limite sans bidouillage. Pour avoir plus de pages, chaque extension mémoire utilise un nouveau truc en ajoutant des ports de manière plus ou moins élégante Exemple ici ou le système est astucieux car il conserve la compatibilité avec dk-tronic: https://cpcrulez.fr/hardware-interface- ... d-ram7.htm
Citer :
D'ailleurs, ce n'est certainement pas une coïncidence si ces machines ont vu naitre beaucoup plus de cartes d'extensions en tout genres, réalisés par des passionnés.
Je n'ai pas l'impression que le monde cpc soit en reste... Enormément de choses ont été réalisées sur le cpc je pense.
Citer :
@longshot tes réponses m'ont tellement allumé que j'en ai écris un petit article sur mon site pour résumer le tout !
Cool si ça peut servir à quelqu'un.
Citer :
C'est surtout les 12ko tout entralcés la dedans qui me parraissent difficilement utilisables, du coup
Si tu ne touches pas au nombre de lignes par caractères, tu dois raisonner en te disant que ta bank de 16k est divisé en 8 blocs de 2 ko (le bloc 0 représentent toutes les lignes 0, le bloc 1 toutes les lignes 1, ...). Donc dans chaque bloc il te reste la mémoire non utilisée pour l'affichage. Donc le nombre d'octet d'une ligne multiplié par le nombre de lignes. Tu peux t'en servir en mettant des bouts de code ou des données. Avec un assembleur il faut juste mettre des "org" un peu partout et s'assurer que le code ne déborde pas sur la zone suivante (je ne sais plus si il existe une directive pour faire ça d'ailleurs...)
Inscription : 15 Août 2008, 13:00 Message(s) : 968 Localisation : Troyes, France
Longshot a écrit :
Avec un assembleur il faut juste mettre des "org" un peu partout et s'assurer que le code ne déborde pas sur la zone suivante (je ne sais plus si il existe une directive pour faire ça d'ailleurs...)
C'est la directive LIMIT.
_________________ "NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)
Inscription : 13 Jan 2010, 14:25 Message(s) : 2282
Longshot a écrit :
La gestion de la mémoire était le truc le moins documenté lors de la sortie du 6128 car seul le CP/M+ l'utilisait. Il m'avait fallu désassembler le CP/M pour piger ce qui se passait. Mais en 1991, tout était dit (https://cpcrulez.fr/coding_logon40.htm)
A l'époque je testais un peut des valeurs au hasard pour découvrir des choses. quand on a C0, C4, C5, C6 et C7 ... C'est plutôt tentant d'essayer C1, C2 et C3 pour voir comment ça réagis, nop ? Je me souviens être tombé par hasard sur l'affichage entrelacé en 1989. J'avais fait un screen overscan entrelacé, mais j'en ai jamais vu le résultat car on CTM a lâché au moment le l'afficher. :p Ce fut la fin de l'ère 8-bit pour ma part.
Longshot a écrit :
Pour avoir plus de pages, chaque extension mémoire utilise un nouveau truc en ajoutant des ports de manière plus ou moins élégante
Au temps pour moi, merci pour la précision.
Longshot a écrit :
Je n'ai pas l'impression que le monde cpc soit en reste... Enormément de choses ont été réalisées sur le cpc je pense.
Beaucoup de choses pour les développeurs, mais pas pour les utilisateurs. Enfin, c'est mon impression.
En tout cas, merci beaucoup de m'avoir fait rêver à l'époque et d'être encore disponible pour ceux qui veulent vivre cette passion aujourd'hui.
C'est surtout les 12ko tout entralcés la dedans qui me parraissent difficilement utilisables, du coup
Si tu ne touches pas au nombre de lignes par caractères,
Bah justement je me suis rendu compte hier soir qu'on pouvais faire ça, mais j'était trop naze pour pouvoir investiguer (j'ai lu ça dans l'article de norecess au sujet des banks mémoire justement). Avec ça, il devrait être possible d'une part de simplifier un poil l'adressage video (même en 16k standard), et de plus, défragmenter un peu l'espace libre en cas d'overscan, non ?
Inscription : 28 Août 2008, 23:41 Message(s) : 270
Dès lors que tu touches au registre 9 du CRTC, tu indiques que tu gères moins de blocs. Ainsi si tu mets 1 dans ce registre, cela indique qu'il gère 2 lignes par "caractère" Tu vas donc avoir sur la ligne 1, le bloc 0 (issus des 2048 premiers octets) Sur la ligne 2, le bloc 1 (issus des 2048 octets suivants) Sur la ligne 3, le bloc 0 de nouveau Et ainsi de suite...
Le problème, c'est que les 2048 octets sont consommés "plus vite" Si une ligne de ton écran consomme 80 octets, tu vas avoir 25 lignes complète pour 1 bloc. Avec seulement 2 blocs affichés, ton écran total aura 50 lignes différentes. Avec 4 blocs (reg 9=3) tu auras 100 lignes différentes, et tu ne consommeras que les 8192 premiers octets de la ram vidéo, le reste restant disponible.
Bien évidemment si tu changes le reg 9, il y a moins de lignes affichées sur l'écran. Et tu dois donc compenser pour garder 312 lignes affichées. (R4+1)x(R9+1)+R5=312 Donc si R9 passe de 7 à 3, il faut que R4 soit multiplié par 2.
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 49 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
. Mais bon, me déplacer dans ce nouvel écran est pas mon plus gros stress en fait, j'arriverais bien a me demerder (merci pour l'astuce des tables d'adressage, vais voir ce que ça donne). C'est surtout les 12ko tout entralcés la dedans qui me parraissent difficilement utilisables, du coup 
