Author
|
Topic: Where do I start?..... (Read 2 times)
|
valitoria
Guest
|
|
« on: February 06, 2009, 07:09:40 am » |
|
After thinking about it about for MONTHS I actually want to get started hacking but another idea changed my mind, NESDev, so where do I start? Learn ASM (I found a document, but it said I really SHOULD LEARN another Assembly Language to understand NES Dev, This confused me, really where do I really start learning ASM?) IDE, Compilers etc. (Found mine Here) Some info down @ NESdevWhere do I really start? Help....
|
|
|
|
tummai
Guest
|
|
« Reply #1 on: February 06, 2009, 10:08:19 am » |
|
I started with bunnyboy's tutorials. They will give you a good ground in the very basics of programming the NES (minus audio and mappers). I especially like his description of attribute tables, which was something I couldn't get my head around until I saw his pictures. Along the way, you should grab some of your favorite ROMs and try to find the stuff you are learning in the tutorials. Use an emulator like FCEUXD and use the debugger to setup breakpoints and watch how commercial games do the basic things like clear memory, set palettes, read the joypads, etc. Also, become a regular reader of the NESdev forums and post questions you have in the Newbie forum. Bunnyboy's tutorials are here: http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=7155If for some reason that link doesn't work, go here: http://nintendoage.com/forum/ then click on "The Brewery" and then the first stickied thread "NES Programming".
|
|
|
|
Jigglysaint
Guest
|
|
« Reply #2 on: February 06, 2009, 09:45:07 pm » |
|
I say screw the compiler and grab a list of opcodes and memorize as many as you can, their functions, and how to interact with the ram. Also, pick a game you like, get aquainted with all the ram offsets, then do searches in the rom for all sorts of addresses. I will say that ASM was like a closed book untill I learned about how ram worked. Now I've even expanded into SNES, Gameboy, and I even tried a little Sega Genesis hacking.
|
|
|
|
tomaitheous
Guest
|
|
« Reply #3 on: February 06, 2009, 11:32:26 pm » |
|
Trying to learn assembly/cpu fundamentals and hardware at the same time can be over whelming for some. Check out 6502.org forum for some assembly help. You need to learn a little bit of 6502 assembly and cpu before you take on the hardware of the system/NES. There are 6502 simulators that allow you to step through your code and see what the cpu is doing one instruction at a time. Also get a firm understanding of Binary and Hexadecimal. The key to learning it is persistence. The time it takes for it to click is not as important as the clicking part itself
|
|
|
|
valitoria
Guest
|
|
« Reply #4 on: February 09, 2009, 06:05:21 am » |
|
Thanks for the tips, I found learning 6502 enjoying, seeing those little pixels on the screen, but what does it have to do on an NES game? Is it for special effects like the "The End" screen on the NES Final Fantasy game? or is because you can see registers of it on a debugger? EDIT: My Code I done for myself, well basically I'm toying with 6502asm.com 's ASM Assembler and Emulator LDA #1 LDX #2 INX JSR stupiddot RTS
stupiddot: STA $200 STX $21F RTS
|
|
« Last Edit: February 09, 2009, 06:15:12 am by valitoria »
|
|
|
|
tummai
Guest
|
|
« Reply #5 on: February 09, 2009, 04:56:39 pm » |
|
Thanks for the tips, I found learning 6502 enjoying, seeing those little pixels on the screen, but what does it have to do on an NES game? Is it for special effects like the "The End" screen on the NES Final Fantasy game? or is because you can see registers of it on a debugger? I think the idea is to familiarize yourself with 6502 Assembly basics before jumping into NES-specific stuff to avoid confusion. It might be useful to know how to add or subtract numbers and make if/then loops before tackling something like scrolling the background on the NES. BTW, the NES has its own PPU (Picture Processing Unit) separate from the CPU that draws to the screen. It is accessed indirectly by writing to certain CPU addresses (starting at $2000).
|
|
|
|
Bond697
Guest
|
|
« Reply #6 on: February 09, 2009, 09:14:19 pm » |
|
are there more bunnyboy tutorials than just those 7?
|
|
|
|
valitoria
Guest
|
|
« Reply #7 on: February 10, 2009, 07:11:43 am » |
|
Only the basics?
Does it mean I have to memorize all those opcodes, registers etc. on 6502? But I heard some other 6502 stuff is rarely or never used in Development or Hacking NES games.
|
|
|
|
KaioShin
Guest
|
|
« Reply #8 on: February 10, 2009, 07:22:00 am » |
|
Does it mean I have to memorize all those opcodes, registers etc. on 6502? But I heard some other 6502 stuff is rarely or never used in Development or Hacking NES games.
You just need to be able to understand the basics behind the opcodes and the registers, then all you need is an opcode-and register-reference to fill in the blanks on demand. The stuff you'll be using all the time will start to stick on it's own then, the rare shit is just one glance to the doc away.
|
|
|
|
Tauwasser
Guest
|
|
« Reply #9 on: February 10, 2009, 07:23:40 am » |
|
You don't have to memorize. Usually, you should get the basics and then get an opcode overview (which exists for every CPU out there and can usually be found!) and familiarize yourself with that special cpu somewhat. The usual things are mostly just named differently. In z80 (gameboy) it's cp a, $03, in 65c816 (SNES) it's cmp $03, etc. Really the only thing you have to know somewhat are the special registers that enamble the whole interaction with the hardware. If you don't intend to mess with that, you can probably always use standard calls that fit your purpose (you have to know their addresses though... time for some debugging). So it's as Jiggly said. I say screw the compiler and grab a list of opcodes and memorize as many as you can, their functions, and how to interact with the ram. Also, pick a game you like, get aquainted with all the ram offsets, then do searches in the rom for all sorts of addresses. I will say that ASM was like a closed book untill I learned about how ram worked. Now I've even expanded into SNES, Gameboy, and I even tried a little Sega Genesis hacking.
You don't really have to get into the whole compiling thing just because you wan't to change something. For big and bothersome code, it's always and option. Generally you need both when you try to reverse engineer/reprogram something, because you have to have a fairly good grip of the opcodes to decipher what a routine actually does. cYa, Tauwasser
|
|
|
|
|