- 7 cycles / pixel, 160 pixels wide + 2 x 16 pixels borders (192px total)
- Code tiled scrollable background, 8x8 tiles, up to 16 colors
- Real-time rendered sprites, sprite mode 0 has 18 x 8 pixels wide 2bpp sprites of which 9 may display on a scanline
- VSync mixer only
- No video related VSync tasks (unlike Mode 2)
- 40 tiles wide (320 pixels, 3.5 cycles / pixel) optional text mode overlays on the top / bottom
Each sprite can have arbitrary Y size (0 - 127 pixels, 0 turns the sprite off), may use any 3 colors, and can be X mirrored. They are fetched from RAM, so some copying may be necessary in games (but very little, just ROM => RAM transfers). These sprites are rendered real-time with no VSync tasks. This means for each of the 18 sprites you have a 8 byte structure to fill in (X:Y position, sprite data location in RAM, height, X mirror flag, the 3 colors), and the video frame will display the sprite accordingly. This means in this mode you will have lots of CPU time for your game logic (you only have a VSync mixer to deal with), and the RAM consumption is also low (no RAM tiles).
The border may be controlled by flags, and may also be sourced from a per-scanline color list (only allocated if enabled). This color list may also source background colors (for the game area and the text overlays), or alternatively you may use it to select a logical scanline for the background on every physical scanline (for various vertical effect, in a racing game this would be used to create hills and valleys).
Per-scanline parallaxing of the background is also supported (not tested yet of course, but the code is there). These would allow the mode to realize an Outrun style racing game.
The overall timing of the mode matches that of an NTSC Commodore 64 (including the text overlays), so it might be used for C64 ports or C64 style games (I will later build a sprite mode for this with 12 pixels wide sprites like the C64 had in multicolor mode).
When there are too many sprites on a scanline, they alternate in an interlaced manner. You may see this in action in the demo (in CUzeBox the frame merge option accessible with F7 smooths this out). A limitation here is that sprites are arranged in fixed pairs, so for example sprite 0 can not coexist with sprite 1 on the same scanline etc. (which you may need to pay attention when designing a game).