The idea: the bus controller is the kernel
On the Neo6502kbd, the RP2040 serves every cycle of the 6502. Eliott65 takes this situation all the way: since the RP2040 is already there, it will be the system.
On this page
Two requirements at the outset
The project was born from two requests, set out in the feasibility study of 13 October 2026:
- preserve the 6502’s memory, and offer something new;
- start from a blank page: do not reuse Morpheus, the firmware supplied with the Neo6502 (written by Paul Robson).
The study compared three routes: a 6502 system on top of Morpheus, a variant of Morpheus, or an entirely new firmware. The third was chosen. The Morpheus repository served as documentation on the hardware timings and as a point of comparison, without a single line of it being reused. The choice has a price, which is accepted: no program written for Morpheus runs as is on Eliott65.
The project went further than planned in this direction: the HDMI and USB drivers are also written for Eliott65, without the PicoDVI or TinyUSB libraries. Only the Raspberry Pi pico-sdk is used.
The central idea: an “out-of-band” kernel
On a conventional computer, the operating system runs on the processor, and takes up part of its memory. On the Neo6502kbd, there is a second, more powerful processor that sees every memory access of the 6502 go by: the RP2040.
So Eliott65 puts the whole system there. The 6502 runs only the user’s programs. The kernel is said to be out-of-band: it runs alongside the processor it serves, not inside it.
Five ideas that follow from it
The study listed five innovations. Here is what became of each one.
1. A system that takes only 8 bytes ✅
Two bytes of call gate ($FFF8–$FFF9) and the six bytes of vectors that the 6502 requires
($FFFA–$FFFF). Nothing else: no ROM, no system variables, no imposed screen buffer.
By way of comparison, the Morpheus ROM kernel occupies 1,024 bytes at $FC00.
2. System calls without a mailbox ✅
The program passes the kernel the address of a parameter block stored in its own memory, wherever it likes. So there is no area reserved for exchanges. See System calls.
3. An “evanescent” boot ✅
To launch a program, the RP2040 places it directly in the 6502’s memory, holds RESET, then releases it. No loader remains in memory: the program starts in a machine where it is alone.
4. An MMU in the bus controller ❌ (then ✅ another way)
The boldest idea: since the RP2040 decodes every address, it could translate it, and offer the 6502 real paged memory management (protection, sharing, virtual memory).
The criterion set in advance was a speed loss of at most 20%. The measurement gave −34% (4.73 MHz instead of 7.20). Decision: no-go; the variant remains as an experimental option. Multitasking was achieved another way, by swapping pages at the moment of switching programs rather than on every access. See Several programs at once.
5. Instant hibernation ✅
Since all of the 6502’s memory lives in the RP2040, the complete state of the machine can be written to a file, then reloaded. See Hibernation.