It is currently Fri Dec 15, 2017 4:49 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 22 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Mon Oct 12, 2015 5:36 am 
Offline

Joined: Sun Sep 20, 2015 5:44 am
Posts: 14
OK I see, thanks.

I think it would be easier to run different things for PPU, APU, CPU and such. That way I can focus on one thing at a time whilst improving bits, without messing up the code elsewhere if I manage to do that.

Also, what are the easiest mapper numbers to use?
(I'm probably going to make a /Mappers directory so they can be updated if needed by anybody, and be easier to work with, but I don't know if I'm able to get mappers to load from a single file, like NESten does)]

Edit: that's a stupidly worded question, what I meant was is putting every mapper on one file better, or to separate each mapper either to their creators or individual mapper. Or something like that.

Also, I'm mainly writing this so I have something to do, and because I want to see how it turns out. I'll be trying to update it sometimes when I start coding it (could be any time from 4 months to over a year)


Top
 Profile  
 
PostPosted: Mon Oct 12, 2015 8:48 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19348
Location: NE Indiana, USA (NTSC)
The easiest mapper numbers to emulate, which will give you the biggest payoff in number of supported English-language games, are 66 (GNROM, which has 0 and 3 as subsets), 11 (Color Dreams, which is GNROM with its writable port's nibbles swapped), and 2 (UNROM). Of the 790 US games in NesCartDB, this covers 250 (31%): 58 on mapper 0, 62 on mapper 3, 5 on mapper 66, 31 on mapper 11, and 94 on mapper 2. Mapper 7 (AOROM) is easy in theory, giving an additional 32 games, but popular games on that mapper are more likely to rely on exact CPU/PPU timing.


Top
 Profile  
 
PostPosted: Sat Oct 17, 2015 1:24 pm 
Offline
User avatar

Joined: Wed Aug 26, 2015 8:24 am
Posts: 21
Location: Ontario, Canada
Termingamer2-JD wrote:
Also, I'm mainly writing this so I have something to do, and because I want to see how it turns out. I'll be trying to update it sometimes when I start coding it (could be any time from 4 months to over a year)


Don't worry, I've been at my emulator on and off for the past 6 months or so and have just recently finally finished the CPU. Has been totally worth it, I've learned (and still am learning!) so much.

_________________
Aliasmk- GitHub :: Twitter :: Website
Current ALIAneS Emulator Progress: CPU complete, PPU indev - we have graphics and sprites!


Top
 Profile  
 
PostPosted: Mon Oct 26, 2015 4:15 am 
Offline

Joined: Sun Sep 20, 2015 5:44 am
Posts: 14
@tepples Thanks for the advice, I'll focus on those mappers and such, I don't need to be having difficulties emulating an annoying mapper first just for compatibility with some good games. (Quality not quantity)

@Aliasmk I noticed that with a lot of things regarding emulation :) although I'll probably release a ton of sub-releases fixing little bugs, actually that gets me onto version systems, how should I do it?

----

There's systems like:
0.11 - ZSNES style
0.1.1 - FCEUX style
0.1a - Nocash style

Best one?

----


Top
 Profile  
 
PostPosted: Mon Oct 26, 2015 8:23 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19348
Location: NE Indiana, USA (NTSC)
I'd begin with 0.01, with two digits after the dots. Hopefully it should take fewer than 100 preview releases to get to the point where you have something you feel is feature complete and stable enough for wide public use. Or for a few of my projects, the version number before completeness has just been the number of days since project start.

Once you have a feature-complete and stable product, increment to 1.0.0 and follow the Semantic Versioning standard a.b.c:
  1. MAJOR version when you make incompatible API changes,
  2. MINOR version when you add functionality in a backwards-compatible manner, and
  3. PATCH version when you make backwards-compatible bug fixes.

For an emulator, "incompatible API changes" may include changes to the scripting system (such as FCEUX Lua) that break existing scripts, changes to the debugger that break existing breakpoint files, or (I'm not entirely sure of this) major updates to the emulation model that break saved states and movies. For a game engine, "incompatible API changes" may include changes to the engine's level data format and enemy behavior model that break mods.


Top
 Profile  
 
PostPosted: Mon Oct 26, 2015 9:20 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2983
Location: Tampere, Finland
Frankly, what versioning scheme you will be using is the least of your worries if you don't know any programming language and want to write an emulator. I'd suggest getting your hands dirty (i.e. start writing code) as soon as possible, if you want to have any chance of succeeding at this. Analysis paralysis is not good, and you're not going to be able to pre-empt all of the problems with no experience. So it's better to take the mistakes as they come, and do a couple of rewrites as needed.

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi


Top
 Profile  
 
PostPosted: Tue Nov 03, 2015 10:20 am 
Offline
User avatar

Joined: Wed Dec 06, 2006 8:18 pm
Posts: 2806
thefox wrote:
Frankly, what versioning scheme you will be using is the least of your worries if you don't know any programming language and want to write an emulator. I'd suggest getting your hands dirty (i.e. start writing code) as soon as possible, if you want to have any chance of succeeding at this. Analysis paralysis is not good, and you're not going to be able to pre-empt all of the problems with no experience. So it's better to take the mistakes as they come, and do a couple of rewrites as needed.


I agree. You need the right priorities. The top priority for you needs to be learning a programming language and getting used to a development environment. You have to be able to write and compile a program that can do two things before you should ever worry about an emulator or various little details. You have to be able to get Input from the user, and draw graphics on the screen. If you can't do either of those you can't make a usable emulator.

I believe I suggested before you should make a simple game. Whether it is your own Pong, Tetris, Space Invaders, etc. it doesn't matter which. It will get you some knowledge that will be needed to put together a working emulator.

About "run different things for PPU, APU, CPU, and such", when programming a complex project you ofcourse will want to organize your source code files and functions in a way that makes sense. Typically people do have the major components in different source files. But that just helps maintaining the project, if you wanted or just for temporary you could have everything in one long source file.

I can't stress it enough though that before writing an emulator you have to have some programming experience and making small demos or games that teach you how to do certain things is very important. Not all development environments are the same, not all libraries are the same. You have to get used to one and be able to put something simple together before you're going to make something as complex as an emulator. And with an emulator, it's the kind of project that is basically never finished. Emulators aren't finished, they just stop being updated or are abandoned. There is almost always more you can improve or add.


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 9 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