search

c0pperdragon / LumaCode

Definition of the "LumaCode" signal standard with reference implementation
59 stars 1 forks source link

Missing colors? #17

Closed LarsBorris closed 3 months ago

LarsBorris commented 3 months ago

Hello!

I installed the VIC 2 DIZER mod in my breadbin and I am having problems with colors: c64 Any suggestions on how to resolve this?

Thanks! (Bought the mod on tindie)

c0pperdragon commented 3 months ago

For a start try to check if the problem is with the VICIIdizer or the RGBtoHDMI. Try to connect the lumacode signal from the VICIIdizer directly to a TV's composite input (normally the yellow jack). When you paint some colored bars on the C64 basic screen, you should see something like that: https://github.com/c0pperdragon/LumaCode/wiki/VIC-II-dizer-(for-the-C64-computer)#details-on-color-encoding

LarsBorris commented 3 months ago

Hello!

I tried that, and I get the same black image and the test is grayish. Thanks!

c0pperdragon commented 3 months ago

Could you paint stripes of all 16 colors on the C64 screen and take a picture of the compostive video screen? Maybe I can detect the error-pattern.

LarsBorris commented 3 months ago

I would be happy to! Can you supply me with the basic code/program needed to display the colors? I have used the C64 alot but it was 30 years ago, when I was 10 years old :)

Thanks!

c0pperdragon commented 3 months ago

No need for any program. Just use the color keys (press Ctrl-1/Ctrl-2 or Commdore-1/Commodore-2, etc) to switch text mode. Then write some letters in this color directly to ths screen. Considering the general behaviour, this may actually already work, even when using the RGBtoHDMI (please check) and int may only be the problem that the screen background and border has the wrong color.

LarsBorris commented 3 months ago

Hello!! image

Those look fine. How do I type more colors? It has 16 right?

c0pperdragon commented 3 months ago

You can switch to futher 16 colors with the Commodore key instead the Ctrl key. But it already seems to me that the colors work in general on the RGBtoHDMI. It may really be the background color and the border that is not correctly initialized.

Try to do that by directly using one of these POKE commands: POKE 53280,1 (or any value of 0 to 15) for the border color POKE 53281,1 (or any value of 0 to 15) for the background color Tell me how this behaves.

LarsBorris commented 3 months ago

Thank you, I will try that soon. Ran out of time (my son woke up) Will give it a go next nap time

LarsBorris commented 3 months ago

I just remembered that when I had the unit hooked up with the rca video cable from the video port the color looked fine.

LarsBorris commented 3 months ago

image

image

c0pperdragon commented 3 months ago

From these test, I see that the VICIIdizer misses some (but not all) writes to the VIC-II registers. The very likely problem is that one of the address lines A2 - A5 (with my guess on A4) has no proper connection. This can either be inside the VICIIdizer or a bad conntact of the socket pins. The second can be ruled out when the original A/V output produces correct colors.

If it is indeed a fault of the VICIIdizer, you could attempt a repair if you have soldering equippment and feel up to the task of re-flowing a SMD part. This would be risk-free, because in case of failure I will send a replacement part.

LarsBorris commented 3 months ago

This is the output from the A/V output image

So it must be the VICIIdizer. I am able to solder and have a hot air SMD station. I just haven't used as much yet.

If it's risk free, I will gladly give it a go.

c0pperdragon commented 3 months ago

Very good. So using a fine tip, give all legs of U2 a reflow heating without adding any addtional solder. If you have some flux, apply a bit of this. U2 is the one IC that has 16 legs.

LarsBorris commented 3 months ago

Reflow didn't help. Same black background but now the text flickers between red and blue. https://github.com/c0pperdragon/LumaCode/assets/10630935/aef09e4a-0d97-44ea-9c3c-7f422eded82c

LarsBorris commented 3 months ago

I reflowed all the square chips btw just in case.

c0pperdragon commented 3 months ago

OK, so I guess it will be a replacement.

LarsBorris commented 3 months ago

Thanks! I will test the new one and report back.

LarsBorris commented 3 months ago

Hello!!

Received the new board today! I installed it and it does exactly the same as the old one (before the reflow)

I am beginning to suspect that something else is wrong. Do you have any suggestions? Just to be sure I already did a reflow of the new board and took pictures so I could zoom in on the tiny legs.

image

image

This time I used my soldering iron.

c0pperdragon commented 3 months ago

Your reflowing looks fine, but when the replacement VICIIdizer behaves exactly as the previous one, it is extremely unlikely that this is the problem.

Something your C64 does must be different from what all other machines do. It is impossible to tell from afar what is going on. If you have access to an oscilloscope, there my be a chance to at least get a hint on what is going on. First thing to check is the pixel clock generator. These sometimes create a very wonky clock signal that is somehow working with the original hardware, but causes trouble for the VICIIdizer. This clock is availabe on pin 22 of the VIC-II. Ideally, it should be a nice 7.88 MHz squarewave. A bit of jitter is ok as long it is not too extreme.

LarsBorris commented 3 months ago

Everything works now. Turns out it was the PLA that was bad. The expansion port was also not working. Changed the PLA and now everything works.

https://github.com/c0pperdragon/LumaCode/assets/10630935/f140e5cc-a84a-4499-877f-b75081546c2f