mist-devel / mist-board

Core sources and tools for the MIST board
445 stars 81 forks source link

global settings #163

Open jotego opened 6 months ago

jotego commented 6 months ago

I offer a CRT H/V offset setting on MiSTer. I originally did not offer it on MiST because the status word is shared with the dip switch configuration, whereas they are independent on MiSTer. However, even the MiSTer solution has a drop back: you have to set it manually for each game and save your settings.

That is fine if you have a problem with a core, but you may have a TV set that is permanently shifted to one side of the screen because of component ageing. In that case, a global offset would be better.

I wonder if, as it happens with the scan doubler and other video configurations, an offset setting could go in the ini file and made known to the core. What JTFRAME supports is a 4-bit signed number for each H/V offset, which helps users center the screen.

What do you think?

gyurco commented 6 months ago

Basically it would be another status word, just not coming from the core OSD, but the ini file (or a system OSD)? It's doable actually, not sure if it is super useful.

jotego commented 6 months ago

A smaller change, only thinking of video options, would be to expand but_sw a few bits. It already covers the video configuration:

assign scandoubler_disable = but_sw[4];
assign ypbpr = but_sw[5];
assign no_csync = but_sw[6];

We could add

assign crt_hoffset = but_sw[ 8+:4];
assign crt_voffset = but_sw[12+:4];

Then the ini file would look like:

crt_hoffset = 0   ; a number between -16 and +15
crt_voffset = 0

I do not know how many people are affected. I am, at least, as my TV set is permanently shifted to the left. I also know that CRT adjustment is a big deal for MiSTer users as about half of them use CRT.

gyurco commented 6 months ago

The problem with but_sw that the current user_io only handles a single byte - extra bytes have to be added with a different SPI command anyway, otherwise it'll break existing cores. I'll look at how it would be handled the best way.

jotego commented 6 months ago

Transferring the data as a ROM with a different IOCTL index would be fine too from the point of view of JTFRAME, it might even be more portable. It could be added as extra bytes to the "core_mod" byte that currently sets whether the game uses vertical video.

Just thinking out loud...