Notepad time! (This is where I just use this blog as a piece of scratch paper for random investigations.)

Solar Jetman’s password entry screen

Reverse engineering the password system from an old NES game…

Read the rest of this entry »

I spent the vast majority of my junior high free time in front of a scratchy television connected to a Nintendo Entertainment System (NES) console. (Try not to act too surprised.) Many of the more involved Nintendo games either had battery-backed RAM on the cartridge PCB for saving games or employed a password system. The game would issue a password at various junctures in the game that you were expected to copy down accurately so that you could resume your game at a later time. Password lengths were commensurate with the complexity of the game and the amount of information required to represent a game’s state. For example, some games obviously had a table of plaintext 4- or 5-character passwords since the only information being saved was which of the game’s 8 levels the player has just passed. On the other end of the spectrum, the most complex password system I ever encountered was for Wall Street Kid, the groundbreaking stock market sim for the NES. It was a variable length password (at least 50 characters was nominal, if memory serves) with just about every letter of the English alphabet, upper and lower case, numbers, and various other symbols. I don’t think I ever successfully copied down a password for that game.

Wall Street Kid

Read the rest of this entry »

Here’s something from my personal archives that is of practial use to almost no one– a gallery of ROM images: http://multimedia.cx/nesgallery/. Technically, they are the printed circuit boards (PCBs) inside the actual NES cartridges. Much of the real estate inside a regulation NES cartridge went unused. I scanned these back when I used to be unusually interested in the technical workings of the classic 8-bit Nintendo Entertainment System and was maintaining a Linux-based NES emulator. Perhaps the most interesting speciman of the set is the PCB for the unlicensed game Bee-52 from Codemasters:

All PCBs for official, licensed games contain at least 3 chips: The PRG ROM (program), the CHR ROM (character/graphic data), and the CIC lockout chip (located next to PRG and CHR ROMs). The NES console had a piece of circuitry that interfaced with the CIC chip and the upshot is that the console refused to run a game cartridge if the CIC chip was not present. Nintendo held a patent on the CIC chip and was, for the most part, able to control which games could be manufactured for the console. Assorted ambitious game houses went the unlicensed route and developed various techniques to circumvent the CIC mechanism. That is what all those hacks on the Bee-52 PCB represent, in lieu of a CIC chip. Notice the switch on the PCB. That’s because when Nintendo rolled out a redesigned top-loading NES console, one of the cost reduction measures was to remove the console-side lockout circuitry. All licensed games continued to play. But it broke the vast majority of unlicensed titles. The switch allows the user to enable or disable the lockout-defeating measures.

Other interesting artifacts to note on the various PCBs are the stock TTL chips or custom mapper chips that games used to break through various limitations of the NES hardware, as well as shiny round batteries which indicate that the user is able to save their game in some RAM area also present on the PCB.

For budding computer geeks like myself, volume 20/January 1991 issue of Nintendo Power magazine (Mega Man III cover) was of particular interest. In this issue, the editors attempted to shed some light on the technical matters driving the 8-bit Nintendo Entertainment System and give insufferable know-it-alls further opportunity to truly know it all.

I still recall the puerile, simplistic explanation for compression using a metaphor every Nintendo nerd could relate to: Tetris! I still think about this article sometimes and wonder what compression method they used and for which games. In fact, I located the relevant article section and scanned it for your enjoyment/edification:

Click for larger image

I came across this document describing a compression algorithm used for a Zelda game on the Super NES, the direct successor to the NES, both market-wise and on a technical level. It seems that the scheme is largely a flexible RLE scheme which allows for decoding single- or double-byte runs (output 5 instances of byte 0×56 vs. output 5 instances of 0×56 0×42); decoding runs of an incrementing byte (e.g., output a sequence of 4 incrementing bytes starting with 0xA2: 0xA2 0xA3 0xA4 0xA5); and even using into the encoded buffer as a dictionary and copying runs from a specified index.

Sony’s PlayStation Portable and Apple’s video iPod are enjoying quite a bit of recognition by allowing users to view television shows and movies on their tiny screens. Some folks, however, think that Nintendo’s Game Boy Advance should share in the fun.

Naturally, the PSP and the iPod have a few advantages over the GBA in that they have gobs of storage capacity, either optical or HD-based, whereas the GBA is limited to a few dozen megabytes in ROM. Further, the PSP and iPod presumably have a little more processing muscle (though I do not know the respective specs off the top of my head). PSP and iPod are known to use MPEG-4 technologies for the video. What does the Game Boy Advance use?

Trixter tipped me off about a game cartridge entitled Game Boy Advance Video: SpongeBob SquarePants, Vol. 1. The ROM squeezes out 44 minutes of video. Trixter maintains that the video quality betrays characteristics of a vector quantizer codec. More Majesco GBA video titles can be found here.

What other video options are out there? Trixter pointed me to Caimans video codec for GBA. The website yields zero data about the underlying compression techniques. Further, the MPEG-like 4xm format is known to have been used in at least one GBA title– Britney’s Dance Beat.

I am still fascinated by the ZeldaClassic project, particularly when it comes to the possibility of creating an interoperable game engine to play the ZC data files.

Fortunately, the project has released some source code that writes out an unencoded quest file (extension .qsu). This divulges quite a few useful details. For greater context, there is the ZQuest editor that is packaged with the ZeldaClassic game which allows you to create qsu files and tweak existing ones. Further, PureZC has a Wiki that clarifies a lot of the technical details of the game’s data structures.

Anyway, I have started writing clear documentation for the qsu file format. Also, I have a sample C program that parses many of the data structures in such files.

I recently discovered Zelda Classic, a fascinating project to clone the classic Legend of Zelda game. This is what the original game looks like running in an emulator:

Why does anyone care? Look, it’s just a really cool game, okay?

These programmers created their own game engine and then cloned the original Zelda graphics for use in the game. But the real value-add is being able to create new quests, distribute them for others to play, and download other quests to play in the engine.

Read the rest of this entry »

The 8-bit Nintendo Entertainment System (NES) is my favorite video game console of all time. I even used to maintain a native Linux NES emulator named TuxNES to help preserve the nostalgia.

<– Simon vs. the undead fish monsters in Konami’s original Castlevania Link, the hope of Hyrule, takes on the Octoroks in the original Legend of Zelda –>

But I love these: Videos showcasing tool-assisted “Time Attacks”. The basic idea is that the people behind the videos use a variety of feature-rich console emulators to get through games very quickly using some very clever methods. Watching a video from start to finish usually lets you relive the experience of playing through the entire game, all in 10-20 minutes, nominally.

The video is encoded with the DivX codec; the frames are each 256×224 at 60 frames/sec (for NTSC games; 50 fps for PAL games). Audio is generally encoded as MP3 audio at 32-64 kbps. As a multimedia freak, I have to admit that it is a little frustrating to watch these videos which are typically encoded with ISO MPEG-4 (under the fourcc DIVX). So I started to wonder if it would be possible to develop a custom codec specifically for coding this type of video, and losslessly.

Read the rest of this entry »