3wonders (jtcps1): Missing background colors on some screens

[BMF54123]

Certain screens that should have background colors do not. Comparing MAME and the MiSTer core (MAME on left):

I actually reported this as an issue in MAME years ago, and I think the consensus was that the method this game uses to set the background color wasn't used in (any?) other games, possibly because it causes color problems on some arcade monitors. I don't know the technical details, though.

[jotego]

Thank you for the detailed report. This is video footage from real PCBs. They look like JTCPS1:

https://www.youtube.com/watch?v=UbJuP4HQMXc https://www.youtube.com/watch?v=UiJeLfruoh4&t=71s https://www.youtube.com/shorts/ZfEGxUK6G9I

[BMF54123]

I found this thread on the MAMEWorld forums that explains what is going on: https://www.mameworld.info/ubbthreads/showflat.php?Cat=2&Number=380374&page=&view=&sb=5&o=&vc=1

"The screen is red on real hardware, this is verified, although some monitors glitch out and strip all red from the image instead. (this happens whenever background colours are used on CPS1 games with said monitors)

MAME correctly emulates the original CPS1 background colours in all situations. Some bootlegs may differ. If you're using one of the monitors that can't handle the signal from the board it will look different tho, yes."

Apparently what's happening is that the game is changing the background color during Vblank in such a way that it confuses the circuitry in a lot of arcade monitors, causing the color to be subtracted from the rest of the image instead (I have seen this with certain games on my own CRT setup). You'll notice that the game selection screen in that thread has a cyan tint to it because of this, and there is a weird gradient on Midnight Wanderers where the monitor is trying to show the purple background.

According to the thread, there was a CPS1 hardware hack that fixed the issue, and some bootlegs apparently do output black instead of color, which might contribute to the confusion.

Also, for what it's worth, the official Capcom Arcade 2nd Stadium collection does show a red background on the game selection:

[jotego]

Thank you for the reference. Note that the boards in the videos I linked were not bootlegs.

The description talks about a glitch during blank that confuse the color reference for some monitors. I think the expected output by the designers is the one that the core produces so I will not take any action on this.

Thank you for bringing it up.

[paulb-nl]

The videos of the PCB shows that the CRTs removes all the red color of all graphics of the 3wonders Game Select screen. Obviously that is not the designer intent and it should show the red colors + red background. Most likely Capcom used CRT monitors that did not have issues with the wrong blank level.

Mame says color code 0xBFF should be used for blank pixels for CPS1. https://github.com/mamedev/mame/blob/25587a632132fab97a00a3dc4b379046aa073463/src/mame/capcom/cps1_v.cpp#L3091C2-L3106C3

        /* Blank screen */
    if (m_cps_version == 1)
    {
        // CPS1 games use pen 0xbff as background color; this is used in 3wonders,
        // mtwins (explosion during attract), mercs (intermission).
        bitmap.fill(0xbff, cliprect);
    }
    else
    {
        // CPS2 apparently always forces the background to black. Several games would
        // show a blue screen during boot if we used the same code as CPS1.
        // Maybe Capcom changed the background handling due to the problems that
        // it caused on several monitors (because the background extended into the
        // blanking area instead of going black, causing the monitor to clip).
        bitmap.fill(m_palette->black_pen(), cliprect);
    }

The DL-0921 RE (LUT storage page) also shows that 0xBFF should be used as you have also said in your source code: https://github.com/jotego/jtcores/blob/581875c01f8a2794e9d122afdf1ab0c17ba156d8/cores/cps1/hdl/jtcps1_colmix.v#L133C1-L138C7

`ifdef CPS2
localparam [13:0] BLANK_PXL = { 2'b11, 12'hBFF }; // according to DL-0921 RE but it doesn't look
// good on CPS1/CPS1.5 games. CPS2 is fine with that
`else
localparam [13:0] BLANK_PXL = ~14'd0;
`endif

What did not look good about using 0xBFF with CPS1?

[jotego]

Using 0xBFF like in CPS2 and MAME actually produces a gray background, not a red one. I am not sold on the story of red being the right color because of some artifact on some CRT color balancing circuit allegedly used by the designers.

I can, however, accept using the 0xBFF code because that is the evidence we have from examining the silicon die shots, but the output produced is not red. Either red or gray will likely cause complaints as neither look correct. Just see how the GAMESELECT screen looks, with the black frames around the game cards. It does not look right.

I have compiled a MiSTer core using 0xBFF so you can examine it yourself. Please find it attached. Look at more games, not just 3wonders jtcps1.rbf.zip

[paulb-nl]

There is a bug in your test build using 0xBFF. It displays backgrounds that should be black as grey too.

Here are some palettes in Mame:

This is the screen with 3wonders build date. Background should be black. We can see that 0xBFF is black. Your test build displays grey.

This is the Game Select screen with red background. 0xBFF is red. Your test build displays grey.

This is the Midnight Wanderers title screen with blue background. 0xBFF is blue. Your test build displays grey.

[jotego]

Thank you for the detailed reply. The color mixer must no be falling correctly to select the background. I will check it.

[JuJuden]

First of all, thanks to Jotego for the amazing core. It's so good I didn't bother firing up the old CPS1 board for years. I finally did last week in order to check its suicide battery and immediately noticed the difference in the background colors as well.

I captured the attract sequence on real hardware (no sound and apologies for the terrible Framemeister video noise): https://youtu.be/oGm67nrkSEQ

Findings:

• The Select Game screen shows a blue hue with some red gradient on top.
• Each game title screen shows a different color for a moment before switching back to normal. Midnight Wanderers and Chariot have a Yellow hue with some Purple gradient visible on top of the screen, while Don't Pull looks all red for a second.
• Not related to this, but worth mentioning Lou's gun is framed here. I couldn't find the original issue number, but I recall there was some discussion about it. It's also still mentioned here: https://github.com/jotego/jtcores/issues/157

Except for Lou's gun going out of the frame in max piccinato's video, it looks consistent with all three videos Jotego shared. I am adding a couple of extra videos for lukemorse1 which seems to show the exact same behavior: https://www.youtube.com/watch?v=H40mqzbG9U0 https://www.youtube.com/watch?v=f0Y0TtWQwjc https://www.youtube.com/watch?v=rGy5VvTNfXI&t=63s

Since the Framemeister offers a "Color Invert" mode, I tried capturing each screen:

I hope this helps. Let me know if you think some other tests could be useful to solve this!

[jotego]

Thank you for the video footage. I was not aware of the gun problem. I have created a new issue for that one, #667. The three of them may be related but it is easier to track them one by one.

I do not know what to do with the inverted color images. But I can see that there might be a hint of pale red in the game selection screen in your footage, which was the topic of the present issue. Thanks for sharing it.

[JuJuden]

You are welcome. Apologies for mixing the two topics.

Researching on the other topic, I came across Japanese Game Center livestreams where the screen goes black when the GAME SELECT screen is supposed to appear (sync drop due to the upscaler or capture device not handling the weird color/signal?):

• https://youtu.be/TcXRdGqDsGo?si=16DgLyN9RlQ614QV&t=140
• https://www.youtube.com/live/F9GeHmWoXoY?si=rvJV4PPW5RcAUln_&t=1834

This one is struggling a bit but doesn't loose sync: https://youtu.be/m4L2ULic3Cw?si=DEW-IChkpphZpK8D&t=70

This one (quality is poor) is showing similar behavior as my capture, but it might be because it's also using the Framemeister: https://youtu.be/MwN0coQmPGU?si=L1_SilzaO78ODvDW&t=1161

Unfortunately, I don't own a CRT anymore to run more test.