Page 2 of 3

Posted: Tue Mar 04, 2008 3:39 pm
by Combuster
Why do I get the idea that you have no clue what 'debugging' means

Posted: Tue Mar 04, 2008 3:43 pm
by os.hacker64
I do understand, I am doing it, and I have no Idea where to go from here. :?

Posted: Tue Mar 04, 2008 3:47 pm
by Combuster
Yet you ignore the suggestion to use bochs :roll:

Posted: Tue Mar 04, 2008 3:53 pm
by os.hacker64
I did in fact ask where to find precofigured GRUB images, I DID install bochs. Anyway it doesn't matter now here is the new code, this does not cause a triple fault, I wonder should I be doing a jmp kernel or a jmp 0x0:kernel

Posted: Tue Mar 04, 2008 4:07 pm
by Combuster
I did in fact ask where to find precofigured GRUB images, I DID install bochs.
You edited that in just before I posted the reply. Nevertheless, you boot on a real PC, so somehow you have a bootable medium with your kernel on it. Why would you need to build a separate image from scratch.
Anyway it doesn't matter now here is the new code, this does not cause a triple fault,
Debugging is *not* to make random changes and asking what's wrong with the code.
I wonder should I be doing a jmp kernel or a jmp 0x0:kernel
I would consider that a good example of being completely clueless about what happens in either case. A far jump reloads CS, including the side-effects. A near jump doesn't. I dunno if you were the one I told last time to read the intel manuals end-to-end five times, but this is a textbook example of a stupid question, if not begging for a RTFM.

Posted: Tue Mar 04, 2008 4:07 pm
by os.hacker64
Where can I find info on setting vesa modes? I have googled.

Posted: Tue Mar 04, 2008 4:08 pm
by Combuster
google harder

Posted: Tue Mar 04, 2008 4:11 pm
by os.hacker64
Combuster wrote:
I did in fact ask where to find precofigured GRUB images, I DID install bochs.
You edited that in just before I posted the reply. Nevertheless, you boot on a real PC, so somehow you have a bootable medium with your kernel on it. Why would you need to build a separate image from scratch.
Anyway it doesn't matter now here is the new code, this does not cause a triple fault,
Debugging is *not* to make random changes and asking what's wrong with the code.
I wonder should I be doing a jmp kernel or a jmp 0x0:kernel
I would consider that a good example of being completely clueless about what happens in either case. A far jump reloads CS, including the side-effects. A near jump doesn't. I dunno if you were the one I told last time to read the intel manuals end-to-end five times, but this is a textbook example of a stupid question, if not begging for a RTFM.
I did NOT edit that post.

Posted: Tue Mar 04, 2008 4:25 pm
by Combuster
I did NOT edit that post.
Whatever you want, Mr. Reagan.

Posted: Tue Mar 04, 2008 4:33 pm
by os.hacker64
I thought you might say that, I swear I didn't though, no memory of it at all, ADD might have something to do with that though. So, where are the images tell me your secrets!!!!!!!!!!!!!!

Posted: Tue Mar 04, 2008 4:43 pm
by Combuster
ADD might have something to do with that though.
I rest my case.

Posted: Tue Mar 04, 2008 4:57 pm
by ~
This code works fine to set Unreal Mode at boot time:

Code: Select all

  ;;INIT: Unreal Mode
  ;;INIT: Unreal Mode
  ;;INIT: Unreal Mode
    ;Unreal Mode is an "unofficial" processor mode
    ;in which practically we are running half real
    ;mode and half protected mode.
    ;
    ;In this operation mode, we can address 32-bit
    ;memory linearily, without having to address a
    ;location with an explicit segment register as
    ;DS or ES; at least with extreme caution.
    ;
    ;At the same time, data protection is disabled.
    ;
    ;The trick is that the segments are cached and
    ;thus the segment registers can be disregarded
    ;thereafter; although for 16-bit addressing we
    ;will always be affected for the default value
    ;of the data segments, mainly DS and then ES.
    ;
    ;The difference is now can reach 32-bit memory
    ;by an instruction such as:
    ;
    ;   mov [eax],ebx
    ;        OR
    ;   a32 rep movsd
    ;
    ;Where the "a32" prefix is a 0x67 byte that we
    ;use to tell the processor that the next bytes
    ;encode an instruction that will use registers
    ;32-bit wide that otherwise would be 16-bit.
    ;
    ;Note that, in unreal mode, this instruction:
    ;
    ;  mov byte[_32_bit_pointer],0
    ;
    ;Can't be encoded because we are trying to use
    ;a 32-bit offset in a 16-bit instruction. This
    ;is a case where we need a 32-bit register for
    ;the addressing, as in:
    ;
    ;   mov [eax],ebx
    ;        OR
    ;  a32 mov byte[_32_bit_pointer],0
    ;
    ;Step 1: Load GDT
    ;Step 1: Load GDT
        lgdt[cs:GDT]   ;{6}

     ;Step 2: Enable PE Bit for Entering Protected Mode
     ;Step 2: Enable PE Bit for Entering Protected Mode
       mov eax,cr0   ;{3}
        inc ax           ;{1}
       mov cr0,eax   ;{3}


      ;Step 3: Load any Data Segments with 32-bit Selector
      ;Step 3: Load any Data Segments with 32-bit Selector
         push byte SELDat32 ;{2}
         pop ds             ;{1}
         push ds            ;{1}
         pop es             ;{1}


    ;Step 4: Back to Real Mode with 32-bit Segments/GDT
    ;Step 4: Back to Real Mode with 32-bit Segments/GDT
      dec ax       ;{1}
      mov cr0,eax  ;{3}
  ;;END:  Unreal Mode
  ;;END:  Unreal Mode
  ;;END:  Unreal Mode

   JMP $   ;This should be replaced by code that won't reach the GDT data


   ;INIT: GDT
   ;INIT: GDT
   ;INIT: GDT
     GDT:
      SELNull equ 0    ;As you may see, we have used
        GDT_size:      ;the Null Selector as the GDT
          dw GDTsize   ;pointer to load with LGDT.
        GDT_actualPtr: ;
          dd GDT       ;You can see that the WORD at
          dw 0x0000    ;the end of these 8 bytes are
                       ;2 padding bytes with 0x0000.

      SELCod32 equ 8
        dw 0FFFFh       ; bits 0-15 length (Bytes 0-1)
        dw 00000h       ; bits 0-15 base addr (Bytes 2-3)
        db 0            ; bits 16-23 base addr (Byte 4)
        db 10011010b    ; bits 0-3 Type, 4 DT, 5-6 DPL & 7 P (Byte 5)
        db 11001111b    ; bits 16-19 length into 0-3, 6 D & 7 G (Byte 6)
        db 0            ; bits 24-31 base addr (Byte 7)

      SELDat32 equ 16
        dw 0FFFFh       ; bits 0-15 length (Bytes 0-1)
        dw 00000h       ; bits 0-15 base addr (Bytes 2-3)
        db 0            ; bits 16-23 base addr (Byte 4)
        db 10010010b    ; bits 0-3 Type, 4 DT, 5-6 DPL & 7 P (Byte 5)
        db 11001111b    ; bits 16-19 length into 0-3, 6 D & 7 G (Byte 6)
        db 0            ; bits 24-31 base addr (Byte 7)
      GDT_end:

      GDTsize equ (GDT_end-GDT)-1
   ;END:  GDT
   ;END:  GDT
   ;END:  GDT

Posted: Wed Mar 05, 2008 12:59 am
by pcmattman
RTFM, search google, and get over your laziness:
I understand with the kprint, I'm too lazy to change it.
And you wonder why it doesn't work?

I'm true to my word.

Posted: Wed Mar 05, 2008 3:50 pm
by os.hacker64
I did not though get upset when someone told me to RTFM. I suck with googling.

Posted: Wed Mar 05, 2008 3:57 pm
by pcmattman
If you're as lazy as I think you are (from what I pick up in this thread) I already know why you suck at googling.