BETTERCP/M FUTURE IDEAS 1. PURPOSE This document records possible capabilities, enhancements, and areas of investigation for BetterCP/M beyond the initial CP/M 2.2-compatible implementation. Items in this document are not requirements and do not imply a commitment to implement them in any particular release. The BetterCP/M v1.0 architecture and engineering design should, where practical and without materially increasing v1.0 complexity, avoid unnecessarily precluding or obstructing these possibilities. 2. MEMORY AND SYSTEM ARCHITECTURE ——————————— 2.1 BANK-SWITCHED MEMORY ———————— Investigate the use of Z80 bank-switched memory in a later BetterCP/M release. Possible uses and architecture remain to be determined. Bank switching is explicitly outside the scope of v1.0. 3. STORAGE ———- 3.1 CONFIG-STYLE LOGICAL DISK FORMATS ————————————- Investigate functionality comparable to Montezuma Micro CP/M’s CONFIG facility, allowing logical disk formats to be selected or configured without rebuilding the operating system. The storage architecture should avoid unnecessarily coupling logical disk organization to a particular physical storage implementation. 3.2 ALTERNATIVE PHYSICAL STORAGE ——————————– Investigate support for storage technologies used by modern Z80-family systems, including: * CompactFlash. * SD cards. * RAM disks. * ROM/flash-backed storage. * Other block-oriented storage devices. Logical CP/M disk organization should, where practical, remain separable from the physical medium providing the storage. 4. HARDWARE PORTABILITY ———————– 4.1 ADDITIONAL Z80-FAMILY SYSTEMS ——————————— Investigate making BetterCP/M easier to adapt to newly built Z80-family computers, including systems based on later processors such as the Z180 and Z280. A future investigation should examine existing hobbyist CP/M systems to determine what changes were required to port CP/M to their hardware and identify recurring portability problems. 4.2 HOMEBREW PORTABILITY AND PORTING KIT Investigate making BetterCP/M particularly easy to bring up on newly built Z80-family computers. A future porting interface should aim to keep the machine-specific portion small, explicit, and well documented. Where practical, a hardware builder should need to provide only the primitive facilities required by the target machine, such as console I/O, storage access, boot initialization, and any optional interrupt or clock facilities. Investigate providing a reference porting kit containing documented machine-interface definitions, skeleton machine-specific modules, example configurations, and one or more reference ports. Possible reference targets include generic Z80 and Z180 systems and representative homebrew hardware. The purpose of such a kit would be to make BetterCP/M an attractive CP/M-compatible operating system for hobbyists designing new hardware, rather than requiring each builder to reconstruct the assumptions and organization of a traditional CP/M BIOS independently. This work is not a v1.0 requirement. The initial architecture should only avoid gratuitous barriers to a clean porting interface where doing so imposes little or no present cost. 4.3 HISTORICAL-MACHINE AND COMMUNITY HARDWARE VALIDATION After BetterCP/M is sufficiently mature on its primary development platform, investigate ports to emulated historical CP/M-class machines. A high-fidelity emulator such as MAME may be useful at this stage for testing BetterCP/M against the hardware characteristics of specific historical systems without making such complexity part of the initial development environment. When suitable historical-machine ports are working under emulation, publish the source code, build instructions, disk images, porting documentation, known-good emulator configurations, and relevant conformance tests so that members of the CP/M community can test BetterCP/M on physical hardware. Community hardware testing may also provide: - Reports of differences between emulated and physical hardware. - Hardware-specific compatibility observations. - Contributions of additional machine-specific ports. - Evidence of hidden assumptions in the hardware-abstraction boundary. Ownership of physical vintage hardware is not a requirement of the BetterCP/M project. 5. BOOT AND PROGRAM LOADING ————————— 5.1 ALTERNATIVE BOOT AND DEPLOYMENT MECHANISMS ———————————————- Investigate deployment from ROM, flash, disk, and other mechanisms appropriate to modern hobbyist Z80-family systems. In particular, investigate ROM-resident or ROM-friendly BetterCP/M configurations for newly built systems. A target might keep substantial portions of BetterCP/M in ROM or flash while placing mutable operating- system state, buffers, and the Transient Program Area in RAM. Where the hardware permits, such a configuration could boot directly from reset into BetterCP/M without requiring CP/M system tracks on writable media. ROM-resident operation shall not be assumed by the baseline system, nor shall it become a v1.0 requirement. Early design should merely avoid unnecessary assumptions that the complete operating-system image must reside in writable RAM when avoiding those assumptions imposes little or no present cost. 5.2 ALTERNATIVE PROGRAM-LOADING MECHANISMS —————————————— Investigate mechanisms beyond loading programs from conventional CP/M logical disks, particularly mechanisms useful on modern hobbyist systems. 6. DEBUGGING ———— 6.1 APPLICATION DEBUGGING SUPPORT ——————————— Investigate operating-system-supported facilities for application debugging. Possible facilities include: * Execution control. * Breakpoints. * Register inspection. * Memory inspection. * BDOS/system-call tracing. * Other debugging hooks exposed by BetterCP/M. This is distinct from the diagnostic instrumentation used internally to develop BetterCP/M itself. 7. GENERAL RULE ————— Future ideas shall not expand the scope of BetterCP/M v1.0 merely because they have been identified. When making v1.0 architectural decisions, however, known future possibilities should be considered where leaving room for them imposes little or no present cost. Speculative infrastructure should not be implemented solely to support an uncommitted future feature.