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.
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.
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’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, in many ways similar to and built upon the SNES' foundation.
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.
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.
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.
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)
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?
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.
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
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
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’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, in many ways similar to and built upon the SNES' foundation.
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.
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.
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...
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.
Howdy to all the people from #dsdev back in the day!
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
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
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.
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.
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.
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
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.
Next up: getting cheetah running. DS X. Lets go
(2008)