In the past there was no python, no game-framework, nothing of that. But people were able to learn it anyways. These frameworks are good - to abstract away the complexity of modern machines. But for ancient machines the assembly is not that hard.

If you already have experience with Arduino, that might be a good entry-point. I don't like the hardware-part very much, so I don't know exactly what is possible with Arduino. But it seems to be a very open platform, that can be extended. So try to add some form of output - say a grid of LEDs and put images on that. If that works, try to add some form of input. If both works, you can add more sophisticated in- and output. Maybe you can even add some graphics-chip to arduino, so that you can output on monitors.

twesterm said: In assembly, nothing is simple.

I learned assembly with 12/13 after learning programming in Basic. That was in east germany. Shortly after that was the fall of the wall, and I had my first PC. Learned Turbo Pascal and used my knowledge of Assembly to use the inline assembly. I was a child doing all this, and you say that's complicated? No, the point is, assembly on modern computers is complicated, because modern machines are much more complicated than the ones in the late 80s and early 90s. But even today exists projects with simple hardware to learn: Arduino, Raspberry Pi. If you at these machines, learning assembly should be much easier.

Would you tell someone who has yet to doodle to paint like Michelangelo? I'm impressed that were able to learn assembly at a young age, but you may have a natural talent for mathematics like Michelangelo had for art. Even if it didn't come easy to you having a natural talent makes learning a skill faster. Some people learn to read at 3 others struggle to read at 13. You are saying starting with assembly will work, but building a foundation to develop skills and knowledge is how most people learn. Not everybody can jump in the deep end and start swimming. Some people sink.

It's not that assembly is hard, it's that you will get frustrated at how long it takes to program the simplest thing or produce anything resembling a game.

For example, you want a character to walk left and right on a flat surface. Well, you need to define character and ground block objects to have variables, input handling, sprite drawing (loading image data and drawing pixels), collision code between the character and ground, and all throughout micromanaging every byte of memory. The code will have no concept of "character", "ground", "position", "collision", "sprite", "screen" and so on in itself, it just deals with memory registers.

Thanks for the confidence booster  Mnementh.  

Assembly programming is not necessarily that difficult, but you really shouldn't take on a large project while learning assembly ...

There are (essentially) two challenges with assembly, you program everything which means you have to be very comfortable with reading documentation on hardware interfaces and binary file formats, and there are a lot of habits that need to be developed to limit the introduction of difficult to debug bugs.

Beyond that, for most of what people would want a Raspberry Pi to do there is really no need to program in assembly. It is actually a fairly powerful little computer and you should see adequate performance regardless of the language you choose (within reason).

You need to be really in-depth if you're planning to program NES games. Besides knowing assembly or 6502 opcodes, you also need to have an in depth knowledge of the hardware registers as well as limitations (eg. The NES only allows a certain number of sprites on the same scanline row on the TV before it starts to blink madly. There is also a rule to the 6502 CPU where you should not execute a Jump or Call at any address ending in hex code FF).  You need to study in depth to know the reasons why limitations like this exist on the hardware, as well as how to overcome them.

You'll need to use memory mappers if you plan to make a game over 32KB. That brings a whole new dimension of code organisation into things, as parts of the ROM cannot just be accessed at any time (you get paging miss penalties if the design requires swapping mapping pages over a lot).

My suggestion? Take a look at how the .NES ROM file is structured, and make a game playable on emulators before you even consider hardware. Once you get that out of the way:

http://www.retrousb.com/index.php?cPath=24

This site provides cases, PCBs and reverse-engineered lockout chips to solder together. Just add an EEPROM for the CHR ROM and one for the PRG ROM (use an EEPROM programmer to put the assembled binary onto the chip), and maybe a memory mapping chip. Solder them onto the board and you should be right to go!

I once had a schematic for a NES. It was dozens of pages long.

If you're really interested in how console hardware works (I'm a bit in that area myself), then I highly recommend this book:

http://books.google.com.au/books/about/The_Black_Art_of_Video_Game_Console_Desi.html?id=4VFyAAAACAAJ&redir_esc=y

It seems to cover the basics of console systems in detail from both a software and an electronics point of view. 

Step 1. Obtain empty NES cartridge.
Step 2. Acquire programmed game
Step 3. Summon Twilight Sparkle
Step 4. Request magical assistance
Step 5. Success
Step 6. "Thanks mysticwolf"