From: cr88192@gmail.com
On 11/2/2025 3:56 PM, Robert Finch wrote:
> On 2025-11-02 3:58 p.m., BGB wrote:
>
>>
>> No real need to go much beyond RGB555, as the FPGA boards have VGA
>> DACs that generally fall below this (Eg: 4 bit/channel on the Nexys
>> A7). And, 2-bit for many VGA PMods (PMod allowing 8 IO pins, so
>> RGB222+H/V Sync; or needing to use 2 PMOD connections for the VGA).
>> The usual workaround was also to perform dithering while driving the
>> VGA output (with ordered dither in the Verilog).
>>
>
> I am using an HDMI interface so the monitor is fed 24-bit RGB digitally.
> I tried to get a display channel interface working but no luck. VGA is
> so old.
>
Never went up the learning curve for HDMI.
Would likely need to drive the monitor outputs with SERDES or similar
though.
> Have you tried dithering based on the frame (temporal dithering vs
> space-al dithering)? First frame is one set of colors, the next frame is
> a second set of colors. I think it may work if the refresh rate is high
> enough (120 Hz). IIRC I tried this a while ago and was not happy with
> the results. I also tried rotating the dithering pattern around each frame.
>
Temporal dithering seems to generate annoying artifacts on the monitors
I tried it on. Trying to use temporal dithering tended to result in
annoying wavy/rippling artifacts.
Likewise, PWM'ing the pixels also makes LCD monitors unhappy (rainbow
banding artifacts), but seems to work OK on CRTs. I suspect it is an
issue that the monitors expect a 25MHz pixel clock (when using 640x400
or 640x480 timing) with an ADC that doesn't like sudden changes in level
(say, if updating the pixels at 50MHz internally).
>
>
>> Generally, the text mode operates in a 640x200 mode with 8x8 + 128b
>> cells, so 32K of VRAM used (for 80x25 cells).
>>
> For the text mode 800x600 mode is used on my system, with 12x18 cells so
> that I can read the display at a distance (64x32 characters).
>
> The font then has 64 block graphic characters of 2x3 block. Low-res
> graphics can be done in text mode with the appropriate font size and
> block graphics characters. Color selection is limited though.>
I went with 80x25 as it is pretty standard;
80x50 is also possible, but less standard.
Though, Linux seems to often like using high-res text modes rather than
the usual 80x25 or similar.
As for 8x8 character cells:
Also pretty standard, and fix nicely into 64 bits.
In theory, for a text mode, could drive a monitor at 1280x400 with
640x400 timings for 16x16 character cells, but LCD monitors don't like
this sort of thing.
Even at 640x400/70Hz timings, the monitor didn't consistently recognize
it as 640x400, and would sometimes try to detect it as 720x400 or
similar (which would look wonky).
The other option being to output 640x480 and simply black-fill the extra
lines (so, add 20 lines of black-fill at the top and bottom of the
screen). Where, the monitors were able to more reliably detect 640x480/60Hz
The main tradeoff is that mostly I have a limited selection of pixel
clocks available:
25, 50, maybe 100.
Mostly because the pixel clocks are high enough and clock-edges
sensitive enough where accumulation timers don't really work.
Though, accumulation timers do work for driving an NTSC composite
output. But, NTSC composite looks poor, can't even really do an 80x25
text mode acceptably (if using colorburst); but can do 80x25 if one can
accept black-and-white.
Well, there was also component video, but this is basically the same as
driving VGA (just with it being able to accept both NTSC and VGA
timings; eg, 15 to 70 kHz for horizontal refresh, 40 to 90 Hz vertical,
...).
Though, I no longer have the display that had component video inputs.
Contrast, there is generally a very limited range of timings for
composite or S-Video (generally, these don't accept VGA-like timings).
Whereas, VGA only really accepts VGA-like timings, and is unhappy if
given NTSC timings (eg: 15 kHz horizontal refresh).
Not sure why seemingly component video is the only "accepts whatever you
throw at it" analog input (say, on a display with multiple input types
and presumably similar hardware internally).
Checks, annoyingly hard to find plain LCD monitors with a component
video inputs that is not also a full TV with a TV tuner (but, a little
easier to find ones with both VGA and composite). Closest I can find are
apparently intended mostly as CCTV monitors.
But, mostly using VGA anyways, so...
...
>> In this case, a 40x25 color-cell mode (with 256-bit cells) could be
>> used for graphics (32K). Early on, this was used as the graphics mode
>> for Doom and similar, before I later expanded VRAM to 128K and
>> switched to 320x200 Hicolor.
>>
>>
>> The bitmap modes are non-raster, generally with pixels packed into 8x8
>> or 4x4 blocks.
>> 4x4:
>> 16bpp: pixels in raster order.
>> 8bpp: raster order, 32-bits per row
>> 4bpp: Raster order, 16-bits per row
>> And, 8x8:
>> 4bpp: Takes 16bpp layout, splits each pixel into 2x2.
>> 2bpp: Takes 8bpp layout, splits each pixel into 2x2.
>> 1bpp: Raster order, 1bpp, but same order as text glyphs.
>> With MSB in upper left, LSB in lower right.
>>
>
>
>
...
But, yeah, my makeshift graphics hardware is a little wonky.
And, works in an almost entirely different way from the VGA style hardware.
Ironically, software doesn't configure timings itself, but rather uses
selector bits to control various properties:
Base Resolution (640x400, 640x480, 800x600, ...);
Character cell size in pixels (4x4 or 8x8);
Settings to modify the number of horizontal and vertical cells relative
to the base resolution;
...
But, for the most part, had been using 640x400 or similar; with 800x600
as more experimental (and doesn't look great with 2bpp cells).
The 1024x768 mode had gone mostly unused, and is still untested on real
hardware.
...
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
