Page 1 of 1
Trying to get print function to work at higher memory addres
Posted: Tue Mar 09, 2004 5:05 pm
by beyondsociety
Im trying to load my kernel to a memory address above 1MB and I have successfully done so. I have noticed that my print routine works at 1MB but if I try it at 2MB, it doesnt print anything.
How would I get my print routine to work at a higher memory address?
Re:Trying to get print function to work at higher memory add
Posted: Tue Mar 09, 2004 10:34 pm
by thooot
Have you changed where it thinks it is being loaded in your linking script? That is, does your compiler know that the code will be loaded to a different address?
Re:Trying to get print function to work at higher memory add
Posted: Wed Mar 10, 2004 4:09 pm
by beyondsociety
Have you changed where it thinks it is being loaded in your linking script? That is, does your compiler know that the code will be loaded to a different address?
Yes I have. I even have the linker print out a memory map and then I checked to see if it was linking my addresses correctly and it was.
Do I have to add a load address to the VIDEO ram memory address?
For exxample:
Video = 0xB8000 for color monitor
Video = 0xB8000 + 0x200000 (where code is loaded to, 2MB)
Re:Trying to get print function to work at higher memory add
Posted: Thu Mar 11, 2004 2:23 am
by Pype.Clicker
that basically depend on how you set up your GDT. If the main data descriptor is 0-based, you have nothing special to do ... If not (i.e. if you have DS.base == 1MB), then you have to adjust accesses to video memory with 0xb8000 - DS.base ...
Re:Trying to get print function to work at higher memory add
Posted: Thu Mar 11, 2004 5:03 pm
by beyondsociety
that basically depend on how you set up your GDT. If the main data descriptor is 0-based, you have nothing special to do ... If not (i.e. if you have DS.base == 1MB), then you have to adjust accesses to video memory with 0xb8000 - DS.base ...
They are are zero-based.
To load my kernel to a higher address than 1MB, I enable the a20 gate and load the kernel using the int 13h (read sectors function)
Code: Select all
load_sectors:
mov bx, 0xffff ; ES:Bx = 0xffff:0x0020 (kernel loaded at 2MB)
mov es, bx
mov bx, 0x0020
mov ah, 0x02 ; Read disk sectors function
mov al, 0x17 ; Read 18 sectors (0x00 + 0x17 = 0x18 sectors)
mov ch, 0x00 ; Track 0x00
mov cl, 0x02 ; Sector 0x02
mov dh, 0x00 ; Head 0x00
mov dl, [DriveNumber] ; Drive number (0x00 = Floppy, 0x80 = Hard Drive)
int 13h
or al, al ; Check for error code
jc load_sectors ; If there was an error, try again
Then I enter protected mode and load kernel to 2MB
Code: Select all
jmp 0x08:0x200000 ; Jump to C kernel
Then I add 2MB to the load address of the linker.ld and compile and test it. It will boot fine but nothing will display.
What could be the problem?
Re:Trying to get print function to work at higher memory add
Posted: Thu Mar 11, 2004 5:43 pm
by thooot
Doesn't 0xffff:0x0020 = 0x100010? So your kernel isn't being loaded at 2MB. You should probably load it somewhere in low memory off of disk and then move it up to 2MB.
Re:Trying to get print function to work at higher memory add
Posted: Fri Mar 12, 2004 2:12 am
by Pype.Clicker
beyondsociety wrote:
To load my kernel to a higher address than 1MB, I enable the a20 gate and load the kernel using the int 13h (read sectors function)
Then I add 2MB to the load address of the linker.ld and compile and test it. It will boot fine but nothing will display.
What could be the problem?
<gandalf>Fool of a Took!</gandalf>
0xffff:0x0020 is certainly not 2MB. Check out Perica's tutorial about realmode addressing if it's not obvious... Only unreal mode can take you up to 2MB. Under real mode, all you can get is 0x0001ffef by cheating with the address formation.
And even under unreal mode, you cannot have the BIOS load anything directly above that barrier because it will only use the lowest 16 bits of memory operands.
What i would recommend is that you first load your kernel below 640KB area and then, either using a manual copy loop in unreal mode or calling the 'memory move' function of INT 15h, you send the kernel at its definitive location (whatever it is).