How does assembly relate to machine/binary code.
For example here is how to print to the screen in mikeOS(a small pure assembly OS), mikeOS it uses NASM to assemble.
BITS 16 ORG 32768 %INCLUDE 'mikedev.inc' start: mov si, mystring call os_print_string call os_wait_for_key ret mystring db 'My first MikeOS program!', 0
Where os_print_string and os_wait_for_key are defined as
os_print_string equ 0003h ; SI = zero-terminated string
os_wait_for_key equ 0012h ; Returns AL = key pressed
in mikedev.inc respectively and defined as
os_call_vectors: jmp os_print_string ; 0003h
Now nasm must do a lot more work under the scene when assembling, I have no idea what.
In other words assembly language is a wrapper to some degree to machine code just as say C is a wrapper to assembly. If I said cout >> "Hello World" for example in C++, this is then compiled into it's assembly equivalent and them assembled into machine code.
So I am trying to understand out how 0003h and 0012h seem to dictate everything that is going on when printing to the screen. How do these two values,
a) Tell the CPU/PC system which bus to send the corresponding bytes that represent the required string to the monitor bus and not say to the sound card.
b) In this case the string is sent to the monitor, obviously, now my understanding is that you have a frame buffer that can store a maximum number of bytes. So say the resolution of your screen is set at 1024 x 768 which is 786432 pixels and a refresh rate of 60hz on the screen, therefore the FB will contain this number of byte values and hence will be sending this many bytes to the monitor every 1/60 sec. The first byte in the FB corresponding to the first pixel on the screen and the last to the last on the screen etc.
So how does the CPU/GPU know which byte to put in which position in the FB. It's like saying to the GPU 'ok I need this pixel at coord (245,232) green so I will leave it to you to put this pixels value in the correct position in the FB' etc.
How does this work.