So in my last entry, I hinted at some projects I had been mulling over. One of those ideas was DS.NET, a port of the .NET Micro Framework (NETMF) to the Nintendo DS (NDS) hardware platform. The NDS is a nifty little piece of hardware with two processors (ARM7, ARM9), two LCD screens (one with touch input), sound I/O and 802.11b Wireless Ethernet.

The real reason NETMF should be ported to the NDS is that in doing so, the ability for homebrew application development would become easier for those interested in programming for the NDS. No fiddling around with different graphics modes and control registers, just pure managed C#.

So, in this article I'll briefly explain what NETMF is, what I think is required to port the NETMF platform to the NDS, and the next steps in the DS.NET project. Now I wont make any promises that there will be a port of the framework, but hey, it's not like I wont give it a go!

.NET Micro Framework

In a nutshell, NETMF is a significantly pared-down version of the .NET BCL running on an CIL interpreter geared towards embedded devices ("bare metal"). The framework can be booted from flash memory and allows applications running in the interpreter to access the underlying hardware through managed drivers. Figure 1 below illustrates the layered levels of the framework:

So the topmost layer is, as with NETMF's bigger brothers the Compact Framework and the Full framework. the application layer where managed user code executes. To develop applications for NETMF devices requires the NETMF SDK. Directly underneath is the library-level layer, where the .NET Base Class Library (BCL), Windows Presentation Foundation (WPF) and harware-specific libraries are. In the runtime component layer lies the Common Language Runtime (CLR), the Platform Abstraction Layer (PAL), and the Hardware Abstraction Layer (HAL). It could probably be said that each of these three components are separate layers themselves, but hey, whatever floats MS's boat right?

Nintendo DS

Homebrew software development for the NDS has been around for a long time, with hundreds of hackers reverse-engineering the hidden proprietary magic inside. So, what has the NDS got to offer the DS.NET developer?

An [ARM946E-S](http://www.arm.com/products/processors/classic/arm9/arm946.php) processor running at 67Mhz, typically used to handle application execution (including graphical routines)
An [ARM7TDMI](http://www.arm.com/products/processors/classic/arm7/arm7tdmi.php) processor running at 33Mhz, typically used to handle on-board device management
Multiple graphics interfaces, including a 3D renderer and two 2D renderers
4MB of EWRAM shared between both cores
16kB of ITCM used to store frequently-used routines and accessable only to the ARM9 core
16kB of DTCM used to store frequently-used variables and acessable only to the ARM9 core
64kB of IWRAM fast memory than is accessable only by the ARM7 core
2×16kB banks of WRAM which can mapped to the memory space of either core
656kB VRAM split into multiple banks for varying purposes
802.11b Wireless Ethernet

All this memory can be confusing! Thankfully, the folks over at Dev-Scene.com have illustrated the memory configuration of the NDS. Basically, the ITCM and DTCM memories act as an L2 cache for the ARM9 processor, with the IWRAM acting as a shared Instruction/Data cache for the ARM7 processor.

A whole lotta work

So, there are a number of considerations even thinking about porting NETMF to the DS. Firstly, we are dealing with a multiprocessor system: this means division of labor and synchronization. So knowing that the ARM7 processor has exclusive access to the I/O devices of the system, let's assign the ARM7 it's own BSP and make it responsible to the ARM9 processor as a slave. Operating as a slave, we'll make the ARM9 processor the master which will run all applications and will have its own BSP. Secondly, the toolchain is going to be annoying. A whole bunch of code will be required from DevKitPro/ndslib/ndswifi/ndsfat.