Architecture of the Nintendo DS
copetti.org
copetti.org
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.
So did the DS: http://melonds.kuribo64.net/comments.php?id=32
Oh my. You really can tell this GPU was done by a 2D PPU team.
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.
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.
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.
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.
(And Interface Builder files get compiled to a format that is then read out at runtime and deserializes the right things.)
It always makes me slightly resentful or sad about apps that are collections of web views but somehow 100+ MB.
As an alternative you could root the device and disable (or remove) the bloat in the stock distribution, this often goes a long way towards getting a more usable device. This is what I did on those few devices which I've used on the stock distribution - remove as much bloat as possible, remove all social media cruft, etc. This can lead to surprising results like the battery lasting twice as long and with that giving new life to a tired old device.
Does it use eMMC storage, or is it new enough to be NVMe? Any pre-2016-ish smartphone is built with basically the guts of an SD card (or MultiMediaCard rather) for internal storage and is a ticking time-bomb with a limited number of write cycles. They'll get slower and slower and then eventually stop working completely. My NoteⅡ and then later my NoteⅣ both succumbed to this. I never owned one but I remember the Nexus 7 being especially notorious for dying this way. You can replace those chips with the right equipment but I've never tried.
At least in part, I expect this is because of the AppCompat library that Google recommends using. If you pull in the whole thing, as tutorials show, it adds a huge number of images (icons and such) that don't get trimmed during compilation (which they're supposed to, if unused) - these make up something like 95% of the size of an app I'd recently been working on. I'd only noticed it because this was a rework of one I'd made ~10 years ago, before AppCompat existed.
I can't help but wonder if some of the "optimizations" done by Google when you turn over your keys and let them compile the apk is just removing this extra bloat.
[0]: https://developer.android.com/training/constraint-layout
Basically, I think modern mobile hardware is fine, it's just the software from Google & Apple that makes it often unusable & out of user control.
Thankfully there are people working on that & I'm sure they are looking for contributors. :)
Yes, I know you could play Rogue under an 8mhz-m68k mac perfectly, but bear in mind GBA cartridges and RAM are really tiny.
But hey. On input, I played Nethack under a PSP, underclocked to 25-50MHZ, the battery lasted a week and more.
Now I am trying to test which older machines could run Nethack 3.6.6. I guess a 2MB m68k Mac would be enough.
No, using telnet/ssh is cheating.
NDS development has always been something I wanted to explore. This article provides a nice excuse to get started.
Just to put things in perspective. DS could run a full 3D platformer like Super Mario 64 DS back in 2005 using only 32-bit ARM7 at 34 MHz. New PS5 specs: 8-core Zen 2 at 3.5GHz, 10 TFLOPs GPU, 16 GB GDDR6
Luckily if you play on something like DraStic, you can add AA yourself which looks much better upscaled.
The PDA's have less RAM and they still had browsers and in some cases, even emulators.
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).
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 and https://github.com/Gericom/GBARunner2
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.
[1]: https://wiki.dolphin-emu.org/index.php/The_Legend_of_Zelda:_...
It's a shame so few people get to play that kind of game. It's a very social experience and exactly what the Wii U was intended for.
We also just embraced screen-peeking as everything was up on the same screen for everyone to see.
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.
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.
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.
- 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.
They then bolted that to some pretty good video hardware but again it wasn't the kind of bitmap addressable blitter supported hardware that was out there on more advanced systems. It was still sprite/tile based stuff, with specific hardware support for common character-movement/scrolling/sprite/tile management, basically a more advanced version of what early 80s gaming systems had done.
Comparing it to arcade machines and computers isn't really fair - totally different price points and market segments. But outside of high-end workstations nothing could spit out the kind of visuals the SNES was in 1990. The Amiga 500 was, what, like $500 in 1990? At least double the price? And that could display a mere 32 9-bit colours on-screen, two background layers, no alpha, no scaling or rotation. PCs were starting to come with VGA cards standard, but you'd need to spend at least 10x as much on one to get a CPU that could do much with it. And that's not even getting into the sound hardware!
The 65816 was an unorthodox choice to be sure, but you're doing it a bit of a disservice: it's still a fully 16-bit CPU internally, and even at ~1/2 the MHz the performance delta between it and the 68k is generally overstated (because the 68k is such a cycle hog), especially for the kind of calculations 2D games tend to do.
Anyway - weaker CPU + powerful video hardware (that gets outmodded by home computers within the next two-three years) has been, with few exceptions, the model for high-end game consoles since, well, at least the SNES. It's true of the PS4/XB1, it was true of the Xbox 360 (and the PS3, sort of, the whole Cell thing is complicated), it was true of the GC...CPU is rarely the bottleneck for games, so as a rule console designers don't get too spendy there. Exceptions might be the N64 and the Xbox, although even they had CPUs that could best be described as mid-range for their release dates.
Comparing to PCE and MD is interesting, the differences in capability seem roughly in line with the different release dates. Being first to market doesn't work in the industry and many consoles were skipped by most consumers. These days MS and Sony are synchronized in terms of release dates, and Nintendo does it's own thing, releasing whenever they feel like it.
GC is kind of interesting, it's kind of halfway between the high performance target of N64 and the philosophy of older hardware + something unique.
For what it's worth SNES is my all-time favorite.
I really wanted to say you're wrong ...
but if you look at a 65816 pinout, it does only have 8 data lines and 16 address lines.
Furthermore each instruction is only 8 bits wide,
And if you do look at this SNES schematic https://wiki.superfamicom.org/uploads/snes_schematic_color.p... I'm seeing 8 data lines and 24 address lines.
Never thought of the 65816 as a supercharged 8-bit CPU but looking at it, that's really not far from the mark.
> bitmap addressable blitter supported hardware that was out there on more advanced systems.
In 1991 when the SNES hit the states you had the Genesis, which was also sprite based, and I think the TurboGrafx-16, which was also sprite based. All of your arcade games of the time had those insane CPS-2 like sprite engine. Maybe CDI was out by then, but I don't think that thing had any graphic acceleration.
https://www.blueoceanstrategy.com/teaching-materials/nintend...
I find it refreshing that Nintendo has such strong opinions about these types of things, even when it’s to their detriment.
This philosophy is a part of why their products always feel like “toys” and inspire all the feelings that come along with that.
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://github.com/barronwaffles/dwc_network_server_emulator...
[1]: https://github.com/KaeruTeam/nds-constraint
My first encounter with the DS’s multi-touch capability was in a homebrew drawing program, Colors! (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)?
Many games are very enjoyable with modern touch controls -- Inamuza Eleven for instance.
This has been true for a lot of Square Enix classics.
I do hope there's conservationists out there that have a way to "freeze" hardware like this in time, shield it from any kind of wear, corrosion, and idk, brittling of materials through time.
Checkout the MiSTer [1] [2] an FPGA-based system where the community are trying to create faithful reproductions to the original hardware in Hardware Description Languages (HDLs) like Verilog. This FPGA based approach is NOT emulation in software, but reproduction of the electrical logic of actual silicon like the CPU and DSP chips.
I'll mention flashcards exist, and so do reproduction cartridges (could be called "bootlegs" but the original cartridges are no longer manufactured so if advertised clearly nobody has much issue with reproductions).
That's not even getting into the world of Android-based emulation (and the myriad of phone holders + custom controller type products).
In some ways the future of video game preservation is bright (but in other ways we're still settling for good enough instead of perfect reproduction)
There are so many new NES games now it's impossible to stay on top of it all.
https://arstechnica.com/gaming/2019/05/28-years-later-hacker...
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. :)
But quite honestly, I think that "leader-follower", politics aside, is plainly a better term to describe these kinds of configurations.