Chameleon Core update 9k released

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.

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.

Quote from Tobias

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.

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!

Quote from Dr.OG

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

Quote from Jens

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.

Quote from robinsonb5

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?

Quote from Jens

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.

Quote from Dr.OG

[...]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.

Quote from Jens

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.

Quote from Jens

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.

Quote from Jens

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

Quote from robinsonb5

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.

Quote from Dr.OG

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.

Quote from Jens

...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.