I know people going to hate me for not even showing any code, but in theory, how can an assembly program, for example, show a functioning menu and play a song at the same time? or like play a game and have a timer at the same time, how it is possible?
I don't see how this can be done because the processor has only one code segment, maybe I can make 2 assembly files and the processor somehow will work with it?
If I understand your question properly, you want to know how multi-tasking -- the continuous forward progress of unrelated programs -- works. If you have as many cpus as things to do, it is easy -- use a cpu for each. If you don't, you need to share them, by rapidly switching between the programs. This rapid switching works well if either the programs spend a significant time waiting for external I/O to operate, or do not require the entire computational ability of the cpu.
For example, if you wanted to generate a pure sine wave on the speaker, you would need to produce an audio sample every 22 microseconds (usec) which is 1 / 44,000, the standard rate for audio reproduction. If it took 0.5usec to switch between processes; 0.1usec to compute sin(), and 1 usec to toggle the speaker; you would only use (0.5+0.1+1)/22 about 7% of the cpu to do this, leaving 93% of the cpu available for other programs.
There are hidden complexities and simplifications in this example. Something needs to know that your code needs to be run every 22 usec; and that a failure to run your code has dire consequences (if pop and crackle are dire). But once you fill in the details, that is about it.
OK, the actual question:
A single program can also split its attention between multiple activities. The most common method people use for this is threads. Two threads share an address space, but have private register sets, and somewhat private stacks. In a system that supports fully independent threads, one could perform the audio operation outlined above, while another remained in a more typical MVC pattern. A potential problem is that various runtimes might have hidden synchronization, which could cause unexpected latency.
Without threads, it becomes increasingly difficult. The UNIX signal concept permits a relatively asynchronous function call to be scheduled with respect to some event, like a timer going off. So the audio example could be performed by a signal handler. The complexity here can be harrowing, since your library may have to deal (perfectly) with system calls that sporadically fail with EAGAIN; while many system calls are themselves restartible this is not guaranteed. A related problem is that some system calls (or even library functions) may temporarily inhibit signals, which could cause the audio program to miss its deadlines.
Without signals, it is very difficult. You need to analyze your program to find every point where it waits for an event (eg. reading from a keyboard), and change those to asynchronous operations. Then you have to sprinkle code throughout your program to check if it is time to put an audio sample to the speaker. Given the 22usec requirement, that is a lot of sprinkles. Once you are finished, you will probably be unable to convince anybody that it works.