Hi Guys,
Have you seen this? What are your thoughts on the CPC version as I cant get my head round it? :D
https://www.youtube.com/watch?v=e8brkYFoO9I&t=1031s&ab_channel=JanBeta (https://www.youtube.com/watch?v=e8brkYFoO9I&t=1031s&ab_channel=JanBeta)
Main Project
https://github.com/hoglet67/RGBtoHDMI/wiki (https://github.com/hoglet67/RGBtoHDMI/wiki)
Amstrad Screen grabs
https://github.com/hoglet67/RGBtoHDMI/wiki/Gallery-of-Screencaps (https://github.com/hoglet67/RGBtoHDMI/wiki/Gallery-of-Screencaps)
Thanks
Mark
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.
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.
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.
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.
Heres the link to the Analogue version:
https://github.com/hoglet67/RGBtoHDMI/wiki/Bill-of-Materials-%28Analog-Board%29 (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 (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 (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+
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.
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.
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.
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. :D
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...
Since I'm getting a bunch of Pi Zero the next days for some other projects : Did anyone tried this already ?
I was thinking about this, it would be a great thing.
You should check out the ZX HD and the TK Pie.
https://www.bytedelight.com/?page_id=1800 (https://www.bytedelight.com/?page_id=1800)
https://gitlab.com/victor.trucco/TK-Pie (https://gitlab.com/victor.trucco/TK-Pie)
These monitor the screen memory rather than the RGB signals, so even closer to the z80! For the CPC I'd imagine you'd need the CRTC and GA registers also. But if the multiface can do it...
Anyone tried this yet on their CPC? I would love to be able to use my CPCs on a more accessible monitor. Trust me. I know what I'm doing.
Still not came around doing it, but I just found this :
https://www.youtube.com/watch?v=a-oWpjN0sFA
The picture quality is awesome (only my 2c) :)
Looks great, but does it support the crazy crtc sync abuse that same games and demos use?
isometrikum, skate wars are two that appear off the top of my head - if it can handle those I might be curious.
If I build one, I'll try ;)
I've made one of these adaptors and have some issues that I'm struggling to sort out. The colours are right in some places and wrong elsewhere. It's not my 464 as it looks ok on my OSSC, but OSSC isn't really good enough due to the sync issues. I have checked all components for soldering and correct values, no problems there. I have tried just about all adjustments and nothing fixes it. I guess I should post on the Github page and see if anyone there has an idea. Photos attached.
Damn! This looks like CGA :o
It does look like CGA, those gastly Cyan and Magenta colours. I put a post on the Github page, will update if anyone has any ideas.It's possible This game and some demo's are using a non supported (by the adaptor) mode.I'll update if and when any replies are forthcoming.
However, it does look ok on the video a few posts up from this one, the part of the Batman Forever demo where the screen is green work ok there but all I get is a solid green screen.
That's clearly a problem with the comparators on the analog board not being set properly; mid-level pixels are being read as full-level.
According to the rgbtohdmi wiki: "manually adjusting the DAC settings in the sampling menu which set the level slice values for the 1 bit A to D converters (these are not altered by the auto calibration). Try adjusting each of the YUV or RGB levels as appropriate a few values in either direction to see if it improves things. (leave each one at it's original value if it doesn't"
This is solved now and it was all my fault for using a CD4066 instead of a 74LVC4066. Lack of availability was the reason but I will definitely learn a lesson here.
CD4066 is for higher VCC voltages74LVC4066 is for lower voltages from 2 to 6v.
The on-state resistance at 3v VCC for CD4066 is very high vs the LVC chip. I paid more attention to pinout instead of IC characteristics when ordering.
I ordered the pcb's for this, then went to order all the parts. Apparently, the MAX5259EEE+ DAC chips are on back order until at least December and I couldn't find a pin compatible replacement except of course the scalpers on ebay who want 30$ for a 6$ chip. :picard:
Welcome to the component supply crisis. Everyone manufacturing electronics is utterly screwed this year, and there's no chance it'll resolve until at least 2022.
I guess I will make my own S-Video and composite adapter to use until the component crisis is over. I couldn't find board files for Bryce's board so I rolled my own version using @Bryce (https://www.cpcwiki.eu/forum/index.php?action=profile;u=225) and RGB4ALL schematics. Ill post a link to the Eagle files and gerbers. I just ordered it so its not tested yet, but it might be of help to someone.
https://drive.google.com/file/d/1EGG1lfo1hvkQ_OntiVEFGNN8wSm2n00l/view?usp=sharing (https://drive.google.com/file/d/1EGG1lfo1hvkQ_OntiVEFGNN8wSm2n00l/view?usp=sharing)
I still have some of the RGB to S-Video boards left over, both populated and unpopulated if you need one.
Bryce.
Thanks Bryce, I already ordered 5 boards on jlcpcb that should arrive soon. Hopefully they will work properly, but if not I may take you up on your offer. I already tried to use an active scart cable and a scart to hdmi converter, but the converter was total rubbish. It had a bad grey monochrome output, then when I opened it none of the RGB signals were even connected. I returned it and ordered a different converter, but figured I should get the svideo converter just in case.