If your intention is to avoid scaring newbies off, I'm not sure if 16bit real mode, PC boot process, BIOS services and all that arcana that follows is the best place to begin.
I agree with you to an extent: The IBM PC was not a very elegant design, and other computers certainly had less complexity to them. But there is a point I want to make which defends this choice somewhat:
Newbies like me are more frustrated by thinking there's no path from introductory material to something useful or realistic. Something that's more immediately friendly would be a simplified virtual machine with no or trivial peripheral hardware, like Redcode in Core War:
The death of education is "So What?": "OK, I've learned to play Core War and I know enough to write a warrior that can occasionally beat other warriors written by beginners. So far, so good... so what? I want to program computers in assembly, not play games using assembly programs, so where's the path from where I am now to where I want to be?"
In this case, the pathway from VM opcodes to native opcodes is hardware interface and, while the IBM PC has some funky hardware, it's heartening to know that your code could, in principle and barring emulation errors, run unmodified on real hardware and do something. Not something useful, but you can get to useful. You can ramp up to it, now that you have the pathway in front of you. It might be a long pathway, but it's there.
Well, I had in mind something more useful and realistic, not less; namely teaching assembly in normal Linux environment. Sure, there are all sorts of complexities there too, but in general I feel like they are also more worthwhile.
> Well, I had in mind something more useful and realistic, not less; namely teaching assembly in normal Linux environment.
This might sound odd, but as someone who's done some assembly programming under Linux, it usually isn't different enough from C to be worth the effort. Even if you eschew libc, the kernel APIs are still fairly high-level and, more to the point, there are no new concepts relative to C: You have pointers and pointer arithmetic, you have fixed-size buffers, you have ints and doubles, and the rest is just syntax.
The exception is doing something like a really tight high-performance kernel using SIMD opcodes, which necessarily involves learning a lot about the specific SIMD hardware and data organization to optimize cache use and other details C can't express.
It seems like a better introduction would have the aim of helping the newbie learn assembly that would be useful in debugging or working around bugs in code that you don't have source to.
Why not? If they're determined enough, they'll get it. I learned a lot back in the day by spending many hours with the book PC Intern and some other book on x86 Assembler.
Granted, I had a little experience with assembler on a C=64, but, I learned _that_ in a similar way.
On the other hand, I think it is fair to assume that people who are interested in assembly programming at all bring a certain degree of determination to the table.
I think the determination of newbies is being underestimated. A lot of us "old timers" didn't have the internet. Just a few books and a whole lot of "Imma figure this crap out!".
