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:

@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.

Sign in to participate in the conversation
Mastodon 🐘

A general-purpose Mastodon server with a 1000 character limit.

Support us on Ko-Fi Support us on Patreon Support us via PayPal