An 8 year old, using the ring bound manual that came with their computer, can figure out the basics - enough to write a program like this, and examine it. I’m not being dismissive here, but speaking literally from experience. Personally, it’s my opinion that computers were a lot simpler back then.
Nowadays we’re very, very far from the hardware - hardware that has grown very complicated in comparison.
The debugger and the 8086 instruction set is well documented, much better than the "modern" software that i have to work with at dayjob. Its not magic.
It's not the assembly language that I feel is like dark magic, but rather having a prompt where you essentially have almost unfettered access to the system, and have basically kernel privileges as long as you understand the hardware well enough (because MS-DOS memory protection is a bit lol).
What I'd really like to see is a way to boot FreeDOS on UEFI. Of course this would require a BIOS emulator somewhere, either inside a native UEFI version of FreeDOS (not very probable to happen, I think), or as an external UEFI executable that can then boot a BIOS system (parts of this do exist, I think).
Developing for "legacy" BIOS is easier at this point because there is less legacy to implement (Windows binaries, Win64 ABI, FAT file system). EFI is a huge pain osdev-wise and thats why nobody wants to do it.
It's interesting how ASM nowadays appears as a dark magic, since only a small fraction of the programmers are (rightfully) very far from that level.
Curiously, I found learning Rust way more challenging than learning 16-bit assembly (it was way simpler back then; no complex instructions, less baggage, simpler processors... and less expectations :)).
I've learned x86 16-bit assembly originally, and I find that most of that knowledge is still applicable when looking at assembly listings while debugging C/C++ today (which is the most likely area where one might have to deal with it in production these days; few people get to write asm from scratch).
For x86, at least, I wouldn't even say that it was less complex. Segmented memory alone is a huge complication, and then on top of that there was all the legacy CISC stuff like the BCD helpers or ENTER/LEAVE; x64 is comparatively streamlined.
Yeah, segmented memory was such a headache. The large memory model that used "far" pointers broke some things that were taken for granted in C. Comparing pointers especially was an easy place to introduce difficult to find bugs. A given memory location could have multiple valid pointers, so you couldn't do an int compare. The 32-bit int 0x00000011 is smaller than 0x00010000 but 0000:0011 pointed to the byte after 0001:0000.
I painstakingly entered so many bytes into DEBUG from the back pages of PC Magazine. It was an amazing experience when they added the ability to pay $4.95 or something cheap (for the time) to access "ZiffNet" as a walled-off section of CompuServe and download the utilities from there.
On other hand I would argue that something like javascript in modern browser is much more arcane and probably opaque.
At least with DEBUG and assembler I could reasonably reason and do things by hand. With many modern languages I have no idea where to even start checking what they do and how.
