RGB to HDMI using a Pi Zero and a small CPLD

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
User avatar
hoglet
Posts: 7218
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

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

Post by hoglet » Sun Jul 08, 2018 12:37 pm

tricky wrote:
Sun Jul 08, 2018 12:03 pm
Great news Hoglet, this was the sort of answer I was expecting/hoping from you :)
Off to see what difference it makes in my CRT.
Before everyone rushes off to do this mod, I've just removed C48 on my second Beeb and ended up with lots of "screen noise" in Mode 7.

So instead I fitted a 100pF value, and this got rid of the noise, and (I think) improved the image.

So probably some experimentation is required.

Once you have desoldered C48 and cleaned out the holes it's quite easy to try different values out (if you have them).

Interestingly, the Master uses 150R and 100pF (compared to 100R and 270pF on the Beeb), so it seems even Acorn needed to fettle this part of the circuit a bit! A larger R and smaller C will, I think, reduce the difference between the rising and falling edge delays.

Dave
Last edited by hoglet on Sun Jul 08, 2018 12:53 pm, edited 4 times in total.

User avatar
tricky
Posts: 2539
Joined: Tue Jun 21, 2011 8:25 am
Contact:

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

Post by tricky » Sun Jul 08, 2018 2:34 pm

At last a good use for that £3 pack of 1,000 assorted capacitors that I accidentally ordered from China!

User avatar
Elminster
Posts: 2346
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK
Contact:

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

Post by Elminster » Sun Jul 08, 2018 3:42 pm

hoglet wrote:
Sun Jul 08, 2018 12:14 pm
dp11 wrote:
Sun Jul 08, 2018 11:46 am
If glitches do occur then a diode across R119 will speed up the rising edge. If the ls86 is socketed then replacing it with a 74hc86 could also work.
IC38 (the LS86) is not typically socketted.

The first thing I did this morning was desolder it and fit a socket so I could try an HC version. The machine booted, but just gave a black screen in Mode 7. The 6MHz clock looked OK, but I guess there was just too much overall delay (the HC part being slower I think).

Interestingly, now I've removed C48, you no longer get a black screen with the HC variant.

Dave
Random question.

Are you not meant to use 74hct as faster replacement for 74ls? I always assume you had to use the ttl tolerant version?

User avatar
hoglet
Posts: 7218
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

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

Post by hoglet » Sun Jul 08, 2018 4:02 pm

Elminster wrote:
Sun Jul 08, 2018 3:42 pm
Random question.

Are you not meant to use 74hct as faster replacement for 74ls? I always assume you had to use the ttl tolerant version?
Generally yes, but I didn't have one to hand!

I think both HC and HCT have symmetrical current sourcing/sinking, which was what mattered here.

Dave


User avatar
hoglet
Posts: 7218
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

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

Post by hoglet » Mon Jul 09, 2018 8:29 am

A few thoughts as to where we might go in the future on the software side of this project:

1. Implement decent software debouncing of the push switches.

2. Port everything to Circle, a C++ Bare Metal environment for the Pi, that amongst other things allows reading/writing files on the SD Card.

3. Support multiple configuration files (one per named system, separate files make it easier to manage). Then if you have several different machines of different types, this would make it easy to switch settings between them.

4. Allow custom colour palettes to be defined in a configuration file.

5. Allow settings can be modified on the fly and saved back to a configuration file, so they are persistent.

6. Take a screen shot of the current frame and save to the SD Card.

7. Take a short video (buffered in RAM), then save to the SD Card. The Pi Zero has 512MB of RAM, which might allow for ~60s of video to be buffered uncompressed. Much more if some simple compression could be done during the blanking interval. The challenge would be maintaining live screen output whilst doing this.

Might take a while....

Dave

User avatar
tricky
Posts: 2539
Joined: Tue Jun 21, 2011 8:25 am
Contact:

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

Post by tricky » Mon Jul 09, 2018 12:06 pm

Great goals.
7 could be extended to a circular buffer so that you can save what just happened.
I would like to add h-sync width/pos on the fly support and then add Beeb to converter communication via h-sync.

User avatar
hoglet
Posts: 7218
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

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

Post by hoglet » Mon Jul 09, 2018 12:19 pm

tricky wrote:
Mon Jul 09, 2018 12:06 pm
I would like to add h-sync width/pos on the fly support and then add Beeb to converter communication via h-sync.
That's a very interesting idea!

BTW, which edge of h-sync should be used as the timing reference, or ideally is it the centre?

Actually, we talked about this before didn't we:
viewtopic.php?p=192482#p192482

I have no idea if there is space in the CPLD to do this.... Somehow I doubt it.

Dave

User avatar
tricky
Posts: 2539
Joined: Tue Jun 21, 2011 8:25 am
Contact:

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

Post by tricky » Mon Jul 09, 2018 4:29 pm

hoglet wrote:
Mon Jul 09, 2018 12:19 pm
...
I have no idea if there is space in the CPLD to do this.... Somehow I doubt it.

Dave
I am hoping that it can be squeezed in to the PI (after h-sync and before the end of h-total) so that the CPLD doesn't have to know. I think you said (but I can't find it now) that the h-sync is passed through to the PI.
The idea (without knowing what you are doing!) is to have the frame buffer wider than what is displayed (probably already the case) and to start filling it at an offset calculated from the centre of the h-sync.
If the h-sync changes width, but the offset also changes giving the same centre, the widths could be used as binary (wide=1, narrow=0) to transfer 32 (maybe up to 39) bytes per frame. The timing would be too tight to do much, but could be used to set a NuLA style palette before starting a game, trigger a re-calibration or set whatever else might be accessible through the menu you were describing.

User avatar
hoglet
Posts: 7218
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

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

Post by hoglet » Mon Jul 09, 2018 6:16 pm

tricky wrote:
Mon Jul 09, 2018 4:29 pm
I am hoping that it can be squeezed in to the PI (after h-sync and before the end of h-total) so that the CPLD doesn't have to know. I think you said (but I can't find it now) that the h-sync is passed through to the PI.
The idea (without knowing what you are doing!) is to have the frame buffer wider than what is displayed (probably already the case) and to start filling it at an offset calculated from the centre of the h-sync.
If the h-sync changes width, but the offset also changes giving the same centre, the widths could be used as binary (wide=1, narrow=0) to transfer 32 (maybe up to 39) bytes per frame. The timing would be too tight to do much, but could be used to set a NuLA style palette before starting a game, trigger a re-calibration or set whatever else might be accessible through the menu you were describing.
I'm not sure that's going to work, for the following reason:

The CPLD passes data to the Pi in units of 4-pixels (a quad). The Pi then collects two quads (8 pixels), packs these into a 32-bit word, and writes this to the frame buffer. You can see the inner loop that does all that here:
https://github.com/hoglet67/RGBtoHDMI/b ... _fb.S#L236

It's hard to see how you could change this code to introduce an N pixel offset, where N could be 0, 1, 2, 3, 4, etc calculated from the width of hsync. It would certainly be much more complicated.

It's conceptually easier to push this down to the CPLD.

The current CPLD uses 66 out of 72 macro cells, so there is a small amount of free space.

I've just tried adding the logic that I outlined earlier, and it seems to still fit. My only concern is there is no guarantee that that offsets introduced are whole pixels wide, so this may well mess up the sampling points.

I'll try this out tomorrow.

Is there any kind of a test program I can use that will vary the sync width?

Dave

User avatar
tricky
Posts: 2539
Joined: Tue Jun 21, 2011 8:25 am
Contact:

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

Post by tricky » Mon Jul 09, 2018 6:57 pm

With the existing CPLD code and assuming that that code is reading MODE 0 width pixels, in which case, there would be two versions:
1. as is
2. start with four black pixels 0..3
.loop
WAIT_FOR_PSYNC_1, read pixels 4..7.
store pixels to buffer
WAIT_FOR_PSYNC_0, read pixels 0..3
jmp loop or whatever it does now
fill in pixel 4..7 black
store pixels to buffer

User avatar
hoglet
Posts: 7218
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

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

Post by hoglet » Mon Jul 09, 2018 7:18 pm

OK, maybe I'm misunderstanding your goal here..

The idea is to provide a mechanism for finer precision horizontal scrolling than is currently possible with the 6845:
- Mode 0/3/4/6: currently 8 pixels
- Mode 1: currently 4 pixels
- Mode 2/5: currently 2 pixels

Correct?

So how fine a precision are you trying to get to, and in what modes?

If it's to improve on the above by a factor of two, then I think doing this in the Pi like you outline would indeed work.

I had (possibly wrongly) been thinking of single pixel precision in Mode 0.

Or to look at it another way. Currently the hsync width in Mode 0 is set to 8, which I think results in a sync pulse of 4us. So what different sync pulse widths are you wanting to discriminate between.

Dave

User avatar
tricky
Posts: 2539
Joined: Tue Jun 21, 2011 8:25 am
Contact:

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

Post by tricky » Tue Jul 10, 2018 5:25 am

I was only looking to match a CRT, which would be twice the current resolution. Being able to do better would be nula territory. I'm not promising that I won't ask for it in future, or saying that nobody wants it now ;)

From the CRT experiments that I have done, +/-1 on the width is OK. I did find one TV that wasn't keen on one of them, but was fine with the other.

For comms, +/-2 width, cancelled out by -/+1 position would need to be recognisable, but not cause any change in the display. I guess other methods could be used, this was just my first thought.

It seems to me that eight copies of the loop would be feasible should someone want it in the future. If they (I) do then, horizontal blanking would also be handy ;)

User avatar
hoglet
Posts: 7218
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

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

Post by hoglet » Tue Jul 10, 2018 7:28 am

OK, this all makes much more sense now. It should indeed be possible to do this in the Pi, exactly as you have outlined. Measuring the width of the sync pulse can be done using the ARM cycle counter register. We already have code elsewhere that uses this:
https://github.com/hoglet67/RGBtoHDMI/b ... _fb.S#L358

Dave

User avatar
hoglet
Posts: 7218
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

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

Post by hoglet » Tue Jul 10, 2018 10:44 am

tricky wrote:
Tue Jul 10, 2018 5:25 am
I was only looking to match a CRT, which would be twice the current resolution.
I've had a go at implementing this as you outlined:
https://github.com/hoglet67/RGBtoHDMI/b ... _fb.S#L313

I've been testing with RallyX, which seems to use 4.0us and 4.5us hsync pulses. So I'm doing a threshold test at 4.25us.

It's working beautifully - super smooth compared to using the SCART input.

I'm planning to order a few more CPLDs and build up a couple more boards this week. Would you like to be a beta tester?

Do you have a suitable HDMI monitor, HDMI cable and a Pi Zero?

Dave
Last edited by hoglet on Tue Jul 10, 2018 10:45 am, edited 1 time in total.

User avatar
tricky
Posts: 2539
Joined: Tue Jun 21, 2011 8:25 am
Contact:

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

Post by tricky » Tue Jul 10, 2018 1:44 pm

I would love to be a beta tester.

I have a couple of HDMI monitors and several TVs, several scart cables and a couple of never used pi zeros.

I do not have any Linux (or compatible) build environments, but I do have a couple of blaster/JTAG adapters.

I also have a cheap USB scope which I am planning on using to tweak mode 7 if required.

User avatar
hoglet
Posts: 7218
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

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

Post by hoglet » Wed Jul 11, 2018 4:41 pm

I wasn't really planning to go into "production" with these yet, but I've been busy soldering today and now five of the ten boards are finished and working:
IMG_1408.JPG
I'll try to get the other five boards I have built over the next couple of days.

Three of these boards are already allocated (two for myself and one for Tricky), so that leaves seven available.

I'm still waiting on bits to make the cables to go from the Beeb to the RGB-to-HDMI (including an appropriate crimping tool for the Molex connector).

In terms of how much these will cost, I basically just want to cover my costs, plus a couple of quid per board beer money.

So I was thinking of pricing them as follows:
- RGB to HDMI Pi Hat - £22.00
- 6-pin DIN (meta bodied to 6-pin Molex Cable £5.00
- Postage £4.40

There is a bit of a disclaimer:
- this is a first prototype run; if this makes you nervous, you might be better waiting
- you need to supply your own Pi Zero (with header), Micro SD Card, Case, Mini-HDMI cable and HDMI Monitor
- no other Pi model is supported (and actually won't work)
- it's been tested with the Electron, the Master 128 and the Model B
- the only known issue (noted earlier) is that Mode 7 on some Model B's can be suffer slight sampling jitter. On both my test machines this was eliminated by reducing C48 from 270pF to 100pF.
- the software is still under development, but what's there is perfectly usable
- the documentation is currently non-existent, but I'll try to put together a user manual on the wiki over the next few days

I'm not sure how many people will be interested at this early stage, but I do reserve the right to allocate these on a none-first-come-first serve basis, especially to people willing to help with the software development and/or testing.

If you are still interested in one of these given all this, then please let me know by posting in this thread.

Dave
Last edited by hoglet on Wed Jul 11, 2018 4:42 pm, edited 1 time in total.

User avatar
Elminster
Posts: 2346
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK
Contact:

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

Post by Elminster » Wed Jul 11, 2018 4:55 pm

I am happy to run a prototype, but will to bow to a better person. Although as noted before I am very good at breaking stuff.

Budgie
Posts: 76
Joined: Mon Nov 02, 2015 9:14 pm
Location: Manchester, UK
Contact:

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

Post by Budgie » Wed Jul 11, 2018 4:59 pm

I’d be interested in one please Dave.

Thanks !!

User avatar
Elk Towers
Posts: 497
Joined: Sun Apr 23, 2006 2:10 am
Location: Kettering, Northants
Contact:

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

Post by Elk Towers » Wed Jul 11, 2018 5:20 pm

I am very interested in one please Dave
Nick

User avatar
myelin
Posts: 420
Joined: Tue Apr 26, 2016 9:17 pm
Location: San Francisco, CA, USA
Contact:

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

Post by myelin » Wed Jul 11, 2018 5:30 pm

I'd be very interested in one (HAT + cable, shipped to San Francisco). Really glad to see this project reaching this stage :) Thanks Dave!

I'm probably going to be switching this between machines, and mounting it behind a monitor, so can I have a 100cm cable please?
Last edited by myelin on Thu Jul 12, 2018 3:49 pm, edited 1 time in total.
SW/EE from New Zealand, now in San Francisco, making BBC/Electron hardware projects for fun.
Most popular: fast serial port, FX2+PiTubeDirect Tube/Cartridge adapter, USB cart interface.

User avatar
KenLowe
Posts: 305
Joined: Mon Oct 18, 2004 4:35 pm
Location: Scotland
Contact:

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

Post by KenLowe » Wed Jul 11, 2018 5:33 pm

I'd like to take one too. Have all the other bits already, and I'm ready to test!

User avatar
tricky
Posts: 2539
Joined: Tue Jun 21, 2011 8:25 am
Contact:

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

Post by tricky » Wed Jul 11, 2018 5:40 pm

I have some 6 pin dins for my RGB to SCART cables and am happy to make my own cable if it helps.

User avatar
hoglet
Posts: 7218
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

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

Post by hoglet » Thu Jul 12, 2018 9:37 am

Here's the current status of the 10 prototype boards:

#01 - Hoglet (1) (1920x1080)
#02 - Hoglet (2) (1600x1200)
#03 - Tricky (no cable, just molex connector) (1920x1080, 1920x1200, possibly 1024x768)
#04 - Elminster (30cm cable) (1366x768?)
#05 - Budgie (60cm cable) (1920x1080)
#06 - Elk Towers (30cm cable, plus spare molex connector)
#07 - Myelin (100cm cable) (1920x1080)
#08 - KenLowe (100cm cable) (1920x1080, 1600x1200, 1680x1050, 1440x900, )
#09 - z0m8ied0g (30cm cable)
#10 - trixter (100cm cable) (1920x1080, 1600x1200)

It's probably going to take another week for me to get the rest of the boards and the cables made up.

The cables have a metal bodied 6-pin DIN soldered to one end and a 6-pin molex KK254 connector crimped to the other. They can be made to any length between 20cm and 150cm. Any longer than 150cm and I think the performance will degrade.

In terms of where you plan to place the unit, consider the following. There are three buttons on the board to drive the user interface. You don't need to use this (i.e. all settings can be statically configured in the config.txt file). But if you want to change things on the fly (e.g. palette, scanlines, re-calibrate, etc) then it's useful to be able to access this.

So if you plan to mount the unit inside your Beeb, or have it to hand close by I would recommend a short 30cm cable. If not, then a longer cable, up to maximum of 150cm.

Please can you let me know, either by PM or by editing your "I want one" post above if you would like a cable and how long. I'll then update this post to keep track.

Once I have everything ready to go, I'll PM each of you with payment details, and for your address.

Dave
Last edited by hoglet on Sun Jul 15, 2018 8:26 pm, edited 13 times in total.

User avatar
KenLowe
Posts: 305
Joined: Mon Oct 18, 2004 4:35 pm
Location: Scotland
Contact:

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

Post by KenLowe » Thu Jul 12, 2018 1:09 pm

Maybe a bit late to ask this question now, but is it possible to get beeb audio out through the HDMI link?

I have already replaced the 6 pin rgb din on my beeb with an 8 pin version and taken the speaker output from the motherboard over to the 2 spare pins. This works great with my SCART link to my TV and also when it goes via my SCART/ HDMI adaptor.

Getting something similar on the PI Zero solution would be awesome!

User avatar
hoglet
Posts: 7218
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

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

Post by hoglet » Thu Jul 12, 2018 3:58 pm

KenLowe wrote:
Thu Jul 12, 2018 1:09 pm
Maybe a bit late to ask this question now, but is it possible to get beeb audio out through the HDMI link?
This would be hard I think, in fact really hard!

From a hardware perspective, the Pi (to my knowledge) has no audio input. So we would need to add some kind of analog-to-digital convertor (ADC) to the RGB-to-HDMI hat. This itself would be a problem, as almost every GPIO is currently in use (even the ones we are not meant to use!)

From a software perspective we would then have to regularly read the ADC (e.g. at 44.1KHz this is every 22.7us). This is going to play havoc with sampling the video.

So at the moment I can't see a way to do this.

As a work work around, most TV/Monitors have an external audio input jack that's automatically used when there is no audio being passed over HDMI. It's possible to configure the Pi to not send audio by adding hdmi_drive=1 to config.txt. I've just tested this on my LG 22MN43 TV and this seems to work.

Does your TV have such an input?

Dave

User avatar
hoglet
Posts: 7218
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

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

Post by hoglet » Thu Jul 12, 2018 4:05 pm

Here's a few photos of the "production line" getting ready to build a couple more boards:
IMG_1411.JPG
IMG_1412.JPG
IMG_1413.JPG
Just two more left to build now.

z0m8ied0g has asked for board #09, so there's just one left now.

Dave

Budgie
Posts: 76
Joined: Mon Nov 02, 2015 9:14 pm
Location: Manchester, UK
Contact:

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

Post by Budgie » Thu Jul 12, 2018 4:10 pm

Very efficient. You can’t beat them Hakos, I have the older analogue control one.

User avatar
Elminster
Posts: 2346
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK
Contact:

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

Post by Elminster » Thu Jul 12, 2018 4:22 pm

Much to nice. My solder area is the dinning room table. This can cause time share issues. And mean I am for ever taking all the stuff up and down the stairs.

User avatar
hoglet
Posts: 7218
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

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

Post by hoglet » Sat Jul 14, 2018 11:31 am

Another update...

Yesterday I did a bit more on the software side:

Code: Select all

ebd2c801 Pi Firmware: Added info feature
349844f5 Pi Firmware: Improved OSD rendering performance in modes 0..6
94dac383 Pi Firmware: Fixed some OSD consistentency issues if mode changed while OSD active
e41da53b Pi Firmware: Improved key handling, no need to spin waiting for key to be release
5f964304 Pi Firmware: Fix flicker when updating OSD in modes 0..6
9fbe0a91 Pi Firmware: Allow for double buffering during calibration, much slicker UI in mode 0..6
Much of this was just tweaking the the user interface, which is now flicker-free in all modes.

This morning I finished soldering the boards, so all 10 are now finished, programmed and tested:
IMG_1415.JPG
I'm going to spend a day or so on documentation (on the Github Wiki), and hopefully the last of the cable bits and the crimping tool will arrive on Monday and I can make a start on the cables.

Dave

Post Reply