probleme avec struct, pointeur, et memoire vidéo

salut

je suis ce qu'on pourais qualifier de "vieillbécanophile", c'est pourquoi je programme sous TurboC, et cherche des trucs bizarre, pas de soucis.

je cherche a maitriser la manipullation de la memoire en mode texte. j'ai donc testé plusieurs trucs, avec l'aide de quelques personnes. voici le principe :

je pose en x,y, le caractere c, de couleur t, dont l'arriere plan est b.
l'adresse de la memoire utile en mode texte est B800, et chaques caractere est dérfinit par 2 octets (couleur et code ascii ...)

j'aimerais créer un pointeur vers la memoire, et , comme voulais que je fasse, le pote en question, définir ce caractere par un struct.

Code:

---

1 2 3 4 5

struct chardata { char code; char colour; }

---

et pour reprendre son exemple exact :

Code:

---

1 2 3 4

struct chardata * screen = <pointer to B800:0000... mk_fptr or something like that, can't remember>   screen[x + 320 * y].code = 'A'; screen[x + 320 * y].colour = 15;

---

je créé donc ma structure :

Code:

---

1 2 3 4 5 6

typedef struct memoire_video { char code; int colour; }

---

puis, j'assigne mo pointeur :

Citation:

---

memoire_video *far charmap (char far*) 0xB8000000;

---

mais, ca coince (erreur dans le codage),et j'ai l'impression de ne pas faire ce que je voudrais.

auriez vous une solution a mon probleme ?, et pouriez vous m'expliquer en quoi ma struct va modifier le second offset de mon segment suivant s'il sajit de colour ou de code ?

merci, ++ Tix.

Citation:

---

Envoyé par tixweb

mais, ca coince (erreur dans le codage),et j'ai l'impression de ne pas faire ce que je voudrais.

.

---

ca coince comment ? Message erreur plantage ?
Il n'ya pas de mode texte en 320 pixels de largeurs à ma connaissance seulement 640*400,640*480 en 16 couleurs.
Il ya le mode 13h en 320*240*256 couleurs mais c'est graphique avec des pixels et tu peux l'adresser avec un pointeur long avec MK_FP à l'adresse A000:000

Code:

---

1 2	memoire_video *far charmap (char far*) 0xB8000000;

---

Non c'est le plantage garanti sauf en mode protégé avec un dos-extender !
en mode réel avec Turbo C c'est segment:offset ( un truc que jamais dans ma vie j'arriverais à piger d'ailleurs )

Cet exemple là est correct
http://www.lfbs.rwth-aachen.de/~stef...src/mk_fp.html

^^ je crois que tu n'a pas bien compris mon probleme, dois-je le tourner autrement ?

merci, ++ Tix.

Citation:

---

Envoyé par tixweb

je suis ce qu'on pourais qualifier de "vieillbécanophile", c'est pourquoi je programme sous TurboC, et cherche des trucs bizarre, pas de soucis.

je cherche a maitriser la manipullation de la memoire en mode texte. j'ai donc testé plusieurs trucs, avec l'aide de quelques personnes. voici le principe :

---

Il n'est pas possible de mapper la mémoire physique de façon portable avec une structure. Ce qui est possible est ceci (Turbo C):

Code:

---

1 2 3 4 5 6

#include <dos.h>   { unsigned char *p_video = MK_FP (0xB800, 0); ...

---

Ensuite, et à supposer que tu es bien en mode texte 80x25, par un subtil jeu de calcul d'index tu peux considérer que tu as un tableau à 3 dimensions constitué d'une page de 25 lignes de 80 colonnes de 2 octets contenant respectivement et dans l'ordre, le caractère et l'attribut.

Code:

---

1 2 3

p_video[(lin*80 + col)*2 + 0] = 'A' ; /* character */ p_video[(lin*80 + col)*2 + 1] = 15 ; /* attribute */

---

ha, tien ,ca me plais ca, c'est élégant :)

je teste dans la soirée sur un des deux HP Vectra Rs 25C que je vais monter dans mon gourbi :mouarf:

merci, je vois tien au courant ;)

++ Tix.

bha ecoutez, je suis circonspect ...

je pense avoir bien tout fait comme tu me l'a suggeré, mais rien ne s'affiche a l'écran et mon niveau ne me permet pas de débugger ou de savoir ou est l'erreur. (aucun message de bug a la compilation)

voila, si vous pouviez m'aider :)

++ Tix.

Citation:

---

Envoyé par tixweb

je pense avoir bien tout fait comme tu me l'a suggeré, mais rien ne s'affiche a l'écran et mon niveau ne me permet pas de débugger ou de savoir ou est l'erreur. (aucun message de bug a la compilation)

---

Le code que je t'ai indiqué n'est pas validé. Je pourrais essayer de le tester sur le plan fonctionnel (le calcul est-il correct ?), mais je pense que tu pourrais le faire aussi. Savoir tester du code 'sans cible dédiée' est un bon exercice... Quelques appels de la fonction à tester, une trace avec printf()... Rien de bien sorcier...

Pour pouvoir t'aider complètement, il faudrait une machine sous DOS avec Turbo C, et je n'ai plus ça en magasin depuis près de 10 ans...

Je ne comprends pas très bien ce que tu cherches à faire. Développer un nième système ?

Poste quand même ton code, il y a peut être un gag...

salut

les calculs me semblent bons. y*w+x, c'est générique et ca marche partout :haha:

ensuite, j'aimerais que l'on éclaircisse plusieurs petits points qui m'interloquent :

quel est la signification des "..." a la fin de ton code ?, ya il quelquechose d'attendu ou d'évident pour un vrais codeur ?

ensuite, quand tu fait

Code:

---

1 2	p_video[(lin*80 + col)*2 + 0]

---

l'intérieur des crochets, c'est l'offset, donc, il faudrais multiplier la position par 16 pour se déplacer de segments en segments ? ^o)

voila, je testerai diverses solutions demain :)

merci, et bonne soirée

++ Tix.

Citation:

---

Envoyé par tixweb

les calculs me semblent bons. y*w+x, c'est générique et ca marche partout

---

Peut être, les maths, c'est pas mon fort...

Citation:

---

ensuite, j'aimerais que l'on éclaircisse plusieurs petits points qui m'interloquent :

quel est la signification des "..." a la fin de ton code ?, ya il quelquechose d'attendu ou d'évident pour un vrais codeur ?

---

Ca veut simplement dire que c'est une ébauche de code et qu'il faut écrire la suite. Je ne sais pas ce que tu veux faire.

Citation:

---

ensuite, quand tu fait

Code:

---

1 2	p_video[(lin*80 + col)*2 + 0]

---

l'intérieur des crochets, c'est l'offset, donc, il faudrais multiplier la position par 16 pour se déplacer de segments en segments ?

---

Hein ? Segment ? C'est quoi ça ? On est dans une zone mémoire 'octet' adressée directement 'en dur' par un offset calculé en nombre d'octets. Si le calcul est correct et si je n'ai pas inversé attribut et caractère (je ne connais pas les specs des cartes vidéo, par coeur...), ça devrait fonctionner. Je conseille d'écrire une fonction d'écriture directe genre :

Code:

---

1 2 3 4 5 6 7 8 9

#include <dos.h>   void putxy(int x, int y, int car, int attr) { unsigned char *p_video = MK_FP (0xB800, 0);} p_video[(y*80 + x)*2 + 0] = car ; /* character */ p_video[(y*80 + x)*2 + 1] = attr ; /* attribute */ }

---

merci bien ED(je pense le meme que sur le SDZ ;))

merci pour tes explications, je pense que je vais essayer de trouver plus d'infos a propos de segments et des offset, ca me semble encore flou, et j'aime pas quand je ne maitrise pas :).

pour le coup, je pense avoir copmpris l'attribution de la position aux []., c'est donc un emplacement dans la mémoire, représentée par le pointeur, est-ce cela ? (je ne m'intéresse aux pointeurs que depuis relativement peu)

cet aprem', je m'intéresserai a ta fonction pour mes tests.

ps:

Citation:

---

Je ne comprends pas très bien ce que tu cherches à faire. Développer un nième système ?

---

biensure que non, comme d'hab, c'est pour comprendre mieu, et comprendre des techniques, ca me parait tout a fait géniale que ca puisse exister ce genre de manip :mrgreen:

merci beaucoup, ++ Tix.

Citation:

---

Envoyé par tixweb

^^ je crois que tu n'a pas bien compris mon probleme, dois-je le tourner autrement ?
merci, ++ Tix.

---

Oui mais tu ne réponds pas à ma question .
; et Emmanuel utilise MK_FP dans son code.

oops, dsl Mat.M :s

heu, oui, une erreur de compilation, je ne saurais m'en souvenir exactement, mais ca parlait d'un pointeur suspect ou quelquechose comme ca, je vérifierais quand je pourrais.

merci, ++ Tix.

ca y est, mo problem est résolu, je posterai mes sources au cas ou ca puisse en intéresser d'autres :)

merci beaucoup pour votre aide, ++ Tix.