Why Are We Still Building 6502 Laptops in 2026? (And Why This One's ROM is a Disaster Waiting to Happen) Here's the thing: I get it. The allure of a simpler machine, a system you can actually hold in your head, is powerful. In an era where "cloud-native" means a thousand microservices and a dependency tree that could choke a redwood, the idea of a 65C02 humming along at 14MHz, driving a 10.1" screen, feels like a breath of fresh air. It's why projects like TechPaula's "Second Revision of 6502 Laptop" still pop up on Hacker News, drawing comments like "Amazing." People are hungry for tangible, understandable tech. But "amazing" doesn't mean "stable," especially when the core 6502 laptop memory map is fundamentally flawed. A good idea can still be built on a house of cards, and this project exemplifies that, highlighting the critical importance of a well-defined 6502 laptop memory map.
The Allure of Retro Computing: Why 6502 Laptops Persist
The 6502 is a legend. It powered the Apple II, the Commodore 64, the NES. It's a CPU that forces you to think about every byte, every cycle. That's the appeal. This second revision of TechPaula's laptop, the LT6502b, shows some real thought in its physical design. They've slimmed it down to a mere 31mm height, a huge improvement from the previous 70mm brick. A single PCB for both keyboard and logic? Smart. That cuts down on interconnects, which means fewer points of failure. And moving to a single USB-C for charging and data, with USB-PD support, is just good engineering for a modern retro build. Even the FFC display connection is a solid choice for a compact form factor. These are the kinds of practical improvements that make a project feel real, not just a proof-of-concept, but they don't compensate for a broken 6502 laptop memory map.
LT6502b's Physical Design: A Step Forward
This second revision of TechPaula's laptop, the LT6502b, shows some real thought in its physical design. They've slimmed it down to a mere 31mm height, a huge improvement from the previous 70mm brick. A single PCB for both keyboard and logic? Smart. That cuts down on interconnects, which means fewer points of failure. And moving to a single USB-C for charging and data, with USB-PD support, is just good engineering for a modern retro build. Even the FFC display connection is a solid choice for a compact form factor. These are the kinds of practical improvements that make a project feel real, not just a proof-of-concept. However, even the most elegant hardware design can be undermined by a flawed 6502 laptop memory map.
The Critical Flaw: Understanding the 6502 Laptop Memory Map
But then you look at the memory map, and my battle-hardened engineer senses start screaming. This isn't just a minor oversight; it's a fundamental architectural flaw that will lead to unpredictable crashes and debugging nightmares. We're talking about a system where the very foundation of its software execution is contradictory. The proposed 6502 laptop memory map is simply unworkable.
Breaking Down the ROM: Stated Sizes vs. Physical Limits
Let's break down the ROM. The total physical ROM is 12288 bytes (0x3000 Hex). That's your hard limit. Now, look at what's supposed to live there:
- EhBASIC (version 2.22p5): Stated size 15104 bytes. Range 0xC000-0xFAFF.
- eWozMon (Enhanced Wozmon): Stated size 768 bytes. Range 0xF000-0xF2FF.
- Bootstrap: Stated size 3322 bytes. Range 0xF300-0xFFF9.
- 6502 Vectors: Stated size 6 bytes. Range 0xFFFA-0xFFFF.
Do the math. The sum of the stated sizes for these components is 15104 + 768 + 3322 + 6 = 19200 bytes. That's 6912 bytes more than the physical ROM can hold. This isn't a tight squeeze; it's like trying to cram a full-size server rack into a NUC case. It just doesn't fit within the constraints of the 6502 laptop memory map.
The Overlap Catastrophe: A Recipe for Disaster
And that's not even the worst part. The address ranges overlap. This is where the 6502 laptop memory map truly becomes a problem.
Memory Map Conflict:
0xC000 +------------------+
| EhBASIC (15104B) |
0xF000 +------------------+ <- OVERLAP START
| eWozMon (768B) |
0xF2FF +------------------+
0xF300 +------------------+
| Bootstrap (3322B)|
0xFFF9 +------------------+
0xFFFA +------------------+
| 6502 Vectors (6B)|
0xFFFF +------------------+ <- OVERLAP END
- EhBASIC claims the range 0xC000-0xFAFF.
- eWozMon claims 0xF000-0xF2FF. This means eWozMon is directly overwriting the last 768 bytes of EhBASIC.
- The Bootstrap claims 0xF300-0xFFF9. This overwrites the rest of EhBASIC and eWozMon.
- The 6502 Vectors, which are absolutely critical for interrupt handling and reset, claim 0xFFFA-0xFFFF. These are stomping all over the end of the Bootstrap and EhBASIC.
This isn't a "feature." This is a recipe for disaster. When the CPU tries to fetch an instruction from, say, 0xF100, which code is it going to get? EhBASIC's? eWozMon's? Whichever one got loaded last, or whichever one the memory controller thinks it's supposed to be? This is a classic memory collision, a failure mode that will manifest as random crashes, corrupted data, and completely unpredictable behavior. (I've seen systems go P0 at 3 AM for less fundamental issues than this.)
The RAM situation looks better on paper: 48816 bytes total, with 46KB for the user and 1280 bytes dedicated to Compact Flash R/W. That's a reasonable split for a retro machine. But if your core ROM is fundamentally broken due to a flawed 6502 laptop memory map, the RAM doesn't matter much. You're building a beautiful house on quicksand.
The stated EhBASIC version inconsistency ("22p2" vs "2.22p5") is a minor detail compared to the ROM map, but it points to a lack of rigorous version control and documentation, which often accompanies deeper architectural issues.
The Path Forward: Fixing the 6502 Laptop Memory Map
The fix here is non-negotiable: you need a proper, non-overlapping memory map. You have 12288 bytes of ROM. You have to fit your BASIC, your monitor, your bootstrap, and your vectors within that space, with clear, distinct address ranges. If EhBASIC is truly 15104 bytes, it simply cannot fit in a 12288-byte ROM. You either need a smaller BASIC, more ROM, or a bank-switching scheme (which adds complexity). Pretending it fits is just asking for trouble. This fundamental correction to the 6502 laptop memory map is paramount for stability.
This project has some genuinely cool engineering choices in its physical design, showing a real passion for the platform. But the memory map is a glaring, critical flaw. Until that's sorted, this isn't a stable retro laptop; it's a fascinating, but ultimately unreliable, experiment. Get the fundamentals of the 6502 laptop memory map right, or everything else is just window dressing.
