Autor Thema: V86 Modus  (Gelesen 7321 mal)

stafe

  • Beiträge: 35
    • Profil anzeigen
    • http://www.staticos.at.tf
Gespeichert
« am: 02. September 2007, 21:08 »
Hallo,

da ich in meinem OS während der Laufzeit den Grafikmodus ändern möchte, habe ich mir gedacht das mit dem Virtual 8086 Mode zu realisieren.
Doch leider sind einige Probleme aufgetreten.

Mein OS kann ring0 und ring3 tasks ausführen ...
Ich habe mal in einem Beitrag gelesen, dass man für einen V86 Task lediglich die EFLAGS ändern muss (0x20002). Dies mache ich wie folgt (Hier der V86 Task Stack):

stackptr=kernstack;
*--stackptr=0x20|3;
*--stackptr=0x20|3;
*--stackptr=0x20|3;
*--stackptr=0x20|3;
*--stackptr=0x20|3;
*--stackptr=(unsigned long)userstack;
*--stackptr=0x20002L;
*--stackptr=0x18|3;
*--stackptr=(unsigned long)startpunkt;
*--stackptr=0x0;    //EAX
*--stackptr=0x0;    //ECX
*--stackptr=0x0;    //EDX
*--stackptr=0x0;    //EBX
*--stackptr=0x0;    //-->ESP kann Null sein
*--stackptr=0x0;    //EBP
*--stackptr=0x0;    //ESI
*--stackptr=0x0; //EDI
*--stackptr=0x10; //ds
*--stackptr=0x10; //es
*--stackptr=0x10; //fs
*--stackptr=0x10; //gs

Ich weiß nicht ob dass so richtig ist ?!

Bochs meldet mir jedoch folgende Fehlermeldungen:

00084951475-i-@00102142-[CPU  ] IRET to V86-mode: ignoring upper 16-bits
00084951478-i-@00000003-[CPU  ] LOCK prefix unallowed (op1=0x53, attr=0x0, mod=0x0, nnn=0)

Es wird unzähligemal folgener Fehler im bochsout.txt angezeigt:

00084951522-e-@00101852-[CPU  ] seg = DS
00084951522-e-@00101852-[CPU  ] seg->selector.value = 0000

Läuft der Task jetzt schon im V86 mode oder kommt beim Versuch in den V86 mode zu schalten der Fehler ??

Ich hoffe jemand hat bereits Erfahrung mit dem V86 mode und kann mir weiterhelfen.

Danke im Voraus

mfG Stafe

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #1 am: 03. September 2007, 00:05 »
00084951475-i-@00102142-[CPU  ] IRET to V86-mode: ignoring upper 16-bits
Könnte es sein, dass dein EIP größer als 64k ist und deswegen diese Meldung kommt?
lightOS
"Überlegen sie mal 'nen Augenblick, dann lösen sich die ganzen Widersprüche auf. Die Wut wird noch größer, aber die intellektuelle Verwirrung lässt nach.", Georg Schramm

stafe

  • Beiträge: 35
    • Profil anzeigen
    • http://www.staticos.at.tf
Gespeichert
« Antwort #2 am: 03. September 2007, 10:59 »
Ich habe das Programm jetzt auf die Adresse 0x500 geladen.
Der Fehler:

00084951475-i-@00102142-[CPU  ] IRET to V86-mode: ignoring upper 16-bits
scheint nun nicht mehr aufzutreten.

Doch es wird trotzdem noch unzählige mal folgender Fehler angezeigt:

00084951522-e-@00101852-[CPU  ] seg = DS
00084951522-e-@00101852-[CPU  ] seg->selector.value = 0000
mfG Stafe

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #3 am: 03. September 2007, 14:12 »
Bei welcher Instruktion tritt denn der Fehler auf?
lightOS
"Überlegen sie mal 'nen Augenblick, dann lösen sich die ganzen Widersprüche auf. Die Wut wird noch größer, aber die intellektuelle Verwirrung lässt nach.", Georg Schramm

stafe

  • Beiträge: 35
    • Profil anzeigen
    • http://www.staticos.at.tf
Gespeichert
« Antwort #4 am: 03. September 2007, 15:59 »
Erstmals danke für deine Antworten ...

Naja ich nehme zum testen des V86 mode folgenden code her:

Dieser Code ist das V86 programm (int 10 aufrufen):

unsigned char opcode[2];
opcode[0] = 0xCD;
opcode[1] = 0x10;
mem_set(0x500, 0, 0xffff);
mem_cpy(0x500, opcode, 0x02);

und anschließend erstelle ich einen V86 Task:

Neuer_Task_vm86( 0x500, "v86task", KERNEL_TASK, NORMAL_PRIORITY );
Zitat
Bei welcher Instruktion tritt denn der Fehler auf?

Ich weiß jetzt nicht genau wie du das meinst?! Der Fehler tritt auf sobald der v86 task ausgeführt wird ...
mfG Stafe

Homix

  • Beiträge: 138
    • Profil anzeigen
Gespeichert
« Antwort #5 am: 04. September 2007, 10:34 »
hi,

probier es doch erstmal mit Befehlen, die weniger machen wie z.B. "jmp $" (= 0xEB, 0xFE).

für Interrupts im V86 Mode brauchst du soweit ich mich erinnern kann einen V86-Handler (im Kernel, der im ProtectedMode im GPF-Handler sitzt), da ein "int 0x10" ein GPF (Exception 13) hervorruft. In dem Handler musst du die Adresse und das Segment dann selbst "hineinschreiben" als Rücksprungsadresse. (im V86-Handler musst du auch DS,ES,.. neu laden, da diese vom V86-Task erhalten bleiben (und DS = 0 im PMode ist ungültig).

Grüsse,
Stefan
« Letzte Änderung: 04. September 2007, 12:54 von stefan2005 »

stafe

  • Beiträge: 35
    • Profil anzeigen
    • http://www.staticos.at.tf
Gespeichert
« Antwort #6 am: 04. September 2007, 15:54 »
Nur leider löst der V86 Task bei einem Interrupt keinen GPF aus sondern bringt unzähligemal den selben Fehler, und Bochs beendet anschließend die Simulation mit einem Page Fault ...
mfG Stafe

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #7 am: 04. September 2007, 18:06 »
Ich denke die Ursache des Problems haben wir im ICQ geklärt, hat auch lang genug gebraucht :-D

Nur um das für andere noch zu erklären: Die CPU setzt alle Segmentregister auf 0 (außer cs & ss) beim Taskwechsel von vm86 -> Ring0. Stafe hat nun ohne die Segmentregister zu setzten einfach DS benutzt. Das hat zu den
00084951522-e-@00101852-[CPU  ] seg = DS
00084951522-e-@00101852-[CPU  ] seg->selector.value = 0000
im Bochslog bei einem Interrupt/Exception geführt.
lightOS
"Überlegen sie mal 'nen Augenblick, dann lösen sich die ganzen Widersprüche auf. Die Wut wird noch größer, aber die intellektuelle Verwirrung lässt nach.", Georg Schramm

stafe

  • Beiträge: 35
    • Profil anzeigen
    • http://www.staticos.at.tf
Gespeichert
« Antwort #8 am: 04. September 2007, 21:32 »
Vielen Dank für deine Hilfe bluecode
mfG Stafe

 

Einloggen