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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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?
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)
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.
[1]: https://www.lnh-team.org/
[2]: https://blocksds.skylyrac.net/
[3]: https://www.pouet.net/prod.php?which=105928
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.
0: https://www.patater.com/manual-git/
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.
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.
[1]: https://github.com/spicyjpeg/ps1-bare-metal
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.
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.
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.
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.
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.
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.
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.
There are also drop-in replacements for the unlit screens of genuine units.
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.
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.
If you want an architectural overview of the DS, this is a fantastic overview: https://www.copetti.org/writings/consoles/nintendo-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
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.
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.
3DS programming is even easier! * Run through https://3ds.hacks.guide/ * Set up devkitpro: https://devkitpro.org/wiki/Getting_Started * Probably start from an example here: https://github.com/devkitpro/3ds-examples * Then you don't even need to transfer your built file, 3dslink can boot it over the network: https://github.com/devkitPro/3ds-hbmenu?tab=readme-ov-file#n...
Howdy to all the people from #dsdev back in the day!
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.
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?
Over wifi. But you have to setup your app to get back to the launcher. And also when it crashes. Or just restart it
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.
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
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.
This should have a (2008) on it.
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-... .
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.
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
Next up: getting cheetah running. DS X. Lets go
(2008)
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)
Seems like you’re describing something like Pico-8: https://www.lexaloffle.com/pico-8.php
There are also open-source versions of the concept, like TIC-80.
The only thing missing is upgradability.