General discussion

[c0pperdragon]

I have set up this thread as a forum to discuss the options with @IanSB concerning the use for the RGBtoHDMI project.

[c0pperdragon]

To define the scope of the project I would only consider the Atari computers. C64 already works and my latest ZX Spectrum board can natively output RGsB which should be easy to use with the RGBtoHDMI.

[c0pperdragon]

A straight forwar solution is a connector with 8 pins for the color, one csync and GND and +5V. This could then directly drive an RGBtoHDMI or being converted to YPbPr with an external adapter. I want this option so I can use it with other upscalers.

[IanSB]

A straight forwar solution is a connector with 8 pins for the color, one csync and GND and +5V

Yes, RGBtoHDMI already has a 12 way IDC header with the following pinout:

Pin 1 X1 (Bit 6) Pin 2 X2 (Bit 7)   Pin 3 GND   Pin 4 Bgreen (Bit 4) Pin 5 Bred  (Bit 3) Pin 6 Bblue (Bit 5) Pin 7 RED (Bit 0)  Pin 8 H/CSYNC  Pin 9 GREEN (Bit 1) Pin 10 VSYNC Pin 11 BLUE (Bit 2) Pin 12 +5V

They are arranged in this order because if you connect a ribbon cable from Pins 3 - 11 to a 9 way IDC 'D' type connector that is the correct pinout for IBM PC MDA, CGA and EGA adapters. (It was originally a 10 way connector and X1 + X2 were added later to make 8 bits)

One possible addition would be to put the pixel clock on the unused pin 10 (VSYNC) as that might allow for the possibility of connecting the signals directly to the Pi's GPIO header bypassing the CPLD for a minimal cost solution. (The CPLD is primarily used to regenerate a pixel clock with the correct phase). The pixel clock might be useful for any external DAC as well.

It would also be possible to communicate with the scaler by outputting data on the 8 pins during sync periods.

C64 already works and my latest ZX Spectrum board can natively output RGsB which should be easy to use with the RGBtoHDMI

It might be useful to add 4 bits + sync + pixel clock onto some unused pins on their FPGAs for experimental purposes.

One possible change to the C64 FPGA that might also be useful would be to add an additional option to address 53311 to switch the YUV output to the special palette and back again so you don't lose the saved palette. The YUV levels required by RGBtoHDMI can be generated procedurally so no need for another table. To switch to special RGBtoHDMI mode that would be something like:

POKE 53311,xxx (where xxx is the number to switch to RGBtoHDMI mode) flip switch POKE 53311, 138

To switch back to normal palette POKE 53311,137 flip switch POKE 53311,138 (That would also ensure that reprogramming the palette would switch back to normal mode)

[c0pperdragon]

Concerning the C64 - maybe it would the best thing to just provide a digital header on the mod board. It may be a bit tricky to squeeze this into some corner, but then all the messing around with the palette would be unnecessary. You could install a digital port (3.3V logic levels) to some convenient place on the case just in addition to the YPbPr output.

Are you sure about the pixel clock? This somehow feels a bit out of place for a digital video interface right out of the stone age of computing ;-) Just providing a 3x2 optional pin header with GND, CSYNC, D0 - D3 seems more fitting.

I can easily modify the firmware to send these signals to some pins, and also modify the board layout to have this option. Then you would need to have such a PCB made and populate it yourself, as we will for sure not do a second production run in the forseeable future. Of course you could also try to solder wires directly to these FPGA pins - but I would not be able to do this.

[c0pperdragon]

For this new Atari modification, I envision to use a CPLD that can directly accept 5V input level. It may run with 3.3V itsself and will also output 3.3V levels.

Because the GTIA chip already directly generates the 4 luminance bits and the CSYNC, the CPLD would only be responsible to generate the 4 bits for the color signal. Internally this saves only a small amount of logic because all the complicated sprite handling is still necessary. But maybe it just enough to squeze the logic into some of the smaller CPLDs. One side effect of this is that the CPLD would not be able to generate a proper pixel clock itself. The Atari graphics system is basically designed around low-res pixels with a 3.54 MHz (PAL) pixel clock. This is also the highest frequency to be found anywhere inside the Atari machines. To generate high-res pixels, the GTIA outputs different luma signals for both halves of the pixel clock. The color signals on the other hand can only ever change at the begin of one full pixel clock, so it can be easily done by logic that is driven by the pixel clock.

To bring the signals (8 data, 1 csync) and power to the exterior of the device, some detachable connector is needed. And IDC header is just not the right thing for a case-mounting. Maybe a DSUB-15 as this seems to be readily available?

[IanSB]

One side effect of this is that the CPLD would not be able to generate a proper pixel clock itself.

The pixel clock is not essential, it was just an idea if it was available already but if it is difficult to implement then it doesn't matter as the scaler doesn't need it.

And IDC header is just not the right thing for a case-mounting. Maybe a DSUB-15 as this seems to be readily available?

I like IDC as it makes it easier to build cables, in this case it would be 12 way IDC to 12 way IDC ribbon

15 way 'D' rather than DSUB might work if it will fit as you can get IDC versions

[c0pperdragon]

I just got an idea about digital signals for the C64. Using the current mod you could actually tap into the various resistors that form the output DAC. These are SMD parts, but not that small so it should be possible to attach wires. So you could actually keep the YPbPr signal unmodified and at the same time extract digital data.You should run the signals through a buffer IC first to avoid coupling noise into the analog signal. With this solution you don't need to create your own custom mod kit but can use the readily available one.

Unluckily with the default palette there is no set of 4 pins to always uniquely specify the color. I did some computation and there is a possibility with 5 pins, but this is quite convoluted and depends on the very exact palette setting. The cleanest solution would be to take the 4 most significant bits of the Y output together with the most significant bit of both Pb and Pr. CSYNC can also be extracted directly. As you have already some systems with a 6-bit input this is probably no big deal for your system.

[c0pperdragon]

Hi! I just had an idea that may (if it actually works) become the best and most cost-effective upscaler solution there is. Is it possible to directly team up the TVP7002 video digitizer chip with the Raspberry Pi Zero? This chip is used in the front-end for the OSSC and has a built-in PLL to sync to any given pixel/line ratio and also outputs the pixel clock alongside the data.

As you have mentioned earlier, having a pixel clock allows the Raspberry Pi to take in the samples directly without additional hardware. And as you also said, genlock is possible, so this could become a very powerfull general upscaler with very low lag. I don't know how far this can be pushed. Would 24 bit color depth with a 640x256 input signal be possible? I would love to actually use this with my Amiga.

[IanSB]

I just got an idea about digital signals for the C64. As you have already some systems with a 6-bit input this is probably no big deal for your system.

I will do some experiments with that later but for now the analog connection is the easiest as it just plugs into the existing connector so maybe the only thing to add at the moment would be the rapid palette output switch I mentioned above.

Is it possible to directly team up the TVP7002 video digitizer chip with the Raspberry Pi Zero?

There are several problems: There might not be enough GPIO pins on the header for 24 bit bus + supporting signals and if the 24 bit bus is multiplexed that increases the data rate to be clocked into the Pi's GPIOs.

The main issue is that the Pi's memory access time is unpredictable and can sometimes be high latency which is not good for real time capture. To get it working with even these limited bit depths required things like instruction re-ordering and register swapping to make use of processor optimisations.

One thing I intend to look at is using the GPU/VPU to capture the incoming data (effectively a FIFO) but the GPU processors are not well documented so that may take some time. Using an external hardware FIFO might help but that would require more GPIO accesses and they are relatively slow too.

The Pi2 and Pi3 perform even worse as their uncached memory access is slower than the Pi zero. The extra cores don't help because if you capture with one core and write with another core you get stalls on contended memory access and cache coherency updates.

The current system has a 12 bit bus from the CPLD to the Pi on the GPIOs for pixel data and that clocks in 4 pixels at a time in 3 bit capture mode, 2 pixels in 6 bit mode and 1 pixel in 8 bit mode. This could be increased to 1.5 pixels in 8 bit mode.

The max pixel clock in 6 bit mode writing to an 8 bit buffer is ~29 Mhz and I have been able to capture 640x480 @ 60hz at that bit depth from a VGA card which also had an EGA TTL connector.

This max pixel clock in 8 bit mode is currently ~14Mhz as the data rate on the 12 bit bus is doubled compared to 6 bit mode. That should be enough for the Atari but not any computer with a higher pixel clock.

Increasing to 24bits per pixel and 32 bits deep framebuffer may be impossible on the zero although it might work on the Pi 4. Certainly some things to investigate in the future.

[c0pperdragon]

About C64 palette swapping: It is a bit of a pain to put more features into the register handling subsystem. Even the extra bit to turn off sync output was quite a hack already.

But maybe you could like the following idea: You can switch to the special palette buy placing a jumper link on a specific position of the JTAG header (I need to check this actually works). Or add some additional wire to the mode switch (soldered from below - that may be tricky) to actually get a 4th output mode.

[c0pperdragon]

Clocking in such amount of data via the GPIO headers using only the CPU is surely a pain, especially when these variable timings are involved that come from using RAM with caches.

On the other hand, the current (and cheapest) version 1.3 of the Raspberry Pi has a high-speed data interface which is meant to be used with a camera. This would handle all we could ever throw at it with ease. But then of course some intermediary IC is needed to translate between the video digitizer (parallel protocol) and the DSI port (serial). Anyway this solution could be the most simple and not even requiring hardware-level programming on the Pi.

[IanSB]

You can switch to the special palette buy placing a jumper link on a specific position of the JTAG header (I need to check this actually works). Or add some additional wire to the mode switch (soldered from below - that may be tricky) to actually get a 4th output mode.

Yes that would be great.

[IanSB]

version 1.3 of the Raspberry Pi has a high-speed data interface which is meant to be used with a camera.

Yes I have considered that, but this is a bare metal project (no OS) so you have to find enough documentation to write a driver for it.

https://github.com/hoglet67/RGBtoHDMI/issues/104

[IanSB]

Have you used JLC PCB assembly service? They are very low cost but only build single sided SMD and only use components they have in stock. I redesigned the analog board for RGBtoHDMI to use only their stocked components and had a batch of 10 assembled very cheaply at about 25% of the cost of getting the original board built. It worked out cheaper than buying just the components for the original design from local suppliers! I also designed with smaller components as I didn't have to build them by hand.

Top is original design, bottom is JLC built design (they are functionally identical)

For this new Atari modification, I envision to use a CPLD that can directly accept 5V input level.

They do stock some CPLDs & FPGAs so if there is anything suitable in their list and they have many of them in stock it might be worth using it in the design, you can get 5 boards assembled for very little. (Even if it requires level shifters, they probably have those as well and adding such things to the assembly costs very little)

https://jlcpcb.com/parts/componentSearch?secondSortUuid=2590dc36ffbf46f29848c82fc031db2e&name=CPLD%20%26%20FPGA&firstSortUuid=4f1daf13964c440f895f56f72c7fe247

[c0pperdragon]

Hmm, these parts look pretty well made. But for my own hobby projects and prototypes I prefer to assemble the boards myself. Actual soldering is my main enjoyment in this hobby. As a decades-long software engineer I am a bit sick of all this computer screen work, so I try to get a better ratio of planing/programming vs. manual work.

[c0pperdragon]

Convering the C64 firmware: I am pretty confident that I can use the JTAG pin and it would then work like this: If you bridge pin 9 and 10 the mode select switch position that would normally select "line double with scan line effect" will then select "normal lines with special high-contrast palette". This would have the least impact on the overall usability as this seems to be the least used output mode anyway.

[IanSB]

If you bridge pin 9 and 10 the mode select switch position that would normally select "line double with scan line effect" will then select "normal lines with special high-contrast palette".

Sounds good

But for my own hobby projects and prototypes I prefer to assemble the boards myself.

Yes I like building the hobby projects but not building lots of the same thing for friends as my eyesight is no longer so good. Anyway if JLC have something in stock that is suitable, no reason not to use it as it leaves the option open.

[c0pperdragon]

Once more back to the Atari: Somehow I am reluctant to start this completely new project when my already existing Atari component video mod already works so nicely. I now think of reworking the FPGA board in a similar way as for the C64 so it will fit better and use existing holes in the case. For my Atari 800XL this is easy, as I have it myself. Probably it is more complicated for other models - this mainly depends on which types of RF modulator were used.

By using existing holes only I would again go for the solution with the TRRS jack and the mode switch.

To support your upscaler in a similar way as we now plan for the C64, we would need to find a way to squeeze the pixel data through the analog data path. This is not so hopeless as it may seem, because the Atari has quite hard restrictions on which colors is can produce. Basically it can only have a different chroma for every two pixels and the luma is mostly restricted to 8 different levels (there is just one special mode with more lumas but then both pixels of a pair are identical). Summing the possibilities for one pixel pair: 1616 + 168*7 = 1152 As far as I understand your analog interface, it can distinguish 27 different R/G/B possibilities. Combining two pixels gives 729 possibilities. That is awfully close to the target (missing only half a bit or so). But maybe I did misunderstand the schematics and you can actually pass more information? Or maybe you can somehow utilize the sync level to transfer this missing data?

[IanSB]

Once more back to the Atari: Somehow I am reluctant to start this completely new project when my already existing Atari component video mod already works so nicely.

OK no problem

As far as I understand your analog interface, it can distinguish 27 different R/G/B possibilities

If an extra comparator (U7) is fitted it can distinguish 64 levels (4 each for RGB or YUV) so that might solve that problem. I already use that option for the TI99/4a. This would then actually capture at 6 bits per pixel plus there would have to be some extra software to decode those combinations according to the restrictions you mention above.

[c0pperdragon]

A had a second look at your analog board and noticed that there actually is the possibility to distinguish onre more level of the R and B lines. So you can differentiate 48 possibilities which give 2304 per pixel pair.
Now this is actually possible and we can even come up with some self-synchronizing encoding to always know which pixel is what.

[c0pperdragon]

Our comments just crossed each other. With true 6 bit per pixel (is it really possible to also get 2 bits from the G line?) encoding and decoding would become even simpler, I guess.

[IanSB]

With true 6 bit per pixel (is it really possible to also get 2 bits from the G line?) encoding and decoding would become even simpler, I guess.

Yes, The comparator connected to the Vsync input which normally detects the sync in YUV mode can also be used to provide the missing level in full 2 bit mode. In that case you have to connect the separate Sync input (normally used for RGBS) to the Y input so that there is still a sync source.

So you can have: 3xY, 3xU, 3xV for 27 levels normal operation 4xY, 3xU, 3xV for 36 levels (requires sync input connected to Y) 3xY, 4xU, 4xV for 48 levels (requires U7 fitted) 4xY, 4xU, 4xV for 64 levels (requires U7 fitted and sync input connected to Y)

[c0pperdragon]

Basically all options execpt the first would be possible. Whatever is the least hassle for you, as for me it is just a matter of fimeware programming. And in my current Atari FPGA there is plenty of room for additional features.

[c0pperdragon]

With just fitting the U7 (so the cable from the C64 can be re-used) we get 2304 possibilities. This is due to some strange coincidence exactly the double of the 1152 possibilities needed for a full pixel pair. So I guess it should really be possible so encode some kind of alignment-marker to know where a pair starts. This should make the decoding processs easier.

[IanSB]

Whatever is the least hassle for you, as for me it is just a matter of fimeware programming

The decoding algorithm needs to be very simple, ideally just logical operations, bit shifts, adds, subtracts, compares etc, no tables or multiply/divide. It could use small tables if they will fit in the level 1 cache.

[c0pperdragon]

So, the C64 firmware change is done. It works as proposed: After flashing the firmware, you can bridge pin 10 an 9 on the JTAG header to activate this special palette when also shifting the mode switch to the position nearest the power LED. I just made up a palette that only uses minimum/middle/maximum values for all three lines (plus the sync in the case of Y). I tried to chose combinations that best fit the original colors, but of course this is not always possible. At least black, middle gray and white are correct. The other grays will look rather cyan, I guess.

You can download the firmware from https://github.com/c0pperdragon/A-VideoBoard/tree/master/c64mod/experimental I trust, you have a USB-Blaster already? Or you can get one with reasonable effort? Please let me know if this works, and also if it solves the startup problem (which, if still existing, should manifest itself in a very different way as the compressed configuration data is now quite different).

Using the JTAG pin was quite a tricky business, and I nearly disabled the JTAG feature permanently. But now everything works fine and later re-programming is still possible without additional measures.

[IanSB]

I just tried this and it works great! I had to update my palette translation to match your new high contrast colours but everything looks OK so far. I have not seen a startup problem yet but not power cycled many times so far so will keep testing.

[IanSB]

I now think of reworking the FPGA board in a similar way as for the C64 so it will fit better and use existing holes in the case. For my Atari 800XL this is easy, as I have it myself. Probably it is more complicated for other models - this mainly depends on which types of RF modulator were used.

Maybe you could put multiple positions for the TRRS connector on the edge of the board?

[c0pperdragon]

As the C64 tasks seems to be done now, I can more focus on the Atari.

Because I have a perfectly working solution for my own machine already, I have actually not so much need to design a completely new hardware. The board I am using is one of my A-Video boards and the adapter for the GTIA chip is a bit of a hack, but works also nicely.

In order for other people to use the mod, this adapter is not really convenient, so I will design a new one based on the same schematics, but it will look much more like the one for the C64. I guess you could have such a board made by your manufacturer.

For the FPGA board there are already two compatible options available: The A-Video board (3 RCA jacks, external mode switches) and the C64-Board (TRRS jack and integrated mode switch). As there are quite some different variants of Atari machines which would work with this mod (everything with a GTIA chip) the best way to install the board should be decided by the owner based on individual preference. The C64-Boards are readily available at VideoGamePerfection and I happen to have a spare A-Video board which you could have for the cost of the parts (about 20€) and shipping (from Austria).

Next step for me is the design of the adapter. I hope I can squeeze the 4 inverter chips into the frame of the IC socket.

[IanSB]

Someone else is trying your board with RGBtoHDMI and has the same left shift problem on power up. He also has a 6569R1 so it seems to be a definite problem with that chip https://stardot.org.uk/forums/viewtopic.php?f=3&t=14430&start=1140#p279622 I have sent him the new FPGA link to see if that fixes but I think he will also change to a 6569R5 It is actually quite difficult to use with a 6569R1 anyway as that needs a big heatsink and the adapter board interferes with that.

Could you check that the numbers I have used in the programs for setting the high contrast palette and restoring the normal c64 palettes with old FPGA firmware are correct: https://github.com/IanSB/RGBtoHDMI/wiki/Cables (See bottom of page)

I might be interested in the A-Video board but I think I would remove the phonos and wire in a trrs. Can the A board and the C64 board be used on the C128 (with the 48 pin C128 adapter)?

Are you going to build an RGBtoHDMI? If so do you want any blank pcbs or are you going to order a batch from China?

[c0pperdragon]

That there is another user with the same shifted display now is actually a good thing. At least that rules out a random malfunction of the FPGA. I still can not figure out how this can even happen, but if both the new firmware as well as swapping out the chip solves the issue, I am fine with that. If that is truly the case I will document this behaviour on the project page. I would be very kind if you could do some more testing nf the matter. Specifically if replacing the chip already solves it with revision 2.6 and if 2.7 with the R1 chips is also fine.

One thought about the independently occuring sparkly pixels that 'anigthin' reported which worsen over time: The mod generates its internal pixel clock from the cpu clock by waiting for an edge and then using its own time source to decide when to start which pixel. The last pixel of a group of 8 will then take up the slack and become a bit longer or shorter. When the input frequency is too far off spec this uneven distribution of pixel times may well screw up your digitizing process. The proper way to do it is of course using a PLL, but the FPGAs PLL can not lock to a 1 MHz input. If there is indeed a drifting clock (you can probably tell by directly measuring pin 22 of the VIC) you will not be able to change this by replacing the VIC. In this case I need to come up with a better way of subdividing the CPU clock.

[c0pperdragon]

Could you open a issue thread on the C64 video enhancement thread about the matter of sparkly pixels and notify the "anightin" on this, because I do not want to use the stardot forum for this purely C64-related issue.

[c0pperdragon]

I just checked the list of color values on your screenshot. Yes, these are exactly my original colors. A bit too bright for the taste of purists - but I like it :-)

[c0pperdragon]

More answers to previous questions: I am not going to build at RGBtoHDMI upscaler myself. I am more interested in making (or even buying - but only as a last resort) a general analog video upscaler solution. The idea to use a Raspberry Pi is very interesting as it really has so much power (and is probably much much cheaper than the upcomming OSSC Pro).

Replacing the RSA jacks should be fairly straight forward. You can also connect a mode switch (2 or 3 way) to the GPIO2 header. To make the system in line with the C64 solution, you will also be able to activate the special "digital" palette with a jumper on the JTAG headers. In this way the C64 board can also be used for this purpose.

Support for the C128 is very much in doubt yet. I have actually designed an adapter board which may work (can not tell because I don't have a C128). But as I have received zero feedback from the community yet, I just can not say how the signals are really generated by the VIC-II E and if this in any way compatible. Actually it would be very cool if you would try. Mouting space is probably an issue as even with an removed RF-modulator the C64 board does not fit. Maybe the A-Video board could fit, but then there is no working signal on the A/V port any longer. Or you screw the A-Video board on top of the RF can. Or you indeed cut down the metal can of the VIC to squeeze the C64 board in. Or whatever floats your boat ;-) Of course before taking such exreme measures, you could very well just try it with an C128 adapter and run the ribbon cable to your existing C64 (don't forget to also connect of the grounds of both machines!)

[c0pperdragon]

Now I even have a question of my own: Do you know if it is possible to do genlock of the Raspberry Pi's HDMI video also when programming it with a "normal" operating system?

[IanSB]

Do you know if it is possible to do genlock of the Raspberry Pi's HDMI video also when programming it with a "normal" operating system?

I've not looked at this but it should be possible if there is an API call to change the HDMI clock, if not you would have to write a driver to directly access the registers to change the clock. You would also need to compare the incoming vsync with the HDMI vsync and there is already a HDMI vsync interrupt.

[c0pperdragon]

So, I have designed a new GTIA adapter for the Atari which you can have manufactured. I have tried to mainly use parts that JLCPCB provides. I guess the very special DIP 40 socket is not in their list, but they would not do the installation anyway because it is such an unusual and quite tricky business. Everything regarding the Atari mod is now available at: https://github.com/c0pperdragon/A-VideoBoard/tree/master/atarimod

If you want my spare A-Video board, please let me know your post address. Postage inside the EU it will cost about10€, outside 15€. Add this to the 20€ for material cost and send it to my paypal account: reinhard.grafl@aon.at . If you do not have a paypal account yourself, we need to find other options.

The board does not contain a proper firmeware yet (I took it out from Spectrum when designing its specific mod kit). I plan to work on the atari firmware again in a few days while the material is on the way.

[c0pperdragon]

No as I have given up the idea of the general upscaler, I would really like a solution to upscale my ZX Spectrum, C64 and Atari computers. My prefered solution would be to design a board the sits on the Raspberry Pi Zero and integrates the functionality of your Analog circuitry and the CPLD. The input connector would be a TRRS jack, so it can be directly plugged to any of my relevant machines. Maybe add some buttons to switch input and output mode. Would you also be interested in such a board? I would like to manually assemble these, but maybe we could share the cost of PCB manufacturing.

[IanSB]

My prefered solution would be to design a board the sits on the Raspberry Pi Zero and integrates the functionality of your Analog circuitry and the CPLD. The input connector would be a TRRS jack, so it can be directly plugged to any of my relevant machines.

What's the problem with the existing design? It fits into a readily available Pi zero case and so has easy access to all the Pi's ports and SD card slot.

[c0pperdragon]

Hmm, this package is actually quite neat. The only thing I don't like is the aesthetics of the ribbon cable. Somehow I feel that ribbon cables should only be used inside the case. I think I will just build my own cable with a more consumer-grade look ;-)

So the question now is: Would you sent me the two boards? I will take care myself to get the Pi, the case, the microSD card and make my own cable. But I have no equipment to re-program the CPLD. Is it already able to be configured to a different pixel clock from the Pi so it will eventually work with all my machines?

As you have previously mentioned, you would like my spare A-Video board, I guess we could just arrange a direct exhange. Do you think this would be a fair trade?

[c0pperdragon]

Now back to the Atari video signal: For the most straight-forward solution, I would propose to actually use the analog board to its full potential. That means it needs to accept 4 levels for R, G, B each in addition to sync. With this the color encoding could be done in a way that even on an analog YPbPr receiver, the image would be somehow reconizeable.

I would work like this: The 4 levels of Y specify the two most significant bits of the brightness. The 4 levels of Pb and Pr specify 2 bits each. The least significant bit of each will be used to form the lower 2 bits of the brightness. The 4 bits needed to specifying the color of a pixel pair can be taken from the higher bit of Pb and Pr of both pixels.

I guess by choosing the best way to encode the color with this 4 bits, the resulting YPbPr could somehow look a tiny bit like the real color. Specifically black, is exactly black which is important for a proper blanking signal.

This scheme relies on the Pi to know which two pixels belong to one pair. As the sync signal from the atari mod is also clearly pixel-aligned and everything is totally determinstic in this respect it should be fairly easy.

[IanSB]

I think I will just build my own cable with a more consumer-grade look ;-)

There is an option on the analog board for an internal molex picoblade connector instead of the external IDC connector. You cut off the tab where the IDC connector is soldered and then fit the picoblade instead.
I like IDC because I hate making cables :-)

Would you sent me the two boards?

Sure.

I have bare boards, assembled boards and bare boards with component kits.

But I have no equipment to re-program the CPLD.

The Pi reprograms the CPLD and there are different CPLDs for RGB mode and YUV mode

Is it already able to be configured to a different pixel clock from the Pi so it will eventually work with all my machines?

There is a profile system that allows you to change to different profiles with totally different clock rates and everything else. See the Wiki documentation: (not 100% complete but mostly finished) https://github.com/IanSB/RGBtoHDMI/wiki/Quick-Start-Guide https://github.com/IanSB/RGBtoHDMI/wiki/Reference-Guide https://github.com/IanSB/RGBtoHDMI/wiki/Tutorial-on-Adding-a-New-Profile

As you have previously mentioned, you would like my spare A-Video board, I guess we could just arrange a direct exhange.

I will email you shortly.

[c0pperdragon]

I guess I will go all-in with my TRRS solution and just mount a TRRS jack instead of the IDC. So I don't even need to make my own cables.

I do not quite understand what "different CPLDs for RGB and YUV" meains. Is this really a different hardware? So you need a different digital board? In any case I am now primarily interested to attach my various YPbPr modded devices, so I will only need the one flavour.

[IanSB]

I do not quite understand what "different CPLDs for RGB and YUV" meains

It just means that YUV sources require you to go to the menus and select the YUV CPLD to be programmed and RGB sources require the RGB CPLD to be programmed. You can change over any time. The CPLDs just have different features that help with RGB or YUV type signals, e.g the YUV CPLD has PAL switching so it will work with the Spectrum YUV output where the R input inverts on every other line. All the features wouldn't fit in the CPLD at the same time.

[c0pperdragon]

So it is actually the same CPLD (the physical chip), but it needs to be reprogrammed. Is this the same way of soft RAM-based programming that FPGAs support? Or is there a flash memory inside the CPLD which would wear out over time due to extensive reprogramming?

[IanSB]

Or is there a flash memory inside the CPLD which would wear out over time due to extensive reprogramming?

It's flash memory but it's rated for 10,000 cycles (27 years at 1 reprogram a day)

Technically you could make an RGB profile with the YUV CPLD or a YUV profile with the RGB CPLD as long as it didn't require any of the special features of each CPLD design.

EDIT: Sorry, by "CPLD" in earlier posts I meant CPLD design file

[IanSB]

I would work like this: The 4 levels of Y specify the two most significant bits of the brightness. The 4 levels of Pb and Pr specify 2 bits each. The least significant bit of each will be used to form the lower 2 bits of the brightness. The 4 bits needed to specifying the color of a pixel pair can be taken from the higher bit of Pb and Pr of both pixels.

This sounds reasonable and would be easy to decode.

This scheme relies on the Pi to know which two pixels belong to one pair. As the sync signal from the atari mod is also clearly pixel-aligned and everything is totally determinstic in this respect it should be fairly easy.

Some of the other capture profiles already require pixel accuracy. e.g the BBC micro teletext mode deinterlacing algorithm requires pixel accuracy and there is already an automatic alignment function to set that up on first installation which does a statistical analysis of the incoming video to determine where the text characters are positioned. (The sync to pixel start varies depending on the manufacturer of the 6845 and video ULA).

[c0pperdragon]

I have just finished the adjustments to the firmware and also fixed an old bug on the way. https://github.com/c0pperdragon/A-VideoBoard/tree/master/atarimod/firmware

I did not bother to find some color encoding that somehow looks "best" when viewed with a normal YPbPr device. The most significant bits of the Pb and Pr signals from a pair of pixels just directly encode the "hue" part of the color. The order is (from most to least significant bit of the hue): Pb1 (pixel A), Pr1 (pixel A), Pb1 (pixel B), Pr1 (pixel B).

The bits for the luminance of a pixel can be found (from most to least signifacnt bit): Y1, Y0, Pb0, Pr0

If you notice that the least significant bit of the luma seems always to be 0, that is because this bit is only ever used by the GTIAs 16-shades mode. This is normally only used to create some very low-res 16-graysale images. And can normally not be seen in games or such. In BASIC this is available with Graphics mode 9.

[c0pperdragon]

Hi @IanSB I finally soldered the CLPD board and the analog board, and after quite some trouble (mainly because of my stupidity) it now I can at least power it on and program the CPLD. I want to connect it to the C64 and am using the beta3 firmware for the RPi which should support the C64 - at least there is a profile for it in one of the folders. My problem now is that I can not select this profile. I can only select through the profiles that are stored in the 6-8_BIT_RGB_Analog subfolder, while the C64 profile would be in the 6-8_BIT_YUV_Analog folder. But I don't think just copying the file over should solve this, I guess. Otherwise what would be the point in having different folders in the first place So maybe you can enlighten me on this matter?

[c0pperdragon]

As i expected, copying the file does not work. I now get a C64 option, but it will not work when selected. During all the time I get a "No sync detected" message in the main menu. Which should not be surprising, giving the software probably expects sync to come on the dedicated sync input line (which I have connected to GND, as specified in the cabling description).