angrycat

The DS Blues

What can I say. I thought I had mustered some more energy to resume daily blogging on the DS but who am I kidding. I am still stinging from having to re-purchase the damned thing after losing it and I just have not built up the same level of steam I had earlier. In fact it sort of makes me sick to look at my new DS.

Another part of the problem may be that we are still some ways off from writing code for the DS and while for a lot of people this whold DS homebrew race is about hacking hardware plain and simple, I am a developer through and through, and am more excited by seeing my code running then anything else.

Add to it the great job of coverage that is being done so far, I think I'm going to take a hiatus on DS dev blogging and finally turn my attention to other subjects that I've been eager and promising to get to.

Don't tune me out completely though, I will be back on the DS sooner than later, that much I promise you.

FU*K!! The new DS has a dead pixel!

Can this freaking DS debacle get any more fu*ked up? I get my replacement DS that I ordered on ebay, after it originally was misplaced by the USPS, after which my first DS was lost in a parking lot, and now, I open it and it has a gawd-damn fuc*king dead pixel. I am fu*king pissed!!!!!!!!!!

DSLinux forums added..

I've added DSLinux's forums site to my list of DS homebrew resources. Make sure to check them out in tandem with gbadev's DS forum.

DS to go multi-medium

Nintendo has announced plans to release an addon to the DS (for the meantime in Japan only) that extends the DS' capabilities to play back video and music.

Thishas prompted an interesting thread of speculation as to whether this means that the DS hardware is accessible from the GBA port, at where else, but gbadev's DS Forum.

Back in the saddle..

Ok, my new DS arrived to day and I'm feeling better. Here comes a flurry of posts to make up for my absence. I realise a lot of it will be old news but I feel a need to regurgitate to get the juices flowing. There's not too much to blog about in terms of DS hacking these days, things are still in the early stages, so bare with me while I refocus my efforts.

He was a good friend...

I haven't blogged in over a week. Why? Well I've been in a funk over the loss of my Nintendo DS which also held within it my Flash2Advance Ultra with several of my demos. Losing $400 worth of rare gadgetry of this kind is enough to give you writer's block.

I may decide to switch gears on DS blogging for a while, at least until my replacement unit comes (which I ordered off of EBay at a 75% markup).

I'll be back.

Forgive me: Redux

I know, still no C++ posts. But believe me I have gotten started on it but was sidetracked with some work on processor technology (ARM of course). Stay with me :) It will be here soon.

Team XLink to release DS Tunneling as Open Source

This is old news by now, but here is the direct link to Team XLink's thread, detailing an open source roadmap for their DS tunneling implementation.

Nintendo DS Cart Checksum

I know I have been abscent all weekend. I took a vacation from blogging. To kick off the new week, here is a link to DarkFader's DS catridge checksum code. And here is a link to the original thread on the DSDev forum.

Stay with me folks, I'm but one soul. Angry Cat will be back in full throttle before the day is old :)

DS Cart Pin Mappings: Redux

The DS cart pin mappings thread over at gbadev's DSDev forum is still going strong and with new insights and modifications to the previous theories/assumptions that I posted about earlier this week. I highly advise you check it out to stay up to date. Meanwhile I will add a "deprecated" note to my first post.

Forgive me...

I know I have failed you :) I promised the first of several C++ postings no later than yesterday. No go. DS hacking has kept me busy along with the usual work that feeds the mouths. I am aiming to knock it out over the weekend. Have faith ;)

Sukanu posts latency theories for DS

Sukanu has posted some interesting thoughts in a somewhat meaty paper entitled "Latency Comparison Analysis Between Local Area Wireless networks and the Internet And Issues That May Occur With the Nintendo DS". Come to think of it that title itself is almost as meaty as the paper :)

His work was born out of a side conversation in the XLink tunnelling thread that I cited in my previous post. I would track it as well since discussion on his thoughts may continue on that thread for a while longer.

Team XLink has tunneled PictoChat

Team XLink has announced that they have successfully tunneled PictoChat over the Internet (i.e., one DS through a PC over the Internet, to a 2nd PC, to a 2nd DS). They have not made the details of their implementation public yet as they are working on perfecting and stabilizing their requirements and procedures, but assure that there will be a more demonstrative announcement when they reach that point (hopefully soon).

You can read more about it (along with all of the skeptics) over at this thread on their forum. This is obviously a very nice accomplishment and a small but important step for the fledgling DS homebrew scene. Congratuations to them. Now everyone back to work :)

gladius makes progress on Wi-Fi hacking

gladius has updated his page with positive progress on the DS Wi-Fi hacking front.

Very good news, I put my DS into Pictochat and managed to get to start the 802.11b authentication process. This means it will at least be possible to research communication with the DS (multiboot, tunnelling). The source to the neccesary programs is here. BE WARNED, this is highly developmental software, it's quite possible it will crash your kernel, etc. Secondly, there is really no functionality here, it's a proof of concept, I'm releasing the source to help spur the development onwards.

Update: managed to get the DS to think Mario 64 is available for wireless download - can't send it yet, and can't modify the replayed packets because there appears to be some sort of CRC check. Try out replay.c on a libpcap capture of mario 64 sending out beacon frames, you'll need at least 4-5 seconds of capture.

As always, go to his page for the full story as well as source code and hardeware/OS requirements. It's also worth mentioning that the gbadev DSDev Wi-Fi hacking thread is still going strong. I recommend you keep watching it as it contains extra minutia that might be helpful to those who are working in tandem on this effort.

You say tomayyto, I say tomaaato!

While talking to Darkain last night on EFNet he pointed out that I'mr using the acronym "Wi-Ni" all over this blog as opposed to the term "Ni-Fi". We both agreed it's a matter of taste and of very little consequence. Maybe the fact that I'm posting it suggests how little else there is to say at the moment? Or maybe this post is a figment of your imagination? Huh? Did you ever consider that?

DS Homebrew Resources

I've updated the "Ports of Call" post to include Spicious' site (which I suspiciously left out - get it?). I've also added a link list to the right-most column of this page, in the upper area. It's easier to use that than to go fishing for the aforementioned post. Enjoy.

Wi-Ni hullabaloo?

Even prior to the DS' release there has been a conventional wisdeom that Nintendo implemented a super-special networking protocol with super secret magic sauce. I have partaken in such conventional conclusions myself.

However, in the past week and a half there has been a lot of work done concerning how the DS peforms networking and Darkain has updated his DS Wi-Fi hacking page to give more detail on where he thinks the Wi-Ni protocol stands, and that may be not very super-special at all:

I believe that "NiFi" is mearly an alternative to TCP/IP for the DS. see, the TCP/IP protocol is actually a bit complex in terms of what all it can support, hence why it is used for general internet communcations. to create a more basic sollution, it appears as tho nintendo came up with their own alternative to TCP/IP. now, this doesnt mean that they wont use TCP/IP in future games (they already said there will eventually be internet based games, wich TCP/IP is a requirement for), but this is on a per-game basis, and nothing out there right now uses such a protocol yet.

The reason why we are able to capture packets from the DS right now is because we are doing this at Layer 2 (like a MAC dump), not Layer 3 (like a TCP dump). this bypasses any sort of protocol translations, and gives us raw binary data to work with.

As always, visit his page for the full details.

Update by Darkain on WiFi progress

Darkain has updated his DS Wi-Fi hacking page and offers this glumy prognosis:

I have also been in contact with several developers that are all exploring possible ideas of way to do bi-directional communication with the DS. As of now, we have only been have to do packet sniffing. I will be blunt on this one: I personally think at this time that we may not have a way to communicate with the DS on the Windows platform, and even on Linux, it may require the use of custom made drivers just for this purpose. Not only this, but only a few select cards will work with the current ideas we are playing around with.

Check his page for more detail. Obviously nothing was ever gauranteed and at the moment I still am optimistic that something will be worked out.

As I've noted (read: complained) in other places, it's not clear that there is full cooperation and disclosure amongst everyone working on the DS hacking efforts. Unfortunately people tend to get a little cliqueish about these things. There are many hands on the monster that is the DS hacking scene and I am not sure which of them is aware what the others are doing.

To be fair however, this is not true of everyone, Darkain and many others on gbadev's DSDev forum, Warp Pipe and sometimes #dsdev on EFNet have been very open about their progress. In any case, chin up!

DS Cart Pin Mappings

UPDATE: This post is somewhat deprecated and you should check the thread over at DSDev for the latest conclusions.

TauZero has molested his Metroid cart to bring you the potential pin mappings:

Starting from the left, pins facing you:
Pin 1   -> GND
Pin 2   -> pin 5 of ROM and pin 6 of the EE (EE CLK)
Pin 3   -> pin 17 of ROM
Pin 4   -> pin 44 of ROM
Pin 5   -> pin 42 of ROM
Pin 6   -> pin 1 of EE (EE CS)
Pin 7   -> GND
Pin 8   -> VCC
Pin 9   -> pin 18 of ROM
Pin 10 -> pin 19 of ROM
Pin 11 -> pin 20 of ROM
Pin 12 -> pin 21 of ROM
Pin 13 -> pin 24 of ROM
Pin 14 -> pin 25 of ROM
Pin 15 -> pin 26 of ROM and pin 2 of EE (EE DOUT)
Pin 16 -> pin 27 of ROM and pin 5 of EE (EE DIN)
Pin 17 -> GND

For more of his thoughts on what this means continue reading the DS Cart Pinout thread over at gbadev's DSDev forum.

DS/ARM9 Speculation

phantom-inker posted speculatory musings on the DS' core CPU, which is an ARM9E-S. Myself and others have responded with some thoughts. There's enough interesting banter that the topic is worth pointing out. The interesting questions (at least in my mind) are:

• What practical performance penalty (if any) will manifest itself as a result of the increased number of pipeline stages (5 instead of the ARM7's 3)?

• What will the ARM9's special "protected" mode be used for, and does it require an MMU? So far the concensus on the DS was that it doesn't have an MMU, and this makes sense (to me at least) for the reasons I pointed out in the thread, namely that when one thinks of an MMU, virtual memory immediately comes to mind.

Given that there is no need for multiple processes to be running on the DS (as there might be for other ARM9 devices such as phones or PDAs running Symbian or Palm OSes), and given that there is no storage device (since carts are more or less a range of addressable memory as was the case on the GBA), there probably is not a need for an MMU. But maybe the MMU is required for the memory masking that the "protected" mode provides?

I have other questions about the fact that the ARM9 is using the Harvard architecture by offering seperate caches for instructions (8KB) and data (4KB). The GBA used the ARM7 which sported the classic Von Neumann architecture, exposing a single cache for data and instructions.

UPDATE: phantom-ink clarifies the implementation of the DS' protected mode and confirms that the DS' ARM9E-S does not have an MMU.