mirror of
https://github.com/ekeeke/Genesis-Plus-GX.git
synced 2025-02-03 05:32:48 +01:00
106 lines
4.6 KiB
Plaintext
106 lines
4.6 KiB
Plaintext
|
|
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.
|
|
|