If the initial part of your program fits in 512 bytes, and you don t mind restricting yourself to BIOS calls, in/out instructions, and writing to magic memory locations for I/O... Then yes!

Assuming you re using NASM, here s a goofy example... (Warning: my 16-bit assembly skills are not very great and kind of rusty, so it might not be the best code.)

[org 7c00h]              ; BIOS will load us to this address

mov ax, 0b800h           ; Console memory is at 0xb8000; set up a segment
mov es, ax               ; for the start of the console text.

;
; Let s clear the screen....
;

xor di, di               ; Start at beginning of screen
mov cx, 80*25            ; Number of chars in the screen
mov al,                  ; Space character
mov ah, 0fh              ; Color (white on black)
repne stosw              ; Copy!

;
; Write an  a  to the screen...
;

mov byte [es:0],  a      ; Write an  a 

sleep:
hlt                      ; Halts CPU until the next external interrupt is fired
jmp sleep                ; Loop forever

times 510-($-$$) db 0    ; Pad to 510 bytes
dw 0aa55h                ; Add boot magic word to mark us as bootable

Then you can assemble with:

nasm foo.asm

And write this to a floppy image like this: (Assuming a Unix-type system...)

$ dd if=/dev/zero of=floppy.img bs=512 count=2880
$ dd if=foo of=floppy.img conv=notrunc

Now you can boot that floppy image in Bochs (or, if you write it to a floppy, run it on a real PC) and it should write an a to the screen.

Note that this is normally only useful if you re writing a bootloader or an operating system... But it s fun to experiment with, especially if you re learning.

Update: I read the emu8086 website... Seems kind of oriented towards embedded use of x86 rather than a PC. It looks like it has some interesting features for simulating hardware. If you re not interested in targeting PCs then Bochs will not be of must interest. If that s not what you want to do, I agree with the commenter who suggested using emu8086 itself.

If you are interested in PCs but want something to step through your programs... I ve often used qemu for this purpose. Its debugging flags (see manpage under -d) are sufficient for observing the execution state of an x86 program at the assembly level. (I ve even found it useful enough for debugging OS kernels written in C, provided you look very carefully what the C compiler generates.)

sudo apt-get install bochs bochs-sdl

printf  ata0-master: type=disk, path="main.img", mode=flat, cylinders=1, heads=1, spt=1
boot: disk
display_library: sdl
megs: 128
  > .bochsrc

bochs -q

worked for me on Ubuntu 14.04, Bochs 2.4.6 with a 512 byte long boot sector main.img.

• cylinders=1, heads=1, spt=1 specifies the disk size, and must match your image! Here we set everything to 1 to mean 1 cylinder, which is 512 bytes like our image file.
• display_library: sdl may be needed because of an Ubuntu packaging bug

main.img was generated from main.asm:

org 0x7c00
bits 16
cli
mov ax, 0x0E61
int 0x10
hlt
times 510 - ($-$$) db 0
dw 0xaa55

Then:

nasm -f bin -o main.img main.asm

This images uses the BIOS to print a single character a to the screen.

It is possible to avoid the creation of the .bochsrc file by using the following command line:

bochs 
    -qf /dev/null 
     ata0-master: type=disk, path="main.img", mode=flat, cylinders=1, heads=1, spt=1  
     boot: disk  
     display_library: sdl  
     megs: 128 

The -qf /dev/null part is ugly, but it is the only way I ve managed to automatically skip the menu screen:

• -q or -n always ask for it, and I have to hit 6 for it to run afterwards
• -qn <(echo ...) also worked, but uses a Bash extension which would fail on my Makefile

QEMU s interface was easier to get started with, so I recommend using it instead.

GitHub repository with this example: https://github.com/cirosantilli/x86-bare-metal-examples/blob/cba0757990843f412b14dffad45467ad0034d286/Makefile#L33

That s not what you really want to do. (Well, maybe it is...)

Basically, Bochs is a x86 PC emulator. In order to execute machine code on that, you need to get the machine code on to a "disk" image. A disk image is a file that is structured like a disk (a floppy or hard drive).

The PC has a specific boot sequence that looks at sections of the disk, loads the machine code there, and executes it. This is how the OS s start up.

Getting "hello world" to run in assembly will be a bit involved, frankly, as you won t have anything but the BIOS, since you won t have an OS to run on top of.

So, if you want to pursue this you ll want to hunt down the books and sites on hobby operating systems and learn how the bootstrap process works, etc. Otherwise, work with something like a DOS system, and create COM files and go from there.