BETTERCP/M ARCHITECTURE
ARCHITECTURE SPECIFICATION
Draft 0.1
The BetterCP/M Architecture Specification defines the overall
architecture of BetterCP/M. Each major section of the
specification is maintained as a separate document.
ARCHITECTURE SPECIFICATION
--------------------------
(TXT) 1. Architectural Principles
Philosophy, design goals, compatibility, simplicity,
modularity, extensibility, and deferred design goals.
(TXT) 2. Overall System Architecture
Architectural model, major components, relationships,
control and service flow, and boot overview.
(TXT) 3. Architectural Boundaries
Responsibilities and boundaries between the operating
system, command environment, system services, hardware
support, and applications.
(TXT) 4. Memory Architecture
Memory organization and the allocation and use of the
Z80 address space.
(TXT) 5. Boot Architecture
System initialization and the transition from machine
startup to the BetterCP/M operating environment.
(TXT) 6. Command Environment
Command processing, resident commands, and launching of
transient programs.
(TXT) 7. System Services
Operating-system services provided to programs and other
system components.
(TXT) 8. Hardware Abstraction
Isolation of machine-dependent hardware support from the
machine-independent portions of BetterCP/M.
(TXT) 9. Program Execution Model
Program loading, execution environment, system interaction,
and return to the command environment.
(TXT) 10. Storage and File-System Architecture
Logical disk organization, file-system services, and the
relationship between logical storage and physical media.
(TXT) 11. System State
Operating-system state maintained across commands, programs,
and system-service operations.
(TXT) 12. Compatibility Architecture
Architectural mechanisms and requirements necessary to
preserve CP/M 2.2 compatibility.
(TXT) 13. Architectural Constraints and Invariants
System-wide conditions and assumptions that must remain
true throughout the BetterCP/M implementation.
(TXT) 14. Extension Architecture
Architectural provisions intended to permit later expansion
without making deferred capabilities requirements of the
initial implementation.
(TXT) 15. Open Questions
Architectural questions requiring further investigation or
design decisions.