| A | B | C | |
|---|---|---|---|
1 | Priority | ||
2 | (1 to 3) | Goals | Status |
3 | 1 | To give the Amstrad CPC within AMSDOS primarily, a standard way of having hardware drivers. | IN REVIEW |
4 | 1 | Standardise simpler driver types that usually just need stream reading / writing. | IN REVIEW |
5 | 1 | A minimal footprint of current standard CPC RAM should be used. Some bytes at #be80? | In Design |
6 | 1 | Drivers should be able to run from either RAM or ROM. | IN REVIEW |
7 | 1 | There should be some support in BASIC for drivers. | IN REVIEW |
8 | 1 | An easy way to use the driver APIs, similar to CP/M with function numbers. | IN REVIEW |
9 | 1 | A fast way to use the driver APIs, via jumpblocks. | IN REVIEW |
10 | 1 | A way to use the driver directly for maximum flexiblity after it is allocated. | IN REVIEW |
11 | 1 | Standardise more complex driver types such as protocol based devices, network, filesystems, sprites etcs. | Pending |
12 | 1 | Drivers should be somewhat consistently programmed to allow for easier redirection. | IN REVIEW |
13 | 2 | Drivers should not necessarily be automatically run, but nominated (even if in ROM). | Pending |
14 | 2 | Additional CPC RAM should be usable and tagged with some purposes so they don't get corrupted by behaving software. | IN REVIEW |
15 | 3 | If the driver system can work in CP/M, or CP/M Plus, that is an added bonus, but not a focus. | Deferred |