Chameleon Core update 9o released

Caution: Non registered users only see threads and messages in the currently selected language, which is determined by their browser. Please create an account and log in to see all content by default. This is a limitation of the forum software.


Also users that are not logged in can not create new threads. This is a, unfortunately needed, counter measure against spam. Please create an account and log in to start new threads.

Don't Panic. Please wash hands.
  • The scandoubled signal _IS_ the 720x576 mode. Its not magically twice the amount of horizontal Pixels. The number of lines is doubled, no more no less.

    Quote

    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

    You gotta translate this into the settings for the Indivision


    this is how it works:

    Code
    1. Modeline "800x600x50.20" 31.423594 800 824 904 1008 600 604 608 621 -HSync +VSync
    2. pixel freq: 31.423594Mhz
    3. v front porch: 824-800=24 h front porch: 604-600=4
    4. v sync: 904-824=80 h sync: 608-604=4
    5. v back porch: 1008-904=104 h back porch: 621-608=13


    and then, since this mode is 49,something Hz and not 50,2Hz as we need, you gotta tweak the settings accordingly, perhaps remove some lines until the vertical frequency is 50.2Hz

  • Also note 720x576 is not a standard Mode, even less so at 50Hz or even with VIC sync enabled. This *will* not work on some (or even most) Monitors.

    Standard or not, i'm realy happy that you have added this mode! On my IIyama syncmaster the image is absolute perfect with vsync on.

    Since its a new mode the screen uses automatic adjust, and no need for any manual adjustment :).

  • 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)

    Interesting - I wasn't sure it was right because the way the border counting works in the core makes it a bit tricky to figure out exactly where the pulses fall.


    The need for a higher framerate is why you reduced vtotal from 625, yes?


    The 576p broadcast video standard - which ultimately is what we're imitating here - is defined in ITU-R Rec 1358-1 - albeit not in a form that can be copied-and-pasted into a modeline. If I'm reading it right, what it defines amounts to:

    modeline "576p" 27.69 720 741 806 886 576 581 586 625


    (Again, I guess you could reduce the 625 to increase the vertical frequency, and trust in the VIC Sync to increase it again.)


    But I will measure exactly what the Minimig core generates.

  • Again, I guess you could reduce the 625 to increase the vertical frequency, and trust in the VIC Sync to increase it again.

    Not sure if this is a fundamental problem of understanding, or if you just used the wrong words and meant the right thing. Just to be clear: Our VIC-Sync feature NEVER increases the vertical frequency - it will increase the line count, thus reducing vertical frequency. This is where the requirement of "just under 50.2Hz" comes from.


    Chameleon has a fundamental difference to most (if not all) cores: It uses a full frame buffer instead of just a line doubler. This enables us to connect literally any VGA moditor and feed it the signal that it requires. If it comes to V-Sync, we therefore have to resort to this "adapting number of lines", which will confuse some monitors, even if they can normally display 50Hz. A straight copy of a modeline is therefore not possible, as the fundamental design had a goal to NOT lock-step the output pixel clock and the emulated computer's pixel clock.


    The same is true for Indivision ECS V2: Here, the fundamental design goal was to decouple input and output pixel clock. Yes, it results in tearing in some cases, but it makes 100% of the monitors usable, and that was the primary goal: Future-proof the output. If in 20 years nobody remembers that 50Hz-compatible monitors even existed, you just set a "safe" VGA mode and you'll be able to see a picture, provided the future device still has a VGA-like input.


    If it comes to V-Sync, we need the adaptive line count to have the two V-Sync signals toggle "about the same time". Not all monitors are compatible with this, which is why we have added the possibility to lock the input- and output pixel clocks on Indivision AGA MK3 ("auto resolution" feature). Unfortunately, this is not an option for Indivision ECS V2 or Chameleon, as the reference clocks are so slow that no PLL of an FPGA will safely lock to them (AGA conveniently has the 28MHz pixel clock signal on the Lisa chip).


    Jens

  • Not sure if this is a fundamental problem of understanding, or if you just used the wrong words and meant the right thing. Just to be clear: Our VIC-Sync feature NEVER increases the vertical frequency - it will increase the line count, thus reducing vertical frequency. This is where the requirement of "just under 50.2Hz" comes from

    Yes, thanks - I worded that ambiguously, but when I said "increase it again" I was referring to the total number of lines, not the frequency.


    If I'm understanding the sync feature correctly, then one could begin with the "ideal" modeline which will have 625 lines, remove a couple of lines from the front porch to increase the vertical frequency, and then the VIC-Sync logic would put them back again when it delays the sync pulse? (With the occasional extra line - or perhaps missing line - due to phase drift effects.)

  • If I'm understanding the sync feature correctly, then one could begin with the "ideal" modeline which will have 625 lines, remove a couple of lines from the front porch to increase the vertical frequency, and then the VIC-Sync logic would put them back again when it delays the sync pulse?

    Sort of. Since you don't want the output to overtake the input, there should be a delay of at least one line on the output side (which will not add any measurable lag), otherwise the framebuffer that's going to be displayed will be "one frame older", putting tearing back into the output.

    (With the occasional extra line - or perhaps missing line - due to phase drift effects.)

    We never take a line away - only add one. A screen must be "as complete as possible", otherwise monitors get confused. We found that a single line difference is the most compatible version - if you allow two lines, you are losing lots of monitors. So the mode line must be tweaked to be really close to, but still faster than the original screen, so there is never a build-up of more than one line difference during one frame. As Tobias wrote, it's tedious tweaking, but the outcome is really worth it.

  • I experimented with 720x576@50Hz Vsync (not 1472x576) on my Indivision ECS V2. I get the same problem like in the past when I was playing around with this resolution, I get vertical bars which I cannot tweak away with the pixelclock setting or phase on my monitor and the picture will not fill the screen (by fill I mean the overscan areas does not fill the screen) like with my 1472x576@50Hz profile, which also shows a perfect pattern on the test screen with no vertical bars.


    I'm quite suprised I cannot replicate the the 50Hz 720x576 mode the ECS V1 is using. In my case the only way I can replicate it with good results on my BenQ BL702As and BL912 is the 1472x576@50Hz option where I divide the 1472 by two. Or options near that resolution. Which gives an even clearer 720x576@50Hz than my ECS V1 in 50Hz mode.


    If my less than satisfactory 720x576@50Hz results on my ECS V2 could be interesting for the further development of the TC64/TC64V2 screen mode problem then I will go take pictures of my 720x576@50Hz profile and post here.


    With all that said, the 720x576@50Hz for TC64V2 is working really good for me. Problem is it will switch to other resolutions after coldboot. I can replicate that with the ECS V2. Usually the fix is to step the pixelclock a few notches up for the monitor to lock on the desired resolution and not be unreliable in the sense it's sometimes switching to other resolutions like 640x480 or 1080i. Which is what's happening on the TC64 V2 with that particular 720x576@50Hz profile


    Another funny thing I noticed. Been experimenting with the minimig core when in cartridge mode. Which is so cool because the real C64 keyboard works with the Amiga core. And the joystick port. But for mouse I need PS2. Really awesome and practical. But in the Amiga core I tweaked the pixel and phaseclocks for my monitor for the best results. When I then tried the 720x576@50Hz mode on the C64 core It switched to the same monitor profile. However, the pixelclock/phase tweaking I did for the Amiga core did not fit the C64 core. lol. Anyway, for now I use the 768x576@50Hz profile for the C64 core. Which I believe switches my BenQs to 1024x576.

  • I'm quite suprised I cannot replicate the the 50Hz 720x576 mode the ECS V1 is using.

    That's because Indivision ECS V1 uses an external PLL that is in sync with the Amiga clock. However, that 50Hz mode is not synced to the vertical beam of the Amiga at all, and you still get tearing in some cases. It's just that the pixel clock is lock-stepped, and there is no attempt to synchonize the vertical beams of VGA output and host computer. This is a HUGE difference to a vertically-synced approach.


    In my case the only way I can replicate it with good results on my BenQ BL702As and BL912 is the 1472x576@50Hz option where I divide the 1472 by two. Or options near that resolution.

    Try un-ticking the "Vsync" box and you'll find that most of what you're setting in the Indivision ECS V2 tool will be fine for your monitor.

    Usually the fix is to step the pixelclock a few notches up for the monitor to lock on the desired resolution and not be unreliable in the sense it's sometimes switching to other resolutions like 640x480 or 1080i. Which is what's happening on the TC64 V2 with that particular 720x576@50Hz profile

    This is a clear sign at the monitor not supporting this output mode. You're tricking it into going to your desired mode by deviating from the pixelclock that allows VSync to work, and when it has caught that, you're going back down to where VSync works. What more do you need to accept that it's "off the edge" with your monitor? The feature description clearly says that not all monitors support V-Syncing and 50Hz. Yours doesn't support it. There's no point in believing it would do anything different if you're trying the same thing over and over again.

  • That's because Indivision ECS V1 uses an external PLL that is in sync with the Amiga clock. However, that 50Hz mode is not synced to the vertical beam of the Amiga at all, and you still get tearing in some cases. It's just that the pixel clock is lock-stepped, and there is no attempt to synchonize the vertical beams of VGA output and host computer. This is a HUGE difference to a vertically-synced approach.


    Try un-ticking the "Vsync" box and you'll find that most of what you're setting in the Indivision ECS V2 tool will be fine for your monitor.

    This is a clear sign at the monitor not supporting this output mode. You're tricking it into going to your desired mode by deviating from the pixelclock that allows VSync to work, and when it has caught that, you're going back down to where VSync works. What more do you need to accept that it's "off the edge" with your monitor? The feature description clearly says that not all monitors support V-Syncing and 50Hz. Yours doesn't support it. There's no point in believing it would do anything different if you're trying the same thing over and over again.

    BenQ BL702A and BL912 does not support vsync at 50Hz? Of course they do. They work just fine with vsync at 50Hz. Either via ECS V2, TC64 VIC II sync on or directly connected to Amiga RGB.

  • BenQ BL702A and BL912 does not support vsync at 50Hz? Of course they do.

    I do not doubt that. It's just that they freak out if they don't always get the same number of lines per VBlank. We've tried getting rid of the extra black lines they insert at the bottom when this syncing method is active, but were not successful.


    That's the fundamentals that we've tried to bring across with all the extensive postings in this thread. If you didn't get that, then, well, I can't do anything more.

  • I do not doubt that. It's just that they freak out if they don't always get the same number of lines per VBlank. We've tried getting rid of the extra black lines they insert at the bottom when this syncing method is active, but were not successful.


    That's the fundamentals that we've tried to bring across with all the extensive postings in this thread. If you didn't get that, then, well, I can't do anything more.

    What I did get is that the TC64/TC64 V2 C64 core works differently due to the VIC II syncing part VS other cores and so on. I'm not complaining. 768x576@50Hz and VIC II sync on works just fine on these monitors. Also my 1472 (736) x 576@50Hz Vsync on works perfectly (monitor will stay at 720x576 at coldboot) for the ECS V2 with these monitors. Even the new 720x576@50Hz profile for TC64/TC64 V2 works just fine until I do a coldboot I have to enable another screen resolution then back again to 720x576@50Hz to get these monitors to switch to 720x576@50Hz.

  • Marking as "resolved", as there is nothing new - we're running around in circles.

    I believe I get the same problem when I turn off Vic II sync with regards to the new 720x576 profile. At least at 50Hz. But if it's impossible to adjust it due to how your C64 core works then it's not the end of the world. The whole reason I started this discussion was because 720x576@50Hz vsync works stable with other cores on my BenQ monitors. But as you guys are saying, your C64 core works differently due to the VIC II sync thing.

  • Did some testing.


    720x576@50Hz VIC II sync ON = Usually when I switch to this from another resolution the screen will switch to 720x576@50Hz. At coldboot it switches to 640x480@50Hz. And sometimes 1080i. Never goes back to 720x576@50Hz unless I select another resolution and then back again to this resolution. But then same thing on every coldboot, where it defaults to 640x480@50Hz or sometimes 1080i.


    720x576@50Hz VIC II sync OFF = So far I have only seen 640x480@50Hz with this one. Even when I select it before coldboot. For every coldboot I see 640x480@50Hz.


    720x576@60Hz VIC II sync ON = monitor switches to 832x624@50Hz and will stick to that resolution on the coldboots I tested.


    720x576@60Hz VIC II sync OFF = Monitor defaults to 1024x576@60Hz and does not change from my testing thus far.


    720x576@72Hz VIC II sync OFF = Monitor defaults to 640x480@72Hz. VIC II sync on did not work for this setting.



    Note: As mentioned before, with minimig core and C16 core my BenQ BL702a and BL912 sticks to 720x576@50Hz.

  • It would mean that the monitor measurement is 20% off. Might be an indicator that something is wrong with that monitor. We have the 702 as well - quite a few of them. The difficulties you're describing are completely new.

  • It would mean that the monitor measurement is 20% off. Might be an indicator that something is wrong with that monitor. We have the 702 as well - quite a few of them. The difficulties you're describing are completely new.

    Well, I can double check with my two BL702As. This specific test was done with my BL912. From experience the BL702A and BL912 behaves exactly the same with regards to resolutions and pixelclock. I have done alot of tweaking with my ECS V2 on these monitors. But I can double check

  • The last reply was more than 365 days ago, this thread is most likely obsolete. It is recommended to create a new thread instead.