search

c0pperdragon / C64-Video-Enhancement

Component video modification for the C64 8-bit computer
MIT License
257 stars 36 forks source link

Compatiblity with 6567R56A #40

Closed c0pperdragon closed 4 years ago

c0pperdragon commented 4 years ago

Hi @laubzega,

As previously discussed, I have made a first experimental firmware version to support the 6567R56A chips. These are quite rare and probably no demo directly supports them (different cycles per line and lines per frame). Also there is not much documentation or test programs available. I think it is good enough if "normal" screen modes and sprites work , without the fancy stuff demo-coders normally use to trick the VIC into all kind of strange behaviour.

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

To actually use the 6567R56A mode, you need to have the pixel clock running at the NTSC frequency (using a normal NTSC computer) and additionally you must pull pin 5 of the JTAG header to ground. Pin 10 and pin 2 of this header already provide ground, so a short jumper wire should work. Obviously you can only attach this jumper when the JTAG programmer is not attached ;-)

laubzega commented 4 years ago

With the JTAG pins shorted the base image shows up correctly. Also simple demos playing with colors posed no problems (top image is S-Video, bottom - component):

6567R56A

However, as I moved to more complex things, it became apparent that not everything is behaving as it should, as this FLI image demonstrates:

6567R56A-FLI

What you cannot see here is that there is some blinking in the image, suggesting there is some timing component to it. Here is the same demo working correctly with 6567R8:

6567R8-FLI

If you would like me to run some specific test software or demos, just send me a link.

laubzega commented 4 years ago

One more thing - I have tested two 6767R56A VICs, with identical results.

c0pperdragon commented 4 years ago

I am actually a bit surprised that it works so well already, as I had only a quity sketchy doc and guesswork.

Before diving deeper into thr FLI topic I would like to ser how sprites behave. Just try a few games and see if everything is actually visible and at the right places.

laubzega commented 4 years ago

Sprites seem off. Here are:

  1. Giana Sisters trainer screen
  2. Giana game start
  3. Ghostbusters sprites capture with AR

Also, some non-sprite issues:

  1. Boulder Dash intro screen

Let me know if more detailed photos are needed.

giana_intro

giana1

ghostbusters

boulderdash

laubzega commented 4 years ago

Some more:

  1. Bruce Lee intro screen.
  2. Bruce Lee in game.
  3. Impossible Mission in game.

It looks as if sprite pointers were captured incorrectly.

bruce_intro bruce im

c0pperdragon commented 4 years ago

Most of these things are perfecly clear if the sprite DMA is off by one cycle. I have adjusted this now in version 2.9.beta5. Please check if it is now fixed. Also the broken giana sisters trainer screen may be caused by this. The strange colors in the boulder dash screen could be a different matter. But please check anyway.

laubzega commented 4 years ago

Great, sprite problems are indeed gone, including Giana Sisters trainer. So what remains are issues that appear to be related to color ram fetches:

bdt2 bdt blt1

https://www.youtube.com/watch?v=VXUSLaDseO4 https://www.youtube.com/watch?v=7peN_i_y614

laubzega commented 4 years ago

Couple more things:

  1. With some color combinations you can see faint echos of previous 8 dotclock pixels, shifted down by approximately one line. At first I thought it could be a problem with improperly programmed palette, but the effect disappeared after I swapped in 6567R8 (and adjusted jtag pins). Still, it is probably due to color mixing.

colorecho

  1. When switching back and forth between component and composite inputs on the same TV, I can see that the R56A component picture is shifted down by two, maybe three rasterlines. With R8 both pictures are aligned perfectly.
c0pperdragon commented 4 years ago

I have uploaded a new beta that should fix this ghosting effect - is caused by a missmatched color merging.

The main problem is probaby not caused by the color ram, but by the access to the video matrix ram. For normal text and graphics modes, this does cause no effects, but for the multicolor modes it will. Maybe you could try to get the C64 into multi color graphics mode (withou any FLI order other fancy tricks) and see if this is causing the glitches. If yes, I would need to shift the sample point to catch the correct data.

laubzega commented 4 years ago

Indeed the ghosting is gone with 2.9_beta6. You are correct about video matrix, and it does not even have to be multicolor mode. This is bitmap mode (poke 53265, peek(53265) or 32) with video matrix cleared ($20).

videomatrix

laubzega commented 4 years ago

Correction: After some more testing it seems that the ghosting is caused by the palette editor, or at least its interaction with the firmware - I can get ghosting-free image right after flashing either beta5 or beta6, but once I adjust the palette, ghosting appears.

Calling @Hojo-Norem.

Hojo-Norem commented 4 years ago

Hmm. Id like to say that the palette editor is a symptom rather than a cause, but I'm not smart enough that I can say that outright.

After a think my first guess is that somehow the buffer in the firmware that holds the previous raster line is somehow out of alignment, possibly the odd/even raster line counter as well.

The baked-in-firmware default palette and the non-mixed colours in the editor generated palettes are arranged in such a way that the line buffer being misaligned wouldn't affect them.

c0pperdragon commented 4 years ago

Hojo-Norem is correct. The colors of the previous line were miss-aligned with the current line, giving this ghosting effect when applying color merging. Because default colors do not use color merging at all (just use the second color directly), this has no effect then.

If have make a firmware that shifts the sample point for the video matrix data by 70ns, so maybe this will catch the correct data.

c0pperdragon commented 4 years ago

In my previous comment I got the difference in the various video modes incorrect. The video matrix glitch should effect the "standard graphics mode", the "multicolor graphics mode" and the "ECM text mode", but not the other text modes (standard and multicolor).

laubzega commented 4 years ago

Yup, that was it. With the latest firmware I am no longer seeing issues with Bruce Lee and BoulderDash title screens. Also FLI demo looks correctly.

Ghosting is still there after palette flashing.

c0pperdragon commented 4 years ago

Oh, my! The FPGA is so totally at its limit that even the slightest changes could cause the VDHL fitter to no longer be able to fit the logic into the device. So I had to refactor quite some parts to squeeze out a few more LUTs to actually make the changes...

I have included the discussed changes and also fixed the ghosting, at least I hope so, because in my current setup I can not test this... I also tried to vertically move the display a few lines, in the correct direction, I hope...

Please give the latest firmware (beta7) a try on the 6567R65A. And if this now all looks good, please re-test it on other VICS as well, as I could very well have broken quite some things there...

laubzega commented 4 years ago

I have a love/hate relationship with logic squeezing. Sometimes it's very rewarding, sometimes it's a major PITA. At least you have a clear migration path to 10M04. Not so with the BeamRacer. :/

Anyway, beta7 works great. I tested both R8 and R56A, no issues observed. Colors align correctly after reprogramming, the vertical shift is no longer there. Games and simple demos I tried worked fine.

Thank you so much for all this work!

c0pperdragon commented 4 years ago

Thank you very much for all this testing. I have released 2.9 which should now indeed cover all possible variants of the VIC-II.

I am pretty sure I will not migrate to a larger FPGA. There have been too many boards produced for which I will not give up support. As it seems the feature set is now complete, anyway.