[mid-kid]

I'd say the GBA is the sweet spot for this.

The DS has you dealing with two cores you need to write a firmware for that have to communicate to do anything useful, a cartridge protocol to fetch any extra code or assets that wouldn't all fit into RAM at runtime, instruction and data caches, an MMU, ... And that's without mentioning some of the more complex peripherals like the touch screen and wifi.

All official games used the same firmware for one of the cores, a copy of which is embedded into every single cartridge ROM. There's some homebrew firmwares included in the respective SDKs, but they aren't well documented for standalone use.

Granted, all of the above isn't completely impossible, but if you think of how much code you'd need to get a simple demo (button input, sprite moving across the screen), especially for a beginner, the DS requires a nontrivial amount of code and knowledge to get started without an SDK. Meanwhile, you can do something similar in less than 100 lines of ASM/C for GBA.

[daneel_w]

Agreed. I spent a lot of time programming the GBA in the early 2000s (back when the state of the art devkit was a flash cartridge writer with parallel cable...) and I consider it the last "grounded" console that Nintendo made, where you immediately and directly get to touch hardware right off the bat, without any gyrations. After having worked with the SNES in the 90s the GBA was a very familiar and pleasant platform to experience, in many ways similar to and built upon the SNES' foundation.

[mid-kid]

I've never coded for SNES, but the GBA having access to a mainline, modern C compiler is a massive buff. Also, emulators for it have always been available on practically any computer, console and mobile phone, and there's many so-called "emulation handhelds" that bring its (and similar) form-factor handheld devices to the market. If you really need an upgraded OG experience, many upgrade kits for the handheld exist as well.

None of this fixes the audio, but it sure gets damn close.

[emptybits]

Just curious what you mean by "fixing the audio"? In GBA emulation or on the hardware?

I'm aware that if you need/want PCM audio, there's going to be mixing, probably with a software library, and significant CPU use for it. Is emulated GBA audio buggy?

One of my first gigs was Game Boy and Game Gear programming. I know the GBA allows DMG audio compatibility and, with all its constraints, well it sure does keep things simple. And emulation is reliable AFAIK.

[mid-kid]

I see what happened, I was replying to a different comment, that did mention the GBA audio, when I wrote that, but somehow ended up replying to this one.

This comment explains it better than I could: https://news.ycombinator.com/item?id=47708201

[TuxSH]

The DS, more specifically the arm946e-s has an MPU, not a MMU (you're confusing it with the 3DS's Arm11). Not like it makes much of a difference anyway, you configure either once or twice then leave them be.

Honestly, I think why the GBA is more popular than the DS for that kind of thing is because it only has one screen (much less awkward to emulate), has high-quality emulators that are mostly free of bugs (mGBA most notably), and its aspect ratio is better than the DS anyway (3:2 upscales really well on 16:10 devices). That is to say, it's much easier to emulate GBA software on a phone or a Steam Deck than it is to emulate DS software.

[mid-kid]

gah, you're right, I was thinking of memory protection (as in, marking the relevant regions as read-write and read-execute) when I wrote MMU.

It's of course optional, and you can ignore it for trivial examples, but most games and SDKs will tweak it all the time when loading additional code modules from the cartridge.

It's just another way in which the DS is more complex to use properly without an SDK to do this for you - there's just more to think about. At least compared to how the GBA lacks all of this and the entire cartridge is mapped into memory at all times.

[wk_end]

I agree, the GBA is a pleasure to work with. It's just a shame that the poor quality of the (stock) screens, low resolution, and lousy sound hardware make it feel like such a downgrade from the otherwise gnarlier and technically inferior SNES.

[Karrot_Kream]

There's a pretty big renaissance of GBA clones out there right now that put better screens and speakers to the platform. And of course with emulators you can get all the modern hardware affordances for the platform.

[wk_end]

The screen can be improved, but the resolution and sound system can't be.

The issue with the sound isn't just the speakers - you could always use headphones, after all. The GBA only has the original GB's primitive PSG (two square waves, a noise channel, and a short programmable 4-bit waveform) plus two 8-bit PCM channels. 8-bit PCM samples are unavoidably noisy with lots of aliasing, and all sound mixing, sequencing, envelopes, etc. for those channels needs to be done in software, which tends to introduce performance and battery life constraints on quality, channel count, effects, and sample rate.

The SNES, by comparison, uses high-quality 16-bit 32kHz samples, and all the places on the GBA where devs may have had to cut corners are done in hardware: eight separate channels, no need for software mixing, built-in envelopes and delay.

Compare the SNES FFVI soundtrack to the GBA version; the difference is dramatic. Frankly, using high quality speakers or headphones just makes the quality difference more obvious.

[exitb]

There are also drop-in replacements for the unlit screens of genuine units.

[pezezin]

In addition to the screen and the sound, don't forget having just 2 face buttons after 4 buttons had become standard and almost mandatory. Many ports suffer mightily in the control department.