RGB to HDMI using a Pi Zero and a small CPLD

discuss both original and modern hardware for the bbc micro/electron
User avatar
IanS
Posts: 1600
Joined: Mon Aug 31, 2009 7:02 pm
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by IanS »

vela025 wrote:
Thu Dec 03, 2020 1:08 pm
Apologies if this has already been asked (I did spot checks at random intervals on the 43 pages of comments but couldn't see anything lol), are there any plans to sell these pre-assembled? [-o<
Check the for sale forum - viewtopic.php?f=8&t=20404
vela025
Posts: 27
Joined: Tue Jun 16, 2020 4:48 pm
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by vela025 »

Ahhhh thank you!!
User avatar
hoglet
Posts: 9941
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by hoglet »

rodders wrote:
Thu Dec 03, 2020 12:04 pm
There are separate offset values for MODE 7, would it be possible to have individual offsets for MODES 0-6?
There is no way (from the video timings) to discriminate modes 0..6 from each other.

They all look the same.

Dave
rodders
Posts: 105
Joined: Thu Jun 25, 2020 3:40 pm
Location: Somerset
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by rodders »

I suspected as much. If it was easy I'm sure you would have done it already.
BBC Model B 32k ICL issue 3, WE ROM/RAM board, Speech Processor, TurboMMC, PiTubeDirect
BBC Master 128
User avatar
danielj
Posts: 8587
Joined: Thu Oct 02, 2008 5:51 pm
Location: Manchester
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by danielj »

hoglet wrote:
Thu May 23, 2019 1:50 pm
I've just looked up the video specs on the Mega Drive:
https://segaretro.org/Sega_Mega_Drive/Palettes_and_CRAM

The system outputs 9-bit colour (i.e. 3-bit Red, 3-bit Green, 3-bit Blue) and the resolution is 320x240 (PAL) and 320x224 (NSTC).

I think in principle the software on the Pi could deal with this data rate.

Unfortunately, none of the current front end capture boards (for the Beeb or the Atom) support the digitization of 3-bit/pixel colours. For that, a new design would be needed, probably using three proper high-speed Video ADC devices, such as three AD9057 convertors:
https://uk.rs-online.com/web/p/video-adcs/7095115/
Bit of necromancy - in 12-bit world, do we think the megadrive is a go-er now?
User avatar
IanB
Posts: 696
Joined: Sun Sep 04, 2011 8:28 pm
Location: South Wales
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by IanB »

danielj wrote:
Fri Dec 04, 2020 9:55 am
in 12-bit world, do we think the megadrive is a go-er now?
It's still a "maybe".

Although the hardware now supports 9 and 12 bits per pixel, that is currently digital only so the 9 or 12 bits have to be available digitally to pick up internally which they are on the Amiga, Atari ST & NuLA.

It looks like the megadrive has analog RGB out of the video IC so it would require a new 9 / 12 bit analog board which I will be looking at designing soon but it might never work properly because it would have to reliably discriminate the 8 or 16 analog levels to recover the 3 or 4 bits of video info for each RGB channel so everything on both the output DAC and input ADC sides would have to be low noise and very linear to match up although it might be possible to avoid linearity issues using 8 bit ADCs and an intermediate lookup table but that's going to make it more complex and expensive to produce.
MajorMar
Posts: 23
Joined: Thu Oct 29, 2020 10:12 pm
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by MajorMar »

Is there an overview of how the analog board works somewhere? I am looking for a high-level theory of operation that I can share on my next video. I looked in this forum and on the wiki page, but I am not seeing it. I am also happy to setup a zoom call with someone who is willing to explain it. Maybe I could put that in the video as well.

Thanks!
User avatar
IanB
Posts: 696
Joined: Sun Sep 04, 2011 8:28 pm
Location: South Wales
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by IanB »

MajorMar wrote:
Sat Dec 05, 2020 5:52 am
Is there an overview of how the analog board works somewhere? I am looking for a high-level theory of operation that I can share on my next video.
I haven't done a detailed writeup previously but it works as follows:

The interface is a collection of comparators and a set of Digital to Analog voltage outputs which are used to set the reference levels for those comparators. Together these effectively form a set of 1 bit Analog to Digital converters which are used to "level slice" the incoming video.

A normal A to D would take an analog input and output a stream of numbers representing the video voltage level as it changes and that would also include any noise in the signal. The comparators in the above 1 bit converters output a logic high or low depending if the incoming voltage is above or below the level set by the DAC connected to each associated comparator.

If you consider the simplest source which is monochrome composite video such as the Ohio Superboard, TRS80 Model I or Apple II the video output on those only has 3 levels: sync level, black level and white level. To extract this information, you set the voltage references on two comparators, one to detect the difference between sync and video and one to detect the difference between black and white and these are then output at TTL levels to feed into the TTL input of RGBtoHDMI in the same way as CGA or EGA signals.

In a normal 1v peak to peak mono video signal the sync is between approx 0v and 0.3v and the video is between 0.3v and 1v so you would set the sync DAC voltage to approx 0.15v and the video (Y) DAC voltage to 0.65v. For the DAC settings, 0 = 0v and 254 = 3.3v (255 means disabled) and you could calculate the initial values from that although in practice it is easier to vary the values up & down until the input breaks and then set the level half way between those extremes. Unused DACs are set to 255.

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.

There is also an optional clamp circuit for any sources that are AC coupled via a capacitor and an additional comparator chip (U7) can be fitted on the back of the analog board which increases the number of detectable levels from 3 to 4 and this can be used to get it working with the TI99/4a and other systems based on the same TI video chip like MSX1 & Colecovision but performance is marginal with those due to the video levels being a bit too close together. Note I think this only works with the PAL version of the TI99/4a which has YUV out as the NTSC version has composite colour video directly out of the video chip.

There is a possibility that the DAC levels might have to be manually tweaked on a per machine basis if there is too much variation in output voltage levels from machine to machine (of the same type) but this would only have to be done once during initial setup similar to the auto calibration of the sampling phase but there haven't been enough different machines tested so far to determine that.

When everything is setup correctly and combined with the pixel accurate sampling of the RGBtoHDMI converter it results in a completely noise free perfectly sampled signal which in most cases is going to be indistinguishable from the output of an emulator.
User avatar
danielj
Posts: 8587
Joined: Thu Oct 02, 2008 5:51 pm
Location: Manchester
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by danielj »

IanB wrote:
Sat Dec 05, 2020 12:39 am
It looks like the megadrive has analog RGB out of the video IC so it would require a new 9 / 12 bit analog board which I will be looking at designing soon but it might never work properly because it would have to reliably discriminate the 8 or 16 analog levels to recover the 3 or 4 bits of video info for each RGB channel so everything on both the output DAC and input ADC sides would have to be low noise and very linear to match up although it might be possible to avoid linearity issues using 8 bit ADCs and an intermediate lookup table but that's going to make it more complex and expensive to produce.
Got you. I'd missed the digital bit :D.

On another note, if there is interest in things that don't seem to behave properly, cmorely just mentioned that Kenton's starquake (as being discussed in another thread) didn't work with any of his LCD displays. I just checked it through RGBtoHDMI and it unfortunately doesn't sync with whatever strange screen-jiggery pokery's going on :S

ssd here: http://bbcmicro.co.uk/index.php?rt_R=&r ... ke+&sort=b - rolling display a-go-go.
User avatar
IanB
Posts: 696
Joined: Sun Sep 04, 2011 8:28 pm
Location: South Wales
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by IanB »

danielj wrote:
Tue Dec 08, 2020 9:39 am
On another note, if there is interest in things that don't seem to behave properly, cmorely just mentioned that Kenton's starquake (as being discussed in another thread) didn't work with any of his LCD displays. I just checked it through RGBtoHDMI and it unfortunately doesn't sync with whatever strange screen-jiggery pokery's going on.
It's caused by Starquake setting the hsync pulses to 8us instead of the standard 4.7us. The current maximum with the beeb profiles is 6.144 us as anything longer than that causes issues with mode7 detection in Stunt Car Racer. For other systems, the maximim is set to 9us which would work but coping with both Starquake and Stunt Car Racer will need a more complex fix.

Meanwhile you can get it to lock by temporarily changing the "Auto Switch" setting from "Mode7" to "Off" which increases the maxium to the above mentioned 9us but then it won't detect Mode 7 until that is turned back on.
Last edited by IanB on Tue Dec 08, 2020 6:30 pm, edited 1 time in total.
cmorley
Posts: 1430
Joined: Sat Jul 30, 2016 8:11 pm
Location: Oxford
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by cmorley »

Patching Starquake would seem best then.
Bitstik
Posts: 60
Joined: Thu Feb 18, 2010 2:59 pm
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by Bitstik »

My 2 ready-built adaptors turned up last week and they have been doing sterling service. Thank you very much for developing this =D>
It's great seeing a BBC screen so clear on a modern monitor and it's so neat with the pi taking its power from the RGB port as well.
MajorMar
Posts: 23
Joined: Thu Oct 29, 2020 10:12 pm
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by MajorMar »

I built an analog board and I am going to try connecting to a TRS-80 Color Computer 1. Is there any way to get the sound into the HDMI? I was thinking maybe by using a USB sound adaptor?
User avatar
IanB
Posts: 696
Joined: Sun Sep 04, 2011 8:28 pm
Location: South Wales
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by IanB »

MajorMar wrote:
Thu Dec 10, 2020 9:22 pm
I built an analog board and I am going to try connecting to a TRS-80 Color Computer 1. Is there any way to get the sound into the HDMI? I was thinking maybe by using a USB sound adaptor?
It's only been tested on a PAL Micro Color Computer and an NTSC Color Computer 2 so far but should work on the Color Computer 1 as it's picking up the same signals directly from the 6847 although you might have to tweak the DAC levels in the sampling menu.

There isn't any way to get audio directly out of the Pi's HDMI output at the moment. RGBtoHDMI was originally designed to work with computers that have built in speakers like the BBC micro so it wasn't an issue. Any audio input to the Pi would require a significant redesign and maybe something more powerful than the Pi zero so it is unlikely to be an option anytime soon.

Many TVs and monitors have a direct 3.5mm analog audio input which can be configured to override the audio on a HDMI input and that is intended for use with PCs that have a separate sound card so using that is one option.

If you really want audio on the HDMI output for video capture etc. you can use a HDMI audio embedder / inserter which takes HDMI and analog audio in and outputs HDMI combined with that audio. There are also older converters that take DVI + audio in and output HDMI.

Unfortunately they tend to be more expensive compared to audio de-embedders / extractors which perform the opposite function of extracting audio from a HDMI source. (If you get an embedder, make sure it has analog audio in and not just digital Co-Ax or Spdif.)

These appear to be suitable HDMI+audio to HDMI embedders:
https://www.ebay.com/itm/DVI-Video-Audi ... 1985276618
https://www.ebay.com/itm/J-Tech-Digital ... 3780536334

The Kramer FC-49 appears to be a suitable DVI + audio to HDMI converter:
https://www.ebay.com/itm/Kramer-FC-49-D ... 3031375163
(That is an old design so it seems to be available reasonably cheaply NOS or second hand.)

Please note I haven't tried any of the above so purchase at your own risk.

If you try a HDMI embedder, you might have to edit both config.txt and default_config.txt on the SD card to change the Pi's HDMI output from DVI compatible mode to true HDMI mode by changing to "hdmi_drive=2".
User avatar
danielj
Posts: 8587
Joined: Thu Oct 02, 2008 5:51 pm
Location: Manchester
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by danielj »

IanB wrote:
Tue Dec 08, 2020 5:07 pm
Meanwhile you can get it to lock by temporarily changing the "Auto Switch" setting from "Mode7" to "Off" which increases the maxium to the above mentioned 9us but then it won't detect Mode 7 until that is turned back on.
Thanks Ian - this does indeed get it to behave for the time being!
MajorMar
Posts: 23
Joined: Thu Oct 29, 2020 10:12 pm
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by MajorMar »

I just tested out the analog board connected to my TRS-80 Coco Model 1 and all I can say is WOW! It looks superb. It took me a few minutes to realize that I had to re-flash the CPLD with the YUV firmware. I will be releasing my video along with a high-level description of how the analog board works and my tests in a few days. I will post back when it is released. Hopefully, I got it all right. :) Thanks for this great project!
Here is a still shot from the video I just recorded running the Coco on a 46" flatscreen TV (slightly out of focus).
vlcsnap-2020-12-12-22h57m01s264.png
User avatar
aotta
Posts: 291
Joined: Fri May 26, 2017 9:57 am
Location: Italy
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by aotta »

IanB wrote:
Sat Dec 05, 2020 12:39 am
...
Although the hardware now supports 9 and 12 bits per pixel, that is currently digital only so the 9 or 12 bits have to be available digitally to pick up internally which they are on the Amiga, Atari ST & NuLA.
...
i'm interested in testing the VNULA's support, but didn't find any info about the cabling from 12bits board and Videonula... anyone has some feedback about it?
User avatar
IanB
Posts: 696
Joined: Sun Sep 04, 2011 8:28 pm
Location: South Wales
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by IanB »

aotta wrote:
Mon Dec 14, 2020 11:18 am
i'm interested in testing the VNULA's support, but didn't find any info about the cabling from 12bits board and Videonula... anyone has some feedback about it?
I'm waiting for RobC to test it as I don't have a NuLA myself.

You would have to pick up the 12 RGB bits from the CPLD side of the 12 DAC resistors on the NuLA (I don't know the order of the resistors) and composite sync from somewhere else on the BBC/Master board together with +5v and 0V.

Also note that the order of the first 4 pins of the 12 bit extender changed from the unreleased V1 PCB to the released V2.
User avatar
aotta
Posts: 291
Joined: Fri May 26, 2017 9:57 am
Location: Italy
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by aotta »

Thank you IanB for the info, so it should need an internal placement of the Rgbtohd, like in the amiga? I'll wait for RobC testing and for more detailed connection info, but I have no more space in my.micro neither in my master, full of vnula, picopro, integra-b, datacentre, etc., so it could be not so easy for me.
User avatar
IanB
Posts: 696
Joined: Sun Sep 04, 2011 8:28 pm
Location: South Wales
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by IanB »

aotta wrote:
Mon Dec 14, 2020 11:41 pm
Thank you IanB for the info, so it should need an internal placement of the Rgbtohd, like in the amiga?
No it's not internal. You have to route a 16 way IDC cable outside the beeb to plug into the header on the 12 bit extender.
You could either have a dangling cable or fit an IDC cable header mounted to the back of the beeb case like this: https://www.ebay.co.uk/itm/16-Way-Boxed ... 3453276086 and then use a short jumper cable to connect between that and the converter.
MajorMar
Posts: 23
Joined: Thu Oct 29, 2020 10:12 pm
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by MajorMar »

Here is my review of the analog board. I was not able to get artifact emulation to work on my NTSC Coco 1. Does that work for analog? I see a Dragon profile in the Palettes menu, but that isn't doing anything. I am using that latest build.

https://youtu.be/Wm2eo4BEna4
User avatar
IanB
Posts: 696
Joined: Sun Sep 04, 2011 8:28 pm
Location: South Wales
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by IanB »

MajorMar wrote:
Tue Dec 15, 2020 7:54 pm
I was not able to get artifact emulation to work on my NTSC Coco 1. Does that work for analog?
I wasn't aware that the CoCo made use of NTSC artifacts. It won't work with the current artifact code because that is intended to work with 14.31818 Mhz pixel clock sources like CGA and Apple II (the colours in Apple II Lores mode make use of pixel patterns output at 14.31818Mhz to get all 16 artifact colours)
The CoCo uses a 7.159 Mhz pixel clock so requires slightly different code but it's not that difficult to add.

Check back in a day or two and I might have an update.
MajorMar wrote:
Tue Dec 15, 2020 7:54 pm
I see a Dragon profile in the Palettes menu, but that isn't doing anything. I am using that latest build.
Not exactly sure what you mean but the Dragon profile won't work with the CoCo because it uses the Dragon's existing Y output rather than a direct connection to the 6847 and that has different voltage levels.
MajorMar
Posts: 23
Joined: Thu Oct 29, 2020 10:12 pm
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by MajorMar »

IanB wrote:
Wed Dec 16, 2020 1:43 am
Check back in a day or two and I might have an update.
You are awesome, sir! That is why I love this project. Everything is so flexible. Other offerings are waiting months for updates.
IanB wrote:
Wed Dec 16, 2020 1:43 am
Not exactly sure what you mean but the Dragon profile won't work with the CoCo because it uses the Dragon's existing Y output rather than a direct connection to the 6847 and that has different voltage levels.
I just assumed that Dragon did it the same way as the Coco. Interesting. Thanks for sharing that.
MajorMar
Posts: 23
Joined: Thu Oct 29, 2020 10:12 pm
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by MajorMar »

Because of my last video, I have people asking about the TRS-80 color computer 3 now :) It seems that the system has a dedicated port with 4 levels of analog RGB if I am reading the specs right. It also has separate horizontal and vertical sync pins. Would this work with the extra comparator installed on U7?

Luckily the header on the Coco 3 is a standard 10 pin/2 row header so I can use the same connector I used on my non-analog RGBtoHDMI board.
Screenshot 2020-12-16 160313.png
User avatar
IanB
Posts: 696
Joined: Sun Sep 04, 2011 8:28 pm
Location: South Wales
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by IanB »

MajorMar wrote:
Thu Dec 17, 2020 12:05 am
Because of my last video, I have people asking about the TRS-80 color computer 3 now :) It seems that the system has a dedicated port with 4 levels of analog RGB if I am reading the specs right. It also has separate horizontal and vertical sync pins. Would this work with the extra comparator installed on U7?
Previously I thought the CoCo 3 used more bits of RGB but looking at the manual it indicates a palette of 64 possible colour combinations.
It doesn't explicitly mention that is 2 bits each of RGB but if it is, then the analog board should work with U7 fitted and that effectively gives you the same colour palette as EGA. (Perhaps someone with a CoCo 3 could confirm the palette is the same as EGA)

An appropriate profile would have to be created and the DACs adjusted to track the 4 levels on each of the RGB outputs so it isn't going to be a plug and play option for the first person to try it.
I could create an initial best guess profile but it is going to need final alignment by someone with the actual hardware and of course there are no guarantees that it will work if there is something unexpected about the output. Any volunteers?

BTW I've nearly finished the artifact colours on the CoCo 1 & 2 but I've not been able to test it properly so far. I have a CoCo SDC for the Dragon but my CoCo 2 doesn't have the Extended Color Basic so I will have to sort that out first before the SDC will work on it so I can load some software.
MajorMar
Posts: 23
Joined: Thu Oct 29, 2020 10:12 pm
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by MajorMar »

IanB wrote:
Thu Dec 17, 2020 2:03 am
I could create an initial best guess profile but it is going to need final alignment by someone with the actual hardware and of course there are no guarantees that it will work if there is something unexpected about the output. Any volunteers?
I have a Coco 3 and I have just ordered some additional comparators. So, once you have a best guess, let me know. Also, what about the separate sync signals? Is that an issue?
MajorMar
Posts: 23
Joined: Thu Oct 29, 2020 10:12 pm
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by MajorMar »

IanB wrote:
Thu Dec 17, 2020 2:03 am
BTW I've nearly finished the artifact colours on the CoCo 1 & 2 but I've not been able to test it properly so far. I have a CoCo SDC for the Dragon but my CoCo 2 doesn't have the Extended Color Basic so I will have to sort that out first before the SDC will work on it so I can load some software.
Someone in the TRS-80 Coco Facebook group sent me this to test with.

10 PCLEAR 5
20 PMODE1,1:PCLS1
30 PMODE1,2:PCLS2
40 PMODE1,3:PCLS3
50 PMODE1,4:PCLS0
60 PMODE 4,1
70 SCREEN 1,1
80 IF INKEY$="" THEN 80
User avatar
IanB
Posts: 696
Joined: Sun Sep 04, 2011 8:28 pm
Location: South Wales
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by IanB »

MajorMar wrote:
Thu Dec 17, 2020 2:21 am
Someone in the TRS-80 Coco Facebook group sent me this to test with.
Thanks.

That also doesn't run on my CoCo due to lack of extended basic but it does run on the Dragon so I can test with that.

What is the expected order of the colours from top to bottom?
i.e. Black, Blue, Orange, White or Black, Orange, Blue, White
(This is tweakable in the menus anyway but I might as well get it right)
MajorMar wrote:
Thu Dec 17, 2020 2:14 am
I have a Coco 3 and I have just ordered some additional comparators. So, once you have a best guess, let me know. Also, what about the separate sync signals? Is that an issue?
The separate syncs are a minor issue as that configuration isn't directly supported but it is fairly easy to work around:

Looking at the service manual for the coco 3 it gives scope traces for the RGB & sync outputs and shows 4 distinct RGB levels so that seems to confirm the above hypothesis and the syncs are positive going TTL so they can be diode ORed together and fed to the composite sync input on the analog board which has a 1K pull down. You would connect H & V syncs to the anodes of two diodes which would have their cathodes (banded ends) tied together and connected to pin 2 on the 6 way connector. Any small signal diode like a 1N4148 would be OK.

https://colorcomputerarchive.com/repo/D ... Tandy).pdf
Last edited by IanB on Thu Dec 17, 2020 3:36 am, edited 1 time in total.
MajorMar
Posts: 23
Joined: Thu Oct 29, 2020 10:12 pm
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by MajorMar »

IanB wrote:
Thu Dec 17, 2020 3:11 am
What is the expected order of the colours from top to bottom?
This was mine. Do you have an NTSC Coco?
131891731_10158706521716648_8525327046350183695_o.jpg
User avatar
IanB
Posts: 696
Joined: Sun Sep 04, 2011 8:28 pm
Location: South Wales
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by IanB »

MajorMar wrote:
Thu Dec 17, 2020 3:33 am
This was mine. Do you have an NTSC Coco?
Yes, but I don't have it hooked up to RF. However from what I've read the orange/blue order is random and varies on power up on the Coco 1 & 2 so looking at real hardware isn't definitive except maybe on the CoCo 3 but I assume the bit patterns have an 'official' order used by software so you would need to ask the person that posted the above code what the expected order was.

See the TRS-80 Color Computer section here:
https://en.wikipedia.org/wiki/Composite_artifact_colors
Post Reply

Return to “8-bit acorn hardware”