Game Boy
Mark Green
School of Creative Media
City University of Hong Kong
Introduction
Probably the most successful console:
Largest number of sales
Longest life
Basicallyowns the mobile game console
market, even Sony is having a hard time
competing against it
Sega was knocked out of the market,
Nokia hasn’t made much progress
Introduction
Despite its size, Game Boy has all of the
characteristics of larger game consoles
Technology isn’t as advanced, one or two
generations behind
But, game development, marketing,
production and other aspects are all the
same
Good case study for mobile games and
consoles
Introduction
Thereare two main differences between
the Game Boy and other consoles:
We know a lot about the Game Boy internals,
the hardware used and how it can be
programmed
There are a number of free and inexpensive
tools that can be used to develop Game Boy
games
place to learn console game
Ideal
development
Console Games
Console game development is different
from PC games, not a lot of companies do
both
Consoles are designed to be cheap, a
small savings on one unit means a lot
when you are making millions
Try to do clever engineering to reduce
costs, don’t care if its easy to program
Console Games
Consoles can’t be upgraded, no changes
to:
Processor
Graphics
Sound
A console has a 3 to 5 year life time
Must be better than a PC when first
released, otherwise it will date very quickly
Console Games
Engineers do a lot of tricks to make things
look better and run faster
Want to have a range of features that give
WOW to the console
Extend the life of the console
Result: hardware is not well organized,
may not be easy to use or program
A lot of tricks to learn
Console Game Development
Differentconsoles are quite different
Often need to redevelop most of a game
when it moves from one console to
another
Program code will be quite different
Art work may also be different
Alsoneed to retrain developers when they
move from one console to another!
Console Game Development
Develop on one platform and test on
another
Emulators can help find program bugs, but
the don’t give the same experience:
Differences in processor speed
Differences in graphics / display quality
Differences in sound generation
Development process more difficult, takes
longer
Game Boy
Concentrate on the GBA
Most recent version that we have a lot of
information on
Don’t know much about the DS yet,
haven’t seen cheap or free tools for
development on it
Many web sites discuss the GBA
hardware and programming it, so lots of
information
Game Boy
Like most consoles a rather ugly
architecture
Tries to get as much as it can out of a low
priced unit
Based on the ARM7TDMI CPU chip, also
used on some phones and PDAs
Appears to be off-the-shelf, no
customization by Nintendo
CPU
Two modes, 16 bit instructions and 32 bit
instructions, can switch between modes
Why?
Internal RAM is 32 bits
ROM cartridges are 16 bits
Switch instructions to match the memory
being used, can copy code from cartridge
to internal RAM
Memory
Many memory areas, most are quite small:
32 Kbytes on chip memory
256 Kbytes off chip working memory
96 Kbytes VRAM (video RAM)
1 Kbyte sprite properties
1 Kbyte pallette
32 Mbytes cartridge memory (may have
several banks of this)
Memory
Access to the cartridge is quite slow
Can run 16 bit code from the cartridge
Better to copy important code to working
memory and use 32 bit instructions
Can store art work in cartridge, bring it into
memory when needed
Programmers need to think more about
memory allocation
Graphics
The display is 240 x 160 pixels
Can display up to 32768 colours, but this
depends upon the display mode
Most of the time use a 16 colour or 256
colour palette
Many different modes and options, not all
of them can be combined together
Graphics
Two types of graphics:
Backgrounds
Sprites
Background is always drawn first, sprites
are drawn over top
Can use sprite priorities to put a sprite
behind part of the background, this gets to
be a bit complicated
Backgrounds
There can be up to 4 background levels
There are 6 background modes
Three modes are tile based, tiles can be
either 16 colour or 256 colour
Tiled backgrounds can vary from 128 x
128 to 1024 x 1024 in size
Tiles are stored in VRAM and can be
shared between background levels
Backgrounds
Threeraster background modes, can
access individual pixels:
Single buffer, 240 x 160, 32768 colours
Double buffer, 240 x 160, 256 colours
Double buffer, 160 x 128, 32768 colours
Size of raster backgrounds is limited by
the amount of VRAM
Can’t do full screen, full colour, double
buffered
Backgrounds
Hardware supports a number of special
effects on backgrounds
Can scale and rotate some of the
background levels
Can pan all of the background levels
independently
Can alpha blend two background levels,
also increase of decrease level brightness
Palettes
Two separate palettes, one for
backgrounds, one for sprites
Palettes have 256 entries of 15 bit colour,
5 bits red, 5 bits green, 5 bits blue
Total 512 bytes per palette
Palette can be viewed as one 256 colour
palette, or 16 palettes of 16 colours
Sprites
Up to 128 sprites, some restrictions on
number of sprites per line
Sprites built from 8x8 pixel tiles, either 16
or 256 colours
Sprites can vary in size from 8x8 to 64x64
pixels, either square or rectangular
Sprites can share tiles, multiple objects
with same appearance don’t need extra
memory
Sprites
Tile memory can hold between 256 and
1024 8x8 tiles, depending upon colour
depth and background mode
This limits the number of large sprites and
the amount of animation
For animation need to store a separate set
of tiles for each frame, can quickly use up
all of the tile memory for large sprites
Example
A 64x64 sprite requires 64 tiles for 16
colours and 128 tiles for 256 colours
If there are 10 frames of animation (the
player character in our phone example has
12) we need 640 or 1280 (too many) tiles
Only store some of the animation frames
in tile memory, copy frames in when
required
Sprites
Sprite position, address of tiles and other
properties stored in sprite memory
Can change properties between frames
32 sets of scaling and rotation data that
can be shared between the sprites
Each sprite can be flipped about horizontal
or vertical axis
Sound
A mixture of old Game Boy analogue
sound and newer digital sound
There are 6 sound channels that are
mixed to provide a final stereo sound (only
heard in headphones)
The final output sound is 9 bits sampled at
a rate of 32768 Hz
This is not very high quality!
Sound
Firstfour channels are basically noise
generators
Can control their parameters, each
channel produces a different type of noise
The last two channels are for digital sound
This is basically 8 bits sampled at 32768
Hz
Samples stored in on chip RAM
Serial Port
is one serial port that is used for a
There
number of communications tasks:
Communications with up to three other Game
Boys, multi-player games
Communications with external devices, like
game controllers and joysticks
Communications with development machines,
downloading of code and debugging
Serial Port
One of the standard ways of getting code
onto a Game Boy
Program prepared on a PC, art work
collected and program compiled
Cable connects PC to Game Boy serial
port, game is transferred to the Game Boy
RAM
Only works for programs that fit into 256
Kbytes RAM
Cartridge
Standard ROM cartridges can have up to
32 Mbytes of program
Executing from cartridge is slower than
RAM, but there is much more room
Usually transfer program code to RAM for
execution, take advantage of faster
memory on Game Boy
Program split between cartridge and RAM
Cartridge
Each cartridge has a header recorded at
the start of ROM
Contains name of game, manufacturer,
device codes, where to start execution of
the game
Also contains a compressed version of the
standard Nintendo logo
Program will not run without the logo,
Game Boy checks for this
Cartridge
One of the important steps in game
development is to add the logo to the
header for your program
This is put there for legal reasons, to catch
piracy
Very weak protection in terms of copying,
can easily copy the logo from another
cartridge and add it to your program
Cartridge
Mainly used for court cases
The Nintendo logo is a copyrighted
trademark
You cannot use it without permission from
Nintendo, so legally you can’t put it in your
program
Legal case is based on use of trademark,
not the illegal copying of the game!
Development Process
Everything is on the cartridge, Game Boy
views it as a program
It doesn’t know anything about files, it
doesn’t have any
Content can’t be stored as files on the
cartridge
Must become part of the program, part of
the data that is built into the program
Development Process
Art work can be produced using standard
tools, well at least some of it
This art work then needs to be put into a
format where it can be used in the game
For example, sprites need to be divided
into tiles
Usually produce a standard set of images
for the sprites, artist doesn’t think about
tiles
Development Process
First use a program to divide the sprite
images into tiles
All the sprites use the same palette, so
some care must be used here:
Develop a single palette that is used for all
sprite images
Use a program that constructs a “best fit”
palette from all the sprite images
Development Process
Now have tiled sprites, plus a palette
Need to convert this into program code or
data, something we can put in the
cartridge
Another program is used for this, produces
a file that is combined with the program
Each time the art work changes, all these
programs must be run again
Development Process
Backgrounds are a bit easier
Tile based map editors are common, level
designers are used to dealing with them
Still need to convert the background
images into a format that can be included
with the program
Sound is harder, need special tools due to
the strange sound formats
Tool Chain
The set of programs used to create the art
work is called a tool chain
Programs are executed one after the
other, like the links in a chain
If one of them is missed, or doesn’t work
right, the art work is no good
A change to the original art work means
we have to execute the whole chain
Tool Chain
Programmers usually develop the tool
chains for individual game projects
Usually work closely with artists, make it
easier for them to produce the art work
Tool chains sometimes shared between
games
Trend towards having technically
sophisticated artists produce the tool
chains – technical artist
Nintendo DS
Information just beginning to appear now,
still not a lot of details
The DS is considerably more complex
than the Game Boy:
Much harder to program, some very tricky
issues as we will see
Harder to find information
Harder to produce programming tools
CPUs
The DS has two CPUs, this makes it more
complicated
The first CPU is a ARM7TDMI, same as
the Game Boy, but twice as fast
The second CPU is an ARM9426E, more
modern than Game Boy and running four
times faster
Both seem to be standard off the shelf
CPUs
Itappears that the ARM9 is the main
processor, responsible for main game
logic and graphics
The ARM7 is a slave and deals with:
Sound
Wifi
Touch pad
The ARM7 may not be able to do graphics
Memory
The DS has considerably more memory
The working RAM is 4Mbytes, and is
shared between the two processors
This memory is used for program code
and communications between the CPUs
There is also 32 Kbytes of internal RAM,
not sure if this is shared or a separate
copy for each processor
Video
The main external feature of the DS
Two 256x192 pixel displays, still 16 bit
colour
Approximately 700 Kbytes of video RAM
Four main banks of 128 Kbytes that
appear to serve the same function as
Game Boy VRAM
Can simulate Game Boy graphics
Video
There are two 2D graphics engines, main
and sub (attached to the two displays??)
The main engine is more powerful
Has at least 7 background modes, many
are tile based and similar to the Game Boy
Can also have full frame buffer access,
can apparently use the first four memory
banks for this
Video
Sprite support seems to be similar to
Game Boy
The 2D engines have separate palette and
sprite memory, but it might be possible to
share the VRAM
Big advance is 3D graphics engine, can be
shared between the two screens, but there
is a speed penalty
3D
Primitive by modern standards
No floating point, uses fixed point integer
coordinates, etc
Need to be careful with model
construction, particularly transformations
May need to process models before they
can be used on the DS
This could be a bit tricky
3D
Still 16 bit colour
Has texture mapping, but no texture
filtering
Can do hardware anti-aliasing
There are suggestions that it can do
special video effects like toon shading, but
this hasn’t been seen
Sound
May support Game Boy sound
Appears to have a better sound system
that is based on sampled sounds
Appears to have up to 8 channels of
sampled or wave sound that can be mixed
and played together
Appears that the ARM7 controls the sound
WIFI
The DS can use standard 802.11g
wireless networking, not sure how
complete this is
It also has its own Nintendo based
protocol – called NIFI
This is mainly used for multiplayer games,
same as the link cables on Game Boy
Can also download games over NIFI
Cartridges
The DS cartridges are encrypted in real
time, so they are harder to deal with than
Game Boy ones
The cartridge itself has a processor for
encryption, the DS sends it the information
for encryption when it starts
Only the initial cartridge header isn’t
encrypted
Development
The first problem is getting code onto the
DS, can’t simply write cartridges
There are now two approaches
First is to intercept the DS cartridge
header and modify it to point to the GBA
cartridge
The GBA cartridge has the DS program,
can be written by standard GBA tools
Development
This requires a DS cartridge to use as a
header donor, and a special hardware
device to modify the header
The second approach is to use NIFI to
download a program, usually to read the
game from the GBA cartridge
This requires a particular WIFI adaptor for
the PC, only one type will work
This seems to be the best approach
Development
Most of the tools used for Game Boy
development can also be used with DS
The 2D art work is basically the same, and
similar processors are used
The main difference is in sound formats
and 3D graphics
Need to keep the ARM7 and ARM9 code
separate