RGB to HDMI using a Pi Zero and a small CPLD

discuss both original and modern hardware for the bbc micro/electron
User avatar
BeebMaster
Posts: 3637
Joined: Sun Aug 02, 2009 5:59 pm
Location: Lost in the BeebVault!
Contact:

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

Post by BeebMaster » Thu Sep 03, 2020 5:33 pm

Ah yes, that's true. I did try to compare a mode 7 and mode 0 PNG file, but I don't know enough about the file format to identify something to pick out as distinguishing between the two. I'll have a read up on the file spec.
Image

User avatar
IanB
Posts: 613
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 » Thu Sep 03, 2020 5:36 pm

tingo wrote:
Thu Sep 03, 2020 1:07 pm
There are lots of frontends: analog 6/8 bit, TTL buffer boards 3/6/8 bit and PC EGA/CGA/MDA buffer

The machine isn't a PC, so the PC buffer board is out.
Example: one of the machines is a Tiki 100: https://en.wikipedia.org/wiki/Tiki_100
which has both analog and digital RGB output connects.
Looking at the specs and pages linked from the wiki, it looks like it has a palette of 256 colours (3 bits green, 3 bits red and 2 bits blue).

I assume the analog output will output all those levels but the RGBtoHDMI analog interface can't handle that number of levels so it would have to be a TTL solution. I couldn't find any info on its TTL RGB output so not sure if it was just 1 bit each of RGB (meaning limited colours) or more so to get all 256 colours you might have to pick up the 8 bits internally. Either way, the 8 bit TTL buffer interface would be the one to use here (or connect directly to the 8 bit header on the main board).

User avatar
IanB
Posts: 613
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 » Thu Sep 03, 2020 5:37 pm

I've started a thread in for sale for RGBtoHDMI and analog boards

I included a list of users that previously expressed an interest in a built up board so can those users confirm if they are still interested by posting in that thread:

viewtopic.php?f=8&t=20404

User avatar
BeebMaster
Posts: 3637
Joined: Sun Aug 02, 2009 5:59 pm
Location: Lost in the BeebVault!
Contact:

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

Post by BeebMaster » Thu Sep 03, 2020 5:45 pm

BeebMaster wrote:
Thu Sep 03, 2020 5:33 pm
Ah yes, that's true. I did try to compare a mode 7 and mode 0 PNG file, but I don't know enough about the file format to identify something to pick out as distinguishing between the two. I'll have a read up on the file spec.
I should be able to get it from the IHDR "chunk" (as long as I can grep hex bytes as well as ASCII characters, or find some other search method). Or more information about the profile/mode could be included in an Exif or Text chunk?
Image

User avatar
aotta
Posts: 282
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 » Sat Sep 05, 2020 12:08 pm

I'm playing for using the RGBtoHDMI with my Mattel Aquarius, and i get decent images wiring the digital RGB and CSync signals directly from the TEA IC:
Aquarius.jpg
i have to find the right setting, since i didn't find any info about pixel clock and geometry, but it's not the big problem now..
setting.jpg
What i can't get correct are colors:
rgbpal.png
the right ones are this:
palette.png
palette.png (2.62 KiB) Viewed 1020 times
I tested different palette and tintes, but with no results. In schematics, i noticed the TEA use a "invert" signals in addition to RGB ones, may be i need it too? how can i use it?
Any suggestion will be appreciated!

User avatar
IanB
Posts: 613
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 » Sun Sep 06, 2020 11:06 pm

aotta wrote:
Sat Sep 05, 2020 12:08 pm
I tested different palette and tintes, but with no results. In schematics, i noticed the TEA use a "invert" signals in addition to RGB ones, may be i need it too? how can i use it?
You will need to create a custom palette table in the palettes folder so first you need to make a table of which digital bits you are picking up are set to 1 or 0 for each colour and then what the RGB values should be for that colour.

User avatar
IanB
Posts: 613
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 » Sun Sep 06, 2020 11:17 pm

I've added support for 8 and 16 bit Atari computers:

1. Atari 800XL
In cooperation with c0pperdragon there is now support for the Atari 800XL:
capture6.png
This requires a similar board to the C64 so is not a simple upgrade. Unfortunately there isn't a ready made solution for this computer although the same FPGA board as the C64 can be used but it requires a different 40 pin extender PCB to pick the signals up from the GTIA chip.

2. Atari ST
The digital signals are picked up internally from the ST like the Amiga. Originally this didn't seem like it was going to work as the pixel clock was too fast but I added some overclock options in the menus and you can now overclock the pi a little to get it working.

Also it works with the 640x400 hires mono mode as well as the standard 320x200 & 640x200 lores modes and automatically switches between them:

320x200 lores mode
capture3.png

640x400 hires mono mode
capture6.png
Last edited by IanB on Sun Sep 06, 2020 11:35 pm, edited 2 times in total.

User avatar
aotta
Posts: 282
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 » Sun Sep 06, 2020 11:29 pm

IanB wrote:
Sun Sep 06, 2020 11:06 pm
aotta wrote:
Sat Sep 05, 2020 12:08 pm
I tested different palette and tintes, but with no results. In schematics, i noticed the TEA use a "invert" signals in addition to RGB ones, may be i need it too? how can i use it?
You will need to create a custom palette table in the palettes folder so first you need to make a table of which digital bits you are picking up are set to 1 or 0 for each colour and then what the RGB values should be for that colour.
I don't find any palette folder in the release's files... nor a palette table to copy from: where can i look for them?

And great news the new hw supported.. will you be able to update the "cabling" section of the wiki with them?

User avatar
IanB
Posts: 613
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 » Sun Sep 06, 2020 11:33 pm

aotta wrote:
Sun Sep 06, 2020 11:29 pm
I don't find any palette folder in the release's files... nor a palette table to copy from: where can i look for them?
The palette folder is created on the SD card at first bootup of a fresh install and contains all the palettes
aotta wrote:
Sun Sep 06, 2020 11:29 pm
And great news the new hw supported.. will you be able to update the "cabling" section of the wiki with them?
Yes, but it will require a new 12 bit PCB with the extra 4 bits

EDIT:

The palette table is 256 32 bit entries (1K) and each 32 bits is 0xMMBBGGRR
where RR, GG, BB are the RGB values and MM is the value used in mono mode with all values from 0x00 to 0xFF
The 8 bit index into the 256 entries is constructed from the input bits as follows:

X2,X1,b,g,r,B,G,R

So if all bits are low that would be word 0x00, if only B is high that would be word 0x04 etc.
Last edited by IanB on Mon Sep 07, 2020 12:25 am, edited 2 times in total.

User avatar
aotta
Posts: 282
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 » Sun Sep 06, 2020 11:44 pm

IanB wrote:
Sun Sep 06, 2020 11:33 pm
The palette folder is created on the SD card at first bootup of a fresh install and contains all the palettes
found it, thank you! now i'll try to decode the table format..
IanB wrote:
Sun Sep 06, 2020 11:33 pm
Yes, but it will require a new 12 bit PCB with the extra 4 bits
Ops.. i've two 3bit board, five 6bit board and five 8bit boards.. it seems i've to find more space for some new ones! :lol:

User avatar
aotta
Posts: 282
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 » Mon Sep 07, 2020 11:01 pm

IanB wrote:
Sun Sep 06, 2020 11:33 pm
[
The palette table is 256 32 bit entries (1K) and each 32 bits is 0xMMBBGGRR
where RR, GG, BB are the RGB values and MM is the value used in mono mode with all values from 0x00 to 0xFF
The 8 bit index into the 256 entries is constructed from the input bits as follows:

X2,X1,b,g,r,B,G,R

So if all bits are low that would be word 0x00, if only B is high that would be word 0x04 etc.
Thank you Ian for the info, but are they right for the 6bit board too? i'm playing with palettes with one of my old RGBtoHD (i keep the new ones with analog and YUV firmware), but it seems the words are in 0xRRGGBBMM format...
I get first 7 colors right (i can't get a nice white for color no.8, very strange), but can't resolve the right RGB code for the 9 to 16 colors: i used "g" for the fourth bit, so used words 5 and 6, but colors are not the RGB value i expected. I'm missing somethings?

User avatar
IanB
Posts: 613
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 » Tue Sep 08, 2020 1:10 am

aotta wrote:
Mon Sep 07, 2020 11:01 pm
Thank you Ian for the info, but are they right for the 6bit board too? i'm playing with palettes with one of my old RGBtoHD (i keep the new ones with analog and YUV firmware), but it seems the words are in 0xRRGGBBMM format...
I get first 7 colors right (i can't get a nice white for color no.8, very strange), but can't resolve the right RGB code for the 9 to 16 colors: i used "g" for the fourth bit, so used words 5 and 6, but colors are not the RGB value i expected. I'm missing somethings?
Yes it's right for the 6 bit board as well, the Pi is little endian so first byte would be RR, second GG, third BB. fourth MM but that would be treated as a 32 bit word 0xMMBBGGRR

Words 0-7 (bytes 0-31) would give you the 8 combinations of RGB with the g input at 0

Words 16-23 (bytes 64-95) would give you the 8 combinations of RGB with the g input 1 (assuming r and b are connected to 0v)

Also make sure you have selected FB Bits/pixel as 8bpp, not 4bpp in the Geometry menu as well as 6bpp capture in the sampling menu (4bpp frame buffer can only be used for 3bpp capture as the 4th bit is reserved for the menu)

User avatar
aotta
Posts: 282
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 » Tue Sep 08, 2020 8:04 am

Thank you Ian, i didn't thought about little endian, but you confirmed i computed the bytes in right order.
So, i look again to my bad results:
capture0.png
and... i found it was only due to a bad soldering in a Cpld's pin!
capture2.png
Now colours are aligned to TEA1002 datasheet values, i have to do some tuning to the geometry, i think, but we can confirm RGBtoHD works fine with TEA1002 based computers too (Aquarius, Videopac G7400, Acetronic MPU-100, etc.)!

User avatar
IanB
Posts: 613
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 » Tue Sep 08, 2020 1:15 pm

aotta wrote:
Tue Sep 08, 2020 8:04 am
and... i found it was only due to a bad soldering in a Cpld's pin!
Glad you got it sorted out
aotta wrote:
Tue Sep 08, 2020 8:04 am
Now colours are aligned to TEA1002 datasheet values, i have to do some tuning to the geometry, i think, but we can confirm RGBtoHD works fine with TEA1002 based computers too (Aquarius, Videopac G7400, Acetronic MPU-100, etc.)!
Looking at the screencaps, there is a band of glitchy pixels on the vertical colours just to the left of centre. This is usually caused by the "Line Length" setting in the geometry menu being wrong by a small amount so try adjusting that value up and down. It can help to display some fine detail like text across the entire width of the screen when making this adjustment.

When you have finished palette and profile files, post them and I'll add them to the next release.

User avatar
aotta
Posts: 282
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 » Tue Sep 08, 2020 2:16 pm

IanB wrote:
Tue Sep 08, 2020 1:15 pm
When you have finished palette and profile files, post them and I'll add them to the next release.
Yes, the geometry was corrected, here the settings and new samples:
Aquarius.txt
(183 Bytes) Downloaded 8 times
Tea1002.bin.txt
(1 KiB) Downloaded 7 times
(added .txt suffix for attaching here)
capture15.png
capture16.png
capture20.png
capture0.png

User avatar
IanB
Posts: 613
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 » Tue Sep 08, 2020 7:10 pm

aotta wrote:
Tue Sep 08, 2020 2:16 pm
Yes, the geometry was corrected, here the settings and new samples:
Aquarius.txt
Tea1002.bin.txt (added .txt suffix for attaching here)
Thanks for that, the supported list keeps growing!

User avatar
IanB
Posts: 613
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 » Tue Sep 08, 2020 7:25 pm

From the for sale thread:
1024MAK wrote:
Tue Sep 08, 2020 3:37 pm
On that basis, it should work with the following models, as they all have the same shifter chip:
  • Atari ST (original range with external PSU and no internal disk drive),
  • Atari STF - built in PSU and built in disk drive,
  • Atari STFM - built in PSU and built in disk drive, the U.K. models have a built in RF modulator,
  • Atari Mega (two box professional computer based on the STFM)
I’ll have to check on the STe, as it has different video circuitry (more colours, a palette of 4096) and I forget what signals are available. It’s been a while since I poked around the video circuitry of these. See here for more details.
The same will apply to the Mega STe models.

The TT (more info) is much less common and I’ve never poked around inside mine. So I’ll have to check.

Due to the 4096 colour palette and the different video circuitry for the STe, Mega STe and TT, I suspect that RGBtoHDMI may not be suitable for use with these.
1024MAK wrote:
Tue Sep 08, 2020 4:04 pm
So the shifter in the STe and Mega STe has four output lines/bits per RGB colour (12 bits total) and therefore if RGBtoHDMI can cope with 12 bits of data it should be possible. Although it looks like picking up the internal signals will be easier on the resistors used as a DAC ladder rather than in the IC pins.
Four bits each for RGB will work as that's what the Amiga uses although it would not be able to auto switch between hires mono mode and lores colour mode because the mono signal is fed into the spare 3 bits.
Is the hires mono mode the same on the later machines?

Increased bit depths at the existing resolutions will work but the other limitation would be any enhanced resolutions or refresh rates which probably won't work because 12bpp with a 16 Mhz pixel clock is the upper limit on what can be captured by the Pi. It can capture higher rate pixel clocks like the 32Mhz used by the hires mode but only at reduced bit depth.

User avatar
1024MAK
Posts: 10294
Joined: Mon Apr 18, 2011 5:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

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

Post by 1024MAK » Tue Sep 08, 2020 7:40 pm

Schematic extracts:
B6E26481-9913-4555-9F7B-6F3F3D2C33FF.png
STe shifter
1B7A6DF1-22B5-4549-95C1-23A3FF2B0DCB.png
Mega STe shifter
Both have the same high resolution mono video mode as the ST/STFM machines. Hence below the RGB outputs you can see a MONO video output signal.

The TT video IC looks like it directly produces an analogue video signal (which then goes via some buffer transistors) to the 15 way VGA style D connector. The MONO video signals are via separate video signals and go to different pins on the connector. I’m not sure how much use this very high resolution mono mode gets used. I suspect not much. For details see this document.

Mark

User avatar
IanB
Posts: 613
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 » Tue Sep 08, 2020 9:16 pm

1024MAK wrote:
Tue Sep 08, 2020 7:40 pm
For details see this document.
The analog output out of the TT chip wouldn't work at the moment although I intend to investigate an alternative analog board design sometime that would work with Atari/Amiga and maybe Archimedes just by plugging into the external video connector.

User avatar
aotta
Posts: 282
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 » Sun Sep 13, 2020 12:13 pm

aotta wrote:
Sun Sep 06, 2020 11:44 pm
IanB wrote:
Sun Sep 06, 2020 11:33 pm
Yes, but it will require a new 12 bit PCB with the extra 4 bits
Ops.. i've two 3bit board, five 6bit board and five 8bit boards.. it seems i've to find more space for some new ones! :lol:
IanB, sorry for quoting again, but looking for the "new 12 bit PCB" in your Dev branch, and realized that perhaps you was referring to the 12bit extender.. it can be used with the 6 bit RGBtoHDMI board?

User avatar
IanB
Posts: 613
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 » Tue Sep 15, 2020 1:31 am

aotta wrote:
Sun Sep 13, 2020 12:13 pm
IanB, sorry for quoting again, but looking for the "new 12 bit PCB" in your Dev branch, and realized that perhaps you was referring to the 12bit extender.. it can be used with the 6 bit RGBtoHDMI board?
No, You will need both the 12 bit main board and the 12 bit extender but I'm waiting for some prototypes to confirm it works OK before moving to release.

User avatar
aotta
Posts: 282
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 » Tue Sep 15, 2020 8:21 am

Well, i'm confident about the results of the tests!
And, about the Denise adapter published in the github, it is tested and working? i didn't found any info about it here in the thread, only a mention about your idea to use a simple direct shifter for the Amiga.. it's a very interesting solution and i'd like to try it!

User avatar
IanB
Posts: 613
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 » Tue Sep 15, 2020 7:36 pm

aotta wrote:
Tue Sep 15, 2020 8:21 am
Well, i'm confident about the results of the tests!
And, about the Denise adapter published in the github, it is tested and working? i didn't found any info about it here in the thread, only a mention about your idea to use a simple direct shifter for the Amiga.. it's a very interesting solution and i'd like to try it!
Yes, the Denise adapter designed by c0pperdragon is tested and working although there is a problem with the Super Denise chip that requires a track cut and link so there may be an updated board with a jumper to address that.
The discussions for that and the Atari 8 bit and 16 bit mods are here:
https://github.com/c0pperdragon/Amiga-D ... deo/issues

As it is fitted internally, the entire menu system is driven by just one button (to avoid drilling too many holes) with long presses of SW1 equal to the Menu button and short presses equal to the up or down button (you can select which one with another menu option). It's a bit tedious to use for anything complicated but it works well enough for setting scaling and resolution etc.

BTW the twelve bit main board design is in the V4 folder in Kicad_6Bit but you also need the 12bit extender because the full 16 way IDC header won't fit on the main board.
Last edited by IanB on Wed Sep 16, 2020 12:50 am, edited 1 time in total.

User avatar
aotta
Posts: 282
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 » Tue Sep 15, 2020 8:52 pm

Thank you Ian for info and link, i've just place an order to the chinese pcb builder, i can't wait to use RGBtoHDMI with Amiga and Atari 800xl too!
And, about Atari 8 bit, is planned a TIA version of C0pperdragon's board for use with an Atari 2600 too?

User avatar
IanB
Posts: 613
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 » Sat Oct 10, 2020 9:21 pm

There is a new full build of the software available:
https://github.com/hoglet67/RGBtoHDMI/r ... 10_4c8ca86
Direct link:
https://github.com/hoglet67/RGBtoHDMI/r ... c8ca86.zip

This is a release candidate for the next official version and has various changes including automatic selection of the HDMI output resolution and refresh rate by reading the EDID of the monitor. It should work on all board versions, 3 bit, 6 bit, 8 bit and later.

There are now 3 new resolution options:

Default@EDID - This is the new default resolution and should select the native resolution of your monitor and output 50Hz if your monitor indicates it supports 50Hz otherwise it will output 60Hz.
Auto@50Hz-60Hz - Selects the native resolution of your monitor and always forces the output to 50Hz or 60Hz depending on the computer refresh rate.
Auto@Unlimited - As Auto@50Hz-60Hz but will also go above 60Hz if your source is above 60Hz

The two "Auto" versions might produce an output that your monitor can't display but hopefully the Default@EDID option should be safer and always output something the monitor can display but, depending on the age of the monitor, you might not get 50Hz even though the monitor will actually run at 50Hz because it doesn't indicate 50Hz support in it's EDID data.

As a general rule, most monitors with a HDMI connector will select 50Hz and most monitors with a DVI connector will select 60Hz although many of them will actually work at 50Hz if you force it using Auto@50Hz-60Hz

You should do a clean install of the software on a blank SD card and power up. You might be asked to upgrade your CPLD to the latest version on the 6 bit+ boards and there are now three CPLD options:
6-12_BIT_BBC_CPLD_v77
6-12_BIT_RGB_CPLD_v91
6-12_BIT_YUV_CPLD_v90

You should select the "BBC" CPLD for use with the BBC micro, Master 128 etc as the RGB CPLD no longer supports capturing mode 7 with an asymmetric clock and so doesn't have any BBC profiles. There is also improved support for very asymmetric mode 7 pixel clocks with a "BBC 24Mhz Mode 7" profile that increases the sampling resolution and can be selected if you have problems with the standard profiles although this is not guaranteed to work as it overclocks the CPLD. (The BBC CPLD also supports some other 3 bit RGB sources.)
The RGB CPLD supports all RGB sources except BBC ones
The YUV CPLD supports YUV and mono sources

On power up or reset when connected to a source computer, the resolution and refresh rate in use are displayed for a few seconds e.g. 1920 x 1080 @ 50Hz.
If it shows 60Hz it means the EDID of your monitor indicates no 50Hz support. If this happens, to test if your monitor can actually work at 50Hz, change the resolution to "Auto@50Hz-60Hz" or to one of the specific 50Hz resolutions and reboot.
If you get a picture then your monitor will work at 50Hz, if you don't, hold down the menu (SW3) button and press reset, keep holding menu until you get back to the resolution/refresh display info.

If you don't get a picture at all on startup of a new install, it means that the monitor indicates 50Hz support but it doesn't actually work at 50Hz. If that happens, you can use the above menu-reset sequence to get back an image and then you will have to select a 60Hz resolution like Default@60Hz. You could also try the specific 50Hz resolution for your monitor as that has slightly different timing to the auto one.

I'm particularly interested in feedback from anyone that gets no output at all with the default settings as that is one thing I'm trying to avoid by reading the EDID. The other possible problem is that the Pi might not select the right resolution for your monitor and that can also be seen on the startup info. To work around that you can manually select the correct resolution.

To aid in diagnosing problems, there is now a log saver feature in the info menu which saves the system log and the EDID data of the monitor to the SD card.

User avatar
anightin
Posts: 617
Joined: Thu Aug 23, 2018 2:03 pm
Location: Cambridge UK
Contact:

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

Post by anightin » Sun Oct 11, 2020 4:15 pm

Lovely work! :D

Just set up my System 5 (YUV) and System 3 (RGB Teletext) with the new software.

YUV took 2 mins. RGB was a bit more of a fiddle as Scaling seemed to create a 1Hz screen blanking effect on all apart from Integer Sharp.

I still have some sparkly pixels on contrasting colour backgrounds I can't seem to resolve but the pin sharp display more than compensates.
IMG_7931.jpeg
IMG_7930.jpeg
Thank you =D>

User avatar
aotta
Posts: 282
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 » Sun Oct 11, 2020 5:16 pm

Since now tested only BBC Cpld, it works but in my small 9" test monitor it sets the maximum supported resolution (1920x1080), that is not the native res (1024x600), so the result it's scaled.
It's normal? i attach log and edid, if useful.
Thank you Ian for your improvements!
Log.txt
(5.44 KiB) Downloaded 3 times
EDID.bin.txt
(256 Bytes) Downloaded 1 time

User avatar
IanB
Posts: 613
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 » Sun Oct 11, 2020 8:01 pm

anightin wrote:
Sun Oct 11, 2020 4:15 pm
RGB was a bit more of a fiddle as Scaling seemed to create a 1Hz screen blanking effect on all apart from Integer Sharp.
The 1Hz effect it the system reinitialising the profile because the timing was out of range which can indicate something is set incorrectly in the geometry menu. Try adjusting the clock tolerance value which should print some helper info at the top of the screen which might help in diagnosing the problem.
Also save the log after you get the 1hz blanking. (This should stop when you call up the menu)
Post the above info and I'll see if I can figure out the problem.

I have a blank system teletext PCB so I will build one up one day and look at this directly, however I recall that the 6/12 Mhz pixel clock on the system teletext board is generated from an RC oscillator, albeit one that is crudely phase locked to phi2 so it may never be possible to reliably sample the output. You might be able to get a better result by tweaking R3 on the teletext board which controls the frequency of the teletext pixel clock to minimise the noise but there's no guarantee it will remain stable as it is likely to vary with temperature.

User avatar
IanB
Posts: 613
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 » Sun Oct 11, 2020 8:07 pm

aotta wrote:
Sun Oct 11, 2020 5:16 pm
Since now tested only BBC Cpld, it works but in my small 9" test monitor it sets the maximum supported resolution (1920x1080), that is not the native res (1024x600), so the result it's scaled.
It's normal? i attach log and edid, if useful.
Yes, it's normal as the EDID you posted doesn't even include 1024x600 anywhere in its tables so it is misleading about it's capability. I think these small monitors are primarily aimed at video use so it just indicates support for the standard TV resolutions and I think you would get a similar scaled result if you connected it to a PC.
This is one of the cases where you have to use manual override and set the resolution correctly yourself.

User avatar
anightin
Posts: 617
Joined: Thu Aug 23, 2018 2:03 pm
Location: Cambridge UK
Contact:

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

Post by anightin » Sun Oct 11, 2020 8:32 pm

IanB wrote:
Sun Oct 11, 2020 8:01 pm
anightin wrote:
Sun Oct 11, 2020 4:15 pm
RGB was a bit more of a fiddle as Scaling seemed to create a 1Hz screen blanking effect on all apart from Integer Sharp.
The 1Hz effect it the system reinitialising the profile because the timing was out of range which can indicate something is set incorrectly in the geometry menu. Try adjusting the clock tolerance value which should print some helper info at the top of the screen which might help in diagnosing the problem.
Also save the log after you get the 1hz blanking. (This should stop when you call up the menu)
Post the above info and I'll see if I can figure out the problem.

I have a blank system teletext PCB so I will build one up one day and look at this directly, however I recall that the 6/12 Mhz pixel clock on the system teletext board is generated from an RC oscillator, albeit one that is crudely phase locked to phi2 so it may never be possible to reliably sample the output. You might be able to get a better result by tweaking R3 on the teletext board which controls the frequency of the teletext pixel clock to minimise the noise but there's no guarantee it will remain stable as it is likely to vary with temperature.
Thanks Ian, yes I've fitted a preset resistor for R3 so I can tweak it to get the best picture. I'll have a go at creating a log when I next have the System 3 assembled and running. I note that when using a 6502A CPU card and appropriate backplane that I can pass in the VDU clock from the CPU card. I guess that's one option if I end up keeping the Teletext card on the System 5 vs the System 3. I have 6502A ROMs for either VDU card.

Post Reply

Return to “8-bit acorn hardware”