# The actual bug — found by reading the code, not guessing

## Root cause: the GDT segment limit was 64MB

In `gdt.cpp` the flat memory segments were defined with a **64MB limit**:

    codeSegmentSelector(0, 64*1024*1024, 0x9A),   // 64MB
    dataSegmentSelector(0, 64*1024*1024, 0x92)    // 64MB

Your Quadro NVS 295 (like all real PCIe GPUs) exposes its framebuffer at a
**high physical address** — typically around 0xD0000000 (3.25 GB). When the
kernel wrote the first pixel there, the CPU saw an address far beyond the 64MB
segment limit, raised a **General Protection fault**, and — because this happens
before the interrupt handlers are installed — it cascaded to a **triple fault**,
which resets the machine.

That is precisely your symptom: GRUB sets its framebuffer (blue flash), the
kernel starts, first framebuffer write → GP fault → **reboot**. Every time.

It was invisible in QEMU because QEMU's standard VGA framebuffer sits at a LOW
address, inside the old 64MB window, so the fault never triggered there.

## The fix (one line, both segments)

    codeSegmentSelector(0, 0xFFFFFFFF, 0x9A),   // full 4GB
    dataSegmentSelector(0, 0xFFFFFFFF, 0x92)    // full 4GB

Now the segment spans the entire 4GB address space, so writes to a high
framebuffer address (0xD0000000, etc.) are legal. Proven by the descriptor math:
old span 0..0x04000000 (64MB) — 0xD0000000 OUTSIDE → fault; new span
0..0xFFFFFFFF (4GB) — 0xD0000000 INSIDE → write OK.

## Boot it

Rufus this `hdgl-c64.iso` (DD Image mode) to USB, boot the NVS 295 machine,
pick a GRUB entry. It should now reach the C64 BASIC face instead of rebooting.
- interactive: type  PRINT 3+4  <Return>  -> 7
- self-test: auto-runs PRINT 3+4 and shows 7

If it STILL reboots, that means there's a second high-address access I haven't
caught — but this removes the one that mathematically guaranteed the reboot on
your hardware.
