Feature Request all cores: Horizontal and vertical CRT adjustment.

lencio commented 3 years ago

Horizontal and vertical adjustment in all cores (CRT). As a CRT user, I have problems in many cores with horizontal or vertical adjustment on different TVs. In some (Sony Trinitron, Phillips, etc.) the cores appear off-center and it is impossible to see everything on their site without resorting to the TV service menu, which in many cases implies having to open the television. Could something similar to what Jotego does be implemented in its arcades? We also have this option in Minimig (Adjust screen position). We are many mister users who suffer this problem in silence. Thanks!

Sir-BLaDE commented 3 years ago

We need that feature, just like in the cores of Jotego, CRT users would appreciate it

osito45 commented 3 years ago

it would be fabulous

gutxihaitz commented 3 years ago

That would be very helpful. I have this very same problem and my CRT TV doesn't have any method to adjust vertically or horizontally. I hope this could be implemented some day. Finger crossed. Thanks a lot for the work behind MiSTer anyway.

sromeroi commented 3 years ago

I'm quite interested in this feature. Jotego's Arcade cores allow to center properly the image on my TV, but consoles and computer cores are not centered and it's quite anoying.

Note: problem happening in both my Sony Trinitron 14" and SANYO 14" CRT TVs.

pplatoon commented 3 years ago

I agree with Lencio's comment, it should be something essential, please take the comments into account and execute the work for everyone, thank you very much

carew14 commented 3 years ago

It wold be very useful!!

shaeon commented 3 years ago

It's must!

james20duros commented 3 years ago

This would make our gaming experiencie nicer

titorin0 commented 3 years ago

Please this option is very necessary, for those of us who use crt it is vital. thanks in advance

Urotsukidoji commented 3 years ago

I agree with everyone. I use a CRT TV and this feature would be so useful (I love to reminisce the 8 bit computer experience at its maximum level). Greetings!

dcrespo3d commented 3 years ago

Unfortunately my Sanyo CRT TV is very off centered, and this feature would be very convenient. I would love to be able to perform horizontal and vertical adjustment on a per-core basis

Crtlovergaddem commented 3 years ago

Hello, I have had the opportunity to use this great MISTer fpga project, very happy with everything it offers but there is a detail in the visual section, on crt screens I see that it is used more than I imagined and that is that all the console cores Except for neo geo they start loaded to the left which is solved in the arcade cores by scrolling the image, my request is if you can implement this for all cores thank you very much

luixyto commented 3 years ago

I join the request

it is something very very useful

Botvinnik92 commented 3 years ago

I think this would be a great addon to the MiSTer framework, as most cores (Arcade, Consoles or Computers) look off-centered when viewed in a CRT display

frdarko commented 3 years ago

As a CRT user, I fully agree with this feature request. We need horizontal and vertical adjustments for each core.

dangonzilla commented 3 years ago

It would be great! I join the request.

sorgelig commented 3 years ago

It was already explained many many times. Console and computer cores are made with video timings supposed to be original, unlike arcade cores made for special non-TV hardware (and there fore may provide incorrect TV signal). So there won't be such option there. If some core supposedly output wrong (not like original HW) TV signal then open issue on that core, so it will be fixed.

lencio commented 3 years ago

It was already explained many many times. Console and computer cores are made with video timings supposed to be original, unlike arcade cores made for special non-TV hardware (and there fore may provide incorrect TV signal). So there won't be such option there. If some core supposedly output wrong (not like original HW) TV signal then open issue on that core, so it will be fixed.

This off-center image problem occurs to me in the vast majority of cores that I usually use, c64, atariXL, MSX, Minimig ... In some, the outer edge disappears completely, such as MSX and ao486. With real machines, it does not happen to me, I usually use real Commodore 64 and atari 800Xl. Neither does the Ultimate64. Do you prefer an issue in each core? Wouldn't it be easier to implement a geometry control in framework? Thanks once again for your quick response.

Greetings!

sorgelig commented 3 years ago

Yes, correcting video centering according to real HW is correct way to solve. btw, Minimig has its own video positioning settings due to variable resolution so this issue is not applicable to Minimig. ao486 requires vga_scaler=0 for CRT output, so position is up to used video resolution in INI file.

lencio commented 3 years ago

Yes, correcting video centering according to real HW is correct way to solve. btw, Minimig has its own video positioning settings due to variable resolution so this issue is not applicable to Minimig. ao486 requires vga_scaler=0 for CRT output, so position is up to used video resolution in INI file.

The problem is that depending on the CRT in which you connect the Mister, sometimes it is 50 pixels to the left, other times 100, and other times something to the right. Hence the suggestion of adding an option to the general H / W adjustment framework in CRT. Normally, I hardly use arcades, I always talk about microcomputer cores.

Thanks once again for replying!

tacertain commented 3 years ago

Wouldn't it be easier to implement a geometry control in framework?

Just to answer this one question, the answer is "no." Analog video output is driven by the FPGA gates in the cores. It's not like in modern computers where you have a graphics chip that has a frame buffer and then dedicated hardware to turn the frame buffer into video scan lines.

To expand on this, the timing of what scan line you're on and what should be output is all controlled by gates in the core. These modules take the clock and output the correct video signal at that point in time. It's not just the pixels, though - the hardware sends out the blanking controls as well - every clock cycle the hardware needs to be sending out the right analog signal to the VGA output. For example, here's a description of the Atari 2600 Television Interface Adapter (TIA): http://atarihq.com/danb/files/TIA_HW_Notes.txt

Even if you just scan through it, you can see all the tables for what's happening at each clock cycle - the clock cycles where colors are being drawn are controlled by the FPGA-implemented version of the TIA in MiSTer. Other cores have completely different implementations for how these signals are generated. There's no possible way to have a generic mechanism that would move the position of the displayed pixels relative to the blanking signals. In the cores that have it, they are implemented with understanding of how the video is being produced and how to modify timing within the core.

So it's not a matter of not being willing to spend the time to do it. I think it's clear that if it were possible, it would be advantageous. But it's just not possible with analog out.

Andrew

lencio commented 3 years ago

Thanks for reply. You explained clearly, but….. Why all Jotego’s cores can do it?

tacertain commented 3 years ago

Because he built it into them. Just like the hi-score saving and pause capability that @JimmyStones has been adding to arcade cores, there's a common framework that can often be used to implement the sync adjustment, but it still needs to be added into the individual cores - it can't just be added in a generic way that will work on unmodified cores. I'd be happy to look into adding them into particular cores. People can file feature requests on the individual cores, link them to this issue and I'll see what I can do. I've only been working on arcade cores, however, which are all pretty simple relative to the console/computer cores, so it may be beyond my skill level to do the cores you want.

Maybe that's what you intended all along. I (and I think others) interpreted the request as something to add to Main_MiSTer that would do it for all cores automatically. That's what's not possible. Most cores should be able to accommodate video shifting - it's just work in each individual core, not in Main_MiSTer.

Andrew

paulb-nl commented 3 years ago

@tacertain It is much easier than you think. For analog output the only thing that's needed is to output H/Vsync earlier or later to offset the image on CRT. Jotego uses a general module in jtframe that does this for all his cores. I helped him to add interlace support and duplicate the original core H/Vsync lengths instead of hardcoded sync lengths.

lencio commented 3 years ago

@tacertain It is much easier than you think. For analog output the only thing that's needed is to output H/Vsync earlier or later to offset the image on CRT. Jotego uses a general module in jtframe that does this for all his cores. I helped him to add interlace support and duplicate the original core H/Vsync lengths instead of hardcoded sync lengths.

It is something that happens to most people, I already said it at the beginning, the original machines come out perfectly centered, it is the FPGA that does not appear in its place on the same TV. There are people for whom the image comes out without the left edge, or on the contrary, the right edge, etc. It is something that I do not understand why nobody wants to do it, and yet it is possible, as in the Jotego cores.

tacertain commented 3 years ago

But it still has to be done per core, right? There's no magic here?

On Fri, Nov 12, 2021, 11:11 AM paulb-nl @.***> wrote:

@tacertain https://github.com/tacertain It is much easier than you think. For analog output the only thing that's needed is to output H/Vsync earlier or later to offset the image on CRT. Jotego uses a general module in jtframe that does this for all his cores. I helped him to add interlace support and duplicate the original core H/Vsync lengths instead of hardcoded sync lengths.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MiSTer-devel/Main_MiSTer/issues/477#issuecomment-967352243, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMVRYKDLMIWFR2G32MBRLLULVRELANCNFSM5HBJO5PA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

lencio commented 3 years ago

But it still has to be done per core, right? There's no magic here? …

It is essential to add this option either in the general framework or in each core, it is a reality that the FPGA does not show the image where it should in many cases, and real machines do.

tacertain commented 3 years ago

I'm not sure what you're trying to say. I've looked at the modules in Jotego's cores. I understand the basics of how it works and was starting to add it to Bagman, since that's the core in most familiar with. As I wrote before, I'm willing to try to add it to other cores, but it's going to be work for every core. Maybe not a ton of work, but for each one you need to make changes, build, test, etc.

As for whether it's essential or not, I dunno. You could do it. I'm doing this for fun in my free time. If there are cores that people would really like to see this added, I'm willing to give it a try. But there are lots of people who thumbed up this issue who could do it as well.

Finally, the actual hardware, such as a C64, uses analog circuitry for the video output, while MiSTer is mimicking the functionality with digital logic. I'm not sure that's what's going on here, but it doesn't surprise me that it's not as tolerant as the original hardware (especially since the electrical engineers building the thing knew that it had to "just work" out of the box for most TVs).

So, as I offered before, if you want to create GitHub issues for cores that you would like to see me try and add this to, please do so and link them to this issue. If you want to debate why somebody should do something that will work for all cores, be my guest, and I'll go back to amusing myself with the arcade cores.

On Fri, Nov 12, 2021, 11:25 AM lencio @.***> wrote:

But it still has to be done per core, right? There's no magic here? … <#m_2324298607147083075m-7261852893969277751_>

It is essential to add this option either in the general framework or in each core, it is a reality that the FPGA does not show the image where it should in many cases, and real machines do.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MiSTer-devel/Main_MiSTer/issues/477#issuecomment-967378046, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMVRYIPHFPSUFPP3INMWNLULVSZNANCNFSM5HBJO5PA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

lencio commented 3 years ago

I'm not sure what you're trying to say. I've looked at the modules in Jotego's cores. I understand the basics of how it works and was starting to add it to Bagman, since that's the core in most familiar with. As I wrote before, I'm willing to try to add it to other cores, but it's going to be work for every core. Maybe not a ton of work, but for each one you need to make changes, build, test, etc. As for whether it's essential or not, I dunno. You could do it. I'm doing this for fun in my free time. If there are cores that people would really like to see this added, I'm willing to give it a try. But there are lots of people who thumbed up this issue who could do it as well. Finally, the actual hardware, such as a C64, uses analog circuitry for the video output, while MiSTer is mimicking the functionality with digital logic. I'm not sure that's what's going on here, but it doesn't surprise me that it's not as tolerant as the original hardware (especially since the electrical engineers building the thing knew that it had to "just work" out of the box for most TVs). So, as I offered before, if you want to create GitHub issues for cores that you would like to see me try and add this to, please do so and link them to this issue. If you want to debate why somebody should do something that will work for all cores, be my guest, and I'll go back to amusing myself with the arcade cores.

Thank you for your effort and dedication, I unfortunately do not have the knowledge to be able to make changes in the different cores, but I offer myself to try everything you need. If you need me to test any change you make in the core that you tell me, I can test it on different TVs. Thank you very much for responding, once again.

tacertain commented 3 years ago

If somebody creates an issue in a particular core that needs this functionality and links it here, I will give it a go.

tacertain commented 3 years ago

@paulb-nl, if you'd be willing to spare me 15 minutes of your time, I have a few questions about the module. If you're willing, can you hit me up on the MiSTer FPGA Discord? My username there is the same as here. If you're not on the Discord, lemme know and I'll suggest another mechanism. I appreciate it and promise to document all I learn for future learners!

paulb-nl commented 3 years ago

You can contact me by pm on the MiSTer forums. (paulbnl)

tacertain commented 3 years ago

Unfortunately, I don't have priviledges enough to make a PM on the forums. I generated a PR here that seems like it should do nothing, but it destroys the video sync. If you have any insight, I'm sure I'm just doing something dumb.

https://github.com/tacertain/Arcade-Bagman_MiSTer/pull/1

tacertain commented 3 years ago

I was able to get resync working on a couple of cores, so I have some confidence that I can make it work elsewhere. But I'm not going to make more changes until I get some issues created. There are a bazillion cores and I would rather spend my time doing things that are going to be used. So if you would like video repositioning added to your favorite core, please make an issue and link it here.

Cheers!

noemiabril commented 3 years ago

very useful

lencio commented 3 years ago

I was able to get resync working on a couple of cores, so I have some confidence that I can make it work elsewhere. But I'm not going to make more changes until I get some issues created. There are a bazillion cores and I would rather spend my time doing things that are going to be used. So if you would like video repositioning added to your favorite core, please make an issue and link it here.

Cheers!

EDITED: Add ZX Next issue, Amstrad, ZX-Spectrum issue

Crtlovergaddem commented 3 years ago

maybe the approach is the most used consoles like nes snes genesis turbografix and computers those that have been mentioned would be a highly valued job

sorgelig commented 3 years ago

As i've mentioned above if core doesn't match real HW video position then it needs to be corrected. Not "Add H/V adjusting"!

lencio commented 3 years ago

As i've mentioned above if core doesn't match real HW video position then it needs to be corrected. Not "Add H/V adjusting"!

Where is the problem in adding this functionality? It is well known that depending on the CRT TV, the image may come out somewhat off-center, depending on the brand, tube, etc. Tacertain has already shown that it is not so difficult to add that small improvement in any core (AtariXL), and it is something that would substantially improve the use of the Mister with CRT. Each TV is a different world, and in most cases the service menu is not accessible, which means opening the TV and touching knobs to center the image. That later in another core it can appear in another side. Is it really so laborious and arduous to implement? Is it necessary to create a different fork that divides the users? In any case, I appreciate the attention and the time you are taking to respond.

sorgelig commented 3 years ago

Do you adjust TV position when you switch between TV channels?

lencio commented 3 years ago

Do you adjust TV position when you switch between TV channels?

No, because all the channels appear centered, they are Mister's cores, which in some cases that I have mentioned come out off-center.

tacertain commented 3 years ago

I don't really care one way or the other, but before I waste more time doing things that you won't accept, can you help me understand what are acceptable ahistorical modifications and what aren't? Like should all the scan doublers for analog video be taken out of the computer and console cores?

Thanks.

james20duros commented 3 years ago

Honestly, I do not understand the reason to censor something that can make the game experience much more pleasant, and that on the other hand, has the purpose of correcting something that affects precisely those of us who want to get closer to the original experience using a CRT. On the other hand, you can accelerate the fx chip in super nintendo, use scandoubler, scanline filters, RGB output in turbografx, savestates in nes, etc ... not to mention that this project is oriented to use hdmi and usb ports for the controls. What is right and what is wrong if the purpose of this project it's the accuracy and fidelity?

lencio commented 3 years ago

I do not think it is a question of looking for what is right and wrong. It is a fact that it is a necessary adjustment, if you want to give some support to users who prefer CRT, just as HDMI users are supported. We can have both worlds in our wonderful FPGA.

tacertain commented 3 years ago

OK, everybody. Sorry for kicking the hornet's nest. I've frustrated a bunch of folks and I apologize. @lencio can you please close all those issues you opened? I'd do it but I don't have permissions.

My guess is that there's a different root cause for each of these consoles, like NTSC vs PAL or not doing interlacing correctly or something.

tacertain commented 3 years ago

@lencio Somebody in the discord suggested the issue might be the way you're getting RGBHV into your CRT, since presumably it doesn't have native RGBHV input, but needs a combined sync signal somewhere, while the actual consoles combined this signal internally.

tacertain commented 3 years ago

Lemme just write a bit longer explanation for everybody. I don't expect it will satisfy everybody, but maybe it'll help some. Part of the issue is that while MiSTer produces analog out and CRTs take analog in, that's only the tip of the iceberg. MiSTer produces 5 analog video signals, Red, Green, Blue, H-sync, and V-sync (using 5 independent signals is referred to as RGBHV). VGA monitors take in these signals directly, and most modern multi-sync flat panels can adjust to a wide range of sync frequencies and pixel counts.

However, while retro computers, arcade games, and consoles generate all five of these signals, most don't expose RGBHV directly, and old TVs certainly did not accept RGBHV, so some conversion has to happen. If you are playing on an Atari 800, for example, the plug at the back has three signal wires, one for luma, one for chroma, and one for composite video. Now these signals can be brought out by cable that simply passes the correct wires through to an RCA or S-video connector for a TV. The composition of the raw RBGHV signals into composite or luma/chroma video was done with some analog circuitry, and the Atari 800's is particularly bad. (https://www.mathyvannisselroy.nl/Super%20Video%20XL%20XE%20plus%20errata.pdf)

But now if you are running the Atari 800 core in MiSTer, MiSTer can output the RGBHV signals directly, or RGBs (which combines the two sync signals together), or YPbPr, which puts the sync signal on the Y (luma) wire. Now you need to hook this up to something. If you are using a computer monitor, you are probably golden, for two reasons. The computer monitor can probably accept RGBHV directly, so you're done. But if you're trying to hook it up to a TV, you have more work to do. Depending on what choices you make for either modding the TV or using a mod cable, you have the potential to change the interpretation of the sync signals, which will move the picture.

So if you are running MiSTer through a mod cable and into a modded TV, instead of running raw RGBHV, and your sync is off, what should happen? I understand that the solution proposed here and what I implemented is to add an option to the core to shift the sync signal, allowing you to position the image where you want. It seemed like a reasonable request and I made it. However, I understand the opposite perspective that the MiSTer cores shouldn't have a bunch of configuration parameters in them to compensate for issues introduced by hooking the MiSTer up to hardware that doesn't conform to expectations.

I've been involved in lots of software projects that ground to a halt because of too many "why don't we just add this one simple extra thing." While it seems like a simple addition, everything has combinatorial cost to maintain. For consoles, I understand the reasoning that the MiSTer RGBHV output should match the internal RGBHV output and it's the responsibility of the user to connect that to their video device, since all those consoles were made for standard TV formats. I also understand why for the arcade cores, a practical concession was made given that each arcade game was made for a particular monitor setup, which may not be replicable today. The computer cores seem somewhere in the middle, since many of them had modes that run on standard equipment and other modes that only worked with proprietary hardware.

Anyway, this is a long way of saying that I understand why Sorg has drawn the line where he has. Were I maintaining it, I might draw the line in a different place, but I might not. One thing I've learned over my career is the wisdom of the Chesterton's fence analogy, which says that not understanding why a decision was made is not an argument that it was made incorrectly. Sorg has a much broader understanding of all the pressures that impact MiSTer, and while I think it's fine to suggest other ways to do it, I don't think it's reasonable to say, "I don't understand why you don't want to do this thing, so I think you are making a mistake by not giving it to me."

sromeroi commented 3 years ago

Sorry to get into the conversation...

In my setup, It's quite annoying getting to the SONY Trinitron cryptic service menu each time I switch to a core and found it a bit off-screen. I'm continuosly adjusting the TV geometry when I change cores except when I use Jotego's cores where I can adjust them with a few UI steps (and I wouldn't need to readjust them at any moment if every core included this feature and I could just "Save Config" on them).

Implementing this for typical consoles and computers would fox for me literally tens of thousands of games...

It would solve a problem that exists, is there, and affects people that use this awesomely device with CRT TVs.

Anyway, thanks for your efforts on this platform and for this discussion, it's also interesting to read and learn about video signals and sync. I hope you're reach some agreement and we could enjoy the cores without losing a part of the image in some side of the screen.

To be honest, I don't care about fancy menus, game screenshots or videos or other "front-end" or typical "emulator" stuff (well, I would love to have snapshots, I cannot end a game in a single session being and adult) but playing the game full screen with no issues is fundamental to me...

Thanks

lencio commented 3 years ago

OK, everybody. Sorry for kicking the hornet's nest. I've frustrated a bunch of folks and I apologize. @lencio can you please close all those issues you opened? I'd do it but I don't have permissions.

My guess is that there's a different root cause for each of these consoles, like NTSC vs PAL or not doing interlacing correctly or something.

Okay. I am going to close them at your request, at no time did I intend to cause controversy. Thank you for trying to fix the problem.

tacertain commented 3 years ago

It would solve a problem that exists, is there, and affects people that use this awesomely device with CRT TVs.

First, we need to separate the issue of consoles from computers. Taking consoles, all of the console cores if properly implemented should replicate the console timings, and the consoles all generated correct timings for whatever TV system they were made for (NTSC, PAL, etc). Serg's point above about "does the image shift when you change the channel" is that each TV station is sending sync timings independently, but they all correctly center the picture (e.g. you don't need to recenter for each station). Same with DVD players, physical consoles, etc. If the generated timings meet the standard, the images will be centered. So the core should be generating the correct timings to center the picture.

Now, it's possible that the timing in the core is wrong, that is, it doesn't generate the same timing signals as the original core. If this is the case, the core should be fixed. This would manifest as the image for that core being shifted even though all other cores display correctly.

However, it's also possible that the way the timings are being transmitted from the MiSTer to the TV are wrong. There are three ways this can happen: One, you modded your TV, so you're not using an input that was on the original device, and that mod is pulling sync from the wrong place or distorting the sync. Two, you're using SCART or component in that is built into the TV, but the VGA adapter cable is wired wrong. Three, you have the wrong settings in your MiSTer (not setting csync or SoG correctly). So if all the console cores are shifted, I would look there.

Computers are a completely different story. In the early days (Apple ][, Timex Sinclair, VIC-20), they were designed to be hooked up to a TV, and mostly met the timing standards of whatever region they were made for. However, as the demand for higher resolutions grew, computer manufactures built video systems that were non-standard. For example, the Atari ST had a 640x400 monochrome resolution that no TV could display - you needed a special computer monitor. Before VESA, computer monitor resolutions and timings were all bespoke and there's no real reason that you should expect them to work on a TV.

And even for those that were intended to work with a TV, the care and attention put into the video output was not as good as the consoles. So it's possible that even if the timings correctly reproduce the original timings that the signal will not work well on some TVs.

tl;dr - if there is a particular console core that is not centered while all others are, there's some reason to believe that the console timings are not correct. Feel free to contact me on discord and I will see what I can discover. If all the consoles are uncentered or they all behave differently, you should check your setup. For computers, I dunno.

MiSTer-devel / Main_MiSTer

Feature Request all cores: Horizontal and vertical CRT adjustment. #477