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: 8366
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 Feb 26, 2019 2:21 pm

1024MAK wrote:
Tue Feb 26, 2019 2:14 pm
I was thinking that the 32 bit sentinel should have a mix of duty cycles between bit changes. Maybe something like 0xCD6638 ?
Out of interest, why?

User avatar
IanB
Posts: 386
Joined: Sun Sep 04, 2011 7:28 pm
Location: South Wales
Contact:

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

Post by IanB » Tue Feb 26, 2019 8:52 pm

hoglet wrote:
Mon Feb 25, 2019 8:09 pm
This should now be fixed in CPLD version v2.2.
Thanks, as you are making changes to the CPLD, have you had a chance to look at the viability of adding the other options I mentioned previously:
1. Separate H & V syncs which would mean V sync on another input such as the unused link and use the current csync as the hsync.
2. Intensity bit for 16 colour capture. I think this one would be harder but it might be possible to free up some space as the delay value is currently 4 bits but only 2 bits are actually required in hardware, the reset of the delay can be created by adding (delay value/4) to the hoffset which is a software delay.
(Alternatively that could be a different build using the mux inputs for the extra bits and dropping mode 7 support)

Other software ideas:
Smaller frame buffers (half current resolution)
Using smaller frame buffers would help with integer scaling with some sources and monitors.
e.g. I'm currently capturing the ZX81 with a BBC resolution buffer of 672 x 504 and integer scaling by 2x2 on a 1600x1200 monitor . If that was halved to 336 x 252 the integer scaling could be 3x3 on a 1024x768 monitor. Also the ZX81 pixels aren't really square so on a 1600x1200 monitor the capture area could be 320x252 with integer scaling of 5x4 which might look better. There is already the option to capture only the odd or even pixels which was created for the atom so those options could be adapted to write to a half horizontal resolution buffer.
The two main issues with half vertical resolution is that the menus would be double height and might not fit unless a smaller font was used and the scan lines option wouldn't work.
Last edited by IanB on Tue Feb 26, 2019 8:55 pm, edited 1 time in total.

User avatar
hoglet
Posts: 8366
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 Feb 26, 2019 9:05 pm

IanB wrote:
Tue Feb 26, 2019 8:52 pm
1. Separate H & V syncs which would mean V sync on another input such as the unused link and use the current csync as the hsync.
This should be possible. I think the only thing it affects is the CSYNC output to the Pi, which would need to be generated as HSYNC xor VSYNC. All the other logic in the CPLD would continue to use HSYNC only. Does that match your thinking?
IanB wrote:
Tue Feb 26, 2019 8:52 pm
2. Intensity bit for 16 colour capture. I think this one would be harder but it might be possible to free up some space as the delay value is currently 4 bits but only 2 bits are actually required in hardware, the reset of the delay can be created by adding (delay value/4) to the hoffset which is a software delay.
(Alternatively that could be a different build using the mux inputs for the extra bits and dropping mode 7 support)
This one feels more like a new CPLD version (as the AtomCPLD is).

What's the maximum horizontal resolution it would need to work at?
IanB wrote:
Tue Feb 26, 2019 8:52 pm
Other software ideas:
Smaller frame buffers (half current resolution)
...
The two main issues with half vertical resolution is that the menus would be double height and might not fit unless a smaller font was used and the scan lines option wouldn't work.
This is going to be hard work to implement. It's probably not something I feel like working on myself.

Dave
Last edited by hoglet on Tue Feb 26, 2019 9:06 pm, edited 1 time in total.

User avatar
1024MAK
Posts: 9050
Joined: Mon Apr 18, 2011 4: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 » Wed Feb 27, 2019 11:06 am

hoglet wrote:
Tue Feb 26, 2019 2:21 pm
1024MAK wrote:
Tue Feb 26, 2019 2:14 pm
I was thinking that the 32 bit sentinel should have a mix of duty cycles between bit changes. Maybe something like 0xCD6638 ?
Out of interest, why?
Although any predetermined (and fixed) “random” number will do for a special “magic” sentinel number, this assumes that the system always catches the start correctly and grabs the bits at the correct rate. If the test to see if the captured number is the same as expected fails, then obviously something went wrong.

Having a number with recogniseable patterns within it, with different duty cycles between bit changes allows for the software (if designed to do so), to allow the system to synchronise better at the next attempt.

By having a mix of duty cycles between bit changes, it may give increased protection against some types of interference causing bits to flip state, it also is less likely that the “magic” sentinel number of this form will be present in screen video data or the data following the the “magic” sentinel number.

At least, that is my thinking...

Mark

User avatar
tricky
Posts: 3600
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 Feb 27, 2019 1:48 pm

A good start on that note might be to eliminate all byte patters from the beeb font + black and white.

It should be easy and cheap to change the first (or second, I haven't checked timing) hsync pos/width after vsync and then restore it if you want a non-visible, non-accidental way of flagging that the data on the first line should be interpreted as commands.

User avatar
IanB
Posts: 386
Joined: Sun Sep 04, 2011 7:28 pm
Location: South Wales
Contact:

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

Post by IanB » Thu Feb 28, 2019 11:30 pm

hoglet wrote:
Tue Feb 26, 2019 9:05 pm
This one feels more like a new CPLD version (as the AtomCPLD is).
Yes that seems likely but it would be nice to get something working on the existing PCB layout with minimal mods for prototyping
hoglet wrote:
Tue Feb 26, 2019 9:05 pm
What's the maximum horizontal resolution it would need to work at?
640x200/60Hz with a pixel clock of 4x NTSC subcarrier (~14.318Mhz)

The other PC related standards that could be converted to HDMI are EGA and MDA/Hercules
EGA is 640×350/60Hz with a pixel clock of 16.257Mhz and has 2 bits each of RGB so 6 bits in total
The extra 3 bits could be fed into the Mux inputs
This is double the bits but the capture loop wouldn't need to double up the vertical resolution so only one screen write per capture.

MDA is 720x350/50Hz with a pixel clock of 16.257Mhz and has 1 bit luminance and 1 bit intensity

Hercules is MDA compatible but uses a 16 Mhz clock instead.

Note that the separate syncs are +ve going so a composite syncs signal generated from them would need to be inverted.
As the link input is currently pulled high you could do an exclusive NOR of that input and the existing sync input and feed that to the rest of the system.
For normal BBC type operation, that would leave the composite sync unmodified but for positive going H and V syncs (feeding Vsync into the link input) that would result in a negative going composite sync. It would also allow the link to be used as a composite sync invert option.
hoglet wrote:
Tue Feb 26, 2019 9:05 pm
This is going to be hard work to implement. It's probably not something I feel like working on myself.
I'm going to look at this once I have the palette stuff working. (Horizontal half resolution should be straightforward enough which would sort out the ZX81 5x4 scaling)

The other thing that needs looking at is blanking the screen on loss of sync which is mainly required for the ZX80/81.
Last edited by IanB on Fri Mar 01, 2019 1:06 am, edited 4 times in total.

User avatar
BigEd
Posts: 2567
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

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

Post by BigEd » Fri Mar 01, 2019 10:57 am

IanB wrote:
Thu Feb 28, 2019 11:30 pm
I'm going to look at this once I have the palette stuff working.
I was round at Dave's the other day, with revaldinho, and he was demonstrating your palette idea with the in-band signalling and your slideshow of RobC's images. It does look very good.

I was reminded of the Amiga's Copper. I wondered if it might be an idea to do something similar. Instead of an instruction in the image which is always executed immediately - and with some difficulty in implementing mid-image palette updates - the data packets could comprise a simple schedule of updates which is then applied on every subsequent frame. On line 0, apply this palette, on line 100 apply this one, and so on. As a second idea, instead of loading a new 12 bit RGB value into one of 16 palette entries, because the Pi is already displaying a byte-per-pixel frame buffer, we can have 16 sets of 16 palette entries, and once the palette is loaded, the per-line updates need only specify 4 bits to switch the palette set. I'm hoping that the Pi's painting of the framebuffer could be cheaply enough updated so the top nibble comes from a table, perhaps a table of 256 nibbles, one per line. In which case the Copper program is just updating this table, perhaps only once in one early frame, such that it applies to all subsequent frames, and those frames don't need to include any specially formatted lines.

Another aspect of this idea is that a second generation videoNuLA with a second or a larger CPLD could perhaps follow the same model. And then we could have software which works with both of the two palette-enhancing Beeb upgrades.

cervaro
Posts: 6
Joined: Sun Feb 18, 2018 9:31 am
Contact:

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

Post by cervaro » Sat Mar 02, 2019 12:29 pm

danielj wrote:
Sat Feb 16, 2019 6:33 am
If nothing has changed with the design (not kept up with thread!) I have some pcbs that I can farm out for a couple of quid including postage.
Do you still have any of these?

Can't recall if the PCB design was in the original thread to make for ourselves?

User avatar
danielj
Posts: 7399
Joined: Thu Oct 02, 2008 4:51 pm
Location: Manchester
Contact:

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

Post by danielj » Sat Mar 02, 2019 12:40 pm

Hello, yes, I've still got a fair few. I've enabled PMs for you :)

All the design stuff is on github: https://github.com/hoglet67/RGBtoHDMI/w ... -Materials

d.

User avatar
IanB
Posts: 386
Joined: Sun Sep 04, 2011 7:28 pm
Location: South Wales
Contact:

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

Post by IanB » Sat Mar 02, 2019 8:59 pm

BigEd wrote:
Fri Mar 01, 2019 10:57 am
I was reminded of the Amiga's Copper. I wondered if it might be an idea to do something similar. Instead of an instruction in the image which is always executed immediately - and with some difficulty in implementing mid-image palette updates - the data packets could comprise a simple schedule of updates which is then applied on every subsequent frame. On line 0, apply this palette, on line 100 apply this one, and so on.
I have considered doing something like a copper list and it might be possible but timing is always the issue as everything is so marginal. Also you wouldn't be able to update the palette mid screen as the Pi only updates the palette on the next frame sync (at least from a mailbox call). It might work if was possible to write directly to the palette locations.
BigEd wrote:
Fri Mar 01, 2019 10:57 am
As a second idea, instead of loading a new 12 bit RGB value into one of 16 palette entries, because the Pi is already displaying a byte-per-pixel frame buffer, we can have 16 sets of 16 palette entries, and once the palette is loaded, the per-line updates need only specify 4 bits to switch the palette set. I'm hoping that the Pi's painting of the framebuffer could be cheaply enough updated so the top nibble comes from a table, perhaps a table of 256 nibbles, one per line.
At the moment the Pi's buffer is only 4 bits/pixel, not 8 so that would need a significant change and as mentioned the timing is so marginal that it might not work at all. I think Dave has managed to get the Atom working with 8 bits/pixel but that is using a pixel clock of 14.318Mhz rather than 16 Mhz which means timing is a bit more lax. (Mode 7 uses a 12 Mhz pixel clock which is why there is a lot more time left to do the deinterlacing)
Actually the problem is more one of latency rather than absolute timing as some instructions (like memory access with cache misses and branches) start to take unpredictable times and even if they only do that occasionally it results in random screen glitches.
e.g. I've just been struggling to fix random glitches using the latest version of the sentinel detection code which works anywhere on the screen but I was getting an occasional line randomly jumping to the left by one word's worth of pixels which I eventually tracked down to having an extra branch in the capture loop. Once that was worked around with some conditional instructions the problem went away. There is still quite a bit of CPU time available for register based instructions but as soon as you start using branches or memory read/writes things begin to fall apart rapidly.

It might be possible to get 8 bits/pixel working using the reduced vertical resolution mentioned in my earlier post:
At the moment the Pi's buffer is always 540 pixels high and that is essential for mode 7 which is actually 504 lines high after deinterlacing but modes 0-6 are only 256 lines high so each line is written twice to the buffer during capture. If the Pi's buffer was reduced to 270 lines high for modes 0-6 then only one write would be needed for 4 bits/pixel but two writes for 8 bits/pixel might then work. The buffer is already being scaled up to the final resolution by the Pi's GPU so reducing the vertical resolution of the buffer won't have any effect on the final output.
The only disadvantage to switching to half vertical resolution is that the scan lines option won't work (unless some custom GPU scaling code is used) and the OSD might need to be modified as it is using the larger mode 7 font so all osd text would be double height unless a smaller font like the beeb's standard 8x8 font was used.
Last edited by IanB on Sat Mar 02, 2019 9:34 pm, edited 2 times in total.

User avatar
BigEd
Posts: 2567
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

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

Post by BigEd » Sat Mar 02, 2019 9:10 pm

OK, if the Pi's frame buffer is only 4 bits then that's a somewhat different story!

I'm thinking that making the interface one of specifying lines where things will happen should remove the need to do any accurately-timed updates: the problem is now a spatial one. Which means it affects what we write, not when we write it. I'm thinking this should be much more tractable. The assumption is that most applications don't need accurate timing, they actually need accurate placement - it's just that on the Beeb the two are the same. If we can have two or three palette changes on particular lines for every subsequent frame, that opens up a lot of extended palette options for graphics, although of course not completely general.

User avatar
BigEd
Posts: 2567
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

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

Post by BigEd » Sat Mar 02, 2019 9:12 pm

(Interesting idea though to get rid of the line-doubling. That sounds great to me, and I personally wouldn't miss the scan lines.)

User avatar
IanB
Posts: 386
Joined: Sun Sep 04, 2011 7:28 pm
Location: South Wales
Contact:

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

Post by IanB » Sun Mar 03, 2019 4:13 am

BigEd wrote:
Sat Mar 02, 2019 9:10 pm
OK, if the Pi's frame buffer is only 4 bits then that's a somewhat different story!
I managed to get the in band control working with an 8 bits per pixel buffer without having to halve the vertical resolution so things are looking more promising for your second option of multiple pre programmed 16 colour palettes that can be switched on a per line basis. Also the in band control can now have commands on multiple lines in a single screen which would be needed to program a full 256 colour palette in a single frame

The main issue with an 8bpp buffer is that the osd can't be redrawn within the blanking period. Putting the menu on the screen halves the frame rate and also seems to mess up palette programming and genlocking so maybe rewriting the menu display code in assembler might help or perhaps switching to the simpler 8x8 font and half vertical resolution would eliminate these timing issues.
Last edited by IanB on Sun Mar 03, 2019 5:13 am, edited 1 time in total.

User avatar
BigEd
Posts: 2567
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

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

Post by BigEd » Sun Mar 03, 2019 8:25 am

It may be a stretch to wrestle it to the ground, but I think the Pi's videocore should be able to overlay two frame buffers (indeed, it should be able to apply a scanlines effect as a post-process, but that probably takes even more research and experiment!)

Or, as you say, a bit of assembly code might be able to do the OSD overlay in the time available.

User avatar
IanB
Posts: 386
Joined: Sun Sep 04, 2011 7:28 pm
Location: South Wales
Contact:

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

Post by IanB » Sun Mar 03, 2019 4:08 pm

BigEd wrote:
Sun Mar 03, 2019 8:25 am
It may be a stretch to wrestle it to the ground, but I think the Pi's videocore should be able to overlay two frame buffers (indeed, it should be able to apply a scanlines effect as a post-process, but that probably takes even more research and experiment!)
I'll probably be looking at overlaying frame buffers with the GPU someday for the Pi based Prisma 3 emulator.

Meanwhile I've fixed some of the issues with the OSD, it still halves the frame rate but the loss of lock and palette glitching have been fixed. This latter issue was caused by the code paths that handle the sentinel data being pushed out of the cache by the osd code during blanking so I've had to create a preload cache call that exercises all possible code paths for the capture code (including the in band data handler) just before a frame grab begins which eliminates any time delays caused by cache misses.
Last edited by IanB on Sun Mar 03, 2019 4:10 pm, edited 1 time in total.

User avatar
IanB
Posts: 386
Joined: Sun Sep 04, 2011 7:28 pm
Location: South Wales
Contact:

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

Post by IanB » Mon Mar 04, 2019 1:08 am

I've got the half resolution capture working using the existing OSD and it just about fits. I had to edit a few menu lines to shorten them and the menu titles are automatically suppressed on low resolution frame buffers to free up screen space. The calibration info will need reformatting a bit but for the most part it's perfectly usable.

Here's a screenshot with a 336x270 framebuffer:

halfres.jpg

This small frame buffer isn't suitable for the BBC as it won't work in mode 0 but the above mode 2 screenshot demonstrates the idea
(It could be used with just half vertical resolution but the only benefit of that might be some more options for integer scaling vertically.)
BigEd wrote:
Fri Mar 01, 2019 10:57 am
As a second idea, instead of loading a new 12 bit RGB value into one of 16 palette entries, because the Pi is already displaying a byte-per-pixel frame buffer, we can have 16 sets of 16 palette entries, and once the palette is loaded, the per-line updates need only specify 4 bits to switch the palette set.
I've now got that working, you can preset on a per line basis which 16 colour palette to use out of a total of 16 palettes although 8 palettes (128 colours) is a more practical limit because the osd uses 1 bit of each byte. You can use all 256 colours but when the osd is switched on the top 128 will all turn white.
Here's a mode 2 test pattern with 128 colours:

multipal.jpg

This will also work in mode 1 with 16 four colour palettes and mode 0 with 16 two colour palettes. A Spectrum style attribute mode where each 8x8 block of pixels can use one of the 16 palettes might also be possible in the future.
Last edited by IanB on Mon Mar 04, 2019 5:16 am, edited 2 times in total.

User avatar
BigEd
Posts: 2567
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

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

Post by BigEd » Mon Mar 04, 2019 8:28 am

Now that does look rather special - well done! I take it this approach has the feature of persistence - that most frames don't need the special code in the picture, because all the palette changes have already been scripted?

User avatar
IanB
Posts: 386
Joined: Sun Sep 04, 2011 7:28 pm
Location: South Wales
Contact:

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

Post by IanB » Tue Mar 05, 2019 12:15 am

BigEd wrote:
Mon Mar 04, 2019 8:28 am
Now that does look rather special - well done! I take it this approach has the feature of persistence - that most frames don't need the special code in the picture, because all the palette changes have already been scripted?
The command protocol has a persistent flag so you can choose whether it only works when the special code is present or continues working once the codes have been removed from the screen buffer.

Following on from the half resolution changes, I've been doing some tests with the ZX81 using 5:4 scaling and the results look more like the normal ZX81 output and it can be made to fill the screen even with integer scaling. I think the actual ZX aspect is approx 4.5:4 so both 4:4 or 5:4 are approximations with similar amounts of error. Exactly 4.5:4 can be achieved but it requires interpolation to be switched on so you lose the sharpness.

I used a 320 x 300 buffer which scaled to 1600x1200 with 5:4 integer scaling. A 320x270 buffer could be used to get 1600x1080 for a HD monitor.

zx81-5to4.jpg
zx-zoom5to4.jpg
zx-5to4-geometry.jpg
hoglet wrote:
Mon Nov 19, 2018 11:27 am
I've been looking at the registers that control the Pi's "Pixel Valve", which is the piece of hardware in the BCM2835 chip that actually drives the HDMI interface and is responsible for all the video timings.
Did you find any registers related to the overscan settings when looking at the Pi's video registers as it would be useful to auto set the overscan which varies depending on the frame buffer size.
Last edited by IanB on Tue Mar 05, 2019 12:34 am, edited 1 time in total.

User avatar
hoglet
Posts: 8366
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 Mar 05, 2019 7:08 am

IanB wrote:
Tue Mar 05, 2019 12:15 am
Did you find any registers related to the overscan settings when looking at the Pi's video registers as it would be useful to auto set the overscan which varies depending on the frame buffer size.
I didn't specifically look for these.

However, just like the frame buffer size, the overscan values can be set through the mailbox interface using the "Set Overscan" tag:
https://github.com/raspberrypi/firmware ... -interface

Dave

User avatar
IanB
Posts: 386
Joined: Sun Sep 04, 2011 7:28 pm
Location: South Wales
Contact:

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

Post by IanB » Wed Mar 06, 2019 8:11 pm

hoglet wrote:
Tue Mar 05, 2019 7:08 am
However, just like the frame buffer size, the overscan values can be set through the mailbox interface using the "Set Overscan" tag:
https://github.com/raspberrypi/firmware ... -interface
Thanks that's useful to know.

I've now got an 8x8 font working and the menu system auto switches between the existing 12x20 font and the new 8x8 font depending on the size of the screen buffer:

8X8Font.jpg
Last edited by IanB on Wed Mar 06, 2019 8:12 pm, edited 1 time in total.

User avatar
hoglet
Posts: 8366
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 Mar 06, 2019 8:16 pm

That looks very nice. What resolution is the frame buffer in that example?

User avatar
IanB
Posts: 386
Joined: Sun Sep 04, 2011 7:28 pm
Location: South Wales
Contact:

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

Post by IanB » Wed Mar 06, 2019 8:29 pm

hoglet wrote:
Wed Mar 06, 2019 8:16 pm
That looks very nice. What resolution is the frame buffer in that example?
It's on the screen :)
(336 x 270)

User avatar
hoglet
Posts: 8366
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 Mar 06, 2019 8:30 pm

IanB wrote:
Wed Mar 06, 2019 8:29 pm
It's on the screen :)
(336 x 270)
#-o It's been a long day. :lol:

tom_seddon
Posts: 310
Joined: Mon Aug 29, 2005 11:42 pm
Contact:

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

Post by tom_seddon » Sat Mar 09, 2019 10:55 pm

Trixster posted about a problem with the Stunt Car Racer instructions screen when using RGB2HDMI: viewtopic.php?f=57&t=16655#p230419

The Stunt Car Racer instructions screen is 41 columns wide, with an hsync position of 53 (https://github.com/kieranhj/scr-beeb/bl ... .asm#L2033), and presumably these settings cause problems with whatever stuff RGB2HDMI has to do to handle Mode 7.

I don't know if this is a bug report, or just a report ;) - wouldn't surprise me if Stunt Car Racer is the first game ever to do anything like this...

--Tom

User avatar
hoglet
Posts: 8366
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 Mar 09, 2019 11:10 pm

tom_seddon wrote:
Sat Mar 09, 2019 10:55 pm
I don't know if this is a bug report, or just a report ;) - wouldn't surprise me if Stunt Car Racer is the first game ever to do anything like this...
Thanks, I'll take a look tomorrow.

I've also noticed a problem with Exile that needs investigating as well.

Dave

User avatar
IanB
Posts: 386
Joined: Sun Sep 04, 2011 7:28 pm
Location: South Wales
Contact:

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

Post by IanB » Sun Mar 10, 2019 2:26 am

Over the past few days I've been working with Dave to increase the number of sampled bits per pixel and we have managed to increase it from 3 bits to 6 bits per pixel so it can now work properly with even more systems like PC CGA & EGA and maybe Amstrad CPC464 and others with some front end processing. It also supports separate H and V syncs so you can now connect directly to a CGA connector.

CGA is 4 bits RGBI:

16colourCGA.jpg

Previously it looked like this with just 3 bits RGB:

8colourCGA.jpg

The extra 3 bits are on the MUX buffer inputs and they are normally used to change the existing RGB logic thresholds.
You have to remove / not fit the 74LS08 and then pins 11,3 and 6 are available for extra RGB bits or G can be used as the CGA intensity bit:

extrabits.jpg

It should be possible to get it working with PC EGA which has 6 bits of RGB but I don't have a card to test that at the moment.
Last edited by IanB on Sun Mar 10, 2019 2:48 am, edited 2 times in total.

User avatar
hoglet
Posts: 8366
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 Mar 10, 2019 1:22 pm

tom_seddon wrote:
Sat Mar 09, 2019 10:55 pm
Trixster posted about a problem with the Stunt Car Racer instructions screen when using RGB2HDMI: viewtopic.php?f=57&t=16655#p230419

The Stunt Car Racer instructions screen is 41 columns wide, with an hsync position of 53 (https://github.com/kieranhj/scr-beeb/bl ... .asm#L2033), and presumably these settings cause problems with whatever stuff RGB2HDMI has to do to handle Mode 7.

I don't know if this is a bug report, or just a report ;) - wouldn't surprise me if Stunt Car Racer is the first game ever to do anything like this...
I've has a quick look at this, and the sync timing during VSYNC is a bit different:
- In normal mode 7, the vertical sync sequence in the even field ends with a 9us low going pulse.
- In Stunt Car Racer mode 7, this is reduced to a 7us low going pulse.

At the moment we have a fixed 8us threshold to distinguished short (normal HSYNC) and long (inverted during VSYNC) sync pulses. So that's what's affecting us here. It's actually thinking odd frames are mode 7, and even frames are mode 0..6, and continually switching.

I can fix it by changing the threshold to 6.144us, which is actually the value it used to be. Back in November we increased it to 8.000 us to improve compatibility with non-Acorn system:
https://github.com/hoglet67/RGBtoHDMI/c ... 36a901035e

So it should actually work with older releases (Early Adopter Release #3 and earlier).

I've created an issue to set the default back to 6.144us, and make this a configurable parameter:
https://github.com/hoglet67/RGBtoHDMI/issues/41

Thanks for reporting this.

Dave
Last edited by hoglet on Sun Mar 10, 2019 1:33 pm, edited 2 times in total.

User avatar
IanB
Posts: 386
Joined: Sun Sep 04, 2011 7:28 pm
Location: South Wales
Contact:

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

Post by IanB » Wed Mar 13, 2019 4:31 pm

I was experimenting with higher resolutions and I have a VGA card with a 9 pin TTL output as used on CGA/EGA as well as the normal VGA connector. Unfortunately it only seems to output VGA timings so I still can't test EGA but I managed to get it working at 640x480/60Hz VGA with a pixel clock of 25.175Mhz and 6 bits per pixel after optimising the capture code a lot more. After all the earlier issues with timing I never thought it would work that fast!

Dave has added a new feature to screengrab the Pi's buffer and save it to the SD card so here's a screengrab straight from the Pi:

vga640x480.png

EDIT: changed pic for one with correct ega palette
Last edited by IanB on Wed Mar 13, 2019 7:23 pm, edited 4 times in total.

aotta
Posts: 173
Joined: Fri May 26, 2017 8:57 am
Location: Italy
Contact:

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

Post by aotta » Sun Mar 17, 2019 1:12 am

i just burned my third xl9572.. i ordered new one but i am afraid my soldering iron isn't small enough for this little smd ics.. is some RGBtoHDMI board for selling somewhere?

User avatar
trixster
Posts: 882
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 » Sun Mar 17, 2019 4:13 pm

Do you think rgbtohdmi will ever support the extra features offered by Rob’s VideoNula?
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

Post Reply