Chip-8 on the COSMAC VIP: The Character Set – Laurence Scotford

submited by
Style Pass
2024-04-28 11:00:05

This is part of a series of posts analysing the Chip-8 interpreter on the RCA COSMAC VIP computer. These posts may be useful if you are building a Chip-8 interpreter on another platform or if you have an interest in the operation of the COSMAC VIP. For other posts in the series refer to the index or instruction index.

The only means of getting data onto the Chip-8 display is using the DXYN instruction to display a sprite. So Chip-8 has a character set, consisting of all the hexadecimal digits, in which each digit is stored as a pre-defined sprite, allowing the programmer to use the DXYN instruction to display these.

The character set sprites are stored in the ROM. Each character is just four pixels wide. As Chip-8 sprites are one byte wide, the characters are aligned to the left side of the sprite and the rightmost four pixels of the sprite are set to 0. Each character is five pixels high. If they were stored in a linear fashion, this would require 80 bytes of memory (16 characters, each consuming 5 bytes). Today we wouldn’t worry about losing 80 bytes any more than we’d worry about a penny that slipped through our fingers and rolled down a drain. However, when your ROM is only 512 bytes, every byte suddenly becomes significant. So the Chip-8 character set sprites were designed in such a way that the data for some characters overlaps. Here’s what that looks like:

This little trick cuts the space requirement from 80 to 51 bytes. Of course the advantage of having the characters stored linearly, with each occupying its own five-byte space, would be that you could calculate the start address of a sprite simply by multiplying the required digit by five and adding this to the base address. With the sprites compressed the way they are in the COSMAC VIP that’s not an option, so the ROM also contains a look-up table with the low-order byte of the address of each sprite. This adds an overhead of 16 bytes. Even so, this still saves 13 bytes over the standard way of doing things. That doesn’t sound like it would be worth the effort until you realise that 13 bytes is 2.5% of the total ROM! This really is a case of having to make every byte count.

Leave a Comment