Amiga HDMI with a Raspberry Pi! (RGBtoHDMI) and CPC??

[Syncmaster319]

Hi Guys,


Have you seen this?  What are your thoughts on the CPC version as I cant get my head round it?


https://www.youtube.com/watch?v=e8brkYFoO9I&t=1031s&ab_channel=JanBeta


Main Project
https://github.com/hoglet67/RGBtoHDMI/wiki

Amstrad Screen grabs
https://github.com/hoglet67/RGBtoHDMI/wiki/Gallery-of-Screencaps


Thanks
Mark

[pelrun]

Primarily it's for digital RGB signals, and they're capturing that data directly into the Pi's video buffer and using it for HDMI display generation.
As the CPC is analog RGB, this isn't sufficient, and so there's a kinda weird analog board that appears to be a controllable 2bit*3 channel ADC, converting the 3-level CPC signals to 2-bit digital ones the rest of the device can accept.

[pelrun]

Here's the developer's description of the analog board: https://stardot.org.uk/forums/viewtopic.php?f=3&t=14430&start=1290#p299426
Looks like it's not really a 2-bit ADC, because only 3 levels can be distinguished. Luckily, that's all a non-plus CPC needs.

[RetroCPC]

The 3 level version will work for all non plus models (CPC464 to CPC6128) - there is also versions with ADC inputs for higher colour bit depths that will work with CPC+ models.

[pelrun]

I don't think that's correct. Almost all the supported inputs are digital RGB only (including the Amiga), and the analog input board only does the 3-level ADC mentioned earlier. There's no high-bitdepth ADC circuit available.
Don't confuse "3 level per channel input" with the 3 *bit* input of the original board - that's 3 bits *total*, i.e. one for each of R, G and B.

[RetroCPC]

Heres the link to the Analogue version:

https://github.com/hoglet67/RGBtoHDMI/wiki/Bill-of-Materials-%28Analog-Board%29

ADC board:

https://github.com/hoglet67/RGBtoHDMI/blob/master/kicad_analog_6bit/V3/analog.pdf

From the Reference guide:

https://github.com/hoglet67/RGBtoHDMI/wiki/Reference-Guide

Sample Mode

Values: 6 Bits Per Pixel / 6 Bits (4 Level)

Changes the type of sampling:
6 Bits Per Pixel = 6 Bit sampling.
6 Bits (4 level) = use 3 line to 2 bit encoders on the analog card to increase the number of analog levels detected.


I admit its confusing as further on there is the following:

For YUV, there are extra comparators for the U & V channels and RGBS mode is also implemented similarly but there is an additional DAC & comparator for the separate sync. In fact there are two comparators for each of the YUV / RGB channels (Lo & Hi) so that they can detect up to 3 levels each and that is enough to discriminate the three video levels on each of the RGB signals on the Spectrum +2A & +3, the Amstrad CPC 464, 664 & 6128 (not 6128 plus) and any system that uses the Motorola 6847 video chip which has 3 levels each of YUV such as Tandy Color Computer, Dragon & Atom. It effectively turns the analog outputs of those sources into a TTL EGA style signal although the TTL levels represent different colours to the EGA standard so you have to select a different palette in the palette menu. (The video is stored in an 8 bit per pixel frame buffer which uses a colour look up table to set the final RGB output colours and those tables are set from the palette menu)

This approach results in a completely noise free output as the signal has effectively been re-quantised to just a few levels and it works extremely well when there is enough difference between the voltage levels of the video source but it won't work at all if the voltage levels are too close together so they can't be reliably separated due to noise.

So. maybe this will not working with the CPC+

[Bryce]

It would work, I'd just question the fact that they are using a device that could easily emulate the entire Amiga or Amstrad just to convert the video signal.
I call these "Sledgehammer" solutions.

Bryce.

[pelrun]

I didn't know there was a regulation requiring design efficiency
Even if a Pi0 is powerful enough to emulate the whole platform, it's *also* ridiculously cheaper than every other decent solution to the problem.

[Bryce]

There's no regulation, I just think that people aren't trying hard enough these days. I was sent a link lately to a simple intercom project, that could easily have been made for pennies with a few transistors or an op-amp, but instead they beat it into an RPi. Laughably, the intercom interface to the Pi had more components than a stand-alone circuit would have needed.

It's a bit like modern software. Back in the day, we had 64K or 128K and your program HAD to fit into it. Now we have simple programs that need Gigabytes of storage and RAM to do very simple tasks.

Bryce.
 

[pelrun]

Oh for sure there are plenty of projects that a Pi shouldn't go anywhere near, I just disagree about this being one of them.
The extra headroom of the Pi also opens up some other possibilities, like simultaneously streaming the video over the network, or properly handling some of the demo sync timing tricks that flummox every other digital capture solution...