So, I have no clue if this is the correct forum to post this in, but this seems to be the most active emulation forum on this site so what the heck.
I took a break of several months (only slightly ashamed) from the scene after having implemented the CPU and most of the PPU for my NES emulator in Java. I got stuck on some MMC1 stuff and it overloaded my brain so I quit for a while.
Anyway, it's all pulling me back again, but this time I'm thinking of trying to emulate the GB(C) rather than finishing the NES.
Does anyone have any experience with emulating both? What's the difference in complexity of emulation between them? I know that the GB(C) CPU is a modified Z80 compared to the 6502 and that graphics are rendered very similarly with a couple more/less colors/tiles etc. Which is harder to emulate? The only reason I see to not emulate the GB(C) yet is due to the combination of: meager experience in emulation and the lack of abundant documentation like the NES has. What do you think?
Furthermore, if anyone has done the SNES and/or GBA, what's the difficulty on those? I have noticed people talking about how those are much much more complex since they have many more quirks that one needs to keep in mind, but how much does this add to complexity compared to the NES/GB(C)?
NES is definitely the easiest to emulate in most ways. It does have some tricky details to get right. But the Gameboy and Gameboy Color have alot more going on. The SNES ofcourse even more so as you have two CPUs. The GBA I'm not sure, it might be less quirky and more straight forward to emulate but if you are writing your own CPU cores it's definitely more work than the little old 6502 based CPU of the NES. I'd say stick with the NES, when you get bored try Gameboy and later GBC.
The MMC1 shouldn't be stopping you. If it's confusing then skip it and do other mappers. UNROM is easy (mapper 2) and many great games use it. You also have AxROM (mapper 7) used by plenty of games that will test your emulator's accuracy and behaviors. Then ofcourse there is MMC3. Not too tricky to implement.
MottZilla wrote:
NES is definitely the easiest to emulate in most ways. It does have some tricky details to get right. But the Gameboy and Gameboy Color have alot more going on. The SNES ofcourse even more so as you have two CPUs. The GBA I'm not sure, it might be less quirky and more straight forward to emulate but if you are writing your own CPU cores it's definitely more work than the little old 6502 based CPU of the NES. I'd say stick with the NES, when you get bored try Gameboy and later GBC.
The MMC1 shouldn't be stopping you. If it's confusing then skip it and do other mappers. UNROM is easy (mapper 2) and many great games use it. You also have AxROM (mapper 7) used by plenty of games that will test your emulator's accuracy and behaviors. Then ofcourse there is MMC3. Not too tricky to implement.
Indeed, the NES does seem to be the easiest. The GameBoy (Color)'s CPU alone seems like a hell to implement, seeing how I took way too long implementing the NES CPU. Probably wouldn't be a good idea for a beginner like me to jump onto the SNES/GBA-train, especially considering the lack of extensive documentation/supporting communities (as far as I could tell).
Mappers didn't stop me at all. I had already implemented NROM, UNROM, CNROM and AxROM successfully. Almost all the games for these mappers worked perfectly, aside from some minor sprite 0 hit issues which are not even mapper-related for the most part. The MMC1 mapper however, seems to load the wrong nametables. Whenever I'm playing a game that does not actually crash, it either renders gibberish or it renders something from the wrong nametable. I suppose I'll make a separate topic about that if I get back to the NES.
Thanks for the info. If anyone has more details about the difference in complexity between the systems, I'd be happy to be informed.
Hello,
I actually have a pretty different opinion - I have not worked on GBC emulation but only GB, so my comments below may not be completely applicable.
1) NES
I find the NES to be overwhelming at times, first of all due to the many mappers out there, which often do more than just "map". Also, implementing cycle-accurate PPU was a tough task for me, and I'm not even done with it. I often feel that my PPU code is like black magic, and that there is little I can do about it. The documentation out there (for instance the skinny on NES scrolling) is quite daunting, leading to source code usually as complex as the information used as a reference. I find it helpful to refer to pieces of the original documentation (using comments within the code) in order to remember what the code is about months later (check ppu_writeb function in
https://code.google.com/p/emux/source/b ... ideo/ppu.c).
2) Game Boy
The Game Boy on the other hand doesn't have many mappers, and their role is limited. The graphics emulation seemed easier to me, and less prone to timing issues. For instance, there was no need to rely on "invisible" sprite hits for a game to know which scanline was just rendered - developers could rely on a scanline interrupt. This means more natural code for game developers and cleaner code for emulator developers. I don't remember finding the GB CPU (stripped down Z80) to be more or less complex than the 6502.
Overall, the NES hardware feels somehow more extensible, but hacky in many ways, making it harder for emulator developers to produce clean code. This is of course just my opinion, I am certain that a lot of people on this forum would completely disagree with this statement
Regards,
Sebastien
Ask kevtris how easy it is to get the GBA timing system down. Until recently, it wasn't really known about, but GB timings make the NES PPU look like a joke, from what I could understand. Think of it as a rendering pipeline where all actions took a little more time from the pipe and to get it right, but the display still rendered correctly when 100% as-is emulation will fail drastically.
viewtopic.php?t=7861
3gengames wrote:
Ask kevtris how easy it is to get the GBA timing system down. Until recently, it wasn't really known about, but GB timings make the NES PPU look like a joke, from what I could understand. Think of it as a rendering pipeline where all actions took a little more time from the pipe and to get it right, but the display still rendered correctly when 100% as-is emulation will fail drastically.
viewtopic.php?t=7861Are you talking about the GBA or GB or both respectively?
If the latter is true, does it mean the GBA timing is pretty easy while the GB timing is hard? Or are you implying something else?
From what ssronse said, the GB's PPU actually sounds like it's not that much to worry about, especially since the mappers and sprite 0 hit are my main problems at this point in time. Some clarification on this would really be appreciated.
I'm under the impression that compared to NES games, far fewer popular Game Boy games other than Prehistorik Man's intro actually require high-precision timing because the Game Boy has an MMC5-class scanline counter built in.
tepples wrote:
I'm under the impression that compared to NES games, far fewer popular Game Boy games other than Prehistorik Man's intro actually require high-precision timing because the Game Boy has an MMC5-class scanline counter built in.
Overlooked this because we posted at the exact same time.
What components does this affect? Does it mean that a scanline-based GB emulator will work for more games than a scanline-based NES emulator? Does this also make the GB PPU easier to implement, or is it just easier to synchronize with the CPU?
I'm trying to read through the Pan Docs of the GB and this document called "GB CPU Manual", and other than having to ingest a ton of new information, I'm not seeing anything that really seems to make it easier/harder. It's just different, but recognizable.
I think that's the idea, since few if any games will require precise CPU/PPU timing unlike on the NES where a great many games use Sprite 0 and/or careful cycle timing for background splits.
The GB probably isn't that much harder to emulate decently than the NES but I do think there is a bit more to it that makes it probably a harder target than the NES for a decent level of accuracy. The GBC complicates it more.
The GB CPU I think as a whole is a bit more complicated than the NES 6502. It's not a huge difference. The GB certainly is easier when it comes to memory mapping since there are so few MBCs and they all behave very similar.
MottZilla wrote:
I think that's the idea, since few if any games will require precise CPU/PPU timing unlike on the NES where a great many games use Sprite 0 and/or careful cycle timing for background splits.
Seems like the GB isn't THAT hard to implement. Not having to resort to cycle-precision to get many games working, and the fact that it has no sprite 0 hit and only a few mappers is really a huge relief.
MottZilla wrote:
The GB probably isn't that much harder to emulate decently than the NES but I do think there is a bit more to it that makes it probably a harder target than the NES for a decent level of accuracy. The GBC complicates it more.
I will make the GB my priority, and afterwards implement the "C" so to speak. Would you happen to know how much more complex a scanline-based GBC is compared to the GB? I presume the CPU and APU (although sound is at the bottom of my list) remain the same.
MottZilla wrote:
The GB CPU I think as a whole is a bit more complicated than the NES 6502. It's not a huge difference.
Well, the Z80 does have over 200 opcodes if I'm looking at it correctly. Most of them are probably "duplicates" with a different addressing mode I suppose, but it's still more work. I just hope the instructions themselves are not more complex than the 6502's, otherwise 1 little mistake might get me stuck for days if not weeks.
Thanks for the info. I think I'm going to start on my Z80 emulator in a while. I hope it won't kick me in the delicates anytime soon though.
ArsonIzer wrote:
Would you happen to know how much more complex a scanline-based GBC is compared to the GB?
Probably like the difference between NES with a "typical" mapper (UNROM, MMC1, etc.) and NES with MMC5 ExGrafix. Game Boy Color's PPU can flip background tiles, place background tiles in front of sprites, pull each tile from one of two pages of CHR RAM, and color each tile with one of several sets of four colors. Its CPU can run at double speed, and it has
general-purpose more versatile DMA to match the "Blast Processing" in Sega's Nomad system as well as CHR HDMA to load dozens of tiles per frame.
That and players of Tetris and Pokemon will expect you to emulate two Game Boy systems connected through an SPI serial link.
Not general purpose DMA, just DMA targeted only at VRAM.
As for how complicated the Z80 instruction set is? Besides the DAA instruction, everything is straightforward.
tepples wrote:
Probably like the difference between NES with a "typical" mapper (UNROM, MMC1, etc.) and NES with MMC5 ExGrafix. Game Boy Color's PPU can flip background tiles, place background tiles in front of sprites, pull each tile from one of two pages of CHR RAM, and color each tile with one of several sets of four colors. Its CPU can run at double speed, and it has general-purpose DMA to match the "Blast Processing" in Sega's Nomad system as well as CHR HDMA to load dozens of tiles per frame.
Wow, there goes my motivation... well, not really, although that does sound painful to figure out.
Dwedit wrote:
As for how complicated the Z80 instruction set is? Besides the DAA instruction, everything is straightforward.
Then I suppose I'll find that out as I implement it. I guess you'll be seeing me spam the GBDev (or whatever) section soon.
Thanks for all the info guys, it's really helpful.
I've emulated all of these. As for difficulty, it all comes down to completeness.
Simple NES emulator (no mappers, no accuracy) = one day project.
Simple GB emulator (no accuracy) = two day project.
Simple GBA emulator (no accuracy) = two week project.
Simple SNES emulator (no special chips, no accuracy) = one month project.
Good NES emulator (decent accuracy, most major mappers) = two month project.
Good GB emulator (dot-based PPU renderer, nearly all mappers) = one month project.
Good GBA emulator (good cycle timings) = doesn't exist yet. But probably three months. [requires your own hardware research]
Good SNES emulator (decent accuracy, most major special chips) = four year project. (maybe 2-3 now that all the coprocessor firmware is available for LLE.)
Great NES emulator (every mapper/controller/add-on device you can find info on) = two year project.
Great GB emulator (handle all of the quirks, obscure mappers like MMM01/HuC) = two year project. [requires your own hardware research]
Great GBA emulator (handle all of the quirks, weird hardware like sun sensor and rumble) = doesn't exist yet. But probably four years. [requires your own hardware research]
Great SNES emulator (dot-based PPU, all special chips) = eight year project. [requires your own hardware research]
By your own research, I mean you need to write your own tests and run them on the real thing to figure out how stuff works, because you won't find it all in documentation.
If you plug in other peoples' code (like blargg's SNES DSP, or an existing ARM CPU core), you can drastically reduce the above times, but what's the point of writing an emulator if you're not actually writing it?
Documentation levels:
NES = best-in-class, very low-level timing information readily available.
GB = absolutely atrocious. Most documentation is from the '90s. Writing a great GB emulator would be much easier if someone would document it.
GBA = somewhat decent. But not much on low-level stuff like ROM prefetch operation, hardware quirks, etc.
SNES = very good. Research up to 2008 or so is available. Died off after anomie left.
The SNES and GBA PPUs are leagues beyond the NES and GB/C PPUs. Still doable, but the complexity goes way, way up. Without copying an existing implementation, the SNES sound core is the hardest to deal with, but the easiest to "perfect" (since it's mostly digital.)
The SNES SuperFX, SA-1 and ST018 each make the NES MMC5 look like child's play, so keep that in mind if you think NES mappers are hard.
byuu wrote:
but what's the point of writing an emulator if you're not actually writing it?
One possibility would be if you were trying to get an emulator on a new or different platform and none is available yet. For example if one didn't already exist maybe you'd want to write an emulator to run on your PSP, or some other portable or maybe an obscure PC platform.
I do agree though that it's more interesting if you are wanting just to write an emulator if you work on things like the CPU core, sound, etc. all on your own. But that isn't always the goal. Sometimes the goal is just more like a good enough emulator on a new platform.
Quote:
One possibility would be if you were trying to get an emulator on a new or different platform and none is available yet.
I thought the best practice for that was to port SDL and port FCEUX. But I acknowledge that this would not work if you are trying to run an emulator on a platform that forbids copylefted software, such as if you are a video game publisher trying to make your classic games available for a modern video game console. I guess being under a permissive license is what helped
PocketNES take off in Atlus, Jaleco, and Konami compilations.
byuu wrote:
I've emulated all of these. As for difficulty, it all comes down to completeness.
Simple NES emulator (no mappers, no accuracy) = one day project.
Good NES emulator (decent accuracy, most major mappers) = two month project.
Great NES emulator (every mapper/controller/add-on device you can find info on) = two year project.
How long did it take you (and everyone else here) to make your first ever emulator? 1 day sounds pretty insane.
ArsonIzer wrote:
How long did it take you (and everyone else here) to make your first ever emulator? 1 day sounds pretty insane.
I wrote the first iteration of my NES emulator in about a week or two. Basic mappers, mediocre accuracy, no sound.
Obviously it depends on how much experience the person has in emulator development and programming in general.
> How long did it take you (and everyone else here) to make your first ever emulator? 1 day sounds pretty insane.
I started with the SNES, and it took a few weeks to get some interesting demo games running, and around a month or two to get the first commercial game fully playable. For a long time I didn't emulate the APU, so I was patching out the APU wait loops in various titles for a while. I put a lot of emphasis on the debugger right away, so that probably stalled me a bit in getting stuff running, but helped later on.
And it actually only took me half a day to get Super Mario Bros fully playable. I'm sure it was because I emulated the SNES first, and it's very much like a substantially souped up NES in design. Still it was somewhat disappointing how easy all of the 'tough' problems like sprite-zero hit and MMC5 turned out to be.
The only real issue with the NES is the way the insane amount of mappers wears me down. I haven't yet found a way to organize all of that code nicely. Mapper#s are a bad system because the same board can use multiple #s. Board serials are a bad system because some boards lack serials. Lots of board variations exist that use the same MMC chip, but act somewhat differently in certain areas, and it's messy whether you combine or separate the logic for those.
byuu wrote:
The only real issue with the NES is the way the insane amount of mappers wears me down. I haven't yet found a way to organize all of that code nicely. Mapper#s are a bad system because the same board can use multiple #s.
Yeah, I know, UNROM is normally 2 but becomes 180 when one chip is replaced. But the behavior of the two configurations of the UNROM board is so different that it demands a different mapper number.
Quote:
Lots of board variations exist that use the same MMC chip, but act somewhat differently in certain areas, and it's messy whether you combine or separate the logic for those.
At least with respect to identifying these variations, that's what NES 2.0 is supposed to fix. If you've found some NES or Famicom boards that don't have a proper technique to distinguish them, such as ROM or RAM size or submapper number, start a new thread and let me know. Or were you just talking about implementing these variations once already identified?
James wrote:
ArsonIzer wrote:
How long did it take you (and everyone else here) to make your first ever emulator? 1 day sounds pretty insane.
I wrote the first iteration of my NES emulator in about a week or two. Basic mappers, mediocre accuracy, no sound.
That's really quick. I assume you had a lot of experience with programming and low-level hardware before this? Mine took 8 months. Granted I'm a complete amateur when it comes to stuff like this but still, sounds great to be able to do that for a first time.
thefox wrote:
Obviously it depends on how much experience the person has in emulator development and programming in general.
I hope that gives me an excuse then.
byuu wrote:
I started with the SNES, and it took a few weeks to get some interesting demo games running, and around a month or two to get the first commercial game fully playable.
I have to ask you the same question I asked James: what kind of experience with hardware/software/electronics did you have before that? I can't imagine just jumping into a project like this (which is supposed to be a ball-buster) and being able to get a game fully playable without having a lot of prior experience with similar stuff.
It definitely is a vague question. But for certain your level of experience is going to drastically impact how long it takes you. And then how much time per day you have to work on it.
When I wrote my first emulator it took probably a week to go from nothing to something that could play some games. The slowest part in the beginning is writing that CPU core. It's also probably the biggest barrier to someone getting started. When you're working on emulating the CPU there is no really satisfying feedback. You are just looking at your debugger or logger executing instructions. Things are far more interesting and rewarding once you can see something happening.
Once you've written an emulator for NES you could certainly crank one out in a day that would play alot of games.
MottZilla wrote:
When you're working on emulating the CPU there is no really satisfying feedback. You are just looking at your debugger or logger executing instructions. Things are far more interesting and rewarding once you can see something happening.
I'm not entirely sure about that. When I was developing a 6502 simulator for a unit test framework, I felt rewarded just seeing the "percentage of nestest completed with PC and CYC matching the Nintendulator log" metric go up.
ArsonIzer wrote:
James wrote:
ArsonIzer wrote:
How long did it take you (and everyone else here) to make your first ever emulator? 1 day sounds pretty insane.
I wrote the first iteration of my NES emulator in about a week or two. Basic mappers, mediocre accuracy, no sound.
That's really quick. I assume you had a lot of experience with programming and low-level hardware before this?
Some programming experience and a pretty good understanding of hardware, I suppose. I also had a lot of free time.
tepples wrote:
MottZilla wrote:
When you're working on emulating the CPU there is no really satisfying feedback. You are just looking at your debugger or logger executing instructions. Things are far more interesting and rewarding once you can see something happening.
I'm not entirely sure about that. When I was developing a 6502 simulator for a unit test framework, I felt rewarded just seeing the "percentage of nestest completed with PC and CYC matching the Nintendulator log" metric go up.
I guess it depends on what type of person you are. I think for alot of people if they are working on their first emulation project they don't really get much satisfaction until they see some real sign of a game running. Particularly because you can make mistakes with a CPU core if you don't have enough experience with that CPU. And the mistakes may not have obvious effects but could prevent you from getting things working.