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
http://shiru.untergrund.net/articles/programming_nes_games_i...
http://forums.nesdev.com/viewtopic.php?f=2&t=8493
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.
http://gendev.spritesmind.net/forum/viewtopic.php?t=14
http://gendev.spritesmind.net/forum/viewtopic.php?t=1373
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.