
Architecture of the Nintendo DS - Polylactic_acid
https://www.copetti.org/projects/consoles/nintendo-ds/
======
Jasper_
Fun fact! The Nintendo DS audio chip has a distinctive buzz that's visible in
all audio tips uploaded to YouTube, and you can even hear it on this page! It
comes from.... a bug in the popular DeSMuMe emulator. Yes, it turns out that
the people that designed the "2sf" format used for unofficial music rips
simply used stripped down ROMs and code extracted from a version of DeSMuMe.
Community tooling later allowed you to batch convert them to MP3, and the rest
is history. Line rips recorded from the audio jack of the device don't have
this distinctive buzz. Extra fun when some official soundtrack releases
contain the buzz :)

There's some other fun facts about the DS (its 3D hardware is scan line based,
not frame buffer based! Which means you can't do post processing on it without
some hacky tricks... can you tell it was from the team that made the PPU,
rather than a modern GPU or even an SGI-derived one?), but that one is my
favorite.

Edit: minor correction, the N64 supported AA, which is another reason jagged
polygons are less common.

~~~
mrguyorama
You say in the article that the 3D engine can only display to one screen at a
time, but some games definitely play 3D content on both screens (like Legend
of Zelda Phantom Hourglass). How do you think these games are accomplishing
this?

~~~
Jasper_
I didn't write the article, and I'm not much of an expert on DS graphics (it's
too surreal for me). But you can copy 3D content to 2D images and then display
it using the 2D engine, I believe, and then use 3D on the other screen through
the direct method. Pretty much everything on the DS is a bizarre special case,
and Nintendo's in-house staff is very good at exploiting every last trick in
the book.

~~~
WorldMaker
The article mentions that the Main 2D Engine had a mode that could write to a
framebuffer that was the combined area of both screens, and could pull from
the 3D engine into that full framebuffer layer.

Also, you'll notice in the New Super Mario Bros example that many of the
sprites were pre-rendered 3D and the 2D engine was just pulling bitmaps at
that point.

So a bunch of options with all sorts of interesting trade-offs and it would be
interesting to see breakdowns of specific games and how they used the trade-
offs.

------
swiley
The GBA and NDS are surprisingly pleasant to develop for, especially compared
to smartphones. My first C programs were written for these.

I still can’t believe what that thing was capable of with a honebrew
cartridge. I had dev tools, emulators for old desktop computers, web browsers
and all kinds of stuff on a machine with just 4mb of ram (and this was before
smartphones so being able to have that in your pocket was still niche.)

I thought smartphones would be like homebrew except projects would be
abandoned less often because people could make money with them. I don’t think
I’ve ever been so disappointed in my life.

~~~
jokoon
I have this 4y old Android smartphone which is slow for no good reason. I
tried everything, removing/disabling apps, reset etc.

The problem is that apps are just too big. Tinder is unusable.

I thought I could root it and install a custom Android, but I realize now that
it's not as easy as installing Debian on a desktop.

If you combine capitalism with wirth's law, you end up with expensive hardware
that you cannot use. It's the same problem with JavaScript and web page size.

Everything is bloated.

~~~
Cthulhu_
Not everything; at least early on, iOS apps were great. But over time, on the
one side the developers started adding more and more features, or switched to
web tech or some hybrid technology, convinced that it would save them time and
money (it didn't and the user experience is the worse for it). I also believe
Apple itself added more and more cruft to the system.

One thing my colleague (who was a bit more hardcore than me) was convinced of
is that hand-coding interface code was faster than using Interface Builder. I
want to believe; I can imagine that the IB interface was just an XML file that
had to be read, parsed and its layout built up, whereas handcoded layouts is
very dumb code that would compile easily and execute quickly. But at the same
time, I want to believe Interface Builder would be converted to obj-c code and
compiled as normal.

Anyway Apple had years of head start in terms of performance and user
experience (= perceived speed) to Android, their technology decisions was one
of the reasons.

And yet, thinking about it, it wasn't even as fast as I could be; because of
how objective-C works, function calls are somewhat dynamic so every function
call, the runtime has to look up what to call the function on. Later on (with
Swift) they managed to add an optimization that could omit this check if they
detected the target could not change.

I'm rambling a bit and speaking from memory here btw, take this comment with a
grain of salt. I'm no computer scientist, just a developer.

~~~
saagarjha
Objective-C message sends are ridiculously fast these days, like less than a
handful of nanoseconds on average (1-2 on the fast path). There are ways of
making it go even faster, but Apple has chosen to sully the language by taking
away some of its dynamism instead :( It’s kind of sad to think about how much
the original iPhone could do and how much code goes into the average app these
days in comparison. You’d guess it was assets or something but no, if you look
at major apps these days they have all sorts of framework dependencies with
multi-megabyte binaries. It’s so sad to see…

(And Interface Builder files get compiled to a format that is then read out at
runtime and deserializes the right things.)

------
someperson
I have always wondered if it's possible to run Gameboy Advance games in DS
Mode (and thus access the DS mode hardware) and patch the GBA Link Cable
serial comms to instead use the Nintendo DS's Wi-Fi connection.

Conventional wisdom says it's impossible to run in AGB Compatibility Mode and
retain DS functionality, but I still wonder if it could be done.

Also given the ancient cryptography, I wonder if it's possible to crack DS
Download Play and introduce a new "Wireless Multiboot" exploit that uses real
DS hardware similar to the early exploratory attempts using "NDS WifiMe"
before flashcards become commonplace. The hardware only has ~256 kilobytes of
RAM (and doesn't even use a standard Wi-Fi stack if I recall correctly), but
it would be SUPER COOL from the perspective of getting hardware to do
something never thought possible.

One use-case for this hack I imagine is playing Zelda Four Swords Adventure
played on a Wii / Wii U (via "Nintendont"), with the game patched to use Wi-Fi
for the communication to the Gameboy Advance controllers rather than a Link
Cable. The players won't need to have a flash card each, but could boot up the
payload using DS Download Play on _any_ DS variant (including DSi and 3DS).

~~~
DCKing
> I have always wondered if it's possible to run Gameboy Advance games in DS
> Mode (and thus access the DS mode hardware)

It is! GBARunner2 is a DS homebrew hypervisor that can run (a lot of) GBA
games in DS mode [1]. It can e.g. be used to run GBA games on the Nintendo
DSi, which lacked the GBA slot and AGB mode, or run GBA games directly from a
DS flashcard.

> and patch the GBA Link Cable serial comms to instead use the Nintendo DS's
> Wi-Fi connection.

It isn't - practically at least. There have been attempts and it works as a
proof of concept with special builds of GBARunner2 [2]. Sadly the game logic
in almost all GBA games does not appear to accept the huge added latency for
wireless connections, compared to the almost nonexisting latency for a serial
cable. This is also a problem for GBA emulators like mGBA, which only support
game linking on the same computer and not e.g. on the network [3]. Games made
only for the Link Cable (and not the niche Wireless Adapter) just can't deal
with network latency.

[1]:
[https://wiki.gbatemp.net/wiki/GBARunner2](https://wiki.gbatemp.net/wiki/GBARunner2)
and
[https://github.com/Gericom/GBARunner2](https://github.com/Gericom/GBARunner2)

[2]:
[https://wiki.gbatemp.net/wiki/GBARunner2/Link](https://wiki.gbatemp.net/wiki/GBARunner2/Link)

[3]: [https://github.com/mgba-
emu/mgba/blob/0.8/README.md](https://github.com/mgba-
emu/mgba/blob/0.8/README.md)

~~~
someperson
Very cool, thanks for the links!

Sounds like the easiest way to solve the problem you describe and play
multiplayer Zelda Four Swords Adventure over the internet (without modifying
the code itself) is for the "server" (Gamecube game) and the client (the
Gameboy Advance console) to be physically closeby and then stream the
(emulated) GBA and (emulated) Gamecube video output framebuffer across the
internet using something like the SteamLink so that the 100ms of latency would
not cause the Link Cable to timeout.

~~~
DCKing
Yeah this is going to be very hard to accomplish unfortunately. I'm guessing
the only possible option to do this over the internet at the moment is using
Dolphin and VBA-M on the same machine and some complex streaming setup.
Dolphin supports linking to the VBA-M GBA emulator, and while this link setup
is prone to bugs there are reports it works with Four Swords Adventures [1].

[1]: [https://wiki.dolphin-
emu.org/index.php/The_Legend_of_Zelda:_...](https://wiki.dolphin-
emu.org/index.php/The_Legend_of_Zelda:_Four_Swords_Adventures)

~~~
pR0Ps
It's 100% possible to play with all the emulators running on the same
computer. I worked my way through most of game with multiple players. There
was a little bit of input lag but not too bad (and the game is pretty
forgiving). If you have a couple friends who are into LoZ games I definitely
recommend it.

We also just embraced screen-peeking as everything was up on the same screen
for everyone to see.

[https://i.imgur.com/pnhyEjS.png](https://i.imgur.com/pnhyEjS.png)

It was definitely a bit of a pain to set up each time. Something like a batch
script that automates setting the emulators to a known-good config,
configuring the controls, opening up the emulators, and starting the game
would be possible and would make it a lot easier.

------
johnwalkr
>Considering the new developments in the ARM world, why did Nintendo
ultimately choose an awfully slow ARM9 combined by an even slower ARM7,
instead of a faster ARM9 (or even a StrongARM)?

Nintendo's core philosophy for hardware has always been to use old hardware
and develop one really unique feature with it, especially for its handhelds.
N64 is an exception to this. The also tend to hold on to something from the
previous generation, leading to some pretty strange architectures. They are
fun to read about though, and there's something about this formula that seems
to hold up over time better than the other consoles.

The switch, using an Nvidia SOC is a real departure from this, since it's
using very standard hardware and its main new feature is a kind of convergance
of the Wii U's components. It's a bit sad in a way, but at least Switch gets a
lot more ports than previous generations.

~~~
christkv
I would argue that the Gamecube was pretty state of the art when it came out
and in some ways ahead of its competition at the time.

~~~
DCKing
Nintendo has been state of the art with the Nintendo 64 and GameCube and
probably the Game Boy Advance in the same era. It was an era where - with
clever engineering - you could be on the cutting edge and still sell your
consoles for cheap. With Nintendo, it's always about cost control.

They learned that being on the cutting edge does not help them sell more
hardware or games, as the N64 and especially GameCube sold below expectations.
They have not been on the cutting edge since then - nor were they really
before. The Switch is pretty great because although it was not really on the
cutting edge it had relatively up to date hardware at launch "for Nintendo" \-
especially compared to its 3DS and Wii U predecessors.

~~~
mumblemumble
I remember there being distinct periods where:

\- Genesis was out but we were still mostly playing NES games.

\- Playstation was out but we were still mostly playing SNES games.

\- PSP was out but everyone stuck to GBA.

\- I was on hiatus from video games when Wii happened, but I was aware that
most my friends had one, even if you wouldn't know it, because ps and xbox
were more popular with (the minority of) people who want to talk about video
games all the time.

My guess is that Nintendo has a few key parts of their strategy: More casual
gamers don't actually care about having the best graphics (corollary: more
casual gamers won't spend an extra $100 on better graphics), you need
something that feels new & novel to attract the attention of more casual
gamers and motivate them to buy, and technical constraints foster the kind of
creativity that does that. Perhaps even more so than clever hardware gimmicks.

------
someperson
If you're reading this you may be interested in Wiimmfi [1], which is a re-
implementation of the Nintendo Wi-Fi Connection (WFC) online gaming service
that discontinued on May 20th, 2014. It was the online service used to play
games like Mario Kart DS online.

Wiimmfi is similar to Xbox Live Project Insignia [2], and to a much lesser
extent XLink Kai tunneling for local System Link over the internet. What a
wonderful age we live in!

[1] [https://wiimmfi.de/](https://wiimmfi.de/)

[2]
[https://www.youtube.com/watch?v=5DVKwTtJtS8](https://www.youtube.com/watch?v=5DVKwTtJtS8)

~~~
tech234a
Connecting to Wiimmfi on the DS is surprisingly simple. Thanks to a mistake in
the SSL certificate verification code on the DS [1], all that is needed is
specifying a custom DNS server (164.132.44.106 [2]). The hardest part is
finding an open or WEP hotspot, as most DS games aren't compatible with newer
Wi-Fi security types [3].

[1]: [https://github.com/KaeruTeam/nds-
constraint](https://github.com/KaeruTeam/nds-constraint)

[2]: [https://www.youtube.com/watch?v=Sh0AZR-
tKwM](https://www.youtube.com/watch?v=Sh0AZR-tKwM)

[3]: [https://wii.guide/wiimmfi.html](https://wii.guide/wiimmfi.html)

------
roryokane
This was really cool to read, but I’m disappointed that the section on the
touchscreen didn’t answer something I’ve long wondered about the Nintendo DS:
what was the extent of the touch screen’s multi-touch capability?

My first encounter with the DS’s multi-touch capability was in a homebrew
drawing program, Colors!
([https://www.gamebrew.org/wiki/Colors%21](https://www.gamebrew.org/wiki/Colors%21)):
I noticed that if I touched the screen with my finger at the same time as the
stylus, the brush drew at the midpoint between my finger and the stylus. My
second and last encounter with multi-touch was in the published game _Hotel
Dusk: Room 215_. It had a puzzle where two switches were displayed on the
touch screen, and the solution was to put two fingers on the touch screen and
pull the switches at the same time. I tried dragging with just the stylus at
the midpoint between the switches, and that didn’t activate it: I truly had to
put both fingers on the screen for it to work.

My question: why wasn’t this capability of the Nintendo DS more widely used or
advertised? Was there some technical limitation on the multi-touch feature
that made it only work under certain conditions? Did it require some private
API (that was somehow figured out by a third-party game developer and approved
by Nintendo nonetheless)? Or was the only reason that most players didn’t have
two styli, and developers didn’t want to encourage players to put their dirty
fingers on the touch screen (which was, admittedly, prone to scratching)?

~~~
Polylactic_acid
Thats actually a super interesting question and something that should not be
impossible to work out. The touchscreen is connected to the mobo with a 4 pin
connector. I don't see an IC on it so I assume it must be analogue signals
coming out. I might see if I can work out the way to read data off it and see
if there is an observable difference for multitouch

------
ricksl
Wow this blog has an entire article series in this format with more than a
dozen write-ups. Incredible that I haven't found this site sooner, what a gem!

~~~
someperson
Hopefully the author receives ample support through his Patreon link!

------
corysama
Note that this article is one in a series:
[https://www.copetti.org/projects/consoles/](https://www.copetti.org/projects/consoles/)

------
yc-kraln
One of my first hardware projects was homebrew related for the DS:
[http://kraln.com/passme/](http://kraln.com/passme/)

~~~
dylan-m
I got one of those! Kudos for making them - it got me started on a lot of
things (including reflashing a CPLD with a parallel cable, come to think of
it, although I can't remember why). I ended up flashing my DS's firmware later
on, but I think I still have my PassMe floating around - it's a fun little
memento :)

------
zwirbl
The amount of detail going into all the write-ups on this page is insane,
great work!

~~~
someperson
Hopefully the author receives ample support through his Patreon link!

~~~
otr
username checks out...

~~~
someperson
(For the record, I'm not the author of the blog post)

------
reedf1
It's interesting to have game formats for which emulation does not capture the
magic of the hardware. When the last DS dies how will people play these games
properly?

~~~
jayd16
A portrait touch screen split top/bottom?

~~~
reedf1
Some games even require you to close the screen! I suppose that's one of those
emulation quirks you will just have to live with.

~~~
saagarjha
Yup, that particular gimmick in Phantom Hourglass got me for a couple seconds
before it figured it out. While not at the same level as the traditional
console games, the DS Legend of Zelda games have their own charm :)

~~~
jamesgeck0
That gimmick didn’t even last through the next console generation. Neither the
original 2DS nor the Wii U have folding screens, you have to suspend/activate
the system to get past that part.

------
godot
This is a bit tangential, but the format of the article as well as the visual,
are really pleasant. It's a great combination of font, color, line heights,
text widths, the use of tabbed widgets for specific sections, etc. It's just a
great example of an article on a web site that takes advantage of the media
(being a web site, that can be interactive) but not overdoing it.

Also another tangent, the game showcased in multiple photos there, Hotel Dusk
Room 215, was one of my favorite DS games. I would've thought no one has heard
about it, but here it is in an article about DS architecture. :)

------
SomeoneFromCA
He uses the dated phrase "master-slave" in his post. He should change it to
"leader-follower" /s.

But quite honestly, I think that "leader-follower", politics aside, is plainly
a better term to describe these kinds of configurations.

