Lecture 22: Fixing a Hardware Bug in Software (65C51 UART)

What this lecture covers

The lecture finishes wiring the 6551 UART into working software, showing how to initialize its control and command registers and use its status register to send and receive bytes. It follows directly from the previous video's hardware wiring of the UART and address decoding.

Partway through, the lecture hits a genuine hardware bug in the modern-production 65C51 chip and shows the process of diagnosing it against the datasheet, comparing behavior against an older original chip, and writing a software workaround. You come away understanding not just UART register programming but also how to debug when the hardware itself is wrong.

Key ideas

• Status register flags: the transmit-data-register-empty and receive-data-register-full bits tell software when it is safe to write the next byte to send or when a received byte is ready to read.
• Overrun and framing errors: the status register also reports if a received byte was overwritten before being read, or if a framing or parity error occurred, so errors can at least be detected.
• Control register: sets stop bits, word length, and baud rate in one byte; the lecture configures 8 data bits, no parity, one stop bit, and 19,200 baud.
• Command register: configures parity mode, echo mode, and interrupt behavior; the lecture disables parity, echo, and interrupts for the simplest working configuration.
• Polling loop pattern: both sending and receiving use a loop that checks a status bit (AND with a mask, then branch) before proceeding, mirroring the pattern used for other status-flag checks in 6502 code.
• Real hardware bug: the Western Design Center-manufactured 65C51 always reports the transmit-data-register-empty bit as set, even mid-transmission, so code that waits on that flag proceeds too early and corrupts back-to-back sends.
• Datasheet versions as evidence: comparing an older (2007) and newer (2021) datasheet revision shows the newer one documents the "bug" as expected behavior and recommends a fixed delay instead of polling that bit.
• Cycle-counted delay workaround: a delay loop sized from the baud rate (accounting for start, data, and stop bits) reliably waits long enough for a byte to finish transmitting before the next one is sent.

Walkthrough

Recapping the wiring and removing the old bit-banged code (0:00)

The lecture reviews how the 6551's four registers are mapped to addresses $5000-$5003 and deletes the previous software-timed serial code, keeping only the LCD routines.

Understanding the status register (1:00)

The lecture walks through each status register bit, focusing on the transmit-data-register-empty and receive-data-register-full flags as the two needed for basic communication, and explains overrun, framing, and parity error bits as detectable failure signals. Writing any value to the status register is shown to reset the chip.

Configuring the control and command registers (6:01)

The control register is set to $1F for 19,200 baud, 8 data bits, one stop bit. The command register is set to $0B to disable parity, echo, and interrupts. This is the minimal configuration needed to get the UART running.

Receiving and echoing data (8:02)

A polling loop checks the receive-data-register-full bit, reads a received byte once available, and prints it to the LCD. Adding a send-character subroutine lets received characters be echoed back to the terminal, making typed input visible.

A message-sending bug traced to real hardware (13:05)

Sending a null-terminated greeting message fails silently. The lecture traces the failure to the transmit-data-register-empty bit always reading as set on the Western Design Center 65C51, even while a byte is still transmitting, causing the send loop to overwrite data before it finishes going out. Swapping in an original 1981-dated AMI 6551 chip confirms the same code works correctly, isolating the problem to the chip itself.

Confirming the bug against the datasheet and writing a workaround (19:09)

A newer datasheet revision documents that the flag is effectively unusable and recommends a fixed delay instead. The lecture computes a delay loop length from the 19,200 baud rate and 10 bit-times per byte (520 clock cycles at 1 MHz), adds it after each character send, and confirms the message now transmits correctly on the buggy chip.

Before you watch

• The previous video in this series, which wires the 6551 UART's data bus and address decoding.
• Familiarity with 6502 status-flag polling patterns (AND, BEQ/BNE) from earlier videos.
• Basic understanding of clock-cycle counting for timing, covered in the hardware-timer video.

Check your understanding

1. Why does the send-character subroutine need to wait for the transmit-data-register-empty flag before returning, in principle?
2. What evidence pointed to a hardware bug rather than a software bug in the message-sending code?
3. Why does the delay-based workaround need roughly 520 clock cycles rather than the 52 cycles of one bit time?
4. How did comparing an original 1981 chip with the modern reproduction help confirm the root cause?