Confidence Building Projects
| BHXSpecter wrote: |
|---|
| Yeah, that is way over my comfort level and knowledge level. |
BHX: It's supposed to be outside your comfort/knowledge levels. That's the point. If you only do things you're comfortable with / already know how to do, you'll never improve.
Though I think you're overestimating how hard it is. A very basic 6502 emulator is pretty easy to write.
Once you have it executing code, you can run some basic test ROMs to make sure it's working (ie: they'll do a bunch of stuff and write 'pass' or 'failure' to memory, and you can examine it to see what's broken and fix it).
Once you have a working CPU, you can start doing the basics of a PPU and get graphics going. And just keep adding functionality from there.
If you take it one bite at a time it's very manageable.
EDIT:
6502 Basics (so you can see what I mean about it not being terribly difficult):
There's 3 general purpose registers: A, X, Y. Each are 8 bits wide, unsigned (ie: hold values between 0-255).
There's also a 16-bit register called the PC (program counter) which keeps track of where the code is executing from.
In addition to those regs (and a few others - but they're all similar), there's a 16-bit "Address space" or "addressable memory". You can think of this as just a big array of bytes:
(technically it's more involved, but again I'm simplifying a bit)
Writing a 6502 emulator basically means doing the following:
1) Read a byte of memory from whatever address the PC is set to. This byte is the "opcode"
2) do whatever instruction that opcode represents
3) increment PC so that it points to the next opcode in memory
4) repeat
The instructions are all incredibly basic and simple. The most complicated one is 'SBC', which subtracts 2 numbers.
So yeah... it's really not that rough.
EDIT:
If a full NES emulator is too much... an alternative is to start with an NSF player (NSF files are music data ripped from NES games.... so instead of emulating the full NES system, you just have to emulate the CPU and APU).
Though I think you're overestimating how hard it is. A very basic 6502 emulator is pretty easy to write.
Once you have it executing code, you can run some basic test ROMs to make sure it's working (ie: they'll do a bunch of stuff and write 'pass' or 'failure' to memory, and you can examine it to see what's broken and fix it).
Once you have a working CPU, you can start doing the basics of a PPU and get graphics going. And just keep adding functionality from there.
If you take it one bite at a time it's very manageable.
EDIT:
6502 Basics (so you can see what I mean about it not being terribly difficult):
There's 3 general purpose registers: A, X, Y. Each are 8 bits wide, unsigned (ie: hold values between 0-255).
There's also a 16-bit register called the PC (program counter) which keeps track of where the code is executing from.
In addition to those regs (and a few others - but they're all similar), there's a 16-bit "Address space" or "addressable memory". You can think of this as just a big array of bytes:
|
|
(technically it's more involved, but again I'm simplifying a bit)
Writing a 6502 emulator basically means doing the following:
1) Read a byte of memory from whatever address the PC is set to. This byte is the "opcode"
2) do whatever instruction that opcode represents
3) increment PC so that it points to the next opcode in memory
4) repeat
The instructions are all incredibly basic and simple. The most complicated one is 'SBC', which subtracts 2 numbers.
So yeah... it's really not that rough.
EDIT:
If a full NES emulator is too much... an alternative is to start with an NSF player (NSF files are music data ripped from NES games.... so instead of emulating the full NES system, you just have to emulate the CPU and APU).
Last edited on
closed account (N36fSL3A)
I think I took on the challenge like 5 times but I kept failing because I don't know Hex. However, it really is simple. And this is coming from a 12 year old :P
If you're going for making NES games, I think it has a C compiler.
If you're going for making NES games, I think it has a C compiler.
Last edited on by Fredbill30
Hex is just a numbering system. It's sequential just like base ten. You don't need to know it inside and out like base 10 to see where each hex number is relative to another.
The only thing that's weird (that I have to sit and think about) is that the 6502 reads little endian data. Which is like reading from right to left to me.
Edit:
You can't think emulating the nes is conceptually siumple yet find hexidecimal numbers the most challenging thing out of it. That makes no sense :P
The only thing that's weird (that I have to sit and think about) is that the 6502 reads little endian data. Which is like reading from right to left to me.
Edit:
You can't think emulating the nes is conceptually siumple yet find hexidecimal numbers the most challenging thing out of it. That makes no sense :P
Last edited on
closed account (N36fSL3A)
I know what hex is, it's just not exactly in my "native language". (I'm not used to it).
I've written a bit of a 6502 emulator before. I had another guy helping me but he stopped emailing me. I stopped working on it shortly thereafter.
@Disch
I'm planning to give it a try but want to finish cleaning up my irc bot a bit before I start working on it.
I'm planning to give it a try but want to finish cleaning up my irc bot a bit before I start working on it.
@chrisname
I love this junk. If you wanted to post your Qs on here rather than through email I'd be happy to answer them (though make sure I see them by putting NES in the title or something).
Or... you could sign up on the nesdev boards and post there, which would probably make more sense. Those guys are question answering machines.
I love this junk. If you wanted to post your Qs on here rather than through email I'd be happy to answer them (though make sure I see them by putting NES in the title or something).
Or... you could sign up on the nesdev boards and post there, which would probably make more sense. Those guys are question answering machines.
@Disch
Been studying NES architecture for the past few days. Waiting for it to all sink in, then the coding begins.
I've got prior experience dealing with low level architectures, so it's clicking faster than I hoped it would. :p
EDIT:
Emulating the 6502 should be simple enough. it's the PPU and APU that I still don't fully have my mind around. But I'll get there.
Been studying NES architecture for the past few days. Waiting for it to all sink in, then the coding begins.
I've got prior experience dealing with low level architectures, so it's clicking faster than I hoped it would. :p
EDIT:
Emulating the 6502 should be simple enough. it's the PPU and APU that I still don't fully have my mind around. But I'll get there.
Last edited on
APU can wait. I wouldn't even start on it until you have at least some games "playable".
Most docs on the PPU get so bogged down on the details that they don't go over the big picture very well.
There's 2 "pattern tables"
and 4 "name tables"
Each name table makes up one "screen" of image data. It is 32x30 tiles in size, each tile is 8x8 pixels.
Each tile is represented by a single byte in the name table. Therefore there are 256 different tiles available for the background
The pattern tables are the 8x8 pixel graphics for each of those tiles. Each 8x8 graphic is stored in 16 bytes (2 bits per pixel in a 'bitplane' format)
squeeeeee so much fun.
Most docs on the PPU get so bogged down on the details that they don't go over the big picture very well.
There's 2 "pattern tables"
and 4 "name tables"
Each name table makes up one "screen" of image data. It is 32x30 tiles in size, each tile is 8x8 pixels.
Each tile is represented by a single byte in the name table. Therefore there are 256 different tiles available for the background
The pattern tables are the 8x8 pixel graphics for each of those tiles. Each 8x8 graphic is stored in 16 bytes (2 bits per pixel in a 'bitplane' format)
squeeeeee so much fun.
closed account (N36fSL3A)
It sounds very interesting a long with time consuming. What part on the APU should I start on first?
Does it require me to be very efficient with the use of my resources?
Does it require me to be very efficient with the use of my resources?
| What part on the APU should I start on first? |
The APU is Audio. Unless you're doing an NSF player I wouldn't worry about it. At least not until you have a functional CPU and PPU.
The PPU is the graphics stuff.
If you meant APU... then start with one of the pulse/square channels. Don't worry about the length/sweep/decay units.. and just focus on the period and duty cycle... those are what are needed to actually generate tones. The other stuff is for effects. Most music will play fine without them.
You can also ignore the frame sequencer (which drives the length/sweep/decay units) at first.
If you meant PPU... then just get a title screen drawing. Don't worry about sprites, just get a basic background displayed.
| Does it require me to be very efficient with the use of my resources? |
Not really. Modern machines are pretty much super-fast, and NES emus written in notoriously slow languages (ie: Javascript) can get full framerates.
That said... faster is better.
Also, FWIW, Super Mario Bros. is a bad game to start with, as it does some trickery and is harder to get working than you might expect.
Some easy starting games are:
Donkey Kong
Balloon Fight
Ice Climber
Some easy starting games are:
Donkey Kong
Balloon Fight
Ice Climber