Introduction to Nintendo DS Programming
patater.com
patater.com
[1]: https://www.lnh-team.org/
Though there were some fits and starts there. The N64 for example is, from what I've heard, heavily library dependent and absolutely brutal to program bare metal (GPU "microcode" that was almost like programmable shaders v0.1); even the GameCube is a significant improvement for that kind of thing.
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.
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.
None of this fixes the audio, but it sure gets damn close.
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.
This comment explains it better than I could: https://news.ycombinator.com/item?id=47708201
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.
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.
Check out this project, fully written in bare metal C
https://problemkaputt.de/gbatek.txt
(but you can replace txt with htm for a fancier version)
this ranges from physical description to compact arm instruction set reference -- you really only need this document (and a way to get your console to run your code!) to program completely from scratch.
i've picked up a dsi because it can load code from an sd card, so only the console, an sd card and a computer is required for programming it, but see https://news.ycombinator.com/item?id=47706877 further down this thread for the case for preferring the gba.
were about writing a program for the NDS
There is no reason to use a slot 2 cart nowadays and the state of the art for a slot 1 cart is the DSPico at https://gbatemp.net/threads/dspico-an-open-source-flashcart-... .
Nice community at the time though, I made a pong clone where the main selling point was that you could switch between different "themes", and a bunch of people contributed some really nice custom ones to be included.
My only hesitation is the firmware update—-I simply prefer to keep my devices without changes like that.
> My only hesitation is the firmware update
If you "hack" your 3DS you will not have to worry about sysupdates anymore. It is slightly more straightforward to do so if your system version is <= 11.14, and quite trivial if <= 11.3.
As for homebrew dev on 3DS, you have a lot more RAM and a "proper" CPU with somewhat modern CPU concepts (an actual OS, virtual memory, caches, multicore).
Unlike the DS and GBA, the 3DS has an actual GPU (well, kinda, it doesn't have programmable fragment shaders), which was designed around a custom flavor of OpenGL ES and it shows; citro3d is a shim, other than stateful state tracking and mem allocation, it mostly exposes the GPU hw as-is.
Overall, I think it is easier for people to get started with 3DS homebrew development and that it provides more transferable skills (w/r/t OpenGL-like APIs).
Disclaimer: I'm the lead maintainer of Luma3DS, am a core maintainer of libctru, and wrote significant parts of the exploit chains the guide uses. Feel free to ask around.
By the way, I have something related rather large in the works, look forward for a "Show HN" ;) (hopefully this quarter!)
> better support than Nintendo does with all their trillion-Yen revenue available to them
Well, they had to develop the entire OS, all GUI applications and SDK (and docs, and tooling...). It would also be far from surprising if they moved significant headcount to developing the Switch after the 3DS launched (and considering the Wii U's apparent failure).
There have been traces of Switch 2 stuff in Switch 1 kernel 3 years (?) before the S2 launched, so, in terms of planning, this tracks.
• Everybody has the same system (devs need to target only 1 environment)
• Boot straight into a programming environment
• Limited OUTPUT that enhances creativity without the internal limitations that hinder creativity: Like a limited numbers of colors, but no bitplane crap or having to do sprite multiplexing etc
• Online, ungated app store where anybody can publish, like itch.io
• Reasonable upgradability (not so much as to defeat point #1)
There are also open-source versions of the concept, like TIC-80.
The only thing missing is upgradability.
There are also hardware-based efforts, like BoxLambda[0], Agon[1], MEGA65[2], Uzebox[3], F256[4].
0. https://epsilon537.github.io/boxlambda/
In case anyone wants to keep the ARM9 assembly/core but also wants modern Linux 6.12 support.
The Nintendo DS was a complete package though: screen, buttons, sound, etc. etc. But I'm still amused at the long term life of embedded programming and how ARM9 cores with ARMv7 assembly still is in production today.
ARMv7 and ARMv4, used by the ARM7TDMI processor core in the GBA, NDS and 3DS, are not the same instruction sets. You can indeed find processor cores in recent microcontrollers/SoCs implementing Armv7 or Armv7-M.
The SAM9x60 has an ARM926 core, which implements the Armv5TEJ instruction set, similar to the DS' ARMv5TE instruction set implemented by its ARM946 core. The former has Jazelle while the latter doesn't.
See https://en.wikipedia.org/wiki/ARM7#ARM7TDMI and https://onlinedocs.microchip.com/oxy/GUID-B822915F-C375-4172...
Learning resources for Nintendo Systems are not, generally, easy to find at least for me.
i miss jaeden. i hope he's well