Mode 748 Quickstart

From Uzebox Wiki
Jump to: navigation, search

Video mode 748's most notable feature is an extensive ability to configure it both compile-time and "on the fly", allowing for the creation of more complex games with multiple, differently configured screens. To support this, it employs different concepts than other Uzebox video modes.

Mode 748 example: SPI RAM bitmap scroll
Mode 748 Example: SPI RAM bitmap scroll

Examples for the video mode are found in the repository, at [kernel/videoMode748/examples].

Note that since several components of this mode work similarly to Mode 74 (particularly the sprite blitter), this mode also uses the "M74" or "m74" prefix for its exposed interfaces.

Documentations are provided in the video mode's various components:

Compiling the examples

The examples can be compiled after you succesfully built Uzebox components by the main Makefile (issuing Make from the root of the repository). This is necessary so the packrom tool is built, which is used to create .UZE files. Then you can compile each example using its own Makefile. Binaries will be placed in _bin_ directories which can be used right away.

Basic concepts: Memory allocation

Unlike other modes, this mode has an extensive set of configuration flags. They are documented in the respective source (videoMode74.def.h). To accommodate these flags, the best is to create an include file (as the examples do, in "m74cfg.h"), and force its inclusion by the makefile (adding "-include m74cfg.h" to CFLAGS). This prevents having long command lines, and is a bit cleaner as it is possible to comment the file.

Important things to set up are the start addresses of various data sources, most notably those required for a tile & sprite game screen. You can check the [Sprite demo] and the [Sprite scroller] for working examples on setting up tilesets and masks for the background.

Here comes another big difference: with Mode 748, you have to manage the allocation of some memories yourself, that is, not by the linker as it is normally done (that is, you just reserve some space by defining variables and arrays and let the linker locate those). This allows for more precise memory management and to overlay different distinct memory configurations for different screens on top of each other.

To do this proper, let's recall how the AVR's RAM memory is normally laid out and managed:

  • 0x0000 - 0x00FF: I/O registers
  • 0x0100 - 0x????: Linker's allocations (starting at 0x0100, growing upwards)
  • 0x???? - 0x????: Unused RAM
  • 0x???? - 0x10FF: Stack (starting at 0x10FF, growing downwards)

Basically it is possible to locate things at absolute offsets in the area marked as Unused RAM without problems. Mode 74 by default locates its 256 byte palette buffer at 0x0F00 - 0x0FFF, and offers a 16 color RAM palette at 0x1000 - 0x100F. The sprite engine also locates its workspace above that below the stack which may be fine if there aren't too many sprites.

With this image, usually the best may be using RAM tiles used for the sprite blitter in the 0x0700 - 0x0EFF range (64 RAM tiles), setting up this by setting:

  • m74_rtbase to 48 (first RAM tile at 0x0700)
  • m74_rtmax to 64 (64 RAM tiles, ending at 0x0EFF)

If you need more RAM tiles for the sprite blitter, expand this downwards. You can use any RAM tile index where the RAM is free as an User RAM tile.

Tile rows and VRAM

The next important part is defining the tile rows, that is, what display mode each tile row uses, and where the VRAM for that should be located. Up to 32 tile rows may be defined of which any may be displayed anywhere (split screen; Y scrolling).

The sprite engine can blit to tile rows of Row mode 0 (the 192 pixels wide 8x8 4bpp tiles mode). Unlike Mode 74, the sprite engine can work with any layout, so you can locate your VRAM wherever you want.

The sprite demos

It might be a good idea to start a new game's development from either sprite demo ([Sprite demo] or [Sprite scroller]) as it contains suitable initialization for the most fundamental features a typical game may require. Studying it you can get a glimpse on how Mode 748's data structures interact to make up a screen.

Some more on sprites

Mode 748's sprite support contrary to the normal kernel doesn't provide "sprites" as such, it rather provides a capability to blit 8x8 transparent sprite tiles on the display (a bit lower level support). You can use this to realize your own high-level sprite support fitting for the game you are designing (see for example Flight of a Dragon, a Mode 74 game. The RAM tile support however is very similar to that of the normal kernel, so it can semi-automatically restore the screen clearing away previously drawn sprites.

So a frame routine normally should restore the screen (M74_VramRestore()), perform any operation it wants to do with the VRAM (such as scrolling, see the sprite scroller for example), then blit sprites to their new locations (M74_BlitSprite()).