If you’re managing data structures, looping through arrays, or setting up pointers, you’ll frequently want to move index values into memory — and that’s where these instructions come in.

What Do STX and STY Do?

Both instructions work exactly like STA, but they store the contents of the X or Y register instead of the accumulator.

They are purely output instructions — they move a value from a register into a given memory location.

Supported Addressing Modes

Notice:

• STX supports Zero Page, Y
• STY supports Zero Page, X
• Neither supports absolute,X/Y or indirect modes
• And like STA, no immediate mode

Flags Affected

None.
Just like STA, these instructions do not modify any status flags.

Example Usage

LDX #$FF
STX $D020      ; Set C64 border color using X register

LDY #$12
STY $C0        ; Store Y into zero page memory

LDX #$33
STX $0200,Y    ; Not valid! STX does not support (abs),Y

Indexed zero page example:

LDY #$02
LDX #$A0
STX $10,Y      ; Store X at address $12

Common Pitfalls

• Misunderstanding addressing support.
  STX and STY are more limited than STA. If you need flexible addressing, move the value into A and use STA.
• Trying to use STX/STY with absolute,X/Y.
  These modes are not valid with STX or STY.

Summary

STX and STY are crucial for saving index values to memory:

• Store the contents of the X or Y register
• Support zero page, indexed zero page, and absolute addressing
• Don’t affect CPU flags
• Great for setting up buffers, counters, and memory-mapped I/O

Combined with STA, these instructions give you full control over writing all main registers to memory.

After learning how to load values into the accumulator using LDA, it’s time to store them back into memory. That’s exactly what the STA instruction does.

Where LDA is about input, STA is about output. It allows your 6502 program to write the value currently held in the accumulator (A) to a specific memory address.

What Does STA Do?

STA takes the value in the accumulator and writes it to a memory location. That location is specified using one of several addressing modes.

This is essential when you want to:

• Update variables
• Write to memory-mapped hardware (like screen RAM or I/O)
• Store intermediate results for later use

Supported Addressing Modes

Unlike LDA, STA does not support the immediate mode — because you can’t store to a literal value.

Here are the valid modes:

Flags Affected

None.
STA does not modify any status flags — not even Zero or Negative.

This makes sense: you’re writing data, not interpreting it.

Example Usage

LDA #$41       ; Load ASCII 'A' into accumulator
STA $0400      ; Write it to screen memory at $0400

LDA #$00
STA $D020      ; Set border color on the C64

Or, with indexed addressing:

LDX #$05
LDA #$FF
STA $0200,X    ; Store $FF at address $0205

Indirect addressing:

LDA #$3C
STA ($20),Y    ; Store A to address pointed to by $20 + Y

Common Pitfalls

• Forgetting that STA doesn’t affect flags. If you plan to branch based on the accumulator value, test it before the STA.
• Using STA #$44 — this is illegal. You can’t store to an immediate value!
• Misusing indirect modes. STA ($20),Y looks up a pointer from zero page $20, adds Y, and stores the value.

Summary

STA is the simplest way to send data from your CPU into memory — and that includes writing to hardware like video, sound, or I/O chips.

Key takeaways:

• Stores accumulator content into memory
• Supports all basic addressing modes except immediate
• Does not modify any flags
• Essential for output, memory updates, and I/O access

With LDA and STA, you have the fundamental load-store mechanism of the 6502 down. Next up, we’ll explore storing other registers: STX and STY.

In the 6502 instruction set, LDX and LDY are the counterparts to LDA. While LDA loads a value into the accumulator, LDX and LDY load values into the index registers X and Y, respectively.

These index registers are used for addressing, iteration, and temporary storage in a wide variety of programming scenarios. Understanding how to load them efficiently is crucial for tight, readable, and performant 6502 code.

What Do LDX and LDY Do?

• LDX loads a value into the X register
• LDY loads a value into the Y register

Both instructions support several addressing modes and affect two status flags: Zero (Z) and Negative (N).

Supported Addressing Modes

LDX

LDY

Note: Indexed Absolute modes can take one extra cycle if a page boundary is crossed.

Flags Affected

Just like LDA, both LDX and LDY affect:

• Zero Flag (Z): Set if the loaded value is 0
• Negative Flag (N): Set if the high bit (bit 7) is set

Other flags remain unchanged.

Practical Examples

Load X Register

LDX #$0A      ; Load constant 10 into X
LDX $20       ; Load value from zero page address $0020
LDX $1000,Y   ; Load value from $1000 + Y

Load Y Register

LDY #$FF      ; Load constant 255 into Y
LDY $D000,X   ; Load value from $D000 + X

These instructions are often used for:

• Setting up offsets for indexed memory access
• Loop counters and decrement operations
• Calling JSR routines that expect parameters in X or Y
• Configuring sprite data or screen memory locations

Typical Usage Patterns

LDX #$00
LOOP:
  LDA message,X
  BEQ done
  STA $0400,X
  INX
  JMP LOOP
done:

In this example, LDX is used to walk through a string and copy it to screen memory. A classic use case for the X register.

Common Pitfalls

• Using the wrong indexed mode (e.g., LDX $10,X → invalid!) — LDX only supports Zero Page, Y and Absolute, Y
• Assuming LDX and LDY behave exactly like LDA — their indexed modes differ
• Forgetting that setting flags can affect branching after a load

Summary

While LDA is used to manipulate data, LDX and LDY are your tools for managing control and structure. They’re essential when looping through data, accessing arrays, or working with hardware registers.

Key takeaways:

• Both instructions support immediate, zero page, and absolute modes
• LDX uses Y as an index for zero-page; LDY uses X
• Flags Z and N are always updated based on the loaded value

Together, LDA, LDX, and LDY form the foundation of memory access on the 6502. Master these three, and you’re well on your way to becoming fluent in low-level 6502 programming.

Understanding LDA is a great starting point for learning how the 6502 interacts with memory and how addressing modes work.

What LDA Does

At its core, LDA performs one simple task:
It loads a value into the accumulator (A).

But depending on the addressing mode, the source of that value can vary:

• A constant value (immediate)
• A memory location (zero page, absolute)
• A computed address (indexed, indirect)
  

Each variation has its own binary opcode and CPU cycle cost.

Supported Addressing Modes

Here are all the addressing modes that LDA supports:

Note: Modes marked with (+1) may require an extra cycle if a page boundary is crossed.

Flags Affected

Executing LDA updates two status flags:

• Zero Flag (Z): Set if the loaded value is 0
• Negative Flag (N): Set if the high bit (bit 7) of the value is set (i.e., if the value is negative in two’s complement)
  

No other flags are affected.

Example: Loading a Constant

LDA #$42

This loads the hexadecimal value $42 into the accumulator. The Z and N flags are updated accordingly.

Example: Reading from Memory

LDA $0400

Loads the value stored at address $0400—which happens to be the start of the C64’s screen memory—into A.

If used in a loop, this kind of instruction is ideal for reading and modifying blocks of memory.

Example: Using Indirect Addressing

LDA ($10),Y

This is a powerful form of pointer-based memory access. It allows you to store a base address at $10/$11, and then offset it with Y. This is often used for accessing tables or sprite data.

Common Pitfalls

• Forgetting that only Z and N flags are affected. If you’re branching based on carry or overflow after LDA, you’ll get misleading results.
• Not accounting for the extra cycle on page crossings in Absolute,X and Indirect,Y modes. This matters for cycle-accurate code like raster interrupts or real-time effects.
  

Summary

LDA is essential to nearly all 6502 programs. It’s how you get data into the accumulator to do something useful—whether that’s math, logic, display updates, or system calls.

Once you understand how LDA works across all addressing modes, you’ve unlocked a fundamental part of 6502 programming. The next steps? Explore its siblings LDX and LDY, and learn how the 6502 transfers and manipulates data across registers.

If you’re new to programming the 6502 microprocessor—or revisiting it from the world of modern computing—one of the first terms you’ll encounter is the opcode. This blog post lays the foundation for the rest of the series by explaining what opcodes are, how they relate to the 6502’s architecture, and why understanding them is key to mastering the platform.

What Is an Opcode?

An opcode (short for operation code) is a single byte of machine code that tells the processor what operation to perform. The 6502 has 151 documented opcodes, each representing a specific instruction like loading a value into a register, adding two numbers, or jumping to another location in memory.

Example:

• $A9 is the opcode for LDA with immediate addressing (Load Accumulator with a constant value).

Every instruction the CPU executes starts with an opcode. Some are followed by operands (data or addresses), depending on the instruction and the addressing mode.

Opcodes and Addressing Modes

The same instruction—like LDA—can have different opcodes depending on how it accesses memory. The 6502 supports a variety of addressing modes, including:

• Immediate: LDA #$10 → load the value $10
• Zero Page: LDA $00 → load from address $0000
• Absolute: LDA $1234 → load from full 16-bit address
• Indexed: LDA $20,X → add X to the base address
• Indirect: for instructions like JMP

Each variant has its own opcode byte. For example:

• LDA #$10 → $A9 10
• LDA $10 → $A5 10
• LDA $1234 → $AD 34 12

So when we say “the 6502 has 151 opcodes,” we’re counting instruction + addressing mode combinations, not just the instruction names.

The Structure of a 6502 Instruction

A typical instruction has this structure:

[Opcode] [Operand (0–2 bytes)]

[Opcode] [Operand (0–2 bytes)]

Examples:

• CLC (Clear Carry) → one byte: $18
• LDA #$42 → two bytes: $A9 42
• JMP $1234 → three bytes: $4C 34 12

The number of bytes used and the number of CPU cycles required to execute the instruction depends on the addressing mode.

Why Learn Opcodes?

Understanding opcodes gives you low-level control over the CPU. This knowledge allows you to:

• Optimize code for speed and size
• Write routines for graphics, sound, and input
• Build emulators, disassemblers, and debuggers
• Understand what’s really going on beneath a BASIC program

Even when using an assembler that lets you write LDA #$10, it’s the opcode $A9 that gets assembled and stored in memory.

What’s Next in the Series?

This post is the beginning of a journey through every single 6502 opcode. In the upcoming entries, we’ll group instructions by functionality—such as loading data, arithmetic, branching, and stack operations—and break them down in detail.

Each post will include:

• Instruction description
• Addressing modes
• Effects on flags
• CPU cycles
• Practical examples

Stay tuned, and let’s start unlocking the power of the 6502—one opcode at a time.

The 6502’s 16-bit Address Space

The 6502 microprocessor at the heart of the C64 has a 16-bit address bus, which allows it to address 2¹⁶ = 65,536 bytes (64KB) of memory. This entire memory space is shared between RAM, ROM, I/O registers, and special-purpose areas like zero page and stack.

Key Memory Regions on the C64

Here’s a breakdown of the most important memory regions:

Bank Switching and Memory Control

The C64’s memory map is more flexible than it seems, thanks to bank switching. Certain regions (especially $A000-$BFFF, $D000-$DFFF, and $E000-$FFFF) can be switched between RAM and ROM (or I/O) by writing to the processor port at address $0001.

This allows, for example:

• Replacing BASIC ROM with RAM for custom code.
• Temporarily disabling I/O to access the underlying RAM at $D000-$DFFF.

Zero Page and Stack

The zero page is a special 256-byte memory region ($0000-$00FF) with optimized access: many 6502 instructions support special addressing modes for it, resulting in faster and smaller code.

The stack is fixed at page 1 ($0100-$01FF) and used for subroutine calls, interrupts, and manual pushing/popping of data.

I/O and Peripherals

Memory-mapped I/O registers reside at $D000-$DFFF, controlling:

• VIC-II (graphics)
• SID (sound)
• CIA chips (timers, I/O ports)
• Color RAM (at $D800-$DBFF, though not part of main RAM)

Final Thoughts

Understanding the C64’s memory layout is key to effective programming. While the 64KB may seem limited, careful planning and use of bank switching, zero page, and hardware registers allows for surprising complexity and performance.

Whether you’re writing assembly, optimizing BASIC routines, or building your own emulator, mastering this map is your first step toward truly understanding the C64’s architecture.

So there we are. My blog about my project, the 6502 simulator. And surely you’re wondering why? Why another 6502 simulator?
Just look at the

‘So Why…‘ section

What am I going to write about here?
– about the progress of the project
– new versions and releases
– screenshots
and maybe more. Let’s see.

Go to this page

Why Separate Memory from CPU Logic?

At a hardware level, the 6502 CPU doesn’t own memory – it communicates with memory-mapped peripherals and RAM through the system bus. Mirroring that in your code makes your emulator more accurate, modular, and testable.

Benefits of separating the CPU from memory:

• Cleaner abstraction: The CPU should only know how to read and write bytes, not where they come from.
• Peripheral integration: You can easily map memory addresses to I/O devices (e.g., screen, keyboard, VIA, etc.).
• Bank switching: Dynamic memory mapping becomes trivial with a proper bus.
• Testing: You can mock memory for unit testing the CPU without dragging the entire system along.

A Simple Bus Interface

Start by defining a bus interface:

public interface IMemoryBus
{
    byte Read(ushort address);
    void Write(ushort address, byte data);
}

public interface IMemoryBus
{
    byte Read(ushort address);
    void Write(ushort address, byte data);
}

CPU only interacts with this interface:

public class CPU
{
    private readonly IMemoryBus _bus;

    public CPU(IMemoryBus bus)
    {
        _bus = bus;
    }

    public void ExecuteNextInstruction()
    {
        ushort pc = /* fetch program counter */;
        byte opcode = _bus.Read(pc);
        // decode & execute
    }
}

public class CPU
{
    private readonly IMemoryBus _bus;

    public CPU(IMemoryBus bus)
    {
        _bus = bus;
    }

    public void ExecuteNextInstruction()
    {
        ushort pc = /* fetch program counter */;
        byte opcode = _bus.Read(pc);
        // decode & execute
    }
}

Modeling your emulator with a decoupled bus architecture brings your code closer to real hardware behavior. It simplifies future expansion and makes the CPU a truly generic component – unaware of the memory layout or even what devices are attached.
If you’re serious about maintainability and hardware accuracy, decoupling CPU and memory isn’t just good style – it’s essential.