Apologies in advance as this is my first GameBoy coding attempt!
I've had a sudden interest in the original Nintendo GameBoy after a 68KMLA article started discussing an emulator for it, that runs on a 68K Mac, at near full speed:
https://68kmla.org/bb/threads/gb6-game-boy-emulator-for-system-6.41600/
And that's quite impressive given that the original GameBoy ran on a 4MHz Z80-type CPU and has a whole pile of quirky graphics tricks that can both slow down the unit by shocking amounts (as we'll find out), but is also the source of its capabilities when programs are tailored to them.
Of course, I don't want to use the kind of normal tiling, sprite and window tricks we'd expect on a GameBoy. Instead I want to treat the screen as a simple pixel-mapped frame buffer upon which I can write text anywhere and do the kinds of graphics operations that were normal on 8-bit computers. I am interested in whether that's at all practical.
Tile-Based Graphics
And it might not be. I'm not going to fully go into the architecture here, because PanDocs does a far better job than I could. I just want to mention the most relevant aspects for my demo.
GameBoy graphics are tile-based. It's a half-way house between early character-based computer graphics and full-fledged frame-buffer graphics that became dominant in computers from the mid-1980s and in game systems from the end of the 1980s. The way they work is that video ram contains a number of, typically 256 x 8x8 pixel blocks, which are called 'Tiles' and then the screen is divided into a 2-d array of values, called the Tile Map, each of which references a Tile. Typically, the values are 8-bits, so each entry in the tile map can reference any one of the Tiles.
When the video generator scans the screen, it scans the Tile Map from top left to bottom right, reading a TileMap entry's value to get the Tile and then it reads a row of pixels from the tile (typically 8 pixels) and transfers those pixels to the screen. When a scan line has been completed, the video generator starts on the next scan line, which for the next 7 rows means reading the same Tile Map entries as before, leading to the same Tiles, but a new row on each Tile.
At one level, this is inefficient, because for every row of pixels sent to the screen, both a Tile Map entry and the pixels themselves need to be read, which might mean up to twice the number of memory accesses.
But on early 8-bit computers (of which the GameBoy is effectively one), it's worth it, because firstly, most of the effort for manipulating the screen can be done by changing Tile Map entries rather than the pixel data. Secondly, because these 8-bit computers often lacked sufficient memory to represent an entire pixel-mapped screen, a lot of video RAM can be saved by re-using the same Tile in multiple Tile Map entries. And because most 8-bit video games had a lot of repeated graphics, it's a massive advantage. So, in summary: Tiled graphics can be much faster to manipulate and use far less memory.
Tiled graphics are best for representing relatively static background images, because otherwise the programmer has to compose the animated parts of a screen using dynamically allocated tiles, which undermines the performance advantage. So, in many systems (like the Commodore-64, the Nintendo NES, Sega Megadrive and of course the GameBoy), tiles are augmented by Sprites which are additional tiles that can overlay the tiled image at any location. The video hardware then handles the effort of composing the background tiles and Sprite data, and typically this also means a limitation in the number of Sprites that can appear on the screen at any point, due to a limitation in hardware registers for Sprites or the sheer amount of hardware effort needed to compose them on top of the tiled background.
Thus, games oriented around tiles and sprites tend to be platform-oriented: a somewhat repetitive 2-d background that can scroll around and upon which the main game characters act.
Well, that's enough about Sprites, because I'm not interested in them for my demo. Suffice to say that the GameBoy implements plenty of them; using them takes up extra video processing and also adds a second video layer called the "Window". I'm not interested in that either.
A Proposed GameBoy Full Frame Buffer
The GameBoy TileMap is 20x18 and each entry is 8-bits, which means that there are 360 tile map locations, but only 256 tile map entries are possible. This would normally preclude being able to support a full frame buffer, which would require a unique tile for each tile map entry (i.e. 360 tiles).
However, it should be possible to achieve that. The GameBoy also has an LCD control register which allows you to select an alternate set of tiles so that the same tile map entry could point to a different tile in a different part of the screen. And it's possible to generate an interrupt on a given scan line. This means that we can use the first 256 tiles for most of the screen, then on the given scan line interrupt switch to the other set of tiles; and then at the end of a video image - in what's called the VBlank region (of 10 scan lines), reset the LCD control register back to the original set of tiles.
Cleverly, the GameBoy tile mapping works so that tile map values $80 to $ff on the first set of tiles map to the same tiles as for the the second set, because the first set are treated as unsigned tile map values (so $80 = 128, which comes after $00 = 0), but the second set are signed ( because $80= -128, which comes before $00 = 0).
Conclusion
The Nintendo GameBoy was an incredibly successful handheld games console beating even more advanced handheld games consoles, thanks to its lower price and power consumption.
To save memory and performance (given its lowly 8-bit CPU), it used Tiled Graphics techniques borrowed common 8-bit graphics techniques, particularly from the Nintendo Entertainment System. Normally (as on the NES), this would heavily restrict the versatility of possible images, because the number of unique tiles will be less (256) than the number of tile locations in the tile map (360 in the case of the GameBoy). However, the GameBoy supports a second set of tiles and a raster trick which should make it possible.
In the next blog post I'll discuss the SM83 CPU at the heart of the system.
