The MOS API works via RST 8, using the A register to indicate the API number to be executed. This inherently limits the API space to be a maximum of 256 potential APIs...
As of MOS 3.0 we currently have 100 different API calls. The highest API number used is 0xA6 (166). There are plans for new features that will need to add in more APIs to support them. Part of the MOS Modules idea #2 is also to allow modules to provide new API calls.
Space is already tight... And if MOS modules could add in new APIs there'd also be the potential for API number clashes.
We should therefore consider ways to address this, and allow for ways that we could expand our potential API space.
As I'm writing this a couple of ideas spring to mind...
Firstly we could just use another RST code, maybe RST 20h, to open up more space and provide a different API surface. We could establish new more consistent rules for API design within this new space. We could decree that the BC register should be used to specify the API being called, and within that we could split B and C between "module" and "number". We could also decree that the A register should always be used to return a status code. We'd need to establish some rules for module numbering - possibly a simple register?
Alternatively we could add a new API into our existing space under RST 8 for "extended" use, and use a register to indicate the "extended" API being called...
Actually maybe both of these ideas can work, as they're effectively very nearly the same thing.
Another alternative would be to design new functionality to work in a much more restrictive way. A module could be allowed just a single API number. We could establish some basic advice, a rough standard, for having that single API number support multiple APIs. This could be something like "use BC to indicate the sub-call, use HL as a pointer to a block of input args, and use DE as a pointer to an output block"...
These are all obviously very incomplete ideas and need more thought. 😀
The MOS API works via
RST 8, using theAregister to indicate the API number to be executed. This inherently limits the API space to be a maximum of 256 potential APIs...As of MOS 3.0 we currently have 100 different API calls. The highest API number used is
0xA6(166). There are plans for new features that will need to add in more APIs to support them. Part of the MOS Modules idea #2 is also to allow modules to provide new API calls.Space is already tight... And if MOS modules could add in new APIs there'd also be the potential for API number clashes.
We should therefore consider ways to address this, and allow for ways that we could expand our potential API space.
As I'm writing this a couple of ideas spring to mind...
Firstly we could just use another
RSTcode, maybeRST 20h, to open up more space and provide a different API surface. We could establish new more consistent rules for API design within this new space. We could decree that theBCregister should be used to specify the API being called, and within that we could splitBandCbetween "module" and "number". We could also decree that theAregister should always be used to return a status code. We'd need to establish some rules for module numbering - possibly a simple register?Alternatively we could add a new API into our existing space under
RST 8for "extended" use, and use a register to indicate the "extended" API being called...Actually maybe both of these ideas can work, as they're effectively very nearly the same thing.
Another alternative would be to design new functionality to work in a much more restrictive way. A module could be allowed just a single API number. We could establish some basic advice, a rough standard, for having that single API number support multiple APIs. This could be something like "use
BCto indicate the sub-call, useHLas a pointer to a block of input args, and useDEas a pointer to an output block"...These are all obviously very incomplete ideas and need more thought. 😀