RGB to HDMI using a Pi Zero and a small CPLD

[aotta]

Thanks to the new "custom profile" feature (and the quartz's frequency from schematic) i got in few time the right profile for the Alphatronic Triumph-Adler TA-8, for both 40 and 80 columns widths:

Thats the profile for the 6-12_BIT_RGB folder:

TA.rar

(543 Bytes) Downloaded 55 times

and below the cable connections (referred to 12-way extender):
Pin 3 GND-->Pin 2 GND
Pin 7 RED3-->Pin 6 RED
Pin 8 HSYNC-->Pin 4 HSYNC
Pin 9 GREEN3-->Pin 7 GREEN
Pin 10 VSYNC-->Pin 5 VSYNC
Pin 11 BLUE3-->Pin 8 BLU

[IanB]

Thanks to the new "custom profile" feature (and the quartz's frequency from schematic) i got in few time the right profile for the Alphatronic Triumph-Adler TA-8, for both 40 and 80 columns widths:

It sounds like you found the new create profile menu useful. Thanks for the profile, I'll add it to the next release in "Other".

BTW I looked at the schematic of the Alphatronic and I think the clock for the 40 column mode is actually half of 17.73Mhz as that resolution would be around 320 pixels rather than 640 and there is a divide by 2 flip flop in the clock path. However using double or quadruple the actual clock usually works anyway (The beeb always samples at 640 pixels even for the 320 and 160 modes) although sometimes it can cause issues if the source is very noisy.
e.g. your original Aquarius profile sampled at 2x (14.318Mhz rather than 7.15Mhz) and that caused noisy results for another user as noted a few pages ago in this thread.

[aotta]

BTW I looked at the schematic of the Alphatronic and I think the clock for the 40 column mode is actually half of 17.73Mhz as that resolution would be around 320 pixels rather than 640 and there is a divide by 2 flip flop in the clock path.

Thank you IanB, i missed the divider in schematic, sincerly when i first tried with the quartz frequency and i got clear dots and zero errors on auto adjust, i thought it was the right clock and resolution.
I'll try soon with suggested values and i'll follow up.

And, sure, the new create profile feature is fantastic!

[aotta]

Attached the new profile with the correct clock as suggested by IanB.
I also added a new subprofile needed by the Micro-text v.1.4 cartridge, that seems to use a strange 322 lines output.

TA.rar

(688 Bytes) Downloaded 51 times

[Bat]

Hi,
Firstly an apology, I haven't read through all 87 pages of this thread!
I've had a quick look on Github but got confused by the number of different board options.
So probably the easiest option is to state what I would like to do then hopefully someone will say yes and you need ...
I've got the following computers, no order of preference

BBC Model B
ZX Spectrum almost all varieties but would be fine with just using the 2 or 3 model with RGB output
Oric Atmos, has an RGB socket on the back
Ti99/4a UK model, believe these output RGB before the separate modulator box.
Atari STFM has the Atari 15?pin din monitor socket

Ideally I'd like to use my Eizo L661 flexscan vga monitor as it's 4:3 aspect and does 800x600 @ 50Hz if required.

Thanks in advance,

Gavin

[scruss]

Ideally I'd like to use my Eizo L661 flexscan vga monitor …

The output's HDMI, so you'd need a (mini) HDMI to VGA converter for that monitor

[Bat]

Ideally I'd like to use my Eizo L661 flexscan vga monitor …

The output's HDMI, so you'd need a (mini) HDMI to VGA converter for that monitor

Great thanks
I think that's going to be the easy part...

[IanB]

BBC Model B
ZX Spectrum almost all varieties but would be fine with just using the 2 or 3 model with RGB output
Oric Atmos, has an RGB socket on the back

The BBC, Oric and Spectrum 128 or Spectrum +2 will all work with just the CPLD board as they all output TTL signals

The Spectrum +2A and +3 require the CPLD and Analog board as they output multi level analog signals.
Note that you can also get Spectrum 128 and Spectrum +2 working with the analog board but they don't require it.

Atari STFM has the Atari 15?pin din monitor socket

In order to get bit perfect results with the STFM you need the internal shifter pickup board plus the CPLD board with 12 bit extender.
This will also work with the hires mono mode.

Ti99/4a UK model, believe these output RGB before the separate modulator box.

The Ti99/4a outputs YUV, not RGB and can mostly be made to work with the CPLD/analog combination but the voltage levels are too close togerther for reliaible operation so it is not ideal.

However there will shortly be a lumacode board available for this and other systems using the same video chip like the colecovision and MSX-1 and that will allow reliable bit perfect extraction.

Similarly the Spectrum 48K outputs YUV but again with unsuitably close voltage levels and a lumacode board for that will also be available soon.

See here for more details on lumacode:
https://www.stardot.org.uk/forums/viewt ... 32#p401932
https://github.com/c0pperdragon/LumaCode/wiki/Overview

Ideally I'd like to use my Eizo L661 flexscan vga monitor …

The output's HDMI, so you'd need a (mini) HDMI to VGA converter for that monitor

Great thanks
I think that's going to be the easy part...

It might not be the easy part as it depends if you can find a HDMI to VGA converter that works with 50Hz modes.
I did manage to find one that worked for 576p @50Hz which is 720x576 and I think it also handled 720p and 1080p but it wouldn't handle other resolutions at 50Hz.
(You can still use 60Hz modes instead but that involves a 50 to 60Hz conversion which introduces judder on smooth motion like scrolling)
Also the quality won't be as good as a direct HDMI or DVI connection.

The gerbers for the CPLD, Analog and ST boards are available on the project github page and pre-assembled boards using improved designs are available from the sellers also linked in the project wiki:
https://github.com/IanSB/RGBtoHDMI/wiki

[G4DDS]

New member just joined so apologies if this has been asked before (the query below). I originally joined as I was having problems programming a "12 Bit Extender 16 way IDC" board with it just going to the CPLD recovery menu even after the reboot following what claimed was a successful programming. However, the seller has since told me to send it back as it looks like a cold solder joint.

However, I do have a query concerning a ZX81. I know I can buy this board:
https://www.sellmyretro.com/offer/detai ... code-63615

which is based on a "RGBtoHDMI 6 way IDC" board as detailed here:

https://github.com/hoglet67/RGBtoHDMI/w ... o-computer

But is there anyway I can save some money and use the "12 Bit Extender 16 way IDC" board and just wire up a phono connector up to the relevant pins on the 16 way IDC instead?

[Rasp]

Hi All,

how do I buy one of these for my BBC Master. Thanks

[IanB]

However, I do have a query concerning a ZX81. I know I can buy this board:
https://www.sellmyretro.com/offer/detai ... code-63615
which is based on a "RGBtoHDMI 6 way IDC" board as detailed here:
https://github.com/hoglet67/RGBtoHDMI/w ... o-computer

Those connections refer to the 6 way IDC on the analog add-on board and the above unit is a lower cost board that combines the CPLD board with part of the analog board (enough to support mono computers like the ZX81)

But is there anyway I can save some money and use the "12 Bit Extender 16 way IDC" board and just wire up a phono connector up to the relevant pins on the 16 way IDC instead?

Not with the ZX81 as the ULA outputs an analog composite video signal so requires some sort of analog interface for it to work, either the full RGB/YUV analog interface or the above combined mono board.
The 12 bit extender is expecting TTL digital signals, not analog signals. Your idea would work with the ZX80 as the video and sync are available on the ZX80 PCB for such a direct connection and there is already a ZX80 (TTL) profile for that.

[IanB]

how do I buy one of these for my BBC Master. Thanks

There are sellers linked in the wiki:
https://github.com/IanSB/RGBtoHDMI/wiki ... s-for-sale
Although I think the UK seller is currently out of stock but they should be available again in a few days time.
Edit: They are back in stock now.

[mikeh_nz]

Dumb question: what’s the profile/rgbToHdmi release that I should be using for the tiaDigitizer (ie Atari 2600 lumacode)?

I’m on the 20230517_eb620884 release - I can get something displayed on the c64 lumacode profile - but it’s not looking very good

Cheers
Mike

[IanB]

Dumb question: what’s the profile/rgbToHdmi release that I should be using for the tiaDigitizer (ie Atari 2600 lumacode)?
I’m on the 20230517_eb620884 release - I can get something displayed on the c64 lumacode profile - but it’s not looking very good

TIA adapter (Atari 2600) support was added in beta 60

Get the latest beta (currently Beta 62) here:
https://github.com/IanSB/RGBtoHDMI/releases

[Bat]

BBC Model B
ZX Spectrum almost all varieties but would be fine with just using the 2 or 3 model with RGB output
Oric Atmos, has an RGB socket on the back

The BBC, Oric and Spectrum 128 or Spectrum +2 will all work with just the CPLD board as they all output TTL signals

The Spectrum +2A and +3 require the CPLD and Analog board as they output multi level analog signals.
Note that you can also get Spectrum 128 and Spectrum +2 working with the analog board but they don't require it.

Atari STFM has the Atari 15?pin din monitor socket

In order to get bit perfect results with the STFM you need the internal shifter pickup board plus the CPLD board with 12 bit extender.
This will also work with the hires mono mode.

Ti99/4a UK model, believe these output RGB before the separate modulator box.

The Ti99/4a outputs YUV, not RGB and can mostly be made to work with the CPLD/analog combination but the voltage levels are too close togerther for reliaible operation so it is not ideal.

However there will shortly be a lumacode board available for this and other systems using the same video chip like the colecovision and MSX-1 and that will allow reliable bit perfect extraction.

Similarly the Spectrum 48K outputs YUV but again with unsuitably close voltage levels and a lumacode board for that will also be available soon.

See here for more details on lumacode:
https://www.stardot.org.uk/forums/viewt ... 32#p401932
https://github.com/c0pperdragon/LumaCode/wiki/Overview

The output's HDMI, so you'd need a (mini) HDMI to VGA converter for that monitor

Great thanks
I think that's going to be the easy part...

It might not be the easy part as it depends if you can find a HDMI to VGA converter that works with 50Hz modes.
I did manage to find one that worked for 576p @50Hz which is 720x576 and I think it also handled 720p and 1080p but it wouldn't handle other resolutions at 50Hz.
(You can still use 60Hz modes instead but that involves a 50 to 60Hz conversion which introduces judder on smooth motion like scrolling)
Also the quality won't be as good as a direct HDMI or DVI connection.

The gerbers for the CPLD, Analog and ST boards are available on the project github page and pre-assembled boards using improved designs are available from the sellers also linked in the project wiki:
https://github.com/IanSB/RGBtoHDMI/wiki

Hi Ian,
Thanks for the detailed reply
I've attached a screenshot of available modes for the L661 monitor. Would this be straightforward with a cheap ebay converter such as this please?https://www.ebay.co.uk/itm/126045924156 ... R-Kct4ehYw

I'm going to assume 50Hz in 50Hz out, worst ways I'll just use a hdmi monitor...

Thanks

[mikeh_nz]

TIA adapter (Atari 2600) support was added in beta 60

Thanks Ian - it’s looking better now.

I’m surprised I’m not getting frame drop from the inconsistent scan line counts of Battlezone. This solution seems robust to it.

Thanks again for this project and the many, many, hours of development & support that you have provided the community…

[IanB]

I've attached a screenshot of available modes for the L661 monitor.

This is one of the problems with older monitors as they don't mention anything about 50Hz support but as you previously indicated that monitor will do at least 800x600@50Hz.
The only way to find out is to try each monitor and mode although I have found that many old HP monitors including their 1600x1200 4:3 DVI ones support 50Hz.

Would this be straightforward with a cheap ebay converter such as this please?https://www.ebay.co.uk/itm/126045924156

It will probably work but again the only way to find out is to try it.

The exact model I have is this one:
https://www.ebay.co.uk/itm/203881829586

By default you are going to get 1280x1024 @60 Hz as that is the monitor's native resolution and refresh so you will have to try other resolutions and refresh rates by selecting them in the main menu to see if you get a usable image.

[vela025]

Apologies in advance if this has passed me by, or if I've missed it in the documentation, but is it possible to change the colour palette using an rgb to hdmi (mine is connected to a rpi3). For example I really like playing Sim City on my BBC, but I find the colour a bit much after a while (I usually swap to a B&W monitor), is it possible to substitute colours using a custom profile something like:

SimCity Original

to

SimCity Custom Colours

[IanB]

Apologies in advance if this has passed me by, or if I've missed it in the documentation, but is it possible to change the colour palette using an rgb to hdmi (mine is connected to a rpi3).

You can dynamically reprogram the colour palette from the beeb by displaying certain pixel sequences and there is a demo of that here:
https://www.stardot.org.uk/forums/viewt ... 61#p226761

Another way would be to create a set of custom palettes that you could manually select from the palette menu:
The beeb profile uses the "RGB.bin" palette file but you could create alternative palettes for different games and put those files in the /palettes folder so they can be selected from the palette menu.

Each palette file contains 257 32 bit words with the first 256 being the palette colours and the last one being the number of entries that are used by the current palette.

Each palette colour word contains the following 4 bytes in order:
Red value 0-255
Green value 0-255
Blue value 0-255
Mono value 0-255 (used in mono mode)

Generally when less than 256 colours are defined the values should repeat to fill the 256 entries

So for a BBC custom palette file you would put the RGBM values in the first 8 words, repeat that 31 more times and put 0x00000008 at the end.

[IanB]

Apologies in advance if this has passed me by, or if I've missed it in the documentation, but is it possible to change the colour palette using an rgb to hdmi (mine is connected to a rpi3).

You can dynamically reprogram the colour palette from the beeb by displaying certain pixel sequences and there is a demo of that here:
https://www.stardot.org.uk/forums/viewt ... 94#p226594
Demo download here:
https://www.stardot.org.uk/forums/viewt ... 61#p226761

Another way would be to create a set of custom palette files that you could manually select from the palette menu:
The beeb profile uses the "RGB.bin" palette file but you could create alternative palettes for different games and put those files in the /palettes folder so they can be selected from the palette menu.

Each palette file contains 257 32 bit words with the first 256 being the palette colours and the last one being the number of entries that are used by the current palette.

Each palette colour word contains the following 4 bytes in order:
Red value 0-255
Green value 0-255
Blue value 0-255
Mono value 0-255 (used in mono mode)

Generally when less than 256 colours are defined the values should repeat to fill the 256 entries

So for a BBC custom palette file you would put the RGBM values in the first 8 words, repeat that 31 more times and put 0x00000008 at the end.

[vela025]

So for a BBC custom palette file you would put the RGBM values in the first 8 words, repeat that 31 more times and put 0x00000008 at the end.

That's great Ian thank you I'll give it a go!

[vela025]

Another way would be to create a set of custom palette files that you could manually select from the palette menu:
The beeb profile uses the "RGB.bin" palette file but you could create alternative palettes for different games and put those files in the /palettes folder so they can be selected from the palette menu.

Each palette file contains 257 32 bit words with the first 256 being the palette colours and the last one being the number of entries that are used by the current palette.

Each palette colour word contains the following 4 bytes in order:
Red value 0-255
Green value 0-255
Blue value 0-255
Mono value 0-255 (used in mono mode)

Generally when less than 256 colours are defined the values should repeat to fill the 256 entries

So for a BBC custom palette file you would put the RGBM values in the first 8 words, repeat that 31 more times and put 0x00000008 at the end.

Would I be correct in thinking I do this using a hex editor?

[IanB]

Would I be correct in thinking I do this using a hex editor?

Yes, or you could write a program to create the file.

If you are going to use a hex editor to edit RGB.bin there is no need to repeat the data, editing the first 8 words should be enough.

[vela025]

Yes, or you could write a program to create the file.

If you are going to use a hex editor to edit RGB.bin there is no need to repeat the data, editing the first 8 words should be enough.

RGB to HDMI Capture

Thanks for explaining the process to me, it worked!...but I hadn't considered that now the trees would be purple back to the drawing board!

[pickledlight]

It should be possible for the non-hdmi version of Kawari to be tweaked to output some sort of lumacode signal should the developer be interested in supporting the option. It might even be possible to support the enhanced features with improved lumacode encoding. (I think c0pperdragon briefly mentioned the idea on the Kawari github a couple of years ago but it wasn't pursued at the time).

Randy, the developer of the Kawari Mini (i.e. the non-hdmi version), published details of his results and process implementing this on his github: https://github.com/randyrossi/vicii-kaw ... UMACODE.md

TL;DR, Randy's implementation involves installing his experimental firmware and hacking up a socket to solder in wires which then incorporate a voltage divider (to pull the signal up to 5v via 120ohm resistor, then tied to GND with a 75ohm resistor) before heading out to the RGBtoHDMI.

Using that method, Randy bypasses the Commodore 64 circuitry, in much the same way as the VIC-II-dizer does.

Randy attests that this works and provides his succesful settings for both the Sampling menu in the RGBtoHDMI and in COMPED, which is where you can adjust LumaCode voltages coming out of the Kawari Mini (so yes, to "tune in" the signal you must adjust both COMPED and the Sampling Menu). Randy used a variant of the RGBtoHDMI with the additional Analogue board, and his DAC settings were RGB based, with the LumaCode using the Green channel.

I decided to have a go at this, but in a neater way, so rather than hack up a socket and have loose wires hanging around, I incorporated the voltage divider into a prototype RF Modulator replacement PCB I designed, which lets the Kawari use the existing C64 luma line circuitry, which I then intercept on my prototype board, pass through the voltage divider and then out through an RCA Jack I added. This is much neater but using the C64 circuitry like this risks introducing noise (so I believe - the traditional luma and chroma signals in the C64 are famously noisy with jailbars etc so interference is coming from somewhere). I don't appear to have any such interference with my implementation, but different C64 boards might.

Additionally I have the RGBtoHDMI Mono & LumaCode so different hardware from Randy. I also decided to stick with the YUV settings.

I then spent many, many hours over a couple of months trying to get this to work. Long story short, I could not replicate Randy's settings. I finally did find settings which produced a relatively clean signal, but had to swap out the 120 ohm resistor in the voltage divider for a 100 ohm, and consequently had to raise all the voltage settings in the DAC. This whole process was brutal.

However, I now have an HDMI signal from my Kawari Mini which is, for the most part, as good as the VIC-II-dizer. However, it is NOT problem free. There is very little latitude between a DAC voltage which produces a clean signal, and one which is filled with noise so my settings are a compromise. Any changes I make now may fix one issue, but just introduce problems elsewhere. I have a sample video which directly compares my Kawari Mini video output with the VIC-II-dizer if anyone wishes to see. I can provide a link so just ask.

What is perfectly clear from all of this: whilst it is possible to get the Kawari Mini to use LumaCode (and it doesn't appear to matter whether you use RGB or YUV) I absolutely would not recommend. It really needs to be just plug n play as the VIC-II-dizer is (pretty much) instead of all that messing around. Randy has advised me he has no plans to change the Kawari Mini, to introduce dedicated headers to a future revision for example, so without that, it's far too arduous for the vast majority to bother. The few (two) others I know of that have tried, have encountered exactly the same issues and to my knowledge, no one else has got it to work.

What this really needs, is a dedicated variant of the Kawari which is specifically geared to LumaCode. I have no idea if that is on the cards.

[Sazhen86]

I've been trying to get a stable mode 7 display out of my Master 128 using an RGBtoHDMI. I have a model B which works fine and displays the mode 7 calibration image perfectly over HDMI, but my Master shows all sorts of problems with M,N etc.

Thinking it may be due to an asymmetric 6MHz clock, I connected the scope to pin 11 of IC25 and noticed that the 6MHz varies a lot resulting in overlapping waveforms. I then check pins 1, 2 and 3 on IC25 and pins 1 and 2 look like good signals, but pin 3 has the same variance.

Could this be a failing 74lS86 in IC25? Does anyone that know more about this than me (which wouldn't be hard ) have any suggestions that I could check?

I've attached some photos of the scope showing the waveforms on some of the pins.

[hoglet]

Does anyone that know more about this than me (which wouldn't be hard ) have any suggestions that I could check?

Have you read this wiki page: Mode 7 Clock Modification?

You should be able to get a stable triggering of your scope if you use the holdoff feature. Try setting it to about 1us and adjust the timebase so about 3 cycles of the 6MHz clock are visible.

Dave

[Sazhen86]

Have you read this wiki page: Mode 7 Clock Modification?

You should be able to get a stable triggering of your scope if you use the holdoff feature. Try setting it to about 1us and adjust the timebase so about 3 cycles of the 6MHz clock are visible.

Thanks for replying, it’s appreciated.

I have read the mode 7 clock modification page and I was trying to determine whether the 6MHz clock was symmetrical or not, and whether that was causing the problem.

I’ll try increasing the trigger hold off time in the morning and see if I can get a better waveform displayed.

Is the variance in the frequency of the 6MHz clock normal?

[hoglet]

Is the variance in the frequency of the 6MHz clock normal?

Some jitter in the position of the edges is normal, due to the way the 6MHz clock is generated. The pattern should repeat over a period of 500ns (3 clock cycles). Because of the way the SAA5050 works, both edges are significant. The "BBC" CPLD Firmware contains a set of six programmable offsets to adjust the pixel sampling points to accomdate the clock asymmetry. Running the calibration process adjusts these offsets to reduce sampling errors. That works better with a reasonable amount of text/graphics on the screen. I typically calibrate using the STH SD Card Menu.

What Pi Firmware and CPLD Firmware is your RGBtoHDMI running? Also, are you using the analog version or the digital only version?

Some photos of the setup might help, as would some screen caps showing the sort of errors that are creeping in.

Dave

[Sazhen86]

Some jitter in the position of the edges is normal, due to the way the 6MHz clock is generated. The pattern should repeat over a period of 500ns (3 clock cycles). Because of the way the SAA5050 works, both edges are significant. The "BBC" CPLD Firmware contains a set of six programmable offsets to adjust the pixel sampling points to accomdate the clock asymmetry. Running the calibration process adjusts these offsets to reduce sampling errors. That works better with a reasonable amount of text/graphics on the screen. I typically calibrate using the STH SD Card Menu.

What Pi Firmware and CPLD Firmware is your RGBtoHDMI running? Also, are you using the analog version or the digital only version?

Some photos of the setup might help, as would some screen caps showing the sort of errors that are creeping in.

Thanks for the update. I adjusted the trigger hold off to 1.30uS as that was the minimum value at which I could get a stable waveform, I've attached a photo of the scope display.

I'm using the Analog board but I did build a digital cable and tried it direct which didn't make much difference. I've attached another photo showing the version numbers. I've also attached a photo showing (hopefully) the problem with the display, although maybe a short video would be better. White on black looks fine, but there are issues with many of the coloured backgrounds which can be seen at the left hand side of the colour bars. I'll see if I can get a better image/video later today.

I now have C30 in a socket as suggested in case I need to try any other values. The original capacitor measure 100pF as expected and R1 is 151 ohms, also as expected.

Any suggestions as to what to try would be really appreciated.