The new agondev toolchain allows for more modern C to be used, and also supports the use of C++ code. Adopting it would therefore potentially offer us some advantages over ZDS.
An experimental port of the MOS 2.3.3 codebase was made by @tomm and is shown in #156
The approach taken and demonstrated in that PR can be applied to the MOS 3.0 codebase. As the PR is, essentially, just three commits (one of which is effectively already included) it may be possible to manually apply those commits, address the resultant conflicts, and then convert the MOS 3.0 codebase additions that the experimental port would not have included, following the model of how such changes were done.
One consideration here, and a potential reason to not switch toolchains, is that ZDS includes a debugger. This requires Zilog's magic cable, so this tends to not be used by most developers... It is however potentially very useful to have a sophisticated debugger. There is at least one alternative debugger approach for which we have integrated support into the VDP - a demonstration of which can be seen in this video: https://www.youtube.com/watch?v=SGg-DttBok0
The new agondev toolchain allows for more modern C to be used, and also supports the use of C++ code. Adopting it would therefore potentially offer us some advantages over ZDS.
An experimental port of the MOS 2.3.3 codebase was made by @tomm and is shown in #156
The approach taken and demonstrated in that PR can be applied to the MOS 3.0 codebase. As the PR is, essentially, just three commits (one of which is effectively already included) it may be possible to manually apply those commits, address the resultant conflicts, and then convert the MOS 3.0 codebase additions that the experimental port would not have included, following the model of how such changes were done.
One consideration here, and a potential reason to not switch toolchains, is that ZDS includes a debugger. This requires Zilog's magic cable, so this tends to not be used by most developers... It is however potentially very useful to have a sophisticated debugger. There is at least one alternative debugger approach for which we have integrated support into the VDP - a demonstration of which can be seen in this video: https://www.youtube.com/watch?v=SGg-DttBok0