Teaching a Course in NES Programming

Are you new to 6502, NES, or even programming in general? Post any of your questions here. Remember - the only dumb question is the question that remains unasked.

Moderator: Moderators

User avatar
Lucradan
Posts: 101
Joined: Wed Sep 21, 2016 12:08 pm

Teaching a Course in NES Programming

Post by Lucradan »

In about 2 weeks, I'm teaching a short course on programming the NES. It's only 50 min so I am only going to be able to touch the surface; the tools, some videos, this community, headaches, pitfalls, etc. But, I would like to add a personal touch and discuss a bit of the lessons learned throughout the process. If you have any words of encouragement to share, stories, frustrations, or sucesses, please reply.

1. Do you have any advice to share to new people interested in this community?
1. If you were back at the very beginning of your NES programming days, what do you feel would have helped you the most to get started?
2. What have you felt the most frustrated with during your development process?
3. Do you have any good or bad stories to share?
User avatar
dougeff
Posts: 3079
Joined: Fri May 08, 2015 7:17 pm

Re: Teaching a Course in NES Programming

Post by dougeff »

Who's the audience? Programming students? University level?
nesdoug.com -- blog/tutorial on programming for the NES
User avatar
Lucradan
Posts: 101
Joined: Wed Sep 21, 2016 12:08 pm

Re: Teaching a Course in NES Programming

Post by Lucradan »

dougeff wrote:Who's the audience? Programming students? University level?
It's a convention hosted by the local community college. I'm going to get a variety of skill sets so I need to keep it at a basic level. I'll have a handout with a glossary of terms to help.
User avatar
dougeff
Posts: 3079
Joined: Fri May 08, 2015 7:17 pm

Re: Teaching a Course in NES Programming

Post by dougeff »

Talking about hardware registers for 50 minutes would be boring.

Show a bunch of clips of real games, then talk about the basic limitations of the system.

Here's Mario. Mario is made up of 4-8 sprites. The system can handle 64 sprites at once.

Here's Megaman. There is a 3-4 color limit per palette. BG vs Sprite palettes.

Here's Zelda. The system had a limit of 32k ROM. Mappers are used to have more.

Etc, etc.
nesdoug.com -- blog/tutorial on programming for the NES
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: Teaching a Course in NES Programming

Post by FrankenGraphics »

1. Do you have any advice to share to new people interested in this community?
a) Don't overthink. Just do. I'm at the stage where i finally feel like i might be able to pull off a small game of questionable quality all on my own, even if my schedule for this year is pretty much booked up by collaborations that will result in something better. That point, however, could've happened a year earlier if i hadn't been worrying over good design, if i'm doing things the "right way", etc. Better make something that risks being bad or seriously buggy and learn from it than stalling over every decision along the way.

b) Dare to collaborate. It might not be what everybody wants, but two personalities, two thinking heads and and two skillsets may balance and complete each other.

c)Because the NES is riddled with the intricacies of hardware-accelerated features, especially thinking about the APU and PPU, there's less of a distinction between art, music production, design and programming than on modern platforms. Whichever end you start in, and whether you're alone or working in a team, be prepared for to learn to tackle a bit of the others too.
1. If you were back at the very beginning of your NES programming days, what do you feel would have helped you the most to get started?
see (a).
2. What have you felt the most frustrated with during your development process?
In no particular order:
d) figuring out how combinations of instructions form the building blocks of a more human-friendly interface (like BASIC), all while not coming from a computer science walk of life. For example how to check if something is equal or greater than isn't self-explanatory from face value.

e)most of my beginners' errors have been about memory management. reading the wrong range or setting up padding wrong or misunderstanding banks.
3. Do you have any good or bad stories to share?
f)i happened to have nesdev related code in an editor up on my laptop when i was to show a GUI wireframe for a potential client. I think they thought it was the code for the wireframe and seemed impressed. I let them.
User avatar
gauauu
Posts: 779
Joined: Sat Jan 09, 2016 9:21 pm
Location: Central Illinois, USA
Contact:

Re: Teaching a Course in NES Programming

Post by gauauu »

FrankenGraphics wrote:
1. Do you have any advice to share to new people interested in this community?
a) Don't overthink. Just do. I'm at the stage where i finally feel like i might be able to pull off a small game of questionable quality all on my own, even if my schedule for this year is pretty much booked up by collaborations that will result in something better. That point, however, could've happened a year earlier if i hadn't been worrying over good design, if i'm doing things the "right way", etc. Better make something that risks being bad or seriously buggy and learn from it than stalling over every decision along the way.
I agree 100% with this. You learn by doing. There's always someone that will tell you that you're doing it wrong, but don't get frustrated. Just keep making things and gradually improve.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Teaching a Course in NES Programming

Post by tokumaru »

Try to break down one or more scenes from iconic games into name tables, attribute tables, pattern tables, palettes, OAM, etc. to help people understand how the PPU forms images. Showing how things change over time using footage from debugging tools (NT viewer, PT viewer, OAM viewer, palette viewer) might be interesting to show the incremental changes a game has to make in order to animate everything.
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: Teaching a Course in NES Programming

Post by koitsu »

I also strongly suggest explaining to people the "interaction" (per se) between the display/CRT and the PPU. It's critical that people understand how this works. There are idiots out there who still don't get it simply because they were never taught.
User avatar
Lucradan
Posts: 101
Joined: Wed Sep 21, 2016 12:08 pm

Re: Teaching a Course in NES Programming

Post by Lucradan »

koitsu wrote:I also strongly suggest explaining to people the "interaction" (per se) between the display/CRT and the PPU. It's critical that people understand how this works. There are idiots out there who still don't get it simply because they were never taught.
Am I missing something? VBlank to VBlank is approximately 1/60th of a second, or 60FPS, yes?
User avatar
dougeff
Posts: 3079
Joined: Fri May 08, 2015 7:17 pm

Re: Teaching a Course in NES Programming

Post by dougeff »

Yeah, I don't get that either. That Twitter discussion seems to be about SNES frame rate, which could have some basis in truth...some games did have a frame rate less than 60 hz. Star Fox, for example.
nesdoug.com -- blog/tutorial on programming for the NES
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Teaching a Course in NES Programming

Post by tokumaru »

There's of course the hardware frame rate and the software frame rate, a lot of people don't get that. There's a lot of misconception about the processing power of classic consoles in general... A lot of people say that NES (or even SNES!) games can't be as fast as Sonic on Genesis, as if fast scrolling was something super hard and time-consuming to do. It's true that the physics might be a limiting factor in this case and bring the software frame rate down, but it's definitely possible to keep the speedy gameplay with some trade-offs (physics accuracy, object count, etc.), if necessary.
User avatar
Lucradan
Posts: 101
Joined: Wed Sep 21, 2016 12:08 pm

Re: Teaching a Course in NES Programming

Post by Lucradan »

Agreed, there is a hard limit to how many bytes of data can change between frames. But what I find fascinating is all that this community has been able to do in those few small bytes. I was thinking today about the perceived "Full Motion Video" limit and how you could use midframe and vblank bankswithing to pull it off. You couldn't maintain it for an long time, but it's do able.
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: Teaching a Course in NES Programming

Post by koitsu »

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:
ff2e_intro_bug.png
ff2e_intro_bug.png (1.4 KiB) Viewed 3886 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.
User avatar
Lucradan
Posts: 101
Joined: Wed Sep 21, 2016 12:08 pm

Re: Teaching a Course in NES Programming

Post by Lucradan »

Good brain dump. Many thanks. I'd planned on a similar outline but got to work on my anologies and storytelling to smooth it out some.

For example, the 60fps is true but since there is not a standard definition of a "frame" it's better to think about it in terms of bandwidth and windows of opportunity (Hblank/Vblank). I probably won't get into the technical intricacies of the $2000/2005/2006 headaches in details. Probably just a heads up when discussing the registers.
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: Teaching a Course in NES Programming

Post by koitsu »

Re: $2000/2002/2005/2006: I'd suggest at least mentioning a "general default behaviour" (i.e. "do this every time, and in this exact order: -- yes there is a reason, it's an advanced topic we don't have time to go in this session") of the following:

1. Do your PPU RAM updates (writing twice to $2006 to select a PPU address, followed by writes to $2007 to do PPU RAM updates)
2. Write to $2000 (to select which nametable (bits 1-0))
3. Write to $2005 twice (to select X offset, then Y offset of background -- or more precisely, "how far/how much" into the nametable area to start drawing at)

The two (very short) items here also cover common pitfalls: https://wiki.nesdev.com/w/index.php/PPU ... t_pitfalls
Post Reply