source/docs/newreg.txt

@@ -0,0 +1,105 @@
+
+ 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.
+

source/docs/ste.txt

@@ -0,0 +1,152 @@
+
+ Shadow / Hilight description
+ Version 0.1 (03/06/01)
+
+ by Charles MacDonald
+ WWW: http://cgfm2.emuviews.com
+
+ Unpublished work Copyright 2001 Charles MacDonald
+
+
+ Table of contents
+
+ 1.) Introduction
+ 2.) Color generation
+ 3.) Backgrounds
+ 4.) Sprites
+ 5.) Overscan / border area
+ 6.) Miscellaneous
+ 7.) Games that use shadow / hilight mode
+ 8.) Disclaimer
+
+
+ 1.) Introduction
+
+ The shadow / hilight feature has never been properly documented, so here's
+ my attempt at doing just that.
+
+ I'd like to thank Flavio Morsoletto for sharing results from his
+ shadow / hilight tests.
+
+ 2.) Color generation
+
+ As the VDP draws each pixel of the display, it uses the raw pattern data
+ and palette values to select an entry from CRAM, which is used to
+ create red, green, and blue values that define the color of the current
+ pixel being drawn.
+
+ In shadow / hilight mode, the VDP can do two things to the resulting pixel
+ color, either divide it's intensity (brightness) in half, or double it.
+ This is based on two factors, the priority level of the pixel, and the
+ values of the raw pattern and palette data.
+
+ In terms of how the colors are actually generated, imagine that each 3-bit
+ color value from CRAM is scaled up to fit a 0 to 63 range. Half intensity
+ colors would would range from 0 to 31, normal intensity colors would
+ range from 0 to 63, and double intensity colors would range from 32 to 63.
+
+ 3.) Backgrounds
+
+ Low priority background tiles are shown at half intensity, high priority
+ background tiles are shown at normal intensity.
+
+ When the VDP renders high priority tiles, it does not take transparent
+ pixels into account. Instead, any underlying pixels (either from the
+ background, sprites, or backdrop) will be shown at normal intensity.
+
+ For example, if you had a completely transparent tile on plane B that
+ had it's priority bit set, any pixel from plane A or the sprite layer
+ that fell within the tile's 8x8 pixel area would be shown at normal
+ intensity.
+
+ 4.) Sprites
+
+ Low priority sprites are shown at half intensity, high priority sprites
+ are shown at normal intensity. The priority values do not affect the
+ intensity of any overlapping sprites.
+
+ Any high-priority background tile will force a low-priority sprite to
+ be shown at normal intensity.
+
+ I'm going to call any sprite pixel that uses color 3Eh a hilight
+ operator, and any sprite pixel that uses color 3Fh a shadow operator.
+ Such pixels are not drawn by the VDP, but instead are treated as
+ transparent.
+
+ A shadow operator forces the underlying background or backdrop pixel
+ to be shown at half intensity, regardless of the pixel's priority.
+
+ A hilight operator forces the underlying background or backdrop pixel
+ to be shown at normal intensity if it is currently at half intensity,
+ or at double intensity if it is currently at normal intensity.
+
+ Operator pixels do not affect other sprites. In the case of operator
+ pixels overlapping, the first sprite in the sprite list is the one that
+ defines how the underlying background / backdrop pixel is modified.
+
+ 5.) Overscan / border area
+
+ The backdrop is the entire display area (usually 256x224 pixels), which is
+ filled with the color value selected in VDP register #7. The background
+ layers and sprites are overlaid on top of the backdrop, so that any pixel
+ where no background or sprite pixels exist will show the backdrop color.
+
+ Overscan is the area outside of the physical display. You can see it if
+ you adjust the vertical or horizontal hold of a monitor to see past the
+ top/bottom or left/right edges of the screen.
+
+ When shadow / hilight mode is enabled, the overscan area is always
+ displayed at half intensity. The backdrop is also shown at half intensity,
+ but that can be modified by overlaying background tiles or sprites.
+ (either by priority, or by operator pixels)
+
+ If the display is blanked (bit 6 of VDP register #1) or the leftmost
+ column is blanked (bit 5 of VDP register #0), the portion of the display
+ in question has the same properties as the overscan area. (meaning
+ sprites and background tiles cannot affect it's intensity, it is
+ always fixed to half intensity)
+
+ 6.) Miscellaneous
+
+ There is a bug in the way sprite pixel colors are processed by the VDP.
+ Color 0Eh of palettes 00-02h is always displayed at normal intensity,
+ regardless of the priority level of the sprite.
+
+ The contents of CRAM for colors 3Eh and 3Fh do not affect the shadow or
+ hilight effect. Though I've noticed many games set one or more of the
+ RGB values for either entry to maximum, like 0EEEh or 0E0Eh.
+
+ For those of you who want some statistics, the Genesis VDP can display 61
+ of 512 colors normally, and 183 of 1536 colors in shadow / hilight mode.
+ That doesn't include duplicate colors, which may or may not exist.
+
+ 7.) Games that use shadow / hilight mode
+
+ - Adventures of Batman & Robin
+ - Ecco 2 : The Tides of Time
+ - Gauntlet IV
+ - Mega Turrican
+ - Mortal Kombat
+ - Shinobi III
+ - Skeleton Krew
+ - Sonic 2
+ - Sonic 3, Sonic & Knuckles
+ - Sonic 3D Blast
+ - Space Harrier II
+ - Sub Terrania
+ - Red Zone
+ - Ranger-X
+
+ 8.) Disclaimer
+
+ If you use any information from this document, please credit me
+ (Charles MacDonald) and optionally provide a link to my webpage
+ (http://cgfm2.emuviews.com/) so interested parties can access it.
+
+ The credit text should be present in the accompanying documentation of
+ whatever project which used the information, or even in the program
+ itself (e.g. an about box)
+
+ Regarding distribution, you cannot put this document on another
+ website, nor link directly to it.
+