RGB to HDMI using a Pi Zero and a small CPLD

discuss both original and modern hardware for the bbc micro/electron
bluearcus
Posts: 7
Joined: Wed Dec 16, 2020 12:06 am
Contact:

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

Post by bluearcus »

Working my way through the tweaking of a PAL CoCo 3 config now based on your Beta 7 release Ian - long wait for cable building components over Christmas and New Year!

Anyway, I seem to be having some difficulty saving profiles - I'm getting an 'Error 4 saving file' message when attempting to save my tweaks into the U7 Tandy CoCo 3 profile. The menuing also shows Sub-Profile as 'Not found' which seems strange to me - should it not show the 50Hz PAL profile?

OK - saving to custom works OK, and I have a profile in progress. Just need to do some level setting for the 3 colour levels.

Experimenting with simulating NTSC artifacting on PAL seems a no go at the moment, as the PAL pixel clock @ 14.2375MHz causes the phase to change across the scanline.

Kind regards,

Mike
User avatar
IanB
Posts: 696
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 »

bluearcus wrote:
Sat Jan 16, 2021 6:15 pm
Anyway, I seem to be having some difficulty saving profiles - I'm getting an 'Error 4 saving file' message when attempting to save my tweaks into the U7 Tandy CoCo 3 profile. The menuing also shows Sub-Profile as 'Not found' which seems strange to me - should it not show the 50Hz PAL profile?
I missed the "default.txt" file out of the CoCo 3 profile folder which will mess up the auto switching and stop things from working.

You can copy that from Profiles\6-12_BIT_RGB\Amiga to \Profiles\6-12_BIT_RGB_Analog\U7_Tandy_CoCo_3. Note it only contains the text "auto_switch=1"
bluearcus wrote:
Sat Jan 16, 2021 6:15 pm
Experimenting with simulating NTSC artifacting on PAL seems a no go at the moment, as the PAL pixel clock @ 14.2375MHz causes the phase to change across the scanline.
NTSC artifact code is done by just analysing the pixels and the pixel clock has no bearing on it so something else is the problem, likely the above missing file means you are not loading the right profile
User avatar
IanB
Posts: 696
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 »

A video update from Jan Beta with video capture working:

https://www.youtube.com/watch?v=9baCd5O2nG4
User avatar
KenLowe
Posts: 1667
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 »

IanB wrote:
Sat Jan 16, 2021 10:54 pm
A video update from Jan Beta with video capture working:

https://www.youtube.com/watch?v=9baCd5O2nG4
Awesome =D> =D> =D>.

Makes me think I need to get myself a Amiga. It's a computer I've never used, but does seem to be very popular.
User avatar
BigEd
Posts: 3879
Joined: Sun Jan 24, 2010 10:24 am
Location: West Country
Contact:

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

Post by BigEd »

Great update. How does that NTSC aspect ratio scaling work? Does it introduce any lag?
User avatar
SpaceFlightOrange
Posts: 168
Joined: Mon Jan 21, 2019 2:28 pm
Contact:

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

Post by SpaceFlightOrange »

Finally got mine built last night. I'm totally blown away by it. I've got it hooked up to my Master which has a VideoNuLA in it, so i obviously can't use that at the moment but hopefully soon.

Next job for me is to mod my Dragon so i can use this. The output from that is terrible!

Thanks to everyone who made this happen. It's fantastic!
IMG_0563.jpeg
James

BBC Model A Issue 3 (Upgraded to Model B, had it since I was a kid), Opus Dual 40/80 FDD, Watford Mouse, Voltmace delta 14/B, Gotek, IFEL ROMRAM-B4, Pi-Zero CoPro

Master 128, VideoNuLA, Gotek
User avatar
hoglet
Posts: 9941
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 »

SpaceFlightOrange wrote:
Sun Jan 17, 2021 11:36 am
Finally got mine built last night. I'm totally blown away by it.
Nice soldering!
User avatar
SpaceFlightOrange
Posts: 168
Joined: Mon Jan 21, 2019 2:28 pm
Contact:

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

Post by SpaceFlightOrange »

hoglet wrote:
Sun Jan 17, 2021 11:53 am
SpaceFlightOrange wrote:
Sun Jan 17, 2021 11:36 am
Finally got mine built last night. I'm totally blown away by it.
Nice soldering!
I can't claim responsibility for it I'm afraid, this one came from the batch that had the surface mount components already installed. I only had to solder all the connectors and make myself a cable.
James

BBC Model A Issue 3 (Upgraded to Model B, had it since I was a kid), Opus Dual 40/80 FDD, Watford Mouse, Voltmace delta 14/B, Gotek, IFEL ROMRAM-B4, Pi-Zero CoPro

Master 128, VideoNuLA, Gotek
User avatar
IanB
Posts: 696
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 »

BigEd wrote:
Sun Jan 17, 2021 9:00 am
How does that NTSC aspect ratio scaling work?
It reduces the capture height from 256 to 200 and changes the pixel scaling from 2x4 to 2x5.
You could have done it manually by changing those settings in the profile but the option automates the changes.
It also works in the other direction so if you have an NTSC source it will output a reduced height image like the PAL equivalent.
BigEd wrote:
Sun Jan 17, 2021 9:00 am
Does it introduce any lag?
No
User avatar
BigEd
Posts: 3879
Joined: Sun Jan 24, 2010 10:24 am
Location: West Country
Contact:

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

Post by BigEd »

Thanks! (For no good reason I was supposed there'd be a need for fractional scaling.)
MajorMar
Posts: 23
Joined: Thu Oct 29, 2020 10:12 pm
Contact:

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

Post by MajorMar »

Here are the results of my tests on the Coco 3 with U7 installed. I am running beta 6 with the same config I posted before. However, I had to use a different monitor, so the resolution is not the same for some of the screenshots. Everything looks great to me!

old
Image
new
capture12.png
old
Image
new
capture16.png
And some screenshots of Donkey King as requested by IanB ...
capture14.png
capture15.png
I also tested NTSC artifacts on the Coco 1. Here are the results.

old
Image
new
capture0.png
old
Image
new
capture1.png
User avatar
IanB
Posts: 696
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 »

MajorMar wrote:
Mon Jan 18, 2021 8:57 pm
Here are the results of my tests on the Coco 3 with U7 installed.
capture12.png
That looks exactly as expected and matches up with your previously posted off screen photo of the CRT output:
MajorMar wrote:
Sat Dec 19, 2020 1:33 am
MVIMG_20201218_011436[1].jpg
So the voltage levels are correct for NTSC at least.
PAL has different levels according to the manual so we will have to wait for bluearcus to finish his tests for those.
MajorMar wrote:
Mon Jan 18, 2021 8:57 pm
However, I had to use a different monitor, so the resolution is not the same for some of the screenshots. Everything looks great to me!
The screencap code needs a complete rewrite so it more accurately reproduces the output of the GPU's scaler. If your lower res monitor can accept a 1080P signal you can work around the issue by changing the resolution output to 1080p before doing the screencaps. Don't forget to switch back to Auto afterwards!

However the old and new screencaps for the CoCo 1 are identical and they shouldn't be, the new ones should be a lot better so I don't think you were running the latest software when you captured those.

Here is the latest beta which has the missing default.txt file mentioned above added as well as some other changes:
https://github.com/IanSB/RGBtoHDMI/releases/tag/3a23a05
MajorMar
Posts: 23
Joined: Thu Oct 29, 2020 10:12 pm
Contact:

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

Post by MajorMar »

IanB wrote:
Mon Jan 18, 2021 10:20 pm
However the old and new screencaps for the CoCo 1 are identical and they shouldn't be, the new ones should be a lot better so I don't think you were running the latest software when you captured those.
Indeed I was running beta 6. Here are some new screenshots from the latest version you linked to above.
capture1.png
capture2.png
User avatar
IanB
Posts: 696
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 »

MajorMar wrote:
Tue Jan 19, 2021 1:40 am
Indeed I was running beta 6. Here are some new screenshots from the latest version you linked to above.
Thanks for testing.
Those look much better, especially the shadow under the ship.

Does the new beta also work on the coco 3 ?
MajorMar
Posts: 23
Joined: Thu Oct 29, 2020 10:12 pm
Contact:

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

Post by MajorMar »

IanB wrote:
Tue Jan 19, 2021 2:49 am
Does the new beta also work on the coco 3 ?
It does! Out of the box. The only thing I had to change once I set the profile was the artifact rotation IIRC.
User avatar
IanB
Posts: 696
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 »

MajorMar wrote:
Tue Jan 19, 2021 3:47 am
It does! Out of the box. The only thing I had to change once I set the profile was the artifact rotation IIRC.
Can you post your saved profile with the correct settings and calibration and I'll put that in the next release.
bluearcus
Posts: 7
Joined: Wed Dec 16, 2020 12:06 am
Contact:

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

Post by bluearcus »

IanB wrote:
Mon Jan 18, 2021 10:20 pm

So the voltage levels are correct for NTSC at least.
PAL has different levels according to the manual so we will have to wait for bluearcus to finish his tests for those.
I've done some more testing now and am quite happy with the PAL 64 colour config, and pixel stability across multiple modes (the 6847-like ones, and the GIME specific ones too). I imagine discrete modes for each of the different pixel clock multiples would make it more rock solid - can autoswitching identify those modes and select them automatically?

The config I've built doesn't seem to like NTSC artifacts though...
Custom.txt
Custom profile PAL Tandy CoCo 3
(232 Bytes) Downloaded 8 times
Palette test (excuse sparklies on the LHS, palette program needs fixing for '86 GIME chips, and I haven't got around to that yet...)
PAL 64 colour palette test
PAL 64 colour palette test
Text screens
capture2.png
capture3.png
NTSC artifact test
NTSC Artifacts on my custom profile - not looking good
NTSC Artifacts on my custom profile - not looking good
The NTSC artifact mode seems to start OK, in terms of colours, but the LH border position is all noisily displaced, then it falls into this mode. This is all with my Custom built profile above.

I'll be trying some Dragons next I think...

Cheers,

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

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

Post by MajorMar »

IanB wrote:
Wed Jan 20, 2021 1:18 am
Can you post your saved profile with the correct settings and calibration and I'll put that in the next release.
Here is what was working for me. I think it is 98% what was already in the default for that beta version.
CoCo_3_60Hz.txt
(201 Bytes) Downloaded 10 times
User avatar
IanB
Posts: 696
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 »

bluearcus wrote:
Thu Jan 21, 2021 8:19 pm
The NTSC artifact mode seems to start OK, in terms of colours, but the LH border position is all noisily displaced, then it falls into this mode. This is all with my Custom built profile above.
Vertical noise columns like that are indicative of the line length in the geometry menu being set incorrectly or possible the clock value being wrong which causes a >5000PPM error.

A close inspection of the text screens also shows a vertical column of noise/mis-sampling caused by incorrect line length (you can see some single pixel width rogue colours in the centre of the screen) and at least some of the noise on the left edge of the palette screen might also be due to mis-sampling.

Here is a slightly tweaked version of your profile with some values adjusted to more sensible defaults. Put this version in \Profiles\6-12_BIT_RGB_Analog on the SD card, reboot the pi and select it from the profiles option.

CoCo3_50Hz.txt
(232 Bytes) Downloaded 10 times

Please tweak the line length up or down a little in the geometry menu until you get a 'null' point which will be either all clean or all noisy. If the helper value at the top of the screen shows a significant PPM error (>1000PPM) you will need to adjust the frequency of the clock as well to match the value on the helper line.

Adjusting the line length works best with a high resolution mode with detail all across the screen like an 80 column text screen with text all the way across the screen but the NTSC artifact screen might be OK as it is clearly amplifying the effect which is only just visible on the 40 column text screen.

The current clock of 14237302Hz and line length of 912 are correct for PAL tandy CoCos using the 6847 for a 64uS line length but it occurred to me that maybe Radio Shack changed to the standard 14318181Hz crystal for cost reduction purposes which would then require a line length of around 916 and that would be possible with a custom chip. The other alternative is that Tandy simply fitted a 14318181Hz crystal without any line length change so two possible pairs to try would be:

Clock Frequency: 14318181
Line Length: 912

Clock Frequency: 14318181
Line Length: 916

If you can't get a good result, screencap the source summary page in the info menu by pressing the up & down buttons simultaneously and post that.
bluearcus
Posts: 7
Joined: Wed Dec 16, 2020 12:06 am
Contact:

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

Post by bluearcus »

Hi again Ian,

Opened the PAL CoCo3 up and the master crystal is labelled 28.4750Mhz, so 14237500ish should be the correct clock I believe. I'm getting a dozen or so PPM on the helper when adjusting plus or minus a few hundred on the fine adjust, so I'm pretty sure that's OK.

As suggested, I've made trials on varying the line length. and anything either side of 912 produces obvious timing effects in increasing band counts in either direction as one steps away from 912... which can't be resolved by further adjusting the clock.

The mis-sampling sparklies seem to inhabit the space between particular colour pairings, and altering the sync level plus recalibrating the sampling phase can improve somewhat, but it seems not possible to eliminate them entirely across all modes - and a calibration that works best in a 'pretending to be a 6847' mode seems off for the new GIME modes. I wonder if my two part cable setup might be the problem (I combine the syncs and drop down to the 6 way on a veroboard under the CoCo).

The source summary as requested:
capture0.png
This is my latest config, a further evolution of your revision.
CoCo3_50Hz_N.txt
(232 Bytes) Downloaded 6 times
I'm still having difficulty with artifact modes. Here's a link to a video showing how the artifact colouring seems to work and hold phase initially but the colour phase then breaks down.

Artifact switch on then breakdown

Kind regards,

Mike
User avatar
IanB
Posts: 696
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 »

bluearcus wrote:
Sat Jan 23, 2021 6:34 pm
The source summary as requested:
Can you drop the multiplier down to x6 or x8 at most as x12 is way overclocking the CPLD.
See if that helps

What software version are you running?

Also how are you combining the H & V syncs?
The sync type should be set to inverted if you are diode or-ing the H & V syncs (It's set to composite)

Check there is a good ground connection between the CoCo 3 and the converter

The sampling relies on a good quality sync pulses so you could try connecting the H & V syncs via a 74LS02 or 74HC02 NOR gate rather than diode or-ing them athough that would require power for the chip. You would also have to change the sync type to Composite as the NOR would invert the syncs back to normal composite rather than inverted although you could invert the ouput again with a second NOR gate and leave the sync setting on inverted to match the diode option

I also noticed that the 75R termination is off and that should really be on. Setting that will probably change the voltage levels so you will have to adjust all those again but try the sync stuff first as that is the likely issue.

Other things not directly related to quality but will mess up scaling on some monitors:
Min H Width should be 640
Min V Height should be at least 202
FB Size should be set to Double height
Lines per frame should be 314

You will need to adjust H & V offsets after changing all the above and the sync setting.
User avatar
IanB
Posts: 696
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 »

bluearcus wrote:
Sat Jan 23, 2021 6:34 pm
I'm still having difficulty with artifact modes. Here's a link to a video showing how the artifact colouring seems to work and hold phase initially but the colour phase then breaks down.
I managed to reproduce an effect similar to the video you posted and in my case it was caused by having the sync type set incorrectly like you have in your profile so the first thing I suggest you do is change the Sync Type in Geometry to inverted.

Here are a couple of profiles with the changes I suggested above already made (including sync):
CoCo3_50Hz_new.txt
(190 Bytes) Downloaded 6 times

This second one also has 75R termination turned on:
CoCo3_50Hz_new75R.txt
(187 Bytes) Downloaded 7 times
I have adjusted the video levels a little to compensate for the 75R termination in this one but they are probably wrong and will need to be adjusted using the info I posted when MajorMar was setting up his profile.

The only thing you should need to change on the above are the H & V offsets to centre the image and the video levels in the 75R one

Also note you should run the auto calibration at the highest horizontal resolution you can display otherwise you will get noise when you switch to that resolution.

Please post adjusted versions if you get a good result. If not then you will need to look at the sync combining as mentioned above.

Can you also post a source summary screencap again if everything works OK.
Last edited by IanB on Mon Jan 25, 2021 1:41 am, edited 1 time in total.
ryanm
Posts: 3
Joined: Sun Jun 28, 2020 12:48 pm
Contact:

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

Post by ryanm »

I fired up the converter with my Model B and had a devil of a time getting a decent image. It looked like a sync problem.
With help from Ian (and a scope) I confirmed that the RGB sync was inverted. This meant changing jumper S31 to West (it in fact had no jumper on originally). I also had inverted colours, but that was fixed by moving S26 to West. This may help others struggling with similar issues.
Everything is now working beautifully!
nivrig
Posts: 1
Joined: Sat Jan 23, 2021 8:00 pm
Contact:

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

Post by nivrig »

I'm curious what it would take to get this working with a VIC20. My uneducated guess is it would need something like the c0pperdragon board as the VIC-I chip also generates composite colour internally (like the VIC-II in C64)? VIC20 video quality isn't great, even with internal SVideo filter boards removing much of the interference, and pixel-perfect HMDI would be a great upgrade :)
bluearcus
Posts: 7
Joined: Wed Dec 16, 2020 12:06 am
Contact:

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

Post by bluearcus »

OK, after some more experimentation (including putting a noise suppression cap on the hsync line as one is present on the NTSC CoCo, but not on the PAL one, and experimenting with tapping the internal combined sync input to the PAL encoder board) I've got to what I think is the current end game.

None of my efforts to produce a cleaner sync solution really improved things... I suspect the RGB signals are noisy, they certainly look to suffer from bleed between pixels for some combinations, and the sync/clock stability is a bit poor, which may be down to my machine that spent most of its life in Australia being just a bit of a dog, or the PAL machines in general being horrible, or the notorious '86 first cut of the GIME chip. '87 GIME machines may well behave slightly differently - they certainly have revised sync timing and allegedly RGB signals too.

So the state I've reached is a pair of profiles, a Primary one, and a special case one.

* Primary CoCo3 PAL 50Hz Hires profile
CoCo3_50Hz_hires.txt
(190 Bytes) Downloaded 5 times
This is running at the GIME's native 640 / 512 pixel clock rate. Supports everything well except NTSC Artifacting. It isn't absolutely 100% noise free on some 6847 text mode colour transitions, but it's very close.

* Secondary CoCo3 PAL 50Hz Lowres profile
CoCo3_50Hz_lowres.txt
(245 Bytes) Downloaded 5 times
This is running at half the above pixel clock and handles NTSC Artifacting simulation perfectly on my machine, plus is rock solid on 6847-style text modes.
Donkey_King_title.png
Donkey_King.png
Sands_of_Egypt_title.png
Right, finally time to start on the Dragons! And then the FM-7! Thanks for your help Ian.
User avatar
IanB
Posts: 696
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 »

There is a new software build here:

https://github.com/hoglet67/RGBtoHDMI/releases

This is a release candidate for the next stable version so please give it a test and let me know if you find any issues.

This doesn't contain the CoCo 3 profiles updated by bluearcus as it was built before they were posted but they will be added to the stable release.
User avatar
aotta
Posts: 291
Joined: Fri May 26, 2017 9:57 am
Location: Italy
Contact:

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

Post by aotta »

Wow, i didn't know it was in progress the support for FF-OSD!! i'll try the new release asap, Thank you!
User avatar
IanB
Posts: 696
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 »

aotta wrote:
Thu Feb 04, 2021 4:21 pm
Wow, i didn't know it was in progress the support for FF-OSD!! i'll try the new release asap, Thank you!
At the moment the support is only for c0pperdragon's internal Amiga board using an overlay input, see this thread for more details:

https://github.com/c0pperdragon/Amiga-D ... /issues/26

It should be possible to add this feature to 12bpp mode on the CPLD version but it won't work in the same way for 6bpp or 3bpp modes so I've been discussing with Keir the possibility of using the serial port to pass the OSD data directly into the Pi for display by the Pi's own OSD.
User avatar
aotta
Posts: 291
Joined: Fri May 26, 2017 9:57 am
Location: Italy
Contact:

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

Post by aotta »

IanB wrote:
Fri Feb 05, 2021 2:39 pm
aotta wrote:
Thu Feb 04, 2021 4:21 pm
Wow, i didn't know it was in progress the support for FF-OSD!! i'll try the new release asap, Thank you!
At the moment the support is only for c0pperdragon's internal Amiga board using an overlay input, see this thread for more details:

https://github.com/c0pperdragon/Amiga-D ... /issues/26

It should be possible to add this feature to 12bpp mode on the CPLD version but it won't work in the same way for 6bpp or 3bpp modes so I've been discussing with Keir the possibility of using the serial port to pass the OSD data directly into the Pi for display by the Pi's own OSD.
I have the internal (big) adapter in an A500 and in the A2000 (with super denise), but installed the FF-OSD only in the A500, i'll test with it the new release.
I have the FF-OSD in one of my A600, but there's a Vampire Card and very few space to try soldering in the "small" adapter... i'll study the case further!
Thank you again, i missed the thread about OSD in github!
marcelaj1
Posts: 212
Joined: Wed Apr 29, 2020 5:07 pm
Contact:

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

Post by marcelaj1 »

Finally got around to putting one of these together for my beeb, had the parts for a month....
Before I loose myself in a tweaking frenzy, a couple of things...
Does using a VideoNula board change anything?
Is there a "test screen" that helps test out the device i.e. a picture with lots of coloured shapes and lines?

My one fired up ok, nice clear display in modes 0-6.......

I have always had issues with mode 7, with fuzzy edges on the right hand side of characters whether I use the original chip or the Nula board, this device seems to amplify the issue (but then rubbish signal in, rubbish signal out).

Are there tweaks that only affect mode 7 or if I tweaked would it cause issues with the other modes?

UPDATE:
Played around with it this morning and found a parameter "Half pixel shift" and set it to "ON" and got rock solid text in all modes - problem solved.
Last edited by marcelaj1 on Mon Feb 08, 2021 1:45 pm, edited 1 time in total.
Post Reply

Return to “8-bit acorn hardware”