Quand je parlais des variables et des processeurs, je ne parlais pas des architectures actuelles, mais du eSAC ! Je me doute que les processeurs 80386 sont différents bien sur !
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Quand je parlais des variables et des processeurs, je ne parlais pas des architectures actuelles, mais du eSAC ! Je me doute que les processeurs 80386 sont différents bien sur !
Donc, eSAC n'utilisera pas de bus d'adresse et de données ?
Comment va-t-elle communiquer avec l'extérieur, alors ?
architecture est un abus de langage, je dirais plutôt implémentation.
pour ce qui est de tester cette implé, la route est longue, et passe par l'emulation.
Évite de penser que le programme vient au CPU ou que le CPU va chercher le programme dans la RAM. Dans ce contexte, programme ne veut rien dire, il faut plutôt se concentrer sur l'idée d'instructions à aller chercher dans un segment de la RAM.
Ton CPU doit alors, par un moyen ou un autre, avoir connaissance de l'adresse mémoire (RAM) de l'instruction à exécuter (un pointeur d'instructions quoi), afin qu'il puisse aller la chercher (tout ça via les bus qu'Obsidian a évoqué) pour pouvoir l'exécuter.
Que tu le veuilles ou non, ce pointeur doit être un registre (ne sois pas assez tordu pour vouloir mettre ce pointeur dans la RAM, là ça serait vraiment bizarre).
Il va de soi que tu dois trouver le moyen d'incrémenter ensuite la valeur contenue dans ce pointeur d'instruction, sinon il exécute qu'une seule instruction en boucle !
Et le truc, c'est comment connaître l'adresse initiale (adresse qui contiendra la première instruction d'un programme) ?
Et là, je n'ai parlé que du segment qui contient les instructions. Bonne chance pour le segment de donnée, le segment de pile et le segment de tas (bon, le principe reste un peu le même : les pointeurs !).
Au début, je pensais que tu avais conscience de tout ça, mais je te conseille vivement de suspendre ton projet (pas l'abandonner, juste le suspendre) en attendant d'acquérir les connaissances manquantes. Puisque tu as, visiblement, une réelle motivation qui est ton projet, tu devrais bien t'en sortir dans l'apprentissage.
Que tu sois au collège peut peut-être être handicapant dans certains cas, mais d'ici que tu aies une bonne maîtrise de tous les concepts, tu seras sûrement déjà au lycée !
Je conviens que je ne connait pas la technologie des processeur 80386 et autres sur le bout des doigts ; par contre, ce dont je suis sur, c'est que les instructions d'un eSAC viennent au processeur, depuis la RAM. Elle est lue en séquence, et lorsqu'elle est terminée, elle retourne au début. Ce qui ne risque pas d'arriver, vu qu'il y a pleins de sauts conditionnels à faire.
Pour un périphérique tel que le Disque Dur, si jamais un jour il en existera un sous eSAC, le secteur boot, similaire à la technologie actuelle, sera automatiquement lu, et chargé en mémoire. A partir de là, on pourra lancer un kernel, lu depuis le disque dur jusqu'à la RAM.
Mais bon, je n'en suis pas encore là!
C'est effectivement comme cela que fonctionnent TOUS les micro-processeurs actuels.Envoyé par nono17pero
C'est déjà comme cela que ça marche : ton micro-processeur, quand il démarre, lit un vecteur de reset à une adresse fixe et déterminée par le constructeur du micro-processeur (ex : http://en.wikipedia.org/wiki/Reset_vector) et saute immédiatement à l'adresse qui y est indiquée.Pour un périphérique tel que le Disque Dur, si jamais un jour il en existera un sous eSAC, le secteur boot, similaire à la technologie actuelle, sera automatiquement lu, et chargé en mémoire. A partir de là, on pourra lancer un kernel, lu depuis le disque dur jusqu'à la RAM.
Cette adresse, sur PC, est celle du point d'entrée du BIOS : un micro-programme écrit en mémoire non-volatile (ROM) qui contient juste ce qu'il faut pour faire des accès élémentaires à l'écran, au disque, et à quelques périphs. BIOS signifie à la base Basic Input/Output System, même si certains deviennent aujourd'hui très sophistiqués. De là, ce BIOS lit un seul secteur, le premier, qui sur un disque dur est un secteur ordinaire. C'est uniquement le format défini par le PC qui en fait un MBR. Le disque dur lui-même n'a même pas de notion de partition. Et ce BIOS charge donc ce secteur à une adresse toujours fixe : 0000:7c00, et saute vers cette adresse. À charge de ce qu'il y a dedans de charger une partie un peu plus longue pour, ensuite, préparer le démarrage du système entier.
Ce qui est plus probable, à terme, c'est que l'on cesse d'utiliser des périphériques de stockage internes (même SSD), pour développer de la RAM non volatile en quantité massive. À ce moment, il n'y aura plus besoin d'aller « charger » quelque chose en RAM, puisque tout s'y trouvera déjà. Mais alors, un telle technologie pourra d'ores et déjà être utilisée avec les processeurs actuels.
Je suppose que les PC sur lesquels tu travailles n'ont même plus de lecteur de disquette, auquel cas ça devient difficile de se faire une idée claire de ce qui relève du périphérique de stockage et de la mémoire proprement dite.
En tout état de cause, personne ici n'essaie de te décourager. Le fait de soutenir la critique sur plusieurs pages et surtout de répondre autant que tu le peux à toutes les interrogations que les gens du métier se posent sur le produit que tu promeus te permettra sans doute, un jour, de soutenir une thèse ou de mener à bien un projet industriel. Sans ironie, je suis réellement curieux de savoir comment tu vas t'y prendre (je veux dire par là : quelle approche tu comptes adopter).Mais bon, je n'en suis pas encore là
Mais avant cela, il est nécessaire, puisque la discipline semble t'intéresser, que tu explores en profondeur ce qui existe déjà, tant au niveau hardware qu'au niveau système. Dans une certaine manière cela dit car tu es à un âge où il y a d'autres choses à apprendre. L'informatique peut absorber une personne toute entière dès le plus jeune âge si l'on n'y prend garde.
D'autre part, l'informatique avance vite et il y a bien assez à apprendre au quotidien pour rester dans la course sans se tourner vers des vieilleries mais — malgré tout — si tu as l'occasion de trouver un vieux 8-bits de ceux qui ont fait notre adolescence, je t'encourage à essayer. Débuter l'informatique aujourd'hui, c'est un peu comme apprendre à voler sur A380. Les principes sont les mêmes, mais ils sont complètement déformés par la démesure de l'appareil, par les équipements de pointe et par l'objectif visé. Du coup, les concepts fondamentaux sont masqués, et apparaissent plus compliqués qu'ils ne le sont en réalité.
N'empêche que je suis toujours curieux de savoir comment, techniquement, tu vas mettre au point un circuit capable d'aller lire une case mémoire et d'aller la réécrire dans une autre sans utiliser un registre interne…
pas mal l'analogie de l'A380... j'adhère.D'autre part, l'informatique avance vite et il y a bien assez à apprendre au quotidien pour rester dans la course sans se tourner vers des vieilleries mais — malgré tout — si tu as l'occasion de trouver un vieux 8-bits de ceux qui ont fait notre adolescence, je t'encourage à essayer. Débuter l'informatique aujourd'hui, c'est un peu comme apprendre à voler sur A380. Les principes sont les mêmes, mais ils sont complètement déformés par la démesure de l'appareil, par les équipements de pointe et par l'objectif visé. Du coup, les concepts fondamentaux sont masqués, et apparaissent plus compliqués qu'ils ne le sont en réalité.
pour ce qui est d'apprendre l'assembleur, si tu as un PC, avec un système qui accepte de faire tourner une sorte de DOS (émulation du mode réel), à savoir XP, 98, NT, 2000, me, MSDOS, FREEDOS, DEXOS, etc... tu pourras apprendre assez facilement le vrai assembleur.
j'entends par là qu'il te faut être en mode réel pour avoir une certaine liberté de mouvement. ce qui n'est pas le cas en mode protégé.
donc, déjà, voilà deux missions pour toi:
mode réel
mode protégé.
après, tu pourras passer à la suite, à savoir, tenter de modéliser ton idée et te faire une vraie opinion de ce que sera ton CPU. quitte à abandonner l'idée de ne pas avoir de registres.
il ne faut pas voir les registres comme de la mémoire ou une sorte de bride, au contraire, le registre, c'est disons, la mémoire temporaire de l'écrivain, celle qui lui permet de transformer rapidement une idée (mémoire) en mot (temporaire, du vent, les paroles s'envolent), qui ensuite sera stocké sur papier comme si c'était un disque dur.
le fait que l'analogie de l'écrivain soit si exacte est qu'en vérité, l'ordinateur, c'est rien de plus qu'une simulation electronique de ce qu'il se passe au niveau de notre pensée.
les concepteurs de CPU ne sont pas trop idiots je crois, et tout ce que nous avons déjà essayé de penser, il y a bien longtemps qu'ils l'ont crée.
moi aussi j'en suis curieux, le registre, comme je viens de le dire, c'est la mémoire temporaire, celle que lorsque tu penses à une chose, tu oublie aussitôt, comme par exemple, les résultats intermédiaires d'une raisonnement ou d'un calcul mental...N'empêche que je suis toujours curieux de savoir comment, techniquement, tu vas mettre au point un circuit capable d'aller lire une case mémoire et d'aller la réécrire dans une autre sans utiliser un registre interne…
fais le test, tu verras, à part si tu t'amuses à te forcer à mémoriser les résultats intermédiaires d'une grosse opération (par exemple, 345*10+432+5445), tu risque fort de tout oublier sitôt le résultat définitif trouvé... on appelle ça les registres dans un ordinateur. et il n'y a aucune honte à s'en servir.
d'ailleurs, lorsque l'on lit un bouquin, en général, on remarque vite que l'on ne se souvient que de quelques bribes de texte, le reste étant passé à la moulinette de nos registres du cerveau pour se changer en idée générale.
donc, au boulot, apprend à coder en mode réel, puis en mode protégé, puis en boot, puis continue jusqu'à arriver au niveau qui te permettra de coder l'émulateur de ton idée.
mais ne te tiens pas trop à l'idée de base, les idées de débutants sont souvent bien trop utopistes et manquent sérieusement de connaissances pour être pertinentes.
Cest qu'au début, je voulais programmer un OS, mais je n'ai pas trouvé assez de sources d'informations, j'ai abandonné.
Par exemple, pour l'Assembleur, à peu près tous les cours disent la même chose, et tout reste toujours un peu flou.
Et j'ai regardé pour les OS, mais je n'ai pas trouvé de cours, ni de normes de système de fichier par exemple...
Enfin bon, si il en existe que je n'ai pas vue, pourquoi pas...
tu as pas du beaucoup chercher je pense.Cest qu'au début, je voulais programmer un OS, mais je n'ai pas trouvé assez de sources d'informations, j'ai abandonné.
Par exemple, pour l'Assembleur, à peu près tous les cours disent la même chose, et tout reste toujours un peu flou.
Et j'ai regardé pour les OS, mais je n'ai pas trouvé de cours, ni de normes de système de fichier par exemple...
Enfin bon, si il en existe que je n'ai pas vue, pourquoi pas
odev.org par exemple, est une ressource presque indispensable (en anglais), avec un wiki spécialisé dans la programmation d'OS justement.
comme tu es collégien, j'imagine que ces ressources te sont difficiles à exploiter, donc, ta mission, apprendre l'anglais par la pratique, tu verras, c'est d'un simple l'anglishe technique, affolant, à croire qu'ils ont volé tout les mots au français en les inversant (swap eax).
et surtout, n'oublie pas, pour les OS, pour coder des OS, et concevoir des CPU, il y a deux choses essentielles et indissociables qui font la différence entre celui qui y arrive, et celui qui n'y arrive pas:
1/ l'imagination et l'esprit pratique
2/ les bases et les techniques.
sans ça, c'est foutu.
et je dirais même que lorsque tu as toutes les connaissances et techniques assimilées, la chose la plus essentielle, c'est l'imagination.
c'est vraiment ça qui fera la différence au final.
Écrire un vrai système d'exploitation, c'est passionnant, mais c'est probablement ce qu'il y a de plus compliqué (et chiant, à terme) en informatique. Certes, cela ne demande pas d'être aussi pointu et industriellement développé que pour produire une puce, mais c'est extrêmement long. Par exemple, il y a des milliers de personnes qui travaillent uniquement sur le noyau Linux depuis 20 ans, maintenant.
Par contre, tu peux essayer de faire un proto-O.S, c'est-à-dire quelque chose qui démarre tout seul (sans l'aide de DOS, de Windows ou de Linux) et qui soit capable de réaliser de menues actions, comme proposer une ligne de commande à l'utilisateur. Ça demande déjà beaucoup de travail en soi, mais c'est faisable, et c'est pour cela qu'il y a même un forum dédié ici.
Mais si tu veux te lancer dans le développement d'O.S. ou simplement de composants pour améliorer ceux que tu utilises au quotidien, alors il faut déjà te plonger dans les modèles des O.S. existants.
Je ne saurais trop te conseiller, même si on s'éloigne un peu de l'assembleur, de te trouver une distribution de Linux. Il y a un vieil adage attribué à Henri Spencer qui dit « Those who do not understand Unix are condemned to reinvent it, poorly », soit « ceux qui ne comprennent pas Unix sont condamnés à le réinventer, en moins bien », et je pense que c'est vrai, même s'il y a eu beaucoup de travail fait du côté de Windows ces dernières années. J'ai moi-même arrêté de caresser l'idée de développer un O.S. le jour où j'ai commencé à y mettre le doigt, car je me suis aperçu que tout ce à quoi je pouvais penser avait déjà été plus ou moins réalisé.
D'autre part, avantage non négligeable, Linux et ce qui va autour (GNU) est un logiciel libre et tu disposes de tout le code source jusqu'au plus fondamental, même s'il est en langage C et pas en assembleur.
Dans un premier temps, fais une recherche avec « architecture des ordinateurs » et choisis le document qui te convient le plus (la plupart d'entre eux ont tendance à faire la genèse de l'informatique et à noyer le lecteur) ;Et j'ai regardé pour les OS, mais je n'ai pas trouvé de cours, ni de normes de système de fichier par exemple... Enfin bon, si il en existe que je n'ai pas vue, pourquoi pas
Ensuite, je t'encourage à regarder un peu comment fonctionne le 6809, dont voici la table des instructions dans la spécification officielle. Le tableau que tu y vois a été photocopié tel quel dans tous les manuels et, personnellement, je n'ai rien vu de plus clair (si on passe sur le fait que le scan donne un aspect « fax » au document, ce qui le rend peu lisible).
On voit clairement les instructions sur la gauche, déclinées dans la colonne qui suit dans ses versions possibles et, « orthogonalement », les modes d'adressage du CPU au sommet de la table. On voit clairement à quel moment tel ou tel mode est utilisable, à quel moment il ne l'est pas (généralement parce que ça n'a pas de sens), et on voit également que chaque déclinaison correspond en fin de compte à un code-opération donné. Ce qui, en soi, en fait en réalité plusieurs instructions distinctes.
Après, ce serait bien que tu aies une petite machine qui utilise ce CPU. Si tu pouvais te trouver un MO5 en état de marche pour pas cher, par exemple, le BASIC serait déjà en ROM, il n'y aurait aucun temps de chargement (comme pour les consoles… de jadis), et tu pourrais en plus faire des POKE directement en mémoire et voir le résultat s'afficher à l'écran. Mais d'ici là, tu peux déjà trouver un simulateur 6809 sur le Net.
Une fois cela maîtrisé, tu t'apercevras qu'à part certains concepts tels que le mode protégé, un x86, c'est la même chose en plus gros (et plus rapide).
À part cela, as-tu déjà l'habitude des portes logiques et de la logique combinatoire en général ?
ho ! un 74xx03 !!
que de souvenirs...
Sinon, le plus chiant pour coder un OS, c'est la gestion des périphériques comme l'USB.
J'ai fait quelques programme sans OS sur des machines industrielles (en fait 2 seulement)
Et comme je bute avec cet USB, plutôt que de m'embêter à gérer un clavier
ou une souris USB en direct en mode protégé, j'utilise le modèle FLAT
(mode réel avec segment de 4Go), ce qui me permet d'utiliser le BIOS
pour l'USB (qui gère aussi les clés comme des disques)
j'utilise même les modes SVGA en accès direct à la RAM (E000:0000 ou D000:0000 suivant les cartes graphiques)
Ca reste de la bidouille, mais ça marche, et c'est une sacrée bonne
protection contre la copie
a+ François
Voire même un 7400 tout simple. :-)ho ! un 74xx03 !!
que de souvenirs...
Ça, c'est clair qu'autant les ports parallèle et série, on pouvait les manipuler directement, autant l'USB, ça demande encore plus de travail qu'une carte réseau.Sinon, le plus chiant pour coder un OS, c'est la gestion des périphériques comme l'USB.
D'ailleurs, à ce stade, tu peux même te payer le luxe d'imposer le PC de ton choix, puisque le prix du développement finit dépasse celui de la machine dans le cas contraire…J'ai fait quelques programme sans OS sur des machines industrielles (en fait 2 seulement
pour l'USB (qui gère aussi les clés comme des disques)
À l'époque où c'était encore normalisé. Il faudrait ré-établir un mode BIOS haute résolution aujourd'hui…j'utilise même les modes SVGA en accès direct à la RAM (E000:0000 ou D000:0000 suivant les cartes graphiques)
L'obsolescence est une bonne protection également. Même avec de bons émulateurs, ça devient difficile de lancer les programmes DOS de l'époque…Ca reste de la bidouille, mais ça marche, et c'est une sacrée bonne
protection contre la copie
la norme vesa est ce que l'on pourrait appeler la norme VGA moderne.
de plus, avec la norme VESA (que je m'en doute, vous n'ignorez pas), la revision 3 permet de gerer plusieurs ecrans, et plusieurs buffers... ce qui est pas mal du tout, sans compter la possibilité de gerer la diffusion d'images 3D (un coup droit, un coup gauche) de manière automatique en passant par deux de ces fameux buffers.
si en plus de ça, on s'amuse à utiliser un des modes unreal, dpmi et autres hybrides mode reel/protegés, nous pouvons directement utiliser les interruptions BIOS de gestion de l'ecran.
evidement, ça reste très lent comparé à l'execution direct driver... mais là encore, c'est une autre histoire.
pour ce qui est du dev usb, vraiment, je deteste cette norme, pas pour l'application super qu'il en decoule, c'est vraiment super de pouvoir brancher un scanner, le debrancher, brancher une clé usb à la place, et ainsi de suite.. cette norme, je l'ai en horreur pour la simple raison que l'organisme de normalisation usb agit comme un apple, il à le culot d'imposer un VID/PID payant à tout les fabriacants, il à aussi le toupet d'imposer des protocoles connexes (en dehors du fonctionnement pur et dur) à tout materiel, ce qui se traduit en de l'overbloat forcé.
pour ce qui est de la nouvelle architecture, je pense que si nous (codeurs experimentés) essayons d'en inventer une, il se pourrait qu'elle soit bien, interressante et compagnie, mais elle ne sera surement pas plus qu'un petit projet sans espoir de sortir du cadre purement passionel.
il faut penser au contexte dans lequel les technologies evoluent, un contexte fortement influencé par les parts de marché, les dinets de gala et les relations mondaines.
l'avenir de nombre de nos technologies se decident très loin des bureau d'etudes, lors de ces fameux banquets de l'ile de rhode island, et sont decidés par des personnes n'ayant probablement aucune connaissance en informatique ni en electronique. donc...
Oui, mais même VESA commence à avoir de l'âge. Cela dit, j'avoue que ça fait bien longtemps que je ne suis pas allé voir ce qu'elle est devenue.
Pour les vendor class, je n'ai pas réussi à trouver une liste précise, mais il serait étonnant qu'il n'y ait pas de classe « locale », sauf à promouvoir leur achat et éviter que tout le monde adopte la même, ce qui, techniquement, pénaliserait beaucoup le système USB. Ça se tient quand même. Par contre, il est possible d'obtenir temporairement des classes de test et j'ai lu que le premier prix commence à 2000 dollars, ce qui reste abordable même pour un particulier. Ce n'est pas tellement différent d'acheter une plage d'adresses IP publiques…pour ce qui est du dev usb, vraiment, je deteste cette norme, pas pour l'application super qu'il en decoule, c'est vraiment super de pouvoir brancher un scanner, le debrancher, brancher une clé usb à la place, et ainsi de suite.. cette norme, je l'ai en horreur pour la simple raison que l'organisme de normalisation usb agit comme un apple, il à le culot d'imposer un VID/PID payant à tout les fabriacants,
De quels protocoles connexes parles-tu ?il à aussi le toupet d'imposer des protocoles connexes (en dehors du fonctionnement pur et dur) à tout materiel, ce qui se traduit en de l'overbloat forcé.
Si ce sont les classes de périphériques, personne ne t'oblige à les suivre mais c'est quand même idiot. Si c'est le protocole sous-jacent à la gestion du bus USB lui-même, alors c'est comme concevoir une carte réseau. C'est parce que le périphérique les gère qu'il peut être énuméré et que leur gestion par l'utilisateur final est si facile.
Ça, malheureusement, c'est vrai. Non pas que je regrette cela en soi, car c'est un travail qui doit également être fait. Par contre, notre pays a été jadis très à la pointe dans les domaines techniques. Aujourd'hui, c'est pratiquement devenu ringard et on apprend carrément à certains ingénieurs à ne plus s'y pencher. Moralité : un plan national d'abandon du savoir-faire…l'avenir de nombre de nos technologies se decident très loin des bureau d'etudes, lors de ces fameux banquets de l'ile de rhode island, et sont decidés par des personnes n'ayant probablement aucune connaissance en informatique ni en electronique. donc...
les protocoles connexes à l'usb sont ceux qui n'ont aucun lien direct ni avec l'application, ni avec la nrome usb.
je dirais, pour ne pas entrer dans des details que je ne connais pas, et donc pour ne pas dire de co**erie, qu'il s'agit principalement de la gestion d'erreurs qui n'arrivent jamais, car improbables, par exemple, une erreur de bus decoulant d'une erreur materielle n'a pas à être gerée, la première etant déjà suffisante pour déclarer le materiel HS.
pour ce qui est du VESA sur des machines récentes il y aurait moyen de faire quelque chose mais il ne prennent pas en compte les résolutions autres que celle du 4:3(sur les cartes video que j'ai testé) ce qui rend moche sur nos écrans moderne en 16:9 et en 16:10
par contre je n'ai pas trouvé trace sur la norme 3 pour la gestion de plusieurs écran, si c'est vrais je doit vite me renseigner la dessus
le vesa permet aux fabricants de cg de definir leurs propres modes.
pour les exploiter, il faut d'abord identifier les modes supportés, qui sont variables d'une carte à l'autre.
puis suite à ça, recuperer les données relatives à la géometrie prise en compte par le DAC.
cette geometrie peut etre de n'importe quelle forme, tant en 4/3 qu'en 16/9 ou autres, il suffit juste de trouver le mode correspondant à la resolution de l'ecran, et là aussi, vesa à prevu le coup en fournissant une fonction qui retourne la resolution de l'ecran branché sur chaque canal de la CG.
la norme VESA3 est la plus aboutie, mais VESA4 ne saurais tarder, disons au bas mot, d'ici 1 ou 2 ans vu l'ecart de temps qu'il y avait entre chaque version de VESA.
petit HS:
Je viens de faire un test avec mon "bidouillage" VESA en mode FLAT
TEST : affichage de sprites en VESA en accès direct
- machine : ultra portable eeePC1000H (proc à 1.6GHz je crois)
- mode VESA 8bits (peu importe la résolution)
- taille du sprite : 64x64 pixels (4Ko)
Vitesse d'affichage : +6300 sprites par seconde
soit + de 24Mo par seconde
C'est pas si mal je trouve...
Ce que je voudrais faire, côté programmation, c'est un OS tout simple, avec un compilateur, à partir duquel on pourrait programmer le disque dur.
Mais j'ai regardé sur le Net, et généralement, on ne dit pas comment fonctionne un tel programme, on explique juste le principe. Les numéros, les adresses, les normes quoi, je n'en n'ai pas trouvé...
S'il y a un compilateur, ce n'est plus un O.S. « tout simple ». La rédaction d'un compilateur propre est un métier à part entière, pour plusieurs personnes. Regarde la théorie des langages que tu verras à l'université ou en école d'ingénieur si tu suis cette voie.
Tu peux cela dit écrire un petit semblant de compilo qui parvienne quand même à ses fins, mais cela va te demander énormément de temps quand même.
Encore une fois, « programmer le disque dur », ça ne veut rien dire. Un disque dur, ça ne se programme pas. À la limite, tu peux essayer de communiquer avec le contrôleur disque, ce qui serait déjà beaucoup.à partir duquel on pourrait programmer le disque dur.
Essaie de récupérer « la bible PC » si tu la trouves quelque part. Elle est hors d'âge et plus du tout à jour pour les PC actuels, mais les dernières éditions couvraient déjà le Pentium et tout ce qui a perduré, finalement, dans les machines d'aujourd'hui.Mais j'ai regardé sur le Net, et généralement, on ne dit pas comment fonctionne un tel programme, on explique juste le principe. Les numéros, les adresses, les normes quoi, je n'en n'ai pas trouvé...
Est-ce que tu as lu les liens que je t'ai donnés plus haut, notamment la table des instructions du 6809 ?
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager