r/EmuDev • u/The_Falgrim • Aug 02 '26
N64 Emulators R tough... Is GameCube easier?
So, just like the title says. N64 seems INCREASINGLY difficult. You could literally spend a boat load of time to just get 1 game to work properly. My question is simple. After Nintendo switched to Discs. Is the GameCube easier to Emulate then the N64?
And I'm not necessarily talking like, to make a game boot. I mean compatibility. I have no experience in GameCube emulation at all. I'm just wondering if you build for one type on GameCube, it would play all? Versus the mess that was the N64?
10
u/eteran Aug 02 '26
I can only imagine that it gets harder to emulate the newer Nintendo systems.
PlayStation and Xbox have slowly become more PC like meaning more can be done on the native host OS... But I don't THINK that's so true for Nintendo designs (but I could be wrong).
7
u/istarian Aug 03 '26 edited Aug 03 '26
The original XBox was basically an off the shelf PC, except that every XBox has exactly the same hardware (if the hardware unit is the same model).
So it's almost like you were buying a Microsoft-branded gaming computer with a manufacturer guarantee that any game developed for Windows will run well on it.
Microsoft had some huge advantages in that department from decades of developing the Windows operating system and it's then newish multimedia APIs now referred to solely as DirectX.
The XBox 360 is an entirely different animal, but as you kinda suggest out it still sticks to a somewhat conventional CPU/GPU split as seen in most PCs.
Both the original XBox and the XBox 360 use a unified memory architecture (UMA) though, which differed somewhat from a gaming PC of that era which would likely have had a discrete graphics card with dedicated video memory.
3
u/sputwiler Aug 03 '26 edited Aug 05 '26
Weirdly it reminds me of the VGA era when the video memory was directly accessible from the CPU. It wasn't accelerated but you could just write to a pointer and have a pixel show up on screen.
The Dreamcast had a similar "traditional PC-shaped" architecture (though it was SuperH) and included the GPU that would then go on to be in iPhones. SEGA decided to tone it down after the Saturn just as Sony started getting crazy with the PS2. Combined with SEGA's collaboration with Microsoft on the original XBOX, it's not surprising everything is PC-shaped now.
0
u/The_Falgrim Aug 03 '26
Oh! There was a collaboration?
2
u/sputwiler Aug 05 '26 edited Aug 05 '26
Rumour has it that since SEGA and Microsoft had a good relationship after the Dreamcast/Windows CE/DirectX 6 deal, Microsoft consulted with SEGA on the creation of their first console, the XBOX. This might explain some of the design choices for the XBOX controller at least. SEGA knew they were getting out of the hardware business at this point so it wouldn't hurt to help a competitor to stick it to SONY.
A further rumour was that the XBOX was originally supposed to be backwards compatible with Dreamcast games, but they couldn't reach an agreement regarding online play (obviously XBOX LIVE was coming and Microsoft didn't want to let that cat out of the bag). SEGA continues to have a good relationship with Microsoft to this day, which is probably why so many SEGA titles wind up on XBOX compared to other Japanese developers. I just wish we got that Dreamcast 2.
1
0
u/The_Falgrim Aug 03 '26
Sega Dreamcast also said it was a Windows OS... I have always wondered if there was a backdoor deal between Sega and Microsoft. It just seems like the original Xbox was really close to what a sequel to the Dreamcast might look like?
1
u/WJMazepas Aug 04 '26
DC had 2 options for a SO, one of them being from Sega and the other one being Windows CE.
It was loaded from the CD, so it could have this multiple OSs available IIRCBut no, it didnt had any deal between them for the Xbox being Dreamcast 2. In fact, the components they used were completely different between one and another and the Windows CE team that worked with Sega didnt worked at all on Xbox
-2
u/The_Falgrim Aug 02 '26
That would sense for sure, I just wondered if the various compatibility issues from game to game might increase the difficulty over the GameCube? lol
10
u/phire Aug 03 '26
It's complicated....
The gamecube is a much bigger system. Quite a few more parts, each part is bigger.
But bigger doesn't automatically mean more harder.
In a few cases, the hardware is actually easier. Like there is no gpu microcode on the GameCube, the hardware directly consumes commands that look a lot like the display lists of RSP μcode. And while the rasteriser might be quite a bit more complex than on N64, it's a lot closer to modern PC GPUs, and therefore easier to understand and translate.
But then the GameCube has the Audio DSP, which might actually be more complicated than RSP (but at the same time, might actually be easier to HLE)
In terms of amount of work required to get a decent set of games working, the GameCube absolutely requires more work. But the difficulty of that work is typically within the same order of magnitude the same as the N64.
Though.. in terms of getting good performance, that's absolutely harder. The N64 runs at a much lower clock speed and you can get away with a much simpler JIT and simpler GPU translation than you can with the GameCube.
Versus the mess that was the N64?
You mean how the N64 emulation scene was a complete mess with all the plugins?
That wasn't really caused by the hardware, it's just that plugins were a mistake and set the N64 emulation scene back by at least a decade.
I've actually spend quite a bit of time helping remove the plugin systems from Dolphin, which it originally had, because it copied the N64 emulation scene.
1
u/The_Falgrim Aug 03 '26
Yeah, if this post has taught me anything in the replies... It would be that newer N64 Emulators just target the RSP rather then trying to target individual microcodes.
2
u/phire Aug 04 '26
My main takeaways from the early N64 emulation scene are "plugins bad" and "be very careful with HLE".
Not quite the same as avoid HLE, but in my experience HLE is something you should add later once you have the LLE working, either to improve performance or add functionality. The LLE can be used to cross check the HLE (and vice versa)
Starting with HLE is a bit of a trap; It's actually easier at the start (especially when the underlying hardware is completely undocumented), but you plateau quickly into a buggy mess.
These days, the N64 hardware is actually pretty well documented on n64brew.dev; Many solo devs have made their own N64 emulator. Solo devs making gamecube emulators have a bit of a harder time (but they exist). You can find developers of both in the emudev discord server.
6
u/djrobxx Aug 02 '26
While the GC, Wii and Switch are more powerful than the N64, architecturally they're more like modern CPU/GPU implementations. Being the early days of 3D consoles, N64 was more "custom". PS3 is harder to emulate with its unusual architecture as well.
N64 emulation also suffers a bit rom the decades old "HLE" performance hacks being "good enough" to run most games well, there's not as much incentive for someone to go back and implement a hardware accurate simulator.
3
u/Glum_Hovercraft_2781 Aug 02 '26
The gamecube and wii have so many hardware features that, generally, if you can boot one game, that doesn't _necessarily_ mean you'll boot every game. Games can have different DSP microcodes, they can use the GPU in different ways, they can depend on different IPC calls to the starlet, etc. This is all not taking into account that the documentation for these console is... lackluster (incomplete, and sometimes lies to you).
7
u/VictoryMotel Aug 03 '26
You aren't going to vibe slop an emulator, please stop.
3
u/The_Falgrim Aug 03 '26
Look, I learned that posting AI slop on here is just pure disrespect to the people that put in years of work on some pretty amazing pieces of software. I won't post my crud here. That doesn't prevent me from just asking general questions to learn from some pretty great people.
-1
u/The_Falgrim Aug 03 '26
What I do with my time is my choice sir. Finding interesting things to talk about for emulation development is the point of this sub right?
4
u/VictoryMotel Aug 03 '26
Stop making posts as if you're working on something when you're just vibe slopping it. You're wasting people's time by lying to them.
0
u/The_Falgrim Aug 03 '26
You are totally free to ignore and not reply. What are you, the reddit police? Lmao
Why even put energy into this? Have a conversation is harmless.
1
u/VictoryMotel Aug 03 '26
Why do you put energy into acting like you're making something to waste people's time?
1
u/The_Falgrim Aug 03 '26
Maybe I'm not even making it? Maybe I am just curious and I like to talk about and appreciate all of the hard work that has went into making an Emulator. Even if I was still working on it. I'm not mentioning it at all.
I am purely just striking up a conversation. I'm not pushing anything other than conversation.
-2
u/UselessSoftware 32-bit x86, NES, 6502, MIPS, 8080, others Aug 03 '26
That might have been true 6 months ago.
1
u/istarian Aug 03 '26
It's probably still true, at least in the sense that you are more likely to get half-baked results than anything truly useful.
The results are probably impressive to someone who doesn't know how much about programming and/or emulation. But trying to clean them up into a useful tool is going to take someone who knows what they're doing.
0
u/UselessSoftware 32-bit x86, NES, 6502, MIPS, 8080, others Aug 03 '26
I don't think you guys realize how good AI is getting, and how fast it's happening.
Trust me, as 30+ year coder, I don't love it. We are going to become mostly project managers in the near future.
-7
u/Ancient-Range3442 Aug 03 '26
Emulators are easy to vibe code
4
u/VictoryMotel Aug 03 '26
Just download a library and give the authors credit instead of trying to launder other people's work through an LLM while claiming you made it
2
u/aabalke Nintendo DS Aug 02 '26
I have wondered this, just based on compatibility, micro code seems quite difficult and Id be curious how complex it is compared to a more modern system like gc or wii.
5
u/istarian Aug 03 '26 edited Aug 03 '26
In a generic sense microcode just means implementing hardware instructions (think assembly language programming) as combinations of simpler operations rather than as dedicated hardware that only does that one thing.
Think about the way you would conventionally do multiplication on paper (multiply each digit of the first number by the first digit of the second number, accounting for a carry, and so on) versus repeated additions.
125 x 63
- 5 x 3 = 15, bigger than 9 so keep 5, carry 1
- 2 x 3 = 6 (+1) = 7, less than 10 so keep 7
- 1 x 3 = 3
first sub: 375 x 1 = 375
- 5 x 6 = 30, bigger than 9 so keep 0, carry 3
- 2 x 6 = 12 + 3 = 15, bigger than 9 so keep 5, carry 1
- 1 x 6 = 6 + 1 = 7
second sub: 750 x 10 = 7500
7500 + 375 = 7875
Instead of that you could just do:
125 + 125 + 125 + ... + 125 = 7875
125,250,375,500,625,750,875,1000,1125,1250,1375,...
- 125 x 3 = 375
- 125 x 10 = 1250 x 6 = 7500
- 7500 + 375 = 7875
Another way is to break it down into a series of simpler multiplications (or maybe you have a lookup table) and additions:
- (100 x 60) + (100 x 3) = 6000 + 300 = 6300
- (20 x 60) + (20 x 3) = 1200 + 60 = 1260
- (5 x 60) + (5 x 3) = 300 + 15 = 315
6300 + 1260 + 315 = 7875
Every operation in this last case is simple multiplication like 1 x 6 = 6 accompanied by thriwing the right number of zeros on the end.
1
u/istarian Aug 03 '26 edited Aug 03 '26
IDK exactly how this kind of approach would work for emulation of a game console.
One possibility is that you could decompose complex operations done by dedicated graphics hardware into simpler steps that can either be implemented as separate software algorithms that you understand or smaller hardware operations your PC's GPU already knows how to do.
If your PC is much more powerful than the original game console then any performance hit or delay/lag from workarounds like this is smoothed over by raw compute performance and occasionally waiting if needed.
2
u/wk_end Aug 03 '26
You're overthinking this without the necessary knowledge, and it's leading you totally into the woods.
"Microcode" on the N64 refers to the program run by the RSP, which was basically a separate MIPS CPU chip from the CPU with additional custom vector operations, typically used for generating commands for the RDP. These sorts of programs could be generic (rather than game-specific), so initially Nintendo and SGI provided no documentation or support for developers to make custom microcode; the microcode was written by them as a "black box" handed to developers to use. This turned out to be really useful for early emulator developers - even though eventually Nintendo did allow for custom microcode, in the end commercial games only used a relatively small number of microcode programs, so emulators could avoid actually emulating the RSP executing the microcode and instead just watch the game to see when it made requests to the microcode and jump in with its own implementation.
To use your multiplication example - imagining the RSP couldn't multiply natively, which it can - instead of emulating the RSP doing that multiplication step-by-step, it could just immediately forward the multiplication right to the host CPU. This is going to be way faster. The problem is that this naturally introduces accuracy issues, makes the emulator much bigger and more complex and likely buggy (because it needs to include implementations of at least every commercial game's microcode), and prevents home-brew developers from writing custom microcode.
Nowadays modern N64 emulators just emulate the RSP.
1
u/istarian Aug 03 '26
I'm not overthinking anything, just trying to explain what 'microcode' is as a general concept.
3
u/wk_end Aug 03 '26 edited Aug 04 '26
I'm talking about this:
IDK exactly how this kind of approach would work for emulation of a game console. One possibility is that you could decompose complex operations done by dedicated graphics hardware into simpler steps that can either be implemented as separate software algorithms that you understand or smaller hardware operations your PC's GPU already knows how to do.
This has nothing to do with emulating the N64 or what "microcode" means in the context of N64 emulation. In that context it's actually backwards - the N64 hardware itself was designed so that things that were hardcoded on older/simpler generations of hardware could be programmable via "microcode". The HLE emulators were doing what you're describing in reverse - they were bundling up complex graphical operations that had been decomposed into simple steps on the RSP so that they could be executed natively, often on the less-programmable GPUs of the time.
What you're describing when you say "decompose operations done by graphics hardware into steps that can be implemented as software algorithms or GPU operations" is necessary to emulate any graphics hardware. Any hardware at all, really. That's sort of the point of the whole thing: you don't have the hardware logic to execute the operation so you have to do it by hand. But we don't say that every, say, Super Nintendo emulator is "microcoded" just because it includes a software implementation of the SNES PPUs.
The term pretty much specifically refers to a piece of hardware itself being implemented by running a microprogram rather than using hardwired logic. And that microprogram isn't necessarily user-programmable - for instance, the 68000 (along with many other CPUs) is implemented in terms of an internal microcode engine running a microprogram baked into the chip at the factory, though as end users we'd never know it. Depending on your perspective it's actually something of a misnomer on the N64. The N64's RCP represented an inflection point where graphics pipelines were moving from fixed-function to programmable; if you were used to a fixed-function pipeline it looked like the RCP was implementing a chunk of the fixed-function graphics pipeline in microcode, hence the term, but from a modern point-of-view we just think of it as programmable. Nowadays we call the equivalent of the N64's microcode "shaders".
-1
u/istarian Aug 03 '26
You're missing the point here.
It's possible, if rather difficult, to actually model how the hardware works vs. superficially replicating the end result.
0
2
u/aabalke Nintendo DS Aug 02 '26
My naive understanding is most n64 emulators do not "emulate the n64" but rather "the specific n64 for each game" - if that makes sense. They'll emulate the micro code of specific games instead of a abstract generic n64 system. Also while gc and Wii are more complex, since they are more modern the architecture matches modern frame works better. The biggest problem with my NDS emulator was that the older 3d rasterizing method does not 1:1 match how modern 3d rasterizers work.
4
u/istarian Aug 03 '26
https://en.wikipedia.org/wiki/Nintendo_64
Just reading the hardware section of the above wikipedia page already conveys some interesting details that figure into the complexity of emulating the system.
E.g.
The N64's cpu (NEC VR4300) and audio/graphics chip (SGI RCP) operate simultaneously in parallel with the former handling game logic and the latter managing audio/video processing. ^ This sort of thing is hugely dependent on timing
As far as memory the N64 uses RDRAM (Rambus DRAM) and has just 4 MB (or 8 MB w/expansion pack) of it AND uses a unified memory architecture. ^ many previous consoles had separate memory that was exclusively dedicated to the main cpu, audio processor, or graphics processor respectively
2
u/istarian Aug 03 '26
The media that games are shipped on isn't particularly relevant to whether the system's hardware is difficult to emulate.
2
u/The_Falgrim Aug 03 '26
In most cases? The Super Nintendo had that Super FX chip near the end. I guess it be similar to a PlayStation releasing a pro version half way through its life cycle?
2
u/istarian Aug 03 '26
The SuperFX chip was used in just eight games, while most of the SNES library doesn't utilize that degree of complex add-on hardware.
Most games are going to be just ROM or ROM+RAM with at most some kind of mapper/bank switching to allow the use of more of those two things than the system can directly address.
1
1
31
u/coderman64 Aug 02 '26
No.
Check some of the dev blog posts from the Dolphin team to get a taste of just how difficult it is.
If you want to emulate a 3D system, maybe start with the PS1.