The PCjr. and CGA Compatibility

When IBM designed the PCjr., it based it on its pre-existing IBM PC Color/Graphics Display Adapter (CGA).  However, IBM did not design it in a way that it would be guaranteed to be backwards compatible with all CGA software, especially games.  This article will demonstrate the limitations of the PCjr. with CGA games.

There are four types of games of CGA games, first those that are not aware of the PCjr (Adventure in Serenia), second those that are aware of the PCjr. but do not use the enhanced graphics features of the PCjr. (M.U.L.E.), third those that are aware of the PCjr. and enhance the graphics in some way (Alley Cat), and fourth those that do not really work on the PCjr. (Microsoft Decathlon).  (Interestingly, all these games were released by IBM).  This article is only concerned with the first two types of games.

CGA and the PCjr. are fully compatible at the BIOS level, but only partially compatible at the register level.  The PCjr. can do everything that CGA can do at the hardware level, it just has to do some things very differently.  The CGA is a relatively simple device with eight registers :

Hex Address       Register Function
3D4                    6845 Index Register (to access 18 internal registers)
3D5                    6845 Data Register
3D8                    Mode Control Register
3D9                    Color Select Register
3DA                   Status Register
3DB                   Clear Light Pen Latch
3DC                   Preset Light Pen Latch

IBM implemented all these registers except for the 6-bit Mode Control and Color Select Registers.  There is nothing present at 3D8 and 3D9 in the PCjr.  The CGA and PCjr. have true Motorola MC6845 CRTCs.  The PCjr. also has a video gate array that acts as the graphics controller.

In addition, the graphics memory window with CGA, B8000-BBFFF will also be found with the PCjr., regardless of the amount of memory the PCjr. has (since it shares its video memory with the CPU).

1.  What works

Anything that access the BIOS will work correctly in either the IBM PC with CGA or PCjr.  The PC BIOS through Int 10H, offers several video functions.  All the video functions in the PC are present on the PCjr. Among the chief functions of BIOS Int 10H include setting the graphics modes.  IBM defined seven modes in the BIOS for CGA, 0-6, as shown below

Mode 0 - 40 column x 25 line Text Color/Black and White
Mode 1 - 40 column x 25 line Text Color/Color
Mode 2 - 80 column x 25 line Text Color/Black and White
Mode 3 - 80 column x 25 line Text Color/Color
Mode 4 - 320x200 Graphics 4-Color
Mode 5 - 320x200 Graphics 4-Color/Black and White
Mode 6 - 640x200 Graphics Black and White

On an RGB monitor, all modes except 6 are color capable through the BIOS.  On a color composite monitor or TV, only Modes 1, 3 and 4 are capable of color.  IBM preferred the black and white modes so that text would appear legible on a color composite monitor or TV.

Two other important functions that Int 10H provides include setting the palette to either green/red/brown or cyan/magenta/white and setting the background + border color in the 320x200 graphics modes and the border color in the text modes.  Even though the register write is the same, it will not set the foreground color in the 640x200 mode.

Additionally, those tweaked text modes, found in games like Round 42 (160x100) or ICON : Quest for the Ring (320x200), may also work because the program tweaks the registers of the Motorola MC6845 CRTC.  ICON has a PCjr. executable, and some games like Styx had a PCjr. specific version.

2.  What doesn't work

Since the Mode Control Register does not exist in the PCjr., a program must select the modes using the BIOS.  Any program writing to the Mode Control Register to change its mode will not work.  In addition, for text modes CGA uses bit 5 to turn blinking off and allow a text cell to select the 8 intense colors.  Finally, when bit 2 is 0 it turns on color for the color composite mode.  This is the way that color composite graphics are shown on CGA using the 640x200 mode and the bit is 0 by default in Modes 1, 3 and 4.

The Color Select Register also does not exist in the PCjr., so any program that uses the register to select colors will not work.  Color selection in CGA is limited as follows :

For text modes, bits 0-3 selects the border color.
For 320x200 graphics modes, bits 0-3 select the background and border color.
For 640x200 graphics mode, bits 0-3 select the foreground color (background and border color is always black, works with color composite graphics when bit 2 of the Mode Control register is 0)

None of those functions will work at all on the PCjr.

Bit 5 selects the 3-color palette in 320x200 Mode 4.  If the bit is 0, then the palette is green, red and brown.  If the bit is 1, the palette is cyan, magenta and white.  This is the default.  In Mode 5, this bit has no effect, the palette is always cyan, red and white.  The background color is the only color that is freely selectable in the 320x200 modes.  Since bit 5 is not implemented, any game that uses the Color Select Register to change the palette will show the cyan, magenta and white palette, even though that is not what was intended.  Also, the cyan, red and white palette will not appear, the default palette will be used.

Bit 4 determines whether the palette colors are in low or high intensity.  It works for all three palettes described above.  Thus green, red and brown becomes light green, light red, yellow; cyan, magenta and white become light cyan, light magenta and high intensity white; and cyan, red and white becomes light cyan, light red and high intensity white.  Since bit 4 is not implemented on the PCjr. games will only use the low intensity palettes.

Thus on CGA there are really six palettes available :

IBM PC CGA Mode 4 Palette 1 Low Intensity :

Ultima II - Revenge of the Enchantress

IBM PC CGA Mode 4 Palette 0 Low Intensity :

Digger

IBM PC CGA Mode 5 Palette 0/1 Low Intensity :

Donkey Kong

IBM PC CGA Mode 4 Palette 1 High Intensity :

Battlezone

IBM PC CGA Mode 4 Palette 0 High Intensity :

Shamus

IBM PC CGA Mode 5 Palette 0/1 High Intensity :

Tapper

On the PCjr., however, there are really only two palettes available for games that aren't PCjr. aware, if they work at all :

IBM PCjr. "CGA" Mode 4/5 Palette 1 :

Ultima II - Revenge of the Enchantress

IBM PCjr. "CGA" Mode 4/5 Palette 0 :

Shamus

Note that for PCjr. CGA Palette 1, cyan and magenta are the same as real CGA, but white has become high intensity white.  This is intentional and has been verified on real hardware.  Apparently IBM decided the original palette was not bright enough and so decided to brighten things up a bit.  For PCjr. CGA Palette 0, the intense palette is not available, even for games that intended to use it.  However, several games that used Palette 0 will use Palette 1 on the PCjr. because they used a register write instead of the BIOS function to set the palette.

However, in a 4-color mode, the PCjr. is not limited to the 78 possible combinations of the three preset colors and the background color.  Through its palette registers, the PCjr. can set each of the four colors to any color in the 16-color palette.  1,820 combinations become available.  Likewise, in a two color mode, the PCjr. can set the foreground and background colors independently, and the background color need not be black.  In addition, the PCjr. can set the border color independently in any mode, whereas the CGA can only set a unique border color in text modes.  Instead of only fifteen choices, 120 choices become available.

Even though Tandy copied the PCjr.'s video gate array and graphics capabilities, it restored the Mode Control and Color Select Registers giving it near perfect compatibility with any non-Tandy aware CGA program using the those registers.

Youtube Sucks for Retrogaming Videos

When it comes to videos showing footage of real retro PC and console games, Youtube and the other major video sharing sites suck.  Here is why :

1.  Standard Definition Frame Rate and Aspect Ratio

Normal TVs output a standard resolution : a 525/480 (output/visible) line resolution interlaced at 29.97Hz for NTSC and a 625/576 line resolution at 25Hz for PAL.  The video is interlaced, with odd lines of a frame being displayed first, then the even lines.  Although the TV may be drawing lines 50-60 times per second, the actual number of frames in video is 25-30 per second.  The horizontal resolution with analog broadcast or recording equipment (tape) could be anywhere from 300-600 color dots per line.  Eventually, by the time of DVD, NTSC and PAL video would be able to display 720/704 horizontal dots, and the 4:3 aspect ratio would constrain the visible pixels to fit within the frame.

When Youtube and other video sharing sites were first being implemented, this was the maximum resolution they supported.  In the beginning, with many amateur filmmakers using whatever kind of video equipment they could find, this was not really a big deal.  Youtube also supported 320x240 and 480x360 resolution modes in addition to a 640x480 resolution mode.

Eventually Youtube added support for 720 and 1080 line modes and 16:9 widescreen modes.  In fact, all videos are shown in the 16:9 video window, and 4:3 content is pillarboxed.  All videos can use be seen in any of the following formats :

192x144*
256x144
320x240*
428x240
480x360*
640x360
640x480*
854x480
960x720*
1280x720
1440x1080*
1920x1080

* - Pillarboxed resolutions

While Youtube describes its resolutions as 720p and 1080p, the maximum frame rate is 30 non-interlaced frames per second.

2.  Home Computer and Console Frame Rate

Every computer and classic console prior to the Sega Genesis and Super Nintendo almost exclusively output a video signal at either 60 frame per second for NTSC systems or 50 frames per second for PAL systems.  Thus the Atari 2600 usually supported a 160x192 resolution, the Apple II, 280x192, the Atari 8-bit,  320x192, the Commodore 64, 320x200, the IBM PC with CGA 640x200, the Colecovision and Sega Master System, 256x192 and the NES, 256x240.   The Sega Genesis and Super Nintendo did support high resolution interlaced graphics, but games stuck with the low resolution modes 99.9% of the time.  Some home computers like the Amiga and add-on cards like the IBM 8514/A did support an interlaced signal, but this was rarely used due to the flicker perceived by the short distance between the user's screen and eyes.  These early consoles and computers traded graphic resolution for frame rate, primarily to reduce distracting flicker.  Handheld consoles like the Gameboy, Sega Game Gear, Nomad, Gameboy Advance all support 60 frames per second.

The IBM PC and compatibles did not vary refresh rate by country but instead by display adapter.  The monochrome and Hercules cards used 50Hz, the CGA, PCjr., Tandy 1000 and EGA adapters 60Hz and the VGA, SVGA and later adapters 60Hz, 70Hz, 72Hz, 75Hz, 85Hz.  When LCDs overtook CRTs in computer display technology, 60Hz to 75Hz was generally deemed sufficient for fluid gameplay, as flicker was no longer an issue.  3D screens in 3D mode use 120Hz because twice as many images are being displayed.

For gaming consoles, only with the Playstation, Nintendo 64 and Sega Saturn did interlaced modes show some significant use, but they did not truly become popular until the Playstation 2.  Most Dreamcast and Gamecube and Xbox games could be played in 480p progressive scan (60 frames per second) through the use of special VGA or component video cables.  A much smaller proportion of games for the Playstation 2 support progressive scan.  The Nintendo Wii supports 480p over component video cables and the Playstation 3 and Xbox 360 generally use 720p for HD games.

3.  The Problems

If you post game footage to Youtube, either taken by a video capture device or an emulator, Youtube is going to convert your video.  Since it will not display native 60 frames per second video, it will convert it to 30 frames per second.  This can be done by dropping every other frame, or by interpolating two or more adjacent frames to make one frame.  However, as either method would cut the running time in half, each frame may be repeated.  This plays havoc with the motion within the game footage.  It looks jumpy as though it was being played on a poor emulator.

The other issue is the scaling algorithms used.  Say I take some emulator footage of a NES game.  The emulator has no filters, no scalers, just pure 256x240 graphics at 60 frames per second.  The pixels are crisp, sharp, clear.  Each pixel is the same size and each color is clearly distinct.  This is the purest form of capture you can get, provided of course you use an accurate emulator like Nintendulator or Nestopia.  The resulting video may be losslessly compressed, but Youtube does not display losslessly compressed video, no matter how small it may be.  DOSBox 0.74 and Yhkwong's SVN has a lossless video codec which it uses to record, and since DOSBox is highly accurate, it is by far easier to capture video from DOS games using it, especially pre-VGA, than from real hardware.

I posted a test video here : [link removed]  This video was originally recorded using Nestopia - Undead Edition 1.45, a very accurate emulator.  I decided to use the 2C03 RGB PPU palette (without the extra grays Nestopia inserts) to simulate as accurately as possible the ideal capture from the real machine using the highest quality output that would be readily available.  The 2C02 PPU, found in every consumer-based NES or Famicom except the Famicom Titler, can only output composite video.

While most of my run through the stage is not too bad, things really start to look wrong when Mega Man fights the boss.  There is a fair amount of flicker on real hardware or the emulator as this part of the game really goes beyond the 64 sprite limit of the NES.  However, the result is nowhere near as bad as the the video makes it out to be, and just ends up distracting.

In addition, my video was pixel perfect, no interpolation shown when viewing it at its native resolution.  Youtube does not offer an "exact size" setting for the video window.  To be fair, 256x240 is really too small to watch unless you have a low resolution monitor.  However, there is no x2 or x3 scaling available.  The smallest window size is 384x360, the larger window size is 512x480 (an ideal 2x) and the full-screen mode is whatever the native resolution of your monitor is with pillarboxing.  All scaling uses typical bilinear or bicubic sampling, so what were sharp pixels appear fuzzy.  Nearest neighbor interpolation is easier computationally, but not available.

If you download an MP4 of the video, and there are many utilities you can use to do this, you can see the video in its native size without interpolation.  It will appear sharp.  However, Youtube's conversion process has done its damage to the frame rate, which as you will now see is 30 fps.  Here you can compare for yourself :

[links removed]

Unfortunately, if you wanted to see my playthrough video at it was meant to be seen, you cannot view it in a browser, you must go to the trouble of downloading it.  And this is with a perfect video capture.  Captures from real hardware frequently look like crap between the capturing device (most not designed for vintage consoles and computers and not designed for pixel-perfect accuracy, if that can be done for analog video) and Youtube's conversion.  I used to host videos of my classic computers on Youtube, but since I only had a cell phone camera (which will take video only at 30fps), the video always looked bad and flickery, something Youtube can do nothing to improve.  To be fair, it was not Youtube's fault, so I took them down.

Nestopia and DOSBox use the ZMBV capture codec to capture video with lossless compression and the accompanying audio.  It is an excellent way to capture 8-bit video, and for NES video, the resulting file size is an average of 7MB per minute.  If you did a two-hour playthrough of a game, the resulting file size would only be 840MB at the native resolution and frame rate.  This is a very reasonable file size, and while Youtube does recognize ZMBV encoded AVI files, it will compress them and the first casualty will be the frame rate.

Windows 98 Tips #1

Accessing DOS

Microsoft Windows 95 and 98 use Real Mode DOS as a boot loader.  Windows provides all the services a well-behaved DOS program needs to function.  It also allows DOS programs to directly access hardware.  However, certain functionality found in the GUI Windows environment is lost if you must use Real Mode MS-DOS unless you know how to restore it.  For games this is chiefly mouse and CD-ROM support.  You may or may not need sound card drivers, depending on the sound card you intend to use for DOS.

Many DOS games will not play at all, or optimally, when run under any Windows 9x system.  See here for Microsoft's list : http://www.vogons.org/viewtopic.php?f=5&t=761&p=28650&hilit=Microsoft+knowledge#p28650
You will need to run them in MS-DOS Mode.  In Windows 98SE, there are four ways by which Microsoft will allow you to use the DOS command line interface.

Command Propmpt Application - This provides the DOS command line interface in a window.  It may look like DOS, especially if you set it to full screen, but it is really Windows allowing you to input commands using the DOS command line prompt.  It is useful if you are trying to run an executable with variables, but it will not otherwise make your DOS game more compatible with Windows.  It does not support Very Long Filenames (none of these methods do), and it will truncate them to the first six characters followed by a ~1, then the extension.   It can also be opened by the file DOSPRMT.PIF in the WINDOWS directory.

Restart in MS-DOS Mode - This will give you a basic, real-mode DOS environment.  By default, it acts like the only thing loaded is your CONFIG.SYS file is HIMEM.SYS and DOS=HIGH.  If you have a Sound Blaster card installed, it will set the SET BLASTER environment variable in DOS.  It is found on the start menu as a shut down option, but can also be activated with the Exit to Dos.PIF in the Windows directory.  About the only thing you may be able to load without games complaining about too little Conventional Memory is the Cutemouse driver.  However, it will allow games that refuse to run with EMM386.EXE to work.  Windows 98 does not provide a mouse driver for real-mode DOS.  

MS-DOS Mode for Games - This .PIF, found in the Windows file, will give you all the benefits of Restart in MS-DOS Mode plus it will load EMM386.EXE with the NOEMS option, giving you access to the Upper Memory Area (UMA).  The CONFIG.SYS file will load DOS=HIGH,UMB instead.  Unfortunately, unlike Restart in MS-DOS Mode, it will cause your system to reboot.  This will allow you load device drivers and TSR programs in Upper Memory to conserve precious Conventional Memory for DOS games.  XMS Memory will be available, but more games used EMS Memory.  

MS-DOS Mode for Games with XMS and EMS Support -  This .PIF, found in the Windows file, will give you all the benefits of MS-DOS Mode for Games and it will by default allow for 4MB of EMS Memory.  EMS was the most popular method to access memory above 640KB and programs used it until 32-bit DOS Extenders became popular in 1994.  Many games supporting Sound Blaster digitized sound and most CD-ROM titles from the 1991-1993 either required it or supported it.  The actual provision of EMS will require 64KB that could otherwise be used as an Upper Memory Block, and this becomes extremely important when loading the Windows 98 default MS-DOS CD-ROM driver, OAKCDROM.SYS.

You can edit Exit to DOS, MS-DOS Mode for Games and MS-DOS Mode for Games with XMS and EMS Support.  You need to right click on the icon, click on properties on the drop-down menu, click on the Program tab and click on the Advanced button.  The next Window will give you boxes to change the lines of CONFIG.SYS and AUTOEXEC.BAT.  Remove the word REM from the lines you wish and add new parameters.  Note that in Windows 98SE, the path where OAKCDROM.SYS is indicated is incorrect.  

CD-ROM and Upper Memory - If you have an IDE/ATAPI CD-ROM or DVD-ROM drive, Windows 98 has a device driver called OAKCDROM.SYS which will mount the drive as a CD-ROM drive in Real Mode DOS.  When Windows 98SE is installed, you can find the file on the startup disk or if you make a recovery disk.  It is a bloated driver and requires 35K of precious memory, so I highly advise using VIDE-CCD.SYS instead, which only requires 5K of memory.  The CD-ROM driver is loaded in CONFIG.SYS in one of the following ways :

DEVICE=C:\WINDOWS\COMMAND\EBD\OAKCDROM.SYS [VIDE-CCD.SYS] /D:MSCD001 (if no UMBs are available)

DEVICEHIGH=C:\WINDOWS\COMMAND\EBD\OAKCDROM.SYS [VIDE-CCD.SYS] /D:MSCD001 (if UMBs are available)

However, loading the device driver is not enough.  For DOS to access it as a disk drive, the MSCDEX.EXE TSR must be loaded.  It is loaded in your AUTOEXEC.BAT file like this :

C:\WINDOWS\COMMAND\MSCDEX.EXE /D:MSCD001

If you have access to UMBs, you can place LH before the path to load MSCDEX in a UMB.  

OAKCDROM.SYS (35K) and MSCDEX.EXE (27K) are by far the largest programs you will ordinarily load into the Upper Memory Area.  By default, Windows will provide approximately 96K of Upper Memory in the MS-DOS Mode for Games mode, but only 32K of Upper Memory in the MS-DOS Mode for Games with XMS and EMS Support mode.  (This is another reason for you to replace OAKCDROM.SYS.)  If you have a CD-ROM game and it needs EMS Memory, try running it in Windows first.

File Transfers using Network Neighborhood

So having Windows installed on your vintage machine, how can you transfer files from a more modern system?  There are many methods.  Some of the most basic, but most annoying are floppies and CD-RWs.  USB sticks or drives may or may not work.  It tends to depend on whether a generic mass storage driver will work with Windows 98 and the drive.  Compact Flash cards are natively supported as IDE devices, but as removable devices you may not get them to work.

The best method, in my experience, is to use network transfers.  Windows 98 has support for file and printer sharing and can talk to Windows NT Networks.  PCI Network cards are cheap and easy to find for Windows 98, and Windows 98SE may have drivers for them out of the box.  The 3Com cards are especially popular and supported out of the box (except for the Gigabit cards).

Once you have your network card's drivers installed, install file and print sharing from the network properties in the control panel.  Then right click on a folder in Windows Explorer and share it.  Make sure that the network name on your Windows 98 machine matches the network name on modern system.  The default name is usually WORKGROUP.  On your modern computer, you should now see your Windows 98 computer on the network.

If your modern PC is running Windows 2000 or XP, you can typically access it with the Windows 98 machine.  With Windows Vista or 7, you cannot access your modern machine through Windows 98 by default.  There may be a method to allow access, but it is not necessary because when you share a folder on the Windows 98 machine, any other machine can copy files to that folder if you set the folder on the Windows 98 machine to allow full access.  With Network Neighborhood, you have a convenient method to send files to your computer without needing physical media.  

320x200 : The Resolution of Choice for the IBM PC

IBM decided that its Color/Graphics Adapter would support a 320x200 pixel resolution in its "medium" resolution graphics modes.  In its 40-column text mode, the 8x8 character cell would given an equivalent resolution with 25 rows on the screen. The 16KB CGA card could only display 4 colors on the screen at one time from a 16 color palette, barring graphics tricks.  It also supported a high resolution graphics at 640x200 pixels with one color freely selectable, but this was comparatively seldom used except when games turned it into a 160x200 pixel mode using color composite graphics.  Its 80-column text mode would, with 25 rows and an 8x8 text box, correspond to the 640x200 pixel resolution.

IBM did not offer a color display at the launch of the PC.  It was assumed that most users would connect the CGA card directly to a color composite monitor or to a TV via an RF modulator.  While NTSC-standard color displays could support up to 240 visible lines without interlacing, a large portion of the visible area of the screen on these devices could be obscured by the physical shell surrounding the glass monitor.  Previous home computers from Apple and Atari only supported 192 pixels as a result.  IBM's 200 pixels was hardly likely to tax the newer displays of the 1980s, which showed a more rectangular viewing area than the more circular TV screens of earlier decades.  In 1983 IBM released its 5153 PC Color Display, which provided official RGBI support from the Corporation.  This monitor had a vertical size control, which could accomodate 240 lines quite easily.  The CGA card hardware and 16KB of RAM, could not.

Jill of the Jungle CGA 320x200x4 Mode

The next widely-used graphics advances were the PCjr.'s Enhanced CGA graphics, later cloned by Tandy and known then as Tandy graphics.  This also primarily used a 320x200 pixel graphics mode with 16 colors available, but also supported a true but seldom used 160x200x16 low resolution graphics mode and a very rarely used 640x200x4 graphics mode.  IBM's PCjr. was only CGA compatible at the BIOS level, but Tandy's Graphics Adapter was CGA compatible at the register level.  The PCjr. and Tandy graphics adapters took from 16-32KB of system RAM for its graphics RAM depending on the mode.

IBM's EGA card also supported a 320x200x16 graphics mode, and this was by far the most frequently used graphics mode in EGA-supporting games.  The EGA could also support a 640x200x16 graphics mode and was backwards compatible with CGA at the BIOS level.   Tandy Graphics and EGA graphics would almost invariably look the same, but the hardware was very different.  Tandy's Enhanced Graphics Adapter, introduced with the Tandy 1000TL and 1000SL also supported a 640x200x16 mode, but few programs used it as it was not EGA compatible.  Amstrad's CGA adapter also supported a unique 640x200x16 mode, but few programs used it.

Jill of the Jungle EGA 320x220x16 Mode

All the above graphics modes worked on the same type of monitor, a digital TTL RGB monitor only capable of selecting sixteen colors.  This monitor supported the same NTSC horizontal (15.75KHz) and vertical (60Hz) scan rates of the television set.  For the EGA, IBM also included support for a 640x350 line mode with 16 colors selectable out of a 64 color palette.  This mode only worked on a special color monitor, the 5154 PC Enhanced Color Display, which supporting a higher horizontal scan rate (21.8KHz) and the ability to select 64 colors through digital TTL RGB inputs.  The standard IBM EGA card only came with 64KB, but the 640x350x16 mode required a 128, 192 or 256KB of RAM on the card.  Most clone cards came with 256KB standard.

In 1987, IBM introduced the VGA and new corresponding monitors.  VGA supported a 320x200x256 graphics mode with a palette of 262,144 colors available.  This was the mode most frequently used by games. VGA was backwards compatible with EGA at the register level and CGA at the BIOS level.   It also supported a 640x480x16 mode, but far fewer DOS games used it.  Windows 3.0 and above would use it for its default graphics display.  A new monitor was required to display the much larger color palette of the VGA compared to the CGA and EGA.  Analog color monitor outputs were used.  The high resolution display supported a 31.5KHz scan rate and 70Hz vertical refresh rates for all VGA modes, including emulated modes, except for the 640x480 mode, which used 60Hz.  200-line modes would be double scanned, with each pixel being double-clocked and each vertical line being repeated to fill up the refresh rate.  This gives a different kind of scan-line structure compared with earlier monitor.

Jill of the Jungle VGA 320x200x256 Mode

By the time of VGA, the 320x200 resolution had found support in many non-IBM PC compatible home computers.  The Commodore 64 used a 320x200 resolution and a derived 160x200 resolution.  The Atari ST, Commodore Amiga and Apple IIgs all used a 320x200 (and to a far lesser extent 640x200) resolution with varying degrees of color and palette support.  While the PAL Amiga supported 256 lines by default, most games used 200 lines for extra speed.  Those squished screenshots of Amiga games (compared to other systems) display that way on PAL machines.

Most VGA games only supported 320x200x256 graphics mode.  The BIOS mode, Mode 13h, was easy to program for but somewhat limited.  Eventually programmers found out how to create custom resolutions by using the VGA hardware registers, the so-called Mode X.  Mode X typically comprised of 320x240 pixels, which gave square pixels.  Epic Pinball and The Last Vikings used this mode.  Some games used a 320x400 graphics mode, which was easy to obtain on VGA hardware.  Programmers had to be careful to ensure that their custom mode would be compatible with the wide variety of VGA adapters in the marketplace.  Standard 256KB VGA can support any combination of 320 or 360 horizontal pixels by 200, 240 or 350 vertical pixels with 256 colors.

I have included screenshots of Jill of the Jungle above.  Jill supports all 320x200 in all three color modes.  The game does not support 320x200x16 graphics on an IBM PCjr. or Tandy 1000 Graphics adapter (few if any shareware games supported the unique graphics modes these adapters), it will use the 320x200x4 mode instead.  Except for Jill's face, the graphics are virtually identical, pixel-wise, across the three modes.  Many games down-convert the graphics using an algorithm to eliminate the need to have two extra sets of graphics images or tiles on the disk.

320x200 has a 1.6 pixel aspect ratio.  To get truly square pixels, a 4:3 display must have letterboxing.  A 16:10 1280x800, 1920x1200 or 2560x1600 widescreen monitor can display the resolution perfectly using nearest-neighbor interpolation.  However, when the resolution was used all displays were 4:3, and most users would stretch the 200 vertical lines to fill up the screen.  Instead of perfectly square pixels, you would get pixels 1.2 times as vertical compared with the horizontal width on a monitor where the vertical width had been stretched to the edges of the monitor.  Most graphic artists assumed this and adjusted their graphics accordingly, but not all did.

An illustrative example.  Look at this screenshot of Elite Plus, using the VGA 320x200x256 graphics mode.

You can see that the circle is a circle in the 1.6:1 aspect ratio.  But when converted to a 4:3 aspect ratio :

The circle has become an oval.  Thus it would seem that the 1.6:1 aspect ratio is correct for this game.

Let's look at another game, LOOM.  Here is a screenshot with a clearly spherical object in it :

Looks a bit squat in the 1.6:1 aspect ratio.  If we stretch the aspect ratio :

Now the crystal ball looks like a sphere in a 4:3 aspect ratio.  Click the 4:3 images for an undistorted, pixel-perfect resize but huge (1600x1200) version of the screenshot.

Even when Windows 95 was released, most graphically intensive games for the PC were still being released for DOS.  Only in 1997, with the acceptance of 3D accelerators, DirectX and the undeniable dominance of the Windows platform did high-performance games finally require Windows.  Most games up to this point either only supported 320x200 (DOOM, Daggerfall) or offered it as the default resolution (Duke Nukem 3D, Quake).  SVGA was not well-supported because each chipset had its own way of offering higher resolution modes, and by the time VESA modes were widely supported, Windows 95 was the gaming OS of choice.  At this point, 640x400x256 and 640x480x256 graphics were the norm.