OSDev.org

so i wrote a boot loader, and a few things are unclear to me, the code : the things that unclear is, if i write into a floppy using the following commands (dd):
dd status=noxfer conv=notrunc if=bin/boot.bin of=boot.flp bs=512 count=1 # Writing it to the first disk
dd status=noxfer conv=notrunc if=bin/kernel.bin of=boot.flp bs=512 count=1 seek=1 # Writing to the first disk on the second block
that means im writing to the same floppy in the first block and skipping a sector right? the boot will go into sector 1 and kernel will go to sector 2.
but in my code i dont understand why choose 1000:00h for bx, i mean i know the es and ds are going need that position, but why exactly 1000h, and by filling the first 512 bytes, does that mean, if i read to 513 the kernel? that will work? and what limit the memory of the kernel in the ram?
thanks alot

This code reads one sector of the kernel. If the size of the code is greater than 512 bytes, then there will be problems.

shmx wrote:This code reads one sector of the kernel. If the size of the code is greater than 512 bytes, then there will be problems.

thank you for the reply, what in the code here defines the sector size? is it by default 512? even if so, if i for example read 2 sectors, and my code need 800, do i need to fill the rest with 0? or it'll work anyways?

Hi,

newbi wrote:but in my code i dont understand why choose 1000:00h for bx....

The only person that knows why 1000h:00h was chosen (and not anything else) is the person that wrote "your" code.

Note that the way it uses lower case instructions in some places (e.g. "mov ch,0h ") and upper case instructions in other places (e.g. "MOV AH, 02h") and the different indenting styles tell me that there were at least 2 authors; and the lack of comments and all of the mistakes and bugs (using "[BITS 16]" instead of "BITS 16", not using the "device number" the BIOS gave you, failing to setup a stack before loading data into memory where the stack might still be, the "on error, repeatedly thrash the floppy drive in an attempt to cause hardware damage" error handling, etc) tells me that none of the different authors knows what they're doing.

Mostly what I'm trying to say here is that I know you're trying to learn (which is good!), but the information (tutorial, example, whatever) that you're trying to learn from is bad, and you need to find better information to learn from.

newbi wrote:...and by filling the first 512 bytes, does that mean, if i read to 513 the kernel? that will work?

You load one sector, which is (almost) always 512 bytes. If your software tries to read the 513th byte then it's reading whatever garbage was left in RAM by firmware.

newbi wrote:and what limit the memory of the kernel in the ram?

What limits the kernel size at the moment is that you only load one sector (which means kernel is limited to 512 bytes).

If you loaded more sectors, the kernel size limit would be "worst_case_EBDA_address - starting_address". The worst case EBDA address is 0x00080000, and if your starting address is 0x00010000 then this gives a kernel size limit of 0x00070000 bytes (or 448 KiB).

If you changed the starting address that kernel is loaded to something lower, like 0x00001000, then it'd give you a kernel size limit of 0x0007F000 bytes (or 508 KiB). This is about as low as the kernel's starting address can be, so this is the "least limiting" limit you can hope for while only using real mode.

To go beyond that limit; you have to use protected mode. The common way is to load part of the kernel (e.g. one track) into a buffer that real mode can access, then switch to protected mode and copy the data somewhere else (e.g. the area starting at 0x00100000), then switch back to real mode and load then next part of the kernel; and so on, until the entire kernel is loaded.

Also note that there's a large amount of additional things you need real mode/BIOS for; including getting a memory map, setting up a video mode, detecting "PCI config space access mechanism", etc. It will not fit in a 512-byte boot loader. To work around that you either need a larger boot loader (where first 512 bytes of boot loader loads the rest of the boot loader before its used) or a second stage (where boot loader loads an "N-sector" second stage, and the second stage gathers all the info from BIOS and loads the kernel).


Cheers,

Brendan

newbi wrote:so i wrote a boot loader, and a few things are unclear to me, the code :

Code: Select all

	jz $

I believe this is an infinite loop.

Also, you don't set your segments or initialize si, and the error printing code appears to be dead code since your never jump to or call it.

newbi wrote: but in my code i dont understand why choose 1000:00h for bx, i mean i know the es and ds are going need that position, but why exactly 1000h,

It's because you don't understand the code.

I'd recommend setting all your segments to 0 and leaving them that way in real mode (for as long as that's realistic); that essentially gives you a 64K "flat mode," which can be easier than dealing with real mode segments.

Now as for "why" 1000:0000, or any other address, the "why" is more or less where ever you want to put the next sector that won't clash with something else.

0x00000-0x003FF has your IVT
0x00400-0x005FF (I think?) is the BDA
0x00600-0x07BFF is free
0x07C00-0x07DFF is the 1st sector (the code you showed above)
0x07E00-0x0FFFF is the rest of the free 64K "flat space"
0x10000-(0x9FFFF -EBDA size) is the rest of lower memory

newbi wrote: and by filling the first 512 bytes, does that mean, if i read to 513 the kernel? that will work?

If you're asking if the kernel in this case can be thought of as being loaded to the 513th byte of the floppy, yes.

Brendan wrote:Hi,

newbi wrote:but in my code i dont understand why choose 1000:00h for bx....

The only person that knows why 1000h:00h was chosen (and not anything else) is the person that wrote "your" code.

Note that the way it uses lower case instructions in some places (e.g. "mov ch,0h ") and upper case instructions in other places (e.g. "MOV AH, 02h") and the different indenting styles tell me that there were at least 2 authors; and the lack of comments and all of the mistakes and bugs (using "[BITS 16]" instead of "BITS 16", not using the "device number" the BIOS gave you, failing to setup a stack before loading data into memory where the stack might still be, the "on error, repeatedly thrash the floppy drive in an attempt to cause hardware damage" error handling, etc) tells me that none of the different authors knows what they're doing.

Mostly what I'm trying to say here is that I know you're trying to learn (which is good!), but the information (tutorial, example, whatever) that you're trying to learn from is bad, and you need to find better information to learn from.

newbi wrote:...and by filling the first 512 bytes, does that mean, if i read to 513 the kernel? that will work?

You load one sector, which is (almost) always 512 bytes. If your software tries to read the 513th byte then it's reading whatever garbage was left in RAM by firmware.

newbi wrote:and what limit the memory of the kernel in the ram?

What limits the kernel size at the moment is that you only load one sector (which means kernel is limited to 512 bytes).

If you loaded more sectors, the kernel size limit would be "worst_case_EBDA_address - starting_address". The worst case EBDA address is 0x00080000, and if your starting address is 0x00010000 then this gives a kernel size limit of 0x00070000 bytes (or 448 KiB).

If you changed the starting address that kernel is loaded to something lower, like 0x00001000, then it'd give you a kernel size limit of 0x0007F000 bytes (or 508 KiB). This is about as low as the kernel's starting address can be, so this is the "least limiting" limit you can hope for while only using real mode.

To go beyond that limit; you have to use protected mode. The common way is to load part of the kernel (e.g. one track) into a buffer that real mode can access, then switch to protected mode and copy the data somewhere else (e.g. the area starting at 0x00100000), then switch back to real mode and load then next part of the kernel; and so on, until the entire kernel is loaded.

Also note that there's a large amount of additional things you need real mode/BIOS for; including getting a memory map, setting up a video mode, detecting "PCI config space access mechanism", etc. It will not fit in a 512-byte boot loader. To work around that you either need a larger boot loader (where first 512 bytes of boot loader loads the rest of the boot loader before its used) or a second stage (where boot loader loads an "N-sector" second stage, and the second stage gathers all the info from BIOS and loads the kernel).


Cheers,

Brendan

i'd understand the code and the parameters for interrupt 13h
i didnt write the entire code since i searched for examlpes and took what i saw, but i have some questions.
1. I didnt set up a stack, but is it rly neccesary? i mean if i dont use it in my code, do the intterups rly need it?
ok, so i read 1 sector, wich is 512 bytes most likely, if for example i wanna build a calculator to run by my os, wich i did for this case,
the input, manage the input and printing will take more then 512, so after i wrote alot of line codes i noticed some of the last data bytes i definde for my strings are started to gone missing like showing just half a sentence, i suspected my ram eneded for the kernel to use and thats why it worked that why, is it really the case? if so, how can i make my kernel be able to read more memory(sectors), and do i have to calculate the number of sectors im reading? if im using a floppy emulator, for example im using qemu to run the system, can i read as much memory as i want because it theoretical or there's a limit?
plus i didnt qutie get the 1000h, i mean i know i decided that so it wont clush with the bootloader's memory right? but how do i know where exactly (address) of the boot loader ends? thanks in advance

azblue wrote:

newbi wrote:so i wrote a boot loader, and a few things are unclear to me, the code :

Code: Select all

	jz $

I believe this is an infinite loop.

Also, you don't set your segments or initialize si, and the error printing code appears to be dead code since your never jump to or call it.

newbi wrote: but in my code i dont understand why choose 1000:00h for bx, i mean i know the es and ds are going need that position, but why exactly 1000h,

It's because you don't understand the code.

I'd recommend setting all your segments to 0 and leaving them that way in real mode (for as long as that's realistic); that essentially gives you a 64K "flat mode," which can be easier than dealing with real mode segments.

Now as for "why" 1000:0000, or any other address, the "why" is more or less where ever you want to put the next sector that won't clash with something else.

0x00000-0x003FF has your IVT
0x00400-0x005FF (I think?) is the BDA
0x00600-0x07BFF is free
0x07C00-0x07DFF is the 1st sector (the code you showed above)
0x07E00-0x0FFFF is the rest of the free 64K "flat space"
0x10000-(0x9FFFF -EBDA size) is the rest of lower memory

newbi wrote: and by filling the first 512 bytes, does that mean, if i read to 513 the kernel? that will work?

If you're asking if the kernel in this case can be thought of as being loaded to the 513th byte of the floppy, yes.

yep, some of the code is dead, since im not jumping into it by intention, not a mistake, im leaving that part for later .
if i set all the parametres to 0 before 13h,it will not read anything since the kernel is written in the second sector of the floppy.
or am i wrong?

Hi,

newbi wrote:1. I didnt set up a stack, but is it rly neccesary? i mean if i dont use it in my code, do the intterups rly need it?

You need a little stack just to use a software interrupt; then the BIOS function itself uses your stack. If you don't setup your own stack then you're using whatever random stack the BIOS left you with, and when you load anything from disk (or use any memory outside your initial 512 bytes) there's a risk that you're trashing your own stack while the BIOS is using it, and that doesn't make the BIOS happy.

newbi wrote:ok, so i read 1 sector, wich is 512 bytes most likely, if for example i wanna build a calculator to run by my os, wich i did for this case,
the input, manage the input and printing will take more then 512, so after i wrote alot of line codes i noticed some of the last data bytes i definde for my strings are started to gone missing like showing just half a sentence, i suspected my ram eneded for the kernel to use and thats why it worked that why, is it really the case?

It should be easy (for you) to check the kernel's file size and determine if it's larger than 512 bytes.

newbi wrote:if so, how can i make my kernel be able to read more memory(sectors), and do i have to calculate the number of sectors im reading?

Typically you have some sort of file header (which can just be "size of file" stored in the first 4 bytes of the file); and your boot loader would load enough of the file (e.g. the first sector) to get the header into RAM and use it to determine how many more sectors it needs to load.

newbi wrote:if im using a floppy emulator, for example im using qemu to run the system, can i read as much memory as i want because it theoretical or there's a limit?

You tell Qemu how much memory to give the emulated computer. You can't use more than that. Of course if you're in real mode you're limited to an "best case" maximum of slightly less than 704 KiB regardless of how much memory the emulated computer has (and that takes some trickery to achieve). More realistic is less than 512 KiB.

newbi wrote:plus i didnt qutie get the 1000h, i mean i know i decided that so it wont clush with the bootloader's memory right? but how do i know where exactly (address) of the boot loader ends? thanks in advance

The address of the end of the boot loader (more correctly; the address of the first byte after the boot loader) will be the address of the start of the boot loader plus the size of the boot loader. If you know the boot loader starts at 0x00007C00 and is 512 bytes (0x00000200 bytes), then...


Cheers,

Brendan

Brendan wrote:Hi,

newbi wrote:1. I didnt set up a stack, but is it rly neccesary? i mean if i dont use it in my code, do the intterups rly need it?

You need a little stack just to use a software interrupt; then the BIOS function itself uses your stack. If you don't setup your own stack then you're using whatever random stack the BIOS left you with, and when you load anything from disk (or use any memory outside your initial 512 bytes) there's a risk that you're trashing your own stack while the BIOS is using it, and that doesn't make the BIOS happy.

newbi wrote:ok, so i read 1 sector, wich is 512 bytes most likely, if for example i wanna build a calculator to run by my os, wich i did for this case,
the input, manage the input and printing will take more then 512, so after i wrote alot of line codes i noticed some of the last data bytes i definde for my strings are started to gone missing like showing just half a sentence, i suspected my ram eneded for the kernel to use and thats why it worked that why, is it really the case?

It should be easy (for you) to check the kernel's file size and determine if it's larger than 512 bytes.

newbi wrote:if so, how can i make my kernel be able to read more memory(sectors), and do i have to calculate the number of sectors im reading?

Typically you have some sort of file header (which can just be "size of file" stored in the first 4 bytes of the file); and your boot loader would load enough of the file (e.g. the first sector) to get the header into RAM and use it to determine how many more sectors it needs to load.

newbi wrote:if im using a floppy emulator, for example im using qemu to run the system, can i read as much memory as i want because it theoretical or there's a limit?

You tell Qemu how much memory to give the emulated computer. You can't use more than that. Of course if you're in real mode you're limited to an "best case" maximum of slightly less than 704 KiB regardless of how much memory the emulated computer has (and that takes some trickery to achieve). More realistic is less than 512 KiB.

newbi wrote:plus i didnt qutie get the 1000h, i mean i know i decided that so it wont clush with the bootloader's memory right? but how do i know where exactly (address) of the boot loader ends? thanks in advance

The address of the end of the boot loader (more correctly; the address of the first byte after the boot loader) will be the address of the start of the boot loader plus the size of the boot loader. If you know the boot loader starts at 0x00007C00 and is 512 bytes (0x00000200 bytes), then...


Cheers,

Brendan

thanks for the reply, a few follow ups,
so lets just say i make a 4k stack for the use of the bios and my own, i will create it after the bios, the process is to to declare a 4k stack of memory after the boot loader witch means (00007C00 + 512 + 4k) and then make the stack segment head there? and i didnt understand why there has to be a limit to a real mode, i mean, i cant just write more and more sectors? load them and continue my programming?

never mind, i will be happy for any help on earlier question or :
1. how come real mode has a very small ram spot?
i mean, in theory why shouldnt someone just add a 512 sector everytime he needed more memory?
2. i located 0x8000 the stack, if it stretches down wont it overwrite my boot sector at some point?
also can someone explains to me what is there in the end of the memory (vector etc...)

Hi,

newbi wrote:never mind, i will be happy for any help on earlier question or :
1. how come real mode has a very small ram spot?
i mean, in theory why shouldnt someone just add a 512 sector everytime he needed more memory?

For real mode, the highest value you can put in a 16-bit segment register is 0xFFFF and the highest value you can use for "offset" is 0xFFFF; which means the highest address you can access is 0xFFFF*16+0xFFFF = 0x00010FFEF. This gives (slightly more than) 1 MiB of address space that you can actually access in real mode.

However, that part of the address space looks like this:

• 0x00000000 to 0x000005FF = used by BIOS (BIOS Data Area)
  0x00000600 to EBDA_start = RAM you can use
  EBDA_start to 0x0009FFFF = used by BIOS (Extended BIOS Data Area)
  0x000A0000 to 0x000FFFFF = used by devices and BIOS (video card's legacy display memory window, device ROMs, BIOS ROM)
  0x00100000 to 0x00010FFEF = potentially usable RAM, but requires A20 to be enabled

If you subtract all the areas you can't use you end up with about 637.5 KiB of RAM you can use (with A20 disabled). If you enable A20 you can access about 701 KiB.

Of course the CPU has multiple modes, and real mode is the oldest (worst) mode the CPU has (it exists for backward compatibility with CPUs made in 1978). If you switch to protected mode (a mode introduced in 1985) you can access 4 GiB of address space and access a lot more RAM. If you switch to long mode (a mode introduced in 2004) you can access even more (up to a theoretical max. of 4194304 GiB of address space).

The reason 8086 originally chose 20-bit "segment + offset" is that this was considered huge at the time - most CPUs from that era only supported 64 KiB of address space; and it was 16 times larger than competing CPUs had.

newbi wrote:i mean, in theory why shouldnt someone just add a 512 sector everytime he needed more memory?

Because you run out of RAM that you can load sectors into.

newbi wrote:2. i located 0x8000 the stack, if it stretches down wont it overwrite my boot sector at some point?

If it keeps growing, it will overwrite the boot sector. Normally it doesn't keep growing. Normally you only use a certain amount.

newbi wrote:also can someone explains to me what is there in the end of the memory (vector etc...)

The existence and use of everything outside the area I described above is all non-standard; and what is at the actual end of the address space could be anything or nothing (you have to use BIOS functions like "int 0x15, eax=0xE820" to find out what is where on each computer).


Cheers,

Brendan

Brendan wrote:Hi,

newbi wrote:never mind, i will be happy for any help on earlier question or :
1. how come real mode has a very small ram spot?
i mean, in theory why shouldnt someone just add a 512 sector everytime he needed more memory?

For real mode, the highest value you can put in a 16-bit segment register is 0xFFFF and the highest value you can use for "offset" is 0xFFFF; which means the highest address you can access is 0xFFFF*16+0xFFFF = 0x00010FFEF. This gives (slightly more than) 1 MiB of address space that you can actually access in real mode.

However, that part of the address space looks like this:

• 0x00000000 to 0x000005FF = used by BIOS (BIOS Data Area)
  0x00000600 to EBDA_start = RAM you can use
  EBDA_start to 0x0009FFFF = used by BIOS (Extended BIOS Data Area)
  0x000A0000 to 0x000FFFFF = used by devices and BIOS (video card's legacy display memory window, device ROMs, BIOS ROM)
  0x00100000 to 0x00010FFEF = potentially usable RAM, but requires A20 to be enabled

If you subtract all the areas you can't use you end up with about 637.5 KiB of RAM you can use (with A20 disabled). If you enable A20 you can access about 701 KiB.

Of course the CPU has multiple modes, and real mode is the oldest (worst) mode the CPU has (it exists for backward compatibility with CPUs made in 1978). If you switch to protected mode (a mode introduced in 1985) you can access 4 GiB of address space and access a lot more RAM. If you switch to long mode (a mode introduced in 2004) you can access even more (up to a theoretical max. of 4194304 GiB of address space).

The reason 8086 originally chose 20-bit "segment + offset" is that this was considered huge at the time - most CPUs from that era only supported 64 KiB of address space; and it was 16 times larger than competing CPUs had.

newbi wrote:i mean, in theory why shouldnt someone just add a 512 sector everytime he needed more memory?

Because you run out of RAM that you can load sectors into.

newbi wrote:2. i located 0x8000 the stack, if it stretches down wont it overwrite my boot sector at some point?

If it keeps growing, it will overwrite the boot sector. Normally it doesn't keep growing. Normally you only use a certain amount.

newbi wrote:also can someone explains to me what is there in the end of the memory (vector etc...)

The existence and use of everything outside the area I described above is all non-standard; and what is at the actual end of the address space could be anything or nothing (you have to use BIOS functions like "int 0x15, eax=0xE820" to find out what is where on each computer).


Cheers,

Brendan

first of all, i dont think i can thank you enough.
second of all, there is a way of combining 2 registers (still at real mode 16 bit) to act as one address and then more of the memory will be adressed , also, if i read 10 sectors into the memory wich means (512*10 = 5120 bytes= 5.12kb) and i write for example a huge text on the second sector in the size of 513, if i'll try and load it, it will read until the 512 byte, but will the last byte will be written to the next available sector or i it is not possible to write a 513 byte into the sector ( assuming my floppy converter wont do it on its own).
another think i tougth is why cant there be just blank space, like loading 2 empty sectors into the memory, just as free space to be used if the definde sectors for a programm has ended?

Hi,

newbi wrote:second of all, there is a way of combining 2 registers (still at real mode 16 bit) to act as one address and then more of the memory will be adressed , also, if i read 10 sectors into the memory wich means (512*10 = 5120 bytes= 5.12kb) and i write for example a huge text on the second sector in the size of 513, if i'll try and load it, it will read until the 512 byte, but will the last byte will be written to the next available sector or i it is not possible to write a 513 byte into the sector ( assuming my floppy converter wont do it on its own).

There's no way to combine 2 registers (while still in real mode) and make them act as one although it is possible to use a 32-bit register in real mode but if you try that you'll just get a general protection fault (exceeding the 64 KiB segment's limit), however alternatively you could maybe use a different piece of hardware (instead of the CPU) to access memory for you and work around the limitations of real mode that way but (excluding "int 0x13 extensions") it's much much easier to just use protected mode instead of trying to think of bizarre ways to make real mode do things it was never intended to do and making everything worse and more fragile and harder to maintain/debug/test, mostly because there's no point having things in memory you can't access in a sane way in the first place unless perhaps you've got 2 or more CPUs and one is stuck in real mode for some reason but you can still use the other CPU to access memory.

newbi wrote:another think i tougth is why cant there be just blank space, like loading 2 empty sectors into the memory, just as free space to be used if the definde sectors for a programm has ended?

There's no reason you can't fill unused disk space with zeros when you create the disk.


Cheers,

Brendan

Brendan wrote:Hi,

newbi wrote:second of all, there is a way of combining 2 registers (still at real mode 16 bit) to act as one address and then more of the memory will be adressed , also, if i read 10 sectors into the memory wich means (512*10 = 5120 bytes= 5.12kb) and i write for example a huge text on the second sector in the size of 513, if i'll try and load it, it will read until the 512 byte, but will the last byte will be written to the next available sector or i it is not possible to write a 513 byte into the sector ( assuming my floppy converter wont do it on its own).

There's no way to combine 2 registers (while still in real mode) and make them act as one although it is possible to use a 32-bit register in real mode but if you try that you'll just get a general protection fault (exceeding the 64 KiB segment's limit), however alternatively you could maybe use a different piece of hardware (instead of the CPU) to access memory for you and work around the limitations of real mode that way but (excluding "int 0x13 extensions") it's much much easier to just use protected mode instead of trying to think of bizarre ways to make real mode do things it was never intended to do and making everything worse and more fragile and harder to maintain/debug/test, mostly because there's no point having things in memory you can't access in a sane way in the first place unless perhaps you've got 2 or more CPUs and one is stuck in real mode for some reason but you can still use the other CPU to access memory.

newbi wrote:another think i tougth is why cant there be just blank space, like loading 2 empty sectors into the memory, just as free space to be used if the definde sectors for a programm has ended?

There's no reason you can't fill unused disk space with zeros when you create the disk.


Cheers,

Brendan

I'm sorry I'm insisting in sticking to real mode, not because im stubbern, but because im developing a os for a university project, and i would like my first OS not to be too complicated, if i'll do it as a hobby later i'll learn eveything about protected mode and long mode.
had a another question, I heard some time in several places things like memory mapping, or managing video mode, i just never did think i need it in real mode,I'm right?
plus, had a general question about memory, the memory before its loaded considered physical, so far i used dd to write into the sectors of the floppy. but in case i just need some space to store some extra data that didnt fit in the kernel, can i just jump to some place free in the virtual memory and fill it with 0 then overwrite it with data i need, ofc assuming im saving the location of the address i actually stored that particular data?

newbi wrote:I'm sorry I'm insisting in sticking to real mode, not because im stubbern, but because im developing a os for a university project, and i would like my first OS not to be too complicated

Real mode isn't less complicated. It might save you having to write some drivers (or not), but otherwise there is nothing simpler about real mode. It is more complicated to manage memory than in protected mode.