Thema: Textausgabe im PMODE??

[RedEagle]

So ich weiß jetzt auch, wo in etwa der Fehler ist.
Vor dem Wechsel in den PMode ist mit SI noch alle klar; nachher nicht mehr.

ABER WAS IST FALSCH??
ps.: Ich habe den code, so die es in dem PMode-Tutorial steht.

[RedEagle]

Ich hab den Kernel nochmal ganz anders und neu gemacht (und in 16Bit und 32Bit aufgeteilt). Das wechseln in den PMode habe ich mit hilfe eines anderen Tutorials gemacht. Das einzigste, was unverendert geblieben ist, ist die A20Gate - sache, und meine printstr.
Es läuft immer noch nicht -> immer noch der gleiche Fehler
Ich habe allerdings in dem Code eines Anderen OS's gesehen, das die bei der GDT extra noch Was für den VRAM gemacht haben. Ist das notwendig??

UND:
Was für ursachen kann den die Fehlfunktion von ESI haben?? Wonach muss ich suchen??

[RedEagle]

Auch nach fast 3 Wochen habe ich noch nicht ausgegeben...

Ich habe jetzt eine Funktion geschrieben, die mir HEX-Werte ausgibt, um den Fehler genauer zu "untersuchen"
mir ist aufgefallen, das ESI auf eine Bitfolge zeigt, die in meinem Code überhaupt nicht vorkommt (hab mit HEX-Editor danach gesucht)

Hier mal ein ScreenShot (ich hoffe die mit Paint eingefügten Kommentare sind ausreichend)


Ich weiß immer noch nicht, was falsch ist. Ich habe mir schon den Code vom PiratOS; U-OS; ObjectOS und MenuetOS angeguckt, aber da ist es auch nicht viel anders.

Mache ich vieleicht schon beim Kompiliern ein Fehler??
Hier mal eine Kurtzform des Batch-Codes:

Code: [Auswählen]

echo -- Compile Kernel ----------------------
 cd "d:\nasm\"
 nasmw -f bin -o d:\reos\_boot\boot.bin d:\reos\_boot\boot.asm
 nasmw -f bin -o d:\reos\_kernel\kernel16.bin d:\reos\_kernel\kernel16.asm
 nasmw -f bin -o d:\reos\_kernel\kernel32.bin d:\reos\_kernel\kernel32.asm

echo -- MergeKernel -------------------------
 cd "d:\REOS\"
 MergeKernel d:\reos\_kernel\kernelxx.bin d:\reos\_kernel\kernel16.bin d:\reos\_kernel\kernel32.bin

echo -- Create image-file -------------------
 copy d:\reos\_boot\boot.bin + d:\reos\_kernel\kernelxx.bin d:\reos\reos.img

echo -- Copy image-file to bochs ------------
 copy d:\reos\reos.img d:\reos\testumgebung\reos.img

[Jidder]

hi,

esi = 5, 6, 7 bedeutet, dass du auf die IVT zeigst. die zahl 0xFF53F000 könnte sehr gut die adresse F000:FF53 darstellen, und dass sieht aus wie ein zeiger auf einen bios interrupt.

an welche adresse lädst du deinen 32bit kernel und bist du sicher, das du org 0x.... entsprechend gemacht hast?

[RedEagle]

Vom bootloader zum 16Bit Kernelteil

Code: [Auswählen]

; Springe zu diesem Kernel
   mov ax, 0x1000 ; Adresse des Programms
   mov  es, ax   ; Segmentregister updaten
   xor  bx, bx     ; bx auf 0 wegen ES:BX
   ; Jetzt die Anresse des Kernels in den Stack laden
   push ax
   mov ax, 0
   push ax

retf ; und zum kernel springen

Anfang des 16Bit Kernelteils

Code: [Auswählen]

[Bits 16]
;org 0x1000 ; Geht nicht (bochs startet neu)
jmp start

start:
   mov ax, 0x1000 ; Segmentregister update
   mov ds, ax
   mov es, ax
;...

Ende des 16Bit Kernelteils

Code: [Auswählen]

   ; Selector
    mov ax, codesel
    mov ds, ax
    mov es, ax
    mov fs, ax
    mov gs, ax
    mov ss, ax
    mov esp, 0x1FFFFF ; Stack mit 2 MB

   PM3:
    jmp ende

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Ende                               ;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
times 512-($-$$) db 0
ende:

Anfang des 32Bit Kernelteils (der 16Bit - Teil und der 32Bit - Teil sind mit MergeKernel.exe "verbunden"

Code: [Auswählen]


[Bits 32]
jmp start ; Variablen überspringen

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Variablen                               ;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
msg_REOS db 0x0C,'RedEagle Operating System',0

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Start                                   ;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

start:

Immer wenn ich irgendwas mit "org" mache restartet bochs (außer "org 0")

[Gawag]

Also ich mach das alles ganz ohne org.

Ich hatte dasselbe Problem und habe es so gelöst, dass ich nicht wie im RM:
mov al, [esi]
sondern:
 mov al, [esi+0x10000]
benutze.

0x10000 ist bei mir die Position des Kernels also allgemein:
mov al, [esi+kernel_position]

An deinem Code war also so nichts falsch, nur die Idee fehlte Passiert mir auch dauernd.

So nebenbei: ich mag org sowieso nicht, das fuscht so "blöde" rum. Ich greife lieber ueber die genauen Adressen auf den RAM zu. Also so dass 0x10000 auch 0x10000 ist und nicht irgendwie 0x20000 oder so. Da ist mir die Fehleranfälligkeit zu hoch (also zumindest wenn die orgs so funktionieren wie ich das verstanden habe).

Klappts mit meiner Methode?

[RedEagle]

DANKE ES LÄUFT

[Gawag]

Juhu!  

Ich dacht schon es käme gar keine Antwort mehr.  

[RedEagle]

sorry, hatte unter der Woche keine Zeit, nachzusehen, ob jemand geantwortet hat