summaryrefslogtreecommitdiffstatshomepage
path: root/src/devices/video/mb_vcu.cpp
diff options
context:
space:
mode:
Diffstat (limited to 'src/devices/video/mb_vcu.cpp')
-rw-r--r--src/devices/video/mb_vcu.cpp58
1 files changed, 36 insertions, 22 deletions
diff --git a/src/devices/video/mb_vcu.cpp b/src/devices/video/mb_vcu.cpp
index 1db506e3d0e..eb14a1df884 100644
--- a/src/devices/video/mb_vcu.cpp
+++ b/src/devices/video/mb_vcu.cpp
@@ -7,16 +7,18 @@ Device for Mazer Blazer/Great Guns custom Video Controller Unit
Written by Angelo Salese, based off old implementation by Jarek Burczynski
TODO:
-- understand what exactly modes 0x03 and 0x13 really reads in set_clr() and
- where it puts results (yeah, shared VCU RAM, but exactly where?). Almost
- surely Mazer Blazer tries to read the pixel data for collision detection and
- Great Guns read backs VRAM for VCU test (patched for now, btw).
+- priority, especially noticeable in Great Guns sprites and Mazer Blazer
+ bonus stages;
+- bit 0 of m_mode;
+- first byte of parameter info;
+- Glitchy UFO in Mazer Blazer when it's gonna zap one of the player lives, m_mode = 0xe and
+ it's supposed to be set into layer 0 somehow but this breaks Mazer Blazer title screen sparkles;
- Understand look-up tables in i/o space.
-- Understand how to handle layer clearance.
-- Understand how planes are really handled.
-- Understand how transparent pens are handled (is 0x0f always transparent or
+- Understand how to handle layer clearance (mostly done).
+- Understand how planes are really handled (mostly done).
+- Understand how transparent pens are handled aka is 0x0f always transparent or
there's some clut gimmick? Great Guns title screen makes me think of the
- latter option)
+ latter option;
***************************************************************************/
@@ -282,11 +284,13 @@ READ8_MEMBER( mb_vcu_device::load_gfx )
int bits = 0;
uint8_t pen = 0;
uint8_t cur_layer;
-
+ uint8_t opaque_pen;
+
// printf("%02x %02x\n",m_mode >> 2,m_mode & 3);
// cur_layer = (m_mode & 0x3);
cur_layer = (m_mode & 2) >> 1;
+ opaque_pen = (cur_layer == 1);
switch(m_mode >> 2)
{
@@ -304,7 +308,7 @@ READ8_MEMBER( mb_vcu_device::load_gfx )
dot&= 0xf;
- //if(dot != 0xf || m_mode & 2)
+ if(dot != 0xf || opaque_pen)
write_byte(dstx|dsty<<8|cur_layer<<16|m_vbank<<18, dot);
}
bits += 4;
@@ -326,7 +330,8 @@ READ8_MEMBER( mb_vcu_device::load_gfx )
dot&= 1;
pen = dot ? (m_color1 >> 4) : (m_color1 & 0xf);
- //if(pen != 0xf || m_mode & 2)
+
+ if(pen != 0xf || opaque_pen)
write_byte(dstx|dsty<<8|cur_layer<<16|m_vbank<<18, pen);
}
bits++;
@@ -360,8 +365,8 @@ READ8_MEMBER( mb_vcu_device::load_gfx )
pen = m_color2 >> 4;
break;
}
-
- //if(pen != 0xf)
+
+ if(pen != 0xf || opaque_pen)
write_byte(dstx|dsty<<8|cur_layer<<16|m_vbank<<18, pen);
}
@@ -396,35 +401,46 @@ READ8_MEMBER( mb_vcu_device::load_set_clr )
{
case 0x13:
{
+ //int16_t srcx = m_ram[m_param_offset_latch + 1];
+ //int16_t srcy = m_ram[m_param_offset_latch + 3];
+ //uint16_t src_xsize = m_ram[m_param_offset_latch + 18] + 1;
+ //uint16_t src_ysize = m_ram[m_param_offset_latch + 19] + 1;
bool collision_flag = false;
-
+
for (yi = 0; yi < m_pix_ysize; yi++)
{
for (xi = 0; xi < m_pix_xsize; xi++)
{
dstx = (m_xpos + xi);
dsty = (m_ypos + yi);
-
+
if(dstx < 256 && dsty < 256)
{
uint8_t res = read_byte(dstx|dsty<<8|0<<16|(m_vbank)<<18);
-
- if(res != 0xf)
+ //uint8_t res2 = read_byte(srcx|srcy<<8|0<<16|(m_vbank)<<18);
+
+ //printf("%02x %02x\n",res,res2);
+
+ // TODO: how it calculates the pen? Might use the commented out stuff and/or the offset somehow
+ if(res == 5)
collision_flag = true;
}
+
+ //srcx++;
}
+ //srcy++;
}
-
+
+
if(collision_flag == true)
m_ram[m_param_offset_latch] |= 8;
else
m_ram[m_param_offset_latch] &= ~8;
-
break;
}
case 0x03:
- {
+ {
for (yi = 0; yi < m_pix_ysize; yi++)
{
for (xi = 0; xi < m_pix_xsize; xi++)
@@ -433,9 +449,7 @@ READ8_MEMBER( mb_vcu_device::load_set_clr )
dsty = (m_ypos + yi);
if(dstx < 256 && dsty < 256)
- {
write_byte(dstx|dsty<<8|0<<16|(m_vbank)<<18, 0xf);
- }
}
}
break;