DementedPurple wrote:
How would I know what memory addresses to use for variables?
You would reserve space for them in your data section and then access them by label. The label is replaced with the exact address either when you link your executable file (in most cases), or when the executable file is loaded by Windows (for position-independent code). If you
really wanted to, you could tell the linker to put your data at a specific address, but the defaults are good enough most of the time.
DementedPurple wrote:
I'll have to keep in mind that I'll have to have RAM to store the code, and that Windows will be running in the background as well as a few other apps. You could say that I've been spoiled by NES programming by having the code stored in a ROM as well as having the entire system dedicated to your program and not having to share system resources.
Well then, I've got good news for you: Windows provides a dedicated virtual computer for your program to run. You don't have to worry about sharing resources at all.
DementedPurple wrote:
I also want to get into programming BIOS' and operating systems, which leads me to even more questions.
BIOS programming depends on a lot of hardware documentation, which isn't always available. By comparison, operating system programming is a lot more reasonable. Most of the information you need for that is freely available (someone else already linked
osdev.org).
DementedPurple wrote:
How do I read and write from a hard disk or CD?
This is not something I could explain in a single post!
DementedPurple wrote:
And how do I know what memory addresses to use for code and variables?
If you're developing a BIOS, you would know what memory is available because you've configured the hardware and determined how much memory is available and where it's mapped. If you're developing an operating system, you would know because the BIOS will tell you (but you might need to ask it in a specific way).
DementedPurple wrote:
How would I run C code?
Load the code to its expected memory address (applying relocations if necessary), set up any other initial things it expects (e.g. a stack), and call its entry point.
DementedPurple wrote:
I'm kind of a noob.
We all start somewhere.