Page 1 of 2
Is this going to work?
Posted: Mon Apr 09, 2012 8:47 pm
by ghostlyfoot
I need to know if this works so I know if the tools I am using are faulty. I have been using nasm and partcopy, but it seems to only show a blank prompt when I boot this from a usb key. It is supposed to print a welcome message to the screen.
Code: Select all
mov si, msg
call print_string
hang:
jmp hang
print_string:
lodsb
cmp al, 0
je print
ret
print:
mov ah, 0x09
int 0x10
jmp print_string
msg db 'Welcome to OS', 0
times 510-($-$$) db 0
dw 0xAA55
Re: Is this going to work?
Posted: Mon Apr 09, 2012 9:08 pm
by GAT
Almost, where it says
Change that to
I think that should work.
Re: Is this going to work?
Posted: Mon Apr 09, 2012 9:52 pm
by Rudster816
1. You need to setup your segments
2. You need to setup a stack for the BIOS to use
3. You're using the wrong AH value to print a character
4. What ghostlyfoot said
Because I'm very bored right now:
Code: Select all
ORG 0x7C00
BITS 16
jmp 0x0:start
start:
cli
xor ax, ax
mov ds, ax
mov es, ax
mov fs, ax
mov gs, ax
mov ss, ax
mov sp, 0x7C00
sti
mov si, msg
call print_string
cli
hlt
print_string:
lodsb
test al, al
jnz print
ret
print:
mov ah, 0xE
int 0x10
jmp print_string
msg db 'Welcome to OS', 0
times 510-($-$$) db 0
dw 0xAA55
Re: Is this going to work?
Posted: Tue Apr 10, 2012 2:29 am
by Chandra
Ah, let me make it concise. Rewrite everything.
OSDEV Wiki at your service!
Re: Is this going to work?
Posted: Tue Apr 10, 2012 12:58 pm
by qw
Some emulators stop updating the screen if you do that, and you may not see the printed message at all. You'd better try this:
Re: Is this going to work?
Posted: Wed Apr 11, 2012 12:44 am
by Combuster
Which doesn't fix the problem at all if interrupts are already off. You'll probably want
for QEMU-safe debugging purposes.
Re: Is this going to work?
Posted: Wed Apr 11, 2012 6:02 pm
by ghostlyfoot
This is what I managed to put together based on the wiki and your advice:
Code: Select all
bits 16
org 0x7C00
SECTION .text
jmp begin
begin:
jmp setup_stack
setup_stack:
mov esp, stack_end
jmp next
next:
mov si, msg
call print_string
cli
jmp $
print_string:
lodsb
cmp al, 0
jne print
ret
print:
mov ah, 0x09
int 0x10
jmp print_string
SECTION .bss
msg db 'Welcome to OS', 0
stack_begin:
resb 4096
stack_end:
times 510-($-$$) db 0
dw 0xAA55
It gives me many, many, many warnings when i assemble it, though. What is the problem?
Re: Is this going to work?
Posted: Wed Apr 11, 2012 6:49 pm
by VolTeK
Why don't you read the warnings.
Re: Is this going to work?
Posted: Wed Apr 11, 2012 8:32 pm
by Rudster816
ghostlyfoot wrote:This is what I managed to put together based on the wiki and your advice:
-SNIP-
It gives me many, many, many warnings when i assemble it, though. What is the problem?
You failed to take a lot of my advice, and your code is far worse then what you had to begin with. I'll do a rundown the problems (there's a lot)...
1. You still fail to setup your segments before doing stuff that would require that
2. You have three useless jmp instructions (the first three).
3. You're still using the wrong AH value to print a character
4. You need to create a flat binary, there are no .bss or .text sections
5. Boot sectors are only 512 bytes long, so even though I believe the resb X works in binary mode (I believe its equal times X db 0), you can't have 4kb worth of 0's in a 512 byte boot sector.
Re: Is this going to work?
Posted: Wed Apr 11, 2012 8:38 pm
by Kazinsal
Rudster816 wrote:4. You need to create a flat binary, there are no .bss or .text sections
NASM interprets .text meaning everything from the org offset until the .data section, .data meaning everything from there until the end of the binary, and .bss meaning locations in memory after the end of the binary. So, as misused as they are, they're still kind of correct.
Re: Is this going to work?
Posted: Thu Apr 12, 2012 5:10 pm
by qw
Combuster wrote:Which doesn't fix the problem at all if interrupts are already off.
True, interrupts should be enabled. The HLT is not really necessary (JMP $ is just fine) but it reduces power consumption (on real hardware).
Re: Is this going to work?
Posted: Fri Apr 13, 2012 7:54 am
by brain
Hobbes wrote:Combuster wrote:Which doesn't fix the problem at all if interrupts are already off.
True, interrupts should be enabled. The HLT is not really necessary (JMP $ is just fine) but it reduces power consumption (on real hardware).
It also reduces cpu usage of your emulator, on emulated hardware
Re: Is this going to work?
Posted: Fri Apr 13, 2012 8:34 am
by Combuster
Well what matters more after a crash, debug info or a lower power consumption?
Re: Is this going to work?
Posted: Fri Apr 13, 2012 11:03 am
by ghostlyfoot
Code: Select all
bits 16 ; 16 bit REAL MODE
org 0x07C00 ; originates at 0x07C00
jmp 0x0:start ; jump to starting point at 0x0 offset start
start: ; starting point
; setup segments
cli ; disable interrupts
xor ax, ax ; make ax 0
mov ds, ax ; make ds 0
mov es, ax ; make es 0
mov fs, ax ; make fs 0
mov gs, ax ; make gs 0
mov ss, ax ; make ss 0
mov sp, 0x7C00 ; tell bios where the stack is?
sti ; enable interrupts
mov si, msg ; move our message into si
call print_string ; let's print
cli ; disable interrupts so nothing 'interrupts' our hang
jmp $ ; keep jumping to this line
print_string: ; will print a string in si
lodsb ; get si and put it in al
cmp al, 0 ; is al null?
jne print ; if it isn't, jmp to print
ret ; return to calling method
print: ; called by print_string
mov ah, 0xE ; tell bios we want to print
int 0x10 ; PRINT!
jmp print_string ; loop
msg db 'Welcome to OS', 0 ; make a message and name it 'msg'
times 510-($-$$) db 0 ; fill with 0s
dw 0xAA55 ; siggy
Did I get all of this right (the comments)? Also, I know you use int 0x13 to load bytes, but I am using a USB flash drive and all of the sample code seems oriented toward a floppy. Can i use the same sectors per track, etc.?
EDIT: I am now using nasm and dd on either ubuntu or trisquel linux depending on the mood im in.
Re: Is this going to work?
Posted: Fri Apr 13, 2012 8:32 pm
by evoex
berkus wrote:Combuster wrote:Well what matters more after a crash, debug info or a lower power consumption?
Imagine an unattended PC crashing, setting its power consumption to the maximum (CPU full speed etc), and then staying in this condition until a human technician checks it. Maybe weeks.
Of course, you could also just use something like:
Code: Select all
#ifndef NDEBUG
jmp $
#else
hlt
#endif