How Did the Commodore VIC-20 Handle Sprite Collisions

The Commodore VIC-20 did not feature hardware sprites or dedicated hardware collision detection registers like its successor, the Commodore 64. Instead, game developers relied on software-based methods to simulate movable objects and detect interactions between them. This article explores the technical limitations of the VIC-20’s video chip, explains how programmers created software sprites using character blocks, and details the logic used to calculate collisions within the system’s memory map.

Hardware Limitations of the VIC Chip

The VIC-20 utilizes the MOS Technology 6560 or 6561 Video Interface Chip (VIC), depending on the region. Unlike the later VIC-II chip found in the Commodore 64, the original VIC chip lacks independent hardware sprite capabilities. Hardware sprites are movable graphic objects managed directly by the video chip, which can also automatically flag when two sprites or a sprite and a background pixel overlap. Because the VIC-20 lacks this circuitry, it cannot generate sprite collision interrupts or store collision status in a register. All movement and interaction logic must be handled by the main CPU, the MOS 6502.

Simulating Sprites with Character Blocks

To create movable objects, programmers utilized the VIC-20’s character-based graphics mode. The screen is organized into a grid of 22 columns by 23 rows. Developers would define custom characters in memory that resembled game entities, such as players, enemies, or projectiles. By rapidly changing the screen memory codes corresponding to specific grid positions, these character blocks could be made to appear as if they were moving across the display. This technique is often referred to as “software sprites” or “charsets,” though they are significantly less flexible than true hardware sprites due to the fixed grid resolution.

Software Collision Detection Logic

Since the hardware does not detect overlaps, collision detection must be performed through software checks during the game loop. The most common method involves monitoring the screen memory addresses associated with the moving objects. Before moving a character block to a new position, the program calculates the target memory address. It then checks the value currently stored at that address. If the value represents a solid background object or another game entity, the program registers a collision.

Another method involves tracking the X and Y coordinates of each object in variables stored in the system’s RAM. The CPU compares these coordinates mathematically to determine if the boundaries of two objects intersect. For example, if the horizontal and vertical positions of a player’s character block fall within the same range as an enemy’s block, the game logic triggers a collision event. This process requires careful optimization to ensure the game maintains a playable frame rate, as the 6502 processor must handle both the game logic and the screen updates without hardware assistance.

Performance Implications

The reliance on software collision detection and character-based movement places a heavy burden on the VIC-20’s processor. Complex games with multiple moving objects risk slowing down because the CPU must constantly update screen memory and perform collision checks for every frame. Consequently, VIC-20 games often feature fewer on-screen objects and simpler mechanics compared to later 8-bit computers. Despite these constraints, developers managed to create engaging titles by optimizing assembly code and designing game mechanics that worked within the strict limitations of the hardware architecture.