When playing classic video games on non-original hardware, one should always be conscious for the amount of extra lag that method may offer over the original hardware. Along with accuracy, latency is one of the most important tangible benefits (versus of using original hardware and display technology (CRTs) over emulators and current display technology (LCDs). Latency has always existed in some form, and in this article I will give an overview on how latency has evolved over time.
Additionally, the use of FPGA chips to simulate original hardware has become increasingly popular over the past five years. FPGAs can offer the benefit of lower latency compared to traditional software based emulation and can offer a high degree of accuracy by using relatively inexpensive hardware. FPGAs are not without their singular issues, and in this article I will go over some of the issues with using FPGAs as a replacement for original hardware.
In the IBM PC world, there is no such thing as "single density" floppy drives. Floppy drives started out as double density and later matured into high density and even extra high density. Those of us who grew up in a PC world had no need to know about "single density". But where did single density come from and which systems used it? Moreover, what happens when system builders try to stretch single density reading into double-density capacities? The truth is a bit more complex than you might think.
I wrote an article about the IBM JX (note no "PC" in the computer's name) five years ago. Much of that article was subject to speculation due to the lack of hard information about the IBM JX. A significant portion of that article had out-of-date information, so with the help of a site dedicated to the IBM JX and two Youtube videos really showing the system off for the first time, I have rewritten that old article (except for the following paragraph) entirely.
In 1985, IBM released a computer in Japan, Australia and New Zealand called the IBM JX, Model 5511. Essentially it was an upgraded PCjr., and in some respects what the PCjr. should have been. In fact, upon rumors of the JX making it to the United States, at least one commentator dubbed it the PCjr. 2. Released in 1985, just as the PCjr. was being discontinued, it proved to be the last machine by IBM with any substantial PCjr. compatibility. However, it was not successful anywhere it was released and consequently is extremely obscure today.
The need for proper preservation of floppy-based software cannot be understated. Floppy disks were not designed to store data for forty plus years, but for the oldest home computer systems like the Apple II, most of its software is at least thirty years old. But it is not preservation merely to dump a copy of a game which was pirated in the day. Those games usually have "cracktros" which do not represent the developer's intended presentation of the game, may have cut out elements of the original game to save space or may include corrupt data in them. Ideally one should have a proper image of original disks with all data preserved. Of course, from almost the earliest days of the Apple II's Disk II drive, copy protection schemes were implemented on commercial software to prevent casual disk copying. True preservation requires preserving them as well, and that requires emulation to become more accurate than it needed to be for just sector based .dsk images. In this blog article I will describe in as much detail as I can how the Disk II Floppy Drive works, how it is different from floppy drives for other systems, how data is stored on disk, the benefits of the .woz format and how .woz images are made.
In the last blog entry I focused on the basics of how to get an Apple //e up and running. In this entry I am going to focus on some of the more advanced issues that users may encounter with running software, programs and hardware on an Apple //e.
The Atari 2600 had a rather conventional design by later home computer standards. It's CPU, the 6507, had an 8-bit data bus and a 13-bit addressing bus. Whatever it did, it did in multiples of 8-bits, which has become the accepted standard for computer design. But its' main competitor, the Mattel Intellivision, has a memory architecture remarkably more complex than its older rival as well as many successive home consoles. Even most later 16-bit systems do everything in 8-bit, 16-bit, 24-bit etc. It is important for anyone wanting to get into Intellivision to understand why it is different. In this short blog post, I will try to explain those differences.
Reproductions of NES games are nothing new, people have been making them and selling them illegally for years. Recently the retro gaming market has shown such strength and durability that legitimate companies have felt there was sufficient interest in making new copies of original games. These games would come packaged as "Anniversary Editions" or "Collector's Editions" and come in packaging and with extras that would easily eclipse the original game's. This of course requires contacting the rights holder and negotiating for permission to release more copies of their game. Recently, the relatively uncommon but well-regarded NES game Metal Storm received a release from retro-bit and I had the chance for it to come into my possession, so let me use this blog entry to review the game and explain why I had the opportunity to briefly handle it.
I have often in conversation referred to retro-bit as one of the "Four Horsemen of the Retro-Gaming Apocalypse", one of four well-known companies (Hyperkin, atgames and Gamerz-Tek) that have consistently released garbage retro video game products over the years. They are hardly alone among lousy retro gaming product makers, but they are the most prominent. Hyperkin can put out a decent controller, so I guess it has graduated, just barely, from the "Horsemen". Can retro-bit do the same with its release of Metal Storm? Let's find out.
Prior to the NES, most controllers had a joystick and one or two buttons. The Atari joystick was wired in parallel, where one wire corresponded to one button, and pressing a direction or a button completed a circuit with the common (ground wire). The program would read these button presses in parallel, where reading from a single memory location would give the state of each of the five buttons at one time.
Nintendo's controllers were to come with a D-pad and four buttons. These were originally hard-wired in the Famicom but would have required at least nine wires if wired by the traditional parallel standard. Moreover, if they wanted to use other kinds of peripherals, they may have found that difficult. To cut down on wires, Nintendo decided to use a serial method for reading buttons. This also allowed for more varied expansion, as will be discussed below.
Truly nothing like the Game Boy had ever been seen before by the general public when it was released in 1989. Handheld gaming prior to that was confined to simple, single hand-held games like the Coleco mini-Arcades, the Nintendo Game and Watch series and the ubiquitous Tiger Electronics Hand-helds. These were simple games that were driven by pre-programmed microcontroller chips and drove an LCD display that was only capable of displaying a series of fixed patterns. Although the patterns could have a high level of detail, the limitations of the display severely limited the complexity and longevity of these games.
The Game Boy's best-known predecessor, the Milton Bradley Microsivion, used a 16x16 display. The Microvision was not very successful and its games were put on pre-programmed microcontrollers that plugged into the main unit. These microcontrollers operated at a very low speed of 100KHz, and provided only 64 bytes of RAM and 1-2KB of ROM for a game. The low resolution of the display also placed severe limitations on the games that could be made for this system. The Epoch Game Pocket Computer was released in Japan in 1984 and used a 75x64 resolution display, but it was not very successful and only had five games released for it.
Bankswitching in cartridge based games is most famous on the NES, especially its Japanese version, the Famicom. The NES, Famicom and their unofficial clones were popular in many parts of the world, but the inherent limitations of its 8-bit CPU required software developers to devise ever more complicated systems to increase the amount of memory the system could address.
But the NES did not invent bankswitching. Most, but not all, 8-bit home consoles, home computers and handheld systems had cartridges with extra hardware to allow the system to address more memory. In this article I will trace the evolution of that hardware outside the NES and give links to sites and documents where the user can find more technical information.
Blu-ray disc may not have been as successful as DVDs, but its capabilities have allowed it to embrace and do some justice to unusual film formats. Let's discuss some of them. For screenshots, I will refer the reader to the Blu-ray.com article with the appropriate links (when available), which has excellent, multiple full-HD screenshots for most of the films I will be discussing here. All Blu-ray covers are taken from Amazon.com or Amazon.co.uk with one exception noted below.
Classic color NTSC uses a frame rate of 59.94 However, classic video game consoles and home computers never adhered strictly to the NTSC standard. Here are the exact frame rates as I have been able to find :
NES & SNES : 60.0988
GB, GBC & GBA : 59.7275
SGB : 61.1679
SGB2 : 60.0988
Apple II, Atari 2600, Colecovision, IBM CGA, PCjr., Tandy 1000, EGA @ 200, MSX, SMS & Genesis : 59.9275
Commodore 64 = 59.862
Hercules Graphics : 50.050048
IBM VGA : 70.086303
IBM VGA 640x480 : 59.940475
As we all know theatrical sound film releases are typically projected at 24 or 25 frames per second. Film is a progressive medium where each film frame captures an image at a discrete point in time. However, film must be developed before it can be exhibited and must handled by experienced technicians, making it a costly medium in which to produce artistic works. To reduce flicker, a shutter in the camera would open or close twice for each frame.
Prior to the advent of television, celluloid film was the only commercial means to display visual moving images. However, the introduction of wholly-electronic television broadcast and receiver systems meant a massive change. TV broadcast cameras were able to achieve acceptable image quality by broadcasting images in an interlaced format. A broadcast camera and a TV tube display images in a set number of lines, and the electron scanning beam inside the tube scans or displays each line sequentially, then returns and draws the next line. (Think of a typewriter.) When it gets to the bottom of the tube, it returns to the top of the tube and draws the next set of lines.
In order to allow the electron beam sufficient time to draw all the lines, interlacing was used. In an interlaced format, "frames" become "fields". A field only captures the odd or the even lines of the TV camera lens. After all the odd lines in the first field are captured, then all the even lines of the second field are captured. In the NTSC countries, 59.94 color fields (formerly 60 fields for B&W NTSC) are captured each second. In PAL and SECAM countries, 50 fields are captured each second. When this is broadcast to a TV screen, the fields are displayed as they are captured. The high number of displayed fields avoids flicker on the TV screen.
Dynamic RAM is typically used in computers because it is cheaper than Static RAM.
Dynamic RAM must be periodically refreshed by an access to RAM or the data contained within the RAM cell decays. Static RAM does not need refreshing, all it needs is a steady supply of power. Computers typically had a method of refreshing the RAM, often tied to the video controller, which refreshes the screen fifty or sixty times per second. Steve Wozniak for example used a unified memory architecture where the video controller circuitry would access the RAM 50-60 times per second, which was sufficiently reliable to keep the RAM contents from degrading.
Virtually all vintage home computers used discrete DRAM chips. However, if you look at the printed circuit board of any old computer, you will see memory chips in columns of eight (or nine) chips. Why is that? This is because a DRAM chip typically holds one bit of data for each memory cell. So you need eight chips to hold a byte. By contrast, you only need one SRAM chip to hold a byte. Despite the need for a refresh circuit and the extra space and complexity required to interface eight DRAM chips compared to one SRAM chip, DRAM was still so much cheaper that it was almost always used.
Vintage consoles more often used SRAM because it made their boards cheaper to manufacture, an important concern when you intend to sell millions of systems based on the same board design. The Atari 2600 used 128 bytes of SRAM, but it was embedded within the RIOT chip. The Atari 5200 used 16KB of DRAM chips, but it was based on the design of the Atari 8-bit computers. The Colecovision uses 1KB of DRAM chips for CPU memory but also a 16KB SRAM chip for the video memory. The NES uses 2KB SRAMs for CPU and PPU memory, but its sprite RAM uses embedded DRAM on the CPU. The SNES uses DRAM throughout, which tends to cause the white stripe issue with its video due to the refresh signal.
In a system with a sixteen bit data bus, you need sixteen chips. In this system, the CPU deals in two bytes (a word) at a time. So the first eight chips hold one byte and the second eight chips hold the next byte. An earlier IBM PC AT system has two banks of eighteen chips each (see parity below). When fully populated, you will have a whopping 512KB of RAM. Each socket uses a pair of 64Kb chips, one piggybacked on top of the other, for 128Kb. So each row of chips provides 128KB. The CPU sees a pair of rows in a 128Kx16bit configuration, but in real purposes you have 256x8bits.
IBM systems, except for the PCjr., use parity memory. Parity memory uses a ninth DRAM chip for each eight DRAM chips. The extra chip is not usable memory, it instead alerts the system to a memory error.
By the mid eighties, some companies were using four bit DRAMs. Four bit DRAMs hold four times the bit capacity as a one bit DRAM. So when you used to need eight chips to form a bank of eight bit DRAM, now you only need two chips.
One bit DRAMs typically have a marking on them like 4116 or 4164, denoting 16Kb and 64Kb parts, respectively. (In this article, a "B" as in KB means byte and a "b" as in Kb means bit). Four bit DRAMs have markings like 4416 and 4464 for the same respective parts. They are also commonly shown as 16Kx1 and 16Kx4.
You can find 1Kb, 4Kb, 16Kb, 64Kb, 256Kb and even 1Mb DRAM chips. You will not find 2Kb, 8Kb, 32Kb, 128Kb or 512Kb chips. Why is that? This is because of the way DRAM is addressed. DRAM is addressed more in a matrix-fashion than a true linear fashion. DRAM uses address lines just like SRAM and ROM chips, but fewer than you would expect.
SRAM can be had in virtually any power of two capacity. 1KB, 2KB, 4KB, 8KB, 16KB, 32KB, 64KB, 128KB, 512KB and 1MB SRAM chips exist. Many chips of the lower capacities can be found in NES and SNES cartridges.
A 64KB SRAM chip has sixteen address lines, but a 64Kb DRAM chip only has eight. We all know that 2^16 = 64KB, right? In order to get to 64Kb in a DRAM chip, you need the Row Access Strobe (RAS) and the Column Access Strobe (CAS) signals. So, first you send a read or write via the address lines and RAS signal, then you send the read or write via the address lines and the CAS signal. Since you are using eight bits twice to get to the correct memory cell, you get your sixteen address bits. If you add a ninth address line to your chip, you will get eighteen bit addressing, which gives you 256Kb. This is why there is no such thing as a 128Kb DRAM chip.
The IBM Color/Graphics Card has been widely seen as a poor attempt at a video adapter. Released with the IBM PC back in 1981, it was not particularly impressive by the standards of its day. Limited colors and no sprites did not make it very attractive for games. However, when you look at the hardware and what it could do, it becomes more impressive. Even though the card is a full length card, it was built from off the shelf logic chips, memory and video controller. Looking at the hardware also helps one understand the limitations of the device.
On an RGBI monitor, the identical Color/B&W modes have no distinction except in Modes 04 and 05. On a color composite monitor or TV set, color modes enable the color burst and b&w modes disable the color burst. The IBM PC defaults to the 40x25 or 80x25 B&W modes depending on how you set a dipswitch. Text, especially 80-column text, is much more difficult to read on a composite color display.
The CGA card has 16KB of RAM. A full screen of 40-column text required 2KB of memory, allowing for 8 separate pages. A full screen of 80 column memory required 4KB of memory, allowing for 4 separate pages. Graphics modes took up all the 16KB of memory. In order to really put the CGA card to work, one has to go deeper and look beyond the BIOS and what could be done by accessing its registers directly.
This blog entry is dedicated to the various mappers files and collections for the NES PowerPak and EverDrive N8. I have previously discussed each device elsewhere in this blog. This blog entry will always have the latest compatibility information for these flash carts. NES PowerPak Mapper Sets
Nintendo World Championships Official Tournament Time Mapper 105/69 :
The NWC had jumpers to set the time from 5m04s to 9m46s. The standard mapper only gives 5m04s, but the official tournament time was 6m15s. This mapper gives you the official tournament time.
Comments : The NES PowerPak uses a MAP.XX file for each mapper. The iNES mapper number is in hexadecimal for each MAP.XX file. So iNES Mapper 79 decimal turns into 4F hexadecimal and is supported by the MAP.4F file.
Mapper 64 - Skull and Crossbones has a garbage scanline above status bar when the main action screen has been scrolled down as much as possible. The Hard Drivin' prototype also exploits this chip in ways not yet supported by flash carts. This is due a lack of information on how the IRQ counter in the RAMBO-1 chip inside this cartridge works.
Galaxian (J) - This is a Mapper 0 game with only has 8KB of PRG-ROM and 8KB of CHR-ROM, whereas the official iNES 1.0 specification does not allow for less than 16KB of PRG-ROM ad 8KB of CHR-ROM with Mapper 0. Use an overdumped 24KB combined ROM to get this game to work.
Study Box (J) - This game will never work properly on any Flash Cart because it embeds a cassette deck.
All Japanese games using a speech synthesizer chip, such as the Moero Pro games, will not play the speech samples because the speech data has never been dumped and the speech synthesizer chips have never been emulated. Most of these games have U.S. counterparts that use the NES's PCM channel to produce speech but not the sound effects.
Mappers 153, 157 and 159 - Games requiring these mapper assignments, instead of the base Mapper 16, will not likely work correctly. They were almost exclusively used by Bandai's Japanese games. These games use similar hardware but different methods to save (none, S-RAM, 128 byte EEPROM, 256 byte EEPROM). These mappers also cover the Datach Joint ROM expansion device, which has a barcode reader which most of the games use.
Karaoke Studio, Mapper 188 will never work correctly because the real cartridges use the attached hardware, specifically the microphone.
Like Karaoke Studio, Nantettatte!! Baseball, Mapper 68, used a cartridge lock-on system that allowed an expansion cartridge to be plugged into the top of the base cartridge. These expansion cartridges, which update team statistics, had a protection IC which the EverDrive and PowerPak do not emulate. The base game plays fine.
Specific Game Issues with EverDrive N8
Cybernoid - This game relies on bus conflicts, which the EverDrive N8 has difficulty with. Use or permanently patch the US ROM with Game Genie code SXZNZV to get the game to work properly after you change the sound mode from sound effects to music.
Gauntlet - Backgrounds will be incorrect if this game is assigned to Mapper 206 because it uses four-screen mirroring, so assign it's iNES header to Mapper 4.
Money Game, The & Tatakae!! Ramen Man: Sakuretsu Choujin 102 Gei - Appear to work when the mapper is changed from Mapper 155 to Mapper 1
Fudou Myouou Den - Appears to work when the mapper is changed from Mapper 207 to Mapper 80.
Mapper 210 is not supported, most games should work as Mapper 19.
General Game Issues with PowerPak (assuming loopy mappers and PowerMappers are added)
Racermate Challenge II - Uses Mapper 168, which is not supported. This game also requires a custom and rare peripheral that attaches to a stationary bicycle.
Most MMC5 games are playable, but Uncharted Waters, Uchuu Keibitai SDF and Bandit Kings of Ancient China will show graphics glitches. No expansion audio support.
Super Mario Bros + Tetris + Nintendo World Cup - A PAL only release, uses Mapper 37 which is not supported by the PowerPak.
Games using MMC3 scanline interrupts will often show jumpy status bars (Super Mario Bros. 3, Crystalis, Mega Man 3) or occasional graphical garbage (Kirby's Adventure, Mickey's Adventures in Numberland). This issue may vary from PowerPak to PowerPak (my PowerPak is a first batch PowerPak), and is ameliorated with the Save State Mappers and PowerMappers.
Specific Game Issues with PowerPak and PowerMappers :
Asmik-kun Land - Status bar on the bottom of the screen constantly shakes. This can be fixed by using MAP04.MAP from the Save State Mappers. You rename the file to something unused like MAP06.MAP and assign the game to Mapper 6 in its header.
Battletoads & Double Dragon - The game may crash when the Level 1 Boss appears. This is also another open bus issue. If you encounter it, it can be fixed by creating a Battletoads & Double Dragon.sav 8KB file filled in entirely with hex 00. Battletoads & Double Dragon does not use S-RAM, but if the game reads these values from where RAM is supposed to be, there will be no glitching or crashing here.
Jackie Chan's Action Kung Fu - Glitchy garbage as the scroll unfurls just before you begin a level. This can be fixed by using MAP04.MAP from the Save State Mappers. You rename the file to something unused like MAP06.MAP and assign the game to Mapper 6 in its header.
Jurassic Park - Extra lines in the wavy Ocean logo on the title screen. This can be fixed by using MAP04.MAP from the Save State Mappers. You rename the file to something unused like MAP06.MAP and assign the game to Mapper 6 in its header.
Low-G-Man - Music for Level 1 Boss is not correct, but it does not crash. This can be fixed by creating a Low-G-Man.sav 8KB file filled in entirely with hex FF. Low-G-Man does not use S-RAM but relies on open bus and this workaround allows the game to obtain the right values it needs for the music engine.
Little Ninja Brothers - Shaking in status menus, text boxes and the like, which did not appear in prior mappers. This can be fixed by using MAP04.MAP from the Save State Mappers. You rename the file to something unused like MAP06.MAP and assign the game to Mapper 6 in its header.
Metroid FDS - Will load to a black screen or a screen so corrupted Samus cannot move. Others have been able to get this game to work, but I cannot.
Mickey's Adventure in Numberland - Certain tiles in Mickey's sprite flicker constantly similar to Startropics. This can be fixed by using MAP04.MAP from the Save State Mappers. You rename the file to something unused like MAP06.MAP and assign the game to Mapper 6 in its header.
Mickey's Safari in Letterland - Status bar shakes because these games requires the IRQ timing for Acclaim's MMC3 clone, which is different from Nintendo's MMC3.
Rad Racer 2 - Occasional flickering of yellow/orange lines in the road. The Save State Mappers do not support the 4-screen mirroring this game uses, so use Loopy's Mapper 4 instead.
Startropics 1 & 2 - Half of Mike's small sprite flickers constantly, as does his inventory in the action sequences. This can be fixed by using MAP04.MAP from the Save State Mappers. You rename the file to something unused like MAP06.MAP and assign the game to Mapper 6 in its header. If you see that the subweapons on the action screen noticeably flicker if you have acquired more than one, then make sure the save state function is turned off in the blue menu before you finish loading the ROM.
Ultima - Exodus - Due to bugs with uninitialized cartridge RAM, you could see shaking text, font corruption and bad audio if you play this game without a corresponding sav file.
Expansion Audio Support
Here is the expansion audio support breakdown for both flash cartridges and the Analogue Nt Mini :
Over the past decade (and a bit) people have been writing new software for "oldskool" PC systems like the IBM PC, IBM PCjr. and the Tandy 1000 computers. Some of these programs have been really impressive or have pushed these systems in ways never envisioned by their creators. While other systems like the Apple II, Commodore and Atari computers may have had comparatively more software released during the same time period, the early PC world has not lain dormant. Starting by the year of announcement, I will identify each project I have found particularly worthwhile or noteworthy and explain why they deserve to be here. I hope this blog entry will serve as a Thank You for all the programmers who put their effort into making new software for the oldest PCs.
2004 - 8088 Corruption
In 2004, Trixter, the creator of The Oldskool PC website and the co-founder of MobyGames, discovered a way to play full motion video on an IBM PC with a CGA card. He did not have much to work with, an 8088 CPU running at 4.77MHz, 640KB of RAM, and a CGA card that could display 16 colors maximum, and all those colors on the screen only in text mode. Moreover, in 80-column text mode, many CGA cards would show "snow", random mosquito noise, when refreshed too quickly.
Trixter looked to the 40 column (by 25 rows) mode for his implementation of full motion video. That mode supports 16 colors, 256 distinct but unchangeable character glyphs, and 8x8 character cell sizes. Most importantly, each 8x8 character cell can choose from any two of the 16 colors for foreground and background colors. A single screenshot using text characters this large would often not show recognizeable objects, but at 30 frames per second, video can be much more watcheable. The 40 column mode has the benefit of only requiring 2,000 bytes to fill the screen compared to 4,000 bytes for an 80-column mode screen or 16,000 bytes for any of the CGA graphics modes.
Of course, the illusion of video is often helped by the use of audio. Use of the PC Speaker was out because too much time would be spent decompressing and displaying the graphics. So Trixter targeted the only devices that would work in a PC's 8-bit slot, could output digital audio and were sufficiently common, the Sound Blaster. 8088 Corruption required a Sound Blaster that supported the auto-init DMA commands so the card could keep its digital audio buffer fed with minimal CPU involvement. The final piece of the puzzle is having a hard drive, preferably a fast one, to hold the video file to be played.
Trixter originally presented 8088 Corruption in 2004 but continually improved the video playback software. However, just about every year thereafter it saw attention at demoparties and news outlets. Eventually an encoder was released that converted .AVI files into the TMV format files the 8088 Corruption (called 8088flex) player needs to load. It can support 60fps video and at least 22kHz 8-bit audio. The most recent versions no longer require a sound card and have much better buffering than older versions. Here is Trixter's original 2006 video showing off 8088 Corruption and proving that it was real :
The concept of a tracker was not a new one in 2008. Music tracker programs had first appeared on the Commodore Amiga in 1987 with Ultimate Soundtracker, which have a graphical interface to music programmers so they could assign PCM samples to their music in a programming-friendly format. The Gravis Ultrasound card was a popular target of early DOS-based tracker programs. Eventually tracker programs were released for the Adlib OPL2 and OPL3 chips as well as other popular platforms that used chiptune music like the NES, the Sega Genesis and the Game Boy.
Trixter noted that there was no tracker program that worked with the PC Speaker, so he sought to change that. The PC Speaker is musically a very limited device, essentially a 1 channel square wave with no volume control but a 16-bit frequency divider. While it could produce digitized and multiple voices by toggling the speaker cone on and off faster than it was designed, there were several disadvantages to this. First, the resulting volume is often very low. Second, these techniques require a large amount of CPU time, leaving little time for much else on 8088 and 80286 machines. Third, the audio can sound very "buzzy" and have a high noise floor, leaving the listener with an uncomfortable experience. Was there any other way to allow the PC Speaker to sing in more than beeps and boops?
Enter Monotone, a solution for a problem few had. Monotone is the first and only tracker designed to support the PC Speaker. Monotone supports 1-4 "voices" for the PC Speaker. It supports multiple voices by giving a programmer a precise time base to change his sound. The PC Speaker still plugs away, but the rapid transitioning of the music, facilitated by the program can give the illusion that the PC Speaker is a multi-channel device. Monotone also supports the Adlib and the Tandy 3-voice sound chip, but both chips have other trackers available to them. You can compare the PC Speaker version of a song in the first video with its Adlib version in the second video :
You like the Internets, right? I do too, but those people still stuck with DOS can have a hard time getting online and enjoying it. Enter mTCP, a suite of utilities developed by VCF forum member mbrutman in 2008. At first he released the utilities separately, starting with IRCjr. IRCjr. is a very slimmed down IRC client that can be run on any PC and intended for the IBM PCjr. Since mbrutman is a IBM PCjr. fan and runs the only IBM PCjr. fansite on the web, it would be natural for him to ensure that the client is sufficiently light-weight to work on a PCjr. or a PC. He also released other programs like a DOS Telnet program and soon began to bundle a whole package of 8088-friendly Internet utilities called mTCP.
mTCP has been continuously updated since 2008. Using the utilities in the package make it very easy to get online with an Ethernet card and a packet driver. For the earlier systems, a Xircom PE3 parallel port Ethernet adapter can work with anything with a standard parallel port (except for the Tandy parallel port). 8-bit Ethernet cards usually work just fine with a transceiver, and 16-bit cards often have RJ-45 jacks so you can directly plug them into a router. Some of these cards are hybrid cards that can work in an 8-bit or 16-bit slot. Wireless Ethernet adapters can be made to work with older systems. If you can find a DOS packet driver for the card, and most major brands and chipsets have one, you are all set to play with mTCP.
mTCP provides a host of utilities. The first one that most people run is DHCP, which obtains all the configuration information you need to get online. You can use IRCjr for connecting to IRC chat rooms so long as you have the relevant information to connect. Similarly, if you need to connect to a BBS, you can use the TELNET application. If your system lacks a real time clock, you can obtain the correct date and time using the SNTP tool. You can also PING the router to check connectivity. You can turn your vintage computer into a basic webpage hosting machine with HTTPSERV
My favorite programs are FTP and FTPSRV. FTP is an FTP client, and you can use it to obtain files from an FTP Server. This of course includes your own FTP server, making for easy file and directory transfers to and from your old computer to your new computer across the network. However, being a lazy guy, I prefer to use FTPSRV on my vintage computer. This allows me to obtain full access to my old computer from my new computer. I can use the FTP client on the new computer to move, copy, delete files on the old computer's storage devices, and I can send files to them or take files from them. It sure beats sneakernet.
The genius of the mTCP program suite is how easy it is to use. Even though it does not come with a web browser or an email client, it can allow you to get on the Internet easily so you can use those programs without any further configuration headaches. mTCP works on all speeds and stripes of DOS computers, but no program requires more than 256KB to run. You can download the mTCP suite from here : http://www.brutman.com/mTCP/mTCP.html
2011 - Paku Paku
A new game that can run on the IBM PC? Who would want to write a new game for that ancient thing? Enter VCF forum member deathshadow, a man determined. He was determined to write a Pac-Man clone that played fast with an IBM PC without the 4-color limitations of the official Pac-Man from Atarisoft or PC-Man and other unofficial clones.
Deathshadow decided to use the CGA 160x100 "graphics" mode. This gave him freedom to use the whole 16-color palette on any display at the expense of resolution. He decided to keep the aspect ratio of the maze to be true to the original arcade game and to have the maze use the proper orientation. He used red, cyan, magenta and brown for the ghosts, yellow for Pac-Man and appropriate blues for the mazes and colors for the fruit. He included all eight types of fruit, both warps and the exact number of dots found on the original arcade. It saves the high scores and can fit onto a floppy disk. He did not include the intermissions that the original game had, and I doubt there is a split screen level 256.
Deathshadow cast a wider range of hardware support, his game can support CGA, PCjr., Tandy, EGA, MCGA and VGA graphics adapters. He quickly added joystick and high score saving support. He added support for the PC Speaker, Tandy 3-voice sound, Adlib and even CMS/Game Blaster for music and sound effects. Later he added MT-32 and General MIDI support. It runs at full speed on an IBM PC with 128KB, even with the joystick reading, although you will have to put up with a bit of snow with many CGA cards. The game even runs on an unexpanded 128KB PCjr. Now there is a feat! He later ported the game to the Commodore 64, which utilizes a 160x200 resolution, smoother graphics and 3-voice music.
Tandy's can only display 16 colors on a screen at once, right? A VCF forum member called chjmartin2 challenged that idea. While it technically can only display 16 colors in a 320x200 mode, or in a 640x200 mode for the Tandy TL, SL and later machines, color blending has often been used to try to give the appearance of more color.
Most RGB monitors, even the crappy Tandy CM-5, make most dithering techniques look very obvious. What chjmartin2 did differently was instead of trying to put two colors next to each other to try to simulate a third color, he displayed two colors in a rapid cycle and relied on the viewer's persistence of vision to make a third color. By displaying two images 30 times per second, he could obtain a result that, while looking somewhat flickery, could give the impression of greater than 16 colors. He made a tool that can take 24-bit BMPs and split them into two images which his program would then display 30 times per second, each following the other.
So finally we have a first for the Tandy, the ability to display lifelike images with sufficient color. Because each combination of two colors does not give a unique third color, 85 colors can be obtained. His program relied on the GW-BASIC included with Tandy DOS, demonstrating that you do not need to master Turbo Pascal or Microsoft Assembler to produce something cool with an old machine! He released his program in 2013 and also included a converter that runs in Windows and will convert any 320x200 24-bit BMP image into a pair of files his program can display on a Tandy 1000. It works on my Tandy 1000 SX and he wrote the program on a Tandy 1000 TL, so it should work with any Tandy 1000 with a built-in Tandy Graphics Adapter. I do not believe it would run in a PCjr. without modification because of the reliance on Tandy GW-BASIC.
Here is a video demonstrating the picture viewer :
This year brought us the first demos for the IBM PCjr. from Hornet. Hornet is the demo "group" of Trixter and Phoenix. They not only ran it on a PCjr., premiering it at @party 2013, but also coded the demo on the machine. Given the chicklet and rubber dome keyboard that the PCjr. uses, that must have been fun. Trixter wanted a "world first" and in these programs he obtained it.
He targeted the PCjr. because he found a video mode unique to it. Even the Tandy 1000s do not replicate IBM's hardware sufficiently to make this video mode work. By accident, he had programmed the PCjr.'s gate array to display each line in 160x200x16 mode twice, giving him something unexpected. His video mode this uses an effective 160x100x16 resolution, but is not set up the same way as it would be on a CGA card. Instead of ASCII values and attribute bytes, he has a 160x100 graphics mode where each pixel determines the color of two bytes. Moreover, there is no interlaced memory organization as there is with other CGA and PCjr. graphics modes. He and Phoenix made a little demo called INTROjr with several demo-effects like plasma and scrolling text and 3-voice music, and it was widely acclaimed. Here you can see it for yourself without the extra scanlines :
Later he made a "silly joke game" called SHAKEjr using the 160x100x16 PCjr. graphics mode. The game requires you to jerk your joystick back and forth as many times as you can within a certain time frame. Then it tells you how many "microfractures" you made to your joystick. Video shows people doing the "Harlem Shake" during the "game". Here is a very tongue-in-cheek video "advertising" SHAKEjr :
While the demo will work in a Tandy 1000, it will show a row of black lines after each row of graphic lines. This is because the Tandy cannot double the scanlines as a PCjr would. Nor does DOSBox properly emulate this functionality of the PCjr. Late in 2015, VOGONS forum member NewRisingSun discovered how any Tandy, except for the original 1000/A/HD, could double the scanlines via another method and released a fixed version of INTROjr that displays properly on the Tandys.
You can obtain INTROjr from here : http://www.pouet.net/prod.php?which=61547
You can obtain SHAKEjr from here : http://www.pouet.net/prod.php?which=61535
2014 - 8088 Domination
Trixter believed that 8088 Corruption was the limit of the IBM PC and CGA's graphics capabilities. But then he discovered the potential of CGA's high resolution composite color mode. But the old problems surfaced. How do you run video at 24fps when you have to output 8x the graphics data on a system so slow as the 8088-based IBM PC? Moreover, when hard disk interfaces of the time only pushed 90KB/sec, how can you get so much data to the graphics card?
Trixter discovered he could do it if refined his techniques. When he had finished dancing naked in the streets, he wrote a new video player that made 8088 Corruption obsolete. Instead of always transferring 2KB per frame as he did with 8088 Corruption, he would only transfer as much pixel data as his demo needed, up to 2KB. He would only update those portions of the frame that needed updating. His encoder would do all the hard work on a modern system and leave the video file simply to tell the 8088 which pixels to update and when. Moreover, instead of just pointing to data and telling the 8088 to fill the graphics memory, he converted that data into code, allowing much faster execution.
He premiered his 8088 Domination decoder @party 2014, an event I was privileged to witness and assist. The first part of the video uses essentially the same video samples he used for 8088 Corruption back in 2004. However, by using high resolution color composite mode, the graphics were much clearer. You could now see something resembling a human face during the Tron sequence. The second part used the Bad Apple animation to show the detail that can be obtained in black and white. Here is a video capture of the demo :
Trixter also released a player that allows people to play back video files as his demo did. He documented the video/animation system as XDC, (X86 Delta Compiler) People can make their own videos, although the process is not as easy as running a video file through a converter. The XDC format supports graphics in 160x200 resolution (Tandy/PCjr only) or 160x100 resolution at 16 colors or 640x200 resolution in two colors (you can specify B&W or color in the encoder). The video must be broken down into individual frames in the bmp format which are accompanied by a 8-bit PCM wav file up to 44.1kHz. Then you use a script file to run it through an encoder in DOS, which makes the XDV file which you can play.
If you want to see just how huge the difference is between 8088 Corruption and 8088 Domination, which Trixter's comparison video here :
Trixter set up a website for 8088 Domination, you can find the player and encoder there : https://x86dc.wordpress.com/
2015 began slightly inauspiciously for oldskool PC demos. GP-01 was a demo that relied on CGA. Unfortunately the demo did not work on real hardware, it was coded in DOSBox and ran only on DOSBox, making it a DOSBox specific demo. As CGA may be improved to more closely emulate real hardware, eventually this demo may fail to run on DOSBox. A VOGONS/VCF forum user named Scali eventually fixed the demo to run on a real IBM PC with CGA.
Much more impressive was the demo 8088MPH, which premiered at Revision 2015 and won first place there in its demo category. Hornet (Trixter and Phoenix) was only part of this demo this time, the project was comparatively huge. Also joining in were VOGONS/VCF forum members known as reengine from the group CRTC, VileR(ancour) and the previously mentioned Scali affiliated with the group DESiRE. Here is the video of the demo as shown at Revision :
The demo version of 8088MPH was extremely picky about the hardware it would run on. If you did not have an IBM PC, XT, Portable or true clone, you could forget about running all parts of the demo correctly. Moreover, the demo was designed for an "old-style" IBM CGA card's composite colors. "New-style" IBM CGA's colors were a bit off. Finally, the CRT controller on the CGA card had to be a Motorola 6845 and many CGA cards came with a Hitachi 6845. The demo took advantage of a text-mode feature found on Motorola chip that was not duplicated on the Hitachi chip.
Fortunately, the demo was cleaned up a bit and the developers released a final version. Now there was official support for new IBM CGA cards and the Hitachi 6845 chip. Additionally, the program offered a calibration screen so you can tweak the colors to get something close to the intended result. By some clever pixel positioning, the program could now even tell you whether you had an old or a new CGA card. Here is the final version of the demo on a new IBM CGA card :
There were several firsts for this demo. The most visibly spectacular was the demo's ability to display 1,024 colors using 80-column text mode and color composite graphics. Using color composite graphics with a text mode is usually undesirable, the monitor does not have sufficient bandwidth to keep up with all those color changes, usually making for a blurry mess of text. However, by using certain carefully selected ASCII values, like the U, the !! and the ▓, cutting down the cell size to 8x2 and using different foreground and background color combinations, a vastly greater color palette is possible.
Another first for the demo was implementing a MOD player for the PC Speaker. While the main two music pieces use songs adapted for Monotone, the final music played during the credits would have taken too much time away from the visual effect earlier in the demo. The Amiga MOD format supports 4-channel playback. Playing MODs using the PC Speaker is nothing new, but playing them at an acceptable sample rate with a 4.77MHz 8088 is a lot more difficult. With some amazing 8088 trickery, they were able to obtain an effective 16.6KHz sample rate from the PC speaker through Pulse Width Modulation..
Because of all these code optimizations and cycle timing, the number of machines on which this demo is guaranteed to run correctly still amount to three, the IBM PC, the IBM PC/XT and the IBM PC Portable (which is really just an XT in a "portable" case). Even the Tandy 1000SX running at 4.77MHz runs a bit too fast for the Kefrens bars, that portion of the demo will lose sync. DOSBox will not run that and several other portions of the demo, you may be able to skip them if it does not crash the emulator. A recent fork of PCem called PCem-X can almost complete the demo, but the Kefrens Bars does not look right and the demo crashes as it tries to play the MOD at the end.
Although not finished, another program of note is a game called MagiDuck. This game, like Paku Paku, is designed to run on an IBM PC with CGA and 256KB. The author, VCF forum member mangis, is learning as he goes. Judging by the beta released in December of 2015, he has learned his craft very well.
MagiDuck is a sidescroller with a vertical orientation with a simple control scheme of three directionals and two buttons, one for shooting fireballs and one for jumping. Your character, the duck, can jump and float downwards and move left and right and look down. She can jump on some enemies and collect keys and treasures to score points. She has four hearts which function as a health meter. There are passages that open touching switches and levels that only open by finding secret stars. There are eight kinds of enemies and six different types of special blocks. There are three save slots and the game tracks your completion level. The game feels reminiscent of Kirby's Adventure for the NES in this regard.
This game has the feel of a shareware game from the early 90s. There are only PC Speaker sound effects, no sound card support has been implemented. Neither Commander Keen 1-3 nor Duke Nukem/Nukum had sound card support either and both are very fun to play. So is this game, which has 10 levels, 3 secret levels and a boss level. You can complete any of the levels in any order and the game saves high scores to disk. The large characters make up much of the challenge because you do not necessarily know what may be in front of you or above you, so you have to be careful.
What makes this game particularly well-suited for the IBM PC is the graphics. MagiDuck can show all 16 colors on the screen at a time. It does this by tweaking the CGA 40 column by 25 row mode to show 50 rows and then uses the half-filled character to give two distinct "pixels". The foreground and background attributes allow each half of the "pixel" to show a different color. The effective resolution is only 80x50 pixels, half the semi-official CGA 160x100 mode. What MagiDuck loses in terms of resolution, it gains in that there is no CGA snow to deal with and maintains a smooth framerate. The game does detect EGA and VGA cards, so it should work in any PC compatible that can run DOS (with the possible exception of the PCjr.) and supports at least a floppy disk. Hopefully the final version 1.0 will work with a joystick, because these games lend themselves well to Gravis Gamepads.
The Atari 2600 is a very compact system, even though this may not be reflected in the standard woodgrain case in which it is housed. Inside each system are three chips, the CPU, the Television Interface Adapter (TIA) and the RAM, Input, Output & Timer (RIOT). These three chips work together along with a cartridge, switches and a controller to display games to a TV. Lets discuss how the design of these chips influences the games that were produced.
CPU
First, lets start with the CPU, which is a MOS 6507 (a.k.a. C010745). The 6507 is a budget version of the 6502 an in the Atari 2600 it runs at 1.19MHz (1/3 of the NTSC color clock frequency). It is a fully-functional 6502 in a 28-pin package. The full 6502 comes in a 40-pin package. As a result of the size reduction there is no support for hardware interrupts and the 6507 only has 13 (of a maximum of 16) address lines. This limits the amount of addressable memory that the CPU can access directly to 8KB (kilobytes). Unlike the NES's 6502 variant, the 6507 has a functional binary-coded decimal mode. The TIA is connected to the CPU's RDY line, so it can halt the processor.
RIOT
Next comes the RIOT chip, which is an MOS 6532 Peripheral Interface Adapter (a.k.a. C010750). This 40-pin chip contains a programmable timer, 128 bytes of RAM and two 8-bit parallel input and output ports. It has 9 registers, some of which are read only, some write and some can do both. The timer counts down an 8-bit value by one of four orders of magnitude. 128 bytes of RAM substantially limits the complexity of games because that is where all a program's variables must live. In addition, this RAM is also used by the stack. The stack is vital for subroutines, which can be many in a game. On the plus side, the RAM is located in the 6507's zero page, so accessing it will be fast.
One of the I/O ports is exclusively used for input from the five switches on the console, one bit for each switch. Each bit of the second I/O port can be set to be an input or an output. As an input, it reads the four directions from each joystick (one direction per bit), the paddle button from each of the four paddles or the position of the driving controller. As an output, it strobes the keyboard controllers. This I/O port can also be used to write to and read from more modern port peripherals like the AtariVox.
TIA - Input and Sound
Finally we come to the TIA, the most complex chip in the system. This is a custom 40-pin Atari chip C010444D which Atari strangely never got around to patenting, leading to cloned chips from Mattel and Coleco later in the 2600's life. It was never an off-the-shelf chip, unlike the 6507 and 6532. The TIA handles all graphics and interfacing with the TV, all sound and handles the remainder of the inputs. It is also mapped into the zero page of the 2600's memory map. It contains 45 write-only registers and 14 read-only registers. Let's discuss its features in inverse order of complexity.
The TIA has four input ports, each dedicated to the input from a single paddle. Paddles are read in a way similar to how a joystick is on the IBM PC. A write to a certain register discharges the a capacitor and the position of a connected potentiomer dictates how long it takes to charge the capacitor. The length of time it takes the capacitor to charge dictates the position of the paddle. These registers also are used to read the keyboard controllers. Essentially the keyboard controllers act like paddles set to a specified resistance value. It also has two ports for reading the state of the joystick switches or the driving controller buttons.
Sound on the 2600 is geared more toward creating interesting sound effect than music. Each of the two audio channels can emit a pure square wave tone, but there are only five bits to divide the frequency. The range of the 2600 is from 30,000Hz (divide by 1) to 937.5Hz (divide by 32). Even the less than impressive TI SN 76489/96 has 11-bits of frequency control. There are 4-bits of volume control, but the 2600 is just not very musical. Even so, some games like Gyruss, Mountain King and Supercharger Frogger have impressive music. The noise is based off a polynomial counter tweaked by various settings. There are 16 combinations (10 unique) of tone and noise to choose from in the 2600, and they are much more geared to sound effects. You can hear what each selection and frequency sounds like here : http://www.randomterrain.com/atari-2600-memories-batari-basic-music-toy.html
TIA - Graphics
Most of the CPU's time is spent drawing the graphics, line by line. The 2600 does not have a frame buffer and it does not have dedicated video memory. More modern game consoles write the graphics data into a frame buffer and into sprite memory and let the video display chip take care of drawing it to the screen.
Atari 2600 graphics have to be fed into the TIA each and every line that the TV draws. Whatever time is left over during horizontal blanking (the time it takes for the TV's electron beam to return from the right side of the screen to the left) is spent on setting up the graphics for the next line. This is what is called racing the beam. The vertical blanking period, (the time it takes for the beam to return to the top left portion of the screen from the bottom right) is typically used for game logic, sound and input reading.
The Atari 2600 is capable of displaying 128 colors, 8 of which are solely grayscale from black to white. The remainder are spread across the NTSC color wheel with a great variety of variation. The horizontal resolution of the Atari 2600 is always 160 pixels. The vertical resolution of the Atari 2600 is not fixed but typically is 192 lines. It is up to the programmer to start the vertical retrace period.
The graphics are made up of seven elements, a background color, a playfield, two players, two missiles and a ball object. The background and the playfield make up what would be known in later consoles as the background graphics and the player, missile and ball objects would later be known as the sprite graphics.
Combat - Note the reflected playfield and the two players. Each player fires a missle with the same color
The background color a single color that is set for the entire TV area, unless changed on a particular scanline. When the color is changed it can be masked by the playfield. Air-Sea Battle has frequent changes of the background color.
The playfield consists of 20 bits per line. If a bit is on, the playfield color is displayed. If the color is off, then the background color is displayed. Each bit of the playfield is four pixels wide, giving the backgrounds to Atari 2600 games a characteristic low resolution look. Additionally, those 20-bits only cover the left side of the screen, so the right side of the screen displays a duplicate or a mirror image of the left side of the screen. This tends to give the backgrounds a symmetrical look in many Atari 2600 games.
Combat - Note the second copy of Player 2, the repeated playfield and that the playfield has priority over the players
When you see counters or scores on the top of the screen, these are usually playfield graphics. But as I mentioned, there is only enough room in the playfield registers for half the screen, so what happens when one side's 0 turns into a 1? You can time your writes to the playfield registers in mid scanline so you get a different playfield on the right side as opposed to the left side. You can also set the colors of each side to the colors of the player 1 and player 2 objects.
Video Olympics - The ball object is used, and the scores are playfield bits changed in midscanline
The ball object is a one pixel object that can be placed anywhere on a scanline. It uses the same color as the playfield on the same scanline. The ball was intended to make Pong games like Video Olympics possible on the 2600.
The player objects are up to eight pixels wide, with a 1 bit showing the player color and a 0 bit showing a background or playfield color. Two players, two colors. Each player has a one pixel missile object associated with it which is the same color as the player. Each player and missle object can also be placed anywhere on a scanline. Multi-colored objects are accomplished by changing the color of the player object each line. These graphics are best suited for Tank-line games like Combat.
Space Invaders - The player cannon is stretched, and each invader is a player copied twice, the copy is removed when shot
Ball and missile objects can be stretched to 2, 4 or 8 pixels. Each player object can have one or two additional copies spaced at set intervals. This is what makes Space Invaders possible. The player can be stretched 2x or 3x horizontally and be reflected (to face left instead of right). Players and missiles are typically displayed over the playfield graphics, but can be set to have the playfield graphics displayed over them.
In many games like Space Invaders and Ms. Pac Man, you will see a serrated series of lines across the left border of the screen. These lines are used to delay the start of the graphics drawing, giving the programmer more time to write graphics to the next line. In the 2600, you always have to be one line ahead of the raster. In fact, the standard Activision practice was to blank out the entire left column of the screen for 8 pixels or so.
Pitfall - Player, missile, ball and playfield graphics all combine on various scanlines to make a complex background
In Video Checkers, there are four pieces per row, three of which are provided by a player object and one provided by a stretched missile object. Lucky for Atari standard checkers is played with a maximum of four pieces per row. However, the same effect is insufficient for Chess. Atari used a Venetian Blinds effect used in Video Chess. This is necessary because each player object can only draw three objects on a line, and you need eight in chess. So in Video Chess, they alternated the drawing of the chess pieces every other line. This eliminated flickering. They also had to alter the player graphics in mid-frame in order to make the king's row pieces distinct for each side.
Yar's Revenge - The Neutral Zone is a visual representation of the game's code
Color cycling was one of the hallmarks of Atari graphics, from the Chalice in Adventure to the Neutral Zone in Yar's Revenge. The color registers are often updated many times per second. In Yar's Revenge, the bit pattern of the code in ROM was used to give a pseudo-random appearance to the Neutral Zone. Color cycling was also done for many of the early 2600 games because this was believed to reduce screen burn-in if the TV and the 2600 were left on.
Video Checkers - Each Player has two copies and stretched missiles make up the fourth checker on each row
Scrolling the screen was uncommon on the 2600 because there were no scrolling registers, everything had to be done in software. Vertical scrolling was easier due to the line-based nature of Atari graphics and because the programmer could tell the TIA when to stop drawing scanlines. Raiders of the Lost Ark, Jr. Pac-Man and Haunted House all have vertical scrolling. Horizontal scrolling was a bit trickier, but it could be done. Mountain King, Stargate/Defender II and Dragonstomper all do it well.
Video Checkers - Each piece is a Player object is staggered compared to the next and drawn every other line. The background is very large to give the programmer more time to update the individual pixel patterns without flickering
There are hardware collision registers for each combination between the six objects. Reading a register will tell you if there was an intersection between player 1 and missile 2, for example. While this saves the programmer from having to determine the collision by having to compare the position values of the two characters, it can also lead to too-strict hit control. If a missile hit a non-visible player pixel, it will still register a hit.
The Stella emulator can turn on and off each of the objects at will. If you ever wonder how so few objects can make up the screen, try turning off some. Collisions can be disabled as well, people tend to use this to cheat.
Cartridges and Memory
Standard Atari 2600 Cartridges contain a 2KB or 4KB ROM chip. 4KB is the maximum amount of ROM the 2600 can address without any bankswitching hardware. To address more ROM, you had to include additional hardware in the cartridge to handle the swapping. Most bankswitching schemes reserve certain addresses. When you write a value to the reserved address, it swaps in another 4KB section of the ROM. Some schemes are more complicated, but this is the general idea.
Asteroids was the first commercially released game to use more than 4KB. Approximately 20% of Atari 2600 games used more than 4KB of ROM, and almost none used more than 16KB. However, most Atari 2600 games did not have title screens because they always require precious space in ROM to program. The title on the cartridge should have been enough for everybody, or so the thinking went. Also, if you wanted to know what the differences between the various game options are, you have to look in the manual or figure it out through observation. There was no space for the game itself to explain options.
Some Atari 2600 Cartridges also include additional RAM, usually 128 or 256 bytes. This RAM is mapped somewhere into the cartridge space and one set of 128 or 256 byte addresses is used for reading and a second set is used for writing. This is because there is no read/write line sent to the cartridge slot.
The B&W switch on the 2600 does nothing if the program ignores it. If the program responds to the B&W switch as it was meant to be used, it will set the graphics to use colors that will show up better on a B&W TV. B&W TVs only understand the eight levels of luminance the Atari 2600 provides. However, there is nothing special about the B&W switch or any of the other non-power switches, and the B&W switch was used for other purposes on occasion : http://nerdlypleasures.blogspot.com/2015/03/the-forgotten-switch-atari-2600s-b.html
Enhancements
The TIA contains two audio channels that operate identically but are mixed together outside the chip. The 2600 was originally planned to be a stereo console with two speakers installed in the 2600's case, but this idea was scrapped as being too costly. Some of the earliest games (Combat) and a few homebrews (Medieval Mayhem) support stereo audio, but you have to modify your system to hear stereo audio.
The Atari 2600 outputs RF video only, which is less than desirable in the year 2015 for many people. The chip outputs the color, c-sync and three luminance levels on separate lines. The luminance levels are mixed and balanced with an R2R network and mixed with the other signals and sent to the RF modulator. Composite and S-Video mods have existed for years. However, S-Video is the best you can get from the TIA without substantial additional hardware.
There is an Atari 2600RGB adapter which will provide RGB video. It requires removing the TIA chip and inserting it into a custom board. The board has an FPGA that will take the values in the color registers and translate them into RGB values. It will also provide S-Video and Composite Video output. Because there are only six graphical objects and the background color and four color palettes to keep track of, the FPGA can keep track of this by snooping on writes to these color palette registers. In order to keep track of the objects as the pixels are displayed, each set of objects is assigned a different black and white palette and intercepts all writes to the palette registers.
Because of the non-standardized method (every game can do it differently) the 2600 uses to indicate that it is time to do vertical blank to the TV, some games may have some trouble when upscaled with an X-RGB Mini Framemeister. The original Warlords is one such game and there is a patch available.
I am going to be using a standard 360KB floppy disk as an example here. A standard MS-DOS format command formats a 360KB floppy disk with 40 cylinders, 9 sectors per cylinder and 512 bytes per sector. I distinguish between cylinders, which use both sides of the disk, from tracks, which only use one side of the disk. Thus you get a total disk size of 368,640 bytes. However, that is the space available for data bytes and a standard disk dump just dumps the data sectors. In between the data there is extra data allowing the disk drive to find the right data.
Each sector has a Sector ID field and Sector Data field. Between the Sector ID field and the Sector Data field are two kinds of bytes. Before the Sector ID field there will be Gap bytes. These Gap bytes, typically hex 4E, are used to compensate between slight differences between the drive that originally wrote the disk and the drive that is currently writing the disk. Without some tolerance, the Sector fields may overwrite each other. After the Gap bytes come the Sync bytes, which help tell the drive that there will be a Sector ID field or a Sector Data fields coming up next. Sync bytes follow a pattern of 00s followed by three A1s. This area is missing the normal clocks and does not follow proper MFM encoding rules so the drive controller can figure out that this is not real data and the real data is coming up. The A1s are also called the Sync mark. Gap bytes and Sync bytes precede both the Sector ID field and the Sector Data field.
The Sector ID begins with an FE byte as an Address mark. Then it continues with track number (00-27), the side number (00-01), the sector number (01-09) and finally the size ID byte (00-06). Unlike everything else, sector numbers use a convention starting with 01, not 00. The size ID byte tells the system how large the follwing Sector Data field is and is interpreted as follows :
Size ID Byte Actual Size in Bytes
00 128
01 256
02 512
03 1024
04 2048
05 4096
06 8192
The only sector size the standard DOS FORMAT command will use is a 512 byte sector size. This applies to all standard 5.25" and 3.5" disks and drives, whether double density (160KB, 180KB, 320KB, 360KB & 720KB), high density (1.2MB and 1.44MB) or extra high density (2.88MB). You can use third party utilities to format disks with other sector sizes, but DOS will not read them. Note that a track on a 360KB disk cannot really fit 8192 data bytes. I have never come across a disk that has had more than 10 x 512 byte sectors.
The next two bytes form a 16-bit Cyclic Redundancy Check (CRC) value. The CRC value verifies that the information contained in the sector ID field is correct. Sometimes there may be some junk bytes between the CRC value and the next sequence of Gap bytes.
As stated above, after more Gap bytes and Sync bytes comes the Sector Data field. The sector data field begins with an FB byte as an Address mark. Then comes the actual data, the bytes you see with a standard disk dump. Finally comes the 16-bit CRC value.
A Sector ID field, without the Address Mark and CRC Value, is 4 bytes large. A Sector Data field without the Address Mark and CRC Value, is typically 512 bytes large, otherwise the size is whatever the Size ID Byte indicates. Gap Bytes and Sync Bytes do not have a set size.
For standard DOS compatible 160KB, 180KB, 320KB and 720KB disks, the only thing that changes is the track number, side number and sector number. 160KB and 180KB disks only use 1 side of the disk, 160KB and 320KB disks only use 8 sectors, and 720KB and larger disks use 80 tracks. High density disks use 15 (1.2MB), 18 (1.44MB) or 36 (2.88MB) sectors per track.
In a hex viewer, a full sector dump might look like this :
4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E
00 00 00 00 00 00 00 00 00 00 00 00 00 A1 A1 A1
FE 04 01 06 02 xx xx4E 4E 4E 4E 4E 4E 4E 4E 4E
4E 4E 4E 4E 4E 4E 4E00 00 00 00 00 00 00 00 00
00 00 00 00 A1 A1 A1FB55 53 45 52 44 41 54 41
55 53 45 52 44 41 54 41 55 53 45 52 44 41 54 41
55 53 45 52 44 41 54 41 55 53 45 52 44 41 54 41
55 53 45 52 44 41 54 41 55 53 45 52 44 41 54 41
55 53 45 52 44 41 54 41 55 53 45 52 44 41 54 41
55 53 45 52 44 41 54 41 55 53 45 52 44 41 54 41
55 53 45 52 44 41 54 41 55 53 45 52 44 41 54 41
55 53 45 52 44 41 54 41 55 53 45 52 44 41 54 41
55 53 45 52 44 41 54 41 55 53 45 52 44 41 54 41
55 53 45 52 44 41 54 41 55 53 45 52 44 41 54 41
55 53 45 52 44 41 54 41 55 53 45 52 44 41 54 41
55 53 45 52 44 41 54 41 55 53 45 52 44 41 54 41
55 53 45 52 44 41 54 41 55 53 45 52 44 41 54 41
55 53 45 52 44 41 54 41 55 53 45 52 44 41 54 41
55 53 45 52 44 41 54 41 55 53 45 52 44 41 54 41
55 53 45 52 44 41 54 41 55 53 45 52 44 41 54 41
55 53 45 52 44 41 54 41 55 53 45 52 44 41 54 41
55 53 45 52 44 41 54 41 55 53 45 52 44 41 54 41
55 53 45 52 44 41 54 41 55 53 45 52 44 41 54 41
55 53 45 52 44 41 54 41 55 53 45 52 44 41 54 41
55 53 45 52 44 41 54 41 55 53 45 52 44 41 54 41
55 53 45 52 44 41 54 41 55 53 45 52 44 41 54 41
55 53 45 52 44 41 54 41 55 53 45 52 44 41 54 41
55 53 45 52 44 41 54 41 55 53 45 52 44 41 54 41
55 53 45 52 44 41 54 41 55 53 45 52 44 41 54 41
55 53 45 52 44 41 54 41 55 53 45 52 44 41 54 41
55 53 45 52 44 41 54 41 55 53 45 52 44 41 54 41
55 53 45 52 44 41 54 41 55 53 45 52 44 41 54 41
55 53 45 52 44 41 54 41 55 53 45 52 44 41 54 41
55 53 45 52 44 41 54 41 55 53 45 52 44 41 54 41
55 53 45 52 44 41 54 41 55 53 45 52 44 41 54 41
55 53 45 52 44 41 54 41 55 53 45 52 44 41 54 41
55 53 45 52 44 41 54 41 xx xx
Green = Gap Bytes
Red = Sync Bytes
Blue = Address Mark Bytes
Magenta = CRC Bytes
Black = ID and Data fields
The hex values in the data field repeat the ASCII for USERDATA over 64 times.
II. Floppy Disk Encoding
A floppy disk is a magnetic storage mechanism. Data is encoded through a flux reversal, the change in the polarity of a magnetic field from north to south and south to north. A flux reversal could signify a 0 or a 1 bit. We start with the proposition that a 0 is represented by no flux reversal and a 1 is represented by a flux reversal. However, this scheme is not workable because it becomes too difficult to keep track of the bits when there is a prolonged period with no flux reversals.
Thus the Frequency Modulation (FM) method was first used. In this method, a 0 bit is encoded by a flux reversal followed by a no flux reversal, and a 1 bit is encoded by two flux reversals. Thus for there will be at least one flux reversal for every two pulses of the clock. This method is used in the earliest floppy disk controllers, but for home computers only the Atari 8-bit drives used it. These disk drives were called single density. The IBM PC floppy disk controllers that use an NEC uDP765 or 100% compatible like the Intel 8272 support FM encoding. Later floppy disk controllers lose that functionality.
This system was easy to implement, but not very efficient. The next improvement was the Modified Frequency Modulation (MFM) method. In this method, a 0 bit preceded by a 0 bit would be encoded by flux reversal then no flux reversal. A 0 bit preceded by a 1 bit would be two clocks of no flux reversal. A 1 bit would be no flux reversal followed by a flux reversal. On average this only requires half the flux reversals per bit as in the FM scheme. The fewer flux reversals needed, the more data can be stored on a disk. The disks that supported this system were called double density. All IBM PC compatible floppy disk controllers use the MFM encoding scheme, as did the earliest hard disk drives.
The data line of a floppy disk does not operate in a vacuum. There is a relationship between the MFM clock bits and the MFM data bits. Both are present on the Write Data and Read Data lines. There are two data bits for every clock bit. Normally the two are in sync, meaning that the clock bits correspond exactly to the MFM data bits. But there is one time when they intentionally are not, the Sync bytes. How this happens is as follows : In MFM encoding, there will never be more than three 0 bits between a 1 bit. However, with this limitation is more liberal than how the bits are actually represented in MFM. The A1 in the Sync bytes does not follow the appropriate clock and data bit pattern. A1 should be encoded as data bits 100010010101001 and clocking bits 0 0 0 1 1 1 0 and is encoded that way in a Sector Data field (there is no reason for it to appear in a Sector ID field). However, to put the A1 out of sync, the following pattern is produced by the clocking bits : 0 0 0 1 0 1 0. The resulting fifth bit is not as it should be, instead it appears as 100010010001001, with the fifth bit being different. This error signals to the disk controller that this is a Sync byte.
III. Copy Protection
Copy protection methods on the IBM PC platform ultimately generally work within this scheme. Other systems like the Apple II, Commodore 64, Atari ST and Commodore Amiga have controller hardware that allows far more sophisticated protection methods to be used. The PC disk controller will not tolerate the more bizarre methods like half tracks, fat tracks, spiral stream, offset tracks or varying bitrate speeds.
The simplest methods are to use non-standard sector sizes, sector numbers or tracks. This is good enough to bypass DISKCOPY and FORMAT, but any utility that uses the PC BIOS can format a disk with non standard. Each track and sector within the track can have differing sector sizes.
Another simple method is to use the write protection tab/notch on a disk. If a program expects the disk to be write protected, it may try to write a destructive sequence of bytes to the disk. Of course, the original disk should have no tab or notch. Be wary if you see a disk notched roughly via scissors or with a hole punch.
A common method is to intentionally write a disk with erroneous CRC bytes. A standard IBM PC Diskette Adapter can read, but not write erroneous CRCs. Of course, sectors with data that cannot be reliably read will also return CRC errors. It is then up to the person de-protecting the diskette to figure out whether the error is intentional or unintentional.
Another method is to check that the exact number of Gap and Sync Bytes are on the disk. If the original disk was written with 16 of each and the copy only has 15, that is a way to detect the copy. The program could instead read data from the Gap bytes, like an encryption key. The PC disk controller's read track command would read the Gap bytes. A method used the Sync bytes to let sectors overlap. The disk can play with the sector ID sizes to make no sense physically, like having sector 1 with an ID of 8192 bytes and then fitting the other sectors "within" sector 1. This protection can often be fooled by writing the image to a high density disk, which allows for 15 or 18 sectors per track. Of course, high density disk controllers were far from ubiquitous in the 1980s when most of these games were released. A devious method used weak bits. In this case, the game would read an area on the disk where the flux transitions have not been written with sufficient magnetic force to make the transitions able to be read reliably. The game would not expect the same result to be returned from multiple reads of a sector. If the same results were always read back, the game would fail to work, thinking it was being run on a copy. Unfortunately, if the disk was damaged unintentionally or the flux transitions have lost their force with age, a flux copier like an Option Board,Deluxe Option Board, a Kryoflux or a Super Card Pro may misinterpret this and make a bad copy. IV. Known Protection Schemes used in Games :
Cops Copylock II
The Rising Dynasty (HD media used)
Electronic Arts IBM Interlock
Used by Electronic Arts booters, involves 96 interleaved sector IDs, typically at track 15, side 0. They also use 200KB and 400KB disk sizes with 10 sectors per track.
Amnesia
Archon: The Light and the Dark
Hard Hat Mack
Marble Madness
Murder on the Zinderneuf
One-on-One
Pinball Construction Set
Seven Cities of Gold, The
Super Boulder Dash
Timothy Leary's Mind Mirror
Will Harvey's Music Construction Set
Formaster Copylock
Contains a sector with errors, usually at at sector 20, side 0, sector 5. The sector ID is marked as having 256 bytes, but actually has 512 bytes, fooling copiers like TeleDisk. Used mostly by Sierra. This protection will probably fail at speeds greater than an AT (8MHz 80286)
B.C.'s Quest for Tires (regular version)
Blockbuster (Second release)
Computer Baseball
Crossfire (IBM PCjr floppy disk version)
Gato (Versions 1.0-1.3)
Hardball (Disk 2/EGA Disk, early version only)
King's Quest (IBM PC-CGA version)
Mr. Cool
Paperboy (Second release)
Pinball Wizard
Oil's Well
Quink
Sierra Championship Boxing (1984 version)
Top Gun
Troll's Tale
Ultima II (1983, 1984 versions)
Ultima III (1984, 1985 versions)
Wizard and the Princess, The (IBM PCjr version)
H.L.S. Duplication
Accolade and Epyx used this type of protection. There is an additional sector ID field in one of the sectors.
Ajax
Bad Dudes
Boot Camp
California Games
Gauntlet (later version)
Grand Prix Circuit (early version only)
Hardball (Disk 1 only)
Mini-Putt
Rush 'n' Attack
Test Drive
Test Drive II
Microprose Protection 1
Protection is found on track 4, side 0. Uses overlapping sectors.
Gunship (certain versions)
Sid Meier's Pirates
Microprose Protection 2
Protection is found on tracks 38-39, side 0. Uses overlapping sectors.
Airborne Ranger
Dr.Doom's Revenge
F-15 Strike Eagle II
F-19 Stealth Fighter
M1 Tank Platoon
Sid Meier's Pirates (432.02 and above)
Red Storm Rising
Rick Dangerous
Savage
Stunt Track Racer
Sword of the Samurai
X-Men
Mindscape DEM
This protection will probably fail at 386 speeds (16MHz and above)
Inflitrator 2
Italy '90
Paperboy (early version)
Minder03
Used by Prism Software
Pipe Dream (European version, U.S. version by LucasFilm Games used a Codewheel)
Non-standard Sector Sizes
Probably the earliest method of copy protection. Self-explanatory, can easily be copied with TeleDisk.
Adventure in Serenia
Agent USA
Arkanoid (Imagine version) & Super Tennis
Below the Root
Gremlins
Jungle Hunt
King's Quest (IBM PCjr. version)
Microsoft Flight Simulator v1.00
Sid Meiers' Pirates! v432.03
Pitstop II
Trains (DOS version)
World Games
On-Line Systems Protection #1
Frogger
Ulysses and the Golden Fleece
Origin Systems OSI-1
Used by all Origin Systems games with an EXE executable.
Ultima I: The First Age of Darkness
Ultima II: Revenge of the Enchantress (Ultima Trilogy version only)
Ultima IV: Quest of the Avatar
Ultima V: Warriors of Destiny
Rob Northern Copylock
Uses weak bits and calculates the entropy expected. Encrypts the actual executable and stores a 32-bit decryption number on a bad sector.
Frank Bruno's Boxing (Compilation version)
Lemmings
Oh No! More Lemmings (comes in disk-based and document-based versions)
Paperboy (later version)
Xenon II
Sector ID Duplication
Sierra used this for the versions of their games distributed under Tandy's label prior to 1985. In this scheme, there are multiple sectors with identical Sector IDs, but different data. Subsequent read sector commands will read the later sectors.
BC's Quest for Tires (Tandy version)
King's Quest (Tandy version)
Softguard 2.x/3.x with original loader
Found mostly in Taito games. Works like Sierra's version, but with a different loader that is harder to decrypt. The file CMLxxxx.FCL will be present.
Arkanoid
Arkanoid II: Revenge of DOH
Bubble Bobble
Operation Wolf
Puzznic
QIX
Rambo III
Rastan
Renegade
Sky Shark
Ultima II (1985 version)
Softguard 2.0.3 with Sierra's Loader
This protection was used in Sierra's games. It relied on a track with non-standard sector sizes, overlapping sectors, CRC errors in the sector data field There is a hidden file called CPC.COM on the first disk that checks for the protection. All these games could be installed to a hard drive, but required the first disk, the key disk, to be inserted in a floppy drive. Police Quest: In Pursuit of the Death Angel, was the only AGI version 2 game that never seemed to be protected. This protection was applied to both booter and DOS games.
3-D Helicopter Simulator
Black Cauldron, The (AGI version 2)
Donald Duck's Playground
King's Quest I: Quest for the Crown (AGI version 2)
King's Quest II: Romancing the Throne (AGI version 2)
King's Quest III: To Heir is Human
Leisure Suit Larry in the Land of the Lounge Lizards (AGI version)
Mixed-Up Mother Goose (AGI version)
Sierra Championship Boxing
Space Quest: The Sarien Encounter (AGI version)
Space Quest II: Vohaul's Revenge
Thexder
Weak Bits Generic Implementation
Typically done by using more than three 0 bits following a 1 bit in violation of MFM encoding rules.
After Burner
Block Buster
Blood Money
Bop'N' Wresting
Boulder Dash II
Gauntlet (Early version)
Ghosts 'n Goblins
Harrier Combat
Horror Zombines From The Crypt
Lemmings 2: The Tribes (used HD media)
Outrun
Rick Dangerous II
Shadow Gate
Shinobi
Space Harrier
Waydisk Minder
This protection will probably fail at greater than IBM AT (8MHz 286) speeds
4 Soccer Simulators
AM, FM Tivia Vol. 2
Arac
Boulder Dash 2
Football Manager
Frank Bruno's Boxing
World Championship Soccer
XELOK/XEMAG
Used mainly by Broderbund. Has 16 sectors instead of 8 on track 9, side 0.
Oo-Topos
Ultima III (Ultima Trilogy version)
Sargon 3
V. Hardware Based Backup Methods
There are several programs that rely purely on the floppy disk controller to try to make a working backup, including Teledisk, ImageDisk, CopyIIPC & Snatchit. None of them is a perfect solution. TeleDisk did not take every PC protection method into account, but its great to write images with non-standard sector sizes. ImageDisk is a newer program and doesn't have that many disk images available for it, but it too is bound by the limitations of the PC disk controller. CopyIIPC and Snatchit only work on 100% compatible IBM PCs (no Tandy 1000s or PCjr.s), do not work at high 386 speeds or faster and potentially will modify the data on the disk image to crack the program.
The closest thing that was available back in the 1980s that could copy anything was Central Point Software's Deluxe Option Board. This was a hardware ISA card that intercepted the signals between the disk drive and disk controller. Because it operated on the flux transition level, it could theoretically copy anything from a double density disk. It could write bad CRCs, overlapping sectors, interleaved sectors and data in the gap bytes. This board used a program called TransCopy. TransCopy could save an image of a disk for future rewriting. 360KB disks would have an image that would be 1,088KB in size.
TransCopy was not without its flaws. The non-Deluxe Option Board could only work with TransCopy versions 4.x or earlier. TransCopy versions below 5.x would not copy 80 track disks, inlcuding 720KB disks. TransCopy images made with version 5.x would not work with earlier TransCopy versions. TransCopy would also be crippled so that it would not work with certain protections, depending on which company was threatening CPS with litigation at the time. You would need to hope that an earlier version of TransCopy would work. Copy Copylock II will not be able to written back with an Option Board or Deluxe Option Board.
The modern equivalent of the TransCopy board are the Kryoflux and SuperCard Pro. In the PC context, KryoFlux will create raw stream files of each track. There are utilities that can convert these raw stream files to TransCopy or TeleDisk formats. It can now write back raw stream files, so you no longer need to send your disk to the SPS and get an IPF file. However, writing back raw stream files is not fully reliable because it does not account for fluctuations in drive rotation speed and imperfections in the signal, possibly leading to signal loss similar to copying analog tapes. There are unsupported utilities to make your own IPF files, but it appears that unless you know the stream format well, you may not be able to write back a working disk. SuperCard Pro does the same thing but contains everything in one file. The two formats require conversion.
