So I switch into Pmode and I call my kernel when

[Candy]

==This is my GDT==
[tt]
gdt: ;This is a pointer. Its value will be help calculate its size

gdt_null: ;Null Segment
dw 0 ;Fill it up with 0s
dw 0 ;More 0s
db 0
db 0
db 0
db 0

gdt_code: ;Our code segment will be defined here
;First Double word
dw 0FFFFh ;Make this 4GB in size
dw 0 ;The first 16-bits of the base address

;Second Double Word
db 0 ;Bits 16-23 of the base address
db 10011010b ;Present = 1 Privilage = 0 Code = 1 CF = 0 Readable = 1 AF = 0
db 11001111b ;Granularity = 1 Size = 1 Reserved = 0 ASP = 0 Limit = 4GB
db 0 ;Last 24-31 of base address
gdt_data: ;Our data segment will be defined here
;First Double word
dw 0FFFFh ;Make this 4GB in size
dw 0 ;The first 16-bits of the base address

;Second Double Word
db 0 ;Bits 16-23 of the base address
db 10010010b ;Present = 1 Privilage = 0 Code = 0 CF = 0 Readable = 1 AF = 0
db 11001111b ;Granularity = 1 Size = 1 Reserved = 0 ASP = 0 Limit = 4GB
db 0 ;Last 24-31 of base address
[/tt]

==This is the kernel code==
All my assembly code is:
[tt]
[extern main_] ;NASM directive for the C function main()
SECTION .text USE32 ;NASM directive for code
[bits 32] ;NASM directive to use 32-bit instructions
call main_ ;Call the C/C++ code
cli ;Disable interrupts
hlt ;Halt the CPU
[/tt]

This is my C/C++ code:
[tt]
unsigned char *text = (char *)0xB80000;

void main();

void main() {
*text++ = '!';
*text++ = 7;
while(1) { }
}
[/tt]

That's a 0 too much in your video address there.

You might still accept interrupts, since you don't disable them explicitly.

What about disassembling your intermediates, or tracing in bochs from the breakpoint at the start of your code? The first would show you whether NASM understood it and the second would show you what JLOC made of it. A hexdump of the image will be quite clear too.

[REV]

I have a lot more code done I just "cut it out" to help diagnose the problem.

Here is the hex dump of my kernel:
[tt]
00000000 FA E8 02 00 00 00 FA F4 68 08 00 00 00 E8 ED FF ??....??h....???
00000010 FE FF 52 A1 37 00 00 00 8D 50 01 89 15 37 00 00 ??R?7...?P.?.7..
00000020 00 C6 00 21 A1 37 00 00 00 8D 50 01 89 15 37 00 .?.!?7...?P.?.7.
00000030 00 00 C6 00 07 EB FE 00 80 0B 00 ..?..??.?..
[/tt]

[Ryu]

Heres what it disassembles to:

Code: Select all

seg000:00010000 seg000          segment byte public 'CODE' use32
seg000:00010000                 assume cs:seg000
seg000:00010000                 ;org 10000h
seg000:00010000                 assume es:nothing, ss:nothing, ds:nothing, fs:nothing, gs:nothing
seg000:00010000                 cli
seg000:00010001                 call    sub_10008
seg000:00010006                 cli
seg000:00010007                 hlt
seg000:00010008 
seg000:00010008 sub_10008       proc near               ; CODE XREF: seg000:00010001p
seg000:00010008                 push    8
seg000:0001000D                 call    near ptr 0FFFFFFFFh
seg000:00010012                 push    edx
seg000:00010013                 mov     eax, large ds:37h
seg000:00010018                 lea     edx, [eax+1]
seg000:0001001B                 mov     large ds:37h, edx
seg000:00010021                 mov     byte ptr [eax], 21h ; '!'
seg000:00010024                 mov     eax, large ds:37h
seg000:00010029                 lea     edx, [eax+1]
seg000:0001002C                 mov     large ds:37h, edx
seg000:00010032                 mov     byte ptr [eax], 7
seg000:00010035 
seg000:00010035 loc_10035:                              ; CODE XREF: sub_10008+2Dj
seg000:00010035                 jmp     short loc_10035
seg000:00010035 sub_10008       endp

seg000:0001000D is the problem, which doesn't relate to your source code. My only guess is made by watcom. I have some questions concerning watcom.. is there a "release" and "debug" compilation modes? If so which mode did you compile under? And, can you tell watcom to not use the default CRT libraries?

Oh yes.. the global: unsigned char *text = (char *)0xB80000; which could be why theres a call to initialize globals, and the code segment it runs in might have been disgarded during linkage.

[REV]

Well I am using 11.0c. Its a release version. Thats cause Im too lazy to upgrade to Open Watcom 1.3 ;D

Looking at Wcc386 there are some command line perimaters that look intresting:
[tt]
-hc generate Codeview debugging information
-hd generate DWARF debugging information
-hw generate Watcom debugging information
[/tt]
Im compiling I guess under the release mode. The default librarys I don't belive are being compiled. Just to make sure I renamed the include and library directories

Ive also disabled all the compiler "extensions" so its compiling by the ANSI standard.

Well Im going to go over the documentation. But this still seems a little weird to me.

[REV]

>:(
Should I upgrade to Open Watcom 1.3 then?

[Candy]

I'm just going to guess that the compiler inserted some form of call to some function at that point, which you don't have defined. It then defined the function arbitrarily to be at -1 (or 0xFFFFFFFF) and caused your program to jump to EIP=-1. This then wrapped around to run the IVT, which contained invalid code.

I'm guessing the function is called alloca(). Try defining it and see whether you get more sensible results. Next time, disassemble first or get a compiler you trust and understand.

[REV]

I fixed it.
I had to turn off Stack Overflow checking. Which dosn't sound too good
Now Its time to work on my kernel.
Hmm how come nothings getting printed?
[tt]
unsigned char *textaddress = (char *)0xB8000;

void main();

void main() {
   while(1) {
      *textaddress++ = '!';
      *textaddress++ = 7;
   }
}
[/tt]

[Candy]

I had to turn off Stack Overflow checking. Which dosn't sound too good

Time for a proper quote on the compiler:

If you make something that an idiot can use, only an idiot will want to use it.

Don't call functions unless I'm !#*()& telling you to.

Now Its time to work on my kernel.
Hmm how come nothings getting printed?
[tt]
unsigned char *textaddress = (char *)0xB8000;

void main();

void main() {
while(1) {
*textaddress++ = '!';
*textaddress++ = 7;
}
}
[/tt]

Did you properly link in the variable? Did you map the memory correctly? Do your segments work? Did you trace it in bochs to see what it did?

[REV]

All my segments work I belive. All these are in the same source file. I belive the memory is mapped correctly. (What do you mean by correctly?) Let me check Bochs aaaaannnnnd it dosn't tell me anything.

[Combuster]

by testing in bochs he means using the bochs debugger to see where and if your characters are being printed to. Bochs' debugger can tell you where memory is mapped to in case you use paging, and to see where your segments are directing your memory accesses to. Just set a breakpoint for 0x7c00 and enjoy reading the rest of the bochs manual

Right now i'm expecting bochs (without debugger) to either ignore your attempts or flood warnings since you'll be running off the end of video memory straight into the bios region with this loop...

[REV]

If I enabled paging will that fix it? Paging is setting the last bit in the CR0 register right?
Well I know for a fact my C/C++ works
I know I was running the Bochs Debugger. Stepping through my bootloader it runs off in a weird direction but some how it later comes back on track with protected mode and then my kernel is called

[Combuster]

If I enabled paging will that fix it? Paging is setting the last bit in the CR0 register right?

Paging doesn't fix anything, it only gives you new options. An yes, PG is bit 31 in CR0

Well I know for a fact my C/C++ works

"I heard that one before"

I know I was running the Bochs Debugger. Stepping through my bootloader it runs off in a weird direction but some how it later comes back on track with protected mode and then my kernel is called

In case you wonder, it helps setting breakpoints after INT instructions. You probably ended up debugging the BIOS which is not really where your issues are right now.
Still i didnt hear of anything happening after protected mode was entered. Have you found yet if you got to something like your mov, inc, mov, inc, jmp printing sequence - maybe you can get a disassembly of that with a cpu dump so we can determine wether You or Bochs should upgrade...