A few questions

[bodgit]

Sorry for the vague title, I realised I had multiple questions :wink:

1. I noticed you've added an FPC/FFC connector to the modulator PCB so it can attach directly to a BeamRacer, (I've got one of these so I'm going to build this new version). I presume from the connector part the cable is 0.5mm pitch and 20 contacts but do you know if the FFC cable should have both sets of contacts on the same side or opposing sides as it means the cable is either pinned 1-1, 2-2, etc. or 1-20, 2-19, etc.
2. With the test pattern firmware, should one of the switch settings produce visible scanlines? I seem to get 576i and 576p but none of them have scanlines that I can see.
3. Building one board as a test circuit to test without having to install every board into a C64 is a really good idea, is it worth trying to reduce the BOM for this? I assume the board doesn't need to be fully populated; it likely needs enough to power the FPGA and connect to its GPIO pins so sections like the resistor network aren't entirely necessary? I'm not sure if the amount of money saved on components is worth the hassle given parts like resistors are fairly cheap.

It's taken me a while to get back to this, (so many projects!), I had trouble getting the JTAG programming to work, I wasn't sure if it was my USB Blaster, or my soldering, or the fact I was using Quartus in a VM with USB passthrough. Turns out I just needed to supply some power to the board, I assumed the JTAG interface did that. Then I found out that my TRRS breakout cable has the Y and Pr connectors swapped which meant I still didn't get a picture when I used the colour of the RCA connectors, only when I hooked up to an oscilloscope was it obvious the sync signals were on the wrong channel.

One suggestion I had is possibly an even simpler test pattern that is just vertical colour bars as that means you only need to capture one scanline between the hsync pulses on a scope to confirm things look correct. I admit I was a bit confused by what I saw on my scope as I didn't know what the test pattern looked like. Now I've seen what the test pattern looks like on a TV it makes more sense.

[c0pperdragon]

I must say I don't know the orienation of the pins on the BeamRacer. I just included the footprint for the plug on the PCB in the same orientation as for the pin socket. Please write a question in this issue thread - which I have just re-opened - to get a more qualified answer: the https://github.com/c0pperdragon/C64-Video-Enhancement/issues/33

The test pattern generator only generates 288p (which the TV may show as 576i) or 576p, but no scanlines.

I came up with this test circuit so the manufacturing house who built the latest batch could test their kits. And you may very well leave out quite some of the parts if it is purely intended to test other boards: All on the analog side, including REG2, AMP2 and all the passives. Also AMP1 and the whole video output circuitry there (including all the resistors). Also the TRRS socket and the mode switch are not necessary. In fact you need to leave away the mode switch in order to have enough outputs to feed to the VIC-II adapter board. It is intended to always test a full set of both the VIC-II adapter together with an FPGA board.

[bodgit]

Excuse the visible moiré interference, but is the attached photo the expected output for the test pattern?

[c0pperdragon]

This output is not quite right. It should actually show all 16 colors as bars, and the dark blue screen area should be 20 rows high as usual on the C64. And this gray area on the lower portion of the screen is also not correct. The "c0pperdragon" text looks correct if it is indeed pure white (which is hard to see on this picture). Maybe something is wrong with the synchronization? How is this device set up? Is the test signal generator directly connected to the component video mod? Or is this piped through the BeamRacer? In this case I assume that the BeamRacer somehow mangles the DRAM refresh pattern.

[bodgit]

Right, I wasn't sure if I should be getting something that looks similar to a normal C64 screen. The text is indeed white.

The setup is one modulator board programmed with your test generator firmware, wired up to the same VIC adapter board on a breadboard that is then connected to each modulator board in turn running the released 2.9 firmware; I've left the BeamRacer out of the equation for now.

I've tested four five modulator boards and they all produced the same output as in the photo, I had a fifth board that was mostly the same but had some artefacts (text was garbled and some pixels on the left border were a different colour) but I think I've tracked that down to a tiny bridge on one of its GPIO pins which I've fixed, (so the test firmware worked in that regard!), I just need to retest that board.

All of the modulator boards ran the standalone test pattern firmware and produced the same output so I think the problem is with either the modulator board running the test firmware or the VIC adapter. I'm fairly sure I wired up the GPIO pins to the VIC adapter correctly but I will doublecheck them again now I know the output is wrong, could this be the cause? The bottom border at least seems to be in the right place but just the wrong colour.

[laubzega]

Which VIC version is that? Have you tried with a different one? @c0pperdragon, is there a reference image for the test pattern somewhere online?

[bodgit]

@laubzega There isn't actually a VIC or even a C64 involved at this point. This is using a second modulator board as a signal generator to test the hardware.

[c0pperdragon]

This miss-aligned frame synchronization hints could be caused by the RAM refresh pattern to not be properly recognized. This RAM refresh is detected by the mod by monitoring the A0 and A1 lines. So I guess these may not be wired up correctly in your testing rig, or the VIC adapter itself does not properly forward these signals.

[bodgit]

I tried swapping out the VIC adapter for a different one and I get the same output still so I think that should rule out the VIC adapter as the source of the problem. I traced through the A0 and A1 pins on the VIC adapter to the A1 and A2 input pins on the LVC245 U5 and then the B1 and B2 outputs from that go to the other end of the IDC cable.

I've also confirmed that pins 100 & 103 on the test FPGA are connected to pins 16 & 18 on the GPIO pin header which are the A0 and A1 outputs to the VIC adapter. The A0-A5 pins are mapped 1:1 to GPIO pins, 18, 16, 14, etc. so I can't see how I've got those wrong.

Edit: Here are two photos showing how I've got it wired up, if there's anything obvious I've done wrong.

If it's helpful, I can put a scope on the A0 and A1 lines before/after the VIC adapter and see what it's doing.

[bodgit]

Here's what I grabbed with my scope, capturing A0 and A1 from GPIO pins 14 and 13 between the VIC adapter and the modulator board being tested:

I probed the Luma channel too so I can see the vsync pulse and use it to capture a single frame. It looks like there's a "missing" A0 and A1 pulse just after the vsync is observed. Is this what you were talking about?

[c0pperdragon]

Sorry for the late reply, but I just had no idea which advise I could give you. Until now, that is.

Quite some time ago, I made the special firmware for signal generation to help the manufacturing house test the mod boards. They programmed firmware 2.6 to the production boards, and they worked fine with the signal generator. Since then I have made some modifications to the firmware to support other VIC variants as well and this also affects the frame synchronization. I have not re-tested any of the newer firmware versions with the signal generator, so it may very well be that it is now no longer compatible. To check this, just use the firmware 2.6 on the device under test and see how the output looks like. If it is OK then you at least know that the hardware is working correctly (all the soldering and wiring of the FPGA board and the adapter). Then you can re-programm it back to the newest firmware and be quite confident that it is still OK.

[bodgit]

Last night I thought "what the hell" and installed one of the boards as a quick experiment and it seemed to work fine, (main C64 screen followed by a few POKE 53280,x's) so I think you might be right. I will put 2.6 on one FPGA board and see what happens and report back, but I think because all of the boards behaved consistently under test I think they're probably okay.

[bodgit]

Your hunch was spot on, with 2.6 flashed on an FGPA board I get this:

[c0pperdragon]

So this looks perfect now. Only this small white vertical line in the upper right part is strange. But maybe this is just a reflection on the screen?

Sorry about the confusion - I really did not think about possible incompatibilities with later firmware versions. I guess you can use the signal generator anyway also for the 2.9 FPGA firmware. As you now know how this looks, this is good enough to confirm that a given hardware is OK.

[bodgit]

Ha, yes, I think it's just a reflection of a window behind me but it does look like some pixels. It was a fun debugging exercise and even though I wasn't getting the "correct" picture, it was still enough to show up one board that had a tiny solder bridge on the FPGA GPIO pins so it was very useful in that regard.

With all of that sorted, I tried adding my BeamRacer to the C64 and I can confirm it all works 👍

[c0pperdragon]

Congratulations to sorting this all out now. I have a small question, though. I see you are using one of my later mod board. I would actually like to know how the new big heatsink area for the voltage regulator REG1 performs. On a long board with its higher voltage, this regulator normally has quite some heat to dissipate. On the previous boards it got quite hot (not too hot to touch, but still). This here now should run much cooler, but I have not actually tried it myself. Maybe you could test this after letting it run for 10 minutes or so?

[bodgit]

Sure, I can test this out. I'm actually just fitting some heatsinks to the big MOS chips like the VIC and SID so I'll be testing how warm everything gets in general.

[bodgit]

I've now run it for a while watching a few demos and I don't think the regulator is even as warm as the FPGA, and neither are anywhere near as warm as the VIC gets.

[c0pperdragon]

Thank you for testing that. Its good to know that this works so well.