Includes don't go at the top
When using a directive like %include "print.asm", NASM will insert the contents of the file print.asm right where you have written the line. The same is true for %include "text.asm". The expanded source text thus becomes:
bits 16
org 0x7C00
print: \ %include "print.asm"
mov ah, 0x0E |
|
.print_loop: |
lodsb |
or al, al |
je .print_done |
int 0x10 |
jmp .print_loop |
|
.print_done: |
cli |
ret /
boot_string_00: db "Placeholder OS Title v0.0.1", 0 \ %include "text.asm"
boot_string_01: db "Loading Operating system", 0 /
boot:
mov si, boot_string_00
call print
mov si, boot_string_01
call print
times 510 - ($-$$) db 0
dw 0xAA55
Now, when BIOS has finished loading your bootsector code at the address 0x7C00, it will transfer control to that same address in memory. The first instruction that the CPU encounters will be mov ah, 0x0E and so our printing loop starts. Problem is, we haven't yet setup the pointer to the message. The intend was for the code to start executing at the boot label, and the includes made that go wrong.
A quick solution would be to have a jmp boot instruction as the very first instruction beneath the org 0x7C00 directive. But why waste 2 or 3 bytes when we could just as well, and better, place the includes below the rest of the code? That's going to be the preferred solution:
bits 16
org 0x7C00
boot:
mov si, boot_string_00
call print
mov si, boot_string_01
call print
%include "print.asm"
%include "text.asm"
times 510 - ($-$$) db 0
dw 0xAA55
Let's expand the includes again and verify that the problem is resolved.
bits 16
org 0x7C00
boot:
mov si, boot_string_00
call print
mov si, boot_string_01
call print
print: \ %include "print.asm"
mov ah, 0x0E |
|
.print_loop: |
lodsb |
or al, al |
je .print_done |
int 0x10 |
jmp .print_loop |
|
.print_done: |
cli |
ret /
boot_string_00: db "Placeholder OS Title v0.0.1", 0 \ %include "text.asm"
boot_string_01: db "Loading Operating system", 0 /
times 510 - ($-$$) db 0
dw 0xAA55
Both messages print fine, but, as you can see, once the second call print returns, the code falls through in the print routine and starts printing an empty message (because the SI register is pointing at the first zero-byte inserted by the times directive).
A far worse problem is, that because this (third) time, the ret instruction has no sensible return address on the stack, the computer will crash, but in a dangerous way because there's no telling about where execution will go to!
The solution is to prevent the code falling through in the print subroutine. Because our program has nothing more to do, we will insert a halting loop so the CPU doesn't waste precious cycles in a tight loop. The preferred way is cli hlt jmp $-2.
bits 16
org 0x7C00
boot:
mov si, boot_string_00
call print
mov si, boot_string_01
call print
cli
hlt
jmp $-2
%include "print.asm"
%include "text.asm"
times 510 - ($-$$) db 0
dw 0xAA55
There's room for improvement in the present print routine
- The BIOS.Teletype function 0Eh expects the
BH register to contain the desired DisplayPage and the BL register the desired GraphicsColor for when the screen is in a graphics mode.
- There's no sense in having the
cli instruction in this code.
- Testing the
AL register for zero, would better use test al, al.
- A simple loop like this should never use 2 branch instructions (while iterating).
- This code depends on a correct
DS segment register. Make sure the calling code has xor ax, ax mov ds, ax in accordance with the org 0x7C00 directive.
print:
mov bx, 0x0007 ; DisplayPage BH=0, GraphicsColor BL=7
jmp .begin ; This is what makes 'empty messages' OK
.print:
mov ah, 0x0E ; BIOS.Teletype
int 0x10
.begin:
lodsb
test al, al
jnz .print
ret
Answering the additional question will improve the code even further
Also, I was wondering how i could implement newlines in assembly so that i could just use '\n' in my strings.
In NASM you can define string litterals in 3 different ways. Using single quotation marks ', using double quotation marks ", or using backticks `.
Only with the backticks can you include escape sequences in the text. In order to insert newlines \r\n, your text.asm would need to become:
boot_string_00: db `Placeholder OS Title v0.0.1\r\n`, 0
boot_string_01: db `Loading Operating system\r\n`, 0
to produce
Placeholder OS Title v0.0.1
Loading Operating system
Now that the newlines are embedded in the messages, you could consider simplifying the code and output the 2-line message as a whole, for a total savings of 7 bytes:
boot_string: db `Placeholder OS Title v0.0.1\r\nLoading Operating system\r\n`, 0
Why the \r\n sequence, and not simply \n?
For reference a quote from the Wikipedia article about escape sequences:
\n produces one byte, despite the fact that the platform may use more than one byte to denote a newline, such as the DOS/Windows CR-LF sequence, 0x0D 0x0A. The translation from 0x0A to 0x0D 0x0A on DOS and Windows occurs when the byte is written out to a file or to the console, and the inverse translation is done when text files are read.
The \n (newline) escape sequence only inserts the linefeed byte (10), but since this is bootloader code, and not DOS/Windows, BIOS will require both the carriage return byte (13) and the linefeed byte (10) in order to perform a move to the beginning of the next line. That's why we need to write \r\n.
