Discussion :

[mouth_fr]

Bonjour,
J'aimerai connaitre l'instruction C++ qui permet de lire et d'ecrire dans les zones d'adresses hautes d'un PC ($CD000).
En fait je cherche l'equivalent de l'instruction Mem en Turbo Pascal.
Merci de m'avoir lu
@+
Julien

[bacelar]

zones d'adresses hautes d'un PC
l'instruction Mem en Turbo Pascal.

Ca date du DOS tout ça.

Vous faite un programme pour quelle plateforme (OS)?

[mouth_fr]

Mon programme Turbo PASCAL fonctionne actuellement sous DOS, mais j'envisage de migrer sous linux et j'aimerai retranscrire mon programme Turbo Pascal en C.
@+
Julien

[Médinoc]

Les histoires d'adresses hautes et compagnie n'existent pas sous les systèmes 32 bits comme Windows NT et Linux.

Mais déjà, si tu trouves un compilateur C pour DOS, ce sera une bonne étape pour la conversion.

PS: $CD000, traduit en segment+offset, ça donne bien CD00:0000?

[Mac LAK]

Vaudrait mieux regarder ce que le programme faisait en tapant directement à cette adresse, puis le "refaire" proprement en utilisant les API 32 bits adéquates de l'OS...

[mouth_fr]

Merci pour vos reponses,
Pour Medinoc : oui on note seg:off $CD00:00
Pour etre plus precis voila ma manipe :
J'ai une carte ISA qui fait de l'aquisition, et elle a pour adresse physique $CD00:00.
Toutes les secondes elle me genere une IRQ. J'ai une procedure d'interruption en pascal qui declenche et je vais ensuite lire une valeure a l'adresse de la carte j'utilise pour cela la ligne pascal :
A:=MEMW[$CD00:00];
Voila.
Pour Mac LAk : peux tu m'expliquer davantage car je ne comprends pas trop (API 32bits ?).
Les adresses hautes sont bien des adresses physiques (point de vue Hardware) je ne vois donc pas pourquoi on ne pourrait plus avoir acces sous systemme 32 bits.
Merci de m'avoir lu.
Julien

[Médinoc]

Hélas, en 32 bits, le processeur impose des restrictions d'accès. Les programmes tournant en "user mode" (Ring 3) ne peuvent pas toucher aux vecteurs d'interruptions ou accéder aux périphériques; seuls les programmes tournant en "kernel mode" (Ring 0) le peuvent. Et ces programmes ce sont des drivers.

Donc, si tu veux accéder à ta carte sur un système récent, tu vas devoir écrire un driver kernel-mode pour ça, et appeler ledit driver depuis ton programme. Sous Windows, renseigne-toi sur le Windows Driver Model...

[camboui]

Ceci me fait penser à la blague de l'informaticien qui s'est fait congeler en 1999 car il ne voulait pas voir les dégats causés par le passage à l'an 2000, et qu'on réveille en 9999 car on l'avait oublié avant cela... on le reveille car en 9999 on a besoin des services d'un gars qui connait le cobol pour le passage à l'an 10000...

Sérieusement, je crois comprendre que tu utilises toujours un vieux PC muni de carte ISA avec des programmes qui tournent en 16bits. Je pense qu'il faudrait décrire le hardware complet (i286 ?), s'il peut être modernisé. Sinon on est en pleine maintenance "long terme et faible coût", je doute qu'une migration des outils soit indiquée.

Mais s'il le faut vraiment, je pense à un truc comme ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
long a=0xCD000000;
char far *p=(char far *)a;
a=*p;

[Mac LAK]

Pour Mac LAk : peux tu m'expliquer davantage car je ne comprends pas trop (API 32bits ?).
Les adresses hautes sont bien des adresses physiques (point de vue Hardware) je ne vois donc pas pourquoi on ne pourrait plus avoir acces sous systemme 32 bits.

Comme l'a dit Médinoc, sous un OS 32 bits, ce genre d'opération est désormais strictement interdite aux applications "normales". C'est une question de protection / isolation des processus, en fait. Et c'est absolument inutile de chercher plus loin : ça ne fonctionnera JAMAIS.
De plus, trouver des ports ISA sur un PC moderne est extrêmement difficile sans taper dans le PC industriel...

Pour pouvoir piloter de nouveau ta carte avec un PC moderne, la seule et UNIQUE solution passe par l'écriture d'un driver 32 bits, qui lui par contre aura l'autorisation d'aller taper dans ces adresses. La communication avec ton application se fera au choix via des commandes read / ReadFile et write / WriteFile (mode flux), ou par des IOCTL (ioctl / DeviceIoControl, commandes dans l'esprit RPC). A noter que, de ce point de vue, c'est exactement pareil pour Windows et Linux : aucun de ces deux OS n'acceptera que tu tapes directement dans le matériel à partir du mode User, et exigeront un driver adéquat...

Pour la doc Windows : Windows Driver Kit (WDK), disponible au téléchargement ici.
Pour la doc Linux, c'est moins net, mais tu n'as pas besoin de SDK particulier pour créer un driver. Tu peux aller voir cet article, ou voir pour l'achat de ce bouquin.


Si par contre tu restes dans le monde DOS sur des anciennes machines, alors le problème se règle de lui-même : les compilateurs 16 bits possèdent tous une instruction / macro permettant de composer une adresse sous la forme segment:offset vers une adresse compatible avec un pointeur (MK_FP, de mémoire...).

[mouth_fr]

Bon je sens que ca va pas etre si simple que ca mon histoire
Mon but final est de migrer mon installation tournant sous DOS vers LINUX.
Ma manipe etant ecrite en PASCAL, je m'etais mis dans l'idée de trouver un compilateur PASCAL sous LINUX mais ne trouvant rien de bien je pensais re-ecrire le tout C.
Mais la si il faut en plus ecrie un driver pour ma carte ca devient coton.
Pour camboui : merci pour les lignes de code je vais essayer.
Merci a tous
@+
Julien

[Mac LAK]

Ma manipe etant ecrite en PASCAL, je m'etais mis dans l'idée de trouver un compilateur PASCAL sous LINUX mais ne trouvant rien de bien je pensais re-ecrire le tout C.

La liste des compilateurs Pascal disponibles...
Tu as notamment Lazarus, Free Pascal, Virtual Pascal et GNU Pascal (par ordre de préférence).

Mais la si il faut en plus ecrie un driver pour ma carte ca devient coton.

Alors ça, inutile d'espérer pouvoir t'en passer, par contre... Faudra mettre les mains dans la tripaille, je te conseille d'essayer de trouver un code source de driver ISA Linux, et de partir de là pour l'adapter à tes besoins. Au moins, tu auras le code source nécessaire pour taper dans ce bus...

[Médinoc]

Cette ligne de code marchera en C sous une plate-forme 16 bits, mais pas sous un OS 32.

[camboui]

Cette ligne de code marchera en C sous une plate-forme 16 bits, mais pas sous un OS 32.

Je suppose que tu fais allusion à mon petit code

Mouth_fr, en effet ce que j'ai écrit ne fonctionne qu'en 16 bits. Je viens seulement de réaliser que tu voulais aussi passer sous Linux.

[mouth_fr]

ok encore une fois merci pour vos reponses.
Bon apparement on est tous d'accord pour dire qu'il me faut un driver pour ma carte ISA si je veux tourner sous LINUX et sous un programme ecrit en C ou en PASCAL.
Comme je n'ai encore jamais ecris de programme faisant appel a un driver si quelqu'un a une bonne documentation ou des tutos cela m'interesse.
Pour Mac LAK : connaitrais tu un code source de driver ISA sous LINUX?
Merci a vous.
@+
Julien

[Mac LAK]

Comme je n'ai encore jamais ecris de programme faisant appel a un driver si quelqu'un a une bonne documentation ou des tutos cela m'interesse.

C'est en fait assez bête comme truc : un driver, c'est comme un fichier un peu particulier. Tu l'ouvres, tu lis/écris dedans et tu peux utiliser des commandes "spéciales" que sont les IOCTL... Rien de bien sorcier.

Pour Mac LAK : connaitrais tu un code source de driver ISA sous LINUX?

Non, désolé, Linux et moi ne sommes pas vraiment potes... Je n'ai pas vu de matériel ISA passer depuis que j'ai lâché ma SoundBlaster 16, ce qui ne nous rajeunit pas.
Il faudra sûrement fouiller dans des sources Linux pour trouver ça.

[mouth_fr]

ok je commence a comprendre, je vais fouiller dans les docs que tu m'as cités plus haut.
Ah les ports ISA mais il faut savoir que dans le milieu industriel (celui ou je me trouve) ces cartes sont encore bien presentes. De plus j'utilise bien en PC industriel.
Merci
@+
Julien.

[Mac LAK]

ok je commence a comprendre, je vais fouiller dans les docs que tu m'as cités plus haut.

Bonne lecture !

Ah les ports ISA mais il faut savoir que dans le milieu industriel (celui ou je me trouve) ces cartes sont encore bien presentes. De plus j'utilise bien en PC industriel.

Je suis aussi dans ce milieu, mais on est quand même passé au PCI (plus l'inévitable VME, bien sûr) : plus pratique et plus pérenne...