Salut,

L'effet de bord, c'est ce que tu as très bien expliqué avec les caches de segment !
Car en effet, pour ne pas aller en permanence relire la gdt, le cpu garde les segments en cache. En théorie, cela n'est sensé rester actif après être revenu en mode réel. Apparement, sur une machine réel, le cache n'est pas vidé. Mais c'est un effet de bord.

Un autre exemple d'effet de bord, serait de prend un registre tel que ax par exemple, lui affecter 65535, la valeur maximum, puis de l'incrémenter de 1. L'effet de bord sera que le registre reviendra à 0.

Le compteur, on dit plutôt le timer. Me rappelle plus du numéro de PIC non plus.
Pour ce qui est du système de fichier, la FAT12, FAT16 et FAT32 possède quelques avantages pour commencer : C'est simple à comprendre et à implémenter, et beaucoup d'outils existe pour vérifier la valider des FAT.

Oublie pas le DMA pour les accès disquettes et disques dur. Mais un conseil, travaille avec une machine virtuelle, si possible qemu, avec gdb connecter pour déboguer par exemple. C'est vraiment pratique. Et pour pouvoir retrouver les symbols du code (Les labels en assembleur), je te conseille de compiler un objet de type ELF en parallèle du binaire et de charger ce dernier ELF dans gdb.

Enfin, je te recommande chaudement de passer au C pour coder ton OS, c'est vraiment plus productif et plus efficace.

Si tu veux, envoie moi ton mail par mp, nous pourrons continuer à discuter tranquillement.

En effet, c'est une bidouille, qui marche par hasard sur la plupart des PC réels, mais ça ne doit pas être exempt d'effet de bord. C'est probablement dû aux systèmes de caches mémoire et compagnies.

Évidemment, quand tu passe en 32/64 bits, tu peux plus compter sur le BIOS, et il faut coder tous les drivers. D'un autre coté, c'est un challenge amusant ;)

Tu n'as pas besoin de modifier le registre cr0 alors. Je n'avais pas vu que tu activais le mode protégé avant de... le désactiver. C'est inutile. Ne me dis pas que t'espère que cs reste en mode protégé. C'est un effet de bord sur les machines réelle, pas dans les émulateurs.

Par contre, tu peux effectivement passer en mode protéger, mais ne pas activer le mode 32 bit du cpu. Ainsi, tu reste en mode réel, mais avec des adresse 32 bit... jusqu'au moment où tu feras un farjump avec selecteur de segment.

Salut,

Dans SYST.ASL:

Le passage en mode protégé peut être corrigé comme suis :

Original :

mov cx,8
mov eax,cr0
mov ebx,eax
or ebx,1
jmp $+2
mov cr0,ebx ;passe en mode protégé
mov ds,cx
mov es,cx
mov fs,cx
mov gs,cx
mov cr0,eax ;mode en mode réel flat ;
               ^^^^^^^^^^^^^ Ceci ne veut rien dire, le mode flat, c'est une organisation de la mémoire qui consiste à avor deux segement englobant chacun toute la RAM, un pour le code, un pour les données. En réalité à ce moment là, tu demande au CPU de passer en mode protégé, c'est à dire que tu va pouvoir profiter des fonctionnalités de droits et autres sur les pages mémoires.
jmp $+2

Correction:

; Indique au CPU de passer en mode protégé.
mov eax, cr0
or ax, 1
mov cr0, eax

; Réinitialise le segment de code.
; un jmp $2 marche aussi, mais je trouve plus propre d'indiquer clairement ce que l'on fait.
; Ce saut va forcer le processeur à vérifier le registre cs, et charger dedans le segment de code comme définit dans la gdt. Nous avons donc accès  à 4go de ram, tout en étant encore en mode d'instruction 16bits.
jmp .CS_OK
.CS_OK

; Mise en place des selecteurs de DS, ES, FS, GS et SS.
mov ax, 8
mov ds, ax
mov es, ax
mov fs, ax
mov gs, ax
mov ss, ax

; Plus bas, le "jmp 1000h:0000h" passera le CPU en mode d'instruction 32 bit.

Au sujet de tes problèmes de boot dans un émulateur, essaye d'intervertir l'ordre du chargement de la GDT et l'activation de la ligne A20. Cela parait complètement irrationnel, mais un vague souvenir d'avoir eu ce problème.

Le temps passe, le code reste...
Mieux encore : le code reste que le temps trépasse...
J'suis déjà partit ======> []

(Errata : C'est pas jolier mais joliet)

Je crois que http://freshmeat.net/projects/cdrecord/ est interessant.
C'est un logiciel console, qu'il est donc facile d'appeler depuis sont propre programme. En plus comme c'est GPL, je suis sûr que tu peux te permettre le luxe d'intégrer le code qui t'interesse dans ton application :D

@+

En fait, il faut convertir soi même les nom en iso standard, puis rajouter si besoin est des descripteur comme rockdrige (linux extention, libre) ou jolier (microsoft, proproétaire).

Je vous conseille plutôt d'utiliser une libraire open source, ça serat beacoup simple au final, et ça merchera mieux, avec beaucoup plus d'option !

Un language bien écrit se lit aisément...

A bon entendeur...

XOR AH,AH est effectivement plus rapide.
En terme de taille d'octet, j'ai la flème de vérifier, mais bon, à pars pour un boot sector, c'est pas vital.

Le RET est donc fonctionnel pour un programme DOS .COM car il y a déjà les valeurs de retour de RET dans la pile pour terminer le programme. Dans le cas d'un programme DOS .EXE, il faudra effectivement utiliser :
MOV AX,4C00h
INT 21h

Quand je dis plus cours, c'est juste à cause du RET, qui remplace la deux lignes de sortie de code .EXE par une seule...

C'est donc une ligne de moins à taper ;)

@+

Oui, tu comprend bien.
En fait, la FAT12 fais environs 16 Mo max (Avec des cluster de 4ko).
La FAT16, 500 MO (Avec des cluster de 4ko)
Et la FAT32 32 go max (Avec des clusters de 4ko).

Donc, microsoft à établit quelques règles :
FAT12 < FAT16 < FAT32
16MO < 500MO < 32GO

Bien sûr, il est possible de faire un FAT32 de 30 mo !
Mais pas avec les outils DOS standard.
Avec les outils linux, tu peux choisir manuellement si tu en à envie.
- Les petites choses qui font que je ne regrette pas d'être passé à linux ;) -