RGB to HDMI using a Pi Zero and a small CPLD

discuss both original and modern hardware for the bbc micro/electron
User avatar
walkerworks
Posts: 109
Joined: Tue Oct 22, 2019 12:03 pm
Contact:

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

Post by walkerworks » Mon Oct 12, 2020 4:21 pm

IanB wrote:
Sat Oct 10, 2020 9:21 pm
I'm particularly interested in feedback from anyone that gets no output at all with the default settings as that is one thing I'm trying to avoid by reading the EDID.
I've just tried out the new build and I get a blank screen on boot. I am using an old Samsung LE19R88 with a reported screen resolution of 1440x900 which I see is not listed in the supported resolutions - I guess because it's non-standard.

I can use the recovery to get an output which works ok but if I manually set up 1024x768 60Hz (it doesn't support 50Hz) then it switches off the gen lock with the result it 'sort of reboots' when changing from mode 7 to modes 0-6.

The upshot is every time I switch on I get a blank screen, I then do a recovery boot and it displays perfectly.

I've attached the log, EDID and my TV's supported resolutions.

Derek
Attachments
Log_EDID.zip
(290.95 KiB) Downloaded 5 times
bygonebytes.co.uk

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

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

Post by IanB » Tue Oct 13, 2020 8:42 pm

walkerworks wrote:
Mon Oct 12, 2020 4:21 pm
I've just tried out the new build and I get a blank screen on boot. I am using an old Samsung LE19R88 with a reported screen resolution of 1440x900 which I see is not listed in the supported resolutions - I guess because it's non-standard.
Thanks for posting your EDID file. It indicates 50Hz support but probably only supports a couple of the TV standards like 1280x720 or 720x576 rather than any 50Hz resolution. A 1440x900 monitor isn't really suitable for the best results with the beeb as you won't be able to use integer scaling which really needs >1024 pixels vertically so it will fall back to using interpolated scaling instead.

50Hz support for older monitors is always a bit of a gamble with many working even though their EDID indicates otherwise and some, as you have discovered, indicating 50Hz but only working in a limited fashion or not at all.

Can you try this version:
testv2.zip
(146.74 KiB) Downloaded 7 times
Replace the kernel file with the one in the zip and add the two txt files to your resolutions folder and reboot.

I've made the 50Hz test a bit stricter so you should get a 60Hz display on power up with the Default@EDID resolution and I fixed the 1024x768 reboot bug. There is also a new option to test 50Hz support although if you run it, it will fail as it will just turn on the 50Hz that we already know doesn't work on your monitor.

However you should be able to try the manual resolution options, starting with 1440x900@50Hz and then 720x576@50Hz plus 1280x720@50Hz and it is likely the latter two will work as they are explicitly listed in the EDID data. Normally this wouldn't be recommended as they would require interpolation but as the standard resolution also has to use interpolation there will be no real difference in quality.

User avatar
walkerworks
Posts: 109
Joined: Tue Oct 22, 2019 12:03 pm
Contact:

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

Post by walkerworks » Wed Oct 14, 2020 4:27 pm

Thanks for testv2.zip, it now recovers successfully at default@EDID. The other test results are:

50Hz Test - fails as predicted.
1024x768 - bug fixed.
1440x900@50Hz - blank screen, as expected.
1440x900@60Hz - ok
720x567@50Hz - ok but unusable..characters way too big.
1280x720@50 or 60Hz - both ok and gives the best picture.

Thanks for looking at this but I think sometime in the future I'll need to get a better TV/monitor to make the most of this converter.

Derek
bygonebytes.co.uk

User avatar
KenLowe
Posts: 1523
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

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

Post by KenLowe » Fri Oct 16, 2020 10:57 pm

I've just upgraded from my original 3 bit board to a new 6 bit board, and upgraded the firmware on this board to BBC v7.7.

The reason I upgraded is because I was getting twinkling on certain mode 7 characters. Unfortunately, this still exists on the 6 bit board. It is most noticeable with the letters 0, A, K, M, N & m although other letters will occasionally twinkle. All other modes work perfectly. Is there anything I can do to stop this from happening?

Edit: Just realise, I've asked this question previously. Old age doesn't come by itself! Back then, the recommendation was to replace a cap in the beeb. Is that still the recommended solution?

Also, my monitor (Philips Brilliance 200W) has a native DVI resolution of 1680 x 1050. In the RGBtoHDMI menu, I see the resolution is set to Default@EDID, and the monitor menu indicates that 1680 x 150 @ 60Hz is selected. I can switch this to 1680 x 1050 @ 50Hz in the RGBtoHDMI menu and the monitor switches to this resolution.

The problem I am having with this native resolution (in either 50 or 60Hz mode) is that I lose part of the last line text. This happens if either 50 or 60Hz is selected. Ignore that. Setting *TV0,0 has fixed the missing last line!

User avatar
BeebMaster
Posts: 3734
Joined: Sun Aug 02, 2009 5:59 pm
Location: Lost in the BeebVault!
Contact:

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

Post by BeebMaster » Fri Oct 16, 2020 11:34 pm

Twinkling in mode 7 reminded me of the advice in the Service Manual (section 6.4):
BBC Micro Service Manual wrote:Our service centres tell us that there is a series of rather obscure faults which they have detected which is associated with timing problems with the RAM. One symptom is twinkling characters in mode 7 but not in the other modes of graphics, and another is that when playing Acornsoft’s "Defender" (not the later version of "Planetoids") some very strange effects occur as the game continues. Also there is a program of 3D Noughts and Crosses from Beebug which produces a strange fault, stopping inexplicably at one particular line and giving a No Room error. These faults, being related to relative timing, can sometimes be cured by changing the 6502 processor, or the 74LS245 (IC14) and are more often noticed where the RAM in CAS 1 is a different type from the RAM in CAS 0, when an A to B upgrade has been done. In particular it seems to be that the Fujitsu RAMs do not mix well with the Mostek or Hitachi RAMs.
Image

User avatar
KenLowe
Posts: 1523
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

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

Post by KenLowe » Fri Oct 16, 2020 11:43 pm

I would have put money on there being a mix of RAM in the beeb, but I've just checked and it's Hitachi all round. And they're all soldered in. So it doesn't look like I've had to replace any RAM in this one... yet!

Edit: Oh, I should have quit whilst I was ahead! I've just soldered up my second RGB2HDMI board only to realise I've stuck the 40 pin header on the wrong side #-o #-o #-o. I'm going to have to cut it out and replace it now.
Last edited by KenLowe on Fri Oct 16, 2020 11:46 pm, edited 2 times in total.

philb
Posts: 219
Joined: Sat Aug 05, 2017 7:05 pm
Location: Cambridge, GB
Contact:

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

Post by philb » Fri Oct 16, 2020 11:45 pm

Yes, it's sort of entertaining that this kind of "fix" was ever considered appropriate. But the past is a different country, as they say.

"Turns out our design has rather marginal timing, you can try swapping parts until it works"...

User avatar
KenLowe
Posts: 1523
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

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

Post by KenLowe » Sat Oct 17, 2020 12:21 am

KenLowe wrote:
Fri Oct 16, 2020 11:43 pm
Edit: Oh, I should have quit whilst I was ahead! I've just soldered up my second RGB2HDMI board only to realise I've stuck the 40 pin header on the wrong side #-o #-o #-o. I'm going to have to cut it out and replace it now.
Situation recovered! That's my 2nd board running now 8).
KenLowe wrote:
Fri Oct 16, 2020 10:57 pm
The reason I upgraded is because I was getting twinkling on certain mode 7 characters. Unfortunately, this still exists on the 6 bit board. It is most noticeable with the letters 0, A, K, M, N & m although other letters will occasionally twinkle. All other modes work perfectly. Is there anything I can do to stop this from happening?
It is worth pointing out that I'm only seeing this issue on the RGB2HDMI interface. I don't have this problem when I plug the beeb directly into my TV SCART socket, or if I use the commercial (small square) SCART to HDMI interface

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

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

Post by IanB » Sat Oct 17, 2020 3:56 am

KenLowe wrote:
Fri Oct 16, 2020 10:57 pm
The reason I upgraded is because I was getting twinkling on certain mode 7 characters. Unfortunately, this still exists on the 6 bit board. It is most noticeable with the letters 0, A, K, M, N & m although other letters will occasionally twinkle. All other modes work perfectly. Is there anything I can do to stop this from happening?
This is caused by an asymmetric mode 7 pixel clock and there isn't any difference between the 3 bit and later boards as far as the handling of that is concerned. There are several things to try to reduce or eliminate the problem:

If you are using the analog board, remove that and try a direct digital connection instead (An asymmetric clock means that some of the mode7 pixels can exceed the bandwidth of the analog board). Also try reducing the cable to ~20cm.

Try the BBC 24Mhz mode 7 profile. This increases the resolution of the mode 7 sampling from 12 Mhz to 24Mhz. Run an auto calibration which will take a lot longer than the normal calibration. This overclocks the CPLD a bit but seems to work on all boards I tested.
If there is still noise, try changing the Clock Multipler in the sampling menu from x6 to x8 which increases the accuracy of sampling further and again run the auto calibration. This really overclocks the CPLD and only works on about half the boards I tested. (You might get streaking or blank screens)
You should run the auto calibration more than once to look for the best result and a manual tweaking of the sampling phases A-F in the sampling menu might be required as well.

If none of the above fix it then the only remaining option which will fix it is to change the capacitors or resistors in the 12 Mhz clock circuit to make it more symmetric.

There is a litte bit more explanation at the bottom of the main page of the wiki:
https://github.com/hoglet67/RGBtoHDMI/wiki
KenLowe wrote:
Fri Oct 16, 2020 10:57 pm
It is worth pointing out that I'm only seeing this issue on the RGB2HDMI interface. I don't have this problem when I plug the beeb directly into my TV SCART socket, or if I use the commercial (small square) SCART to HDMI interface
The board uses a completely different sampling technique compared to 'normal' converters to (try to) perfectly extract the raw digital info and although it contains extra circuitry to cope with the mode 7 clock it is still susceptible to extremely asymmetric pixel clocks on some beebs.

User avatar
KenLowe
Posts: 1523
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

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

Post by KenLowe » Sat Oct 17, 2020 8:50 am

Thanks for the detailed reply. I should have mentioned it earlier, but I'm not using the analogue board. I've just switched on my beeb this morning, and no twinkles. I think I've seen this before where they only start once the beeb has warmed up. I'll try out the tweaks you suggested and see if they help at all, but I do think I'm going to have to get the soldering iron onto this beeb.

Thanks for the great product and excellent support!

Edit: Ok, now the beeb has warmed up, the sparkles are back.
IanB wrote:
Sat Oct 17, 2020 3:56 am
Try the BBC 24Mhz mode 7 profile. This increases the resolution of the mode 7 sampling from 12 Mhz to 24Mhz. Run an auto calibration which will take a lot longer than the normal calibration. This overclocks the CPLD a bit but seems to work on all boards I tested.
This seems to have fixed it. Lovely crisp screen again. Thanks.

MajorMar
Posts: 5
Joined: Thu Oct 29, 2020 10:12 pm
Contact:

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

Post by MajorMar » Thu Oct 29, 2020 10:30 pm

Wow. This is an awesome project!!! Thanks to everyone who has contributed so far.

I built up a 6bit board and I am testing it out on an IBM PC 5150 with a CGA card. It seems to work fine until I start up a game and then the display is slightly wavy. In some games (Burger Time) the colors are missing. Has anyone seen this before? Do I need to change any settings for various CGA modes or should that happen automatically?

I have tried this on a small LCD TV as well as a newer HDMI computer monitor (EDID seems to work fine BTW). I am running build 20201010_4c8ca86, but this also happens on the latest stable 20200504_d19df1c.

I am recording my progress on building the board and configuring it to feature on my YouTube channel (RetroHackShack), but I am stuck on this wavy video problem. I am happy to upload a short video of the problem if that would help.

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

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

Post by IanB » Fri Oct 30, 2020 4:19 am

MajorMar wrote:
Thu Oct 29, 2020 10:30 pm
I built up a 6bit board and I am testing it out on an IBM PC 5150 with a CGA card. It seems to work fine until I start up a game and then the display is slightly wavy. In some games (Burger Time) the colors are missing. Has anyone seen this before? Do I need to change any settings for various CGA modes or should that happen automatically?
What profile are you using?

Can you post some screencaps.
Press the middle button to capture, the files will be in the Captures folder on the SD card.
You can also screencap the menus by pressing the up and down buttons simultaneously so can you post screencaps of the Source Summary page in the Info menu for both good and bad screens.

I assume that running the auto calibration doesn't help with the wavy lines and that can indicate that the line length is set incorrectly. This could be because the graphics mode has a slightly different timing to the text mode or maybe the games themselves are messing with the CRTC registers.
Unfortunately I dont have an original CGA card and I've been using a Toshiba T3100e and some generic CGA / EGA / VGA cards in a 486 to do my tests and they might have different timings. There is a similar problem on the BBC with some games and there are several ways to work around that.

Can you also use the save log option after switching from good to bad screens and post log.txt as well.

I'm not sure about missing colours, it could be that the profile has an incorrect palette or it might be a hardware issue with one of the RGBI lines.

MajorMar
Posts: 5
Joined: Thu Oct 29, 2020 10:12 pm
Contact:

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

Post by MajorMar » Fri Oct 30, 2020 7:15 am

IanB wrote:
Fri Oct 30, 2020 4:19 am
What profile are you using?
Standard PC/CGA
IanB wrote:
Fri Oct 30, 2020 4:19 am
Can you post some screencaps.
I can do if you still want them. However, I found that increasing the sampling phase from 0 to 1 fixed the issue. Here is a video of what I was seeing. It seems the default config for PC has sampling phase set to 0. Perhaps I am masking the real problem by doing this. Not sure.
https://youtu.be/plSoNFxjh0E
IanB wrote:
Fri Oct 30, 2020 4:19 am
I assume that running the auto calibration doesn't help with the wavy lines and that can indicate that the line length is set incorrectly.
That's the first thing I tried. It did clear up the picture very slightly, but didn't help with the wavyness.
IanB wrote:
Fri Oct 30, 2020 4:19 am
Can you also use the save log option after switching from good to bad screens and post log.txt as well.
Will do. It took me a while to navigate to the save option. https://pastebin.com/cUMQajsx
IanB wrote:
Fri Oct 30, 2020 4:19 am
I'm not sure about missing colours, it could be that the profile has an incorrect palette or it might be a hardware issue with one of the RGBI lines.
Turns out this is just a problem with Burger Time. :) It does the same thing on my other setup.

User avatar
BeebMaster
Posts: 3734
Joined: Sun Aug 02, 2009 5:59 pm
Location: Lost in the BeebVault!
Contact:

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

Post by BeebMaster » Fri Oct 30, 2020 11:05 am

IanB wrote:
Fri Oct 30, 2020 4:19 am

You can also screencap the menus by pressing the up and down buttons simultaneously so can you post screencaps of the Source Summary page in the Info menu for both good and bad screens.
That's good to know, I've got a picture set of RGB to HDMI in my to-do book but I've kept putting it off thinking, "now how am I going to capture the menus?"
Image

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

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

Post by IanB » Fri Oct 30, 2020 11:05 am

MajorMar wrote:
Fri Oct 30, 2020 7:15 am
I can do if you still want them. However, I found that increasing the sampling phase from 0 to 1 fixed the issue. Here is a video of what I was seeing. It seems the default config for PC has sampling phase set to 0. Perhaps I am masking the real problem by doing this. Not sure.
https://youtu.be/plSoNFxjh0E
Thanks for the video. That sort of wavy lines effect is expected when the sample phase is set to the worst possible value for a source as it is sampling on the edge of each pixel rather than the centre of each pixel so the results are messed up by pixel transitions.

I think I know what the problem is:
It looks like the text mode pixels have a 180 degree phase difference to the graphics mode pixels which means that the best possible sampling phase for text is the worst possible value for graphics and vice-versa. This doesn't happen with my CGA sources so it's probably a peculiarity of the original IBM CGA card.
You may find that the best value for graphics is around 2 or 3 and the best value for text is 5 or 0 with the x6 multiplier.

Try running an auto calibration in text mode followed by another in graphics mode and then save and post the log. Note the graphics will have to be stationary when running the calibration

To work around this, the sampling phase should be set to a value half way between the best values for text and graphics and that's what you are doing by adjusting the sampling phase to 1. However with the x6 multiplier there are only 6 sampling phase values and that isn't a fine enough resolution to get a good intermediate value.

You can change the multiplier to x8 and that will increase the sampling phase range to 8 and that might be enough for a clean result in both text and graphics so try that and then manually adjust the sampling phase value for best quality in both text and graphics.
I'm currently working on the next firmware release and I think I will add some additional multiplier options like x10 or x12 which should then give a much more reliable result as there will be many more points to try in between the two optimal values.

I recall there are two different designs of the IBM CGA card and they have different NTSC artifact colours which indicates they have different pixel phases so maybe this problem only affects one of the versions.

BTW That log indicates you are using a 1440 x 900 monitor which can't use integer scaling as there aren't enough pixels vertically so it has to fall back to using interpolated scaling. You will get the best/sharpest results with CGA / EGA using either 1920x1080, 1920x1200, 1680x1050 or 1600x1200 monitors.

MajorMar
Posts: 5
Joined: Thu Oct 29, 2020 10:12 pm
Contact:

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

Post by MajorMar » Fri Oct 30, 2020 4:31 pm

IanB wrote:
Fri Oct 30, 2020 11:05 am
Try running an auto calibration in text mode followed by another in graphics mode and then save and post the log. Note the graphics will have to be stationary when running the calibration
Thanks for all the great information in your reply!! I will try to do this today.

Also, I plan on testing out an EGA card and on a Tandy 1000. Will this board handle Tandy 1000 special graphics mode? I didn't see a preset for it.

MajorMar
Posts: 5
Joined: Thu Oct 29, 2020 10:12 pm
Contact:

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

Post by MajorMar » Fri Oct 30, 2020 4:44 pm

... and here is the log file after running both autocalibrations. https://pastebin.com/WFvb5S42

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

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

Post by IanB » Fri Oct 30, 2020 11:51 pm

MajorMar wrote:
Fri Oct 30, 2020 4:31 pm
Also, I plan on testing out an EGA card and on a Tandy 1000. Will this board handle Tandy 1000 special graphics mode? I didn't see a preset for it.
It should work on the Tandy 1000 which has a CGA style interface but can send out all 16 colours simultaneously. I haven't got one so again it hasn't been tested and similarly with EGA I've only tested on my clone boards. The Tandy 1000 should work using the existing Standard PC/CGA profile but after you have saved any new calibration, you will lose any saved values for the IBM CGA card so I suggest you create a separate Tandy 1000 profile as follows:

go into \Profiles\6-12_BIT_RGB\Standard_PC on the SD card and copy the CGA.txt file up 1 level to \Profiles\6-12_BIT_RGB and rename it to Tandy_1000.txt. (You can't leave it in the Standard PC folder to be auto selected as it has the same timings as CGA so the auto switch code won't be able to determine which one to select).

After rebooting the Pi you should be able to select a separate Tandy 1000 profile in the menu which will have its own saved parameters.
It will be interesting to see if that suffers from the same phase difference between text and graphics modes (likewise with EGA)
MajorMar wrote:
Fri Oct 30, 2020 4:44 pm
... and here is the log file after running both autocalibrations. https://pastebin.com/WFvb5S42
Thanks, it does look like there is a difference but there is not enough info in the logs.
Can you try the following:

First select the x8 multiplier in the sampling menu.
Run an auto calibration in text mode
Go to the Info menu and select the "Calibration Detail" menu option and screencap that using the up & down buttons
Then repeat the above in graphics mode and post the two screencaps

Pepperm
Posts: 16
Joined: Mon Nov 02, 2020 9:09 pm
Contact:

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

Post by Pepperm » Thu Nov 05, 2020 10:48 pm

Sorry to invade this thread but how do I get my hands on an RGB to HDMI adaptor please? I see that there are some for sale in Australia but I am in the UK and no one answers on the other thread that seems to be about getting one.

Mark

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

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

Post by IanB » Fri Nov 06, 2020 12:23 am

Pepperm wrote:
Thu Nov 05, 2020 10:48 pm
Sorry to invade this thread but how do I get my hands on an RGB to HDMI adaptor please?
You just post in the for sale thread to reserve one and you will be contacted via PM when some more are available probably in the next week or so.

MajorMar
Posts: 5
Joined: Thu Oct 29, 2020 10:12 pm
Contact:

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

Post by MajorMar » Fri Nov 06, 2020 3:47 am

IanB wrote:
Fri Oct 30, 2020 11:51 pm
First select the x8 multiplier in the sampling menu.
Run an auto calibration in text mode
Go to the Info menu and select the "Calibration Detail" menu option and screencap that using the up & down buttons
Then repeat the above in graphics mode and post the two screencaps
OK. I tested with two different cards. One was a standard CGA card. The other was an EGA card with the dip switches set to CGA mode. See screen caps below. Also, I have recorded my assembly and testing in two parts. First episode is here https://youtu.be/8lnaI7TY0qQ. Second episode will be out in a few days here https://youtu.be/xGO3N1ThHFA.

Finally, I was able to test Tandy 1000 and it worked perfectly using "Standard PC" "CGA" profiles as far as I could tell. You can see a comparison in the second video when it comes out.
CGA_text.png
CGA_graph.png
CGA(EGA)_text.png
CGA(EGA)_graph.png

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

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

Post by IanB » Fri Nov 06, 2020 9:32 am

MajorMar wrote:
Fri Nov 06, 2020 3:47 am
OK. I tested with two different cards. One was a standard CGA card. The other was an EGA card with the dip switches set to CGA mode. See screen caps below.
Thanks for these, you can clearly see a phase difference between CGA text and graphics but it looks to be around 45 - 90 degrees, not 180 as I first thought (each phase step is 45 degrees in x8 mode). It's also clear that there is no such difference in the CGA(EGA) ones. Setting a phase value of 5 when using the x8 multiplier seems to be a good compromise with these cards so I'll use those as the default settings on the next release.

It's good to finally have some feedback on PC usage: Most other supported computers have already been tested by others on here but not PCs so far and they are the ones that are likely to have most issues due to there being so many different designs.

User avatar
IanS
Posts: 1437
Joined: Mon Aug 31, 2009 7:02 pm
Contact:

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

Post by IanS » Tue Nov 10, 2020 3:47 pm

Would a dedicated version that supports the A4xx/A540 hi-res mono mode be possible?
(I guess) It would need to pick up the signals internally, before the serializer.
viewtopic.php?t=6202#p58967
viewtopic.php?p=130641#p130641
edit: extra link added.
Last edited by IanS on Tue Nov 10, 2020 7:05 pm, edited 1 time in total.

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

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

Post by IanB » Tue Nov 10, 2020 6:00 pm

IanS wrote:
Tue Nov 10, 2020 3:47 pm
Would a dedicated version that supports the A4xx/A540 hi-res mono mode be possible?
(I guess) It would need to pick up the signals internally, before the serializer.
In theory it should already work as I've added 1 bit per pixel and extra multiplier options to the latest CPLD. It works with the hires mono output of the Atari ST which has a 32 Mhz dot clock so running at 48Mhz on the Archimedes is not that much more.
It would require the new x3 multiplier option to run the CPLD at 144Mhz or x4 to run the CPLD at 192Mhz (the latter is less likely to work as that is really overclocking the CPLD but x3 should be enough). The serial data and sync signals would need to be at > 2v logic levels minimum so they would probably have to be level shifted from the analog BNC outputs or picked up internally.

User avatar
IanS
Posts: 1437
Joined: Mon Aug 31, 2009 7:02 pm
Contact:

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

Post by IanS » Tue Nov 10, 2020 7:04 pm

In Mode 23 the VIDC outputs 4 bits at a time, and is then serialised externally with a 96MHz pixel clock. I assumed it would need to pick up the parallel data.
In theory it would then be possible to run it on any Arc (not just A4xx/A540), as the 4 bits are available on PL3 (in an A310).

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

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

Post by IanB » Tue Nov 10, 2020 8:58 pm

IanS wrote:
Tue Nov 10, 2020 7:04 pm
In Mode 23 the VIDC outputs 4 bits at a time, and is then serialised externally with a 96MHz pixel clock.
Yes, you are correct, I recalled it was 48Mhz instead of 96 Mhz.
96Mhz is too high to deserialise in the current design so, as you say, the 4 bits would have to be picked up in parallel with a 24 Mhz clock instead. That could be done with the existing hardware using 6 bit capture mode which is already tested to work up to 28Mhz together with a custom capture software loop. However more memory would have to be written per pixel as I think the minimum frame buffer depth is 4 bits per pixel and that might cause problems due to lack of memory bandwidth so it would have to be tested.

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

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

Post by hoglet » Fri Nov 13, 2020 10:43 pm

I'm not sure if these "Retro Hack Shack" YouTube videos have been posted before.

I certainly haven't seen them...

Add HDMI To Your Vintage Computers! - Part 1

Add HDMI To Your Vintage Computers! - Part 2

Edit: Ah, I see they were linked a few posts up by MajorMar #-o

Dave

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

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

Post by IanB » Sat Nov 14, 2020 12:58 am

There is a new software build available here:
https://github.com/hoglet67/RGBtoHDMI/r ... 13_0471da6
Direct link:
https://github.com/hoglet67/RGBtoHDMI/r ... 471da6.zip

This has various improvements including 12 bit per pixel support in the BBC CPLD which means it should work with the NuLA in conjunction with the new 12 bit main board (not tested yet) although you will have to pick up the 12 bits directly from the NuLA board. The RGB CPLD has additional clock multiplier options so now x3, x4, x6, x8, x10, x12, x14 and x16 are available.
There is now a new "Test monitor for 50Hz support" option so you can quickly check if your monitor will work at 50Hz and I also added an NTSC Tandy Color Computer profile which was missing from previous versions which only had the PAL profile.

I've updated the wiki quick start and reference guides to document all the recent software changes as it was getting quite out of date.
https://github.com/hoglet67/RGBtoHDMI/w ... tart-Guide
https://github.com/hoglet67/RGBtoHDMI/w ... ence-Guide


User avatar
Mince
Posts: 77
Joined: Thu Sep 05, 2019 11:25 pm
Location: Cambridge, UK
Contact:

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

Post by Mince » Sun Nov 15, 2020 12:38 pm

IanB wrote:
Sat Nov 14, 2020 12:58 am
There is a new software build available here:
https://github.com/hoglet67/RGBtoHDMI/r ... 13_0471da6
Direct link:
https://github.com/hoglet67/RGBtoHDMI/r ... 471da6.zip
Thanks for this!

This new version seems to solve about 90% of the jittering I was getting in MODE 7 with brighter backgrounds (anything with a red or green component; mainly green), whilst still looking good with plain white-on-black text. It defaults to 8x CPLD and changing it higher seems to make the picture worse for me.

Post Reply

Return to “8-bit acorn hardware”