Commodore Plus/4 Keyboard Response Time and Scan Rate

This article provides a technical overview of the input latency and scanning mechanism associated with the Commodore Plus/4 keyboard. It examines the hardware architecture that dictated key registration speeds, compares the typing experience to contemporaries like the Commodore 64, and clarifies the specific response capabilities inherent to the system’s design.

When discussing the response time of the Commodore Plus/4 keyboard, it is important to understand that specific millisecond latency figures were not standardized marketing specifications in the 1980s home computer industry. Unlike modern peripherals that advertise response times in milliseconds, the Plus/4’s keyboard performance was dictated by the system’s central scanning routine. The keyboard matrix was polled by the computer’s operating system, typically synchronized with the video vertical blank interrupt. This means the theoretical maximum response time was bound by the screen refresh rate, resulting in a latency window of approximately 20 milliseconds on PAL systems and 16.6 milliseconds on NTSC systems before a key press was even detected by the CPU.

The Commodore Plus/4 featured a full-travel, typewriter-style keyboard, which was a significant departure from the flat chiclet keys found on the popular Commodore 64. While the physical actuation point and key travel distance contributed to a faster subjective typing experience for many users, the electronic response remained tied to the 7360 TED chip’s interrupt cycle. The keyboard matrix consisted of an 8x8 grid, and the KERNAL ROM routines scanned this grid during the vertical blanking interval to prevent visual interference on the display. Consequently, the effective response time was consistent with the frame rate of the connected monitor rather than a dedicated high-speed input buffer.

Users often reported that the keyboard felt more responsive than other Commodore machines of the era, primarily due to the mechanical quality of the switches rather than electronic latency improvements. However, the system was not immune to input lag if the software did not poll the keyboard buffer efficiently. Games and applications that relied on direct hardware scanning could achieve slightly faster reaction times than those relying on the standard operating system queue, but the hardware limitation of the video sync remained the primary bottleneck. Ultimately, while no official millisecond spec exists, the response time is technically defined by the 50Hz or 60Hz scan rate inherent to the machine’s video architecture.