(almost) Z80 Assembly programming for the Gameboy and Gameboy Color

The Gameboys do not use a Z80... some people say they do, but those people are wrong! it has MANY features of a Z80... but MANY others are weird... and some are even BUGGY! So why might we want to use it... well,  the gameboy+GBC sold 118 MILLION!... compared to the ZX spectrum's puny 5 million... the gamegears 10 million, the Master system's 13 million... the Gameboy gives the 'real z80' systems a spanking! We can't use a normal Z80 assembler to develop for it, but Vasm in 'OldStyle' mode will compile for it, just use the switch '-gbz80' and it will compile compatible code!

The Gameboy Color is just a Gameboy with a few 'power ups', The best thing is, if we limit ourselves a bit, we can write games that have full color on the GBC, but still play the same on the Classic Gameboy! Lets take a look at the GB and GBC specs! Specs: Gameboy Gameboy Color Cpu 4mhz 8mhz Ram 8k 32k Vram 8k 16k Resolution 160x144 160x144 Max Tiles 256 (8x8 px) - 360 onscreen 512 (8x8 px) - 360 onscreen Max Sprites 40 (10 per line) 8x8px or 8x16px 40 (10 per line) 8x8px or 8x16px Colors 4 4 per palette - 8 palettes (0-7) from 32768 colors for tiles separate 8 palettes (0-7) from 32768 colors for sprites Sound chip GBZ80 PAPU GBZ80 PAPU

If you want to learn GBZ80 get the Cheatsheet! it has all the Z80 commands, but higlights the ones missing on the GBZ80 - as well as the extra commands that the GBZ80 posesses, and the commands with different bytecode... You can use it for both your Z80 and GBZ80 development!

ChibiAkumas Tutorials

Flags are DIFFERENT on the GBZ80!

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 6 (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 gameboy can show 40 sprites onscreen, there can only be 10 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 gameboy color has many enhancements, We can switch the CPU into high speed mode, for twice the CPU power and we have extra ram banks we can page in. Most importantly the GBC adds more graphics ability, with twice the tile definitions (512) and 8 'palettes' of four colours Colour palettes are defined with a 5 bits per channel in the format  -BBBBBGG GGGRRRRR Turning on the 'Second bank of tiles' (the extra 256) and setting the color palette is done by paging in the second 'GBC only' Vram Bank The second bank of the tilemap is in the format: PVH_RCCC _ No function P Priority (1=Tile in front of Sprites... 0=behind) C Color palette (0=normal 1=Sprite palette) V Vertical Flip (1=on) H Horizontal flip (1=on) R Ram bank for tiles (1= GBC for tiles numbered  257-511)

Sprite Data is stored from &FE00 onwards, there are 40 sprites, and each definition uses 4 consecutive bytes... For Example, Sprite 0's bytes are highlighted in black... it has a Y co-ordinate, an X co-ordinate, a Tile Number, and tile Attributes Y and X are offset, so you can have a sprite partially off the screen, You need to set XY to (8,16) to get the top corner of the screen (0,0) Attributes:   7      6         5           4      3   2   1   0   Tile-Sprite Priority Y-flip X-flip GB-Pal CGB-Vbank CGB-Palette On GBC sprites use an alternate 8 palettes to background tiles. Sprites are all 8x8 or 8x16, which is define by bit 2 of &FF40 (LCDC - LCD Control)

Gameboy & Gameboy Color Links
Visual Boy Advance - Emulates the Gameboy , Gameboy Color, and others!
GameBoy Dev'rs - Gameboy programming website
Color Programming - The only site I can find with examples about Color on the gameboy!
Vasm - You can't easilly compile for the gameboy with a standard Z80 assembler like  WinApe... but VASM in 'OldStyle' mode is pretty similar to WinApe