Assembly Printing Outputs Unexpected Result: just an " S"

Question

I'm relatively new to assembly programming and was wondering why my code does not print the expected strings. This project is supposed to be a bootloader when finished. I am compiling using the command nasm -f bin boot.asm -o boot.bin. There are no errors during compilation.

boot.asm

bits 16
org 0x7C00

%include "print.asm"
%include "text.asm"

boot:
        mov si, boot_string_00
        call print
        mov si, boot_string_01
        call print

times 510 - ($-$$) db 0
dw 0xAA55

print.asm

print:
        mov ah, 0x0E

.print_loop:
        lodsb
        or al, al
        je .print_done
        int 0x10
        jmp .print_loop

.print_done:
        cli
        ret

text.asm

boot_string_00: db "Placeholder OS Title v0.0.1", 0
boot_string_01: db "Loading Operating system", 0

Expected Output:

PlaceHolder OS Title v0.0.1Loading Operating System

Actual Output:

S

Also, I was wondering how i could implement newlines in assembly so that i could just use '\n' in my strings.

You included your extra files at the top of your bootloader where they'll execute first. Use a debugger like BOCH's built-in one, this should be pretty easy to see in the disassembly view. asm doesn't have functions; you have to implement them yourself out of labels and branches. — Peter Cordes, Apr 07 '20 at 02:48

Furkan Çetinkaya · Answer 1 · 2020-04-07T19:34:08.877

3

You included stuff at the top of your bootloader, where it will executes first. Instead include extra functions where they aren't in the main path of execution and are only reached by call.

Please try. According to the comments I edited the code

boot.asm:

[bits 16]
[org 0x7c00]

boot:
  xor ax, ax
  mov ds, ax        ; set up DS to make sure it matches our ORG

  mov si, boot_string_00
  call println

  mov si, boot_string_01
  call println

finish:       ; fall into a hlt loop to save power when we're done
  hlt
  jmp finish


%include "printf.asm"      ; not reachable except by call to labels in this file
%include "text.S"


times 510-($-$$) db 0
dw 0xaa55

printf.asm:

print:
        mov ah, 0x0E      ; call number for int 0x10 screen output

print_loop:
        lodsb
        test al, al
        je print_done
        int 0x10
        jmp print_loop

print_done:
        ret

println:
  call print
  mov si, line_end
  call print
  ret

text.S:

boot_string_00: db "Placeholder OS Title v0.0.1", 0
boot_string_01: db "Loading Operating system", 0
line_end:       db 0xD, 0xA, 0

(Editor's note: fixed this code myself instead of trying to describe the change in comments)

edited Apr 07 '20 at 19:34

answered Apr 07 '20 at 05:07

Furkan Çetinkaya

170
6

1

Linebreak should be a CR (13, 0Dh) followed by LF (10, 0Ah). – ecm Apr 07 '20 at 10:27
1

You should add the following after the last call to `print`: `halt:` \ `sti` \ `hlt` \ `jmp halt` – ecm Apr 07 '20 at 10:28
1

You should also add segment register initialisation, before calling the function: `xor ax, ax` \ `mov ds, ax` – ecm Apr 07 '20 at 10:31
1

Why would you want `print` to disable interrupts before returning? That doesn't make sense as part of printing. If the main bootloader wants that, it can do it itself. Also, use `test al,al` not `or al,al`. They both work but [`test` is better for efficiency](https://stackoverflow.com/questions/33721204/test-whether-a-register-is-zero-with-cmp-reg-0-vs-or-reg-reg/33724806#33724806) and is more idiomatic. You have your `line_end` backwards. It probably works here but more standard to do `\r\n` not `\n\r`. There's also no need to put the `finish` loop after the includes; before is fine. – Peter Cordes Apr 07 '20 at 16:27
As Peter Cordes listed, the order of the linebreak should be CR 13 LF 10, not 10 13. The `cli` is wrong but to be fair that was already present in the question. However, you should change "[the halting loop from `JMP $` to `sti` \ `hlt` \ `jmp` to idle while halting. This means the qemu process won't waste CPU time while running this loop.](https://stackoverflow.com/questions/60980527/how-to-solve-bootloader-asm30-error-times-value-44-is-negative-problem-in/60988502#60988502)" – ecm Apr 07 '20 at 16:47
Thanks for these informative comment. I editied the code. @PeterCordes – Furkan Çetinkaya Apr 07 '20 at 18:43
@ecm Thanks for these informative comments. I editied the code. – Furkan Çetinkaya Apr 07 '20 at 18:43
1

Now your finish loop isn't a loop. You `jmp` to a `hlt` and then fall off the end. Instead, fall into the `hlt` and then `jmp` back to before the `hlt`. – Peter Cordes Apr 07 '20 at 18:45
@PeterCordes I did not understand. Is it for that "Don't finish the program. If an interrupt occurs, do the another job." for future extension of the code or something else? – Furkan Çetinkaya Apr 07 '20 at 19:04
1

Try it in an emulator + debugger like BOCHS or QEMU. Set a breakpoint on the `times 510-($-$$) db 0` and note that it's reached after the first timer or keyboard interrupt after `hlt` runs. You should put `hlt` *in* a loop because it only sleeps until the next interrupt. (The other via option is `cli` / `hlt` (because no NMIs should happen so nothing will wake hlt up) but then you can't reboot with ctrl+alt+del because interrupts are disabled so the keyboard interrupt is ignored.) – Peter Cordes Apr 07 '20 at 19:10
I edited your answer since apparently you're not understanding what I was trying to describe. The reason for it is in my previous comment. – Peter Cordes Apr 07 '20 at 19:16
1

What is the point of putting `halt_op:` after the includes? There's zero benefit to looping there instead of at the end of the main code. IMO every part of your last edit made your answer worse, removing comments (especially the ones that explain the key change) and making the code more complicated with an extra jmp. Adding the `magic_num:` label was almost an improvement, but you put it on the padding, not the actual boot signature. But it's your answer, feel free to do whatever you want. – Peter Cordes Apr 07 '20 at 19:25
Sorry for reediting. I did not realize it. I am converting it back. @PeterCordes – Furkan Çetinkaya Apr 07 '20 at 19:27
1

Yeah, looks fine now. The key parts you initial answer was missing was some text explaining what the problem was, and why the change fixed it. That's part of what I added with my edit, along with comments in the code pointing that out. – Peter Cordes Apr 07 '20 at 19:40
@PeterCordes Thanks for comments – Furkan Çetinkaya Apr 07 '20 at 19:44

Assembly Printing Outputs Unexpected Result: just an " S"

1 Answers1