Chameleon Core update 9o released

very nice. My benq bl912 switched to 720x576@50hz and the picture fills the screen with the correct aspect ratio

issue. More often than not my monitor will switch to 640x480 than 720x576. I have to change the resolution then go back to 720x576@50hz several times before it switches to 720x576. And after a coldboot i have to do the same thing. I had this issue with my ecs v2. Had to do adjustments for it to always switch to the correct resolution.

Edit: it's all over the place. Sometimes it switches to 1080i when using 720x576@50hz. You could take a look at my profile for ecs v2 in the ecs v2 ghosting thread. I managed to make a stable 720x576@50hz profile which will not switch to other resolutions like 1080i or 640x480. But i had that issue until i tweaked my profile. So it should be possible on the tc64 v2 aswell

Quote from turrican9

Had to do adjustments for it to always switch to the correct resolution.

What kind of adjustments are that?

Quote from turrican9

it's all over the place. Sometimes it switches to 1080i when using 720x576@50hz.

You would think that it's "just a matter of counting lines" to get to the right screen mode. However, our method of achieving sync with the vertical blank of the host computer is to delay the vertical blank of the VGA output by one line if the difference is beyond that. This is true for both Chameleon and Indivision ECS V2. I can totally imagine that really bad firmware in a monitor will confuse this with an interlaced signal (as consecutive frames have a one-line difference), but the keyword here is "really bad firmware", as 1080i can never have 576 valid lines in one frame.

So the question goes back to what I asked above: What kind of adjustments did you do in order to keep this erratic switching from happening? We may be able to do the same in Chameleon, if it's not too specific for your ill-fated monitor.

720x576@50Hz is used to manipulate pal on modern screens. Even if monitors do not switch to 720x576@50Hz, like my BenQs can do, you will often get the correct aspect ratio anyway for old PAL systems. It also takes into account the full overscan area.

Here is my ECS V2 profile:

You are writing about 720x576, yet your screenshot shows 1472 pixel wide screen - showing 736 pixels of the up to 768 pixel wide Amiga-screen. Also, the back porch value is not readable on that screenshot - your mouse pointer covers it.

Divided by two it's 736. This takes into account the full overscan. If i go just a tiny bit up or down with the pixelclocks then i get the problem that the monitor switches to other resolutions at coldboot. I may manage to change the horizontal to lets say 1470 and keep it stable. I could experiment more if you want

Quote from turrican9

Divided by two it's 736. This takes into account the full overscan. If i go just a tiny bit up or down with the pixelclocks then i get the problem that the monitor switches to other resolutions at coldboot. I may manage to change the horizontal to lets say 1470 and keep it stable. I could experiment more if you want

You can probably reduce it to 1440 and put the extra 32 clocks into the front porch instead without upsetting anything.

Likewise, if you halve all the horizontal values as well as the pixel clock you should, in theory, end up with a true 720x576 mode that has exactly the same timings. If you can get that working stably, then you'll have useful settings for other people to refer to.

Halfing it is a no go with the ecs v2. Bad results. However, 1440 could be doable. It takes very little to upset the clocks.

For reference. My current profile will give the exact same picture aspect ratio wise and size wise as the minimig core for tc64 v2, ecs v1 50hz profile and if i plug my monitors directly to the rgb. So i know i've hit 'the spot'.

Edit: why not use the minimig core as reference? It gives me a stable 720x576@50hz picture that will not switch to other resolutions at coldboot. I believe the c16 core for the tc64 could also be used for reference

Quote from Tobias

you should absolutely be able to reproduce it with the indivision

He's probably running twice the output pixels in order to take advantage of the built-in scaler. The ECS V2 scaler performs much better if the output resolution is high.

Quote from Jens

You are writing about 720x576, yet your screenshot shows 1472 pixel wide screen - showing 736 pixels of the up to 768 pixel wide Amiga-screen. Also, the back porch value is not readable on that screenshot - your mouse pointer covers it.

The talk about 720x576@50Hz is about the resolution the monitor runs at. Which is desired in this case. The Amigas screen may be 768 pixels but 1472/736 will show the exact same overscan area as if I plug the screen directly to my RGB port, TC64 V2 minimig core or ECS V1 50Hz mode. Exact same picture both overscan wise and size wise. And in all cases my monitor switches to 720x576@50Hz appart from the RGB 15KHz it will switch to 576i. If I go much over 736/1472 I cannot make it work anyway. In fact, I don't think I can go over that at all.

Quote from Tobias

i wonder what the exact setup for those cores is (didnt i ask it before, i cant find it now...) robinsonb5 do you know? couldnt find it with a quick look at the sources (and i cant read verilog at all...)

I don't know off the top of my head, but I can measure them.

The thing to understand about those cores is that they're not doing any kind of scan conversion or smart scaling - they're simply scandoubling the PAL 288p or NTSC 240p TV-compatible signal. And the scandoubler *really* means it when it says double. Each row is sampled, then emitted again at double the pixel clock - pixel data, sync pulse, porches and everything.

So from a modeline perspective, the horizontal parameters wouldn't change, while the pixel clock and vertical parameters would all double, compared with vanilla 240 or 288p.

Technically the back porch would be reduced by 1 (doubled to 2) and the front porch increased by 1 (2) due to the buffer delay.
(Also I believe serration pulses are only inserted when the scandoubler's disabled.)

In last month's update thread I did post what I believe is a modeline matching the C16 core -

Modeline "720x576x50" 28.38 720 732 798 912 576 580 586 624 -HSync -VSync

Since 625 is the number of lines in a complete PAL frame, I suspect it's important for VTotal to be as close to that as possible.

Quote from Tobias

In the first place it matters what the video producing device puts out - what your monitor detects and how it displays something comes second (and might be just wrong, or just match by chance). Hence the question what these 1472 pixels are about. To me it looks like you have basically created a 1440x576 mode, which for some reason your monitor detects at 720x576.

Ah yes, i remember this. And i remember i tried this and it did NOT work with my monitor - showing pretty much the symptoms turrican9 is describing with his now It doesnt seem to be 100% right though - because the C16 core works fine here. Also, we have another "problem" with Chameleon - the 50Hz modes have to be slightly faster than 50Hz (actually faster than 50.125Hz), else the "VIC-Sync" will not work (Thats why all the other 50Hz modes are actually 50.2Hz)

But I divide it in two (look picture). Also, Jens is correct.

Quote from Jens

He's probably running twice the output pixels in order to take advantage of the built-in scaler. The ECS V2 scaler performs much better if the output resolution is high.

If I half the VGA mode to 736 I get really bad results. However, I half 1472 to 736 by using the adjustment in the tool.

Quote from Tobias

You need to create a 720x576 mode *for the monitor*. all the messing around with the scaler is pointless for what we are trying to find out here.

That is out of the question. Horrible results. Instead, look more closely at the C16, minimig core or even the ECS V1 50Hz mode which simply scandoubles the standard 240p/288p singnals. Like robinsonb5 explained