Slashdot Mirror

yes, but can it run linux? http://dslinux.org/

The DS can, with the right hardware to enable homebrew: http://www.dslinux.org/

The DS only has 4MB of RAM which severely limits how much you can do with DSLinux. Thanks to the work of Amadeus and many others, the DLDI Build will now detect and enable the GBA RAM automatically on most Slot-2 cards that have built-in RAM. If you do not have a RAM extension you may experience crashes and "out of memory" errors when running most of the applications.

means you can't easily run sugar or abiword on it..

I have a biiig question. i have windows and ubuntu, can i still install linux on the iphone? i suspect that files you published are only for mac osx

This isn't as stupid as it sounds (though one hopes they RTFA'd.) I recall trying to put Linux on my Nintendo DS, only to find that installing it (without using additional hardware) required... Windows. I'm not sure if that situation has changed since, but it was a major disappointment and WTF at the time.

That's been changed a long time ago.
Actually, it isn't even that accurate of a statement, since installing doesn't require any specific type of OS (as long as you can place the files on the media).
What you're referring to is compiling, which (as far as I know) required not Windows, but Linux (I would even goes as far as to say this was always the case as, currently, compiling DSLinux for windows instructions instruct the user/developer to download a Linux live distro).

Perhaps they're taking hints from OSX, KDE and Gnome. It'd be a positive thing. Now, for some commentary on their new features..

--HomeGroup. This essentially turns all the Windows 7 PCs on the home network into a combined pool of data and files

I could easily see how one could do something similar on Linux vis automounter and Samba. DHCP could report the client list to Samba, which attempts to use a specially set password to mount other computers. From then, users would have rights as their own user, granting only rights that they natively have. This would provide security along with a standard solution that all Samba-speaking machines could use.

The only gripe with that setup is that data goes from A to server to B, rather than A to B directly, with the server mediating connections. However, I think this could be made around if we allow direct mediation like FTP can be set up for (Server says send file from B to A).

--HomeGroup is its ability to automatically detect when your work laptop, for instance, is being used in the home.

Network profiles would be much more handy, so one could choose which profile where one is. Also, CUPS is much better than the windows counterpart, as it announces service. Announcement is so much more handy in that regard, because so many devices and OSes speak that. Windows is the odd one out, yet again, unless you go through the "advanced configs".

--Music and video streaming

Arguably, Linux already supports this via multiple protocols. If your client computer is beefy enough, one can "stream" the video from the server. Or, if the client is a low-powered machine, you could use a combination of a sound daemon and X to do the heavy lifting. I would say that there might not be enough bandwidth for raw video via X, but it IS compressed somewhat. X settings are easier, at least in my experience. The sound is more tricky.

There's a few ways to get remote sound. One is to use PulseAudio, and follow the instructions here. They work fine. Also, another choice, if your program is ESD aware, you can use a syntax to target output at a certain server. In fact, I can play MP3s like that on my DS vis the command:

mplayer -ao esd:ip_address_of_ds music.mp3

Found here.

It's a bit more of a setup, but Linux can either process the video locally OR remotely. I dont think Windows can do that.

As for the touch-interface, it looks a lot better than what Linux _currently_ offers, however MPX is a big thing to watch, considering is in the main X.org package. MPX is a multi-point server extension that allows up to 16 mice and 16 keyboard inputs, WHILE keeping backward compatibility with non-MPX-aware apps. This is a biggie, as MS could only figure out how to do multi-point and multi-touch with a special OS only for MP programs. All it takes now is Gnome, KDE, and Compiz to natively communicate with MPX so that we can realize the future of Linux over input development.

Add this to the Wiimote, light-pens, and a downward-facing projector, we could create a touch surface for 1000$ or less, and multi-pointer to boot. Things in Linux sure are picking up...

Nintendo DS?

And it runs Linux! Not to sound like a snob, but I own two because not enough of my friends own their own.

Linux on the DS is actually getting slightly useful if you have a Slot-2 card with GBA RAM on it. You get a wireless webserver, ftpd, telnetd, openvpn/ssh/telnet clients, a mature web browser (links) and I even managed to get clam-av running on it. It is suffering from a lack of developers recently though. http://www.dslinux.org/

Don't forget that you need some kind of homebrew device (I refuse to call them 'pirate devices') to run DSLinux. http://www.dslinux.org/

As a big fan of the potential of the Nintendo DS, I want to point out the possibilities of developing for handheld consoles. In terms of functionality, the current handheld generation, i.e. the Nintendo DS and the Sony PSP aren't far behind, if not even ahead of, cellphones and PDAs. They both have nice big screens and WLAN, which opens up a broad range of possibilities for homebrew software. For example, for the DS there is an e-Mail program, web browsers, internet radio clients, ssh (in DSLinux) and much more. The PSP has a fast CPU and a powerful graphics chip, while the DS two screens one of which is a touchscreen, so it encourages experimentation with novel user interfaces. Both consoles can deal with removable media: The PSP uses the Memory Stick while for the DS there are adapters for Compact Flash and (mini|micro)SD cards. The SDKs are both unofficial, but freely available and actively maintained. Both homebrew scenes are worth checking out, since they have produced a lot of great software, which is not only games. I admit that getting into development is a bit hard at first, but the coolness factor of having your own apps and games running on a games console is just worth it :)

Some links:
Devkitpro (Compiler toolchains and SDKs for DS, PSP and others)
Dev-Scene (DS homebrew news and homebrew database)
DSLinux

Pictoblog (one of my projects)
My DS coding blog

Cheers!
Tob

The DS could actually be quite a capable "smart-device" if Nintendo wanted to market it that way. After all, it already has wi-fi built in, plus chat, mail, etc. I don't know if they have it or not, but if the DS includes an address book and a few other things (calendar, graphing calculator, memo pad), it would actually make a killer replacement for a PDA.

The PSP plays home console quality games, video, music, provides some internet access, makes a great photo viewer, and more.

There's someone working on a firmware patch (or some such), but it looks dubious to me and also requires a specific flashcart: http://geekboy.ca/wifi/?cat=2/ Also it's probably possible for DSLinux (http://www.dslinux.org/) to support WPA and wpa_supplicant has been ported but it requires some more work on the driver before it'll function properly. Trouble is none of the current dev's are really au fait with WPA, so any help is gratefully accepted.

..what I want is an affordable DS cart loaded up with Firefox, a lightweight mail client (put the keyboard on the touchscreen), a lightweight AIM app, telnet/ssh, and maybe even an IRC client. Give me that, and I won't need an iPhone.

Firefox is impossible because the DS has too little memory to run it.

But you can have links/telnet/ssh/bitchX IRC with dslinux. A mail client (mutt or mailx) may be added in the future. If you have a host to run bitlbee on you can have AIM via bitchX.

You'll need to buy a Supercard or an M3 (they cost small bit more than a DS game), and possibly a NoPass device (don't know how much they are right now but they should cost less than Supercard/M3). Check the dslinux wiki for more information.

..what I want is an affordable DS cart loaded up with Firefox, a lightweight mail client (put the keyboard on the touchscreen), a lightweight AIM app, telnet/ssh, and maybe even an IRC client. Give me that, and I won't need an iPhone.

Firefox is impossible because the DS has too little memory to run it.

But you can have links/telnet/ssh/bitchX IRC with dslinux. A mail client (mutt or mailx) may be added in the future. If you have a host to run bitlbee on you can have AIM via bitchX.

You'll need to buy a Supercard or an M3 (they cost small bit more than a DS game), and possibly a NoPass device (don't know how much they are right now but they should cost less than Supercard/M3). Check the dslinux wiki for more information.

"I think it's a good start, though I can't say I like all of the Slot 1 solutions yet. They still don't have a way to play games that need GBA mode, which is a bit of a deal breaker for me."

I don't believe you'll ever see GBA stuff running from Slot 1. It is my understanding that it's a physical architecture problem; the Slot 1 stuff simply cannot access the GBA bus.

See this section of the DSLinux Wiki "About Slot 1 Devices and RAM." It's obviously concerned with DSLinux and not GBA access, but the restrictions are the same as related to Slot 1:

http://dslinux.org/wiki/Slot-1_Device#About_Slot-1 _Devices_and_RAM

Couldn't you also just get a slot-1 device, and then put memory-mapped RAM in slot-2?

Yes, if vendors supplied a RAM expansion for slot 2 the problem would go away.

Do you know if it would be possible to run an ssh client on DSLinux without RAM expansion?

The ssh client works well without additional RAM. If you want to browse the web with links or run the bitchx IRC client, you are better off with extra RAM. But if you just want to ssh into some other box and do everything else there, you don't need extra RAM. See also http://www.dslinux.org/wiki/DSLinux_as_Terminal

1. They are more supported by homebrew, although as the article said, this is slowly diminishing due to the new DLDI support.
2. SnezziDS, one of the best SNES emulators for the DS, only runs on slot-2 cards with GBA compatibility.
3. DSLinux works best on slot-2 devices with GBA compatibility, as explained in this post. With DSLinux, I can browse the web while listening to MP3s while chatting on IRC.

The latest hardware is the slot-1 type, which is a DS-sized card and requires no additional hardware or modifications to the DS. These are much simpler to use than slot-2 devices, but as the majority of homebrew was designed for the slot-2 hardware and it's ability to boot GBA software, there are some compatibility issues. They are thankfully being ironed out, and as slot-1 devices become the standard we fully expect that all new homebrew will be designed with them in mind.'

For DSLinux, the issues cannot be ironed out! So this new trend gives us headaches :(

The DS has only 4MB of RAM. DSLinux has been using extra RAM present in add-on devices for some time now (usually an extra 32MB). But because only slot-2 is mapped into RAM, only slot-2 devices can provide additional RAM. Slot-1 devices can only be accessed via serial.

So if you want to run DSLinux, don't get a slot-1 device, get a slot-2 device that provides additional RAM.

See also:
http://mailman.dslinux.in-berlin.de/pipermail/dsli nux-devel/2006-December/000379.html
http://www.dslinux.org/wiki/Running_Homebrew#Recom mended_storage_devices

The latest hardware is the slot-1 type, which is a DS-sized card and requires no additional hardware or modifications to the DS. These are much simpler to use than slot-2 devices, but as the majority of homebrew was designed for the slot-2 hardware and it's ability to boot GBA software, there are some compatibility issues. They are thankfully being ironed out, and as slot-1 devices become the standard we fully expect that all new homebrew will be designed with them in mind.'

For DSLinux, the issues cannot be ironed out! So this new trend gives us headaches :(

The DS has only 4MB of RAM. DSLinux has been using extra RAM present in add-on devices for some time now (usually an extra 32MB). But because only slot-2 is mapped into RAM, only slot-2 devices can provide additional RAM. Slot-1 devices can only be accessed via serial.

So if you want to run DSLinux, don't get a slot-1 device, get a slot-2 device that provides additional RAM.

See also:
http://mailman.dslinux.in-berlin.de/pipermail/dsli nux-devel/2006-December/000379.html
http://www.dslinux.org/wiki/Running_Homebrew#Recom mended_storage_devices

I agree with your point that hacking many platforms is difficult but that people are doing it is probably the best way to improve the hackability of future platforms. If hardware vendors see hackability as a desired feature, they will enable it. My original reason for replying was just to counter the impression that running homebrew on the DS(including http://dslinux.org/) no longer requires flashing the firmware or taking the chance that you'll brick your hardware. The latest NoPass devices, let you run applications from an sd or cd or minisd card via other cards and can even increase the RAM available to homebrew. Once again, no flashing necessary. Happy hacking.

If you treat someone like the villain, they always will be. I think the Rootkit thing was abhorrent - but Sony music is to blame, not Sony games.

Except Sony BMG Music and Sony Computer Entertainment share revenue and earnings. One division can prop up another, and one division can give another a discount on licensing underlying works (e.g. PS2/PS3 games based on Columbia Pictures movies, or Columbia Records music used as the soundtrack in a PS2/PS3 game).

I'd love to run homebrew on it myself but I realize that at the moment Sony is not up for that, so I simply do not buy one.

Neither do I, and for the same reason. However, "not being up for that" is precisely what people complain about. It possibly includes some bitterness that Sony terminated the CLIE, which Nintendo fanboys may allege is for fear that sales of CLIE hardware and Palm OS games might cannibalize sales of PSP hardware and games.

If I were really into that I'd buy the Linux based handheld.

Thanks to resourceful hackers, Nintendo makes the Linux based handheld. If you're referring to the GP2X, most people don't want to buy and carry two handhelds: one for commercial games and one for homebrew. And where can I buy the GP2X in person with cash in the United States? And where can I meet other players with a GP2X in person in order to play local multiplayer games?

And doesn't Nintendo have essentially that same issue?

No. Nintendo isn't taking any steps to block NoPass, the most common method of getting a DS ready to run homebrew. The last security-related update to the DS firmware was a year ago.

you have to encourage good behaviors when they happens. Supporting Linux on the PS3 = good behavior. Homebrew games on the PS3 = good behavior

I'll encourage the good behavior when it happens, not before. Linux on the PS2 was discontinued too quickly.

Would you execute a guy for buying pot on the street, or give him another chance?

For one thing, Sony BMG Music's rootkit is more like breaking and entering than like buying pot. For another, "another chance" has happened over half a dozen times in the PS2's lifetime alone; compare to several US states' "three strikes" rules.

If you want to try Linux on your DS, check here: dslinux.org

The info on that DSLinux Wiki article is a bit outdated as of a few weeks ago. A user named amadeus has recently found a way to utilize the 32 MB of RAM in the Supercard CF and SD editions in DSLinux, and he is currently working on getting the M3 to work as well. See http://www.dslinux.org/index.php?showtopic=1748 for details.

It even has a built in 32 MB RAM expansion, which makes DSLinux much more useful than before.

The RAM extension isn't used by DSLinux, though. You said you still use GBAMP for Scumm VM? I thought Scumm VM runs fine on a Supercard CF? Are there any problems?

(nice firmware and a built in clock for evil warez stuff, effectively)

Does somebody know if the battery for this RTC can be replaced? Is the M3 useless once the battery is empty?

The Nintendo DS community is a loud and wonderful beast. In the last few months... We've had DSDoom, DSLinux and Dev-Scene. natrium42 is a brillant developer and this is an interesting piece of hack but.. wouldn't be have been a better idea to post the bigger picture (for some reason all my submittions keep getting denied.)

Are you interested only in DS homebrew or in both?

DSLinux and Scumm VM are most tempting, so I guess I'm mostly interested in DS homebrew. I've read that neither works with the M3 DS lite (which would'nt stick out of my DS lite), and Scumm VM has only restricted compatibility with Scumm VM + speech output.

I'd prefer to use DSLinux to get best of both worlds.. the great games of the Nintendo DS, and the flexibility of Linux (for which, to be honest, there are not as many great games as for the DS).

We are developing the port of Linux to the Nintendo DS. The project is based on uClinux. We have inherited uClinux' build system and CVS organisation.

Just like in uClinux, our CVS repository contains everything (Linux kernel, uClibc C library, uClinux userland). It is very, very large (almost 1GB). It has multiple branches to keep imports of third party sources organised. I've written a page on our wiki that explains how we set things up in the repository.

Not everyone is really happy with this. While I am comfortable using CVS (since by now I know how not to shoot myself in the foot), there are a couple of things that CVS cannot do for us. When it comes to moving things around on a great scale CVS is just a pain in the ass.

Regarding the build system: Our current setup makes package management quite impractical, but people keep requesting this feature It is very hard to incorporate, because of our strong ties to the way things are done in uClinux (zero package management).

Also, there is currently only one anonymous CVS mirror. At peak times the load is very high, and people keep complaining about poor performance of the server. Making CVS use a ram disk for temporary files helped a little, but the bottleneck is really CVS's poor ability to scale to large trees.

So we are considering moving to git. I am currently investigating it and I must say that I like it much more than CVS and subversion. The way we handle branching should feel much more natural with git. Conversion from CVS seems to be very smooth, at least according to the git documentation.

Conclusion:
Changing the version control system is not a huge problem really. You can always do that. What is very hard is changing the build system. You should really consider and evaluate all alternatives you've got before going productive. The question is of course what you really want to do, and what you are starting out with.

In your case, you should probably take a look at various other Debian-based projects. You may find a suitable solution, already tried and tested.

In our case, uClinux was an obvious choice, since it included an (incomplete) port of Linux to the Gameboy Advance, which DSLinux is based on. Alas, it looks like we now have to live with the deficiencies of the build system.

We are developing the port of Linux to the Nintendo DS. The project is based on uClinux. We have inherited uClinux' build system and CVS organisation.

Just like in uClinux, our CVS repository contains everything (Linux kernel, uClibc C library, uClinux userland). It is very, very large (almost 1GB). It has multiple branches to keep imports of third party sources organised. I've written a page on our wiki that explains how we set things up in the repository.

Not everyone is really happy with this. While I am comfortable using CVS (since by now I know how not to shoot myself in the foot), there are a couple of things that CVS cannot do for us. When it comes to moving things around on a great scale CVS is just a pain in the ass.

Regarding the build system: Our current setup makes package management quite impractical, but people keep requesting this feature It is very hard to incorporate, because of our strong ties to the way things are done in uClinux (zero package management).

Also, there is currently only one anonymous CVS mirror. At peak times the load is very high, and people keep complaining about poor performance of the server. Making CVS use a ram disk for temporary files helped a little, but the bottleneck is really CVS's poor ability to scale to large trees.

So we are considering moving to git. I am currently investigating it and I must say that I like it much more than CVS and subversion. The way we handle branching should feel much more natural with git. Conversion from CVS seems to be very smooth, at least according to the git documentation.

Conclusion:
Changing the version control system is not a huge problem really. You can always do that. What is very hard is changing the build system. You should really consider and evaluate all alternatives you've got before going productive. The question is of course what you really want to do, and what you are starting out with.

In your case, you should probably take a look at various other Debian-based projects. You may find a suitable solution, already tried and tested.

In our case, uClinux was an obvious choice, since it included an (incomplete) port of Linux to the Gameboy Advance, which DSLinux is based on. Alas, it looks like we now have to live with the deficiencies of the build system.

Much easier to write it on a notebook and be able to take screenshots/videos to show the judges and not to mention sticking it on a projector

Point taken.

rather than to get them all to crowd around the one ds that you've flashed so you can run your own code on.

It could still be argued that a game designed for the DS should be presented on a DS nonetheless. The judges should take the time to give the game a spin on a real DS if they could.

And you don't need to modify (or flash, as you put it) the DS in order to run your own code. You just need extra hardware which costs about 75 Euros. See here for more info on this.

From TFA:

DS Linux is a port of the Linux operating system to the Nintendo DS. The project hopes to bring the full capability of Linux to the DS, but is still in the developmental stages. The project supports a full keyboard on the touchscreen, and will allow users to send and read email, chat online, and play text-based games. (emphasis mine)

We are actually a bit further than that. Two IRC clients are available (tinyirc and bitchX). BSDgames and other text games are mostly working. The article forgot to mention highlights such as working wifi support, ssh/scp, an algebra system (mathomatic), and text-based web browsing. (To be fair, they contacted us for an interview before writing the article but it seems we were to busy to respond :P)

The biggest limitation is the lack of an MMU, which means neither paging nor swapping is possible. Hence DSLinux is a port of uClinux to the DS, not of the vanilla kernel. Our current kernel version is 2.4.16-hsc0 with an awful lot of patches and lots of new drivers to support the hardware of the Nintendo DS itself and various add-on devices (mostly storage devices using CF or SD cards).

At the moment we are stuck with 4MB RAM, which makes things a bit tricky. There is work going on to expand the available RAM from 4MB to up to 32MB for storage devices that sport on-board RAM, for example the Supercard. We also have someone on the team capable of building custom RAM expansion carts for the DS's GBA slot. Once we have more memory we'll have much more possibilities (there's talk about a GUI, for example, but that is still far off). Accessing RAM through the GBA slot involves gcc modifications, which have already been made. We still have to rewrite some of the assembly code in the kernel and the C library (uClibc). You can read more about this here if you are interested.

As you can see, this project is quite fun and challenging. Tasks on the TODO list range from shell scripting and cross-compiling applications to hacking ARM assembly in the Linux kernel. Progress is slow because we only have 3 very active developers at the moment (myself included), and some people who occasionally send patches. There is a lot of work to do. Get in touch if you are interested in helping out.

From TFA:

DS Linux is a port of the Linux operating system to the Nintendo DS. The project hopes to bring the full capability of Linux to the DS, but is still in the developmental stages. The project supports a full keyboard on the touchscreen, and will allow users to send and read email, chat online, and play text-based games. (emphasis mine)

We are actually a bit further than that. Two IRC clients are available (tinyirc and bitchX). BSDgames and other text games are mostly working. The article forgot to mention highlights such as working wifi support, ssh/scp, an algebra system (mathomatic), and text-based web browsing. (To be fair, they contacted us for an interview before writing the article but it seems we were to busy to respond :P)

The biggest limitation is the lack of an MMU, which means neither paging nor swapping is possible. Hence DSLinux is a port of uClinux to the DS, not of the vanilla kernel. Our current kernel version is 2.4.16-hsc0 with an awful lot of patches and lots of new drivers to support the hardware of the Nintendo DS itself and various add-on devices (mostly storage devices using CF or SD cards).

At the moment we are stuck with 4MB RAM, which makes things a bit tricky. There is work going on to expand the available RAM from 4MB to up to 32MB for storage devices that sport on-board RAM, for example the Supercard. We also have someone on the team capable of building custom RAM expansion carts for the DS's GBA slot. Once we have more memory we'll have much more possibilities (there's talk about a GUI, for example, but that is still far off). Accessing RAM through the GBA slot involves gcc modifications, which have already been made. We still have to rewrite some of the assembly code in the kernel and the C library (uClibc). You can read more about this here if you are interested.

As you can see, this project is quite fun and challenging. Tasks on the TODO list range from shell scripting and cross-compiling applications to hacking ARM assembly in the Linux kernel. Progress is slow because we only have 3 very active developers at the moment (myself included), and some people who occasionally send patches. There is a lot of work to do. Get in touch if you are interested in helping out.

I own the original as well, and I would agree with you: it works just fine. However, I am a teensy bit jealous of my friends that have Lites; the difference in brightness has tempted me dangerously close to purchasing one.

Like you, I'll probably wait until it breaks (or I decide to put Linux on it) before getting a Lite.

I'm not sure why the other post pointing to DSlinux is (0), but there is at least one ssh client for DSlinux - Dropbear. I haven't tried it yet. Of course you'd need a flash cart or (mini/micro/normal)-SD adapter such as the M3.

Well, you could try dslinux.

The scary thing is they do run linux, and they have the wifi working. So, you actually could cluster them..

Zero.

And here's what you need to run Linux or other homebrew programs on your DS.

Mod parent up.

As an amateur Nintend DS developer:
In the "good old days" one could buy a device called a PassMe (a glorified device that performs a JMP into the GBA cartridge's ROM thus executing unencrypted code. They come in several variations such as the PassMe and the SuperPass). Nintendo was not happy with the PassMe and made all the recent DS systems (after and including firmware 4.0) and made the handshaking between the DS and the DS cartridge a bit more complicated and on a game-by-game basis. Now, one needs a device called a PassMe2 which essentially pretends to be a game. Beyond this, there are "NoPass" devices which don't have to do the handshaking with the DS.

As it stands you can't use the rumble addon like the article implies, largely because both slots on the DS are taken up with the current state of homebrew (a GBA cart containing the code you want to run and a PassMe-like device in the DS slot). The DS section of this article is misleading. For more information, I suggest DualScene.net and MaxConsole.net for information on homebrew games and programs. One can check DSLinux.org for information on, appropriately, DS Linux, and one can check GBADev.org for information on DS and GBA development.

Even a Nintendo DS can run Linux.

most likely.

There is a web browser already available. Someone ported retawq (text based browser) to http://www.dslinux.org/ and now that XIP is working apparently it's actually nearly usuable. Someones got nano-x working as well, but I think that due to RAM limitations having Firefox on top of DSLinux is you waking up blowing bubbles in your cornflakes. Also semi working is IRC, SSH and I've played around with NFS, it sorta works. The other thing about OperaDS is the fact that there are going to use the GBA slot for extra ram, or so I've heard, so that may mean the homebrewers get more to play with.

Actually there is a group working on a distro of Linux for the DS. It even allows the use of the touch screen. Check it out.

Compare the installed base of PDAs (either by model, by manufacturer, or by the class of devices as a whole) to the installed base of portable gaming devices (GameBoy, et. al.), and you might see *one* possible direction for the PDA. Previously, games were popular on a PDA, but the limitations (speed, memory, battery life, etc.) made it evident that portable gaming on a PDA wasn't enough to keep the PDA craze alive as we knew it. The Nintendo DS, though, is already starting to look more and more like a PDA every day: there's a homebrew organizer (http://www.youngmx.com/?loc=ndsdev/DSOrganize), a Linux project (http://dslinux.org/), and even a game that features puzzles aimed at/successful with older people (http://www.nintendo.com/gamemini?gameid=tYVqJgro- KG6QL_mMbXFoQTkQIzgi9nU). The fact that it has touch/stylus input and 802.11b is enough to get one's mental gears turning at the possible confluence of a gaming idiom and personal information management idiom in a single device. Perhaps the change will come from the other direction. As millions and millions more Nintendo DS units (and Sony PSP units, for that matter) are sold, we may get a population of generally older, more sophisticated portable gamers who demand a bit more functionality from their handheld devices -- the very same functionality that a stripped-down, basic PDA would have provided. Instead of a feature-rich-but-mostly-underused PDA that can play games, we might have a gaming-device-that-also-holds-my-calendar that can read e-mails. And I guarantee you that there are more GameBoys out there than Palms.

I really wish Nintendo would come out with a pda

keep an eye on http://www.dslinux.org/.

Considering that it is a DS, it will probably be able to run DSLinux. I think they even have the touch screen working, but there's not much you can run considering the unit only has 4MB of internal memory.

It looks like the site is having some database problems right now, I hope those clear up soon.

Yes, actually.

http://sourceforge.net/projects/dslinux/
http://www.dslinux.org/

DS Linux is a perfect example of another linux distro that runs on flash alone.
As for *limited* rights, its something like >5x10^6 writes to the card isn't it? I don't really know how that compares to the amount of r/w's a typical computer performs over a given amount of time, but it sounds like a lot to me. Also, with prices on flash memory falling as they are, it likely won't be a big deal to replace the card once you've expended your 5 mil writes.

I have to agree. The dual screen rarely brings anything to the device that a larger screen or better use of existing screen real-estate doesn't. I hate the second screen in that respect, because it constantly diverts my attention from where it should be: the gameplay. There are a couple interesting uses for it, but I have yet to see any use of the second screen that justifies it.