How do we go from assembly to machine code(code generation)

I find this definition pretty clear:

The Instruction Set Architecture (ISA) is the part of the processor that is visible to the programmer or compiler writer. The ISA serves as the boundary between software and hardware.

The ISA provides an abstraction of the actual microarchitecture, which is the implementation of the instruction set by the processor.

So when your compiler is said to produce machine code, it produces instructions for the configured instruction set, not the actual processor, so any processor implementing that instruction set can run that machine code.

A virtual machine such as the JVM or CLR runs code that has been compiled to bytecode specific to that virtual machine's architecture, Java bytecode and CIL in this case.

The runtime of such a virtual machine, which in turn is built for and runs on a specific processor architecture and OS, translates the bytecode to the machine code and API calls for the platform it runs on, and usually does so just-in-time.

Assembly language translates almost directly to machine code. mov becomes a mov instruction. call becomes a call instruction. The arguments on the same line become the argument fields for those instructions. There's a bit of assistance in computing addresses, but not a lot beyond that.

The operating system can be treated much like a subroutine library. The "magic numbers" you're asking about are operating system entry points; the call instruction, like a function call in higher level languages, invokes them; they run until they return, at which point your program picks up where it left off. Your OS's user manual will tell you which entry point to invoke to do what, how to set up any arguments required (such as putting the address of the string to be printed in the si register before calling os_print_string, though some may involve pushing values onto the stack rather than putting them in registers), and how to read their returned results if any (again, which registers will have the result or what to pop off the stack).

As far as question (b) goes -- That's all stuff the OS and its device drivers, or a function library linked with your assembly code, will normally handle for you. If you really need to know it (eg because you're writing an OS or device drivers), you'll need to study the documentation for your specific hardware to understand how to communicate with it... but what you'll wind up doing is writing a library of functions which do the necessary work, and packaging it so main programs just invoke those functions. In other words, for most programs I/O is much like working in a higher-level language; the runtime library does all the work and all you need to know is how to use it. (Sane assembler code is critically dependent upon writing good functions so you don't spend time endlessly reinventing wheels!)