The thread I linked -- specifically the image John Linnemann included -- shows how we have entire generations of people who do not understand how the system and PPU actually behave, or what their direct relationship is to one another; I'm not talking about John, I'm talking about the person in the image. People don't understand what a "frame" really represents, or what's going on at the hardware level (you DO NOT need to get into extensive hardware details to understand or explain it! Really! I'm not a hardware guy myself yet I understand this stuff).
If your teaching materials consist of you saying "VBlank is approximately 1/60th of a second, thus 60fps", then you're doing the students a disservice, IMO. But you are limited on time, so maybe it's something you can't cover. My advice is with regards to your first two numbered items (which you called #1 and... #1 ;-) ). Random brain dump:
Students need to understand how the display ends up rendering the results they stick into PPU RAM. To understand that, they need to understand how the PPU and CRT (or LCD; effectively the same thing) "draws" (reads) data. They need to be taught what an
actual frame is, and how that relates to frames-per-second (the hardware will always be drawing at a specified rate, but what you choose to do update in PPU RAM, and how often, is up to the programmer -- so while the screen is effectively drawn at, say, 60Hz, *visually* things might be updating at half that). You might also want to cover that the NES is effectively 240p (this is not a NES-specific thing, BTW; most systems from that era are like this). They should be taught what VBlank and HBlank are. They should be taught of 50Hz vs. 60Hz variances (PAL vs. NTSC). Once all that's established, they should be taught about NMI and how to tie NMI to VBlank (which should in turn act as a "connect the dots" moment).
This will probably also help. I also
strongly suggest telling people how many CPU cycles there are in VBlank (for PAL and NTSC), not just "frequencies" or clocks, so that the students know how much actual time code-wise they have to do something. You might also explain that determining how much time you "have left" in VBlank is difficult to do aside from literally counting cycles (emulators can sometimes make it easier). Also explain that if you exceed how much time is in VBlank (i.e. your NMI routine takes too long), what the effects of that will be (more on that in a moment).
Once you get that out of the way, they should be taught about
the horrible intricacies and complexities of $2000 / $2002 / $2005 / $2006, including why the order in which you write to those MMIO registers matters. This is still the #1 problem for developers (and emulator authors) to date -- it's hard to understand, but it matters immensely. If someone had taught me all of this back when I started, I wouldn't have made the mistakes I did. But of course, this information wasn't discovered/available at that time. Also, for the record, nobody has been able to teach this nuance effectively. I've seen so many write-ups on it and none of them make it easy for someone to understand, hence why it's still a problem.
I would also suggest demonstrating what happens if you get the above wrong -- it can manifest in several different ways, but there's usually a particular pattern to it (corrupted graphics that have a particular style/layout to them). The bug/quirk during fade in/fade out in my old FF2e intro for Neo Demiforce is a good example of why writes to $2000/2005/2006 and a $2002 read, and their order, matter:
Attachment:
ff2e_intro_bug.png [ 1.4 KiB | Viewed 2202 times ]
Showing people what mistakes look like can help speed up the process. Showing what happens visually on screen if an NMI routine takes too long (i.e. CRT/PPU begins to draw despite CPU still doing stuff in NMI) is equally useful.
I cannot stress how these are recurring stumbling blocks / problem points that show up in the wild *constantly*. These are people who have no familiarity with the system, want to learn it, start coding + trying to get something working, then "sort of" get it working but don't understand why visually everything looks botched. They come to the nesdev forum all the time asking for help. There is no "printf debugging" methodology on the NES, which makes debugging painful for people who might have exposure to, say, present-day computer programming. So maybe a small bit on how to use the FCEUX debugger (and/or Mesen's debugger) would be helpful as well.