Bonjour,  
 
en assembleur pur (sans bibliothèque) et sur un pc sans OS, savez-vous comment je pourrais m'y prendre pour gérer une caméra, un microphone et un haut-parleur ? Est-ce possible en communiquant avec le BIOS par exemple ?

C'est pour ton robot? Je te souhaite bien du courage, tu vas en avoir besoin.

Bon, en supposant que tu ne trolles pas (ce dont je doute fortement quand même): C'est infaisable en pratique, à moins d'avoir des connaissances très pointues et vraiment beaucoup de temps et de patience.

Personne ?

Pour ce qui est du son voici deux liens venus d'ailleurs si d'autres se posent la même question : http://wiki.osdev.org/Intel_High_Definition_Audio et http://www.intel.com/content/www/us/...ification.html, me reste à savoir comment gérer la caméra, une idée ?

En assembleur sans OS et sur un PC en plus ? C'est complètement barré comme question , t'en as pour au moins 10 ans à programmer ton truc sauf si tu te contentes de faire couiner le buzzer de la carte mère
Et ça veut dire quoi au juste pour toi "gérer" dans le cadre d'une caméra par exemple ?

Gérer dans n'importe quel cadre veut dire s'occuper de, 10 ans, pour avancer une telle durée est-ce que tu t'y connais suffisamment ? Je suis en train de lire "Assembleur x86" et ces 10 ans je ne les vois absolument pas, je ne vois que quelques mois.

Il n'y a pas vraiment de standards pour les webcam... Il faut que tu "inventes" ton propre pilote et je te souhaite bonne chance...  
En plus au delà du driver de la webcam, il faut pouvoir gérer l'USB...  
Pour le son, idem...
 
bref, c'est infaisable en pratique

Tu dois avoir raison. Vu tes références à wikipédia et tes lectures c'est manifeste que tu maitrises à fond. Tiens nous au courant au fur et à mesure de tes succès, on est impatient de voir comment ça finira.

Meuh non, c'est l'affaire des quelques mois

Quelques mois tout au plus, je ne vois pas comment tu arrives à 10 ans, je fais cette remarque car tout ceux qui m'ont dit que l'assembleur était lent et dépassé pour programmer de grandes structures n'y avaient au final jamais touché ou que très peu.

Lent, certainement pas. Dépassé ? Tout dépend ce que tu veux faire...
Mais vu ta question tu as l'air de maîtriser ton sujet.... Bonne chance alors

Je pense qu'il veut dire "lent à programmer". C'est clair que coder direct en ASM, faut être bien concentré (et motivé !) car on très vite fait de faire une bourde.
 
Quand je vois le temps que j'ai mis en 2ème année d'école d'ingé à coder un petit noyau multi-tâches en ASM (plusieurs semaines). Et encore, il reposait sur MS-DOS (qui est déjà assez bas niveau)
 
Quel est l'intérêt de se passer d'OS Il existe des petits OS qui prennent peu de place en mémoire et qui permettent de pas partir from scratch. Je vois pas l'intérêt de se prendre la tête à recoder des drivers pour piloter un écran, un clavier, une souris, la com USB... alors que ça existe déjà tout fait    
Un OS comme celui fait pour Rasberry Pi, ça devrait faire l'affaire pour de l'embarqué (et c'est pourtant pas le plus petit OS !).
 
https://fr.wikipedia.org/wiki/TinyOS -> il fait 300 à 400 octets et demande 4 Ko de Ram. Ca devrait le faire...

Nous c'était un bête pacman... Une belle galère à coder.

Je pense qu'il devrait aussi refaire le CPU sur un FPGA, l'ASM c'est pour les noobs.

Ben oui, j'ambitionne de coder le prochain GTA avec des portes logiques câblées....

Sur un assez volumineux programme comme une i.a, en assembleur la création de toutes les fonctions comme if, while et de biens plus complexes ne représente même pas un tiers du travail. je ne perds pas tant que ça en réalité.

Pourquoi l'assembleur ? C'est le seul langage qui m'a séduit parmi 4 que j'ai pu essayer.

Tu n'aurais pas des liens de sang avec un certain Valise, prénom Jo ?
 

 
Tu devrais le faire sur du Z80, ça c'est du sport (le M68k est sympa aussi dans le genre)...  
Le truc, c'est que tu veux le faire sans OS.... donc il faudra que tu codes un OS pour gérer toutes les entrées-sorties ainsi que le décodage du flux vidéo pour la caméra (sans parler des drivers pour lequel évidement, il n'y a pas beaucoup de spécifications matérielles...). Tu peux te baser sur une achi libre, mais tu oublis le X86 dans ce cas (Arduino par exemple)...
 
Et sinon, tu as fait quoi en assembleur (ou même dans d'autres langages) ?

T'as regardé quoi comme langages, pour être aussi définitif ? Tu bosses sur quel type de matériel ? Parce que du C bien codé et optimisé, avec un compilo bien paramétré, on n'est en général pas très éloigné des perfs de l'ASM (sur tout si c'est de l'ASM fait par qq'un qui ne le maîtrise pas).

Je me pose exactement la même question depuis qu'il a commencé à poster sur Electronique.
Sa prose est plus lisible que celle de jovalise/par l'anneau de l'IA mais les objectifs sont aussi délirants ambitieux.

Pour les fins connaisseurs, n'existe t  il pas un logiciel qui détermine l'architecture d'un périphérique donné ? En envoyant une série de bit et en regardant ce qui en retourne par exemple ?

Qu'est ce que tu entends par architecture ?

L'architecture, la façon dont fonctionne le périphérique, pour ensuite pouvoir coder son pilote.

La réponse est non, tu ne crois pas que ça serait un peu facile question concurrence ?
(d'où la difficulté d'avoir certains pilotes sur Linux ou BSD...)
 
C'est en partie pour ça qu'on te dit que tu vas dans le mur. Après certains ont réussi (développer un OS), mais il s'agit quasi toujours d'une équipe, sur plusieurs années (et en général, c'est surtout codé en C...)

 
 
Ca a l'air marrant ici

Tiens c'est vrai, ça doit avoir bien avancé en un mois. Terminator est prêt ?

Y'a la suite sur ces 2 topics :
http://forum.hardware.fr/forum2.ph [...] w=0&nojs=0
 
http://forum.hardware.fr/forum2.ph [...] w=0&nojs=0

Si l'auteur du post est vraiment sérieux, pourquoi ne pas chercher des informations :

• sur Github
• contacter ou s'inspirer de ce qui se fait dans la communauté, par exemple : KolibriOS
• en ligne : OSDev, dans la littérature spécialisée : Operating Systems Design and Implementation (3rd Edition), Modern Operating Systems (4th Edition)