Discussion :

[Transgarp]

Hello,

J'ai un petit programme en BP7 de contrôle d'éclairage de la maison qui écrit et lit direct en mémoire sur l'ancienne plage de carte prototype hex300 à hex302

Tout fonctionne à merveille depuis que j'ai concu cet interface sur mon IBM-PC 8088 sous IBM DOS 5.0 en 1988 qui avait comme langage Basica que j'ai traduit en BP7 en 1990

Cette carte prototype est monté présentement sur un slot ISA d'un P3-800Mhz Asus CUV4X sous W98

Le problème est survenu lorsque j'ai installé XP sur le P3, je n'ai plus accès à la plage de carte prototype. Alors je n'ai pas eu le choix de revenir à W98

Petit exemple de code que j'utilise:

Code :

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

1
2
3
4
5
6
7
8
9
10
 
Procedure Port_Prise(J,X : Byte);
Var I : Byte;
Begin
  Repeat
    Port[$301]:=J+56+X*64; Delay(1); Port[$301]:=J+X*64; Delay(1);
    Port[$301]:=J+48; Delay(1); Port_C_8;
    If Port[$300]=1-X then I:=1 else I:=0;
  Until I=1;
End;

Selon le code, vous voyez bien que ca boucle sans arrêt vu que je ne peu changer les données de l'adresse mémoire.

J'ai su qu'il y a moyen de créer un driver pour faire tourner ce programme sous XP, mais je ne sais pas comment.

Ah oui, depuis que je roule ce programme avec des ordis plus performants que mon IBM-PC, je n'ai pas eu le choix d'insérer des Delay() pour laisser le temps de lire les états de la carte de puissance qui se trouve à 100 pieds de la carte interface de l'ordi.

Pour mes Xeon, c'est une autre histoire, je devrai refaire la carte prototype pour slot PCI

[M.Dlb]

Intéressant

Concernant la programmation sous XP, comme celui verrouille tout (accès direct à la mémoire et au hardware), tu as la possibilité d'écrire un driver pour accéder à ton matériel. D'après ce que j'en sais, c'est assez compliqué et il faut avoir de très bonnes bases concernant la programmation win32 sous XP en général. Mais avec un peu de persévérance ce n'est pas insurmontable

Ah oui, depuis que je roule ce programme avec des ordis plus performants que mon IBM-PC, je n'ai pas eu le choix d'insérer des Delay() pour laisser le temps de lire les états de la carte de puissance qui se trouve à 100 pieds de la carte interface de l'ordi.

Qu'entends-tu par là ? Comme l'ordinateur que tu utilises est plus puissant et plus rapide que ton précédent, les accès au port et à la mémoire sont plus rapides également (tu peux comparer les valeurs des fréquences des bus de données de tes ordinateurs, la différence doit être assez conséquente). Cependant la carte te met autant de temps pour te répondre, si on considère en plus le temps de transfert vers le module contrôlé (ce qui ajoute de la latence supplémentaire). Tu peux utiliser des delays pour temporiser ton programme, le temps que tu reçoives la réponse, comme tu as fait dans ton exemple.

[Alcatîz]

Bonjour !

Voici un lien vers une discussion qui devrait te donner des pistes :
http://www.developpez.net/forums/sho...ighlight=ports

[Transgarp]

j'utilise la commande Delay(1) seulement après avoir écrit dans la mémoire du timer 82C255 qui se trouve à 20 mètres de l'ordi de contrôle pour ensuite lire l'état de réponse.

Du temps de mon IBM-PC8088, nul besoin d'insérer un delay avant de faire une lecture de mémoire après avoir fait une écriture.

Mais sous un ordi puissant, le signal a tout de même 40 mètres aller-retour à franchir et Delay(1) donne une pause de 1 milliseconde, le temps que les TTL-CMOS de la carte de puissance ont eu le temps de faire les modifs et de donner la bonne réponse de lecture.

Dans l'exemple que j'ai donné, si j'écris à Port[$301]:=J+56+X*64; sans donner le temps aux TTL-CMOS de faire leur opérations sur la carte de puissance, la lecture à Port[$301]:=J+X*64; risque d'être erronée

[droggo]

Die,

Le système des délais pour lire un port n'est pas top.

Normalement, on peut vérifier qu'un port a une nouvelle donnée prête à être lue. Il vaudrait mieux boucler là-dessus, d'autant que les délais sont loin d'être garantis côté précisison, ce qui va probablement amener des disfonctionnements aléatoires.

[Transgarp]

droggo,

Regarde le petit code que j'ai placé en début de message.
Il y a un Repeat...Until, on appelle ca une boucle et mon programme contient 5000 lignes de code Pascal du même style

Le big problème est bien simple, avec les nouveaux ordis quand je ne place pas de Delay(1), ca ne sort simplement pas de la boucle en tournant en rond

Anywhay, le truc de ma conception fonctionne sans problème depuis maintenant 20 ans et aucun TTL-CMOS n'a grillé.

Tout roule maintenant sur P3-800Mhz sous W98 depuis 5 ans

Mon interface domotique a passé à travers tous les changements informatique, de Basica à BP7 et C++, de DOS à W98, de IBM-PC à Asus CUV4X-800Mhz, de 1988 à 2008

J'ai résolu tous les petits détails électronique et tout va bien.

En jonglant avec Bureau à distance et UltraVNC j'arrive même à gérer mon système sur n'importe quel ordi de la planète.

J'aurais une balle de moins à jongler si je pouvais rouler l'interface domotique sous XP, vu que 3 ordis de mon réseau sont déjà sous XP et 2003 Server.

J'aime pas utiliser UltraVNC pour gérer à distance l'ordi domotique.

Je souhaite Bureau à distance partout et jeter UltraVNC.

[Transgarp]

@Alcatiz

Un simple exemple de code pour écrire et lire à l'adresse mémoire du port jeu $300 la valeur 45 me serait utile.

Que l'application programmé et compilé en BP7 puisse tourner sous XP

Et surtout comment construire un driver pour cette application.

Pour le reste je saurai me débrouiller.

En attendant, mon système domotique de la maison roule très bien sous W98

[Alcatîz]

BP7 te compile un programme 16 bits qui tourne sur une machine DOS virtuelle sous XP. NTVDM.exe (c'est son nom) émule l'accès à certains ports, une partie des interruptions du BIOS, etc, mais tout cela se passe sur une machine virtuelle. Dans cette optique, créer un driver 16 bits ne te servirait malheureusement à rien.

Dans le sujet que je t'avais proposé, tu as des pistes intéressantes mais, à part celle de Sub0 (passer par un programme d'interface dédié), elles nécessitent toutes un compilateur 32 bits. Passer de BP7 à Free Pascal ou Virtual Pascal, par exemple, ne devrait pas te poser trop de problèmes.

[Transgarp]

@Alcatîz

Free Pascal ou Virtual Pascal permettrait vraiment d'écrire ou lire dans les ports sans autre modification pour exécuter le programme sous XP ?

Nul besoin de réécrire tout le code du programme d'Interface domotique ?

Delphi 6.0 le pourrait il aussi ?

Je sais bien que BP7 est limité à 16 bits, de là son incapacité d'écrire dans des adresses mémoire 32 bits.

Pour NTVDM.exe , oui il m'est apparu sous XP en citant des codes d'erreurs que j'ai vite corrigé par la suite.

Crime que la programmation était plus simple du temps que je programmais en Fortran en 1975 sur des cartes perforées

Faut toujours s'adapter à des nouvelles méthodes.

[droggo]

Fio,

@Alcatîz

Free Pascal ou Virtual Pascal permettrait vraiment d'écrire ou lire dans les ports sans autre modification pour exécuter le programme sous XP ?

Nul besoin de réécrire tout le code du programme d'Interface domotique ?

Delphi 6.0 le pourrait il aussi ?

Je sais bien que BP7 est limité à 16 bits, de là son incapacité d'écrire dans des adresses mémoire 32 bits.

Pour NTVDM.exe , oui il m'est apparu sous XP en citant des codes d'erreurs que j'ai vite corrigé par la suite.
...

Faut toujours s'adapter à des nouvelles méthodes.

Ben oui, et à la vitesse d'évolution de l'informatique...

Je crois que tu aurais intérêt à faire l'effort de refaire ton programme pour utiliser les machines modernes (au moins en 32 bits, même si désormais la majorité des machines vendues sont des 64 bits [hélas, généralement bridées par l'utilisation d'un OS 32 bits, la honte]).
Cela ne devrait pas t'empêcher pas de récupérer une partie du code, mais après tout, ne connaissant pas ton code, je ne m'avancerai pas plus.

Crime que la programmation était plus simple du temps que je programmais en Fortran en 1975 sur des cartes perforées

Je ne dirais pas de même : adieu les temps d'attente pour savoir si tout est ok (le va-et-vient avec les perfos, la compilation rejetée, ...) et toutes les contraintes qu'il y avait, ne serait-ce que pour obtenir les résultats une fois le programme corrigé, mais lancé plus tard dans la file, attendre l'impression...

Bref, la micro nous a vraiment fait changer d'époque et de méthode de travail.

[Transgarp]

Bien évident que la micro nous a facilité l'accès à l'informatique.

Le mammouth mainframe IBM à transistors de 16K ram de $500,000.00 que j'utilisais en 1975 nétait pas vraiment pratique d'utilisation pour mes études collégiales, une simple erreur de frappe sur la perforatrice et fallait recommencer à écrire le code. Facile à écrire sur le papier malgré tout.

Quand même pas gratuit mon premier IBM-PC que j'ai payé $4,000.00 en 1984 avec un extra de luxe qu'était le lecteur de disquette double-face de 360K qui m'a couté un surplus de $400.00

Mais j'étais autonome et je pouvais programmer et bidouiller ce que je voulais.

En 1986 j'ai commencé à étudier les circuits de la carte-mère et je me suis servis du timer 8255 pour me batir une carte d'interface pour mon système domotique qui est devenu opérationnel en 1988 et roulait sous IBM Basica à l'époque.

En 1990 j'ai tout traduit en BP7 et tout roule sans faille depuis, à part mon petit essai sous XP, pour revenir vitement à W98 en attendant.

[droggo]

Fio,

Eh oui, tout ça évolue.

Et si tu n'adaptes pas ton programme, il finira par devenir inutilisable, car aucune machine ne pourra le faire tourner, c'est pourquoi je te conseille de le faire.

[Transgarp]

En passant droggo tout mes programmes compilé BP7 pour DOS tourne facilement sous XP sur des bi-Xeon Asus PC-DL et NCCH-DL

Je n'ai qu'un seul programme qui n'arrive pas à écrire dans les ports de l'ordi sous XP et que je dois faire fonctionner sur un vieux P3 que j'ai monté W98

Quand même, faut pas charier, je programmais avant que la majorité de ce forum soit dans les pensées de leurs parents

Mettons que je suis pas mal paresseux pour traduire mes programmes avec les nouvelles plate-formes et que je préfère mettre mon temps libre à rouler en moto et faire des videos de helmet cam.

Je pensais obtenir une recette facile pour le problème de l'adressage mémoire en m'inscrivant ici, je me suis peux-être planté.

[droggo]

Fio,

Ton problème est directement lié aux OS modernes, qui tendent de plus en plus à protéger les accès au matériel, et la preuve que tu commences à avoir des problèmes est que tu as au moins celui-là.
Ce n'est pas si simple à résoudre en se contentant de persister à utiliser des programmes 16bits.

D'autre part, même pour tes autres programmes, rien, absolument rien ne peut garantir qu'ils fonctionneront avec les OS à venir. Bien au contraire, il est clair que ça te posera de plus en plus de problèmes.

Si tu as la flemme de t'y mettre, ou que tu préfères faire autre chose, je le comprends très bien, mais cela ne nous concerne pas. Il n'y a pas de magie en programmation comme ailleurs : ça ne se fera pas tout seul.

[Transgarp]

IPG va très bien sur le P3 CUV4X avec W98

GPG fonctionne sous XP avec le bi-Xeon NCCH-DL, j'ai limité à 2147483647 d'individus, en fait j'utilise la variable LongInt qui me limite à ce nombre et à un rythme de 10,000 nouveaux individus par année pour un nombre actuel de 150,000 individus, il me faudrait vivre encore 185 ans pour que le programme arrive à la limite

[droggo]

Fio,

IPG va très bien sur le P3 CUV4X avec W98

GPG fonctionne sous XP avec le NCCH-DL, j'ai limité à 2 milliards d'individus, en fait j'utilise la variable LongInt qui me limite à ce nombre et à un rythme de 10,000 nouveaux individus par année pour un nombre actuel de 150,000 individus, il me faudrait vivre encore 185 ans pour que le programme arrive à la limite

Il ne s'agit pas des limites que tu as mises dans tes programmes, mais du fait que tu auras de plus en plus de mal à avoir une machine et un OS assurant leur fonctionnement.

[Transgarp]

Je monte tout mes PC depuis plus de 20 ans.

Mon IBM-PC et le IBM-XT286 sont encore fonctionnel ainsi que mes 4 ordis du réseau que j'utilise à tous les jours et les 4 autres ordis encore fonctionnel qui ramasse la poussière et toutes les pièces d'ordis qui traine dans la maison

Je me suis aussi amusé sur un de mes P2 à installer Vista et tester ce qui fonctionne ou pas en programme compilé BP7

En plus c'est incroyable le nombre de marchands de pièces usagés d'ordis qu'il existe au Québec, de quoi rouler encore 100 ans sur ces vieilles machines.

Ah oui, je roule avec une Triumph Bonneville 1967 en parfait ordre de marche avec une facilité incroyable pour de nouvelles pièces

[droggo]

Gie,

Si tu y tiens, c'est clairement toi que ça regarde, mais alors, évite de te plaindre "Ouin, ça marche plus".

[Transgarp]

Je me plains de quoi ??

Je ne fais que discuter et parler pour parler, c'est interdit ?

En passant, je suis en train de tester FreePascal que j'ai d/l à partir de ce site Oueb, je verrai bien ce qu'il a dans le ventre

[Alcatîz]

Un conseil pour passer à Free Pascal : l'EDI Dev-Pascal est beaucoup plus agréable à utiliser que l'EDI natif :
http://www.bloodshed.net/devpascal.html
Il faut tout-de-même télécharger ensuite la dernière version stable de Free Pascal :
http://www.freepascal.org/download.var

Attention toutefois : l'accès direct aux ports ne sera pas plus autorisé par le système que sous BP7 : tu devras passer par l'API ou une librairie spécialisée, comme précisé dans l'autre fil de discussion. D'où l'intérêt de disposer d'un compilateur 32 bits comme Free Pascal.