I heard you talking about that. Care to explain how it works, what needs to be written, or do you have any links or code, etc?
bootsector@mbr (frank!)
Re:bootsector@mbr (frank!)
A bootsector is the first sector on the disk (head 0, cylinder 0)
which gets booted (when you start the computer),
the bios loads it into 0x0000:0x7c00
(memory)
Also called the mbr (Master Boot Recotr)
The mbr is 1 sector big (512 bytes usually)
bios-es check (well should do, a lot of new bioses do not (like mine) check the last 2 bytes for 0xAA55 to see if there is an bootsector on the disk, if not it checks another disk... or display an boot error..
This is a basic bootsector:
it should hang.
assemble like this:
(if you're using win then it should be nasmw, and use partcopy or something for putting it on the disk)
To improve it a bit
It now prints an f on the screen...
anyway the bootsector wasn't made for putting a lot of code in (I think )
For an os, the bootsector should load the kernel code,
(if you're not using partitions =))
this can either be 16 bit or 32bit
(32bit means (pmode) you can access about 4 gigabyte of memory.
16bit means (realmode) you can maximum use 1 MB of memory)
Is suggest you load your kernel (if you're doing an os, using int 0x13) switch to pmode and jump to the kernel.
There are some pmode docs/questions on the board
(can't share mine code yet, don't know what license to put on it... bsl or gpl... or my own ....)
Best,
Frank
which gets booted (when you start the computer),
the bios loads it into 0x0000:0x7c00
(memory)
Also called the mbr (Master Boot Recotr)
The mbr is 1 sector big (512 bytes usually)
bios-es check (well should do, a lot of new bioses do not (like mine) check the last 2 bytes for 0xAA55 to see if there is an bootsector on the disk, if not it checks another disk... or display an boot error..
This is a basic bootsector:
Code: Select all
org 7c00h
jmp main
main: jmp main
times 510-($-$$) db 0
sign dw 0xAA55
assemble like this:
Code: Select all
nasm bootsector.asm -f bin
dd if=bootsector of=/dev/disk
To improve it a bit
Code: Select all
org 7c00h
jmp f
f: mov ah,0Eh
mov al,'f'
int 0x10
jmp main
main: jmp main
times 510-($-$$) db 0
sign dw 0xAA55
anyway the bootsector wasn't made for putting a lot of code in (I think )
For an os, the bootsector should load the kernel code,
(if you're not using partitions =))
this can either be 16 bit or 32bit
(32bit means (pmode) you can access about 4 gigabyte of memory.
16bit means (realmode) you can maximum use 1 MB of memory)
Is suggest you load your kernel (if you're doing an os, using int 0x13) switch to pmode and jump to the kernel.
There are some pmode docs/questions on the board
(can't share mine code yet, don't know what license to put on it... bsl or gpl... or my own ....)
Best,
Frank
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:bootsector@mbr (frank!)
when the task of loading your kernel becomes too complicated (because of turning into pmode, handling multiple possible locations, unzipping the kernel on the fly, etc.) for the 512 bytes you have, it's common to come with a second stage loader.
This is a small program (a few Kb is usually enough) written in asm (most often) which is loaded by your boot sector and which will do the complex task of effective kernel loading.
A lot of OSes use this technique: the first stage (boot sector) just loads a bunch of sectors from some well-known (usually reserved at formatting time) location on the disk, an those sectors (the second-stage loader) will locate the kernel, unpack it if needed, then do whatever appropriated with the hardware before starting the kernel (entering pmode, remapping IRQs, etc.)
The point doing so is that your kernel will include less machine-specific code and thus can be more portable, etc.
This is a small program (a few Kb is usually enough) written in asm (most often) which is loaded by your boot sector and which will do the complex task of effective kernel loading.
A lot of OSes use this technique: the first stage (boot sector) just loads a bunch of sectors from some well-known (usually reserved at formatting time) location on the disk, an those sectors (the second-stage loader) will locate the kernel, unpack it if needed, then do whatever appropriated with the hardware before starting the kernel (entering pmode, remapping IRQs, etc.)
The point doing so is that your kernel will include less machine-specific code and thus can be more portable, etc.
Re:bootsector@mbr (frank!)
MBR is used on partitioned disk it manage bootsector on each partition and of course the partition themself with a table.
Stop me if i'm wrong
Stop me if i'm wrong