Toggling black screen when launching Scramble arcade core

[morgoth]

I tried to play Konami's old STG Scramble earlier today, but upon launching, the screen toggles on/off a few times, and then largely remains black. This is odd b/c I have been using my Mister for 2ish years, and have never encountered a screen issue like this before. Could a faulty .mra setting or something be the culprit? I've pasted the contents of the .mra below. Also, I'm using "Scramble_20210915.rbf". Thanks for your help!

-------------
<misterromdescription>
<remark>
prg 0000-7FFF
aud 8000-9FFF
obj0 A000-BFFF
obj1 C000-DFFF
col E000-E01F
</remark>
<name>Scramble (Stern Electronics set 1)</name>
<mameversion>0216</mameversion>
<mratimestamp>201911270000</mratimestamp>
<year>1981</year>
<manufacturer>Konami (Stern Electronics license)</manufacturer>
<category>Space / Defender</category>
<setname>scramble</setname>
<rbf>scramble</rbf>
<buttons names="Shoot,Bomb,-,-,Start 1P,Start 2P,Coin,Pause" default="A,B,Start,Select,R,L"/>
<switches default="FF,FC,F1">
<dip bits="8,9" name="Lives" ids="3,4,5,255(Cheat)"/>
<dip bits="17,18" name="Coinage" ids="1c/1cr,1c/2cr,1c/3cr,1c/4cr"/>
<dip bits="19" name="Cabinet" ids="Upright,Cocktail"/>
</switches>
<rom index="1">
<part>00</part>
</rom>
<rom index="0" zip="scramble.zip|scrambles.zip" md5="686d9523f69d6be4af6fd17c2bf63ef8" type="merged|nonmerged">
<part crc="b89207a1" name="2d"/>
<part crc="e9b4b9eb" name="2e"/>
<part crc="a1f14f4c" name="2f"/>
<part crc="591bc0d9" name="2h"/>
<part crc="22f11b6b" name="2j"/>
<part crc="705ffe49" name="2l"/>
<part crc="ea26c35c" name="2m"/>
<part crc="94d8f5e3" name="2p"/>
<part crc="b89207a1" name="2d"/>
<part crc="e9b4b9eb" name="2e"/>
<part crc="a1f14f4c" name="2f"/>
<part crc="591bc0d9" name="2h"/>
<part crc="22f11b6b" name="2j"/>
<part crc="705ffe49" name="2l"/>
<part crc="ea26c35c" name="2m"/>
<part crc="94d8f5e3" name="2p"/>
<part crc="bcd297f0" name="ot1.5c"/>
<part crc="de7912da" name="ot2.5d"/>
<part crc="ba2fa933" name="ot3.5e"/>
<part crc="ba2fa933" name="ot3.5e"/>
<part crc="516e029e" repeat="4" name="5h"/>
<part crc="5f30311a" repeat="4" name="5f"/>
<part crc="4e3caeab" name="c01s.6e"/>
</rom>
<rom index="3" md5="none">
<part>
00 00 42 00 1E 00 01 00
00 00 40 A8 03 00 01 00
</part>
</rom>
<nvram index="4" size="33"/>
</misterromdescription>

[zakk4223]

Are you using vsync_adjust=2?

[morgoth]

Yes, I am

[zakk4223]

Use a 50hz video mode with the scramble core (this doesn't cause it to run at a different refresh rate, it just allows it to calculate a working pixel clock)

put this in your ini, at the bottom.

[A.SCRMBL]
video_mode=9

[morgoth]

interesting. Will that code snippit change the video mode specifically when I launch scramble? And which version of scramble...I see two...
Thanks!

[zakk4223]

Yes, it will change for any game that uses the scramble core

[morgoth]

@zakk4223, thanks so much, that worked.
Any chance you (or somebody else) has a list of (arcade) cores that require 50hz video mode?

[aberu]

https://mister-devel.github.io/MkDocs_M ... logcompat/ - this is incomplete, but it's got a lot on there.

[zakk4223]

@zakk4223, thanks so much, that worked.
Any chance you (or somebody else) has a list of (arcade) cores that require 50hz video mode?

No, I don't know of any. Maybe if you look at the list above and find the other cores that have similar horizontal and vertical refresh rates that might be a good start. It's some interaction between the core video timings, the video mode output timings and the constraints of the pixel clock PLL.

[morgoth]

Sounds good, thanks again Zakk4223 (and Aberu).

[akeley]

https://mister-devel.github.io/MkDocs_M ... logcompat/ - this is incomplete, but it's got a lot on there.

This list is really outdated and contains a lot of inaccurate info.

https://github.com/MiSTer-devel/Main_Mi ... patibility

[aberu]

https://mister-devel.github.io/MkDocs_M ... logcompat/ - this is incomplete, but it's got a lot on there.

This list is really outdated and contains a lot of inaccurate info.

https://github.com/MiSTer-devel/Main_Mi ... patibility

Thanks! The information comes from here:

https://github.com/MiSTer-devel/Main_Mi ... patibility

To be clear, the information is based upon what the core outputs by default. This doesn't count what can be achieved by using custom video_mode or vscale_border values in the MiSTer.ini. Given there is an external document, I'll update it with what NML32 has reported in the link you provided in that section.

I am noticing some anomalies in NML32's list. For instance, ao486 is listed as supporting RGB 15kHz. That core does not officially support 15kHz, it has to be done by using custom video_mode's which are hit or miss depending on what TV someone has and depending on the resolution of the software they are running on the core, it will look good or bad. The doc does link the MiSTer CRT Guide you've been writing, which is great, which shows how to remedy the fact that 15kHz isn't supported by it however.

It is a useful document though and I'll take a look so it will help me improve the docs.

EDIT: I checked the CRT doc you've done such a good job on writing for updates, but it only has significant updates to the custom video modelines section which I have ommitted on purpose from MkDocs as I think it's more suitable for a separate article. I try not to have each page be very long and the CRT page is already kind of too long. I've been planning on splitting some of it up.

[morgoth]

Hey yall, so the first doc linked to above specifies the following re: the Scramble core:

Scramble 20180929 240p 15.86kHz, 60.6Hz

However, the fix to my display issue was to set "video_mode=9" which maps to "1920x1080@50" aka a 50hz video mode.

Why is Scramble listed as 60.6Hz but you knew to set the display to 50Hz? What am I missing?
Thanks,

[akeley]

Thanks! The information comes from here:

https://github.com/MiSTer-devel/Main_Mi ... patibility

To be clear, the information is based upon what the core outputs by default.

Tomorrow is the second anniversary of when that list was last updated. A lot has changed since then, and some cores which were VGA-only now are 15kHz too (which also corresponds to the real hardware) without using custom video modes. Examples: Atari ST, BBC Micro, Apple II...

I am noticing some anomalies in NML32's list. For instance, ao486 is listed as supporting RGB 15kHz. That core does not officially support 15kHz, it has to be done by using custom video_mode's which are hit or miss depending on what TV someone has and depending on the resolution of the software they are running on the core, it will look good or bad.

Custom video modes aren't really "hit & miss", they have been extensively tested (at least the ones in the wiki) and should work fine in most of the user cases, baring some really unusual setups. The wiki guide also mentions the current official frequency and often has links to the assorted discussion threads where these modelines come from, and all the caveats are discussed.

NML32's list is a google doc so anybody can edit it, so you can correct the ao486 and others not having official 15kHz support if you feel like it.

[aberu]

I think you are missing my point. The analog compatibility documentation wiki page on github and mkdocs should be updated, that's something I totally agree with. But the analog compatibility wiki list tells you what the core natively outputs. Yes, you can trick MiSTer into sending a super resolution from the scaler to do pseudo-240p (15kHz), but that isn't the same thing as the core being compatible with 15kHz consumer CRT tv's. Compatibility =/= capability.

Anyways, back on topic. I really wish I could link some documentation to people without it devolving into this every single time.

Hey yall, so the first doc linked to above specifies the following re: the Scramble core:

Scramble 20180929 240p 15.86kHz, 60.6Hz

However, the fix to my display issue was to set "video_mode=9" which maps to "1920x1080@50" aka a 50hz video mode.

Why is Scramble listed as 60.6Hz but you knew to set the display to 50Hz? What am I missing?
Thanks,

Here is how you find out what the native refresh rate of the core is --> https://mister-devel.github.io/MkDocs_M ... d/console/

You can watch the debug output and watch for the video mode change. Here I fired up the Scramble core just now (note I have vsync_adjust=0 turned on here, hence why the VGA and HDMI frame times don't match, it's irrelevant to the point, check the fVert value):

Code: Select all

INFO: Video resolution: 256 x 224, fHorz = 16.0KHz, fVert = 60.6Hz, fPix = 6.14MHz
INFO: Frame time (100MHz counter): VGA = 1649999, HDMI = 1666666

This is what is meant by the core's refresh rate being 60.6Hz.

The advice to set the core to 50Hz, I don't understand the reasoning behind it, you will just see stuttering on the screen that will be worse than just running the game in vsync_adjust=0. Maybe there is some special reason that I'm unaware of.

Try running the game with vsync_adjust=1 first (which has only 1 frame of input lag on account of the scaler itself), it's a lot easier than concocting your own custom video modes using a couple calculators and a ton of trial and error. vsync_adjust=2 is sort of analogous to racing the beam and it is the least compatible vsync_adjust option. vsync_adjust=1 syncs you display to the exact refresh rate of the core, in this case 60.6Hz. vsync_adjust=2 actually runs your tv at a frequency that is slightly faster than the core's frequency typically, because it is just made for the lowest input lag possible.

If vsync_adjust=1 doesn't work, then see if you don't mind playing on vsync_adjust=0, which has 2-3 frames of input lag.

If you don't like all of these options then it's not a bad idea to explore into custom video_modes on your own using the helpful links that akeley graciously provided above.

[zakk4223]

Hey yall, so the first doc linked to above specifies the following re: the Scramble core:

Scramble 20180929 240p 15.86kHz, 60.6Hz

However, the fix to my display issue was to set "video_mode=9" which maps to "1920x1080@50" aka a 50hz video mode.

Why is Scramble listed as 60.6Hz but you knew to set the display to 50Hz? What am I missing?
Thanks,

When you use vsync_adjust=2 (low lag mode) the video mode's vertical refresh rate is semi-ignored. Your display will still run at the core native refresh (60.6Hz).

Someone with more intricate knowledge of the scaler and HDMI output would have to fill in the details here. My understanding is that it must calculate some clock value based on the input and output pixel clocks, and there are some limitations.

To quote Sorg when I opened an issue for this exact problem with Scramble:

"there are some frequencies impossible to generate according to PLL datasheet.
With vsync_adjust=2 you can use 1080p@50hz as a base - it will be adjusted to core's frame rate."

[aberu]

Hey yall, so the first doc linked to above specifies the following re: the Scramble core:

Scramble 20180929 240p 15.86kHz, 60.6Hz

However, the fix to my display issue was to set "video_mode=9" which maps to "1920x1080@50" aka a 50hz video mode.

Why is Scramble listed as 60.6Hz but you knew to set the display to 50Hz? What am I missing?
Thanks,

When you use vsync_adjust=2 (low lag mode) the video mode's vertical refresh rate is semi-ignored. Your display will still run at the core native refresh (60.6Hz).

Someone with more intricate knowledge of the scaler and HDMI output would have to fill in the details here. My understanding is that it must calculate some clock value based on the input and output pixel clocks, and there are some limitations.

To quote Sorg when I opened an issue for this exact problem with Scramble:

"there are some frequencies impossible to generate according to PLL datasheet.
With vsync_adjust=2 you can use 1080p@50hz as a base - it will be adjusted to core's frame rate."

I'll test that theory to see what scramble does:

vsync_adjust=2 @ 1080p60:

Code: Select all

INFO: Video resolution: 256 x 224, fHorz = 16.0KHz, fVert = 60.6Hz, fPix = 6.14MHz
INFO: Frame time (100MHz counter): VGA = 1649999, HDMI = 1648405

This was very unstable, note the frame time between VGA and HDMI are mismatched. Technically HDMI is running at a higher frequency than the core is because the frame time is lower. While the core is running around 60.63~Hz (it's truncated in the output), display is being told to run at 60.65~Hz in this case. This is intended and it is how vsync_adjust=2 does a psuedo-racing-the-beam effect to achieve lower lag on modern displays. However, because there is a mismatch in the refresh rate, some displays just can't achieve sync at all, so it's less compatible.

vsync_adjust=2 @ 1080p50:

Code: Select all

INFO: Video resolution: 256 x 224, fHorz = 16.0KHz, fVert = 60.6Hz, fPix = 6.14MHz
INFO: Frame time (100MHz counter): VGA = 1649999, HDMI = 1638168

Now, for some reason, the frametime is even lower (meaning it's running even faster than the previous configuration), however it's totally distorted and drawing weird lines all over my screen, because now I'm racing the beam of a 60.6hz game down to 50hz display.

https://www.youtube.com/watch?v=ERdpHOtWgWM

I don't understand why this would help, it's just confusing the scaler a lot, and sending a very messed up image. Instead, my advice would be to set it to vsync_adjust=1, which generates this output from the console connection:

Code: Select all

INFO: Video resolution: 256 x 224, fHorz = 16.0KHz, fVert = 60.6Hz, fPix = 6.14MHz
INFO: Frame time (100MHz counter): VGA = 1649999, HDMI = 1649999

Now the HDMI and VGA frametimes are identical, which will produce an identical frequency of 60.6~whatever-Hz. you get smooth scrolling (only marginally less smooth than vsync_adjust=2) and you get only 1 frame of lag.

I sorta believe that sorgelig intended the 1080p@50 mode advice he gave for something more specific, or he might've been mistaken, I'm not too sure since I don't see the context in which he said it.

EDIT: On that note, I'm noticing that the scramble core doesn't have the mathematically calculated aspect ratios so it's Vert orientation isn't wide enough over the scaler I think? Or maybe it is. I'll look at it later... too much stuff I'm doing.

[zakk4223]

https://github.com/MiSTer-devel/Arcade- ... /issues/25

It was for this exact same problem. Note I'm using a freesync display that happily drives the panel at the input rate and when video_mode 9 is used it reports the input as 60.6Hz

[aberu]

Yup, that's fair. It was advice that didn't make sense to me given what I know about vsync_adjust settings and the frequency. This means that it's tricking your screen to go even faster than 1080p60 would (given vsync_adjust=2). I wonder if the aspect ratio fixes I submitted a PR for will influence this any. Maybe not. I don't have the sync issue so I can't test whether it resolves it or not.

[akeley]

I think you are missing my point. The analog compatibility documentation wiki page on github and mkdocs should be updated, that's something I totally agree with. But the analog compatibility wiki list tells you what the core natively outputs. Yes, you can trick MiSTer into sending a super resolution from the scaler to do pseudo-240p (15kHz), but that isn't the same thing as the core being compatible with 15kHz consumer CRT tv's.
Compatibility =/= capability.

If I start a core and it displays on a CRT via standard connections (IO or DV) and without any ini tweaking from me, then the core is compatible with a 15 kHz consumer CRT TV. It's as simple as that, and that's what a page named "analogue compatibility list" should reflect. If Atari ST core natively outputs VGA 31 khz and then it somehow gets converted by MiSTer internally (but without any custom modelines, etc, which I've never mentioned) to normal 15kHz then this is of interest only to devs, not normal users. It's not even what video_info or OSD reports.

If it's really what goes on in the internals, then it might warrant a well-defined separate column, but as it is this wiki page has been a source of constant confusion for people who just want to connect to a CRT. It happened to me personally at the beginning, and I've seen it mentioned by others too. If a new user looks at it now and sees that eg Apple II is a 31kHz VGA core, they might not want to bother with trying it on their 15kHz TV (on which it will work perfectly). And if anybody wants exact values, they can simply look at the OSD anyway.

I really wish I could link some documentation to people without it devolving into this every single time.

You linked to a potentially misleading, outdated resource, and this was pointed out, as you'd certainly do yourself should it happen elsewhere. That page even gives wrong values for Scramble itself, because it refers to the 2018 core version, and if somebody'd like to find out the current ones, they're better off simply looking at the OSD anyway. And this was the sole reason for my initial comment. It had nothing to do with custom modelines (or "graciousness", for that matter, there's really no need for digs like these) which you seem to be fixated on for some reason and went off on a tangent about.

For the record, I'm not sure what your "devolving into this every single time" refers to, and I don't really want to know either, because I have zero interest in forum squabbles. I'm here strictly to learn some new things about MiSTer, and if possible to try and help some people in regard to CRT use, seeing as I've spent countless hours figuring out things which could otherwise be sorted with a simple comment. This might occasionally involve disagreeing with other people, but I neither take it nor intend personally. It's unavoidable though when it comes to complex topics.

[aberu]

Sorgelig is the one that wrote the entry for Atari ST. If it's outdated, then it needs to be fixed. It's possible he wrote it before the linedoubler was toggleable or something like that. If it were on all the time (because it was a MiST core, this might've been the case), then it would be stuck to outputting 31kHz at that time.

I think what it comes down to is... what is the core outputting natively vs what can you make it do either through OSD options or via custom video modes with scaled output? If that list isn't accurate I guess I'll fix it and validate every single result with the debug console connection and my retrotink 5x pro with all of the info it provides. I was doing other things and got down a rabbit hole yesterday.

If this list has been a constant problem like that, then it should be edited and fixed, yes.

My "graciously" ("in a courteous, kind, and pleasant manner") was actually sincere because I do appreciate the work you do and you go out of your way to help people, which is a kind thing to do. It's not a sarcastic remark at all.

That page even gives wrong values for Scramble itself, because it refers to the 2018 core version

No it doesn't, 60.6Hz is the core's native refresh rate, and the article says 60.6Hz. The core runs at 15kHz, natively, and the article says that too. That core has the scandoubler FX added which then allows you to linedouble so you can use it on a 31kHz display, sure, so there should be a column added for "Scandoubler?" and a checkmark. I can do that later. But the core's native frequency is still 60.6Hz, because the arcade hardware was, ostensibly, 60.6Hz.

If Scramble runs natively on your computer CRT without enabling the Scandoubler, then that means your CRT is fine with a 15kHz signal in some way. It doesn't mean the core is natively outputting 31kHz over the VGA port by default.

In the analog compatibility article it says the following:

Native resolutions here denote video signals generated by the core by default

I think that misunderstanding what this means might be more common than intended and I suppose I could go into more detail as well so people aren't confused again.

EDIT: I added a disclaimer to help --> https://github.com/MiSTer-devel/MkDocs_ ... 81003db440

[aberu]

@akeley - I have revised my end of the documentation entirely since the verbage "compatibility" as you have rightly been pointing out, is inaccurate.

https://mister-devel.github.io/MkDocs_M ... nativeres/

Here is a newly made table that is up to date. There are a few arcade cores I have to validate the results in, and it does not list the output of every single game in multi-game cores that have different resolutions, merely the core's native output when ran directly.