Can't understand how to get pixel perfect resolution on my Philips CM8833 CRT

[Yim]

Sounds like it’s working as intended, I guess I should look at getting it incorporated into the official core.

As an HDMI user though this kind of makes border on worse in PAL, because it reduces the amount of screen available to the active image and fills it with background colour lines, many of which would be offscreen on a CRT. I was thinking of changing the border option from off/on to off/NTSC/PAL, with the first option just showing the active image, the second filling up to 240 lines with background colour (the behaviour of the current offical core’s border), and the third going up to the full 294. That way PAL CRT users could get the more accurate image, but HDMI users would be able to run games set to PAL with borders that gave the feel of the old days without excessively filling the screen with border.

[akeley]

I was thinking of changing the border option from off/on to off/NTSC/PAL, with the first option just showing the active image, the second filling up to 240 lines with background colour (the behaviour of the current offical core’s border), and the third going up to the full 294. That way PAL CRT users could get the more accurate image, but HDMI users would be able to run games set to PAL with borders that gave the feel of the old days without excessively filling the screen with border.

Sounds like a good compromise. I think the filling with colour only happens in few games, most just leave that space black (which is why I had never spotted it when trying out the SMS core before). Still, these will also benefit from being centered better now.

[thorr]

Great stuff. One thing to check is to make sure the lightgun games still work with SNAC. Adding/removing lines may break it. I am not sure. I can test on the NTSC side, but not on the PAL side.

[Yim]

I don’t think it should make a difference to the light gun, but I have no way of testing it myself. I could maybe do a build where the ntsc picture is shifted in the same way and you could test that?

[Yim]

Great stuff. One thing to check is to make sure the lightgun games still work with SNAC. Adding/removing lines may break it. I am not sure. I can test on the NTSC side, but not on the PAL side.

OK, here's a build where the vsync has been moved 30 lines later in NTSC. It is otherwise the same as the last one I posted. This should move the image upwards in NTSC on CRT, and I've only made it for testing out whether doing that will break the light gun. Please give it a try, thorr, thanks. I'm realising now you might have meant changing the size of the border rather than moving the picture around, in which case turning the border on or off should tell you if that makes a difference.

[thorr]

OK, here's a build where the vsync has been moved 30 lines later in NTSC. It is otherwise the same as the last one I posted. This should move the image upwards in NTSC on CRT, and I've only made it for testing out whether doing that will break the light gun. Please give it a try, thorr, thanks. I'm realising now you might have meant changing the size of the border rather than moving the picture around, in which case turning the border on or off should tell you if that makes a difference.

Thanks! I have two CRT TV's that I tested with Marksman Shooting and Trap Shooting (USA) - Sony and Sharp. Turning the border on and off has no effect whatsoever on the results.

Using the regular SMS core that is provided with the update_all script, I get the following results:
20" Sony TV: I have to aim about and inch to the left of the target.
36" Sharp TV: It takes some doing to get the gunshot to start the game using the top half game, but it will start eventually. Once started, I have to aim slightly down and to the right of the target.

Using the new NTSC guntest core, I get the following results:
20" Sony TV: I still have to aim about an inch to the left. The gun is not affected. With the border turned on, the top lines show up at the bottom of the screen. There is a big black bar at the bottom, but at the very bottom, there are blue lines that are supposed to be on the top.
36" Sharp TV: I can't get the game to start using the top half game. I can start the game using the Sony TV and switch it to the Sharp. Once started, I have to aim slightly down and to the right of the target.

I was wondering why the aim was different on the two TV's. I guessed that it has to do with the distance from the TV and the screen size and I was right. Moving farther away from the TV (either one) changed where the shot was fired on the screen. The accuracy is really bad on the smaller Sony from further away. It is consistent though, so once I figure out where I need to re-aim to, I can hit the targets every time. I don't know if a real SMS behaves the same way.

Conclusion, your changes to the core don't seem to affect the gun accuracy. Moving closer or further away from the TV affects the accuracy. This may be a different core bug if a real SMS doesn't have this problem. Thanks again!

[AmintaMister]

OK, I've compiled another version with the vsync signal moved to match what's in Charles MacDonald's SMS specs when in PAL 256x192 mode. If I'm right about this, that should move the active image down to match what the actual console is putting out. I also adjusted the vertical border size to match, so it's 54 lines above and 48 below. I don't think that'll make any difference to what you see on the CRT, the extra border area should be off the top of the screen anyway. I don't have a CRT to test this out on, though, so AmintaMister if you could try it out and take some more photos I'd appreciate it.

Here's the new RBF.

Unrelated to that, I changed the vsync in PAL 256x240 mode so that it will actually occur. It took me a while to find any software that uses that mode, but I got there: the program posted in the third to last post of this forum thread (in ras.zip). Load that ROM and press button 1 once so that a number 1 is displayed on screen, and you'll have be in 256x240 mode. Could anyone with a CRT could try that in both my version of the core and the official one, both while set to PAL, and tell me if there's any difference?

Hy Yim, here it is! I think it is almost perfect because neither the original RF is perfectly centered vertically!

IMG_8899.jpeg (255.4 KiB) Viewed 4865 times

[Yim]

I'm working on making a version of this that I can submit for inclusion into the official core, but I'm suffering from mission creep. My plan is to change the border menu option from off/on to off/NTSC/PAL/216p. These options would give:

off - no border, 192 lines.
NTSC - 24 line border above and below, resulting in 240 line picture. Current behaviour when border set to on.
PAL - when TV System set to PAL, 54 line border above, 48 line border below, 294 lines total. If TV system set to NTSC, then 24 line borders. The whole NTSC picture including blanking and sync is 262 lines, so the PAL borders wouldn't fit.
216p - 12 line borders above and below, 216p total. On a 1080p TV, this would give 5x integer scaling, so you can have a clean image with the border filling to the top and bottom. This is the setting I'll use once implemented, I think.

One problem is that the SMS doesn't always use a 192 line resolution. Demos and a few commercial games run with 224 lines (or 240). The existing border option deals with this by ignoring those video modes for vertical borders, and for now I'm doing the same. It was getting too complicated. They'll run as they do now.

Another issue is the Game Gear, which runs in the middle 140 lines of the SMS's 192 lines. The logic relating to the game gear and borders in video.vhd was confusing the heck out of me, especially since there are no borders when you run a game gear game through MiSTer with borders set to on despite it looking like there should be in video.vhd. Eventually I looked at SMS.sv and realised that the signal for having borders on isn't transmitted in GG mode. It's arguably more accurate to have the borders there (GGs modified for TV out have borders), but again the code would get quite complicated and you can't see them on a real GG so I'm not putting any borders in GG mode.

[paulbnl]

216p - 12 line borders above and below, 216p total. On a 1080p TV, this would give 5x integer scaling, so you can have a clean image with the border filling to the top and bottom. This is the setting I'll use once implemented, I think.

That one isn't needed. This core already forces a crop to 216p with a 1080p resolution.

https://github.com/MiSTer-devel/SMS_MiS ... MS.sv#L193

[Yim]

Aww man, I had seen that in the code but misunderstood it. That being the case, most of what I’ve been working on is kind of unnecessary and the version I already posted was adequate.

I had vscale_mode=1 in my mister.ini, which disables 216 crop (and is made redundant by the OSD integer scaling options we have now), so I wasn’t aware of the crop being there. I saw the line paulbnl linked had 216p crop disabled if the wire “scale” had a non-zero value and assumed “scale” carried the value of the scaling options in the OSD (which I don’t want to do without), but it’s actually where the scandoubler setting is held.

Ah well. That’s kind of killed my motivation for the moment, but at least I’d enjoyed the pointless work I was doing on it. I’d been looking at how I’d have to adjust the aspect ratio for different border sizes and realised the aspect ratio doesn’t change in PAL mode like it does on real hardware and was thinking of implementing that, but that would probably not be a popular change anyway.

[thorr]

Will your latest version that fixes the centering on PAL be incorporated into the main updates?

[Yim]

Not yet. For it to get in, I have to put the code up on GitHub, make a pull request, and get it accepted, none of which I’ve done yet. I’m looking at the aspect ratios - at the moment it uses 32:21 for SMS, or 47:35 with the border on. If I’m changing the size of the border I should change the aspect ratio too, and now that I know about the 216p mode that changes the aspect ratio too, plus there’s no game gear specific aspect ratio. I can put all that in, it’s just a matter of finding the time.

[Yim]

My pull request has been merged, so next time the core gets updated it should have bigger borders in PAL mode and the image at the right height on CRT. I didn’t wind up fiddling with the aspect ratio for HDMI, kept it simple for now.

[mark_eire]

Hi all. Hopefully forum etiquette doesn't mind the old post reply, but this topic is exactly what I've been looking for after some experimentation the last few days.

Reading all the great work in this thread, and the update from Yim.
Has the border change discussed in this post been rolled back in some time since? I don't see the improvements as in this forum post. I've got MiSTer borders that are not extending far enough at the top and bottom of the screen. (The slight image shift between is my TVs RGB response).

If anyone else can double check my findings. I'm comparing:

• PAL SMS console (Master System II), via RF on Irish/UK consumer TV

• MiSTer connected via RGB SCART cable, same TV
  • MiSTer all updated to current Main and Cores as of 2nd April 2022
  • TV System = PAL
  • Border = Yes

MasterSystem_PAL_Hardware.JPG (38.72 KiB) Viewed 3568 times

MasterSystem_PAL_MiSTer.JPG (34.54 KiB) Viewed 3568 times

[aberu]

For some reason the regression happened with 20210930. On HDMI the output is incorrect as well, the border makes no difference. I think Yim's changes actually cropped the output instead of moved it. Not sure why.

[mark_eire]

I'm still testing now. I've been linked the "SMS_20210926.rbf" (before your noted date of 20210930).
I believe that should have the fix, but on my CRT the border is exactly the same.

The image is shifted up, which I believe was a known issue in that version which was then fixed. But it is very odd. I've yet to find a core version with the fix working from back then. Unfortunately, the links to test cores in this thread no longer work.

I'm in touch with birdybro who is kindly looking into the issue for me. I'll report back with any update

[akeley]

Hmm...I'm not sure - seems to be working ok for me (core v220326).

IMG-20220403-203232.jpg (5.2 MiB) Viewed 3205 times

IMG-20220403-203142.jpg (4.34 MiB) Viewed 3205 times

You can try my mister.ini (for CRT with Direct Video)

[mark_eire]

Hi there. Here is my Sonic 1 for comparison.

Main difference may well be that I am using SCART onto a consumer CRT with an Analogue IO Board.

MiSTer_PAL_Sonic1.jpg (23.9 KiB) Viewed 3490 times

Interesting to see the difference there. Have you checked the HDMI output? It also appears broken, seems to be handled similar to my TV. I've no idea why your border is so different, but I'll pass it along. This seems a strange output between HDMI, RGB SCART, your Direct Video.

EDIT: akeley, are you using PAL just to be sure too? Maybe another difference

[akeley]

Definitely PAL + Border = Yes.

Connecting to HDMI is a bit of a hassle here, so I didn't try that. My photos are from Direct Video into a PVM's BNC inputs. If it's still a problem tomorrow I can check on my SCART consumer set and/or HDMI.

[mark_eire]

Interesting. If you could try SCART and/or HDMI that would be nice just to verify if nothing else. I can't imagine why you'd have different results on that front, but it certainly is odd.

I did compare our INI files. Other than not using Direct Video, I couldn't see anything obviously different.

I'm not aware of anyone else actively using SMS with Direct Video, so if there is an update you might be a good test case for the RBF. RGB SCART from the Analogue IO board definitely needs a fix. HDMI aspect ratio is another topic.
It would be good to confirm any updates to fix those things has no unintended adverse effect on the Direct Video results you can get already.

Thanks

[mark_eire]

Another update to the puzzle.

Below are 2 images, both from MiSTer on my consumer CRT via RGB SCART from Analogue IO Board.

One change to my INI. direct_video=1

• Left; Border = No

• Right; Border = Yes

DirectVideoOn_PAL_SMS_Border.png (385.94 KiB) Viewed 3447 times

Despite the fact that I am not actually using the Direct Video signal (HDMI TV is very unhappy), somehow, that setting effects the Analogue output too. I've notified birdybro so he's aware of the response.
Very odd behaviour to my mind.

For your sake akeley, less need to test your setup on CRT or HDMI I suppose. The "direct_video" INI setting appears to give correct borders from both it's output port, and fix the CRT view (via Analogue IO).

The issues remain for Analogue IO and HDMI output if direct_video=0 it seems

[aberu]

Yup, confirmed. Direct video as a setting makes the PAL SMS border draw correctly in both a direct video adapter and on the analog io board. Super bizarre. I haven't seen the Direct video toggle change output for the analog IO board before...

[akeley]

That really is odd. I didn't even suspect direct_video can affect the I/O at all...

[paulbnl]

It is not so odd. This core forces cropping to 216p when the output resolution is 1920x1080. This cropping also affects the analog output. (Analog being affected by 216p happens on all cores. Something which should be improved)

If you enable Direct video then the resolution is changed so cropping is disabled.