HI:
Dithvide, was always a software project I intended to a have a look at, I will setup a dedicated QL with Trump card to see if faster expanded memory will have any effect.
Odd - Interesting - Forgotten
-
Derek_Stewart
- Font of All Knowledge
- Posts: 4652
- Joined: Mon Dec 20, 2010 11:40 am
- Location: Sunny Runcorn, Cheshire, UK
Re: Odd - Interesting - Forgotten
Unlikely. The actual switching between "front" and "back" screen memory is not using CPU memory accesses at all - Just flips a switch in the ULA.Derek_Stewart wrote: Sat Jan 18, 2025 6:59 am HI:
Dithvide, was always a software project I intended to a have a look at, I will setup a dedicated QL with Trump card to see if faster expanded memory will have any effect.
ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
Re: Odd - Interesting - Forgotten
The principle of this method lies in switching screens on each refresh by toggling bit 1 of the mc_stat (master chip settings). CPU speed and memory do not matter. This method works on BBQL by design.
In mixed mode, the screen switches every line. Proper timing is required, but if the executable is located in the contended memory, it should work correctly with or without memory expansion.
One note: modern RGB converters and LCD TVs perform "post-processing" on raw RGB data. During post-processing, two frames are merged, resulting in a stable 25Hz image. As a result, the output screen is stable and free of flickering. I assume that mixed mode will work correctly even if it is not properly timed.
In mixed mode, the screen switches every line. Proper timing is required, but if the executable is located in the contended memory, it should work correctly with or without memory expansion.
One note: modern RGB converters and LCD TVs perform "post-processing" on raw RGB data. During post-processing, two frames are merged, resulting in a stable 25Hz image. As a result, the output screen is stable and free of flickering. I assume that mixed mode will work correctly even if it is not properly timed.
Re: Odd - Interesting - Forgotten
Are all color combinations allowed in lores? I ask because, when using these two screens, I get fast flashing image instead of a stable one. I expected it to show all possible colors.omega wrote: Sat Jan 18, 2025 1:07 pm The principle of this method lies in switching screens on each refresh by toggling bit 1 of the mc_stat (master chip settings). CPU speed and memory do not matter. This method works on BBQL by design.
Last edited by bwinkel67 on Sat Jan 18, 2025 1:14 pm, edited 1 time in total.
Re: Odd - Interesting - Forgotten
Mixed mode worked perfectly for me on my NTSC QL with JSU ROM displayed on an LCD monitor with composite signal. I will try RGB input at one point and will post any issues that come up.omega wrote: Sat Jan 18, 2025 1:07 pm One note: modern RGB converters and LCD TVs perform "post-processing" on raw RGB data. During post-processing, two frames are merged, resulting in a stable 25Hz image. As a result, the output screen is stable and free of flickering. I assume that mixed mode will work correctly even if it is not properly timed.
Re: Odd - Interesting - Forgotten
Understanding Flickering in Dithvide and How to Mitigate It
In very simple terms, flickering occurs when we alternate between two colors and average them to create a new one. Since this color change happens at a 50Hz rate, the flickering becomes visible to the human eye.
First Issue - Size of the Flickering Area and Color Distance:
The degree of flickering is directly influenced by the distance between the two alternating colors:
- The closer the two colors are to each other, the less noticeable the flickering will be.
- For example, flickering between 0 and 1 (black and blue), 2 and 3, or 5 and 6 yields a softer result.
- The farther apart the colors are, the more pronounced the flickering will be.
- For example, flickering between 0 and 7 (black and white) leads to a much more jarring effect.
If a large area of the screen is flickering between extreme color differences (e.g., black and white), the effect is very unpleasant to the human eye.
Second Issue - Emulator Output:
Unfortunately, most emulators don’t synchronize the video output of the emulated machine with the host PC's video refresh rate. This is understandable, as it’s a challenging task, and monitor refresh rates (60Hz, 70Hz, 85Hz) aren’t divisible by the 50Hz flicker rate. As a result:
- The 50Hz flicker will be further compounded by an asynchronous screen update between the emulator's output and your PC's monitor refresh rate.
- This creates a visual effect much worse than if the QL were connected to a real 50Hz RGB monitor.
Third Factor - CRT and Human Eye:
Dithvide works particularly well on CRT screens, for several reasons:
- The cathode ray technology draws pixels slowly, allowing them to fade into each other in a more natural way.
- The phosphor layer on a CRT screen causes pixels to fade gradually, creating a soft transition between colors.
- The shape of the pixel itself is not a perfectly sharp square, which also contributes to a smoother, more natural appearance.
This gradual fading and less precise pixel shape make CRT screens more forgiving when it comes to flickering, as the human eye perceives these transitions as more natural.
Fourth Factor - Image Post-Processing:
With modern upscalers and image converters that connect analogue RGB signals to HDMI TVs, some devices merge two half-frames into a full-frame. This has the effect of:
- Averaging the colors, reducing visible flickering and making the image look smoother.
- This is likely the best result we can get in a modern setup. However, the downside is that we don’t control the post-processing, and each device may handle this averaging differently.
Image Conversion and Flickering:
To convert an image into the QL Dithvide format, I follow these steps:
1. Adjust brightness and contrast to match the display.
2. Crop the image to the correct 4:3 aspect ratio.
3. Resize the image to either 256x256 or 512x256, ensuring the proper aspect ratio for the QL display.
4. Dither the image to fit the QL's hi-color palette.
5. Convert the resulting image into two QL screens.
6. Convert the QL screens into the final QL binary format.
Key Considerations for Minimizing Flickering:
- Step 5: This step is crucial. When converting the image into two QL screens, I modify which screen a pixel is placed on, using a checkerboard pattern. This minimizes the visible flickering by ensuring that large areas don’t flicker between two highly contrasting colors. This approach works well for both low-resolution (lores) and high-resolution (hires) modes.
- Mixed mode doesn’t require this step, as the CPU switches between screen modes automatically for each line.
- Step 4: I use a custom palette for each display mode. The dithering algorithm compares the RGB distance of the original pixel to the available palette colors and selects the one with the smallest distance. The difference in color is then used for error diffusion and further dithering to ensure smooth color transitions.
By following these steps and taking these factors into account, we can significantly reduce the flickering effect and achieve a much more pleasant visual experience when using Dithvide.
In very simple terms, flickering occurs when we alternate between two colors and average them to create a new one. Since this color change happens at a 50Hz rate, the flickering becomes visible to the human eye.
First Issue - Size of the Flickering Area and Color Distance:
The degree of flickering is directly influenced by the distance between the two alternating colors:
- The closer the two colors are to each other, the less noticeable the flickering will be.
- For example, flickering between 0 and 1 (black and blue), 2 and 3, or 5 and 6 yields a softer result.
- The farther apart the colors are, the more pronounced the flickering will be.
- For example, flickering between 0 and 7 (black and white) leads to a much more jarring effect.
If a large area of the screen is flickering between extreme color differences (e.g., black and white), the effect is very unpleasant to the human eye.
Second Issue - Emulator Output:
Unfortunately, most emulators don’t synchronize the video output of the emulated machine with the host PC's video refresh rate. This is understandable, as it’s a challenging task, and monitor refresh rates (60Hz, 70Hz, 85Hz) aren’t divisible by the 50Hz flicker rate. As a result:
- The 50Hz flicker will be further compounded by an asynchronous screen update between the emulator's output and your PC's monitor refresh rate.
- This creates a visual effect much worse than if the QL were connected to a real 50Hz RGB monitor.
Third Factor - CRT and Human Eye:
Dithvide works particularly well on CRT screens, for several reasons:
- The cathode ray technology draws pixels slowly, allowing them to fade into each other in a more natural way.
- The phosphor layer on a CRT screen causes pixels to fade gradually, creating a soft transition between colors.
- The shape of the pixel itself is not a perfectly sharp square, which also contributes to a smoother, more natural appearance.
This gradual fading and less precise pixel shape make CRT screens more forgiving when it comes to flickering, as the human eye perceives these transitions as more natural.
Fourth Factor - Image Post-Processing:
With modern upscalers and image converters that connect analogue RGB signals to HDMI TVs, some devices merge two half-frames into a full-frame. This has the effect of:
- Averaging the colors, reducing visible flickering and making the image look smoother.
- This is likely the best result we can get in a modern setup. However, the downside is that we don’t control the post-processing, and each device may handle this averaging differently.
Image Conversion and Flickering:
To convert an image into the QL Dithvide format, I follow these steps:
1. Adjust brightness and contrast to match the display.
2. Crop the image to the correct 4:3 aspect ratio.
3. Resize the image to either 256x256 or 512x256, ensuring the proper aspect ratio for the QL display.
4. Dither the image to fit the QL's hi-color palette.
5. Convert the resulting image into two QL screens.
6. Convert the QL screens into the final QL binary format.
Key Considerations for Minimizing Flickering:
- Step 5: This step is crucial. When converting the image into two QL screens, I modify which screen a pixel is placed on, using a checkerboard pattern. This minimizes the visible flickering by ensuring that large areas don’t flicker between two highly contrasting colors. This approach works well for both low-resolution (lores) and high-resolution (hires) modes.
- Mixed mode doesn’t require this step, as the CPU switches between screen modes automatically for each line.
- Step 4: I use a custom palette for each display mode. The dithering algorithm compares the RGB distance of the original pixel to the available palette colors and selects the one with the smallest distance. The difference in color is then used for error diffusion and further dithering to ensure smooth color transitions.
By following these steps and taking these factors into account, we can significantly reduce the flickering effect and achieve a much more pleasant visual experience when using Dithvide.
- Attachments
-
- pattern_merged_90_lr1.png (2.45 KiB) Viewed 565 times
-
- pattern_merged_90_lr2.png (2.29 KiB) Viewed 565 times
-
- pattern_merged_lr1.png (1.6 KiB) Viewed 565 times
-
- pattern_merged_lr2.png (1.58 KiB) Viewed 565 times
Last edited by omega on Sat Jan 18, 2025 4:33 pm, edited 1 time in total.
Re: Odd - Interesting - Forgotten
Hey Mike,
Just a quick suggestion – you can set the PAL or NTSC mode directly in the Dithvide source code if that helps. To do so, you'd need to update the source to modify bit 6 whenever mc_stat is written.
Just a quick suggestion – you can set the PAL or NTSC mode directly in the Dithvide source code if that helps. To do so, you'd need to update the source to modify bit 6 whenever mc_stat is written.
Code: Select all
mc_stat EQU $18063 master chip settings
screen1 EQU $20000
screen2 EQU $28000
* bit 1 - screen off (1)
* bit 3 - lores (1), hires (0)
* bit 6 - (0) PAL, (1) NTSC
* bit 7 - (0) VRAM starts $20000, (1) $28000
Re: Odd - Interesting - Forgotten
Thank you. I will give it a try. What I notice on my system that it puts the display into PAL when it does monitor mode and keeps it in NTSC when in TV mode (at least that's what my LCD TV says). The JSU ROM is weird in how it deals with TV mode since it only shows 192 lines, so I'm not quite sure what it does. Also don't understand why it does monitor mode as PAL.omega wrote: Sat Jan 18, 2025 4:28 pm Hey Mike,
Just a quick suggestion – you can set the PAL or NTSC mode directly in the Dithvide source code if that helps. To do so, you'd need to update the source to modify bit 6 whenever mc_stat is written.
Code: Select all
mc_stat EQU $18063 master chip settings screen1 EQU $20000 screen2 EQU $28000 * bit 1 - screen off (1) * bit 3 - lores (1), hires (0) * bit 6 - (0) PAL, (1) NTSC * bit 7 - (0) VRAM starts $20000, (1) $28000
Re: Odd - Interesting - Forgotten
Seems well thought through - and beautifully written! I wish all manuals could be written so clearly!omega wrote: Sat Jan 18, 2025 4:15 pm Understanding Flickering in Dithvide and How to Mitigate It
<>
Per
I love long walks, especially when they are taken by people who annoy me.
- Fred Allen
I love long walks, especially when they are taken by people who annoy me.
- Fred Allen