Random power up issue

[IanSB]

I've been getting a random power on problem where the video is messed up. When connected to a Retrotink and this happens, there is no output at all, just the Retrotink generated colour bars, when it's connected to my HDMI scaler project the video is visible but it is shifted to the left and game backgrounds are corrupted (the sprites look OK).

The normal C64 composite video output is still OK when this happens.

Normal:

Problem:

Power cycling fixes the problem. This seems to happen about 15% of the time on power up.

[c0pperdragon]

This behavior strongly hints at the C64 clock generator chip 8701 to behave exceptionally bad. By the way the VIC cteates the CPU clock from the pixel clock, the system can come up in any one of 4 different configurations. One of these seems to result in a very unlucky timing for certain bus signals. So I would actually expect an error rate of 25%. If you have an oscilloscope try to probe pin 6 of this chip. If the signal looks extremely unregular (should ideally be a clean square wave) this could indeed be the problem Maybe replacing this chip could help.

[IanSB]

The board is ASSY No.250407 REV A with a 6569R1 and doesn't have an 8701, it uses several chips for the clock generator.

[c0pperdragon]

Still the problem may be the same If you can, probe pin 22 of the VIC. But fixing the issue would be pretty difficult, I guess

[IanSB]

Here's pin 22 of the VIC II:

Here is another grab over a longer period which shows some jitter

[c0pperdragon]

This pixel clock looks pretty perfect. In fact it is much better than what an 8701 would produce. This leaves me a bit clueless. Specifically what happens at power-up that can mess up the situation in only some instances. A last idea: The mod auto-detects an NTSC machine by measuring the CPU clock. Maybe the pixel clock generator runs a bit too fast immrdiately after power-up? Could this lead to a miss-detection? But the symptoms do not really fit, either...

[c0pperdragon]

Another hint to follow is the video signal that seems to be too far off spec so the 2x refuses it. Could you check what is going on on the Y signal in the caae od the error?

[IanSB]

The only thing wrong with the video signal is that the back porch is only 2uS and it's followed by a high luma level due to the video signal border being shifted left. This would mess up any agc and back porch clamping in the 2x. Note the video levels are not standard as I reprogrammed the palette.

Here is normal operation with a back porch of ~6uS

Here's the source info page on my scaler but the timings seem correct:

However there are some twinkling pixels due to sampling error which means there has been a change in the phase relationship between the trailing edge of the sync pulse and the pixel clock compared to normal operation.

[Hojo-Norem]

I apologise for the intrusion, but your Pi based HDMI upscaler is a really neat idea. In relation to c0perdragon's mod are you using a ADC or equivalent to input the video signal or taping the digital bits straight from the FPGA? How do you handle, or going to handle custom palettes?

I can imagine a version of the video-enhancement designed to mate up with a Pi. Strip out the palette and analog video generator parts from the FPGA and then just spit 9 bit palette indexes out from the FPGA and into the Pi. All you'd need then is some way to let the C64 talk to the Pi to upload palettes and alter other settings. A SPI between the FPGA and Pi perhaps?

Actually, don't need 9 bits (for the two 256 colour palette tables). Just 4 bits and do the delay line emulation on the Pi. That means the palette is not limited to 15 bits per pixel.

Is there a more suitable location to discuss this further?

[IanSB]

The original project was created by hoglet67 for the BBC micro which has RGB TTL outputs (1 bit each so 3 bits per pixel) and I got involved to add deinterlacing support for the BBC's teletext mode 7 which has interlaced video (all the other BBC graphics modes are 288p). I also added genlocking so the Pi's video output tracks the source which keeps the lag down to 3 milliseconds.

Because of the way it samples and integer scales the incoming video, the results are totally noise free and as clean and sharp as an emulator so I decided to see if it could be adapted to support other vintage computers. The CPLD was then reworked to increase to 6 bits per pixel which initially allowed support for IBM PC CGA and EGA and any other computers with TTL video output.

As only 6 bits per pixel are available, a normal ADC couldn't be used but I designed a simple analog interface which is effectively a discrete ADC made up of an 8 output DAC and 8 comparators to level slice the incoming video to generate some discrete digital values. This only works on computers where the analog levels are widely spaced and can be easily discriminated like the Amstrad CPC, Tandy color computer / Dragon or the later Spectrums (it does work on the 48K Spectrum but can't discriminate bright / non bright colours). It also works with most early monochrome computers like ZX81 or Apple II and I added NTSC artifact decoding so you get colour out of the Apple II or IBM CGA). It should be possible to add PAL delay line artifact emulation.

The default palette on c0pperdragon's interface has too many levels that are too close together so to get it working I reprogrammed the palette to output very widely spaced levels that are easily detected so effectively it is extracting the 4 bit logical colour info via the analog output although it would be better if that was directly available on a header. See bottom of this page for the levels used: https://github.com/IanSB/RGBtoHDMI/wiki/Cables

It uses a profile system because you need to describe the source video in detail so that it can be sampled correctly and that includes palette tables which are stored on the Pi's SD card along with the profiles so you can create custom ones. You can also dynamically reprogram the palette by briefly displaying a line of pixels with a specific pattern in a sequence that is extremely unlikely to occur by chance.

I think it should be very easy to merge this project with c0pperdragons designs. I've recently done some work to increase to 8 bits per pixel so it will probably also work with the Atari 800 board but that would definitely need an 8 bit digital output as the intermediate analog option wouldn't work.

The scaler project is here: https://github.com/IanSB/RGBtoHDMI/wiki Gallery of supported computers: https://github.com/IanSB/RGBtoHDMI/wiki/Gallery-of-Screencaps (Click on the links and view the images at 100% on a 1080p monitor for exactly the quality you get out of the Pi) It is a fork of this project started by hoglet on the startdot forum (Acorn / BBC micro) https://github.com/hoglet67/RGBtoHDMI Most of my work has now been merged back into the original but the latest including the C64 support is only in the dev branch of my fork at the moment. The original thread on stardot is here: https://stardot.org.uk/forums/viewtopic.php?f=3&t=14430 All of the discussion has been on there so far.

[c0pperdragon]

This video signal is strange and I guess it can only happen if something goes wrong with the detection of the frame start. I am using the DRAM refresh pattern of the VIC to sync the FPGA to it. So far this always worked. Can you tell me, which version of the firmware you are using? The mod kits sold by VideoGamedPerfection come with 2.6 installed. If you happen to have compiled the firmware from the current sources in the Repo, this could be the problem because they contain a change to also support PAL-N and are very little tested.

[IanSB]

I got it from VideoGamedPerfection so 2.6

[c0pperdragon]

Short comment on your scaler project: Very nice approach to zero-noise video output. I initially wanted to make a solution for the C64 that correctly quantizes the output of the VIC, but this just didn't work. Similar solutions for the ZX Spectrum and Atari 8-bit line also failed. So I made FPGA solutions for all three instead. The Spectrum board could also work with your upscsaler: only 15 colors with very clean levels.

[c0pperdragon]

Version 2.6 is pretty well tested on many VIC revisions. But maybe there is something the R1 does slightly different in regards of the DRAM refresh. And this diffetence only manifests itself in some cases.

[IanSB]

I should have a 6569R5 to test with next week so I'll see if that behaves differently. Are you interested in working together to link up our two projects? I'd like to get the Atari 800 working with the scaler but using the C64 style analog workaround isn't going to be an option for that one.

[c0pperdragon]

Yes, lets wait to see if the other chip changed anything. About linking the projects: This is a great idea. Maybe we should switch discussion to a different location?

[IanSB]

Any location you would prefer? The home location for the scaler is the stardot forum thread: https://stardot.org.uk/forums/viewtopic.php?f=3&t=14430 That is an Acorn / BBC forum although I've been posting updates there as new machines are supported

Alternatively we could start another thread here.

BTW If you want to experiment with the existing scaler I have blank pcbs and I also had some boards made up in China.

[c0pperdragon]

I just went forward, creating a new Github project with issue thread an all: https://github.com/c0pperdragon/Atari-Digital-Video

[c0pperdragon]

Concerning the original power-up problem: I don't think swapping out the VIC will actually help. Especially the strange way the FPGA creates the faulty back porch leaves me only with this conclusion: The FPGA itself is malfunctioning. I just can not conceive any external input by which the FPGA could be tricked into doing this.

Considering the way this malfunction is determined at power-up time, it must be some problem during the initialization process, where the configuration of the logic fabric is copied from the on-chip flash. Given that there are just two possible states (rock-solid working and rock-solid faulty) it is probably just one single bit of the whole configuration that can come up in one of two states.

I do not know any details about the inner working of this process (is there any kind of error-correction involved?), but I guess the reason could either be a physically faulty flash memory cell (not much to do but replace the part) or the relevant data bit is just in a half-between state. In the second case you may just be able to re-flash the firmware to fix the problem.

For re-flashing you need an USB-Blaster device. If you do not already have one, they can be found quite cheaply on e-bay and as far as I know even the cheapest clone device just works fine.

[IanSB]

Some further updates:

I received a 6569R5 and that has the same random left shift as the 6569R1 with V2.6 firmware (not seen on 2.7 so far) so that indicates it's not the VIC II. That plus aknightin comfirming the same issue with the same revision board indicates it's not a board fault so it may well be down to differences with the discrete clock circuit.

In addition I got the same pixel glitches as aknightin with the R5 (see other issue for a possible fix https://github.com/c0pperdragon/C64-Video-Enhancement/issues/38)

[IanSB]

There is still a problem with random power up issue on v2.7 but it is slightly different now. Previously the image was shifted to the left and the background in games was messed up, now there is no shift left but the background in games can still get randomly messed up. Again power cycling fixes it. This is the same as my first post with v2.6 firmware but with v2.7 there is no left shift which is actually worse as you don't know immediately that there is a problem until you run a game.

[c0pperdragon]

As complex and diverse the symptoms are (messed up image, sparkly pixels, shifted display in firmware 2.6) there is surely one common cause to all of this. More specifically it seems to always be determined at power up.

My vage idea about the problem is this: The mod continously measures the CPU frequency to detect if it is an NTSC or a PAL-B machine (with PAL-N and PAL-M variants also using the same CPU clock as NTSC). In case of NTSC it needs to reprogramm the PLL which subdivides the CPU clock into pixel clocks, (the default PLL setting is PAL). But this reprogramming is currently a one-way operation and the mod can not switch back to PAL. So if for some reason the CPU clock runs faster than 1.04 MHz for a millisecond, this switching to NTSC timing happens which then stays active until power-off. So the hypothesis here is that the discrete clock circuit in your is running too fast for some time after power up before it can settle to the correct frequency. But not even this is yet established. I really need the exact time measurements of the video output as requested in https://github.com/c0pperdragon/C64-Video-Enhancement/issues/38

[c0pperdragon]

Fixed with firmware release 2.8