I got to experience the RGBI vs RGBrgb problem first hand when I was hacking my Toshiba T3200 luggable to have a normal analog RGB output for TV connection via SCART.
I found the EGA chipset can output the 6bit RGB even in low res mode (matter of setting one bit from what I remember) and you could freely write palette to get anything out the 16 colors out of the 6bit palette, but the actual EGA monitor with its CGA compatibility hack makes it not work and all the software assumes RGBI way of things with palette the video BIOS sets up too... what a loss 🤣

Yup, the RGBI-logic is in the monitor.
There are monitors that have a switch to override this, so you can indeed have 200-line modes with 6-bit colour. That should work on any EGA card.
There are a few games out there that have this 'enhanced EGA' support. I believe Xenon 2 is one of them, and I also think Iron Man did this.

I found that the EGA emulation mode on my GeForce also supports the full 6-bit colour in 200-line modes.

And I actually added a switch that enables 6bit mode, so I should check these things out at some point 🤣

I would argue that interlacing is more of a "hack" than progressive is. But that's just semantics.

This is the best write up I've been able to find about how the raster is scanned out at the physical level. It should help to dispel any confusion about interlaced vs progressive scan.

https://web.archive.org/web/20180303133419/ht … on/scanning.htm

Jo22 wrote on 2023-06-27, 12:47:

Because, it's not as if the monitor suddenly stops to interlace the signal. It still does.
This pseudo "progressive" scan is just a butchered signal, really.

completely wrong

Rincewind42 wrote on 2023-06-27, 09:17:

Thanks, and you're right. I've tweaked it further; how about these?

Unfortunately, I have only a couple of late 90s/early 2000s VGA monitors, but no EGA, so I need to rely on photo/video references alone which is far from optimal. Also, even on 4k trying to replicate the triad dot pattern is a fools errand, it's just not going to happen I think when you can want something that works well with different viewport sizes.

Ultimately, I just want something that I can slap on when emulating "true EGA" (with scanlines) a never think about it. Width-doubling 320-pixel content seems to be the ticket, now this shader works well with all EGA resolutions as shown below (well, well enough for me at least).

To me these look more like TVs with slot masks, but don't take that as an attempt to shoot you down or anything - if you're good with something that's close enough, without going overboard on trying to be 'accurate' (which can be a bottomless rabbit hole anyway), they're honestly fine. It's all about what works for your use-case, after all.

Still, I wouldn't say it's impossible to get a decent simulation of a phosphor-dot shadowmask... here are a couple of my attempts, although they're based on a script for ffmpeg rather than a shader (so it's far from anything that can be applied in real-time).

I don't have any display intended for EGA either, so the above is based on my 5153 CGA monitor (which can still display EGA's 200-line modes if you plug in an actual EGA). If anything, the dot pitch here is even larger than the real thing.

...and that's an attempt at the finer dot pitch of a more "typical" EGA monitor, although it's probably inaccurate anyway. (You picked an ACiD artpack for your example, so I might as well pull a shameless plug here) 😉

If you open them at full size then the dot mask should be reasonably noticeable - I'll never call these 'perfect', but I'd say it looks decent overall.

Scali wrote on 2023-06-27, 14:31:

Yes, EGA is a bit of a weird standard. The 200-line modes are deliberately designed to be backward-compatible with CGA monitors. […]
Show full quote

Yes, EGA is a bit of a weird standard.
The 200-line modes are deliberately designed to be backward-compatible with CGA monitors. Which ironically means that you're stuck with the 16 fixed RGBI colours in 320x200 and 640x200, even on an actual EGA monitor which has 64 RGBrgb colours.
There's a dip-switch to indicate that you are using a CGA monitor, so it disables the 350-line modes altogether (else it boots up in a 350-line textmode).

EGA monitors are a bit of an early hackish form of 'multiscan' or 'multisync'... The polarity of the sync signals is reversed for 350-line modes, so the monitor can easily detect whether to switch to CGA-compatible 200-line mode (which also makes it behave like a regular RGBI 16-colour monitor), or to 350-line mode.

Are there any EGA monitors that allow you to use RGBrgb in 200 line modes, or was this behaviour standard across the board?

Sorry ignore that, I see you answered already further up..

Jo22 wrote on 2023-06-27, 12:47:

I disagree. It's fake, simply because it's not complying to the NTSC standard. Non-interlaced operation isn't being specified/su […]
Show full quote

I disagree. It's fake, simply because it's not complying to the NTSC standard.
Non-interlaced operation isn't being specified/supported, so it's a form of hack.

Because, it's not as if the monitor suddenly stops to interlace the signal. It still does.
This pseudo "progressive" scan is just a butchered signal, really.

Sorry, but the first part doesn't make much logical sense, and the second is just flat out 'alternative facts'.

If something doesn't comply with a standard, that doesn't make it 'fake' - it makes it non-standard. 30Hz/480p NTSC was itself a 'hack', since the actual standard had always specified interlaced video, and that form of progressive scan (AKA "NTSC-HQ" or "EDTV") never really became a thing until the '90s, with DVD players and so on. That doesn't make it 'fake' either.

CGA's colorburst isn't quite standard NTSC either, and of course its digital RGBI colors have nothing to do with NTSC whatsoever. By your logic, I suppose that makes it all "fake color" (and really just hacked monochrome). 😉

Many early computers aren't *quite* implementing the NTSC/PAL/SECAM standards correctly, but it's close enough, and it's all analog anyway, so things are quite forgiving.
If you REALLY want a non-standard signal, then the ZX81 is an interesting one.
They cut cost on the machine to the extreme, they actually need the CPU to generate the video signal. And the generated signal is missing the so called 'back porch' on the hsync pulses.
Back in the early 80s that was fine... But when you try to connect a ZX81 to a reasonably modern (eg digital/flatpanel) display, they generally won't be able to get horizontal sync.
My workaround for that was simple and effective: I ran the ZX81 through an 80s VCR, which could properly decode and sync. Then it generated its own output signal, where it added correct hsync pulses, which the modern TV could understand.

To my understanding, the flyback transformer in a video monitor must be kept in resonance. Otherwise, it heats up and breaks (it has a wire thin as a hair, due to being voltage operated).
So in order to use a video signal with true 200 or 240 lines (progressive), the timings must be different to NTSC standard. Approx. 7 KHz horizontal frequency?

Edit: My bad, 7 KHz wasn't correct. 60 Hz by 200 lines would be 12 KHz (arithmetically).
That is, if the signal was natively supported, without any borders. Like in a custom built terminal device.

Edit: I remembered it. What I was thinking of was the relationship between the sawtooth generator
(gets triggered by signal blacker-than-black-, controls the deflection frequency, signal retrived via VBS) and the nature of the rasterization of the CRT image.
To my understanding, its signal's timings were made with interlaced video in mind (480i/576i).
So depending on the point of view, a traditional, analog TV or video monitor does kind of "expect" an interlaced signal at some point.
If being fed with a "pseudo" progressive scan signal (240p/288p), the raster has "dead" lines (missing lines).
In order to attempt to display such a signal "natively" (real progressive scan, no fields, no missing lines),
the sawtooth generator signal had to be adjusted accordingly, resulting in a squashed screen.
To avoid that, the size of the CRT's picture element also had to be equally enlarged, for compensation.
The focus also had to be slightly adapted, maybe. Some voltages mudt be adjusted, deflection magnets, too (for linearity). .
Essentially, it's like tuning an oscilloscope accordingly. Ironically, the scope itself also was used to primarily adjust a TV.

Edit: Rediscovered that story about FCC vs 240p, too.
https://www.digitalfaq.com/forum/video-captur … .html#post17658

Jo22 wrote on 2023-06-27, 20:17:

To my understanding, the flyback transformer in a video monitor must be kept in resonance. Otherwise, it heats up and breaks (it has a wire thin as a hair, due to being voltage operated).
So in order to use a video signal with true 200 or 240 lines (progressive), the timings must be different to NTSC standard. Approx. 7 KHz horizontal frequency?

Well, firstly, any half-decent monitor (any colour monitor should, and the better mono ones do as well) will have its own oscillator, which will merely synchronize itself to the external signal.
If not, you'll burn out any transformer whenever you have a bad signal (especially TVs would suffer from that, when they have poor or no reception).
So it's not something you have to worry about with NTSC-compatible monitors in general (MDA monitors are a different story, with the IBM 5151 being a notorious example).

Secondly, 200 or 240 lines is the *visible* area. There's a border around it. As I already said, the actual frame generated is 262 lines large. Some of these lines are a visible border area, others are part of the vertical blank.
262 lines is very close to the 262.5 lines of interlaced fields, so there's no issue with timings. It's basically as close to NTSC standard as possible for progressive scan, so it's still ~15.7 kHz.
As I said, you're basically sending all odd NTSC fields (or all even ones) to generate the progressive image.

cinnabar wrote on 2023-06-27, 19:30:

Are there any EGA monitors that allow you to use RGBrgb in 200 line modes, or was this behaviour standard across the board?

I have an Eizo / Nanao FlexScan 8050S multisync analog/digital monitor that supports four different digital color modes: RGB (8 colors), RGBI without brown adjustment (16 colors "AT&T"), RGBI with brown adjustment (16 colors "IBM") and RGBrgb (64 colors). It also has a switch to enable "auto color mode", which will choose 16-color IBM or 64 colors based on VSYNC polarity, which is the 5154 behaviour. So if I switch it to manual color mode with 64 colors, I get RGBrgb support in 200 line modes.

VileR wrote on 2023-06-27, 19:25:

To me these look more like TVs with slot masks, but don't take that as an attempt to shoot you down or anything - if you're good with something that's close enough, without going overboard on trying to be 'accurate' (which can be a bottomless rabbit hole anyway), they're honestly fine. It's all about what works for your use-case, after all.

Indeed, it's a compromise because without copious amounts of oversampling it's very hard to emulate a triad dot mask, whereas pixel (or subpixel) aligned slot and aperture masks are relatively easy to do. I can get better results with specific masks at very specific, fixed resolutions, but ultimately this aims to be a shader that works well enough with any viewport size and both 320x200 and 640x200 EGA resolutions. Without oversampling, I get really ugly moire at most non-integer scaling ratios (and even with some integer factors) when using more elaborate phosphor mask patterns.

Yeah, it's meant to evoke the right fuzzy nostalgic feelings and get you in the right mood, or for someone who has zero nostalgia for this period, to get the most important "analog characteristics" of CRTs (bloom, rounded edges, subtle texture, scanlines).

So yeah, by no means "accurate" in the scientific sense, but pretty close from the point of view that it evokes the intended emotional reaction, I'd say 😀

VileR wrote on 2023-06-27, 19:25:

Still, I wouldn't say it's impossible to get a decent simulation of a phosphor-dot shadowmask... here are a couple of my attempts, although they're based on a script for ffmpeg rather than a shader (so it's far from anything that can be applied in real-time).

Your images are quite impressive, especially given the fact you've accomplished all this only with ImageMagick and some clever batch scripting! I did come across your CRT experiments a year or so ago, great stuff. But yeah, that overlaying the triad dot mask pattern at 4x oversampling then downscaling would be quite heavy to do in real time at 4k resolutions (and at 1080p it's a bit pointless as all that fine detail would disappear anyway; hence I'm "fudging" it just to give it some horizontal texture).

So, the discussion about the workings of these monitors in the analog electronics domain has been surely interesting, but from a practical viewpoint could someone in possession of a CGA or EGA monitor do the following test?

1) A photo of the following pixel-pattern in 320x200 mode (a single line is enough)
1 = white
0 = black

1 0 1 0 1 0 1 0 ...

2) Another photo of the following pixel-pattern in 640x200 mode

11 00 11 00 11 00 ...

So two white pixels, then two black, then two white, and so on...

If my assumptions are correct, the two photos should look exactly identical. What I'm after here is proving that the apparent horizontal sharpness is exactly the same in both scenarios.

Perhaps @VileR would you be able to do such a quick test on your nice CGA monitor? 😀

Focus is a bit uneven (cellphone camera + curved CRT), but the vertical lines do look the same in both modes. Can't think of any way it could be otherwise, in either CGA or EGA. 😀

VileR wrote on 2023-06-29, 19:37:

[...] vertical lines do look the same in both modes. Can't think of any way it could be otherwise, in either CGA or EGA. 😀

Me neither, but I always like to confirm theoretical conclusions by taking a look at actual reality 😄

Thanks!

^Are the stripes on purpose? Some DOS-based TUIs have trouble with 9x16 fonts.
Or fonts which aren't square-ish. Really old TUIs need these blocky 8x8 fonts, even.
That MS-DOS Manager comes to mind (uses minus character as a design element).

http://steptail.com/guides:text_mode

Jo22 wrote on 2023-06-30, 23:38:

^Are the stripes on purpose? Some DOS-based TUIs have trouble with 9x16 fonts. Or fonts which aren't square-ish. Really old TUI […]
Show full quote

^Are the stripes on purpose? Some DOS-based TUIs have trouble with 9x16 fonts.
Or fonts which aren't square-ish. Really old TUIs need these blocky 8x8 fonts, even.
That MS-DOS Manager comes to mind (uses minus character as a design element).

http://steptail.com/guides:text_mode

Not sure what you're asking about? This was just a test to see how the monitor behaves.