Specification 00.012.000 for which the toolset currently comes alive might very likely be the final version by binary compatibility.
This does not mean there will be no changes from now, there will, even major ones, as I will explain below, however binary compatibility is very likely to stay from now.
A bit of history first, to summarize the development process:
- On 1st April, version 00.000.000 was opened. This was functional, but obviously had it's problems. Some application development tests followed, while mostly working on the specification in a binary compatible manner, up until and including specification 00.005.000.
- Specification 00.006.000 and 00.007.000 focused on redesigning the graphics subsystem, which in this respect broke backwards compatibility, so all graphics related experiments had to be redone. The core system was not touched significantly, carrying over it's inherent problems (paging system).
- Specification 00.010.000 to 00.012.000 focused on going down to the core, by the previous experiences re-designing it to correct the discovered problems. The most important was the removal of paging, however many minor changes followed all around. While the graphic subsystem didn't change significantly, due to the modified core, everything has to be redone.
The process of evolving the line started with 00.010.000 is mostly complete by now, that is I am now writing applications, testing this system to find remaining bugs in the implementations and whatever minor leftovers which might have stayed in the specification. Like with the previous versions, some iterations mostly concentrating on fixes will likely come.
While I am quite confident in that this system will be OK to last, I also have to admit I simply wouldn't want to redo things again from ground-up. So this will likely stay, that is, applications written to it will likely work further on without too many modifications. Of course, the more distant plan is to have a robust locked system (that's a primary goal of RRPGE, to give a system which would last, so games and stuff never have to be recompiled or otherwise tampered with to keep them functional), however here it is still alpha, the stage where the system should be evolved to live up to the expectations.
And the major change which will likely even enforce this compatibility:Even with the previous take (the 00.007.000 line) I was starting to develop a generic user library which is meant to complement the currently existing base system. The base system has to be emulated with native code (or realized in hardware once), and, to be honest, the interface it provides is not very friendly. Developers would like to have the capability of doing some common tasks included in the system (such as a tile & sprite system for games, or some text output features, such as even some "printf" equivalent for faster construction, debugging, and tools where aesthetic is not critical). The user library is meant to fulfill this role.
This library will be a part of the final system. It is a nice addition on that term that it does not increase emulator (or hardware) complexity at all, since it is pure software running on RRPGE. The way it will be added to the current system matches the way how some initial data is provided: simply the high end of the code memory will be populated with the user library with a well defined entry point table. If an application does not want to use it, it does not need to, it may even override it (by having larger code than fitting under the user library).
Creating this library simply mandates binary compatibility, since otherwise this task would never be finished. The next versions after some leftover testing and example construction will mostly cover the development of this component.
