Great resource! But a lot of it is very old. I recently discovered this open source ds cart[1] and an alternative SDK[2] to devkitPro. Both were used in the development of a demo[3] released at Revision this year.
Even the version linked to is out of date. The homepage links to a version of this guide[0] updated as recently as 2024. Still likely not the best place to get started.
Yea, the link really should be switched to this. Has a much more modern feel, hell as I was reading the OP the reason why I opened the comments was to see if someone commented on how dated the UI was.
medbar 17 hours ago [-]
I don't have an issue with the style personally. I actually like being able to navigate the whole page without clicking through pages. Looks like the content is the same too? Although that's just a glance comparing random snippets.
spicyjpeg 1 days ago [-]
In case anybody here is interested, a few years ago I put together a similar (albeit far less comprehensive) resource on original PlayStation programming [1], exploring the GPU, geometry coprocessor and serial I/O hardware step-by-step with plain C examples. I'm planning to extend it with more examples covering audio and CD-ROM access next, but haven't yet had the chance to do so.
Wow, that's really neat! Looking forward to your writeup.
corysama 1 days ago [-]
I’d bet the DS is the most advanced game console where it is still possible for a person to productively program it entirely via the bare metal memory map. As in: using an “SDK” that’s just a C header full of struct and array definitions at magic fixed addresses and no functions at all. Set values and the hardware does stuff.
mid-kid 1 days ago [-]
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 1 days ago [-]
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 1 days ago [-]
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 20 hours ago [-]
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 20 hours ago [-]
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.
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 20 hours ago [-]
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 1 days ago [-]
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 1 days ago [-]
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 1 days ago [-]
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 1 days ago [-]
There are also drop-in replacements for the unlit screens of genuine units.
pezezin 15 hours ago [-]
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.
Charon77 19 hours ago [-]
I think 3ds is also reasonably in the sweet spot.
Check out this project, fully written in bare metal C
Probably? Everything else onward relies on libraries...
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.
5- 21 hours ago [-]
all of game boy advance and nintendo ds hardware is exhaustively documented in a single text file:
(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.
medbar 17 hours ago [-]
Whoah, this is great! Thanks for sharing
cunidev 1 days ago [-]
The Nintendo DS is the platform that taught me programming around 2010, via devkitPro, and it really let me understand a lot about how computers work. It was a rough ecosystem back in the day, but a very exciting one. We had no internet connection at home but I had the docs downloaded and it was surprisingly satisfying to compile on.
medbar 16 hours ago [-]
Just getting into homebrewing / jailbreaking old handhelds and consoles, and I really do feel like I missed a golden age of hacking that I would have loved. That said, I don't know if the tenacity I had back then would be enough to endure the steeper learning curve. Still, I would have loved to see my own work running on my DS.
I will always be grateful that my CS Operative Systems course 'lab classes' introduced assembly and computer architecture with assignments around writing programs for the NDS. It was fun to see our childhood consoles run low-level programs written by us.
were about writing a program for the NDS
jdwithit 1 days ago [-]
That sounds really cool! My CS curriculum had one class where we had to read and write assembly (targeting an emulator for some Motorola chip I don't recall). It was fine but writing something that ran on an actual game console would have REALLY hooked me I'm sure. Instead we got that one little taste of low level development and then went back to writing sort algorithms in Java. This was in the early 2000s fwiw.
stratts 1 days ago [-]
Making homebrew for the Nintendo DS was how I got into programming in the first place. Devkitpro was too confusing for me back then, so I used something called PALib, essentially a pretty hacky library built on top to make it "easy".
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.
poffdeluxe 1 days ago [-]
Howdy to all the people from #dsdev back in the day!
bashmelek 1 days ago [-]
I have an old 3DS. Does anyone know if would these techniques, including the Slot-1 devices, also apply? I would like to try this out.
My only hesitation is the firmware update—-I simply prefer to keep my devices without changes like that.
You can of course run DS (and GBA) software on 3DS.
> 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.
seabass-labrax 19 hours ago [-]
Luma3DS and the community around it is excellent; thank you TuxSH! Your community provides better software and better support than Nintendo does with all their trillion-Yen revenue available to them; you deserve to be proud of that achievement.
TuxSH 4 hours ago [-]
You're welcome!
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.
Gigachad 1 days ago [-]
I had a go at setting up the devkitpro stuff and building a demo that I run on my DS. It’s surprisingly easy to do and kinda neat.
voidUpdate 1 days ago [-]
This is exactly what I've been looking for recently. Me and my partner have gotten into reshelling and jailbreaking old handhelds, and we both have DSis that we enjoy, and I've been thinking of homebrewing some stuff for us
dragontamer 24 hours ago [-]
Note: arm32 / ARMv7 embedded boards produced in the 2020+ era still exist (see SAM9x60).
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.
ConfuSomu 23 hours ago [-]
Indeed, and for more clarification, as Arm's naming scheme easily causes confusion :
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.
ARMv7 and ARM7 look very similar, but ARM7 is ARMv3, and ARM9 is ARMv4. Similar names are very misleading here.
SilentEditor 1 days ago [-]
Damn this is some legit information. I've looked around for some more recent information regarding modding and shelling, any tips other than the ones listed below?
Thx
crims0n 1 days ago [-]
Man this brings back memories. The homebrew scene around the DS and PSP was so lively circa 2005/2006, and it solidified my burgeoning interest in programming.
ex-aws-dude 1 days ago [-]
Anyone know is there a way to automatically copy over and launch the game on the DS without having to swap cards back and forth?
msk-lywenn 1 days ago [-]
Over wifi. But you have to setup your app to get back to the launcher. And also when it crashes. Or just restart it
Despite the timestamp, I originally uploaded this a day ago and can no longer edit the title. My bad! I didn’t notice how dated the page was until it was too late. Thanks for the link, I’ve been mulling over getting a DSPico to tinker on my old DS.
nimish 22 hours ago [-]
I remember writing a little screensaver for the NDS. Got me into programming in a way
HelloUsername 1 days ago [-]
(2008)
SilentM68 18 hours ago [-]
Great Info. :)
Learning resources for Nintendo Systems are not, generally, easy to find at least for me.
supliminal 1 days ago [-]
Next up: getting cheetah running. DS X. Lets go
Razengan 1 days ago [-]
It'd be cool to have a new modern retro system that embraces the spirit of the early "computer consoles" like the Commodore 64 while adding all modern conveniences:
• 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)
[1]: https://www.lnh-team.org/
[2]: https://blocksds.skylyrac.net/
[3]: https://www.pouet.net/prod.php?which=105928
0: https://www.patater.com/manual-git/
[1]: https://github.com/spicyjpeg/ps1-bare-metal
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.
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.
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.
Check out this project, fully written in bare metal C
https://github.com/profi200/open_agb_firm
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.
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
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.
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...
Thx
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-... .
Learning resources for Nintendo Systems are not, generally, easy to find at least for me.
• 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/
1. https://www.thebyteattic.com/p/agon.html
2. https://mega65.org/
3. https://uzebox.org/
4. https://wildbitscomputing.com/
i miss jaeden. i hope he's well