RGB to HDMI using a Pi Zero and a small CPLD

[Budgie]

Okay so here's mine. Works flawlessly so far.

The first 4 images are from the BBC micro. The last 2 are from an issue 6 Electron. The TV resolution is 1920 x 1080 50Hz

Just realised I didn't set Elk=1 in cmdline but it seems to be fine ?

[Elminster]

Edit3: Playing in colour is a novelty though. Played Boxer, the last game on the game challenge, seems pretty good. Anyone remember if they is anything taxing I might have choosen on the MGC, other wise I ma going to need to load up DC or GoSDC with stuff.

Depends what you have on the MGC. Firetrack, perhaps?

Okay not played Firetrack before but the graphics are stunning.

As Iused to use an Electron on a 10inch manual tune black and white TV. And I have been using it modern day on composite (i.e. black and white) I cant ever recall having a better picture on an Electron I own.

So for Electron Issue 4 on an unbranded 12inch ebay HDMI monitor, it does the business.

[trixster]

Having 50hz is brilliant. Coming from my gbs8200 which only outputs 60hz, the smooth 50hz scrolling on my dell 2001fp is fantastic

[hoglet]

The first 4 images are from the BBC micro. The last 2 are from an issue 6 Electron. The TV resolution is 1920 x 1080 50Hz

The third image, M0TEST, looks like the monitor is also doing some scaling, as the vertical lines are uneven.

What's the TV/Monitor model?

Might be worth seeing if there are settings like:
a) Overscan: off, or
b) Aspect ratio: "1:1" or "Original" or "Just Scan"

Dave

[tricky]

Here is a link to the video of what the fuel bar corruption looks like on the NuLA beeb with mux off.
https://www.dropbox.com/s/66v26f14tinrg ... n.avi?dl=0
With the mode 0 test screen, in the left hand edge line, the corruption can be seen moving down the screen several times a second.
It looks to me like two clocks slightly out of sync, but as I say, there are no issues with mux on, other than might be fixed by a cap swap.

As I say though, I'm not planning on using it/them on a NuLA'd beeb, so I will swap to another beeb today.

PS Just tried another beeb, works fine, mux seems to make no difference and today the Panasonic isn't stretching the picture!
It has a TWO MEG card in it which seems to conflict with the user port, so I might need to set up the GOTEK too.

[hoglet]

Here is a link to the video of what the fuel bar corruption looks like on the NuLA beeb with mux off.
https://www.dropbox.com/s/66v26f14tinrg ... n.avi?dl=0
With the mode 0 test screen, in the left hand edge line, the corruption can be seen moving down the screen several times a second.
It looks to me like two clocks slightly out of sync, but as I say, there are no issues with mux on, other than might be fixed by a cap swap.

That does just look like the video level being a bit low. The Mux=On setting does is to take the RGB signals after they have been fed through the 74LS08, which has a slightly lower switching threshold than the CPLD. It's also useful to do this on older Elks.

Dave

[BigEd]

To implement a programmable palette we really just need to add the communications stuff

I had some thoughts about in-band signalling:
- put data in the last line of the frame
- add a checksum at the end (perhaps very simple XOR)
- the Pi should do nothing special if the last line has a bad checksum
- the Pi should rewrite a line with a good checksum as all-black for display purposes
- just possibly the CPLD could compute and validate the checksum, if there's room for one more bit from the CPLD to the Pi?
- and finally, of course, if the checksum is good the Pi should decode the line as a command

[hoglet]

Lots of good ideas there Ed - I do particularly like the idea of in-band signalling in the video data.

- just possibly the CPLD could compute and validate the checksum, if there's room for one more bit from the CPLD to the Pi?

I don't think this will be possible, as it would require several additional registers.

A couple of minor complexities:

1. Depending on the screen mode, Beeb pixels will map to 1, 2, or 4 pixels. So probably we should design the encoding around Mode 2/5 pixels, which gives us 160 bits.

2. We can't guarantee the Beeb pixels ends up at an exact offset in the 672 pixel frame buffer - it varies depending on screen mode, and also on the sampling offset. So we probably need some kind of start bit, or sync byte.

All quite doable though.

If we restrict the colour palette to 4096 colours, then the full palette is 8 x 12 = 96 bits, so that fits nicely.

Dave

[hoglet]

In other news, I've finally managed to adjust the frequency of the PLLH (which us user for the HDMI clock) by writing to the clock manager registers:
https://github.com/hoglet67/RGBtoHDMI/b ... dmi.c#L319

I can also put a marker on the screen at the point that the HDMI VSync is detected, which allows you to observe the phase of the HDMI VSync wrt the Beeb's VSync. After calculating for the clock error and updaing PLLH, this marker is very stable.

It's interesting to deliberately introduce a known clock error, so the VSync phase shifts continuously. This has demonstrated the the double buffering scheme I have currently implemented is not sufficient to avoid tearing. So I need to upgrade this to triple buffering. Done correctly, it seems that triple buffering not only eliminates tearing, it actually reduces lag (compared to double buffering). At least, according to this article.

So I'm going to have a stab at that tomorrow.

Dave

[hoglet]

I've been working on the dev branch today and have added three new items to the feature menu:

1. An "HDMI Clock" setting to compensate for the clock offset between the Beeb and the Pi, and also compensate for games that run with interlace off (i.e. 50.08Hz rather than 50Hz).

2. A "VSync" setting that is a debugging aid to let you see the position of the Pi's HDMI VSync compared to the Beeb's VSync. Useful to check the previous setting is correct. Currently this is only visible in Modes 0..6.

3. A "Num Buffers" setting that changes the buffering strategy used in Modes 0..6:
- single buffering (minimal latency, but lots of potential for tearing and currently messes up the OSD)
- double buffering (typically an extra 20ms latency, but greatly reduces tearing)
- triple buffering (eliminates all tearing)
- quadruple buffering (overkill, never really needed)

More buffers doesn't necessarily mean more latency, it just means those buffers are available if needed. In all cases the Pi should flip to the most recently written buffer on HDMI VSync. So in practice there is little difference in latency between 2, 3 and 4 buffers.

This is quite a big change, so I need to do more testing tomorrow before I merge back to master.

But if anyone is dead keen to try this, there is a test build available here:
https://github.com/hoglet67/RGBtoHDMI/r ... 23_156dec8

I've been using Tricky's scramble as a test program, and then deliberately setting "HDMI Clock" to 623 or 625 to induce VSync slip. The correct behaviour is to drop or replicate a frame as needed, rather than tear. When "HDMI Clock" is set to 624 the sync rates match very closely indeed.

Dave

[Elminster]

i am away from my machine at the moment, but my conclusion was the Electron was perfect. Will see what it does on the Nula’s Master next, then swap to a Nula’s free Beeb b issue 7 or a b+

Edit: is the videonula the only addon expected to break things? I might have asked this already.

[hoglet]

Edit: is the videonula the only addon expected to break things? I might have asked this already.

Yup, definitely not designed to deal with the "non-digital" RGB values you get using the palette.

It should work if you don't use the palette, and set Mux=On in the OSD (or mux=1 in cmdline.txt)

Dave

[myelin]

Finally set mine up, and it works very nicely with my Master 128. Thanks Dave! Now I can run three computers at VCF West rather than two

[sjo03]

I was late to see this topic. If another batch would be made - would definitely be interested in getting one or two.

[marcusjambler]

Also registering interest in one built up board

Marcus

[hoglet]

Hi Guys,

Thanks for the interest, but I just want to make it clear that I'm not planning to produce any more built-up boards, at least not in the near future. It took me the best part of a week, working 8-10 hours a day, to produce the previous 10, when you include all the time for component ordering, building, cleaning, programming, testing, packaging, shipping, etc. The final accounts say I made a profit of £13.61.

All the design files are on github (including the gerber files for the PCB) and the design is open source so you (or anyone else) are welcome to order the parts and make these up yourself. If you are reasonable at through-hole soldering, but have yet to do any surface mount assembly, this is a good board to start on.

regards

Dave

[daveejhitchins]

The final accounts say I made a profit of £13.61

Wow! . . . That's £1.36/unit - I've just got to get a viewing of your business plan, Dave - it seems to be far better than mine

Dave H

[trixster]

Swapped the pi zero W out for a normal v1.3 pi zero, still works great!

[Elminster]

Random people thought, could he debug output from hdmi board give any useful information for debugging video issues? Not specifically my issue but in general,or perhaps I should say what sort of video issues could you debut with this?

[hoglet]

Random people thought, could he debug output from hdmi board give any useful information for debugging video issues? Not specifically my issue but in general,or perhaps I should say what sort of video issues could you debut with this?

About all it could tell you is exactly what the VSync period is, and whether the video is interlaced or not.

I think you can tell that easily with a scope as well.

Dave

[Elminster]

Random people thought, could he debug output from hdmi board give any useful information for debugging video issues? Not specifically my issue but in general,or perhaps I should say what sort of video issues could you debut with this?

About all it could tell you is exactly what the VSync period is, and whether the video is interlaced or not.

I think you can tell that easily with a scope as well.

Dave

Ah okay just a thought. Although could be useful for someone without a scope I guess.

[tricky]

If you have a scope capable of capturing and syncing to the signal!
I couldn't capture my vsync issue on my cheap USB scope if you remember.
Sometimes, it would be helpful to get a log of scan line counts between vsyncs, especially if it isn't 312/313.

[Elminster]

As part of my testing the fixed video on my Beeb issu4 I have tested the following.

- Kix
- Frenzy
- Tricky Space Invaders
- Tricky Frogger
- Tricky AstroBlast
- Bad Apple (Mode 7)

Only thing I have noticed is on space invaders the backgroud shakes a little. I guess everything is shifting 1 pixel back and forth. Not qite sure how to describe it. Not sure a video would pick it up.

[hoglet]

Only thing I have noticed is on space invaders the backgroud shakes a little. I guess everything is shifting 1 pixel back and forth. Not qite sure how to describe it. Not sure a video would pick it up.

Do you have a link to the .ssd file? I'll give it a try as well.

[Elminster]

Only thing I have noticed is on space invaders the backgroud shakes a little. I guess everything is shifting 1 pixel back and forth. Not qite sure how to describe it. Not sure a video would pick it up.

Do you have a link to the .ssd file? I'll give it a try as well.

viewtopic.php?f=57&t=12474&p=167377&hil ... rs#p167377

[tricky]

Only thing I have noticed is on space invaders the backgroud shakes a little. I guess everything is shifting 1 pixel back and forth. Not qite sure how to describe it. Not sure a video would pick it up.

Do you have a link to the .ssd file? I'll give it a try as well.

Most of my stuff is on bbcmicro.co.uk, search for broadhurst.

[Elminster]

i like frogger, it was really clean and crisp on HDMI, could not spot any artifacts. And plays well to boot.

[alienkidmj12]

are you able to give me some advice to those less fortunate to have a complete one and a bit unsure how to proceed with putting these together ?

what do we do with the files for this, what do i we load gerber files into ?

what programmers do we need if any ?

thanks

dave

Only thing I have noticed is on space invaders the backgroud shakes a little. I guess everything is shifting 1 pixel back and forth. Not qite sure how to describe it. Not sure a video would pick it up.

Do you have a link to the .ssd file? I'll give it a try as well.

[bprosman]

Maybe a weird/dumb question but can this also be used to create an Atom "color board" ?

Kind regards, Bram

[Elminster]

Maybe a weird/dumb question but can this also be used to create an Atom "color board" ?

Kind regards, Bram

Similar question asked/answer here, does that answer your question?

viewtopic.php?f=3&t=14430&p=209125&hilit=Atom#p209125