CPC Rulez :: Consulter le sujet

les 12ko inutilsés sont... perdu, ou difficilement addressable ?

Citer :

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, ..

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!

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

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 !

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.

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.

@longshot tes réponses m'ont tellement allumé que j'en ai écris un petit article sur mon site pour résumer le tout !

C'est surtout les 12ko tout entralcés la dedans qui me parraissent difficilement utilisables, du coup

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...)

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)

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

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 :

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,

Auteur :	norecess [ 04 Mars 2011, 21:27 ]
Sujet du message :	Re: la ram du cpc
@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?

Auteur :	norecess [ 04 Mars 2011, 21:29 ]
Sujet du message :	Re: la ram du cpc
Citer : 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, ..

Auteur :	dentifiant [ 04 Mars 2011, 21:38 ]
Sujet du message :	Re: la ram du cpc
norecess a écrit : Citer : 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

Auteur :	norecess [ 04 Mars 2011, 21:46 ]
Sujet du message :	Re: la ram du cpc
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!

Auteur :	dentifiant [ 04 Mars 2011, 21:50 ]
Sujet du message :	Re: la ram du cpc
norecess a écrit : 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

CPC Rulez https://cpcrulez.fr/forum/

la ram du cpc https://cpcrulez.fr/forum/viewtopic.php?f=4&t=4480	Page 3 sur 3

Auteur :	norecess [ 04 Mars 2011, 22:14 ]
Sujet du message :	Re: la ram du cpc
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.

Auteur :	dentifiant [ 04 Mars 2011, 22:48 ]
Sujet du message :	Re: la ram du cpc
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.

Auteur :	norecess [ 04 Mars 2011, 22:59 ]
Sujet du message :	Re: la ram du cpc
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.

Auteur :	dentifiant [ 04 Mars 2011, 23:22 ]
Sujet du message :	Re: la ram du cpc
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

Auteur :	fano [ 05 Mars 2011, 01:29 ]
Sujet du message :	Re: la ram du cpc
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)

Auteur :	Longshot [ 05 Mars 2011, 11:28 ]
Sujet du message :	Re: la ram du cpc
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...)

Auteur :	fano [ 05 Mars 2011, 11:58 ]
Sujet du message :	Re: la ram du cpc
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.

Auteur :	TotO [ 05 Mars 2011, 15:28 ]
Sujet du message :	Re: la ram du cpc
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.

Auteur :	dentifiant [ 05 Mars 2011, 16:42 ]
Sujet du message :	Re: la ram du cpc
Longshot a écrit : 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, 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 ?

Page 3 sur 3	Le fuseau horaire est UTC+1 heure
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/

Auteur :	Longshot [ 08 Mars 2011, 13:38 ]
Sujet du message :	Re: la ram du cpc
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.