# HDGL C64 — metal-safe ISO

## What changed (why earlier ISOs didn't reach the C64 on real hardware)

The earlier kernels set up video via **Bochs/QEMU DISPI VBE** and, when locating
the framebuffer, fell back to a **hardcoded address `0xE0000000`** — QEMU's
framebuffer location. On real hardware the framebuffer lives elsewhere, so the
kernel drew C64 pixels into the wrong memory and you saw uninitialized VRAM /
garbled richness instead of the clean C64 face.

This build is **metal-safe**:
1. The kernel now **prefers the framebuffer GRUB actually set up** and handed it
   via the multiboot info tag (the real address on real hardware), and only
   falls back to Bochs DISPI under QEMU/Bochs.
2. The ISO's `grub.cfg` uses **`set gfxpayload=...`** so GRUB establishes a real
   linear framebuffer before launching the kernel.

Verified booting to the C64 BASIC face in QEMU; the framebuffer path is now the
GRUB-provided one, which is what real hardware needs.

## Rufus (Windows)

1. Rufus → SELECT `iso/hdgl-c64.iso` → **DD Image mode** → START.
2. Boot the PC from USB (boot menu; pick the **non-UEFI / Legacy** USB entry).
3. If USB doesn't appear: BIOS setup → enable **CSM / Legacy boot**, disable
   **Secure Boot**, retry.
4. GRUB menu → "HDGL Commodore 64 (interactive)" → you get READY.
   Type: PRINT 3+4  <Return>  ->  7

## If it STILL shows a rich pattern instead of the C64 on your hardware

That means your GPU didn't give GRUB a framebuffer at a mode the kernel handled.
Tell me your machine's GPU and I'll add its mode. In the GRUB menu you can also
press `c` and try:  `set gfxpayload=1024x768x32` then boot, to test a mode your
card prefers.
