The Atari 2600 Emulator FAQ --------------------------- Version 1.4 9/1/96 Copyright 1996, Dennis Brown (brownde@cs.unc.edu, http://www.cs.unc.edu/~brownde) except as attributed to other contributors This file is located at: http://www.cs.unc.edu/~brownde/museum/texts/2600emu.faq All trademarks are under ownership of their respective companies and are used without permission, yadda, yadda, yadda. Please don't sue me. ----------------- Info still needed ----------------- Regarding the Activision Action Packs: * HEY!!!! I only have access to Version 1 of the Action Pack. If you have more accurate information for the later versions for any of the topics in the FAQ, or for other useful topics, let me know and I'll include the information. Thanks. * Is there a debugger in the Mac version? How do you get to it? * How do you get to the Win95 debugger? Other stuff: * Am I missing any emulators???? ------------ Contributors ------------ Most of the contributors did so unknowingly by posting to the Usenet newsgroup rec.games.video.classic (r.g.v.c). If you're in here and want your contribution removed, e-mail me. Otherwise, thanks. * Mike Livesay (lti@earthlink.net), creator of the Activision Atari 2600 Action Pack for Windows 3.1 and Windows 95, posted several informative notes to r.g.v.c which are included here. * Ed Federmeyer (ed@iitmax.acc.iit.edu) explained on rec.games.video.classic how to use any ROM image with the debugger. * Lee K. Seitz (lkseitz@iquest.com) saved Mike's and Ed's posts and put them on his video games pages (http://iquest.com/~lkseitz/videogames/). * Eckhard Stolberg (2stolber@informatik.uni-hamburg.de) posted on r.g.v.c about the settings in the .INI files. * Pete Rittwage (bushwick@ix.netcom.com) posted on r.g.v.c about a possibility of a debugger in the Win95 version. * Ray Wilmott (rwilmott@mars.superlink.net) posted on r.g.v.c about how to use alternate ROM images with the Mac version of the emulator. * Dan Perttula (souvenir@grfn.org)--using alternate images with the Win95 Action Pack. * Alex Hornby (W.A.Hornby@dcs.warwick.ac.uk) created the x2600 emulator. * Adam Roach (adam@why.net) created the Atari 2600 Emulation Project. * CJayC (cjayc@flex.net) contributed more information about using alternate ROM images. * Howard Uman (howieu@nmaa.org)--Atari Action Pack Image Commander * Bradford Mott (bwmott@eos.ncsu.edu)--Stella 96 emulator * Paul Robson (autismuk@aol.com)--A26 emulator -------------- Update History -------------- 08/30/96 - Added section V (A26 emulator) 07/26/96 - Added section IV (Stella 96 emulator) 06/05/96 - Added section I.C.1.a (utilities for using images) 05/02/96 - Added more information to I.C.1 (using alternate images) 04/03/96 - Added III.A. 04/02/96 - Added this section (Update History), I.A.10, and II.A. 03/28/96 - Created the FAQ. -------- Contents -------- I. The Activision Atari 2600 Action Pack for Win3.1, Win95, and MacOS A. Background Information 1. Who wrote the Atari 2600 Action Pack Emulator for Win3.1 and Win95? 2. What languages were used to create the Win3.1 emulator? 3. Why does the emulator need a 486? 4. Why does the emulator run slowly on low-end (486/25 and down) systems? 5. What was hard about emulating the 2600's hardware? 6. Why Windows instead of DOS? 7. What is the ideal system for Action Pack? 8. Are there any bugs in the emulator? 9. I want to play Pitfall II! Why isn't it in any Packs? 10. What games come in each Action Pack? B. Tweaking the Emulator 1. How do I change collision detection? (Win3.1, Win95) 2. How do I invoke the debugger? (Win3.1) 3. What do all of the settings in the game .INI files do? (Win3.1, Win95) C. Using the Emulator with other Atari 2600 ROM images 1. How do I use any ROM image with the Win3.1 and Win95 emulators? a. What utilities make this easier? 2. How do I use any ROM image with the Mac emulator? 3. Where do I get ROM images? 4. Why won't some images work? II. Virtual 2600 by Alex Hornby (was x2600) A. Background Information III. Atari 2600 Emulation Project by Adam Roach A. Background Information IV. Stella 96 by Bradford Mott A. Background Information V. A26 by Paul Robson A. Background Information --------------------------------------------------------------------- I. The Activision Atari 2600 Action Pack for Win3.1, Win95, and MacOS --------------------------------------------------------------------- ------------------------- A. Background Information ------------------------- 1. Who wrote the Atari 2600 Action Pack Emulator for Win3.1 and Win95? ---------------------------------------------------------------------- Posted to the Usenet newsgroup rec.games.video.classic by Mike Livesay: By way of introduction, I'm Mike Livesay, a game developer/programmer for the past 15 years. Past work includes Miner2049er, Arcade Game Construction Set, The Heist, It Came From The Desert, etc, etc. Other software-related interests include video compression, color quantization, and image processing. I began development on Action Pack in June '94, just shipped Volume I (as you know), and am in the process of finishing additional volumes. Action Pack, while certainly not huge project like DOOM, was a fun technology project and a nice detour into my youth and the early days of video gaming, when the 6502 was king and cart ROMs were measured in 1,000 (not millions) of bits. Action Pack was not only my first commercial PC/Windows product, but also my first experience with 486 assembly coding. I've spent most of my time on game console programming, usually in 68K, 6502, or Z80 ASM. The last time I had done x86 programming was when the 8088 was first released and before the IBM PC hit the market (back when the Apple II was king)! 2. What languages were used to create the Win3.1 and Win95 emulators? ---------------------------------------------------------------------- >From Mike Livesay: 90% 486 assembly and 10% C, using Borland Turbo C++ and Turbo ASM. The Pack was written almost entirely in 486 assembly using Borland's Turbo Assembler. The GUI stuff was written in C++ (no OOP extensions used, though - not really necessary) using Borland Turbo C++ 4.0. All of the emulation stuff was written in 486ASM. I didn't want to have to rely on Win32 DLLs, so everything was written assuming a 486 Win16 target system. However, 32-bit 486 instructions are used all over the place in the emulator, especially in the line rendering code. There have been some comments that the Pack may have written in BASIC (wince). Sorry, but even C would be too slow to implement a 2600 emulator. Assembly was the only realistic option. I've heard some folks discussing the possibility of writing an 2600 emulator in a high level language - forget it, not possible. 3. Why does the emulator need a 486? ------------------------------------ >From Mike Livesay: Two reasons: Speed and the BSWAP instruction. Most 486 instructions execute in one cycle (assuming no cache hits), which was a saving grace for the emulator. The BSWAP instruction, which executes in one cycle, was a life saver during pixel rendering in the TIA emulator. I won't bore you with details, but it really came in handy. 4. Why does the emulator run slowly on low-end (486/25 and down) systems? (i.e., Why does a 1MHz 6502-based VCS emulator need a 486/33 minimum system?) ----------------------------------------------------------------------------- >From Mike Livesay: There are a number of reasons, but I'll name the two main ones. First, the emulator has to do much more than just emulate a 6507 CPU. It also has to emulate VCS sound and graphics hardware, which is quite involved. Not to mention that, in order to run at full speed, it has to emulate the 6507 code, along with the sound/graphics functions, at a very high rate, like 320,000 emulated instructions per second! Secondly, the line-oriented nature of the VCS graphics hardware causes a whole lot of processing to be done on every scan line. On emulaters with sprite-oriented displays, like the the Genesis or the C64, when a sprite is plotted very little processing has to be done to render each line of the sprite. On the VCS, collision detection, graphics, color, etc are modified on at line, sometimes even multiple time during a line. This creates a whole lot of overhead for the emulator. Not to mention the fact that there are no X/Y position registers; the position of a single line sprite is determined by position the TV beam is currently at when a write to a certain TIA register occurs, in REAL TIME. This creates the necessity to count the actual number of cycles each CPU instruction takes as the game code is executing. (side note: very few VCSgames do a WSYNC at each line - this would have made life much easier, but life in game programmer is seldon easy!) More from Mike Livesay: Action Pack makes use of the Micro$ofts's WinG DLL, which actually works fairly well. However, due to the fact that I wanted the games to run in both normal (320x200) and maximized (640x400) windows, it was necessary to write some pretty tricky code that makes WinG only update regions that have changed from frame to frame. The original 2600 screen resolution was 160x200 (the number of active lines depends on the game), so even in the normal window size, the emulator is doubling the pixels horizontally. Even at 15fps, Action Pack pumps a whole lot of pixels to the screen, especially in a maximized window. However, when I last profiled the emulator, WinG updates were only eating up 10% of the CPU on each displayed frame on a P90. In order to keep game play responsive, the emulator must emulate each frame (actually, NTSC field) in 1/60th of a second or less (16ms). Unfortunately, on all but the highest end, PCI/VLB video cards, it is impossible to update even a 320x200 window at 60 frames/sec. So the emulator runs the game code at full speed, while refreshing the display at some user assignable interval (usually every 4th frame, or 15fps). 5. What was hard about emulating the 2600's hardware? ----------------------------------------------------- >From Mike Livesay: The emulator consists of two major pieces of code: a TIA emulator and a 6507 (6502) CPU emulator. The two are pretty intimate with one another, since it is necessary to count the number of CPU cycles that have executed between TIA register writes to keep everything in sync. The TIA emulator ended up working as sort of a state machine and only gets activated when a TIA register is accessed and changes, and at the end of each line, when the pixels are actually created. Mid-scanline register changes and collision register reads are supported, which was a major programming pain. Many games do things like change the color registers. VCS sound emulation was a painful exercise, mainly due to the fact that Windows doesn't support the Adlib very well (there is no support for loading custom timbres) and the multimedia low level audio API is not supported robustly by all sound card drivers. The sound API was designed mainly to play back short samples in a linear fashion with a known duration. Since the emulator knows nothing about the sound effects in an emulated game, it needs to play back very short, looped waveforms. I experimented with sampling all waveforms at all frequencies, and wrote something similar to WAVEMIX.DLL, which worked, but not fast enough, due to the fact that the loop rate had to be kept down to 250ms or less (otherwise, one would need a huge amount of memory to store all the samples). The final workable solution I came up with is that all VCS waveforms, except noise, are emulated using FM. The noise sample are played back using PCM, and only once noise sample at a time can play. The noise samples were created by actually sampling the output of a VCS, at each frequency setting. Note that VCS games that use noise extensively, like River Raid and Kaboom!, tend to run a bit slower, depending on the PCM sound driver being used. All FM access was done at the register level - I had to bypass the MIDI interface stuff. 6. Why Windows instead of DOS? ------------------------------ >From Mike Livesay: Wasn't really my decision, but I think it was the correct one on Activision's part. There is a lot of demand for Windows-based games at this time. The only real competition is MS Arcade, which has been out for a while. Under DOS, Action Pack would be competing with raycasting-based games like Doom, Dark Forces, etc, which are certainly much flashier and are at the leading edge of the industry, technically speaking. Action Pack was never intended to push the envelope (although, it certainly was not a walk in the park to code) or compete with such games. Its a retro/nostalgia kind of thing. Also, going to DOS would only have speed things up by 10..20%, not a real major gain. I definately agree that Windows has its downside, but Action Pack was well suited for the platform. 7. What is the ideal system for Action Pack? -------------------------------------------- >From Mike Livesay: A 486/66 with a fast (VLB/PCI) video card, reasonable amount of cache memory (256K) and a Pro Audio Spectum 16 (or compatible) with the latest sound drivers. Best display mode is 640x480, 256 colors. NOTE: you must run Action Pack in 256-color mode, or things will look weird and run slow. 8. Are there any bugs in the emulator? -------------------------------------- >From Mike Livesay: ... the emulator DOES actually emulate the play control register and the graphics flipping. The areas where things can get shaky is on games that do strange stuff like write to the TIA via the stack, which causes me to do extra checking every time a stack operation occurs and makes for slower emulations. I disabled this feature and three or four games (like Demon Attack) had trouble. I made the decision to remove the stack I/O games from the first list and have since made more speed improvements that should cover the extra cycles consumed by those games. The other area the the emulator may have trouble with is games that do multiple mid-line things (ie: horizontal multiplexing). The emulator will do this kind of stuff in most cases, but not all. For example, the emulator does support mid line collision checking and resets, which games like Freeway do all over the place. I have to say that that feature was one of the major programming bitches I had to deal with. 9. I want to play Pitfall II! Why isn't it in any Packs? -------------------------------------------------------- >From Mike Livesay: "Pitfall II was impossible to emulate, due to the fact that it has custom hardware in the cartridge." This hardware enhances the 2600's audio (notice that Pitfall II has three voices plus a noise track throughout the game, while the 2600 only supports two sound channels natively). [For more information on other incompatiblities, see section I.C.4.] 10. What games come in each Action Pack? ---------------------------------------- * Pack 1: Pitfall!, Kaboom!, River Raid, H.E.R.O, Chopper Command, Grand Prix, Boxing, Cosmic Commuter, Crackpots, Fishing Derby, Freeway, Frostbite, Seaquest, Sky Jinks, and Spider Fighter. * Pack 2: Dragster, Skiing, Tennis, Laser Blast, Stampede, Ice Hockey, Barnstorming, Megamania, Oink!, Dolphin, Keystone Kapers, Enduro, Plaque Attack, River Raid II, and Atlantis. * Pack 3: Checkers, Starmaster, Pressure Cooker, Private Eye, Double Dragon, Combat, Space War, Canyon Bomber, Breakout, Night Driver, Yar's Revenge, and Title Match Pro Wrestling. Two more Packs are planned, though the games are not yet known. ------------------------ B. Tweaking the Emulator ------------------------ 1. How do I change collision detection? (Win3.1, Win95) --------------------------------------- >From Mike Livesay: The collision detection "softness" is not a bug, but is actually an adjustable parameter in each game's INI file, called "ActiveLineMask". Each game has an INI file associated with it, which is editable using notepad or any text editor. To get 100% accurate collision detection, set the parameter to 0; ie: ActiveLineMask=0 This parameter controls the line interleave that the emulator uses when checking collisions. The reason for this parameter is that I was concerned about always checking every line on all games on slow systems (ie: 486/25) as collision checking it a definate cycle eater and it isn't really necessary on every line in most games. If you have a reasonably fast system (486/66), you should be able to set this parameter to 0, which causes the emulator to check collisions on every line. If you want to play with the parameter, here is how it works: The value in ActiveLineMask must always be power's of 2 minus one, ie: (1, 3, 7, 15, 31, etc). If set to 31, then one line in 32 is checked each field (the line checked is not the same line each field - it is bumped within the 32-line range each field. Large values will increase both the execution speed and collision softness of most games, depending on how large objects are, how often the game polls the collision registers, etc. 1a. What utilities make this easier? ---------------------------------- >From Howard Uman: Basically, I've written what I call the "Atari Action Pack Image Commander". It works with the Activision Action Pack and allows you to manage your cartridge images very easily. Currently, it's available for Win95 and it's tested using Action Packs for Win3.1. I don't have Action Pack #3 to test it with. It provides users with a menu of all cartridges, allows the user to configure cartridges and automatically saves the settings for that game. If an image doesn't work with the emulator, it allows you to block that image out without deleting the image (so maybe some other emulator will come along and work with that image). It handles copying the image into an appropriate size as well. I'll be working on a Win3.1 version soon. Users interested in it can write me via email at howieu@nmaa.org. [As of this writing, Howie is looking for a place on-line (web/ftp site) to put his program--if you can provide a spot, let him know.] 2. How do I invoke the debugger? (Win3.1, Win95) -------------------------------- 2a. How do I invoke the debugger for the Win3.1 version? -------------------------------------------------------- >From Mike Livesay: In the ActPack directory (where everthing is placed from the setup program), there is a file called 2600EMU.EXE. Run this EXE file - The program will come up with a "DEBUG" pull down item on the menu bar. There are a number of choices under "Debug", but the only one that is active is the "Debug65.." item. Selecting this item will bring up my 6507 symbolic debugger, which allows you to single step, change registers, generate interrupts, examine memory, etc. NOTE: The above only works on "Pitfall" with Pack 1. Ed Federmeyer explains how to use the Action Pack (version 1) with any ROM image: After playing with it a bit I've found the following: 1) You can copy 2600emu.exe to debug_x.exe (for example). Use a HEX editor on debug.exe to change "PITFALL.BIN" to "DEBUG_X.BIN" (again, for example) Create a new program icon in Windows to run the new debug_x.exe. Now, when you run the debug_x.exe, It will give you the "debug" pulldown menu, and load DEBUG_X.BIN instead of PITFALL.BIN. Note: If there is an easier way to load your own binary image instead of PITFALL.BIN, please let me know! My Debug/Open Cart Image... pulldown menu doesn't do anything! 2) To create debug_x.bin, use your favorite 6502 cross assembler to assemble your test-2600 code. You might need a utility of some kind to convert the OBJECT file produced by the assembler into a raw BINARY image, suitable for burning into a 4K EPROM. (This kind of utility would probably come with an EPROM burner, but maybe there is something out there you can use???) Once you have a 4Kb EPROM image, copy it four times!!! Ie: COPY /B test.bin + test.bin + test.bin + test.bin debug_x.bin (Notice that all the .BIN files that come with the program are 16K!) Now you can step through your code, set breakpoints, etc. When you run your debug_x.exe, it will create a debug_x.ini with some minimal default values. You can look at the other *.ini files to get an idea of the other setup values you can play with. 2b. How do I invoke the debugger for the Win95 version? -------------------------------------------------------- >From Pete Rittwage: It's there in the Win95 version. I have no idea how to activate it but I can see the resources in a dump of the file. I've tried every key stroke I can think of to no avail. Maybe it's triggered by a line in the .INI files? I've tried some obvious ones and it hasn't worked either. [Lee K. Seitz then mentions the file 2600EMU.EXE and the Win3.1 steps] There is only one file now, actpack.exe. Once you run it, it lets you choose which game to run by clicking on a picture of it's original box. The .BIN files are still there, though. 3. What do all of the settings in the game .INI files do? (Win3.1, Win95) --------------------------------------------------------- >From Eckhard Stolberg and Dennis Brown: [controllers] Pad0=Mouse Pad1=Joy1 Pad2=Kybd2 Pad3=Kybd3 Joy0=Kybd1 Joy1=Off ;These settings describe which paddle and joystick are emulated by wich ;PC input device. They can be changed in the setup dialog in the game. ControllerMode=paddle ;Here you choose the controller for the game (paddle or joystick). PadMin=10 PadMax=60 ;If you choose paddle as the controller type you have to set these two. ;They hold the values the paddle gives when turned fully to the left ;and right. In the game the values are messured by a counting loop, ;so the settings might differ from game to game. PadKeyScale=5 ;This one was first used in Action Pack 3 and I don't think AP1 knows it. [display] PALmode=false ;Here you can say if you are using a PAL-ROM or a NTSC-ROM. FrameInterval=1 ;This is the ratio of actual frames to displayed frames. In this case, the ;system shows every frame the 2600 would. For many computers, this is too slow. ;The value 2 works best on my 486/66 with VLB, which means that I only see ;every other screen update compared to a real 2600. This can be changed ;with a slider in the settings dialog. ;IMPORTANT! This setting *must* be 1 for certain games (like Pac-Man) ;to play properly (for example, in Pac-Man, if the value is above 1, ;you'll only see two ghosts--the other two are displayed on the frames ;that the emulator doesn't display! ActiveLineMask=0 ;enables "exact" collision detection (see the explanation in I.B.1) CollLineStart=0 ;enables collision detection from row 0 ... CollLineEnd=199 ;... to row 199 (whole screen). The only reason the above numbers would be more ;limited (less exact or smaller area of the screen) is for slower PCs. DispXStart=0 ;which horizontal pixel (0-160) to start the display on DispYStart=0 ;which vertical line (0-[see below]) to start the display on DispWidth=160 ;width of lines in pixels DispHeight=237 ;height of screen in lines ;The 2600 has 262 lines per frame but needs about 40 for the ;vertical blanking. That leaves 222 lines to display, although ;most games use only 192 lines for speed reasons. ;For PAL games that is 312 lines and 48 for the vblank giving ;264 lines max and 228 lines normal. ;Some games won't work if the values aren't within a certain range. [sound] VolumeOffset=0 ;Change it in the settings dialog. [misc] ROMimage=breakout.bin GameName=Breakout ;These should be self-explanatory. InitCartBank=0x1FF8 MinCartBankTrig=0x1FF8 MaxCartBankTrig=0x1FF9 ;Again some that were first used by AP3 and won't do anything in AP1. ;They are for games that are bigger than 4KB. As the ATARI can only ;use 4KB of ROM bigger games have to switch ROM banks. The settings ;tell the emulator how to do it and which bank to use first. They may ;be different for different types of cartridges. InitialVBlanks=80 ;Another setting that hasn't any effect in AP1 either. It tells the ;emulator to wait for 80 pixelclocks before starting the display. ;If you play BREAKOUT from AP3 with AP1 you'll see that the whole ;display is shifted half a screen (80 pixels) to the side. [CONSOLE] LEFTDIF=A RIGHTDIF=A TVTYPE=COLOR ;These settings hold the difficulty and colormode switches from the ;ATARI console. You'll find them in the settings dialog. ------------------------------------------------------ C. Using the Emulator with other Atari 2600 ROM images ------------------------------------------------------ 1. How do I use any ROM image with the Win3.1 and Win95 emulators? ------------------------------------------------------------------ 1. First of all, the Win3.1 and Win95 versions require that all ROM images, regardless of initial size, be 16KB. If the ROM image you want to use is less than 16k, you must "pad" it so that it is 16k. It doesn't matter what goes into the padding. The "quick and dirty" way to pad a file is to concatenate copies of the file into a separate large file. For example, if you want to play the 4k Pac-Man on the emulator: COPY /B PACMAN.BIN+PACMAN.BIN+PACMAN.BIN+PACMAN.BIN PLAYME.BIN where you would use PLAYME.BIN with the emulator. For 2k games, you make a file with 8 copies. 2 copies for 8k games. NOTE: You can also use the program CART.EXE in Pete Rittwage's 2600 Development Software package to read in .BIN files and write them out in the 16k format the Action Pack wants. The software is on his page at http://www.io.com/~kgk/pete/2600.htm 2. Rename this image with the same name as an image that came with the emulator, and then click on the icon for the old game. Make sure to edit the associated .INI file as necessary, and to make backups of the original .BIN files first! If you have Windows 95, Dan Perttula gives this method for using alternate ROM images: "It is possible to play other images without overwriting your existing ones. In the ACTPACK.INI file you'll see GAME0=Boxing, GAME1=Chopper, etc. entries. Unfortunately, just changing an entry to GAME0=Combat won't work in the Win95 version. Your alternate cart must have an entry in the the Win95 System Registery (specifically HKEY_LOCAL_MACHINE\Software\Activision\ActionPack\Vol1). There are many ways to do this (messing with registry, rerunning the install, etc.)." CJayC gives another method: 2600emu.exe is the actual emulator program, and it can be called very simply with the following (using the Windows "Run" command): 2600emu gamename This launches gamename.bin with the emulator. It's that easy! If a gamename.ini exists, it is used as the initialization file. If not, a default one is generated (that does work with a lot of games, I have found). 2. How do I use any ROM image with the Mac emulator? ---------------------------------------------------- >From Ray Wilmott: It's Simple! 1. Open the ROM image with TeachText or SimpleText 2. Select All (cmd-A), Copy (cmd-C) 3. Open a copy of any "Activision Action Pack" game application with ResEdit. 4. Open up the "Cart" resource, and then "ID 128". 5. Click anywhere in the right-hand column of data (ie - the ASCII data). Select all (cmd-A). Paste (cmd-V). 6. Close the window. Save the file. 7. Double-click that ActionPack game and enjoy playing the new ROM. I've tried lots of ROM images so far. I guestimate about 75% work fine. Of the remaining 25%, some crash, some run but the controls don't work properly. BTW, you may hear about the need to "quadruple up" ROM images because the emulator needs all images to be 16k in size. That's apparently only true for the Windoze version. On the Mac version you can paste 2k, 4k, 8k and 16k cart images "as is" into the Cart resource and have it work fine. 3. Where do I get ROM images? ----------------------------- You dump them from your own personal collection into your computer using a cart reader, of course! Although I suppose it would be just as legal to obtain images of games you already own that were dumped by someone else, making these images available to the general public is, for most if not all games, illegal, so no sites carrying images will be listed here. [Unofficially, if you look hard enough, you'll find them.] 4. Why won't some images work? ------------------------------ * possible bugs in the emulator * 8k-and-larger images use a technique called bank-switching to get around the 2600's inherent 4k ROM limit. Different manufacturers used different techniques! The 8k-and-up Parker Brothers images won't work with the emulator version 1--later versions have more flexible bank switching. The Activision images mostly *will* work with the emulator. In version 3 of the Action Pack, the way bank switching is handled can be changed (see I.B.3). * Any images larger than 16k (like "Road Runner") won't work. * Any games using special on-cart hardware (like Pitfall II's sound chip or Tunnel Runner's extra RAM) won't work. --------------------------------------------------------------------- II. Virtual 2600 by Alex Hornby (was X2600) --------------------------------------------------------------------- ------------------------- A. Background Information ------------------------- >From Alex's page: Virtual 2600 is an emulation of the Atari 2600 game console that currently runs on UN*X/X11, SVGAlib and DOS. Virtual 2600 was formerly known as X2600, and has been renamed as it is no longer restricted to X11. It has a homepage at http://www.users.zetnet.co.uk/ahornby/v2600.html Beta 2 source has been released, along with binaries for Linux. --------------------------------------------------------------------- III. Atari 2600 Emulation Project by Adam Roach --------------------------------------------------------------------- ------------------------- A. Background Information ------------------------- The Atari 2600 Emulation Project (subject to renaming) is not yet ready for any sort of release, but you can find out more about it at http://www.why.net/home/adam/2600/ --------------------------------------------------------------------- IV. Stella 96 by Bradford Mott --------------------------------------------------------------------- ------------------------- A. Background Information ------------------------- Stella 96 is a portable emulator of the old Atari 2600 video-game console written in C++. It is a work-in-progress and should be consider BETA level software. However, you can play most Atari 2600 games with this release. Version 0.3 is the latest distribution, though 0.4 is due soon which claims many improvements over 0.3 involving speed, error handling, and support for X. Distributions are available for Linux, MS-DOS, Power Mac, and Win95/NT. Source code for Unix platforms is also available (compile-it-yourself). The Stella 96 distributions can be obtained from the Stella 96 home page at: http://www4.ncsu.edu/~bwmott/www/2600 --------------------------------------------------------------------- V. A26 by Paul Robson --------------------------------------------------------------------- ------------------------- A. Background Information ------------------------- Paul describes his emulator as "the quick DOS only version." It is currently in the beta stage. The whole emulator, zipped, is only 12k, yet it contains many features listed on the WWW page. It can be obtained from: http://users.aol.com/autismuk/a26home.htm