alt.hn

4/8/2026 at 5:22:42 AM

Introduction to Nintendo DS Programming

 https://www.patater.com/files/projects/manual/manual.html

by medbar

4/9/2026 at 12:34:15 PM

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

by msk-lywenn

4/9/2026 at 7:25:29 PM

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/

by extraduder_ire

4/9/2026 at 7:30:57 PM

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.

by NewsaHackO

4/10/2026 at 3:56:28 AM

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.

by medbar

4/9/2026 at 2:13:45 PM

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

by spicyjpeg

4/9/2026 at 9:09:16 PM

This is going to be user useful for me in a few weeks as I bring up PalmOS 5 on Playstation One. Thanks.

by dmitrygr

4/9/2026 at 2:27:51 PM

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.

by corysama

4/9/2026 at 5:46:18 PM

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.

by mid-kid

4/9/2026 at 6:32:55 PM

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.

by daneel_w

4/9/2026 at 7:07:15 PM

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.

by mid-kid

4/10/2026 at 12:16:29 AM

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.

by emptybits

4/10/2026 at 12:37:14 AM

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.

This comment explains it better than I could: https://news.ycombinator.com/item?id=47708201

by mid-kid

4/9/2026 at 8:45:27 PM

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.

by TuxSH

4/10/2026 at 12:25:27 AM

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.

by mid-kid

4/9/2026 at 6:26:50 PM

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.

by wk_end

4/10/2026 at 5:09:07 AM

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.

by pezezin

4/9/2026 at 6:37:33 PM

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.

by Karrot_Kream

4/9/2026 at 7:02:36 PM

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.

by wk_end

4/9/2026 at 6:56:11 PM

There are also drop-in replacements for the unlit screens of genuine units.

by exitb

4/9/2026 at 3:24:24 PM

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.

by gjsman-1000

4/9/2026 at 11:22:56 PM

all of game boy advance and nintendo ds hardware is exhaustively documented in a single text file:

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.

by 5-

4/10/2026 at 3:58:22 AM

Whoah, this is great! Thanks for sharing

by medbar

4/9/2026 at 4:15:55 PM

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.

by cunidev

4/10/2026 at 4:01:45 AM

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.

by medbar

4/9/2026 at 3:01:39 PM

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

by kerochord

4/9/2026 at 4:27:20 PM

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.

by jdwithit

4/9/2026 at 1:17:24 PM

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.

by stratts

4/9/2026 at 4:28:32 PM

Howdy to all the people from #dsdev back in the day!

by poffdeluxe

4/9/2026 at 4:40:45 PM

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.

by bashmelek

4/9/2026 at 9:08:19 PM

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.

by TuxSH

4/10/2026 at 1:25:43 AM

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.

by seabass-labrax

4/9/2026 at 11:47:49 AM

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.

by Gigachad

4/9/2026 at 8:34:16 PM

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.

by dragontamer

4/9/2026 at 9:43:06 PM

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...

by ConfuSomu

4/9/2026 at 10:05:56 PM

ARMv7 and ARM7 look very similar, but ARM7 is ARMv3, and ARM9 is ARMv4. Similar names are very misleading here.

by Dwedit

4/9/2026 at 1:33:41 PM

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

by voidUpdate

4/9/2026 at 1:41:44 PM

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

by SilentEditor

4/9/2026 at 10:35:41 PM

I remember writing a little screensaver for the NDS. Got me into programming in a way

by nimish

4/9/2026 at 2:48:41 PM

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.

by crims0n

4/9/2026 at 5:43:41 PM

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?

by ex-aws-dude

4/9/2026 at 6:09:56 PM

Over wifi. But you have to setup your app to get back to the launcher. And also when it crashes. Or just restart it

by msk-lywenn

4/9/2026 at 3:29:18 PM

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-... .

by Jiro

4/9/2026 at 3:40:12 PM

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.

by medbar

4/10/2026 at 2:18:00 AM

Great Info. :)

Learning resources for Nintendo Systems are not, generally, easy to find at least for me.

by SilentM68

4/9/2026 at 1:03:31 PM

(2008)

by HelloUsername

4/9/2026 at 5:55:14 PM

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)

by Razengan

4/9/2026 at 6:14:55 PM

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.

by Uncorrelated

4/9/2026 at 2:12:28 PM

Next up: getting cheetah running. DS X. Lets go

by supliminal

4/9/2026 at 11:49:35 PM

holy shit, how am i the first person in the thanks list? half that list deserves it more than i do, especially dave, liran, and jason

i miss jaeden. i hope he's well

by JohnHaugeland