OSDev.org

Is it necessary to write org 0x7C00 in assembly so that NASM calculates addresses starting from 0x7C00?

If you want NASM to calculate addresses starting from 0x7C00 instead of starting from 0, yes.

Yes. Say you have a label "msg" that stores some text. You'll need to access msg directly to retrieve its data; without the org statement, nasm would use 0x80 (for example) as msg's actual address, but the address it will actually be in will be 0x7c80 because that's where the bios put it

Must you use org 0x7C00? No. Should you use org 0x7C00? Probably.

I believe the org 0x7C00 is only half the equation and here's why.

Giving a value using org, only defines the offset part of the equation. It isn't going to make any difference what offset you use if you don't also set the segment portion as well.

For example, if the BIOS set DS to 0x07C0 and you use an org of 0x7C00, you aren't going to get the address you think you are. When you think about what value you will use with the org line, you must also think about what matching value you must place in the desired segment register.

Using a value of 0x07C0 in DS, you then most surely should use a value of 0x0000 in the org line. However, since many segment:offset combinations can point to the same physical address, you can use many of these combinations to get the same result.

Can I set DS to 0x0123 and use an org line value of 0x69D0? Absolutely. (0x0123 * 16) + 0x69D0 = 0x7C00.

The usual question comes to light when the CS segment register is in question. Must I use an org of 0x7C00? Again, the answer is no. The BIOS has placed you at physical address 0x7C00. As long as you use a CS and org combination to point to that same address, it doesn't matter what that combination is. Therefore, as long as you use all relative branching (jmps, jccs, and calls), don't use a cs: override, or use a few other rarely used techniques, you really don't have to worry what the CS:IP register set is. If the BIOS didn't set them to a valid value, your boot code wouldn't be executed anyway.

There are two most used techniques. The first, is to set DS and ES to 0x07C0 and use an org of 0x0000. The second is to set DS and ES to 0x0000 and use an org of 0x7C00. Either way, you must not assume a value in the DS or ES register, and must set them to one or the other value when using one of these two techniques.

To further this, a normal technique is to set SS to 0x0000 and SP to 0x7C00 so that the first push to the stack will be just below the boot sector.

That's just my 2 cents.

-- Ben
https://www.fysnet.net/osdesign_book_series.htm

I suggest you at the very beginning.

wishedtobe wrote: ↑Tue Jul 29, 2025 1:19 am I suggest you

Code: Select all

push word 0x7c0
push word start
retf
start:

at the very beginning.

I'm not very practiced in x86 asm, but isn't this just a longer, unclear version of JMP 0x07c0:0000? Also, it makes the assumption that SS:SP points to a region of RAM which doesn't conflict with anything. I've heard many times that you should never do this, always set SS:SP first.

eekee wrote: ↑Tue Jul 29, 2025 2:34 am I'm not very practiced in x86 asm, but isn't this just a longer, unclear version of JMP 0x07c0:0000? Also, it makes the assumption that SS:SP points to a region of RAM which doesn't conflict with anything. I've heard many times that you should never do this, always set SS:SP first.

I forgot that. I'm too accustomed to the instruction retf.

Programmed return is powerful. Some Forth code uses it for weird and wonderful tricks as the stack is accessible in high level code. It's also a neat way to start a new process. And there's a lot to be said for not bothering to remember every x86 instruction.