[VERA] Add explanation how the video pipeline works (#287)

* Add explanation how the video pipeline works

* corrections, clarifications, and explanations

---------

Co-authored-by: MooingLemur <mooinglemur@users.noreply.github.com>

Author: stople

X16 Reference - 03 - Editor.md

@@ -27,6 +27,8 @@ Mode $80 contains two layers: a text layer on top of a graphics screen. In this
 
 To switch modes, use the BASIC statement `SCREEN` or the KERNAL API `screen_mode`. In the BASIC editor, the F4 key toggles between modes 0 (80x60) and 3 (40x30).
 
+All modes use layer 1 (the uppermost layer) for text. Mode $80 also uses layer 0 for graphics.
+
 <!-- For PDF formatting -->
 <div class="page-break"></div>
 

X16 Reference - 09 - VERA Programmer's Reference.md

@@ -1017,7 +1017,7 @@ At reset, the palette will contain a predefined palette:
 | 2                     | 32 pixels   |
 | 3                     | 64 pixels   |
 
-**Rendering Priority** The sprite memory location dictates the order in which it is rendered. The sprite whose attributes are at the lowest location will be rendered in front of all other sprites; the sprite at the highest location will be rendered behind all other sprites, and so forth.
+**Rendering Priority** Sprites are rendered in ascending order in memory. If a pixel has already been rendered by a sprite with a given Z-depth, it will not be rendered again by another sprite with the same Z-depth. If Z-depth of the new sprite is higher, the pixel is overwritten.
 
 **Palette offset** works in the same way as with the layers.
 
@@ -1060,6 +1060,48 @@ FX features are controlled mainly by registers $9F29-$9F2C with DCSEL set to 2 t
 Preliminary documentation for the feature can be found in [Chapter 10](X16%20Reference%20-%2010%20-%20VERA%20FX%20Reference.md#chapter-10-vera-fx-reference), but as this is a brand new
  feature, examples and documentation still need to be written.
 
+
+## Video pipeline
+The active area of the screen consist of layers stacked in this order. They are rendered from bottom to top, by the display composer.
+
+- Sprite, if Z=3  _(top)_
+- Layer 1
+- Sprite, if Z=2
+- Layer 0
+- Sprite, if Z=1
+- The color of palette index 0, black by default _(bottom)_
+
+If a pixel in a layer is transparent (palette index 0), or, the entire layer is hidden (**DC_VIDEO**), the output becomes what is visible in the layer(s) below.
+
+### Sprite renderer / line buffer
+There are 128 sprites, which are rendered to a double scanline buffer. This buffer contains, for each pixel:
+- Palette index (transparent if 0)
+- Z depth
+- Sprite collision mask
+
+The display composer reads the pre-rendered data from line buffer A, pixel by pixel. At the same time, it requests the sprite renderer to render the next line to line buffer B. One scanline is written to the VGA port in 800 clock cycles. The deadline for rendering all of the sprite pixels for the next scan-out is 798 cycles.
+
+Sprite rendering can be interrupted by the CPU and the layer renderers accessing VRAM. If this happens, the sprite renderer will wait extra cycles until the VRAM no longer has contention. In addition, finding a sprite for rendering happens in parallel to the renderer doing the VRAM fetch and rendering pixels into the line buffer. This makes the number of sprites that can be rendered on one scanline non-trivial to predict.
+
+Cost:  
+Sprite finder:
+- 1 cycle per sprite index, 1 additional cycle per sprite that is handed off to the renderer.
+
+Sprite renderer:
+- Handoff from sprite finder: 1 cycle
+- Positioning line buffer pointer: 1 cycle
+- Fetching 32 bits of sprite image data: 1 cycle
+- VRAM ack latency: 1-4 cycles per fetch, depending on contention
+- Rendering one pixel: 1 cycle
+- Becoming ready for next sprite: 1 cycle
+
+Example:
+- Smallest (4bpp 8px): 13-17 cycles
+- Biggest (8bpp 64px): 99-147 cycles
+
+Sprites are rendered from lowest to highest index. If a sprite is to be rendered, the image data is loaded from video ram. Then, individual non-transparent pixels are written to the buffer IF the Z-depth is bigger than existing pixel, OR if existing pixel is transparent. Sprite collision mask may reveal a collision between sprites.
+
+
 ## Audio
 
 The audio functionality contains of 2 independent systems. The first is the PSG or Programmable Sound Generator. The second is the PCM (or Pulse-Code Modulation) playback system.