Violent Storm Palette fix
For a while the colors on this game has been very washed out compared to real pcb footage but i think i found the perfect settings to fix the colors somewhat, heres a comparsion and i hope it helps
Before
and after
To my eye, that looks worse. It looks like when someone cranks up the saturation control on the TV to an ungodly level. Look at how it make the “GO!” text less legible.
If you look at pcb footage apparently it's supposed to look like that?
I think there's something subtle with the protection causing the 'off' colours in the first place.
There have been reports of some bootlegs having the 'off' colours and some having more 'correct' colours using the exact same monitor setup that displays the original game without it looking washed out.
Also if you go into the service mode and do the colour test, it's not showing what it should there either.
Konami did like their subtle protections, sometimes directly interacting with memory, so there could be more to it than what is simulated for the movement right now.
There's a small chance it's some non-standard resistor network on the boards though, there are other cases like that (Data East's Crude Buster) where in some cases the expected resistors got replaced with standard ones during repairs.
I'd assume something simpler like the last thing you mentioned: nonlinear resistor array for r/g/b. I'd even say possibly 'gamma proms' like Namco System 22 are more likely than it being subtle protection.
either way direct footage from any original PCB is far less washed out https://www.youtube.com/watch?v=0hEZvGd4whM
people aren't specifically adjusting their capture set-ups for this PCB, so it's something with the board, maybe there's even some software controlled gamma in addition to the brightness, could be a simple case of an unemulated register on the mixer chip that nothing else uses like this.
The bootleg in mame has the correct colors , it's an issue with the 55555 or 55550 emulation (the bootleg cracks / patches it all out so looks good in mame)
Adjusting the overall brightness is NOT the fix.
I'm not seeing any difference with the overall bootleg colours in MAME apart from the service mode colour test does work there (which is a bit weird, why patch just that to work correctly, did they not know how to improve the game colours too?)
could even be related to https://github.com/mamedev/mame/pull/13400
It would seem like the color test palette doesn't get copied over properly (in viostorm). The palette colors are located at 0x015EFC, and the function responsible for uploading them sits at 0x012288. It interacts with the 55550, I'm not familiar with this chip. But this might be a good place to start looking into.
| Name | Size | Ram address | 55550 address | Value |
|---|---|---|---|---|
| 1 | 300 | 00 | 0x98 | |
| 1 | 304 | 01 | 0x00 | |
| 1 | 305 | 02 | 0x0F | |
| Src | 4 | 310 | 04 | 0x015EFC |
| 2 | 302 | 08 | 0x0006 | |
| Size...? | 4 | 314 | 0A | 0x00000080 |
| Dest | 4 | 318 | 0E | 0x330800 |
| 2 | 308 | 12 | 0x0002 | |
| Size? | 4 | 31C | 14 | 0x00000040 |
Here's the data being written to the 55550 the first time around. As far as I can tell, it should send 16 colors (64 bytes) per transfer, and it sends every other color (4 bytes copied, 4 bytes skipped) per transfer.
I wonder if some of those other params can adjust things like the contract / gamma when copying said palettes.
konamigx_state::K055550_word_w():
case 0x98: {
const u32 dst = (m_prot_data[0x07] << 16) | m_prot_data[0x08];
const u32 src = (m_prot_data[0x02] << 16) | m_prot_data[0x03];
for(int x = 0; x < 16; ++x) {
mspace.write_dword(dst + x *4, mspace.read_dword(src + x * 8));
}
} break;
My most definitely correct implementation of this memory transfer! Just needs some, uh, polish.
didnt even know that screen was broken hahahaha
In any case, this fixes the viostorm palette test. The implementation of this memcpy operation is obviously not complete, so I'll only send a PR if more qualified mame devs think I should.
If I had more test cases I could improve it, but the color test menu is the only instance of this operation I know of.
use the size param and it's probably ok IMHO
doesn't solve the problem of the ingame graphics having washed out palettes, but nice to know that specific test mode case is tied to the protection.
makes me wonder if they do it with the protection there to bypass something else related to the rest of the game palettes, but who knows