Wednesday, October 30, 2013

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.

Saturday, October 19, 2013

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.  

Saturday, October 12, 2013

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.

Sunday, September 29, 2013

Slaughter of the 'Bots - One Must Fall 2097 vs. Rise of the Robots

One Must Fall 2097 Title Screen
Rise of the Robots SVGA Title Screen
Rise of the Robots VGA Title Screen
In 1991, Street Fighter II was released in the arcades to great acclaim.  Ports of the game to home consoles and computers and clones like Mortal Kombat soon followed.  Virtually any property or idea could be used in a fighting game, including dinosaurs (Primal Rage), The Simpsons, or even Nintendo's characters (Super Smash Bros.).  In 1994, two different companies released a robot fighting game for the IBM PC Compatible platform.  The first was One Must Fall 2097 (OMF), developed by Diversions Entertainment and released around October, 1994 by Epic Megagames.  The second was Rise of the Robots (RotR), developed by Mirage Studios also released around the same time by Time-Warner Interactive.  In this article, we will compare these two DOS fighting games in every area.  As you will soon read, this comparison will turn out to be grossly unfair to one game.

Graphics

OMF Main Menu
OMF uses the standard 320x200x256 VGA color mode and originally came on five floppy disks.  Later releases were on CD.  RotR was released in separate 320x200x256 VGA and 640x400 SVGA boxes.  The SVGA retail version took up fourteen disks.  The VGA version, which was released only in Europe, still took up ten,  The VGA version has more animated cutscenes than the SVGA version. RotR was also released on CD with more animated scenes than either disk version, but no extra gameplay or music.  The screenshots for OMF and RotR VGA in this post have been pixel-doubled to 640x400 while the screenshots from RotR SVGA are in their native 640x400 resolution.  Neither game featured scrolling backgrounds.  Unlike RotR's static backgrounds, there is animation in OMF's backgrounds and hazards (spikes, fireballs, electrified walls, strafing aircraft) that can harm either opponent.

OMF takes its inspiration from Japanese anime.  Realism is not particularly prized.  This approach was uncommon during the mid-90s, when DOS games were generally striving for better realism.  RotR shows a more Western sci-fi influence, where realistic shapes and models are used.  Robot animation seems a bit choppier with RotR than with OMF.

Both games run very well on a mid-range 486, even RotR in its SVGA version.

RotR Main Menu SVGA
RotR Main Menu VGA
Sound and Music

OMF Combat Screen
Both games have entirely digitized sound tracks.  OMF officially supports the Sound Blaster, Sound Blaster Pro, Sound Blaster 16, Pro Audio Spectrum cards and the Gravis Ultrasound with 512K or more of RAM. The Ultrasound is the best choice by far for the game, the audio output quality with this card is always at its best.  The Sound Blaster 16 and the Pro Audio Spectrum 16 require a Pentium sound quality approaching that of the Ultrasound.  Even at the maximum quality settings, the music and sound effects as output by a Sound Blaster 16 or Pro Audio Spectrum 16 still sound a bit muffled and noisy compared to the output of the Ultrasound.

RotR only officially supports Sound Blaster cards.  It does not allow the user to determine the type of card, original, Pro, 16, in the setup program.

RotR Combat Screen SVGA
RotR Combat Screen VGA
The music for OMF was done by C.C. Catch (real name Kenny Chou) of the demoscene group Renaissance.  It is well-known that the demoscene took to the Gravis Ultrasound and thrived with it, and this music is well-representative of the music found in demos.  Each of the five arenas has its own music.

The "music" for RotR was done by Brian May, the guitarist of the band Queen, however in the DOS versions it consists of 15 seconds of guitar riffs, even with the CD version.  May's music is only heard during the title sequence.  The rest is ambient audio, even in the fight scenes.  The 3DO version has his soundtrack in addition to the Mirage soundtrack.

Control

Both games support the use of the keyboard or joystick.  Gravis gamepads, which are digital, are highly recommended.  Only the first two buttons on a joystick are supported.  Gemini of Ancient DOS Games indicates a preference for the keyboard because it is easier to pull off special moves.

Both games use the Up, Up-Left and Up-Right joystick positions to jump.  OMF uses one button for "punching" and one button for "kicking".  RotR uses one button for attacking and one button for blocking.  In both games blocking can be done by holding the directional away from the attacker.  In RotR, blocking an attack will still result in damage being taken, OMF only allows special attacks to take away health if successfully blocked.

RotR requires you to hold down the button to determine the strength of the attack, then push a direction to initiate an attack.  This is very strange for a fighting game.  Ordinary fighting games give an instant response to a button push.  If you press the punch button, your fighter punches.  The strength of the attack is usually determined by the button pressed.  In RotR, if you want to make an attack any more powerful, you must hold down the button until the power meter is at the level sought, then release the button to make the attack.  Needless to say this scheme throws timing completely off and makes jump attacks much more difficult to pull off than they should be.

OMF has a much more fluid control scheme like Street Fighter II.  It uses the combination of direction with the punch and kick buttons to determine the type and strength of the attack.  The push of a button, even without a direction, will still result in an attack.

Another oddity for RotR is that you cannot jump over your opponent and will always face the same direction.

With a special move list, I was able to perform special moves for the Jaguar robot reasonably well with OMF, but could not execute the special moves for RotR's Cyborg at all.

Robots

OMF Pilot Select
OMF in its one or two player games requires you to select a pilot for each robot, and there are ten pilots, each with their own back story and motivations.  The pilot determine the strength, speed and endurance of the robot selected.  When pilots fight against each other they taunt each other before the fight, and each pilot has his or her own ending.  There are ten robots ordinarily available, each with their own handling characteristics and three to four special moves.  Thus 100 combinations are available.  There are also special finishing moves like the fatalities of Mortal Kombat.  In the Tournament Play, you get to customize your own pilot character and your robot.  You can earn money by victories to buy upgrades for both and can eventually purchase new robots.  This is as about as close to a Role Playing Game as a fighting game got at this time.

OMF Robot Select
RotR has one main robot, the Cyborg which you can use in the story mode.  Five more robots are available for practice and in the two player fighting mode, but one player must control the Cyborg.  Each robot has one or two special moves.

RotR Enemy Robot Introduction SVGA (Originally Animated)
RotR Enemy Robot Introduction VGA (Originally Animated)
Releases and Ports

OMF was strictly a DOS game.  RotR was released for a wide variety of platforms, including the IBM PC Compatibles, the 3DO, Commodore Amiga (separate 32-color and 256-color disk releases), Amiga CD32, Phillips CD-i, Sega Game Gear, Sega Genesis and Super Nintendo.  The Super Nintendo version has more animation and music than the PC floppy versions, although it weighs in at only 4MB compared to the 29.7MB install of the SVGA PC floppy version.

Difficulty Levels

OMF Combat Aftermath
OMF has many difficulty levels, some of which are hidden.  The readily available difficulty levels are punching bag, rookie, veteran, world class and champion.  There are also the hidden difficulty settings of deadly and ultimate.  The lowest difficulty is for practicing moves, and the rookie difficulty is manageable once you know the regular and basic special moves.  The higher difficulty levels above veteran require real commitment to the game.  I was able to win on the veteran difficulty level (the lowest level of difficulty where you can face the final pilot and win the game) after a few hours of playing the game with the basic Jaguar robot.

RotR Combat Aftermath SVGA (you will see this screen a lot if you play this game)
RotR Combat Aftermath VGA (you will see this screen a lot if you play this game)
RotR has beginner, easy, medium and hard difficulties.  Don't be fooled, the beginner level is very difficult. The true final robot is only accessible after beating the hard difficulty twice.  The robots you will face in the game have tremendously unfair advantages.  Almost all of them seem to move faster and have attacks with a much better reach than the Cyborg and more powerful to boot.  They do not seem to be hampered by the control scheme inflicted on the player.

Special Features

OMF supports remote multiplayer as of version 2.0 through a null-modem serial link, a modem or over an IPX network.  It also will let you record your gameplay and play it back later.  There are a number of secrets, codes, robots and settings.  There is a hyper mode that makes for faster gameplay and more intense special moves.

RotR has a few special codes, but generally what you see is what you get.

Assessment

One Must Fall 2097 was one of the best fighting games for DOS.  I would say this is as controversial an opinion as "Abraham Lincoln was one of the greatest Presidents of the United States."  This is not saying too much, as most fighting games released for the PC before Street Fighter II have not aged well at all and most of the games released after Street Fighter II are ports of arcade machines of varying quality.  Still, given the limitations of the controllers available to OMF, it still manages to be a game of surprising depth and yet easy to pick up and play today.  The robots have varying abilities and while the balance is not necessarily perfect, all have their interesting points.  Moreover, it is surprising today to learn that this game was realized mainly by four people (according to the credits).  It is a testament to the talent and dedication of a few individuals who wanted to make a fun and enjoyable fighting game and succeeded tremendously.

As for Rise of the Robots, virtually every negative comment I have heard about the game prior to my own investigation of it is justified.  "Style over substance" and "graphics over gameplay" are two accusations that are entirely supported.  Interestingly, RotR had over a dozen people working on it and a budget large enough to port it to eight very different platforms.  It seems that whatever resources were left over after modeling the robots in 3D Studio Max was spent on ports.  However, all those resources resulted in a game that was about as complex as the original Street Fighter arcade game.  The moves are so simple, the too-few robots have very similar moves and there are only limited match ups available.  The music, sound effects, animation and moves are too limited to keep anyone playing for long.  Unless you are playing in the two player mode, your one robot will fight the same five robots in the same order over and over again until you get sick of the game.  The game quickly becomes boring and between the awful control scheme and the cheap computer opponents there is no reason why I would want to play this game ever again after this blog entry.  The PC version feels especially rushed, the console versions are more playable.

One Must Fall 2097 is freeware and deserves a spot on every DOS gamer's hard drive.  Virtually every version of it, 1.0, 1.1, 2.0 and 2.1 can be found at RGB Classic Games : http://www.classicdosgames.com/.  Ancient DOS Games' review of the game is an excellent point to start the new player with acquainting himself or herself with the game modes and play :  http://www.pixelships.com/adg/ep0019.html

Rise of the Robots deserves only to sit on a collector's shelf.

Tuesday, September 24, 2013

The Overlooked Artifact Color Capabilities of non-Apple II Computers

When the first home computers came to market in the late 1970s, their capabilities were focused mainly on getting text to display on the screen.  Text doesn't require color.  Steve Wozniak wanted his second computer, the Apple II, to display in color.  The computer had a monochrome text mode of 40 columns by 24 rows with a 7x8 character box.  It also could display up to 16 solid colors (really 15 as the two gray colors are not really distinct) using those text boxes, and two colors in each box (a top color and a bottom color) for an effective resolution of 40x48.  However, this Low Resolution Graphics Mode was insufficient for graphics of any real detail.

Apple II Low Resolution Graphics Example - Lemonade Stand

The Apple II also supported a 280x192 pixel High Resolution Graphics mode.  The actual pixels were white and did not contain color/hue or saturation information.  Each of bits, except the highest, of every memory byte for the HGR page could display a single dot if set (logical 1).  A single memory location could set up to seven consecutive pixels.  Pixels on even horizontal lines would appear as purple first, on odd lines they would be green first.  If one pixel was set, it would be in color on a color monitor.  If two adjacent pixels were set, they would appear as a double-wide white pixel.  Similarly, if two adjacent pixels were off, they would appear as black. The trick to getting solid colors was to place pixels in an alternating on-off-on pattern.  That is why people would frequently see "serrated" or "stripey" graphics with a monochrome display instead of a solid color.  The effective color resolution is something close to 140x192.

Apple II High Resolution Graphics Example #1 - Ultima

The trick behind color composite graphics is the use artifact color.  The NTSC color carrier operates at a 3.58MHz frequency.  The phase (measured in degrees, think of sine waves) of this frequency is shifted as the beam travels across the TV to set the color/hue, and the amplitude of the signal is varied to determine the saturation.  In HGR Mode, the pixels, which constitute the brightness information, are being sent to the TV at a 7.16MHz frequency.  Thus there are two "black and white" pixels for every "color" pixel.  In a pure black and white mode, the color carrier, informing the TV that it is to display in black and white only.  In fact, the Apple II has a "color killer" circuit to prevent the color carrier from being sent in full text modes.  However, the text will show artifacts in mixed modes.

With composite artifact color, the color carrier signal is sent.  The phase of the signal oscillates from 180 degrees to 270 degrees, 0 degrees, 90 degrees and back to 180 degrees for each color clock.  The pixels are sent at twice the frequency of the color clock, and depending on where on the screen the pixel is, this will show the combination of the two nearest phase shifts.  Thus, in the original Apple II, you can obtain a green from the combination of 90 and 180 degrees (~135 degrees) and magenta from 270 and 0/360 degrees (~315 degrees).  Soon, the designers of the Apple II figured out how to use the eighth bit of each memory location to delay the pixel clock by half a clock, giving blue (~45 degrees) and orange (~225 degrees) artifact colors.  Visually, a memory location with blue/orange colors will appear slightly shifted compared to a memory location above or below with green/magenta colors.

Due to the lack of bandwidth of an NTSC monitor, instead of getting colors alternating with black, you will see mostly solid colors.  When the first pixel is set to color, the color carrier does not have time to fully transition back to black for the second color when the third pixel is also set to color.  Thus you get a mostly solid color, however the better your monitor and connection, the more likely you will see lines between pixels.

Apple II High Resolution Graphics Example #2 - Wasteland


Apple II Double High Resolution Graphics Example - Might and Magic II: Gates to Another World

Later with the Apple IIe machines (after the first revision and expanded to 128K), a Double High Resolution Graphics Mode supporting all 15 unique colors was available.  By this time Apple had begun to use VLSI chips and thus no longer as limited in the color selections.  Double High Resolution Graphics use a 560x192 resolution and a 14.318MHz pixel clock.  Because there are now four pixels changes for every color change, the effective color resolution is still close to 140x192.  The extra pixels allow for a much more expanded color palette.  The high-bit pixel clock delay of the High Resolution Mode, which was something of a hack, is not required.  In this mode, each byte sets the color of two pixels.

At least seventy games support DHGR graphics, but not all are very playable on a 1MHz 6502/65C02 and many of these games pale in comparison to versions of these games for other platforms.  Maniac Mansion, Sierra AGI Quest games and many arcade ports fall into this category.  Still, there are several games originally developed for the Apple IIe and its DHGR mode, including Prince of Persia (limited), Dragon Wars, Might and Magic II, King's Bounty, Air Heart, Into the Eagle's Nest, Legend of Blacksilver.

Atari 8-bit Color Composite Graphics Example #1 - Exodus: Ultima III

While the Apple II was built entirely with generic TTL logic chips, the Atari 8-bit machines had a pair custom graphics chips, ANTIC and CTIA, later GTIA, to handle the graphics modes.  ANTIC and GTIA offered several graphics modes, and one of them, ANTIC Mode F, BASIC Mode 8, gave a 320x192 resolution mode with monochrome graphics.  However, this mode utilized artifact color.  Many ports of Apple II games used this mode.  Four primary artifact colors are supported in this mode, the colors vary depending on the revision of the CTIA or GTIA chip and system.  At least 45 games support the Atari composite color mode, including all the Ultima games, anything released by Origin Systems, Broderbund's original Choplifter,  Lode Runner & Championship Lode Runner; Sierra's Hi-Res Adventures, Flight Simulator II and many Pinball games.  Unlike the Apple II, the Atari machines were not strictly limited to black and white as the direct color in this mode, as can be seen in Choplifter and Ulysses and the Golden Fleece.  These machines can set artifact color in combination with a direct color.  Assuming that the base color is white, the usual artifact colors are blue (~0 degrees) and brown (~180 degrees).  Some machines reverse the colors output.

Atari 8-bit Composite Color Example #2 - Choplifter!

Discussion of IBM PC Composite Color moved to its own blog entry : http://nerdlypleasures.blogspot.com/2013/11/ibm-pc-color-composite-graphics.html

Tandy TRS-80 Color Computer Color Composite Graphics Example - Donald Duck's Playground

In 1982, Tandy released its Color Computer.  Its graphics system had definite similarities with the CGA card, its sound system was very simple and it was not very attractive to game developers.  It supported a 256x192 artifact color mode, with blue and orange in addition to black and white. Many games used this mode due to the limitations of the direct color modes.  Essentially the graphics look very similar to the Apple II's HGR graphics, but are more limited due to the absence of any primary colors other than blue and orange.  The Color Computer 3 has far superior graphic capabilities, enough so that a nearly-perfect port of Donkey Kong was created for it.

Artifact color does not work with S-Video (which can be obtained from the Atari 800), as that connector separates the luminance and chrominance signals.  Artifact color relies on the demodulation of the combined luminance and chrominance signals.  You will see monochrome colored pixels with serrated graphics where color was intended if you use S-Video.

Artifact color was designed for NTSC-standard monitors.  No PAL home computer ever used it.  The Apple II Europlus does not output color without a special "PAL color card."  The Apple IIe have the PAL color card built in but the Apple IIc requires an external dongle to show color.  The video output is not as good as with an NTSC monitor.  There is no "PAL" CGA card.  The PAL Atari 8-bit machines would have treated the 320x192 as a strictly monochrome mode.  While the TRS-80 CoCo may not have been widely distributed in Europe, the Dragon 32/64 computers are very close cousins to it.  While it supports a 256x192 mode, it seems to be strictly black and white.  Compare the game "The Vortex Factor" for both systems.

Thursday, September 12, 2013

The Everdrive 64 - The only N64 Flashcart you will ever need

Continuing in my series profiling various flash cart devices, I turn to that incredible device known as the Everdrive 64.  This cartridge loads N64 ROMs off an SD card and lets you run just about every Nintendo 64 game on the Nintendo 64 game console as they were meant to be run.  No need for emulators of varying quality.  No need to hunt down expensive cartridges.

Nintendo 64 cartridges ranged in size from 4MB to 64MB.  They had various methods to save games, including 32KB or 128KB of battery-backed static RAM, a 4Kbit or 16Kbit EEPROM, or 128KB of Flash Memory. Some games did not allow games to be saved on the cartridge, instead you had to purchase and insert the Controller Pak into the port on the N64 controller to save a game.  There are games that can use both the internal saving cartridge hardware and a Controller Pak.  Additionally, five different lockout CIC chips were used in the cartridges, and the games expected the exact CIC chip in order to bypass their security check and play the game.  These are the CIC-6101, 6102, 6103, 6105 and 6106 chips (NTSC cartridges and machines) or 7102, 7101, 7103, 7105 and 7106 chips (PAL cartridges and machines).  A mostly-comprehensive list of the games and the CIC chips and the saving hardware they use is available here : http://n64.icequake.net/mirror/www.elitendo.com/n64/usa_boot_save_list.html

Making an all-encompassing Nintendo 64 flash cartridge is not an easy task.  Krikzz, a developer from the Ukraine, decided to make a cartridge that would eventually work with any game regardless of saving mechanism or lockout chip.  Thus the Everdrive 64 was born.

The Everdrive 64 has just been released with v3.  v1 does not support games using Flash RAM saving (Jet Force Gemini, Legend of Zelda : Majora's Mask, Megaman 64) without a firmware upgrade via a special programmer.  The v2 can update the firmware without needing a special programmer and loads faster, but the last firmware update was in 2011.  v2 is what I have and is identical, feature-wise to the current v2.5 version still being sold.

The SD card must be formatted in the FAT16 or FAT32 formats.  SDHC cards are supported, so you can easily put a 32GB SD card in the Everdrive 64 formatted with FAT32 in Windows 2000, XP, Vista, 7 & 8.  A folder called ED64 must be created in the root of the drive and the current OS file, OS64.v64, must be placed in it.  That is all that is required for the card to work.  An 8GB card should be sufficient to hold all the ROMs you would want to play.

Official Nintendo 64 ROMs need a CIC chip installed in the Everdrive 64 to work at all.  The most common CIC chip, by far, was the CIC-6102/7101.  A working CIC-6102 (NTSC models) or 7101 (PAL models) must be desoldered from a Nintendo 64 Game Pak and put in the socket inside the Everdrive 64.  The Everdrive 64 can now use the 6102 or 7101 to emulate all the other CIC chips, including the more advanced CIC-6105 chip.

Look here for the latest incompatibility list, as you can see it is a short list (nine games max) :

http://krikzz.com/forum/index.php?topic=147.0

Of course, to play all Nintendo 64 games (except as noted in the last paragraph), you will need the right peripherals.  This means you may need up to four Nintendo 64 Controllers, a Controller Pak for games that do not save to the cartridge (the Castlevania games for example), a Rumble Pak is recommended for games that support that feature (the Zelda games, Star Fox), the Expansion Pak to add more RAM to the system (Donkey Kong 64, Perfect Dark, Legend of Zelda : Majora's Mask, Banjo-Tooie), the Transfer Pak for the Pokemon Stadium games, and the VRU Voice Recognition Unit for Hey You, Pikachu!.

The Everdrive 64 will sort ROMs alphabetically and create save files automatically as a game would have saved its game to a cartridge.  However, you must press reset before turning the system off or the save will be lost!  v3 has a battery, so this will no longer be an issue.  The cartridge now supports Gameshark codes, but will not emulate a Controller Pak or support save states.  However, with the most recent OS it can switch Controller Pak save files in and out of the Pak.

I ordered my Everdrive 64 directly from Krikzz.  He had options to add a cartridge shell with a nicely cut slot for the SD card and a CIC-6102.  I highly recommend this cart, especially the new v3 version with a real time clock (Animal Crossing) and its socketed battery which eliminates the need to press reset to save a game.

Friday, August 23, 2013

The NES and the Powerpak - An Oldie but Goodie

Once upon a time, if you wanted to play a game on the Nintendo Entertainment System, you needed the cartridge of that game.  The idea of a flash, programmable or rewritable cartridge, either with a single game or a multi-cart, was something strictly in the domain of hackers and pirates.  Unlike other cartridge systems, where the internal hardware inside the cartridge rarely varied, there were enormous numbers of different cartridge hardware for the NES.  While the basic NES cartridge could support either 16KB or 32KB of game code (Program ROM) and 8KB of graphics tiles (Character ROM), anything beyond that required hardware to implement a bank switching scheme to allow the game to overcome those limits.

When a NES or Famicom cartridge uses extra hardware, that hardware is called a mapper.  With the Japanese Family Computer (Famicom), Nintendo created several methods, some using simple glue logic, others using custom application-specific integrated circuits (ASICs) which it termed Multi-Memory Controllers (MMCs).  It allowed its initial partners, Namco, Konami, Sunsoft, Irem, Bandai, Jaleco and Taito to make cartridges and whatever hardware they could put on them.  Later partners had to use Nintendo's boards almost without exception.  Some Famicom mappers supported additional sound channels.  Many games used battery backed static RAM (S-RAM) in the cartridge to save games, and a few used EEPROM to save.

When the Famicom came to the USA and became the NES, Nintendo implemented stricter controls over cartridge manufacture.  Almost without exception, it manufactured all cartridges and its partners had to use the hardware Nintendo offered or their game would not be released.  The number and variety of different mapping schemes was greatly reduced compared with the Japanese cartridges.  This situation carried over into Europe.  However, all versions of the NES added a lockout chip, one region for the US and Canada, a region for the U.K., Italy and Australia (PAL-A), a region for the rest of Europe (PAL-B), and even a region for short lived Hong Kong version of the NES.

Still, when unlicensed third parties entered the scene, they quickly devised their own mapping schemes, although sometimes their schemes function identically with a Nintendo mapper.  Unlicensed manufacturers were Tengen (began as a licensed third party), Camerica/Codemasters, Color Dreams/Wisdom Tree/AGCI/Bunch Games, SEI/American Video Entertainment, Racermate, Inc., Panesian, Caltron/Myriad and Active Enterprises.  These cartridges contain various methods to defeat the lockout chip in the NES.

In Japan the Famicom had an add-on peripheral called the Famicom Disk System.  This allowed the users to load games off special, 3" floppy disks into a special adapter cartridge containing 32KB and 8KB of RAM and an ASIC containing the logic and code necessary to control the disk drive and provide an extra sound channel.  Disks were much, much easier to manufacture than ROM cartridges and far cheaper to make. Nintendo considered releasing it in the west, but the disks did not have a great profit margin, were easy to pirate, not very reliable and the peripheral was not a smash success in Japan.  Because of all those issues it was never released overseas.  Still, several of Nintendo's classics like The Legend of Zelda, Zelda II: The Adventure of Link, Metroid, Kid Icarus, Super Mario Bros. 2 and Doki Doki Panic and Konami classics like the first two Castlevania games were released first for the Disk System.

The NES hardware found its way into the arcades.  The Playchoice-10 was an arcade machine that allowed people to play NES games for as long as they had quarters to buy time in the machine.  The games themselves were on PCBs that inserted into special slots on the arcade PCB, but the code was little changed from the consumer cartridge and can easily be run with the appropriate NES cartridge.  This was the only exposure The Goonies had in the West.  The Vs. System was an arcade machine dedicated to playing an adapted NES or Famicom game like Duck Hunt or Super Mario Bros.  The game would usually be more challenging for the arcades and often have some additional graphics.  The NES hardware would still be the basis for the game, however the games started via coin slots and multiple, incompatible PPU chips were used with the games.

Most licensed NES games use only a few mappers.  0, 1, 2, 3, 4 & 7 are the most popular.  5, 9, 13, 34 & 66, 69, 105, 118, 119 & 206 are also used by NES games, although often only one to five games may use a mapper.  Unlicensed NES games use several more mappers, including 11, 34, 41, 64, 68, 71, 79, 113, 144, 158, 168, 228 & 232

As anyone might observe, this dizzying array of hardware would have made anyone wary of trying to make a cartridge that could play multiple games as a multi-cart.  Early copiers are very obscure nowadays and never covered a complete variety of hardware.  Emulators began to be able to play a large number of games and the ability to dump games was focused on in the mid-to-late 90s.  Not until 2007 was a cartridge released that allowed people to play a wide variety of games on a real NES or Famicom.  That cartridge is called the NES PowerPak, and it revolutionized the way multi-carts were made for retro-systems.  It was released by RetroZone, which had previously offered USB converter kits and adapters for NES, SNES and Genesis controllers.

There had been multi-carts before, but they used odd methods to transmit games (the Atari 2600 Cuttle Cart required the game to be converted into an audio signal) or only had a fixed and relatively small amount of memory (Tototek) to hold games.  The PowerPak's chief innovation was to allow removable storage in the form of easily available Compact Flash cards to hold games.  Thus the number of games that the cartridge could access at any one time was only limited by the size of the card and the file system.  The result was that the whole NES library could easily be fit within a 1GB Compact Flash card.

The PowerPak required a second innovation to work particularly with the NES.  Since the NES contained so many mappers, few of which could co-exist with each other, each had to be emulated by the cartridge. Bunnyboy, the inventor of the cartridge, used a large Field Programmable Grid Array (FPGA) chip that would be programmed to emulate each game's mapper as they game loaded.  The FPGA is RAM based, so it can be reprogrammed long after you and I are dead, in theory.  Other programmable logic chips may be flash memory based and have a finite number of rewrite cycles.

I was a very early adopter of the NES PowerPak, and there were some growing pains with the device. Early cartridges required a resistor pack soldered to the data pins of the video bus to avoid graphical tile corruption. I had to send my cartridge back for the modification.  The mod instructions are here for anyone who has not had their early device modded : http://www.nespowerpak.com/powerpakmod.html  In the beginning some NES games did not read the joystick properly loaded from the PowerPak, and a BIOS update, which had to be done with a Flash Programmer, was needed to fix these games.

For Famicom users, the PowerPak will require a 72-to-60 pin connector, and they are hard to find.  You will also need to make sure that the converter does not tie pins 48 and 49 on the Famicom connector.  Many, many games do tie these pins together, but some games do not and the PowerPak needs them separated to work properly.  Also, you need to consider a housing for the converter to add stability to the setup.  The PowerPak must face the rear of the Famicom when inserted into the adapter.

The PowerPak can support the expansion audio of games that use VRC6, N163, Sunsoft-5B chips and the Famicom Disk System.  If using the cartridge on the Famicom with an adapter, a 10K resistor will need to be run from pin 54 on the NES side of the connector to pin 45 of the Famicom connector, and another 10K resistor needs to be run from pins 45 to 46 on the Famicom connector.  The resistor values may need to be changed for a Famicom AV, because those resistors make the system audio virtually inaudible on the AV unit.

To obtain expansion sound on a Front Loader NES, you will need to solder a 47K resistor from pin 3 to pin 9 of the expansion connector.  To obtain expansion sound on a Top Loader, you will need to solder a wire connecting pins 51 and 54 in the PowerPak.  Next you will need to solder a 1.2K resistor between pin 51 and the audio out pin on the NES PCB.  See here for details : http://forums.nesdev.com/viewtopic.php?f=9&t=7880&hilit=top+loader+expansion+audio

The PowerPak can have a bit of trouble with some Compact Flash cards.  I would use genuine Sandisk CF cards and they should not be especially fast.  There are fakes floating around, see here for more details : http://www.ebay.com/gds/FAKE-SanDisk-Extreme-Compact-Flash-Cards-Exposed-/10000000001456539/g.html

The card requires a set of files to be put in a PowerPak directory to instruct the cartridge how to program the FPGA for each mapper or feature.  Mapper support was a bit weak at first, but it eventually improved. Also, programmers other than Bunnyboy began making their own mappers to add features beyond the intended scope of the NES PowerPak like Famicom Disk System support.  This is how the PowerPak supports mapper 5 games, which use the most complex Nintendo MMC, MMC5 at all.

In my experience, the PowerPak requires mapper files from a few sources to ensure that almost every non-Famicom game will play correctly on it.  Here is my mapper mix :

Start with the lastrelease of the official PowerPak mappers, found here : http://www.retrousb.com/downloads/POWERPAK135b2.zip.  Place those mappers into a directory labeled POWERPAK in the root of your CF card.

Next download loopy's latest PowerPak mappers, found here : http://3dscapture.com/NES/powerpak_loopy.zip.  You will also need to download his mapper 5 file separately.  They will overwrite the older mapper files (also from loopy) from the official set.

The most frequent issue with games is that they have wrong or missing headers.  All NES ROMs require a 16-byte header (iNES) for emulators to make them work.  The actual ROM in a GoodSet or No-Intro set may be perfectly dumped, but information in the header may be wrong.  Pay close attention to the mapper number, the mirroring and the battery backed flag.  I used to see a warped racetrack for Mach Rider for years in emulators and I erroneously believed it to be due to poor emulation when it was due to the wrong mirroring being set in the header.  Super Cars has a similar issue.  The NES Cart Database will give the proper mapper, mirroring and battery backed memory settings for every US/European game.  Alien Syndrome and all the Mapper 206 games should be set to Mapper 4 for the PowerPak.

At this point, you may be able to enjoy fully glitch free NES games and many Famicom and Famicom Disk System games.  Some games, like Gimmick! and Akumajou Densetsu, (the original version of Castlevania III) use expansion sound that their NES ports cannot.  Famicom Disk System games need the 16-byte header before the disk code, the crucial byte informs the PowerPak how many sides the disk is supposed to have.  FDS image = 65,500 bytes, one sided disk; FDS image = 131,000 bytes, two sided disk.  (The mapper could have determined this easily enough by the file size alone).  The PowerPak does not support two disk games.

More information about the mappers the PowerPak supports can be found here : http://wiki.nesdev.com/w/index.php/PowerPak

Fixable Issues with Games

I had some issues with certain NES games after the PowerPak folder had been setup in this way.  Here are my solutions :

Mapper 4 Games (used by many, many games, best candidates are ) :

Crystalis
Mega Man 3
Kirby's Adventure
Startropics 1-2
Super Mario Bros. 3
Mickey's Adventures in Numberland

Issue : Portion of Screen Shakes uncontrollably

Solution : These games use the MMC3's IRQ Scanline Counter to change tilesets.  On real hardware you may notice one scanline flicker a bit before a status bar, this is normal.  However, the portion of the screen after the line should not shake (with the exception of some games like Zombie Nation).  On the robot master screen of Mega Man 3, the scanline counter should cause the top line of Shadow Man's box to flicker back and forth.  I found that the save state mappers from thefox, available here : http://kkfos.aspekt.fi/projects/nes/powerpak/save-state-mappers/  make the scanline counter behave in every game.  Thefox has save state mappers for Mappers 0, 1, 2, 3, 4, 7 and 69 (except for Japanese Gimmick!), which encompass 95% of all Licensed NES games.  Use v1.6 and turn off the save state support.  His later NES PowerMappers are not as accurate with the MMC3 scanline counter.

Four-Screen Mirroring Games :

Gauntlet
Rad Racer II

Issue : Tile Corruption or Wrong Tiles

Solution : The use of the save state mapper breaks these games.  Use MAP04.MAP from loopy's latest PowerPak mappers and rename the file to MAP06.MAP.  Set the mapper from 4 to 6 for both games in the ROM header.  I would recommend the Nintendulator emulator to change the mapper number in the ROM header. ROMs must have four screen mirroring set in the header for these games to work correctly.

Nintendo World Championships :

Issue : While the PowerPak supports this game, the official mapper does not support the dipswitches to change the time allowed for the game, and acts like no dipswitches are set, giving the player just over five minutes.  The official competition time was six minutes and twenty-one seconds.

Solution : Join Nintendoage.com, download the file MAP695.MAP attached to this thread http://nintendoage.com/forum/messageview.cfm?catid=8&threadid=97798, rename it to MAP69.MAP and overwrite the official MAP69.MAP.  This mapper file will give you the official competition competition time of six minutes and twenty-one seconds.

Broken, Buggy, Incomplete or Non-working Games :

Incomplete MMC5 Emulation : 

Bandit Kings of Ancient China - Severe Graphical Glitches due to incomplete MMC5 emulation
Uncharted Waters - Severe Graphical Glitches due to incomplete MMC5 emulation

No Mapper Support :

Racermate Challenge II
Super Mario Bros./Tetris/World Class Track Meet (PAL only)

Game Size :

Action 52 - PowerPak not big enough to fit a 1.5 Megabyte PRG-ROM, so most games will not work

CHR-ROM/CHR-RAM Conflicts:

All games are still playable :

Noah's Ark (Konami PAL only) - Background tiles corrupted
Addams Family, The - Pugsley's Scavenger Hunt - Extraneous lines on text and menu screens
Baseball Stars II - Extraneous lines and moderate graphical glitches on menu screens, game is playable
Bigfoot - Extraneous lines on title screen
Krusty's Fun House - Extraneous lines on text screens
Fisher Price - Perfect Fit - Garbled Graphics at times

Acclaim MMC3 Clone :

Mickey's Safari in Letterland (shaking status bar)

MMC3B/C Behavior :

Star Trek 25th Anniversary (glitches when character text boxes appear on screen)
Kid Klown in Night Mayor World/Mickey Mouse III: Yume Fuusen (glitches in warping effect when beginning first level)

PowerPak Menu and ROM Naming :

The PowerPak does not sort files alphabetically, it displays them as they were copied to the card.  A program called DriveSort, available here : http://www.anerty.net/software/file/DriveSort.php can be used to sort the files in a directory or subdirectory.  It does not sort files in subdirectories automatically, you have to enter each subdirectory and click on Sort.  The resulting sort may not be ideal for games that start with the same word like Super.  Due to the way long file names in FAT works, each title will be truncated to an 8.3 filename, and after the tenth game with the same first seven characters, the names start to get weird.  The result is that the sort will not work properly unless you rename the 8.3 names into something sortable.

The PowerPak menu uses an 8x8 pixel fixed width font within a 256x240 resolution.  30 lines of characters can be seen on the screen, but the TV bezel may totally or partially obscure the first and last line.  For cosmetic purposes, I place a dummy directory named ! so it gets obscured.  The menu will display 26 characters in a file name.  For a clean looking menu, I recommend shortening names whenever possible.  You can use abbreviations like Adv for Adventure and eliminate unnecessary portions of titles.  For sports games I usually shorten the title to the name of the athlete or organization and the type of game (basketball, baseball, etc.).  Arabic numerals should replace roman numerals.

The PowerPak does support battery backed S-RAM games which use the RAM for saving games.  There has to be a file with the exact same name as the ROM, with the extension .sav instead of .nes, in the SAVES subfolder of the POWERPAK folder.  The PowerPak has the capability to save to the appropriate file automatically.  However, the user cannot simply turn off the NES, he must hold the reset button down until the PowerPak menu reappears.  Later multicartridges from Krikzz will automatically create save files and keep the save if the user turns the console off.  All NES games use an 8KB S-RAM except for Romance of the Three Kingdoms II, which requires 32KB.  If using the save state mappers, the .sav file must be 32KB to save the game's state.

Competitors :

While the PowerPak is currently available for sale, there is a similar device for the NES and the Famicom made by Krikzz called the Everdrive N8.  It comes in a 60-pin version for the Famicom and a 72-pin version for the NES.  Its support for Famicom games is may be better than the PowerPak's,  It uses SD cards, which are more common nowadays than CF cards.  It has a save battery socket on the PCB, so you don't have to press reset to save a game.  Firmware updates do not require a reprogrammer, and more mappers have support for save states.  It even has enough MMC5 support to play Castlevania III, but not enough for other MMC5 games like the Koei games, Just Breed or Laser Invasion.  Among the few other NES ROMs it does not support is Nintendo World Championships, Action 52 and Cheetamen II and Maxi-15.  However, it is somewhat cheaper than the PowerPak.