[FR] Support for external RGBtoHDMI upscaler

[c0pperdragon]

[FR] Support for external RGBtoHDMI upscaler

[randyrossi]

Hi. Yes, that does sound like an interesting (and useful) alternative for video output. I like the idea of repurposing the RF jack for a single wire protocol. It would only make sense for a POV since the colors are fixed by the external RGB2HDMI board (my enhanced VIC-IIs can change the colors and also have hires modes). Just so I understand things correctly, the RGB2HDMI board needs a .7Vp-p analog signal operating at 2x the dot clock (4 levels of luma, 2 bits per pixel resulting in 16 values for each pixel)? Sync signal would be 0V? I can reprogram one of the pins on the RGB header on my large board prototype to do this already. There is a 6-bit DAC on each pin. So I could try this out with my existing hardware I think. I don't have a RGB2HDMI board though so I could only look at the signal on an oscilloscope.

…

On Mon, May 23, 2022 at 7:01 AM c0pperdragon ***@***.***> wrote: What do you think about a very reduced variant of the Kawari (nearly POV) that has just one cheap additional output possibility besides the luma/chroma ? This output signal would be a simple 75 ohm terminated video signal that could encode the 16 C64 colors in the necessary resolution using luma only. This properitary signal could then be easily interpreted by an external RGBtoHDMI to generate perfect HDMI from it. Re-purposing the RF out jack, this signal could be brought of the the case without drilling holes and by just cutting a single wire and maybe attaching a clip-lead to the RF jack. IanSB already modified the RGBtoHDMI software to support such a signal, and I built a proof-of-concept setup and this looks really pretty easy. Have a look at our discussion here: hoglet67/RGBtoHDMI#258 <hoglet67/RGBtoHDMI#258> — Reply to this email directly, view it on GitHub <#1>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAI3HKANEXAPFKKPFLSOII3VLNQRTANCNFSM5WVN7U5A> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- Randy Rossi - "There are only two things that are hard about computer science; Naming things, Cache Invalidation, and Off-by-one errors."

[c0pperdragon]

Yes, you got it exactly right. The precise signal levels are not all that important because the RGBtoHDMI can fine-tune all comparator voltages programmatically. It is only imporant that the voltages are consistent so there is no need to recalibrate everything all the time.
In my experiments I just tried to get as close as possible to nominal 300mV sync and 700mV luma levels. In this way the signal can be directly fed into a composite TV to have a first impresson on what is going on.

Availability of the RGBtoHDMI is a real problem right now. Not only the Raspberry Pi Zero but also the CPLD chip and even the necessary DACs are unavailable. So I could not even build a new device to let you test anything of this. I only have the one I am using myself.

I basically just wanted you to know about this idea to take this into consideration
Also I don't know about your plans to support 80 columns mode. This would be somehow in conflict with how of the luma-code signal now works, as it could not easily go beyond the standard C64 pixel clock speed.

[Icelvlan88]

@c0pperdragon, did you ever get this going? Would be awesome to have RGB or component from your board and HDMI as well. Maybe RGB/component from composite connector areas and then micro hdmi from the small port beside.

[randyrossi]

I purchased a RGBtoHDMI hat for the pizero and will see if I can get this working with the Kawari. Looks like the luma signal should go directly from the VIC-II pin to both G and SYNC inputs on the hat. The Kawari already has a 4x dot clock driving the luma levels so it should be trivial to change the generator to encode the 2 x 4 levels required to encode the 16 index values. There's probably plenty of room on the Mini to make it software configurable (i.e. enable lumacode flag) in the firmware. Not sure about the large as there is very little room left in the fabric for more features, but not really essential since it already has direct DVI out anyway. I'll update this thread on progress once the hat arrives.

[randyrossi]

@c0pperdragon Would your RGB board mentioned in Issue #25 be capable of interpreting lumacode? I just commented on that issue noting that it's not surprising the Kawari does not work with c0pperdragon RGB adapter. The adapter probably has some expectations on the timing that the Kawari doesn't replicate exactly. But it seems to me a more straight forward solution would be for the Kawari to encode something like lumacode via the luma pin and perhaps add a feature to this RGB board to be able to interpret it rather than trying to sniff the data/address and control lines to mimic the output. Any thoughts?

[c0pperdragon]

Yes. The timing my component video adapter expects is a result of direct measurements of the VIC-II's behaviour as well as some additional tweaks done to increase compatibility with some C64 add-on cartridges that also have their own way of messing with the VIC-II. So it is pretty complicated already and I will surely not touch this fragile construction.

I am not quite sure how you envision the use of the luma pin, but my board has no connection to any of the analog outputs, so it can not interpret this. In any case, the FPGA is so completely full that there is just no space for any new features. It was a nightmare to get all the user-requested features added that arrived over time and I had to restructure the logic serveral times already to squeeze a little bit of additional logic into the part.

Speaking of lumacode: My new and shiny VIC-II-dizer will probably have the same troubles matching your timings. But when the Kawari can produce proper Lumacode on the A/V output port, an external RGBtoHDMI could produce a HDMI signal. I don't know how noisy such a signal would be, because it would use the original C64's video amplifier. Testing would be necessary.

[randyrossi]

Yes, I was going to try outputting lumacode directly from the Kawari and not have the luma signal reach the video amplifier circuit by placing another socket underneath with a 'tap' to luma. I should be able to feed the luma signal directly into the RGBtoHDMI hat green/sync inputs, right? Or perhaps I need a 75ohm termination to get the 1v p-p? I am waiting for a RGB2HDMI hat to arrive to try it out.

…

On Sat, Oct 28, 2023 at 4:03 PM c0pperdragon ***@***.***> wrote: Yes. The timing my component video adapter expects is a result of direct measurements of the VIC-II's behaviour as well as some additional tweaks done to increase compatibility with some C64 add-on cartridges that also have their own way of messing with the VIC-II. So it is pretty complicated already and I will surely not touch this fragile construction. I am not quite sure how you envision the use of the luma pin, but my board has no connection to any of the analog outputs, so it can not interpret this. In any case, the FPGA is so completely full that there is just no space for any new features. It was a nightmare to get all the user-requested features added that arrived over time and I had to restructure the logic serveral times already to squeeze a little bit of additional logic into the part. Speaking of lumacode: My new and shiny VIC-II-dizer will probably have the same troubles matching your timings. But when the Kawari can produce proper Lumacode on the A/V output port, an external RGBtoHDMI could produce a HDMI signal. I don't know how noisy such a signal would be, because it would use the original C64's video amplifier. Testing would be necessary. — Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAI3HKE34PYAH5YGAAK6MELYBVQJ7AVCNFSM5WVN7U5KU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZYGM4TCMBVHA4A> . You are receiving this because you commented.Message ID: ***@***.***>

-- Randy Rossi - "There are only two things that are hard about computer science; Naming things, Cache Invalidation, and Off-by-one errors."

[c0pperdragon]

Yes, the RGBtoHDMI analog board (6 pin IDC socket) needs the signal on both those pins. It expects 1v p-p when it internally terminates the signal with 75ohm. The exact voltages can be adjusted.

[randyrossi]

@c0pperdragon I ordered an RGB2HDMI board from retrohackshack but I didn't realize when I ordered I also need the analog adapter as well. Or should I have purchased the variant of RGB2HDMI with lumacode built in? I didn't see that option on their site though. Would it be possible to get one from you so I can try out my lumacode firmware update to the Kawari? I see your Tindie site is out of stock though. Or if you have a Kawari, would you be willing to try it out for me?

[c0pperdragon]

I need to build more of those RGBtoHDMI with lumacode anyway, so I can reserve one for you. When bypassing Tindie this way, you can have it for $36. Please tell me your shipping details via email: reinhard.grafl (at) aon.at

[randyrossi]

Thanks. I'm not sure I can get the required voltage levels to the analog inputs though. The resistor values I use for 6 bit DAC on the Kawari are 249, 499, 1k, 2k, 4k, 8k. I believe the luma line is pulled up to 5V by a 470ohm resistor in the RF modulator circuit. If you are terminating the input with 75ohm, I don't think I can get the voltage to range between .3v and 1v. I think it will be more like .45 to .68 which is a more narrow a range. I don't know what the VICII-dizer does but in my case I'm trying to output lumacode directly from my board's luma pin. My voltage range to the RF modulator is from approx 1V - 5V with my resistor values (and 0v for sync pulse). I haven't thought about how to connect the luma signal to the analog input but I figure I would just add a socket with a 'tap' into luma. I can probably sever the connection into the motherboard and use my own pullup to widen the range of voltages but not sure if it's possible to get between .3 and 1v. Any thoughts are appreciated.

[c0pperdragon]

Don't worry about the voltage levels here. The RGBtoHDMI can configure its input threashold freely in a very wide range. You an set the 4 comparators to basically everything between 0 and 3.3V ( or even 5V, I am not sure about the details right now). Of course, your signal is then not a completely standard-conform Lumacode. But as I have invented the standard myself, we have some flexibilty here&nbsp; ;-) Reinhard&nbsp;

…

----- Urspr&uuml;ngliche Nachricht ----- Von: randyrossi ***@***.***> Datum: 30.10.2023 14:05 An: randyrossi/vicii-kawari ***@***.***> Kopie: c0pperdragon ***@***.***>, Mention ***@***.***> Betreff: Re: [randyrossi/vicii-kawari] [FR] Support for external RGBtoHDMI upscaler (Issue #1) &nbsp; >

&nbsp; Thanks. I'm not sure I can get the required voltage levels to the analog inputs though. The resistor values I use for 6 bit DAC on the Kawari are 249, 499, 1k, 2k, 4k, 8k. I believe the luma line is pulled up to 5V by a 470ohm resistor in the RF modulator circuit. If you are terminating the input with 75ohm, I don't think I can get the voltage to range between .3v and 1v. I think it will be more like .45 to .68 which is a more narrow a range. I don't know what the VICII-dizer does but in my case I'm trying to output lumacode directly from my board's luma pin. My voltage range to the RF modulator is from approx 1V - 5V with my resistor values (and 0v for sync pulse). I haven't thought about how to connect the luma signal to the analog input but I figure I would just add a socket with a ' tap' into luma. I can probably sever the connection into the motherboard and use my own pullup to widen the range of voltages but not sure if it's possible to get between .3 and 1v. Any thoughts are appreciated. &mdash; Reply to this email directly, view it on GitHub <https://github. com/randyrossi/vicii-kawari/issues/1#issuecomment-1785154391>, or unsubscribe <https://github. com/notifications/unsubscribe-auth/ACTIHVFRMFS762ODJGHNVTLYB6Q2XAVCNFSM5WV N7U5KU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZYGUYTKNBTHEYQ>. You are receiving this because you were mentioned.Message ID: < ***@***.***>

[randyrossi]

Ok sounds good. I found an adapter board and since I have a RGB2HDMI board on the way, I'll just wait for those to arrive. When they do, I might ask for some help in configuring the voltage levels. Thanks again!

[randyrossi]

@c0pperdragon
Are the voltage levels configurable for the Commodore 64 Lumacode profile?

I see this in the config file:

sampling=5,5,5,5,5,5,5,1,1,0,6,0,0,0,0,2,0,7,1,0,65,32,256,256,10,48,256,256
geometry=80,33,336,208,416,240,4,5,3,2,16363636,1040,5000,262,4,0,0
palette=C64_Lumacode
palette_control=7
pal_oddlevel=33

Will I be able to modify the levels for the comparator here or will that have to be done in firmware?

[c0pperdragon]

You can configure everything in the settings menu using the buttons. The threshold voltages specifically in the "Sampling Menu"&nbsp;&nbsp; Reinhard

…

----- Urspr&uuml;ngliche Nachricht ----- Von: randyrossi ***@***.***> Datum: 11.11.2023 19:55 An: randyrossi/vicii-kawari ***@***.***> Kopie: c0pperdragon ***@***.***>, Mention ***@***.***> Betreff: Re: [randyrossi/vicii-kawari] [FR] Support for external RGBtoHDMI upscaler (Issue #1) &nbsp; >

&nbsp; @c0pperdragon <https://github.com/c0pperdragon> Are the voltage levels configurable for the Commodore 64 Lumacode profile? I see this in the config file: sampling=5,5,5,5,5,5,5,1,1,0,6,0,0,0,0,2,0,7,1,0,65,32,256,256,10,48,256, 256 geometry=80,33,336,208,416,240,4,5,3,2,16363636,1040,5000,262,4,0,0 palette=C64_Lumacode palette_control=7 pal_oddlevel=33 Will I be able to modify the levels for the comparator here or will that have to be done in firmware? &mdash; Reply to this email directly, view it on GitHub <https://github. com/randyrossi/vicii-kawari/issues/1#issuecomment-1806891342>, or unsubscribe <https://github. com/notifications/unsubscribe-auth/ACTIHVEFMCF5KZKLAYB7YJDYD7CY5AVCNFSM5WV N7U5KU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBQGY4DSMJTGQZA>. You are receiving this because you were mentioned.Message ID: < ***@***.***>

[randyrossi]

@c0pperdragon

My analog board arrived. I was hoping you could help me figure out how to wire up the luma line from my Kawari.

My 407 board is pulling up the luma line by a 470 ohm resistor (I think) to 5V. The 6-bit DAC resistors for luma out on the Kawari are 249, 499, 1k, 2k, 4k, 8k. The line is quite noisy though. I'm not sure if it's this motherboard but I don't remember the signal being this noisy before. I'll try switching boards.

I'm also not sure if I should disconnect the line from the motherboard altogether and add my own components rather than letting it reach the RF modulator circuit in the first place.

In any case, I placed a 120ohm resistor to GND on the luma output to get started.

The sync level is around 280mv. I managed to get a sync lock by setting sync level to .28 in the sampling menu.

Then I wired the same line to green input and managed to fiddle with the levels to get an image but it's quite noisy. I think the levels are very close together and I have to change both the luma levels for the 4 values and the sampling levels. I just gave it a quick try this morning but I'll have more time on the weekend to experiment,

Any recommendations on a circuit I should build off the luma line? I see the comparators can go up to 3.3v but I imagine I don't want large voltage swings between the 4 levels. Thanks.

[randyrossi]

I got a noisy image at least.

[c0pperdragon]

So this is at least a proof of concept that it could work in principle. When your Kawari is made of recent parts it should not create much noise at all, so the poblems are very likely introduced by the original amplifier circuit. Maybe it is not even noise but just a low-pass behaviour that prevents the outgoing lumacode signal to switch to the required levels fast enough.
Check with an oscillosope. But do this on the end of the RGBtoHDMI while it is either plugged in, or use an extra 75ohm resistor from the signal to GND as an equivalent termination.

In case the transitions are indeed looking slow, you could do a small modification to your RF modulator which was shown in one of Adrian Black's videos: https://www.youtube.com/watch?v=vTn36UaUfrk&t=1734s
But of course, I don't know if this is working with your machine

[c0pperdragon]

The error pixels look a bit like a jailbar effect. I guess this could have the same cause as at the real VIC-II. Which is very likely a ground bounce when the single GND line needs to sink extra large amounds of current. This is first going through a single pin and socket connection and then through a labyrinth of traces to reach some decoupling capactor.
You could try to add some extra grounding here.

[randyrossi]

@c0pperdragon
I managed to get a stable image by building my own circuit with luma pulled up to 5V via 470ohm, then to GND by 185 ohms and turning off 75 ohm termination on the analog board. This spread out the max/min voltage levels to .75, .95, 1.11, 1.32 and sync ends up around .3v.

Unfortunately, there is a lot of noise generated by the transceivers on the Kawari each time they switch direction of the address/data buses. Its noise I was never able to eliminate. No amount of extra grounding made a difference. The magnitude is enough to prevent the 4 levels from being too close together. Even though I get a stable image this way, I see some transitions cause color bleeding. Maybe the problem is it takes too long for the level to drop/rise and the first half pixel level is registering as the wrong value. But then I don't understand why other colors that are encoded with the highest and lowest voltage level end up rendering properly. It's only the first pixel in a the transition that does not get the right color. I checked my encoding and it looks right in the simulator.

For example, WHITE to BLACK shows a green stripe in between.

[c0pperdragon]

When the signal is indeed going through a significant low-pass, this could be explained this way:
A solid color X that toggles both samples between highest and lowes levels will probably just reach the threashold for high and low but not more.
When some color Y comes before that ends with the same level as the start of X, the voltage is drawn further to the extreme and the second sample of the first X pixel may not reach the threashold after that.

In any case, this whole low-pass behaviour can not be solved by any amount of adjustements. I am pretty sure this can be theoretically computed using https://en.wikipedia.org/wiki/Nyquist%E2%80%93Shannon_sampling_theorem, but
I do not have much more then my intuition here.

[randyrossi]

@c0pperdragon Yeah, I don't quite understand what causes some transitions to register the wrong color. Here is the output from a small program I wrote that pairs every color with every other one (except itself). When I have time I will look at the pixel encoding levels for the ones that work/don't work and see if I can come up with an explanation.

[c0pperdragon]

On this picture nearly all transitions are wrong. This looks too consistent. Maybe the sampling offset in the RGBtoHDMI is set incorrectly so that not the samples belongin to one pixel are paired together, but always the second sample from one pixel and the first of the next.
If for some reason you have also mixed up the sample generation on the Kawari, solid colors would look correct, but it gives one wrong pixel on each transition.

[randyrossi]

Yep, this was indeed a problem with my encoding. I have a 4x dot clock and I am using a 2 bit register to keep track of first / second pixel transitions. My initial value was off by 1 so all the transitions were mis-aligned by 1/4th a pixel. Once I 'straightened' out the alignment I started to get clean transitions for most colors now. There is still some noise I have to deal with but I think I should be able to get this working soon. At least much better than before. Thanks for your help!

…

On Tue, Nov 21, 2023 at 8:43 AM c0pperdragon ***@***.***> wrote: On this picture nearly all transitions are wrong. This looks too consistent. Maybe the sampling offset in the RGBtoHDMI is set incorrectly so that not the samples belongin to one pixel are paired together, but always the second sample from one pixel and the first of the next. If for some reason you have also mixed up the sample generation on the Kawari, solid colors would look correct, but it gives one wrong pixel on each transition. — Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAI3HKDCRC6UZHBCVZF42XLYFSVZ5AVCNFSM5WVN7U5KU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBSGA4TKMRSGE2Q> . You are receiving this because you commented.Message ID: ***@***.***>

-- Randy Rossi - "There are only two things that are hard about computer science; Naming things, Cache Invalidation, and Off-by-one errors."

[laubzega]

Please make sure to check cache invalidation next. ;)

[IanSB]

@randyrossi

There is still some noise I have to deal with but I think I should be able to get this working soon.
Will I be able to modify the levels for the comparator here or will that have to be done in firmware?

As mentioned above you can customise the voltage thresholds for the different levels to anything up to 3.3v in the sampling menu (the actual video can be up to 5v) so if the signal is too noisy to match the standard lumacode thresholds I could include a custom Kawari profile in future RGBtoHDMI releases with different settings (which would probably be a good idea anyway to indicate Kawari support)

Also don't forget to re-run the auto calibration after changing anything with the analog signal.

If you get this working, some of the additional Kawari features could also be supported using additional signalling.
e.g. to support custom palettes you could dump the palette registers to a video line in blanking (rather like a teletext signal)
This has already been implemented for the BBC micro profile so that the 8 standard colours can be reprogrammed to be any RGB values so it is already known to be technically possible.

My analog board arrived. I was hoping you could help me figure out how to wire up the luma line from my Kawari.

Which analog board are you using?
i.e. The dedicated lumacode/mono board or a standard CPLD board with the plug-in analog board (if so which issue?)

The later boards have very high bandwidth so can cope with up to about 60Mhz pixel clocks.

[dabonetn]

I've got a dedicated lumacode board, a analog 4A-T with u7 installed, and 2 4A-T-GS8743 boards here.
Which should I be testing with?