-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FR] Support for external RGBtoHDMI upscaler #1
Comments
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."
|
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. 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 |
@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. |
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. |
@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? |
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. |
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."
|
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. |
@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? |
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 |
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. |
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 ;-)
Reinhard
…----- Ursprü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)
>
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.
—
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: <
***@***.***>
|
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! |
@c0pperdragon 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 Will I be able to modify the levels for the comparator here or will that have to be done in firmware? |
You can configure everything in the settings menu using the buttons. The threshold voltages specifically in the "Sampling Menu"
Reinhard
…----- Ursprü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)
>
@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?
—
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: <
***@***.***>
|
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. |
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. 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 |
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. |
@c0pperdragon 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. |
When the signal is indeed going through a significant low-pass, this could be explained this way: 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 |
@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. |
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. |
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."
|
Please make sure to check cache invalidation next. ;) |
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.
Which analog board are you using? The later boards have very high bandwidth so can cope with up to about 60Mhz pixel clocks. |
I've got a dedicated lumacode board, a analog 4A-T with u7 installed, and 2 4A-T-GS8743 boards here. |
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
The text was updated successfully, but these errors were encountered: