Strange behaviour with SdBrowse

[pazuzu72]

I am using your upgrade with great pleasure on my C64 connected to an RGB CRT monitor. Up to now I have not found any incompatible programs or games ... today it happened!

This is SdBrowse, not that I care, but maybe it can be useful to find a solution and understand the reason. Switching to composite (obviously without turning off the C64) everything is ok. When the program is loaded, RGB is correctly displayed for a few fractions of a second and then the lines that can be seen in the photo appear.

[c0pperdragon]

This is indeed a strange behavior. Let me see, if I got this right: The bottom picture shows your monitor using the composite video signal from the original A/V jack. The top picture shows the same monitor switched to RGB driven by the mod board. Between both photos you just switched the input at the monitor.

Guessing from the aspect ratio I would say, you are using a PAL C64 with 50Hz frame rate. I have the same here and this program works absolutely flawless and the output is totally identical to the composite video in every respect (except better image quality of course). Even the small one-pixel glitch in the right panel is the same.

So, I think the problem somehow arises from your specific setup. First let me know how you attach your monitor, especially how sync is handled. And second, how is the color palette configured? Do you use the option to have "pure" RGB without sync on the green line?

Maybe something is set up in an off-spec way that somehow works in most cases, but can be pushed over the limit by some unusal video signals.

[pazuzu72]

Let me see, if I got this right: The bottom picture shows your monitor using the composite video signal from the original A/V jack. The top picture shows the same monitor switched to RGB driven by the mod board. Between both photos you just switched the input at the monitor.

It's correct.

I'm so stupid. I failed to tell you an important detail. I'm using an Ultimate II + I think that's the problem. Now I'll try a different system (pi1541 or EasyFlash). I'll let you know.

[pazuzu72]

The problem also remains when running the program from via other systems (Pi1541).

[c0pperdragon]

I don't think it makes any difference if you use a floppy emulator. This has not much to do with the video signal generation. The ultimate II could actually influence video generation when showing its built-in menu, but otherwise it would not interfere. The Pi1541 is completely unsuspicious as it is totall decoupled from any display.

[c0pperdragon]

Looking at your picture with the colored lines, it somehow looks a bit like the monitor does not recieve proper horizontal sync signals. Could you please tell me in more detail how you connect the C64 and he monitor together?

[pazuzu72]

It works perfectly with everything except with that program (as far as I have been able to verify with my experience so far). I obviously take RGB signals from your card and sync from composite or luma but it makes no difference, the problem persists. The image can be seen correctly for a moment and then those lines appear. I could do a test by reprogramming the output in YPbPr and connecting another monitor with component input.

[pazuzu72]

Due to lack of time, I was only able to take the test now. Setting the firmware as YPbPr output works without any problem. So the problem is limited only to RGB.

[c0pperdragon]

To make a better guess, I really need more information about your RGB setup. Can you tell me how your cabling is exactly done. From which output ports of the C64 to which inputs into the monitor. And which inputs does the monitor have in the first place? Can you make photographs of both the cables and the monitor ports seperately and then again when everything is connected? The problem must be some very strange incompatibility in some very specific cases. I am still not sure how your sync is passed to the monitor.

[pazuzu72]

The one in the photo is the pinout of the input of my monitor (Commodore 1084S-D2). There is not much to explain. To the Red, Green, Blue pins (3,4,5) your board is connected in addition to the ground of course. The composite video taken from the C64 DIN port is connected to pin 7 (composite sync). But again, it works perfectly with almost everything else so I assume it's not a connection problem. (I say "almost" because I discovered that even a demo at some point, only on disk 1, presents the same problem https://csdb.dk/release/?id=180320)

[c0pperdragon]

I think the main problem is that this csync input can not handle a composite (or luma singnal) in all circumstances. Probably you were just lucky and and the detection circuit just worked most of the time. I would think that this mainly depends on the overall brightness of the screen and with these particular programs the signal is just a little too far out of the detectable range.

For a proper solution you would need a sync stripper to retrieve a "pure" csync signal from the luma or composite. There are some nice tutorials on this matter on https://www.retrorgb.com/sync.html and https://www.retrorgb.com/syncstripper.html With some soldering skills and the necessary IC you could make yourself a sync-stripper cable.

Another solution would be to modify my mod board to then output "pure" csync instead of composite video on the A/V port. This may be an option if you will never again want the composite video signal anyway. Luma/chroma would stay intact so you could still use these signals for an s-video setup. If you want to go this route, I could draw up some instructions how to do this.

[c0pperdragon]

Another option to make a sync-stripper cable would be to insert a diode of just the right characteristics into the cable between the luma and the GND signals. This diode would need to have fast switching and a forward voltage between 450 and 500 mV. I don't know how easily you could obtain such a diode. Also this cable would only work specifically for the C64 with my video enhancement mod. In the general case sync-stripping is much more complicated.

[c0pperdragon]

You could actually test my hypotesis concerning the total luma on the screen by just setting border and background color to white: poke 53280,1:poke 53281,1

[c0pperdragon]

Hi! It would be nice to hear if you could actually solve the issue...

By the way: I did some experiments with diodes to reduce the luminousity in the luma signal while keeping the sync intact (a kind of poor-man's sync stripper). I was using a high-speed schottky diode (more specifically a BAS40 variant) between the luma signal and GND of the A/V port (original signal is routed through the mod board, so it has a very clearly defined DC bias). While I can not really test the effect on a monitor with "pure" sync input, the sync pulse is now much more prominent in respect to the image data. So I guess it really should improve the matter.

[pazuzu72]

Hi, sorry I'm late but I don't have much time. I just tried the diode quickly and it seems to work. Now I will install it more permanently and do other tests.

[pazuzu72]

Update! I tried a diode that I had at home and it actually solved the sync problem with the SdBrowse. In the normal screen of the C64 instead as well as in other situations the edges of the image were distorted. I solved definitively using 2 diodes in series (I don't know what type). One has a voltage drop of 0.2V and the other about 0.55V.