After some testing, it turns out that the unused VDP address $C0001C
 (mirrored at $C0001E) controls how the VDP generates the display.

 Specifically, it allows layers to be turned on and off, it affects how
 high priority sprites or tiles are interpreted, and it seems to change
 how layers are combined together.

 No games use this register to my knowledge, maybe it was left in for
 testing or debugging purposes by the VDP manufacturer. This was all
 checked on an original model Genesis, the register may not be present
 or behave differently in later versions of the VDP hardware.

 Here's the layout of $C0001C/$C0001E:

 MSB             LSB
 -gfe ---d cba- ----

 Notes:

 Unmarked bits have no effect.
 Anything pertaining to plane A also applies to the window layer.
 Any description about color intensity changes is only valid when
 the VDP is in shadow/hilight mode.

     a = Display garbage (bad pattern data) on all background rows
         and for the sprites.

     b = Turn display off (background and sprites)
         Display is filled with background color.
         CRAM data is randomly corrupted as long as this bit is set.

     c = Turn display off (background only)
         In shadow/hilight mode, high priority tiles are also invisble
         but are drawn in the regular normal intensity backdrop color,
         while low priority tiles are drawn in the half intensity
         backdrop color.
         Transparent pixels in high priority sprites are also filled
         with the normal intensity backdrop color, so sprites have
         a tile shaped outline around them.
         It seems like either underlying pixels from the background
         are visible through shadow/hilight pixels in sprites, but
         the colors are wrong. (as if they were logically OR'd with
         the sprite pixels, as both layers can be seen)
         CRAM data is randomly corrupted as long as this bit is set.

     **  When 'c' and 'b' are set, the background layers are invisible,
         but sprites are not. All sprites, regardless of priority,
         have a tile shaped outline around them that is drawn in some
         color other than the backdrop color. (can't exactly tell)

     d = When set, garbage is displayed in the top and bottom border areas.
         Plane B is disabled, only plane A is visible.
         All sprites are drawn in the regular intensity backdrop color.
         High priority plane B tiles are drawn in the regular intensity
         background color, low priority plane B tiles are drawn in the
         half intensity backdrop color.

 g,f,e = All bits turn off sprites when set.
         If bit 'd' is set, bit 'e' changes the garbage data printed
         in the border areas.

 Bits b,c,d have effects when combined, as the following table
 shows. Some of this information is a rehash of what was explained
 above. Bits g,f,e will turn off sprites in all cases. (unless they
 are already off to begin with)

 Notes:
 RI = regular intensity backdrop color
 HI = half intensity backdrop color
 A,B,S = Plane A, plane B, sprite layer

 b c d   Effect
 -----   ------
 0 0 0   Display shown normally
 0 0 1   B and S off, high priority pixels from B and S drawn in RI
 0 1 0   A and B off, high priority pixels from A and S drawn in RI, sprites
         have tile-shaped outline in RI.
 0 1 1   Plane A pixels seem to be OR'd with plane B pixels, and the
         output is OR'd with the sprite pixels.
 1 0 0   A, B, and S off
 1 0 1   B and S off, shadow/hilight mode off
 1 1 0   A and B off, sprites have tile shaped outline in unknown color.       
 1 1 1   A and S off, shadow/hilight mode off

 In mode 4, the same results apply with the following exceptions:

 - Shadow/hilight processing is always off

 - Anything that enables plane B seems to turn on a second graphics
   layer, which is identical to plane A with garbage data. (so the VDP
   can't really create two playfields in mode 4, but it does seem
   to try to re-use plane A with bad graphics)
   The settings which seem to enable plane B are when
   bits b,c,d are 1,1,1, and and 0,1,1.

 - The leftmost 8 pixels show a lot of garbage data when some of the
   bits are set. (seems unrelated to sprites or background)
   Earlier it was discovered that the VDP doesn't draw the background
   tile in the left 8 pixels when the lower 3 bits of the horizontal
   scroll value are not equal to zero, it shows garbage data that seems
   to be based on the sprite positions. Also, this can be seen in the
   rightmost 8 columns if you enable 40-cell mode while in mode 4, so
   the resulting display is 320x192.