I made a few small contributions to this a long time ago. Nice to see that the website is still up!
Probably the most interesting feature of this project was how it handled memory. The DS only has 4mb of ram. And there is no MMU, so swap isn't an option. But the gameboy cartridge port has 32mb of address space mapped to the bus. And there are homebrew/piracy cartridges that fill that space with 32mb of ram. Which is great, except that the DS can only write to the cartridge port on 16-bit aligned addresses. And almost all software will assume that 8-bit aligned writes will work. To make use of the expansion memory the developers ended up creating a patched GCC that would convert any writes to unaligned locations to an appropriate read, 16-bit write, and set of shift operations.
Huh, does it really have an MMU? I don't remember that when I coded for it back in the day, and wiki seems to be the only one saying that (uncited). It also doesn't make a lot of sense to be at that point in the system as it's so far away from the main bus matrix.
But perhaps my memory is going bad and my Google Fu is worse.
I have no idea, just quoted Wikipedia. It looks like there is only a single chip in that module, so it would make sense for that only being a RAM chip. Can't edit the post anymore though.
Haha! I always wondered as a kid why that was a requirement. The number of times I had to use the Opera browser to get around my restrictive mother, sigh.
Another quirk: It was pretty common to load your homebrew software from a cartridge in the gameboy port. The cartridges would have some combination of ram and flash based storage or CF Card, and you could tell the cartridge to expose the storage or the ram as they were behind some sort of banking scheme. This meant that the storage system was mapped directly to the bus. So to save on ram, programs were run "in place", executing directly from the storage rather than being copied to ram first.
I very fondly remember this project when I was growing up too, and I credit it with sparking my interest in kernel development.
When trying to port some industrial control software to DSLinux, I ran into some bugs around how the SLOB allocator behaved under memory pressure. One of my patches landed upstream, even though SLOB is deprecated now. Still, as a kid starting out in the embedded space, it opened my eyes to the joys of hacking around with homebrew.
Fun fact: a modded DS still powers a large part of my local observatory's equipment.
I recently did a deep dive into DS homebrew. Some cool stuff - a Yugioh calculator, mp3 player, port of Doom. In particular, I just love the hardware of the DS Lite or the DsI - it feels great in 2023, and the symmetrical screens are amazing when holding in vertical mode reading an ebook or playing Hotel Dusk. It also has one of the best pieces of software ever for learning Chinese, ‘My Chinese Coach’ - there are additionally two more (at least) homebrew software packages that focus on Chinese, such as DS Zhongwhen.
DS is very underrated - so many great games, and it’s an emulation dream. All without being too powerful, and having ‘realistic’ graphics that just drain battery life.
I was the one who ported DOOM to DS back in high school; we were all in the same DS homebrew IRC channel together. A lot of my now-closest friends worked on the other projects (including the author of DS Linux) -- incidentally we all ended up working for various tech companies in Silicon Valley and ended up reuniting in real life decades later.
DS Zhongwen, that's a name I didn't heard in a long time! I am its author :-). I also made other stuff, like Knytt Stories DS. Making homebrew for the Nintendo DS was a great experience, as the limitations (and possibilities) of the hardware gave enough space for both creativity and engineering challenges.
The most surprising thing to me about DS and Switch homebrew was how approachable they are. For some reason I always imagined building things on them would be wizardry, but it's really not.
I had a dive in to it. The docs and info is pretty accessible, the problem comes from the fact that the hardware itself is inherently pretty confusing. Having to understand all these memory banks and graphics modes, etc.
Was a lot of fun though. It's super cool how easy it is to just download libnds, compile the demos and get them running with a $9 flash cart.
There's also an entire visual novel engine called VNDS[0], with quite a few ports made for it. Afaict most "classic" VNs have ports available for it.
Also if you have a 3DS, check out the TwilightMenu project. It's a DSiMenu clone that can load homebrew titles and the like from the SD card (as well as flashcards).
I remember ...taking my sister's iPod something to install this and then to connect it to my PS3 in order to jailbreak it.
My sister was not happy of course, I am not sure whether I was able to reset the iPod to its original state or not.
I don't believe in Hell, but if I did I would suspect it would have a special place for Wikipedia deletionists, somewhere near the people who never return their shopping carts.
I think Wikipedia deletionists would love to open up a circle of hell just for video games and related topics because it seems quite hard for a book to be considered notable on Wikipedia but hard for a game not to be. For instance only half of this author's books
are considered notable enough to have Wikipedia pages (and notably not the excellent https://www.amazon.com/If-Then-Simulmatics-Corporation-Inven... but maybe that is just my opinion as a computer nerd who works in the public opinion field... If you notice I try not to say things like "most people think that" because I don't want to be caught with my facts wrong.) but truly obscure games like
seem to not have to fight for notability at all. (Personally I kinda like that one, but I'm a serious weeb and even I'll admit that it is terribly balanced and too grindy)
It's a problem that came up ~~a few years~~more than a decade ago with Kate Middleton's Wedding Dress which was deemed "not significant" initially, whereas every niche Linux distro has a page, which simply shows the demographics of the folks in charge of moderating Wikipedia: https://slate.com/technology/2012/07/kate-middleton-s-weddin...
I get the idea of "Let's keep Wikipedia for relevant things instead of a graveyard of everyone that wants to self-promote their meaningless project", but there is absolutely a real problem here.
Code of Princess is relevant because it's published by Atlus, but by that measure, any of Jill Lepore should be relevant enough. That said: Do you know if the books without pages were removed for non-relevance, or if it's simply a matter of "No one has created a proper Wikipedia Article for it yet?"
which has some stories in newspapers claiming it has serious player numbers but the people who make it have tried several times to make their own page for it which have been taken down because it was self-promotion. I’d imagine someone else could still make one but nobody has.
Myself I’d rather deal with nicer people so I try to slip real Ukiyo-e prints into Danbooru and also correct historical inaccuracies in the bio(s) of people that FGO characters were based on.
I don't think it's weird at all for there to be a Wikipedia page for every official release for a popular gaming system, even if the release itself is somewhat obscure. On the other hand, it makes sense that some author's books would only be found as a subitem on the author's page. I couldn't tell you offhand what the exact delineation there is, though.
Given the price of bits these days a single bit flag with 'non notable' would suffice and then they could keep these and allow people to see 'full' or 'just notable'. That should satisfy all parties. Of course there is then also the cost of the bits of the articles themselves but that too would be manageable.
The problem with this idea is that it will just be abused for SEO spam junk, and you'll have to default to hiding all content with the 'non notable' bit from discovery by default lest the entire ecosystem get dragged down by the pollution. At this point, you might as well delete the content entirely, because it's just taking up space and not contributing to the experience for the vast majority of users.
I think there is a pretty easy to distinguish difference between 'SEO spam junk' and 'non notable' but if you're worried about that you could always have 'non notable' default to all outbound links to be 'nofollow'. For every problem there is a solution, if you want to solve it. I've seen and heard just about every excuse possible why particular things should be 'non notable' but not a single one that has stood up to scrutiny, it always seems to in the end boil down to 'because we say so'. Which is a pity because ultimately 'notability' is as much in the eye of the beholder as it is something objective and what is non-notable to one large group may well be notable to another. And if that first group is over-represented amongst the wikipedians then that's the end of that, no matter how important something really is.
What a nice surprise to see this on the HN front page! I was involved with DSLinux for several years. I maintained nightly-ish builds that I hosted on my website. I don't think I ever contributed any code, as my C and system programming skills were still rudimentary at the time, but I did a fair amount of testing and helping people in the community.
Most of credit for the amazing work that made this possible goes to a few individuals, in particular Malcolm Parsons (pepsiman), Stefan Sperling (who later became an OpenBSD developer), and Amadeus: http://dslinux.org/wiki/ContactingDevelopers.html
It's not exactly the modern equivalent, but owners of a modded Nintendo Switch can dual-boot with a few different Linux images: https://wiki.switchroot.org/
Since it's based on the official (albeit outdated) Tegra drivers, you can run a surprising amount of stuff on it. I got SkiFree working in Box86 and called it a day.
Additionally, the switch is a hop, skip, and a jump away from being the same hardware as a Tegra Shield that the L4T images initially targeted. Like even down to the same exact model of DRAM chips which should have been more of a commodity and a reflection of the manufacturer's vendor relationships.
It's as close to an officially supported Linux distro for Nintendo hardware as we've ever gotten.
> It's as close to an officially supported Linux distro for Nintendo hardware as we've ever gotten.
To be fair, Linux on the Wii was also quite good: I remember running Debian 5 Lenny on my Wii many years ago, and it seemed to be "just" a different kernel with drivers for the Wii hardware but with the normal userspace / repos. With an USB mouse and keyboard this was even somewhat usable, even with X11 and some lightweight window manager. Of course RAM was quite limited with only 80MB in total, but still. It definitely wasn't as hacky or limited as DSLinux.
Back in high school, I used to go “war driving” on my bike around my neighborhood with DS Linux running on an M3 cart. Almost forgot this existed; thanks for sharing, this was a fun memory to dig up. I still have my DS and my M3 cart but the SD card with my old build on it is long gone.
This was my gateway into Linux! I'm grateful to whoever decided to bundle the BSDgames [0] and Frotz [1] packages, for sparking a lifelong love of text adventure games and interactive fiction. Imagine my surprise as a little kid poking around the bin directory, typing "advent" into the prompt expecting a simple advent calendar application, and instead getting dropped into a whole other world [2]...
Same as you, but first I played IF games under Winfrotz/ZX Spectrum. Later, I ran Linux with advent/battlestar and such under Frotz for Unix (among trek) and I was hooked.
I sure did! We got pretty good at text-entry with the stylus when it was the only input method we had to work with. Like how people adapted to thumb-typing on smartphone touch screens.
The first one being that the SoC configuration runs in DS-compatibility mode which does not expose all of the available RAM in the DSi, and nds-bootstrap won't properly redirect I/O requests to the external SD card, which means you either need to embed the rootfs in the NDS ROM which won't persist changes, or use a flash cart and run the DLDI build instead.
Actually, someone made a working DSi mode WiFi driver some months ago. It is even used in a DSi compatible fork of ftpd. Very handy when transferring files on the SD card of a hacked DSi since it has WPA2 support unlike DS mode which is stuck with WEP.
As a heavy Linux user myself, I was wondering what kind of functionality you would gain from running Linux on a DS (aside from the obvious learning experience and “because you can”). I found the FAQ[0] answers this nicely.
Basically, it boils down to anything you can do on the command line within the resource constraints of the DS.
Would love to hear any DSLinux users who would be willing to share stories about cool functionality they were able to achieve.
I could never run DSLinux, I was in eighth grade and couldn't afford the RAM pack (just used a pirate card for games). But I printed out all of the documentation at the school library and read it until I pretty much new it by heart, and that became my introduction to Linux.
I can't remember if this was before or after I managed to inadvertently install (!?) Knoppix on my sister's school laptop, but my passion for Linux was there well before I had the means to run it myself.
The problem is the touch keyboard is unusuable. Most likely because of the NDS v 3DS screen resolution difference, it's impossible to type on it. Took me a couple of minutes to type "root" but never managed to hit Enter :D
Every once and a while I get the urge to run this again and host a webpage from it.. sucks this device lacked a lot of IO and the wifi stack is so weird
Probably the most interesting feature of this project was how it handled memory. The DS only has 4mb of ram. And there is no MMU, so swap isn't an option. But the gameboy cartridge port has 32mb of address space mapped to the bus. And there are homebrew/piracy cartridges that fill that space with 32mb of ram. Which is great, except that the DS can only write to the cartridge port on 16-bit aligned addresses. And almost all software will assume that 8-bit aligned writes will work. To make use of the expansion memory the developers ended up creating a patched GCC that would convert any writes to unaligned locations to an appropriate read, 16-bit write, and set of shift operations.