It is currently Mon Oct 23, 2017 10:14 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 22 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Tue Sep 29, 2015 5:38 am 
Offline

Joined: Sun Sep 20, 2015 5:44 am
Posts: 14
Obviously I need to learn code first, like C, C++ or assembly, but blarg, what else should be started?

I'm obviously new to this, but I need to know what kind of things should be included first, and what else could be added later on... I'm talking in fact of the NES emulation and not GUI or other useless features, I want to get stable performance and accuracy before adding a GUI or other features.

Elaborate on this.

(Also, I AM going to start this project some time, it's to turn into something usable and for me to learn code.)


Top
 Profile  
 
PostPosted: Tue Sep 29, 2015 6:05 am 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3064
Location: Brazil
My suggestion:

1. Take an open source NES emulator and try to compile it. These days are very common the Visual C++ to compile it. In older times, you take the source and compile it with gcc using the command prompt, but oh well... :) Setting up Visual C++ isn't an easy task, or even... is it free?

2. Modify it, try to make some minor improvement. It's a valuable step for learning C/C++.

3. Read the CPU source code and trace it. It's another valuable step for the inner mechanics of the NES.

Well, C wasn't my first step into PC programming. I had a huge experience with Clipper Summer'87 and something with Pascal. Getting into C language wasn't so hard... and getting the things working was very good. ^_^;;


Top
 Profile  
 
PostPosted: Wed Sep 30, 2015 7:20 pm 
Offline
User avatar

Joined: Mon Apr 13, 2015 7:52 am
Posts: 6
No GUI, difficult to debug PPU it is a long way.
I learned about half a year is also wrote a no sound demo (I know DirectX/Win32SDK) :wink:
Image


Top
 Profile  
 
PostPosted: Wed Sep 30, 2015 10:01 pm 
Offline

Joined: Sun Jan 26, 2014 9:31 am
Posts: 256
Generic advice before starting on any emulation project:

* Read up on documentation about the system (the NES in your case). You don't have to cram everything into your head, just browse through some stuff and see what you can pick up. Try to get a rough overview of what the console looks like on the inside.

* Aim for CPU emulation first. The CPU is central to the rest of the system, and you need a basic working CPU before you can attempt to delve into video (the PPU) or audio (the APU) properly. Emulating the CPU may not have any fancy output (like graphics or sound) but it's important to get this out of the way.

* Along with emulating the CPU, one of the first things I usually do when emulating a new system is to emulate basic memory operations (reading and writing bytes, memory management). As a start, try to emulate the NES' memory map roughly. Do something simple like loading up a ROM, then grabbing and decoding a couple of instructions.

* Choose simple "carts" to emulate at first. By this, I'm referring to the NES' mappers (the Game Boy equivalent would be memory bank controllers, or MBCs). There are a handful of them with various nuances and levels of difficulty to implement. Start with one of the simpler ones (NROM? I'm not familiar with mappers, so someone else can tell you from their experience)

* Build a small debugger. It doesn't have to be anything special. It can spit out pure textual info, as long as it shows you useful information (CPU state, current instruction, specific memory values, etc). I can tell you firsthand that making a debugger is the single greatest time-saving mechanism I made when programming emulators. Any number of things can go wrong as you start out; you should have some way to look inside your emulator and see what it's trying to do in comparison to the behavior you actually expect.

* Try your hand at homebrew tests. Sometimes you want to test a really specific aspect of a system, under certain conditions. Writing your own programs for the NES (and your emulator) will enable you to make any test you want.

This is pretty much the process I take whenever I tackle a new system. Currently working on DS emulation, and these are the same steps I took with the GBC/GBA. Hope it helps :)


Top
 Profile  
 
PostPosted: Thu Oct 01, 2015 11:56 am 
Offline
User avatar

Joined: Wed Dec 06, 2006 8:18 pm
Posts: 2801
If you cannot program anything you should start there. You might want to try making a simple game. If you can make a simple game, you'll have a lot easier time trying to make an emulator. It will atleast get you familiar with getting Input from the user and drawing graphics on the screen.

If you really have no coding experience, starting with an emulator is unlikely to lead to anything positive. Just a lot of wasted time. I doubt anyone here that has programmed an emulator did so starting out with no programming experience.


Top
 Profile  
 
 Post subject: ok
PostPosted: Fri Oct 02, 2015 5:27 am 
Offline

Joined: Sun Sep 20, 2015 5:44 am
Posts: 14
I could try.

Perhaps demos that test out the nes features, although there's many, I could write some for testing on other emulators too.

Also, I'm pretty aware that there's about 562946 mappers for the NES. What are the main ones used for NES games? I'll mainly focus on those like the early releases on the system first and mappers used by homebrew developers.

Also, I plan to make this usable on other OS's (unofficial builds) so I'll probably use C, but I don't know the best for sound. Obviously sound isn't one of my concerns right now, though.

Oh, and it might be a waste of time but it can help me learn stuff, also I don't know what I could make before the emulator. I don't care whether it's useful for 6502 debugging or hex editing, besides other things, all I would need is reasonable accuracy and speed, I don't care for other features.

So yeah it will be an average NES emulator which will be built on most likely.

Edit: Oops. I forgot to reread the post before the last one, although I read it last night, so most of what I said was covered above or I contradicted it.


Top
 Profile  
 
 Post subject: Re: ok
PostPosted: Fri Oct 02, 2015 6:28 am 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19119
Location: NE Indiana, USA (NTSC)
Termingamer2-JD wrote:
Also, I'm pretty aware that there's about 562946 mappers for the NES. What are the main ones used for NES games? I'll mainly focus on those like the early releases on the system first

The common discrete logic mappers are CNROM (which has NROM as a subset), UNROM, BNROM, and AOROM. They should get you through much of the early library.

Quote:
and mappers used by homebrew developers.

Once you get those done, it shouldn't be hard to progress to MMC1 and Action 53.


Top
 Profile  
 
 Post subject: Re: ok
PostPosted: Fri Oct 02, 2015 10:01 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6297
Location: Seattle
tepples wrote:
BNROM
Pedantic and unimportant, but GNROM is more common than BNROM.


Top
 Profile  
 
PostPosted: Fri Oct 02, 2015 11:22 am 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19119
Location: NE Indiana, USA (NTSC)
I admit I was thinking forward toward a couple new releases on oversize-BNROM mappers.

And yes, CNROM itself is a subset of GNROM.


Top
 Profile  
 
 Post subject: Re: ok
PostPosted: Fri Oct 02, 2015 12:30 pm 
Offline
User avatar

Joined: Wed Dec 06, 2006 8:18 pm
Posts: 2801
Termingamer2-JD wrote:
Also, I'm pretty aware that there's about 562946 mappers for the NES. What are the main ones used for NES games? I'll mainly focus on those like the early releases on the system first and mappers used by homebrew developers.


The majority of games official licensed titles use a very small number of the total mappers. Very few mappers being supported will still allow for supporting the vast majority of titles. The discrete logic mappers like UxROM, AxROM, NROM, CNROM, cover a large portion of titles. Then MMC-1 and MMC-3 cover the next big groups. After those however you have a lot of mappers that are used in relatively few games by comparison.

Quote:
Also, I plan to make this usable on other OS's (unofficial builds) so I'll probably use C, but I don't know the best for sound. Obviously sound isn't one of my concerns right now, though.


If you aren't already familiar with any programming language then you need to learn one first. You also need to realize that the programming language doesn't provide things like sound or graphics output. You have to link to a library to have those things available to you generally. On the PC you have multiple OS to choose from and many different libraries. SDL is a library that is supported on many platforms. However there are different versions which may not be fully compatible between eachother so you need to be sure whatever platforms you intend to port to have an appropriate version of your library choice.

I started using C in combination with Allegro which I like using. I use Allegro 4.x however there are newer versions. Ofcourse you can choose to use whatever you want for whatever you want. I've used Allegro for input and graphics while using FMOD for sound. You could use Direct X if you wanted but that limits you to Windows platforms. You'll just have to look and see but if you have no programming experience you have a lot to work out before worrying too much about making any emulator.

Quote:
Oh, and it might be a waste of time but it can help me learn stuff, also I don't know what I could make before the emulator. I don't care whether it's useful for 6502 debugging or hex editing, besides other things, all I would need is reasonable accuracy and speed, I don't care for other features.


It's not a waste of time if you learn from it. Before making an emulator you could make a simple interactive game or demo. For example one of the first "game" programs I made was just 2 player Pong with a high resolution background I found appealing and some hand drawn paddles and ball. I added some sounds and music too. That taught me a lot of key things for programming. Then you can go further, maybe program a simple shooter game like Space Invaders or Galaga. Or try to do a Tetris clone.

Quote:
So yeah it will be an average NES emulator which will be built on most likely.


Making even an average NES emulator for someone with no programming experience is not an easy goal to reach. But you certainly can reach it if you put in the time and effort. The biggest task and first task is getting the 6502 type CPU emulated. This is a long process that will take a lot of time and debugging to get right. It's not terribly exciting work but it's the heart of the system. Once you get it solid, you can work on graphics display to actually see something going on. But that's getting ahead of yourself if you have no programming experience and don't understand 6502 ASM code.

If the whole idea of writing your own emulator appeals to you, do it. All I am telling you is that it's going to take significant time and effort to achieve if you have no experience so far. But as far as systems go, the NES is not hard to emulate decently. This is likely part of why there are more emulators for NES than any other system I bet.


Top
 Profile  
 
 Post subject: Re: ok
PostPosted: Fri Oct 02, 2015 12:46 pm 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19119
Location: NE Indiana, USA (NTSC)
MottZilla wrote:
Or try to do a Tetris clone.

Careful.


Top
 Profile  
 
PostPosted: Sun Oct 11, 2015 8:15 am 
Offline

Joined: Sun Sep 20, 2015 5:44 am
Posts: 14
That's why I chose NES/Game Boy to start with (perhaps co-developing), because I think it would be a good place to start.

And I'll be focusing on that 6502 CPU, and I'll also build a debugger with it (before actually emulating more than a CPU and operation codes).

I have a couple of questions, though: when should I build a GUI? I don't know whether to add one at first or whether to use a command line for a while.

Also, what could I build in C and what in assembly? This is intended to be open source and freely usable to be ported to other systems like Linux, for example. I'll probably use assembly for emulation, because of the CPU itself.

There's no knowing when this is going to be done. I'm just collecting ideas before I start getting into programming, I didn't want to go in cold and be confused, sit for a while wondering what to do. If that makes sense.


Top
 Profile  
 
PostPosted: Mon Oct 12, 2015 2:59 am 
Offline

Joined: Mon Apr 01, 2013 11:17 pm
Posts: 437
Termingamer2-JD wrote:
Also, what could I build in C and what in assembly? This is intended to be open source and freely usable to be ported to other systems like Linux, for example.

You should not use assembly for any part of the emulator. It makes porting much more difficult, and the C compiler is probably better at writing assembly than you are.

Termingamer2-JD wrote:
I'll probably use assembly for emulation, because of the CPU itself.

What do you mean by that?


Top
 Profile  
 
PostPosted: Mon Oct 12, 2015 3:16 am 
Offline

Joined: Sun Sep 20, 2015 5:44 am
Posts: 14
Well I know nothing.

What I mean is that the 6502 CPU is assembly anyways, as previously stated somewhere.

----
I'll take your advice, I'll go and just use C and see how it goes on, it should therefore be easier and still fast (hopefully).
----------
Another thing - where can I store each thing? video, audio etc. by that what sort of dlls should I make for each thing and what should be in the main emulator code, and what in the external files.


Top
 Profile  
 
PostPosted: Mon Oct 12, 2015 3:40 am 
Offline

Joined: Mon Apr 01, 2013 11:17 pm
Posts: 437
Termingamer2-JD wrote:
Well I know nothing.

What I mean is that the 6502 CPU is assembly anyways, as previously stated somewhere.

Okay, I think I see the confusion here.

Every CPU runs on machine code. The 6502 understands 6502 machine code, the x86-based CPU in your computer understands x86 machine code, and the ARM CPU in your cell phone understands ARM machine code.

Reading and writing machine code is a pain, so we use assembly instead. Every instruction in assembly corresponds to one instruction of machine code. (There are some exceptions, but let's ignore that for now.) This means assembly for a 6502 CPU will look a lot different compared to assembly for an x86 CPU.

Termingamer2-JD wrote:
Another thing - where can I store each thing? video, audio etc. by that what sort of dlls should I make for each thing and what should be in the main emulator code, and what in the external files.

If you have any shared libraries (or "DLLs"), those should belong to whichever UI framework you're using. All of your emulator code should end up inside the main executable.

Of course, your C code does not have to be all in one file. You'll probably want to split up the C code by major functions: audio, CPU, video, mappers, and so on. You can then tell the compiler to link them together into a single executable.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 22 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group