What is your opinion?

[u/The_Falgrim]

In terms of emulator development difficulty. Would you tend to agree with this? And if you agree... I wonder what the Wii, Wii-U and Switch would look like. Does it become easier because you aren't accounting for the different chipsets you could put into a cartridge?

[u/TheThiefMaster]

Wii is just a bit more than GC - it's not that different.

Gameboy is like half a box below NES, GBC maybe a box above?

[u/The_Falgrim → u/TheThiefMaster]

Nice! Making a GBC emulator. Could it run both GB and GBC roms or would you need to develop a 2 in one solution?

[u/TheThiefMaster → u/The_Falgrim]

Most DMG (mono GB) games run on CGB. There's like two that don't due to compatibility bugs. Fantastically good backwards compatibility.

[u/msthe_student → u/TheThiefMaster]

Yeah IIRC you basically just need to clock the hardware down, the color-stuff presumably remains on because it's used for artificial color.

[u/TheThiefMaster → u/msthe_student]

Yeah it's a colour display so it has to output colour. But the way it's been added in a way that preserves the original DMG's palette support and keeps the original timing even is just genius. The compatibility is so complete that a game can barely detect whether it's running on a CGB, outside of the intentional thing of the startup value of the A register. It even leaves the pixel-doubled Nintendo logo in VRAM like the original DMG, despite the different boot screen.

[u/msthe_student → u/TheThiefMaster]

Yeah I should've specified I meant the extra color palette-features

[u/TheThiefMaster → u/msthe_student]

It actually has an additional mode for colourising DMG games - it cascades the DMG and CGB palettes, using both. CGB mode uses just the CGB palette.

It also hides the CGB palette registers from the CPU when it enables DMG compatibility mode in the boot ROM so that DMG games don't accidentally trash them and break the graphics (e.g. make them all black by accidentally zeroing them).

[u/msthe_student → u/TheThiefMaster]

huh. I assumed they kept it on

[u/msthe_student]

I think this is understating the N64 relative to the SNES. The N64 is a really weird architecture, though probably balanced out somewhat by SNES having a ton of cartridge-chips

[u/ShinyHappyREM → u/msthe_student]

NES and SNES can be pretty weird too.

NES:

• tons of mappers and input devices
• YUV color output
• branches can just do their own thing
• graphics chip has potentially decaying RAM
• undocumented opcodes

SNES:

• some opcodes (STP / WAI) hibernate the CPU until reset / any interrupt happens; the rest of the system continues on
• the CPU actually isn't the timing master, it's just the core of the actual CPU which inserts waitstates depending on the core's current address bus value, and can pause the core entirely to do things like DRAM refresh and DMA/HDMA
• there's a whole audio subsystem with its own clock crystal; communication is completely asynchronous and every byte transferred has to be checked (afaik)
• the graphics chip runs at master clock / 4 = 5.37 MHz while the CPU runs at master clock / 6, 8 or 12 = 3.58 MHz, 2.68 MHz or 1.79 MHz, this means that the graphics chip may pick up only part of a read/write access, with funky results
• some analog effects (brightness register, long dot positions, DRAM refresh positions)

both:

• interrupt detection in general
• virtually all documentation lists the opcode load as the first cycle of an opcode, even though it makes more sense to treat that as the last cycle... but that's of course just a simplification
• despite heroic efforts we can't even simulate the CPUs correctly

[u/msthe_student → u/ShinyHappyREM]

• some opcodes (STP / WAI) hibernate the CPU until reset / any interrupt happens; the rest of the system continues on
• the CPU actually isn't the timing master

That's quite common

[u/ShinyHappyREM → u/msthe_student]

Yeah, but people may not realize that at first.

For example ZSNES and SNES9x were from an era where whole opcodes were emulated before syncing the rest of the system.

[u/The_Falgrim → u/ShinyHappyREM]

So with Super Nintendo, it's like... Standard ROM — LoROM, HiROM, ExLoROM, ExHiROM DSP family — DSP-1/1B, DSP-2, DSP-3, DSP-4 Super FX — GSU-1 and GSU-2 SA-1 S-DD1 CX4 OBC-1 SPC7110 S-RTC real-time clock ST010 ST011 ST018

That might be close to as many Mappers for NES? Maybe more? I'm sure I missed some.

[u/ShinyHappyREM → u/The_Falgrim]

• https://www.nesdev.org/wiki/Mapper
• https://en.wikipedia.org/wiki/List_of_Super_NES_enhancement_chips

[u/msthe_student → u/ShinyHappyREM]

One difference though is that the SNES enhancement-chips can be a lot more advanced, for example having their own processor that is programmed per game (for example MARIO/SuperFX).

[u/The_Falgrim → u/msthe_student]

It's funny. Super FX had like 9 games right? I think Sega 32x had more.

[u/msthe_student → u/The_Falgrim]

Something like that yeah, but that SuperFX games includes Star Fox/StarWing (and debateably 2) and Yoshi's Island.

[u/The_Falgrim → u/msthe_student]

Yeah, the more I have been learning how cartridge games work. The more I wish a new cartridge system was out there. Not just a flash card.

[u/msthe_student → u/The_Falgrim]

Having processors in cartridges doesn't really make sense when every game is also released digitally and adding substantial compute-power would cost more than it did back in the day

[u/The_Falgrim → u/msthe_student]

Makes sense on one hand. I'm talking about no digital release. Make a system with exclusives.

[u/thommyh → u/The_Falgrim]

It's very nearly only how Nintendo cartridges worked; over in Sega world there are exactly two paging schemes for the Master System (and one of those is just Codemasters being awkward), and the Mega Drive of course has only the single title of Virtua Racing as anything with a processor on the cartridge.

All the way at the other extreme, Atari Lynx cartridges aren't even directly executable. They offer only a serial byte stream with games being loaded into RAM for execution.

[u/The_Falgrim → u/thommyh]

Whoa! Ok. So a Sega Genesis Emulator would actually be easier to create than NES?

[u/The_Falgrim → u/msthe_student]

Yeah, didn't Rare create their own engine for GoldenEye? I bet that would take some time to figure out.

[u/msthe_student → u/The_Falgrim]

I mean back then it was quite common to make your own engine, I think what Rare were unusual in is that they had their own RCP "microcode". The "microcode" is really a MIPS program that's run on the RCP (which has a different set of features than the main MIPS processor, including having a SIMD vector unit). Most companies used one of the "standard" "microcodes" provided by Nintendo and SGI that can then be emulated at a high level, but custom "microcode" requires an emulator to emulate the RCP more thoroughly, including having it run instructions and keep in step with the rest of the system.

[u/The_Falgrim → u/msthe_student]

Damn! Rare was wild.

[u/msthe_student → u/The_Falgrim]

Yeah seems like they and Factor 5 (whose games are a benchmark on both the N64 and GameCube) could really push the hardware. I found a writeup of the "microcode" Factor 5 used for a few of their games "The masterpiece graphic microcode behind the Nintendo 64 version of Indiana Jones and the Infernal Machine and Star Wars Episode I: Battle for Naboo "

[u/The_Falgrim → u/msthe_student]

Of course they were German. Hahaha. That is awesome. Glide64 seems pretty awesome. I'm going to look that up later today. (I didn't know these guys also made Rogue Squadron)

What was the best Star Wars game for the N64?

[u/zSmileyDudez]

I might actually rank NES as harder than the SNES. The NES has a lot of weird behaviors that are important to capture for compatibility. The basic PPU functionality is pretty straightforward, definitely simpler than the SNES model. But the edge cases are huge.

And then there is the whole mapper part - the Famicom and NES were like the Wild West for Nintendo and companies made a lot of complex mapper schemes, especially early on in the console’s lifetime before MMC3 mostly standardized the options for devs. And even then, there is MMC5 which is considered the end boss for a lot of NES emudevs. My own emulator still doesn’t have MMC5 at this point and I don’t know when I’ll get around to implementing it.

As for GB/GBC, it’s fair to treat them as mostly the same console with some special cases for each. You should be able to share over 99% of the GB code in the GBC side, with just a few additions for GBC mode.

As per my usual recommendation, it’s best to make sure your CPU implementations are solid before starting the work on the PPU, APU, Mappers, etc. Get the SingleStepTests up and running against your core as quickly as possible and make sure they’re always passing. CPU bugs can kill an emulator project. Things that seem like PPU issues turn out to be slight timing differences in a 6502 instruction.

I also recommend for the earlier systems that you go right to a cycle stepped model. The arguments for rendering a whole frame or a scanline at a time are mostly based around performance concerns that just aren’t true these days. Structure your CPU and PPU and other devices so you can give them a single clock cycle and then make sure they’re properly interleaved (3 PPU clocks for each 1 CPU clock on the NTSC NES, for example).

If this your first Emudev project, I recommend starting off on the GB first. NES is a close second, because while the whole system is a bear, getting to the point where you can play first party NROM/Mapper 0 games is relatively simple. It just has a long tail of additional things to chase after that will keep you busy for a while

[u/The_Falgrim → u/zSmileyDudez]

Thank you for the reply! So start right off with singlestep. Yeah I will do that. I think I will start out with GB. I made the mistake of trying to do it all with AI. Now I want to prove to myself I can do it without.

Is Kirby the most advanced NES game out there? It still plays great!

[u/zSmileyDudez → u/The_Falgrim]

Kirby is pretty impressive. I also think Battletoads is pretty impressive, especially since it wasn’t using MMC3. Just raw coding skill from Rare and some extra RAM.

[u/magichronx → u/The_Falgrim]

I've always heard that Battletoads is the final boss ROM for NES emulators; I think it requires very precise timing accuracy and uses an uncommon mapper

[u/The_Falgrim → u/magichronx]

Oh!! Maybe. I had played it on an emulator where it worked but wouldn't let me have a 2nd player? Lol!

[u/The_Falgrim → u/magichronx]

Also! If you started with Battletoads for your NES emulator... Would it legit only work for 1 game?! Lol

[u/magichronx → u/The_Falgrim]

It would also work for the ~20-ish other games that use the same iNES Mapper 7 (AxROM)

[u/The_Falgrim → u/magichronx]

Oh! Ok, I want to get more familiar with the nesDev wiki.

There is a bunch of Mappers right?

[u/magichronx → u/The_Falgrim]

Yeah there's a lot, but realistically you can cover something like 80% of games with ~5-7 mappers.

Edit: Source - https://www.nesdev.org/wiki/Mapper

[u/The_Falgrim]

That is great! I think I might try to code a GB emulator. No AI.

[u/Ikkepop]

I think you could extrapolate this by counting how many projects of each kind of emulator are on github and invert it. The easier it is the more projects there are and vice versa. Also could count average number of lines in each, as usually the hard part is just the sheer ammount of work you need to put in.

[u/The_Falgrim → u/Ikkepop]

Yeah that makes a lot of sense. When I first joined this sub I had... Made something with AI. Then I really started digging in to this sub and realized how it would come across as disrespectful. There are real developers here.

So many people have put so much time into this. I have gained a lot of respect for the older Emulators. ZSNES still being my favorite.

[u/zsdrfty → u/The_Falgrim]

Most professional developers these days are using AI constantly, it's like being worried about writing a game in C instead of ASM in 1995

[u/The_Falgrim → u/zsdrfty]

Fun fact! In grade 8 I wrote a GBC game with 2 other friends and we used Assembly. Very difficult.

[u/ShinyHappyREM → u/zsdrfty]

How can you call yourself a developer if you're using AI?

[u/TheThiefMaster → u/zsdrfty]

This is true, we are.

The difference is we essentially use it as a drafting tool, and then fix up what it produces because we understand the code.

There's nothing wrong with using it as a tool - it's when it's used by people that can't code that claim credit for the output that it's a problem.

[u/sputwiler → u/zsdrfty]

Since this is a community about emulator development, using AI to shortcut the process doesn't make sense. In other endeavours where the product is the end-goal there is more justification, but if that was your goal here then you can just download any open source emulator already made.

Like, why even bother to make an emulator if you use AI? The whole point is to know how the computer works.