User feedback and experiences

[c0pperdragon]

Please let the community know about your experiences when building/installing/using this mod.

[c0pperdragon]

Great job for RGB color space compatibility. Unluckily, I do not have hardware to test any flavor of RGB. If olliraa can do that, whis would be great.

I guess now there is only one missing piece in the puzzle: Disabling the sync signal to create "pure" RGB by the mod. This could be easily done by setting bit 15 of the color register 0. Hojo-Norem, is there a chance that you could also implement this as a kind of toggle button in your program?

With this it would then be possible to solder up a SCART adapter cable that combines the audio and luma (for sync) signal from the original A/V connector with the RGB signals from the mod. With this any SCART based setup can be driven.

By the way: Series production of the component mod should happen very soon now. I guess there will be much more interest for your color mixer program as soon as the hardware gets readily available.

[desaster]

Only problem is that I don't have any hardware that takes sync-on-green. So while the RGsB output looks like it's working (as in, it isn't crashing ^_^) I have no way of verifying the colours that are being output.

I just tested RGsB output with a PVM, and it seems to be working well. The colors look very much like the standard s-video output. Although the monkey in donkey kong seems much hairier with the roughness of the s-video output ;)

RGsB	S-Video

Disclaimer: Color reproduction in these photographs is not very good, and they don't look that different to each other in real life. (EDIT: adjusted white balance)

[Hojo-Norem]

is there a chance that you could also implement this as a kind of toggle button in your program?

Shouldn't take too long. I'll just add it as an extra option to the video output mode setting: YPbPr-RGsB-RGBns (no sync).

I just tested RGsB output with a PVM, and it seems to be working well. The colors look very much like the standard s-video output. Although the monkey in donkey kong seems much hairier with the roughness of the s-video output ;)

Nice! I was worried that it wouldn't look anywhere near correct. With this any minor differences can be tuned to the user's preference in the editor.

[Hojo-Norem]

Aaaand done. While I can test regular RGB, I haven't made the adapter to do so for this particular case yet. I can confirm that the sync signal does turn off when the switch is moved over to SDTV mode. As I've implemented it as it's own 'video mode', the setting gets saved with the rest of the palette data and is identified when the palette is loaded stand-alone. I've also added a RGBns variant of the default on the main menu.

[olliraa]

Only problem is that I don't have any hardware that takes sync-on-green. So while the RGsB output looks like it's working (as in, it isn't crashing ^_^) I have no way of verifying the colours that are being output.

I just tested RGsB output with a PVM, and it seems to be working well. The colors look very much like the standard s-video output. Although the monkey in donkey kong seems much hairier with the roughness of the s-video output ;)

RGsB S-Video Disclaimer: Color reproduction in these photographs is not very good, and they don't look that different to each other in real life. (EDIT: adjusted white balance)

Awesome, now I really need to flash the latest 2.6 fw. :) Only experience on old Xilinx cpld:s, but I guess with the free Quartus software (and a cheap usb blaster) it should,be pretty simple.

[olliraa]

Could someone please tell me the right "tick-boxes" when flashing fw with Quartus Prime Programmer?

Thanks! I'm kinda hesitant regarding the flashing :)

[c0pperdragon]

When flashing the 2.6 firmware, you need to write both the actual "program" (CFM0) as well as the configuration data (UFM) as the format for storing the palette information has changed. Just check all boxes for Program/Configure, Verify, Blank-Check.

I don't even know that the other columns (examine, security bit, erase, ISP CLAMP) are good for. I never use those.

In case of future firmware release, you could omit reflashing the UFM area so you would not lose your current palette settings (UFM = User Flash Memory).

[olliraa]

When flashing the 2.6 firmware, you need to write both the actual "program" (CFM0) as well as the configuration data (UFM) as the format for storing the palette information has changed. Just check all boxes for Program/Configure, Verify, Blank-Check.

I don't even know that the other columns (examine, security bit, erase, ISP CLAMP) are good for. I never use those.

In case of future firmware release, you could omit reflashing the UFM area so you would not lose your current palette settings (UFM = User Flash Memory).

Cool, thank you soo much :D Will flash (the fw ;) tonigh!

[olliraa]

Just flashed the latest fw and tried the latest palette editor. I changed the palette to RGsB (which the Sony BVM accepts), but I get a heavy green tint on the image, so something is not correct... Is there something obvious I'm missing here? I can change the color mode to RGB or YUV and sync as INT or EXT. This is really simple and has worked perfectly with all kinds of setups. With RGB and INT sync selected I get the green tint, and with EXT naturally nothing, because I've not (yet) tried with the external sync from the A/V port of C64. With YUV I get close to correct colors, kinda same as with the default YPrPb without changing the palette.

Any tips? :)

[desaster]

but I get a heavy green tint on the image

If your BVM/PVM is set to RGB, and your image looks green, then probably your C64 is outputting YPbPr.

When you change the video output mode in the Palette editor with V, does the screen colors actually change?

[olliraa]

but I get a heavy green tint on the image

If your BVM/PVM is set to RGB, and your image looks green, then probably your C64 is outputting YPbPr.

When you change the video output mode in the Palette editor with V, does the screen colors actually change?

Solved! For some reason, it seems the palette did not change on the first time, although it said so and I toggled the video mode to RGsB. Now everything is more than great! Superb image quality! Thank you all who's involved in this sorcery :D

[Hojo-Norem]

For some reason, it seems the palette did not change on the first time

I'm guessing that you selected the RGB default palette first and then enter the editor? Yeah, that would make it behave how you described.

I've just put out v1.15. Now if you apply a default palette then the respective video mode will carry properly into the editor. Also I've defined proper RGB values for the GUI elements in the editor so they still look somewhat the same between YPbPr and RGB modes.

Also, embarrassingly, I broke the colour mixing on the previous version. Each alternate line of mixed colour was just black. Just as embarrassingly it took me a while to track it down... but I did and now it's fixed.

I just wish I was any good at pixeling, or I'd be able to to a better job then the current excuse of a test image I have.

EDIT: If you flashed a palette (not a default) with v1.1 then you'll need to re-do it with v1.15 to re-calculate the missing colours.

[pazuzu72]

I would like to build this board myself but I did not understand if by setting the output to RGB I can connect a Commodore 1084, taking the synchronism from the AV output. Who can clarify this topic?

[c0pperdragon]

Yes, the mod can be configured to output not its standard YPbPr signal, but "pure" RGB on its signal output, using Hojo-Norem's awesome configuration software (a program to run on the C64 that gives you a proper user interface to do this).

As the color information is not enough to drive a monitor, a seperate sync signal is needed. The original A/V port produces its usual set of signals: composite, luma, chhroma. Both composite and luma carry a sync signal along and either can be used to synchrionize an analog monitor.

This whole sync issue is quite a deep toppic, and I recommend to have a look at https://www.youtube.com/watch?v=LAlrdCBjUAQ&list=PLTNBVisVMbSR1ZDDQRgjg6S9D2YQ4rwnZ&index=5&t=318s for a good introduction.

[c0pperdragon]

I did a bit of research, an it seems not all Commodore 1084 are made equal in this respect. If you have one with a SCART input this should directly accept the a composite or luma signal to use for sync. Other models seem not be able to directly use this kind of sync information, but would need a "pure" csync.

There are some resources on the web how to retro-fit a SCART input into 1084 which does not have one. Other possibilities are to use an external converter.

[pazuzu72]

If I remember correctly, I connected an SNES in RGB using composite video as synchronism. I have to check.

[pazuzu72]

I've just checked. SNES RGB + Composite Video on CSync on Commodore 1084S-D2. It works.

I think the C64 should work too.

[antongale]

picture

47pF did the trick. It still 'wobbles' for a few seconds on initial power up, but it is all OK after that.

[pazuzu72]

I have mounted the card in my C64, I am using the A-VideoBoard version. When connected to an LCD TV with YPrPb input it does not work. If instead I use the test firmware that generates the pattern, everything is ok. If I use a CRT monitor (RGB with Sync taken from the composite video) it shows (C64) but obviously with a predominance of green as I cannot set the RGB output in any way using the special program for C64. Where am I wrong?

[Hojo-Norem]

Just to be clear, you built A-Videoboard and not RFreplacement? Does A-Videoboard have a mode select switch? If not then my guess is:

1a: I'm not sure but perhaps the A-Videoboard defaults to 240p output, which some LCD TVs dont like being fed into their component video inputs. The mode select switch allows you to switch the line doubler on and solves this issue. c0pperdragon should be able to correct me if I'm wrong here.

1b: I could be wrong about this, but perhaps the test firmware has the line doubler locked on. That could be why you had success there.

2: The palette registers are locked until the mode select switch is toggled, as per the instructions on the main page and as requested by the first screen on the palette editor. Without a mode select switch the registers can not be unlocked and the palette editor will not function correctly.

[pazuzu72]

Exactly A-Videoboard. That's what the indication was in your program, I didn't understand it. I could solder a switch on the GPIO2 connector since there are connections to pins 39 and 40 of the FPGA.

[pazuzu72]

2: The palette registers are locked until the mode select switch is toggled, as per the instructions on the main page and as requested by the first screen on the palette editor. Without a mode select switch the registers can not be unlocked and the palette editor will not function correctly.

Awesome. It works. Thank you very much. There is a mess it's all on the fly but for now it's okay.

[c0pperdragon]

My congratulations! The images look really pretty good on your CRT. This now also confirms that the color palette program is able to make color fo the "pure" RGB mode (very good work, Hojo-Norem!). And also that taking sync from the A/V is indeed a viable option.

Also Hojo-Norems guesses about the behaviour of the test-firmware and the actual firmware were spot-on.

Anyway, I need to open a new feedback thread now, as this one is really getting much too long...