This was a question which puzzled me when I first found out about it, but now that I understand all the history behind it, it makes perfect sense.
The IBM PC (5150) was originally designed output to an NTSC television in mind - hence the 4.77MHz clock speed (4/3 the NTSC color carrier frequency - allowing the video output and CPU clock to share a crystal). It was thought that home users would generally hook their PCs up the TV rather than having a separate, expensive, monitor. Another major limiting factor in the design of the CGA was the price of video memory - the 16Kb on the card would have been fairly expensive at the time (it was as much as the amount of main memory in the entry level PC). TV resolution is 912x262 at CGA 2-colour pixel sizes in non-interlaced mode, but TVs (especially CRTs) don't show all of the image - some of those scanlines and pixels are devoted to sync signals and others are cropped out because they would be distorted due to the difficulties of approximating high frequency sawtooth waves with high-voltage analog circuitry. So 320x200 4-colour and 640x200 2-colour packed pixel modes were chosen because they were a good fit for both 16Kb of memory and TV resolutions.
That system did work quite well for many home users - lots of CGA games have 16-colour composite output modes. But it wasn't so good for business users. These users tended not to care so much about colour but did care about having lots of columns of text - 80 was a common standard for interfacing with mainframes and for printed documents. But 80-column text on a TV or composite monitor is almost completely illegible, especially for colour images - alternating columns of black and white pixels in a mode with 320 pixels horizontally gets turned into a solid colour by NTSC. So for business users, IBM developed a completely separate video standard - MDA. This was a much simpler monochrome text device with 4Kb of memory - enough for 80 columns by 25 rows of text. To display high quality text, IBM decided on a completely different video standard - 370 scanlines (350 active) by 882 pixels (720 active) at 50Hz, yielding a 9x14 pixel grid for high-fidelity (for the time) character rendering. In terms of timings, the character clock is similar (but not identical) to that of the CGA 80-column text mode (presumably 16.257MHz crystals were the closest they could source to a design target of 16.108MHz). To further emphasize the business target of the MDA card, the printer port was built into the same card (a printer would have been de-rigour for a business user but a rare luxury for a home user). Business users would also usually have purchased an IBM 5151 (green-screen monitor designed for use with MDA) and IBM 5152 (printer).
CGA also had a digital TTL output for displaying high quality 16-colour 80-column text (at a lower resolution than MDA) on specially designed monitors such as the IBM 5153 - this seems to have been much more popular than the composite output option over the lifetime of these machines. The two cards used different memory and IO addresses, so could coexist in the same machine - real power users would have had two monitors, one for CGA and one for MDA (and maybe even a composite monitor as well for games which preferred that mode). The 9-pin digital connectors for CGA and MDA were physically identical and used the same pins for ground (1 and 2), secondary intensity (7), horizontal sync (8) and vertical sync (9) but CGA used 3, 4 and 5 for primary red, primary green and primary blue respectively whereas MDA used pin 7 for its primary video signal. MDA also used a negative-going pulse to indicate vertical sync while the CGA's vertical sync pulse is positive-going.
So for a while these two incompatible standards coexisted. The next major graphics standard IBM designed was the EGA, and one of the major design goals for this card was to be an upgrade path for both home and business users that did not require them to buy a new monitor - i.e. it should be compatible with both CGA and MDA monitors. This was accomplished by putting a 16.257MHz crystal on the card and having a register bit to select whether that or the 14.318MHz one would be used for the pixel clock (and by having the on-board video BIOS ROM program the CRTC appropriately). By 1984, it was not out of the question to put 128Kb of RAM on a video card, though a cheaper 64Kb option was also available. 64Kb was enough to allow the highest CGA resolution (640x200) with each pixel being able to display any of the CGA's 16 colours - these would have been the best possible images that CGA monitors such as the IBM 5153 could display. It was also enough for 4 colours at the higher 640x350 resolution - allowing graphics on MDA monitors. With 128Kb you got the best of both worlds - 16 colours (from a palette of 64) at 640x350.
IBM made a special monitor (the 5154) for use with the EGA. This monitor could display both 200-line and 350-line images (deciding which to use by examining the vertical sync pulse polarity), and allowed users would be able to take advantage of all 64 colours available in 350-line modes. The video connector was again physically the same and pins 1, 3, 4, 5, 8 and 9 had identical functions, but pins 2, 6 and 7 were repurposed as secondary red, green and blue signals respectively, allowing all 64 possible colours. But they wanted this monitor to be compatible with CGA cards as well, which meant that in 200 line mode it needed to interpret pins 3-6 as RGBI instead of RGBg and ignore pins 2 and 7. So even with a 5154, the EGA needed to generate a 4-bit signal when connected to a CGA monitor, disabling pins 2 and 7.
I guess the designers thought that sacrificing 48 of EGA's colours in 200-line modes was a small price to pay for making the EGA monitor compatible with CGA cards. Presumably they thought that if you had an EGA card and an EGA monitor you would be using 350-line mode anyway, or be running legacy CGA software which wouldn't miss those extra colours.
One thing I haven't mentioned here is the PCjr graphics. For the purposes of the discussion above it's essentially the same as CGA (it has the same outputs) but it's more flexible and slower due to the use of system RAM as video RAM, as many 8-bit microcomputers did in the 80s.
Nice! This is something I've often wondered about, as an erstwhile EGA owner. Hi-res (350-line) games were rare, but they got to pick and choose their colors out of the full EGA palette; while low-res (200-line) games, which were prevalent, were limited to the 16 fixed CGA colors.
Back then, it seemed as if the low-res modes were needlessly crippled - I mean, in those days of limited video RAM, lower resolution should've meant *more* colors, not less!... right?
After I wised up a little, I assumed that this was simply a means of preserving compatibility with RGBI/CGA displays: just set the jumpers correctly, and you get the assurance of 4-bit RGBI signals that your monitor can handle. But that begged the question: why didn't they add *separate* 200-line modes with customizable palettes, for use with specialized EGA monitors that could understand 6-bit signals?
Now that I've read your post, it seems that the key factor in this limitation was the 5154 monitor design: Vsync polarity was inextricalby tied up to scanline count and pinout configuration. So 200-line graphics with the enhanced 6-bit signal just couldn't be tramnsmitted, even though the card had the capacity for it (at leas with 128KB/256KB RAM). Am I getting it right? :)
Yes, exactly - becuase the 5154 has to be compatible with CGA cards as well as EGA cards, if you feed it a 200-line (vsync positive) signal it has no way of knowing whether it is connected to a CGA card or an EGA card, and therefore has to be conservative and assume a 4-bit signal. That in turn means that the EGA card has to generate a 4-bt signal in 200-line mode. If you reprogrammed the registers right, I think it would be possible for the EGA card to generate a 200-line 6-bit signal, but no monitor would display it correctly because they are all CGA/200-line-EGA compatible and therefore assume that all 200-line signals are 4-bit.
[...] Reenigne blog Stuff I think about « Why the EGA can only use 16 of its 64 colours in 200-line modes [...]
I'm glad I found this.
I've been playing around with EGA a bit, and couldn't figure out why although I could write values to the palette registers, only 16 unique colours were displayed at most in 320x200. Each colour was duplicated 4 times in the total palette.
This was on a VGA card, but apparently it emulates this EGA behaviour. I found one other card so far that did NOT emulate it, and showed all colours as expected.
So I read your blog and tried to use mode 0x10 (640x350) instead of 0x0D (320x200). And indeed, in that mode, the palette works just fine.
Nasty behaviour anyway. For games/demos, 320x200 is a far more important resolution. 640x350 was just too slow (and wouldn't allow for double-buffering on real EGA cards with only 128k memory).
Now I not only know what is going on, but also why: IBM in their infinite wisdom made their EGA monitor backward-compatible with CGA. Just great. That's why I'm missing 2 intensity bits, and the third is changed to global intensity.
I do wonder though: this seems to be purely the monitor's doing? I could not find any information on any EGA registers which would control any kind of colour remapping mode. So I wonder if the EGA card just output the colours in 320x200... meaning that the right type of monitor would actually display them all... but do such monitors even exist in the first place?
Yes, it's purely the monitor's doing - from the point of view of the EGA card there's no difference in colour handling between 200-line and 350-line modes - it's just a question of setting the palette registers to the . If you set bits 5 or (especially) 3 in the palette register you could potentially damage a CGA monitor or the EGA card when connected to a CGA monitor, though, since pin 2 (bit 3) is ground on CGA.
There's no monitor that can do all 64 colours in 200-line modes for that reason, and because EGA was quickly replaced by VGA, which has a much more flexible colour output (the DAC registers) with 18 bits instead of 6.
Ah yea... I have been reading the original IBM EGA programmer's manual, which I found here: http://www.minuszerodegrees.net/oa/oa.htm
It is not too clear about this situation, but it does talk about how the card behaves with a CGA monitor connected, and with an EGA monitor connected.
So it works both ways: the EGA monitor is backwards compatible with 200-line CGA output, but also, the EGA output is backwards compatible with a CGA monitor. You can't use the 350-line modes, but the 200-line modes still work (and obviously with the same reduced colours).
I figured I could work around it on VGA cards because they will probably remap the EGA palette to the first 64 entries of the VGA palette. So if I modify the VGA palette directly, I can probably force the full EGA palette.
It's just a bit of a catch-22: it would only work on VGA cards, and if I want to support VGA anyway, I might as well use proper mode 0x13 or mode X (which funny enough is mostly exploiting the graphics controller functionality introduced with EGA, which is what got me interested in exploring EGA in the first place... On EGA I could do the same tricks: smooth scrolling, double-buffering, fast 'blt' operations using the latches, and quick fill routines writing to multiple planes at a time).
There is one other possibility I just thought of. You could probably do a "tweak" 320x350 mode by using the horizontal settings from a 320x200 mode and the vertical settings from a 640x350 mode. Then you could change the CRTC registers so that it only generates 200 active scanlines for a 320x200 mode that is seen by an EGA monitor as a 350-line mode, so all 64 colours would be available. However, the pixel aspect ratio would be that of the 350-line mode, not the 200-line mode. I don't think there's any way around that.
Yes... The site I just linked to also has a manual of the IBM 5154 monitor. It mentions the remapping quite explicitly. They say the mode is enabled based on the polarity of the vertical sync signal. Positive pulse is CGA/200-line, negative pulse is EGA/350-line.
So I guess there is some freedom in reprogramming the CRTC registers, as long as you keep the polarity negative.
There might be a tweaked mode in there somewhere.
For now I've just added some code to detect VGA, and in that case, it overwrites the VGA palette after setting mode 0x0D.
Yeah, the sync pulse timings need to be the right timings to match the sync polarity, so with a negative polarity vsync you still need to generate 366 hsyncs per vsync at 21KHz instead of 262 at 15.7KHz, but within that structure you can generate whatever number of active lines you want.
By the way, this trick of setting VGA palette values in an EGA mode gave me an idea:
My EGA polyfiller is slightly faster than my unchained VGA mode one, since I only need to fill 4 bits per pixel. A dword write results in 32 pixels rather than 16.
Also, because they are actual bitplanes, I can do transparency/glenz effects more easily, by just disabling certain planes while writing.
So then it dawned on me: Triton's Crystal Dream has the fastest polyfiller I've ever seen. Even on a simple 386sx-16 it runs very smoothly. Also, it has a glenz sequence which does not appear to slow down the polyfiller at all (I have tried using the graphics controller's logical or mode in VGA, but you need to read per byte to fill the latches, then write back 1 byte, so you lose the hyperspeed filling of 16 pixels per store, and are limited to 'only' 4).
But... it does not seem to use that many colours. Theoretically it could be using 16 colours, but those 16 colours would be 18-bit VGA palette entries.
So I decided to check... and guess what? It sets mode 0x0D, not mode 0x13. So it's not a fast unchained mode VGA filler as I originally thought. Nope, it's EGA!
[...] the EGA palette? Apparently there is a method to this madness, but what? Eventually I landed upon this blog post, and there was an explanation at last! Apparently IBM wanted to keep compatibility between CGA [...]
Anyone here know why EGA graphics mode was 350-line instead of 400-line? If you are wondering why, look up "NEC PC-98".
I had assumed (as I said in the post) that it was due to compatibility between EGA and MDA (both using an MDA monitor with an EGA card, and using an EGA monitor with an MDA card). Though having said that I'm not sure how compatible they really were since some of the EGA 350-line modes have a different horizontal frequency than the MDA 350-line modes. I'm not sure what the NEC PC-98 had to do with it though - presumably that machine's 400-line mode was based on an interlaced NTSC-compatible timings.
I mean, it was one of the biggest reason why the non IBM PC compatible NEC PC-98 in Japan lasted for so long. Japanese characters were typically displayed as 16x16 per character, and 25 lines * 16 pixels equaled 400 lines. The EGA was short by 50 lines!
Oh, interesting! Is Japanese text not legible with 14 lines then? And is Japanese usually displayed in text mode anyway? I thought there were too many characters so a graphics mode would be used, in which case it would be trivial to display 21 rows of 16-line characters on an EGA screen in graphics mode.
A curious finding that sent me back to this post: *some* extended EGA clones could indeed output 6-bit color in 200-line modes... or so it would seem. (The plot thickens?)
I recently came across these screenshots on Mobygames -
http://www.mobygames.com/game/dos/rambo-iii/screenshots/gameShotId,541305/
http://www.mobygames.com/game/dos/rambo-iii/screenshots/gameShotId,541312/
http://www.mobygames.com/game/dos/rambo-iii/screenshots/gameShotId,541319/
As seen in the first shot, the game supports two "EGA Enhanced 320x200 16 color" modes - Boca and Paradise, as opposed to "Standard IBM Type". The other two screenshots show this "enhanced color" in action. According to the guy who submitted them, they were created using the PCE/ibmpc emulator (http://www.hampa.ch/pce/pce-ibmpc.html).
The colors in these screenshots are a subset of the full 64-color EGA palette, outside the CGA color range. In true 320x200 mode, this shouldn't be possible on an EGA monitor, as your original post shows.
Have you run into such extended EGA cards before? I'm wondering how they made this work - is it actually a "tweaked" 350-line mode like you described in an earlier comment (having wonky aspect ratio on a real monitor)? A true 200-line mode avaliable only on non-standard (or multisync) monitors? My guess is the latter, but there are probably other options I'm unaware of.
My guess would be the latter too. I think it has to be one of those two options (either it works with a standard EGA monitor, in which case it's really a 350-line mode, or it doesn't and isn't). The reason I think it's a VGA monitor with a EGA card that happens to have a VGA connector is that if it was a tweaked 350-line mode it would work fine with a standard IBM EGA and it wouldn't be necessary to have separate modes for Boca and Paradise cards. But it's quite possible that those two cards have different registers for enabling the secondary intensity outputs and/or programming the DAC.
I went and tried the game under the PCE emulator myself. Funny thing: the emulated card is vanilla IBM EGA w/ a ROM dump, but both the Boca and Paradise modes produce 6-bit "enhanced color". I guess PCE doesn't fully implement the way an EGA monitor would treat the signal; in DOSBox, for instance, both options result in a fallback to the CGA palette, making the colors all wrong (the expected behavior for standard EGA in 320x200).
All the more confusing that two separate modes were needed, though. I'm not entirely sold that the targeted monitors were VGA - the menu has "CAUTION!" next to these two options, and that suggests some sort of potential damage if you don't know what you're doing. As you've noted in an earlier comment, messing with palette bits could do that to a CGA screen, but anything that needs a VGA connector should do fine.... not sure what to make of it.
I'm not at all surprised that emulators wouldn't handle these modes correctly - it's pretty rare to find an emulator that supports something that obscure.
My guess is that the warning is to caution against using those modes with a standard EGA card, or possibly with a digital monitor plugged into the Boca or Paradise card - they might have both kinds of connector.
Well, I know that at least some (most?) Paradise EGA cards don't have a VGA connector. They use a standard 9-pin connector. They predate VGA anyway.
Have never seen a Boca card, but googling for info gives a vague reference to the Multi-EGA card having a 15-pin analog connector.
I wonder if the fact that the Paradise cards came with 256k had anything to do with it... That they used a tweaked 350-line mode that only worked with extra memory.