Chameleon Core update 9k 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.
  • Yes, we are serious about it - Chameleon will get monthly updates from now on - and we are doing big steps approaching the final non beta release. This one fixes long standing VICII bugs that results in almost all "real world" testcases to work 100%. In particular those are:

    ... and likely more that suffered from the same timing bug.


    As this is a fundamental fix that removes almost all misbehaving programs from our list, we'd like to encourage Chameleon owners to report anything that is still wrong after the update. Please check the wiki to see which issues we already know about.


    Please also head over to the Chameleon C64 Core - Compatible Monitors thread and report back your success (hopefully) with using the new VGA controller with your monitor(s).


    The changes in detail:


    Code
    1. - Merge incomming system reset with local reset, so CPU is held in reset while external reset is pending.
    2. - Fix in scaler for the scale factor 1.5x only used by 640x480, that caused pixels to be lost reducing the picture quality.
    3. - Fix in VIC-II emulation, changes to D011 yscroll value to preform DMA delay effects were one cycle off.
    4. - Fix in VIC-II emulation, changed the architecture of the internal 40 character buffer to match observed addressbus bahavior during DMA delays.


    As usual get the update on the Chameleon wiki page.


    Have fun!

  • Tobias

    Approved the thread.
  • Thanks for the good news Tobias. I have to admit that I had to rub my eyes first when I read about the monthly updates. ;-)


    The Turbo Chameleon would do very well to finally reach the final status after the long years of the beta phase. In any case, I'm already looking forward to the final version of the firmware. :-)


    Cheers
    SID-6581


    P.S: I offer you to help with testing within the scope of my possibilities.

  • Right now the best help we can get is reports about misbehaving Games/Demos. Preferably single-filers with obvious bugs right after starting, so we dont have to sit through minutes of game/demo for a test :)

  • Great, that every month a update come out. Have update it to 9k the letters are good but only the K is not good (640x480 60Hz). You see it (64K) on the C64 Basic screen F3 option.


    The REU demo Treu Love / Booze Design works now perfect with 9i it stops.

    https://csdb.dk/release/?id=144105


    Shall test the best C64 Games and Demos if it works or not on the BenQ BL702A VGA monitor. Setup C64 Reloaded MK2, iComp 12V DC 2.0A with the TC64 V1.



    A1200 GHOST Rev2B RECAP TSB 2020 / CA-PSU / Indivision AGA MK3 / Blizzard 1230 IV

    A1200 CD32 Rev1D.4 RECAP TSB 2019 / CA-PSU / Indivision AGA MK3 / ACA1234-50
    A1200 BLACK Rev2B RECAP TSB 2018 / CA-PSU / Indivision AGA MK3 /
    Blizzard 1230 IV

    A1200 TRANSLUCENT Rev1D.4 RECAP TSB 2018 /
    CA-PSU / Indivision AGA MK2CR / ACA1233-55 LE
    A500 BLACK Rev6A / CA-PSU / ACE2 / Indivision ECS V1-V2 / ACA500Plus V1-V2 / ACA1221 Rev1.3 / ACA1233n-55

    C64R MK1-MK2 TRANSPARENT 2015 DM / iComp 12V 2.0A / TC64 V1

    Edited once, last by JohanSSID ().

  • I still wonder why you dont use the native resolution of your monitor (or at least 800x600) - that would certainly look better :)

    Look worse with 800x600 and the 1280x1024 60Hz. Great for the Indivision ECS V2 and the Indivision AGA MK3. Had lot of problems with the Indivision ECS V1 and the AGA MK2CR. The BenQ BL702A monitor is great but not so great as the BenQ BL912. The BenQ BL912 is now rare and expensive, The 640x480 60Hz is the only best resolution for the TC64 V1. Normally I connect it on the TV but the C64R MK2 gives bad picture on it with Composiet or S-Video. Had a old Commodore 1702 monitor which was the C64R MK2 razor sharp but it’s now dead. The Ultimate 64 Elite looks great with HDMI on the TV.

    A1200 GHOST Rev2B RECAP TSB 2020 / CA-PSU / Indivision AGA MK3 / Blizzard 1230 IV

    A1200 CD32 Rev1D.4 RECAP TSB 2019 / CA-PSU / Indivision AGA MK3 / ACA1234-50
    A1200 BLACK Rev2B RECAP TSB 2018 / CA-PSU / Indivision AGA MK3 /
    Blizzard 1230 IV

    A1200 TRANSLUCENT Rev1D.4 RECAP TSB 2018 /
    CA-PSU / Indivision AGA MK2CR / ACA1233-55 LE
    A500 BLACK Rev6A / CA-PSU / ACE2 / Indivision ECS V1-V2 / ACA500Plus V1-V2 / ACA1221 Rev1.3 / ACA1233n-55

    C64R MK1-MK2 TRANSPARENT 2015 DM / iComp 12V 2.0A / TC64 V1

  • Hi!


    I tested the latest firmware (ß9k) with my TC64v1, and it improved the VGA compatibility with my Samsung LE40B650 TV significantly! Thank you for your effort. Some ghosting/shadowing are present at higher resolutions (screenshot attached), but overall image quality is far better than the original C64 over composite out.


    As you (we) are near out of beta stage, it would be avesome if an 50i PAL mode would be added to the output options. Unfortunately my TV does not support 50Hz over VGA, but has a SCART input, which is useful if I want to run the cores on the native resolution of the original HW (576i). This option is present in the minimig core, as well as in case of most other cores available on V1 hardware (PC Engine, MSX, ZX Spectrum, Atari 800). I have a minimig VGA2SCART cable already,


    Thanks in advance: Gábor!

  • it would be avesome if an 50i PAL mode would be added

    I fear that this won't be possible. 50i would mean that we'd "invent" the other half frame, which happens to be the long frame (313 instead of 312 lines that the C64 normally shows). While in theory you'd "only" need to generate a pixel clock that is slightly faster, the exact calculation (divide by 312, times 312.5 or 0.16%) involves numbers that are so close together that I'm pretty sure that the PLLs of the Cyclone FPGA can't generate that.


    If you think about "faking" this by halting the whole C64 for one line in every other frame, you'll end up with sound hickups and possibly jerky movement.


    It's the first time I'm trying to wrap my head around this, and pwsoft may come up with a better idea. I believe it may be possible with cascaded PLLs if the chip has the amount of resources. This is hardly the case for Chameleon (the chip is so full that we're struggling to meet timing on every compile), but the idea is good and will go on the "nice to have list" for the C64 Reloaded MK3 and possibly other products.

  • Thanks for your reply! I didn't think that's so complicated, I assumed that should be more trivial, as other cores already implemented this years ago, but I was obviously wrong.


    Cheers: Gábor

  • I fear that this won't be possible. 50i would mean that we'd "invent" the other half frame, which happens to be the long frame (313 instead of 312 lines that the C64 normally shows). While in theory you'd "only" need to generate a pixel clock that is slightly faster, the exact calculation (divide by 312, times 312.5 or 0.16%) involves numbers that are so close together that I'm pretty sure that the PLLs of the Cyclone FPGA can't generate that

    The other cores don't bother generating long frames (except Minimig if interlace mode is enabled) - they simply repeatedly generate short frames (which of course is what the real hardware does, too) creating a kind of 288p mode which nearly all 576i-capable devices seem to be happy with. It shouldn't (!) be much more complicated than halving the pixel clock, and producing the correct serration on the sync pulses.


    Edit: oh yeah, and the 15KHz modes use composite sync, too.

  • Sounds like it's easy enough to add if 288p or 312p is what TVs accept as 50i.


    Edit: oh yeah, and the 15KHz modes use composite sync, too.

    Composite sync for interlacing involves adding pre- and post-sync equalization pulses, keeping the falling HSync edges aligned and making the TV aware of the half frame that's coming. Possible, but requires additional logic, as a simple XOR of HSync and VSync won't cut it.


    Is there a standard about which pin the TV expects the CSync signal? Is that on HSync or on VSync? Or both?

  • Sounds like it's easy enough to add if 288p or 312p is what TVs accept as 50i.


    Composite sync for interlacing involves adding pre- and post-sync equalization pulses, keeping the falling HSync edges aligned and making the TV aware of the half frame that's coming. Possible, but requires additional logic, as a simple XOR of HSync and VSync won't cut it.


    Is there a standard about which pin the TV expects the CSync signal? Is that on HSync or on VSync? Or both?

    CSync ends up on the VGA connector's HSync pin, and VSync is held high. I'm not 100% certain but I believe the Minimig -> SCART cable maps the VSync pin to the SCART connector's blanking pin, which tells the TV to expect an RGB signal (when high) rather than a composite signal (when low).

  • Caution: Scart does not always work with logic levels. If a signal is pulled up to 12V, Chameleon might break. You should double-triple-check this before you connect such a cable. I remember that Amiga->Scart cables needed a bunch of resistor dividers in order to generate proper voltages, and they used the 12V output on the DB23 of the Amiga for that as well.


    I won't promise that this will make it into Chameleon for two reasons:


    1) logic space is really tight, and this will not only need additional counters for generating CSync, but also additional logic for a few config bits, so the menu system can switch the feature on/off. It may be plain impossible to fit this.


    2) it's an added feature, never advertised before. Granted, it seems useful, but the mere fact that it took ten years for the idea to surface, it may not be all that necessary - at least not for the majority of Chameleon users in the field.

  • I don’t get the appeal of interlaced video modes, apart from the native interlaced Amiga modes naturally. Modern TVs usually add high latency with interlaced signals and you’ll get combing artifacts or blurred pixels with moving images.

    [...]my TV does not support 50Hz over VGA, but has a SCART input, which is useful if I want to run the cores on the native resolution of the original HW (576i). This option is present in the minimig core, as well as in case of most other cores available on V1 hardware (PC Engine, MSX, ZX Spectrum, Atari 800). I have a minimig VGA2SCART cable already,

    Are you sure these cores output 576i and not 288p(Amiga interlace being the exception) and your TV is misinterpreting the 288p signal as 576i?

    As I see it, there are two problems:

    1. VGA being incompatible with 50Hz

    2. Scart on modern TVs not handling 288p signals correctly.

    Both leave me unsatisfied.

  • 2) it's an added feature, never advertised before. Granted, it seems useful, but the mere fact that it took ten years for the idea to surface, it may not be all that necessary - at least not for the majority of Chameleon users in the field.

    I don’t see much benefit in it, as long as you aren’t going to use a 15khz crt, or the lower frequency would promise a better picture(free of ghosting effects) an feeding the signal afterwards into a scan doubler like the ossc to get a proper digital image.

  • Caution: Scart does not always work with logic levels. If a signal is pulled up to 12V, Chameleon might break. You should double-triple-check this before you connect such a cable. I remember that Amiga->Scart cables needed a bunch of resistor dividers in order to generate proper voltages, and they used the 12V output on the DB23 of the Amiga for that as well.

    Indeed. The voltate on the pin in question should be between 1v and 3v, and the video source (Amiga, Minimig or Chameleon) is reponsible for generating that. You're clamped the same way as the original Minimig board that the cable's designed for, so it should be safe.

    1) logic space is really tight, and this will not only need additional counters for generating CSync, but also additional logic for a few config bits, so the menu system can switch the feature on/off. It may be plain impossible to fit this.


    2) it's an added feature, never advertised before. Granted, it seems useful, but the mere fact that it took ten years for the idea to surface, it may not be all that necessary - at least not for the majority of Chameleon users in the field.

    Understood, and fair enough - the other cores only support it because their various upstream projects already have it.

  • Actually the main benefit of 576i/288p signals is improved compatibility with older TVs/monitors which often have an RGB-compatible SCART input. 576p@50Hz was never VGA standard AFAIK. I assume robinsonb5 is right and the signal would be 288p instead of 576i. And yes, CSync is on VGA pin #13 (HSync), and pin #14 (VSync) goes to SCART pin #16 (RGB switch). The latter expects 1-3V (nominal 2,5V).

    The minimig-VGA2SCART cable is "de facto" standard since more than a decade (schematic attached), and mine works perfectly with other cores and FPGAs since years without any issues. Mixing HSync and VSync shouldn't be so difficult as there are very simple schematics with only one logical IC, using some XOR gates. I built both of them to merge H and VSyncs to CSync in real world (not FPGA) to use my C128's RGBI out with standard SCART TV, both works perfecly (4070 and 7486 ICs, see attachments).

  • The voltate on the pin in question should be between 1v and 3v,

    ...so a VGA->Scart cable would require pin#9 to really be wired to 5V, which it isn't on Chameleon for safety reasons. One more reason to move this feature to a different product.

  • Mixing HSync and VSync shouldn't be so difficult as there are very simple schematics with only one logical IC, using some XOR gates. I built both of them to merge H and VSyncs to CSync in real world (not FPGA) to use my C128's RGBI out with standard SCART TV, both works perfecly (4070 and 7486 ICs, see attachments).

    It's not just a case of generating CSync - TVs use a more complex sync pattern in the VBlank region which tells the TV whether to expect a short or long frame next. You can't generate that using simple logic gates. Combining H and V sync onto a single pin is a separate issue, which the circuit you posted does indeed solve - but that much is also trivial to do within the FPGA.

  • ...so a VGA->Scart cable would require pin#9 to really be wired to 5V, which it isn't on Chameleon for safety reasons. One more reason to move this feature to a different product.

    The cable avoids this by driving the VSync pin high, and feeding that to the blanking (RGB select) signal. Ugly hack? Absolutely. It appears to work in practice, however.

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