In an earlier series we built a complete Snake game for the Game Boy in C and ran it on a real DMG-01. That game works, but it is bare: no title, no score, no lives, and a rather abrupt end. This new series levels it up, adding a title screen, a score, lives, a proper game-over screen, sound and a pause function, one feature per part. Before any of that, though, we need something the first game deliberately went without: graphics and text of our own. So we begin exactly where the Game Boy's own artists began, by drawing. The final homebrew snake game in action By the end of this part you will understand how graphics were made for the Game Boy, and you will have designed two things we use for the rest of the series: a small font, and a start-screen picture. No prior coding experience is needed; we will read every line together in plain English. How the Artists Drew for the Game Boy In 1989 there were no drag-and-drop art tools of the kind we know today. A Game Boy artist often began much like someone doing cross-stitch: on squared paper, one small 8 by 8 tile at a time, filling each of its 64 squares with one of just four shades. A logo, a character or a letter was then assembled from these little tiles like a mosaic, and finally turned into the numbers the console understood. Trivia, since people always ask: did programmers really work out every pixel as a number by hand? In the very early days, and for lone hobbyists, yes, that graph-paper-to-hex conversion was a genuine rite of passage. Professional studios did not stay in that world for long, though. They worked on development computers with graphical tile editors, painting each 8 by 8 tile with a cursor while the tool wrote out the numbers automatically. Today nobody types hex by hand at all: you draw your tiles in a pixel-art program such as Aseprite, or a dedicated tool like Game Boy Tile Designer, or design whole games visually in GB Studio, and a converter (for example GBDK's png2asset) turns your picture straight into the data the console needs. We are doing it the old, manual way in this series purely because it makes the machine impossible to misunderstand. Four Shades, Two Bits, Sixteen Bytes Because every pixel is one of four shades, it can be described by two bits (a bit is just a single yes-or-no value in the computer's memory). Each row of eight pixels therefore needs two bytes, one for each bit, and a full tile of eight rows takes sixteen bytes. That is why, back in the beginner series, our tiles were always sixteen numbers long. Here is the food tile again, a diamond: // the food tile: a diamond, 16 bytes (two per row) 0x00,0x00, 0x18,0x18, 0x3C,0x3C, 0x7E,0x7E, 0x7E,0x7E, 0x3C,0x3C, 0x18,0x18, 0x00,0x00 If those numbers look intimidating, here is the trick to reading them. The tile is eight rows tall, and each row is described by a pair of numbers, so there are eight pairs. A line beginning with two slashes is just a comment, a note for humans that the console ignores. A value like 0x00 means an empty row with nothing lit; the 0x in front simply marks it as a hexadecimal number. In the very next section we will work out, step by step, exactly where such a number comes from. Designing a Font To show a score, or the word SNAKE, we need letters and numbers, and on the Game Boy a letter is simply another tile. We design a compact five-by-seven pixel letterform inside each eight-by-eight tile, leaving a little breathing space around it so the words do not run together. Draw the twenty-six capitals and the ten digits once, store them as tiles, and you can write anything on screen. This is our little museum font, the alphabet and numbers we will use for every screen from here on. Designing a font for the Game Boy Designing One Letter, Pixel by Pixel To see exactly how a tile is born, let us build one letter from scratch: a capital A. First we sketch it on the eight-by-eight grid, colouring in the squares that should be dark and leaving the rest light. Straight away the familiar shape appears, a narrow peak, two uprights and a bar across the middle, with an empty row at the very bottom so the letters below have room to breathe. Designing Letter A Pixel By Pixel Reading the grid one row at a time, we turn each row into a single number. Here is that same A, row by row: // the letter A, one row at a time 0x38, // ### the peak 0x44, // # # the uprights begin 0x44, // # # 0x7C, // ##### the bar across the middle 0x44, // # # 0x44, // # # 0x44, // # # the two legs 0x00 // a blank row for spacing Read the little comment beside each number and you can find the letter hiding in the digits: 0x38 is the narrow peak, each 0x44 is a row with only its two edges lit, 0x7C is the bar across the centre, and 0x00 is the empty row at the foot. But where do those particular numbers come from? That is the part worth slowing down for. How Each Row's Number Is Worked Out Here is the simple rule behind every one of those numbers. Think of the eight squares in a row as eight switches. Each square has a fixed value that depends only on its position, starting from the left: 128, 64, 32, 16, 8, 4, 2, 1, each one exactly half of the one before it. To turn a row into its number, you add up the values of only the squares that are switched on (the dark ones), and then write that total in hexadecimal. Numbers and Pixels Take the upright row of our A, the one written 0x44, which has just its two edge squares lit. Looking at their positions, those two squares are worth 64 and 4. Add them together: 64 + 4 = 68. The last step is to write 68 in hexadecimal, the base-sixteen counting that programmers use. Hexadecimal counts in sixteens, so 68 is four sixteens (that is 64) plus four more, which is written as 44, giving us 0x44. That is the whole calculation: pick the lit squares, add their position values, convert the total to hex. The other rows work the very same way. The peak of the A lights the three middle squares, worth 32, 16 and 8; add them, 32 + 16 + 8 = 56, and 56 in hexadecimal is 0x38 (three sixteens is 48, plus eight, written 38). A completely empty row lights nothing, so it adds up to 0, written 0x00. And the bar across the middle lights five squares, 64 + 32 + 16 + 8 + 4 = 124, which is 0x7C. Work down all eight rows like this and you have built the letter by hand, one number at a time. A tile editor simply does this addition for you, but now you know exactly what it is doing under the hood. One last detail we skipped earlier: in the real font file each of these values is written twice in a row, because the Game Boy stores two copies for its four possible shades. Our font uses only the darkest shade, so the two copies are identical, which is why the finished tiles read 0x38,0x38, 0x44,0x44 and so on. Once the letters exist as tiles, writing a word is just placing the right tiles side by side. This little helper does exactly that: // each character is just a tile; write a word by placing tiles void draw_text(uint8_t col, uint8_t row, const char *s) { while (*s) set_bkg_tile_xy(col++, row, tile_for(*s++)); } Even if you have never written a line of code, you can follow what this does. The word void just means this is a reusable instruction, which we have named draw_text, that we can call whenever we want to write something. It is handed three things inside the brackets: a column and a row where the text should start, and the text itself (called s). The line while (*s) means keep repeating the next step as long as there are still characters left in the text. That step, set_bkg_tile_xy(col++, row, tile_for(*s++)), quietly does three small jobs at once: tile_for finds which tile matches the current character, set_bkg_tile_xy places that tile at the current column and row, and the two ++ marks then nudge us one column to the right and one character further along the text. Round and round it goes until the text runs out, and the word has appeared on screen, letter by letter. The full font, all twenty-six letters and ten digits already turned into tiles, lives in the downloadable project at the end of the series, so you never have to type it out by hand. Drawing the Start Screen With tiles and a font in hand, a title screen is simply careful arrangement. We place the word SNAKE near the top, coil a little snake underneath from the same body tile the game uses, drop a single piece of food beside it, and write PRESS START lower down. Notice that we are no longer thinking about individual pixels at all; we are arranging ready-made tiles on the twenty-by-eighteen grid, which is exactly how Nintendo's own title screens were built. The result already looks like a real game waiting to be played. Adding some flavour to our snake like game - a simple start screen Coming Up in Part 2 A picture on its own is not a title screen yet. In Part 2 we make it interactive: the game will show this start screen the moment it boots, sit patiently on it, and wait for the player to press START before the snake ever appears. That single change is what turns a program into something that feels like a cartridge. New to all this? Start with the beginner series, Build Your Own Game Boy Game, which builds the Snake we are about to improve. And to see the machine we are drawing for, browse the collection. The Level Up Series Part 1: Drawing Graphics the Game Boy Way (you are here) · Part 2: A Title Screen for Your Snake · Part 3: Keeping Score · Part 4: Three Lives · Part 5: A Proper Game Over · Part 6: Sound and Pause

Gameorama, Lucerne: one ticket, and everything is set to free play. Switzerland is quietly rich in places that take play seriously. Some preserve a single object with obsessive care. Others throw open the doors and simply invite you to press start. Gameorama, in the middle of Lucerne, belongs firmly to the second kind, and it does the job with more variety than almost anywhere else in the country. We wanted to introduce it, partly because it is a wonderful day out, and partly because it is the perfect counterpart to what we do at the Game Boy Museum. An Interactive Game Museum in the Heart of Lucerne Gameorama is an interactive game museum in Lucerne, at Hirschengraben 49, only about ten minutes on foot from the main station and a couple of minutes from Kasernenplatz. The principle is generous: you pay one entrance fee and the machines are yours. Pinball tables, arcade cabinets, a console area and a virtual reality arena are all set to free play, with no coins to feed. Entry is CHF 25 for adults and CHF 20 for children aged six to fifteen, the museum floor is limited to two hours, and each time slot is capped at sixty visitors, so booking ahead is strongly recommended. Children under sixteen visit with an adult, which keeps the older, more delicate machines in good hands. Far More Than Arcade Cabinets What sets Gameorama apart is its sheer range. Alongside the museum floor sits a board-game cafe with a large lending library, a shop that also exhibits work by Swiss artists, and four escape rooms the team designed and built themselves. The calendar fills up with poker evenings, role-playing sessions, dedicated offerings for seniors and even prototype-testing nights where new games get their first real players. The board-game cafe is the social heart of it. You can settle in with something to drink, pull a title off the shelves and stay as long as you like, since the cafe has no time limit at all. It is the kind of room where an hour quietly turns into three. It means the place works for almost anyone: a family with small children, a group of friends after a rainy-day plan, board-game devotees who want to try before they buy, and people who would never call themselves gamers at all. Gameorama makes a point of easing newcomers in gently, with plenty of history and context along the way. Built by Four Enthusiasts, Made to Last Behind Gameorama stand four self-declared game enthusiasts, Angela, Jerome, Marco and Lukas, who were convinced Lucerne needed an interactive game museum of its own. That hands-on, personal spirit shows in how the collection is treated. The old machines are looked after so they keep working for years to come, and the museum happily gives a new home to donated pinball tables and vintage games that would otherwise gather dust in an attic. The effort has not gone unnoticed. In 2026 Gameorama was named among the nominees for the new Swiss Museum Prize, a nod to just how much a small, independent house can achieve. Play in Lucerne, Preserve Online This is where our two worlds meet. Gameorama keeps gaming culture alive by switching it on and handing you the controller. The Game Boy Museum keeps it alive in a different way, by preserving and documenting one machine in complete, original condition so the record survives for good. Breadth and depth, the living game and the archived artefact: together they tell the fuller story. It is also part of a bigger picture. Between Gameorama in Lucerne, kindred museums elsewhere and an online archive like ours, Switzerland has the makings of a real network of places devoted to gaming history. If a visit leaves you curious about the little grey handheld that started so many gaming lives, you can explore the whole original Game Boy story in our complete DMG-01 guide. Plan Your Visit Gameorama is open five days a week, from Wednesday to Sunday (during Lucerne summer holiday even 7 days a week); the exact times and the handful of annual holiday closures are listed on its own site. The board-game cafe is free to enter, with the usual expectation that you order something while you play, and there is no time limit there. For the museum itself, reserve a slot in advance to be sure of getting in. You will find everything, from opening hours to group and school offerings, at gameorama.ch. Go with an afternoon to spare, and let yourself be surprised by how much of gaming history you can actually touch.

We have an arena with walls, but it is completely still. In this part we give it a star: a snake that the player can steer around the board. To get there we need three things. We need a way to remember where the snake is, a way to read the buttons, and a loop that ties it all together and runs the game. Let us take them one at a time. Say hello to the snake Remembering the Snake A snake is really just a chain of body segments, each sitting in one grid cell. The neat way to store that is two lists: one holding the column of every segment, and one holding the row. We also remember how long the snake currently is, and which direction it is travelling. Position zero in the lists is always the head. #define MAX_LEN 128 // the longest the snake can ever get uint8_t snake_x[MAX_LEN]; // column of each segment uint8_t snake_y[MAX_LEN]; // row of each segment uint8_t length; // how many segments right now int8_t dir_x, dir_y; // current direction (-1, 0 or 1) These few lines are just labelled boxes to remember things in. The define line fixes MAX_LEN, the longest the snake can ever grow, at 128. snake_x and snake_y are two lists (programmers call them arrays), each with room for 128 numbers; together they store the column and row of every body segment, with position 0 always being the head. length holds how many segments exist right now, and dir_x and dir_y hold the current direction as a pair of small numbers, each being minus one, zero or plus one. For example, dir_x of 1 with dir_y of 0 means moving right. Now we set the snake up at the start of a game. We place a short, three-segment snake in the middle of the board and point it to the right. void init_snake(void) { uint8_t i; length = 3; for (i = 0; i < length; i++) { snake_x[i] = 10 - i; // head at 10, body trailing left snake_y[i] = 9; set_bkg_tile_xy(snake_x[i], snake_y[i], T_BODY); } dir_x = 1; // moving right dir_y = 0; } init_snake lays down the starting snake. length = 3 says three segments to begin with. The for loop then runs i from 0 to 2 and, for each segment, sets its column to 10 - i (so the head sits at column 10 and the body trails off to the left), sets its row to 9, and draws a body tile there. Finally dir_x = 1 and dir_y = 0 point it to the right. A short snake, ready to go. Reading the Game Boy Controls GBDK-2020 gives us a joypad function that tells us which buttons are currently held. We check the four direction buttons and update the snake's direction. There is one classic rule in Snake: you cannot instantly turn back on yourself, so we only allow an up or down turn when the snake is moving horizontally, and a left or right turn when it is moving vertically. void read_input(void) { uint8_t keys = joypad(); if ((keys & J_UP) && dir_y == 0) { dir_x = 0; dir_y = -1; } else if ((keys & J_DOWN) && dir_y == 0) { dir_x = 0; dir_y = 1; } else if ((keys & J_LEFT) && dir_x == 0) { dir_x = -1; dir_y = 0; } else if ((keys & J_RIGHT) && dir_x == 0) { dir_x = 1; dir_y = 0; } } The one new symbol here is the & in keys & J_UP. joypad() hands back all the buttons squashed into a single number, and & is how we ask whether one particular button is pressed, so (keys & J_UP) means the up button is down. The extra check && dir_y == 0 enforces the classic Snake rule: you may only turn up or down while moving sideways, which stops the snake instantly doubling back on itself. The else if chain means only the first matching direction is taken each time. Making the Snake Move Moving the snake is the clever bit, and it is simpler than it looks. We work out where the new head will be, then shuffle every segment one place along the chain so the body follows the head. We draw a body tile at the new head, and clear the tile where the tail used to be. Because we only ever change two tiles per step, the head and the old tail, the game stays fast even when the snake grows long. void move_snake(void) { int8_t i; uint8_t nx = snake_x[0] + dir_x; // new head column uint8_t ny = snake_y[0] + dir_y; // new head row uint8_t tail_x = snake_x[length - 1]; uint8_t tail_y = snake_y[length - 1]; for (i = length - 1; i > 0; i--) { // body follows the head snake_x[i] = snake_x[i - 1]; snake_y[i] = snake_y[i - 1]; } snake_x[0] = nx; snake_y[0] = ny; set_bkg_tile_xy(nx, ny, T_BODY); // draw new head set_bkg_tile_xy(tail_x, tail_y, T_EMPTY); // erase old tail } This is the heart of the movement, so let us take it slowly. First we work out the new head position, nx and ny, by adding the direction to the old head (position 0). We also make a note of where the tail currently is. Then comes the clever part: the for loop runs backwards, from the last segment to the second, and copies each segment into the position of the one in front of it, so the whole body shuffles forward by one and follows the head. We then place the new head into position 0, draw a body tile there, and rub out the tile where the tail used to be. Because only two tiles ever change, the head and the old tail, the game stays fast no matter how long the snake grows. The Game Loop Every game has a heartbeat: a loop that repeats forever, reading input and updating the screen. On the Game Boy we pace that loop with wait_vbl_done, which pauses until the console has finished drawing the current frame. That happens about 60 times a second, which would make our snake far too fast, so we use a small counter and only move the snake every sixth frame. That gives a comfortable, classic Snake speed while still reading the buttons smoothly. void main(void) { uint8_t timer = 0; set_bkg_data(0, 4, tiles); SHOW_BKG; DISPLAY_ON; draw_walls(); init_snake(); while (1) { wait_vbl_done(); // wait one frame (~1/60 s) read_input(); // check the buttons every frame if (++timer >= 6) { // but only move every 6th frame timer = 0; move_snake(); } } } The main function is the whole game in miniature. It loads the tiles, shows the background, turns on the screen, draws the walls and places the snake, exactly the pieces from Part 3. Then while (1) starts a loop that runs forever. Each time round, wait_vbl_done pauses until the console has finished drawing one frame (about a sixtieth of a second), and read_input checks the buttons. The line if (++timer >= 6) counts those frames and only lets the snake move on every sixth one; without it the snake would lurch sixty times a second, far too fast to play. So the buttons stay responsive while the snake glides at a comfortable pace. Build the ROM and you will have a snake gliding around the arena, turning crisply as you press the direction pad. It does not eat, grow or die yet, but it is unmistakably a game now, and it responds to your hands. Coming Up in Part 5 In Part 5 we turn this into a real, winnable and losable game. We will scatter food for the snake to eat, make it grow with every bite, and add the rules that end the game when it hits a wall or its own tail. By the end you will have a complete, playable Snake. The Full Series Part 1: Setting Up Your Workshop · Part 2: How the Game Boy Thinks · Part 3: Drawing Your World · Part 4: Taking Control (you are here) · Part 5: Food, Growth and Game Over · Part 6: From Emulator to Cartridge

Our snake glides around the arena, but it has nothing to do and no way to lose. In this final building part we add the three things that turn a moving line into a real game: food to chase, growth as a reward, and rules that end the run when you crash. After this, you will have a complete Snake that you can lose, swear at, and immediately play again. Scattering the Food Food should appear at a random empty spot inside the walls. GBDK-2020 provides a random number generator, which we use to pick a column and a row. If the spot we picked is already occupied, by the snake or by a wall, we simply try again until we find an empty cell, then place the food tile there. #include void place_food(void) { uint8_t fx, fy; do { fx = 1 + (rand() % (GRID_W - 2)); // somewhere inside the walls fy = 1 + (rand() % (GRID_H - 2)); } while (get_bkg_tile_xy(fx, fy) != T_EMPTY); set_bkg_tile_xy(fx, fy, T_FOOD); } This little function drops food somewhere valid. rand() asks GBDK for a random number, and the % (remainder) trims it down into range, so rand() % (GRID_W - 2) lands somewhere between the side walls; adding 1 keeps it off the wall itself. The do ... while wrapper means try this, and if the chosen spot is not empty (because the snake or a wall is already there) try again, repeating until it finds a free cell. Only then does it place the food tile. It is a tidy way of saying keep guessing until you find an empty square. Eating, Growing and Crashing Now we upgrade the move function from Part 4 into a full game step. Before moving, we look at the tile the head is about to enter. If it is a wall or part of the snake, the game is over and we report it. If it is food, the snake grows by keeping its old tail instead of erasing it, and we drop a fresh piece of food. Otherwise it is a normal move and we clear the tail as before. // returns 1 if the snake died this step uint8_t step_game(void) { int8_t i; uint8_t nx = snake_x[0] + dir_x; uint8_t ny = snake_y[0] + dir_y; uint8_t hit = get_bkg_tile_xy(nx, ny); if (hit == T_WALL || hit == T_BODY) return 1; // crashed: game over uint8_t tail_x = snake_x[length - 1]; uint8_t tail_y = snake_y[length - 1]; for (i = length - 1; i > 0; i--) { // body follows the head snake_x[i] = snake_x[i - 1]; snake_y[i] = snake_y[i - 1]; } snake_x[0] = nx; snake_y[0] = ny; set_bkg_tile_xy(nx, ny, T_BODY); if (hit == T_FOOD) { // ate food: grow if (length < MAX_LEN) { snake_x[length] = tail_x; snake_y[length] = tail_y; length++; } place_food(); } else { // normal move: clear tail set_bkg_tile_xy(tail_x, tail_y, T_EMPTY); } return 0; } step_game is the Part 4 move function with the rules added, so read it in three beats. First it works out the square the head is about to enter and looks at what is already there, storing that in hit. If hit is a wall or the snake's own body, it returns 1, our agreed signal for game over. If the snake survived, the middle section shuffles the body forward and draws the new head, exactly as before. Then the decision: if hit was food, the snake grows by keeping its old tail segment instead of erasing it, adds one to length, and drops a new piece of food; otherwise it was an ordinary move, so we rub out the tail as usual. Returning 0 at the end means the snake is still alive. That single returned number, 1 or 0, is how the game loop will know whether to carry on. Starting and Restarting We want each game to begin fresh, so we gather the setup into one function that clears the arena, places a new three-segment snake and drops the first food. This is the Part 4 setup with a clean-up sweep and a piece of food added. void init_game(void) { uint8_t x, y, i; for (y = 1; y < GRID_H - 1; y++) // clear the arena for (x = 1; x < GRID_W - 1; x++) set_bkg_tile_xy(x, y, T_EMPTY); length = 3; for (i = 0; i < length; i++) { snake_x[i] = 10 - i; snake_y[i] = 9; set_bkg_tile_xy(snake_x[i], snake_y[i], T_BODY); } dir_x = 1; dir_y = 0; place_food(); } init_game simply resets everything for a fresh run. The two stacked for loops together sweep across every cell inside the walls (one loop for the rows, one nested inside it for the columns) and set each to empty, wiping the old game away. Then, exactly as in Part 4, it lays down a new three-segment snake pointing right, and finally drops the first piece of food with place_food. One small but important detail: a random generator needs a seed, or it produces the same food pattern every time. A neat trick is to wait for the player to press START, count rapidly while the button is held, and use that count as the seed. Because no two people hold the button for exactly the same time, the food lands differently every game. void main(void) { uint8_t timer; uint16_t seed = 0; set_bkg_data(0, 4, tiles); SHOW_BKG; DISPLAY_ON; waitpad(J_START); // wait for the player while (joypad() & J_START) seed++; // count while held initrand(seed); // seed the randomness while (1) { // one game per outer loop draw_walls(); init_game(); timer = 0; while (1) { // the game loop wait_vbl_done(); read_input(); if (++timer >= 6) { timer = 0; if (step_game()) break; // died: leave the loop } } waitpad(J_START); // game over: press START waitpadup(); // wait for release, then restart } } The main function now runs whole games back to back. The first lines load the tiles and switch the screen on. Then comes the seeding trick: waitpad(J_START) freezes until START is pressed, while (joypad() & J_START) seed++ counts rapidly for as long as it is held, and initrand(seed) uses that count so the food falls differently each time. After that, the outer while (1) plays one game per lap: it draws the walls, sets up a fresh board, and runs the inner game loop. That inner loop moves the snake every sixth frame and watches step_game; the moment step_game reports a crash, break jumps out of it. We then wait for START and its release before looping back to start another game. Two loops, one nested inside the other: the inner one is a single game, the outer one lets you play again and again. Finishing the Snake Game Put all the pieces together, the tiles and defines from Part 3, the data and input from Part 4, and the food, growth and game-over logic from this part, and you have a complete Snake game in roughly 150 lines of C. Build it, hold START to begin, and play. The snake eats, grows longer with every bite, and the run ends the moment you clip a wall or your own tail. Press START again and you are straight into a fresh game. Take a moment to appreciate what you have done. You designed graphics, talked to real Game Boy hardware, handled input and wrote game logic, and the result is a genuine cartridge-ready game you made yourself. That is the same craft, in miniature, that built the library this whole collection celebrates. Let's play - the final snake game for your Game Boy Building Your snake.gb File Throughout this series you have built each step the same way you built your very first ROM back in Part 1: with the lcc tool that ships with GBDK-2020. To turn the finished game into a playable file, save the complete program as snake.c, open a terminal in that folder, and run a single command. Adjust the path so that it points at the lcc program inside your GBDK bin folder. lcc -o snake.gb snake.c That produces snake.gb, a real Game Boy ROM. Open it in an emulator such as Emulicious, BGB or SameBoy to play right away, or copy it onto a flash cartridge to run it on a genuine DMG-01. We look at that last step, playing on real hardware, in more detail in Part 6. Download the Game Files Want to skip ahead, or check your work against a finished version? Grab the complete project here: the full snake.c source code, ready to build, together with the compiled snake.gb ROM so you can play it straight away. Coming Up in Part 6 So far we have played in an emulator. In the final part we take the leap that makes it all real: running your game on an actual Game Boy, plus where to go next if you have caught the bug, from friendlier tools to deeper ones and the welcoming community behind them. The Full Series Part 1: Setting Up Your Workshop · Part 2: How the Game Boy Thinks · Part 3: Drawing Your World · Part 4: Taking Control · Part 5: Food, Growth and Game Over (you are here) · Part 6: From Emulator to Cartridge

We now know that the Game Boy draws everything from small 8 by 8 tiles placed on a grid. In this part we will design our own tiles, load them into the console and use them to draw the playfield for Snake, including a solid wall around the edge of the screen. By the end you will have a real game board sitting on that green screen, ready for a snake to move across. The four tiles we are going to build Designing Your Own Game Boy Tiles A tile is 8 by 8 pixels, and each pixel is one of four shades. In code, a single tile is described by 16 numbers. For our game we only need four tiles: an empty space, the snake's body, a piece of food and a wall. Here is how we describe them. Do not worry about every individual number; the comments tell you which tile is which, and you can tweak them freely later. #include #include // tile numbers, so we can use names instead of bare numbers #define T_EMPTY 0 #define T_BODY 1 #define T_FOOD 2 #define T_WALL 3 // 16 bytes per tile: empty, body (solid), food (diamond), wall (solid) const uint8_t tiles[] = { 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, 0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF, 0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF, 0x00,0x00,0x18,0x18,0x3C,0x3C,0x7E,0x7E, 0x7E,0x7E,0x3C,0x3C,0x18,0x18,0x00,0x00, 0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF, 0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF }; Here is how to read that block. The two include lines at the top bring in the Game Boy toolkit and the number types we use. The four define lines just give friendly names to the tile slots, so we can write T_FOOD instead of the bare number 2. Then the tiles array holds the actual pictures: sixteen numbers per tile, two for each of the eight rows. A row of 0x00 is completely empty, a row of 0xFF is fully solid (that is how the body and the wall become solid dark blocks), and the food's numbers grow then shrink (0x18, 0x3C, 0x7E, then back down) to trace a diamond. If you would like to see exactly how a row of pixels turns into a number like 0x7E, we walk through that arithmetic step by step in the Level Up series, Part 1. Giving the tiles names with those define lines is a small habit that pays off. Writing T_FOOD later in the code is far clearer than writing the number 2, and if you ever reorder your tiles you only change one line. Loading the Tiles and Turning On the Screen Designing tiles is not enough; we have to copy them into the console's video memory and switch the display on. GBDK-2020 makes this a three-line affair at the start of our program. The first line loads our four tiles, the second tells the Game Boy to show the background layer, and the third turns the screen on. set_bkg_data(0, 4, tiles); // load 4 tiles, starting at slot 0 SHOW_BKG; // show the background layer DISPLAY_ON; // turn the screen on Those three lines are the switch-on sequence. set_bkg_data(0, 4, tiles) copies our artwork into the console's video memory: the 0 means start at tile slot 0, the 4 is how many tiles to load, and tiles is where to copy them from. SHOW_BKG and DISPLAY_ON are simply on switches, the first for the background layer and the second for the screen itself. Run only this much and you would see a blank, lit screen, ready to be drawn on. Drawing the Walls Our playfield is the whole screen, which is 20 tiles wide and 18 tiles tall. We want a solid wall running all the way around the edge, so the snake has something to crash into. We will define the size of the grid as names, then write a small function that places wall tiles along the top, bottom, left and right edges. #define GRID_W 20 // the background is 20 tiles wide #define GRID_H 18 // and 18 tiles tall void draw_walls(void) { uint8_t x, y; for (x = 0; x < GRID_W; x++) { set_bkg_tile_xy(x, 0, T_WALL); // top edge set_bkg_tile_xy(x, GRID_H - 1, T_WALL); // bottom edge } for (y = 0; y < GRID_H; y++) { set_bkg_tile_xy(0, y, T_WALL); // left edge set_bkg_tile_xy(GRID_W - 1, y, T_WALL); // right edge } } If you have not met a for loop before, it is simply a way to repeat something a set number of times. Read for (x = 0; x < GRID_W; x++) as: start with x at 0, keep going as long as x is less than the width, and add one to x each time round. So the first loop runs x across every column, dropping a wall tile on the top row (row 0) and the bottom row each time; the second loop runs y down every row, placing a wall on the left column (column 0) and the right column. Four edges, drawn by two little loops. Read that function slowly and it is quite friendly. The first loop walks across every column and drops a wall tile on the very top row and the very bottom row. The second loop walks down every row and places a wall tile on the far left and far right columns. Together they frame the screen with a tidy border. Seeing It On Screen If you call draw_walls right after loading the tiles and turning on the display, then build the ROM the same way as in Part 1, your emulator will show a clean rectangular arena framed by a solid border. It may not look like much yet, but you are now drawing your own graphics, pixel patterns you designed yourself, on real Game Boy hardware. That is a genuine milestone. Set the game arena Coming Up in Part 4 We have an arena, but nothing moves. In Part 4 we will bring the snake to life: we will store its body in memory, read the player's button presses, and build the game loop that makes it slither around the board one step at a time. This is where it finally starts to feel like a game. The Full Series Part 1: Setting Up Your Workshop · Part 2: How the Game Boy Thinks · Part 3: Drawing Your World (you are here) · Part 4: Taking Control · Part 5: Food, Growth and Game Over · Part 6: From Emulator to Cartridge

In Part 1 we set up GBDK-2020 and got a first ROM running, with a short message printed on screen. That printed text was a gentle shortcut. To build an actual game like Snake, we need to draw our own graphics, and for that we first have to understand how the Game Boy puts anything on screen at all. It is genuinely different from a modern computer, and once it clicks, the rest of the series becomes much easier. Understanding Game Boy Graphics The Game Boy screen is 160 pixels wide and 144 pixels tall. You might expect to draw by setting those pixels one by one, the way you would on a modern screen. The Game Boy almost never works that way. In 1989 there simply was not enough memory to hold a full picture of the screen and update it many times a second. So Nintendo's engineers used a clever trick that defines Game Boy graphics to this day: instead of pixels, the console thinks in small reusable tiles. A Screen Made of Tiles A tile is a tiny square image, 8 pixels by 8 pixels. You design a small set of these tiles once, and the Game Boy stores them in its video memory. The screen is then treated as a grid of these tiles, 20 tiles across and 18 tiles down. To draw something, you do not paint pixels; you tell the console which tile to show in which grid cell. A brick wall, a patch of grass, a letter of text: each is just an 8 by 8 tile, placed again and again wherever it is needed. This is why so many classic Game Boy games have that charming, blocky, grid-aligned look. Four Shades of Green The original DMG-01 cannot show colour. Every pixel is one of just four shades, rendered in that famous pea-green tint. When you design a tile, each of its 64 pixels is set to one of those four shades: think of them as white, light grey, dark grey and black. Behind the scenes each tile is stored in 16 bytes, using two bits per pixel to pick one of the four shades. You do not have to do that maths by hand, but it helps to know why graphics data looks the way it does when we start defining our own tiles in the next part. The Background Layer The grid of tiles we have been describing is called the background layer. It is the main canvas of most Game Boy games. GBDK-2020 gives us simple functions to work with it. One function loads your tile images into video memory, and another places a particular tile at a chosen grid position. Placing a tile is as easy as naming a column, a row and a tile number, like this: set_bkg_tile_xy(5, 5, 1); // put tile number 1 at column 5, row 5 Do not let the punctuation put you off. set_bkg_tile_xy is a ready-made GBDK instruction, and its name reads as set background tile, by x and y. The three numbers in the brackets simply answer where and what: the first is the column, the second is the row, and the third is which tile to place there. So this whole line says put tile number 1 into the cell at column 5, row 5. Change the three numbers and you move the tile anywhere on the grid. Almost everything we draw from here on is just this one instruction, repeated with different numbers. That single line is the heart of how we will draw everything in Snake. The whole game is really just deciding which tiles to place, and where, many times a second. Sprites: Things That Move Freely There is a second way to draw, and it is the one most people picture when they think of game characters. Sprites are small images, again built from 8 by 8 tiles, but unlike the background they can be positioned anywhere on screen, down to the individual pixel, and moved smoothly. Mario, a bouncing ball or a blinking cursor are all sprites. The catch is that the Game Boy can only show a limited number of them at once, 40 in total, and only a handful on any single horizontal line. Sprites are perfect for a hero that glides around, but less suited to something that grows without limit. Why Snake Lives on the Background This is exactly why we will build Snake out of background tiles rather than sprites. A snake grows longer and longer as it eats, and could easily pass the 40-sprite limit. It also moves on a neat grid, one step at a time, which fits the tile system perfectly. So our plan is simple and robust: we will design a handful of tiles, one for the snake's body, one for the food and one for the wall, and then play the entire game by placing and removing those tiles on the background grid. No flicker, no sprite limits, just clean and reliable drawing. 4 tiles for our little game The four tiles we need for our little game: Empty – empty light-colored area (background) Wall – solid dark square (wall) Food – dark diamond on a light background (food) Body – solid dark square (snake's body) Coming Up in Part 3 Now that we know the Game Boy thinks in tiles, it is time to make some. In Part 3 we will design our own tile graphics in code, load them into the console and draw the Snake playfield, complete with a wall around the edge. From there, the game starts to take shape quickly. If you would like to see the hardware behind all this theory, the original DMG-01 console in the collection is the very machine whose tile-based screen we are learning to command. The Full Series Part 1: Setting Up Your Workshop · Part 2: How the Game Boy Thinks (you are here) · Part 3: Drawing Your World · Part 4: Taking Control · Part 5: Food, Growth and Game Over · Part 6: From Emulator to Cartridge

The Game Boy did not just give us games to play. It gave a whole generation the itch to make them. If you have ever held a DMG-01 and wondered what it would feel like to write something of your own for it, this series is for you. Over the next few parts we are going to build a complete, playable game from scratch, in the C programming language, and run it on a real Game Boy. The game we will make is Snake: simple enough to understand fully, yet a proper game with food, growth and a satisfying way to lose. You do not need to be a professional programmer to follow along. A little curiosity and a willingness to experiment is enough. This first part is all about setting up your workshop, so that by the end you have written your very first Game Boy program and watched it boot up on screen. Why Write a New Game for a 1989 Console Here is the wonderful part. The Game Boy is still very much alive as a platform for makers. Thanks to a dedicated community, the tools to build new games are free, modern and surprisingly friendly. The machine itself is also a joy to develop for, precisely because it is so limited. There is no sprawling operating system to fight and no hidden layers. You talk almost directly to the hardware, and you can hold the entire console in your head. When your code finally runs on that pea-green screen, it feels like magic in a way that modern development rarely does. The Toolchain: Meet GBDK-2020 To turn code into a Game Boy game we need a toolchain: a set of programs that take what you type and translate it into something the console can run. We will use GBDK-2020, the Game Boy Development Kit. It is a modern, actively maintained descendant of the original GBDK from the 1990s, and it bundles everything you need in one package: a C compiler, an assembler, a linker and a library of ready-made functions for talking to the Game Boy hardware. In plain terms, you write your game in C, GBDK-2020 compiles it, and out comes a .gb file. That .gb file is a ROM, the exact same kind of file a real cartridge holds. It will run in an emulator on your computer and, with the right hardware, on an actual Game Boy. What You Will Need The good news is that the whole setup is free and runs on Windows, macOS and Linux. You need four things. First, a copy of GBDK-2020. Second, a plain text or code editor to write your C files; something like Visual Studio Code works beautifully, but even a simple editor will do. Third, a Game Boy emulator to test your game quickly, where Emulicious, BGB and SameBoy are all excellent and free. And fourth, optional but deeply rewarding, a flash cartridge such as an EverDrive so you can eventually play your creation on a genuine DMG-01. Installing GBDK-2020 Installation is refreshingly simple, because there is no installer. Head to the GBDK-2020 releases page on GitHub and download the latest package for your operating system. Unzip it somewhere sensible, for example a folder called gbdk in your home directory. Inside you will find a folder named bin, and that is where the important tools live. The one we care about most is called lcc, the program that turns your C code into a ROM. There is nothing else to configure to get started. GitHub Page: https://github.com/gbdk-2020/gbdk-2020/releases Your First Steps in Game Boy Programming With the toolkit in place, let us write something. Create a new file called hello.c and type in the following. It is about as small as a Game Boy program gets, and it already does something real. #include #include void main(void) { printf("HELLO, GAME BOY!"); } Before we run it, let us read those few lines, because you will meet them again and again. The two #include lines at the top pull in ready-made code so we can use it: gb.h brings in the Game Boy functions, and stdio.h brings in printf. The line void main(void) marks where the program begins; every Game Boy program starts running from main, and the curly brackets hold everything it does. Inside, the single instruction printf("HELLO, GAME BOY!"); prints that text on the screen. That really is a complete program: pull in what you need, then do one thing. Save the file. Now open a terminal, navigate to the folder that contains hello.c, and run a single command. Adjust the path so that it points at the lcc program inside your GBDK bin folder. lcc -o hello.gb hello.c If everything is set up correctly, you will now have a brand new file sitting right next to your code: hello.gb. That is a real Game Boy ROM, and you wrote it. Open it in your emulator and you should see your message printed on screen in that unmistakable Game Boy font. Take a moment to enjoy it. You are now, officially, a Game Boy developer. Your first line of Code "Hello, Game Boy!" What Just Happened In just a few seconds, GBDK-2020 did quite a lot on your behalf. It compiled your C into the low-level machine code that the Game Boy's processor understands, linked it with the kit's built-in library, and packaged the result into a .gb ROM laid out exactly the way the console expects. The printf function you called is part of that library; it quietly handled the fiddly business of drawing letters on the screen. As the series goes on we will step away from printf and start drawing our own graphics, which is where the real fun begins. Coming Up in Part 2 Before we can move a snake around the screen, we need to understand how the Game Boy actually draws anything at all. It does not work like a modern computer with a simple canvas of pixels. Instead it thinks in small tiles and sprites, a clever system born from the hardware limits of 1989. In the next part we will explore that mental model, and it will make everything that follows click into place. If you want to get to know the machine we are writing for, browse the collection or look closely at the original DMG-01 console that started it all. Then open your editor, install the tools, and get that first ROM running. See you in Part 2. The Full Series Part 1: Setting Up Your Workshop (you are here) · Part 2: How the Game Boy Thinks · Part 3: Drawing Your World · Part 4: Taking Control · Part 5: Food, Growth and Game Over · Part 6: From Emulator to Cartridge

The original Game Boy's screen was small, unlit and famously hard to see in poor light. Where there is a problem like that, accessory makers appear, and one of the more elegant answers carried a confusingly grand name: the Sunsoft Wide Boy. It is also the source of one of the most common mix-ups in Game Boy collecting, so it is worth setting the record straight. Sunsoft Wide Boy (WB-01) What Is the Sunsoft Wide Boy? The Sunsoft Wide Boy, model WB-01, was sold as a Visual Power-Up Unit. In plain terms it is a magnifying lens that fits over the Game Boy's display and enlarges the picture, making those tiny green dots easier on the eyes. No electronics, no batteries, just clever optics clipped to the front of the handheld. Solving the Tiny-Screen Problem Magnifiers were a whole category of their own in the early 1990s, and it is easy to see why. The reflective screen was compact and had no backlight, so anything that made the image larger or clearer was welcome. The Wide Boy zoomed the display so the action filled more of your field of view, a simple comfort upgrade for long sessions. It sat alongside dozens of rival lenses and light-and-magnifier combos from other brands. The Wide Boy Boxed (CIB) A Name That Confuses Collectors Here is the trap. There is another, completely unrelated device also called the Wide Boy, made by Nintendo's subsidiary Intelligent Systems. Those Wide Boy units were professional development tools that let studios display Game Boy games on a television or monitor, so programmers could build and test games without squinting at the handheld. Same name, utterly different purpose: the Sunsoft Wide Boy is a consumer magnifier, while the Intelligent Systems Wide Boy is a developer's TV unit. Mixing them up is one of the classic Game Boy collecting errors. Why the Sunsoft Wide Boy Is Collectible As a boxed, period magnifier, the Sunsoft Wide Boy is a tidy little piece of accessory history, and its shared name makes it a great way to explain how careful collectors have to be with labels. It is a reminder that in the Game Boy world, two things can look like cousins on paper and have nothing to do with each other. Browse more accessories in the Knowledge Base.

Long before amiibo figures and toys-to-life games, Nintendo's handheld already had a way to pull real-world objects into a game. All you needed was a barcode, and a strange little device called the Barcode Boy. It is one of those ideas that sounds made up, and yet it was a real, boxed product you could buy in 1992. What Is the Barcode Boy? The Barcode Boy was developed by Sofel and released by Namcot, a Namco brand, only in Japan in December 1992. It connects through the Game Boy's link port, and a card is swiped through its sensor so the device can read the barcode printed on it. In effect, it gave the Game Boy a barcode scanner. Scanning the Supermarket Here is the part that delighted players: it did not only read the special cards in the box. You could scan barcodes from ordinary store-bought packaging too, turning a tin of food or a magazine into game data. Each code unlocked characters, items or features, so a trip to the supermarket became a hunt for the most powerful barcode you could find. Battles by Barcode Around four games were built to use it, the best known being Monster Maker: Barcode Saga and Battle Space. In Monster Maker, two players could enter barcodes and then fight head to head, with the codes determining each fighter's hit points, magic points, attack, defence and experience. Your shopping, quite literally, set your stats. A Truly DMG-01-Only Device There is a neat hardware footnote here. Because the Barcode Boy relies on the original Game Boy's link port, and the Game Boy Pocket introduced a different connector in 1996, the Barcode Boy is one of the rare accessories that only works on the DMG-01. It is a true original-hardware exclusive. Set 1, Set 2 and the Stand-Alone Unit The collection holds the Barcode Boy across its forms. The two boxed releases, Barcode Boy 1 and Barcode Boy 2, each paired the scanner with a compatible game and a deck of printed barcode cards to get players started. Alongside them sits a stand-alone unit, the scanner preserved on its own. Seen together, they show how Namcot packaged the same clever idea in more than one form for the Japanese market. There is a nice reason the gadget felt so futuristic at the time. In the early 1990s barcodes were the quiet symbol of a newly computerised world arriving in everyday shops, and the notion that a toy could read them, turning a cereal box into a game character, felt like genuine science fiction. That is exactly the spirit the Barcode Boy captured, and a big part of why it still charms people today. Why the Barcode Boy Endures The Barcode Boy quietly predicted a whole genre, the toys-to-life and scan-to-play games that would become huge decades later. As a Japan-only curiosity that depends on the original Game Boy, it is a wonderful talking point in any collection. Explore more peripherals in the Knowledge Base.

They hung from school bags and key rings all over the world: tiny LCD games, each one shaped like a shrunken Game Boy. For many children of the late 1990s, a Nintendo Mini Classic was their first taste of owning a Nintendo, even if it was not quite the real thing. Cheap, charming and surprisingly faithful, they deserve a place in any Game Boy collection. What Are Nintendo Mini Classics? The Nintendo Mini Classics are a series of small, single-game LCD handhelds licensed by Nintendo from 1998. Most are reissues of classic Game & Watch titles, though the line later stretched to outside properties too. Each unit is styled to look like a miniaturised Game Boy, complete with a little screen and controls, and a removable keychain clipped to the top corner so you could carry it everywhere. Game & Watch in Your Pocket The first wave in 1998 included Super Mario Bros., Donkey Kong Junior, Fire and Parachute. In one sense this was the Game & Watch coming full circle: the simple, single-game LCD format that Gunpei Yokoi pioneered in the early 1980s, reborn for a new generation, now wearing the silhouette of the handheld it had helped inspire. Not Quite a Game Boy It is worth being clear, because collectors sometimes are not: a Mini Classic is not a Game Boy and does not play cartridges. Each one is a fixed, self-contained LCD game in a Game Boy-shaped case. They were produced by the company Stadlbauer and sold through a range of distributors in different countries, which is why you will find the same little units under various names and packaging around the world. A Whole Series to Collect The line grew well beyond that first handful. Beyond the Super Mario Bros. and Donkey Kong Junior units, the collection also holds Mario's Cement Factory, another Game & Watch classic reborn in miniature. Over the years the range spanned many titles, mixing Nintendo's own back catalogue with other licensed games, so building a full set became a rewarding little quest in itself. Because the same units were sold through different distributors under slightly different names and packaging around the world, there is real variety for a collector to chase: regional boxes, colour variations and label differences all exist. It is exactly the kind of low-cost, high-charm corner of collecting where completeness is achievable and the hunt stays fun rather than ruinous. Why Nintendo Mini Classics Are Fun to Collect There are many Nintendo Mini Classics titles to chase, they are usually affordable, and they capture the exact moment the Game Boy shape became pop-culture shorthand for handheld fun. As a set they make a colourful, nostalgic display and a gentle entry point into collecting. Explore more Game Boy merchandise in the Knowledge Base.

The Game Boy played games, of course. But for a few years in the 1990s, accessory makers were convinced it should do everything else as well, and that included playing the radio. A small group of add-ons clipped onto the handheld and turned it into a portable FM radio, and they are some of the most charming oddities in the accessory world. A Radio in Your Game Boy The best known of these is the GameTunes Stereo FM Tuner, made by the accessory specialist Beeshu. It was a true FM radio that drew power and a home from the Game Boy, letting you tune in to stations through headphones. By most accounts it worked perfectly well, which is more than you might expect from such an unlikely mashup of console and transistor radio. GameTunes and the Gameball The GameTunes tuner was not alone. The collection also holds the BigBen FM Gameball, another take on the same idea from a different maker. Between them they show that putting a radio on a Game Boy was not a one-off joke but a small genre of its own, with rival companies offering their own spin on the concept. The Era of Add-on Everything FM tuners belong to a wonderful moment when the Game Boy was treated as a platform to build on, not just a toy to play. The same shops sold clip-on lights, magnifiers, amplifiers and cradles, all promising to make the handheld brighter, louder or more capable. A radio attachment was simply the logical extension: if you already carried a Game Boy everywhere, why not let it keep you company with music too? Why the Game Boy FM Radio Add-ons Are Fun to Collect Because they were niche, third-party and easily lost, Game Boy FM radio attachments are uncommon today, and they make a delightful talking point in a collection. They capture a very particular flavour of 1990s optimism, when a grey handheld seemed like it might be the one gadget you needed for everything. Browse more curious accessories in the Knowledge Base.

We tend to think of the Game Boy as a pure games machine. But for a brief, optimistic moment around 1991, one company tried to turn it into something else entirely: a pocket organizer, translator and reference library, years before the smartphone made all of that ordinary. The result was a small family of non-game cartridges that are now among the most curious items a DMG-01 collector can own. InfoGenius Series: Berlitz French Translator Cartridge The Game Boy InfoGenius Series In 1991 the publisher GameTek launched the Game Boy InfoGenius Productivity Pak range, a set of cartridges that contained no real game at all. Instead they offered genuinely useful tools: language translators, a travel guide, a personal organizer and a spell checker. On a console best known for Tetris, this was a bold and slightly eccentric idea. A Pocket Translator and Travel Guide Two of the most charming entries leaned into travel. The Berlitz translator cartridges offered French and Spanish phrases for travellers, while the Frommer's Travel Guide packed visitor information for fifteen major US cities into a single cartridge, drawn from the famous printed guides. Your Game Boy could, in theory, help you order dinner abroad and find your hotel. InfoGenius Travel Guide Spell Checker and Calculator Perhaps the most wonderfully unglamorous entry was the Spell Checker and Calculator. It let you type in a word and instantly see the correct spelling, drawing on a dictionary of more than sixty thousand commonly misspelled words, with a calculator thrown in for good measure. It was, essentially, office stationery for your games console. InfoGenius Spell Checker and Calculator Beyond the Cartridges: Notes and Organizers The productivity story did not stop at GameTek's cartridges. In Japan, Konami released the Nano Note in 1992, a licensed cartridge that turned the Game Boy into a full digital organizer, with a calendar, scheduler, address book, memo pad, calculator, expense tracking and alarm, and it could even exchange data over the link cable. It is a remarkably complete pocket organizer for a games console of the era. A similar impulse produced the Smartcom Electronic Note, another accessory that cast the Game Boy as a note-taker and organizer rather than a toy. Set beside the InfoGenius translators and the Nano Note, it shows this was not one company's whim but a recurring temptation: to look at the best-selling handheld on earth and wonder whether it could also run your day. Why the Game Boy InfoGenius Carts Matter The InfoGenius cartridges sold poorly and slipped into obscurity almost immediately, which is exactly what makes them fascinating now. They were an early, earnest attempt to treat the Game Boy as a general-purpose handheld computer, an idea the world would not truly embrace until pocket devices could do it all. For a collector they are quietly profound oddities. Explore more in the Knowledge Base.