User feedback and experiences

[c0pperdragon]

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

[RobeeeJay]

Installed this today on a PAL 64C with short board and 8565R2 VIC chip. It worked first time, is really nicely built and the picture is absolutely amazing when fed through an OSSC. The image is quite saturated for a C64 though, perhaps I can fix this with an OSSC setting.

There are probably three things which weren't entirely clear to me in the instructions, I'll list them here:

1. Which way up the headers go, I guessed at long pin up otherwise I think they'd poke out too much on the underside of the motherboard but perhaps the other way is better for a higher board position?
2. The height that the daughterboard should be soldered at needs to be chosen carefully (go as high as possible I think) so the 3.5mm socket isn't fouling the case.
3. The docs didn't say which switch position did what, but I've since worked out that right is 240p, middle is 480p and left is 480p with scan lines.

The only other things I'd mention are:

1. There is a little flux on the FPGA board that some people may want to clear depending on how much they mind that sort of thing, I'm being super picky here, I didn't care myself!
2. The DIP socket and pins for the VIC are very short/shallow, and require more force to get fitted than I'm used to when seating chips.

Thank you so much Reinhard for the opportunity to get one of these from you, combined with the OSSC this is the most amazing picture quality I think could actually be possible from a C64, it's just stunning!

If composite is a magnitude greater than RF, and Luma Fix -> S-Video -> Sony VR-1000 -> OSSC is a magnitude greater than composite, then this is definitely a magnitude greater than that! It is really like looking at an emulator output! ❤️❤️❤️

[c0pperdragon]

Thank you very much for this feedback, and I am very glad that the mod works so well for you. I have now added the missing parts to the instructions.

About the colors: As there is no 'true' standard, and everybody will also prefer a different palette, anyway, I just chose colors I personally like best. They are indeed quite bright now and remind me of a modern Nintendo console, but as you said, you can probably reduce saturation with your TV or upscaler setting.

Also I am aware of the short connector pins, but I just could not come up with any better solution, than using standard 40-pin precision IC sockets here for reason of saving space. Maybe someone can propose a better way?

[RobeeeJay]

I managed to solve the clearance by soldering the board so as little of the pins were visible as possible, I think this is a reasonable solution rather than changing components, it's just being aware that this is an issue before you solder everything as it's not the easiest thing to adjust afterwards. 😁

I understand about the colour preference, as a kid I used to increase the saturation myself whenever I borrowed a friends C64 for the summer. But this might be because I was more used to the ZX Spectrum. 😮 I suspect purists may find it too high though.

[c0pperdragon]

I have just added a section to the documentation about how to modify the FPGA board to reduce the color saturation. This may be an option if you can not adjust the saturation on the TV or upscaler.

[bwack]

Hi. I programmed the board right now using USB Blaster (cheap) and Quartus Prime 18.1 programmer software. At first I got a scare since the programmer software didn't find any jtag chain / device, but then when I measured voltages, it was all over the place. I had the ground lead near the 12V input, and therefor no ground on the fpga due to the split ground plane.

After shorting GND2 and GND4 with the meter, it did program :)

Question is it .pof or .sof files I use for programming the device ?

[desaster]

use .pof to flash the device, .sof is temporary and useful for development

[bwack]

Thanks! No image though, and no activity on y pb pr, only on svideo. Will trouble shoot.

[desaster]

Try the test pattern generator https://github.com/c0pperdragon/A-VideoBoard/releases

[bwack]

Thanks a lot desaster. I'll open another issue to continue.

[c0pperdragon]

Yes, I know the problem. Having this split ground configuration is surely a bit confusing. But I wanted to seperate the analog signal path as clearly as possible from the digital path, to get the best possible picture on the A/V output. And the same goes for the YPbPr output, as I did not want to have any crosstalk there either.

[Hojo-Norem]

I'd like to report a successful build:

Thing's I've observed during construction and testing:

1. The silkscreening for the ICs could do with a little more hinting for orientation.

2. Some people might do what I did and try using one of those camcorder 3.5mm to 3 phono leads (yellow, white, red). I found that GND is swapped with another signal on these leads. A note in the docs would help mitigate that, or a set of solderable jumpers on the main PCB to allow the builder to swap the offending pins around.

3. It may be a good idea to publish firmware images as a SVF or JAM files in addition to the proprietary Intel/Altera pof. I had to employ Mailinator so I could make a throw away account on Intel's site (They /demand/ things like your phone number, number of employees, expected units, etc) to let me download a 300+MB application to program the FPGA. I would not be surprised if there are more open alternatives. No biggie, especially that Intel aren't blocking signups from Mailinator addresses.

Now that I've got it working, I'll probably try having a go at knocking together some form of palette editor or adjuster (probably using the colodore algorithm).

EDIT: Seeing that there have been some code commits since the last FW release, I'm going to hold off reporting bugs until the next FW. Knowing me, the bugs I've come across have probably already been fixed.

[c0pperdragon]

My congratulations for getting this to work! But as you have a heavily modded board already, you sure are no beginner.

About your remarks:

1. I just use the standard silk screen markings that KiCad provides. These signify the pin one location in what seems to be the industry standard. I also took care to orient the reference IDs in the same way as the parts needs to go (this is especally imporant for the oscilator). I don't know what I could do more.

2. This would require quite some re-routing of the traces through jumpers. And I wanted especially the GND contact to have the shortest possible connection to the GND plane. I have also explained the connector pinout in the documentation ("you can use any breakout cable that converts TSSR to 3 RCA jacks, as long as the common GND is located at the sleeve").

3. I do not really know much about the various programmer file formats, so I just used the POF that comes out of the quartus compiler. After 5 minutes of research I guess the JAM format could be used with some non-intel programmer to flash the firmware. But as the software is free and the programming device can be found very cheaply, I did not care. Maybe you can propose some solution here?

An interactive palette adjuster would be very nice. Please feel free to ask if the documentation on the register settings is unclear.

Incidentially I have released firmware 2.2 today just before I read your post. So please feel free to report any bug you come accross. Of course I am already aware of the problems with "Edge of Disgrace" and what happens to a lesser extend with "Deus ex Machina".

[Hojo-Norem]

Thanks. On point one, on the small number of PCBs I've designed for myself where the silkscreen wasn't clear on orientation (either by design or because of a VIA or two blocking the print) I just add a small dot or line to the silkscreen to show the intended orientation.

The second point is essentially just me saying that I didn't know that the more common (in my experience) YWR coloured camcorder lead is wired differently to the RGB coloured component lead. Without a multimeter you cant tell until you plug it in. Then again, if you're building one of these then it's pretty much expected to have a meter on hand. :)

As for the third... well, thats just me venting a little... sorry. It wasn't aimed at you. With how the enthusiast movement is increasingly turning to programmable logic, it still irks me that the big vendors still insist on putting their software behind logins and think that only professionals (read, businesses big or small) are the only ones using their products.

I'm giving the new firmware a go. Big improvement over the previous. So far I've seen one bug. I'll open a fresh issue once I've got some more detail on it.

As for my ideas on a palette editor, at the moment I'm leaning towards implementing a version of the colordore editor (https://www.colodore.com/), there the main adjustments are just brightness, contrast and saturation. The algorithm looks to be fairly straightforward to re-implement in Basic 2.0 and we can even skip the YUV to RGB conversion step, seeing that we are already working in practically the same colourspace. From experimentation and research it looks like the various colour mixes can be calculated easily and offering a choice of old or new lumas even easier so.

[Hojo-Norem]

It's taken me a little while, but I've finally managed to wrap my head around the colour register system and successfully begun implementing the Colodore algorithm:
My camera isn't the best, but what you see here is a before and after. I haven't got any of the controls implemented yet, so what's here are just the defaults. Its good to know that 5 bits per channel seem to be good enough for a fairly accurate job.

[Hojo-Norem]

Making progress. I now have the brightness, contrast and saturation adjustment part of the algorithm working to a degree.

Saturation works pretty much as is, being able to go from grayscale up to full which looks fairly close to c0pperdragon's default palette.

Contrast need me to make sure I clamped luma to 5 bits or white would roll over and go dark.

Brightness has had me scratching my head a little. For a while it didn't seem to do much of anything... but I did notice all the colours would occasionally change briefly all at once. It's impossible for that to happen programmatically (especially in basic). After some thinking on the matter, I've come to the conclusion that colour 0 is also used as the black reference. Seeing that the brightness part of the algorithm made the greatest change to black then the black reference would change with it, meaning I would see little change on my screen. I've hacked my way around that by keeping colour 0 at a fixed level. It isn't as accurate, but at least the other colours are now changing somewhat properly.

Got to remember that your display device's settings will also affect the end result.

[c0pperdragon]

Yes, I forgot to mention in the doc: Color 0 is indeed the signal that goes out during all the horizontal and vertical blanking. TVs will use this signal as their reference levels. For YPbPr it is necessary that the reference level for Y is set to 0 and for Pb and Pr to something in the middle of the full range (I use 16 here), so the other signals can give positive or negative Pb and Pr values.

You can also reconfigure the system to generate RGB by setting all reference levels to 0 and map the G onto the G line, the R to the Pr and the B to the Pb. But in this case the scan-line emulation (right-most position of the slider switch) will not generate proper colors.

[Hojo-Norem]

vid-enh-palgen-asm.zip

Its been a while, but I've made enough progress with the adjuster that it's actually quite usable now. I've pretty much had to teach myself 6502 ML from scratch because the BASIC version wasn't really much good, even compiled. I don't have the PAL mixing calculations in place yet. I have a few ideas on how to go about doing that.

Actually, how much spare is there in the FPGA? If there's enough for a single line pixel buffer one bit in size and a few extra bits of simple logic then I think we could implement the odd/even line biasing for the colour mixing (I don't know if that's the correct term).

EDIT: Now that I've had a chance to sleep on it, if it's possible to access the palette matrix twice per pixel then I don't think that the extra buffer would be needed. Then again, either with or without the buffer my idea relies on being able to use bit 15 (unused except for palette reg 0).

Anyway my idea is that when calculating the palette, the non mixed colours will have bit 15 unset as normal. When the mixed colours are calculated they would be uploaded with bit 15 set. The crux of it all is the fact that with a PAL signal, whatever colour is on the odd scanline influences the resulting mix. ABABAB results in a different colour to BABABA.

As the firmware is designed at the moment, as the alternating colour lines are displayed, the interface is alternating between two palette registers, one for the AB mix and one for the BA mix. If we call the mixed colours C and D, the resulting output would be ACDCDC and BDCDCD.

How we would leverage this in the design is that all we need do is somehow force the output to only one of the two registers and this is how I think I'd go about it:

1. Get palette register entry for current pixel/upper pixel pair and get entry with current / upper swapped.
2. Logical AND bit 15 of the palette register entry with LSB of scanline counter (or some other way of tracking if line is odd or even)
3. If result of AND is true, display swapped register else display unswapped.

With my example above (assuming the first colour is on a odd line), what this should result in is something like ACCCCC and BDDDDD.

If we can get this working then we may get results close to this:

The rest of the work would then be the mathematics on the software side in the palette adjuster, which I'm fairly confident I should be able to manage seeing that I've gotten this far.

[c0pperdragon]

Good to hear about your progress. Will you make your program also available to the public when you are finished?

About the even/odd issue: I am not completely sure what you actually need, but maybe this could solve it: I can easily provide two banks of palette registers. One for even and one for odd lines. To keep compatibility, you would write into both banks by default, but you can also use some magic number to write into the banks individually. The additional RAM is no issue here, and the flash storage also has more than enough capacity.

[Hojo-Norem]

Sure, source code and all... Those who are more knowledgable with 6502 asm can look at my code and have a good chuckle. ^_^

As for my question about odd / even lines, I never realised that just throwing more memory at the problem could be a possible solution. Whatever method you pick for selecting the odd / even bank is fine with me.

If I can pull of the maths to make it work, then I might implement some extra tweaks. I've been translating pepto's algorithm in a way that doing things like adjusting the hue globally or on a individual colour basis should be straightforward. Another idea I've had is the ability to save a palette to removable storage as a stand alone loader.

I appreciate how far you have been willing to put up with my requests.

[c0pperdragon]

I have just implemented the second register bank to allow different colors for even and odd lines. By default, writing to the color registers sets both banks, so it behaves exactly as before. If you want to only write to a single bank, you need to write either 0 or 1 to address 53311. Writing 137 to this address will again activate both banks.

You can get the experimental firmware from: https://github.com/c0pperdragon/A-VideoBoard/tree/master/c64mod/experimental

[Hojo-Norem]

Thanks. I've given the firmware a quick test and I haven't spotted any compatibility issues so far. I'm still working on the palette adjuster and I'm not too far off a first stab at the colour mixing maths. The colours that the algorithm is producing aren't 100% to my liking, so I will be implementing a way to adjust individual colours. With that it practically becomes a HSL-esque colourspace palette editor.

[Hojo-Norem]

Success! The colours aren't quite right yet. I think I need to tweak the odd/even line biasing some more but I'd say this it pretty close to the real thing now. I just need to get the final couple functions done and then I'll post it up.

[bwack]

My video about this project. https://youtu.be/WxA-zrOpcDU

[Hojo-Norem]

c64-vid-enh-PALgen.zip

Well, here's what I'd call the first proper release of the editor. Just to make it clear to everyone, this is for component video use only.

 What's done:
    Default palette generation based on colodore algorithm
    Ability to alter brightness, contrast hue and saturation on a global or per colour basis
    ability to choose between First revision VIC-II lumas (old) and everything else (new)
    PAL colourmixing calculation...  an approximation but works somewhat
    ability to apply old VIC-II lumas to colourmix calaulations for new lumas.  Per colour luma channel is averaged without bias. 
    Upload to device flash
    Built in test image:
        This is just a Koala format bitmap.  I would appreciate something a little better, even if it's only a nice border...

 What's to do:
    Save/Load palettes to/from tape/disk

Source code is included. By reading it you accept that you will not hold me responsible for any damage to your sanity...

While where is no load / save code in the editor, it can be simulated by using a MC monitor to save $6e00 to $7800. This range contains all the calculated values and a small loader (with BASIC stub) to load them to the FPGA.

[MagerValp]

Perfect timing, I was just about to ask for a copy to test it! This requires the experimental firmware with the second register bank, right?

[Hojo-Norem]

Yeah, that's right.

[MagerValp]

I'm finally done building a compo machine for Datastorm with SIDFX and the video enhancement, using the experimental fw and @Hojo-Norem's palette settings. It's a 250466 board and with the mod installed the image is super crisp on both S-video and component.

The machine will be streaming live from Datastorm starting tomorrow evening, at scenesat.com, the schedule is at datastorm.party.

The photos below don't do it justice, the colors are actually well matched between component and s-video, but my phone camera interacts weirdly with the cheap HDMI display.

[c0pperdragon]

This is great news. I will try to follow as much as possible on the live stream.

[Hojo-Norem]

@MagerValp : Watching the SIDtune compo part right now. Picture is coming though nice and clean! It's hard to spot but the gfx for 'Melodeus' had some colourmixing going on. There'd be a bit more with the old lumas, but that'd be true for an actual 6569R1 VIC-II.

Can't wait to see it in the demo compo part.

Nice that you've given a shoutout to c0pperdragon.

I'm curious though, You are connecting via YPbPr > RetroTinkX2 > OSSC... I thought the OSSC supported component natively and that it didn't have a digital video (DVI, HDMI) input...

Edit: Now the stream won't load...

[olliraa]

Hi.

This might be an ultra stupid question, but if/when I upgrade the fw with a cheap usb blaster, does the AV-board has to be already soldered to the C64 pcb? I'm asking this because with the Furia Amiga 600 Xilinx fpga based turbo card it was specifically instructed that the card has to be isntalled on to the Amiga CPU before doing the fw update.

Just wondering, because I haven't installed the Video enhancement board yet (it's fully assembled though) and I'd be anxious to flash the 2.6 fw with the fixes regarding the Ultimate cartridge.

[c0pperdragon]

You can flash the firmware in any configuration you want. If the board it is not mounted in the C64, you need to provide a power supply yourselves, though. See the section on "Test the FPGA board (optional)" for a description where the power leads need to be connected.

[MagerValp]

@Hojo-Norem Glad you enjoyed the stream! :) The OSSC does indeed directly support component, but we had some initial issues and we also had to support S-Video so it was easier to just let the RetroTink handle it. It was mostly just due to lack of time, but as far as I could tell there was no loss of quality. I plan on testing the setup more now that I'm home and recovered :)

[Hojo-Norem]

It's a shame we didn't get to see it in use during the demo compo section.

Anyway, for what it's worth I've gone and put the sources and binary for the palette editor here: https://github.com/Hojo-Norem/c0pperdragon-VIC-II-Palette-editor (Finally put this account to use for something other than commenting here ^_^)

[olliraa]

Ok, thank you for the explanation. I had the wrong impression that the fpga would be powered via the jtag during tbe flash 🤣

[jpino1]

Hi, Amazing job thank you so much for doing it I love it. It would be possible to make it work in a C128? I see that it would be necessary to route the signals to the correct pins of VIC of this machine (MOS8566 is 48pins IC). Checking the schematic I see that all the signals are present. and I am willing to mount one by making a new adapter plate for these machines to test if work.

[antongale]

I've just built this excellent project and I am experiencing an issue where the horizontal pixel position of each line varies from frame to frame (see picture). Strangely, if I leave the C64 on for a while (~20 minutes) the issue dies down. I have tried with two VIC 6569R3 units in a 250407 motherboard and the results are the same. If anyone has experienced a similar issue please let me know.

[Hojo-Norem]

Have you tried the test pattern firmware? (https://github.com/c0pperdragon/A-VideoBoard/releases) It might help narrow the problem down.

[antongale]

Yes, the test pattern works without issue.

[c0pperdragon]

This really looks very unusual. Generation of the image in this case is only driven by the system clock and nothing else should influence the output. I only can imagine the reason to be that the mod can not properly receive the clock signal.

If you have access to an oscilloscope, try to probe pin 17 of the VIC to see what this signal looks like. It should be a regular 0.985MHz square wave. Also try to check if the signal reaches the FPGA (after voltage conversion to 3.3v) on the FPGA pin (pin 106).

[Hojo-Norem]

Got a new version of the palette editor ready. There are some tweaks to the UI and palette generating code, but the main new feature is proper saving and loading of palettes to and from tape and disk. Saved palettes can be loaded stand-alone without the editor.

Still no RGsB output mode yet, sorry...

https://github.com/Hojo-Norem/c0pperdragon-VIC-II-Palette-editor

[antongale]

Here is a trace from PIN17 of the VIC. As soon as I connect the probe (even without connecting it to the oscilloscope) the image corrects itself.

I did have to add a riser to the VIC board to avoid the variable resistor that interferes with the adapter board. I have built two of the adapter boards and they both do the same thing. Here is a picture of the installation:

[antongale]

You had also asked for some readings at pin 106. Without the scope connected to the VIC the frequency fluctuates between 976-994kHz.

With the scope connected to the VIC at the same time, everything settles down to 985kHz.

[c0pperdragon]

That is a very weird behavior of the VIC. It looks like the small added capacitance of the oscilloscope is may be just enough to even out some fluctuations on the clock line that would otherwise be amplified by the adapter board and mess up the clock signal.

You cold try to add a tiny capacitance between pin 17 and pin 20. 10pF would sound reasonable. You could solder this to the small visible metal cylinders on the adapter board, or you have some way to mount it to your own riser board.

[c0pperdragon]

Or just for experiment, try to place the capacitor with its legs so that it just touches the VIC pins (assuming some springy-ness of the pins if bent correctly). With this you could easily try out various capacitances as well...

[antongale]

I tried with a capacitor yesterday (between 17 & 20) and the screen went black. I'll try some other values tonight if I get a chance. Thank you for the support!

[c0pperdragon]

Hi! I would be nice to know if you eventually managed to get a stable picture.

[Hojo-Norem]

Been working on the editor a bit more recently. Main new features are the firmware default palette can be re-applied and RGsB output.

https://github.com/Hojo-Norem/c0pperdragon-VIC-II-Palette-editor

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.

[olliraa]

Been working on the editor a bit more recently. Main new features are the firmware default palette can be re-applied and RGsB output.

https://github.com/Hojo-Norem/c0pperdragon-VIC-II-Palette-editor

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.

Awesome :) Does this mean the RGsB works also with fw 2.5? If so, I can test RGsB with my Sony BVM.

[Hojo-Norem]

If you have been using the previous version (not the very first) on FW 2.5 then there shouldn't be any reason why this version shouldn't 'operate' as well. The upload to FPGA code hasn't really changed.

That being said, is there a reason why you're still on 2.5? The odd / even scanline palette function of 2.6 is needed for the editor to properly implement the colour mixing.

[olliraa]

If you have been using the previous version (not the very first) on FW 2.5 then there shouldn't be any reason why this version shouldn't 'operate' as well. The upload to FPGA code hasn't really changed.

That being said, is there a reason why you're still on 2.5? The odd / even scanline palette function of 2.6 is needed for the editor to properly implement the colour mixing.

Running the 2.5 from August. Haven't dared to try the flashing yet :/ I should really do that though.