RGB to HDMI using a Pi Zero and a small CPLD

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
User avatar
trixster
Posts: 885
Joined: Wed May 06, 2015 11:45 am
Location: York
Contact:

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

Post by trixster » Fri Jul 20, 2018 7:34 am

What would be required to get the RGBtoHDMI working with the VideoNULA? And with an Atom?
A3020 | A3000 | A420/1 | BBC B | Master Turbo | ZX48K | NeoGeo
Atom | Amiga A4000 | A3000 | A1200 | A500 | PC Engine | Enterprise
Falcon | Saturn | PS1 | SNES | CPC6128 | C64 | 3DO | MD | Jaguar | X68000 | CD32

User avatar
hoglet
Posts: 8373
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 » Fri Jul 20, 2018 8:28 am

trixster wrote:
Fri Jul 20, 2018 7:34 am
What would be required to get the RGBtoHDMI working with the VideoNULA? And with an Atom?
I doubt working with the 4-bit RGB levels of VideoNuLa is technically possible. You would need:
- three video DACs
- a bigger CPLD
- four times as much GPIO and Memory bandwidth

It's the last part that is the killer.

With an Atom, you could design a new Hat that would attach to the PL4 and work with the 6847 output levels directly. But the analogue circuitry would be different to what we currently have. It needs to end up with 1-bit Y and 2-bits (each) of CR and CB. This is very doable, but it's effectively a new project.

It is something that interests me, but there is already a very good Atom PL4 to VGA convertor design:
https://github.com/hoglet67/AtomVGAWing
Because the Atom is 60Hz, it's much more compatible with VGA monitors than the Beeb is. It just uses 800x600 @ 60Hz and is pixel perfect.

Dave

User avatar
Elminster
Posts: 3692
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 » Fri Jul 20, 2018 8:34 am

hoglet wrote:
Fri Jul 20, 2018 8:28 am
trixster wrote:
Fri Jul 20, 2018 7:34 am
What would be required to get the RGBtoHDMI working with the VideoNULA? And with an Atom?
I doubt working with the 4-bit RGB levels of VideoNuLa is technically possible. You would need:
- three video DACs
- a bigger CPLD
- four times as much GPIO and Memory bandwidth

It's the last part that is the killer.
Do you mean Technically? From the list above sounds like you are saying it would be doable but need to switch to a FPGA and generally add more stuff making it a more expensive beast. i.e. a new project.

I assume testing in a machien with a videonula just using standard modes is not an issue?
Last edited by Elminster on Fri Jul 20, 2018 8:34 am, edited 2 times in total.

User avatar
hoglet
Posts: 8373
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 » Fri Jul 20, 2018 8:53 am

Elminster wrote:
Fri Jul 20, 2018 8:34 am
Do you mean Technically? From the list above sounds like you are saying it would be doable but need to switch to a FPGA and generally add more stuff making it a more expensive beast. i.e. a new project.
The bit that not (in my opinion) doable is having the Pi read video data and write it to memory four times faster than it currently does. That just not possible on a Pi. So yes, you could design a new hat with a small FPGA and some proper DACs. But the Pi just won't deal with that volume of data,

(As a data point, the current RGB to HDMI deals with 1-bit RGB and transfers 16 bits of data every 500ns over GPIO and into the frame buffer. It would need to run four times that speed to deal with 4-bit RGB.)

The only way to do this would be to put everything in an FPGA that is able to output HDMI. That's starts to be a pretty serious piece of hardware, and almost certainly not something that could be built at home.
Elminster wrote:
Fri Jul 20, 2018 8:34 am
I assume testing in a machien with a videonula just using standard modes is not an issue?
Probably it would work.

Dave

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

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

Post by tricky » Fri Jul 20, 2018 9:46 am

I'm not suggesting that you do it or that I want one, but could you spot the different colours as they arrive and effectively palatalise on the fly, passing on new colours at end of line to update the PI palette (probably requires GPU support) and only sending 4 bits per pixel (or 3 if 4 is too many, I can't remember).
This would give the wrong colours on the line where a new colour is seen, so could be problematic for games using more than 16 colours per frame.
Like I say, this is just a mental exercise.
I'm still hoping to allow one way communication to the PI to allow for changing the mapping for the eight colours , but this will probably need to wait until we can use the GPU to add a palette.

User avatar
hoglet
Posts: 8373
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 » Fri Jul 20, 2018 10:02 am

tricky wrote:
Fri Jul 20, 2018 9:46 am
I'm still hoping to allow one way communication to the PI to allow for changing the mapping for the eight colours , but this will probably need to wait until we can use the GPU to add a palette.
We can already use the GPU to customize the palette. Currently there is a somewhat adhoc selection of example palettes hard coded (which I'm happy to change). There is an option on the feature menu to change the palette, and also a property in the cmdline.txt file to set the default.

To implement a programmable palette we really just need to add the communications stuff (i.e. decode the hsync width). The only possible gotcha here is that the CPLD also uses the falling edge of hsync to start it's counters, so we possibly risk scrolling cropping the left or right few pixels. If this happens, then it's easily fixable but would involve re-programming the CPLD.

Tricky, do you have a proposal for the "protocol" we would use, and how this would be encoded as sync-pulse widths?

I'm also wondering how this would work in Mode 4,5,6 because in these modes the sync width control is somewhat coarser.

The other option is to encode the palette in the video data itself (preceded by 32-bit magic number). It would only need to be present for one field, so would probably not be noticeable unless there was a lot of palette changing. This might actually be easier to hack together.

Dave

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

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

Post by tricky » Fri Jul 20, 2018 12:53 pm

My original idea was to +/-2 to the width and -/+1 to the offset to make no visible difference on the screen for each bit. This was to allow "full speed/frame" comm's, but if it was just from vsync for a fixed number of lines that would be simpler. This would allow for about 38 bits, which would allow for simple "commands", although this could be greatly reduced.

For extended commands, I was thinking of using the first line of the display as 78 bits with the first colour being a 0 and any other colours being 1s. This would work for any mode and the first 7 scan lines could be displayed as black to hide the comms (just an option - only needed for mode 7, otherwise 1 line would do) for longer commands, the third line could be used as well etc.

Taking this to the extreme, if there was enough take up and more functionality could be coaxed from the GPU, I was thinking of having the PI grab sections of the screen and store them as sprites which would then be positioned using longer commands the would encode sprite, position, orientation etc The same could be done for encoded sound effects, which could be played on demand.

For early games like Centipede, the GFX hardware handles everything that moves using 48 bytes which would leave the beeb drawing the mushrooms and doing collision checking. I was also thinking that a Graphics Extension Rom replacement could be done that used the PI, but there doesn't seem to have been much use made of that, so best stick to what we know works and swap out palettes before running a game and maybe load a TSR to auto re-calibrate after a mode change.

User avatar
trixster
Posts: 885
Joined: Wed May 06, 2015 11:45 am
Location: York
Contact:

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

Post by trixster » Fri Jul 20, 2018 4:55 pm

Works great first time!

Master with RGBtoHDMI on the left, Beeb B using a GBS8200 on the right.

The picture does not do the RGBtoHDMI justice as it looks perfect.
Attachments
3A07CCAE-6805-40E8-A52F-24436B9E4834.jpeg
A3020 | A3000 | A420/1 | BBC B | Master Turbo | ZX48K | NeoGeo
Atom | Amiga A4000 | A3000 | A1200 | A500 | PC Engine | Enterprise
Falcon | Saturn | PS1 | SNES | CPC6128 | C64 | 3DO | MD | Jaguar | X68000 | CD32

User avatar
hoglet
Posts: 8373
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 » Fri Jul 20, 2018 5:00 pm

trixster wrote:
Fri Jul 20, 2018 4:55 pm
Master with RGBtoHDMI on the left, Beeb B using a GBS8200 on the right.

The picture does not do the RGBtoHDMI justice as it looks perfect.
Excellent news.

Can you post a photo of the Calibration Detail page after doing a Calibration in Mode 7?
- press left button once
- then press right button once

I'd be interested if you get down to zero errors, and how wide the "plateau" is.

I find a good screen to use for Calibration is the STH Menu, but any screen with plenty of text will do.
Last edited by hoglet on Fri Jul 20, 2018 5:00 pm, edited 1 time in total.

User avatar
KenLowe
Posts: 616
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 » Fri Jul 20, 2018 5:14 pm

Just picked my RGBtoHDMI up from the post office and hooked it up. Didn't realise it wasn't going to be compatible with the VideoNuLA, so I've dug out a non VideoNuLA modded Beeb to try this on.

Using a non 'W' Pi Zero to start with, my initial impression is that it looks really nice on my LG 4k TV. Running through the test programs on the supplied .ssd, I do notice the odd twinkle on the 'K' in mode 7 - in between where the '/' joins the '|'. Otherwise it seems to be pretty rock solid. I've not really put it through it's paces yet, though.

User avatar
hoglet
Posts: 8373
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 » Fri Jul 20, 2018 5:25 pm

Hi Ken,
KenLowe wrote:
Fri Jul 20, 2018 5:14 pm
Didn't realise it wasn't going to be compatible with the VideoNuLA, so I've dug out a non VideoNuLA modded Beeb to try this on.
Sorry that I didn't make that clearer.

I'm happy to refund you if you decide you don't want to keep it.

Actually, it should still work with VideoNuLA, it just won't be compatible with use of the palette.
KenLowe wrote:
Fri Jul 20, 2018 5:14 pm
Using a non 'W' Pi Zero to start with, my initial impression is that it looks really nice on my LG 4k TV. Running through the test programs on the supplied .ssd, I do notice the odd twinkle on the 'K' in mode 7 - in between where the '/' joins the '|'. Otherwise it seems to be pretty rock solid. I've not really put it through it's paces yet, though.
That does sound like what I've experienced with some of my Model Bs, and described earlier in the thread. The test program M7TEST4 contains the set of characters that are most probematic, because after character rounding they contain a single off pixel surrounded by on pixels:

$*4KMN^kmr¼¾

It does seems to be possible to improve that by reducing the value of C48 in the Beeb, e.g. to 100pF.

Dave
Last edited by hoglet on Fri Jul 20, 2018 5:32 pm, edited 4 times in total.

User avatar
KenLowe
Posts: 616
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 » Fri Jul 20, 2018 5:37 pm

hoglet wrote:
Fri Jul 20, 2018 5:25 pm
Sorry that I didn't make that clearer.

I'm happy to refund you if you decide you don't want to keep it.
Not at all. I'm really happy with it.
hoglet wrote:
Fri Jul 20, 2018 5:25 pm
It does seems to be possible to improve that by reducing the value of C48 in the Beeb, e.g. to 100pF.
Yes, I noticed that in the thread and in your manual, but not tried that yet. TBH, it's not that noticeable, and I'm pretty sure I see the same with my other SCART / HDMI adaptor.

Here's a couple of photos with the calibration details:
Attachments
20180720_182017.jpg
Mode 7
20180720_181824.jpg
Modes 0 - 6
Last edited by KenLowe on Fri Jul 20, 2018 5:41 pm, edited 1 time in total.

User avatar
trixster
Posts: 885
Joined: Wed May 06, 2015 11:45 am
Location: York
Contact:

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

Post by trixster » Fri Jul 20, 2018 6:00 pm

I’ll do some more testing tomorrow morning as out on the beers now! :)

One thing I did notice is that I autocalibrated the boot screen, left the machine for about ten minutes and then when I came back I noticed there were a few twinkles around the edges of the letters meaning I had to redo the calibration.
A3020 | A3000 | A420/1 | BBC B | Master Turbo | ZX48K | NeoGeo
Atom | Amiga A4000 | A3000 | A1200 | A500 | PC Engine | Enterprise
Falcon | Saturn | PS1 | SNES | CPC6128 | C64 | 3DO | MD | Jaguar | X68000 | CD32

User avatar
hoglet
Posts: 8373
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 » Fri Jul 20, 2018 6:06 pm

trixster wrote:
Fri Jul 20, 2018 6:00 pm
I’ll do some more testing tomorrow morning as out on the beers now! :)

One thing I did notice is that I autocalibrated the boot screen, left the machine for about ten minutes and then when I came back I noticed there were a few twinkles around the edges of the letters meaning I had to redo the calibration.
That's interesting.

I guess the first few minutes of on-time is when you would expect to see the most drift, as things get up to temperature.

I wonder if it's the Beeb or the Pi that's drifting most?

This is something I'll try to replicate over the weekend, because it would be good to understand the magnitude of these kind of changes.

I assume this was with the Master?
Last edited by hoglet on Fri Jul 20, 2018 6:06 pm, edited 1 time in total.

User avatar
Elminster
Posts: 3692
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 » Fri Jul 20, 2018 7:12 pm

My testing will have to wait as I don’t have the right cable yet, I did put on the reset header on the pi.

Edit: Hopefully order the right one this time, didnt notice was two versions, one for hdmi on mobile devices and one for RPI.
Last edited by Elminster on Fri Jul 20, 2018 9:14 pm, edited 1 time in total.

User avatar
trixster
Posts: 885
Joined: Wed May 06, 2015 11:45 am
Location: York
Contact:

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

Post by trixster » Fri Jul 20, 2018 7:13 pm

Affirm, with the Master.
A3020 | A3000 | A420/1 | BBC B | Master Turbo | ZX48K | NeoGeo
Atom | Amiga A4000 | A3000 | A1200 | A500 | PC Engine | Enterprise
Falcon | Saturn | PS1 | SNES | CPC6128 | C64 | 3DO | MD | Jaguar | X68000 | CD32

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

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

Post by tricky » Fri Jul 20, 2018 8:11 pm

Mine arrived today, I've made a cable and soldered up the PI.
The HDMI cable I had ready is too small for the PI, so I will have to dig another out tomorrow.
The PI doesn't seem to have a 1920x1200p50 mode, so I will go with 1080p50 and set the monitor to 1:1.

User avatar
hoglet
Posts: 8373
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 » Fri Jul 20, 2018 8:15 pm

tricky wrote:
Fri Jul 20, 2018 8:11 pm
The PI doesn't seem to have a 1920x1200p50 mode, so I will go with 1080p50 and set the monitor to 1:1.
If you look in the config.txt file, there is a 1920x1200p50 defined that you just need to uncomment:

Code: Select all

## 1920x1200 @ 50Hz
##
## Scale by 1:2 - 672x540 => 1344x1080
##   l/r overscan = (1920-1344)/2 = 288
##   t/b overscan = (1200-1080)/2 =  60
##
#hdmi_group=2
#hdmi_mode=87
#hdmi_cvt=1920 1200 50 5 0 0 0
#overscan_left=288
#overscan_right=288
#overscan_top=60
#overscan_bottom=60
hdmi_cvt is an easy way to define pretty much any custom screen mode.

Dave

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

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

Post by tricky » Fri Jul 20, 2018 9:50 pm

Sorry, I don't know how I missed that, I mist have also not searched for not 1200!

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

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

Post by tricky » Sat Jul 21, 2018 12:58 pm

Found a cable and had a few panic moments!
It turns out that the HDMI socket on my monitor is missing the socket and only has the flat centre section that goes into the plug and I can't get it working on the few resolutions that I have tried. This was followed by several more minor dramas!
Falling back to a Panasonic TV, I have it working :)

I am using a NuLA beeb to start with, so this might be part of the issue I am getting and I won't be using RGBtoHDMI on it long term.

I am going to try to make a better calibration screen for mode 1 as although text is great, when different colour combinations are adjacent, it gets confused. I don't know if this is a NuLA thing or not.

With mode 7, the smallest error I get is around 1400, so I may try swapping the cap tonight when my room cools off again.

User avatar
Elminster
Posts: 3692
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 » Sat Jul 21, 2018 1:20 pm

Is the vidnula on a Beeb or a master? Will try on master with nula later
Last edited by Elminster on Sat Jul 21, 2018 1:22 pm, edited 1 time in total.

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

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

Post by tricky » Sat Jul 21, 2018 1:21 pm

NuLA is on a Model B (early model 7).

User avatar
hoglet
Posts: 8373
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 21, 2018 1:54 pm

Hi Tricky,
tricky wrote:
Sat Jul 21, 2018 12:58 pm
Falling back to a Panasonic TV, I have it working :)
What resolution is the Panasonic TV?
tricky wrote:
Sat Jul 21, 2018 12:58 pm
I am going to try to make a better calibration screen for mode 1 as although text is great, when different colour combinations are adjacent, it gets confused. I don't know if this is a NuLA thing or not.
Probably stating the obvious, but the calibration screen needs to be static. The flashing cursor is OK, because we have discard the lines where the cursor might be so it doesn't introduce errors.

With Mode 0..6 I would expect the calibration to be error free at 4 of the 6 offsets.

You can try modifying the M0TEST to work in Mode 1 if you like:
- Change line 10 to MODE 1
- Change line 30 to be STEP 8

Or just use M0TEST in Mode 0.

Can you describe in a bit more detail what you are seeing, and maybe try to take a photo?

I've also just tried the Scramble.ssd that you sent, and that seems to be very clear and crisp on my Beeb. I did notice a small amount of tearing (briefy, about once a minute), which I think indicates the double buffering I thought I had included is actually not working. This is something I need to look into. The code in that area is quite complicated and a bit of a mess.

Thinking about the Video NuLA, the csync signal doesn't pass through the video processor, so that's going to be unaffected. So the only possible difference is the levels of the RGB signals. One thing you could try is enabling the "Mux=On" setting the feature menu. If that improves things, then it's definitely a levels thing.

Dave

User avatar
hoglet
Posts: 8373
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 21, 2018 3:23 pm

I've been pondering on compatibility with the VideoNuLA.

Maybe Rob can chip in here as well, as I'm guessing a bit.

I've beeb working from a photo of the board:
videonula.jpg
First, in terms of levels, there does seem to be three transistors (bottom left) buffering the R, B, G outputs from the CPLD. These look like emitter followers, so they will provide current gain but will reduce high level output voltage by 0.7v. The Beeb also contains emitter followers, which will give a further 0.7 reduction. So the high level output will be 3.3V - 0.7 - 0.7 which is 1.9V. This is significantly less than a normal Beeb output (3.5V) and so might be problematic. And that's ignoring any losses related to the resistor DACs.

Second, there is a separate independent 48MHz oscillator on VideoNuLA. I think this is used for both the VideoNuLA and also fed back into the Beeb as the 1/2/4/8MHz clocks (effectively replacing the Beeb's 16MHz clock). If this is the case, then there should be no pixel timing difference as far as RGBtoHDMI is concerned.

So even if the palette is programmed to provide the maximum RGB levels, there might possibly be an issue with levels. Selecting Mux=On in the feature menu may well help.

All speculation....

Dave
Last edited by hoglet on Sat Jul 21, 2018 3:25 pm, edited 1 time in total.

User avatar
trixster
Posts: 885
Joined: Wed May 06, 2015 11:45 am
Location: York
Contact:

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

Post by trixster » Sat Jul 21, 2018 5:27 pm

hoglet wrote:
Fri Jul 20, 2018 5:00 pm
trixster wrote:
Fri Jul 20, 2018 4:55 pm
Master with RGBtoHDMI on the left, Beeb B using a GBS8200 on the right.

The picture does not do the RGBtoHDMI justice as it looks perfect.
Excellent news.

Can you post a photo of the Calibration Detail page after doing a Calibration in Mode 7?
- press left button once
- then press right button once

I'd be interested if you get down to zero errors, and how wide the "plateau" is.

I find a good screen to use for Calibration is the STH Menu, but any screen with plenty of text will do.
Here you go:
72E094E9-7B6C-4FEB-9986-CE0AE896C567.jpeg
A3020 | A3000 | A420/1 | BBC B | Master Turbo | ZX48K | NeoGeo
Atom | Amiga A4000 | A3000 | A1200 | A500 | PC Engine | Enterprise
Falcon | Saturn | PS1 | SNES | CPC6128 | C64 | 3DO | MD | Jaguar | X68000 | CD32

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

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

Post by tricky » Sat Jul 21, 2018 5:35 pm

Turning on input mux got the mode 7 errors down from 1400 to about 100 (about 2 pixels) and completely fixed the scramble issues.
The mode 7 issues weren't on diagonals, but on the highlighted row on the games menu where red meets green on straight verticals.
The Panasonic appears to be doing the (stupid) default thing of stretching the image by 5% - this has never made any sense to me from an HDMI source!
The timing is off by 11ppm when cold and closes to about 5 when warm.
With input mux off in modes 0-6, I am lucky to get 2 of the six offsets being 0, but with it on, I usually get 4 zeros.

User avatar
hoglet
Posts: 8373
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 21, 2018 5:58 pm

tricky wrote:
Sat Jul 21, 2018 5:35 pm
With input mux off in modes 0-6, I am lucky to get 2 of the six offsets being 0, but with it on, I usually get 4 zeros.
And this is in the Model B with the VideoNuLA?

What model is the Panasonic TV?
Last edited by hoglet on Sat Jul 21, 2018 6:11 pm, edited 1 time in total.

User avatar
Elminster
Posts: 3692
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 » Sat Jul 21, 2018 8:00 pm

Okay I have mine up and runnng now. Using Electron to avoid any VideoNUla issues. Works okay although if I switch to composite on same monitor it runs smaller and crisper (i.e. higher res), so probably need to tweak the resolution.

No marking on unit at all as to what it is, and nothing in the menus.

Currently set to ## 720x576 @ 50Hz

Edit: It is unbranded but looks identical to one of these

https://www.ebay.co.uk/itm/ZOTER-12-Inc ... SwmgJY5eIf

Edit2: Auto calibrartion reports 0 errors.

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.

Edit4: Is the supplied SSD only for the Beeb? Or will those tests work on Electron as well?

Edit5: Thinking about it are there any games on the Electron that do clever 'tricky' things with the video hardware. Pretty happy with the colour picture for games, for text only composite is a little sharper, but for games HDMI is superior by far.

Edit6: Some photos
Attachments
IMG_4079.jpg
IMG_4078.jpg
Last edited by Elminster on Sat Jul 21, 2018 8:26 pm, edited 7 times in total.

User avatar
davidb
Posts: 2458
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

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

Post by davidb » Sat Jul 21, 2018 8:29 pm

Elminster wrote:
Sat Jul 21, 2018 8:00 pm
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?

User avatar
Elminster
Posts: 3692
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 » Sat Jul 21, 2018 8:33 pm

Yep. Fire track was one of the ones I choose. Will give that one a go.

Generally it looks like I have proved a good baseline. i.e. hardware working with monitor on Electron.

Then I have to go try some tricky stuff on Beebs and masters.

Post Reply