[HN Gopher] Introduction to Nintendo DS Programming
___________________________________________________________________
Introduction to Nintendo DS Programming
Author : medbar
Score : 202 points
Date : 2026-04-08 05:22 UTC (1 days ago)
(HTM) web link (www.patater.com)
(TXT) w3m dump (www.patater.com)
| Gigachad wrote:
| 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.
| msk-lywenn wrote:
| 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
| extraduder_ire wrote:
| 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/
| NewsaHackO wrote:
| 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.
| HelloUsername wrote:
| (2008)
| stratts wrote:
| 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.
| voidUpdate wrote:
| 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
| SilentEditor wrote:
| 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
| shmolyneaux wrote:
| If you want an architectural overview of the DS, this is a
| fantastic overview:
| https://www.copetti.org/writings/consoles/nintendo-ds/
| supliminal wrote:
| Next up: getting cheetah running. DS X. Lets go
| spicyjpeg wrote:
| 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
| dmitrygr wrote:
| This is going to be user useful for me in a few weeks as I
| bring up PalmOS 5 on Playstation One. Thanks.
| corysama wrote:
| 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.
| gjsman-1000 wrote:
| 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.
| mid-kid wrote:
| 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.
| wk_end wrote:
| 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 wrote:
| 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.
| exitb wrote:
| There are also drop-in replacements for the unlit screens
| of genuine units.
| wk_end wrote:
| 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.
| daneel_w wrote:
| 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 wrote:
| 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.
| TuxSH wrote:
| 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.
| crims0n wrote:
| 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.
| kerochord wrote:
| 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 wrote:
| 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.
| Jiro wrote:
| 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-... .
| medbar wrote:
| 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.
| cunidev wrote:
| 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.
| poffdeluxe wrote:
| Howdy to all the people from #dsdev back in the day!
| bashmelek wrote:
| 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.
| HoppyHaus wrote:
| 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...
| TuxSH wrote:
| 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.
| ex-aws-dude wrote:
| 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 wrote:
| Over wifi. But you have to setup your app to get back to the
| launcher. And also when it crashes. Or just restart it
| Razengan wrote:
| 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)
| Uncorrelated wrote:
| 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.
| dragontamer wrote:
| 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 wrote:
| 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.
|
| See https://en.wikipedia.org/wiki/ARM7#ARM7TDMI and
| https://onlinedocs.microchip.com/oxy/GUID-B822915F-C375-4172...
| Dwedit wrote:
| ARMv7 and ARM7 look very similar, but ARM7 is ARMv3, and ARM9
| is ARMv4. Similar names are very misleading here.
| nimish wrote:
| I remember writing a little screensaver for the NDS. Got me into
| programming in a way
___________________________________________________________________
(page generated 2026-04-09 23:00 UTC)