Quantum Computer. Playfully, a quby. A shared family of machines for learning, making, AI and new frontiers.
Experimental research projectConcept blueprint / September 2026 Functional software exists. These drawings are proposed relationships, not a PCB layout or a manufactured board.
Working software slicePlanned engineeringExperimental research
One stack. Many kinds of computer.
Select a block to inspect its role and next proof step.
Use the layer controls above, then select a component. On a small screen, pan the drawing sideways or use its text links. Keyboard: Tab to a layer, arrow keys to switch, then Tab to components.
The board, as a set of serviceable systems.
Illustrative placement. No dimensions, routed traces or selected parts are implied.
Specialists working with shared data.
CPU, GPU and NPU are useful roles to experiment with. The final division is open.
Begin with a result we can check.
A small classical integer workload is the current functional proof.
Keep the healthy parts in use.
Repairability starts with architecture, access, documentation and software recovery.
Space readiness belongs to a mission.
Orbit, duration, power, radiation and recovery requirements determine the flight configuration.
The idea behind the blueprint
Build a machine people can understand.
Explore a layer above and select a subsystem. Each drawing describes intended relationships, with the next experiment needed to turn a proposal into evidence. The working native designer and simulator are written in Yeho. This web blueprint is a declarative HTML/SVG explanation, not a second simulator.
No physical board, chip, optical or quantum device, VR platform or space-qualified hardware has been demonstrated by Qube yet.
System / people
One family, chosen for the job.
Affordable learning kits, tiny sleeping sensors, pocket computers, robotics, creative machines, gaming/VR and data-center profiles share documented contracts. They do not need the same die, memory size or installed modules.
Interfaces: capability manifests, compatible programs, accessible controls and repair documentation.
Next proof: choose one real activity per profile and measure useful output, energy, cost and usability.
System / language
Co-design the language and the machine.
Yeho owns program meaning, types, memory lifetime and lowering. Dolphin owns spatial and creative primitives; Yodi owns intelligence behavior. Qube experiments should expose costs and capabilities without making ordinary creators program every device by hand.
Next proof: lower one bounded real Yeho workload into the graph model and compare independently expected results.
The owned tools use Yeho; existing host/compiler and website technologies remain identified dependencies.
System / operating system
Starfish, rewritten in Yeho.
The directed rewrite connects firmware, memory protection, scheduling, device discovery, graphics and recovery to the hardware contracts. UEFI is a compatibility goal where a profile can support it; tiny devices may need a smaller boot path.
Next proof: a minimal real Yeho Starfish image boots in our owned machine simulator, handles a timer and recovers from a deliberate fault.
The current graph simulator executes no ISA and boots no operating system. Container isolation is also future work.
Working software / visual workshop
A blueprint you can manipulate.
The native Yeho/Dolphin/YUI designer already has a sixteen-area overview, draggable cards, pan, eased zoom, saved layouts and four initial views. Its board and SoC views are sketches. The eventual workshop links system, board, package, chip, logic, physical structures, simulation and service instructions.
Next proof, 0.2: edit and connect a bounded graph, run that exact graph, inspect values, undo, save, reload and reproduce it in the command-line runner.
General graph editing is not connected to the native UI yet. Manufacturing export currently declares fabrication_ready: false.
Working software / functional model
Small experiments with independent answers.
The fixed native fixture and independent Yeho graph executor agree across 216 configurations. The general runner supports affine, add, matrix multiply and reduction with checked shapes, immutable named buffer versions and signed 32-bit wraparound.
Current measurement: logical accesses, copies and residency. These are not real timing, watts, silicon area or neural-model quality.
Next proof: one shared executable document across the designer and runner, with bounded execution, source-bound evidence and recovery from invalid edits.
Planned engineering / compute assembly
Rethink the division of work.
Study CPU, GPU, NPU and APU ideas as one computer. Scalar control, vector work and tensor operations may share resources where evidence supports it. RISC-V is the leading open instruction-set baseline to evaluate; no final ISA, core count, process node or chiplet contract is selected.
Next proof: run real mixed workloads and compare locality, synchronization, useful results and energy assumptions before fixing architecture.
Planned engineering / CPU role
Control that stays understandable.
Branches, interrupts, operating-system work and irregular programs need predictable architectural behavior. An explicit RISC-V subset is a practical reference for an owned instruction interpreter and eventual custom microarchitecture.
Next proof: pinned instructions, traps, privilege and device semantics with independent known-answer checks, followed by the minimal Starfish boot path.
Planned engineering / GPU role
Parallel work, graphics and VR.
Study vector/SIMT execution, efficient scheduling, tiled rendering, locality and shared resource use. Rendering, display timing, audio and headset behavior must eventually meet measured frame and latency budgets together.
Next proof: a small real graphics workload, then a complete measured frame path. The current arithmetic model is not a GPU or VR runtime.
Planned engineering / AI role
Optimize for useful intelligence.
Evaluate tensor execution, data reuse, sparse work and precision against real model outputs. Co-design with Yeho and Yodi so shape, ownership, accuracy and completion are observable.
Next proof: an actual bounded inference model with frozen inputs, an independent reference and explicit quality tolerances.
Planned hardware / working functional comparison
Move data only when it earns its cost.
Compare unified access, explicit local storage and hybrid designs. Addressability alone does not establish coherence: ownership, synchronization, protection, error correction, bandwidth and contention all need contracts.
Next proof: connect real workloads to measured-versus-assumed traffic and energy. A discrete GPU retains its own memory constraints until interoperability is demonstrated.
Planned engineering / energy
Spend energy on useful work.
Design voltage regulation, power domains, clock gating, deep sleep, retention, wake sources and fault limits together. Compare energy per completed activity and include memory, radios, optics and conversion overhead.
Next proof: a realistic sensor wake/sleep budget with measured leakage, battery aging and duty cycle. A century on one AA remains an aspiration, not a demonstrated battery lifetime.
Planned engineering / heat
Give heat a real path out.
Design package contacts, spreaders, serviceable thermal parts and the enclosure with electrical loads. In vacuum, heat leaves through conduction and radiation rather than ambient-air convection. Optical links still have laser, receiver and conversion costs.
Next proof: component power estimates, a thermal model, then calibrated measurements. Rounded conductors must be evaluated electrically; they do not eliminate resistive loss by avoiding mechanical friction.
Use documented storage boundaries, owner-controlled keys, recoverable firmware and offline restore paths. A compatible replacement should retain access to legitimate user data and calibration without an artificial account or pairing lock.
Next proof: interrupted-write/update recovery, known-good boot and replacement storage restore with user data preserved.
Planned engineering / external connections
One familiar connection, many uses.
Thunderbolt 5 over USB-C is the preferred general exterior connector for appropriate profiles. Controllers, power delivery, display paths, audio, networking, cable reach and daisy-chain resource limits must be qualified together.
Next proof: available controller/IP, firmware and Starfish drivers, with measured interoperability and cost. HDMI displays would require a suitable adapter; HDMI is not the native Thunderbolt display protocol.
Protected builder GPIO is a deliberate additional interface. Space configurations need mission-qualified mechanical and electrical connections.
Planned engineering / builder connections
Make sensors and movement approachable.
Provide documented, protected GPIO and module interfaces with discoverable voltage/current limits. Robotics uses appropriate isolated or protected motor-controller modules; logic pins do not directly power motors.
Next proof: connect a simple sensor and controller, detect a wiring fault and recover without damaging healthy assemblies.
Planned engineering / expansion
Room for comparison and transition.
Study an optional current-generation PCIe expansion path for a qualified NVIDIA card beside our own GPU. Choose from shipping compatible parts when prototyping, with explicit lane, power, cooling, memory and driver requirements.
Next proof: actual controller enumeration, DMA isolation, driver operation and one comparative workload. Qube has not demonstrated NVIDIA support under Starfish.
Planned modules / research link
Wireless that fits the activity.
Support qualified Wi-Fi and Bluetooth modules through owned interfaces. Study an owned room-scale VR link with real throughput, latency, jitter, blockage, coexistence and energy measurements.
Next proof: one real radio module and driver, then a measured room link. Standards compatibility and spectrum obligations remain part of the interface.
Planned engineering / observation
A common language for many senses.
Touch, images, depth, infrared, lidar, ultrasound, sonar, precision positioning and novel scientific sensors need units, timestamps, uncertainty, calibration and explicit operating limits. Optical, radio and acoustic devices can serve observation or communication.
Next proof: one discoverable module with replayable samples and calibration history. Every wavelength or sensing technology still needs suitable real transducers.
Planned engineering / displays and audio
Make the whole experience work together.
Support real panels, headsets and multichannel audio through explicit display, color, timing and device contracts. Advanced holography and open-air displays are separate research tracks with visibility, resolution, eye safety and power requirements.
Next proof: a measured display and synchronized audio path, then a complete headset experience. Optical effects such as rainbows and auroras are inspiration, not a demonstrated addressable pixel system.
Experimental research / light
Use light where the whole link wins.
Explore fiber and package optical links, then bounded photonic acceleration. Include electrical/optical conversion, laser power, thermal tuning, precision, alignment and repair cost in comparisons.
Next proof: a measured component/link experiment compared with an electrical alternative at the same useful throughput, reach and error rate.
No optical hardware has been demonstrated in Qube. Light does not make the system heat-free.
Experimental research / quantum
Keep imagination attached to an experiment.
Explore modular quantum devices, sensing, simulation and networking with classical control. A simulated atom made visually large is an explanatory model, not a way to remove quantum measurement backaction or the cost of accurate quantum simulation.
Next proof: select a bounded published model, reproduce known results and define a measurable device hypothesis.
Entanglement does not enable controllable faster-than-light messages. Instant galactic internet and quantum pixels in open air have no demonstrated mechanism here.
Planned engineering / containment
Make faults small and recovery explicit.
Define memory protection, device isolation, queue lifetimes, watchdogs, reset boundaries, ECC and safe states. Redundant compute needs protection against common-cause power, clock, software and radiation failures.
Next proof: inject specific faults, detect them, contain them and recover a useful workload. A successful restart does not by itself establish a fault-tolerant mission.
Required direction / repair
Highly repairable at every practical layer.
Use reusable fasteners, accessible wear parts, replaceable port/power/storage assemblies, schematics, part identities and safe service procedures. State which parts an owner can replace and which require a bench or specialist.
Next proof: service-boundary studies now; actual timed repairs, compatibility checks and post-repair tests on physical prototypes before release.
High-speed and package constraints must be measured. Individual on-die transistors are not plug-in repair parts; replacing the smallest practical assembly is the target.
Planned engineering / service evidence
Show what failed and how we know.
Connect self-tests, fault logs, accessible test points, known-answer workloads and calibration records to the visible blueprint. Preserve machine and part identities so repairs are reproducible.
Next proof: a deliberately failed module, a useful diagnosis and a successful replacement/recovery record, with time, tools, cost and discarded material recorded.
Required profile direction / space
Specify the mission before promising readiness.
Define orbit or destination, duration, radiation environment, thermal/vacuum conditions, power, launch loads, communication delays, sensing and safe behavior. An uncrewed experimental sensor payload is a sensible first feasibility study, not a selected mission.
Next proof: a bounded mission envelope and parts/process study; then autonomous fault recovery and measured environmental tests for the exact configuration.
Track the unit, revisions, part lots, materials, firmware, calibration and deviations. Establish mission-specific radiation, thermal-vacuum, mechanical, power and electromagnetic verification with specialists and the launch/mission authority.
Next proof: a reviewed qualification plan, then tests and analysis tied to flight configuration and acceptance limits. Passing an ordinary kit milestone is insufficient.
The designer must eventually carry dimensioned geometry, validated connectivity, bill of materials, process/package/IP rights, physical signoff, test coverage and a bring-up plan into an immutable release dossier.
Next proof: supplier feasibility and cost studies early, FPGA parity before silicon, then partner-reviewed files and a real quote before fabrication.
No fabrication-ready files or orders exist in the current slice. This public drawing is not a manufacturing file.
Build next / proposed milestone 0.2
Make the drawing executable.
The next version joins the existing native designer to the general graph runner. A change on the canvas must change the program being run. Package versions are separate from these proposed integration milestones.
Edit the actual graph
Add, connect, change and remove bounded operations. Validate shapes, names, dependencies and resource limits before execution.
Run and inspect the same document
Share production graph semantics between UI and command line. Keep independent checks so two views cannot agree on the same mistake.
Undo, save and recover
Preserve legacy files, atomically validate loads, recover from invalid edits and compare the saved/reloaded result.
Attach evidence to the design
Record source and input identity, results and explicit limitations. Keep fabrication_ready false until physical manufacturing gates are earned.
The path to physical computers
Each version earns a new claim.
The project tracks 109 feature ideas across design, simulation, architecture, software, connections, research, fabrication, openness, repair and space. These are planned work, not 109 shipped features.
NOW → 0.2
Executable blueprint
Connect graph editing, independent results, saving and recovery in one Yeho workbench.
0.3
Real workload laboratory
Yeho programs, graphics, neural, sensor and audio cases. Cost, energy assumptions and supplier feasibility.
Real logic, board measurements, documented parts, selected interfaces and demonstrated repairs.
0.8 → 0.9
Manufacture and measure
Partner-accepted release dossier, fabricated development silicon, characterization and errata.
1.0 → FAMILY
Qualified research kits
Usable examples, recovery, repair and honest cost. Each gaming, tiny or space profile earns its own claims.
Good ideas worth carrying forward
Let people see how their computer works.
Apple II: publish the machinery
Bring schematics, interface explanations and small useful examples together. Qube should connect each part in the drawing to its documents and tests. Apple II Reference Manual
PDP-8/e: design service boundaries
Learn from documented modules and their interconnection. Make the smallest practical Qube assembly diagnosable and replaceable. DEC maintenance manual
Smalltalk: keep experimentation live
Edit, run and inspect in one environment. For Qube, preserve undo, validation and recovery as the real design changes. Dan Ingalls' Smalltalk-72 environment
Sketchpad: give drawings meaning
Connected geometry, constraints and reusable structures make a drawing more than decoration. Qube's canvas should operate on real design data. Ivan Sutherland's thesis
Amiga: coordinate specialists
Learn from the coordination of graphics, sound, DMA and coprocessors. Test Qube's specialists together, including contention and synchronization. Commodore hardware manual
System/360: make a compatible family
Preserve useful program and interface contracts as machines grow. Share Qube's architecture where useful while qualifying each physical profile. IBM's System/360 history
Apollo: design the restart
Fault detection and recovery belong in the architecture. Deliberately break a Qube workload, recover its useful work and retain the evidence. NASA report on computer reliability