Skip to content
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.

Sign up for GitHub

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

Jump to bottom

[FR] Support for external RGBtoHDMI upscaler #1

Open
c0pperdragon opened this issue May 23, 2022 · 27 comments
Open

[FR] Support for external RGBtoHDMI upscaler #1

c0pperdragon opened this issue May 23, 2022 · 27 comments
Labels
enhancement New feature or request

Comments

@c0pperdragon
Copy link

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
@randyrossi
Copy link
Owner

randyrossi commented May 23, 2022 via email

@c0pperdragon
Copy link
Author

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.

@randyrossi randyrossi changed the title Support for external RGBtoHDMI upscaler [FR] Support for external RGBtoHDMI upscaler Sep 2, 2022
@randyrossi randyrossi added the enhancement New feature or request label Sep 15, 2022
@Icelvlan88
Copy link

Icelvlan88 commented May 1, 2023 •
edited

@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
Copy link
Owner

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 randyrossi mentioned this issue Oct 28, 2023
Open
@randyrossi
Copy link
Owner

@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
Copy link
Author

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
Copy link
Owner

randyrossi commented Oct 28, 2023 via email

@c0pperdragon
Copy link
Author

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
Copy link
Owner

@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
Copy link
Author

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
Copy link
Owner

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
Copy link
Author

c0pperdragon commented Oct 30, 2023 via email

@randyrossi
Copy link
Owner

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
Copy link
Owner

@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
Copy link
Author

c0pperdragon commented Nov 11, 2023 via email

@randyrossi
Copy link
Owner

@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
Copy link
Owner

I got a noisy image at least.
image

@c0pperdragon
Copy link
Author

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
Copy link
Author

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
Copy link
Owner

randyrossi commented Nov 18, 2023 •
edited

@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.

image
image

@c0pperdragon
Copy link
Author

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
Copy link
Owner

randyrossi commented Nov 20, 2023 •
edited

@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.

Image_20231119_081216

@c0pperdragon
Copy link
Author

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
Copy link
Owner

randyrossi commented Nov 21, 2023 via email

@laubzega
Copy link

Please make sure to check cache invalidation next. ;)

@c0pperdragon c0pperdragon mentioned this issue Dec 16, 2023
Closed
@IanSB
Copy link

IanSB commented Dec 17, 2023

@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
Copy link

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@randyrossi @laubzega @c0pperdragon @dabonetn @IanSB @Icelvlan88