Docstoc

HOMEBREW COMPUTING AND THE NINTENDO DS

Document Sample
HOMEBREW COMPUTING AND THE NINTENDO DS Powered By Docstoc
					               HOMEBREW COMPUTING AND THE NINTENDO DS:

                            Programming and Controlling
                        a Dedicated-Purpose Computer System




                                Craig Schroeder and Luke Walker

                               CIT 595, University of Pennsylvania
                                         April 28, 2008




                                           ABSTRACT

       Portable video game systems are not only a multibillion-dollar computer industry, but also
an attractive platform to enable people with knowledge of computer organization and architecture
to develop innovative software applications.     The authors show how so-called "homebrew"
computing has led to significant innovations in computer science, and, by explaining the
organization and architecture of the Nintendo DS, show how this game system is, in many ways,
an ideal homebrew computing device.         In addition, readers with an interest in homebrew
computing are provided a guide to getting started with programming for the DS platform.
                                                               CONTENTS




Introduction and Motivation ......................................................................................................... 1

Historical Perspective on Homebrew Computing ........................................................................... 3

Nintendo DS Organization and Architecture ................................................................................. 5

Developing Homebrew Software for the DS .................................................................................. 8

Conclusion ................................................................................................................................ 15

References ................................................................................................................................. 16

Appendices................................................................................................................................ 18
                                 INTRODUCTION AND MOTIVATION


        Most people who own a Nintendo DS probably don't think of it as a computer. It is sold
and marketed, after all, as a game system – a device that children and adults use to enjoy the fun
and distraction of playing video games. But the DS is, of course, also a computer – one that has
been carefully optimized for the rigors of real time input and output, and complex video and
sound processing. Those who understand the DS and its games in this way, and have a reasonable
amount of technical knowledge and skill, are more likely to take on the challenge of programming
their own code for the device, rather than just passively playing with the prepackaged diversions
that are officially sanctioned for the system.


        There are two sets of motivations for developing an understanding of the Nintendo DS
platform. The extrinsic motivators are the professional and financial opportunities that come from
understanding the technology. The DS was released in 2004. By the end of 2007, Nintendo had
sold 70.6 million DS units worldwide. At a suggested list price of $130, with some allowance for
discount pricing, this sales volume represents more than $8.5 billion in sales revenue over a 4-year
period. Add to this the 185 million game packs sold by Nintendo and other game software
companies, and it is clear that the DS product alone represents a successful business model. Last
year, in fact, commercial developers introduced 342 new games for the DS (Hall) . Successful
large-scale business ventures bring employment opportunities, and students of computer
technology will realize that these game companies require talented software developers in order to
create new products. By understanding the technology behind the DS platform, a programmer or
designer will vastly expand his or her career prospects in this field.


        Perhaps more importantly, many people find significant intrinsic motivations for
understanding the technology behind computing devices.                   People who are interested in
technology find it natural to want to understand and master the technological devices they use in
their lives – and once they understand them, they often seek to control them, to use them as tools
to do the things that they want.         On a philosophical level, technological innovations are
extensions of human brainpower, a set of tools that people have developed to get things done
more effectively. Further, from a political and cultural standpoint, individuals who are able to



                                                                                                    1
master and control tools are more empowered to control their own lives than those who are
dependent on others. This human striving for innovation, for intellectual mastery, even for status
among one’s peers, has led during the age of the computer to the homebrew computing
movement.
       Homebrew computing is the pursuit of innovation for its own sake – the challenge of
mastering, controlling, and improving upon everyday technology. It is about empowering the
individual. Homebrew computing is something that people do for fun, for intellectual challenge,
and for bragging rights, not to get paid, and for this reason games are particularly appealing to
homebrew enthusiasts because they are fun and challenging at the same time. Today, because the
Nintendo DS is small, relatively powerful, manageable, and inexpensive, it is an attractive
homebrew computing platform.




2
                   HISTORICAL PERSPECTIVE ON HOMEBREW COMPUTING


       “Amateur Computer users Group, Homebrew Computer Club…you name it. Are
       you building your own computer? Terminal, TV typewriter? I/O Device? or some
       other digital black-magic box? … If so, you might like to come to a gathering of
       people with like-minded interests. Exchange information, swap ideas, talk shop,
       help work on a project, whatever…”
               From a 1975 flyer announcing the formation of the Homebrew Computer
               Club (qtd. in Markoff, 275-6)


Early Homebrew Video Games Create an Industry
       Almost as long as there have been computers, there have been people who have found
ways, in their own free time, to make computers play games. In 1958, Willy Higinbotham, a
physicist at the Brookhaven National Laboratories in New York, created an interactive tennis-like
game, displayed on a oscilloscope, to amuse visitors. In 1962, students and staff at MIT developed
“Spacewar!” (a forerunner of the popular Asteroids game) in their spare time, on a donated Digital
Equipment Company (DEC) PDP-1 computer.           And in 1966, television engineer Ralph Baer
continued work on an idea he had in 1951 to add an interactive game to television sets – a game
that in 1972 would become “Pong,” the first commercial video game. (Herman, Horvitz, Kent,
and Miller)


“Space Travel” and the Development of Unix
       Computing pioneer Dennis Richie reports that one of the reasons that he and Ken
Thompson developed the Unix operating system in 1969 was to play “Space Travel,” a video
game that Thompson had written in his spare time. (pars. 7-8) The game required a file system
and an operating system that could run multiple processes concurrently. Unix quickly became an
industry standard, and the features that were initially built for a homebrew game paved the way for
multi-user mainframe computing in the 1970s and the development of window-based operating
systems in the 1980s.




                                                                                                 3
The Homebrew Computer Club and the First Personal Computers
       Apple co-founder Steve Wozniak, an early member of the Homebrew Computer Club,
explains that the first personal computers were developed solely as homebrew projects:


       “The Apple I and II were designed strictly on a hobby, for-fun basis, not to be a
       product for a company. They were meant to bring down to the [Homebrew
       Computer] club…and demonstrate: Look at this, it uses very few chips. It's got a
       video screen. You can type stuff on it. Personal computer keyboards and video
       screens were not well established then. There was a lot of showing off to other
       members of the club. Schematics of the Apple I were passed around freely, and I'd
       even go over to people's houses and help them build their own.” (par. 4)


       When Wozniak and partner Steve Jobs began work on the Apple II computer, they had the
idea to include a version of an arcade game, Breakout, that they had written for Atari. Wozniak
recalls that they decided to include color, sound, and graphics mode commands in the Apple II
solely to be able to play this homebrew game and show it off to other club members:


        “All of these features were basically just to play one game. These turned out to be
       common features for the personal computers that have come out since that
       time.“(par. 14)


       The early pioneers of homebrew computing believed in the power of the individual, and
the homebrew movement that combined efforts towards social change, human rights,
empowerment and technology. (Markoff, 254-287) The personal computer movement that grew
out of this has brought computing power to a great many people in the world. Although the
corporations that make and market computers would prefer that consumers just buy them and use
them, the individuals who understand and embrace technology continue to find ways to take them
apart, put them back together, reprogram and sometimes even improve them.


       Today, many homebrew enthusiasts have turned their attention to a small, inexpensive,
relatively manageable device – the Nintendo DS. To understand the appeal of the DS to
homebrewers, we must start by understanding the device’s organization and architecture.




4
                     NINTENDO DS ORGANIZATION             AND   ARCHITECTURE


Two-CPU Design
       Processing responsibilities for the DS are split between two CPUs, an ARM9 and an ARM7.
The ARM9 has a 67 MHz speed and processes up to 300 MIPS. It is a RISC chip with the ability to
handle 32-bit ARM instruction sets or the 16-bit Thumb instruction set, which allows up to 40%
improvement in code density. The ARM9 is optimized for low-power applications such as battery-
powered portable devices.       It incorporates a Harvard architecture, which sends data and
instructions over separate bus lines, improving its efficiency and processing capability. The ARM9
chip does most computation-intensive tasks for the DS, including graphics and the 3D rendering
engine. (ARM9, ARM Tech., OSDL)


       The other CPU is a ARM7, with a 33 MHz speed and 20 MIPS. Like the more-powerful
ARM9, the ARM7 is a RISC chip with 32-bit ARM instruction sets or 16-bit Thumb instructions.
However, the ARM7 uses a von Neumann architecture, which means that data and instructions
must share the same bus.      Because of its slower speed and throughput, the ARM7 is given
responsibility for tasks that are less computationally-intensive, including input management,
wireless communications, audio output, and the DS’s backwards-compatibility with its legacy
predecessor, the GameBoy Advance. (ARM7, ARM Tech., OSDL)


Innovative Input/Output Capabilities
       The nature of video games requires that a player maintain constant real-time interaction
with the process currently running on the system. By including technologically innovative input
and output devices, the Nintendo DS enables the player to interact using several senses at once,
creating a compelling and immersive gameplay environment. The device includes two, rather
than the usual one, back-lighted display screens, and the lower screen is built with an integrated
resistive touchpad for onscreen input with a stylus.           Twelve input buttons are grouped
ergonomically and by function. Sixteen-channel stereo sound is provided through integrated
speakers, and the user can even speak back to the DS through an integrated microphone which
utilizes the device’s application-specific speech recognition capabilities. (Nintendo)




                                                                                                5
Dedicated Graphics Processing Unit
          Because most games strive to provide the most realistic on-screen images possible, and
because high-resolution graphics require a large amount of processing power, Nintendo has
integrated a high-quality custom Graphical Processing Unit (GPU) into the main processor of the
DS. This GPU has three roles: 2D graphics for the top screen, separate 2D graphics for the
bottom screen, and an advanced rendering system to enable game programs to include more
sophisticated three-dimensional images. It is organized around two separate graphics cores: the
Sub core, which handles 2D graphics, and the more-powerful Main core, which manages 2D
graphics as well as the 3D rendering engine. The Main core is also capable of bypassing the 2D
engine and writing directly to the screen from memory, in frame buffer mode. Overall, the GPU is
capable of rendering up to 120,000 triangles per second at 60 frames per second, with a total fill
rate of about 30 million pixels per second. Given the relatively small screen size of the DS, this
processing power enables developers to add relatively sophisticated graphical features to game
programs, including fog and lighting effects, and texture, shading, and anti-aliasing processes.
(OSDL)


Integrated Wireless Communication
          The ability to communicate wirelessly with other users and to share data across networks is
another innovative feature of the DS.        The device offers integrated connectivity through two
wireless protocols: a proprietary wireless protocol for local communication with other DSs within
a 10-30 yard range, and the industry-standard 802.11b WiFi for internet and other network
communications. (Nintendo)


Multiple Special-Purpose Memory Banks
          Processing power and efficiency on the DS is enhanced by the use of several dedicated
memory banks. The system begins with 4MB of built-in RAM for main memory, which is shared
between the two CPUs but cannot be accessed by both at the same time.                  To resolve bus
conflicts, developers designate one processor to have priority and require the other to wait for
access.


          Each processor also has dedicated memory available.          The ARM9, with its Harvard
architecture, has two caches – one for data and one for instructions. It also has access to a 16KB



6
Data Tightly Coupled Memory (DTCM) and a 32KB Instruction Tightly Coupled Memory (ITCM),
which store, respectively, the ARM9’s stack and complex instructions. The ARM7 has a 64KB
Internal Working Ram (IWRAM) bank that contains its code and data. In addition, there are two
small (16KB) banks of fast RAM that can be assigned to either the ARM9 or ARM7.


       As mentioned earlier, rendering realistic graphics is the most daunting challenge for the DS
processors. Accordingly, graphics is a priority for memory, with 656KB of dedicated video RAM
available in 9 individually-accessible memory banks. Although the amount of video-only memory
is somewhat limited, the flexibility of this 9-bank system is designed to enable developers to make
the most efficient use of the available video RAM. (OSDL)


Dual External Memory Ports
       The DS has two external memory ports to access external process code (which the typical
user would call “video games.”)      Slot 1 reads DS-specific 256MB proprietary flash memory
cartridges, while Slot 2 reads 32MB GameBoy Advance cartridges to enable backwards
compatibility with games written for Nintendo’s very popular legacy portable game system.
(Nintendo, OSDL)


Summary: The Nintendo DS Data Path
       Please refer to Appendix B for a detailed diagram of the data path and memory map.




                                                                                                 7
                        DEVELOPING HOMEBREW SOFTWARE FOR THE DS

        “It is a shame that homebrew development can't be officially sanctioned and
        supported, because it would be a wonderful platform for a modern generation of
        programmers to be able to get a real feel for low level design work, to be contrasted
        with the high level web and application work that so many entry level people start
        with.”
                 John Carmack, Gaming Tech Guru,
                 best known for his work on Doom, Quake and Wolfenstein 3D (Harris, par. 7)


        It is important to note that the Nintendo DS is not meant to be a homebrew device.
Nintendo’s business model has always been geared towards the value and quality of its software
and games. The company traditionally, and intentionally, loses money on the sale of each console
or handheld device (Surette). This loss is made up for in sales of games and applications for the
device. Considering this, it is understandable that Nintendo does not support the unauthorized
development of software and hardware interfaces for the DS. Unfortunately the completely legal
tools that have been developed via reverse engineering, that allow homebrew enthusiasts to
becoming knowledgeable about the hardware of the DS and harness its power, also allow people
to engage in illegal acts of software piracy (Amero, pars. 8 - 12).


        Up until very recently, The DS and the PlayStation Portable (PSP) have been the homebrew
devices of choice. Since Apple’s release of the iPhone, and more importantly the release of a
robust, and fully supported SDK for the device, many brewer’s have geared their efforts into
developing iPhone applications. One might ask: Why don’t all homebrewers just ‘upgrade’ and
gear their efforts towards developing for the iPhone? There are many reasons why the DS remains
a much more attractive option for the homebrew community. Probably the most significant
characteristic of the DS that makes it an ideal homebrew device is the price. The current price of a
Nintendo DS is about $130. Even after adding the cost of some necessary homebrew accessories
(a NoPass device, and MicroSD card), the total cost to get started is still less than half the cost of
an iPhone, which is $400 - $500 not including cellular service charges.


        One must realize that homebrew computing is a grassroots movement that started in the



8
1970s. One of the underlying goals of the movement was, and in some sense still is, to bring
computing power into the hands of the people, rather than just letting it be a tool to maintain the
supremacy of large corporations and other institutions. In light of this, a portable, affordable, mass
distributed computer, such as the DS, is an ideal device to sustain the practice of, and uphold the
ideals of, homebrew computing.


        The Nintendo DS, with its dual CPUs, multiple GPUs, and complex memory structure,
presents the homebrewer with many unusual development challenges. Homebrewer John Iversen
put it best:


        “Programming for the DS is possibly one of the purest coding experiences out there
        at this time. There is no operating system between the developer and the ’bits &
        chips.’”


In light of this, the available libraries are indispensable. However, even with these libraries, it is
not possible to write code that will work without some knowledge of what is happening at a very
low-level within the DS.


        There are two ways to develop games or applications for the Nintendo DS: acquire the
official development kit from Nintendo; or use some of the unofficial development kits that have
been made available by members of the homebrew computing community. The first option
requires an exclusive agreement with Nintendo: a developer purchases an official development
kit at significant cost and produces games with the goal of marketing them commercially (Amero,
par 6). The second option is completely free. The unofficial toolkits have been developed by
dedicated homebrewers who spent weeks reverse engineering the DS hardware in order to allow
themselves and others to harness the power of the DS (Amero par. 7). These development
endeavors are completely legal. However, as mentioned previously, some of these technologies
can and have been used to commit illegal actions such as pirating software, which the authors of
this paper strongly oppose.


How to run homebrew programs on the Nintendo DS
        A number of approaches have been developed to allow homebrewers to run their
programs on the DS. By far, the simplest option is to use a “NoPass” device. These are “Slot-1


                                                                                                    9
devices”, that fit into the smaller DS cartridge slot rather than the legacy GBA slot. They do not
bypass the copy-protection of the DS, rather they contain code that is encrypted in the same
manner as a normal DS cartridge thanks to the reverse engineering efforts of homebrewer Martin
Korth (Amero par. 20). These cards look like normal DS cartridges and usually have a micro-SD
slot which you can use to move files back and forth from a PC. They also come with preloaded
software that allows you to browse, manage & run files on the DS.


       Before the “NoPass” method, homebrewers used “PassThrough” devices which allowed
them to put their DS programs on “Slot-2” cards. This approach used the unencrypted legacy
GameBoy Advance slot to bypass the security system. Slot-2 devices require more power, and
there are many different ones for different Nintendo DS hardware releases, so this is not the best
way to go. Many of these cards (both slot types) support Wi-Fi transfer methods, which make the
transfer process go more smoothly. A final alternative is to use one of many readily available PC-
based Nintendo DS emulators.


       Additionally, if you plan to write or use programs that require more RAM than the 4MB
main memory provides, you can buy special GBA cartridges which act as an additional 32MB of
RAM at approximately the same performance speeds as the main memory. This is necessary if you
plan to run the popular homebrew application DSLinux (www.dslinux.org) on your console.


The ToolKits You’ll Need


devkitPro
       devkitPro is a collection of development toolchains for a variety of handheld and console
systems. For the DS you’ll need devkitARM, which allows the compiling of ARM binaries, and is
based on gcc, the gnu compiler collection (Amero ch. 4, par. 2). Theoretically, devkitARM is all
you need to get started. That is, if you want to write all your code in ARM assembly. You’ll need
devkitARM because it contains the tools you’ll need to generate the object files (machine code)
that will run on the DS. However, to avoid unnecessary tedium, you’ll probably want to write your
code in a slightly higher-level language. In that case devkitARM also includes the compiling tools
that allow you to write DS specific programs in C or C++. To use standard functions that
devkitARM offers you must specify #include <stdlib.h> in your source files (OSDL).




10
libnds
         libnds is a library developed by Michael Noland (joat), Jason Rogers (dovoto), and Dave
Murphy (WinterMute) (Amero ch. 4, par. 3). It is a relatively thin abstraction layer that started as a
collection of ‘defines’ for common memory locations in the DS. More recently libnds has been
improved with the addition of some structs and unions that help simplify the programmers job
(Amero ch. 4, par. 4). While devkitARM allows you to use the usual C/C++ constructs, libnds gives
us access to text output, graphics, touchpad, and other DS-specific constructs. The source package
of libnds also provides starter code including a basic ARM7 executable, if you simply want the
ARM7 to do its usual IO management (OSDL).


libfat
         You may want write applications for the DS, that save high-scores, or modify graphic files.
Doing this requires reading and writing to non-volatile media, and to access it as a file-system. To
manage such a file-system in your DS code, libfat is the recommended library (OSDL).


PAlib
         PAlib is a library of constructs, functions and media built on top of libnds. It is a much
higher level abstraction from the hardware, providing many convenience functions from collision
detection and gravity simulation to a virtual keyboard, and hand-writing shape recognition
(OSDL). If your goals in developing for the DS include intimately acquainting yourself with its
unique hardware set-up, stick with libnds for your first few programs. Also, if you are concerned
about performance, you may want to use PAlib sparingly. On the other hand, if you are eager to
develop an application for the DS with advanced features relatively quickly, making use of PAlib is
recommended.


Two main() functions
         The two CPUs on the DS require two separate main functions. The ARM7 is solely
responsible for touch screen input, microphone, sound playback, wireless communications, and
the real-time clock (OSDL). Because libraries are readily available, there is rarely a need to write
custom code for the ARM7. The boiler-plate code provided in the toolkits sets reserved memory
registers that correspond to button presses and releases, and records values of the touch-screen
parameters, then stores them in a data-structure that can be accessed by the ARM9 (OSDL).



                                                                                                   11
     The main() function for the ARM9, the main processor, is responsible for the bulk of
application code. Generally, it includes (OSDL):
     1. Initialization
             a. To set screen modes, memory banks, interrupt handlers, initialize various libraries,
                 load resources, set up Wi-Fi connections, etc.
     2. Main Program Loop
             a. Game Logic
             b. Input Management
             c. Audio and Video Rendering
             d. I/O exchanges
     3. Shut Down
             a. Stops all sub-systems properly, flushing buffers, disconnecting Wi-Fi, etc.


Inter-CPU communication
         Because each CPU has specific abilities, they need some way of communicating with each
other. For example, since the ARM7 has the exclusive responsibility of managing the Wi-Fi
connection, in order for programs to interact with programs on other wirelessly connected devices,
the ARM9 needs to send data to other devices through the ARM7. Conversely any data coming
from the other devices is accessed first by the ARM7 and then communicated to the ARM9.


         The CPUs communicate using IPC (inter-process communications) based on a set of
registers (in this case, just reserved main memory locations) which are managed using a FIFO data
structure (OSDL). IPC is a set of techniques for the exchange of data among two or more threads
in one or more processes (Ramachandran, Solomon, and Vernon, 178-188). In light of this, it may
be helpful to think of the two main() functions as two ‘threads’ of one primary “process.” There are
many methods of IPC, the DS uses the “Message Queue” method. This method provides an
asynchronous communications protocol, which means that the sender and the receiver of the
message do not need to interact with the queue at the same time (OSDL). This has programming
implications, because the developer has to decide whether a program should wait for expected
data, or simply access it when it becomes available and continue doing whatever it was doing in
the meantime.



12
       One particularly tricky aspect of inter-CPU communication on the DS is the fact that the
ARM7 is not aware of a small stash of tightly coupled memory that the ARM9 has access to. This
could lead to inconsistencies when using the main memory to share data. There are a number of
ways to avoid this problem. A simple solution is to allocate memory from ARM9 code and, when
doing so, use a section of memory called the “non-cached main memory mirror” (0x02400000 –
0x02400000). However, this will slow down processing considerably because you are not taking
advantage of speedier memory resources (OSDL).


Managing Memory
       Memory management is one area where the available libraries make a DS developers life
much easier. The memory structure of the DS is quite complicated, and many of the ‘defines’,
‘structs’, and functions provided give understandable names to various memory locations. Initially,
for most cases, the ARM9 executable is loaded into the 4MB main memory along with most game
data. The ARM7 executable can also be loaded into main memory, however, for performance
reasons it is often placed into the ARM7’s IWRAM (see attached memory map). When using the
devkitARMs boiler-plate code for ARM7, this is the case. If for some reason you alter, or customize
your ARM7 code, it is best to keep it small enough to fit in the ARM7’s IWRAM (64K) (OSDL).


       Another important memory component for developers to consider is the ITCM (Instruction
Tightly-Coupled Memory) of the ARM9. This is a special 32K memory module which can be
mapped to various actual physical addresses. There are commands & macros provided in libnds,
and PAlib to specify important blocks of code that will be called frequently and thus should be
stored in this special section of memory. For example, if you are using libnds the following code
will specify an ITCM function (OSDL):
                      void myITCMfunction()ITCM_CODE;
                      void myITCMfunction() { ... }


Interrupts
       The DS hardware makes considerable use of interrupts as opposed to polling in order to
optimize user-interaction and system performance. Libnds stores its higher-level interrupt
management code in the ITCM. This keeps these functions running as fast as possible, so as to



                                                                                                13
avoid being interrupted themselves. The DS supports 23 different hardware interrupts based on
various events. A few examples of these events are: screen-related (i.e. when an entire screen, or
specified number of lines has finished displaying), network-related, input-related (when keys
pressed match a user-specified mask), or even lid-related (when the DS lid is closed or opened)
(OSDL).


       In many applications the ARM9 main() function contains a while() loop with a command at
the end of each cycle that instructs the main CPU to wait until a Vertical Blank Interrupt (fired
once a full screen has been redrawn) (Amero ch. 5 par. 3).


       Developers can also make use of software interrupts, which allow immediate calls to BIOS
functions. These are libnds functions that branch directly to functions defined in the DS BIOS.
Using these functions allows your program to be smaller in memory (OSDL).


Your first homebrew program
       We’ve only just scratched the surface of development for the DS. As is the case with most
software development processes, the best way to learn is to dive right in and write a program. To
help the readers of this report in this process, we have written a concise quick-start guide for the
beginning DS homebrewer, which is included in this report as Appendix C.




14
                                         CONCLUSION



        In the computer industry, innovation often has come from talented individuals who are
motivated not solely by money, but by the intellectual challenge of discovering, understanding
and improving upon technology. This challenge is well known to students, educators, hobbyists,
and professional engineers. Although necessity, as the saying goes, may be the mother of
invention, we believe that play and discovery play an equally important role in moving technology
forward in our modern age.       As an extension of our human capabilities, the computer has
empowered individuals to take the lead, in their own way and according to their own interests, in
shaping the technological innovations that drive our economy and our culture.


        Today the Nintendo DS, with its many features and affordable cost, is a device of choice
for homebrew enthusiasts. We have reviewed the organization and architecture of this special-
purpose computer, and shown readers how to get started with understanding its capabilities and
creating their own innovations. Since the introduction of the DS in 2004, many homebrew
computing hobbyists have created their own innovations on the platform, and many more have
improved their understanding of computer technology just by learning about the possibilities that
this system offers. We challenge the reader to take the next step – to take the tools of homebrew
computing and create his or her own code for the DS – and we look forward to the innovations
that will follow.




                                                                                              15
                                           REFERENCES




Amero, Jaeden. “Introduction to Nintendo DS Programming.” 24 April 2008
       http://patater.com/manual


“ARM7 Family.” ARM. 24 April 2008.
       http://www.arm.com/products/CPUs/families/ARM7Family.htm


“ARM9 Family.” ARM. 24 April 2008.
       http://www.arm.com/products/CPUs/families/ARM9Family.htm


“ARM Technical Support FAQs: What is the difference between a von Neumann architecture and
       a Harvard architecture?” ARM. 24 April 2008.
       http://www.arm.com/support/faqip/3738.html


Harris, Craig. “John Carmack on the Nintendo DS: The gaming tech guru chats up the dual screen
       handheld in our exclusive interview.” IGN.COM UK. November 2007.
       14 April 2008. http://uk.ds.ign.com/articles/833/833894p1.html


Hall, Kenji. “Nintendo Rakes it In… But For How Long?” Business Week. 24 April 2008.
       http://www.businessweek.com/innovate/gamesinc/archives/2008/04/nintendo_rakes.html


Herman, Leonard; Horwitz, Jer; Kent, Steve; and Miller, Skyler. “The History of Video Games.”
       CNET Networks, Inc. 24 April 2008
       http://www.gamespot.com/gamespot/features/video/hov/


Iversen, John. 20 April 2008. Personal interview.


Markoff, John. What the Dormouse Said: How the 60s Counterculture Shaped the Personal
       Computer Industry. New York: Viking Penguin, 2005.


16
“Nintendo DS Features.” Nintendo of America, Inc. 24 April 2008
       http://www.nintendo.com/ds/what/features


Object-Oriented Simple Direct Media Library Project (OSDL), “A Guide to Homebrew
       Development for the Nintendo DS.” 24 April 2008
       http://osdl.sourceforge.net/main/documentation/misc/nintendo-DS/homebrew-
       guide/HomebrewForDS.html


Ramachandran, U.; Solomon, M.; Vernon, M. “Hardware Support for Interprocess
       Communication.” Proceedings of the 14th Annual International Symposium on Computer
       Architecture. 1987.


Richie, Dennis. “The Evolution of the Unix Time-Sharing System.” Bell Laboratories. September
       1979. 24 April 2008 http://cm.bell-labs.com/cm/cs/who/dmr/hist.html


Surette, Tim. “Reggie: Wii makes $$$ immediately: Nintendo not waiting around for market share,
       production efficiency to make money on next-gen console; cash will be made “out of the
       box.” GameSpot News. September 2006.
       24 April 2008 http://www.gamespot.com/news/6157690.html


Wozniak, Stephen. “Homebrew and How the Apple Came to Be.” Edited by Ditlea, Steve. Digital
       Deli: The Comprehensive, User-Lovable Menu of Computer Lore, Culture, Lifestyles and
       Fancy. New York: Workman, 1984. 24 April 2008
       http://www.atariarchives.org/deli/homebrew_and_how_the_apple.php




                                                                                                  17
                                                           APPENDICES




A. Project Task Summary ........................................................................................................... 19

B. Nintendo DS Memory Map.................................................................................................... 20

C. QuickStart Guide .................................................................................................................. 21




18
                                     PROJECT TASK SUMMARY



       We collaborated fully on this project, using Google Docs to create online documents that
could be written and edited by both of us throughout the semester.


Project Planning
       After agreeing on our project topic, we worked together to draft an outline of the scope of
our research. This outline, which we submitted to our instructor for approval, was the basis for
our research throughout the semester. As our research progressed, we refined the scope of our
original outline, notably excluding information on other game systems so that we could focus
more on the architectural and programming aspects of the DS platform.


Primary Research
       Although we searched for documents that had been published in books and written
periodicals, we found that the majority of the first-person research was available only in online
websites. This is not unusual, given that homebrew computing is a constantly evolving field
characterized by decentralized individual innovation and decision-making. To improve research
efficiency, we decided that Luke would take the lead on DS coding research, while Craig would
lead the research into homebrew innovations. Both project members did extensive research on
the topic, independently and in collaboration with each other.


Preparation of Presentation Materials and Class Presentation
       Both project members collaborated equally on preparing the class presentation,
PowerPoint slides, and handouts.


Written Report
       Both project members collaborated equally on writing and editing the written report.




                                                                                                     19
Illustration from http://www.dev-scene.com/NDS/Tutorials_Day_2#Memory_Layout


20
                                          QUICKSTART GUIDE


For the benefit of our readers who are anxious to dive right into development on the DS, this
section provides a condensed guide to getting up and running.


What you need:
Hardware:
    •   A Nintendo DS, preferably a DS Lite which is smaller, has brighter screens, and a more
        comfortable stylus.
            o    Note: You can also use a DS emulator for your PC, however these are not without
                 their quirks. (Ensata, ideas & DeSmuME are a few ordered by popularity)
            o    If you decide to try an emulator – skip down to software
    •   A “NoPass” Device
            o    Since this is the “QuickStart” section  get a slot-1 device with a micro-sd card
                 slot, these work on all DS models, with no problems.
            o    Electrobee.com is one of many retailers that sell these devices
    •   A micro-sd card and some way to read it on your PC
Software:
    •   devkitARM
    •   libnds
    •   optional libraries: libfat, dswifi, PAlib
            o    Note: PAlib is designed to work on windows (.Net environment) so getting it to
                 work on Mac or Linux requires a bit of extra work.


        With devkitARM and libnds installed you have all you need to start developing programs
on the DS. It is left as an exercise to the reader to make use of the libnds API –
http://libnds.devkitpro.org and the DSWiki http://www.tobw.net/dswiki/ for building and compiling
his/her applications.


        Once you’ve done this, transfer your <file>.nds to your NoPass device, turn on your DS
and run your code!




                                                                                               21

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:170
posted:2/14/2010
language:English
pages:23
Description: Portable video game systems are not only a multibillion-dollar computer industry, but alsoan attractive platform to enable people with knowledge of computer organization and architectureto develop innovative software applications. The authors show how so-called “homebrew” computing has led to significant innovations in computer science, and, by explaining theorganization and architecture of the Nintendo DS, show how this game system is, in many ways,an ideal homebrew computing device. In addition, readers with an interest in homebrewcomputing are provided a guide to getting started with programming for the DS platform.