-2
bits 32
main:

    mov ah, 09h
    mov bh, 0
    mov cx, 80
    mov bl, 01110000b
    mov al, ' '
    int 10h

    jmp $

times 512-($-$$) db 0
Alexey Frunze
  • 61,140
  • 12
  • 83
  • 180
Deckdyl
  • 103
  • 1
  • 2
  • 12

2 Answers2

0

You're not in 32-bit mode yet, so use bits 16.

Also, in protected mode, BIOS functions aren't available. Just so you know and don't attempt calling them when in protected mode.

Alexey Frunze
  • 61,140
  • 12
  • 83
  • 180
0

It is, in fact, the bits 32 that keeps this from working. You can see what's happening by using ndisasm. Assemble it as-is, and disassemble it with ndisasm. The default for ndisasm is 16 bits, but you can specify -b16 for clarity. This is what the CPU will "see" if it's in 16-bit mode... which it is. It'll take some more code to switch to 32-bit mode - you'll get to that soon, but the CPU starts up in 16-bit mode (even a 64-bit CPU). To see what the CPU would "see" if/when it's in 32-bit mode, disassemble again with -b32. See the difference? Your mov bl, 01110000b has disappeared, being "gobbled up" by the mov cx, 80! Then try it again without the bits 32. You can say bits 16, but that's Nasm's default anyway.

There's a subtle difference between telling the assembler bits 32 and actually having the CPU in 32-bit mode. Ordinarily, this wouldn't cause much trouble (sombody else - the OS - has determined the CPU mode), but in a boot sector it will!

When you get to actually switching the CPU to 32-bit protected mode, at that point - exactly - you will want to tell Nasm bits 32.

Lots of information about this at http://www.osdev.org - I recommend it! I also have an example posted to a newsgroup - a long time ago - by Alexey ("Alexei" actually - that's you isn't it?).

Happy bootin',

Frank

Frank Kotler
  • 1,462
  • 1
  • 8
  • 4