Writing a computer game has always been hard. It is only the nature of the difficulty that changes. A modern game is as much about graphics, sound, and storytelling as it is about programming. But in the early days of computers, writing a game was a challenge because of limited graphics, slow CPUs, and tiny memory capacity. If you wanted to write a game for an early microcomputer, you generally wrote it in something like Python, where the interpreter readsproach that was particularly attractive when memory and processor cycles were precious: threaded code
In a threaded-code interpreter, a program consists of references (like indices into a command table) to routines that perform operations. Instead of decoding complicated instructions, the interpreter follows these references, executing the corresponding routines. There are several variations, including direct threading, indirect threading, and token threading. Forth is probably the best-known example of a language that commonly uses threaded code. In a typical Forth implementation, a program is compiled into a sequence of references to words, and a compact inner interpreter executes them.
Why bother? Because the implementation can be remarkably small. Instead of generating native machine code, a compiler can produce a compact representation that is relatively easy to execute. CHIP-8 belongs to the same general family of ideas, although it is more accurately described as a bytecode interpreter than a conventional threaded-code system. Its instructions are two bytes long, and the interpreter decodes each instruction and executes the corresponding operation. The original implementation was written in RCA 1802 machine code.
History Of CHIP-8
CHIP-8 made programming the VIP considerably easier, especially for games. Rather than dealing with the peculiarities of the 1802 and the VIP’s display hardware, programmers could use a small, consistent instruction set designed around graphics and keypad input.
The CHIP-8 virtual machine provides sixteen 8-bit registers, conventionally named V0 through VF. It also has a 16-bit index register, a program counter, a stack for subroutine calls, and two timers.
The display is 64 pixels wide and 32 pixels high. Pixels are either on or off. There’s no color, no hardware sprites, and no sophisticated graphics processor. There are, however, instructions specifically intended to make games easier to write. You can draw a sprite with a single instruction, test whether a key is pressed, generate a random number, and use timers to control animation.
A sprite is simply a sequence of bytes, with each bit representing a pixel. A typical sprite can be up to eight pixels wide and fifteen pixels high. The instruction set is tiny, with only a few dozen basic operations. Yet it is sufficient to implement games such as Pong, Breakout, and Space Invaders-like shooters.
CHIP-8 subsequently appeared on other systems, and later variants extended its capabilities. The best-known extension is Super-CHIP, which added features including higher-resolution graphics. Today, CHIP-8 survives largely because it is an excellent target for emulator projects. Writing a CHIP-8 interpreter is a manageable exercise, and there are thousands of small programs available to test one. But you don’t need to write an interpreter to experiment with CHIP-8.
