Take note of the "Optimization" section. The C you have to write for cc65 to generate a somewhat acceptable program is very... unidiomatic. C's machine model does not map well to 8-bit micros at all.
You can't write a game for the NES or any of these old consoles entirely in C, some parts simply will not be fast enough to fit into tiny timing windows. At the very least, your interrupt routines (updating sound, graphics, and possibly scanline "raster effects") will have to be written in assembly. Game logic has a bit more leeway, but you'd still run the risk of taking too long and losing frames with an unoptimized program. Given that, it may still be a productivity win to use C to "script" some optimized assembly language to make a simple game (kinda like how modern game engines use languages like Lua to script optimized C++), but I don't think you can get very far if you're just using C as a crutch to avoid understanding the 6502.
I think 6502 assembly isn't as hard as it sounds (it's fun!), but if that thought really turns you off, others have been much more successful with the C + optimized assembly libraries approach in the Sega Genesis/Mega Drive scene, where the standard dev tools are an older version of the GNU binutils + gcc for C projects. The 68000 is much more amenable to being targeted by a C compiler than a 6502 is.
EDIT: Also, from experience writing some simple demo programs for the NES, I think understanding the PPU and writing a program that can be bank-switched effectively dwarfs the challenge of learning to program in assembly language.
I suppose it depends on the CPU. GCC can generate high quality, compact code for the 8-bit AVR. Of course, AVR was designed for C, it has 32 registers and good indexing modes.
Someone made a project called nbasic, but I would say it was closer to some macros around assembler (and allowed inline assembly!) more than any basic dialect I imagine many of us are familiar with.
http://bobrost.com/nes/files/nbasic_manual.html
I've wanted to try writing for NES. Learning 6502 seems like a fun intellectual exercise - certainly the most fun way to learn assembly.
Even if I could write NES code, I probably can't find working NES hardware to test it on. There are emulators, at which point I may as well write in another language.
Why do people have Renaissance fairs, use film cameras, paint instead of using Photoshop, etc? Why do anything? It's fine if it doesn't interest you, but it's not like you need a practical reason to have fun making something.
>Even if I could write NES code, I probably can't find working NES hardware to test it on.
NESes themselves are readily available. Flashcarts like the PowerPak and the Everdrive-N8 are somewhat expensive, but not outrageously so. Some people also gut old games or buy repro PCBs to create test cartridges with somewhat easily-rewritable EEPROMs.
>There are emulators, at which point I may as well write in another language.
As long as you periodically test on the real deal, I fail to see how this would be a problem. It's certainly faster to load a ROM in an emulator than it is to copy it to an SD card or rewrite an EEPROM. Not to mention, there are obvious advantages to having access to a software debugger.
One of the nice benefits of writing for an old console like the NES is that emulators are often the first things ported to new platforms - you effectively get all the portability of writing for a virtual machine, along with the ease of running on only one type of hardware. Most of the hardware/compatibility concerns (Can I maintain a proper framerate on this hardware? Is the screen large enough? What kind of controller does the user have?) are on the person porting the emulator, not the developer. Also, for the user, this means any configuration only needs to be done once for all of the games on that platform.
As for hardware, if you can't find an NES, you can always use a third-party retro console, like the Retron 3.[1]
Also, if you're worried about compatibility, Byuu's cycle-accurate SNES emulator[2] has been expanded to run NES, Gameboy, and Gameboy Advance games, so testing on actual hardware is a lot less necessary than it used to be.
I have a little NES programming experience. The 6502 assembler I use is NESASM, which is also the one those tutorials recommend. There are others called Asm6 and CA65 that I haven't tried.
The syntax that each assembler recognizes is slightly different so source code that assembles properly in one assembler may not assemble properly in another. This is something to watch out for when looking at code examples on the nesdev.com forums.
HAVE FUN with NES programming! :) I've only ever made simple programs. However, the only limits are your imagination. The homebrew game "Battle Kid: Fortress of Peril" was created recently, which is one of the best NES games in my opinion.
This is interesting, as I was recently asked to teach 6502 programming for the purpose of programming the NES (I never have programmed an NES, my (limited) background in assembly language was for the Apple II).
After much searching, it seems a lot of the materials are poorly organized despite the wikis and such out there. This set of tutorials by far the most approachable and understandable material to go from not knowing much about the NES to being able to get Mario to move around.
I think he means the deeper in the comments you go, the closer it becomes an 'e-peen' measuring contest. But the first post is the only thing you should dive into.
