The Ultimate Game Boy Talk
CC Attribution 4.0 International:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Steil, Michael
The 8-bit Game Boy was sold between 1989 and 2003, but its architecture more closely resembles machines from the early 1980s, like the Commodore 64 or the NES. This talk attempts to communicate "everything about the Game Boy" to the listener, including its internals and quirks, as well as the tricks that have been used by games and modern demos, reviving once more the spirit of times when programmers counted clock cycles and hardware limitations were seen as a challenge.
 So, the next talk, I'm really looking forward to this and I know why most of you are here. Because I'm excited about this too, I own a Game Boy 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. That is how it's supposed to work, right? And I'm looking forward to this. By the way, I'm my favourite games on a Game Boy, the first one to make that clear. Our Mega Man 2, Vario Land and Mystic Quest 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. Yeah, we have as a speaker Michael Steyl and he held a really great talk at 25C3, the ultimate Commodore 64 talk and now with the ultimate Game Boy talk I'm really looking forward to this. Michael Steyl, by day he works on operating system technology, by night he hacks obsolete systems, in a previous life he hacked game consoles. Please, a big round of applause, Michael, the stage is yours. Hello, everyone. Again, my name is Michael Steyl 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 Boy. 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 Game Boy 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 2600, the Galaxya and the Amiga 500 and so it's my turn now. Again. And I picked the Game Boy. Why is the Game Boy so interesting? Because they solve lots and lots of systems. Game Boy, Game Boy Color, 118 million alone. And if you count the Game Boy Advanced models that are compatible, excluding the Game Boy Micro, in total it's almost 200 million systems. They have made about 1600 official games and they produced it from 1989, just the 8-bit models until 2003. And again, if you count the compatible Game Boy Advanced models, they made 8-bit compatible gaming systems until 2009, so that's a 20-year run, which is pretty amazing. Let's look at the competition. Back then, just after the Game Boy, the Atari released the Lynx, Sega, the Game Gear and any 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 Game Boy had 15 to 30 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 Game Boy, of which there are many. The original Game Boy and the original design, which was produced for the longest time, is the DMG. DMG stands for Dot Matrix Game, which was the original code name. Then in 96, they released the Game Boy Pocket, which had a much better screen, much smaller. The MGB, Game Boy Lite was only released in Japan. It had a backlight. And then the Game Boy Color with twice the CPU space, and twice the RAM, and twice the video RAM, and color support. Then the Game Boy Advance series, they were completely different architecture. They were based on an ARM CPU, but still they were 100% backwards compatible with Game Boy and Game Boy Color games. The Advance SP of that one, two models exist. If you want to get one, you really need to get the M-A-G-S 101, which is the one with a backlight instead of the frontlight. And as you can see, Nintendo has always been ahead of its time a little. They didn't only make a rose gold version, but also you need an adapter to plug in regular headphones. If you want to play Game Boy games on a regular TV set, the two options for that, either you use an M Super Nintendo and plug in a Super Game Boy, the two versions of that, one only released in Japan, which had the proper timing, didn't run 3% too fast as the original one, and the Game Boy Player for the Nintendo GameCube. All of these had complete Game Boy hardware embedded inside, basically a normal Game Boy, and it just puts its pixel into the host system instead of on the screen. So what is a Game Boy like? It has a 2.6-inch screen, joypad, mono speaker, you can get stereo over the headphones. There's a link connector, serial port to connect two Game Boy's 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 a game looks like, and basically most games are really just ROM chips, there's nothing more to it. Specifications. What are the specifications of the Game Boy? Let's compare the Game Boy to some other systems that may or may not be comparable. The CPU is a 1 MHz 8-bit CPU. Some people in the audience may complain at this point and say, no, it's a 4 MHz CPU, but I'll explain later why I call it a 1 MHz CPU. There's 8 kB of RAM, which is plenty for a gaming system of that type. VRAM of 8 kB is a little tight. The resolution of 160 by 144 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 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 Game Boy is way more advanced than, for example, the entire 2600, but it's not at all in the league of a Super Nintendo. It's more like a standard Nintendo entertainment system or a Commodore 64. But the fun thing here is that while the NES and the C64 were released in the early 80s, the Game Boy is from 89, and as I said, compatible hardware was supported and released until 2009. So that's what makes it really interesting. It's an 8-bit system, but it's really the latest, the last 8-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 is connected. Speaker and the buttons. The board on the back is much more interesting. This is where you can see three chips. So this is the DMG, the original Game Boy board. Two RAM chips, two identical RAM chips. One is for CPU RAM. One is for video RAM. And this one big chip here, it's called the DMG CPU, but it really is the SOC, 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 Game Boy chip. Let's compare some other boards here. The Super Game Boy, it has a very similar chip. It's actually really 99.9% identical. The Game Boy pocket is a slightly optimized model, it comes only with one RAM chip for both. The Game Boy Lite 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. Then there's the Super Game Boy 2, which is based on the Game Boy pocket. And this is what the Game Boy 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 GB Boy. There have been companies cloning the Game Boy all the time. What this particular model is, it's a perfect clone from decapping and photographing and redoing the mask of the original SOC here. And it's a Chinese Game Boy that you can still buy today for like 30, 40 bucks or so on eBay. It's a shame that the quartz is 30% 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 the system. What is included in the DMG CPU? While a regular CPU core, Interop Controller, Time and Memory, Bootrom, what you would expect from something like that, and then all the peripheral devices like the I.O., Joypad input, serial data transfer for the Link Cable, Assign Controller, and a video controller, the Pixel Processing Unit. So let's talk about the CPU. The Game Boy from 1989 was released between the NES and the Super NES, and the NES came with a 6502. Super NES came with a 816, which is the 16-bit version of that same CPU. So obviously, the Game Boy comes with a Sharp LR35902. What is the Sharp LR35902 core? It's nothing like a 6502. It's more like somewhere in between an Intel AD80 and a Xilog Z80, but it's neither. Both these architectures are interesting because the AD80 was, for example, used in the Altair, which is the first computer that Bill Gates wrote software for and released it for. And the Z80 is in pretty much every 8-bit home computer system that did not contain a 6502, very successful architecture. So if you imagine, this is the feature set of the Intel AD80. That's the feature set of the Xilog Z80. So it's a strict superset. It's perfectly back when it's compatible. And that is the Game Boy CPU. The core architecture is the same as the one from the AD80. So all the core features are the register set, the instruction encoding, all that is the same. But there are some features that are not supported. But it does support some Z80 features, but it does not support most of the Z80 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 AD80 first. It has these registers. There's the accumulator, which is special. It's the one that can do all the arithmetic and logic. You cannot do these with the other registers. A flags register, it only has two useful flags, the zero and the carry flag in the Game Boy model. The other two are only used for decimal adjust. And then there's BCDEHL, another set of 8-bit registers. But the fun thing about those is that you can combine B and C into BC and DE and HL, same thing. So you actually have 16-bit registers that you can use as pointers, for example. So in total, there are four 16-bit registers that can do some things. And seven 8-bit registers plus one special case here, which is the memory allocation pointed to or the value at the memory allocation pointed to by the HL register, which can be used in place of any register in any instruction, which is pretty nice. So these are the instructions. The load and store is practically the same instruction. You can indirect, immediate, direct. Stack is 16-bit. It can only push 16-bit registers. These are arithmetic and logic ones. As I said, only the accumulator can do most of those, except for incrementing and decrementing, which works in any register. And that one also works on 16-bit registers. There are rotate instructions, control flow, jump, call, and return, conditional and indirect. And then some miscellaneous functions setting the carry, clearing the carry, not halt, and disabling and enabling the interrupt. What is the interrupt model? On most systems of that time, you would expect there's an interrupt vector for all the interrupts. But it's neither a vector 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, so hex 40, hex 48, and so on. And there's also a concept of software interrupts. You can jump to these locations with special instructions. And RST0 is a special one because this is the same as a reset. When you turn on an 8080 CPU, it starts at location zero. Let's talk about the few unsupported 8080 features. So these are the flags of the Game Boy. These are the actual flags of the 8080. And it has two extra flags. One is the sign flag, which is kind of useful, and the parity flag, which is not. So none of these instructions are supported. And a few others. For some reason, they just decided not to include those. Port IO, you may remember that from the 8086. It has the port space. That one is in the 8080, but it's not supported on the Game Boy because it uses memory mapped IO instead. The 8080 has lots of extra rotate and pitch shift and pitch testing setting and resetting instructions. All of those are supported as is the relative jump instruction, which is a more optimized version of a jump. And the return from interrupt. That's all that is supported. Everything that is not supported is all the interesting stuff from the 8080, which is the second register set, the extra two registers, and lots and lots of features, including the auto increment and decrement and loop instructions, which are nice for copying memory. But it has a few features of its own that take their place. For example, there's a post increment and decrement. So if you want to access memory, that is pointed to by HL. You can post increment or you can pre-decrement HL. There's also the concept of a zero page. And it's a little confusing because not actually page zero in RAM. It's the topmost page in RAM. And if you know the 65 or two, you can see this is a concept borrowed from the 65 or two. It just means that there's an optimized instruction encoding for instructions that are in the, for memory accesses that are in the topmost page of RAM. So instead of doing this, loading from FF 40, which takes three bytes and four cycles, you can encode it like this. It takes two bytes and three cycles. And obviously you have to put something useful up there in the topmost page, which is timing critical. They added a few stack instructions, another store SP instruction. You can swap the low and the high nibble. They added eight instructions there. And there's an extra power saving instruction. So this is what the opcode table looks like. Just to get an idea from the color coding, that you can see this is quite orthogonal. And there are a few instructions that are, or a few opcodes that are not in use and they all crash, which is a nice design. And this one is special, the opcode CB. It's a prefix which hosts another 256 opcodes. This is the complete opcode space for the rotate and shift instructions borrowed from the Z80 plus the additional swap instruction that was added on the GameBose CPU. Let's look at another instruction here, just as an example. This is a low, it loads from a fixed address. This means it takes three bytes, 16 clocks. 16 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 CPU that is clocked at one megahertz and it takes four clocks for this. And these are much strenuer numbers now because now the numbers are actually comparable with similar systems like 65 or two base systems that also have one megahertz memory with a one megahertz CPU. So in theory, yes, the CPU is clocked with four megahertz. The RAM runs at one megahertz. The PPU draws its pixels, the pixel processing unit at four megahertz and is connected to VRAM that is running at 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 Mibihertz as in 1024 times 24 hertz. So they didn't base it on factor 10, they based it on base two. Just pretty. And so from now on if I speak about cycles, I mean machine cycles at one megahertz. So that's the CPU and it's a 16-bit CPU, an 8-bit CPU that has a 16-bit address space because of the 16-bit pointers. So 64 kilobytes of address space is all it can see. 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 boot ROM lying on top of that that we'll talk about later. Videoram 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 OAM RAM which is a special purpose videoram that is distinct from the videoram that we'll talk about later. And then the last page which is the zero page contains the IO area, so all the registers for all the peripherals like sound and video, plus another 127 bytes of H-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 there. 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 controller 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 bank zero of the ROM and the upper 16k map two, whatever they can map to, bank one, bank two, and so on. And all this is controlled by writing magic values into ROM locations which then will 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 battery backed, that's the only way to do safe games, it can map in external RAM here. Same model. So what's up with this boot ROM? The CPU starts running at location zero in memory and the boot ROM is the thing that draws this and does the chime. This boot ROM is built into the Game Boy and took a while until this was extracted, was a real pain, not done by me. And what it does is this is the complete boot ROM, it initializes RAM, initializes sound, sets up and decodes the logo that it puts on the screen, that it scrolls in the logo, it plays the chime, 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 boot. 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 you include that and you don't have Nintendo's permission. After that, it also checks the header just to make sure that all you don't have to blow into the pins and then it turns off the ROM and continues execution in there. So that logo, though, is actually presented from the cartridge, so if you boot up a Game Boy without a cartridge, you will see this. But it doesn't mean that an application or a game can put any logo in there because it does get compared and at that point it wouldn't boot any further. And since there was no cleanup code, it doesn't reset the system or anything or clear the screen, so some games did something like this, they played with what's on the screen, let's just continue with that. And of course, demos also like to play with that. The Nintendo logo is on the screen, let's just do something with it. Which is pretty nice. So the boot ROM runs until the last instruction and the last instruction is the one that turns off the boot ROM. So at this point, even the first page in ROM is mapped to show game data and it continues running here, so it just continues running into the next instructions from the game. And usually there's a jump there because there's a header that is specified to be there at this location. That header contains the Nintendo logo and the header checks 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 doesn't actually check any of this. And after that, you can have the actual game data. So one other thing that we haven't looked at is the IOW area and HRAM, which is the topmost page in the system, it's the zero page, it's the one that you can access quite efficiently. So the top 127 here are extra RAM and all the rest you can sprinkle throughout here, you can see the different devices. And these are all the registers total in the system, interrupt controller, sound controller, joypad, serial, timer and pixel processing unit. And these are all the components that we'll talk about now. Joypad input, it's really simple. These are all the inputs the gameboy has, it's four buttons and four directions, so you would think let's have eight GPIOs and with that we can do this, but we can actually do it with six GPIOs 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 button was pressed. So they could do it with six instead of eight. That's all about the buttons, pretty simple. Serial data transfer, you can connect two gameboys together with a link cable. Everything the link cable consisted of was one wire of data in the one direction, one wire for data in the other direction and a third wire for the clock. The two gameboys 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 receiving clock can really be anything, it can go up to 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, as any system, it has a timer, there's only one timer. The TMA 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 start it and then it counts up until it overflows and at the overflow time it reloads the module number and can optionally generate an interrupt. Speaking of interrupts, the interrupt controller supports five different interrupts. Vblank and LCD stat deal with the pixel processing unit, we'll talk about those later. We've already seen the timer, serial can cause an interrupt when a new byte has been received and joypad when a button has been pressed. This was the interrupt enable register and there's the interrupt flag register where you can see which interrupt is still pending. And these are the addresses where those different interrupts jump. So you don't have to find out which interrupt it was because there's a few jumps to different locations. So the sound controller, nothing has as many registers as the sound controller because there's four voices and they all have their distinct registers. 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 is called voice and one that 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 bit and a length register so you can just say turn it off after a quarter second. 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 16 bytes of register here which is 32 entries of four bits each and these can describe any waveform that you like that fits into these 32 slots. So here are some examples, you could for example create a sawtooth which is a pretty simple waveform or 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. It controls how fast that wave table is played. And two extra bits of volume so you can play it 100%, 50%, 25% or you can mute it. The other two here, 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 here. 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. 12.5 high and the rest is low. 25%. 50. And then 75 should sound exactly like 25. 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 frequency sweep. So you can go up. Or you can go down. So you can see this is mostly meant for sound effects. 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 pseudoramnum numbers. And depending on whether you set it to 15-bit mode or 7-bit mode, it will do one of two different waveforms. That's 15-bit mode. And that's 7-bit mode. So these are all the registers again. Different voices. And three general purpose registers. This register has a volume for left, volume for 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 where you can say should a voice be on the left or the right on the right on both or on neither. And then there's the power bit if you turn off the power to audio. You will save like 13% or so of energy. So the Game Boy sound is not only used for games. People still compose music in tools like Little Sound DJ today on the Game Boy. I'll show you a short example of that. So much for sound. 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, 160 by 140 pixels, not that much. Four shades of gray, which is more like four bad shades of green. Later Game Boy sound much better. Everything on the screen is 8 by 8 tile based and there are a certain number of tiles on the screen that's sprites and all this has to deal with 8 kilobytes of video RAM. What do I mean when I say 8 by 8 pixel tiles? If we look at a game like Tetris, you can see everything is blocky. Everything is based on these blocks. Same with Zelda. If we put the grid over it, you can see they're 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 is aligned to that, even though they did a very good job at hiding that. In some games, you can see it because it plays with that very concept. So here in Turrican, you can see it fills the screen with tiles. Let's look at a tile and what a tile is like. Tile consists of 8 times 8 pixels and has four colors like everything in the system. These colors are encoded, 0, 0, 1, 1, 0, 1, 1. 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, 0, 2, and ff. So for every line of pixels, I need two bytes. And in total, I need 16 bytes to describe a whole tile. You may have noticed here that the ordering of the colors here doesn't necessarily make sense. This is because I can choose my own palette. It can be any palette. There's a 2-bit to 2-bit mapping in the system for these background tiles. So the native colors are 0, 0 means white and 1, 1 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 256 tiles in the system. So this tile set, do you recognize 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 Super Mario Land, which only uses 128 tiles. You can't 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 puzzled together from 20 tiles by 18 tiles which fill up the whole screen, which is not the whole truth because actually in video RAM there are 32 tiles by 32 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 that 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 32 map. But this only works with games that are maximum 32 by 32. What about games 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 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. This also works in two dimensions. This is Donkey Kong Land 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 is 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 a 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 is you put it to the very right or you put it to the very bottom. It just overlays this 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. It's a game of color games but it wouldn't matter. It works on the game by just as well. And then there's another layer on top of the background and the window, which is sprites. Sprites are objects on the screen that don't fit into the 8x8 rasters. You can position them freely. So we have three sprites here in the system. Nintendo calls them objects, OBJ. But I'll keep calling them sprites because everyone calls them sprites. Let's just look at this Goomba here. Every sprite in the system has attributes. And there's the OAM, which is the object attribute map. And this is one OAM entry. And it has these values. So one of them is the X position. So if we put the Goomba to the very left of the screen, you would expect it 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 at 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 wide position where you see it fully is 16 because sprites can be up to 16 bits, 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 an 8x8 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 256 tiles in the system, which is a byte. And we can see it here. It's tile hex 90. The next thing is the flip expert. So you don't have to save two Goombas here. One that walks to the left and one that walks 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 Goomba. You flip it horizontally and vertically, and you have a dead Goomba walking the other direction. So let's put it right side up again. The next bit is the palette. 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 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 palette zero, palette one? If it takes palette one, it would look like this. Would look like this with palette zero. It looks like this. And one more bit is priority. So how does the sprite draw in comparison with the background? If the 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, the Goomba could very well be drawn on top of any other color. If we set the priority 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. We have this rectangle here. And the Goomba is on top of the rectangle, which is because the Goomba's horizontal position is smaller than the rectangles. As soon as they are at the same horizontal position, the sprite with a lower number wins because the sprites are an array in memory, the one that comes earlier draws over the one that comes later. As soon as the white-ranked angle has a smaller X position than the Goomba, 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 OAM entry. It fits neatly into four bytes. So this is one OAM entry in memory. FE00 is where these entries are stored. There are 40 of them for the sprites, and the whole thing is called the OAM RAM, which is a special purpose RAM 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 8 by 8 sprites. So you could do it as four sprites, and this is what the game actually does. But there's another mode where you can have sprites that are 16 pixels high. But this is global. The whole game would have to deal with the 16 pixel sprites then. So we've seen the three different layers. There's 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 draw a background, you get white. If you draw the background and say you want to draw it in light gray, it completely replaces that color. You can draw a window on top, again, no translucency here. And you can draw sprites on top. Notice that sprites don't distinguish between whether a 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? Four kilobytes of sprite tiles, and four kilobytes of background tiles, and one kilobyte of the background map, the 32 by 32, 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. We only have eight kilobytes of video RAM, so if we put the sprites 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. What do we do with the background tiles? Let's have them overlap. And there are 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 sprite tiles, they're in the same format, 8 by 8, 2 bits per pixel, so they could share exactly the same tiles. But you can also put them this way. So the first third, the first 128, would be sprite tiles exclusively. The last 128 would be background tiles exclusively, and the ones in the middle would be shared by both, or usable 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 Game Boy. 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 reusing some old components. They completely read it, the very idea how this was done, but still an LCD wants to be refreshed 60 times a second, and they draw it like that. And this is important to know 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. If you've seen 8-bit programming on something like a C64 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 an 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 this with a scroll offset of zero. At this point, our program will set the scroll offset, the horizontal scroll offset to, let's say, 23. In the next frame, we'll set it to 24, so we'll scroll. And we'll set the compare register to 42, and it will continue drawing here with a certain offset. And then we set it to something else, set another lyc. It keeps drawing like that. How exactly it 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 only have to do with the X scrolling register, here's a different example where the Mario 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 it draw halfway. But yes, you can. You trigger at line zero and turn on the window, and they trigger again at line 40 and turn off the window. So when it draws line 40, the PPU will think, window? What window? No, no, no, no 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 the window, other have to be done with screen 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, you can see what's actually happening or what's stored inside the video RAM. If you change SCX in every line, this is the curve that is just used as a tool. The 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 write a different SCX value into the SCX register. And of course, it has to be done in every line. This 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 RAM. 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 SCX. So if you keep updating SCX 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 palette every few lines. 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 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 PPU. It usually takes 43 clocks. And this is done for 144 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's happening. Because there's an extra OAM search at the beginning of each line, which is 20 clocks. I'll talk about that in a minute. And an H blank area of 51 clocks at the end of every line. In H blank mode, the PPU is idling. It doesn't do anything. And there's also a V blank mode when the PPU doesn't do anything between screens. So let's do the math. A line is 114 clocks at 1 megahertz, 54 lines. So this is this many clocks per screen. If you divide the base clock by this, you'll get a refresh rate of 59.7 hertz. These four different modes that the PPU can be in, you can read that out. And the CPU 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 OAM search of 20 cycles at the beginning of each line? So every line, the PPU 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 sprites 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 where there was a fun bug here, if you do any calculations, any 16-bit calculations with numbers between FE00 and FEFF, which is the pointer to the OAM RAM, even if you're not accessing RAM at all, it will destroy the RAM during OAM mode. So why else would you have to care about what's going on? The CPU is connected to RAM. PPU is connected to video RAM. And OAM RAM is special. PPU is also connected directly to OAM RAM. CPU could be connected to the video RAM as well, so it can write to video RAM. But this is not how it's done. You would need a double-speed video RAM here. C64 does it like that. But on the Game Boy, it has to go through the PPU. And there's this one big switch where the PPU can say, you cannot access it right now if you want, if the CPU wants to write, nothing happens. If it reads, it gets all FEFF. At least nothing bad can happen, but it's also not very useful. So the CPU has to make sure that the PPU 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 OAM search, H blank and V blank, video RAM access is okay. If you want to access OAM RAM, you cannot do it in either OAM search or during pixel transfer because that's when the sprites are drawn, the PPU 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 V blank, where you have the most uninterrupted time. And all the game logic, all the game AI 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 OAM is going on. So what games usually do is they write the new updated sprite information into a shadow OAM, which is just a copy of the OAM. And then during V blank, they copy that into the real OAM. So they copy a block from here from any of those sources into the OAM as a location. This is not to scale. You don'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 160 clocks. And while it's doing that, the CPU keeps running, but it cannot access any of the source address space. 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 Hram, which is a nice use of that as well. So pixel pipeline, let's dig in as deep as it gets into the pixel pipeline. And this is cutting edge research. And some of these things have been previously not known to the public. The pixel FIFO is the central concept of how the Game Boy draws its picture. So let's jump somewhere in the middle. We have some pixels on the LCD already. So there's five pixels already shifted out, sent to the LCD. And the pixel FIFO, let's say, there are a few pixels in there. Now in every step, in every four-megahit step, it shifts out one pixel and sends it to the LCD. It shifts out a pixel, sends it to the LCD, shifts out the next one, sends it to the LCD. You may have noticed here that a green button just became red because the pixel FIFO 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 FETCHER is for. The FETCHER's background tiles and 9802 is right now the position of the map that it fetches it from. So it reads the tile number from the background map, takes one cycle, and the next cycle it reads the first part of the data and the second part of the data from the tile RAM because every line of a tile is 16 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 FIFO. 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 walk through this real quick. The FIFO is running at twice the speed, so it does two pushes until the FETCHER can do one step. So push, push, and we read the first byte of data, push, push, and the second part of the data. And at that point, it cannot put the data into the FIFO yet because the FIFO isn't empty yet. So FETCHER switches to red, 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 an idle, three reads and an idle. So again, the FIFO pushes one pixel per clock at four megahertz, pauses unless it contains more than eight pixels. And the FETCHER 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 FIFO available. Scrolling is done very simply. Let's say we scroll by three pixels, so everything's 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 160, the FIFO may contain the next few pixels that we won't actually draw. And the FETCHER 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 H blank mode, which is the reason why a line takes 43 clocks instead of more logical 40 clocks. If we have a window, let's say the window triggers at position 26, and we're here at 26, the FIFO has some data in it. The FETCHER is somewhere in the middle. It will completely clear the FIFO, and then the FIFO will be stopped because we don't want those pixels anymore that are already lined up. And the FETCHER will switch over to the map of the window, and the FETCHER will be restarted. And then we'll do the tile fetch, the data fetch, the data fetch, and we'll get the data from the window. We can put it into the pixel FIFO. So as soon as those are shifting out, window pixels will be drawing. With sprites, there are 10 comparators that are triggering on the X position. And let's say here at position 26, we have a sprite at that location. And again, the pixel FIFO has lots of pixels, and FETCHER is somewhere in the middle. First we temporarily suspend the pixel FIFO. It cannot push out any more pixels. We switch temporarily the FETCHER to doing a sprite FETCHER and restarting the FETCHER. So we're getting the sprite information. And instead of putting it at the end, we overlay it with the first eight pixels, and we mix them onto the pixels. And this explains why the FIFO always has to have eight pixels in there, because that's how it mixes in the sprites. This is in stark contrast to other systems. So when we just push out pixels at a constant rate until a window starts, when the window starts, the FIFO gets cleared. We are not pushing out pixels for quite a while until the FIFO has the window data again, and at which point it is resumed. So it takes 43 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. So for example, on a C64, a line always has to have exactly 40 clocks, because any pixel that comes a clock too late will be shifted to the right visually. So it's not completely accurate that we have 40 clocks. For pixel transfer, it's more like 43 plus. And the H-blank area is just the remaining line. And in practice, this is more like what it looks like, depending on what sprites or background you have. So I wasn't completely honest about how the Pixel FIFO works. It does not actually store pixel colors. What it does store is the original information of the bit combinations and the source. Like here it says these are nine background pixels. And the same is true with a fetch. It does not create pixel colors. It creates those bit combinations plus the information which sprite palette it was or what the source was. So let's mix these together. The sprite is priority zero, meaning drawing on top of the background. And let's go through these. There's sprite 1, 0, 0, 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 1. And it's 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 0 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 sprites that 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 where the sprite wins again. And the applying 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 on LCD. Look it up, convert it, LCD. Another one, black. And this is how it's also done on the color system. So starting with the Super Game Boy, existing games that couldn't really deal with this could be colorized. And what's done there, 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. RGB color puts a pink pixel on the screen. 11, S1. That's here. Black pixel. One more example, 01 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 more minutes. Let's talk about development. In case you're now interested in doing Game Boy development, there are some really nice tools. The Rednecks 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 BGP emulator, which is meant for Windows, but works really nicely with wine on top of OS X or Linux as well. It has a built-in debugger, single stepping break points, and it has this really nice video RAM viewer that shows you all the details about what's going on. Also really nice to run demos in that and see what's going on inside. If you want to run it on real hardware, there are devices like the EverDrive where you can put in an SD card. Since we have another four minutes, let's talk about my favorite peripheral of the Game Boy, the Game Boy Camera. But not from a technical perspective, just how great a device that is. This is the Game Boy Camera. You put it at the back of the Game Boy. It's really nice pictures. You can print them on the Game Boy printer, on thermal paper if you can still get that paper, and you can get these to 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 CCD that has 14 kilopixels and a bit depth of two. Next time you go on a trip, make sure, take a Game Boy. Don't forget your Game Boy 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 Game Boy and helped me with a presentation, and those people helped me in various other ways. So 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 two talks. I'm nominating for 34C3. Dominic Wagner to talk about the Acorn Archimedes. And I nominate Janis Harder. For the Super 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. So do you guys. you
 So, the next talk, I'm really looking forward to this and I know why most of you are here.  Because I'm excited about this too, I own a Game Boy 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.  That is how it's supposed to work, right?  And I'm looking forward to this.  By the way, I'm my favourite games on a Game Boy, the first one to make that clear.  Our Mega Man 2, Vario Land and Mystic Quest 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.  Yeah, we have as a speaker Michael Steyl and he held a really great talk at 25C3, the  ultimate Commodore 64 talk and now with the ultimate Game Boy talk I'm really looking  forward to this.  Michael Steyl, by day he works on operating system technology, by night he hacks obsolete  systems, in a previous life he hacked game consoles.  Please, a big round of applause, Michael, the stage is yours.  Hello, everyone.  Again, my name is Michael Steyl 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 Boy.  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 Game Boy 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 2600, the Galaxya and the Amiga 500 and so it's my turn now.  Again.  And I picked the Game Boy.  Why is the Game Boy so interesting?  Because they solve lots and lots of systems.  Game Boy, Game Boy Color, 118 million alone.  And if you count the Game Boy Advanced models that are compatible, excluding the Game Boy  Micro, in total it's almost 200 million systems.  They have made about 1600 official games and they produced it from 1989, just the 8-bit  models until 2003.  And again, if you count the compatible Game Boy Advanced models, they made 8-bit compatible  gaming systems until 2009, so that's a 20-year run, which is pretty amazing.  Let's look at the competition.  Back then, just after the Game Boy, the Atari released the Lynx, Sega, the Game Gear and  any 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 Game Boy had 15 to 30 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 Game Boy, of which there are many.  The original Game Boy and the original design, which was produced for the longest time, is  the DMG.  DMG stands for Dot Matrix Game, which was the original code name.  Then in 96, they released the Game Boy Pocket, which had a much better screen, much smaller.  The MGB, Game Boy Lite was only released in Japan.  It had a backlight.  And then the Game Boy Color with twice the CPU space, and twice the RAM, and twice the  video RAM, and color support.  Then the Game Boy Advance series, they were completely different architecture.  They were based on an ARM CPU, but still they were 100% backwards compatible with Game Boy  and Game Boy Color games.  The Advance SP of that one, two models exist.  If you want to get one, you really need to get the M-A-G-S 101, which is the one with  a backlight instead of the frontlight.  And as you can see, Nintendo has always been ahead of its time a little.  They didn't only make a rose gold version, but also you need an adapter to plug in regular  headphones.  If you want to play Game Boy games on a regular TV set, the two options for that, either you  use an M Super Nintendo and plug in a Super Game Boy, the two versions of that, one only  released in Japan, which had the proper timing, didn't run 3% too fast as the original one,  and the Game Boy Player for the Nintendo GameCube.  All of these had complete Game Boy hardware embedded inside, basically a normal Game Boy,  and it just puts its pixel into the host system instead of on the screen.  So what is a Game Boy like?  It has a 2.6-inch screen, joypad, mono speaker, you can get stereo over the headphones.  There's a link connector, serial port to connect two Game Boy's 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 a game looks like, and basically most games are really just ROM chips, there's  nothing more to it.  Specifications.  What are the specifications of the Game Boy?  Let's compare the Game Boy to some other systems that may or may not be comparable.  The CPU is a 1 MHz 8-bit CPU.  Some people in the audience may complain at this point and say, no, it's a 4 MHz CPU,  but I'll explain later why I call it a 1 MHz CPU.  There's 8 kB of RAM, which is plenty for a gaming system of that type.  VRAM of 8 kB is a little tight.  The resolution of 160 by 144 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 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 Game Boy  is way more advanced than, for example, the entire 2600, but it's not at all in the league  of a Super Nintendo.  It's more like a standard Nintendo entertainment system or a Commodore 64.  But the fun thing here is that while the NES and the C64 were released in the early  80s, the Game Boy is from 89, and as I said, compatible hardware was supported and released  until 2009.  So that's what makes it really interesting.  It's an 8-bit system, but it's really the latest, the last 8-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 is connected.  Speaker and the buttons.  The board on the back is much more interesting.  This is where you can see three chips.  So this is the DMG, the original Game Boy board.  Two RAM chips, two identical RAM chips.  One is for CPU RAM.  One is for video RAM.  And this one big chip here, it's called the DMG CPU, but it really is the SOC, 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 Game Boy chip.  Let's compare some other boards here.  The Super Game Boy, it has a very similar chip.  It's actually really 99.9% identical.  The Game Boy pocket is a slightly optimized model, it comes only with one RAM chip for  both.  The Game Boy Lite 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.  Then there's the Super Game Boy 2, which is based on the Game Boy pocket.  And this is what the Game Boy 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 GB Boy.  There have been companies cloning the Game Boy all the time.  What this particular model is, it's a perfect clone from decapping and photographing and  redoing the mask of the original SOC here.  And it's a Chinese Game Boy that you can still buy today for like 30, 40 bucks or so on eBay.  It's a shame that the quartz is 30% 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 the system.  What is included in the DMG CPU?  While a regular CPU core, Interop Controller, Time and Memory, Bootrom, what you would expect  from something like that, and then all the peripheral devices like the I.O., Joypad input,  serial data transfer for the Link Cable, Assign Controller, and a video controller, the Pixel  Processing Unit.  So let's talk about the CPU.  The Game Boy from 1989 was released between the NES and the Super NES, and the NES came  with a 6502.  Super NES came with a 816, which is the 16-bit version of that same CPU.  So obviously, the Game Boy comes with a Sharp LR35902.  What is the Sharp LR35902 core?  It's nothing like a 6502.  It's more like somewhere in between an Intel AD80 and a Xilog Z80, but it's neither.  Both these architectures are interesting because the AD80 was, for example, used in the Altair,  which is the first computer that Bill Gates wrote software for and released it for.  And the Z80 is in pretty much every 8-bit home computer system that did not contain a  6502, very successful architecture.  So if you imagine, this is the feature set of the Intel AD80.  That's the feature set of the Xilog Z80.  So it's a strict superset.  It's perfectly back when it's compatible.  And that is the Game Boy CPU.  The core architecture is the same as the one from the AD80.  So all the core features are the register set, the instruction encoding, all that is  the same.  But there are some features that are not supported.  But it does support some Z80 features, but it does not support most of the Z80 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 AD80 first.  It has these registers.  There's the accumulator, which is special.  It's the one that can do all the arithmetic and logic.  You cannot do these with the other registers.  A flags register, it only has two useful flags, the zero and the carry flag in the Game Boy  model.  The other two are only used for decimal adjust.  And then there's BCDEHL, another set of 8-bit registers.  But the fun thing about those is that you can combine B and C into BC and DE and HL,  same thing.  So you actually have 16-bit registers that you can use as pointers, for example.  So in total, there are four 16-bit registers that can do some things.  And seven 8-bit registers plus one special case here, which is the memory allocation  pointed to or the value at the memory allocation pointed to by the HL register, which can be  used in place of any register in any instruction, which is pretty nice.  So these are the instructions.  The load and store is practically the same instruction.  You can indirect, immediate, direct.  Stack is 16-bit.  It can only push 16-bit registers.  These are arithmetic and logic ones.  As I said, only the accumulator can do most of those, except for incrementing and decrementing,  which works in any register.  And that one also works on 16-bit registers.  There are rotate instructions, control flow, jump, call, and return, conditional and indirect.  And then some miscellaneous functions setting the carry, clearing the carry, not halt, and  disabling and enabling the interrupt.  What is the interrupt model?  On most systems of that time, you would expect there's an interrupt vector for all the interrupts.  But it's neither a vector 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, so hex 40,  hex 48, and so on.  And there's also a concept of software interrupts.  You can jump to these locations with special instructions.  And RST0 is a special one because this is the same as a reset.  When you turn on an 8080 CPU, it starts at location zero.  Let's talk about the few unsupported 8080 features.  So these are the flags of the Game Boy.  These are the actual flags of the 8080.  And it has two extra flags.  One is the sign flag, which is kind of useful, and the parity flag, which is not.  So none of these instructions are supported.  And a few others.  For some reason, they just decided not to include those.  Port IO, you may remember that from the 8086.  It has the port space.  That one is in the 8080, but it's not supported on the Game Boy because it uses memory mapped  IO instead.  The 8080 has lots of extra rotate and pitch shift and pitch testing setting and resetting  instructions.  All of those are supported as is the relative jump instruction, which is a more optimized  version of a jump.  And the return from interrupt.  That's all that is supported.  Everything that is not supported is all the interesting stuff from the 8080, which is  the second register set, the extra two registers, and lots and lots of features, including  the auto increment and decrement and loop instructions, which are nice for copying memory.  But it has a few features of its own that take their place.  For example, there's a post increment and decrement.  So if you want to access memory, that is pointed to by HL.  You can post increment or you can pre-decrement HL.  There's also the concept of a zero page.  And it's a little confusing because not actually page zero in RAM.  It's the topmost page in RAM.  And if you know the 65 or two, you can see this is a concept borrowed from the 65 or  two.  It just means that there's an optimized instruction encoding for instructions that are in the,  for memory accesses that are in the topmost page of RAM.  So instead of doing this, loading from FF 40, which takes three bytes and four cycles,  you can encode it like this.  It takes two bytes and three cycles.  And obviously you have to put something useful up there in the topmost page, which is timing  critical.  They added a few stack instructions, another store SP instruction.  You can swap the low and the high nibble.  They added eight instructions there.  And there's an extra power saving instruction.  So this is what the opcode table looks like.  Just to get an idea from the color coding, that you can see this is quite orthogonal.  And there are a few instructions that are, or a few opcodes that are not in use and they  all crash, which is a nice design.  And this one is special, the opcode CB.  It's a prefix which hosts another 256 opcodes.  This is the complete opcode space for the rotate and shift instructions borrowed from  the Z80 plus the additional swap instruction that was added on the GameBose CPU.  Let's look at another instruction here, just as an example.  This is a low, it loads from a fixed address.  This means it takes three bytes, 16 clocks.  16 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 CPU that is clocked at one megahertz  and it takes four clocks for this.  And these are much strenuer numbers now because now the numbers are actually comparable with  similar systems like 65 or two base systems that also have one megahertz memory with a  one megahertz CPU.  So in theory, yes, the CPU is clocked with four megahertz.  The RAM runs at one megahertz.  The PPU draws its pixels, the pixel processing unit at four megahertz and is connected to  VRAM that is running at 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 Mibihertz as in 1024 times 24 hertz.  So they didn't base it on factor 10, they based it on base two.  Just pretty.  And so from now on if I speak about cycles, I mean machine cycles at one megahertz.  So that's the CPU and it's a 16-bit CPU, an 8-bit CPU that has a 16-bit address space  because of the 16-bit pointers.  So 64 kilobytes of address space is all it can see.  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 boot ROM lying on top of that that we'll talk about later.  Videoram 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 OAM RAM which  is a special purpose videoram that is distinct from the videoram that we'll talk about later.  And then the last page which is the zero page contains the IO area, so all the registers  for all the peripherals like sound and video, plus another 127 bytes of H-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 there.  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 controller 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 bank zero of the ROM and the upper 16k map two,  whatever they can map to, bank one, bank two, and so on.  And all this is controlled by writing magic values into ROM locations which then will  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 battery backed, that's the only way to do safe games, it can  map in external RAM here.  Same model.  So what's up with this boot ROM?  The CPU starts running at location zero in memory and the boot ROM is the thing that  draws this and does the chime.  This boot ROM is built into the Game Boy and took a while until this was extracted, was  a real pain, not done by me.  And what it does is this is the complete boot ROM, it initializes RAM, initializes sound,  sets up and decodes the logo that it puts on the screen, that it scrolls in the logo,  it plays the chime, 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 boot.  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 you include that and you don't have Nintendo's permission.  After that, it also checks the header just to make sure that all you don't have to blow  into the pins and then it turns off the ROM and continues execution in there.  So that logo, though, is actually presented from the cartridge, so if you boot up a Game  Boy without a cartridge, you will see this.  But it doesn't mean that an application or a game can put any logo in there because  it does get compared and at that point it wouldn't boot any further.  And since there was no cleanup code, it doesn't reset the system or anything or clear the  screen, so some games did something like this, they played with what's on the screen, let's  just continue with that.  And of course, demos also like to play with that.  The Nintendo logo is on the screen, let's just do something with it.  Which is pretty nice.  So the boot ROM runs until the last instruction and the last instruction is the one that turns  off the boot ROM.  So at this point, even the first page in ROM is mapped to show game data and it continues  running here, so it just continues running into the next instructions from the game.  And usually there's a jump there because there's a header that is specified to be there at  this location.  That header contains the Nintendo logo and the header checks 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 doesn't actually check any of this.  And after that, you can have the actual game data.  So one other thing that we haven't looked at is the IOW area and HRAM, which is the  topmost page in the system, it's the zero page, it's the one that you can access quite  efficiently.  So the top 127 here are extra RAM and all the rest you can sprinkle throughout here,  you can see the different devices.  And these are all the registers total in the system, interrupt controller, sound controller,  joypad, serial, timer and pixel processing unit.  And these are all the components that we'll talk about now.  Joypad input, it's really simple.  These are all the inputs the gameboy has, it's four buttons and four directions, so  you would think let's have eight GPIOs and with that we can do this, but we can actually  do it with six GPIOs 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 button was pressed.  So they could do it with six instead of eight.  That's all about the buttons, pretty simple.  Serial data transfer, you can connect two gameboys together with a link cable.  Everything the link cable consisted of was one wire of data in the one direction, one  wire for data in the other direction and a third wire for the clock.  The two gameboys 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 receiving clock can really be anything, it can go up to 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, as any system, it has a timer, there's only one timer.  The TMA 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 start it and then it counts up  until it overflows and at the overflow time it reloads the module number and can optionally  generate an interrupt.  Speaking of interrupts, the interrupt controller supports five different interrupts.  Vblank and LCD stat deal with the pixel processing unit, we'll talk about those later.  We've already seen the timer, serial can cause an interrupt when a new byte has been received  and joypad when a button has been pressed.  This was the interrupt enable register and there's the interrupt flag register where  you can see which interrupt is still pending.  And these are the addresses where those different interrupts jump.  So you don't have to find out which interrupt it was because there's a few jumps to different  locations.  So the sound controller, nothing has as many registers as the sound controller because there's  four voices and they all have their distinct registers.  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 is called voice and one  that 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 bit and a length  register so you can just say turn it off after a quarter second.  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 16 bytes of register here which is 32 entries of four bits each and  these can describe any waveform that you like that fits into these 32 slots.  So here are some examples, you could for example create a sawtooth which is a pretty simple  waveform or 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.  It controls how fast that wave table is played.  And two extra bits of volume so you can play it 100%, 50%, 25% or you can mute it.  The other two here, 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 here.  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.  12.5 high and the rest is low.  25%.  50.  And then 75 should sound exactly like 25.  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 frequency sweep.  So you can go up.  Or you can go down.  So you can see this is mostly meant for sound effects.  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 pseudoramnum numbers.  And depending on whether you set it to 15-bit mode or 7-bit mode, it will do one of two  different waveforms.  That's 15-bit mode.  And that's 7-bit mode.  So these are all the registers again.  Different voices.  And three general purpose registers.  This register has a volume for left, volume for 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 where you can say should a voice be on the left or the right  on the right on both or on neither.  And then there's the power bit if you turn off the power to audio.  You will save like 13% or so of energy.  So the Game Boy sound is not only used for games.  People still compose music in tools like Little Sound DJ today on the Game Boy.  I'll show you a short example of that.  So much for sound.  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, 160 by 140 pixels, not that much.  Four shades of gray, which is more like four bad shades of green.  Later Game Boy sound much better.  Everything on the screen is 8 by 8 tile based and there are a certain number of tiles on  the screen that's sprites and all this has to deal with 8 kilobytes of video RAM.  What do I mean when I say 8 by 8 pixel tiles?  If we look at a game like Tetris, you can see everything is blocky.  Everything is based on these blocks.  Same with Zelda.  If we put the grid over it, you can see they're 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 is aligned to that, even though  they did a very good job at hiding that.  In some games, you can see it because it plays with that very concept.  So here in Turrican, you can see it fills the screen with tiles.  Let's look at a tile and what a tile is like.  Tile consists of 8 times 8 pixels and has four colors like everything in the system.  These colors are encoded, 0, 0, 1, 1, 0, 1, 1.  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, 0, 2, and ff.  So for every line of pixels, I need two bytes.  And in total, I need 16 bytes to describe a whole tile.  You may have noticed here that the ordering of the colors here doesn't necessarily make  sense.  This is because I can choose my own palette.  It can be any palette.  There's a 2-bit to 2-bit mapping in the system for these background tiles.  So the native colors are 0, 0 means white and 1, 1 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 256 tiles in the system.  So this tile set, do you recognize 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 Super Mario Land, which only uses 128 tiles.  You can't 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 puzzled together from 20 tiles by 18 tiles which fill up the whole screen,  which is not the whole truth because actually in video RAM there are 32 tiles by 32 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 that 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 32 map.  But this only works with games that are maximum 32 by 32.  What about games 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 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.  This also works in two dimensions.  This is Donkey Kong Land 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 is 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 a 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 is you put it to the very right or you put it to the very  bottom.  It just overlays this 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.  It's a game of color games but it wouldn't matter.  It works on the game by just as well.  And then there's another layer on top of the background and the window, which is sprites.  Sprites are objects on the screen that don't fit into the 8x8 rasters.  You can position them freely.  So we have three sprites here in the system.  Nintendo calls them objects, OBJ.  But I'll keep calling them sprites because everyone calls them sprites.  Let's just look at this Goomba here.  Every sprite in the system has attributes.  And there's the OAM, which is the object attribute map.  And this is one OAM entry.  And it has these values.  So one of them is the X position.  So if we put the Goomba to the very left of the screen, you would expect it 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 at 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 wide position where you see it fully is 16 because sprites can be up to  16 bits, 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 an 8x8 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 256 tiles in the system, which is a byte.  And we can see it here.  It's tile hex 90.  The next thing is the flip expert.  So you don't have to save two Goombas here.  One that walks to the left and one that walks 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 Goomba.  You flip it horizontally and vertically, and you have a dead Goomba walking the other direction.  So let's put it right side up again.  The next bit is the palette.  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 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 palette zero, palette one?  If it takes palette one, it would look like this.  Would look like this with palette zero.  It looks like this.  And one more bit is priority.  So how does the sprite draw in comparison with the background?  If the 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, the Goomba could very well be drawn on top of any other  color.  If we set the priority 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.  We have this rectangle here.  And the Goomba is on top of the rectangle, which is because the Goomba's horizontal position  is smaller than the rectangles.  As soon as they are at the same horizontal position, the sprite with a lower number wins  because the sprites are an array in memory, the one that comes earlier draws over the  one that comes later.  As soon as the white-ranked angle has a smaller X position than the Goomba, 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 OAM entry.  It fits neatly into four bytes.  So this is one OAM entry in memory.  FE00 is where these entries are stored.  There are 40 of them for the sprites, and the whole thing is called the OAM RAM, which  is a special purpose RAM 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 8 by 8 sprites.  So you could do it as four sprites, and this is what the game actually does.  But there's another mode where you can have sprites that are 16 pixels high.  But this is global.  The whole game would have to deal with the 16 pixel sprites then.  So we've seen the three different layers.  There's 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 draw a background, you get white.  If you draw the background and say you want to draw it in light gray, it completely replaces  that color.  You can draw a window on top, again, no translucency here.  And you can draw sprites on top.  Notice that sprites don't distinguish between whether a 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?  Four kilobytes of sprite tiles, and four kilobytes of background tiles, and one kilobyte of the  background map, the 32 by 32, 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.  We only have eight kilobytes of video RAM, so if we put the sprites 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.  What do we do with the background tiles?  Let's have them overlap.  And there are 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 sprite tiles, they're in the same format, 8 by 8, 2 bits  per pixel, so they could share exactly the same tiles.  But you can also put them this way.  So the first third, the first 128, would be sprite tiles exclusively.  The last 128 would be background tiles exclusively, and the ones in the middle would be shared  by both, or usable 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 Game Boy.  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 reusing some old components.  They completely read it, the very idea how this was done, but still an LCD wants to be  refreshed 60 times a second, and they draw it like that.  And this is important to know 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.  If you've seen 8-bit programming on something like a C64 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 an 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 this with a scroll offset of zero.  At this point, our program will set the scroll offset, the horizontal scroll offset to, let's  say, 23.  In the next frame, we'll set it to 24, so we'll scroll.  And we'll set the compare register to 42, and it will continue drawing here with a certain  offset.  And then we set it to something else, set another lyc.  It keeps drawing like that.  How exactly it 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 only have to do with the X scrolling register, here's a  different example where the Mario 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 it draw halfway.  But yes, you can.  You trigger at line zero and turn on the window, and they trigger again at line 40 and turn  off the window.  So when it draws line 40, the PPU will think, window?  What window?  No, no, no, no 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 the window, other have to be done with screen  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, you can see what's actually happening or what's stored inside the video  RAM.  If you change SCX in every line, this is the curve that is just used as a tool.  The 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 write a different SCX  value into the SCX register.  And of course, it has to be done in every line.  This 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 RAM.  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 SCX.  So if you keep updating SCX 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 palette every few lines.  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 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 PPU.  It usually takes 43 clocks.  And this is done for 144 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's happening.  Because there's an extra OAM search at the beginning of each line, which is 20 clocks.  I'll talk about that in a minute.  And an H blank area of 51 clocks at the end of every line.  In H blank mode, the PPU is idling.  It doesn't do anything.  And there's also a V blank mode when the PPU doesn't do anything between screens.  So let's do the math.  A line is 114 clocks at 1 megahertz, 54 lines.  So this is this many clocks per screen.  If you divide the base clock by this, you'll get a refresh rate of 59.7 hertz.  These four different modes that the PPU can be in, you can read that out.  And the CPU 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 OAM search of 20 cycles at the beginning of each line?  So every line, the PPU 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 sprites 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 where there was a fun bug here, if you do any calculations,  any 16-bit calculations with numbers between FE00 and FEFF, which is the pointer to the  OAM RAM, even if you're not accessing RAM at all, it will destroy the RAM during OAM  mode.  So why else would you have to care about what's going on?  The CPU is connected to RAM.  PPU is connected to video RAM.  And OAM RAM is special.  PPU is also connected directly to OAM RAM.  CPU could be connected to the video RAM as well, so it can write to video RAM.  But this is not how it's done.  You would need a double-speed video RAM here.  C64 does it like that.  But on the Game Boy, it has to go through the PPU.  And there's this one big switch where the PPU can say, you cannot access it right now  if you want, if the CPU wants to write, nothing happens.  If it reads, it gets all FEFF.  At least nothing bad can happen, but it's also not very useful.  So the CPU has to make sure that the PPU 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 OAM search, H blank and V blank, video RAM access is okay.  If you want to access OAM RAM, you cannot do it in either OAM search or during pixel  transfer because that's when the sprites are drawn, the PPU 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 V blank, where you have the most uninterrupted time.  And all the game logic, all the game AI 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  OAM is going on.  So what games usually do is they write the new updated sprite information into a shadow  OAM, which is just a copy of the OAM.  And then during V blank, they copy that into the real OAM.  So they copy a block from here from any of those sources into the OAM as a location.  This is not to scale.  You don'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 160 clocks.  And while it's doing that, the CPU keeps running, but it cannot access any of the source address  space.  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  Hram, which is a nice use of that as well.  So pixel pipeline, let's dig in as deep as it gets into the pixel pipeline.  And this is cutting edge research.  And some of these things have been previously not known to the public.  The pixel FIFO is the central concept of how the Game Boy draws its picture.  So let's jump somewhere in the middle.  We have some pixels on the LCD already.  So there's five pixels already shifted out, sent to the LCD.  And the pixel FIFO, let's say, there are a few pixels in there.  Now in every step, in every four-megahit step, it shifts out one pixel and sends it to the  LCD.  It shifts out a pixel, sends it to the LCD, shifts out the next one, sends it to the LCD.  You may have noticed here that a green button just became red because the pixel FIFO 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 FETCHER is for.  The FETCHER's background tiles and 9802 is right now the position of the map that it  fetches it from.  So it reads the tile number from the background map, takes one cycle, and the next cycle it  reads the first part of the data and the second part of the data from the tile RAM because  every line of a tile is 16 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 FIFO.  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 walk through this real quick.  The FIFO is running at twice the speed, so it does two pushes until the FETCHER can do  one step.  So push, push, and we read the first byte of data, push, push, and the second part of the  data.  And at that point, it cannot put the data into the FIFO yet because the FIFO isn't empty  yet.  So FETCHER switches to red, 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 an idle, three  reads and an idle.  So again, the FIFO pushes one pixel per clock at four megahertz, pauses unless it contains  more than eight pixels.  And the FETCHER 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 FIFO available.  Scrolling is done very simply.  Let's say we scroll by three pixels, so everything's 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 160, the  FIFO may contain the next few pixels that we won't actually draw.  And the FETCHER 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 H blank mode, which is the reason why a line takes 43 clocks instead of more logical  40 clocks.  If we have a window, let's say the window triggers at position 26, and we're here at  26, the FIFO has some data in it.  The FETCHER is somewhere in the middle.  It will completely clear the FIFO, and then the FIFO will be stopped because we don't  want those pixels anymore that are already lined up.  And the FETCHER will switch over to the map of the window, and the FETCHER will be restarted.  And then we'll do the tile fetch, the data fetch, the data fetch, and we'll get the data  from the window.  We can put it into the pixel FIFO.  So as soon as those are shifting out, window pixels will be drawing.  With sprites, there are 10 comparators that are triggering on the X position.  And let's say here at position 26, we have a sprite at that location.  And again, the pixel FIFO has lots of pixels, and FETCHER is somewhere in the middle.  First we temporarily suspend the pixel FIFO.  It cannot push out any more pixels.  We switch temporarily the FETCHER to doing a sprite FETCHER and restarting the FETCHER.  So we're getting the sprite information.  And instead of putting it at the end, we overlay it with the first eight pixels, and we mix  them onto the pixels.  And this explains why the FIFO always has to have eight pixels in there, because that's  how it mixes in the sprites.  This is in stark contrast to other systems.  So when we just push out pixels at a constant rate until a window starts, when the window  starts, the FIFO gets cleared.  We are not pushing out pixels for quite a while until the FIFO has the window data again,  and at which point it is resumed.  So it takes 43 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.  So for example, on a C64, a line always has to have exactly 40 clocks, because any pixel  that comes a clock too late will be shifted to the right visually.  So it's not completely accurate that we have 40 clocks.  For pixel transfer, it's more like 43 plus.  And the H-blank area is just the remaining line.  And in practice, this is more like what it looks like, depending on what sprites or background  you have.  So I wasn't completely honest about how the Pixel FIFO works.  It does not actually store pixel colors.  What it does store is the original information of the bit combinations and the source.  Like here it says these are nine background pixels.  And the same is true with a fetch.  It does not create pixel colors.  It creates those bit combinations plus the information which sprite palette it was or  what the source was.  So let's mix these together.  The sprite is priority zero, meaning drawing on top of the background.  And let's go through these.  There's sprite 1, 0, 0, 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 1.  And it's 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 0 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 sprites that 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 where the sprite wins again.  And the applying 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 on LCD.  Look it up, convert it, LCD.  Another one, black.  And this is how it's also done on the color system.  So starting with the Super Game Boy, existing games that couldn't really deal with this  could be colorized.  And what's done there, 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.  RGB color puts a pink pixel on the screen.  11, S1.  That's here.  Black pixel.  One more example, 01 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 more minutes.  Let's talk about development.  In case you're now interested in doing Game Boy development, there are some really nice  tools.  The Rednecks 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 BGP emulator, which is meant for Windows, but  works really nicely with wine on top of OS X or Linux as well.  It has a built-in debugger, single stepping break points, and it has this really nice  video RAM viewer that shows you all the details about what's going on.  Also really nice to run demos in that and see what's going on inside.  If you want to run it on real hardware, there are devices like the EverDrive where you can  put in an SD card.  Since we have another four minutes, let's talk about my favorite peripheral of the Game  Boy, the Game Boy Camera.  But not from a technical perspective, just how great a device that is.  This is the Game Boy Camera.  You put it at the back of the Game Boy.  It's really nice pictures.  You can print them on the Game Boy printer, on thermal paper if you can still get that  paper, and you can get these to 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 CCD that has 14 kilopixels and a bit depth of two.  Next time you go on a trip, make sure, take a Game Boy.  Don't forget your Game Boy 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 Game Boy and helped me with a presentation,  and those people helped me in various other ways.  So 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 two talks.  I'm nominating for 34C3.  Dominic Wagner to talk about the Acorn Archimedes.  And I nominate Janis Harder.  For the Super 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.  So do you guys.  you
33c3-8029-the_ultimate_game_boy_talk_0_599.png 33c3-8029-the_ultimate_game_boy_talk_600_1007.png 33c3-8029-the_ultimate_game_boy_talk_1008_1067.png 33c3-8029-the_ultimate_game_boy_talk_1068_1187.png 33c3-8029-the_ultimate_game_boy_talk_1188_1475.png 33c3-8029-the_ultimate_game_boy_talk_1476_1787.png 33c3-8029-the_ultimate_game_boy_talk_1788_2519.png 33c3-8029-the_ultimate_game_boy_talk_2520_2951.png 33c3-8029-the_ultimate_game_boy_talk_2952_3011.png 33c3-8029-the_ultimate_game_boy_talk_3012_3131.png 33c3-8029-the_ultimate_game_boy_talk_3132_3503.png 33c3-8029-the_ultimate_game_boy_talk_3504_3671.png 33c3-8029-the_ultimate_game_boy_talk_3672_3887.png 33c3-8029-the_ultimate_game_boy_talk_3888_4535.png 33c3-8029-the_ultimate_game_boy_talk_4536_4667.png 33c3-8029-the_ultimate_game_boy_talk_4668_8639.png 33c3-8029-the_ultimate_game_boy_talk_8640_8735.png 33c3-8029-the_ultimate_game_boy_talk_8736_8783.png 33c3-8029-the_ultimate_game_boy_talk_8784_8831.png 33c3-8029-the_ultimate_game_boy_talk_8832_17531.png 33c3-8029-the_ultimate_game_boy_talk_17532_17579.png 33c3-8029-the_ultimate_game_boy_talk_17580_18803.png 33c3-8029-the_ultimate_game_boy_talk_18804_20375.png 33c3-8029-the_ultimate_game_boy_talk_20376_20723.png 33c3-8029-the_ultimate_game_boy_talk_20724_21587.png 33c3-8029-the_ultimate_game_boy_talk_21588_27815.png 33c3-8029-the_ultimate_game_boy_talk_27816_30227.png 33c3-8029-the_ultimate_game_boy_talk_30228_33203.png 33c3-8029-the_ultimate_game_boy_talk_33204_33275.png 33c3-8029-the_ultimate_game_boy_talk_33276_33995.png 33c3-8029-the_ultimate_game_boy_talk_33996_34967.png 33c3-8029-the_ultimate_game_boy_talk_34968_35099.png 33c3-8029-the_ultimate_game_boy_talk_35100_36095.png 33c3-8029-the_ultimate_game_boy_talk_36096_43679.png 33c3-8029-the_ultimate_game_boy_talk_43680_47267.png 33c3-8029-the_ultimate_game_boy_talk_47268_52523.png 33c3-8029-the_ultimate_game_boy_talk_52524_54359.png 33c3-8029-the_ultimate_game_boy_talk_54360_66611.png 33c3-8029-the_ultimate_game_boy_talk_66612_66827.png 33c3-8029-the_ultimate_game_boy_talk_66828_67679.png 33c3-8029-the_ultimate_game_boy_talk_67680_68567.png 33c3-8029-the_ultimate_game_boy_talk_68568_74543.png 33c3-8029-the_ultimate_game_boy_talk_74544_77231.png 33c3-8029-the_ultimate_game_boy_talk_77232_85355.png 33c3-8029-the_ultimate_game_boy_talk_85356_89471.png 33c3-8029-the_ultimate_game_boy_talk_89472_91343.png 33c3-8029-the_ultimate_game_boy_talk_91344_91656.png