Replies: 9 comments
-
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. |
Beta Was this translation helpful? Give feedback.
-
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: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
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? 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 😅 |
Beta Was this translation helpful? Give feedback.
-
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: K055555Priority encoder. Always found in conjunction with k054338, but the For each pixel the circuit computes for each layer a 17-bits color, a Layers A-D: Layers A to D provide 10 color bits as input. Transparency is Color is built from the 10 color bits + 7 bits from clbk added at the Priority of the layer is set in the associated pri register. For Mixing mode bits are taken either from bits 8-9 of the input or the v Brigthness is taken from v inbri. For layers A-B, if the ?b bit of Object/Sub 1-3: Object and Sub 1 layers provide 8 color bits, 8 priority bits, 2 For Object and Sub 1, color is built from the 8 color bits, plus the For Sub 2 and 3, color is build from bits 0-9 of the input. Bits Priority is built from the priority input for the bits selected by Mixing mode is taken from either the mixing mode input of the os inmix Brightness mode is similarly taken from either the input or os inbri Shadow bits: There are two shadow bits not tied to any specific layer, but usually Each layer says whether it can be shadowed by its shd on bit. If Background layer: A background layer is generated when all normal layers are disabled or Priority comparison: For each pixel, each of the eight layers has a computed 8-bits When prflp is 0, the lowest priority score wins. In case of equality, When prflp is 1, the highest priority score wins. In case of The two to highest priority pixels are output with their associated Register map: |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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.
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 waterwhat 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
Beta Was this translation helpful? Give feedback.
All reactions