1. ARCHITECTURAL PRINCIPLES --------------------------- 1.1 Philosophy ~~~~~~~~~~~~~~ HyperCP/M is a modular operating system architecture designed to preserve and extend the CP/M ecosystem while providing capabilities that were impractical on the original hardware. Rather than evolving a single version of CP/M, HyperCP/M provides a common execution platform capable of hosting multiple operating-system personalities simultaneously. Each personality executes within its own session and observes the execution environment expected by that operating system. CPU state, memory state, and console state are isolated between sessions, while shared resources have explicitly defined sharing semantics. The architecture separates three distinct responsibilities: * HyperCP/M provides the kernel, resource management, session management, virtualization, and hardware abstraction. * Personalities provide operating-system environments such as CP/M 2.2. * Applications execute within a personality and remain unaware of the underlying HyperCP/M implementation unless they explicitly make use of HyperCP/M services. A fundamental design objective is that historical operating systems shall execute without modification whenever practical. HyperCP/M therefore virtualizes the execution environment rather than attempting to reimplement or extend historical operating systems directly. The initial reference personality is CP/M 2.2. This choice reflects its historical significance, broad software compatibility, and suitability as a reference implementation. The architecture, however, is personality-centric rather than CP/M-centric. The kernel shall not contain assumptions specific to any individual personality. HyperCP/M is intended to evolve incrementally. The initial implementation focuses on a small, well-defined set of capabilities that establish the architectural foundation. More advanced facilities--including additional personalities, enhanced operating environments, networking, and automation--are expected to build upon that foundation without requiring architectural redesign. Where practical, HyperCP/M favors simplicity over complexity. Features should arise naturally from well-defined kernel services rather than from special-case implementations. The preferred solution is one that provides a general mechanism from which multiple capabilities can emerge. The architecture is intended to remain understandable by a single developer. Modularity, clear subsystem boundaries, and explicit interfaces are therefore considered primary design goals rather than implementation details. 1.2 Design Goals ~~~~~~~~~~~~~~~~ The primary design goals of HyperCP/M are: Compatibility Maintain the highest practical level of compatibility with historical operating systems and software while preserving architectural integrity. Simplicity Favor simple, well-defined mechanisms over complex, specialized implementations. General kernel services are preferred to feature-specific solutions. Modularity Divide the system into clearly defined subsystems with explicit interfaces and minimal coupling. Extensibility Permit new personalities, devices, and services to be added without requiring redesign of the kernel architecture. Observability Provide built-in mechanisms for diagnosing and inspecting kernel behaviour during development and system maintenance. Diagnostic capabilities shall be designed into the architecture rather than added as implementation afterthoughts. Isolation Provide strong separation between sessions such that each personality observes only the resources explicitly assigned to it. The initial HyperCP/M implementation shall provide cooperative session switching. Concurrent execution of multiple sessions is a future extension and is not required for compatibility with the initial architecture. Incremental Development Permit the system to evolve through a sequence of small, testable milestones, each producing a useful and demonstrable result. Historical Preservation Accurately reproduce historical operating-system environments where practical, allowing existing software to execute without modification. Native Evolution Provide a foundation upon which new operating environments may be developed without being constrained by historical implementation limitations. Evolution The architecture shall avoid unnecessary assumptions that preclude future enhancement. Version-specific implementation constraints may be stricter than the architecture provided they do not unnecessarily restrict future evolution. 1.3 Compatibility ~~~~~~~~~~~~~~~~~ Compatibility is a primary architectural objective of HyperCP/M. Where practical, existing operating systems and application software shall execute without modification. Compatibility shall be achieved by faithfully presenting the execution environment expected by each supported personality rather than by modifying the behaviour of historical software. The kernel shall remain independent of any individual personality. Personality-specific behaviour shall reside within the corresponding personality implementation. Compatibility shall be evaluated at multiple levels, including: * Application compatibility * Operating system compatibility * BIOS compatibility * Device compatibility The initial reference personality shall be CP/M 2.2. Future personalities shall extend the range of supported operating environments without altering the architectural principles defined by this specification. Absolute compatibility is not an objective where it would require compromising architectural integrity, system reliability, or maintainability. Any incompatibilities shall be explicitly documented. 1.4 Extensibility ~~~~~~~~~~~~~~~~~ HyperCP/M is designed to evolve without requiring architectural redesign. The architecture shall permit extension through well-defined interfaces rather than modification of existing subsystems. Examples of expected future extensions include: * Additional operating-system personalities * New virtual devices * Expanded kernel services * Additional storage technologies * Networking facilities * Enhanced console capabilities * Native operating environments The addition of a new capability shall, where practical, require only the implementation of the corresponding subsystem or personality rather than modification of unrelated components. Future enhancements shall build upon existing architectural mechanisms whenever practical. The preferred design is one in which a general service enables multiple future capabilities rather than introducing specialized interfaces for individual features. Features intentionally deferred from the initial implementation shall be recorded separately in the HyperCP/M Future Ideas document and shall not influence the scope of the initial implementation unless formally incorporated into this specification. ============================================================================