All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frank Kotler <fbkotler@comcast.net>
To: httu <httu@tma.com.vn>
Cc: "linux-assembly@vger.kernel.org" <linux-assembly@vger.kernel.org>
Subject: Re: please help me
Date: Tue, 09 May 2006 12:17:31 -0400	[thread overview]
Message-ID: <4460C09B.70107@comcast.net> (raw)
In-Reply-To: <000101c6734a$573086d0$c41e1ec7@TuThuyHa>

Hi Tuha,

> Coming on with my bootin :)

Good!

> I install my interrupt handler at the vector 0x21.
> But I cannot reach the interrupt handler.

Another segment:offset mismatch, I think. The label "interrupt_handler" 
is calculated as the offset into the file, plus any ".org" we specify - 
none, in this case. This is correct with respect to BOOTSEG, 0x7C0. 
07C0:00xx will hit code or data in our bootsector... but %cs is still 
whatever bios set it - almost certainly zero. (there are rumors of 
biosen that jump to 07C0:0000 - extremely rare, if it exists at all) You 
want the address in the IVT to be 07C0:00xx or 0000:7Cxx - 0000:00xx 
won't work.

> The led of floppy drive lights up
> forever. It should be turned off when bios has loaded the boot sector into
> RAM!!?

I don't know about this one. I've seen code that turns off the floppy 
motor - via ports on the floppy controller - pretty much "first thing". 
I *thought* that would only be necessary if we had interrupts 
disabled... as we would when entering protected mode, or sometimes when 
altering %ss:%sp. The fact that your code jumps off into lala-land 
attempting the int 21h may be causing it. I'd try to get that fixed 
first, and tackle this if it's still a problem.

> Here is the piece of code.
> 
> .code16
> .section .text
> .globl _start
> _start:
> 	movw	$STACK_SEGMENT, %sp
> 	movw	%sp, %ss
> 	movw	$STACK_SIZE, %sp

A STACK_SIZE of 0xffff is going to mis-align your stack, so all stack 
access will be slow! If you want to use the entire segment, zero is a 
perfectly good initial %sp - it will be decremented, and the first 
(word) push will go at 0xfffe.

I mentioned that sometimes we cli/sti around altering %ss:%sp... I don't 
think it's really necessary these days - non-buggy CPUs disable 
interrupts for one instruction after a load of %ss anyway. Altering %sp 
first, then %ss, then %ss again might be "dangerous", I'm not sure. 
It'll work most of the time anyway - the odds of an interrupt occuring 
in the middle of this are small - but I suppose you'd like it to work 
*all* the time...

> 	pushw	$BOOTSEG
> 	popw	%ds
> 	pushw	$SCREEN_SEGMENT
> 	popw	%es
> 
> #Blank screen
> 	call 	clearScreen
> 
> #Say hello
> 	movw	$MESSAGE_POS, cursor_pos
> 	call 	printString
> 
> #install interrupt handler
> 	pushw	%ds
> 	pushw	$0
> 	popw	%ds
> 	movw    $interrupt_handler, %ds:(4 * 0x21)
> 	movw    %cs, %ds:(4 * 0x21 + 2)

Try "$BOOTSEG" here instead of %cs - I *think* that's the problem.

> 	popw	%ds
> 
> 
> #test interrupt hander
> 	int	$0x21
> 
> 
> die:	jmp	die
> 
> #
> # Functions 
> #
> 
> .type   clearScreen, @function
> clearScreen:
> 	movb	$SCREEN_COLS, %al
> 	movb	$SCREEN_ROWS, %bl
> 	mulb	%bl
> 	movw	%ax, %cx
>         movb    screen_color, %ah
>         movb    $0, %al
> 	xorw 	%di, %di
> 	rep
> 	stosw		#Write ax to to screen and decrement cx, until cx
> equals 0
> 	movw	$0, cursor_pos
> 	ret
> 
> 
> .type   printString, @function
> printString:
> 	movb	message_color, %ah
> 	movw	$MESSAGE_SIZE, %cx
> 	movw	$welcomeMessage, %si
> 	movw	cursor_pos, %di
> loop0:
> 	lodsb		#load byte from string
> 	stosw		#store byte and color on screen
> 	loop 	loop0	#decrement cx, jump to loop0 if cx > 0
> 	movw	%di,  cursor_pos
> 	call	newline

???

> 	ret
> 
> 
> #
> #interupt handlers
> #
> 
> interrupt_handler:
> 	pusha
> 
>         movb    screen_color, %ah
>         movw    $MESSAGE_SIZE, %cx
>         movw    $welcomeMessage, %si
>         movw    cursor_pos, %di
> loop1:
>         lodsb           #load byte from string
>         stosw           #store byte and color on screen
>         loop    loop1   #decrement cx, jump to loop0 if cx > 0
>         movw    %di,  cursor_pos
> 
> 	popa
> 	iret
> 
> 
> #.section .data
> welcomeMessage: .ascii "Hey! my boot loader."
> MESSAGE_SIZE	= . - welcomeMessage
> screen_color:   .byte 0x07      # White on black
> message_color:  .byte 0x03	# cyan on black     
> cursor_pos:     .word 0x0
> 
> 
> .org 510
> boot_flag:      .word 0xAA55
>  
> 
> #constants
> .equ MESSAGE_POS       , 860		#offset 30 at line 5.
> .equ STACK_SEGMENT     , 0x9000      # Top of conventional memory
> .equ STACK_SIZE        , 0xffff      # 64K - 1 bytes of stack
> .equ SCREEN_SEGMENT    , 0xb800
> .equ SCREEN_COLS       , 80
> .equ SCREEN_ROWS       , 25
> .equ BOOTSEG           , 0x07C0                /* original address of
> boot-sector */
> 
> Thanks in advance,

Hope it helped. I haven't tested your code - what's the command-line to 
as? "-oformat=binary"? (I'm a Nasm user). I'm cc'ing this to the list 
(if you just hit "reply", it goes only to sender - you gotta "reply all" 
to have it go to the list. PITA!), in case someone can correct any 
errors. Hope that's what you intended. (If not... too late! :)

Best,
Frank


       reply	other threads:[~2006-05-09 16:17 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <000101c6734a$573086d0$c41e1ec7@TuThuyHa>
2006-05-09 16:17 ` Frank Kotler [this message]
2006-05-10 14:05   ` please help me httu
2014-09-10 12:01 Please Help Me Alina Yukov
  -- strict thread matches above, loose matches on Subject: below --
2014-08-20 15:53 PLEASE HELP ME Abdoul Issouf
2014-08-20 15:20 mrissouf issouf
2011-11-26  6:49 Please help me shibin k reeny
2009-12-21  9:15 please " rajkumar
2009-12-21 10:48 ` Emmanuel Florac
2007-01-05  8:01 Please " Debasree Mallick
2007-01-05  8:04 ` Justin Patrin
2007-01-05  8:14   ` Debasree Mallick
2007-01-05  8:43     ` Matthew Palmer
2007-01-05  8:54       ` Marcin Juszkiewicz
2007-01-10  7:13       ` Debasree Mallick
2007-01-11  0:17         ` Justin Patrin
2006-08-28 12:30 Kumar, Satish B
2006-08-28 14:30 ` Mouhammad Tayseer Alquoatli
2006-04-24 10:11 please " Tu Ha
2006-04-24  4:11 ` Frank Kotler
2006-04-24 12:09   ` Tu Ha
2004-03-30  9:48 Sofia Pujeh
2003-09-19  8:55 Vijay Angelo
2003-09-19  9:45 ` Arvanitis Kostas
1999-12-31  2:29 Please " dony
1999-12-27  8:42 ` Raphael Bossek
2000-01-02  7:23   ` dony
1999-12-30  2:11 ` Brendan J Simon
     [not found]   ` <38701F3A.FAD6263E@huawei.com.cn>
1999-12-30  4:23     ` Brendan J Simon
     [not found]       ` <38704D0B.94438516@huawei.com.cn>
1999-12-30  6:46         ` Brendan J Simon
1999-12-30 13:25           ` Charles Lepple
     [not found] ` <000401bf5016$4757c420$0201a8c0@home>
1999-12-31  8:37   ` dony
     [not found]     ` <000c01bf5086$3e358d80$0201a8c0@home>
2000-01-01  1:58       ` dony
     [not found]         ` <001801bf50e1$6d3ad8a0$0201a8c0@home>
2000-01-01  8:46           ` dony
1999-12-31  8:40   ` dony

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4460C09B.70107@comcast.net \
    --to=fbkotler@comcast.net \
    --cc=httu@tma.com.vn \
    --cc=linux-assembly@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.