MSE NES emulation

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
MSE NES emulation
by on (#93070)
Hello. I have created a NES emulator, but I need some help (Especially when trying to get mappers to work, PPU emulation, APU emulation). It's also part of a multi-system emulator called MSE, but anyways, here's the source link:
https://github.com/Alegend45/MSE

by on (#93071)
Skilled NesDevers would probably be more inclined to help if you were more specific about what you're having trouble with. Or are you just asking people to chip in and code for you?

by on (#93074)
Quote:
Before considering developing your own NES emulator, ask yourself if your efforts may be better spent helping out those who already have emulators in development!

by on (#93078)
Well, it's not just NES, but others, only starting with NES. Also, I'm having trouble extending my framework to emulating not just the CPU, but also the PPU, APU, and mappers. So far, I only have a partial CPU, and mapper 0 implemented.

For example, I'm having trouble extending my single fread of a 32K bank of ROM, into a mapper-conscious loading function...

by on (#93080)
What are you having trouble doing? Do you just not know what to do?

The iNES header will tell you how many PRG and CHR banks exist and you just load the data into memory. Most mappers are very simple to handle. Only a few get a bit more complicated.

But it sounds like you're trying to make a NES emulator and just don't know what to do, which is fine, but you need to ask questions or be more specific about what you don't understand.

by on (#93081)
Well, I have just now made some progress with mapper 2, but on mapper 1, or MMC1, I'm having trouble understanding how I am supposed to duplicate the effect of writing 1 bit at a time, into 5-bit registers. Also, I have no idea where to start on PPU or APU emulation. Console programs are my main specialty.

by on (#93082)
What is so hard about it? You have a counter that determines how many bits have been written into the shift register. When it overflows (all 5bits written) you write to the internal register associated with the address written to. And if anytime the reset bit is written to, you reset your counter.

What is more confusing about MMC1 is there are some games that use MMC1 in odd configurations like SXROM where CHR registers are repurposed for having more than 256K of PRG-ROM and/or more than 8K of PRG-RAM. MMC6 is kind of annoying too since only 2 games use it and it doesn't behave like the MMC3 exactly but as far as iNES mapper numbers are concerned it should.

by on (#93099)
All you seem to have is a bare bones 6502 emulator. I would hardly classify that as a NES emulator at this point. Also if you need to ask such simple questions this early in the development process, it's unlikely you'll ever be able to finish your emulator. Making a multi emulator system doesn't sound like a realistic goal either given your progress so far.

Not trying to be a dick, just stating the truth.

by on (#93105)
thefox wrote:
Not trying to be a dick, just stating the truth.


Agreed. Perhaps, in short words, enthusiastic... but fails.

by on (#93106)
Mednafen has the right approach, in my opinion: a common front-end for multiple existing freely licensed emulator cores.

by on (#93132)
thefox, you have a point there. Honestly though, I seem to be the best with mappers.

by on (#93141)
tepples wrote:
Mednafen has the right approach, in my opinion: a common front-end for multiple existing freely licensed emulator cores.


Important to add that Ryphecha (the author) writes her own cores as well, and thus has experience with fixing the cores she imports. Just slapping a bunch of other emulators into one GUI is interesting, but it's been done to death already as well.

I really have to agree with Zepper and thefox. If the NES is difficult, then emulating other systems (other than perhaps the Chip8) is only going to get worse.

However, the NES is a great place to start learning. Keep at it for 5-10 years and who knows what you can create.

by on (#93148)
I would agree that the NES is probably the easiest console to get games emulated, because you don't have to be that precise to get alot of games to run. And there aren't a lot of complicated details, atleast not required to play the majority of software.

It also is one of the most fun to emulate due to the library of many great games.

by on (#93155)
I'm told the original Game Boy is even easier because fewer games rely on exact cycle timing due to the MMC5-style scanline counter in the Game Boy's PPU.

by on (#93156)
But the Z80 is tougher to simulate than the 6502...

by on (#93162)
Fortunately, the Game Boy doesn't have a full Z80. It has a simpler CPU in the 8080-clone family, with "zero page" style extensions (shorter codes for accessing $FFxx) instead of Zilog's extensions.

by on (#93169)
I agree that Gameboy is probably a bit more complex emulating than NES. There is a bit more going on, though I guess you don't have to be exact. Though personally I find the 6502 variant in the NES to be more friendly than the GB i8080 variant.