Mystic Warriors-based hardware blending issues / finds

[FredYeye]

I'm not sure where would be best to post these kinds of things, but here goes.

Mystic Warriors (mystwarr) has a lot of blending issues. Been taking a look at it and getting familiarized with the related MAME code. I couldn't figure out how mystwarr decides what layer to blend, so I started looking at other related games. Violent Storm (viostorm) has the same (or very similar) HW, so I started there.

Violent storm seems to make use of blending much less overall, but there are still some instances nonetheless. Just like in mystwarr, some blending works and some doesn't. Perhaps most notably though, it's actually applying blending on sprites! Something that mystwarr doesn't seem to do (never say never...).

In any case, it does seem like sprites with the effect code 0b01 are supposed to be blended.
As viostorm was using metamrph_sprite_callback and that game may or may not behave the same way, I copied that callback and made a separate callback for viostorm to test it out for now.

K055673_CB_MEMBER(mystwarr_state::viostorm_sprite_callback)
{
	int c = *color;
	int attr = c;

	c = (c & 0x1f) | m_sprite_colorbase;

	// Bit8 & 9 are effect attributes. It is not known whether the effects are generated by external logic.
	if ((attr & 0x300) != 0x300)
	{
		// NEW: set blend code based on sprite effect code
		const int blend = ((attr >> 8) & 1) << K055555_MIXSHIFT;

		*color = c | blend;
		*priority_mask = (attr & 0xe0) >> 2;
	}
	else
	{
		*color = c | 3<<K055555_MIXSHIFT | K055555_SKIPSHADOW; // reflection?
		*priority_mask = 0x1c;
	}
}

This looks like this:

Which makes the one and only blended sprite in the game, the fountain, blend.

It's not quite right though - it's too transparent. The K054338 register K338_REG_PBLEND is set to 8 here (range: 0 - 31). Let's assume that for whatever reason this is supposed to be inverted, 31 - 8 = 23.

This looks about right. Inverting the value is just a random idea though, and that's why this isn't a PR! Jokes aside, I'm still very inexperienced with these things so it's hard to intuit / know where to look and what to try still.

I'm going to keep digging around and see what I can find but for now I figured I'll post this magnificent blended water what I found so far.

---

I also noticed another thing: K054338 has the register K338_REG_BRI3, a brightness control. This one also seems to go unused in these games. Seems like something that could potentially be "easy" to get a half-decent implementation for, but in the end I wasn't quite sure where to apply it.

---

Video sources:

mystwarr PCB videos
https://www.youtube.com/watch?v=0WAlbNOmTpI
https://www.youtube.com/watch?v=01n3zToNWn8 (part 1)
https://www.youtube.com/watch?v=PvMN8OfYUgQ (part 2)
https://www.youtube.com/watch?v=BtZ7RYq8pjc (highest quality footage)

viostorm PCB video
https://youtu.be/0hEZvGd4whM

[FredYeye]

Oh. Did I say the only blended sprite? Well, there's another one!

The "END" letters also seem to be blended sprites. And interestingly enough, they're fading in reverse! As in, going from fully there to disappearing... makes the case for inverting the blending stronger. Blending can't be inverted at all times though, since that'd make the mist in the park stage fully opaque.

[galibert]

Some doc I wrote a fucking long while ago in a branch that I'll need to redo entirely before it can be public: // The 054338 "CLTC" is a final blender/modifier. It is connected to // a series of 54573 dacs (one per color channel) or one integrated // 56766 which also handles brightness. // Input: // - two pixels composed each of: // - 13-bit color index // - 2-bit shadow information // - 2-bit mixing information // - 2-bit brightness information // - one bit of "is a pixel present?" // Output: // - 8-bit R, G and B // - 8-bit intensity (may be unused if not connected to a 56766) // The chip is connected to the palette ram. It is designed to get // its inputs from a 55555 mixer chip, but it has been used with a // 53251 with some hacking (fixed second pixel connected to a specific // tilemap layer, fixed mixing/brightness info). // Theory of operation: // - lookup the pixel colors in the colormap // - blend the two pixels together, either with an average or additively, saturate // - add shadow-controlled value to each channel, saturate or wrap // - output the result conjointly with a brightness value // If there's no pixel, a background color is output instead // Register map: // f e d c b a 9 8 7 6 5 4 3 2 1 0 // 00 . . . . . . . . --------back R-------- // 02 --------back G-------- --------back B-------- // 04 . . . . . . . --------shadow 1 R------- // 06 . . . . . . . --------shadow 1 G------- // 08 . . . . . . . --------shadow 1 B------- // 0a . . . . . . . --------shadow 2 R------- // 0c . . . . . . . --------shadow 2 G------- // 0e . . . . . . . --------shadow 2 B------- // 10 . . . . . . . --------shadow 3 R------- // 12 . . . . . . . --------shadow 3 G------- // 14 . . . . . . . --------shadow 3 B------- // 16 . . . . . . . . -------briset 1------- // 18 -------briset 2------- -------briset 3------- // 1a . . . . . . . . . . x1 -----mv 1----- // 1c . . x2 -----mv 2----- . . x3 -----mv 3----- // 1e . . . . . . . . . . CL WA BR SH MI KI // MI (mixpri): select the second (0) or the first (1) pixel as // primary in the blending and as source of the 2-bit // mixing mode. Mixing mode 0 is no mixing, pass the // primary pixel color as-is. // x<n>: mixing mode n is average (0) or additive (1) // mv<n>: mixing mode n level (0-31) // mixing formula for each channel: // - average: result = (primary * (32-level) + secondary * level) / 32 // - additive: result = min(0xff, primary * (32-level)/32 + secondary) // SH (shdpri): select the second (0) or the first (1) pixel as source // of the 2-bit shadow mode. Shadow mode 0 is no shadow, // output the color unchanged. // CL (clipsl): select whether to saturate (0) or wrap (1) the result // shadow <n><c>: value to add to channel c in shadow mode n. 9-bits // signed (-255..+255, -256 is not supposed to be used) // // clipping formula: // - saturate: result = min(0xff, max(0, input + value)) // - wrap: r1 = abs(input + value), result = r1 > 255 ? 510 - r1 : r1 // Hardware-wise, wrapping is doing a 9-bit signed add and taking the // absolute value // BR (brtpri): select the second (0) or the first (1) pixel as source // of the 2-bit brightness mode. Brightness mode 0 is no // brightness, outputs 0xff. // briset<n>: brightness value to output in mode n // KI (kill): output background color instead of computed pixels (0) // back<c>: background color channel c // Background color is also output when the input says there's no pixel present // WA (wait): when actually mixing two colors, the palette ram access // is saturated. If the cpu tries to access the palette ram at that // time, it will either wait (0) or take priority (1) but then the // output pixel will be incorrect.

…

On Wed, May 8, 2024 at 1:25 PM Fred ***@***.***> wrote: Oh. Did I say *the only blended sprite*? Well, there's another one! vio3.png (view on web) <https://github.com/mamedev/discussions/assets/7881804/4203cda8-0d61-41c6-8f36-da92c95656af> The "END" letters also seem to be blended sprites. And interestingly enough, they're fading in reverse! As in, going from fully there to disappearing... makes the case for inverting the blending stronger. Blending can't be inverted at all times though, since that'd make the mist in the park stage fully opaque. — Reply to this email directly, view it on GitHub <#109 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACGSF4OPYAPCCDWY5OQ2N5DZBIDSLAVCNFSM6AAAAABHMBNQ4OVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TGNJTGQ4TM> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[FredYeye]

Good information!

Since the K054338 takes two inputs, I suppose one problem right now is figuring out just which two sources it's supposed to use.

[galibert]

mystwarr and xexex use essentially the same setup. The 53251 is double-clocked to generate two pixels per dot clock. Sprites and lvc don't change between the two. Similarly, layers a, c and d (a, b and d I think on mystwarr but not 100% sure) are directly connected. All the fun happens on the input of layer b on the '251. On one cycle the color just passes through. On the other cycle, if the bit 8 is set then the bits 0-3 are cleared (usually making it transparent, but that depends on the '251 configuration of course).. That's done in discrete logic chips, you can see it in the mystwarr schematics. OG.

…

On Thu, May 9, 2024 at 10:18 AM Fred ***@***.***> wrote: Good information! Since the K054338 takes two inputs, I suppose one problem right now is figuring out just which two sources it's supposed to use. — Reply to this email directly, view it on GitHub <#109 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACGSF4MQPQO62EQC3ILIOG3ZBMWMJAVCNFSM6AAAAABHMBNQ4OVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TGNRVGQYTM> . You are receiving this because you commented.Message ID: ***@***.***>

[FredYeye]

Hm. I was unable to find a proper schematic... this was the best I could find - a picture that partly features the 55555 and the 54338.

[galibert]

There's no proper schematic, but the shenanigans with the '251 are visible in the bucky 'o' hare partial ones. CHENMIX is coming from a latch set by the cpu, and allows disabling blending.

…

On Mon, May 13, 2024 at 9:41 AM Fred ***@***.***> wrote: Hm. I was unable to find a proper schematic... this was the best I could find - a picture that partly features the 55555 and the 54338. 055555_schematics.jpg (view on web) <https://github.com/mamedev/discussions/assets/7881804/0940d4d4-ae34-46ea-8a35-55eaf23225d1> — Reply to this email directly, view it on GitHub <#109 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACGSF4M3OHTTT7YTOWSTITTZCBVDPAVCNFSM6AAAAABHMBNQ4OVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TIMJVGYZDM> . You are receiving this because you commented.Message ID: ***@***.***>

[FredYeye]

Yes ok, I can see CHENMIX ("character enable mix" maybe?) on there! I don't think I would've thought of a latch enabling / disabling blending haha. I'm not the best at reading these schematics, but CHENMIX looks to be connected to the LS175 Q1, and the corresponding D1 gets set from D9 of the cpu databus. Is this is done by writing to some specific address (range), perhaps?

CHENMIX doesn't seem to be on the mystic warriors boards - makes sense if it's related to the '251?
Still, something must determine when blending should be enabled / disabled on those boards as well.
My first guess was that a write to the K054338 or the K055555 would enable / disable blending, but this does not appear to be the case (doesn't seem to happen in mame at least).

The end of the mystic warriors intro fades from one layer to another. If you insert a coin mid-fade, it switches to a scene that shouldn't use blending but doesn't adjust the blend amount... so probably it's disabling blending here? Maybe it's a good case for digging for... well, something.

I hope you don't mind my ramblings about this. Thanks for your insights, galibert 😅

[galibert]

Oh duh, you're correct, mystwarr has a 55555, not a '251. Ok yeah, the 5x5 is designed to work with the '338, it sends it the two top pixels.

rummage rummage rummage yeah, I wrote a doc for that one too:

K055555

Priority encoder. Always found in conjunction with k054338, but the
reverse isn't true. The 55555 has 8 inputs: "A", "B", "C", and "D"
intended for a 156/157 type tilemap chip, "OBJ" intended for a '246
type sprite chip, and "SUB1-SUB3" which can be used for 3 additional
layers. In addition a background layer with an optional gradient is
internally generated. The disp register allows to enable/disable
layers independently.

For each pixel the circuit computes for each layer a 17-bits color, a
8-bits priority, 2 bits of shadow, 2 bits of mixing mode, and 2 bits
of brightness. All 8 priorities are compared, with an implicit order
in case of ties. The two front pixels are sent to the 054338.

Layers A-D:

Layers A to D provide 10 color bits as input. Transparency is
determined by checking if the low bits are 0, when nl is 4 to 8
depending on the colsel setting.

Color is built from the 10 color bits + 7 bits from clbk added at the
top, for 17 bits total.

Priority of the layer is set in the associated pri register. For
layers A and B, default priority is in register pri0. If the
associated ?p bit of colchg is set and the bottom bits of the
color have a higher value that the bottom bits of colpri, then
the priority is taken from pri1.

Mixing mode bits are taken either from bits 8-9 of the input or the v
inmix value depending on the v inmix on bits.

Brigthness is taken from v inbri. For layers A-B, if the ?b bit of
colchg is set, brightness is forced to zero if the bottom bits of
the color have a lower or equal value that the bottom bits of
colpri.

Object/Sub 1-3:

Object and Sub 1 layers provide 8 color bits, 8 priority bits, 2
mixing mode bits and 2 brightness bits. Sub 2-3 is the same except
with 17 color bits. Transparency is determined by checking if the
low bits are 0, when nl is 4 to 8 depending on the colsel
setting, same as for layers A-D.

For Object and Sub 1, color is built from the 8 color bits, plus the
bits from priority which are not selected by inpri. For the bits
selected by inpri, clbk is used instead starting by bit 10 (same
alignement than for layers A-D).

For Sub 2 and 3, color is build from bits 0-9 of the input. Bits
10-16 come either from the input or cblk depending on the cblk on
register.

Priority is built from the priority input for the bits selected by
inpri, from the pri register for the others.

Mixing mode is taken from either the mixing mode input of the os inmix
value depending on the os inmix on bits.

Brightness mode is similarly taken from either the input or os inbri
following os inbri on.

Shadow bits:

There are two shadow bits not tied to any specific layer, but usually
provided by the sprite generator. When both are zero, there is no
shadow and the result shadow bits are zero. Otherwise, the two bits
select a test to do (never, <, = or >, shd pri sel register) and a
priority level to test against (shd pri register). If the test passes
for the two top layers, the shadow bits are passed on.

Each layer says whether it can be shadowed by its shd on bit. If
zero, shadow value will always be 0 for that layer, no matter the test result.

Background layer:

A background layer is generated when all normal layers are disabled or
transparent. Shadow/mixing mode/brightness are zero. Color is built
from 9 bits of an internal counter with 4 bits from bgc cblk added as
msb.
If the cnton bit is zero, the counter stays at zero. When cnton is
one and bgcmd is zero the counter is reset at start of screen and
incremented on hblank (horizontal lines). When both cnton and bgcmd
are one the counter is reset at start of line and incremented every
pixel. The exact position of the resets is unknown, probably the
syncs.

Priority comparison:

For each pixel, each of the eight layers has a computed 8-bits
priority associated. Priority resolution depends on prflp bit.

When prflp is 0, the lowest priority score wins. In case of equality,
the order is A>B>C>D>O>S2>S3>S1.

When prflp is 1, the highest priority score wins. In case of
equality, the order is S1>S3>S2>O>D>B>C>A.

The two to highest priority pixels are output with their associated
shadow, mixing mode and brightness bits. If only one pixel is enabled
and non-transparent, the second layer uses the background layer color.
If no pixel is available, both outputs use the background layer color.
When an output uses the background, the "no pixel present" signal is
set.

Register map:
7 6 5 4 3 2 1 0
00 bgc cblk . . . . --bgc cblk---
01 bgc set . . . . sds prf cnt bgc
02 colsel0 . -vb col-- . -va col--
03 colsel1 . -vd col-- . -vc col--
04 colsel2 . -s1 col-- . --o col--
05 colsel3 . -s3 col-- . -s2 col--
06 colchg on . . . . ap ab bp bb
07 a pri0 ------------a pri0-----------
08 a pri1 ------------a pri1-----------
09 a colpri ----------a colpri-----------
0a b pri0 ------------b pri0-----------
0b b pri1 ------------b pri1-----------
0c b colpri ----------b colpri-----------
0d c pri ------------c pri------------
0e d pri ------------d pri------------
0f o pri ------------o pri------------
10 s1 pri -----------s1 pri------------
11 s2 pri -----------s2 pri------------
12 s3 pri -----------s3 pri------------
13 o inpri on ----------o inpri on---------
14 s1 inpri on ---------s1 inpri on---------
15 s2 inpri on ---------s2 inpri on---------
16 s3 inpri on ---------s3 inpri on---------
17 a cblk . ---------a cblk----------
18 b cblk . ---------b cblk----------
19 c cblk . ---------c cblk----------
1a d cblk . ---------d cblk----------
1b o cblk . ---------o cblk----------
1c s1 cblk . --------s1 cblk----------
1d s2 cblk . --------s2 cblk----------
1e s3 cblk . --------s3 cblk----------
1f s2 cblk on . --------s2 cblk on-------
20 s3 cblk on . --------s3 cblk on-------
21 v inmix -vd-- -vc-- -vb-- -va--
22 v inmix on -vdm- -vcm- -vbm- -vam-
23 os inmix -s3-- -s2-- -s1-- --o--
24 os inmix on -s3m- -s2m- -s1m- --om-
25 shd pri1 -----------shd pri1----------
26 shd pri2 -----------shd pri2----------
27 shd pri3 -----------shd pri3----------
28 shd on s3s s2s s1s os vds vcs vbs vas
29 shd pri sel . . -ps3- -ps2- -ps1-
2a v inbri -vdb- -vcb- -vbb- -vab-
2b os inbri -s3b- -s2b- -s1b- -s0b-
2c os inbri on -s3m- -s2m- -s1m- -s0m-
2d disp s3 s2 s1 o vd vc vb va

[FredYeye]

Right, so there's no "blend on/off" toggle per se, the two highest priority pixels are sent to the 338 and mixed based on the mixing mode bits (which come from the input or from v inmix).

Not sure where to go from here... I'll have to see what is currently being done and not done in mame i suppose.

Sprites should be blended if bit 8 of the sprite effect code is set. This part now works, but the blending is "backwards". Priority / primary pixel issue, perhaps...? Needs investigation.

For bg layers... I guess just identifying the 10 color bits from the layer inputs and determining if blending should happen or not is a start, maybe.

[FredYeye]

I took a hiatus from mystwarr hacking - my computer at the time was just too slow at compiling mame. Though maybe there's some settings I should be using to speed up testing compile times? I got a new cpu which cut down times significantly in any case, so I went back to this.

I decided to focus on sprite blending for now, seeing how it's working somewhat.
I've only tested mystwarr / viostorm / metamrph so far, but all 3 games seem to set inverted alpha on startup and leave it like that. This makes sprite alpha work incorrectly; it is now backwards. It can be "fixed" by doing this in konamigx_v.cpp:

m_k054338->invert_alpha(0); // hack for mystwarr / viostorm / metamrph: do not invert alpha for sprites
alpha = m_k054338->set_alpha_level(alpha);
m_k054338->invert_alpha(1); // restore alpha

I'm not saying it should be done this way, but it produces the desired result (except for blend values 0 and 31, see below).

---

Here's another odd thing I just noticed with sprite alpha blending. Blend values 0 and 31 seem to actually be correct, "only" 1-30 are backwards. Strange! I need to track down why this is the case, don't have more time today. (For example: if 0 means fully visible, then 1 is almost transparent.)

---

After looking at metamrph for a while, I eventually realized that something is wrong with the shadows as well.

Currently, there's some checking against the effect code of the sprite to determine if K055555_SKIPSHADOW should be set. This is to remove the shadows from the reflections in the ice stage. This also removes shadows from airborne objects however!
It seems like turning off shadows on shadow code 3 both disable the reflected shadow and keeps the airborne shadow. This seemingly goes against the above documentation and konamigx_v.cpp that state that shadow code 0 means off.

This is what my modified callback looks like currently:

K055673_CB_MEMBER(mystwarr_state::metamrph_sprite_callback)
{
	const int attr = ((*color >> 8) & 0b11) << K055555_MIXSHIFT;
	const int shadow = (*color >> 10) & 0b11;

	*color = (*color & 0x1f) | m_sprite_colorbase | attr;

	if (shadow == 0b11) { *color |= K055555_SKIPSHADOW; }

	*priority_mask = (attr & 0xe0) >> 2; // oops! doesn't use prio bits atm
}

This appears to mostly work, minus priority issues. Which is probably not simple to fix, as always. 😅

Edit: as it turns out, shadows not showing seems to be a priority issue, not that it's getting skipped, heh. Back to sprite blending it is...

[FredYeye]

In tracing down the issue of 0 & 31 blending values working as intended and 1-30 being inverted, i first reached this code in k053246_k053247_k055673.cpp.

if (drawmode & 2)
{
	if (alpha <= 0) return;
	if (alpha >= 255) drawmode &= ~2;
}

If alpha is 255, then change the drawmode from alpha drawing to solid drawing as this sprite is 0% transparent anyway (probably an optimization). Blending inversion is always on in these games, so 0 mix mode level -> inverted (31) -> expanded to a u8 (255) = this is a solid sprite. This makes sense.

Going further down, the actual blending is performed here (and in some other places).
dst_ptr[ecx] = alpha_blend_r32(pal_base[eax], dst_ptr[ecx], alpha);

Switching the dst and src blending operands should invert the result, like so:
dst_ptr[ecx] = alpha_blend_r32(dst_ptr[ecx], pal_base[eax], alpha);

This change along with tagging sprites with their effect attributes in the K055673_CB_MEMBER callbacks in mystwarr_v.cpp makes sprite transparency work seemingly as intended.

I'll give it some testing, but I'm guessing this affects other systems than just mystwarr-based HW.
Probably it breaks blending everywhere else. 🎉

[FredYeye]

I wrote a simple program that shows the K054338 & K055555 states to make it easier to see what's going on. The K055555 window is still a mess but ah well. This made me realize that not only is this text supposed to be blended, it's also using the elusive additive blending mode!
This is also gets used in metamrph for the stained glass windows in the last stage. I tried hacking in additive blending by modifying the alpha blending code in tilemap.cpp, but I couldn't get it to look quite right.

[FredYeye]

Two things I'm thinking about atm:

k054338.h

// configuration
	void set_alpha_invert(int alpha_inv) { m_alpha_inv = alpha_inv; }

what is set_alpha_invert? I mean, I get that it inverts the alpha. But is this a hack or because of how the chip is wired up? configuration would suggest that it isn't a hack.

---

k053936.cpp

if ((dst_ptr+ecx+dst_base2)<dst_size) dst_base[dst_ptr+ecx+dst_base2] = alpha_blend_r32(pal_base[pixel], dst_base[dst_ptr+ecx+dst_base2], alpha);

if (pixeldouble_output)
{
	ecx++;
	if ((dst_ptr+ecx+dst_base2)<dst_size) dst_base[dst_ptr+ecx+dst_base2] = alpha_blend_r32(pal_base[pixel], dst_base[dst_ptr+ecx+dst_base2], alpha);
}

Made some changes to k054338.cpp and wanted to make sure I didn't break anything, so I traced some value to where it gets used. Stumbled upon another alpha_blend_r32(dst, src, a) with its source operand yet again being named dst_base... which suggests that the operands have been accidentally flipped. Needs testing though.

[FredYeye]

Additive blending of mmaulers sprites! Improves the slime death animation a bit.

The image below isn't taken at the same moment as above, but this looks very different on PCB compared to mame currently. When the slime is almost completely transparent, the background behind him still lights up quite brightly from the blending. As far as I understand, mame currently renders a background bitmap first, then draws / blends sprites on top of this finished image. I wonder if this method is sufficient...?

(image from PCB footage)

[FredYeye]

Made some progress on tile blending:

Blending appears to work pretty good in mystic warriors now. The water is also transparent now without having to resort to hacks.

With a small tweak it also works on sexy parodius:

It still requires additive blending, but this helps quite a bit with visibility haha.