Category Archives: Nintendo

Of or pertaining to the Big ‘N’

ROM “Images”

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:


Codemasters NES PCB

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.

NES Compression

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.


8-bit Nintendo Entertainment System

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:


NES Compression
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 0x56 vs. output 5 instances of 0x56 0x42); 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.

Survey Of GBA Coding Methods

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.


Game Boy Advance

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.

The Format Of Zelda

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.


ZeldaClassic

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.