Lecture 25: A Simple BIOS for My Breadboard Computer

What this lecture covers

The lecture prepares the breadboard 6502 computer to eventually run Microsoft BASIC by building a proper toolchain-driven ROM image, rather than a single hand-assembled file. It follows the earlier Wozmon-porting videos and precedes running BASIC itself.

You see how other 6502 computers expose simple "character in / character out" style routines at fixed addresses as a minimal BIOS, then build the equivalent for this computer using the cc65 assembler and linker, controlling exactly where code lands in ROM and where the reset vector points.

Key ideas

• BIOS as fixed-address routines: many 6502 systems (Commodore 64, Apple IIe) expose simple, hardware-specific input/output routines at known ROM addresses so higher-level software like BASIC can call them without knowing the underlying hardware.
• cc65 toolchain: ca65 is the assembler, ld65 is the linker; building from source requires switching Wozmon's .org address directives to instead be controlled by the linker.
• Relocatable object files: an assembled .o file is not directly executable ROM content; it retains label metadata so the linker can decide final addresses.
• Linker configuration file: describes the memory map (RAM and ROM regions, their start addresses, sizes, and read/write type) and which code segments load into which memory region.
• Custom segments for placement control: defining named segments (for example, a Wozmon segment and a reset-vector segment) lets you control exactly where each piece of code lands in the final ROM image, independent of assembly order.
• Reset vector placement: the 6502 always reads its start address from $FFFC/$FFFD, so the reset vector segment must be pinned to the very end of ROM regardless of where the rest of the code lives.
• Symbol tables for cross-file addressing: the linker can emit a symbol file listing each label's final address, letting other software (like BASIC) reference BIOS routines like character in/character out by fixed address without needing their source.

Walkthrough

Motivation: other computers' BIOS conventions (0:00)

The lecture reviews the Microsoft BASIC-for-6502 GitHub repository, showing how the Commodore 64 and Apple IIe ports hard-code addresses for monitor routines like character-in/character-out — a minimal BIOS pattern this computer needs its own version of before BASIC can be ported.

Building the cc65 toolchain and fixing a CPU mismatch (1:00)

The lecture clones and builds cc65 locally, then assembles the existing Wozmon source with ca65, hitting an "illegal addressing mode" error caused by an instruction (incrementing the accumulator) that only exists on the 65C02, fixed by declaring the correct CPU target.

From object file to linked ROM image (3:02)

The lecture explains that the assembled object file is relocatable, not final machine code, and removes the source's .org directives in favor of linker-controlled placement. It builds up a linker configuration file step by step: defining the RAM and ROM memory regions, assigning the default code segment into ROM, and padding the output to the full 32K ROM size.

Controlling where code and the reset vector land (8:05)

Because the reset vector must sit at the very end of ROM, the lecture introduces custom segments (a Wozmon segment and a separate reset-vector segment) and a dedicated memory region for the reset vector, iteratively adjusting the configuration until Wozmon is correctly placed with the reset vector pointing to it. It writes the resulting image to an EEPROM and confirms Wozmon still boots correctly, then relocates Wozmon to its traditional address at $FF00 by adding another dedicated memory block.

Building a minimal BIOS layer and organizing source files (16:17)

The lecture adds simple character-in and character-out subroutines as a separate "BIOS" segment, reorganizes the source so a new bios.s file defines shared registers and includes Wozmon as a subordinate file, and removes duplicate register definitions from Wozmon itself.

Generating a symbol table for other software to use (19:21)

Using assembler debug-info directives and a linker symbol-file option, the lecture generates a table of every label's final ROM address, showing how the character-in and character-out routine addresses can be found and used by other programs (like a future BASIC port) without needing the BIOS source itself.

Before you watch

• The earlier videos on Wozmon and its adaptation to the serial interface.
• Basic familiarity with assemblers, linkers, and object files in any toolchain.
• Comfort with hexadecimal addressing and the 6502 memory map used throughout this series.

Check your understanding

1. Why can't the linker place code correctly without a memory configuration file once .org directives are removed?
2. Why must the reset vector always end up at the very last two bytes of ROM regardless of where other code is placed?
3. How does defining custom segments give more placement control than relying on the assembler's default code segment?
4. Why is a symbol table useful for software like BASIC that needs to call BIOS routines without including their source?