Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/757 Thanks!
So the next talk,
I'm really looking forward to this, and I
know why the most
most of you are here.
Because I'm excited about this, too.
I own a Gameboy
and I'm really proud of it and I
have it in my flat
and on special occasions I take it
out. Well, nowadays, I use an emulator
for sure, and I only have ROMs
of cartridges I really own.
Well, that is.
That is how it's supposed to work, right?
Yeah, and I'm
looking forward to this.
By the way, I'm my favorite
games on a game boy, the the first
one to make that clear,
our Megaman two Vario
Land and Mystic Quest.
And and who
does not agree with this?
Well, you don't know me that
good then.
So we go to the
talk of the ultimate
game boy talk.
I'm really looking forward to this.
Uh, yeah.
We have a speaker, Michael
Style, and he held a
really great talk at twenty five
C three, the ultimate
Commodore 64 talk.
And now with the ultimate game boy
talk. I'm really looking forward to this
Michael style. By day, he works on
operating system technology.
By night, he hacks obsolete systems.
In a previous life, he hacked
game consoles, police, a big
round of applause.
Michael, the stage is yours.
Hello, hello, everyone,
again, my name is Michael Steele, and
this is the ultimate game boy talk.
The idea of the talk is to talk as much
as possible about all the different
hardware details, everything that I can
fit into 60 Minutes, everything about the
game, Gameboy, 60 Minutes,
I have about 200 slides, over
800 individual builds.
So maybe the information density is a
little higher than normal.
So let's get started real quick.
The Gameboy talk is in the context of a
series of talks that I have started eight
years ago with the ultimate Commodore 64
talk and other people have picked that up
and talked about the Atari twenty six
hundred, the Galaxy and the Amiga
five hundred.
And so it's my turn now
again.
And I think the Gameboy.
Why is the game boy so interesting?
Because they solve lots and lots of
systems. Game boy, game boy, color one
hundred eighteen million alone.
And if you count the Gameboy Advance
models that are compatible, excluding
the game boy micro in total it's almost
two hundred million systems that have
made sixteen hundred, about sixteen
hundred official games
and they produced it from nineteen eighty
nine, just the models until 2003.
And again if you count the compatable
Gameboy Advance models, they made
a compatible gaming systems until
two thousand nine. So that's a twenty
year run, which is pretty amazing.
Let's look at the competition back then
just after the game.
Boy, the Atari really still links Sega
the game gear and see the Turbo Express.
All of these had one thing in common.
They had a color screen, pretty
good color screen, but they also had one
thing in common, which was really bad
battery life of maybe three to five hours
while a Gameboy had fifteen to thirty
hours.
But the compromise was it had a screen
that looked like this and you could
hardly make out anything really as soon
as it starts scrolling.
This is not the case with all the models
of the Gameboy of which there are many.
The original Gameboy and the original
design, which was produced for the
longest time, is the DMG.
DMG stands for DOT Matrix Game, which
was the original codename.
Then in ninety six they released their
game by pocket, which had a much better
screen, much smaller.
The MGB Gameboy Light was only
released in Japan. It had a backlight and
then the Gameboy color with twice the
speed and twice the ram and twice the
video ram and support.
Then the Gameboy Advance series.
They were completely different
architecture. They were based on an arm
CPU, but still they were on one hundred
percent backwards, compatible with
Gameboy and Gameboy color games.
The events as part of
that one two models exist.
If you want to get one, you really need
to get the one on one,
which is the one with a backlight instead
of the front light.
And as you can see, Nintendo has always
been ahead of its time a little.
That didn't only make a rose colored
version, but also you need an adapter to
plug in regular headphones.
If you want to play a game, boy games on
a regular TV set, the two options
for that, either you use a Super Nintendo
and plug in the super Gameboy, the two
versions of that one only be released in
Japan, which had the proper timing,
didn't run three percent too fast as the
original one and the Gameboy player
for the Nintendo Game Cube and all
of these had complete Gameboy hardware
embedded inside, basically a normal
Gameboy. And it just it puts its pixel
into the whole system instead of on the
screen.
So what does a Gameboy like as a two
point six inch screen department
or speaker? You can get stereo over the
headphones.
There's a link connector serial port to
connect to game boys together, contrast
and volume. And on the back,
this is where the game goes and this is
where you put in your batteries
and this is what the game looks like.
And the basically most games are really
just rom chips. There's nothing more to
it
specifications.
What are the specifications of the game
when let's compare the Gameboy to some
other systems that may or may not be
comparable.
The CPU is a one megahertz eight, but
suppose some people in the audience may
complain at this point and say no, it's a
four megahertz Tipu. But I'll explain
later while I call it one megahertz CPU.
That's a better friend, which is plenty
for a gaming system of that type.
VRM of kilobytes is a little tight.
The resolution of one hundred and sixty,
but one hundred and forty four is really
poor. But at a screen this size you
don't really notice that much.
It can do four simultaneous colors, which
is four four shades of gray,
and it supports up to 10 sprites per
line.
So if you compare all this to these other
systems here, it's clear that
the Gameboy is way more advanced.
For example, Ontari. Twenty six hundred.
But it's not at all in the league of
Super Nintendo.
It's more like an Sunia and more like a
standard Nintendo entertainment system or
a Commodore 64.
But the fun thing here is that while the
S and the C 64 were released in the early
80s, the Gameboy is from eighty nine.
And as I said, Compatible Hardware was
was supported and released until
2009.
So that's what makes it really
interesting.
It's an eight bit system, but it's really
the latest, the last eight
bit system that was in common use.
Let's look inside
on the right. The board on the right
isn't very interesting. If you look at it
from the front, this is where the LCD
connected speaker and the buttons,
the button, the board
on the back is much more interesting.
This is where you can see three chips.
So this is the DMG, the original Gameboy
board to ram chips, two identical RAM
chips. One is for CPU ramp, one is for
video RAM.
And this one big chip here, it's called
the DMG CPU, but it really is the
see the system on a chip.
So what you would regularly
expect to be lots of chips in a computer
system like that. Everything is
integrated into just a single chip, which
is the Gameboy chip.
Let's compare some other boys to the
super Gameboy.
It has a very similar chip.
It's actually really ninety nine point
nine percent identical.
The Gameboy Pocket is then
is a slightly optimized model
that comes only with one round trip for
both the Gameboy like you might have
seen. It's not actually any different.
It's just another MGB from the MGB
series, but it comes with a backlight.
And then there's the super Gameboy, too,
which is based on the Gameboy Pocket.
And this is what the Gameboy color looks
like on the inside.
They all have this one gigantic chip that
does everything.
But what is this one? This is a special
one. You may not recognize it from the
markings.
This thing is called the boy.
There have been companies closing the
game, but all the time. And what this
particular model is, is it's a perfect
clone from copying and photographing
and redoing that mask of the original
Soucy here.
And it's a Chinese
Gameboy that you can still buy today
for like thirty, forty bucks or so on
eBay.
It's a shame that the courts are 30
percent too fast, so none of the games
are playable.
Let's go back to the board.
So the DMG CPU is the thing that we're
really interested in that does everything
on this system. What is included in the
DMG CPU while the regular C.P.U
core interrupt controller time and
memory? But from what you would expect
from something like that, and then all
the peripheral devices like the IO
iPad input, serial data transfer
for the link cable, that sound controller
and a video controller, the pixel
processing unit.
So let's talk about the CPU.
Historically, the Gameboy
from nineteen eighty nine was
released between the US and
the Supreme.
The S and the
S came with a sixty five vote to
Supernus, came with a sixty five
eight sixteen which is the sixteen bit
version of that same CPU.
So obviously the Gameboy comes with a
sharp LR three five nine oh two.
What is the sharp L are a three five
nine oh two core.
It's nothing like a sixty five or two,
it's more like somewhere in between an
intel. Eighty eighty and a dialog eighty.
But it's neither and both these
architectures are interesting because the
eighty eighty was for example used
in the Altair, which is the first
computer that Bill Gates wrote software
for and released it for.
And the Zetas and pretty much every
computer home computer system
that did not contain a 65 or to very
successful architecture.
So if you imagine this is the
feature set of the Intel 80 80, that's
the feature set of the dialog.
So it's a strict superset.
It's perfectly backwards compatible.
And that is the Gameboy,
if you.
They're the core architecture is the same
as the one from the 80 80, so all the
core features are the register set to the
instruction, encoding everything.
All that is the same.
But there are some features that are not
supported, but it does support
some zaidee features, but it does
not support most of the Zedi features.
And then they added a few features on
top.
Let's walk through that.
So let's talk about the core architecture
of the first.
It has these registers accumulator,
which is special. It's the one that can
do all the arithmetic and logic.
You cannot do this with the other
registers.
Flags register.
It only has two useful flaks, the zero
and the Kerry flag in the Gameboy model.
The other two are only used for decimal
adjust. And then there's
another and another set of eight
registers.
But the fun thing about those is that you
can combine B and C into A, B, C
and D, E and the same thing.
So you actually have 16 better registers
that you can use as pointers, for
example.
So in total there for 16,
but registers that can do some things and
seven, eight bed registers plus
one special case here, which is the
memory location pointed to or the
value at the memory location pointed to
by the register, which can be used in
place of any register in any
in any instruction, which is pretty nice.
So these are the instructions.
There's the load in stores by practically
the same instruction you can in direct,
immediate direct
stack is 16 but can only
push 16 registers.
And these are the printing and logic
ones. As I said, only the accumulator can
do most of those except for incrementing
and incrementing, which works in any
register. And that one also works on
16. But registers that rotate
instructions, controls flow, just call
and return conditional and
indirect and then some miscellaneous
functions, setting the carriage, clearing
the carry, not polt and disabling
it, enabling to interrupt.
What is the interrupt model
on most systems.
And that time you would expect there's an
interrupt vector for all the interrupts,
but it's neither a veteran nor is it just
one.
Instead of jumping over a vector, it
jumps to fixed locations in RAM at
the beginning of RAM and for
the different kinds of interrupts it
jumps at different locations to hex,
forty hex, forty eight and so on.
And there's also a concept of software
interrupts. You can jump to these
locations with special instructions and
Oreste zero is a special one because this
is the same as a reset.
When you turn on an eighty eight CPU,
it starts at location zero.
Let's talk about the few unsupported
eighty eighty features.
So these are the flags of the Gameboy.
These are the actual flags of the eighty
eighty. And it has to for two
extra flags. One is the same flag which
is kind of useful, and the Perati flag,
which is not so nice.
None of these instructions are supported
and a few others for some reason they
just decided not to include those
IO.
You may remember that from eighty from
the eighty, eighty six it has the support
space. That one is in the eighty eighty
but it's not supported on the Gameboy
because it uses memory map.
Instead, the Zaydi
has lots of extra rotate
and shift and pretesting setting
and resetting instructions.
All of those are supported as are,
as is the relative instruction which
is a more optimized version of a jump
and the return from Interop.
That's all that is supported.
Everything that is not supported is all
the interesting stuff from the Zaidee,
which is the second register said the
extra two registers and lots and lots
of features, including the order
increment and decrement and loop
instructions, which are nice for copying
memory, but it has a few features
of its own that to take their place.
For example,
there's a post increment.
And so if you want to access memory
that is pointed to by you
can post increment or you can predicament
HL.
There's also the concept of a zero page
and it's a little confusing because it's
not actually page zero and it's the
topmost page in RAM.
And if you know the sixty five or two you
can see this is a concept borrowed from
the sixty five or two.
It just means that there's an optimized
instruction encoding for instructions
that are in the four for memory
accesses that are in the topmost page of
RAM. So instead of doing this
loading from forty, which takes three
bytes and four cycles, you can encoded
like this takes two bytes and three
cycles.
And obviously you have to put something
useful up there in the topmost page,
which is timing critical that if
you stack instructions and other stories,
instruction, you can swap the low and the
high nable. They added eight instructions
there and there's an extra
power saving instruction.
So this is what the code table looks
like. Just to get an idea from the color
coding, you can see this is quite
orthogonal and there are few instructions
that are or a few op codes that are not
in use and they all crash, which is a
nice design.
And this one
is special. The OP code KB is the same
prefix which hosts another two hundred
and fifty six of codes.
This is the complete space for the.
Rotate and shift instructions borrowed
from the Zaydi, plus the additional swap
instruction that was added on the game,
both of you.
Let's look at another instruction here.
Just as an example.
This is a low load from a fixed
address.
This means it takes three bytes, sixteen
clocks, sixteen clocks at four megahertz.
But the Internet disagrees whether
it should be looked at at four megahertz
or at one megahertz, because all the
clock times are
divisible by four.
And this is because the whole system
is memory bound. The whole CPU is memory
bound.
So it can only calculate as fast
as memory is providing
the data.
So basically you could just as well say
this is a few that is clocked at one
megahertz and it takes four clocks
for this. And these are much smaller
numbers now because now the numbers are
actually comparable with similar systems
like sixty five or two based systems
that also have one megahertz memory
with one megahertz.
If you. So in theory, yes, the CPU
is clock with four megahertz, but the RAM
Rams at one megahertz, the CPU
draws its pixels, the pixel processing
unit at four megahertz and it's connected
to VRAM that is running a two megahertz.
So it's a little complicated here in the
system, but most of the time everything
runs or most of the numbers
can be expressed in terms of
one megahertz.
But to be exact,
it's not exactly one megahertz, it's one
maybe Hertz as in ten to twenty
four times twenty four hertz.
So they didn't base it on fact
or on base 10.
They based on these two, just
pretty.
And so from now on, if I speak about
cycles, I mean machine cycles at one
megahertz.
So that's the issue, and it's a
16 that's Dipu and it's Tipu that
has a sixteen bit address space because
of the 16 pointers, so 64
kilobytes of address space
is all it can see.
It's 32 kilobytes of that is the
rom space that comes from the cartridge.
It's just mapped in from the cartridge
and there's a buttram lying on top of
that that we'll talk about later.
Video Ram is mapped in external ram that
can also come from the cartridge
optionally.
Then there's the internal ram and
some empty space, which is unassigned or
is mirroring just other things.
And if we zoom into this, we can see
at the top there is another
page of OEM RAM, which is like a special
purpose video ram that is distinct
from the video RAM that we'll talk about
later.
And then the last page, which is the zero
page, contains the area.
So all the registers for the peripherals
like sound and video, plus another
hundred and twenty seven bytes of
each ram, which is
distinct from the other ram.
So does this mean that games can only
have 32 kilobytes?
Well, some games only need 32 kilobytes.
Tetris fits nicely into 32 kilobytes.
There's a single chip. They're pretty
simple to manufacture.
Other games can have in practice.
I mean, there's no theoretical limit, but
in practice, games go up to, I think, two
megabytes.
This one is 128 kilobytes.
The way it achieves that is by adding
another memory bank control a special
chip to the cartridge, which can switch
banks.
This is common on all kinds of system.
So in practice, well, these memory bank
controllers can be very different, but
most of them work something like this.
The lowest bank in
memory always maps to banks of the room
and the upper 16 K map
to whatever they can map to bank one bank
too, and so on.
And all this is controlled
by writing magic values into
ROM locations, which then we'll go to the
cartridge, be intercepted by the memory
bank controller, which then can switch
those banks.
The same is true with the external RAM.
If the cartridge wants to
expose extra ram, for example, for safe
games that are the battery backed, that's
the only way to do safe games.
It can map an external ram here.
Same model.
So what's up with this from
the CPU starts running at
location zero in memory and the Buderim
is the thing that draws this
and does the time.
This spectrum is built into the Gameboy
and took a while until this was
extracted was a real pain, not
me.
And what it does is this is a complete
goodrum initializes, ram, initializes
sound setup and decodes the
logo that it puts on the screen that it
scrolls in the logo.
It placed the time and then it gets
interesting. It compares the logo
because the game has to have a copy
of that Nintendo logo inside.
If that if it doesn't match, the game
does not put this was meant so that
Nintendo could control which games are
released for the platform because all
games had to contain the logo, which is
not just a copyright violation, but also
a trademark violation.
If if you include that and you don't have
Nintendo's permission
after that, it also checks the header
just to make sure that you don't have to
blow into the pins and then
it turns off the ROM and continuous
execution in there.
So then
that logo, though, is actually
presented from the cartridge.
So if you put up a Gameboy without a
cartridge, you will see this.
So but that doesn't mean that an
application or a game can put any logo in
there, but because it does get compared
and at that point it wouldn't put any
further.
And since that's there was no clean up
code, it doesn't reset the system or
anything or clear the screen.
So some games to something like this,
they played with what's on the screen.
Let's just continue with that.
And of course, Demo was also like to play
with that, the Nintendo logos on the
screen. Let's just do something with it.
Which is pretty nice.
So the Buderim runs and runs until the
last instruction and the last instruction
is the one that turns off the Buderim.
So at this point, even the first
pigeon rom is mapped to
show game data and it continues
running here. So it's just continuous
running into the next instructions from
the game. And usually there's a jump
there because there's a header that that
is specified to be there at this location
that had a contender contains the
Nintendo logo and the header check, some
which are important. All the other
metadata is not really important.
It was important for the developers back
then for their hardware, but the game
does not actually check any of this.
And after that, you can have the actual
game data.
So one of the things that we haven't
looked at is the Iowa area and atrium,
which is the topmost page
in the
in the system. It's the zero page, the
one that you can access
quite efficiently.
So the top one twenty seven here
are extra ram and all the rest
you can sprinkled throughout here.
You can see the different devices and
these are all the registers total in the
system. Interrupt control of sound
controller, joy, serial timer and
pixel processing unit.
These are all the components that we'll
talk about now.
TripIt input.
It's really simple.
This is these are all the inputs.
The game has its four buttons and four
directions. So you would think, let's
have eight.
And with that, we can do this.
But we can actually do it with Scorpio's
because it's two columns with four rows.
So you select the column that you want to
test and then from the row you can read
what the what button was pressed so
they could do with six instead of eight.
That's all about the buttons.
Pretty simple serial data
transfer.
You can connect to getting both together
with a link cable.
Everything that can link cable consisted
of was one wire of data
in the one direction, one wire, four data
in the other direction and a third wire
for the clock.
The two chambers had to decide which one
is sending the clock and which one is
receiving the clock.
So these are the bits that control this
one sets the clock and it's always eight
kilohertz. The receding clock can
really be anything. It can be go up to a
half a megahertz and it will receive it.
And as soon as the transfer started, it
will clock the bytes through and it
always goes both directions.
At the same time,
the timer is any system.
It has a timer. There's only one timer
them to register.
The modular register is where you put in
the start value and then you can
select one of four different speeds.
And then you started and then it counts
up until it overflows.
And at the overflow time it reloads
the module number and
can optionally generate and interrupt.
Speaking of interrupts, the interrupt
controller supports five different
interrupts v blenkin the LCD
stat deal with the pixel processing
unit. We'll talk about those later.
We've already seen the timer causing
interrupt. Serial can cause an interrupt
when a new byte has been received and
dropped when a button has been pressed
and this was interrupted navel register.
And that's the interlocked flag register
where you can see which interrupt is
still pending.
And these are the addresses where those
different interrupts jumps.
So there's you don't have to find out
which interrupted was because the two
jumps to different locations.
So the sound controller, sound
controller, nothing has as many
registers as the sound controller
because there's four voices and they all
have their distinct registers.
So this is a better way to look at them.
Four voices and
five registers each.
And those registers have particular
meanings,
but the meanings are rough because
the four voices are not exactly the same.
There are two very similar ones that do a
pulse and one that does that.
That is called voice. And one of those is
called noise.
If you look at the bits here,
they are similar, but they're not the
same. So it depends on the voice.
What exactly those bits in those
registers mean.
Let's look at the ones that are in
common.
All the voices have a trigger bit which
turns on the voice and you
could just turn it off again at some
point. But there's a
length, a bit and a length register.
So you can just say it turned off after
quarter second.
And let's look at the wave register,
which is the simplest one in addition.
So the idea of the wave register is that
you can play any sound wave.
It has these extra sixteen
bytes of register here, which is thirty
two entries of four bits each.
And these can describe any waveform
that you like that fits into these twenty
introduced thirty two
slots. So here are some examples.
So you could for example create a
sawtooth.
Which is a pretty simple waveform where
you could have a sign.
Or you could just do anything custom.
So you're pretty flexible at that, and
then there's the frequency which controls
the pitch, just controls how fast that
wave table is played
and two extra bits of volume so you can
play 100 percent, 50 percent.
Twenty five percent, or you can mute it.
The other two hear the two pulse
registers, the two pulse voices that are
very similar.
All these bits are the same and behave
the same.
You cannot specify a waveform.
Hear the waveform is kind of fixed.
It's always a pulse, meaning low and
high in different
ratios. And these two bits
determine the ratio between low and high.
Twelve point five higher and
the rest is low.
Twenty five percent.
Fifty and then seventy five should sound
exactly like twenty five, it's just
inverted.
So you can do this with either of these
registers and there's also the concept
of volume sweep so the volume
can go up or the volume can go down,
volume going down is the common case for
emulating standard instruments.
Or the volume going up is an interesting
effect.
And only the first
pulse voice also has the concept
of a frequency sweep
so you can go up.
Or you can go down the.
So you can see this is mostly meant for
sound effects and these are some more
examples of sound effects.
That's what you can do with that, and
there's a fourth voice that can only do
noise, so this is a shift
register that basically generates
pseudo random numbers.
And depending on whether you
said it's to 15 bot mode or seven
mode, it will do one.
We'll do one of two different waveforms.
That's 15. But most.
And that seven bit mode,
so these are all the registers, again,
different voices and three
general-purpose registers, this register
has a Volume four left, volume four right
channel. And interestingly, cartridges
can have their own audio controller
that outputs an analog signal that can
be hooked up into this.
But no game ever did this.
And there is
another register we can say, should a
voice be on the left or the right?
On the right, on both or neither.
And then there's the power bit.
If you turn off the power to audio,
you will save like 13 percent or so of
energy.
So the game
is not only used or is the game, but
sound is not only used for games.
People still compose music in tools
like a little sound today on the Gameboy
and also your short example of that.
So much,
so much for.
Let's talk about the pixel processing
unit, the pixel processing unit is the
thing that makes graphics.
It has 12 registers, which is not quite a
lot.
But let's look at the specifications
first. We talked about it before.
One hundred and sixty. One hundred and
forty pixels, not that much.
Four shades of gray, which is more like
four bad shades of green
little Gameboy that much better.
Everything on the screen is tile based
and there are a certain number of tiles
on the screen, the sprites and all this
has to deal with eight kilobytes of
video. Ram, what do I mean when I say
eight by eight pixel tiles?
If we look at a game like Tetris, you can
see everything's blocky, everything's
based on these blocks.
Same with Zelda. If we put the grid over
it, you can see there repeating patterns
and they're all aligned to a certain grid
with Super Mario land.
It's also pretty obvious here, especially
because it doesn't have many different of
these tiles.
Even with something like Donkey Kong
land, you can see it as
soon as you put the grid over it, that
there are some repetitions and
everything's aligned to that, even though
they did a very good job of hiding that.
And in some games you can see it because
it plays with that very concept.
So here in a hurricane, you can see it
fills the screen with tiles.
Let's look at the tile and what a tile is
like. Tile consists of eight times
eight pixels and has four colors like
everything in the system.
And these colors are encoded zero zero
zero one one zero one one.
So let's add that to these pixels
and let's look at how the encoding is
done. If I look at the first line here
and I read it as a binary number zero two
and F, so for every line of pixels,
I need two bytes and in
total I need 60 votes to describe a whole
tile.
You may have noticed here that the
ordering of the colors, it doesn't
necessarily make sense.
This is because I can choose my own
palette. I can be any palette.
There's a two bit to two bit mapping in
the system for these background tiles.
So the native colors are zero,
zero means white and one one means black.
So I can pick any palette like this.
I can also reuse the same colors if I
want that for some effect.
There are two hundred fifty six tiles in
the system. So this tile set do.
That's what it is.
It's Tetris.
If you don't recognize those dancing
people at the bottom then you have not
finished Tetris.
This is Zelda
and that is a Super Mario land which
only uses a hundred twenty eight tiles
that can deal with that.
Anyone recognize what this is?
Let's just puzzle together something and
we'll see it's a tennis game.
It's all star tennis
and this is the puzzle
together from 20 tiles by 18 tiles which
fill up the whole screen, which is not
the whole truth, because actually
in video room there are thirty two
tiles by 30 tiles.
This is the complete background map.
And what you see on the screen is just a
viewport into that.
And it's 256
by 256 pixels, which is nice and
convenient because this is how
scrolling works by just moving that
viewport around and
we can see this in practice.
There's a really nice emulator that lets
you see what's going on in the background
map and how the viewport is changing
around. So this is basically really a
camera that is moving around a bigger 32
by thirty two map.
But this only works with games that are
maximum thirty two by thirty two.
What about games that are, that are
scrolling infinitely like Super Mario
land?
We can have this many extra columns
and we can move the viewport over here.
But what happens if we end up
here at the end?
Well, it will wrap around.
And if we just to draw columns fast
enough just before the viewport hits
them, we can have an infinite world.
So in the emulator, you can see this
quite clearly in the off screen area
of the viewport it keeps putting
in those new columns.
And this also works in two dimensions.
This is Donkey Kong. And again, this
looks pretty freaky.
It just puts those extra columns
and lines where it will
go.
So this is the one layer that we've
talked about so far,
it's the background and on top of the
background, there's another layer that
you can optionally put on top.
It's the window.
It can cover it fully or it can start at
any location. There's an X and Y position
for that and it will draw from there to
the right and to the bottom.
There's no translucency ever.
So usually how this is used, as you put
it, to the very right or you put it to
the very bottom, it just always does and
does not respond to the other scrolling
settings.
And you guessed it, this is necessary
for something like a score that is shown
at the bottom of the screen.
This is very nice, easy and convenient
for games.
But you can also put it on the right.
And these are games, but it wouldn't
matter. It works on the game just as
well.
And then there's another layer on top of
the background. And the window, which is
a sprites, are objects on the screen
that are that don't fit into the eight by
eight Vasteras. You can position them
freely.
So we have three sprites here in the
system, Nintendo Custom Objects, LBJ,
but I keep calling them sprites because
everyone calls them aspirates.
Let's just look at this one here.
Every Sprite in the system has attributes
and there's the OEM, which
is the object attribute map, and this is
one entry and it has these values.
So one of them is the position.
So if we put the goombah to the very left
of the screen, you would expect us
to have a horizontal position of zero.
Right. But no, it's eight.
Why is that?
Because if you put it at four, it's here.
And if you put it, it's zero.
It's here because it's eight pixels wide.
You need a way to scroll it in.
And something similar is true at the top
of the screen. But the first
Y position where you see it fully is 16,
because sprites
can also be can can be up to 16 bits,
16,
16 pixels in height.
So let's put it at its natural
location here.
The next thing to look at is what
should it look like?
So first of all, you can see it's eight
by eight grid. It's the same encoding,
except that it also has translucent
pixels.
So the code zero zero stands for
translucency.
And since it's the same encoding, it's
the same kind of tiles.
And there's also two hundred fifty six
tiles in the system, which is a bit and
we can see it here, it's Hilex 90.
The next thing is the flip.
So in so you don't have to
save to goombahs here, one that works to
the left and one works to the right.
You just flip it horizontally and you
have one that walks to the right.
You flip it vertically and you have a
dead gumba, you flip it horizontally and
vertically and you have a dead woman
walking the other direction.
So let's put it right side up again.
The next bit is the pallet, because
one pixel combination, one bit
combination means translucency.
You only have three more colors for
sprites, which is a shame.
So they didn't want to impose
three specific colors for this.
So four for the sprites you can pick
which three colors out of the four you
want and all the sprites don't have to
share the same three colors because there
are two palettes in the system, which is
why the Sprite also has another flag.
Does it take Pallot zero one?
If it takes one, it would like this would
look like this with Pallot zero.
It looks like this and
one more bit is priority.
So how does the Sprite draw in
comparison with the background
if that priority is one?
This is the interesting case.
It will draw on top of all those white
pixels here, but it will draw at the
back of all the non white pixels.
But there's nothing special about white
here. This is why there exists a
background palette.
It's about pixels that have the value of
zero in the background.
So if you pick another palette and the
Goolma could very well be drawn
on top of any other color,
if we set the property to zero, it will
draw on top of everything except for the
translucent pixels, of course,
Sprite and Sprite priority.
There's nothing you can do about this.
This is always fixed with this rectangle
here and the base on top of the
rectangle, which is because the goombahs
horizontal position is smaller than the
rectangles. As soon as they're at the
same horizontal position, the sprites
with a lower number wins because the
sprites are an array and memory.
The one that comes earlier draws over,
the one that comes later.
As soon as the white rectangle
it has a small exposition, then the
gumba, it will draw on top of it.
And you can see this as flickering
effects in some games when you walk
through other things.
There are 40 sprites in the system, you
can have 40 sprites on the screen at the
same time, but there's another limitation
per line. You can only have 10 sprites.
So I have an 11th Sprite here and it only
counts per pixel line.
So here, these pixels would not be drawn
or the next line or
the next line. And this is not about the
11th one from the left.
It's the 11th visible one in
the list of sprites in the ordering that
the program decides.
So this is the complete entry.
It fits neatly into four bytes.
So this is one entry in memory.
Zero zero is where these entries are
stored. There are 40 of them for the 40
sprites. And the whole thing is called
the RAM, which is a special purpose
room at this location in memory,
which is not part of video RAM.
One more thing I should say about sprites
is even the small Mario this is the small
one is too big for it, but it's bright.
So you could do it as force bright.
And this is what the game actually does.
But there's another mode where you can
have surprise that a 16 pixels high,
but this is global.
The whole game would have to deal with a
16 pixel sprites then.
So we've seen the three different layers.
There is one more thing.
You can actually completely turn off the
display, which is a fifth color,
which is a little lighter than white,
not very useful because you have to turn
off the complete LCD.
So as soon as you turn on the LCD but
don't do a background, you could wait.
If you draw the background and say you
want to draw it and light gray,
it's completely replaces that color.
You can draw a window on top.
Again, no translucency here and
you can draw sprites on top and
notice that sprites don't distinguish
between whether pixel is background or
window. So there's no clipping going on
with the window.
So how does all this work with
the memory map for kilobytes of sprite
tiles and four kilobytes
of background tiles and
one kilobyte of the background map, the
32 by thirty two.
And we also have a kilobyte of the window
map. It's not the most efficient
representation, but they did it for
because it was easier.
And we only have eight kilobytes of video
ram. So if we put this brutality of the
background tiles here, we have already
run out of video. Ram, let's
try it differently. Let's put the sprites
here. Let's put the background in the
window map here. And what do we do with
the background tiles?
Let's have them overlap
and the different configurations here,
three bits.
We can have them completely overlap or
just partially and we can swap around
these or have them at the same location.
What does this overlap mean?
So this is one configuration, the
background tiles and the tiles there in
the same format, eight eight, two bits
per pixel, so they could share exactly
the same tiles.
But you can also put them this way.
So the first third of the first one,
twenty eight would be Sprite Taza
collusively. The last one twenty eight
would be background tiles exclusively and
the ones in the middle would be shared by
both or useable by both.
And in the case of Super Mario land here
you can see that the first two thirds
are used for sprites and the last third
is used for the background.
The next step is vertical timing,
as in CRT based systems.
So this is how a normal old CRT system
draws its picture very in
a very slow motion version.
It draws it from the top to the bottom,
from the left to the right.
And the same is true on a Gameboy.
It keeps drawing the picture 60 times
a second from top to bottom, line by
line, left to right.
This was not done because they were using
some old components.
They completely redid the
very idea how this was done, but still
nails, if you want to be refreshed 60
times a second and they dried like that.
And this is important to note, if you
wanted to do certain effects that you
cannot otherwise do in this game, for
example, you can see that different parts
of the screen behave differently.
And let's just look at the
scrolling city line here.
It would be easy to just have that scroll
by itself on the full screen, but we only
want to scroll a part of the screen.
And the way this is done is with these
extra registers. So if you've seen a bit
programing on something like AC 64 before
you've seen all this, you can see
you can read which line is currently
being drawn or which will be drawn in
just a moment.
And instead of just busy waiting there,
you can also set and interrupt.
It will wake you up as soon as a certain
line is reached.
So let's set the scroll X register
to zero and let's trigger here at line
eight. So it will draw all of this with a
scroll offset of zero.
At this point, our program will set
the scroll, offset the horizontal scroll
of the two, let's say twenty three in the
next room. We'll set it to twenty four.
So we'll scroll and we'll
compare it just to forty two and it will
continue drawing here with a certain
offset and then we set it to something
else, said another.
I see it keeps drawing like that.
How exactly draws the road here.
We'll talk about that later.
That's a fun trick as well.
And then we set it to zero again because
the dashboard doesn't do any kind of
scrolling and we do the same thing on the
next screen, again
in this example.
So it doesn't have to only have to do
with the scrolling register.
Here's a different example where the
Murray on the top right is actually a
window.
And we talked about this
before. The window will draw from a
certain position to the right and to the
bottom of the screen.
You cannot just have a draw halfway.
But yes, you can.
You trigger a line zero and turn on
the window and the trigger again at line
forty and turn off the window.
So when it draws a line forty,
the people will think a window.
What window?
Don't know about any window, so
it won't draw any further and.
You can see this in all kinds of games,
some of these tricks can be done with a
window. They have to be done with
screens, splitting techniques.
If you don't just trigger on
certain lines, but do something fun on
every line, you can do a trick like this.
So on the left, you can see what's on the
screen. On the right can see what's
actually happening or what's stored
inside the video room if
you change in every line.
This is the curve
that is just used as a transform for
that picture. And that curve changes on
every frame. And all the program has to
do is on every single line.
It has to to
write a different value into the
register.
And of course, it has to be done in every
line. The picture here doesn't show it in
every line.
And the racing game effect is
pretty much the same thing here.
This is what you can see in the video.
It's just a straight road, but it
gets distorted at runtime while the
picture is being drawn.
So let's zoom into this.
This is the source and this is what we
can see on the screen.
So if you ignore the sprites here,
this is the curve that it has to use to
distort it.
And these are all the offsets of X.
So if you keep updating in every
single line, you can warp it like that.
And another thing you can see here is
that the line in the middle is patterned
as well as the part
outside of the road.
And this is done by changing the pallet
every few lines in the circuit.
And you can even go one step further.
This rally game here can also do bumps in
the road, which is done by picking
not just the horizontal scroll register,
but also the vertical scroll register in
every line. So you can
you can duplicate lines and you can skip
lines. And with some good math,
you'll get to that.
And if you update your vertical scroll
register in the middle of a line, you can
do this wobble effect, which is two
dimensional.
But for that, we have to go a little
deeper and go into horizontal
timing.
What happens while a line is being drawn?
So this is the pixel transfer mode
of the people and it usually takes
forty three clocks and this is
done for one hundred and forty four
lines. But you cannot
just imagine that at the end of the first
line it will immediately draw
the first pixel of the next line.
That's not what what's happening because
there's an extra OEM's search at
the beginning of each line, which is
twenty clocks. I'll talk about that in a
minute. And an blank area of
fifty one clocks at the end of every line
in each blank about the people is idling.
It doesn't do anything.
And there's also a blank mode when the
people doesn't do anything between
screens.
So let's do the math aligned.
One hundred and fourteen clocks at one
megahertz.
Fifty four lines.
So this is this many clocks screen.
If you divide the clock by
this, you'll get a refresh rate of fifty
nine point seven hertz.
These four different modes that the
people can be in.
You can read that out and see if you can
know about that and you can also trigger
interrupts based on this.
But why would the CPU have to know?
Let's look at what's going on in these
different modes. First, what is this OEM
surge of twenty cycles at the beginning
of each line for every line, the CPU
has to decide which sprites
are visible in that line.
So there are 40 sprites total in the
system and it has
to filter those sprites.
It has to find the price that are visible
in that line and put them into
an array of up to 10 sprites that are
visible there.
And the logic for that is the exposition
cannot be zero because then it would be
invisible. And the
current line that we're drawing must be
between the first line of the Sprite and
the last line of the Sprite.
So it gets added to the visible sprite
array.
And this takes 20 cycles,
by the way, in the original game.
There was a fun bug here.
If you do
any calculations, any 16 bit calculations
with numbers between four 00
and four, which is the pointer to the OEM
rim, even if you're not accessing RAM at
all, it will destroy
the rim wire during open-mouthed.
So why else
would you have to care about what's going
on?
As if he was connected to RAM.
CPU is connected to video RAM and
a special Pipas also connected directly
to RAM CPU could be connected
to the video RAM as well.
So can write to a video ram.
But this is not how it's done.
You wouldn't need a double speed video
ram here. See 64 does it like that.
But on the Gameboy it has to go through
the CPU and this, this one big switch
where the people can say you cannot
access it right now if you want.
If the if this, if you want to write,
nothing happens. If it reads, it gets all
FNF at least nothing that can
happen. But it's also not very useful.
So the CPU has to make sure that the
people is in the right mode so that it
can access all this
during pixel transfer.
You cannot access video ram, but
you can. But during OEM search
and video and violent video ram access
is OK.
If you want to access OEM RAM,
you cannot do it in either OEM search or
doing pixel transfer because that's when
the sprays are drawn.
The CPU needs that.
You can only access it in those times.
So you have to be very careful in those
times while the screen is being drawn.
So basically all this is bad area
for the CPU. It shouldn't do anything
important at that time.
So, for example, if you want to move in
new columns into the background map, you
should do this in the blank where you
have the most uninterrupted time
and all the game logic of the game.
I can be done while the screen
is being drawn.
But there's a caveat here.
You cannot write the new Sprite
positions at this point because OEM
is going on.
So what games usually do is they
write the new updated Sprite information
into a shadow OEM, which is just a copy
of the OEM.
And then during the blank they copy that
into the real OEM.
So they copy a block from here from
any of those sources into the OEM
as a location. This is not to scale.
It doesn't have to do that
by itself because there's a DMA
function. You just write the block that
you want to be copied into.
This location takes a hundred and sixty
clocks.
And while it's doing that, the
CPU keeps running, but it cannot access
any of the source of
the source address base.
So it has to wait.
But since that code has to come from
somewhere as well, the only place you
can put it is into atrium, which is a
nice use of that as well.
So pixelate pipeline, let's dig in as
deep as it gets into the pipeline, and
this is cutting edge research and some
of these things have been previously
not known to the public.
The pixel is the central
concept of how the Gameboy draws
its picture.
So let's jump somewhere in the middle.
We have some pixels on the LCD already.
So that's five pixels already shifted
out, sent to the LCD
and the pixel five. Let's say there are a
few pixels in there now.
In every step, in every four megahertz
step, it shifts out one pixel and
sends it to the LCD.
It shifts all the pixel, sends it to the
LCD shifts at the next one, sends it to
the LCD. You may have noticed here that a
green button just became red
because the pixel pfeifle has to contain
more than eight pixels to be able to
shift something out. Why that is.
We'll get to that now.
We should get new data and fill
the FIFO and that's what
the future is for.
The future fetches background tiles
and nine eight oh two is right now the
position of the map that it fetches it
from. So it reads the tag number from the
background map takes one cycle in the
next cycle. It reads the first
part of the data and the second part of
the data from the tile rim.
Because every line of a tile
is sixteen bits and from that it
can construct eight new pixels.
It starts over again, goes to the next
location, and it can put those eight
pixels into the upper half of the
FIFA and then it can just continue
pushing those pixels out.
But what is not happening is that
it keeps pushing pixels and when it's
done it has to fetch some again.
Of course, this is all interleaved and
running at the same time. So let's work
through this real quick.
The FIFA is running at twice the speed,
so it does two pushes until
the Fed can do one step.
So push, push.
And we read the first bit of data,
push, push, and
the second part of the data.
And at that point,
it cannot put the data
into the FIFA yet because the FIFA isn't
empty yet. So Fichus, which is
to read, has to wait for two more
cycles here and then.
So it's idle for a while and then it puts
the data in. So if you look at the
memory access patterns, you can see three
reads and and an idle
three reads in an idle.
So again, the FIFA put just pushes one
picks up the clock at four megahertz
pauses unless it contains more than eight
pixels and the fetch runs at two
megahertz, three clocks to fetch those
new eight pixels.
And it pauses in the fourth clock unless
there's space in the available scrolling
is done very simply.
Let's say we scroll by three pixel so
everything is moved to the left by three
pixels.
The first three pixels are just discarded
and then the next pixel goes here on the
LCD. So at the end of the line this
becomes interesting because when we
want to trigger on one hundred and sixty,
the faithful may contain the next few
pixels that we want to actually draw.
And the fetch is already in the middle
of fetching the next tile that we also
don't care about.
So at this point, it'll just stop all
this and it has done too much work and
will be in blank mode, which is the
reason why a line takes forty,
forty, forty three clocks instead of
more logical forty clocks.
If we have a window, let's say
the window triggers at position twenty
six and we're here at twenty six.
The Pfeifle has some data in the fetcher
somewhere in the middle it will
completely clear the FIFA and then the
FIFA will be stopped because we don't
want those pixels anymore that are
already lined up and the fetch will
switch over to the map off
the window and the fetch will be
restarted and then we'll do the tower,
fetch the data, fetch the data, fetch and
we'll get the data from the window.
We can put it into the pixel FIFA.
So as soon as those are shifting out,
window pixels will be drawing
with sprites. There are ten competitors
that are triggering on the position.
And let's say here at position twenty
six, we have a Sprite at that location
and again the pixel FIFA has lots of
pixels and fetch somewhere in the middle.
First we temporarily suspend the pixel
FIFA. It cannot push out any more pixels.
We switch temporarily the fetch to
doing a sprite fetch and
restarting the fetch.
So we're getting the sprite information
and instead of putting it at the end,
we overlaid with the first eight pixels
and we mix them onto the pixels.
And this explains why the FIFA always has
to have eight pixels in there, because
that's how it mixes in the sprites.
This is in stark contrast
to two other systems.
So when we just push out pixels at a
constant rate until the window
starts, when the window starts,
the pfeifle gets cleared.
We are not pushing out pixels for quite
a while until the FIFA has
the window data again.
And which time? At which point it is
resumed. So it takes forty three clocks
or more depending on what's going on the
screen with sprites, it can take even
more.
This is on an LCD based system.
You can do that. You can suspend sending
pixels on a CRT based system.
You cannot see, for example, on a C sixty
four, a line always has to have exactly
forty clocks because any pixel that
comes. Too late, will it be shifted
to the right visually
so it's not completely accurate that we
have 40 clocks for pixel transports,
more like forty three plus and
the blink area is just the remaining
line.
And in practice, this is more like what
it looks like, depending on what sprites
or backgrounds you have.
So I wasn't completely honest about
how the pixel FIFA works.
It does not actually store of pixel
colors. What it does store is the
information, the original information of
the bit combinations
and the source like here, it says
these are a nine background pixels
and the same is true with a fetch.
It does not create pixel colors.
It creates
those combinations, plus the information
which Sprite palliated was or what
the source was.
So let's mix these together.
The Sprite is probably zero, meaning
drawing on top of the background.
And let's go through these Sprite
one zero zero means this is the
translucent. So the background wins.
In this case, the Sprite wins because
it draws on top of the background.
And this is true for most of those
pixels.
And at the very last pixel we can see
this is a Sprite with palette one
and translucent again.
So here the background wins again.
Let's do this one more time with another
Sprite that is at the exact same
location.
In the first case here, Sprite
with a palette of zero draws
on top of the background. Sprite wins and
in this case, a new Sprite does not win
over the old Sprite. There's already a
Sprite at this pixel.
So the old Sprite wins.
And this is true for everything.
And this is how spritzed the draw farther
to the right. Don't draw on top of
existing sprites and sprites with higher
numbers. Don't draw on top of existing
sprites.
And this is the last one with the Sprite
wins again.
And the playing of the palette
is only done at the very end when the
pixel is shifted out.
So we look it up here in the palette.
We convert it to a color and we put it
onto LCD.
Look it up, converted, LCD,
another one black.
And this is how it's also
done on the color system.
So starting with the super Gameboy,
existing games that couldn't really deal
with this could be colorized.
And what's done there, there's
the existing three palettes can now be
RGB palettes.
Everything else in the system is the
same.
But as soon as we
shift this out, it looks up.
RGV color puts the pink pixel
on the screen.
Eleven is one that's here.
Black pixel.
One more example. There are one from S1
because that used to be a Sprite with
palette one.
Put it on the screen.
That's the end of the technical part.
We have five minutes.
Let's talk about development in case
you're now interested in doing Gambo
development.
There are some really nice tools.
The redneck's game boy development system
is a set of command line tools that work
really nice with make files and your
editor of Choice
when you want to debug your code.
The BGB emulator, which is meant for
Windows but works really nicely with
with wine on top of 10 or Linux as
well. It has a built in debugger, single
stepping breakpoints, and it has this
really nice video
viewer that shows you all the details
about what's going on. Also really nice
to run demos and that and see what's
going on inside.
And if you want to run it on real
hardware, there are devices like the EVA
Drive where you can put in an SD
card.
And since we have another four
minutes, let's talk
about my favorite peripheral of the
Gameboy, the Gameboy camera, but not from
a technical perspective, just how great
a device that is.
This is the Gameboy camera.
You put it in the back of the game.
Boy, she it's really nice pictures.
You can print them on the Gameboy
printer, on thermal paper.
If it can still get that paper
and you can get these that you make, you
can take awesome pictures like that.
Let's zoom in a little.
These are really nice pictures.
Every picture is based on
the CD that has 14 color pixels
at a depth of
two.
So next time you go on a trip, make
sure take a Gameboy,
take a Gameboy.
Don't forget your Gameboy camera and a PC
with a parallel port and that one link
cable that you cannot get on
eBay anymore.
So thanks to those people who helped
debug the Gameboy and
helped me with the presentation, and
those people helped me in
various other ways.
So in.
In the series of the ultimate talks,
this was now the fifth talk, what's
next?
There should be a talk next year, right?
I'm suggesting to talks.
I'm nominating four, four, three,
four, three.
Dominic Bogner to talk about
the Archimedes.
And I nominated Janice Hodor.
Well, that's super for Nintendo.
It's your choice, you can do these talks
or you can put a bucket of ice water on
top of your head.
Thank you for your attention and see you
next year.