Z80 Assembly programming for the Sega Master System and the Game Gear!

Unlike the Gameboy, the SMS and GG have a real Z80 CPU!... Quite surprisingly the Master System and Game Gear are pretty much the same system... it was also known as the Sega Mark III in Japan. The Game Gear has a smaller screen than the master system... rather strangely it actually has a better colour palette! but appart from that, they are identical, and can run the same basic games! Lets take a look at the specs!

Master System  / Mark III Game Gear Cpu Z80 3.5mhz Z80 3.5mhz Ram 8k 8k Max Rom 512k (Up to 4 mbyte in theory) 512k Vram 16k 16k Resolution 256x192 pixels (32x24 tiles - 768 tiles total) 160x144 pixels (20x18 tiles - 360 tiles total) Max Tiles 448 (8x8 px) (512 in theory but some vram used by tilemap etc) 448 (8x8 px) (512 in theory but some vram used by tilemap etc) Max Sprites 64 (8x8 px 8 per line) 64 (8x8 px 8 per line) Colors 32 onscreen (16 sprite, 16 tile) 32 onscreen (16 sprite, 16 tile) Palette 64 4096 Sound chip SN76489 SN76489 Joystick 2x 4 directon, 2 fire 1x 4 direction, 2 fire + start PSU Power Supply Model 3025-1 9V 1A Center NEGATIVE (both SMS and Mark III) (10V famicom works OK) Model MK-2103 10V 1A Center POSITIVE The smaller screen is handled by 'skipping the 6 tiles from the left and right side, and 3 from the top and bottom... So we can write a game for our gamegear, and run it on a mastersystem, we just need to design around the screen size difference, and use some different palette code!

ChibiAkumas Tutorials

Console graphics hardware - Tiles and Sprites!

The Gameboy,Gamegear and Mastersystem screens do not work like they do on computers like the CPC Graphics are not just 'bytes' in a memory address...  The screen is made up of a 'Tile Layer' and a 'Sprite Layer' To explain Tiles and sprites, lets look at our imaginary game shown to the right 'The Super Yuusha Siblings', on a theoretical game system the 'GameChibi'... Just to be very clear, we looking at this as a concept, not the actual layout of the gameboy! Looking at our example, We have a level with some grass, blocks, and some collectable 'stars'... our hero, Yume is controlled by the player...
The screen is made up of the Tile layer, and the Sprite Layer, Usually Sprites are drawn above the Tiles... but sometimes they may be drawn below. It's also possible we could use sprites for the stars.. but sprites are very limited, so the object doesn't move, then tiles will do the job... we can even animate the stars by switching the tile between different patterns
The tile array on the systems we'll be looking at is made up of 8x8 tiles... the array is a 'grid' of these tiles, so the tiles must line up, a block cannot be at a 'half way boundary' Tiles are defined by a number (usually 0-255)... we define the bitmap (image) data for that tile (we'll call it a pattern), then tell the hardware what positions in the tile array to use that pattern. In our example, the black background is pattern 0 ... the blocks are pattern 1... the grass is pattern 2... and the stars are pattern 3 Our 'GameChibi' console has a tile array of 8x8... and 64 bytes is used to define the tile grid... So to define the stars, we need to set memory locations 10,20 and 15 of the tile array to byte '3' A real system usually has a tile array bigger than the screen (maybe just by one row and one coumn)... this is to allow smooth scrolling of the screen, where two tiles are 'half shown' Now in the case of our 'GameChibi' system, with it's 64 tile screen, and 256 pattern definitions, we could just set every visible tile to a different pattern, and treat the screen as a plain bitmap again... We can do that on the MSX1, but unfortunately the Gameboy and Mastersystem have too few tiles for their screen size, so some parts of the screen must contain the same tile!

Because our system is using hardware sprites, we have to design our game sprites in a way that can be drawn with the hardware sprites... for example lets look at our Yume sprite... if our 'GameChibi' used 8x8 hardware sprites, we would have to use 48 of them to make this image!... we can save 5 (marked green)... these have no data, so we can just not draw them... When it comes to moving our character, the software will have to move the hardware sprites all together, so the user does not realise they are made up of many sprites!... on systems with more onscreen colors than sprite colors, two or more sprites may be overlapped to make the sprite appear more colorful Most systems will have one color (usually 0) which marks the transparent colour. but there is a problem! with software sprites on a bitmap screen, we can draw as much as we want, it will just get slow.... but with hardware sprites, we have a fixed limit of how many sprites can be shown onscreen at once! sounds bad? well actually it's worse, even though a system like the master system can show 64 sprites onscreen, there can only be 8 on a line... if more than 10 appear on the same line, some will flicker, or not appear... there's nothing we can do about it, we just have to design our game to avoid this problem!

The Sega Mastersystem and Sega game gear are almost the same system, the major difference is the screen size, The SMS screen is 256x192, but the GG screen is 160x144... If we draw the same data to the screen, we'll realize that the gamegear is drawing only the center area of the SMS screen area, with 3 lines missing from the top and bottom, and 6 columns missing from the left and right sides. While both systems are 16 color, The Gamegear has a better color palette! The MasterSystem uses a single byte palette in the format: --BBGGRR The GameGear uses 2 bytes, in the format ----BBBB GGGGRRRR

Gamegear & Mastersystem Tilemap

The 2 bytes that define each tile are in the format ---PCVHN NNNNNNNN

The SMS/GG memory supports up to 64 sprites, they can be 8x8 or 8x16 pixels. They use the second palette of 16 colors. if you don't set the palette, all your sprites will be black! It is not possible to X or Y flip sprites. There are 3 memory bytes for each hardware sprite, but they are not consecutive! Look at sprite 0... it's Y co-ordinate is at &3F00 ... it's X co-ordinate is at &3F80... it's Sprite Number is at &3F81 Sprite Numbers can come from memory address &2000 (Tile 256+), or &0000 (Tile 0-255) depending on the setting of register &06

To Set a register we out the value to the control port, then the register number +128.
For Example: lets set register 8  to value 11

My SMS/GG site - A breif overview of the system, I'll be including these systems in my tutorials soon!