Should I learn computer architecture (i.e. CPU, hardware, memory, etc.) first before I dive into low-level software (i.e. kernels, drivers, init systems, etc.), viceversa, only low-level software, or learn both concurrently? Why? Is there a better alternative?
@avalos Low level software has to be written to target the specifics of the hardware you're using. So you kinda have to learn both together as you go. Every time I write bare metal code, I have documentation on the hardware in hand while I do it. So really it works best to co-learn it.
@avalos Incidentally, if you're looking for a great way to get your feet wet in bare metal coding, have you considered writing your own Nintendo game from scratch? It's a great way to learn about hardware and about writing assembly language.
@roadriverrail I have a spare Nintendo DS Lite lying around. Sounds like a great idea to experiment with it! Is there anything special about Nintendo hardware that will help me get started more easily?
Also, I had a class at school past semester where we learned 8086/8088 assembly, and I also learned some basic ARMv7 assembly quickly; but none of that was on bare metal. I wrote 8086 on top of the DOS API, and ARMv7 on top of Linux and C libraries.
Here's the ARMv7 code I wrote: https://fossil.avalos.me/rggpolis
@avalos I'm sure the DS hacking community can help, but I know little of it. The original NES on an emulator is a great target though because the hardware is well known and quite well documented. I even have a set of instructional labs available to help people learn the platform. And the 6502 is an easy but iconic processor used in multiple 80s PCs and still sees use today.
