First of all, forgive me for sounding harsh.
You are 1) asking the wrong questions and 2) asking them in the wrong place. None of your questions are NASM specific. x86 Operating system programming and x86 embedded programming can be done in multiple languages/syntax's.
The first steps you must take is to learn about the BIOS, and how to execute a real mode bootloader. From here it gets much more complex if you want a true 32-bit protected mode operation system. And the complexity increases if you want make a 64-bit long mode operating system.
Making a real mode bootloader is fairly easy (compared to what you face next), if you've got the "know how". I'll help you by pointing you the this tutorial
http://mikeos.sourceforge.net/write-your-own-os.html It demonstrates how to create a simple "hello world" real mode bootloader with NASM under Linux. From here you might want to access a file system, but I warn you, nothing about this is easy! Your next steps should focus on going from real mode to protected mode. Protected mode is MUCH more complex in the way memory is handled. Next step would probably be to understand the framebuffer and how to manipulate it in the lowest bit mode (console mode), and from here how to switch VGA modes. For all of this you will probably want to visit
http://wiki.osdev.org/Main_Page They have some good tutorials and resources to learn most of the above. Once you have mastered all of this (probably years and years from now), you can begin to ask questions like; how do I interface with my audio card, network adapter, graphics card etc.?
There are so many things to learn here, and I've probably forgotten to mention a lot of important stuff. It has been a while since I've dabbled in OS programming. But take it from someone who used a couple of years learning about this stuff; only the most hardcore "hobbyists" will ever get a remotely functional operating system up and running, and even fewer will get to a stage, where their OS can interface with complex hardware, such as the graphics card. If you just want to play around with hardware, getting into driver programming is probably a better bet, but still much more complex then your typical user mode programming.
Hope this helps a bit.