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.
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.
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.
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.
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.
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.
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.
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.
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.
(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.
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.
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.
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.
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.
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.
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.
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 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.
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
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)
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.
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.
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?
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.
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.
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.
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
This is going to be user useful for me in a few weeks as I bring up PalmOS 5 on Playstation One. Thanks.
Did you port PalmOS 5 to MIPS somehow?
I did, yes: https://x.com/dmitrygr/status/2042036163335041305
Wow, that's really neat! Looking forward to your writeup.
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.
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.
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
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.
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.
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.
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.
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 think 3ds is also reasonably in the sweet spot.
Check out this project, fully written in bare metal C
https://github.com/profi200/open_agb_firm
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.
Whoah, this is great! Thanks for sharing
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.
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
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.
If you want an architectural overview of the DS, this is a fantastic overview: https://www.copetti.org/writings/consoles/nintendo-ds/
Bookmarked! Awesome, thanks.
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.
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.
Howdy to all the people from #dsdev back in the day!
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...
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.
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.
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.
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
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)
Software-only fantasy consoles are an interesting concept, covered by a sister comment.
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/
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.
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.
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...
ARMv7 and ARM7 look very similar, but ARM7 is ARMv3, and ARM9 is ARMv4. Similar names are very misleading here.
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
Great Info. :)
Learning resources for Nintendo Systems are not, generally, easy to find at least for me.
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.
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 remember writing a little screensaver for the NDS. Got me into programming in a way
(2008)
Next up: getting cheetah running. DS X. Lets go
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