flat assembler
Message board for the users of flat assembler.

Index > OS Construction > Help understanding "jmp 0000:0000" to another prog

Author
Thread Post new topic Reply to topic
Coddy41



Joined: 18 Jan 2009
Posts: 384
Location: Ohio, USA
Coddy41
OK, I am wanting to try to make a two stage boot loader. now I under stand how to use int
0x13 and ah = 02 to read files into to memory I also understand after that I have to jump to the
file, what I don't get is how the whole jmp thing works, I under stand org 0x0100 I would use
jmp 0000:0100, but I also have found out if my kernel is at 0800:0000 and I make a jmp inside
of it to say 0800:0100 I will jump to line 100 in the kernel.

I guess what I am asking is this. How is the first number in 0800:0000 decided when I am
loading it? do I choose it some how, or is it all based off of how much memory the file takes
up?

PS: please excuse any bad grammar.

_________________
Want hosting for free for your asm project? You can PM me. (*.fasm4u.net)
Post 24 Nov 2009, 17:39
View user's profile Send private message Visit poster's website Reply with quote
bitshifter



Joined: 04 Dec 2007
Posts: 764
Location: Massachusetts, USA
bitshifter
Hello
Maybe this will help you...
http://board.flatassembler.net/topic.php?t=10790
Post 24 Nov 2009, 18:47
View user's profile Send private message Reply with quote
Coddy41



Joined: 18 Jan 2009
Posts: 384
Location: Ohio, USA
Coddy41
Yes, it somewhat helped me, I suppose I should have done a better search...

I found the solution to my problem. I just do this:
Code:
    
mov     bx, 0x0600      
mov     es, bx          
mov     bx, 0x0000
; K, kernel loaded @ [0600:0000]    

thanks...

_________________
Want hosting for free for your asm project? You can PM me. (*.fasm4u.net)
Post 24 Nov 2009, 20:03
View user's profile Send private message Visit poster's website Reply with quote
windwakr



Joined: 30 Jun 2004
Posts: 827
Location: Michigan, USA
windwakr
I think it would be a smarter idea to load your kernel into a segment that is a multiple of 1000, that way you can't accidentally write to it when doing something else.

When you stick to 1000's for the segment, it makes everything so much easier. You then just have 65,536 bytes you can write to, and then move onto the next 1000 segment.

With something like 0600:0000, things just get complicated.

Each point in memory can be accessed by up to 4,096 different segment:offset pairs! So, for me at least, I keep the segment as a multiple of 1000.
http://mirror.href.com/thestarman/asm/debug/Segments.html


If you want it loaded there, load it to 0:6000. Same place in memory, and keeps segment:offset nice.

_________________
----> * <---- My star, won HERE
Post 24 Nov 2009, 20:30
View user's profile Send private message Reply with quote
Coddy41



Joined: 18 Jan 2009
Posts: 384
Location: Ohio, USA
Coddy41
I didn't think of that..
OK, so i will load the second stage to 1000:0000 and my kernel to 2000:0000. And if I
load any progs I should also load it to 3000:0100.

Or since stage two is so small I could load it at 0500:0000 and load the kernel at
1000:0000.

Edit: oh, thanks for the link, didn't see it there Very Happy

_________________
Want hosting for free for your asm project? You can PM me. (*.fasm4u.net)
Post 24 Nov 2009, 20:45
View user's profile Send private message Visit poster's website Reply with quote
windwakr



Joined: 30 Jun 2004
Posts: 827
Location: Michigan, USA
windwakr
Coddy41 wrote:
Or since stage two is so small I could load it at 0500:0000...


0000:5000 would be a better choice. It is the exact same point in memory, but wouldn't start overwriting the 1000:xxxx's at the end of it.

At 0500:B000 and up, you would be overwriting whats at 1000:0000 and up.


Although, like you say, your stage two wouldn't be that big, so I guess it's up to you.




I would love to find the man who invented the Segment:Offset addressing and punch him in the face. Very Happy

_________________
----> * <---- My star, won HERE
Post 24 Nov 2009, 21:25
View user's profile Send private message Reply with quote
Coddy41



Joined: 18 Jan 2009
Posts: 384
Location: Ohio, USA
Coddy41
Yeah, I'll just go with the first idea in my previous post. Thanks for all the help Very Happy

Quote:
I would love to find the man who invented the Segment:Offset addressing and punch him in the face. Very Happy

Yes. Twisted Evil

_________________
Want hosting for free for your asm project? You can PM me. (*.fasm4u.net)
Post 24 Nov 2009, 22:07
View user's profile Send private message Visit poster's website Reply with quote
tom tobias



Joined: 09 Sep 2003
Posts: 1320
Location: usa
tom tobias
windwakr wrote:
...I would love to find the man who invented the Segment:Offset addressing and punch him in the face....
Sorry to disagree with you and coddy. It is not the guy or gal who misdesigned the Intel cpu, but rather the marketing/sales gurus at IBM who deserve our wrath. The engineers at IBM, as I understand it, agreed with all of us, back in 1979, that the Motorola 68000 was far superior to the 8086. So, why did IBM choose the Intel product instead?
It is important to note that even though the 68000 had a 16bit ALU, addresses were always manipulated by 32bit instructions. I.e. not only was the address space 32bit, but flat addressing was used. Contrast this to the 8086, which had 20bit address space, but could only access 16bit (64 kilobyte) chunks without resorting to slow extra instructions. The clever 68000 compromise was that in spite of databus and ALU width being 16bit, address arithmetic always is 32bit
Post 25 Nov 2009, 11:48
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.