Part 2: How CPUs read machine code

What this lecture covers

Building on the bare 6502 from part 1, this lecture replaces hard-wired no-op instructions with a programmable EEPROM, so the processor can finally fetch real, changeable instructions. It walks through address decoding, why only half of the address space is used for ROM, and how the 6502's reset vector tells the processor where a program starts.

The second half introduces the 65C22 Versatile Interface Adapter (VIA), a companion chip that lets the processor talk to the outside world through latched output ports. By the end, the circuit runs a small hand-written machine code program that writes alternating bit patterns to eight LEDs in a loop, the first genuinely interactive output from the build.

Key ideas

• EEPROM address decoding: because the 28C256 EEPROM has 15 address lines but the 6502 has 16, the top address line (A15) is used to enable the chip only for the upper half of the address space, so the reset vector at $FFFC/$FFFD lands inside the ROM.
• Chip enable via NAND-as-inverter: a NAND gate with its inputs tied together acts as an inverter, turning A15 into an active-low chip-select signal for the EEPROM.
• Little-endian addresses: the 6502 stores 16-bit addresses low byte first, so a jump target of $8000 is written in the program as bytes 00, 80.
• Writing vs. reading on the bus: the processor uses the same address and data lines for both instruction fetches and data output, so writing to an address is only meaningful if some hardware is listening at that address.
• Address decode + latch: any output device needs decode logic to recognize its address and a latch to hold the data after the processor moves on, which is exactly what the 65C22 VIA provides.
• Data direction registers: each pin of the VIA's port A and port B can be individually configured as input or output by writing a bitmask to a data direction register before using the port.
• Register select lines: four register-select pins on the VIA, driven from the low address bits, choose which of its 16 internal registers (such as port B or its data direction register) the processor is addressing.
• Address space trade-offs: the decode logic deliberately ignores several address bits, wasting address range but saving logic gates, a cost/complexity trade-off the lecture treats as a real engineering decision.

Walkthrough

Wiring the EEPROM into the address and data bus (1:00)

The 28C256 EEPROM's 15 address lines are connected to the processor's A0-A14, and its 8 data lines to the processor's data bus. Because the EEPROM only covers half the 6502's address range, its chip-enable pin is wired through an inverted A15 so that it only responds to addresses $8000 and above, keeping the reset vector inside programmable memory.

Programming the EEPROM with Python and testing no-ops (8:00)

A short Python script builds a 32,768-byte ROM image filled with the no-op opcode $EA and writes it with an EEPROM programmer. Single-stepping the clock (monitored again through the Arduino from part 1) confirms the processor reads the reset vector from the EEPROM and starts fetching no-ops from $8000 onward, reproducing part 1's behavior but from real memory instead of hard-wired resistors.

Writing a first real program: load and store (15:09)

Using the 6502's opcode table, the lecture builds a tiny program: LDA #$42 (opcode A9) loads a value into the accumulator, then STA $6000 (opcode 8D) writes it to an address. Single-stepping shows the processor set the address bus to $6000 and drive the value $42 onto the data bus itself, rather than reading it, which raises the question of what, if anything, is listening at that address.

Introducing the 65C22 VIA for output (22:10)

The lecture explains that any output device needs address-decode logic plus a latch, and introduces the 65C22 VIA as a chip that provides both, alongside ports A and B, register-select lines, and a data-direction register per port. Wiring covers chip-select logic built from NAND gates (reusing one already used for the EEPROM), the clock, read/write, reset, data bus, and register-select lines tied to the low address bits.

Configuring port B and driving LEDs (37:25)

Eight LEDs are wired to VIA port B. The program is rewritten to first write $FF to the data direction register (address $6002) to set all of port B's pins as outputs, then alternately store $55 and $AA to port B (address $6000) with a jump instruction looping back, producing an alternating LED pattern.

Assembling, reprogramming, and verifying step by step (43:28)

After fixing a Python syntax error, the final ROM image is inspected as a hex dump, reprogrammed onto the EEPROM, and run. The LEDs immediately flip between the two bit patterns. The lecture then reconnects the Arduino monitor and single-steps through the whole program once more, confirming each load, store, and jump instruction against what appears on the address, data, and read/write lines.

Before you watch

• Watch part 1 first for the basic 6502 pinout, clock wiring, and reset-vector behavior this video builds on.
• Comfort reading hexadecimal and binary values, and following an opcode table, is assumed.
• Basic familiarity with NAND gates as logic building blocks is useful for the address-decode sections.

Check your understanding

1. Why does the EEPROM only respond to the upper half of the 6502's address space, and how does that keep the reset vector inside ROM?
2. What two things does any output device connected to the 6502's bus need, and which chip provides both in this build?
3. Why must the data direction register be configured before writing meaningful output to VIA port B?
4. Explain why the program's jump target and the reset vector bytes appear "backwards" in the ROM image.
5. What trade-off does the lecture describe in choosing not to decode every address bit for the VIA's chip select?